[PATCH v2 1/2] wined3d: Support AMD alpha to coverage state.

[Henri Verbeet]

On Wed, 12 Feb 2020 at 15:17, Paul Gofman <gofmanp at gmail.com> wrote:
> On 2/12/20 14:28, Henri Verbeet wrote:
> >> So maybe then I introduce wined3d_stateblock_set_blend_state() for now,
> >> manage D3DRS_BLENDFACTOR in d3d9 (if I am not missing something this
> >> state is d3d9 only) and remove WINED3D_RS_BLENDFACTOR handling from
> >> wined3d? I suppose on top of this managing ATOC from d3d9 should be trivial.
> >>
> > I don't think you need to touch WINED3D_RS_BLENDFACTOR.
>
> No, I don't need that for implementing d3d9 ATOC state. I just thought
> that it is a step towards moving blend states to d3d11 style, which
> looked natural if I was to implement wined3d_stateblock_set_blend_state().
>
Oh, in case it wasn't quite clear, what we'd do would be to push
stateblocks out of core wined3d. So stateblocks would still be dealing
with render states, but the wined3d device wouldn't, and translation
from render states to state objects would happen in
wined3d_device_apply_stateblock().

> > You'd need to
> > track the AtoC state somewhere in the stateblock, update it in
> > wined3d_stateblock_set_render_state(), and apply the corresponding
> > blend state object in wined3d_device_apply_stateblock().
>
> Yes, that is something close to what I was trying to suggest a bit
> earlier before considering broader plans of state redesign which you
> shared. So I should probably go this way now? I suppose I can bypass the
> proper creation and destruction of blend state object in state block
> with wined3d_blend_state_create / decref, and just use it as a plain
> structure.
>
You could, but I think that's probably best avoided. You'd only need a
single blend object anyway, since setting NULL is equivalent to
disabling AtoC.