On 2/13/20 19:10, Henri Verbeet wrote:
On Thu, 13 Feb 2020 at 19:25, Paul Gofman gofmanp@gmail.com wrote:
On 2/13/20 18:37, Henri Verbeet wrote:
On Thu, 13 Feb 2020 at 18:28, Paul Gofman gofmanp@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.