And most important of all, glslang is, at present, the #1 cause of OpenGL implementation headaches. All of the other annoyances are annoyances, but glslang implementations have always been spotty. From nVidia’s refusal to stop allowing non-compilant glslang code, to ATi’s various failed attempts at implementing the language.
As I am a new developer using glslang, I don’t quite understand this. Why are there implementation headaches in the GLSL? Isn’t there supposed to be a 3DLabs provided reference parser implementation, so why can’t ATi, nVidia and the others to just use that?
As I am a new developer using glslang, I don’t quite understand this. Why are there implementation headaches in the GLSL? Isn’t there supposed to be a 3DLabs provided reference parser implementation, so why can’t ATi, nVidia and the others to just use that?
ATI uses it but I imagine they have updated.
nVidia uses their Cg codebase instead of 3dlabs.
Parsing is only the first stage.
There is optimization to do in terms of temp register usage, code simplification, const register mapping. It gets more complex when you have to deal with 3 or 4 generations of GPUs.
Next you have the driver’s logic to perfect.
“oh, the user called glUniform 15 times in sequence, shall we send this to the GPU now?”
“oh wait, he called glLightf, is there a shader bound, should we update that constant register?”
Maybe I missed something, but one potential problem area with GLSL, once you remove the built-ins, is replacing the functionality of gl_*In[] in the geometry shader stage.
I wonder what the replacement is going to look like, or how one might go about achieving the same result with as much grace and aplomb.
I am not tracking this very closely (so I could be wrong), but I don’t believe GLSL issues are gating GL3 at present.
Personally, I think the question of the “ideal” model for programmable shading is still unanswered. Like Korval, I think a simpler machine abstraction (or abstractions! - multiple abstractions like SM2, SM3, etc, exist in the driver whether it tries to hide them from the developer or not) is very attractive for driver implementation. At the same time, as GPUs support more flexible and general-purpose execution environments, the desire to use more powerful source-level languages increases. Languages like (but not limited to) C++ and C#.
Ultimately, I find it hard to imagine how we won’t wind up with a compiler/linker/loader environment on the GPU much like we have with conventional CPU programming. I would rather leave the arguments over high-level language definition to the Stroustrups of the world. I feel pretty sure they’ll do a better job than me. And I don’t think it’s helpful for every API to have its own non-portable high-level language when portability needn’t be a problem.
Since the ARB wants S3TC in GL3 they might be trying to negotiate a S3TC patent licence covering all OpenGL implementations (like Microsoft did with DirectX).
I hope they do (or remove S3TC from GL3).
C is today’s portable assembler. Why not let the Stroustrups layer their high-level languages (potentially including stuff like object-orientation or templates) on top of GLSL?
I think this is more future-proof (in the sense of working well on future GPU architectures) than some lower level language like SMwhatever that might not map so well to the future’s hardware.
And I don’t think it’s helpful for every API to have its own non-portable high-level language when portability needn’t be a problem.