30/01/2012 January 2012 OpenGL drivers status

RSS Feed ~ Comment: by email - on Twitter ~ Share: Twitter - Facebook - Linked In - Google+ - Permanent link

For this month OpenGL drivers status, the drivers haven't really evolved as surprizingly NVIDIA didn't release any drivers and AMD drivers doesn't fix anything I noticed compare to last month. However, the just released OpenGL Samples Pack 4.2.3 brings a set of changes that give us some new information.

Rendering without fragment shader output variables

First of all, I fixed the results of 420-image-store on NVIDIA as I found some languages that demonstrates that the results of the framebuffer is undefined as NVIDIA implementation leads to.

"If a fragment shader writes to none of gl_FragColor, gl_FragData, nor any user-defined output variables, the values of the fragment colors following shader execution are undefined, and may differ for each fragment color." GLSL 4.20.8 specification, section 4.2.1 Selecting Buffers for Writing

I pretty much think that this language could be changed to get a more sensible result for rendering without fragment shader output variable but in the meantime we will have to use glColorMaski(AttachementIndex, GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);.

Using and updating a buffer simultaneously

For four or five years, I have in mind "it's all about memory bandwidth" and this remains true to me even if the problem has slightly evolved. These days some interesting solutions are coming with programmable vertex pulling, partially resident resources or voxel representations which all converge toward the need for alternative representations of the asserts and a finer control of our accesses and updates the data. OpenGL buffer usage flags days are numbered. There is still a long way to go but I added a trivial embodiment of this direction with 420-buffer-barrier-gtc which updates a buffer and use it at the same time but ensures a fine granularity synchronization with glMemoryBarrier. According to the OpenGL specification, this idea should generates an invalide operation error but it appears to work fine on AMD implementation. We would probably need a better API to reach something really interesting but it's an interesting start to me.

"Most, but not all GL commands will detect attempts to read data from a mapped buffer object. When such an attempt is detected, an INVALID_OPERATION error will be generated. Any command which does not detect these attempts, and performs such an invalid read, has undefined results and may result in GL interruption or termination." GLSL 4.20.8 specification, Effects of Mapping Buffers on Other GL Commands

Imagine an OpenGL world with Direct State Access, extensive debugging functionnalities and finer memory control... Pretty nice and ineluctable future!

Once again, don't forget to contribute to the OpenGL community by reporting your bugs!

The test

These tests have been done on Windows 7 64 with the OpenGL Samples Pack 4.2.3.1 on an GeForce GTX 470 and a Radeon HD 5850.

• OpenGL Samples Pack 4.2.3.0: (ZIP, 12.7 MB) (7Z, 6.1 MB)