[PATCH 5/5] wined3d: Move some states to wined3d_rasterizer_state.
Zebediah Figura
z.figura12 at gmail.com
Wed Mar 4 11:12:16 CST 2020
On 3/4/20 9:18 AM, Henri Verbeet wrote:
> On Wed, 4 Mar 2020 at 03:27, Zebediah Figura <z.figura12 at gmail.com> wrote:
>> Signed-off-by: Zebediah Figura <z.figura12 at gmail.com>
>> ---
>> dlls/d3d11/device.c | 20 ----------
>> dlls/d3d11/state.c | 8 +++-
>> dlls/wined3d/context.c | 7 ++--
>> dlls/wined3d/cs.c | 6 +--
>> dlls/wined3d/device.c | 62 +++++++++++++++++++++++++-----
>> dlls/wined3d/state.c | 85 +++++++++++++++++++++---------------------
>> dlls/wined3d/surface.c | 4 +-
>> include/wine/wined3d.h | 6 +++
>> 8 files changed, 115 insertions(+), 83 deletions(-)
>>
> This moves a bunch of things at the same time. That isn't necessarily
> wrong, but does make it harder to bisect if something were to
> inadvertently go wrong.
Sure, makes sense. I can resend while moving one thing at a time.
>
>> + if (set_rasterizer_state)
>> + {
>> + struct wined3d_rasterizer_state *rasterizer_state;
>> + struct wined3d_rasterizer_state_desc desc;
>> + union
>> + {
>> + DWORD d;
>> + float f;
>> + } bias;
>> +
>> + desc.fill_mode = state->rs[WINED3D_RS_FILLMODE];
>> + desc.cull_mode = state->rs[WINED3D_RS_CULLMODE];
>> + desc.front_ccw = FALSE;
>> + bias.d = state->rs[WINED3D_RS_DEPTHBIAS];
>> + desc.depth_bias = bias.f;
>> + desc.depth_bias_clamp = 0.0f;
>> + bias.d = state->rs[WINED3D_RS_SLOPESCALEDEPTHBIAS];
>> + desc.scale_bias = bias.f;
>> + desc.depth_clip = TRUE;
>> + desc.scissor = state->rs[WINED3D_RS_SCISSORTESTENABLE];
>> + desc.line_antialias = state->rs[WINED3D_RS_ANTIALIASEDLINEENABLE];
>> +
>> + if (SUCCEEDED(wined3d_rasterizer_state_create(device, &desc,
>> + NULL, &wined3d_null_parent_ops, &rasterizer_state)))
>> + {
>> + wined3d_device_set_rasterizer_state(device, rasterizer_state);
>> + wined3d_rasterizer_state_decref(rasterizer_state);
>> + }
>> + }
> Recreating state objects here doesn't seem ideal. (For comparison,
> look at sampler objects in sampler().)
>
Okay, that makes sense.
Broadly, though, I'm curious how this approach is more performant (or
otherwise preferable) to just copying something like
wined3d_rasterizer_state_desc as a flat structure. The only advantage I
see is that it takes up less space in the CS; is that important enough
to outweigh the overhead of allocation and rbtree lookup, or is there
something else I'm missing?
More information about the wine-devel
mailing list