i have to quote myself here. i am back at our ATI machine using catalyst 10.11 drivers. the problem described above is still there. how in the hell can something like this be still there? glClearBufferfi is a fundamental OpenGL call. the most frustrating thing is, if i use another fbo directly before the clear operation of the fbo in question it works. i also set the stencil and depth mask before calling the glClearBufferfi function. it makes no sense that glClear works when glClearBufferfi does not under exact the same conditions!
ATI is unusable when it comes to OpenGL development. Another problem i have to deal with here is some uniform where i get the following warning. When i set this uniform to 0 it works, when i set it to 1 glUniform1i crashes… yes crashes, no error no warning, a crash!
I am extremely frustrated! On some occasions going to ATI forces me to write OpenGL code more in line with the spec. BUT on a lot more occasions ATI just does not work…
I just noticed your report on ClearBuffer; I looked at the implementation, and it seems that DEPTH_STENCIL is indeed not handled; you should have got an invalid enum error though. As well, if you used GL_DEPTH, it seems that it should have worked too.
we will fix it asap.
if you find other issues, do not hesitate to contact us directly, since we might not catch your post here.
glClearBufferfi is a fundamental OpenGL call. the most frustrating thing is, if i use another fbo directly before the clear operation of the fbo in question it works. i also set the stencil and depth mask before calling the glClearBufferfi function. it makes no sense that glClear works when glClearBufferfi does not under exact the same conditions!
Sure it does. glClearBufferfi is not a “fundamental OpenGL call.” It is a relatively new entrypoint, added in the ARB_framebuffer_object/OpenGL 3.0 specifications. How many live OpenGL applications do you suppose actually use glClearBufferfi, especially when the existing glClear calls work just fine for 90+% of cases? And if no applications use an entrypoint, what’s the chance of an IHV detecting a driver bug with it?
What we have here is the reason why conformance tests were invented. To force makers of an implementation to implement the entire specification, and to detect exactly when and where an implementation is deficient.
So long as OpenGL lacks a rigorous conformance test, these problems will persist.
yes, glClear works just fine, but the more DSA approach of the glClearBufferX functions is very appealing. ARB_framebuffer_object/OpenGL 3.0 are out for over two years, it is a shame that no one at ATi detected it until now. it also shows how valued by developers ATi is when it comes to OpenGL development.
What we have here is the reason why conformance tests were invented. To force makers of an implementation to implement the entire specification, and to detect exactly when and where an implementation is deficient.
So long as OpenGL lacks a rigorous conformance test, these problems will persist.
if khronos did not listen until now i think they will never listen to implement a new conformance test suite. sadly.
it also shows how valued by developers ATi is when it comes to OpenGL development.
More likely it shows how often this function is used in actual shipping code. That being, not particularly often.
if khronos did not listen until now i think they will never listen to implement a new conformance test suite.
They say they’re working on it. They know the need for it; it’s simply a matter of resources. Khronos, and the ARB before it, is a volunteer organization. That doesn’t lend them to being able to employ a couple of skilled OpenGL developers for a year to build a proper conformance suite for GL.