With the unexpected interest for the OpenGL drivers status, I thought it could be a good idea to make it a monthly thing to reach some visibility over OpenGL drivers development.
There are multiple issues to make this visibility relevant: First, this status is based on an always too limited number of samples but also my knowledge of specification details and drivers implementations. Usually, with my samples if it's reasonable to update them to make them work on either AMD or nVidia drivers, I don't hesitate to make these changes so that a maximum of samples actually work. If I reach a point of dilemma between AMD and nVidia, I always choose a solution as close as the specification says because in the end the specification is nothing else than the bible for OpenGL programmers.
| Drivers: | AMD Catalyst 10.10c (26/10/2010) | AMD Catalyst 10.12 ccc (13/12/2010) | nVidia Forceware 260.93 (17/10/2010) | nVidia Forceware 265.90 (01/12/2010) |
|---|---|---|---|---|
| 410-debug-output-arb | AMD_debug_output support only | AMD_debug_output support only | ||
| 410-program-varying | gl_PerVertex redeclaration involves compiler errors... | gl_PerVertex redeclaration involves compiler errors... | ||
| 410-program-separate | gl_PerVertex redeclaration involves compiler errors... | gl_PerVertex redeclaration involves compiler errors... | ||
| 410-program-binary | Will crash after enough load and save instead of returning GL_FALSE. | Will crash after enough load and save instead of returning GL_FALSE. | ||
| 410-program-64 | glVertexAttribLPointer is null but glVertexAttribLPointerARB available | |||
| 410-primitive-tessellation-5 | gl_PerVertex redeclaration involves compiler errors... | gl_PerVertex redeclaration involves compiler errors... | ||
| 410-primitive-tessellation-2 | gl_PerVertex redeclaration involves compiler errors... | gl_PerVertex redeclaration involves compiler errors... | ||
| 410-primitive-instanced | Using explicit location silently ignore throw a parsing error. | Unexpected warning | Unexpected warning | |
| 410-fbo-layered | Unexpected warning | Unexpected warning | ||
| 400-transform-feedback-object | ||||
| 400-texture-compression-arb | ||||
| 400-texture-buffer-rgb | ||||
| 400-sampler-gather | ||||
| 400-sampler-fetch | ||||
| 400-sampler-array | ||||
| 400-program-varying-structs | Doesn't support varying struct and offensive error message | |||
| 400-program-varying-blocks | Unexpected warning / gl_in.length() not fully supported | Unexpected warning / gl_in.length() not fully supported | ||
| 400-program-subroutine | ||||
| 400-program-64 | ||||
| 400-primitive-tessellation | Unexpected warning | Unexpected warning | ||
| 400-primitive-smooth-shading | Unexpected warning | Unexpected warning | ||
| 400-primitive-instanced | Unexpected warning | Unexpected warning | ||
| 400-fbo-rtt-texture-array | ||||
| 400-fbo-rtt | ||||
| 400-fbo-multisample | ||||
| 400-fbo-layered | ||||
| 400-draw-indirect | ||||
| 400-buffer-uniform | Unsupported uniform block array | Unsupported uniform block array | ||
| 400-blend-rtt | ||||
| 330-texture-array | Required glTexParameteri to setup filtering, sampler unsupported | Required glTexParameteri to setup filtering, sampler unsupported | ||
| 330-sampler-object | Sampler object doesn't always oversede texture parameters | Sampler object doesn't always oversede texture parameters |
Following some samples that illustrates some OpenGL 4.2+ feature requests I made and taking the "gtc" post-fix. I wrote these samples as I think they show either specification bugs, design mistakes, lack of arrucacy or perspectives.
| Drivers: | AMD Catalyst 10.10c (26/10/2010) | AMD Catalyst 10.12 ccc (13/12/2010) | nVidia Forceware 260.93 (17/10/2010) | nVidia Forceware 265.90 (01/12/2010) |
|---|---|---|---|---|
| 410-program-varying-gtc | Not supported as OpenGL specify... | Not supported as OpenGL specify... | A GLSL compiler warning would be nice | A GLSL compiler warning would be nice |
| 410-program-separate-dsa-gtc | A debug output warning would be nice | A debug output warning would be nice | A debug output warning would be nice | A debug output warning would be nice |
| 400-sampler-array-gtc | Not supported as OpenGL specify... | Not supported as OpenGL specify... | A GLSL compiler warning would be nice | A GLSL compiler warning would be nice |
| 400-buffer-uniform-shared-gtc | Not supported as OpenGL specify... | Not supported as OpenGL specify... | A GLSL compiler warning would be nice | A GLSL compiler warning would be nice |
On the nVidia side the only change I notice is on the regard of the support of varying structures. I have been told my some developers that the support is still not perfect but my OpenGL sample is working correctly. The drivers are still fully of "'variable' might be used before being initialized" but I have no idea how to fix this or the nature of the problem.
On the AMD side it's very surprising that the sampler objects problems still remains. The sampler object implementation seems to have been rushed at the beginning but not AMD seems to struggle to fix it. Not shown in the OpenGL Samples Pack 4.1.3.3, the AMD drivers also have multiple issues on the regard of glClear* functions. On the OpenGL 4 side, some trivial issues have been fixed but the support of uniform arrays is still lacking.
At that date, I would say that nVidia drivers are OpenGL 4.0 'production ready' while AMD implementation is barely OpenGL 3.2 'production ready'. It's quite unfortunate to see on one hand AMD much more involve toward specification conformance but in other hand still suffering of a bad OpenGL implementation legacy. At nVidia's, the attitude is more pragmatic and I don't think that we can really rely on nVidia implementation as an OpenGL reference implementation but the team is so fast to fix the reported issues that nVidia approach remains incredibly effective.