From: Zebediah Figura Subject: Re: [PATCH v2 1/5] wined3d: Introduce wined3d_device_apply_stateblock(). Message-Id: <5f3e0bde-b6b4-3d95-c1f0-b2afcaff3832@gmail.com> Date: Fri, 13 Dec 2019 09:53:35 -0600 In-Reply-To: References: <20191211034354.809085-1-z.figura12@gmail.com> On 12/12/19 7:22 AM, Henri Verbeet wrote: > On Wed, 11 Dec 2019 at 07:16, Zebediah Figura 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.