29/02/2012 February 2012 OpenGL drivers status, update 2

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

This month the last release drivers appears to be for GeForce, Forceware 295.73; and for Radeon, Catalyst 12.x preview 8.96.

Catalyst 12.x preview 8.96 looks like a leak but it is available online and performs relatively well as it fixes few bugs. Following some discussions about SNORM texture and texture format conversions in OpenGL, I decided to make the following write up for this status for programmers interested by these greedy OpenGL details.

Texture format to internal format conversions

Here is the following up some discussions resulting of the SNORM textures status from last month.

Typically with OpenGL textures, we are living in a convenient world where whatever texture format data will be converted automatically by the implementation to whatever internal format the user requested or to be precise, to whatever internal format with a precision at least big enough to store the request internal format. This is to say for example a lot of GPUs doesn’t support anymore RGB5A1 format anymore but this format remains part of OpenGL 4.2 specification. An implementation may implement this format with RGBA8 instead for example. This conversion support is so wide that we can even submit RGBA32F data and convert it to DXT1 using glTexImage2D if we wish… I am not saying I can imagine a good reason to do that but it’s possible.

With the release of EXT_texture_integer, it seems that all these conversions were not really making the authors of this extension in a good mood so that this extension prevent any kind of conversion by forcing the application which want to use an integer texture to use one of the following format without any format conversion possible.

In parallel to this extension, EXT_texture_snorm extension was released providing snorm textures (normalized texture between -1.0 and 1.0 instead of 0.0 and 1.0). This extension written against OpenGL 3.0, followed the same precedent than any other OpenGL core textures which means that we could convert any texture format to a snorm texture internal format.

Unfortunately and probably because OpenGL tends to build up more exceptions than the French grammar does, OpenGL core specification (from 3.1 onward) allows conversion of only signed format data (GL_BYTE, GL_SHORT, GL_INTEGER) to snorm textures.

What implementations do? AMD implementation exposes EXT_texture_snorm so we should expect that we could create snorm texture from unsigned integer data. Unfortunately and this is the result of the status, the implementation result isn’t correct. On NVIDIA side, EXT_texture_snorm is not exposed so we should get an OpenGL error when trying to convert unsigned format data to snorm texture. However, this pass and create a functional texture.

04/03/2012 UPDATE

I recieved few feedbacks and I am taking advantage of this quick update to comment them and update the drivers status.

Conversion of SNORM texture data

Some new evidences demonstrate that I was wrong on the snorm texture and the OpenGL specification allows to convert anything to SNORM textures.

Data are taken from the currently bound pixel unpack buffer or client memory as a sequence of signed or unsigned bytes (GL data types byte and ubyte), signed or unsigned short integers (GL data types short and ushort), signed or unsigned integers (GL data types int and uint), or floating point values (GL data types half and float). These elements are grouped into sets of one, two, three, or four values, depending on the format, to form a group. Table 3.3 summarizes the format of groups obtained from memory; it also indicates those formats that yield indices and those that yield floating-point or integer components. OpenGL 4.2 specification, 3.7.2 Transfer of Pixel Rectangles - Unpacking

gl-410-fbo-layered broken on NVIDIA?

I didn't really took time to figure out the bottom of this but it looks like there is a problem: The sample displays a black screen, no OpenGL error generates... but the sample is still working on AMD. I can't exclude that I did something wrong.

Vertex inputs and structures

The GLSL 4.20 clearly specify that vertex input can't be structures but it NVIDIA implementation supports them. Even if the GLSL compiler should generate an error, it sounds like a good idea and it doesn't look like it's an issue for the enumeration API.

"Vertex shader inputs can also form arrays of these types, but not structures." GLSL 4.20.11 specification, section 4.3.4 Input Variables

Implicit conversions

I can't say I really understand GLSL implicit conversions. It would be me they would all generate GLSL error and I think an implementation should as least generate an warning for each like a C++ compiler would do. GLSL defines a clear list for the implicit conversion section "4.1.10 Implicit Conversions". In this list, the allowed conversions are always between type with the same number of components. It seems that in some case AMD implementation allows implicit conversions between vectors of different sizes.

If you have feedback on this, please don't hesitate to drop me a mail.

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.4 branch, still in development, on an GeForce GTX 470 and a Radeon HD 5850.

05/03/2012 UPDATE 2

I think that OpenGL 4.2 is so much better than OpenGL 4.1 because it completely clarifies the interface matching between shader stages. However, I discover a new corner case: With linked programs, if a built-in block is declared on the vertex shader stage but the next shader stage doesn't declare it, this is undefined and either lead to a silent error (NVIDIA implemetation) or a sort of luck (AMD implemetation where it's working).

• OpenGL Samples Pack 4.2.3.1: (ZIP, 13.0 MB) (7Z, 6.2 MB)