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

[Józef Kucia]

On Fri, Feb 22, 2019 at 11:49 PM Zebediah Figura  wrote:
> Right. As long as we're here, can we clarify what we want the end goal
> for this architecture to look like? I think I've been misunderstanding
> somewhat. E.g. what should the body of d3d9_device_SetRenderState()
> resemble? I was originally picturing something like this:
>
> static HRESULT WINAPI DECLSPEC_HOTPATCH
> d3d9_device_SetRenderState(IDirect3DDevice9Ex *iface,
>         D3DRENDERSTATETYPE state, DWORD value)
> {
>     struct d3d9_device *device = impl_from_IDirect3DDevice9Ex(iface);
>     struct wined3d_rasterizer_state *rasterizer_state;
>     struct wined3d_color factor;
> TRACE("iface %p, state %#x, value %#x.\n", iface, state, value);
>
> if (state > WINED3D_HIGHEST_RENDER_STATE)
> {
>     ERR("Invalid render state %#x.\n", state);
>     return D3DERR_INVALIDCALL;
> }
>
> wined3d_mutex_lock();
>
> device->update_state->rs[state] = value;
>
> if (device->recording)
> {
>     device->recording->changed.renderState[state >> 5] |= 1u <<
>
> (state & 0x1f);
>         wined3d_mutex_unlock();
>         return D3D_OK;
>     }
> switch (state)
> {
> case D3DRS_FILLMODE:
> case D3DRS_CULLMODE:
> case D3DRS_DEPTHBIAS:
> case D3DRS_SLOPESCALEDEPTHBIAS:
> case D3DRS_SCISSORTESTENABLE:
> case D3DRS_MULTISAMPLEANTIALIAS:
> case D3DRS_ANTIALIASEDLINEENABLE:
>     if (FAILED(hr =
>
> d3d9_rasterizer_state_from_render_state(device->state.rs,
> &rasterizer_state)))
>         {
>             wined3d_mutex_unlock();
>             return hr;
>         }
>         wined3d_rasterizer_state_decref(device->rasterizer_state);
>         device->rasterizer_state = rasterizer_state;
>         wined3d_device_set_rasterizer_state(device->wined3d_device,
> rasterizer_state);
>         break;
>     case D3DRS_SRCBLEND:
>     case D3DRS_DESTBLEND:
>     case D3DRS_BLENDOP:
>     case D3DRS_SRCBLENDALPHA:
>     case D3DRS_DESTBLENDALPHA:
>     case D3DRS_BLENDOPALPHA:
>     case D3DRS_COLORWRITEENABLE:
>     case D3DRS_COLORWRITEENABLE1:
>     case D3DRS_COLORWRITEENABLE2:
>     case D3DRS_COLORWRITEENABLE3:
>          /* sim. */
>     case D3DRS_BLENDFACTOR:
>         wined3d_color_from_d3dcolor(&factor, value);
>         wined3d_device_set_blend_state(device->wined3d_device, NULL,
> &factor);
>     default:
>         wined3d_device_set_render_State(device->wined3d_device, state,
> value);
>     }
> wined3d_mutex_unlock();
> return D3D_OK;
>
> }
>
> but this seems to not quite be what you want; can you please help clarify?

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.