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().