EXT_packed_depth_stencil released

The ARB superbuffers workgroup recently finished this specification. You can find it here:

EXT_packed_depth_stencil

Barthold

Very nice!

and what exactly can we do with this now?

Considering it’s still (documented as) incomplete, I expect it to improve before the final version. Thought I’d mention some things I came to think of anyway.

Perhaps it could be better to briefly introduce the new identifiers and their intended usage first, as an overview, instead of diving into specifics and introduce them upon time of usage?

I’m a bit curious about the order of the bytes, and potential performance impact, when the server is connected by a hardware bus.

For LE (e.g. an IA32 PC) it might be that the order is optimal, and one can simply DMA gfx <-> system RAM, as the order is defined to be:
(DB = Depth Buffer, St=Stencil, B=byte, b=bit)
DB b23-16 = sys. B[3]
DB b15- 8 = sys. B[2]
DB b 7- 0 = sys. B[1]
St b 7- 0 = sys. B[0]

But the same server hardware, if using DMA, would (AFAIK, I could be wrong) on a BE machine end up as:

DB b23-16 = sys. B[0]
DB b15- 8 = sys. B[1]
DB b 7- 0 = sys. B[2]
St b 7- 0 = sys. B[3]

and thereby violate the spec.

Does this mean that

  1. such h/w when running on BE would have to have a “crossbar” in front of DMA’able video RAM, to swap bytes, or
  2. The driver would have to do this in software, or
  3. I’ve misunderstood something completely
    ?

Also, by the name of the data format type I get the impression that the depth data must be expressed as a 24-bit (even LE?) integer. Wouldn’t this further limit implementation freedom (and extensibility), or force a slow path when copying such data to host memory?

Perhaps the “INT” designator in the datatype isn’t what I think it is (a 24-bit integer), and it should really be viewed as a black-box storage?

Overall I think what I’ve read of it so far is good, but I look forward to the next draft; both a reorder of introduction and some elaboration on the bit-twiddling issues.

Thanks.

yes tamlin, the same issues occurred to me.

The ARB superbuffers workgroup recently finished this specification.
At last! I couldn’t wait for it to come out, because FBO without stencil buffer support was quite useless in my case. I wonder, when we will see this implemented in official drivers for mainstream hardware.

I’m a bit curious about the order of the bytes…
The spec is quite clear about this and as I assume anything else should be considered not compilant.

UNSIGNED_INT_24_8_EXT

   31 30 29 28 27 26 ... 12 11 10 9 8 7 6 5 4 3 2 1 0
  +----------------------------------+---------------+
  |           1st Component          | 2nd Component |
  +----------------------------------+---------------+

And as I am at the topic of spec I found some rather minor bugs:

In section 4.4.4 “Framebuffer Completeness”, modify the definition of
“depth-renderable” and “stencil-renderable” to say:

   "* An internal format is "depth-renderable" if it is
      DEPTH_COMPONENT or one of the formats from table 3.16 whose
      base internal format is DEPTH_COMPONENT or DEPTH_STENCIL_EXT.
      No other formats are depth-renderable.

Should probably say:

  • An internal format is “depth-renderable” if it is DEPTH_COMPONENT or DEPTH_STENCIL_EXT, if it is one of the formats from table 3.16 whose base internal format is DEPTH_COMPONENT or DEPTH_STENCIL_EXT.
    To be in line with the next bullet.

Add a row to table 6.17 “Textures (state per texture image)” on page
278:

  Get value             Type    Get Cmd               IV  Description                           Sec.
  -------------------------------------------------------------------------------------------------------
  ...                       ...     ...                   ... ...                                   ...
  TEXTURE_STENCIL_SIZE_EXT  n x Z+  GetTexLevelParameter  0   texture image's intensity resolution  3.8.3

Intensity should probably by changed to stencil.

Usage ExampleS…
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8_EXT,
512, 512, 0, GL_RGBA, GL_INT, NULL);
Should in my view be:
Usage Examples (case typo)…
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8_EXT,
512, 512, 0, GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, NULL);

Originally posted by tamlin:
For LE (e.g. an IA32 PC) it might be that the order is optimal, and one can simply DMA gfx <-> system RAM, as the order is defined to be:

What happens on a big endian CPU when you create a VBO and write your vertices to it?
Does the GPU flip bytes if it is little endian?

I think byte flipping is built into the GPU. The driver probably just sets a switch.

Originally posted by Dez:
I wonder, when we will see this implemented in official drivers for mainstream hardware.

It is already implmented in the nvidia driver, and and a public driver supporting the new extension should be avaiable relatively soon.

as I am at the topic of spec I found some rather minor bugs:
Thanks for pointing these out.

Should in my view be:
Usage Examples (case typo)…
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8_EXT,
512, 512, 0, GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, NULL);
You are correct. The externail format and type are supposed to be GL_DEPTH_STENCIL_EXT and GL_UNSIGNED_INT_24_8_EXT.

This is not a troll, nor intended as flames. I like to think it as a open letter to OpenGl ARB comitee.

Dear ARB comitee, and whoever manages OpenGL. Thank you very much for releasing this spec. Of course, I would have expect that OpenGL 2.0 have core FBO support , and not a EXT extension. Of course, I would have expect to have depthstencil format as part of initial FBO, and not after many many months,
have yet another extension in a jungle of extensions.

Of course, we all plead for OpenGL saving in Windows
Vista, but who will save OpenGl from itself ? In ano
domini 2005 we wanted Gl 2.0 core to have float textures, FBOs, with depth stencil support. But it want meant to be.

I think I am in conset with other developers at the speed and direction in which some OpenGl extensions are worked by ARB. Guys, please, wake up. You are already falling behind DirectX since DirectX 9 is out, and if you continue this way, with DirectX Next, you will be history on Windows platform. There will be no need to Gl , since the gap will become increasingly harder to bridge.

Please, save OpenGL. Is the greates API of all times. Dont ruin it, ARB comitee, and Gl managers.

I second that… but I dont know if I can wait around for GL long enough… I’m sick of playing with pbuffers and FBO’s which dont do what I want or pause for 1second on nvidia cards if you make a context switch… This is all unusable, I’m very heavily considering dropping GL completely and moving all my development to DX.

Dan, I might agree with you, but I couldn’t understand what you were talking about because every other word was mispelled. In the future, if you’re going to offer up an open letter to someone, you should take the time to make sure it uses reasonable spelling.

Korval, Im sure you do understend the ideea behind my lines, and you jsut preted you dont. Even a man with a marginal IQ can grasp the ideea, with all those speelling mistakes. And im 100% that many developers second my position, even if its expressed
in a awfull english.

But thanks for your comment on spelling. Next time,
Im looking forward to see how you write in my native
language. Until then , your comments are of not use to me.

Sincerely yours , Dan

I think I am in conset with other developers at the speed and direction in which some OpenGl extensions are worked by ARB.
speed is good, but isn’t the strength of opengl the great design of the api? i mean, if you want the features of d3d, use d3d. what’s it all about if it’s only the features your interested in. if you want a polished, constistent, cross-platform, well spec’ed api, then use opengl, but don’t think such a pretty api comes at no cost. the cost is time, time to carefully introduce each extension. heck, without the carefull design process, what do you get? (hint: something like d3d)

i think microsoft is smart in the way they approach d3d. they realise that game developers want the latest features, no matter the cost. if it means that the api isn’t quite as pretty as it could be, so what, it’s all going to change tomorrow. however, microsoft has the luxury of catering to game developers more or less exclusively, whereas opengl’s dev base is far more diverse.

i feel the need for speed too, but at what cost? it seems like you need to cut some hefty chunks out of the api and simplify some stuff if you want to speed things up. those arb guys have it tough, what with that big hairy spec and all.

if you want a polished, constistent, cross-platform, well spec’ed api, then use opengl
Well, I certainly agree with you. But , is really a
well spec;d API one in which you introduce yet another extension to support D24S8 with FBOs ? IMHO this should have been part of initial plan.

Also, uberbuffers where planned to be part of GL 2.0. It was the single biggest feature I wanted to see in core GL 2. I think elimination of uberbuffers , and implicityl FBO, had to do a lot
with politics and sterile discuttion and not only lack of time. They (uberbuffers) where mediatized, said theyll make DirectX look like ****, and where big plans to make them Gl 2.0.

Today, couple of years latters, look where we are.
They cut down GL 2 new major core features to GLSL. Not even enough to justify a major version.

Just my 2 cents.

But , is really a
well spec;d API one in which you introduce yet another extension to support D24S8 with FBOs ? IMHO this should have been part of initial plan.

it is a matter of practice in opengl first to introduce the abstract base api and then to add various extensions attuned to topical hardware architectures. thats why the DEPTH_STENCIL comes later - its more like a patch to the abstract api.
yet i agree with you it shouldnt have taken so long.

Also, uberbuffers where planned to be part of GL 2.0. It was the single biggest feature I wanted to see in core GL 2.

i hoped to see the framebuffer objects in 2.0 as well. im quite disappointed

because every other word was mispelled.

with all those speelling
:slight_smile: im one of the worse offenders

they realise that game developers want the latest features, no matter the cost.
bollux, well maybe they want them but do they use them? NO, if u disagree name released examples.
eg i read a review of FEAR today, along the lines best graphics ever etc. and heres me looking at the screenshots + going huh?
most of these games labelled dx9/10 are not much better visually than quake3

bollux, well maybe they want them but do they use them?
right said, zed. are you too sexy for logical questions? :smiley:

my point was the stuff about the speed thing that dan mentioned, the turnaround issue, the “what the heck is taking so long” deal. you knows? like, zoiks scoob, i was defending opengl and the arb (not that they need defense), or did i make that too obvious?

i haven’t played many games lately, i regret to admit, but i suspect that all the latest games will make full use of their respective apis, else they will likely not sell many copies compared to those that do. and consider all the games that are currently in developement. the sooner dev teams have access to the latest features, the sooner they can begin incorporating them into their engines. this takes time, and advanced availability makes planning and developement a lot easier, especially with a dev cycle of a couple years or more. it’s nice to know what you have in the bag, even if you don’t use it today.

regards,
bonehead

Next time,
Im looking forward to see how you write in my native
language.
I’m sure that if I were to take the time to offer up an “open letter” to someone in your language (or any language I am not familiar with), I would consider it inappropriate to release said letter if I had not taken the time to do even basic spelling checks (like looking at some other posts in the thread and following their lead on how to spell something I don’t know). But that’s just me. And the whole “English as a second language” thing isn’t an excuse, as there are plenty of posters here and elsewhere who know English as a second language who are capable of spelling better than many to whom English is a first language.

But, I digress.

As to the point of your diatribe, we all know that the SuperBuffers/UberBuffers/etc fiasco was due to a combination of problems in the ARB, ranging from politicking amongst its members to simple apathy about the extension. The ARB has made numerous mistakes pertaining to this important functionality, and I have even made numerous posts attacking them for it.

However, the fact of the matter is that the ARB is made of a bunch of people who are in competition with one another. While I blame them for the generally poor state of OpenGL in comparison to D3D on a variety of fronts, no particular resolution exists in order to rectify the situation. Effectively, hate the ARB all you want, but that’s what we have.

speed is good, but isn’t the strength of opengl the great design of the api?
You’re kidding, right? OpenGL’s strength is not the “great design” of its API, but in the fact that it is the only cross-platform 3D graphics API. That is it’s only strength compared to its competition. Everything else is either approximately equal to D3D or inferior.

OpenGL is not a well-designed API. It is an API that has had layers and layers built on it, each one depricating the previous one but without actually removing it from the language. As such, implementing it becomes an ever escalating problem. Maybe if the API could be rebuilt from the ground up, then it might be considered well-designed. Until then, it is a mismash of features that, while certainly functional, has innumerable pitfalls in its design. OpenGL ES, by contrast, is far better of a 3D API.

But, I digress.
Yes, you digress. As I said Im not interested in your opinions about language and spelling. They are boring. If you cant uderstand my post, ignore it, and consider me an illiterate.

no particular resolution exists in order to rectify the situation. Effectively, hate the ARB all you want, but that’s what we have.

You make very valid points Korval. But they should be reminded again and again that they did a lame job with Gl 2.0.

Maybe those guys will awake from this state. I really cant rest with an “thats what we have” , those guys should be rempembered that if they are the ARB comitee, they have a RESPONSABILITY to OpenGL and the standard. If they cant understand this, and let politics and contradictory fights, and , why not , apathy , they should go to sleep ,and let others step in their positions.