Slashdot Mirror
On the Subject of OpenGL 2.0
zendal writes "The danger with pixel shaders and vertex shaders is that there is no standard for programmability of graphics hardware. A schism has formed within DirectX between the competing demands of GPU makers Nvidia and ATI. Noted analyst Jon Peddie gives THG an exclusive first look at a White Paper on how OpenGL 2.0 is trying to bring stability and open standards to programmable graphics and GPUs."
In every emerging technology, there will always be a delay between the first appearance and the outcome of an almighty standard.
It was the same with SuperVGA (took about 2 years), Internet Protocols (still on going, W3C is struggling for standards) and now OpenGL and DirectX.
OpenGL 2.0 seems pretty much like the definitive solution...
Violence is the last refuge of the incompetent - Salvor Hardin
It seems sometimes that standards are a bad thing. If the OpenGL extensions would readily be incorporated into the main specs like DX internal extensions are, OpenGL could have been on par with DirectX by now.
But no, stick to the standards when the every thing else has changed.
You'd be hard pressed to say this is surprising. I can't recall a standard piece of computer hardware (like a processor or so) that hasn't had these kind of not-too-significant-non-standardness at some point in it's history.
Is it me or is this a standard marketing technique by a company that wants domination?
A most interesting point is right at the end of the article:
One of the key points stressed by the ARB is that the "open" needs to go back into OpenGL. The group has pledged that all ideas submitted for OpenGL, if adopted, are then open for use and not licensable as IP.
So, they won't pull a "Rambus" here... hopefully.
...has always been that driver support is buggy. nVidia is notoriously bad at this; their DirectX drivers are quite stable, but OpenGL blue screens left and right (especially with a lot of detail in the scene graph). I always wondered why they even bothered to include OpenGL support in their drivers, although I suppose with such a major standard they have pretty much no choice.
Now, with OpenGL 2.0, if they have to support three different API's, isn't driver quality going to suffer even more? Oh well, ATI has been getting a lot better recently, I guess we can always switch to them. :-)
---Crash Windows XP with just a simple printf!
sounds really great, but i don't see it happening... nVidia, ATI, Voodoo, whomever will alway wanna do the next cool great thing and that's why the extensions are available...
And we all know MS wants DirectX to rule them all. OpenGL works, and is an open standard by definition. Extensions in there make life interesting certainly, but you pretty much know what you're getting into when you try NV_texture_rectangle or NV_texture_shader. (hint, the NV stands for NVidia) sure you can find out in directx if the hardware supports XYZ before you call it, but i find the naming convention of OpenGL a bit more coder friendly. it's readily obvious if you're trying something that's not supported across the specification.
I don't think so. The 2.0 proposal was brought up at the September 2001 OpenGL ARB meeting -- about five months ago. And the OpenGL 2.0 White Paper has been since at least November. While this stuff is important, there's nothing new about it. (Good thing, too; good standards take time.)
GollyGee Blocks -- 3D creativity software for kids.
>how OpenGL 2.0 is trying to bring
>stability and open standards to
>programmable graphics and GPUs
The problem is that there are quite a few companies out there that do not want open standards because it gives them a competitive edge over other companies, end users, and organizations; even if it actually helps them as well. (And you know who you are).
A vertex processor, fragment, pack and unpack are going to be supported.
- Vertex processing is targeted to replace lighting, materials and coordinate transformations, all on hardware level using a high-level API.
- Fragment processing will let a better access to texture memory, surely allowing some nifty effects like texture animation or pseudo-refraction on hot air.
- The pack and unpack processors will allow a faster transmission of vertex data through the buses, hopefully reducing the bandwith bottleneck.
All of those can and are at the present being implemented on software, but will be nice to see them implemented on hardware.I will. In typical Tom fashion, this article uses a lot of words to express a small bit of information. From my reading, I get that OpenGL 2.0 is taking a long time to finalize, and the OpenGL ARB is trying to standardize a lot of the extensions without hitting copyright/Intellectual Property/etc issues. A decent read, but it needs to be re-written by someone who isn't so wordy.
RagManX
X11R6 is old enough now so how about X12 that has OpenGL (and lots of other improvements) build in?
So Xlib would have it incorporated and it would be much faster than as is done now of building it
on top of Xlib and extensions.
I bet on string based ATI
the Nvidia solution you had to licence from them then the ARB did not want to get into that ugly mess only when ATI after being given time and incentive (from MS to do DirectX 8.1) did NVidia change their terms even then its a kludge
I quite like the ATI solution and they right from the start made it so that anyone could implement it, Yay for standards (-;
regards
john jones
I think this is a cunning move by 3Dlabs - Their business is being threatened by nVidia and their Quadro range - it'll be interesting to see how unbiased they can manage to be when generating the spec.
Otherwise, I think it's a good idea. It'd be nice to see OpenGL keeping up with (or even outshining) DirectX...
MPEG was longtime THE de facto standart for video.. now they want a penny _EVERYTIME_ a film is played.. sorry mpeg, i'll never use you again. DivX owns! =)
I can't speak much to DirectX, but you can also query out what extensions the hardware (or at the very least ICD) supports in OpenGL. But even if you don't, an unsupported op is treated like a non-op anyway, so even if you call an NV_ extension on an ATI board, it shouldn't do any harm (or am I incorrect?).
Regardless, the extensibility of OGL is a double edged sword. Really, it does make features board-specific, which is not the point of OGL. On the other hand, allowing these extensions does drive the future of the standard. It lets everyone throw what they got out in the public and see what sticks.
Personally, I'm glad that OGL has huge gaps in standards updates, unlike DX. After all, it *is* a standard, and should be relatively static. Each new version of the standard should be absolutely positively a good standard. Anything missing can be used as an extension in the meantime and added to the next version 4-6 years down the road. This is the strongest point of OpenGL vs DirectX, there is a controlling body of many companies, rather than one main controller (MS). Bringing together the experience of co's like MS, SGI, NVIDIA, ATI, etc not only makes the standard better but adds a level of comfort to the users of the standard.
Basically, my point is that OGL standards *should* take a long time to finalize. Everyone seems to forget that standards should be able to last a long time. OGL is now on v1.2/1.3 after an evolution of around 10 years, while DX is nearing DX9 since, what, 1995 or so?
Where are we going and why am I in this handbasket?
The fact alone that it is more neutral to what OS you use makes it much better that DirectX. I really hope those VB developers get an easy way to use OpenGL instead of DirectX.
HTTP/1.1 400
IMHO, its time to SCRAP OpenGL and start over,
Modern hardware support is critical, interfacing with what seems to be a diminishing number of compatile drivers is critical. Keeping the spec out of MS control is critical.
There are MANY options to a ground up rewrite of OpenGL supporting CURRENT hardware, working with the Hardware vendors directly is the key.
I understand this is not an undertaking to be taken lightly, I have been working on options and looking for cross platform alternatives for a couple of months up to now, there are several promising alternatives, I hope to present these in a short time.
OpenGL's time is over it seems, MS is working with vendors explicitly to limit their support, there remain major differences of opinon in it developer base and schisms seem to be forming in it goals.
Sig went tro...aahemmm.....fishing........
"OpenGL 2.0 is trying to bring stability and open standards to programmable graphics and GPUs."
:)
Uh...isn't that what OpenGL did in the first place?
This is a technology that's been around for years and isn't verion 9 yet
A lame, fuzzy article with a superficial understanding of the issues involved in creating rendering pipelines. Just go here if you want to start reading tech docs.
sounds really great, but i don't see it happening... nVidia, ATI, Voodoo, whomever will alway wanna do the next cool great thing and that's why the extensions are available...
As an OpenGL developer, I can truely say: Extensions SUCK ASS. I've been keeping up with extensions with my DemoGL library for some time now, but it's a battle you can't win, there is no consistency, no 1 clear API, but there are a few: nVidiaGL (with the nv extensions) and ATIGL, with the ATI(X) extensions. Oh, and some drivers support OpenGL 1.2, others support OpenGL 1.3... Yeah, nice and all. (not).
And we all know MS wants DirectX to rule them all. OpenGL works, and is an open standard by definition.
OpenGL is a standard, but not 'open'. You don't have anything to say about what OpenGL will be in the next version. The ARB does, but they also are limited, since nVidia and ATI are always ahead of them, and because what they offer in propriety extensions is _THE_ stuff to use in bleeding edge 3D graphics, using an 'older' ARB standard is not the way to go to stay ahead of the pack of competitors.
Extensions in there make life interesting certainly, but you pretty much know what you're getting into when you try NV_texture_rectangle or NV_texture_shader.
Oh, do you? What if I have an ATI radeon 8500, these extensions are not available, I have to use ATI's syntaxis. But what's worse: you have to rely on the cardmanufacturers documentation for these extensions. I don't know if you've tried to figure out how to do cubemapping and compressed textures using nVidia's docs, but it's a pain to say the least.
With DirectX, there is one clear manual, one clear API and no zillion codepaths to code to support OpenGL 1.1, 1.2, 1.3, nVidia's extensions, ATI's extensions etc.
Never underestimate the relief of true separation of Religion and State.
Aww , poor little boy. Did mommy shout at you when you messed your pants again this morning?
You really should get potty trained you know.
OpenGL 2.0 seems to be in the right place at the right time. If the 2.0 standard can sanely standardize the programming of pixel and vertex shaders, OpenGL might be given the boost it needs to start overtaking Direct3D's hold on the gaming market. And once development moves to OpenGL, it's one step closer to widespread releases on (insert favorite OpenGL friendly operating system here) and a loosening of the MS stranglehold on computer games.
On the other hand, if this OpenGL extension craziness continues on as it has been, the project might collapse into a tangled and unsalvageable mess. The OpenGL standards people have one shot at doing this right, and whether or not they pull it off will determine their long term success or failure.
Comments should be like skirts. Short enough to keep your attention, but long enough to cover the subject
It's especially problematic for graphics standards. GKS, which was hideously based on ideas from pen plotters, still dominated much of the 1980's. Open GL has been pretty good, but it's stuck in some 1980's ideas. For example, the strict ordering of primitives makes sense in a world of bit blasters where double-buffering and Z-buffering are expensive, but it makes little sense on modern hardware and even worse makes it impossible to implement some of the better modern techniques (such as hierarchical global scanline algorithms). Some day, we're going to have systems that cost less than a million dollars that can do real-time ray-tracing, radiosity, and other solutions of the Rendering Equation.
The only way OpenGL is open is that core OpenGL (and ARB extenstions) can be implemented without getting into patent trouble ... and thats true for D3D too, except with D3D everything is in the core so it being open is a little more meaningfull.
Hahaha, guess it got to you :-)
You're still a dumbass BTW!
OpenGL's success came from the fact that it was leading the hardware, it didnt need to evolve fast since hardware had not caught up. Today's situation is wildly different.
... its design by committee at its worst, every member has been send with an agenda. Now that they have a single enemy to unite against (NVIDIA) things are moving a little more smoothly than usual, but on the whole a single independent party defining a standard will probably result in the best deal for joe the consumer.
Your view on how the ARB works is slightly optimistic IMO
While on the topic of graphics, one should check out John Carmack's latest
plan.
A interesting read about the ATI8500 vs. GF4.
He also says:"Do not buy a GeForce4-MX for Doom."
The "Specification Overview" pdf from the 3dlabs white paper page is pretty interesting. It has a list of over 250 opengl extensions and what happens to them in opengl 2.
Basically they all disapear.
Some have already become part of the standard. Some are added to the standard in opengl 2. Some just disapear altogether.
But the large majority of them are not needed anymore when you have programability, memory management and opengl objects etc.
To me that means that opengl 2 is way more flexible. Flexible enough so that we won't need as many extensions in the future.
And that's pretty cool.
(BTW: Brian Paul is a member of the ARB. He wrote on the mesa list that he hasn't been following the opengl 2 process very closely but that he expected that they would probably want him to write a free implementation).
No. Well, technically it is available as middleware, but no-one in their right mind would use it.
Apparently the Game Cube libraries look remarkably similar to OpenGL though.
There's the artistic question of whether textures should be drawn or programmed. In the film industry, everybody except Pixar mostly draws, while Pixar writes RenderMan shaders for everything. (The whole OpenGL vertex/pixel shader thing is basically a lightweight version of RenderMan). Artists would rather have more texture memory than programmability.
A whole language for writing data pack and unpack functions is overkill. Pack/unpack doesn't do that much. It's not like the graphics board is going to unpack a JPEG image. It's just converting bitplane order, depth, and such. OpenGL already has quite a number of modes for texture storage; this just handles the people who wanted their favorite storage mode supported. A more declarative mechanism would have been more appropriate.
Can someone truely explain how DX 8.1 is so bad in comparison to OpenGL 1.3.
.5 billion home users at some point.
When I sit down and do the math in terms of vendors/coders writting to the two API's, in terms of features and supported functions, etc... I can't come up with anything that really points to OpenGL being superior in any way.
Now, this is not about high end graphics design, rendering, etc... I am talking home use. Big difference from professional design and implimentation for various things, I know.
Unless I am mistaken, the 2.0 standards would effect all sectors of graphical computing code in the future if adopted, correct? That being the case, then it would effect
Don't bash... I am not holding a MS flag and waving it, I am just examining the two critically ( and trying hard to not let my experience in home graphics and gaming taint it). I do understand that how drivers are written to interface with hardware, and how software layers interact and call/read on the driver effect performance and stabilty... I am just talking features here.
First, OpenGl is far more stable than DX on NVidia cards. It is only outside that market that this is sometimes not true. However, you have to keep your drivers updated. Graphics programmers typically push the newest extensions and that will break old drivers. In practice, I virtually never lock up my computer using GL. However, it is trivial to lock up a system in DX. Of course, we won't even go into the compatibility of non-Windows systems with DX because that's, well, obvious, yes?
Now don't take this as a diatribe against DX. I use it frequently, and for some projects it's the thing to use. It's easy to develop quick apps, prototypes in particular, and obviously with the Xbox it's the thing to do.
As for whether a generic shader language should go into OpenGL 2, well, everyone has their opinion on that. Personally, I think it's a bad, bad, bad idea. Any pixel or vertex shader language that is implemented now will be out of date in short order. Anyone who has used these shader languages knows how crippled they are. Ergo, you'd implement these standards in OpenGl 2 and everyone would use the vendor supplied extensions instead anyway. How does that improve OpenGL?
DX has made many mistakes with regard to implementing these kind of features. They're barely used in one version of D3D and become white elephants in subsequent versions.
Fundamentally, the OpenGL standard is an API core. It only supports a minimal core level of functionality that can reasonably be expected to persist over time. Everything else should be an extension. It's not like it's hard to figure extensions out, after all. The vendors do supply documentation, and the Opengl repository maintains a list of all extension documentation. Then you can freely recognize which extensions are garbage and not use them, rather than be saddled with them for a decade.
John Bible
Bioware
In every emerging technology, there will always be a delay between the first appearance and the outcome of an almighty standard.
Actually, OpenGL (which was very much an almighty standard) was famous for being very forward-looking. Rather than ratifying commonly-available functionality, it defined a standard for hardware companies to aspire to and work towards. The actual hardware came later; for a while, many OpenGL core features were available only on extremely expensive SGI big-iron.
Incidentally, OpenGL's role as defining the long-term goal for hardware has now been usurped, not by OpenGL2.0 or D3D but by Renderman.
no. you're wrong.
They are used extensively in film graphics. All other major renderers, not just RenderMan, have shader languages. Ie vMantra, Maya, LightWave, etc.
Shaders do not "replace" texture maps. One of the most-used functions in a shader is to look up a given uv coordinate in a texture map and use the resulting color to control the shader. In fact most of the shaders we write involve manipulating texture maps, which were (as you said) painted by hand. We can do much more interesting things with textures other than just using them to color the surface!
I agree about the pack/unpack mess. I think all useful image formats could be described by these items: number of bits per sample (limited to powers of 2), number of samples per pixel, delta between each pixel (so they can be further apart than the number of samples or you can trivially mirror it with negative numbers), delta between each line (allows a "window" to be cut out of a larger image, allows flipping upside-down, and allows 90 degree rotations by adjusting both deltas). There is no need to describe what the samples are, that can be determined from the count and what function you are calling, we can insist on RGBA order for normal images.
You really should know better than to use version numbers as a sign of progression. First, Direct3D only appeared in DirectX 3. Second, there was no DirectX 4 (God knows why). Third, the first few itterations of Direct3D were awful.
i know that most people on slashdot are open source all the way, so am i, i am actully learning OpenGl right now, and writing my own 3d-wolrd, but there some one out there who would argue for DirectX, and i am curies to hear his counter point... thanks... p.s. the openGL will bring long lasted benefits to 3d world...
Who controls the information, controls the world...
Last month M$ already signed death warrent to OpenGL by buying SGI patents [1], so don't expect any other 3d standard but DirectX in very near future.
1 82 4256&mode=thread
[1]http://slashdot.org/article.pl?sid=02/01/16/
Hopefully the feds will keep Microsoft from doing anything. They are like the shark in Jaws, feeding on the little children on the beach. They've been at it for too long. I say it's time to start a revolution! Stop Microsoft before it's too late. If the law won't save us, maybe harpoons will.
I actually think standardizing stuff like vertex and pixel shaders is the wrong thing to do right now - there are too many differences between the major implementations that smoothing them over in a universal API would be costly/inelegant, and the feature sets are changing very rapidly (new texture modes every 6 months!)... It would be smarter to wait a year or two, when things will have settled down a bit, and then write the standard in stone.
They don't sell gaming boards, they well professional boards - they're competing with NVidia's Quadro cards, not with the GeForce cards.
3DLabs are actually (I believe) the best selling make of professional graphics cards - they're not a wannabe by any stretch of the imagination.
himi
My very own DeCSS mirror.