Thanks for the bug report. The issue with “sharedBuf[1 + gl_LocalInvocationID.x]” under Linux will be fixed in the next OpenGL 4.3 beta driver, which is scheduled for the end of next week.
The issue reported by JakobProgsch with “local[localindex+128] = localindex+128;” should also be fixed then.
Hi,
Is there a lack of support for glDebugMessageCallback running on linux beta driver?
Thank you.
Is there a lack of support for glDebugMessageCallback running on linux beta driver?
I’ve been using it successfully on Ubuntu 11.04 64b (driver 304.15.00.02). Have you declared you callback function with APIENTRY? Here’s the declaration I use:
static void APIENTRY
showDebugOutput(GLenum source, GLenum type, GLuint id, GLenum severity,
GLsizei length, const RE_GLchar *message, GLvoid *userParam)
Hi malexander. I am using the following code. My issue is that glDebugMessageCallback is null at runtime using freeglut and GLEW (both are latest version).
I also posted more code in a different thread: glDebugMessageCallback on nVidia using Ubuntu - OpenGL - Khronos Forums
My system is ubuntu 12.04 x64 with nVidia 304.15 beta drivers.
static void debugLog(GLenum source, GLenum type, GLuint id,
GLenum severity, GLsizei /*length*/, const GLchar *message,
void * /*userParam*/) {
std::cerr << " --
" << "Type: " << getStringForType(type).c_str() <<
"; Source: " << getStringForSource(source).c_str() << "; ID: " << id <<
"; Severity: " << getStringForSeverity(severity).c_str() << "
" <<
message << std::endl;
}
Perhaps freeglut/GLEW is the issue then. I’m using direct glX calls to get the function pointer to glDebugMessageCallback (glXGetProcAddressARB).
I filed a bug on glew, so hopefully an answer will come soon.
After moving to the new nvidia beta drivers AND defining GL_GLEXT_PROTOTYPES, glDebugMessageCallback works. The previous driver reported missing glDebugMessageCallback/ARB as missing when I ran glewinfo.
Texture sampling in Compute Shader always return vec4(0).
I use sampler2D in the shader and create texture like this:
glGenTextures(1, &m_texture);
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, m_texture);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, kWidth, kHeight, 0, GL_RGBA, GL_FLOAT, &texture_data[0]);
Just for the sake of completeness, what texture functions are you using in your shader?
I have tried various functions: texelFetch, texture, textureProj, textureProjOffset, textureLodOffset, texelFetchOffset.
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.
#version 430 core
buffer Output {
vec4 g_output[];
};
void main() {
g_output[128] = vec4(1, 2, 3, 4);
}
This compute shader fails to compile with “invalid operands to !=” error. This is clearly a driver bug.
#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;
}
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?
Sorry, shader must be more complicated, like this:
#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.
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.
The issue you found with “g_uniform != gl_MaxComputeWorkGroupCount” is another bug. We’ll fix this shortly.
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)?
[QUOTE=randall;1243550]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)?[/QUOTE]
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
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.
I think I have found a bug.
I have this shader 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.