IMO SC2 will not need GL3.0
There’s a difference between “need” and “support”.
“Support” is like how Crysis supports DX10. It has a DX9 renderer too, but that doesn’t stop it from having a DX10 renderer as an alternative.
“Need” is something different. “Need” is, “you can’t run this without R300/NV30-class hardware.” That’s the baseline minimum these days.
Not so. Like most developers, id and Blizzard want the largest possible market and therefore need to support at least the previous generation hardware; therefore 3.0 will not be required. But I would wager they will take advantage of new functionality where they can, whether for performance or eye candy.
Rob Barris has invested considerable time and energy in GL3. There is no question in my mind but he’ll use it.
And from the IHV perspective, nobody wants to be left behind. The drivers will come.
if you build it they will come.
except intel.
And from the IHV perspective, nobody wants to be left behind.
True, I want to own a Ferrari like my neighbor so people will love me as much as him. But it comes down to cost/benefit. If I spent all my money on one would the benefit be worth it?
Intel: Not a major player in DX10 level graphics hardware, nor providing visualization solutions. They’ve been left behind in that field for a while now. Is it worth it to put effort into a 3.0 driver for all that previous and current generation hardware? Doubtful.
Larrabee, who knows. If they’re writing the driver from scratch they might as well do a 3.0 one.
not until they can write one with all the depreciated features removed and STILL call it an OpenGL compliant card.
Until then we might as well expect walt disney to write a full 3.0 implementation (and he’s dead, by the way).
About GPU capabilities… features not supported by GPU will be emulated? (like DX does?)
If we think well, DX is the reference of portability!!!
A power of OpenGL comes from extensions, but I see that it´s a hell too!!!
We can´t ensure that samples, tutorials,… can run anywhere…
them’s the breaks. One thing is for sure in this life: nothing is perfect. And like cigarettes, whiskey, and wild, wild women, expecting otherwise will drive you crazy… it’ll drive you insane.
have you had a nervous breakdown recently, modus? Your comments are getting more and more off the wall (and funny, might I add).
I guess we’ve all taken this GL3 farce hard.
(my doctors tell me that, aside from a long held “delusion” that I am Brolingstanz the Omnipotent, ruler of the planet Prombaatu, I’ve never been better.)
I’d like to say that in my opinion the whining here is largely because people had over 1 year to wrap their minds around what was promised as Long Peaks and get their hopes up, and not so much because GL 3.0 is flawed. It was a mistake not to release any information in January when it was decided that Long Peaks wasn’t going to happen anytime soon, but that’s too late to fix now.
However the improvements to OpenGL are sane and sound, and I’ll definitely continue using it for graphics.
Another thing that should be said is that Ati’s OpenGL 2.1 drivers (Catalyst 8.x) are not as bad as their reputation is. VBO, FBO, GLSL all work fine with my 3870 card (have to admit that I haven’t tried any weird GPGPU stuff, just rendering) and that it’s obviously easier for Nvidia to release GL 3.0 drivers, since alot of the extensions that were promoted originate from them and have been in stable status for a while already. Without any doubt the Ati drivers will include the new extensions soon, it’s just that Nvidia had a head start 
In November, “that other” is going to preview about how next generation hw features will be exposed.
The ARB so far failed to expose all features of current generation hw. And I am not even talking about their “information policy”
It took them 4 years to get vertex buffers into core (version 1.5, 2003). It has been part of “that other” 3D API (version 7.0) since 1999.
It also took 8 years to get render to texture functionality into an OpenGL core (version 3.0, 2008). It has been part of “that other” 3D API (version 8.0) since 2000.
Scott, we have a pretty long list of what didn’t make it into 3.0 (both relating to specific hardware func as well as API streamlining) and have already started work on feature binning for 3.1 and beyond. If there is a feature you want, and want to confirm with the working group that it’s under consideration, the best thing you can do is be very specific about what is holding back your application in GL 3.0.
Access to individual samples of a multi-sampled render target, so one can do a custom resolve for HDR and MSAA or implement stencil routed order independent transparency. (NVIDIA Direct3D SDK 10 Code Samples)
Removing redundant ways of doing things. E.g. One FBO per render target vs. one FBO and then rebinding the render targets. Having multiple rendertargets increases that combination also.
“That other” API has exactly one way of doing this. Both the app and the driver/runtime know what a SetRenderTargets(…) means. Currently in OpenGL “3.0”, the app has to guess what is fast and the driver has to guess what the user wants to do actually.
Currently I have one FBO for each number of active render targets and then I rebind the color attachment properly.
Or with the “new” ARB_vertex_array_object functionality in OpenGL “3.0”. Let’s say I want to render 20 characters, each one has the geometry stored in a separate VBO. And I have 5 different shaders, some using only vertex position (e.g. one for a depth only pre-pass, one uses texture coordinates in addition, another might also use tangents and binormals).
Do what shall I do? One VAO for each combination of character and shader (total = 100)? Or one VAO for each shader (total = 5), rebinding the character’s VBO before rendering. Or one for each character (total = 20) , enabling and disabling client attributes depending on the shader?
Once I get a driver with VAO support, I think I will have one VAO for each combination of active attributes and then rebind the VBOs to it. I have no idea what is better.
In “that other API” there are clear boundaries defined as well as rules how stages can fit together if the downstream stage doesn’t need certain data.
The main thing I wanted from OpenGL 3.0 was to make it easier for IHV’s to make drivers for it. From where I’m sitting, OpenGL 3.0 fails completely at this. Right now, IHV’s will still have to code all those “obscure” features to be OpenGL 3.0 compliant (one way or the other). So, as far as I’m concerned, OpenGL 3.0 brought nothing to the table.
If they had included a “lean and mean” profile with OpenGL 3.0, I think things would be a whole lot better.
Once I get a driver with VAO support, I think I will have one VAO for each combination of active attributes and then rebind the VBOs to it. I have no idea what is better.
There’s no reasonable way that this is better. In fact, there’s a pretty strong argument to be made that using VAOs this way is no different than simply not using them.
The whole point of VAO is to avoid the cost of binding buffer objects: avoiding the cost of glVertexAttribPointer. Thus, you should choose the methods that minimize calling this function.
For example, it is perfectly legitimate to have more attributes bound than a shader actually uses. Because of that, I’d suggest 1 VAO per “character” (or mesh, rather) and just let the implementation figure out that some go unused. That is, never call glVertexAttribPointer inside the main rendering loop. It should only be used for setup work.
It’s not that I don’t disagree with your premise of reducing the “redundant” ways of doing things, but this doesn’t really fit that. The only thing that this misses from LP is the attribute immutability: that each binding point in an LP VAO would have been fixed at creation time. You could still change what buffer object was being used and what the offset into that buffer was on the fly.
Yes, I would rather have immutable objects where that immutability matters with regard to performance. But the VAO case is about the least objectionable case, since we know that the bottleneck is glVertexAttribPointer. The FBO case is more reasonable, as we don’t really know a priori the right way to use it.
In “that other API” there are clear boundaries defined as well as rules how stages can fit together if the downstream stage doesn’t need certain data.
There are rules about how stages fit together in GL 3.0 (and 2.x).
I can’t imagine that there would be significant perf advantages to having more than 1 FBO on current hardware, not having tested. If anything I would expect an arrangement like this in DX instead, where it would seem that higher API interaction overhead would make a tidy grouping of targets an efficient packaging.
However, … (I’d pause at this point to dig up relevant spec issues that make the forward-looking case or argue advantage on the basis of efficient internal bookkeeping and whatnot, but I’m plum tuckered.)
Another thing that should be said is that Ati’s OpenGL 2.1 drivers (Catalyst 8.x) are not as bad as their reputation is.
You obviously don’t do very heavy shader work because if you try rendering to an FBO with AMD’s current drivers gl_FragCoord.y is inverted! If you render to the back buffer, it is not inverted, and it is not inverted on their older cards. So there is no consistent way to detect the problem and use a workaround.
The release of our next product is stalled because if I release it while this driver bug exists it will give us a bad reputation.
GL3 doesn’t make things any easier, so AMD will continue to not provide working drivers, and OpenGL will continue to not work on half our market’s hardware. How many bugs do you think are going to come up when they try adding all the SM4 extensions, without breaking compatibility with the rest of the API, that isn’t even working right now?
One of the reasons I chose OpenGL was because I kept hearing about how OpenGL3 would be a huge cleanup, and I figured around the time our technology was mature, the driver issues would get sorted out with GL3. I did my part, but it turns out everything they said about OpenGL3 was a lie, and they’ve know it for 9 months without saying anything.
There are two advantages of using multiple instances of objects like VAO and FBO. First, you avoid some of the API overhead by binding a single object instead of making multiple API calls to achieve the same state vector. Second, and probably more important, is the fact that some implementations can avoid performing redundant validation if you treat the object as if it were immutable after initial setup. Validation is perhaps the single most time consuming operation within the driver, and caching the results of validation within the object can reduce this overhead.
Immutable objects, as Longs Peak intended to deliver, prevent the developer from dirtying the state of the object. You can achieve much of the same effect by simply never modifying object state after creation, although you cannot eliminate the overhead completely under the current object model. Instead, simply create a new object for each unique state vector, or at least those which are most frequently used. Whether the incremental performance gain of immutability is more important than the lost flexibility of editable objects is an open debate, and in fact was one of the major sticking points in delivering on the ARB’s original plan. (By the way Leadwerks, while the change in direction was unfortunate, the originally advertised plan was never a lie, and I can personally attest to this fact.)
Treating objects as immutable instead of thrashing object state may benefit legacy objects like textures and buffers as well as the new objects introduced in 3.0. The same principle applies.
By the way Leadwerks, while the change in direction was unfortunate, the originally advertised plan was never a lie, and I can personally attest to this fact.
A lie of omission is still a lie. It’s one thing to decide to change strategy; it’s quite another to not tell anyone about it for 8 months.
I never cared about the immutable object thing. As a general rule I avoid them because they require more dynamic memory allocation, although the implementation on the GPU might be a completely different matter.
My gripe is that OpenGL3 does not make working AMD drivers any more likely than OpenGL 2.1. In fact, it makes them less likely, because it adds new features without simplifying anything. That is why I feel like we were deceived.