[PATCH v2 1/5] wined3d: Introduce wined3d_device_apply_stateblock().

[Zebediah Figura]

On 12/12/19 7:22 AM, Henri Verbeet wrote:
> On Wed, 11 Dec 2019 at 07:16, Zebediah Figura <z.figura12 at gmail.com> wrote:
>> +    wined3d_device_set_vs_consts_f(device, 0, d3d_info->limits.vs_uniform_count, state->vs_consts_f);
>> +    wined3d_device_set_vs_consts_b(device, 0, WINED3D_MAX_CONSTS_B, state->vs_consts_b);
>> +    wined3d_device_set_vs_consts_i(device, 0, WINED3D_MAX_CONSTS_I, state->vs_consts_i);
>> +    wined3d_device_set_ps_consts_f(device, 0, d3d_info->limits.ps_uniform_count, state->ps_consts_f);
>> +    wined3d_device_set_ps_consts_b(device, 0, WINED3D_MAX_CONSTS_B, state->ps_consts_b);
>> +    wined3d_device_set_ps_consts_i(device, 0, WINED3D_MAX_CONSTS_I, state->ps_consts_i);
>> +
> That's going to invalidate every constant on every draw, even if none
> of them changed, which seems undesirable. It shouldn't be too hard to
> extract ranges from the "changed" info, although ideally changed float
> constants would be stored in a proper bitmap first.
> 

Sure, I can try for that. I admittedly don't have a great idea of the
tradeoffs and bottlenecks involved here, so a bit of clarification would
also be appreciated.