OGL 2.0 standard shading language... is NOT Cg!!!
Well, I think nVIDIA tried alot to make Cg to be the standard shading language for the OpenGL 2.0 but, sorry! not happening...
The compitition was between nVIDIA's Cg and 3DLAB's Glslang... GL slang... haha... ;)
so you are saying that OpenGL 2.0 is the 3dLabs API essentially? do you have a link confirming this?
As far as I know, this is old news. Regardless, OpenGL 2.0 is not out yet, so we don't know for certain what the final lanaguage idea will be.
However, I do support one major facet of 3DLabs' version of the spec: standardize the HLSL, with vendor-specific assembly/machine language, as well as compilers.
I also like the cross-API nature of nVidia's Cg, however, so I would personally like it if the two languages were merged, keeping both of these facets in the final design.
One other thing: it certainly seems to me like a standardized HLSL will require support for auto-multipass for fragment programs, and CPU-assist for vertex programs.
Whatever they do, it'll be cool with me.
I seem to be getting more and more impressed with Microsoft stuff over the competition. However, I'm wierd. Details.
Personally, I think it matters a huge amount which direction is taken today. After all, the direction that is taken today will effect events years down the line.
As a quick case in point, think of the x86 architecture. This instruction set has, quite simply, held back the PC industry by huge amounts.
For example, if it would have been possible at the time the x86 code was originally released to have all software run in a multiplatform emulation layer (akin to Java), there would be performance problems at first, but in the long run, things would be running far faster than they are today. Of course, back then, there just wasn't enough performance to spare, so it wasn't an option.
Btw, if you doubt this, just look at API's used in 3D rendering. In particular, consider a proprietary API: Glide. That API was much faster than Direct3D or OpenGL in the majority of games, but today hardware has more than picked up that slack. While OpenGL and Direct3D may never be quite as fast as a lower-level, vendor-specific API, they end up being faster in the long run because of the ease of development and the ability for hardware developers to change much more of the hardware than with a lower-level API (one of the reasons I believe the Voodoo4/5 was so behind technologically...clinging to Glide made it much harder to implement new features...).
Today, it's a similar scenario. That is, a good game designer might be able to write a shader that is more efficient on today's hardware than any compiler could do.
But that same assembly-language program might end up running much slower than one compiled by a higher-level language for the next generation of hardware.
The other thing to keep an eye on is program length. The simple fact is that it quickly becomes impractical to write nothing but assembly-language shaders as programs approach hundreds of lines of assembly, let alone optimal ones. In this situation, a compiler can do a much better job at both keeping the code readable (minimizing programming errors), and optimization of code.
By contrast, it looks right now like the direction DX9 is taking is to attempt to standardize the assembly, leaving HLSL as sort of an "extra." This means, to me, that HLSL is put it not as a primary development tool, but more as a prototyping tool (i.e. runtime compiling will be uncommon).
|All times are GMT -5. The time now is 03:54 AM.|
Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.