OpenGL 3 Updates

[pudman]

There are still a *lot* of people NVIDIA that care about OpenGL

Mind if I ask why? From an IHV perspective, what excites one about OpenGL? Sure, it broadens support across platforms, but really, why OpenGL? For those that *care* about it, wouldn't it be advantageous to *do* something about it?

NVIDIA is one of those places that could toss out another cross platform API and drive a stake in OpenGL's heart. What rationale would they have for *not* doing this, assuming that GL3 is also not code-compatible with pre-3.0 versions.

It could be like a large "GL extension" -- A whole new API that is GL3 in spirit that in the future Kronos could adopt as GL3.

[Korval]

What rationale would they have for *not* doing this, assuming that GL3 is also not code-compatible with pre-3.0 versions.

What good would it do? Apple's not behind it, so nVidia will still have to support their AppleGL implementation. Linux doesn't matter very much to nVidia. And it would be equally as ignored on Windows as OpenGL, if not moreso because of the lack of ATi and Intel support.

The simple fact of the matter is that no API is useful without support. And unless nVidia, ATi, and Intel all decide to support an API, then it is of no value.

As far as GL 3's "code-compatibility", it isn't. At least, it wasn't last year, when we heard anything. GL 3.0 is a new API; there was said to be a backwards compatibility API that would allow you to use certain select GL 3.0 objects in GL 2.x rendering contexts. But that's all.

[pudman]

And unless nVidia, ATi, and Intel all decide to support an API, then it is of no value.

I was drawing on the idea started by CUDA, which is why I suggested that nvidia might be in a position to create an new API. Sure, CUDA is for a different market, but what about Cg? Nvidia seems to like creating these thing that can exploit their hardware, moreso than AMD.

If nvidia left GL support as-is (w/ possible bug patches) and came out with a new API that *nvidia* support, cross-platform, that had all the nifty features of the theoretical 3.0, why *wouldn't* you use it? Because it's not supported by AMD? That so far hasn't stopped people from developing with nvidia's "SM4.0" extensions.

There's a need for a cross-platform well-crafted graphics API. That's one of the reason for this long topic. What if someone (or something) provided it other than OpenGL/Kronos?

As far as GL 3's "code-compatibility", it isn't.

That's what I said I was assuming, just in case the argument arose that this mythical new API wouldn't have a nice legacy installed base like GL does.

Basically I'm just blabbing out loud, and fully expect to be disappointed with whatever happens. It's much more healthy to have really low expectations so you can always be surprised in the end.

[Korval]

Sure, CUDA is for a different market, but what about Cg? Nvidia seems to like creating these thing that can exploit their hardware, moreso than AMD.

nVidia can create whatever it wants, but Cg (despite their attempts to force Cg on GL users) is still not widely used. That's because neither ATi nor Intel support it, and using Cg with either of those two pieces of hardware produces sub-optimal drivers and doesn't expose the hardware features (since they don't extend ARB_vp/fp with new features).

[Timothy Farrar]

Sure, CUDA is for a different market, but what about Cg? Nvidia seems to like creating these thing that can exploit their hardware, moreso than AMD.

nVidia can create whatever it wants, but Cg (despite their attempts to force Cg on GL users) is still not widely used. That's because neither ATi nor Intel support it, and using Cg with either of those two pieces of hardware produces sub-optimal drivers and doesn't expose the hardware features (since they don't extend ARB_vp/fp with new features).

Somehow I doubt Cg isn't widely used. Just look at the PS3, and take into account developers writing cross platform shaders. It is near working with just a re-compile for DX (with a few ifdefs). Not to mention the ability to simply re-target.

[sqrt[-1]]

I think Quake Wars (the last high profile OpenGL game) used Cg for some of it's shaders....

[bertgp]

Right now, implementations have been known to recompile shaders (as a performance "optimization") if you set certain uniforms to certain values.

Really? Which ones particularly? This could explain some performance glitches I encounter sometimes. Is there any documentation/release notes/anything explaining this in more details?

Thanks in advance!

[cass]

Having and retaining a legacy installed base may be the primary reason that OpenGL is still around today. Certainly it is one of the very important reasons. Blaming OpenGL's woes on the burden of legacy support is lazy though. Legacy support isn't why it took unacceptably long to get render-to-texture support. It isn't why the API fast path isn't always obvious. It isn't why implementation quality varies dramatically among vendors.

OpenGL has problems that need solving today, but not problems that absolutely require a from-the-ground-up API rewrite. The nail that is sticking out the highest right now is API overhead relative to consoles. Even within that space, the lowest hanging fruit is concentrated on a small set of API calls (shader binding and parameter setting, texture binding, vertex buffer input configuration, and a handful of misc state like blend mode and depth func). I am going to spend my energy hammering that nail until another nail is sticking out higher. I will be forward looking, but I cannot accept the cost of being paralyzed by trying to make everything perfect in a single incompatible iteration.

If you can't get there in steps, you may not be able to get there at all. And maybe you shouldn't.

Regarding Cg, "force" is a pretty strong word. What we wanted to do was provide a single source language that would work on all platforms and APIs. At id, the same shader source compiles for xbox360, ps3, and PC, - even though the 3 APIs are all different - and the reason it does is because you can write source compatible Cg and HLSL. For ATI and Intel (and maybe even NVIDIA) PC platforms, we will use the Cg GLSL profiles. A single source language eliminates a lot of development headaches. We chose to use Cg rather than invent our own. It's interesting that isolating the API is a lot easier than isolating the shader. It's because the shader is content, which is something a lot of OpenGL implementors still don't get. Just like vertex array data and image data, shaders need to be API agnostic.

[Mars_999]

I am starting to get the idea that, if they say anything about GL3.0 at Siggraph, it will be something along the lines of "We aren't going to redo 3.0 into a new API but fix some of the broken items and clean up the API, but not use this new Object Model"? I guess I don't care about the whole new coding interface if they do this, but I want to see the nvidia extensions they have for GF8 put into the core GL3.0 spec...

[NeARAZ]

nVidia can create whatever it wants, but Cg (despite their attempts to force Cg on GL users) is still not widely used.

Is GLSL widely used? No, because OpenGL is not widely used in the first place; and then if someone does use OpenGL, they stick to fixed function or ARB vertex/fragment programs (which Cg can target just fine).

So whether Cg or GLSL is more widely used - hard to say. Anyone has the data?

We at work use Cg just because we can cross-compile to ARB vertex/fragment programs and Direct3D assembly shaders. We don't compile it to GLSL profiles just because GLSL is too unstable to be used in real life (in our target market) and has a host of other problems (shader loading speed, anyone?)