Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 12

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

  1. #1
    Intern Newbie
    Join Date
    Oct 2007
    Posts
    47

    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
    Code :
    #ifdef USE_SBO
    layout(binding = 0) buffer cbPerObject 
    #else
    uniform cbPerObject
    #endif
    {
        mat4x4  g_mWorldViewProjection;     
        mat4x4  g_mWorldView;               
        mat4x4  g_mWorld;                   
        float4  g_MaterialAmbientColorUp;
        float4  g_MaterialAmbientColorDown;
    };
    has code like accessing
    Code :
    either using
    g_mProjectionInv[2].w
    or
    g_mProjectionInv[2][3]

    shader compiles (ie. generates NV assembly but fails with:
    Code :
    -- error message --
    line 710, column 30:  error: expected ';'
    line 711, column 29:  error: expected ';'
    -- internal assembly text --
    !!NVcp5.0
     
    offending lines:
    LDB.F32X4 R3.x, sbo_buf1[112].w;
    LDB.F32X4 R2.x, sbo_buf1[96].w;
    so seems doesn't like .w modifier and seems coming from access to matrices mat4x4
    Last edited by oscarbg; 03-11-2013 at 06:52 AM.

  2. #2
    Junior Member Newbie
    Join Date
    Jan 2013
    Posts
    11
    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.

    If you change
    Code :
    g_mProjectionInv[2].w
    to
    Code :
    g_mProjectionInv[2][3]
    it should work.

  3. #3
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.

  4. #4
    Junior Member Newbie
    Join Date
    Jan 2013
    Posts
    11
    You are right, I just read the sentence on array access and did not read the sentence on vector access.

  5. #5
    Junior Member Newbie
    Join Date
    May 2012
    Location
    Germany
    Posts
    4
    just quickly threw something together that compiles just fine. As the others mentioned the code you show wouldn't compile at all? g_mProjectionInv doesn't exist in the struct either?

  6. #6
    Intern Newbie
    Join Date
    Oct 2007
    Posts
    47
    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:
    Code :
    #define matrix mat4x4
    #ifdef USE_SBO
    /*cbuffer*/layout(binding = 0) buffer cbPerFrame //: register( b1 )
    #else
    uniform cbPerFrame
    #endif
    {
        matrix              g_mProjection           ;//: packoffset( c0 );
        matrix              g_mProjectionInv        ;//: packoffset( c4 );
        float3              g_vCameraPos            ;//: packoffset( c8 );
        float               g_fAlphaTest            ;//: packoffset( c8.w );
        uint                g_uNumLights            ;//: packoffset( c9 );
        uint                g_uWindowWidth          ;//: packoffset( c9.y );
        uint                g_uWindowHeight         ;//: packoffset( c9.z );
        uint                g_uMaxNumLightsPerTile  ;//: packoffset( c9.w );
    };
    anyway tested that offensive line is:
    Code :
     z = 1.f / (z*g_mProjectionInv[2].w + g_mProjectionInv[3].w);
    changing to
    Code :
      z = 1.f / (z*g_mProjectionInv[2][3]+ g_mProjectionInv[3][3]);
    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..

  7. #7
    Intern Newbie
    Join Date
    Oct 2007
    Posts
    47
    Ok I post a minimal repro case:
    Code :
    #version 430 core
     
    #define TILE_RES 16
     
    layout(binding = 0) buffer cbPerFrame 
    {
        mat4x4             g_mProjectionInv;
    };
     
    layout(binding = 3, r32f) uniform imageBuffer g_PerTileLightIndexBufferOut; 
     
    layout (local_size_x = TILE_RES, local_size_y = TILE_RES) in;
    void main(  )
    {
        float z;
        mat4x4 matr=g_mProjectionInv;
        z=1.f / (z*matr[2][1] + matr[3][1]);
        imageStore(g_PerTileLightIndexBufferOut,int(1),vec4(z));
    }

    and compiler error:
    Code :
    Compute info
    ------------
    0(16) : warning C7050: "z" might be used before being initialized
    Internal error: assembly compile error for compute shader at offset 619:
    -- error message --
    line 19, column 29:  error: expected ';'
    line 20, column 29:  error: expected ';'
    -- internal assembly text --
    !!NVcp5.0
    OPTION NV_shader_storage_buffer;
    OPTION NV_shader_atomic_float;
    GROUP_SIZE 16 16;
    # cgc version 3.1.0001, build date Feb 28 2013
    # command line args:
    #vendor NVIDIA Corporation
    #version 3.1.0.1
    #profile gp5cp
    #program main
    #semantic g_PerTileLightIndexBufferOut : IMAGE[3]
    #semantic cbPerFrame : SBO_BUFFER[0]
    #var int g_PerTileLightIndexBufferOut.__remap :  : c[0] : -1 : 1
    #var float4x4 g_mProjectionInv : SBO_BUFFER[0] : sbo_buffer[0][0], 4 : -1 : 1
    PARAM c[1] = { program.local[0] };
    STORAGE sbo_buf0[] = { program.storage[0] };
    TEMP R0, R1;
    IMAGE images[] = { image[0..7] };
    LDB.F32X2 R1.x, sbo_buf0[48].y;
    LDB.F32X2 R0.x, sbo_buf0[32].y;
    MAD.F R0.x, R0.y, R0, R1;
    RCP.F R0.x, R0.x;
    MOV.S R0.y, c[0].x;
    STOREIM.F images[R0.y], R0.x, {1, 0, 0, 0}, BUFFER;
    MOV.F R1, R0;
    MOV.U R0.x, R0;
    END
    # 8 instructions, 2 R-regs

  8. #8
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Internal error: assembly compile error for compute shader at offset 619:
    Generally speaking "internal error"s are bugs from within the compiler itself.

  9. #9
    Junior Member Newbie
    Join Date
    May 2012
    Location
    Germany
    Posts
    4
    compiles fine for me, looks like it has been fixed with newer drivers (though can't say exactly from which version on)

  10. #10
    Intern Newbie
    Join Date
    Oct 2007
    Posts
    47
    Quote Originally Posted by Christoph Kubisch View Post
    compiles fine for me, looks like it has been fixed with newer drivers (though can't say exactly from which version on)
    Seems bug is still present on OGL 4.4 beta drivers!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •