I suppose then that this cold have been a big step toward linux gaming: if OGL 3.0 was so nice and powerful to move developers (at least some), then porting would have been far easier and perhaps even rewarding… Linux distributions should be interested in this, since there are so many people that wont switch to linux just because games…
I think if OpenGL 3 had been as nice an API as everybody says D3D10 is, plus having full support for modern video cards (geometry shaders, etc) under Windows XP, that would probably have been enough to get more people using it. Linux users would possibly benefit from that, but there’s the rest of the Windows infrastructure that many developers seem to like. Of course, Wine tends to run OpenGL-based games much better than D3D games, so just having games done in OpenGL instead of D3D would be a good step for Linux.
I don’t know who the ARB listened to, but it doesn’t look like they were listening to the game developers. I doubt that they would have had much interest in the opinions of the Linux distributions either, given their current track record.
Sigh, people stop crying about GL3 in these threads, its over, move on, deal with it, yes they heard the out cry from us. Maybe they will do something about it, maybe they won’t. Your choice is simple use it or move to DX10.
It’s like a break up with one of the partners, but one of them still thinking they are going out!!
Well I’m happy - mainly because of EXT_framebuffer_blit and the relationship to multi-sampling and FBOs, as, if I’m not mistaken, allows custom resolve order in OpenGL. This is something I’ve been waiting on for ages, and looks great.
Generally all draw calls for my code are wrapped anyway so I’m not really fussed about graphics APIs. Working with consoles cuts through any sort of API syntax wishlist altogether really, so nowadays I’m more interested in features than how nice an API is.
In fact I would prefer it if HW vendors could get together and provide a universal push-buffer format API than be messing about with all this high level stuff, though that may well just be an intermediate option anyway.
Having attended Siggraph this year, if Intel does actually pull the Larrabee project off with competitive performance when the HW ships, I think we may well see the real-time graphics world change quite considerably in the next few years.
I’m saying that in the context of this ‘if’: If performance is good, and other HW vendors feel the need to compete in terms of programmability, then it’s reasonable to assume that both GL and DX will eventually become history as more people get access to the hardware and write their own custom renderers.
How long this takes is another thing, but I think Intel have their eyes in the right direction and appear to be moving quite swiftly.
But anyway - digressions aside - thanks for the extension, very useful.
It’s like a break up with one of the partners, but one of them still thinking they are going out!!
That is the best analogy I have ever heard. Khronos just told us they’re not that into us. They’ll still have sex with us, but they don’t want to take us out on any more dates.
We’re either going to move in the direction of adding cross-platform support for Mac and possible Linux, or focus on DX11 and maybe whatever new console MS comes out with next. If OpenGL 3.1 turns out well, we might go cross-platform, but Khronos has consistently proven to be an absolute failure with everything they do. I have never criticized Collada on this forum because of Khronos, but that is another absolute joke from the same failures. I do not expect them to suddenly start doing things right after so much failure.
There is also nothing that makes me AMD will ever have working 3.0 drivers. All the new extensions, plus support for all the old garbage?! They don’t even have working 2.1 drivers. AMD has been pretty good about fixing bugs from my experience with them, but I think the 2.1/3.0 spec is too complicated to expect working drivers, and NVidia’s support is an exception. Working drivers for 3.1 (as it is described now) would be much more likely.
So the situation is exactly the same as before: Only NVidia fully supports OpenGL, AMD does halfway, and Intel’s drivers are a joke. Khronos managed to spend two years doing absolutely nothing, and then put out a spec where their main feature is a list of promises. It’s brilliant, in a way. If you told me I had to write a spec that changes nothing, but it had to look like progress was being made, I wouldn’t have come up with that.
All Khronos does is take other people’s ideas, put their logo on it, screw it up, and call it an “industry standard”. Since they get paid by Sony instead of selling a product, the market forces that would have put them out of business long ago do not apply. So I think we will continue to see astounding incompetence and OpenGL 3.1, as it is described now, will never come to be. They get paid no matter what, so they’ll just keep spending Sony’s money and doing no work until they get cut off from their source of funding.
I think the most accurate assessment of this news is that OpenGL is no longer being developed.
no, custom resolves are not supported currently. custom resolves mean that you can access all subsamples in a shader and do the downsampling yourself after for example tone mapping etc.
For starters, I disagree that OpenGL3 is a failure; I don’t think it’s flawless by any means, but I don’t think it’s a failure. It actually accomplishes several of the goals it set out to do, but in a less aggressive manner. One of the things that was mentioned at the Siggraph BOF was the mandatory support of DX10 competitive functionality for a true OpenGL 3.0 implementation. Also, the direct_state_access extension is required too. That said, the following goals are accomplished…
1.) Faster object creation and state changes promised by the new object model.
- vertex_array_objects provide atomic an optimized path for setting up vertex-buffer/vertex-array state.
- direct_state_access allows for fast creation and modification of texture objects, buffer objects, framebuffer objects, and other resource types.
2.) DirectX 10 competitive functionality.
- for someone to have an OpenGL 3.0 implementation, geometry shaders must be supported.
- render to vertex array must also be supported.
- texture arrays must be supported.
- plus more.
3.) Versioning.
- the new context creation mechanism allows for solid versioning. It simply limits the scope of an OpenGL specification for defining (and implementing) interactions with older functionality. For instance, it makes very little sense to have interactions defined between geometry shaders and fixed function, since fixed function is an extremely limited form of defining a shader. OpenGL 3.0 is compatible all of the way back to 1.0, but the next version will most likely be compatible back to 2.1, or something similar.
Failures:
The biggest failure of the ARB was to limit the backwards compatibility of 3.0. However, with the new revisioning system, I think that the next version will limit the scope just fine. I also got the impression that current IHVs simply didn’t want to break backwards compatibility in 3.0. I think we’ll see 3.1 as functionally identical to 3.0, but without most of the backwards compatibility.
Also, the object model didn’t make it in, but I think they still managed to solve most of the performance issues that the object model was meant to solve. That said, I wouldn’t see this as a total failure, or even a failure at all.
The biggest issue, and I think the one that people are the most upset about is the lack of commitment to an original goal. People planned for a new object model, bought in to it, and then got something completely different. However, in the end, the API that we were presented with is totally workable, and solves most of the issues the original design was supposed to solve. However, from the sound of it, I guess my desires from an API might be different than other people’s.
Also, at the BOF, ATI/AMD stated that they would be releasing OpenGL 3.0 drivers by Q1 2009. As for the quality of them, I’m not sure, but they made a public announcement with respect to their driver plans (which is historically very rare for them). That said, I would guess that ATI/AMD is fully behind OpenGL 3.0 and is very willing to throw resources at it.
Kevin B
First off, how many of you that are bitching about GL, actually program in DX also?
Second, how many actually tried profiling the performance difference between a properly programmed GL version of the same engine and a properly programmed DX9 or DX10 version on good drivers (ie the newest ones from NVidia)?
Got numbers?
If you don’t have specific documented performance problems then my guess is that you just must be complaining that the current GL API is too hard to use compared to DX? Which is really stupid because with either you can get great performance, and both GL and DX interface should be something like a tiny fraction of your code base.
Now as regards to GL3. Have you even fully read the spec and understand the usefulness of what is now in GL3?
Do you realize that most game developers are still DX9 level (because of consoles, and because of Vista requirement of DX10), and that compared to DX9, GL3 offers a tremendous set of advantages (no contest really).
Besides, do you even know what GL3 is missing compared to DX10? Given that ATI has announced that it intends to support the GL3 extension pack, what is left?
Answer, primarily just two things: constant buffers and some state objects (GL3 has some of the more important ones already: VAOs and FBOs).
So really, GL3 is awesome!
There are just to many things the ARB got right this time. Check out MapBufferRange(), much better interface that what you get with DX9 and DX10. Check out the changes which have made it into the framebuffer interface (clean support for mixed format, mixed bit depth, etc). Etc, etc.
So if you want to keep complaining, do yourself a favor and try DX and post some numbers to backup what you are saying, otherwise how can you expect anyone to take you seriously?
- direct_state_access allows for fast creation and modification of texture objects, buffer objects, framebuffer objects, and other resource types.
Direct state access is not only not core 3.0 functionality, it is not even written against the core 3.0 spec, so it doesn’t wrap everything in 3.0.
- for someone to have an OpenGL 3.0 implementation, geometry shaders must be supported.
You realize that they aren’t actually supported, right? Not in the 3.0 core.
First off, how many of you that are bitching about GL, actually program in DX also?
Wait, what? What does that have to do with anything? People don’t have the right to complain about what they have regardless of whether they use the alternative?
Now as regards to GL3. Have you even fully read the spec and understand the usefulness of what is now in GL3?
Yes. I also read about what Longs Peak was going to be. I prefer Longs Peak. By far.
and that compared to DX9, GL3 offers a tremendous set of advantages (no contest really).
A decent API not being one of them, of course.
You SIR miss something.
Before reading scroll back and read what i said about Linux/OpenGL.
Now, picture the new users. I am NOT talking about peoples who already know OpenGL very good, i am talking about new users who want to make games/3d stuff, they look at OpenGL 3 and they get:
- old api
- no documentation ( oh wait, some books for 50$)
- no technical support ( pls dont say comunity forums)
- no sdk
- incert future about drivers/versions
(and the list can continue)
They dont even care about 1-2% performance boost or the ultra high tek extension, got the point now???
ps. yeah i do d3d also. at least in d3d is only one way to load a texture (eg.) and is working on all cards. same as for almost all d3d core, is working.
Direct state access is not only not core 3.0 functionality, it is not even written against the core 3.0 spec, so it doesn’t wrap everything in 3.0.
While you’re correct, this must be supported in order to have an OpenGL 3.0 compliant implementation. How that works, I’m not exactly sure, but this was stated by the ARB at the BOF.
You realize that they aren’t actually supported, right? Not in the 3.0 core.
The same goes for this as well. It must be supported in order to call yourself 3.0 compliant.
So while I’m not sure how something should be required to call yourself 3.0 compliant, yet not be in the specification, I’m not sure. I’m guessing this is just an initial implementation for community review. Can someone from the ARB explain this?
These were things discussed at the BOF. Whether or not these are mentioned in the OpenGL 3.0 specification PDF, I’m not sure.
Kevin B
this was stated by the ARB at the BOF.
Let me get this straight.
The OpenGL Architectural Review Board, at the BoF, said that in order to have a 3.0 implementation of OpenGL, you must implement an extension that was written against OpenGL 2.1.
I’m sorry, no. That’s total BS. Unless you can provide a link to a website or something, I’m calling shenanigans on that.
Same goes for geometry shaders, though at least that is an extension written against GL 3.0.
Whether or not these are mentioned in the OpenGL 3.0 specification PDF
They aren’t. If it isn’t in the GL 3.0 specification, it isn’t in 3.0 core. That’s what the specification is! It defines what is and is not core.
The gl spec, glsl spec, and extension specs are rather complete API documentation by themselves. Otherwise your about one google away from a tremendous amount of free easily accessible GL documentation and examples. Apple for one has a lot of extremely good GL documentation, such as, http://developer.apple.com/graphicsimaging/opengl/optimizingdata.html .
Driver bugs are not the responsibility of the ARB. It is the vendor’s responsibility. You got issues with a driver, bring it up with the vendor.
Have fun asking ATI to fix the drivers problems.
Driver bugs are not the responsibility of the ARB.
Actually, they are, partially. If OpenGL weren’t needlessly complicated, there would be fewer driver bugs.
I’m sorry, no. That’s total BS. Unless you can provide a link to a website or something, I’m calling shenanigans on that.
Same goes for geometry shaders, though at least that is an extension written against GL 3.0.
Does anyone who was at the BOF care to either back me up or correct me on this?
Edit:
While I have not found documentation stating these extensions are required, I have found documentation stating that NVidia and AMD will both support them here:
http://www.khronos.org/developers/librar…BOF%20Aug08.pdf
Kevin B
While I have not found documentation stating these extensions are required, I have found documentation stating that NVidia and AMD will both support them here:
No, ATi said that they would be supporting the OpenGL 3.0 extension pack. Precisely what this means is unclear. It could simply be the “core extensions” that GL 3.0 brings out. That is, extensions to 2.1 that allow 2.1 applications to use certain core features of 3.0 (like VAO, etc). Another interpretation is that they would be supporting all of the ARB extensions revealed with 3.0 (things like geometry shaders and instanced rendering). But direct state access is not one of those.
Basically, it’s up to interpretation as to what ATi intends to support. But I wouldn’t get my hopes up for more than just the core extensions. ATi is pretty strongly against implementing anything more than the bare minimum necessary for OpenGL. And that includes ARB extensions.
Furthermore, there’s a big difference between a few implementers who say that they’re going to support something and saying that GL 3.0 support requires that something.
In the context of the BOF, the “extension pack” referred to is all of the extensions listed in the slides, plus a couple more. I understand your skepticism, but certainly hope that you’re wrong with respect to your statements, otherwise I’d think I was intentionally misled.
It would be really nice for someone else who was at the BOF or even someone on the ARB to come in and either correct me or verify what I’m saying. =)
Kevin B
In the context of the BOF, the “extension pack” referred to is all of the extensions listed in the slides, plus a couple more. I understand your skepticism, but certainly hope that you’re wrong with respect to your statements, otherwise I’d think I was intentionally misled.
“plus a couple more?” I could understand the assumption that the extensions on the slides would see widespread implementation, but where do you get the “couple more” from?
As for being intentionally misled, isn’t that just par for the course with the ARB, who’ve been doing it for the last 9 months?
Dude, get over yourself.