[PATCH 5/6] d3d9: Handle stateblocks in d3d9_device_SetVertexShader().

[Zebediah Figura]

On 02/25/2019 02:16 PM, Henri Verbeet wrote:
> On Mon, 25 Feb 2019 at 12:51, Józef Kucia <joseph.kucia at gmail.com> wrote:
>> I'm not sure about the exact design, but I think it would be preferred
>> to introduce an abstraction in wined3d for the state translation to
>> new d3d11-like state objects. Mainly because, there are no reasons to
>> duplicate code in client libraries, and the state translation won't be
>> entirely trivial, e.g. we need some caching mechanism for the state
>> objects. I expect that d3d9_device_SetRenderState() should just call
>> some wined3d helpers methods. In theory, the state translation code
>> could even reside in a separate library outside wined3d, but we don't
>> have strong reasons to introduce a new library.
>>
>> Also, I don't think that we want to create rasterizer and blend state
>> objects in d3d9_device_SetRenderState(). We should create and set
>> state objects just before draw calls.
>>
>> You may want to ask Henri for his opinion. Hopefully, it aligns with
>> my description.
>>
> Yeah. I'd put this in roughly the same category as the
> wined3d_private_store helpers. I think it's fine for the
> wined3d_stateblock_state structure to be in the public header, but
> probably not the details of wined3d_stateblock itself. State object
> extraction should happen on draws.
> 

Right, okay, thanks. So then would the translation happen on the wined3d
side? I.e. would we have d3d[789] call wined3d_device_set_render_state()
as now, and that would forgo invalidating state for things like depth
bias until a draw call occurs? Or would the client d3d libraries be
responsible for calling wined3d_device_set_render_state() only for
states that actually correspond to wined3d render states?