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"<i...@freedesktop.org> wrote:
From: Ian Romanick<ian.d.roman...@intel.com>
Signed-off-by: Ian Romanick<ian.d.roman...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
