[Mesa-dev] [PATCH] glsl: atomic counters are different than their uniforms

[Ian Romanick]

On 06/30/2016 12:50 AM, Andres Gomez wrote:
> 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?

Sounds good to me.

> Thanks!