[PATCH v2 1/5] wined3d: Introduce wined3d_device_apply_stateblock().
z.figura12 at gmail.com
Fri Dec 13 09:53:35 CST 2019
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.
More information about the wine-devel