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 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 63

Thread: NVIDIA releases OpenGL 4.3 beta drivers

  1. #51
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    This compute shader fails to compile with "array access is out of bounds" error. I think that this is a driver bug. Unsized array being last block member should be dynamically sized.

    Code :
    #version 430 core
    buffer Output {
       vec4 g_output[];
    };
    void main() {
      g_output[128] = vec4(1, 2, 3, 4);
    }

  2. #52
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    This compute shader fails to compile with "invalid operands to !=" error. This is clearly a driver bug.

    Code :
    #version 430 core
    layout(local_size_x = 1) in;
    buffer Output { int g_output; };
    uniform ivec3 g_uniform;
    void main() {
      if (g_uniform != gl_MaxComputeWorkGroupCount) g_output = 0;
      else g_output = 1;
    }

  3. #53
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    I wasn't able to reproduce the "array access is out of bounds" error. I did need to add something like "layout(local_size_x=16, local_size_y=16) in;" to avoid a different error. What driver are you using?

  4. #54
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    Sorry, shader must be more complicated, like this:

    Code :
    #version 430 core
    layout(local_size_x = 128) in;
    buffer Output {
      vec4 g_output[];
    };
    void main() {
      if (gl_LocalInvocationID.x == 0) {
        g_output[128] = vec4(1);
      } else {
        const uint index = gl_LocalInvocationIndex;
        g_output[index + 128] = vec4(1);
      }
    }

    I am using 306.63.

  5. #55
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    Thanks, I was able to reproduce the problem with your new sample. This is a bug in our driver. Before ARB_shader_storage_buffer_objects, which allows the last element of a buffer to be an unsized array, it was possible to use unsized arrays but it was necessary to index that unsized array somewhere in the shader in such a way that the compiler could determine the size from its use. In your example the g_output[128] is causing us to think it's the old style of unsized array and we're sizing it to 128. Then the other g_output[128 + index] is thinking it's not sized right.

    You can work around this bug by avoiding indexing into the buffer unsized array with a constant. For example, change g_output[128] to g_output[g_LocalInvocationID.x + 128] instead.

  6. #56
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    The issue you found with "g_uniform != gl_MaxComputeWorkGroupCount" is another bug. We'll fix this shortly.

  7. #57
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    Thanks. One more thing. GLSL spec revision 7:

    The control flow barrier built-in function barrier() is allowed inside uniform flow control for
    compute shaders.

    Currenty (in 306.63) this is an error. Will this be fixed (for GLSL and assembly shaders)?
    Last edited by randall; 10-18-2012 at 06:26 AM.

  8. #58
    Junior Member Regular Contributor
    Join Date
    Sep 2001
    Location
    Wake Forest, NC, USA
    Posts
    171
    Quote Originally Posted by randall View Post
    Thanks. One more thing. GLSL spec revision 7:

    The control flow barrier built-in function barrier() is allowed inside uniform flow control for
    compute shaders.

    Currenty (in 306.63) this is an error. Will this be fixed (for GLSL and assembly shaders)?
    Yes. As I mentioned earlier in the thread (August 27), I had filed a Khronos bug on this issue after realizing that this behavior would be problematic. We decided to simply remove the restriction from the GLSL 4.30 specification, rather than postponing to a future version of GLSL or leaving as an extension. As you observe, this happened in revision 7. NVIDIA hasn't yet published a driver removing the error, but we will definitely do so.

    Thanks,
    Pat

  9. #59
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Oh, there's another spec bug in regards to this. The expressions leading to the execution of a barrier() must be "dynamically uniform". However, the section titled "dynamically uniform expressions" states that the concept only applies to fragment shaders.

  10. #60
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    I think I have found a bug.

    I have this shader code:

    Code :
    // ...
     
    struct Struct0 {
      ivec2 m0;
    };
    layout(std430) buffer Input {
      int data0;        // offset 0
      Struct0 data1; // I think that offset should be 16 according to the rule: the base alignment of the structure is N, where
                           // N is the largest base alignment value of any of its members, and rounded
                           // up to the base alignment of a vec4. When using 310.33 driver offset is 8 (so, structure base alignment is not rounded up to the base alignment of a vec4).
    } g_input;
     
    // ...

    Can you confirm? Or, am I missing something?

    Thanks.
    Last edited by randall; 10-26-2012 at 08:07 AM.

Tags for this Thread

Posting Permissions

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