Also AFAIK you can't actually use the current DX9 SDK to produce PS3.0 applications
Using DX's HLSL. You can do anything supported through the API if you aren't relying on their HLSL(for comparison you could argue that OGL has
no shader support outside of Cg).
So as long as you don't use HLSL you can use the current DX runtime with PS2.0? Why can't you compile HLSL as ps3.0 instead of just 2.0, 1.4, 1.3, 1.2, and 1.1?
I still don't have any OpenGL 1.5 drivers for my R9800Pro- and as you pointed out that was ratified eighteen months ago. OpenGL adoption is excruciatingly slow to put it nicely.
But what features are you missing? I just took a quick look at what new features are in 1.5:
-GLSL shader extension
-VBO as core
-occulsion query (can you even do this in D3D9?)
-shadow function (generalized)
-sdk (not driver) token changes
The 9800 has the GLSL extension, VBOs, occulsion query, and basic shadow functions. The only thing ATI is missing (maybe not) is generalized depth shadow functions, which is a very minor feature. Other than the GLSL extension ATI has supported those features for a long time.
But this is changing the subject from if OpenGL supports something to if a vendor supports OpenGL. They may be saving changing the OpenGL version to 1.5 for internal reasons like matching the release of their next generation hardware. <speculation>It doesn't matter that they don't call their driver 1.5 because they support all the features of 1.5 then developers are happy because they can use 1.5 now on ATI hardware which is really all that matters, and marketting is happy because they can release a new special driver with their next hardware which adds OpenGL 1.5 support. Most people who don't look what is actually new will get all excited that ATI has added OpenGL 1.5 to their new drivers for their new hardware and talk about it like it is a great new feature, when in reality they basically already supported it for months on their old hardware
🙂</speculation>
Very different case with OpenGL. You don't write code for vendor proprietary extensions under D3D which you do deal with on the OpenGL side of things. I'm not talking about general cases which is what you are using for D3D- take DooM3 as an example. It has it's 'low quality' fallback mode(which the R1x0 parts will use), then it has the NV1x path, the NV2x path, NV3x path, R2x0 path and 'ARB2' path. There are a few different boards that have feature parity(in terms of the D3 engine and how it will utilize the hardware) that are still using seperate code paths due to vendor implementations and lack of concrete extensions when these new features came about.
That is true. The one nice thing about D3D is when you write the r2x0 specific code path in D3D is it is called "Pixel Shader 1.4" not "ATI_fragment_shader". In reality it is a R2x0 specific code path because only the r2x0 would use it, all the rest would use the ARB2/ps2.0 path. Of course any company is just as free to implement the ATI_fragment_shader extension in OpenGL as they are to support PS1.4 in D3D. For example Matrox uses the ATI VAO extension and 3Dlabs implements the nvidia register combine extension. But you're completely right, naming it PS1.4 will make it more likely for another vendor to support it than to name it ATI_fragment_shader. That is an advantage for D3D, even if in reality it isn't any different because PS1.4 is just the same as writing a R2x0 specific code path in OpenGL.
DX8 level hardware was a bit of a mess, only three vendors ever supported just it (and Matrox isn't that relevent), and they had hugely different functionality. OpenGL does not have a standard way to use PS1.1/PS1.4, so you do need to use extensions for the nv2x or r2x0. But a shader for the nv2x and another for the r2x0 isn't too different than a PS1.1 and a PS1.4 shader. The only company that offers a product that with that functionality that would normally piggy back on the nv2x path is Matrox with PS1.3 support in D3D, but their own fragment shader extension in D3D. However there is full standard support for all cards with VS1.1 functionality. In reality just those Matrox gamers get shafted under OpenGL. Unless Matrox does what 3Dlabs did-they support both the nvidia register combiner extension and the ARB fragment shader.
The ARB had the forsight to forget about wasting time on finding a lowest common denominator standard for only a couple venders that had their own extensions to use that functionality and instead jumped straight to fragment programs/PS2.0 which will be supported by all vendors like S3, and SiS. Hell, nvidia didn't even make a low end DX8 part, they jumped right in with DX9 across the board.
In Doom3 the one thing about the nv1x path is under D3D it is impossible to write the equivilent! Nvidia's hardware goes beyond the DX7 standard, so you can either treat the nv1x like standard DX7 hardware in OpenGL, or you can use nvidia's extensions to use all power of that card. The nv1x will run D3 much better than the R1x0 because of this. It's hard to call this a strike against OpenGL since it is providing something D3D doesn't. Same with the nv3x path, the nv3x is fine running the standard arb2 fragment program path, there is just a nv3x path for increased performance.
