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
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.
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.
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.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 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...
"Blue Screens" are caused by a fault in the Kernel or something writing to memory it's not meant to be writing to.
This is almost correct. Blue screens are caused by a fault in *kernel mode* (Ring 0 on Intel architecture), which is not equivalent to "in the kernel." WDM drivers (like the nVidia graphics drivers), as well as all NT drivers and in fact the entire USER and GDI subsystem (since NT4), all run in kernel mode. None of these components are technically the kernel. Btw, wild pointer writes are a kind of "fault in kernel mode."
Assuming normal user processes can only write to their own memory space, then it is a fault of the kernel.
No argument there. See also this page. But as I already pointed out, the nVidia driver runs in kernel mode, not user mode, so this argument is not relevant.
Sure, Open GL might be buggy,
OpenGL can't be buggy, it's just a specification. nVidia's implementation is buggy, like I said. This is especially apparent considering that the blue screen errors have the name of nVidia's kernel mode driver in them.
but it's your Windows kernel that's causing the blue screen.
Again, confusing "the Kernel" with "kernel mode." Hey, I hate Windows as much as the next guy, but that's no reason to post incorrect technical information about it and hope nobody will realize you're blowing smoke out your ass. Next time, do a little more research first.
---Windows 2000/XP stable? safe? secure? 5 lines of simple C code say otherwise!
What exactly leads you to say otherwise? Presumably personal experience, rather than just a desire to trash nVidia, but compared to what? Given that 3D game luminaries have repeatedly stated they prefer nVidia's OpenGL drivers to those from ATI or (shudder) Matrox, that really only leaves the few remaining "professional space" vendors (sgi, 3DLabs), and I can't imagine they're universally perfect either.
Perhaps your perspective needs widening? Or perhaps you're running into the same bug over & over and have not bothered to notify nVidia about it? (or perhaps they just think it too isolated a case to get a high priority)
Why would anyone engrave "Elbereth"?
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).