[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