[Mesa-dev] [PATCH] glsl: atomic counters are different than their uniforms
Andres Gomez
agomez at igalia.com
Thu Jun 30 07:50:38 UTC 2016
On Thu, 2016-06-30 at 00:29 -0700, Ian Romanick wrote:
> On 06/29/2016 05:55 PM, Timothy Arceri wrote:
...
> > <insert supporting spec quote??>
>
> So, I don't think there is a clear part of the spec to quote here,
> and
> I looked. :) While the spec doesn't come right out and say it, I
> think
> we can infer that this behavior is correct. It's clear how offsets
> will be assigned for arrays:
>
> * Arrays of type atomic_uint are stored in memory by element
> order,
> with array element member zero at the lowest offset. The
> difference
> in offsets between each pair of elements in the array in basic
> machine
> units is referred to as the array stride, and is constant across
> the
> entire array. The stride can be queried by calling GetIntegerv
> with
> a <pname> of UNIFORM_ARRAY_STRIDE after a program is linked.
>
> From that it is clear how arrays of atomic counters will interact
> with
> GL_MAX_ATOMIC_COUNTER_BUFFER_SIZE.
>
> For other kinds of uniforms it's also clear that each entry in an
> array
> counts against the relevant limits.
>
> I think this is correct, but you have to rely on inference.
I bumped into the same problem, having to infer the expected behavior
to know whether the related CTS test implementation was correct or it
was mesa's implementation. I came to the same conclusion.
You have put it very well into words in your answer. What about I use
your paragraph above to include it into the commit message?
Thanks!
--
Br,
Andres
More information about the mesa-dev
mailing list