[PATCH 5/6] d3d9: Handle stateblocks in d3d9_device_SetVertexShader().
hverbeet at gmail.com
Mon Feb 25 14:16:44 CST 2019
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.
More information about the wine-devel