How to beat driver issues

We need a unified implantation of OpenGL that runs on top of true GL drivers provided by the IHVs, the same way Direct3D works. Khronos or ARB or whatever taking over the common centralized implantation, and the IHVs provide minimal work just to get the implementation accelerated. This way we guarantee excellent driver quality and reliability.

Why reinventing the wheel?

like this ?

although i doubt ati/nvidia will ever ship gallium drivers on linux :frowning:

Another pointless “OpenGL is so great”-thread?

Well no serious feedback. I think OpenGL is dying or at least facing a giant beast that cannot afford to beat. Anyway anything open dies. [censored] it, stick to Direct3D.

Their driver model integration concept with OpenGL must have failed after SIGGRAPH '08. Still on their website: “The OpenGL 3.0 API will be very different from OpenGL 1.x/2.x.”

it didn’t
they were expecting the existing old dri model to fail when a major opengl cleanup was going to be announced (which didn’t happen sigh)

the MacOS OpenGL driver model is conceptually similar

OK, I’ll bite…

Well, in the games arena OpenGL desktop has been marginalized in part because the market itself has gone to consoles. Carmack himself has stated as much, though apparently Id plans continued PC releases - if for no other reason than it’s the right thing to do. If DX has an edge here it’s partly due to it being the API of the Xbox, which effectively doubles the logic of its use on the Windows platform. Unfortunately, OpenGL|ES can stake no such claim on the PS3, even though ES is apparently used for RAD. (Btw, why wasn’t ES designated at the outset as the de facto API for the PS3?)

Bottom line, it doesn’t really matter. A properly abstracted graphics interface is relatively easy to implement with either API. Would be nice, however, if we could somehow make the PC more like the console in terms of feature levels and implementation predictability and stability. With that in mind, the nicest thing to me about DX9.c+ is that I can pull out an NV card and plug in an Ati card and everything just works - no modifications necessary. Wish I could say the same for OpenGL, but understandably there are market forces at work here beyond developer control.

Forget about it. Not going to happen.
What would be better if there was some tools. What about a tool that optimizes meshes? Something that checks if your shader is OK?

AMD Tootle? AMD GPU ShaderAnalyzer?

I believe in OpenGL being superior API regardless of its current status in game technology. My anticipation is however ironic, and many will find it too far from happening. XNA is taking over the play and dont be surprised if it completely replaces native DirectX, even on XBox.

Talking about consoles, I believe adopting a PC-based API is an immature idea even if it works. A console should provide its own API, or go straight to the metal. Having an OS underneath that’s able to run XNA and .NET makes it more a PC. Anyway…

Looking froward to seeing OpenGL 3.5 specification.

Because GL and GL ES does NOT give low enough access to the hardware on the PS3.

And what’s the defacto standard on PS3?

Writing you own command buffers.

The “XNA Framework” (XNA is a brand that includes native DirectX) is a managed wrapper around the native DirectX versions for the PC and the XBox 360. Therefore you don’t have the same level of access that the native APIs offers. Beside of this there are still too many drawbacks of using a managed environment for retail titles. It may be good enough for Live Arcade but not more at it’s current state.

The XBox Version of Direct3D is similar but not identical to the PC version.

I mean in the end these are technologies subject to change and replacement. But when an API changes every month trying to approach another API, no matter how reliable it’s, it’s just screwed up as an API.

Again and for the 1 million times I repeat, we need a strong reliable OpenGL 3.0 implementation with alot of extensions please.

Don’t deprecate any feature, let it be robust and intimidating.

Can t the deprecated features be implemented in an external library? For example, you could put some new functions in GLU such as gluBegin, gluVertex3f, gluTexCoord2f.
There is some D3D lib that does exactly that and it had functions like D3DXBegin, D3DXVertex3f, D3DXTexCoord2f, so it is a good idea for some people.

This could be a solution. For Vista/Direct3D Microsoft goes even an additional step by translating any API version older than 9 to driver calls for the 9 version. Additional there is an automatic translation from fixed function to shaders for any shader model 3 card. This makes driver implementation easier.

But the problem with this approach is that you need someone who fell responsible to write and maintain these solutions. So far I don’t have the feeling that Khronos have the necessary resources for such a step.

I don’t think khronos would do it either so perhaps it should be done by some 3rd party just like GLEW, GLEE, DevIL.
It would be a huge job but in the end, this suggestion would become a reality : a single implementation for all of them on top of a simple “real driver”
Eventually, the IHVs would agree that GLU has taken over and they will really remove the fluff.

and there is the bonus that it can be open source and in fact, GLU is already open.

I don’t think that GLU is taking over. GLU is old and mostly deprecated, including the way it is implemented. I don’t used it anymore and I pretty sure that less and less project is using it.

If a new extenal library is created by a third party, it adoption time will be very long and I’m afraid even if nVidia come up with it. Even nVidia doesn’t have the strengh of SGI when they released GLU.

It’s needed to but certifed by the Khronos Group to be trustly used by everyone that need it.

GLEW and GLEE are good examples. There are both mature but still 2 projects for the same purpose but something like 5 years old… Do we want to wait 5 years to get a simplied OpenGL specification?

Just deprecated every old thing in OpenGL 3.1 and state as a guide line to use OpenGL 1.x for fixed pipeline based software. OpenGL 2.x for mixed programmable and fixed pipeline softwares and OpenGL 3.x for pure programmable software. That’s a good deal for everyone. If the Khronos group wants to come up with “profiles” that match to these needs with OpenGL 3 that’s good too to me.

Each need just diserved to be satisfied until everyone reach the pure programmble stage which will basically not going to happened within the 5 next years.