No GL3 and no newsletter yet...

[CrazyButcher]

it depends on how you define "customers" for a open-standard. There is no real loss, "openGL" is not a company, and the xplatform ness + huge amount of legacy apps in CAD/whatever serious application is still there, that aside OpenGL ES has probably most importance today, but also has less issues...
The only thing where GL in it's current state really fails would be game market imo, due to the things mentioned (binary shader, precompiled, performance tools and better drivers across hardware). For non-game, ie where platforms/hardware are less likely to vary greatly (read nvidia based, or arb programs shaders/vbos for some CAD rendering) it's still perfectly useable.
that aside I share the frustration and hopes about a xplatfrom gameapi, but I think we will always have better d3d drivers across the board than ogl, simply cause of market share.

[bobvodka]

Legacy means nothing for a new breaking standard. Those legacy apps will stick with working OpenGL2.x libraries/drivers and if the percieved support isn't there for GL3.0 then the code will be migrated. Many apps already have a D3D backend anyway.

Crossplatform-ness means very little;
- PC is dominated by D3D
- 360 is D3D
- PS2 used its own API
- PS3 uses its own API afaik
- Wii uses it own API

That leaves you with Mac and Linux, which compared to the above (and in the PC domain at all) is hardly any market share.

Also, what OpenGL is losing right now is programmers. I've switched to D3D10, others are considering D3D9, and the general advice given to newbies is 'learn D3D' (advice echoed by myself simply due to the extra tools you can use when you get started).

That's what this is costing OpenGL, that and reputation, although the rep. sucked before now and the chance to turn it around has been horribly botched with the lack of communication.

Hate MS all you like, at least they get [censored] done.

[Demirug]

- PS3 uses its own API afaik

The PS3 offers optional OpenGL ES support. But it’s hardly used by the developers. Anyway even if you use the OpenGL ES wrapper the shader language is still Cg and not GLSL.


Hate MS all you like, at least they get [censored] done.

It’s not only about getting things done. It’s although about managing the expectations of the community. I am sure that after the newsletters I was not the only one who expected to get the OpenGL 3.0 spec last year. On the other hand the public presentations about the future of Direct3D gave me now Idea when we will see the next API iteration. They only gave an Idea what could be part of it. Another nice thing that Microsoft started with Direct3D 10 are the CTPs (Community Technology Previews).

[knackered]

At the end of the day, it matters not a jot which API you use from a programming point of view. For me it only matters which shading language I use, and even that's not very important, as translating from one to another is trivial.
These are the main reasons why I primarily maintain the OpenGL implementation of my renderer interface:
1/ it supports quad buffered stereo and gen-locking/swap groups. D3d just doesn't, and never will (vista makes it impossible). My d3d renderer implementation just has a printf("switch to GL") in those functions.
2/ The draw call overhead is insane with d3d (v9, which is the only realistic option). To get decent performance you have to have ideal, pre-processed-to-f-uck scenes. With OpenGL, it's just not an issue. I regularly get above spec throughput with OpenGL when rendering CAD-type scenes, but struggle to get anywhere near that with d3d.
For me, and I dare say many others, d3d = d3d9, and therefore means stupidly costly draw calls and lack of professional features.

[dorbie]

It's important to rev OpenGL, the number is far too low, 2 vs. 10, how can OpenGL compete. Pretty soon D3D will go "up to eleven", ELEVEN people!!!!!

:-)

btw, well done knackered, good post.

[Zengar]

OpenGL XI 8)

[knackered]

Thanks dorbie. I hope to god OpenGL doesn't die, or any kind of clustered visualisation systems are going to start looking very dated in a few years time.

[CatDog]

For me, and I dare say many others, d3d = d3d9, and therefore means stupidly costly draw calls
Could you elaborate on that? What do you mean by higher draw call overhead? And how does this affect on rendering CAD data with high batch count?

CatDog

[Zengar]

Draw call overhead=initialization time spend on setting the batch up. Draw calls in DX9 are very costly in comparison to OpenGL, so your application becomes CPU bounds very fast if you don't minimize the batch number. In DX10, the driver model was changed so that draw calls became cheaper.

[knackered]

The last time I measured it, a draw call was 3 to 4 times more expensive in d3d9 than in GL. So, in turn, the more batches your scene consists of, the slower it is going to render. Dynamic CAD data is difficult to batch in a CPU and memory efficient manner. For example, to batch a dynamic scene can require data duplication (pack meshes into a single VB if they haven't moved in a while) - and if your scene already has a 3GB footprint, this obviously isn't an option, so you accept the poor performance.
Some of this can be alleviated by using geometry instancing, but it isn't that common to have a great number of identical instances in engineering data.
Aside from engineering data, there's a move towards games being more and more dynamic, with unified physics etc. and this kind of forces you to draw lots of batches.
And yes, this problem is apparently fixed in d3d10, but 10 requires vista, and vista itself imposes a 12% performance hit, as well as being a dead-duck of an operating system that nobody's using.

[CatDog]

Yes, batching dynamic engineering data is very painful. I am for example minimizing the batch count by merging geometries with same properties - but this creates rigid bodies, so it's limited to the static parts of the scene that I know to be static beforehand.

That's why I asked and that's why this is bad news for me.

So the (my) options are sticking with an ancient and nearly dead API or switching to that new and supported API that nobody's using. Cool.

All that is somewhat disappointing.

CatDog

[Dark Photon]

It's important to rev OpenGL, the number is far too low, 2 vs. 10, how can OpenGL compete. Pretty soon D3D will go "up to eleven"...
"Yeah, jus' one mo'. Ya jus' need one mo'."

Man, that was a horrible movie. :p

[KRONOS]

Isn't it obvious? They're adding the API for ray-tracing... :p
(I wouldn't be surprised if nVidia is backing up Intel on this)

[Seth Hoffert]

Nice one, I laughed a little. :D

[knackered]

No, it isn't obvious. The revision of GL we're asking for is the one where the interface is tidied up and streamlined, not the one where new features are added. Even if they're trying to modify the object mechanism with a view towards ray tracing, I still don't see the reason for such a ridiculous delay.

[EvilOne]

At the end of day, all I wanted from GL is a nice API and performance cleanup. A fine interface to code for DX9 class hardware and up.

The most annoying thing in GL is, that every renderstate has it's own setter function. GL is a damn function-mania...

For instance, in my D3D renderer I setup states this way:



for(int i = 0; i < count; i++)
{
unsigned int state = *table++;
unsigned int value = *table++;

if(cache[state] == value)
continue;

Device->SetRenderState(state, value);
cache[state] = value;
}


The nice thing with D3D is, you can write clean and compact code... Easy to maintain. GL code almost always "look and feel" butt-ugly, although it does the same as it's D3D counterpart. I hope they think about the API design carefully.

And hopefully they throw away this completely crap GLSL constant model. It would also be nice, to bind constants to specific registers.

Example in HLSL:

float4x4 WorldViewProj : register(c0);
float4x4 WorldView : register(c4);

All my shaders have a common set of such constants. Simple to maintain and even simpler to setup.

Why is there no counterpart for glBindAttribLocation (something like glBindUniformLocation) - that would helped somehow.

Hopefully, GL3 will stop this we-need-more-entrypoints-mania...

Btw, coding GL using good old ARB vertex- and fragment programs is fun - thanks to program environment parameters. I hope, that they will never drop those nice extensions. Because my guess is GL3 GLSL replacement and API is as crap as the current one.

And to Khronos as always: Thanks for nothing.

I would bet my ass, Siggraph 2008 will not bring any good thing about GL3 (I don't trust any annoucement). Just the common "look at us, we have ES".

[knackered]

for you, the renaissance was just something that happened to other people, wasn't it?

[LogicalError]

are you implying you where actually there in the 15th - 16th century? :)

[bobvodka]

you mean you werent?

[EvilOne]

The renaissance happend. But unfortunally not to OpenGL.

[knackered]

not yet, anyway............................................ .................................................. ...

[LogicalError]

not yet, anyway.....

Repeat ad infinitum?

[PkK]

Here's something someone who AFAIK is on the ARB posted to a public (so I assume it's OK that I repeat it here) mailing list today:

- GL_EXT_texture_buffer_object allows a portion of a buffer object to be
used to back a texture.

- GL_EXT_bindable_uniform allows a portion of a buffer object to be used
to back a block of uniforms.

- GL_EXT_transform_feedback allows the output of the vertex shader or
geometry shader to be stored to buffer objects.

- Long's Peak has functionality where a buffer object can be mapped
*without* waiting for all previous GL commands to complete.
GL_APPLE_flush_buffer_range has similar functionality.

- Long's Peak has NV_fence-like synchronization objects.

[bobvodka]

The first 3 of those are GL2.x extensions and, afaik, currently only supported by NV.

The last one was known (see pipeline) and the 2nd to last can be more or less done now with a "discard" update to a buffer.

[Brolingstanz]

NV has pretty much all of sm4 wrapped up in 2.1; they've even added the drawbuffers2 extension (separate RT blend enable and write masks), which as i recall was only recently exposed in dx10.1.

I see also framebuffer mixed formats and conditional render are still in the "X" stage. Seeing as these are already implemented for dx10 it's obviously just a matter of pushing things through the OpenGL "bureaucracy", which is obviously not as easy as one might expect.

[Seth Hoffert]

X stage? http://www.opengl.org/registry/specs/NV/conditional_render.txt :D

(Or does X mean NV and not EXT?)

[Brolingstanz]

"X" as in X-perimental ;-)

Hadn't noticed there's no X in the spec though, just in the extension strings.

[Mark Shaxted]

Has anyone else noticed that the opengl.org homepage had a link to a blogspot entry talking about GL3? This has now been removed... conspiracy? Que theme music for 'The Twilight Zone'!

[Seth Hoffert]

Ohhh, I see. I never knew what "NVX" meant until now. :)

[PkK]

Has anyone else noticed that the opengl.org homepage had a link to a blogspot entry talking about GL3? This has now been removed... conspiracy? Que theme music for 'The Twilight Zone'!
When the Link was there I thought "just allowing that link to be posted to the front page means they think GL3 is important and are probably working on it". Now it looks more like "they've abandoned GL3, so they censor a link to those that say GL 3 is important, however they're so slow they need a whole week just to censor a link".

[ScottManDeath]

Per rendertarget blend enables are D3D 10.0, but with the same blend function and blend equation. D3D 10.1 adds per rendertarget blend functions and blend equations.

DX 10 has multisample textures, which GL is lacking, even on NVIDIA. Other vendors only support GLSL GS and transform feedback, but they dont support integer ops in the shaders, no integer textures, no texture arrays. So there is no real wide spread SM 4.0 feature support on GL.

[Eddy Luten]

The link to my post was removed due to reasons I will leave undisclosed, but the reasons are nothing like what PkK implies. I'll post it here, since everything here is casual.

Why OpenGL 3.0 is Important (http://scriptionary.com/blog/2008/05/15/why-opengl-30-is-important/)

Edit: PS, Korval, thanks for the elaborate comment, much appreciated. :)

[Brolingstanz]

Per rendertarget blend enables are D3D 10.0, but with the same blend function and blend equation. D3D 10.1 adds per rendertarget blend functions and blend equations.


Right, I stand corrected.


DX 10 has multisample textures, which GL is lacking, even on NVIDIA. Other vendors only support GLSL GS and transform feedback, but they dont support integer ops in the shaders, no integer textures, no texture arrays. So there is no real wide spread SM 4.0 feature support on GL.

Afaik Nvidia implements all of these in OpenGL; but you're right that there's no wide spread support.

[Zengar]

Afaik Nvidia implements all of these in OpenGL; but you're right that there's no wide spread support.

Could you please point me to the extension that provides multisample textures? I was under a strong impressions this was still unsupported (even under nvidia)

[Brolingstanz]

Well, there's framebuffer_multisample.

[-NiCo-]

@modus
I believe thats only for creating multisample renderbuffers, not multisample textures

[Zengar]

And Nico is right, no textures in the spec...

[pudman]

The link to my post was removed due to reasons I will leave undisclosed, but the reasons are nothing like what PkK implies.

(My wild speculations follow...)

Reasons you decided to leave undisclosed or are requ

[Jan]

And while he was typing his wild speculations he was killed, because he discovered that öajdf lkn

[pudman]

I just looked at my post and thought for a second "Wow, they deleted my post too! I must have been right!"

But no, my internet connection has been bad at my house the past week and apparently the post simply died mid-transmit.

The synopsis from the last post is: 3.0 is probably scaled back or changed enough such that commentary, even on the publicly available Pipeline, is too inaccurate to present on the front page.

[bobvodka]

Or maybe they just don't want to promote personal blogs on the front page? *shrugs*

[PkK]

Here's another little bit of info from the same source as last time (from a discusion about sharing GL objects between contexts):

We're going to update the GLX spec after OpenGL 3.0 ships, and we're going
to make a lot of this more explicit.

While this isn't much info by itself it seems they're still working on GL 3 and expect to have it ready in finite time (otherwise they wouldn't think about what to do after GL3).

Philipp

[bobvodka]

Well, the 'finite time' was kinda half assumed from the "Longs Peak Reloaded" and "Mt Evans" plans they had... you know, around a year ago...

[pudman]

I'm sure Duke Nukem Forever will be completed in finite time as well. Just what the length of that finite time is ahead of time is the problem.

[Leadwerks]

If (money < time) GL3 = NULL

[Jan]

Money and Time are of two different units, you can't just compare them like that (basic physics-class).
It would be more like this:

if (money < time * money_per_time) GL3 = NULL;

Jan.

[-NiCo-]

So everybody saying "time is money" is wrong? :)

[tanzanite]

Yes. It is a badly worded statement describing a perceived correlation between time and money. :P

[Jan]

Nice :-D

[k_szczech]

Hey, OpenGL 3.0 has arrived. And guess what - it actually has a new logo:

http://ks-media.ehost.pl/opengl_org/OpenGL3.jpg


They should really name it 2.2. Everybody would love new features in 2.2, and simply continue to wait for 3.0. What we have now is:
-ARB is working on 3.0
-it turns out to be 2.2
-it's released as 3.0 anyway

Just as 2.0 turned out to be nothing more than 1.6 in my opinion.

So honestly, I'm glad OpenGL 1.8 specs are released now - they're nice. But I'm still waiting for the OpenGL 2.0 I dream about for a few years now...
What are going to call the version of OpenGL that will introduce new object model? 4.0? It's a major change, right? So when do we get it? After OpenGL 3.1? Yeah, 1.5->2.0->2.1->3.0->3.1->4.0->4.1?
But I guess it will be no sooner than 5.0 - they're probably going to waste 4.0 on promoting some extensions to core.

So now I'm not waiting for 3.1, 4.0 nor 5.0, because I expect them to be nothing more than just another updates to OpenGL 1.0.


What I'm waiting for now is "OpenGL 2 1.0".
Let me know when it's ready - not a day sooner.

Don't get me wrong - I love OpenGL. I guess I'm just broken-hearted right now.

[k_szczech]

Creativity out of frustration. Here goes:

http://ks-media.ehost.pl/opengl_org/DilbertOpenGL01.jpg

http://ks-media.ehost.pl/opengl_org/DilbertOpenGL02.jpg

;)

[Korval]

Oh my God, it's like these were written while watching the ARB in "action". Or perhaps that's "inaction."

It's funny because it's true.

[k_szczech]

Oh my God, it's like these were written while watching the ARB in "action"

They were. I made these today (just by replacing text in original stories). Just as I wrote above - it was creativity out of frustration ;)