NV bug (tested on 314.14) using storage buffer objects..

UPDATE:Sorry for poor code pasting I was testing correct code (with semicolons and defined g_mProjectionInv like mat4x4 so doesn't change any observation)
Hi I seem to have found a bug using storage buffer objects porting deferred+ code to GLSL
I tried to use a storage buffer instead of default uniform buffer to see only how affected perf.. so

According to the GLSL spec the only way to access members of a matrix is using array subscripting syntax:

5.6 Matrix Components

The components of a matrix can be accessed using array subscripting syntax. Applying a single subscript
to a matrix treats the matrix as an array of column vectors, and selects a single column, whose type is a
vector of the same size as the matrix. The leftmost column is column 0. A second subscript would then
operate on the column vector, as defined earlier for vectors. Hence, two subscripts select a column and
then a row.

mat4 m;
m[1] = vec4(2.0); // sets the second column to all 2.0
m[0][0] = 1.0; // sets the upper left element to 1.0
m[2][3] = 2.0; // sets the 4th element of the third column to 2.0

Behavior is undefined when accessing a component outside the bounds of a matrix with a non-constant
expression. It is an error to access a matrix with a constant expression that is outside the bounds of the
matrix.

It should not work when using a uniform buffer as well. It seems the NVIDIA compiler is taking another path there.

so seems doesn't like .w modifier and seems coming from access to matrices mat4x4

It's more likely that you didn't use semicolons. Especially considering that, well, there aren't any semicolons anywhere in the code you posted. You should add some and get back to us.

@AHeumann: That doesn't make sense. An array of column vectors would treat `arc[0]` as a vector. And it is legal to do `.w` on a vector. Therefore, if `arc` is an array of column vectors, `arc[0].w` should be legal GLSL code.

First sorry for poor posting I'm using semicolons of course but not posted here.. also I have another Storage buffer or uniform buffer and it contains g_mProjectionInv see here (I cleaned semicolons for not showing commented HSLS port:

doesn't fix nothing as still generates same nv assembly code with .w
as said using uniform objects fixes issue so it's a bug in NV compiler..
I can post full code if needed but issue is good isolated now..