Well I spent a lot of time working just with C# and some things slipped my mind from my last attack at studying Shaderlab+Cg.
I’m doing a self-study review of shader programming over-all, and I’m also making some tutorial-like documents with example shaders; both so I can reference them, and because I’m not happy with the introductions to shader programming in Unity I found. No disrespect to the people putting tutorials out there, but piecing the whole picture together was pretty difficult between learning C# and 3D asset / animation basics / Blender. I’m gonna do my own breakdown of how to get started with some basic stuff so I can share that with people, collecting some stuff out of places like the Nvidia CG manual that are relevant when you’re doing it.
Is HLSL a lot different than Cg, or just more up-to-date? Will we still be using Cg? Basically I know writing vertex + fragment functions will be relevant: will shaderlab be obsolete? Will I be able to write vertex+fragment shaders using similar formatting for the new pipelines?
Shaderlab is primarily just a way for setting up the UI properties for a material using the shader, it doesn’t have any real bearing on the shader coding apart from potentially setting some keywords. So no, it’s not likely to go anywhere anytime soon.
HLSL and CG are very similar, CG is more easily compiled into various other APIs.
You still use shaderlab when writing vertex/frag shaders.
Unity compiles the CG to the appropriate language versions and variants being asked for being asked for, it’s a combination of the target API shader code and assembly. You can view it for yourself by just clicking “compile and show code” on a given shader.
Unity no longer uses Cg, regardless of what the official documentation says.
Shaders are written in HLSL or optionally directly in GLSL. Things like “CGPROGRAM” the .cginc file extension and calling the pixel shader the fragment shader are holdovers from when Unity was CG based, but if you look at more recent work in Unity 2018 you’ll see many are being updated to use HLSLPROGRAM, and .hlsl, though they’re still “fragment” shaders. For the most part Cg and DirectX 9 HLSL are identical in terms of the shader code, so Unity switching from the former to the later went mostly unnoticed by most. There are a small handful of Cg specific functions or overrides that have no direct equivalent in HLSL, and these now either exist as custom functions or #define lines in the various include files, or in at least one case simply causes an error on compile.
Unity used to use Cg because it was billed as a shader language that automatically compiled to both HLSL and GLSL. However Nvidia stopped development after Unity started using it, and they completely abandoned it in 2012. Unity moved over to using hlsl2glsl by ATI, eventually forking and effectively taking over that project. Today they support translating from HLSL to far more shader languages than Cg ever could, as almost every console has their own unique language, on top of DirectX 11 & 12 HLSL, Vulkan SPIR-V, Metal MSL, and the many flavors of OpenGL ES GLSL.
The Nvidia Cg documentation remains a useful tool even though it isn’t actually used by Unity simply because it’s well written documentation with nice example implementation code to help explain what many functions actually do (or at least roughly what they are expected to do).
Unity compiles the CG to the appropriate language versions and variants being asked for being asked for, it’s a combination of the target API shader code and assembly. You can view it for yourself by just clicking “compile and show code” on a given shader.
This much I knew, since what you program is only a fragment and the graphics api - DirectX or OpenGL does the rest.
