I don’t agree (for Nvidia anyways). Their Cg 2.0 Toolkit/SDK already supports the latest features (gp4vp,gp4gp,gp4fp) in OpenGL while the Cg Direct3D interface is stuck at DirectX 9c. Same is true for CUDA interoperability. And they still provide nice OpenGL SDKS although they might not be as elaborate as the Direct3D ones.
Now the trick with Cg and HLSL is that although NVIDIA and Microsoft joined forces in developing the first shader languages for graphics hardware; both companies are in the language industry 
But you are right NVIDIA is still trying to promote Cg as the standard shader language.
And NVIDIA can hardly compete with HLSL as the native language when using DirectX, on the other hand they can more than compete with GLSL. Which also explains the occasional driver flukes, because they certainly have a interest in bring Cg into the OpenGL standard.
But lets bury the DirectX comparison.
Has anyone heard anything at all when we are to expect OpenGL 3.0? Whats causing the delay?
The fast path is always going to be hardware specific and something which requires either good vendor documentation or simple profiling by the programmer. How is GL3 going to aid the programmer in knowing? GL3 going to have an API which you can probe to know all the differences in hardware? That would simply be a nightmare of complexity.
The core stuff needed for speed is currently well documented for GL2. How much faster do you actually think a GL3 app will be compared to a GL2 app on the same hardware?
About the only case I can see GL3 kicking some arse is if your application is draw call bound on the driver (actually on the driver side, and not on your side feeding the draw calls). And if you are driver side draw call bound, then you might want to re-engineer, optimize, and factor out the draw calls away anyway.
Making the fast path the only path is one of the primary goals of GL 3.0.
Agreed. And GL3 hopefully will finally enable some IHVs to actually get fully functional and DX matching drivers out when they release hardware.
[quote]Given that ATI/AMD isn’t adding EXT_gpu_program4 type support for HD anytime soon
How do you know that? I always assumed that the general feature freeze for GL 2.1 was to promote GL 3.0 and Mt. Evans when it came out. That is, ATi took its meager GL development and focused it on preparing for GL 3.0.
And don’t forget: ATi just finished a complete rewrite of their GL drivers; that basically stalled any real GL development for a good 6-12 months. And that rewrite was probably looked at in terms of making sure that the low-level code was ready for GL 3.0.[/QUOTE]
I hope you are right about that!
But that being said, all the hooks needed for GL2.1 and most of EXT_gpu_program4 should already be in the DX10 / DX10.1 drivers. Wouldn’t be too tough to build a mostly functioning GL2.1 + EXT_gpu_program4 wrapper around the DX10 interface. Take NVidia’s drivers for example, aren’t they like 95% shared code base between all platforms (DX and GL on multiple OSs). Why blow out 6-12 months writing a separate not fully functional new GL driver when you could just do a fully functional wrapper around a shared already fully working DX10 code base.
Even with GL3 done, I’m guessing it is going to be a long time before Evans, and I would still bet ATI/AMD doesn’t add support for GL2.1 EXT_gpu_program4 in the mean time. Honestly I would love, really love to be wrong on this.
Um, I don’t see anything particular special about later-gen GPUs (even Larrabee) from a graphics API perspective. Oh, if you’re talking about them writing an API for accessing a GPU at a low level, then maybe there’s a need for a unified API there. However, this is fundamentally different from a graphics API. The needs of the two tasks are different, with precious little overlap.
Not yet, just wait, there will be much overlap in the future. I can give many many examples if need be.
The goal of the GL 3.0 graphics API was to be backwards compatible with all GL 2.0-capable hardware (obviously not BC with the API). If you start taking that off the table, there’s absolutely no point in switching to an API that can’t be used until hardware that won’t exist for 1.5 years comes out.
Very important point here. Could be part of the problem be given that GL3 was also trying to be “future proof” and the future seems to look quite different than the older hardware!
For mobile devices you are to use OpenGL ES… Cant find a mobile device which actually supports say OpenGL 2.1 sure you can use ES but thats an entire different API.
I believe “entire” is quite an overstatement. OpenGL ES is OpenGL but stripped down to bare necessities implementable on current mobile devices.
My point on consoles is that there is no standard but what the vendors create.
I believe that’s the antithesis of “standard”. I didn’t interpret that as “your point”. You stated that OpenGL was not really multi platform because it wasn’t supported on all consoles. Even for gaming GL is more multi platform than D3D… PC, OSX, Linux, ~PS3. If you include professional applications it’s an even wider market. That was my point.
It remains to be seen how much support there will be behind GL3 when the spec is finally out. Right now it’s pure conjecture.
Again you fail to understand that DirectX was not developed by Microsoft alone.
I understand that completely, don’t worry. Without MS there would be no D3D. While SGI did create GL, “Open” GL exists just fine without them. However, the ARB and now Kronos don’t have the resources that MS does to throw at tools and developer promotions.
My point is OpenGL lacks a company devoted to the survival of the standard.
You are absolutely correct. Having a well-known company (or arguably companies) “dependent” on GL would be a huge benefit. Dependency is a great motivator.
Then we agree 
The lack of a major player involved/devoted to OpenGL is becoming more and more apparent at least for me.
OpenGL running on PS3 is just not correct its a Sony owned version of OpenGL ES. And with the lack of good drivers you can count out OSX and Linux depending on what IHV your are trusting not to throw a null pointer at your attempt to unlock geometry shader 4.0 add consistent quirks like when ATI drivers forced into software when writting to gl_ClipVertex; I am simply amazed of the lack of driver conformance, and the IHVs get away with such sloppiness.
By the way OpenGL ES isnt the only player on the mobile device market, NVIDIA has actually chosen that the new APX 2500 is targeted for Windows Mobile only. It will have support for OpenGL but it is likely that the preferred graphics API will be D3D mobile, time will tell.
Its a standard so in theory your list is correct, but not in real life. Take for example texture proxies which as far back as I remeber have not worked.
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=234665#Post234665
Why hasnt there been an effort to make an add on library to OpenGL which takes some of the nicer things from D3DX.
And who precisely is going to write and support it? You?
The ARB pre-Kronos had precisely enough resources to write specifications and PDFs. The Kronos ARB has slightly more resources, but look at the “OpenGL SDK”. Everyone knows what an SDK is supposed to be, yet they released nothing of the kind. Why? Because they don’t have the resources to write, debug, and maintain anything like D3DX.
It makes me smile when arguments start to degenerate into the “philosophy” of OpenGL
It’s used a bit like a shield you raise each time you don’t want to answer about an important missing functionality.
It’s not a shield, it’s a prioritization. It represents an understanding that a particular process of design has a goal to it, and the achievement of that goal is to be served by that process. So when you look at feature X, if it doesn’t fit with the design goals, you don’t include it.
We refuse to hear anything about querying video memory usage, but meanwhile, it’s possible to query the amount of temporary registers or max instructions in shaders, for example…
Actually, max instructions and temporary register counts aren’t querriable in glslang, only in the ARB_*_program extensions.
Oh, and what happens to your precious “video memory query” when full-on virtualization comes along? Should the driver report that the hardware only has 64MB of memory, or the size of your main memory? That “philosophy” exists for a reason.
But then again alot of the forum users seem to be very happy with how things are.
Um, since when? Nobody on this forum is “very happy” with GL 2.1 as it stands. We all want GL 3.0. What we don’t necessarily want is GL 3.0 == D3D, which is what you seem to be arguing for.
The fast path is always going to be hardware specific and something which requires either good vendor documentation or simple profiling by the programmer.
That’s a half-truth.
Yes, the fast path will always be hardware specific. But the API does nothing to communicate hardware limitations to the user. What to use normalized unsigned shorts in your vertex data? The API says fine whether the hardware can do it or not. And if it can’t, then the driver now much read your VBO (slow), rearrange your data, and write it to another VBO that it then uses to render from. And it does this every time you draw.
That’s one of the things GL 3.0 promises to deal with. When you create a VAO, you tell it what your vertex format will look like. If the hardware doesn’t like it, it will simply fail to create the VAO. Simple.
You may not be using the fastest possible path for your data (using floats when you could live with unsigned shorts or something), but you won’t fall into the “driver must emulate functionality X for this hardware” path. There is better communication between the user and the hardware through the API.
Wouldn’t be too tough to build a mostly functioning GL2.1 + EXT_gpu_program4 wrapper around the DX10 interface.
You might have noticed that OpenGL uses a different shading language from D3D. That means that implementing EXT_gpu_program4 would require changing the compiler, linker, and optimizer. This is a lot of work.
It isn’t a lot of work for nVidia, because they just compile glslang to Cg, which by being a slight spinoff of D3D-HLSL, already has these features. They can leverage their D3D-HLSL compiler. ATi can’t.
The lack of a major player involved/devoted to OpenGL is becoming more and more apparent at least for me.
Have we forgotten Apple? Oh, and therefore Blizzard.
Blizzard, for reasons that continue to perplex me, loves making Mac games. Every Blizzard game has a Mac version, and they will continue to do so.
Apple has precisely one interface for 3D graphics: OpenGL. That’s it. If OpenGL doesn’t work, World of Warcraft doesn’t work. And that’s not acceptable to Blizzard or Apple.
OpenGL is built into MacOSX itself; it relies upon it for its rendering needs (though it is a bit more complex than that).
In short, Apple needs OpenGL in order to have 3D applications. Blizzard needs OpenGL to work in order to make 3D games on the Mac.
Apple doesn’t care about getting an OpenGL SDK; that’s not important to them in any way, because it doesn’t help solve their problems. What Apple wants is an OpenGL that is more performant, easier to write drivers for (though they solved much of this problem in their OS implementation), and so on. Apple is dependent on OpenGL.
The problem isn’t that someone isn’t dependent on it; the problem is that someone can’t dictate the progress of OpenGL. Microsoft may have collaborated with nVidia on D3D-HLSL, but they had final say. The language was as they wanted it to be. The D3D API may have been developed with input from IHVs, but Microsoft was ultimately in charge of it.
The fact that everything requires a vote and so forth with the ARB is probably the biggest limiting factor. If two people are having a good faith disagreement on a point, the deadlock can’t easily be broken.
Take for example texture proxies which as far back as I remeber have not worked.
I think you’re misunderstanding people. It isn’t that everone thinks everything’s AOK with OpenGL. It’s that they don’t think that the solution is to give up or copy D3D.
[quote=“ruysch”]
Then we agree The lack of a major player involved/devoted to OpenGL is becoming more and more apparent at least for me.[/QUOTE]
Some would argue that OpenGL would have had no place in gaming had it not been for John Carmack’s vocal support for it back around '96. It would definitely be a boost for GL for something like that to happen now. Who knows, maybe when 3.0 comes out there will be a surge of support.
Every GL implementation is a proprietary implementation, technically.
You are really just picking hairs. If GL didn’t work on any platforms, sure it wouldn’t be considered multi platform. The facts are against you however. World of Warcraft runs quite fine on OSX, for example. And you’d be hard pressed to tell other coders in this forum that work on Linux that they aren’t technically using OpenGL because the drivers aren’t as good as Window’s drivers.
Lack of perfect support does not make GL less multi platform. You could argue it’s usefulness on certain platforms but the fact remains that if you do 3D on a platform other than an MS platform, chances are that you’re using GL. I’m not sure how else you’d define multi platform support.
I have just written an app for linux, but since i am a windows-guy i did it on windows (with Qt). “Porting” it to linux was really only compiling it for linux. There were zero issues, that i had with the OpenGL drivers. Neither on nVidia nor on ATI, that i didn’t have on windows too.
So, in MY opinion, that counts as multi-platform. With D3D that wouldn’t have been possible.
But in MY opinion you fail to see those arguments anyway. YOU argue, that for an API to be multi-platform it needs to
a) be supported on ANY platform
b) work without ANY differences, equally on ALL platforms
a) is not the decision of the ARB. The owner of the platforms decide whether they want to support OpenGL, therefore there is no OpenGL for the xBox.
b) is not possible, since every implementation is done by different vendors, introducing different errors and having different performance characteristics for their hardware. But D3D is no different in this point.
But i guess this discussion is pointless anyway.
Jan.
Hmmm, whats planned for GL3 doesn’t make me really happy. My problem here is the “error reporting on create”. I’d prefer a “query what works” before creating any resource and a simple “fail on create” when creating the resource. I see an explosion in error return codes…
// TODO: Make this a recursive function... lol
GLerror error = glCreateStuff();
if(error != GL_NO_ERROR)
{
AdjustParameters(error);
error = glCreateStuff();
if(error != GL_NO_ERROR)
{
AdjustParameters(error);
error = glCreateStuff();
if(error != GL_NO_ERROR)
{
AdjustParameters(error);
error = glCreateStuff();
if(error != GL_NO_ERROR)
{
// You get the point... hehehe :-D
}
}
}
}
It’s true, not really a very important point, but somehow annyoing. And it makes writing buffer factory classes impossible.
As a funny sidenote, this board is a proof that GL2.0 + FBO is in no way a replacement for DX9. 90% of the threads are about driver errors, unpredicted behaviour, non-standard behaviour, strange results without error codes, incompatiblities, crashes, etc.
I hearby demand a name change from “OpenGL Coding: Advanced” to “OpenGL Coding: Guess what the error is! A forum for the whole family!”
My sense of humor is a bit crappy today.
To be true, it would be really nice if we can get some progress update, that is not the common “we are working on something”, look at our nice presentations… But a simple, why the delay, whats the current state, what are we working on.
How so? If a format’s not supported, then it’s not supported. Makes no difference whether you called glCreateStuff() or glIsThisPossible().
You’re being a picky sod, and frankly it’s getting annoying.
Yeah, thats the problem with public forums. Simply, click on my user name, click on “view profile”. An user page shows up. Click “Ignore this user”. Your problem is solved. Wow… that gives some ARB feeling. “Ingore those users”. Why not shove your opinion about other people right up your ass?
So this implies to me that we can’t even query texture sizes before trying to create the resource? And then we start permutating widths and heights? Or some half-baked model we have currently, some stuff we can query, some not? Then I prospose the following model: All texture widths are available by a query, all heigts by create and error. Same with vertex element types, unsigned types by query, signed types by create and error. Floating point texture formats by query, integer types… etc.
Well the query mechanism as I have heard about sounds a lot like the way D3D works. Could you post a link to where you have your information from?
That’s what I’ve read from the few pipeline newsletters and some posts in the boards.
Are you feeling ok?
If what you want to do won’t work, you can’t do it. It’s really that simple. Query mechanisms won’t help a whole lot to overcome this, at least as far as I can see. IF you were trying to find some working combination, you’d have to enumerate all possibilities until something valid popped through either way. It’s not like it’s a linear programming problem…
Unless I’m missing something.
Lindley, imagine the following hypothetical scenario: you have a 4096x4096 bitmap that you want to upload as a texture. Depending on max texture size, you’ll need to downsample it, or split it up into different objects. How would you do this with and without queries?
A trivial example, but it highlights the difference in the approaches. If you can query max texture size:
int max = GL.GetInteger(GetPName.MaxTextureSize);
if (max < bmp.Size)
bmp.Resize(max, max);
GL.TexImage2D(texture, PixelFormat.Bgra, PixelInternalFormat.Four, max, max, bmp.RawData);
if (error = GL.GetError() != 0)
...
If you cannot:
do
{
GL.TexImage2D(texture, PixelFormat.Bgra, PixelInternalFormat.Four, bmp.Width, bmp.Height, bmp.RawData);
if (error = GL.GetError() != 0)
if (error == ErrorCode.TextureSizeExceeded)
bmp.Resize(bmp.Width >> 1, bmp.Height >> 1);
else
...
}
while (error != 0);
The latter is less performant, as you have to blindly resize the bitmap until it fits; and since you can’t query maximum size beforehand, there is no way around that.
It is not linear programming either way. However, queries allow you to separate the setup from the renderpath (i.e. check capabilities and choose the best available renderpath). Without queries, you have little choice but litter the actual renderpath with blind trials. You may argue that you can execute the trials beforehand, but in this case you are just emulating queries, albeit less efficiently!
Anyway, this topic has been discussed extensively in the other GL3 thread. Back to waiting, I guess.
I would say, that max texture sizes are parameters that will be queryable. HOWEVER, only because you do fulfill the restriction on the size, it might still fail (as you recognized in your first example, too).
It makes no sense to have an API that does not allow to query ANY values, as your example shows well.
However, in OpenGL 2.1 the spec implies, that when you fulfill the queryable restrictions, it will work (which is in reality not the case). OpenGL 3.0 simply changes this, that you will most certainly still be able to query some max values, but the meaning of those is simply, that when you DO NOT fulfill the restrictions, it will DEFINITELY fail. When you DO fulfill the restrictions, it is still up to the creation-call to decide, whether the actual combination is possible.
This is an important contrast to 2.1, where after you made sure to fulfill the restrictions, there is no mechanism for the driver to reject your chosen combination (only FBOs are able to return “unsupported”). So the drivers TRY to allow all valid configurations, which makes it often difficult to hit the fast-path.
There is one ring to rule them all, but there is not one mechanism to fulfill every bodies needs. The ARB might be slow, but they are not stupid. There will always be min/max values to query, but with 3.0 the driver will have a way to communicate with the application, instead of silently trying to obey its master for better or worse.
Jan.
To be true, it would be really nice if we can get some progress update, that is not the common “we are working on something”,
look at our nice presentations… But a simple, why the delay, whats the current state, what are we working on.
The thing is they can’t just lean in here and whisper in our ears… they’d have to announce it to the world, and in so doing they’d have to make it official, with all the pomp and circumstance befitting an announcement from Khronos. As such I suspect they’d like to wait until they have something substantial to say, in preference to a spring throat clearing.
Anyhoo, it wouldn’t be a pub-like nudge-nudge, wink-wink, say no more, he said knowingly kind of thing.
About the query vs. error-on-creation issue:
When you develop an application, you have general idea what the hardware you target is capable of. So you can have different rendering paths, ending with code like
if not VeryAdvancedPath then
if not AdvancedPath then
if not Simplepath then Exception("Get a new card!")
[\code]
In my opinion, this is very convenient. With a query mechanism, you will need to "duplicate" your code (a query part and a setup part), making it more complicated. The idea is, that a single application will never use lot of different feature combinations. It is common sence that each card that, say, supports floating-point texture blending also supports the so called "SM2.0" shaders: the point is, the combination of features are not arbitrary, but rather very well defined by evolution of graphics cards. So the "trial-and-error" structure of GL3 is very practical. Also, there are features that can hardly be queried, like special combinations of shader instructions.