Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 4 of 4

Thread: per patch varyings : arrays vs vectors

  1. #1
    Intern Contributor
    Join Date
    Apr 2010
    Posts
    68

    per patch varyings : arrays vs vectors

    When setting a specific component of an array using gl_InvocationID, I get undefined results from patch varyings set in my tessellation control shaders with vectors while arrays work fine. I don't see why vectors should give an undefined result.
    Here's some code illustrating the problem (using triangular patches):
    Code :
    // tessellation control shader
    #version 410
    layout(location = 0) patch out vec3  oData1; 
    layout(location = 1) patch out float oData2[3];
     
    [...]
     
    void main()
    {
    	oData1[gl_InvocationID] = someScalarValue(gl_InvocationID); // undefined in my tessellation evaluation shader 
    	oData2[gl_InvocationID] = someScalarValue(gl_InvocationID); // works fine in my tessellation evaluation shader
    }
    Either I missed something in the specs, either it's a driver bug, I'm on Catalyst 11.9.

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,732

    Re: per patch varyings : arrays vs vectors

    `oData1` is not an array. So how are you accessing it as an array?

  3. #3
    Intern Contributor
    Join Date
    Apr 2010
    Posts
    68

    Re: per patch varyings : arrays vs vectors

    It's perfectly valid to access the components of a vector using the bracket operator (see, for example, page 80 of glsl420 specs: section 5.5).

  4. #4
    Junior Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    249

    Re: per patch varyings : arrays vs vectors

    Tessellation shader invocations were designed to be run in parallel. AMD hardware is vector-based, so I'd guess that what is actually happening in each invocation is:

    Code :
    load vec3 data
    insert scalar->vec3
    store vec3 data
    Because of the fact that the entire vector is being stored, parallel invocations are stomping on the same data location, producing unpredictable results. The float[3] array is very likely being stored in separate 128b-padded addresses, so no data-stomping occurs.

    This is in theory, anyway -- I don't exactly know what's going on behind the scenes.

Posting Permissions

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