PDA

View Full Version : EXT_packed_depth_stencil released



barthold
09-26-2005, 08:23 AM
The ARB superbuffers workgroup recently finished this specification. You can find it here:

EXT_packed_depth_stencil (http://oss.sgi.com/projects/ogl-sample/registry/EXT/packed_depth_stencil.txt)

Barthold

Humus
09-26-2005, 09:24 PM
Very nice!

Vexator
09-26-2005, 10:35 PM
and what exactly can we do with this now?

tamlin
09-27-2005, 01:09 AM
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.

knackered
09-27-2005, 03:32 AM
yes tamlin, the same issues occurred to me.

Dez
09-27-2005, 03:37 AM
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.3Intensity 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);

V-man
09-27-2005, 06:21 AM
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.

JeffJ
09-29-2005, 06:36 AM
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.

DanPartelly
10-19-2005, 05:55 AM
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.

ChiefWiggum
10-19-2005, 08:36 PM
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.

Korval
10-20-2005, 12:38 AM
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.

DanPartelly
10-20-2005, 03:59 AM
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

Brolingstanz
10-20-2005, 04:28 AM
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.

DanPartelly
10-20-2005, 05:37 AM
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.

l_belev
10-20-2005, 08:20 AM
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

zed
10-20-2005, 04:21 PM
because every other word was mispelled.
with all those speelling:) 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

Brolingstanz
10-20-2005, 05:42 PM
bollux, well maybe they want them but do they use them?right said, zed. are you too sexy for logical questions? :D

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

Korval
10-20-2005, 08:26 PM
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.

DanPartelly
10-21-2005, 12:18 AM
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.

DanPartelly
10-21-2005, 12:29 AM
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.

marco_dup1
10-21-2005, 02:18 AM
Originally posted by Korval:

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.This is also my impression. But that is a problem with support of long-lasting software. That I find really annoying is, that I have to bind something to change his parameters. I like the Shader Objects API much better. But there should be also a way to change uniforms without use the shader if the uniforms are saved. I don't say the the binding way should go. I think both ways should be possible.

regards

marco

PS sorry for my english but I have big problems in my native language too.

DanPartelly
10-21-2005, 06:52 AM
PS sorry for my english but I have big problems in my native language too. Why to you apologise Marco ? No need. Is a simple skill, which can be learned, given enough interes.
Your potential spellind errors are of practical importance only to very picky and weird persons.

I got 2 MVPs for Widnows DDK from Microsoft, and helped online hundred of ppl with this awfull english I have, many which finalized complex projects due to my help. And yes they where able to understood what I want to say. All this in a ****ty, every 2 words with spelling errors english. It helped the US and UK guys as well as others :p

Dont apologise for the likes of Korval only, those persons which pretend they cant understand because
your english is so miserable are just telling you
this because they have nothing better to do.

tamlin
10-21-2005, 10:31 AM
This has also absolutely nothing to do with the subject.


Korval wrote:
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.While I agree with the rest you wrote, I don't consider this OpenGL's only strengt.

I think OpenGL has more speaking for it (compared to the competition or not). Cross-platform is perhaps the most obviously, but I wouldn't discount the fact I can today take an OpenGL program written 12+ years ago, compile it, and it works.

Can you even find equally old "competition" code, that's still even valid?

OpenGL has managed, like e.g. the Win32 or POSIX API's, to grow and expand the existing interface(s). DirectX hasn't grown. It has been superceeded time and time again by "new and shiny" (and even incompatible) interfaces. Heck, a DirectX interface Microsoft released just a few years ago is now documented as "obsolete" and its documentation has even been revoked!

I suspect the first Red Book is still as valid as they day it was first printed.

To this one could add the incompatible changes introduced in the many versions of different DirectX interfaces. I mean, 10+ versions in just a little over a decade? That's AFAIK only surpassed (but then by an insane margin) by nvidia's 75-80 versions in a similar timeframe.

That said, obviously I also think OpenGL displays its age, and on many occasions I get annoyed with its flaws. But then again, is there an alternative? No. Furthermore, if an alternative was created and available now, today, could anyone with less than under threat of thermonuclear warheads and total annihilation of Redmond get the largest software "almost"-monopoly on the planet to support such an API? Even if the API today had implementations for ALL other operating systems than Windows?

ebray99
10-21-2005, 12:57 PM
Okay, I feel like I'm adding to a thread that has already lost any of it's value, however, I still haven't learned my lesson from past experience. That said, I'm going to post my opinion, if it even matters.

1.) the FBO stuff is pretty easy to use and it's performance for me has been outstanding. The only problems *I* (there may certainly be others... not discounting them) have had are regarding errors... sometimes I do something wrong and don't get a good error message to tell me. For instance: binding a framebuffer while one of it's texture objects is still bound to a texture target.

2.) PBuffers suck. They were are PITA to use, especially with shaders.

3.) The "extension hell"... I don't feel the extensions are *that bad*. There is currently a mess of extensions, but since they're getting rolled into the core API, it's really not that big of a deal. The first thing I tend to do in a project is look at the desired feature set, and then go through building a wrapper library for the stuff in GL that I want to use. If there is desired functionality in the core spec, I make sure to use it. It's really not that tough for me. The only extensions I use currently are: ARB_texture_non_power_of_two, EXT_framebuffer_object, EXT_packed_depth_stencil. I've got a near complete engine with shaders and all. All I'm doing is using OpenGL 2.0. Thats it. Pretty easy, pretty solid, runs on a wide range of graphics cards... I even have some fallbacks with the ability to run on cards that only do OpenGL 1.5 with GLSL as an extension.

Why is this easy for me? It's an investment. I only have to learn the OpenGL API once. My knowledge from 4 years ago still applies today. When a new extension comes out, I simply read over it and decide if I want to use it. If I want to use it, I'll simply roll it into my codebase. Viola! New feature! Try doing that with Direct3D. In short, when you're on a project that takes a long time, you grow to love the extension mechanism. I can be adding in new graphics features all the way to a few months before ship. I don't have to worry about whether or not I'll have to rewrite my engine internals to use a single new feature, simply because it wasn't included in the current version of D3D at the time the engine was started. The OpenGL extension mechanism works great for an iterative development process.

So thats it. Those are my opinions for what they're worth. Dunno if it will help anyone with their problems, or will perhaps provide a new perspective for anyone, but if so, great. If not, then I really haven't learned my lesson. =)

- Kevin

DanPartelly
10-21-2005, 02:26 PM
Try doing that with Direct3D. Dont be naive. Look at DX9 API. It almost , and I stress the word almost, cleaner and at least as usable as OpenGL. I can guarantee you that the changes in the API will be very conservative, and differences will be minimal, for DirectX Next. DX has evolved to an API which is comparable with OpenGL both as strength and flexibility. DX9+ only lacks cross platform. As "real world" features, it already exceed OpenGl.

Im afraid, altough I really do not desire this, that DirectX Next will be a much more better API then OpenGL.

There where posts here saying that "game developers need latest features and speed". Well,
its true ! Go check the figures and see how much
% of the 3D market is entertainment. And , unfortunately OpenGL loose space every day in it.

Truth is, DirectX evolves at at least 2x speed of OpenGL. ARB comitee can save OpenGL. If they understand their failures and want to save it.
If not, GL will become almost extinct soon.

Brolingstanz
10-21-2005, 04:07 PM
It has been superceeded time and time again by "new and shiny" (and even incompatible) interfaces. Heck, a DirectX interface Microsoft released just a few years ago is now documented as "obsolete" and its documentation has even been revoked!tamlin, that's the beauty of it!

you see, for game development, it doesn't matter if interfaces change a little each year or so, since it's not that difficult to remedy in a properly written renderer, for one thing, and it's a heck of a lot better than waiting while engineers try to shoehorn square pegs into round holes. we are, after all, talking about interfaces, not core features.

think about it. in opengl, if a new extension is released, we're presented with an entirely new api, a new set of functions, enums, and documentation. what's the difference if a function has been changed, or documentation has to be rewritten? look at all the necessary modification to existing spec each time an extension is released. yes, your old code will work, and for certain developers that's important. but eventually you have to cut your losses and realize that no matter how smart you are, you can't predict the future. technology is changing quickly, and you can't anticipate and design optimal interfaces around technology that doesn't exist yet.

heck, to me it's refreshing to get a clean start. sometimes you need to rethink things; ideas that were good at the time just don't stand the test of time sometimes. it's just a pity that opengl is not in a good position to do that. i'm sure the arb would love to change some things if they could. it would probably makes their jobs a lot easier. but because opengl is not a game api specifically, this is not likely to happen anytime soon. as much as you might gripe about how long things are taking, there would be a mighty, cantankerous din, the likes of which has never been heard, if you were to change things and disturb a code base out there the size of canada.

Groovounet
10-23-2005, 04:54 AM
bonehead, you may be explain why OpenGL ES exist, why it is used to PS3 programming. Maybe, because it will become an OpenGL game API.

Even if OpenGL wasn't used in games I still trust it and I think that every OpenGL Extensions witch replace WGL or GLX features are welcomes

marco_dup1
10-23-2005, 07:56 AM
Originally posted by Groovounet:
bonehead, you may be explain why OpenGL ES exist, why it is used to PS3 programming. Maybe, because it will become an OpenGL game API.

Even if OpenGL wasn't used in games I still trust it and I think that every OpenGL Extensions witch replace WGL or GLX features are welcomesMaybe EGL is the way to go?

zed
10-23-2005, 07:11 PM
Dont be naive. Look at DX9 API. It almost , and I stress the word almost, cleaner and at least as usable as OpenGLof course the word 'almost' means even though its close its still worse.
randomly picked example

pd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, true );
vs
glEnable( GL_BLEND );


Truth is, DirectX evolves at at least 2x speed of OpenGL. ARB comitee can save OpenGL. If they understand their failures and want to save it.
If not, GL will become almost extinct soon.how on earth can it become extinct soon if the ps3 uses it, in fact ild say WRT to game sales opengl's market share by 2007 is gonna be larger than d3d

Korval
10-23-2005, 10:40 PM
Can you even find equally old "competition" code, that's still even valid?As part of COM, DirectX must provide (functioning) interfaces for all previous versions of DirectX. As such, Direct3D 3.0 (the earliest and ugliest version of D3D) should still run. Unfortunately, I have no applications this old that run on a WinXP machine. However, I do know of a game that does run under WinXP that uses DirectDraw 2.0, and it runs under any DirectX install.

This happens because Microsoft makes sure it happens. They put the legacy code into each DirectX release (which is one reason why they keep getting bigger); they do not force the legacy on either the modern API or driver developers. It's one of the few smart things Microsoft did early on with DirectX. Putting new APIs into new interfaces that are completely separate from the old API is what allows modern D3D to be a relatively clean API, free of legacy APIs.


To this one could add the incompatible changes introduced in the many versions of different DirectX interfaces. I mean, 10+ versions in just a little over a decade? That's AFAIK only surpassed (but then by an insane margin) by nvidia's 75-80 versions in a similar timeframe.That's actually pretty good. Remember, D3D didn't even exist in DX 2.0 (there never was a DX 1.0), and it wasn't changed in DX 4.0. I don't even know if DX 6.0 changed the D3D API. So what you really have are 5-6 API changes over 10 years.

That's pretty good for a company that initially knew nothing about 3D APIs.


But then again, is there an alternative? No. Furthermore, if an alternative was created and available now, today, could anyone with less than under threat of thermonuclear warheads and total annihilation of Redmond get the largest software "almost"-monopoly on the planet to support such an API?Does Linus Torvald get consulted on OpenGL changes? Of course not; he's just involved with the kernel, which has nothing to do with a 3D API. The idea that Microsoft must be involved with or must support any 3D API is simply in error; it's the IHV's who must provide support, not Microsoft.


bonehead, you may be explain why OpenGL ES exist, why it is used to PS3 programming. Maybe, because it will become an OpenGL game API.Because:

1: Sony is (finally) aware that they need to provide some kind of API for graphics, rather than just shoving some tech manuals at developers and telling them to go to work like they did with the PS2.

2: Because D3D is Microsoft's, and the last thing Sony wants to do is legitimize Microsoft.

3: It's less work to extend an already existing API than to write a new one from scratch.

4: The graphics chip is an nVidia chip; they already have a functioning OpenGL implementation that can be used to create the implementation for the PS3.

marco_dup1
10-24-2005, 04:40 AM
Originally posted by Korval:

Can you even find equally old "competition" code, that's still even valid?As part of COM, DirectX must provide (functioning) interfaces for all previous versions of DirectX. As such, Direct3D 3.0 (the earliest and ugliest version of D3D) should still run. Unfortunately, I have no applications this old that run on a WinXP machine. However, I do know of a game that does run under WinXP that uses DirectDraw 2.0, and it runs under any DirectX install.

This happens because Microsoft makes sure it happens. They put the legacy code into each DirectX release (which is one reason why they keep getting bigger); they do not force the legacy on either the modern API or driver developers. It's one of the few smart things Microsoft did early on with DirectX. Putting new APIs into new interfaces that are completely separate from the old API is what allows modern D3D to be a relatively clean API, free of legacy APIs.

So you have ABI but not API compability over the versions. This is good for games but not so much for long-lived Applications. But don't forget DX is windows only and the best force for innovations is competition. I don't care how long the names of the functions are but how much the design of the opengl api contrainst me.

ebray99
10-24-2005, 12:21 PM
Dont be naive. Look at DX9 API. It almost , and I stress the word almost, cleaner and at least as usable as OpenGL. I can guarantee you that the changes in the API will be very conservative, and differences will be minimal, for DirectX Next. DX has evolved to an API which is comparable with OpenGL both as strength and flexibility. DX9+ only lacks cross platform. As "real world" features, it already exceed OpenGl. Of course D3D is cleaner =). I never made any claim that it isn't. My point was that D3D doesn't work as well with an iterative development process. Why? Because you have to
"port" your application to the latest version of D3D to take advantage of various features. Just as you said, "when DirectX next comes out". Yeah, when it does, I'll be adding in new features and you'll be porting your code. When your development cycle is 3-4 years long, you begin to appreciate certain things about OpenGL. If I went with DirectX, I would have "ported" once already, possibly again to support the new features of latest update, and then at least one more time when "DirectX Next" comes out. Fun stuff right there. As far as "real world" features, OpenGL matches everything D3D has plus some. For instance, I can do an asynchronous texture/vertex buffer upload in GL; can't do that in D3D. I can do depth clamp in GL; can't do that in D3D. I can do primitive restart instead of degenerate tris in GL; can't do that in D3D. In Direct3D's defense, it has D3DX. It has a number of rather useful functions for loading images as well as a pretty nice math library. I'd say here it kicks the crap out of GL. Really though, is D3DX that big of a deal? I doubt I would have saved time using D3DX over the course of a project simply because of the cost of doing those "ports". However, D3DX rules for getting something up and running though.

Also, don't expect the changes to DirectX Next (WGF 2.0) to be minimal. Matter of fact, I doubt you'll even recognize most of the API. ;) :cool: However! If you're talking about DX9+, then you're right, the changes will be fairly light except for a few new (and big) features.

Korval
10-24-2005, 03:53 PM
So you have ABI but not API compability over the versions. This is good for games but not so much for long-lived Applications.I'm not sure I understand your point here. If you want, you can get the Direct3D 3.0 documents and use that interface for doing your rendering. You won't get much in terms of functionality out of your graphics chip, but the older API's are still there. A "long-lived" application can still use the old API's.


My point was that D3D doesn't work as well with an iterative development process. Why? Because you have to
"port" your application to the latest version of D3D to take advantage of various features. Just as you said, "when DirectX next comes out". Yeah, when it does, I'll be adding in new features and you'll be porting your code.Yes, but we've been on D3D 9.0 for quite some time. And the difference between 9.0 and 8.0 aren't that much, so you could consider them to be effectively the same API. So, looking at it from that perspective, D3D hasn't changed since the GeForce 3 came out. OpenGL has had more API changes since then than D3D.

marco_dup1
10-24-2005, 11:11 PM
Originally posted by Korval:

So you have ABI but not API compability over the versions. This is good for games but not so much for long-lived Applications.I'm not sure I understand your point here. If you want, you can get the Direct3D 3.0 documents and use that interface for doing your rendering. You won't get much in terms of functionality out of your graphics chip, but the older API's are still there. A "long-lived" application can still use the old API's.Yes, but if I want use the new features I have to change my complete code to the new interface. In OpenGL I can change my code and still can use the old way in the old code(change code in complex stuff cost allmost time and money). But I think the GPUs will change very much in next years and where will be a need for very different API. So I hope OpenGL (ES) 3 will be not backward compatible. I hope my point is now clearer.

knackered
10-25-2005, 12:25 AM
direct3d is much more cpu heavy, because of the processing needed to construct large batches, which are certainly neccessary for realtime rendering in d3d.
Out of the two abstract implementations of my renderer, I use (and recommend to customers) the opengl version, because the data they use is usually large numbers of small objects, which draw much faster with opengl - and it's not pratical to pre-process data dynamically submitted by the user into large batches.

DanPartelly
10-25-2005, 05:16 AM
direct3d is much more cpu heavy, because of the processing needed to construct large batches, which are certainly neccessary for realtime rendering in d3d. This will change in DirectX next. Buffers will be constructed differently.

V-man
10-25-2005, 05:54 AM
D3DX that big of a deal? D3DX doesn't matter to game developers because creating their own code takes very little time and it needs to be done once.

What matters is the core. Does the API in question do what you need? Are video drivers stable? Will your target audience be able to enjoy your product?

Sidenote : I hope FBO gets perfected quickly. There better be trouble free drivers available as well!

knackered
10-25-2005, 06:48 AM
Originally posted by DanPartelly:
This will change in DirectX next. Buffers will be constructed differently.Is this the virtual memory thing?

knackered
10-25-2005, 06:55 AM
as for d3d being a cleaner api, my opinion is I really hate enums. OpenGL has less, D3D has more. If you're going to do an object orientated api (which D3D is mascarading as), use polymorphism. Over reliance on enums is a sign of bad design. It's nothing to do with performance, because a look-up table has the same cost as a vtable look-up. It's nothing to do with making it extensible, because they've demonstrated they change the entire API interface at the drop of a hat.

Korval
10-25-2005, 08:02 AM
direct3d is much more cpu heavy, because of the processing needed to construct large batches, which are certainly neccessary for realtime rendering in d3d.No, the reason D3D is more CPU heavy is because it is easier to write D3D drivers. An OpenGL implementation has full control over a function call from the moment it gets made. OpenGL implementations implement the API that the user uses directly.

D3D drivers don't work like that. Microsoft defines an API for D3D driver developers to implement. This driver runs in unprotected mode on the CPU. As such, every call to D3D that has to talk to the driver forces a switch to Ring0 on the CPU. This is not a fast operation. Because D3D itself implements a layer between the application and the hardware driver, it cannot properly do marshalling of various function calls (for various reasons), especially considering that "proper" marshalling for a GeForce isn't necessarily proper for a Radeon.

So, basically, it is exchanging performance for easier to implement drivers (and thus more robust drivers). Much like giving Microsoft responsibility over the HLSL compiler rather than putting it in the driver trades potential performance for robustness of the API.

As I understand it, in DirectX 10 (or whatever they call it), they are going to remove some of the more bothersome layers between the driver and the application, thus allowing the driver to do some marshalling (and probably async uploads and so forth). I doubt that the entire mechanism will be exposed as it is under OpenGL, but it should alieviate the most significant performance penalties associated with this issue.


as for d3d being a cleaner api, my opinion is I really hate enums. OpenGL has less, D3D has more.Admittedly, I haven't looked at D3D in quite some time, but I can't imagine the API having more enums than OpenGL. The possibilities that fit into glGet* alone probably outstrip anything in D3D.


If you're going to do an object orientated api (which D3D is mascarading as), use polymorphism.I would suggest that D3D is not an object oriented API. It uses objects (instances of C++ classes and COM objects), but it clearly follows few if any OOP design principles. Furthermore, I would suggest that OOP doesn't really belong at the low-level graphics API, but at a higher level scene-graph level (or, at least, a level that recognizes a "mesh" as being more than just a group of vertex buffers). So, under that belief, it is a good thing that D3D is not an object-oriented API.

knackered
10-25-2005, 09:26 AM
Eh? I didn't give any reason why d3d only works properly with large batches, I merely stated that it, as it stands in the major implementations, is definately cpu intensive. The reasons for this are irrelevant to the developer. I've measured the differences between the two API's with real world data, and d3d is significantly slower. It's comparable with opengl with larger batches, however.

D3D is trying to be object oriented (Common Object Model), it has a notion of interfaces (d3d, d3ddevice), it has a notion of objects (texture objects, vertex buffer objects, index buffer objects, surface objects etc.etc). So, it works in an object-oriented way as it stands, so why so many enums? Every single state is an enum, every single state has just one parameter, which is a 32bit integer...things like fog range values have to be macro-magic'd into 32bit integers in order to fit in with this grand design. What the hell is wrong with having a function for every state? It's not like there's hundreds of states. Then you can be type-safe, then you don't need to look up in a table for the attributes of that particular object/state. If you've got the freedom to re-invent your entire interface with every revision, then it absolutely should be completely object-oriented, because we're dealing with objects all the way down the (pipe)line.
Why, specifically, do you believe object-oriented design doesn't belong in a low level API?
Low level doesn't necessarily mean straight C, you know.

Korval
10-25-2005, 09:38 AM
The reasons for this are irrelevant to the developer.Actually, the reasons are quite relevant for the developer. If the developer were giving up performance without getting anything in return, then D3D would have problems. However, developers are getting something for that; they get more stable drivers (thus less testing and therefore more time can be spent on more important things). Just as an OpenGL developer can expect more driver instability, but they can also expect better overall performance.


D3D is trying to be object oriented (Common Object Model), it has a notion of interfaces (d3d, d3ddevice), it has a notion of objects (texture objects, vertex buffer objects, index buffer objects, surface objects etc.etc).OpenGL has many of those same objects, and yet nobody would even consider calling it object oriented. And COM does not imply OOP; it is a language-neutral mechanism for communicating between two different concepts. Just because the word/concept "object" is used does not imply that OOP is intended.

knackered
10-25-2005, 11:25 AM
COM is of course an object-oriented concept, your interpretation of it is just its main motivation (and the blurb on the box).

Also, OpenGL *should* abstract it's objects using interfaces too, but it's current API is much clearer than D3D, it's type-safe (glFogfv expects a float, no unsafe macros needed). It's also pure C, and has to maintain backwards compatibility (see my point about d3d's freedom to re-invent itself). But opengl is a C programmers interpretation of object-orientation.
Direct3D has the opportunity every year to sort this mess out, but it never seems to.
I'm sure there's a very good reason, but nobody has so far given an explaination.