OpenGL 2.0 White Papers 129
Timothy J. Wood writes "3DLabs has posted a series of white papers on OpenGL 2.0 covering topics such as improving parallelism, timing control, minimizing data movement programmable pixel pack and unpack and (most notably) a proposal for a hardware independent shading language."
Shading Language (Score:5, Interesting)
Can't wait! Hopefully they'll base it on something already well established, ie. Renderman SL.
Way too late. (Score:4, Interesting)
What's another issue is that Microsoft, up till now, has refused to distribute an updated opengl32.dll with their Operating Systems. The current version is the old OpenGL v1.1 compatible version. SGI has said it has distributed a v1.2 version to Microsoft, but for whatever reason, it's not distributed further to the clients. This widens the gap between a non-uniform OpenGL platform still on v1.1, forcing you to use non-standard stuff like vendor-specific extensions and vendor specific opengl loading on one side and the DirectX API on the other. Without Microsoft's help, OpenGL will never be in the front seat again on Windows systems and because they're gaining a lot of marketshare in the workstation market, also not in that typical OpenGL area.
In a nutshell: OpenGL2 good; "Pure" OpenGL bad (Score:4, Interesting)
The synchronisation stuff is pretty handy: certainly, NV_fence has been very useful over the past year or so, and again: vendor-specific paths BAD.
Some of the changes seem to be as much to persuade some-ignorant developers to use OpenGL over D3D - the "black box" aspects of OpenGL are one the more DESIRABLE things about it. Changing those because some D3D guy is saying "I do xyz in D3D and I want the exact same concept to work well in GL because I'm too thick to actually use the right approach for that renderer" seems simply wrong to me.
Uh-oh: UPS just kicked in. Yay mountain storms...
"Pure" OpenGL2 is a terrible mistake. Give vendors the option NOT to support something, and they won't. Then all your old apps+games are up shit creek.
Will finish later when I have stable power again...
The future of OpenGL article (Score:4, Interesting)
Humm... (Score:3, Interesting)
Let me explain, and ignore the hardware issues to some extent:
Looking back at a summary of 3d api's:
Glide: Wickedly fast , easy to write for, obsessivly propritary (IIRC) a la 3dfx.
OpenGL: Fast (glide speed on compliant/correct hardware), moderatly hard to write for initially but easier as time goes by. Open/closed? I honestly forget. Was it documented API's and closed source?
DirectX: Humm. Used to be "Dog ass slow". Moderatly fast, maybe medium speed, very compatible, used to be (maybe still is) hard as hell to write for (this may have changed).
Eventually, If memory recalls correctly, absorbed the "better aspects" of other 3d api's, but also added another degree of difficulty/confusion to implementation.
Now, realize I base this off of my: gaming, memory (oops) and discussion of merits I've read/heard/been privy to.
I'll focus on gaming because that is where the rubber meets the road (or where the 'trons hit the tube).
OpenGL: Quake/GLquake (...or was it GLquack? heh)
Even the "software" mode went from Impressive and Eye opening, but GLquake put the "am" in {higher octave in voice} 'Daaaaaaaammmmmnn'.
Fast and pretty (for its day).
Glide: Quake2, software vs Glide mode. No debate until you can pick your jaw off the floor and keep your mouth closed for more than 5 seconds.
(and stop drooling on my keyboard, dammit).
Glide was the...damn, what is the word?...pinnacle, saviour, "schwing" that low, med end hardware needed to be 'high endish'.
(example: friend of min playing tomb raider on a G3 333...Showed him TR on a p200 w/V2...'fuck you, man' was the response {seg})
DirectX...Thief: Glide vs DX{murmph-snort-bwahahahaha}...Hummmm: 30 fps in glide,
Nowadays, the software has improved incrementally, but the hardware by leaps and bounds...making the s/w look good. Humm.
Sort of the reverse of Glide--software made the h/w shine--here it is the other way around.
I think OpenGL is trying to bring back the "make the hardware shine" days back.
Good luck, because if I understand the way DX is now...it has "absorbed" the api's of GL and Glide and whatever company made the software in the first place (damned if I can find the link...british company I believe).
Well, I've blathered on long enough. Not bashing, just offering my opinion and what I saw and heard in a nutshell.
The eyes don't lie...that is the lips job.
Cheers.
Re:What about.. (Score:3, Interesting)
SDL is a 2D frame buffer and blitting library for the most part (to be pedantic, it also includes input, CD, and minimal sound libraries). The 3D side of SDL is just OpenGL. So if OpenGL goes away, so do 3D graphics in SDL.
wasn't the MS/SGI pack just a ploy to borrow/steal (Score:2, Interesting)
Unfortunately for SGI, there wasn't much to learn from Microsoft and MS is better at deception. As others have mentioned, DX has borrowed/stolen api and ideas from other competing API. It's great for gamers, but bad for the competition.
Is anyone really surprised Microsoft hasn't released new openGL drivers for windows? Unless game development on other platforms gain momentum, DX will eventually win and OpenGL will fade away. It's really shame, since OpenGL and Glide are better, but what does average joe care about. If it runs fast on their windows box, no one really cares. At the current rate of performance improvement in GPU's, no one is really going to care about squeezing out the last ounce of power. Only exception I can think is scientific application that absolutely need every ounce of power. Doing realtime simulations/modeling require insane power. But those are nitch products.
Re:What about.. (Score:2, Interesting)
The input handling is annoying at best. It is similar to handling the WM_KEYDOWN and associated messages. Who want's to do that. That is an inflexible solution. That is why DirectInput was invented. To give a OO, abstracted view of the input devices connected to your machine.
Just to add to that. I really hope SDL [libsdl.org] really takes off. Without trying to be rendundant, developers really need a cross-platform library that matches DirectX. I can't wait until the first major game is released using SDL or something similar. That's the better solution to getting games for Linux rather than WineX or whatever other emulator you want. And contrary to what they claim, Wine is an emulator.
You have to admit that Windoze is king in the PC gaming market. So let's develop a library that allows developers to make games on Windoze...and then get Linux, Mac, etc ports for free.
Fahrenheit (Score:3, Interesting)
Don't get me wrong though. I Love OpenGL. Not only do I consider it the _only_ 3d api, I consider it one of the most professional and designed APIs. It's how an API should be designed.
Perpixel shading is a very welcome addition and should save some texture memory. Imaging all the Q3 shaders implemented in hardware... yum.. And I'm sure you could implement some nice trees with it too..
Although all these nice additions to an API won't stop inventive programming. There will still be a need for billboard trees and highlights..
Even so, the additions to the api will create even more ingenious implementations. Lionheads use of mipmapping for bluring distant objects was ingenious. Look at how far ModeX pushed the pc, or how Mode7 pushed the Nes. With a more powerful API the possibilities appear endless
Unfortunately I don't see drivers appearing for a long time..
-J
Re:Way too late. (Score:3, Interesting)
Hrmmm. Apple is up and coming (again) with its nice PPCs and MacOS X (UNIX!). This and the fact that even MacOS 9 doesn't use Direct X means that software that goes out there for Macs and PCs, and seeks to stick with the growing (again) Apple market will have to stick with OpenGL. Mac doesn't do DirectX (thank GAWD!).
Many still do lots of graphics stuff on Macs, this means OpenGL. Games on Macs will have to be OpenGL.
Fortunately, since there is but a relatively minor difference between MacOS X and Linux/*BSD, support for Macs means easier time getting support for Linux/*BSD in this area. DirectX is not and has not killed OpenGL. It cannot.
Re:In a nutshell: OpenGL2 good; "Pure" OpenGL bad (Score:2, Interesting)
So, yeah: the Stanford PS stuff would be a very nice fit, from the looks of things. Certainly, something along those lines is needed, and it might as well be something that's actually be thrashed around a bit.
One thing that needs to be stressed wrt OpenML is that it's NOT necessarily what we want in OpenGL. While there's a clear overlap in some areas, the ARB needs to make sure that they don't end up kitchen-sinking it. The concern here is dependencies: in the same way that you try to keep classes as loosely coupled as possible, you also don't want your specs tied to each other so that changes in OpenML end up being mirrored slavishly in OpenGL irrespective of whether they actually add real value *from an OpenGL perspective* or not.
I'm absolutely NOT going to buy into the "xyz existing feature should be cut out" approach. Are the non-indexed primitives fundamentally worthless for "real" work? Yeah, pretty much. But they're also an easy way for newbies to mess around with OpenGL and get instant results. Those of us who suffered through the POS that was D3D's execute buffers would prefer that people not need 80 lines of code just to draw a single triangle. Every language needs its "Hello World", and that's basically the function that immediate mode serves.
Even display lists, which I haven't used in many years now, seem to have a place - I gather that on a fair number of non-"consumer class" systems they're still the way to go for a lot of things.
The "focus on this stuff which must be done the best/fastest" argument is a load of bollocks. Developers and IHV's already know what the important fast path is, and have done for years: it's glDrawElements on fully-featured data in CVAs.
The "fewer code paths mean there are fewer ways implementors can screw up their drivers" claim is fundamentally flawed, because we would certainly hope that any vendor who DOES drop "legacy" support goes out of business, so those "old" code paths will still be in every driver. Or at least, every driver for the cards *I'll* own...
Basically, given a decent shading language, we're pretty much set in terms of features. That's BY FAR the most important part of this.
GLsync (i.e. NV_fence extended and renamed) is a nice thing, although it's as much a matter of doing the Right Thing for the future as anything else, since we can EASILY saturate GeForce2-class cards ATM. Saving a few microseconds in setup/transform is all well and good, but since the true bottleneck for common apps (i.e. games) right now is memory bandwidth, the actual gains are basically non-existent. Still, there are other apps that DO benefit greatly from the improved parallelism, and like I say it's the Right Thing anyway.
The pack/unpack features are nice for certain effects, but they're clearly an example of "add this predominantly useless feature just to shut D3D people up". While a pack processor MAY lend itself to something useful (though given what's available through the pixel/vertex shaders that's a bit iffy), the unpack aspects seem almost completely pointless to me. Basically, the amount of "useful" work you can do in software is close to nil, and ANY glReadPixels-style call is going to bog because you're stalling the pipeline. That the other costs of such an action can be minimised is all very lovely, but next to the stall they're absolutely trivial.
The memory management is a *shrug* feature. Useful in some places, and I expect I'll whore certain aspects of it once it's available, but in reality it's nothing like as big a deal as some people seem to think - again, most of it is "D3D has this and we don't". Strangely enough though, this perceived lack doesn't stop my renderer or, say, Quake3's consistently outperforming any D3D-based one, does it?
700,000 OpenGL systems sold in past 4 days alone! (Score:1, Interesting)