3D Labs Proposes OpenGL 2.0 To Kick DirectX

furiousgreencloud writes "3Dlabs is trying to drive the graphics interface away from hardware specific extentions, as seen in DirectX. Instead, they are proposing an open (no NDA) dialog on OpenGL 2.0. The guidelines mention good-ol-fashioned platform independence (linux included) and emphasis on programmability, time control and memory managemenmt. They've got a PDF availible for consumption."

Comments

Mirrored

[ekrout]

This 2.25MB pdf will surely be inaccessible in a few minutes. I've mirrored it at http://ekrout.resnet.bucknell.edu/mirrored.pdf.

This IS necessary

[rips]

There seem to be a lot of posts stating that the current OpenGL implementation is good enough but I question whether or not these people are developing software with the latest graphics features.

Vendor specific extensions are making cross-vendor OpenGL development difficult. It is necessary to implement several different codepaths in order to achieve various effects on different hardware (bump mapping, cubic environment mapping, etc.) because each vendor wants to do it their own way to expose all of the new capabilities of their hardware. The SGI multitexture extension is probabily the only real exception to this since it seems to be supported by the bulk of cards on the market.

I don't know of any current AAA, A or B grade game that doesn't support at least one proprietary OpenGL extension.

DirectX8 exposes the hardware in an 'almost' abstract manner but again vendor specific features have started to creep into the mix (the different shader version support is something that comes to mind), meaning that developers still have to develop multiple versions of the same effect for different hardware.

This is definately a great move! I hope they succeed!

You mean SDL?

[Starship Trooper]

This has probably already been said, but the SDL library is probably our best bet. It has been in development for the past two years or so, and has progressed immensely into a stable and feature-rich development platform. It is a complete cross-platform solution for high-performance game graphics, sound, and input on an insane amount of platforms, including the requisite Windows, Mac (both Classic and OS X) and *nix. Ports are also available or in the works for QNX, BeOS, Amiga, and a number of other OSes, I'm sure. I have used it for some of my projects, and I must say it is far superior to any other API I have ever tried, including DirectX (which it encapsulates nicely :-). Sam Latinga, the founder and main coordinator of SDL, is not only a great programmer and API engineer, but a nice guy as well.

Misc first impressions

[Anonymous Coward]

Loops

I'd recommend against general for and while loop constructs in the shading languages. These are difficult to statically analyze the behavior of. For instance, you could stall your pipeline with an infinite loop but no compiler can detect infinite loops. Also, loops are rarely used except for Perlin noise where you iterate down to a particular frequency.

Loops of a particular form can still be analyzed, and would be useful. Something like this:


for (int i = 0; i &lt N; i++) { body }


If i is 'const' within the body, then this will iterate at most N times, giving you a bound on the compute time needed. Note that if N is an arbitrarily large number, it may still be difficult to analyse. Here's another form that is more generally boundable:

for (int i = 0; i &lt N && i &lt 20; i++) { body }

This will run at most twenty times, giving an easily computable upper bound on the total run time for the loop. Of course, 20 was just pulled out of a hat, and should probably be a constant specific to the compiler or hardware available.

Memory Management Issues

Pinning is dangerous, your program could be really broken on a graphics card with smaller memory than you intended. At the end of the standardization process it will probably become a mere 'hint' anyway.

An alternative might be to treat the memory management as a generational garbage collector, with user hints on what generation things should fall into. Rather than specify a particular management scheme, the programmer could hint at how dynamic the object would likely to be, say for instance ranking them from 0-7, with 0 being transient and 7 being pinned. Alternatively the systems themselves could become more intelligent, tossing everything into the transient area, and migrating them upstream automatically when the transient area starts to fill up.

Another useful operation would be to hint flushing everything below a certain level. So for instance you could give Everquest character models a level 5, the terrain a level 4, mobs a level 3, and various effects and candy at lower levels. Then on zone you would just specify a flush of levels 4 and under to clear that memory, while leaving the character models intact.

For added flexibility to this model, multiple different memory pools could be managed in this fashion. It remains to be tested whether that would be worthwhile or not.

Well, that's all I could think of off the top of my head. Good luck on OpenGL 2.0!

Michael

OpenGL ARB Meeting notes

[Namarrgon]

Available here.

There's a lot of discussion on how/when/why they want to move forward to OpenGL 2.0. Gives some interesting insights into how these things are done.

Also, there's some talk about nVidia's new position on opening up their vertex shading IP, GL_vertex_program_NV vs. ATI's GL_EXT_vertex_shader, and which approach would be better for OpenGL 2.0 (low-level vs. high-level).

Re:OpenGL

[spectral]

Can you provide an example of how it's dying? It's evolving, that's what this whole article is about, one of the largest revisions/additions/etc. to the OpenGL specification since it was made (hence the major version # increase). If you're going solely by games, well, most develop for Windows. In Windows, drivers seem to be optimized for D3D. So games use D3D. Plus, they're using the rest of the DX suite for sound/input/etc. anyway, why not? These are the same people who don't care about portability.

So basically, You're just a troll. And I've been trolled. Damnit :)

Re:Lacking

[Osram]

Have you seen PLIB ?
This not only includes a portable (Linux, BSD etc, Windows, MacOS etc) scene graph on top of OpenGL and sound and input, but also the other stuff you need for games development like networking and graphical user interface.

Re:Lacking

[SilentChris]

Ahem.

"3D Labs Proposes OpenGL 2.0 To Kick DirectX"

DirectX includes all of the extensions shown above. OpenGL just does graphics. The author of the post, and the person who posted the story, clearly wanted to make a comparison between OpenGL and ALL of DirectX, which as as mentioned before, is ludicrous because of all the stuff OpenGL is lacking.

Get your facts straight.