On 02/25/2019 02:16 PM, Henri Verbeet wrote:
On Mon, 25 Feb 2019 at 12:51, Józef Kucia joseph.kucia@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?