The ARB announced OpenGL 3.0 and GLSL 1.30 today

OpenGL
181

Exactly, now that those 2.1 + extensions have been ratified as core, we can finally see driver support from other vendors. This alone is very important.

No, it is not.

Intel won’t be supporting jack. They’ve never had good OpenGL support, and GL “3.0” isn’t going to change that. Reliance on Intel’s GL implementation is flat-out stupid.

ATi may claim support for OpenGL, but it is a minefield. You never know when an ATi driver will crash or choke on some shader. Worst still, you never know when it will choke on some shader after you ship.

Sure it does, finally have cross platform support for a majority of the current GPU features.

No, those are features. They don’t resolve fast-path issues.

I’m personally targeting DX10 level and up

Well golly gee wilikers, isn’t that nice for you. The rest of us recognize that there are millions of DX9 cards out there that need support too.

in IMO the fast path on that hardware is very well defined if you are keeping up with the hardware design

Really? Then does ATi’s hardware support normalized unsigned shorts as vertex attributes? Does nVidia’s? How many attributes can be separated in different vertex buffers on their hardware? What “hardware design” should we be keeping up with to answer these questions?

Think the fact that GL3 provides DX10 level features on XP (assuming ATI and Intel build GL3 drivers for XP), would be enough.

Vista marketshare is only going one way: up. That fact might have been useful a year ago, or two years ago. But that ship has sailed.

For smaller developers, having a larger market share (ie add in Apple as well) could be very important.

But that would be much more expensive, which smaller developers can’t afford. They’re doing good to test on XP and Vista. You’d be asking them to test on XP, Vista, and MacOS X. Not to mention having to develop for MacOS X to begin with.

Be happy for what you have, and do the best to use it to your advantage.

That’s like saying that it’s OK that you were promised a steak dinner and are given dog poo. At least you aren’t starving; after all, you’ve got that nice dog poo.

182

Let me rephrase, is cross platform compatibility the ONLY reason you stay with OpenGL? Can you iterate the features in OpenGL (we’re talking programming features AND hardware supported features) that you’d be without if you switched to D3D?

OpenGL will always be useful for its cross platform nature, there’s no disputing that. Regardless of whether the ARB continues to drag its heels, we multiplatform folk have no alternative. Surely you can convince me that I’m missing something?

183

Thats why i put Bytecode and Binaries as seperate items, i want BOTH.
ByteCode GLSL would just parse the strings into a more compact format that was still high-level language (something like P-code would be ideal)
As ektor said, the main advantage is that you dont get unexpected syntax errors when the customer recompiles it with a different driver.
Other advantages are:
2/ Some optimisations can be done at the tokenisation stage such as dead code removal and combining variables with different scope into one register.
3/ The bytecode is smaller and faster to load (especially for those that have hundreds of shaders)
4/ Those of us who prefer languages that are not ‘C’ can write our own front-end in our language of choice.
5/ The hardware vendors only need to write the back-end compilor.
6/ The load or run-time compilation will be slightly faster.
7/ As the bytecode has been pre-optimised you will get a better assesment of which hardware it will run on.
8/ The source code is not distributed so those who like trade secrets can make it harder for others to see what they did.

Thats exactly what i want it for, i want to get the driver to pre-compile the shaders at installation and not have to recompile them until the hardware or driver changes.

184

As ektor said, the main advantage is that you dont get unexpected syntax errors when the customer recompiles it with a different driver.

Unless the bytecode interpreter has a bug in it. Granted, this is less likely than making a parser bug, but it can still happen.

4/ Those of us who prefer languages that are not ‘C’ can write our own front-end in our language of choice.

Technically, there’s nothing stopping you from doing that now. You’d just be writing glslang code rather than assembly.

8/ The source code is not distributed so those who like trade secrets can make it harder for others to see what they did.

Since the bytecode format would have to be very public, it would only make it slightly harder.

185

To add some facts about Intel’s GPUs:

  • do not support textures larger than 512x512
  • do not support anything DX or OpenGL.
  • crash randomly even on simplest, cleanest, tutorial-code
  • cull triangles randomly, switch to wireframe-mode randomly, generates bogus triangles randomly
  • not even one of the hundreds of queries to DX and OpenGL caps return valid results. I.e it states texture-size up to 2048; as you continue verifying query-results, things become even more horrifying.
    Overall, Intel’s cards are absolutely useless for any accelerated 3D or even 2D. Only GDI works - by a software-fallback from MS, definitely.
    The millions of Intel IGPs sold do not show whether that miserable ancient silicon stays enabled. The price difference when buying a mobo is $4; people that tried to run games or CAD on it definitely saw they need a real GPU for $20+.

I tried to add support for Intel cards to my commercial software [just ortho 2D stuff, using SM1 shaders or FF in DX9 or OGL] - but it proved impossible.

ATi are quite silent about GL3, are missing from the GL3 credits that I saw, and have no extensions in the spec. So it’s safe to think they’ll completely ignore it. Also, it’s funny how the “extensions, promoted to core” seem to be largely vendor-specific and thus could be guaranteed to be missing in most cases. Apple’s VARs and the nv-half-float vtx-attrib, for instance. It kind of looks like GL3 is only bound only to nVidia+Apple. So much for a cross-platform API.

OpenGL2.1’s driver model (FIFOs) on WinXP is great, imho. So, how about providing 2 GL2 renderers for WinXP users (one SM3 model, another with SM4), and a DX10 one for Vista? Cg will be invaluable in such a model. If game/gui features in your software can be wrapped like that, you’ll be giving users a lot of freedom on using their favorite OS and gpu.

186

If its going to be in DX11 then we should get an extension for it when the DX11 driver is released, if not before.

At the moment i do my first pass normally and then do several passes using a screen-aligned quad for post-processing effects like motion blur.
This extension would allow me to specify several fragment shaders that are to be run as seperate passes without needing to setup screen-aligned quads or run the vertex processor every time.
The 2nd and following shaders would simply be run for each pixel of the framebuffer (with the framebuffer/G-Buffer data being prefetched ‘in’ varyings instead of requiring a texture lookup)
This is purely a way to make deferred shading more efficient and more intuitive.

I have a 9 level 256x256 mipmap texture loaded for a background object.
It comes twice as close to the camera so i now need a 10 level mipmap.
I want to be able to stream the new 512x512 texture level onto the card and tell the card firmware to combine it with the existing levels to create a new MipMap that then replaces the old one.
And also remove a mipmap level when objects move away again.

187

I agree Intel’s GPUs suck and I think always will, but the intel GPU in my Mac mini has been working fairly well so far. OSX uses OpenGL in the desktop rendering which works fine and I can play Quake 3 on it and it works perfect. Quake 3’s graphics engine isn’t some really basic code ripped from a tutorial either. But, this may be due to apple going into the drivers and fixing Intel’s incompetence with the graphics themselves, I’m not sure.

I also agree that AMD/ATI needs to pull their heads out of their asses and make a GL driver worth a damn.

188

ATi are quite silent about GL3, are missing from the GL3 credits that I saw, and have no extensions in the spec. So it’s safe to think they’ll completely ignore it.

Maybe. Or, maybe not.

Blizzard, being a MacOS developer, uses OpenGL. They may have a D3D rendering mode for Windows, but they will be using OpenGL. If ATi/AMD is pledging their support, then at least that means that they’ll be taking GL “3.0” seriously, to some degree.

Apple’s VARs and the nv-half-float vtx-attrib, for instance.

Um, what? VAO (not VAR) can be entirely server-side (aka, a lie); there isn’t and never will be a hardware-equivalent. What it does is allow the implementation to do the necessary vertex format checks once, instead of every time you draw with that vertex format.

And the half-float stuff is probably supportable in ATi hardware too.

I would point out that, while ATi may not have written any of the specs, they still voted for it.

This extension would allow me to specify several fragment shaders that are to be run as seperate passes without needing to setup screen-aligned quads or run the vertex processor every time.

You really think that the 4 vertices you use for your screen-aligned quad takes up any real time? I mean seriously now.

I want to be able to stream the new 512x512 texture level onto the card and tell the card firmware to combine it with the existing levels to create a new MipMap that then replaces the old one.

Yeah, you can forget that.

189

Not following you here? My shader doesn’t use matrices as of now, but that isn’t what I am referring to, what I am referring to is this


glTranslatef();
glRotatef();

//now new way with GL3.0?
Matrix4x4 translate;
Matrix4x4 rotate;
Matrix4x4 result;
result = translate * rotate;
glMultMatrixf(result.matrix);

That is what I am getting at… This is how DX does things you had in DX9 some GL type functions for moving objects around and such, but the main idea was to do the latter in the above code, and if I am understanding correctly this will be the new way in GL3.0… I don’t care if it is, I just wanted to clear it up…

190

No, that is not how you do things. This is:


//Full GL "3.0":
glTranslatef();
glRotatef();

//GL "3.0" with deprecated features removed.
Matrix4x4 myMat = //Get some modelviewprojection matrix.
glUniform4fv(<Insert your matrix uniform here>, &myMat[0]);
glUniform4fv(<Insert your matrix uniform here> + 1, &myMat[1]);
glUniform4fv(<Insert your matrix uniform here> + 2, &myMat[2]);
glUniform4fv(<Insert your matrix uniform here> + 3, &myMat[3]);

That is, you have to do everything yourself. You must create a uniform in your glslang shader to represent the matrix in the form you want it in. You must load that uniform yourself for each program that uses it. You must change that uniform in each appropriate program if it’s value changes. And so on.

There are no built-in uniforms anymore at all.

And there’s still the “3.0” full context if you don’t want to get rid of the cruft.

191

First, I must say i’m pretty dissapointed about that spec. You promised a lot but I have the impression you gave us really an “OpenGL 2.2”. On the other hand, i’m still waiting a method to manage shaders like DX does(effects)… We know about glFX … but what’s its real state today?

Second, the ARB’s silence was not good at all. The lack of news, information and uncertainty only made DX10 stronger and stronger. For one year I got the impression that OpenGL was completely abandoned. That’s not any good.

Here, we moved all our PC pipeline to DX10… just because Microsoft keeps us informed, launches a SDK revision almost each 3 months, is more productive, easier due to the lack of “capabilities” and unified model(dx10.1 is a divergence in the force though!)… For the other systems (MacOSX,linux) we have no choice… but it’s bad because we lack some functionality(multithreading pain, not standardized geometry shaders, too many paths to take, sRGB blending nightmare, etc).

OGL lost all its innovation… When DX3 appeared OGL was the king… it has a lot of things that DX lacked, a better/simpler interface, more support, a solid community, etc… then, it suddenly started to loose terrain… and now the situation is the inverse. Today, DX10 is much more innovative, better designed, supported and manageable than OGL… just see the # of the commercial engines for PC-Windows games using OGL and the # of the DX ones… clearly OGL is loosing the battle… each day that pass a bit more.

If the alpha test is immutable, is the alpha ref value also?

??? Alpha test should just NOT “be”. I mean it must be killed without any piety as DX10 did, so it’s completely managed in the pixel shader.

…We decided on a formal mechanism to remove functionality from the API…deprecation

Ok, but I think the deprecation step just adds complexity to the OGL3 programming ( more tests to perform, more paths to follow, more IFs, etc… ) I think it’s better to make a shock change like DX10 did. Change radically and forget the 1992’s model! I think to kill the current obsolete model and to start one new and modern from zero will be the best.

Btw, do you know that DX11 gonna be presented this year, don’t you? I would like to know what the ARB/Khronos gonna do with the hull, domain, tessellators and computing shaders… also how you’re gonna fight with the new(old really) and very flexible software render model of Larrabee and how are you going to define the data exchange for OpenCL(CL not GL, read well :p).

192

You and everyone else here. We told them this is what we wanted, over a year ago they said that’s what they were going to do, then they were silent for a year, then in January 2008 they decided to disregard everything they’d told us and we were expecting and asked for, and they waited until August 2008 to tell us that they totally scrapped that plan, knowing full well that we were still expecting a clean, modern, API, and gave us an incremental update that’s even messier than before.

Khronos Group, give us one good reason to believe a single word that comes out of your mouths about OpenGL’s future.

193

Btw, do you know that DX11 gonna be presented this year, don’t you? I would like to know what you’re gonna do with the hull, domain, tessellators and computing shaders…

What the ARB is good at: shipping stuff a day late and a dollar short. Don’t expect to see those features in GL for the next year, minimum.

Let me rephrase, is cross platform compatibility the ONLY reason you stay with OpenGL? Can you iterate the features in OpenGL (we’re talking programming features AND hardware supported features) that you’d be without if you switched to D3D?

It’s funny how the pro-GL “3.0” crowd completely ignored this most important of questions.

Not one person has stated any reason for using OpenGL other than its cross-platform compatibility. In short, if more people could abandon OpenGL, they would.

Good job, ARB: you’ve succeeded in making an API that should only ever be used if you have no other alternative.

I just want to see how much more epically the ARB can fail. I want to see GL 3.1 with 5 profiles, 2 gigantic deprecated sections, and a spec so gigantic and convoluted that God himself could not implement it.

Oh, and of course, nothing removed from the core.

194

Explain to me please, what means “Deprecation”?

Let I have program which is created with use OpenGL. And in this program are used “Deprecated features”, i.e. at start of this program on the computer with OpenGL v3 or is higher, it will not be possible to work this program?! I.e. if there is a driver with OpenGL v3 it(he) will not provide compatibility with previous versions OpenGL. Thus, probably many programs which for any reasons may not be changed, will not be started in the future?!

195

Panic, panic, panic… it just means this features should not be used anymore and will be removed in future versions. You can also create a GL3.0 context that does not support the deprecated features. IT WILL NOT AFFECT CURRENT PROGRAMS, as they are compiled for an older GL version which will still be supported by the driver!

196

A key requirement of the deprecation model is that you must always opt-in to an incompatible version. Enter WGL_ARB_create_context.

The legacy wglCreateContext is capped at 2.1, so all existing apps will continue to run as long as vendors support a 2.1 driver. I imagine this support won’t go away anytime soon, as 100% of existing apps require the existing drivers.

In order to create a 3.0 or newer context, you must use wglCreateContextAttribsARB(). This allows you to specify a required level of compatibility. For example, if 3.1 remains compatible with 3.0 but 3.2 removes deprecated functionality, a create request of 3.0 could give you 3.0 or 3.1 context, but never 3.2.

197

Thank for the answer. If I have correctly understood you, it is possible to create a context with “deprecated features” and a context without “deprecated features”. How, it can be made? What functions and in what sequence should be named? Where the description of it?

198

WGL_ARB_create_context, as Michael wrote in the previous post.

Still, wait till the 3.0 drivers are aviable, there will probably be some tutorials and docs too.

199

Many thanks, I have understood as to choose a correct context. Not clear there was only one thing. If I have chosen a context of version 3.0 all “deprecated features” are not supported, or the part of them is supported? Or I simply should understand, what if have chosen a context of version 3.0 all “deprecated features” should not be used, they are not important supported whether or not? In a context 2.1 functions 3.0 will be supported?

200

Ok, once again:

  • if you create a normal 3.0 context, all features are supported (even deprecated ones)
  • if you create a forward-3.0 context, deprecated features are not supported

I don’t understand the " In a context 2.1 functions 3.0 will be supported?" questions. If your implementation only supports 2.1 but not 3.0 then it won’t support 3.0 but this should be clear?