Originally posted by Korval:
The problem with nVidia’s implementation arose because GL_CLAMP_TO_EDGE didn’t exist in GL for quite some time (GL 1.2 introduced it). This, coupled with the fact that nobody wants GL_CLAMP behavior (it is rarely useful, especially compared to GL_CLAMP_TO_EDGE), and what do you get? Well, you get a lot of GL developers complaining to nVidia that they’re getting black lines at the edges of their textures, and that it is a hardware problem. Since GL provided no GL_CLAMP_TO_EDGE at the time, they had no real choice but to make GL_CLAMP behave like GL_CLAMP_TO_EDGE.
I’m sorry, but that’s just simply not correct.
First, both SGIS_texture_edge_clamp and EXT_texture_edge_clamp predate TNT. Other implementors (even in the consumer market) supported these extensions back then.
Second, even after OpenGL 1.2, TNT through GeForce2 silently “fell back” to GL_CLAMP_TO_EDGE when asked to GL_CLAMP. No developer could complain to NVIDIA about black lines in their textures, because TNT through GeForce2 wouldn’t give them black (or more commonly tinted grey) lines with GL_CLAMP.
Third, early GeForce 3 drivers finally had conformant GL_CLAMP behavior. So for the first time NVIDIA faced the same complaints from developers that most other implementors had heard for years - your “GL_CLAMP” is broken because I’m seeing texture borders in my cubemaps/skyboxes/edges of textures. I don’t blame developers, they developed and tested on non-conformant hardware, and often filed bug reports against conformant hardware.
“Compatibility” won over conformance, so later drivers added the still misunderstood conformance checkbox.
Finally, GL did provide (through widely implemented extensions) GL_CLAMP_TO_EDGE_SGIS and GL_CLAMP_TO_EDGE_EXT, so there really was a correct choice to make.
(Oh, in fairness, Nvidia wasn’t the first implementor to get this stuff wrong.)
Anyhow, water under the bridge.
-mr. bill