Quote:Original post by Myopic Rhino

Quote:Original post by DumpAlien

Quote:Original post by phantom

- failed to make the fast path easy to find
- failed to make the driver developers lives easier
- failed to change the API to better reflect the hardware

Sorry for asking again... but how u come to a conclusion that openGL failed on these three above? I am a little confuzed..

Thanks again!

Having worked very closely with OpenGL drivers at AMD/ATI and Qualcomm, I'll take this one.

1) Because of its long evolution, OpenGL provides many different ways to do the same thing. Typically, one of those ways is very good for performance, and the other ways are bad. In order to access the fast path as things now stand, you have to be familiar with the underlying hardware and usually write multiple paths to fully take advantage of all the hardware out there.

2) Supporting 15+ years of legacy functionality by itself significantly complicates the driver. The expectation that the driver should not just support it, but make it fast, further complicates the drivers.

3) Hardware has changed drastically since OpenGL was first introduced. Because of this, OpenGL is no longer "close to the metal" - which is what you'd expect from a low-level, high performance graphics API. This gets back to the first two points: because the API doesn't really reflect how the hardware actually works, a significant amount of optimization needs to to be done both in the driver and in applications.

As originally described, 3.0 would have fixed these things. Unfortunately, just like 2.0, it seems that 3.0 fell far short of what was initially envisioned.

Quote:Original post by speciesUnknown

Quote:Original post by Myopic Rhino

Quote:Original post by DumpAlien

Quote:Original post by phantom

- failed to make the fast path easy to find
- failed to make the driver developers lives easier
- failed to change the API to better reflect the hardware

Sorry for asking again... but how u come to a conclusion that openGL failed on these three above? I am a little confuzed..

Thanks again!

Having worked very closely with OpenGL drivers at AMD/ATI and Qualcomm, I'll take this one.

1) Because of its long evolution, OpenGL provides many different ways to do the same thing. Typically, one of those ways is very good for performance, and the other ways are bad. In order to access the fast path as things now stand, you have to be familiar with the underlying hardware and usually write multiple paths to fully take advantage of all the hardware out there.

2) Supporting 15+ years of legacy functionality by itself significantly complicates the driver. The expectation that the driver should not just support it, but make it fast, further complicates the drivers.

3) Hardware has changed drastically since OpenGL was first introduced. Because of this, OpenGL is no longer "close to the metal" - which is what you'd expect from a low-level, high performance graphics API. This gets back to the first two points: because the API doesn't really reflect how the hardware actually works, a significant amount of optimization needs to to be done both in the driver and in applications.

As originally described, 3.0 would have fixed these things. Unfortunately, just like 2.0, it seems that 3.0 fell far short of what was initially envisioned.

Its nice to know why, but what concerns me is what do we do next? The only alternatives to windows PC's for gaming, without a more up to date OpenGL, is Cider on apple machines, or consoles. For indie game developers, this means XNA, therefore the Xbox. Either way, MS now get a further increased share of the video game market, to the point where the effect of free market competition is non existant.

I fear that no competator to D3D means poorer quality from MS in the future. OpenGl thrived when it was a viable alternative to DX, but now it seems this is no longer the case. What other alternatives are there?

Quote:Original post by phantom

Quote:Original post by speciesUnknown
I fear that no competator to D3D means poorer quality from MS in the future. OpenGl thrived when it was a viable alternative to DX, but now it seems this is no longer the case. What other alternatives are there?

To be fair, OpenGL hasn't really been a viable alternative to D3D in the commerical game space for some years now. Also, MS have already been throwing more resources at XB360 as the recent GameFest showed in the presentation bias towards the 360.

For hobby developers, well, you've still got OpenGL, just not the new shiney API that was planned for.

Quote:Original post by speciesUnknown
I fear that no competator to D3D means poorer quality from MS in the future. OpenGl thrived when it was a viable alternative to DX, but now it seems this is no longer the case. What other alternatives are there?

Quote:Original post by Myopic Rhino
Having worked very closely with OpenGL drivers at AMD/ATI and Qualcomm, I'll take this one.

1) Because of its long evolution, OpenGL provides many different ways to do the same thing. Typically, one of those ways is very good for performance, and the other ways are bad. In order to access the fast path as things now stand, you have to be familiar with the underlying hardware and usually write multiple paths to fully take advantage of all the hardware out there.

2) Supporting 15+ years of legacy functionality by itself significantly complicates the driver. The expectation that the driver should not just support it, but make it fast, further complicates the drivers.

3) Hardware has changed drastically since OpenGL was first introduced. Because of this, OpenGL is no longer "close to the metal" - which is what you'd expect from a low-level, high performance graphics API. This gets back to the first two points: because the API doesn't really reflect how the hardware actually works, a significant amount of optimization needs to to be done both in the driver and in applications.