PDA

View Full Version : The ARB announced OpenGL 3.0 and GLSL 1.30 today



Pages : 1 2 [3]

Rob Barris
08-27-2008, 06:12 PM
The only "must" they have in their future is Starcraft II.

When did Blizzard say SC2 would be GL3.0? I would think that it would be too risky to develop for an API that won't even have any official drivers out from anyone for months, much less drivers from all major players.

There's no such statement. Korval has mis-spoken here.

Rob Barris
08-27-2008, 06:15 PM
When did Blizzard say SC2 would be GL3.0?

When ATi announced GL 3.0 support.


Korval, this isn't accurate, though I would be curious where you saw this stated.

Korval
08-27-2008, 07:09 PM
Korval, this isn't accurate, though I would be curious where you saw this stated.

I didn't see it stated; I'm making a (to my mind, quite reasonable) assumption based on the available data. To whit:

1: ATi announces GL 3.0 support in Q1 next year.
2: ATi and Blizzard announce some vague cooperation with regard to Blizzard's games.
3: SC2's earliest (reasonable) release date would be sometime Q1 of next year.

I mean, I don't see it as much of a stretch to say that SC2 will provide GL 3.0 support. I mean, I could be wrong (you'd know better than I), but all the available facts suggest it.

obirsoy
08-27-2008, 08:08 PM
*_redist is the redistributable files you can distribute with your DX application. It is not the SDK.

You have to download DXSDK_Aug08.exe (http://www.microsoft.com/downloads/details.aspx?FamilyID=ea4894b5-e98d-44f6-842d-e32147237638&DisplayLang=en).

Rob Barris
08-27-2008, 09:31 PM
Korval, this isn't accurate, though I would be curious where you saw this stated.

I didn't see it stated; I'm making a (to my mind, quite reasonable) assumption based on the available data. To whit:

1: ATi announces GL 3.0 support in Q1 next year.
2: ATi and Blizzard announce some vague cooperation with regard to Blizzard's games.
3: SC2's earliest (reasonable) release date would be sometime Q1 of next year.

I mean, I don't see it as much of a stretch to say that SC2 will provide GL 3.0 support. I mean, I could be wrong (you'd know better than I), but all the available facts suggest it.

I think this is a fine post, it makes it clear that you are only attempting to "connect the dots" with casual speculation. That's very different from "this was stated".

Mars_999
08-27-2008, 10:19 PM
IMO SC2 will not need GL3.0, why Blizzard doesn't make their games run on current top of the line hardware, as GL3 would need. I can see GL2.0 though! ;)

Blizzards games are fun, and have really great storylines, along with the Best CG cut scenes, NOBODY does cut scenes like BLizzard and that is one reason I buy them, just to see them. Hell Diablo2 when Tyrael fights with Diablo's brothers is just badass. Not including all the SC, Warcraft movies. I would like to see GL3.0 features in SC2, but in reality there isn't a huge need for it this time around. Now SC3, I would expect it. :)

bobvodka
08-28-2008, 04:12 AM
For example, FBO support for binding framebuffers of different formats and bit depths.

1: That should have been in FBO since day 1 (or at least not making it an incompleteness, so implementations could do it themselves). It was literally the first thing people said after reading the EXT_FBO spec. So the ARB was just being stupid then.


For the record, you've been able to do this with NV hardware for some time with a NVX extension.

Timothy Farrar
08-28-2008, 08:25 AM
For the record, you've been able to do this with NV hardware for some time with a NVX extension.

I wasn't aware of that. Which NV_ extension?

bobvodka
08-28-2008, 08:43 AM
Ah, my bad, it was infact GL_EXTX_framebuffer_mixed_formats; technically an experimental extension but it allowed the functionality to work on my 8800GT card in Vista.

bertgp
08-28-2008, 08:52 AM
I didn't see it stated; I'm making a (to my mind, quite reasonable) assumption based on the available data. To whit:

1: ATi announces GL 3.0 support in Q1 next year.
2: ATi and Blizzard announce some vague cooperation with regard to Blizzard's games.
3: SC2's earliest (reasonable) release date would be sometime Q1 of next year.

I mean, I don't see it as much of a stretch to say that SC2 will provide GL 3.0 support. I mean, I could be wrong (you'd know better than I), but all the available facts suggest it.

This Siggraph presentation (http://ati.amd.com/developer/SIGGRAPH08%5CSiggraph2008-Advances_in_Real-Time_Rendering_Course.pdf) from Blizzard states :


For Starcraft II, we wanted to maximize compatibility with less capable systems to ensure hassle-free game play for as broad a player base as possible. Yet we also wanted to utilize the full potential of any available hardware to ensure the games looks were competitive. This meant supporting a wide range of hardware, from ATI RadeonTM 9800/NVIDIA GeForceTM FXs to the ATI RadeonTM HD 4800s and NVIDIA GeForceTM G200s, targeting maximum utilization on each different GPU platform.


This range of hardware support clearly matches the targeted GL 3.0 capable platforms. That's even more evidence to Korval's deduction...

Brolingstanz
08-28-2008, 08:54 AM
Funny, I seem to recall that being an NV extension too. Easy mistake to make with that dizzying blizzard of NV_*s in the extension string, some 42 in total by my weary-eyed estimates.

Rob Barris
08-28-2008, 10:08 AM
I didn't see it stated; I'm making a (to my mind, quite reasonable) assumption based on the available data. To whit:

1: ATi announces GL 3.0 support in Q1 next year.
2: ATi and Blizzard announce some vague cooperation with regard to Blizzard's games.
3: SC2's earliest (reasonable) release date would be sometime Q1 of next year.

I mean, I don't see it as much of a stretch to say that SC2 will provide GL 3.0 support. I mean, I could be wrong (you'd know better than I), but all the available facts suggest it.

This Siggraph presentation (http://ati.amd.com/developer/SIGGRAPH08%5CSiggraph2008-Advances_in_Real-Time_Rendering_Course.pdf) from Blizzard states :


For Starcraft II, we wanted to maximize compatibility with less capable systems to ensure hassle-free game play for as broad a player base as possible. Yet we also wanted to utilize the full potential of any available hardware to ensure the games looks were competitive. This meant supporting a wide range of hardware, from ATI RadeonTM 9800/NVIDIA GeForceTM FXs to the ATI RadeonTM HD 4800s and NVIDIA GeForceTM G200s, targeting maximum utilization on each different GPU platform.


This range of hardware support clearly matches the targeted GL 3.0 capable platforms. That's even more evidence to Korval's deduction...

Actually not, since Radeon 9800 and GeForce FX are not GL 3.0 capable.

Brolingstanz
08-28-2008, 11:42 AM
Perhaps that's just a bit of wishful thinking on Korval's part. A big game release touting GL3 in its trailer couldn't hurt things for GL. If Id software follows suit with a big release of their own, leaping lizards... I expect we'd see quality drivers toot sweet (maybe that's just wishful thinking on my part).

bobvodka
08-28-2008, 12:04 PM
Well, no, more likely we'll be back in the Quake days of "it'll be fast provided you do what Blizzard or iD are doing'.

Not that it matters much as iD are pretty much going to be using GL2.x (or maybe less, and JC wasn't happy with what happened with GL either) and Rob's comments indicate that Blizzard will be using GL2.x as well so there is no pressure for anyone to produce quality GL3.0 drivers anyway.

PaladinOfKaos
08-28-2008, 12:16 PM
NVIDIA has a certain incentive to make quality drivers. All that data being crunched through Tesla cards needs to be visualized somehow. DX is seen as being for games, so I expect that a lot of the visualization code is written in OpenGL.

Of course, OpenGL is the only solution to visualize that data on Linux. I don't know any usage statistics for Linux/Windows in visualization applications.

Seth Hoffert
08-28-2008, 12:31 PM
Seeing as D3D10 is a general 3D API, I personally don't see anything wrong with using it for visualization (especially on consumer-level cards) as long as you don't need quad buffers.

EDIT: Of course, there is the benefit of more code/support for using OpenGL for vis... dang, now I'm unsure again.

knackered
08-28-2008, 01:00 PM
leaping lizards?

Brolingstanz
08-28-2008, 01:18 PM
crazier than a spit-house rat (only I don't mean spit).

God help me I do love a good colloquialism.

Seth Hoffert
08-28-2008, 01:41 PM
Nice signature, modus. ;)

Brolingstanz
08-28-2008, 01:49 PM
thanks. I really think a bumper sticker would sell like hot-cakes in the arctic.

Korval
08-28-2008, 02:01 PM
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.

Michael Gold
08-29-2008, 01:26 AM
Not that it matters much as iD are pretty much going to be using GL2.x (or maybe less, and JC wasn't happy with what happened with GL either) and Rob's comments indicate that Blizzard will be using GL2.x as well so there is no pressure for anyone to produce quality GL3.0 drivers anyway.

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.

knackered
08-29-2008, 09:57 AM
if you build it they will come.
except intel.

pudman
08-29-2008, 02:14 PM
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.

knackered
08-29-2008, 06:10 PM
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).

Rubens BR
09-01-2008, 05:12 PM
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 its a hell too!!!
We cant ensure that samples, tutorials,.. can run anywhere...

Brolingstanz
09-01-2008, 08:59 PM
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.

knackered
09-02-2008, 01:27 AM
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.

Brolingstanz
09-02-2008, 01:54 AM
(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.)

Warshade
09-02-2008, 01:46 PM
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 ;)

ScottManDeath
09-02-2008, 02:15 PM
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.

Rob Barris
09-02-2008, 04:10 PM
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.

ScottManDeath
09-02-2008, 05:03 PM
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. (http://developer.download.nvidia.com/SDK/10.5/direct3d/samples.html#StencilRoutedKBuffer)

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.

Lord crc
09-02-2008, 05:45 PM
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.

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.

Korval
09-02-2008, 06:27 PM
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).

Brolingstanz
09-02-2008, 09:55 PM
One FBO per render target vs. one FBO and then rebinding the render targets. Having multiple rendertargets increases that combination also.

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.)

Leadwerks
09-02-2008, 10:00 PM
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.

Michael Gold
09-02-2008, 11:14 PM
I can't imagine that there would be significant perf advantages to having more than 1 FBO on current hardware
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.

Korval
09-02-2008, 11:59 PM
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.

Leadwerks
09-03-2008, 12:18 AM
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.

Brolingstanz
09-03-2008, 12:41 AM
It's one thing to decide to change strategy; it's quite another to not tell anyone about it for 8 months.

What are the alternatives?

1. Listen to 8 months of protracted ballyhoo and brouhaha
2. Listen to 8 months of accumulated ballyhoo and brouhaha

I'd choose the latter too. Besides, suffering community criticism during the development phase would likely have been a pointless distraction.

bobvodka
09-03-2008, 03:05 AM
If you look at a fair amount of the 'ballyhoo and brouhaha' going on it's about the fact that things were changed back in Jan and no one said anything thus pissing off everyone because of the lack of feedback and community involvement, something they had previously prasied themselves for.

If, back in Jan, someone had said "look guys we can't do this because of x,y,z so the plan going forward is...", then sure you would have got some annoyance due to the lack of new API but at the same time there wouldn't be quite this feeling of 'oh, the ARB have done it AGAIN'. Indeed, from that point going forward they could have again engaged the community with regards to the new direction and what priorities we would have had.

It's the 10 months of silence, with 8 months of a new plan, which has caused the bigger problem; everything else just steams from there.

CatDog
09-03-2008, 03:28 AM
And what's happening now is that every time an ARB member comes here to discuss or explain some technical issues, the discussion immediately turns to ballyhoo and brouhaha again. "Ouch, the silence still hurts. ARB, I don't love you anymore. What did you say?"


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.
[..] 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.
Cut this out and paste it somewhere, so that people will read it when they try to use it! It's just like that old nVidia VBO white paper (http://developer.nvidia.com/attach/6427) from 2003. There was written how you should do it. The API provides several ways to do things, which is fine sometimes, but it doesn't assess them. There's always one best way, and describing this best way should be part of the documentation.

It's not that this valuable information isn't there. But it's scattered around the whole web, in forums, IHV papers, tutorials... it totally depends on coincidence, if you find it.

*edit* Oh, and maybe you like to comment on the wide lines issue (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Main=47863&Number=245046#Post245046)? ;)

CatDog

Leadwerks
09-03-2008, 09:24 AM
Sorry, I didn't realize my desire to be properly informed so I can make good business decisions was such a burden. I think I will use DX the next time around, since they don't seem to mind giving out information for developers.

Michael Gold
09-03-2008, 09:55 AM
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.

GL3 failed to instantly remove legacy features, but all is not lost. Bear in mind that no vendor was likely to drop support for 2.1 anytime soon, so that burden wouldn't have suddenly disappeared the moment Longs Peak shipped.

Here's how I believe the deprecation model can simplify a vendor's task over time. Deprecation is a clear warning to developers to stop using features which may be removed in the near future. As legacy features become less important to modern applications, vendors can provide backward compatibility through layering (or a separate driver) without as much concern for performance. Meanwhile new development efforts can be focused on the current feature set.

Considering that GL3+ shares a basic framework with GL2, this is actually *less* work for vendors than Longs Peak would have been.

Michael Gold
09-03-2008, 10:14 AM
The API provides several ways to do things, which is fine sometimes, but it doesn't assess them. There's always one best way, and describing this best way should be part of the documentation.
My vision for LP was to remove the "wrong choices" from the API so such documentation would be unnecessary. While deprecation addresses some of this (e.g. don't use feature X because its going away), mutable objects remain part of the spec. Some ARB members consider this a "feature" rather than a "bug", so documentation / performance hints remain important. But they also may be implementation-specific. Not all hardware supports the same basic constructs, which is why vendors often disagree on guidance.


*edit* Oh, and maybe you like to comment on the wide lines issue (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Main=47863&Number=245046#Post245046)? ;)
Well, my best suggestion is to firmly (but politely) lobby your favorite IHVs to retain support for any deprecated feature which you consider critical. No firm decisions have been made at this time regarding which of the deprecated features will actually be removed in any particular version of the GL, although its likely many/most will be removed in whatever comes next. And bear in mind that the ARB is a committee - majority rules - so make sure you lobby all the vendors, since we don't always agree. (See above comment about hardware differences.)

Michael Gold
09-03-2008, 10:26 AM
Sorry, I didn't realize my desire to be properly informed so I can make good business decisions was such a burden. I think I will use DX the next time around, since they don't seem to mind giving out information for developers.
For what its worth I will offer an apology for the silence. As you might imagine the decision to change directions was not without contention, and the ARB didn't want to say anything publically until the dust had settled, lest the message become even more confused. That said, something probably should have been said sooner. I'll throw the marketing folks under the bus here. :)

Please believe me when I say that the ARB is well aware of the community's displeasure about the news blackout. Continuing to pound the point home in every other post isn't going to change anything, but if it makes you feel better, carry on.

Korval
09-03-2008, 10:51 AM
Considering that GL3+ shares a basic framework with GL2, this is actually *less* work for vendors than Longs Peak would have been.

Yes, but it does nothing to change the fact that the drivers will still be just as unreliable as before. At least LP drivers would have been closer to the metal, thus removing a lot of chances for implementations to screw things up.


Here's how I believe the deprecation model can simplify a vendor's task over time.

Disregarding the question of how useful that is in practice, the fundamental problem is that this help was not what was asked for or promised. Or at least, not within the timeframe. See below.


No firm decisions have been made at this time regarding which of the deprecated features will actually be removed in any particular version of the GL

Which is the single most disconcerting thing about the whole "GL 3.0" process.

The ARB said they were rewriting the API a year ago. That didn't turn out. Now the ARB says that they'll be removing deprecated features. Eventually. Is there any reason to believe them now? Especially when they're being so equivocating about whether deprecated functionality will actually be removed?

The simple fact of the matter is this: implementations will continue to be unreliable until OpenGL is a reasonably implementable specification. When will that be? GL 3.1? GL 3.5? GL 4.0? How many years do we have to wait before reasonable people can trust their products to the vagaries of ATi's OpenGL implementation?

Michael, the fundamental question around all of this is this simple. If you're not Id or Blizzard (IHV's always test their drivers on their games), which would you bet the life and continued success of your company on: the quality of D3D implementations or OpenGL implementations? Can you honestly and truthfully say that you're willing to bet millions of dollars and the possibility of your company going bankrupt on the functionality of OpenGL implementations over D3D ones?

The fact that the answer to this question is "no" is why the only people who use OpenGL are those who have to, not those who want to. Carmack has this love affair with Linux, just as Blizzard does with MacOS. Until the answer to that question is yes, OpenGL will continue to suffer. LP had the potential to make that answer yes, but it didn't come to pass.

Leadwerks
09-03-2008, 11:09 AM
For what its worth I will offer an apology for the silence.
Thank you.

Michael Gold
09-03-2008, 11:21 AM
Korval,

There are plenty of commercial applications which depend on OpenGL. If this wasn't the case, no vendor would continue to support it, not even my employer. As imperfect as OpenGL may be, it solves problems that paying customers want solved.

If I personally had the ability to dictate the direction of the ARB, we'd be having a much different conversation right now. But I don't - I'm just one individual associated with one vendor. I share a lot of the frustration being expressed on this forum, but some of the comments being made here are so ridiculous, so over the top, that I feel compelled to defend a decision which I personally did not support.

Is GL3 what we wanted? Opinions vary, but its clearly not what many of us wanted, at least the most vocal among us. Was it handled well? Probably not - the ARB telegraphed one direction and then shifted in another without informing the community. Is it the end of the world? Again, opinions will vary. I would say no - there are some nice additions to the core, and there is still a path forward which could lead to something resembling LP in design.

Even if I could predict with 99% certainty which direction the ARB will go, I see the folly in making promises when I cannot control the outcome. If you feel that OpenGL is not for you, you need to do what's right for you. But I'm not interested in a protracted debate. I'm going to continue to write drivers and attempt to influence the ARB in a positive direction. What you choose to do is your own business.

My goal here is to lend some sanity to the discussion. I suppose its inevitable that I will become a lightning rod for criticism.

ScottManDeath
09-03-2008, 12:00 PM
I appreciate the new ClearBuffer API :) At least something that I can't do on GL2.x even with extensions.

knackered
09-03-2008, 12:14 PM
Thanks for the apology. Thanks for being honest too - we could do with more of that from the ARB.

CatDog
09-03-2008, 02:08 PM
Not all hardware supports the same basic constructs, which is why vendors often disagree on guidance.
Which then leads to no guidance at all? From my point of view, this is the most annoying thing about OpenGL today. Five years ago, there was the excellent Red Book. Hardware didn't change that quickly theses days, so that good old Red Book was all you needed to write good OpenGL applications. Nowadays hardware is less abstracted. So I'd really appreciate all efforts of the ARB to find a place where vendor specific information is condensed.

Also, I'd like to know, what you guys are breeding about for the future. Rob talks about a long list of things to do. Would you mind to share this list with us? I'm explicitly not asking for *promises* here. I'm just asking for your plans!

This leads to your statement about lobbying ARB members. How can I successfully express my wishes when I don't know what you are currently discussing and (most important) whom to speak to? Take the wide lines as an examples. From my user perspective, I can only guess *why* glLineWidth now fails for values > 1. Guesswork isn't the best foundation for building a solid opinion about a specific topic.

CatDog

Michael Gold
09-03-2008, 02:48 PM
The fact that different vendors may disagree on optimal paths is hardly specific to OpenGL. There are some common sense optimization tricks which should work well on most implementations. The ecosystem group intends to offer generic guidance but realistically vendor specific information can only come from the vendors.

In general terms I would expect the next version to roll more functionality into core (see the current list of ARB extensions) and some of the deprecated functionality will probably be removed. I know this is fairly obvious but I really can't be more specific than that.

Topics for lobbying include anything you consider important. Don't want a deprecated feature to be removed? Speak up! Need an extension promoted to the core? Speak up! Need a new mechanism which doesn't yet exist? Speak up!

I don't imagine wide lines will fail for any GL3 implementation which supported wide lines on 2.1. The reason for deprecation? Likely one or more vendors simply don't have the hardware support for it and don't want to emulate it anymore. As I said, not all vendors agree on the deprecation list.

CatDog
09-03-2008, 03:01 PM
Thanks for your answers!

What is the proper way to "Speak up!" (and getting the warm feeling of having been heard)?

And if "one or more vendors simply don't have the hardware support for it and don't want to emulate it" is true, then I really like to know which vendors are going to drop support for that feature! Or at least, which one will continue supporting it as core extension. Some of us have the ability to "recommend" hardware to their users, you know...

CatDog

Warshade
09-03-2008, 03:08 PM
Please do not misunderstand my previous post as a complaint, the intent was neither to pour salt into the wound, nor to find a scapegoat. My point was that people would have probably taken it more lightly if there was an announcement in February stating "Long Peaks has been aborted due to difficulties that need serious investigation before continuing the effort. Due to the desire for DirectX 10 level functionality, OpenGL 2.1 will be continued for now." for example. Every seasoned programmer knows that you have to support the mistakes you make and that something like LP - that was intended to last for years - should not contain rushed, severe design flaws. GL3 is an improvement and it was definitely a sane decision to do this, instead of releasing an immature LP.

I resisted the urge to voice my disappointment around Siggraph to get a better picture of GL3 first, thus the delay. Due to the silence around LP and the rumors about a NDC I expected some great and clever hacks that would kick Microsoft's solution hard between the legs ;)

@Korval: Do not take it as offense, but have you actually tried working together with IHVs to solve the difficulties you mention? Sounds a bit like a prejudice that they wouldn't care if your company isn't id or Blizzard.

ebray99
09-03-2008, 04:44 PM
For what it's worth, I'd personally like to state that I'm satisfied with the direction OpenGL is going. Admittedly, satisfied is not necessarily "totally happy with", but in my opinion, OpenGL 3.0 is an acceptable first step.

On one hand, I really like the idea of a brand new API. On the other hand, the idea of an untested API is a pretty big concern for me. When I heard that LP would be a complete departure from the current API, I expected that I'd have to write and maintain two separate rendering paths: one for OpenGL 2.1 and one for OpenGL 3.0. Of course, I could have just ported everything to OpenGL 3.0, but to do so would have been somewhat risky. In short, while I like the idea of a total refresh, I think I personally benefit more from the incremental approach that's being taken.

Also, as much as people complain about OpenGL 2.1 and drivers, my personal experience with them has been fairly smooth sailing. As a general rule, I try to do as little with the API as possible... I pre-allocate resources, I keep usage patterns extremely simple, and I try to keep my resource counts to reasonable numbers. That said, perhaps I'm just not hitting the buggy paths that I hear so much about. I can honestly say that I've found OpenGL drivers to be just as stable as D3D9 drivers.

Kevin B

Michael Gold
09-03-2008, 04:51 PM
CatDog -

Its a good question - Honestly I'm not sure the best mechanism to ensure you are "heard" by the right people. I was going to suggest developer support but their focus is different. Let me get back to you on this one. (Some ARB members read here but the signal-to-noise ratio has been lacking of late.)

Again, the ARB cannot be expected to provide vendor-specific information. I can state that, in the case of wide lines, NVIDIA hardware has supported this feature for a long time and will for the foreseeable future. Hence we're likely to continue supporting this if/when the ARB officially removes it.

cass
09-03-2008, 10:32 PM
Agreed that the signal-to-noise has been a little lower than normal since SIGGRAPH, but it's going up. Also I think a lot of ARB members read posts here, though from the frequency of their posts they could do better at making that clear.

And from my experience, posting here is a good way to get heard. But you have to be careful that your personal s/n is high. I have always cherry-picked what I read here based on members who offer useful insights and communicate clearly. It takes some time to develop that kind of reputation.

CatDog
09-04-2008, 03:17 AM
Since I'm getting heard at the moment, I'd like to speak up and make a suggestion concerning this forum. A simple first step for solving the feedback problem is to tag ARB representatives as such. For example replace Michaels "Regular Contributor" by "ARB - nVidia". Same for other active ARB representatives of course.

This would have several (mostly psychological) effects. First of all, it would express the ARBs will to officially communicate - this would be an important signal I think. Novices searching the forum will be able to separate ARB statements. Information given away by individual representatives can be thought of as vendor specific without explicitely mentioning it. Finally, this may add pressure to communicate for those vendors, that have been very quite in the past... but of course, each member/vendor would be free to attend to this kind of "PR".

(*edit* Of course those members have to agree to this before replacing their titles!)

Well, I hope this isn't too naive thinking and I don't make a fool of myself with this suggestion.

CatDog

cass
09-04-2008, 06:42 AM
This is a tricky thing. If you are officially acknowledged as a representative of your company or the Khronos OpenGL ARB WG more people want to be involved in what you say and how you say it.

Keeping the forums informal is the best way to keep information flowing and to get an idea of what individuals really think. In the end, I'd rather hear from the individual than get the party line from Khronos or a member company.

To that end, I would hope that Khronos, AMD, NVIDIA, Apple, etc would encourage open discussions. They don't commit anybody to any course, but they would allow developers to follow the logic of the current directions and to be more involved in the process by way of voicing concerns or making suggestions.

We still need regular official information dumps though - via newsletters and (even more desirable) meeting minutes that don't have all the interesting bits redacted.

CatDog
09-04-2008, 07:40 AM
To that end, I would hope that Khronos, AMD, NVIDIA, Apple, etc would encourage open discussions.
That's my wish, too. And I'm aware of the implications of this suggestion. But the point is, that I really want to speak to officials. It's fine to have informal discussions and I don't see why officials wouldn't be allowed to state their personal opinions.

To be honest, I'm currently checking if staying with OpenGL is a wise descision. From a technical point of view there's little concern. Despite some minor issues, GL3 looks good to me. It has introduced a feature that can bring a new level of "vitality" to the API: the deprecation model. But this feature heavily relies on discussion. See above, Rob and Michael are asking for feedback. That's good, but it looks like their efforts are based on personal commitment. Bringing the conversation to a more official level would possibly force some other ARB members to openly express their intentions. Which then would lead to some open discussion. Maybe. Wishful thinking?

CatDog

Timothy Farrar
09-04-2008, 08:59 AM
I can't imagine that there would be significant perf advantages to having more than 1 FBO on current hardware, not having tested.

Could having multiple FBOs could possibly provide a performance advantage if the FBO objects were left static after creation? Presumably the driver could have a compiled copy of the command buffer commands required to setup the FBO render state for future draw calls (effectively the point of immutable objects). Should also reduce the amount of error checking. Also if the hardware has multiple sets of hardware frame buffer states, using multiple FBOs might allow the driver to better match logical FBOs to those hardware states?

Michael Gold
09-04-2008, 09:12 AM
Probably wishful thinking.

If you really want to be heard you are encouraged to join Khronos - even at the non-voting level you may participate in the debate and may influence the outcome. We really could use more ISV participation - there are a few now but increasing that number would increase the likelihood of a "representative sample".

As for tagging myself as an ARB representative - I think it would discourage me from posting, as I'm not authorized to speak on behalf of the group. Most people here know who I am, and I try to make clear from context when I am stating ARB policy and when I am stating personal opinion. I walk a fine line.

Michael Gold
09-04-2008, 09:22 AM
Could having multiple FBOs could possibly provide a performance advantage if the FBO objects were left static after creation? Presumably the driver could have a compiled copy of the command buffer commands required to setup the FBO render state for future draw calls (effectively the point of immutable objects). Should also reduce the amount of error checking. Also if the hardware has multiple sets of hardware frame buffer states, using multiple FBOs might allow the driver to better match logical FBOs to those hardware states?

In theory, keeping the FBO static can help. Unfortunately textures are mutable, so the implementation may need to check if any attached objects are dirty even if the container (FBO) itself is not. Worse, the spec is unclear when a change to e.g. a texture format becomes visible to a consumer of this object (think shared objects and async changes in another thread). This is why I continue to push for immutability - it eliminates this entire class of problems.

All else being equal, you're still better off leaving the FBO state static after setup.

ScottManDeath
09-04-2008, 11:37 AM
Since quite a few ARB members (e.g Rob, Michael or Cass) are reading and asking for input, why not centralizing this? Having a thread where both ARB people can ask questions (such as do you really want to have wide lines in GL3.x?), as well as developers (Gimme multi sampled textures already)

This thread would be updated maybe once a month or so by ARB members posting what the general impression of the ARB was with respect to feature this or rant that.

This way, it is not really formal such as meeting notes or newsletters, but would still allow some information flow in both directions.

However it would be important that this thread gets updated regularly and maintained properly, e.g. by creating a new one every month/quarter/whenever something happened.

Currently, people are asking questions and get answers spread all over the place.

A good start would be the list of possibly deprecated list of features gone in the next revision (Rob mentioned something like that in another thread). So posting this list, even if it is just for discussion, without any guarantees whatsoever would feel the pack at ease and give the ARB some input.

Korval
09-04-2008, 11:58 AM
Having a thread where both ARB people can ask questions (such as do you really want to have wide lines in GL3.x?), as well as developers (Gimme multi sampled textures already)

The thing is, we have an entire forum dedicated to the possibility of that. If the ARB wanted to solicit advice from users, they could just create a thread in the "Suggestions for the next release of OpenGL" forum, and we'll respond.

We don't need a special thread for it. Besides, having everything in one thread is confusing.

CatDog
09-04-2008, 02:34 PM
The thing is, we have an entire forum dedicated to the possibility of that.
That's true.

Michael, it's somewhat confusing me, that ARB members don't want to appear as ARB members in their own forum. I can't suppress the feeling, that you're still far from consensus. Well, I'd better shut up, because obviously I don't have a clue what's going on behind the scenes.

CatDog

zed
09-04-2008, 04:17 PM
Whats wrong with what I suggested earlier,
once a month someone on the ARB eg Rob Barris, Michael Gold or whoever starts a topic here titled 'October 2008' and just summarizes whats happened over the last month.
Ok I can see arguments against this as its not the ARB sanctioned gospel, but perhaps the post can start with a disclaimer stating this.

Brolingstanz
09-05-2008, 12:15 AM
To ARB members, the prospect of ongoing obligations in community service is probably not an appealing one. That's just more work for them in the spotlight of public scrutiny (put yourself in their shoes). Leaving things on an opt-in basis seems fair to me.

I'd sure like to see the newsletter press reopened.

Timothy Farrar
09-05-2008, 09:02 AM
So as for GL 3.1 what can we expect? My predictions (/wild speculation),

(1.) Some time 2009, perhaps late Q1?

(2.) Working NVidia, and ATI GL3 drivers. Apple perhaps with Snow Leopard in January (10.6 going to have OpenCL right?). Intel perhaps not because of Larrabee not being out yet.

(3.) Geometry shaders, texture buffer objects, and instancing extensions get rolled into the core spec.

(4.) Uniform (parameter) buffer objects as an extension. Question as to if this functionality gets supported on older hardware which need to patch shaders after uniform changes.

(5.) Unlikely, but perhaps something to do with texture fetch from multisample textures. Maybe only a vendor extension.

Other things I would personally like to see in GL.

(1.) Roll in fence support (NV_fence/APPLE_fence) into the core spec.

(2.) Support for fences to be shared across contexts!

(3.) Would be nice to have support for keeping a buffer mapped with MapBufferRange( .. MAP_UNSYNCHRONIZED_BIT .. ) mapped during drawing. So one could keep filling in dynamic VBO ring buffers from other threads easily.

(4.) Would be nice to have support for MapBufferRange( .. MAP_UNSYNCHRONIZED_BIT + MAP READ BIT .. ) with the same functionality of being mapped during drawing. Combined this in the form of a readback ring buffer, with shared context fences and transform feedback, then GPU readback could become a lot more useful.

Rob Barris
09-05-2008, 09:49 AM
The "mapped during drawing" thing is not very likely to happen. MapBufferRange was designed to work in at least two different ways in the underlying implementation for certain kinds of traffic.

So the first way is, the memory the CPU sees while mapped is memory that can be simultaneously observed by the GPU (i.e. GART/AGP mapped or PCIe DMA wired). And in a world like that, you *might* be able to make draw-while mapped work - as long as the draw call knows to flush CPU write caches so the shared RAM has the right bits in it.

But the second way, specifically in cases where the app has requested write-only with range or buffer invalidation, allows the driver to provide a piece of scratch memory that may have no residence in the actual buffer, as a destination for the writes.

The magic happens at FlushMappedBufferRange or unmap time - as long as the written bytes are transferred into the GPU visible buffer before the draw gets underway, all is well. This was set up in this fashion to accommodate systems where establishing DMA mappings fluidly to arbitrary pieces of system memory is cumbersome - it also allows for idioms where you are mapping tiny pieces of a huge buffer, the tiny pieces can be doled out from a ring buffer of scratch space and re-used over time with a fixed DMA mapping.

But in the second world, you have to have that flush or unmap event happen so the signal of when to transfer the newly written bytes is received by the driver. I suppose this raises the question of "well, would flushing of a range be sufficient on its own, without the actual unmap - turn unmap into a no-op"? - that one I don't have an immediate answer for.

I liked the rest of the list though !

Michael Gold
09-05-2008, 10:35 AM
Yes, its a decent list and probably not far off.

I'm thinking about the proposal of "flush as good as unmap". We've already gone past my comfort zone (that happened when we introduced the unsynchronized bit - you can blame/thank Rob for pushing hard for this feature), so its possible that we're no worse off with this proposal. The problem is historically developers don't get this kind of thing right, or they think they do and it breaks on a new driver or chip, forcing us to add heuristics to try to fix the broken app without slowing everyone else down. (In an ideal world the developer would just fix the app so the driver doesn't have to - but the PC space is less than ideal. In this day and age, if you ship a title without a self-patching mechanism, shame on you!)

The other problem with allowing an app to hold a mapping indefinitely is that it messes with memory management. We cannot relocate a buffer which is mapped.

Timothy Farrar
09-05-2008, 10:45 AM
I suppose this raises the question of "well, would flushing of a range be sufficient on its own, without the actual unmap - turn unmap into a no-op"? - that one I don't have an immediate answer for.

And this (using flush) is exactly what I had in mind. Map buffer. one thread draws using ring buffer, other thread(s) can write and flush into that buffer without the need to be concerned with needing an unmap at any point where the primary thread is issuing draw calls. Of course the mapped buffer would also have to be shared across contexts.

Timothy Farrar
09-05-2008, 01:30 PM
One thing we would possibly get with this functionality is easier porting of stuff we do on consoles to the PC/Mac.


The other problem with allowing an app to hold a mapping indefinitely is that it messes with memory management. We cannot relocate a buffer which is mapped.

It would certainly complicate memory management. I'd guess (with no knowledge of the XP or Vista driver model), that the user side mapping shouldn't be a tremendous problem in itself, assuming the driver can change the page table physical mapping (for a fixed user space address) when it needs to move stuff around (say when user changes primary display resolution). In the worst case, ie the driver is out of usable memory (which should never happen, but needs to not crash in case of), perhaps the driver could map all the previously mapped user space pages to a single common junk physical page and then return error later on a modified version of FlushMappedBufferRange().

Eric Lengyel
09-05-2008, 02:25 PM
Don't want a deprecated feature to be removed? Speak up!

While I agree with the decision to deprecate almost everything on the list in Appendix E, there were a few items whose removal didn't make sense to me: quads, alpha test, and the luminance / luminance-alpha / intensity internal formats. I'll try to explain why it's good to have each of these around.

1) Quads. I use these a lot for particle systems, fire, and other special effects where you end up rendering a bunch of disjoint quads that have their vertex positions recalculated every frame. It just makes sense to dump the four corners of each quad into a buffer and let the hardware render them as quads. Quads are supported in hardware by all Nvidia chips and all recent ATI chips. If quads go away, then I have to either (a) dump six vertices into the vertex buffer for each quad instead of four, or (b) construct an index buffer in addition to the vertex buffer that wasn't necessary before. In both cases, we lose speed and increase memory requirements.

2) Alpha test. This one isn't a huge deal, but why should we have to add a texkill instruction to our fragment programs when all hardware already supports a separate alpha test that doesn't eat up an extra cycle in the fragment processor? Taking away alpha test just slows alpha-tested rendering down a little bit without simplifying the driver in any significant way.

3) L / LA / I internal formats. I have found these formats to be very convenient, and I know that they are supported in all modern hardware through a programmable swizzle/crossbar in the texture units. Consider the following scenario: you're using a fragment shader that reads an RGB color from a texture map. Now you want to change the texture map (perhaps in the middle of a game) while using the same exact shader, but the new texture map is grayscale, so you decided to store it in a single-channel format to save space. If you load it into GL as a luminance texture, then the shader continues to work correctly without modification because the texture unit distributes the single channel to all three RGB channels for free. If you take away the luminance-based formats, then you're forced to build a completely different shader for the single-channel case. This creates an extra hassle for the software developer without really simplifying the driver at all. (Setting the texture units swizzle register is dirt simple.)

I noticed that all three of these items represent features that are not supported in DirectX 10. Were they deprecated just to achieve some kind of feature parity between the two libraries?

Seth Hoffert
09-05-2008, 02:30 PM
Why not just use a triangle strip with 4 vertices instead of a quad?

EDIT: I suppose you'd need glMultiDrawArrays or glMultiDrawElements, nevermind...

I was also going to mention the geometry shader, but that isn't core.

Korval
09-05-2008, 02:34 PM
you can blame/thank Rob for pushing hard for this feature

Thanks, Rob ;) Though I wish you could have gotten them to approve the Fences necessary to guarantee safety...

Michael Gold
09-05-2008, 02:36 PM
I'd guess (with no knowledge of the XP or Vista driver model), that the user side mapping shouldn't be a tremendous problem in itself, assuming the driver can change the page table physical mapping (for a fixed user space address) when it needs to move stuff around (say when user changes primary display resolution).

In order to do this reliably, moving the data and remapping the PTEs need to happen atomically. I don't see a way to do this for arbitrarily large buffers.

Korval
09-05-2008, 02:38 PM
If quads go away, then I have to either (a) dump six vertices into the vertex buffer for each quad instead of four, or (b) construct an index buffer in addition to the vertex buffer that wasn't necessary before. In both cases, we lose speed and increase memory requirements.

Unless the hardware can't actually support it anymore and thus emulates it.


I noticed that all three of these items represent features that are not supported in DirectX 10. Were they deprecated just to achieve some kind of feature parity between the two libraries?

Not so much feature parity but driver parity. Each step away from the low-level is another step away from making drivers easy to write.

Rob Barris
09-05-2008, 02:41 PM
You can guarantee safety without fences, if you constrain your access patterns to use a "write once" model - write batches using an ascending cursor/offset, and orphan the buffer once you hit the end (glBufferData(..., NULL)) - at which point you wind the cursor back to zero and proceed again. This lets you pack many disjoint variable sized batches of data into one healthy sized VBO without any un needed blocking/waiting.

If you have repeated partial update needs then you have to use something like an explicit fence + unsynchronized, or just go back to BufferSubData. The value of MapBufferRange combined with fences is higher if you have many more things crammed into the buffer object.

Gauss
09-05-2008, 04:13 PM
It seems that AreTexturesResident() and PrioritizeTextures() are on the depreciated list.

I wonder why this is the case, possible explanations i see are:
- textures are always resident in the future. When i try to allocate a new texture and it does not fit onto the GPU an out of memory error is created
- there will come a memory management extension that will allow to achieve same functionality on your own
- it will go away with simply no way to achieve similar functionality

Or did i miss something here, since no one else seems to complain this could also be true :)

arekkusu
09-05-2008, 07:31 PM
Don't want a deprecated feature to be removed? Speak up!

I don't understand the rationale behind deprecating CLAMP_TO_BORDER and the constant border color.

I completely understand deprecating textures with borders... but the constant border color?

Michael Gold
09-06-2008, 09:17 AM
CLAMP_TO_BORDER and TEXTURE_BORDER_COLOR are not deprecated. This was a spec bug which will be corrected in an updated 3.0 spec.

tamlin
09-06-2008, 12:35 PM
In order to do this reliably, moving the data and remapping the PTEs need to happen atomically. I don't see a way to do this for arbitrarily large buffers.
I agree, but I'd also throw in the sabot of SMP systems. As I see it, it would require lock, effectively "starve" every CPU, switch, and finally flush. AFAICT that would be both a performance and logistic disaster (waiting to happen).

So instead of this, can we try to find alternatives? Could a model where the actual mapping is abstracted from the app work? I'm just brainstorming a bit now...

Imagine a "multimapped" (just invented word) buffer, where the user instead of using it as a ring buffer (as suggested previously) that would have quite serious implications wrt page- and mapping-granularity get two (or more, as requested by the client) memory areas to play with - but using a single mapping (section). Each of them would only be ("legally") usable by the server after an "unmap" call (that wouldn't be a heavy unmap at all, but simply a synchronization flush and possibly an additional revocation of writable on the memory). Then the client could continue write data in another of the "segments" it got, while the server could process the previous data confident it's not modified under its feet.

Again, I was just brainstorming. I don't know how much it could save in time (if it's at all feasible), but at least it could, if possible, allow a single mapping (kmode<->umode) to be "reused" and effectively persistemt (from the client's POV).

But then, if the system changed screen setup and the physical VRAM got reallocated/invalidated... Damn, but I still think it was a possibly neat idea. :)

Timothy Farrar
09-07-2008, 07:15 PM
You can guarantee safety without fences, if you constrain your access patterns to use a "write once" model - write batches using an ascending cursor/offset, and orphan the buffer once you hit the end (glBufferData(..., NULL)) - at which point you wind the cursor back to zero and proceed again. This lets you pack many disjoint variable sized batches of data into one healthy sized VBO without any un needed blocking/waiting.

I've thought about this issue some more this weekend, and think I might have found a better alternative when taking into consideration threading. And it turns out that it would NOT require my previous suggestion. With the ascending cursor scheme you have say a VBO which is allocated at a size which can hold at least 3 frames worth of dynamic geometry. This buffer must be unmapped to use for drawing, which I see as a problem for threading.

However what if one was to instead break this VBO into at least 3 (and perhaps more if necessary) separate VBOs and use the following scheme instead. Initialize all VBOs, and use MapBufferRange() to map the entire range of all VBOs using MAP_WRITE_BIT | MAP_INVALIDATE_BUFFER_BIT | MAP_FLUSH_EXPLICIT_BIT | MAP_UNSYNCHRONIZED_BIT. Then add these mapped VBOs to a FIFO queue. Draw frames using the following steps in the primary GL context thread,

1. When the first worker thread finishes working on the current frame, remove a new mapped VBO from the FIFO queue, and begin finished worker threads on the next frame. No delay is necessary because the VBOs in the FIFO are already mapped, worker threads can begin to insert new dynamic geometry into the next VBO regardless of what GL or the GPU is doing.

2. Block, or do something else and poll for completion, for all worker threads to complete for the current frame.

3. Use FlushMappedBufferRange() on the range(s) of the current VBO which got written by the worker threads. Then unmap the VBO.

4. Do all drawing for the frame.

5. Now remap the VBO using MapBufferRange() and the same access bits used in initialization. Add this mapped VBO back into the FIFO so that after another say 2 (or more if necessary) frames, it is used again.

Michael, seems to me that this model would provide the best performance for an application which wanted to generate dynamic geometry using multiple threads (at the expense of giving the driver less flexibility to move memory).

Is there a better way?

Rob Barris
09-08-2008, 10:21 AM
When you use the invalidate whole buffer bit, this is meant to detach/orphan the current storage so you do not need to do any of your own juggling of old buffers. You could be running 12 buffer-fulls ahead of the driver, the driver gets to keep track of which ones have actually been fully consumed and can make that storage available again for the next invalidated buffer. If the driver and hardware are infinitely fast, then you won't get that far ahead. If they are much slower, then at some point the driver will enforce command queue depth (or storage footprint) limiting and calls will start to take more time as perceived by the issuing thread.

Timothy Farrar
09-08-2008, 02:02 PM
When you use the invalidate whole buffer bit, this is meant to detach/orphan the current storage so you do not need to do any of your own juggling of old buffers. You could be running 12 buffer-fulls ahead of the driver, the driver gets to keep track of which ones have actually been fully consumed and can make that storage available again for the next invalidated buffer. If the driver and hardware are infinitely fast, then you won't get that far ahead. If they are much slower, then at some point the driver will enforce command queue depth (or storage footprint) limiting and calls will start to take more time as perceived by the issuing thread.


I should remove the invalidate bit and rely on only the unsynchronized bit instead?

Is my example a case of the programmer trying to outsmart the driver? One primary goal here is to try and force the driver to do nearly all buffer overhead at creation time instead of at map time. Also to try and force the driver to allocate VBOs together at one time to limit GPU memory fragmentation.

Also I should have noted in my previous post that one could modify the construct above to work in under a single frame delay by breaking up into many more than 3 subframes/VBO buffers.

Rob Barris
09-08-2008, 02:56 PM
Well that's an interesting question. If you can actually calculate the upper bounds output in terms of bytes per frame of data needing to be written, then you might be able to put something together where you never have to block.

However in a more general sense this is difficult to do (i.e. if you have no idea how much data will come down per frame) - unless you have fences. So usually you find out after a frame or two what the real demand is, so if the driver is managing orphaned buffers efficiently it should converge on a working set size that eliminates need for new allocations, and the application can remain oblivious to how many real buffers the driver had to juggle.

mfort
09-09-2008, 11:50 AM
Now something easier ...

Look at this function:


wglShareLists
The wglShareLists function enables multiple OpenGL rendering contexts to share a single display-list space.

Display lists are be gone in OpenGL 3.0+
Any plans to rename this function or to introduce a new one?
Imagine a newbie learning opengl 3.1. "Share what? Display lists? whats that?"

Korval
09-09-2008, 12:01 PM
Any plans to rename this function or to introduce a new one?

How could they? It's a core WGL function; WGL is owned and "maintained" by Microsoft.

The ARB instead has a parameter on wglCreateContext that says that you're sharing object spaces with another context.

mfort
09-09-2008, 01:11 PM
I dont know who "owns" glx/wglShareLists. But Yes, it is deprecated by extension WGL_ARB_create_context.
I still think this method is more "OpenGL" then "Microsoft" and probably implemented by IHV.

Probably this is the first time we have a deprecated WGL "core" function.

WGL is important, developers should know what not to use.
There is no OGL without WGL/GLX/AGL/... .

knackered
09-09-2008, 04:31 PM
Well it's been used to share all sorts of other things apart from display lists for a long time. Nobody complained too loudly then, why now?

mfort
09-09-2008, 10:50 PM
Because this function cannot be used in 3.0+ OpenGL. The function fails according to the docs. (effectively deprecated)

Korval
09-10-2008, 12:18 AM
mfort, what part of they can't do anything about it don't you understand?

Michael Gold
09-10-2008, 09:09 AM
The notion of changing a shareList after context creation is troubling. What happens to any objects which have been created between context creation and joining a shareList? No, setting the shareList for a context should happen as part of creation, not separately. GLX had it right, MS got it wrong and we're fixing it.

Hampel
09-11-2008, 02:12 AM
What does that mean? We use one rendering context for "normal" interactive viewing and for example for creating a "large scale" snapshot of the current scene we create an additional pbuffer and call shareLists() with the "normal" rendering context in order to reuse the already uploaded textures, VBOs, ... No problems with this yet. Will this scenario not be possible in the future then?

Brolingstanz
09-11-2008, 08:25 AM
Like, either you want to share resource between contexts or you don't. Seems like maybe wglCreateContextAttribs simplifies things a bit, in that this question is answered right up front - no changing your mind later on and throwing everything out of whack. I think we're all for anything that makes the driver writer's life a bit easier...

Michael Gold
09-11-2008, 11:00 AM
This should work fine Hampel. When you create the pbuffer context, add it to the share group during creation instead of separately later. Here's the problem we're trying to avoid:

Create and bind context A
create some objects (A)
Create and bind context B
create some objects (B)
Join context B to context A's shareList

There are two possibilities here. You can either fail the call to wglShareLists() since context B already has some objects, or you can implicitly delete all of B's objects since context B now shares a namespace with context A. You cannot merge the namespaces (e.g. both A and B may have a texture named "3").

In practice its a solved problem and not really a burden - but its messy and annoying, and WGL should have just followed the GLX model from day one.

knackered
09-12-2008, 10:56 AM
its messy and annoying
Like GL3, and you were part of its design. Those who are without sin, and all that.

bobvodka
09-12-2008, 01:00 PM
To be fair I get the impression from a couple of things posted in this thread that Michael was one of those who wanted the new API but were overruled by other considerations.

Korval
09-12-2008, 03:07 PM
To be fair I get the impression from a couple of things posted in this thread that Michael was one of those who wanted the new API but were overruled by other considerations.

By other people, you mean.

Personally, I appreciate that Michael went to bat for us. But the ARB's failures and continued refusal to provide a satisfactory explanation (oh, it was the CAD people. No, it wasn't the CAD people; regular GL was just stagnant for too long, etc) creates frustration. Particularly for someone like Knackered who has no choice but to use this API, and would have abandoned it long ago if certain functionality were available to its competitors.

The simple fact is that the ARB are poor stewards of the API; they have been for years. After two years and innumerable promises, seeing no progress being made to fix the implementation issues with OpenGL is going to create a lot of anger. The ARB as a whole needs to stop complaining about that anger, man up, and accept their responsibility in creating it.

knackered
09-12-2008, 09:04 PM
No individuals are accepting any responsibility, so when an ARB member, any ARB member, criticises another organisation for creating something messy the hypocrisy has to be noted. They're all hiding behind group responsibility, so they're all to blame, including individuals.
Was a bit of a cheap jibe though. Sorry.

dor00
09-18-2008, 12:07 PM
Interesting articles, but sad:( check the users point of view also.

http://www.tomshardware.com/reviews/opengl-directx,2019.html#
http://www.neowin.net/forum/index.php?showtopic=670942&st=0

V-man
09-18-2008, 05:17 PM
Interesting articles, but sad:( check the users point of view also.

http://www.tomshardware.com/reviews/opengl-directx,2019.html#
http://www.neowin.net/forum/index.php?showtopic=670942&st=0


User POV doesn't matter. A user just clicks your icon and runs your game.
A user should be more concerned about his OS.
The only interesting talk in the forums was from a Linux user saying that it should be easy to install software (ex : Opera).
Another user thinks that it is great that he can run games through WINE. It's too bad that you can't run everything through WINE. I've had little success. WINE is also a DX wrapper so there is probably a few % performance loss and errors, perhaps some shaders won't even translate correctly, etc. I find that offensive and I'm betting most user's as well.

dor00
09-18-2008, 10:55 PM
User POV doesn't matter. A user just clicks your icon and runs your game.
A user should be more concerned about his OS.


Actually user POV matter, they are choosing the OS:)

Rob Barris
09-20-2008, 03:24 PM
I started a thread where people could post some more details about their OpenGL applications and what needs they would like to see addressed in future spec releases and implementations. It's here in the suggestions forum and is titled simply "Talk about your applications."

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=246133

ScottManDeath
10-14-2008, 12:34 PM
What happened to the ARB_framebuffer_object extension spec. Wasn't is supposed to be released within 1 month after the 3.0 spec was released, since it was in the cool down period?

Given any useful GL documentation/programming guide, looking at extension specs is better than having nothing at all, since the specs at least contain a focused description of what one can with a specific feature.

Korval
10-14-2008, 01:27 PM
What happened to the ARB_framebuffer_object extension spec. Wasn't is supposed to be released within 1 month after the 3.0 spec was released, since it was in the cool down period?

The spec is right there on the extension registry page.

ScottManDeath
10-15-2008, 03:38 PM
Consider myself embarrased :eek: I was expecting it to appear on the end of the list, rather in the middle, as it did

Thanks!

l_belev
10-17-2008, 10:14 AM
1) Quads. I use these a lot for particle systems, fire, and other special effects where you end up rendering a bunch of disjoint quads that have their vertex positions recalculated every frame. It just makes sense to dump the four corners of each quad into a buffer and let the hardware render them as quads. Quads are supported in hardware by all Nvidia chips and all recent ATI chips. If quads go away, then I have to either (a) dump six vertices into the vertex buffer for each quad instead of four, or (b) construct an index buffer in addition to the vertex buffer that wasn't necessary before. In both cases, we lose speed and increase memory requirements.


Absolutely agree!
Quads are very useful feature for things like particles or many billboarded distant objects (trees) etc.
Also useful for drawing of text (quad per letter) tho for that one can also use point sprites if the text is in screen space(which is most often the case)
You can't often replace quads with point sprites because the latter can only be screen-space axis-aligned squares (if you use bigger sprite and cut the unneeded parts with texkill, you waste gpu time and/or fill rate)

They are far more useful than triangle fans for example yet the last aren't deprecated but the quads are.
This was one of the nice OpenGL features that contributed to it's charm in contrast to direct 3d

About the quad_strip and polygon, they are unneeded indeed: the first is a triangle strip with different vertex order and the second is triangle fan
But i'm so unhappy about the quads :(

Jan
10-17-2008, 12:35 PM
The ARB_fbo extension does have some very useful enhancements. Nice to see that the limitation, that all render-targets need to have the same sizes (width, height) and format, will be lifted.

Jan.

Rob Barris
10-20-2008, 05:39 PM
IIRC the same-width/height/stride limitations were based on hardware, so that extension won't be exported on all OpenGL hardware, just the ones that do not have that limitation. Roughly speaking, parts which can run DirectX 9.0 are in that category.

Leadwerks
10-24-2008, 12:46 AM
Probably the biggest difference the lack of quads will make is that when I am rendering terrain, the indice data will be 50% larger. Not a huge deal, but it's something to think about.

As pointed out, particles become a little awkward. Not a huge deal, just a little annoying.

Y-tension
10-28-2008, 07:04 AM
...That means you're literally using GL_QUADS. 6 indices instead of 4. But why not use a triangle strip?

Jan
10-28-2008, 07:24 AM
Depending on what LOD-schemes you use, you might very well not be able to render your terrain with triangle-strips, at least not without nVidias (proprietary) restart-extension.

Leadwerks
10-29-2008, 03:50 PM
I'd actually like to see GL_POLYGONS implemented:

Each polygon would start with the number of indices, followed by that many indices. So you could mix triangles, quads, pentagons, whatever. It would be useful for CSG geometry.

tamlin
10-31-2008, 04:01 PM
I'd actually like to see GL_POLYGONS implementedWhile I can sympathize with this whish, I'd personally oppose it if the issue was raised. For one thing it would open a can of worms in areas such as "interpolate between n vertices", "what if the vertices describe a concave surface" and "what if these point's are not on a plane?" - not to mention different implementations might have different optimizations or calculations, making one impl. see an n-polygon as planar, while another not.

I think you see the problem.

As for CSG, that's outside the scope of OpenGL (as I'm sure you know ;) ).

Leadwerks
11-01-2008, 03:05 AM
It would expect a concave coplanar surface, just like GL_POLYGON or GL_QUADS does. Really it is just a compact way of drawing triangles. But I agree, it's not important, and if I can just have triangles work on all targetted hardware without any bugs, I would be happy.

Rohit Pathak
11-25-2008, 09:39 AM
OpenGL 3.0 sucks
It just wasted our time

tfpsly
11-26-2008, 01:44 PM
OpenGL-ES 2 is actually much closer from a clean OGL API than OGL3 imho. It would actually be a good start, added with some DX10.x features (geometry shaders, float render target with blending and antialiasing and the likes) to get a clean 3d portable API.

Rubens BR
02-21-2009, 03:34 PM
A very funny stuff, unfortunately true...
http://www.youtube.com/watch?v=sddv3d-w5p4
Spread it!!!

Y-tension
03-09-2009, 04:25 AM
Infinite LOLZ!!!