[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:40:51 PDT 2011


On 10/31/2011 11:04 AM, Ian Romanick wrote:
> 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.

Looking at the surrounding code, that leaves only two bitfields in that 
structure.  I'm going to change 'initialized' to a bool and 'sampler' to 
a uint8_t.  I don't anticipate having more than 256 possible samplers in 
the near future.


More information about the mesa-dev mailing list