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.

Re:Good idea...

[donglekey]

This is completely untrue.

A standard for pixel and vertex shaders that is not specific to any one card is a very big deal, and people are reconizing that it is the future. Many people are scared of games being released for only one card, and/or having to write a game for only one card. I don't think anyone wants that to happen. Standards mean more competition, more competition means higher quality and lower price at a faster rate. Defining a standard for procedural, hardware implemented functions will be key in advancing realtime 3D further. Image based textures are eventually going to be phased out for most purposes (as seen with trends relating to high-end 3D and the trickle down effect into realtime) and a standard makes it infinitly easier. There are many other applications, such as acceleration of non-realtime rendering, which is also a very big deal, and vastly accelerated and much more realistic previews in 3D applications. 3D Studio has already started to do this a little bit and it looks great.

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!

Re:This IS necessary

[Jurjen Katsman]

While it might be true that DX8.0 added a lot of features that only worked on the Geforce3 back then, the new Radeon 8500 supports all those features just fine as well.

DX8.1 adds new features only available on the Radeon 8500, but a new NVidia card will be able to run all that just fine as well.

The plan is for this to continue in this fashion, so the next NVidia card will probably support PS1.4 again (the R8500) stuff, and so forth.

This is a very different situation from OpenGL where the way to do pixelshaders is completely different on ATI or NVidia hardware, and anything you do for an NVidia card will never work on an ATI card, and not the other way around either. As far as I know the same applies to vertexshaders, and ATI still doesn't have their own version of NV_VertexArrayRange. (And they certainly need it).

On OpenGL2.0, it seems like an interesting plan at first (I'm always open for API innovation), but atleast for gaming it doesn't seem to be a very interesting API, and not very forward thinking either. For example keeping the framebuffer blend out of the programmable pipe goes directly against what game programmers have been asking for.

In addition it seems the API would have a lot of problems running on current hardware (not to mention how long it would take for drivers to even get close to stability). OpenGL2.0 would expose model for vertex and pixelshader programming that would be completely unsupported by current hardware. This means you will have a lot of rules to follow to achieve hardware acceleration on specific hardware. When using more features you'd drop back to mostly unacceptably slow software emulation. This would either be hidden (and you could only find out by browsing PDFs hidden somewhere on some IHV site), or it would have to be exposed through some sort of caps system. (Exactly what the OpenGL crowd so seems to dislike.)

Anyway, I don't see this working yet, not for the games market, maybe for others. Best of luck to them anyway.

Re:This IS necessary

[Namarrgon]

Indeed. This is one of the things they talk about in the recent OpenGL ARB meeting notes.

nVidia's extensions alone total more than 500 pages, compared to 230 pages for the entire OpenGL 1.3 spec. ATI has their own comprehensive list of extensions, as does SGI and many others. Since there's little natural overlap, each vendor implements similar features in a different way (e.g vertex shaders), and you have to code for each vendor's set of extensions separately. The OpenGL ARB can "ratify" extensions to promote standardization, but you still have to cope with them not being present at all.

This is exactly the problem developers have with DirectX - MS regularly revs the entire API to try and support features from every vendor, so there's an ever-increasing number of ways the underlying hardware differences are exposed, and the number of hardware caps that have to be checked before doing anything is growing rapidly. There are 4 different versions of pixel shaders that a vendor can support in DX 8.1, and the only reason it's not more of a mess is that there's only two chips which support any of them so far (and one of those isn't even available yet).

Regular simplification & unification of all these diverging directions is required. Vendors should of course be able to add innovative extensions, but a core of Really Useful standard features must be maintained & extended, so that hardware vendors have a baseline to target, developers can rely on the features being present, and the lowest common denominator gets steadily pushed higher for everyone.

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