It's similar to preshaders (we thought of the idea independently, and call it something different in the book... uniform lifting... but it is basically the same idea). So I guess it's a little unfair to say "an optimization that no other shading language provides". It also would be possible, in theory, for OpenGL SL implementations to provide this optimization.
In Sh, though, this optimization is internal and automatic, and so invisible to the user. It's important to do it that way, because the shader algebra in Sh lets you turn uniforms into inputs and vice-versa. If you convert an input to a uniform, new uniform lifting optimizations become available, and vice-versa. The system keeps track of the "preshaders" for you in this case, and actually includes a dependency tracking and lazy update system internally. You can create your own "dependent uniforms" if you want, but in general it's unnecessary for a user to worry about or explicitly define lifted computations.
The idea is also related to hoisting computations out of loops. If you think of the data-parallel shading of vertices or fragments as a loop over all vertices and fragments...
Yes, our approach provides more optimization opportunity. For instance, computations that depend only on uniforms can be lifted out of the shaders to the host (the next release of Sh will do this; see the post by Stefanus). There are also various transformations on programs that we can do, like the shader algebra, if we have a higher-level representation than a string. Our system also allows introspection, i.e. you can ask a program object what its inputs and outputs are, what the types of those inputs are, etc. Finally, by using our own representation, we can map to multiple backends; the same program object can be compiled (long after definition time) to both the CPU and the GPU. This is handy if you're not sure you want to run a given simulation kernel on the host or on the GPU to load-balance an application. Using our system, you can defer that decision to installation time.
I should point out that it seems the original poster may not have been aware that modern GPUs can do floating-point natively. We played around with using rational arithmetic on older cards, but...
But anyways, it's true that the FP on GPUs takes a bunch of shortcuts, doesn't handle various things the way it's supposed to according to the IEEE spec, drops low-order bits for some cards, etc. etc. The work at Stanford is certainly valuable in characterizing these issues. However, I suspect the next generation of cards will address most of these issues, and we'll see both higher performance and greater adherance to the IEEE spec in future cards, and possibly higher precision, making GPUs more suitable for scientific applications. And remember, "future" in the graphics industry means in one year. "Far future" is two years;-)
In our defense... the OpenGL Shading Language is defined the same way. There are very few cards/drivers (that you can afford) that can currently implement *everything* in the OpenGL SL spec, or described in the OpenGL SL book, and current implementations are missing a few things here and there. There are things like true data-dependent control flow, derivatives, and arbitrary-length shaders, that are very hard to do correctly if the hardware doesn't cooperate. Not impossible... just hard.
We *were* planning to get closer to the spec for the release of the book, but we got distracted trying to support some of the fun new features in the newest graphics cards. So in fact the implementation contains things the book *doesn't* specify, too. Of course we want the spec and the implementation to converge as soon as possible.
Well, you can. There's another level to Sh that let you glue together program fragments under host program control. There's an example in the book where we take a string and build a custom shader that evaluates to a black and white image that renders that string. It's basically a custom compiler, built using metaprogramming. You can also write an interpretor for any shading interface you want, using Sh tuple types to implement it. Wrap the whole thing in SH_BEGIN_PROGRAM/SH_END, and you now have a compiler for that language (Caveat: data-dependent control flow needs to be implemented using special SH keywords... see below).
If you want to be picky, what Sh supports is "generative metaprogramming", i.e. the ability of one program to build another. This is sometimes called "code generation", i.e. see Herrington's book by that title (but that's confusing terminology too!). There are other meanings to metaprogramming, like self-reflection, that we don't support, although the host application *can* manipulate and analyse program objects (i.e. the C++ app can look at program objects from "the outside" but shader programs themselves have more limited semantics and can't look inside or modify their *own* implementations).
Also, it is possible to use C++ control constructs in the definition of Sh programs to swap chunks in and out or to repeat chunks (unrolled loops). This is handy for creating variants of shaders, i.e. for different levels of detail. Basically, C++ is used as a "macro" language for the definition of Sh program objects.
And yes... it is true that most Sh syntax is checked statically by C++ at C++ compile time. We consider this a feature. Why "most"? Well, we support SH_IF/SH_END_IF and like constructs for data-dependent control flow, and these must be parsed at runtime, although we've set up the library so that simple syntax checking (looking for matching begin/end keyword pairs) is done at C++ compile time.
Yes, we're aware of these problems. On the other hand... how is an API that loads and runs a DLL different from one loads and downloads a precompiled representation of a shader? Externally, they can be made to look exactly the same: you point at a file and say "load", and return a handle of some kind to manage the shader.
However, people DO like to think of shaders as "data" to be managed like "assets", just like textures. Also, there are contexts like web browsers where downloading and running an arbitrary C++ program or loading and running a DLL is not a good idea, and situations like limited-memory game platforms where having a full JIT compiler is too expensive (also a problem with the OpenGL SL, BTW; the OpenGL ES spec called for a precompiled mode for this reason).
Well, both those problems can be solved. Basically, the idea is to externalize shaders (after using a host C++ app to "build" them) and then load them using a lightweight load-and-run engine. Of course such a lightweight runtime engine would not be able to use metaprogramming techniques, and would require an API similar to other shading languages to manage parameters and so forth, but you could use metaprogramming to BUILD the the shaders. It turns out that this is not all THAT easy as you also have to externalize all the RELATIONSHIPS between shaders, textures, and parameters. On the other hand, other shading languages force you to manage these relationships yourself...
Another alternative would be to bind all the types, operators, and functions of Sh to a suitable (sandboxed) scripting language. This would preserve the metaprogramming capabilities, and permit applications in things like web browsers.
Both of these solutions would also make it easier for artists to use Sh. In the first case, the application that defines an Sh shader might in fact be a content creation tool that uses, for instance, a visual language. If you can write an interpretor for a language, it's easy to use Sh to build a compiler for it. In the second case, a scripting language is probably a better tool for artists to use (if they must) to write shaders themselves. And there are lots of good scripting languages out there with good modularity constructs that we can hijack with the same approach we used with C++.
These are things we want very much to do... once we tackle a few other issues, like completing our GPGPU stream programming model. For the moment, we want to focus on the C++ binding of the library until it is completely polished before moving onto these extensions.
Actually, the stone shader uses both Worley basis functions and several octaves of Perlin noise. It's the Perlin noise that slows it down. We have a stained glass shader that runs at 200fps that uses just the Worley basis functions and a few cube map lookups to do the glass. Perlin noise could be sped up *a lot* if there was a "hash" instruction on the GPU to generate position-dependent pseudorandom numbers. But there isn't, so we have to generate the hash by using texture lookups, or several instructions to generate the hash procedurally:-(. Each invocation of Perlin requires four hashes and Worley requires nine. The bottom line is the assembly for the stone shader is VERY complex.
There's a poster for the implementation of the Worley basis functions available on the website. You can also get the source code for these shaders by downloading "shrike", our demo application, from the http://libsh.org/ website.
Actually, Sh was developed on Linux, and only recently ported to Windows. Like I said, the name was a historical accident, and in retrospect, I probably should have picked another one. This name also has the problem that a lot of... unfortunate... acronyms/words that begin with it. But; oh, well.
Call it "shlang" if it makes you happy. Also easier to pronounce;-). But it's not really a language; it's really a library. The website is http://libsh.org/, so calling it "libsh" is also acceptable if you would like to avoid confusion.
A lot of other shading languages don't even really have names. The OpenGL shading language is called... the OpenGL Shading Language. The Microsoft shading language is called... the High-Level Shading Language. More of a marketing statement, really;-). The Renderman Shading Language is called... the Renderman Shading Language. The Stanford Real-Time Shading Language is called... Ok, so Cg has a real name. The exception;-) The bottom line is that it's really hard to come up with names that are meaningful and haven't been taken.
Actually, there's one more trick Sh uses. If you declare a variable outside a SH_BEGIN_PROGRAM/SH_END block, then use that variable inside such a block, then that's how Sh sets up "uniform" parameters. For instance, suppose we have
ShVector3f d; ShProgram p = SH_BEGIN_PROGRAM("gpu:stream") { ShInputVector3f a; ShOutputVector3f b; b = a + d; } SH_END;
Now the program object p uses d as a constant over each data-parallel invocation of p to data. To support GPGPU, Sh supports a stream data abstraction so invoking an Sh function is pretty straightforward:
ShChannel<ShVector3f> input_data; ShChannel<ShVector3f> output_data; //... initialize input here // then apply p to it output_data = p << input_data;
Outside of a program definition, you can assign new values to d by simply assigning to it, and then apply p to some other data. This works for both shaders and for stream programs (the above is a stream program). In other words, d is interpreted as a "global variable" relative to the definition of p.
This is more interesting than it looks. The variable d is bound to the definition of p using the scope rules of C++. Sh "captures" the scope relationships set up by C++ when it creates the program object p. In programming language terminology, p is a "closure".
Closures are the basis of object-oriented programming---the object-oriented features of Smalltalk were originally motivated by the mechanisms required to support closures and statically scoped nested function definitions in Algol. By capturing the relationships between parameters and programs set up by C++, the Sh library lets you "hijack" ALL the modularity constructs of C++. Finally... textures are managed in the same way. So you can create strong data abstractions in Sh... and run them on the GPU. Or compile out the C++ modularity overhead and create high-performance code for the CPU, just by using "cpu:stream" in the above instead.
As for the difficulty of learning a new language; well, Sh really isn't a language. It's just a "simple" C++ library;-)
To emphasize this... Sh just "pretends" to look like a vector/matrix/colour library, since that is a familiar concept to graphics programmers. But it's this "retained mode" trick (also a common concept to graphics programmers) that lets you, basically, add dynamic definition of functions to C++. And those functions are really "remote procedure calls" that can run on another processor... like the GPU.
Another thing to emphasize: yes, Sh does compile to the *CPU* as well as the GPU. So you can use it for dynamic code generation.
And finally: our long term goal is to make sh suitable for all kinds of scientfic programming on all kinds of data-parallel machines, not just GPUs.
The choice of the name Sh is a long, evolutionary one. That was our internal name for a long time, and we published a paper using it long before we thought we'd be releasing it publically. But then after we published the first paper on it, we didn't want to change the name (there's already some confusion between Sh and the system it grew out of, SMASH...). But, we figured no-one would be silly enough to confuse a C++ library with a scripting language, so... although believe me, we had long discussions on exactly this problem.
Get over it. The name comes from the "Sh" prefix used on all the types, and (originally) was short for "shader".
Actually, I never taught CS246, just CS241 and CS251. And as for the paper bag thing... well, I have to teach the material in CS251 sooo sloowwly that it's hard to keep myself awake.
Slashdot Mirror
In Sh, though, this optimization is internal and automatic, and so invisible to the user. It's important to do it that way, because the shader algebra in Sh lets you turn uniforms into inputs and vice-versa. If you convert an input to a uniform, new uniform lifting optimizations become available, and vice-versa. The system keeps track of the "preshaders" for you in this case, and actually includes a dependency tracking and lazy update system internally. You can create your own "dependent uniforms" if you want, but in general it's unnecessary for a user to worry about or explicitly define lifted computations.
The idea is also related to hoisting computations out of loops. If you think of the data-parallel shading of vertices or fragments as a loop over all vertices and fragments...
Yes, our approach provides more optimization opportunity. For instance, computations that depend only on uniforms can be lifted out of the shaders to the host (the next release of Sh will do this; see the post by Stefanus). There are also various transformations on programs that we can do, like the shader algebra, if we have a higher-level representation than a string. Our system also allows introspection, i.e. you can ask a program object what its inputs and outputs are, what the types of those inputs are, etc. Finally, by using our own representation, we can map to multiple backends; the same program object can be compiled (long after definition time) to both the CPU and the GPU. This is handy if you're not sure you want to run a given simulation kernel on the host or on the GPU to load-balance an application. Using our system, you can defer that decision to installation time.
But anyways, it's true that the FP on GPUs takes a bunch of shortcuts, doesn't handle various things the way it's supposed to according to the IEEE spec, drops low-order bits for some cards, etc. etc. The work at Stanford is certainly valuable in characterizing these issues. However, I suspect the next generation of cards will address most of these issues, and we'll see both higher performance and greater adherance to the IEEE spec in future cards, and possibly higher precision, making GPUs more suitable for scientific applications. And remember, "future" in the graphics industry means in one year. "Far future" is two years
We *were* planning to get closer to the spec for the release of the book, but we got distracted trying to support some of the fun new features in the newest graphics cards. So in fact the implementation contains things the book *doesn't* specify, too. Of course we want the spec and the implementation to converge as soon as possible.
If you want to be picky, what Sh supports is "generative metaprogramming", i.e. the ability of one program to build another. This is sometimes called "code generation", i.e. see Herrington's book by that title (but that's confusing terminology too!). There are other meanings to metaprogramming, like self-reflection, that we don't support, although the host application *can* manipulate and analyse program objects (i.e. the C++ app can look at program objects from "the outside" but shader programs themselves have more limited semantics and can't look inside or modify their *own* implementations).
Also, it is possible to use C++ control constructs in the definition of Sh programs to swap chunks in and out or to repeat chunks (unrolled loops). This is handy for creating variants of shaders, i.e. for different levels of detail. Basically, C++ is used as a "macro" language for the definition of Sh program objects.
And yes... it is true that most Sh syntax is checked statically by C++ at C++ compile time. We consider this a feature. Why "most"? Well, we support SH_IF/SH_END_IF and like constructs for data-dependent control flow, and these must be parsed at runtime, although we've set up the library so that simple syntax checking (looking for matching begin/end keyword pairs) is done at C++ compile time.
However, people DO like to think of shaders as "data" to be managed like "assets", just like textures. Also, there are contexts like web browsers where downloading and running an arbitrary C++ program or loading and running a DLL is not a good idea, and situations like limited-memory game platforms where having a full JIT compiler is too expensive (also a problem with the OpenGL SL, BTW; the OpenGL ES spec called for a precompiled mode for this reason).
Well, both those problems can be solved. Basically, the idea is to externalize shaders (after using a host C++ app to "build" them) and then load them using a lightweight load-and-run engine. Of course such a lightweight runtime engine would not be able to use metaprogramming techniques, and would require an API similar to other shading languages to manage parameters and so forth, but you could use metaprogramming to BUILD the the shaders. It turns out that this is not all THAT easy as you also have to externalize all the RELATIONSHIPS between shaders, textures, and parameters. On the other hand, other shading languages force you to manage these relationships yourself...
Another alternative would be to bind all the types, operators, and functions of Sh to a suitable (sandboxed) scripting language. This would preserve the metaprogramming capabilities, and permit applications in things like web browsers.
Both of these solutions would also make it easier for artists to use Sh. In the first case, the application that defines an Sh shader might in fact be a content creation tool that uses, for instance, a visual language. If you can write an interpretor for a language, it's easy to use Sh to build a compiler for it. In the second case, a scripting language is probably a better tool for artists to use (if they must) to write shaders themselves. And there are lots of good scripting languages out there with good modularity constructs that we can hijack with the same approach we used with C++.
These are things we want very much to do... once we tackle a few other issues, like completing our GPGPU stream programming model. For the moment, we want to focus on the C++ binding of the library until it is completely polished before moving onto these extensions.
There's a poster for the implementation of the Worley basis functions available on the website. You can also get the source code for these shaders by downloading "shrike", our demo application, from the http://libsh.org/ website.
Call it "shlang" if it makes you happy. Also easier to pronounce ;-). But it's not really a language; it's really a library. The website is http://libsh.org/, so calling it "libsh" is also acceptable if you would like to avoid confusion.
A lot of other shading languages don't even really have names. The OpenGL shading language is called... the OpenGL Shading Language. The Microsoft shading language is called... the High-Level Shading Language. More of a marketing statement, really ;-). The Renderman Shading Language is called... the Renderman Shading Language. The Stanford Real-Time Shading Language is called... Ok, so Cg has a real name. The exception ;-) The bottom line is that it's really hard to come up with names that are meaningful and haven't been taken.
This is more interesting than it looks. The variable d is bound to the definition of p using the scope rules of C++. Sh "captures" the scope relationships set up by C++ when it creates the program object p. In programming language terminology, p is a "closure".
Closures are the basis of object-oriented programming---the object-oriented features of Smalltalk were originally motivated by the mechanisms required to support closures and statically scoped nested function definitions in Algol. By capturing the relationships between parameters and programs set up by C++, the Sh library lets you "hijack" ALL the modularity constructs of C++. Finally... textures are managed in the same way. So you can create strong data abstractions in Sh... and run them on the GPU. Or compile out the C++ modularity overhead and create high-performance code for the CPU, just by using "cpu:stream" in the above instead.
As for the difficulty of learning a new language; well, Sh really isn't a language. It's just a "simple" C++ library ;-)
Another thing to emphasize: yes, Sh does compile to the *CPU* as well as the GPU. So you can use it for dynamic code generation.
And finally: our long term goal is to make sh suitable for all kinds of scientfic programming on all kinds of data-parallel machines, not just GPUs.
Get over it. The name comes from the "Sh" prefix used on all the types, and (originally) was short for "shader".
Actually, I never taught CS246, just CS241 and CS251. And as for the paper bag thing... well, I have to teach the material in CS251 sooo sloowwly that it's hard to keep myself awake.