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."

Comments

The Standard is always long to come

[gounthar]

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...

Re:The Standard is always long to come

[Starship Trooper]

As long as IDSoftware uses OpenGL, there will be life left for it on the games industry.

Rarely do you see something on Slashdot that contains as much truth as that statement. Microsoft focuses their best development efforts into free products designed to crush other people's standards. OpenGL has been a continuing thorn in their side, and their ferocious work on Direct3D is aimed at obtaining the complete dominance they're used to in the gaming market. Jon Carmack has (almost singlehandedly) prevented them from doing this, and the ensuing competition has left consumers and game developers with... two really good standards. I could almost feel good about this, if it weren't for the fact that iD is competing with a monopoly, and is succeeding only because they remain privately owned and hold their market presence through sheer programming prowess.

If only we had someone like Carmack to write Office software for Linux.

Lots of programmable processors

[Dante'sPrayer]

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.

Re:The problem with OpenGL on Windows...

[IPFreely]

I'd guess the hope is that once OpenGL 2.0 stablizes, then OpenGL 1.3 compatibility can be dropped and we're back to two standards.

THEN, maybe Micorsoft and the OpenGL group can try come to terms and maybe bring DirectX compatibility closer to OpenGL (Or vs/vs) and have a single standard.

It sounded like Microsoft wanted to come into compliance with OpenGL before, but dropped it because the OpenGL group moved too slowly. (Insert your own M$ conspiricy theory here, but I suspect they really honestly tried, and if a good opportunity arose, would come back and try again).

Re:The problem with OpenGL on Windows...

[Error27]

I was wonderring the same thing.

I have heard bad things about nVidea on Linux. Part of the problem was a bug in certain AMD mother-boards that got fixed in the kernel two months ago. (AMD mother-boards in the sense that they worked with AMD cpus. AMD doesn't make mother boards itself). I think the problem was probably publicized more because people don't like the close source driver.

I don't remember hearing bad things about nVidea on windows.