[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