driver working : 22.5.1 : windows 10
driver broken : 23.5.2 : windows 10
Not much else to say other than likely a separate issue is while texel fetching data with a standard texture bind for the texture buffer doesn't timeout and shows the expected result if you fail to bind a texture to that explicit layout location and do a texelFetch you wont get a timeout but a instant crash if this is the expected new behaviour a error message would be welcome, the previous driver stack would just display nothing if you failed to bind a texture to that slot. Will update if I've missed anything or do more testing.
# VERT_SHADER
layout (std140, binding = 0) buffer BINDLESS_VERTEX_DATA_BUFFERS {
samplerBuffer texture_buffer_handles[];
};
// layout (binding = 0) uniform samplerBuffer texture_buffer;
void main() {
vec3 position = texelFetch(texture_buffer_handles[0], gl_VertexID).xyz;
// vec3 position = texelFetch(texture_buffer, gl_VertexID).xyz; // works if texBuf bound to layout location
gl_Position = vec4(position.xy, 0.0, 1.0);
}
# FRAG_SHADER
layout (location = 0) out vec4 color;
void main() {
color = vec4(1.0, 0.0, 0.0, 1.0);
}
#init
unsigned int bufferID, textureID;
float mesh_data[] = {0.0, 0.5, 0.0, -0.5, -0.5, 0.0, 0.5, -0.5, 0.0};
glCreateBuffers(1, &bufferID);
glCreateTextures(GL_TEXTURE_BUFFER, 1, &textureID);
glTextureBuffer(textureID, GL_RGB32F, bufferID);
glNamedBufferStorage(bufferID, sizeof(mesh_data), mesh_data, GL_DYNAMIC_STORAGE_BIT);
glMakeTextureHandleResidentARB(glGetTextureHandleARB(textureID));
uint64_t buffer_texture_handles_arr[8];
buffer_texture_handles_arr[0] = glGetTextureHandleARB(textureID)
unsigned int handles_bufferID;
glCreateBuffers(1, &handles_bufferID);
glNamedBufferStorage(handles_bufferID, 8 * sizeof(uint64_t), buffer_texture_handles_arr, GL_DYNAMIC_STORAGE_BIT);
glBindBufferBase(GL_SHADER_STORAGE_BUFFER, 0, handles_bufferID);
int vertID, fragID, pipelineID;
vertID = glCreateShaderProgramv(GL_VERTEX_SHADER, 1, vert_shader_string);
fragID = glCreateShaderProgramv(GL_FRAGMENT_SHADER, 1, frag_shader_string);
glCreateProgramPipelines(1, &pipelineID);
glUseProgramStages(pipelineID, GL_VERTEX_SHADER_BIT, vertID);
glUseProgramStages(pipelineID, GL_FRAGMENT_SHADER_BIT, fragID);
#loop
glViewport(0, 0, 450, 350);
glBindProgramPipeline(pipelineID);
// glBindTextureUnit(0, textureID); // will work if correct location as mentioned above
glDrawArrays(GL_TRIANGLES, 0, 3); // timeout
Solved! Go to Solution.
Ok after some painful investigation into the app I'm tasked with updating I've found the issue. The app was taking the 64bit handle from glGetTextureHandleARB but only storing it to a 32bit uint!.
It was getting away with this on driver 22.5.1 because it seems like its impossible to get that driver and older to actually spit out a larger than 32bit handle from my testing of spawning thousands of handles to check, However the newer drivers first handle you create on my system is always larger than 32bit.
I assume the app did this originally to save memory and of course padded out to 64 on upload to the gpu. This is some heavy abuse of specific driver behaviour that I assume also didn't show its self on other vendors. Anywho not a driver issue sorry for the report.
Couldn't edit the main post anymore. GPU rx5700xt
Thanks for the information. I have reported the issue to the OpenGL team and filed an internal bug ticket for it. Will notify you once there is any update on this.
Thanks.
Hi @RichPressence ,
The OpenGL team was unable to reproduce the issue locally with the latest internal builds.
Could you please try the latest public driver (Adrenalin 23.7.1 ) and share your findings?
Thanks.
Ok after some painful investigation into the app I'm tasked with updating I've found the issue. The app was taking the 64bit handle from glGetTextureHandleARB but only storing it to a 32bit uint!.
It was getting away with this on driver 22.5.1 because it seems like its impossible to get that driver and older to actually spit out a larger than 32bit handle from my testing of spawning thousands of handles to check, However the newer drivers first handle you create on my system is always larger than 32bit.
I assume the app did this originally to save memory and of course padded out to 64 on upload to the gpu. This is some heavy abuse of specific driver behaviour that I assume also didn't show its self on other vendors. Anywho not a driver issue sorry for the report.
Thanks for the confirmation.