Slashdot Mirror
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."
Soon we'll have Nvidia making games tho I'm sure that will be created on a proprietary system even more stringent than where we are now. You don't think so? --- Example: ... "It's the hottest game of the year and they don't take ATI." (Sung to the toon of a Visa comercial. It's in Nvidias best intrest to make this happen. Tho maybe not in the markets best interest.
I am Jack's HTTP Server
...but the current OpenGL standard is extensible enough for the time being. More important would be a complete OpenAPI setup with input, sound, network, and graphics options all combined and available on all platforms.
Sure, including specific instructions for per-pixel operations etc. for all cards as opposed to stuff like GL_EXT_NVIDIA_WHATEVER would be great, but it's not likely that there will be many drivers for any older cards for this, and all the new cards have great GL drivers already...
Basically, this is unneccessary.
This 2.25MB pdf will surely be inaccessible in a few minutes. I've mirrored it at http://ekrout.resnet.bucknell.edu/mirrored.pdf.
If you celebrate Xmas, befriend me (538
Minus DirectSound, DirectInput, and all the other things which make DirectX a "good thing (tm)" for Windows (simple interoperability with hardware using standardized API's, simple driver writeups). For the time being I'll pass.
Besides, I can always teach my upcoming XBox to dual-boot. :) Best of both game-playing worlds.
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!
Not only is this a worthy cause (eliminating the depenence hardware specific extensions), but I fully support a graphics solution that doesn't have the final say on everything rest with MircoSoft.
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.
Loneliness is a power that we possess to give or take away forever
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 < 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 < N && i < 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
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).
Why would anyone engrave "Elbereth"?
Jeez. Major trolling.
Or do you actually believe everything you just said?
The Structure of Array link is actually fairly interesting, but if you think about it it has no meaning to this argument. OpenGL has allows allowed you to specify seperate streams, but X/Y/Z are still bound together. That's not SOA, and not what Intel likes. When you get down to it the whole SOA thing was basically just Intel making up excuses and workarounds for poor CPU design.
In fact most modern hardware (Radeon, Geforce) will prefer it if you pack all your vertex components together, as DirectX has always worked. This all to make more efficient use of memory bandwidth.
Ofcouse that link to Paul Hsieh's site is ancient, and reflects a persons opinion of a battle that raged years ago, based on years old facts. Not all that interesting really.
Great, they're closing the barn door after the livestock has left.
Seriously, why now? This could have easily happened long ago, before Nvidia crushed the competition. I don't like the world where looking to open source (or even just open discussion) is the last resort of a dying technology.
Invisible Agent
This post is a mirror; when a monkey stares in, no hacker gazes out.
In similar news...
Linus Torvalds proposes to kick Bill Gates.
It is uncertain as to whether the world's richest man will propose a retaliation kick. Such a proposal could be viewed as a sign of weakness. It should be noted that while Gates is phyiscally much smaller than Torvalds, microsoft operating systems have a much larger market share than linux.
Know what I like about atheists? I've yet to meet one that believes God is on their side.
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
In my opinion, if you're comparing DirectX and OpenGL then you're really talking about group multimedia projects, and I really think that sticking it out in C isn't the way to go for that.
I love C, but there are huge design benefits in going OO with C++. Eventually you'll get to the point where there'll be a large body of accepted base classes that should handle all the standard 3D objects you might need for a game, and then you won't have to (eg) search all over the internet to find obscure libraries in beta form just to get your program to load a model from a 3D cad program.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Game developers have to develop where the market is. Game developers aren't scratching their heads in a huddle making sure some vertex shader is going to work on a MIPS box as well as a Intel one. They also aren't wondering if they ought to code some API extensions used by a chip that is in a fraction of a percent of boxes. The ones clamouring for standards are the third tier and lower chip makers that have a fraction of the market penetration ATi and nVidia have. If you've got support for ATi, nVidia, and 3dfx you're set to go on just about everything. I'd bet the markets for the big three (now the big two) is fairly even considering the proliferation of ATi cards in OEM systems. Selling your game to a publisher doesn't necessarily entail providing support for every potential market, just the ones the publisher decides are important. A bulk of game developers and publishers won't bitch much about standards while they can hit an incredible percentage of the gaming market by focusing on one system. The developers and publishers look at it like this: what are the machines we're targeting being used for? If the answer doesn't involve the machine sitting idle with signifigant amounts of computing power (enough for the proposed game, aka most consumer Windows machines) the game probably won't be developed for the system. Macs enjoy a much wider market than linux systems and have vendor support for APIs and are still second tier for game developers because not enough of them are sitting on desks in the game purchasing consumer's home.
I'm a loner Dottie, a Rebel.
Just like OpenGL's interleaved vertex arrays.
Circa ... 1996?
After all, why lock your game into one platform when another equally good API allows you to port to other platforms (including consoles) with relative ease? Certainly you'd have to port all the sound and controller stuff but that's chicken feed compared to porting a game engine.
No, 3Dlabs != 3dfx.
3Dlabs produced the Permedia cards, which were marketed at gamers, and continue to produce professional workstation OpenGL accelerators based on the Glint chip.
3dfx made the Voodoo series of cards. They're the guys who promoted Glide, which was their proprietary API.
DirectX was much simpler when it first came out, so was easier to implement. It had Microsoft's weight behind it, it was being steadily improved, and it supported 90%+ of the target market. So vendors implemented drivers for that as part of their normal Windows support.
A few (luckily influential) die-hards (like Carmack) used & promoted OpenGL, which forced minimal support from vendors (remember 3dfx's mini-driver?), but few vendors bothered to go the whole way & write a full OpenGL ICD.
Direct3D was the lazy way out, so that's what people got.
Why would anyone engrave "Elbereth"?
True, but us game developers also buggered up the market by NOT actively pushing OpenGL instead of D3D, and developing for D3D *when we HAD a choice*.
There was even a petition to Microsoft to better support OpenGL for gaming, which Microsoft responded by ramming D3D down everyones throats.
I'm just thankfull that Carmack didn't sell out - he's the primary reason OpenGL support for games is still around. The OpenGL-Game-Dev list traffic has unfortunately slowed down, but it's not dead (yet.)
> Game developers aren't scratching their heads in a huddle
> making sure some vertex shader is going to work on a MIPS box as well as a Intel one.
You don't do any PS2 coding do you?
When your game is simulatenously being ported to X-Box, and the PS2 you need to re-implement the vertex shader natively on each hardware. It would save a LOT of time if us developers could use just ONE vertex shader description language for BOTH platforms !
> A bulk of game developers and publishers won't bitch much about standards
> while they can hit an incredible percentage of the gaming market by focusing on one system.
And loose 1/2 your sales?! That's the reason a standard exists - so we DON'T have to code specifically for one card !
Game developers want to maximize their sales with the least amount of work.
Rest of your comment is correct.
~~~
WTF is "Your comment violated the postersubj compression filter. Comment aborted" and why isn't it in the FAQ ?
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.
DirectX does only three things: graphics, sound, and input. OpenGL handles graphics, GLUT handles input, and OpenAL can do sound. Other multimedia programming libraries include Allegro, SDL, and ClanLib, all of which can coexist peacefully with OpenGL graphics.
Will I retire or break 10K?
There is hardware. That hardware is owned by your targetgroup. That targetgroup will buy/use your application. What do you do? That's right! You use the API that will make the targetgroup able to run your application on the hardware they own. Does the targetgroup care which api, which dll's, which 3d object format etc you use? No. They probably don't even know what a 'vertex' is.
So if you have to use OpenGL, use OpenGL. If you have to use D3D, use D3D. Being productive, THAT's the key here. Not the emotional connection with any API. Save the emotions for a hobbyproject.
Never underestimate the relief of true separation of Religion and State.
Yeah, that's why IBM PC compatible clone market died in 80s; nobody wanted non-proprietary hardware platform. Same for the TCP/IP and WWW on 80s and 90s; neither had a chance against cool stuff like decnet, netware and various cool hypertext protocols that rule nowadays.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
Organizational support for OpenGL continues, but it's not like the days when SGI was really pushing it. The Farenheit debacle turned off many people. Apple is still OpenGL oriented, but support is weak. From the minutes of the last meeting: "The next meeting date is set for Tue-Wed, December 11-12, 2001. Apple is tentatively willing to host again, if needed - the food budget was a bit of a problem for them this time."
What this proposal really calls for is a sort of "RenderMan Lite". The concept is very like RenderMan, with programmable shaders written in a C-like language.
This is an instance of the "programmable peripheral" problem. There's always a temptation to put programmability in peripheral devices. The usual problems of embedded systems programming apply - a special toolset is needed for the target system, debugging support is usually weak, and synchronization between host and target is complicated. That's why programmable peripherals are rare. (For example, we don't usually see the ability to put the file system in the disk controller, or the TCP/IP stack in the Ethernet controller, although hardware has been built and sold for both of those functions.)
What usually happens is that agreement emerges on what functionality a device should export, and device controllers implement that functionality, rather than exposing their innards.
Kinda like how Glide won? Or MeTaL? Or PowerSGL? Direct3D is not extendible (game developers stopped MS from making it extendible) and it owns the majority of the consumer 3D market. All the graphics cards makers are actively in support of it, while most offer less support for OpenGL. The fact that a standard interface like DirectX allows manufacturers to reach *everyone* with a 3D card, not just those with particular 3D cards outweighs any advantages of proprietory APIs. The game developers like it because it simplifies development for them. The hardware manufacturers like it because it broadens the use of 3D hardware. Consumers like it because they aren't stuck buying unsupported crap (generally...)
A deep unwavering belief is a sure sign you're missing something...
Which would be correct. Linux is a kernel; a kernel's job is to run programs.
.mid file doing a good impression of a tb-303 to convince me otherwise. Why else did Unreal Tournament use S3M, XM, and IT tracked music instead of MIDI, and most newer games like q3a use streaming MP3 or ogg anyway?
>>>>>
But those words carry a far larger meaning than the sentence implies. DirectX does only do sound, graphics, and input, but those words understate its power.
Just a tad, and DirectX Graphics's superiority is in areas that require hardware that most consumers (early adopters excluded) do not yet own. Even so, I hope Microsoft is enjoying its fleeting precious moments [gocollect.com] of superiority because they will end very soon.
>>>>>>>>
Why? The link you provide doesn't have anything to do with DirectX or OpenGL, so I surmise that you have no proof that OpenGL will suddenly stage a comeback. Even if OGL 2.0 gets rolling right now (it won't) it will quite awhile before the glacial-paced ARB will produce something useful.
Or "GLUT is infinitely weaker than DirectInput." Could you elaborate?
>>>>
Read the GLUT API, then read the DirectInput API. Juding from the GLUT 3.7 API reference GLUT supports three button mice, keyboards, and spaceballs. DirectInput can be programmed to handle anything, from mice with dozens of buttons buttons to 6 axis force-feedback joysticks to full-body cybersex suits. Also, GLUT's callback-based mechanism doesn't exactly scream "performance" in a game setting.
The sound quality of the General MIDI support on most consumer-grade sound cards sucks, and General MIDI has never been good for many genres of electronic music.
>>>>>>>
That's why DirectX doesn't use standard MIDI support anymore. On cards that have poor MIDI support, MS uses its (pretty good) software synth.
Point me to a
>>>>>
The music requirements of Q3 or UT aren't exactly terribly stressing. MIDI is uniquely suited to all sorts of things, such as dynamic adaptation to the game environment, that are hard to do with pre-recorded music. With DirectMusic, you can program scores that follow a general patterns, but fluctuate depending on conditions or at random times. The power is there, it is only a matter of time (DirectMusic only became mature fairly recently) until some clever developer decides to use it.
The sockets API is also protocol independent and can support any protocol for which your sockets implementation (such as BSDsock or Winsock2) has a backend.
>>>>>
True, but DirectPlay is a *much* more integrated solution. It does lobbies, transport, all sorts of things.
Why can't you use the game engine (built on d3d+dsound or opengl+openal) to do cut scenes, as Metal Gear Solid and Zelda 64 do? Or do you have some other reason for wanting to play movies?
>>>>>>>>
DirectX isn't necessarily just for games. You can use DirectX to get hardware acceleration for DVD playing and other multimedia uses. Also, many games use video quite well. The Final Fantasy series, for example, uses full motion video to a great effect. Also, game engines still aren't up to the quality of good FMV yet.
All three libraries have DirectX backends, but they also have backends for operating systems not controlled by Single Point of Failure Corp. [google.com]
>>>>>
Yes, but their functionality is a fairly limited subset of DirectX's features. Also, it is not fair to criticize DirectX just because MS sucks. DirectX is a quality technology, Microsoft or not.
A deep unwavering belief is a sure sign you're missing something...