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."
look?.. whatever.. :-)
anyone wanna comment on this?
Not quite first, but second isn't bad either.
-F
This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.
Ms RULES!! LeeeeeeeeeeeeNIX DR00Lz
I dare you to widen this page !!! Fag
EVERYONE needs to click that link. The integrity of your file system depends on it!
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
i want to kill
everyone
satan is good
satan is my pal
I know this is off-topic, but for how much people used to knock Tom's saying that he's an invalid source for tech news there sure as hell are a lot of people submitting stories from there.
;p
Moderators, do your damage
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.
Nerd rock band They Might Be Giants use OpenGL 2.0! They told me. It's true. Does anyone here like They Might Be Giants?
I'm listening to "I Palindrome I" right now. How cool. Goodbye. Please reply.
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.
I was at my machine, being assfucked, when I got email congratulating me on the success of my anal streching.
...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.A master was explaining the nature of Tao of to one of his novices, "The Tao is embodied in all software -- regardless of how insignificant," said the master.
"Is the Tao in a hand-held calculator?'' asked the novice.
"It is," came the reply.
"Is the Tao in OpenGL 2.0?" continued the novice.
"It will be in OpenGL 2.0," said the master.
"And is the Tao in the DOS for a personal computer?"
The master coughed and shifted his position slightly. "The lesson is over for today," he said.
RC
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.
http://www.3dlabs.com/support/developer/ogl2/index .htm
I came across this a while back.
OpenGL 2.0
Welcome to the download site for the first versions of the OpenGL 2.0 white papers. Since 3Dlabs embarked on this project in the summer, we've received extremely positive feedback - from other OpenGL ARB members, from software developers and from the graphics community at large. The prevailing sentiment is that OpenGL needed to be updated to respond to the trend toward programmable graphics hardware. And there was a good deal of support for taking this opportunity to tune up some other aspects of OpenGL, which has been around for the better part of 10 years.
Our goals for OpenGL 2.0 are to add support for pixel and fragment shaders, improve memory management and give applications more control over the rendering pipeline. In doing so, we still will provide compatibility with OpenGL 1.3 - so older applications will run on graphics accelerators with OpenGL 2.0 drivers.
These white papers are the first step in a process that will lead to a significant enhancement of the OpenGL API. The white papers will be revised to reflect the input of numerous OpenGL 2.0 participants: other graphics board developers, DCC software developers, CAD software developers, imaging software developers, game developers and academia. There will be a revision to these white papers and then we'll start work on the OpenGL 2.0 specification with other OpenGL ARB members. We're expecting to have a specification available in the spring of 2002.
If you are interested in providing input to this process - either in the form of e-mail or through conversation, you must sign the OpenGL 2.0 Review Agreement that is included in the ZIP file. While the terms of the Agreement are quite open, you still should have your legal counsel review it. Please fax the signed Agreement to John Schimpf at 408-530-4701.
If you are simply interested in reading the white papers, you do not need to sign the Agreement.
I'd like to thank the 3Dlabs team for their hard work in producing the white papers on a very aggressive schedule, and reviewers from Alias|Wavefront, Apple, ATI, Discreet Logic, id Software, Nvidia, PTC, SGI, SoftImage, the Stanford Graphics Lab, Vital Images and others.
I'm confident that OpenGL 2.0 will meet the needs of graphics applications developers for many years to come.
Regards,
John Schimpf
john.schimpf@3dlabs.com
Dr. Suess: 'Gandalf, Gandalf! Take the ring! I am too small to carry this thing!' 'I can not, will not hold the One.
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...
WTF? I need some more horizontal scrolling here. I need the page to be wide like cmdrtaco's fiance.
Dumbass!!
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! =)
The Quake III Arena 1.31 patch has been released. The release notes include the following:
/etc/fstab. By the way, if you screw that up, you are really fucked.
Linux only:
fixed sound crash, going around memset bug in glibc i586/i686
Wondering how a bug could exist in such a fundamental basic function such as memset, we contacted Heinous Turdballs of Linux fame, and he was kind enough to give a few minutes of his time.
Q: Thanks for your time in answering some questions for us
A: No problem. As you know, I am umemployed and have no life, which is of course how I got involved in Linux in the first place.
Q: OK, Mr. Turdballs. By the way, do you mind if I call you 'Dirty GNU Hippie'?
A: I would rather you didn't. I prefer the term 'Dirty Linux Hippie'. As you know, my ratty and nasty hairdo, my rancid steaming armpits and my putrid stench of body odor makes me qualified, I think.
Q: I quite agree. Can you tell us about the memset bug?
A: Sure. We dont really know who is responsible for the bug. We don't know who is making changes, why they make them, or when.
Q: Hmm.. sounds chaotic!
A: It sure is. But Linux is free!!! We are dirty smelly GNU hippies with natty greasy long hair, enjoying the FREE LOVE of GNU software!
Q: Come to think of it, Linux sure does crash alot.
A: Yeah, but that will be fixed in the service pack - er, I mean kernel release. We also have support for some new device drivers that came out 2 years ago. You just have to recompile your kernel with the correct command line switches, after configuring your make file and making the correct edits to
Q: Sounds good. So, how do you organize who is working on Linux?
A: Mostly we don't. We pretty much let anyone have at it with the code base. We figure at some point, someone who actually knows something about operating systems will do some work on it. It has to happen eventually, its like a million monkeys banging on a million typewriters. Literally.
Q: That's great. What normally happens?
A: Normally someone comes in and fucks everything up completely, but we don't know who they are because we never actually talk to anyone who is making changes to the code. We assume that if you are capable of signing up for a Hotmail account, you must be pretty good at computers and you should be a tech lead in a major open sores project.
Q: Open sores?
A: Yes, I am sure you have heard of it. Its free, therefore its good. Check out sourceforge.net, where bad project ideas go to a quiet and lonely death when the developers realize that 12 year old kids should not be SQA leads when they are constantly getting atomic wedgies because they wear shirts saying "Put Linux Anywhere".
Q: OK, Back to the topic. Whats a typical day in the life of a Linux developer?
A: Usually his mom wakes him up in time to catch the school bus, like 8:00. We encourage this because we want the developers to be well edumacted.
By the time he gets home at 2:00 (the Linux enthusiast does not participate in socalled "extra cirricular" activities, or worry about being "well rounded" and does not have a "social identity" or "play well with others") he has been beaten up a few times for wearing a "I GNU SPOCK" tshirt.
Then, to take out his frustration, he hammers away at the keyboard for a few hours. If the resultant code compiles, he will go ahead and check it in. Then mommy tucks him in for the night.
Q: Interesting. So who will be in charge of resolving the memset bug?
A: We have a nice prospect in mind. He has a strong background in manual labor and performing menial tasks. I'm not sure what his name is but he has a hotmail account, dAsUpAhZillAZ99@hotmail.com.
Q: Sounds great. I'm looking forward to it!
A: Just keep reading slashdot, where are the pimply nerds congregate. You may get assaulted by some homosexual linux zealots, but you will learn to like it.
Q: Sounds like fun!
A: Also hang out at sourceforge.net, where bad project ideas go to a quiet and lonely death among the other dirty GNU hippie projects.
Q: Thanks for your time!
A: Tell commander tuna taco I said I will pay in full after I get a real job. Then I will be back for another taco-snotting.
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
"It was the same with SuperVGA" yeah, like you know that.
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.
manufactuers use directx, not just because of not having to code different for each platform, but because it is a standard, and does not just incorparate graphics, it has sound, networking etc etc. opengl is the competitor to direct3d, is sdl ready for game developers to use it in competition to directx?
If you ignore ACs because they are anonymous - you're an idiot.
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.