[resend PATCH v3 2/4] wined3d: Support Nvidia alpha to coverage state.

[Paul Gofman]

On 2/13/20 19:41, Paul Gofman wrote:
> On 2/13/20 19:10, Henri Verbeet wrote:
>> On Thu, 13 Feb 2020 at 19:25, Paul Gofman <gofmanp at gmail.com> wrote:
>>> On 2/13/20 18:37, Henri Verbeet wrote:
>>>> On Thu, 13 Feb 2020 at 18:28, Paul Gofman <gofmanp at gmail.com> wrote:
>>>> I was thinking of simply taking WINED3D_RS_ADAPTIVETESS_Y into account
>>>> when setting the blend state in wined3d_device_apply_stateblock().
>>>> I.e., some variant of the following:
>>>>
>>>>     if (changed->blend_state || state_changed(changed->renderState,
>>>> WINED3D_RS_ADAPTIVETESS_Y))
>>>>     {
>>>>         blend_state = state->blend_state;
>>>>         if (state->rs[WINED3D_RS_ADAPTIVETESS_Y] == WINED3DFMT_ATOC)
>>>>             blend_state = device->blend_state_atoc_enabled;
>>>>         ...
>>>>         wined3d_device_set_blend_state(..., blend_state, ...);
>>>>     }
>>> This will reset ATOC state whenever application sets _ADAPTIVETESS_Y,
>>> while the application could have set ATOC state AMD way previously (not
>>> in the current stateblock, so changed->blend_state is 0 and
>>> state->blend_state is NULL).
>> I don't think that can happen for WINED3D_SBT_PRIMARY stateblocks.
>> (I.e., the ones used with wined3d_device_apply_stateblock().) That
>> does mean some loss of generality for
>> wined3d_device_apply_stateblock(), but I don't think that can be
>> maintained once it starts setting state objects anyway. I.e., I think
>> it's fine to assume the stateblock contains complete and consistent
>> state in wined3d_device_apply_stateblock().
>
> ATOC state can be set / reset with _SBT_RECORDED stateblocks as well.
> The logic for this case seems to work now: if the recorded stateblock
> had an AMD trigger then state block has changed.blend_state and updates
> it, otherwise it does not touch it. It is encoded not exactly
> straightforward but looks the same in principle like if we had something
> like D3DRS_ATOC separate state. I. e., I think we could introduce
> WINED3D_RS_ATOC and translate _POINTSIZE('A2M1') to _RS_ATOC(TRUE) and
> _POINTSIZE('A2M0') to _RS_ATOC(FALSE) (I am not suggesting to do so at
> least because it won't simplify the things in wined3d anyway due to
> d3d11 blend state object). But maybe it worth to change
> wined3d_stateblock_set_render_state() and not to record _RS_POINTSIZE in
> case it is (re)setting ATOC? This would simplify blend state application
> in wined3d_device_apply_stateblock() and wined3d_device_apply_stateblock().
>
> While d3d9 adaptive tesselation itself which could interfere with AMD
> ATOC state is barely ever used or supported, my concern was more related
> to games which like to reset a bunch of random (or all) states now and
> then just in case. But it is not something I have an application to
> depend on though.
>
>
>
Sorry, please ignore this message. I figured my previous implementation
of Nvidia state in state.c is functionally equivalent to what you suggested.