[Mesa-dev] [PATCH 05/20] glsl: Add new structures for tracking uniforms in linked shaders
Ian Romanick
idr at freedesktop.org
Mon Oct 31 11:04:40 PDT 2011
On 10/28/2011 02:28 PM, Eric Anholt wrote:
> On Fri, 28 Oct 2011 10:42:32 -0700, "Ian Romanick"<idr at freedesktop.org> wrote:
>> From: Ian Romanick<ian.d.romanick at intel.com>
>>
>> Signed-off-by: Ian Romanick<ian.d.romanick at intel.com>
>> ---
>> src/glsl/ir_uniform.h | 128 +++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 128 insertions(+), 0 deletions(-)
>> create mode 100644 src/glsl/ir_uniform.h
>>
>> diff --git a/src/glsl/ir_uniform.h b/src/glsl/ir_uniform.h
>> new file mode 100644
>> index 0000000..ba442f8
>> --- /dev/null
>> +++ b/src/glsl/ir_uniform.h
>
>> + /**
>> + * Set each time the value of the uniform is change.
>> + *
>> + * Drivers that do not used the \c ::driver_storage interface should clear
>> + * this bit when the value of the uniform is updated on the hardware.
>> + */
>> + unsigned dirty:1;
>
> Having reached near the end of the patch series, I don't see any user of
> the dirty bit, nor any reasonable way for someone to actually use the
> dirty bit. Are you imagining some implementation where somebody's
> DMAing in the dirty uniform components into an existing hardware uniform
> buffer? Wouldn't that be a property of driver storage, not this
> structure?
The idea, which I never used, was that a driver could just use the
gl_constant_value data in the uniform itself.
I was also thinking a driver could use this to only upload data from the
gl_program_parameters that have changed. Thinking about it a bit more,
you are correct. There is no way a driver could use this field in that
manner.
I'll go ahead and remove it.
More information about the mesa-dev
mailing list