In block naming under NVIDIA driver

Linux 32-bit, 256.35

Here goes:



struct lightdata_type
{
  vec3 light_position, light_direction, light_color;
  float directional_attenuation_cos_begin, directional_attenuation_cos_end;
  float radial_attenuation_begin;
  float radial_attenuation_linear;
  float radial_attenuation_quad;
  float radial_cutoff;
};
in lightdata_in
{
  struct lightdata_type L_vertex_in;
} L;

gives me:

Attributes:
3: lightdata_in.L_vertex_in.directional_attenuation_cos_begin
4: lightdata_in.L_vertex_in.directional_attenuation_cos_end
2: lightdata_in.L_vertex_in.light_color
1: lightdata_in.L_vertex_in.light_direction
0: lightdata_in.L_vertex_in.light_position
5: lightdata_in.L_vertex_in.radial_attenuation_begin
6: lightdata_in.L_vertex_in.radial_attenuation_linear
7: lightdata_in.L_vertex_in.radial_attenuation_quad

for my list of attributes according to glGetActiveAttrib and glGetAttribLocation.

But changing it to:


in lightdata_in
{
  struct lightdata_type L_vertex_in;
};

does NOT change the name of the attributes, i.e. dropping the instance name does not change the names from the API:

Attributes:
3: lightdata_in.L_vertex_in.directional_attenuation_cos_begin
4: lightdata_in.L_vertex_in.directional_attenuation_cos_end
2: lightdata_in.L_vertex_in.light_color
1: lightdata_in.L_vertex_in.light_direction
0: lightdata_in.L_vertex_in.light_position
5: lightdata_in.L_vertex_in.radial_attenuation_begin
6: lightdata_in.L_vertex_in.radial_attenuation_linear
7: lightdata_in.L_vertex_in.radial_attenuation_quad

(also in the rest of the shader L.L_vertex_in is changed to L_vertex_in).

The GLSL spec has this (section 4.3.8.1)

Outside the shading language (i.e., in the API), members are similarly identified except the block name is
always used in place of the instance name (API accesses are to interfaces, not to shaders). If there is no
instance name, then the API does not use the block name to access a member, just the member name.

So I figured that by leaving the instance name out then the prefix “lightdata_in.” would be dropped in the API name.

Though I have to admit, the spec has me scratching my head as it says the API uses the blockname (where as GLSL uses the instance name)… which makes me wonder what is supposed to happen if one does:


in lightdata_in
{
  struct lightdata_type L_vertex_in;
} L1;

in lightdata_in
{
  struct lightdata_type L_vertex_in;
} L2;

From the shader point of view all is rosy and doing so does not make the NVIDIA compiler freak out either, I am guessing that then L2.whatever and L1.whatever actually then refer to the exact same thing? The output of glGetActiveAttrib and glGetAttribLocation suggest this atleast. Anyone know if (and where) the spec covers this case?

Section 4.3.7 “Interface Blocks” of GLSL 410 spec first paragraph says:
“It is illegal to have an input block in a vertex shader or an
output block in a fragment shader; these uses are reserved for future use.”

So we should probably fix the driver to produce a compile error if interface blocks are used like this.

I believe we already treat uniform interface blocks fine and correctly strip off the block name if the instance name isn’t used in the shader. We may have a problem with XFB variables, which I need to look into.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.