opinions about cg 1.5?
Author
Hello,
I'm starting a new project using OpenGL/GLSL aimed to be quite platform independant. I really need an effect format for GLSL and now cg has been digged out of it's grave and supports GLSL as target profile.
Rumors had it that the cg compiler didn't produce optimal code for other hardware than nvidia. Is this still true when using GLSL as target because the produced GLSL code is optimized by the OpenGL ICD later?
Are there any alternative effect formats I could use? I read about ColladaFX but is it really suited to be used directly in an engine or just for exchanging FX data in the content pipeline?
Thank you for your opinions.
Markus
the thing i like about cg is its similarity to dx hlsl, makes writting shaders easier to port. plus you can pretty much load shaders from fx composer or render monkey strait in to your game.
also i recon it compiles best on nvidia though simple because they wrote it and can optimise for thier hardware, but this is just a guess
also i recon it compiles best on nvidia though simple because they wrote it and can optimise for thier hardware, but this is just a guess
I agree with supagu. Cg is very similarity to HLSL which makes writting shaders easier to port.
One thing i like to add is that Cg 1.5 is still currently in beta. I havent experienced any problems so far but the documentation has alot of "To be written" comments.
One thing i like to add is that Cg 1.5 is still currently in beta. I havent experienced any problems so far but the documentation has alot of "To be written" comments.
We just released the final version of 1.5 and the documentation no longer has "to be written" anymore. Check it out!
Quote:Original post by supagu
also i recon it compiles best on nvidia though simple because they wrote it and can optimise for thier hardware, but this is just a guess
With the GLSL profile in Cg, this is no longer the case since the GLSL compiler is in the driver. We just translate to the GLSL language and let the IHV's driver do the dirty work. :) We have optimized the GLSL translation a lot so be sure to use 1.5 final now.
A lot of that should be reduced with the new version but don't expect all redundancy to be gone. The reason is because of GL's state model. It really is GL's fault this happens, not ours.
When setting a parameter, we have to be sure the correct program for that parameter is the one bound. Since we have no way of knowing what the app is doing, the app could change to a different bound program using a GL call somewhere and if we just set the parameter anyway, you'd get an error or very wrong results. The only way to not rebind like that over and over for each parameter set is to do a glGet to make sure the bound program state hasn't changed.
With the new things we're adding to Cg right now combined with the new advancements in OpenGL, this problem will go away. A better solution is comming.
When setting a parameter, we have to be sure the correct program for that parameter is the one bound. Since we have no way of knowing what the app is doing, the app could change to a different bound program using a GL call somewhere and if we just set the parameter anyway, you'd get an error or very wrong results. The only way to not rebind like that over and over for each parameter set is to do a glGet to make sure the bound program state hasn't changed.
With the new things we're adding to Cg right now combined with the new advancements in OpenGL, this problem will go away. A better solution is comming.
Oh BTW, cgGL has always had this redundant binding problem. It's just the nature of GL. It just so happens that people started looking at the GL trace calls during the time 1.5 has been out which made it look like a 1.5 issue.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
