On 16/09/15 10:52, Samuel Iglesias Gonsálvez wrote:
[...]
>>>> As way of validation, have you tried running your modified script
>>>> against any other drivers? They may well have bugs in them as well,
>>>> but it should be possible to determine if the bug is in the script or
>>>> the other impl, should they not match up.
>>>>
>>>> -ilia
>>>>
>>>
>>> I tested it on NVIDIA proprietary driver version 352.21. It has an issue
>>> when we query shader storage block members when they are arrays of
>>> structs and the index is different than zero -> it doesn't find them as
>>> active. For example:
>>>
>>> struct B {
>>> vec4 a[2];
>>> }
>>>
>>> layout(std430) buffer Block {
>>> B[2] s;
>>> vec3 v;
>>> };
>>>
>>> NVIDIA marked v, s[0].a[0] and s[0].a[1] as active but s[1].a[0] and
>>> s[0].a[1] as inactive even when they are referenced in main().
>>>
>
> ... but s[1].a[0] and s[*1*].a[1] as inactive ...
>
>>> I have not checked yet what ARB_program_interface_query spec says
>>> regarding to that to see if it is a bug in our driver or in NVIDIA's.
>>>
>>> However, I modified by hand the failed autogenerated tests removing the
>>> queries to those "inactive" variables. As we are interested in offsets,
>>> arrays strides and so on, polling index zero of all the top level array
>>> of struct members is enough. With that modifications, those tests pass.
>>>
>>> I plan to try to adapt my script to NVIDIA behavior so I can validate it
>>> properly. However, these preliminary results indicate that I don't have
>>> made any big mistake.
>>
>> From the spec:
>>
>> * For an active variable declared as an array of basic types, a single
>> entry will be generated, with its name string formed by concatenating
>> the name of the array and the string "[0]".
>>
>> * For an active shader storage block member declared as an array, an
>> entry will be generated only for the first array element, regardless
>> of its type. For arrays of aggregate types, the enumeration rules
>> are
>> applied recursively for the single enumerated array element.
>>
>> I find this stuff very difficult to interpret properly, TBH, but I
>> think the above may be relevant.
>>
>> -ilia
>>
>
> OK, I will take a look at it as it mentions explicitly active shader
> storage block members declared as an array. It is possible that we have
> a bug in our code.
>
I checked it and there is a bug in our code, we need to apply the
top-level array flattening for shader storage block members.
We even have an example on ARB_program_interface_query, "Issues" section:
"We also apply the top-level array flattening for shader storage
block members. For example:
buffer Block {
vec4 a[5][4][3];
};
would enumerate only four entries -- "a[0][0][0]" through
"a[0][3][0]", where each enumerated entry corresponds to an array
of size 3, has a top-level size of 5, and has a top-level stride
appropriate for its layout in memory."
I am going to write a follow-up patch fixing this.
Thanks,
Sam
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
