Sh GPU Metaprogramming Language: Frequently Asked Questions
This FAQ page gathers common questions and answers about the Sh GPU metaprogramming language. If you are wondering about Sh, check here first to see whether your question has already been covered. To comment on this FAQ, you can write to the mailing list or use the "Edit" link at the top of this wiki page.
About Sh
What exactly is Sh?
For a brief introduction, see the Sh page, and for a fuller account of the ideas behind it, see How Sh Works.
How should Sh be capitalized and pronounced?
It is written with a capital S and a lowercase h, and is usually pronounced as the two English letters. You are of course free to say it in another language, but pronouncing it as an ordinary word is not recommended, since listeners may think you are asking them to be quiet.
Where does the name come from, and how does Sh relate to the Unix shell "sh"?
Sh grew out of a larger research project named SMASH, which explored both software programmability of GPUs and hardware features. Sh was intended to be the software layer of that system. When it turned out that the name SMASH was already taken by a related project, the two main parts were split into Sm (the simulator) and Sh (the language), which conveniently made SMASH an acronym for "Sm and Sh". The clash with the Unix shell "sh" is unfortunate, but after some deliberation the name was kept because it had already been used publicly for some time. Moreover, the Unix shell sh has largely been replaced by derivatives such as bash and csh, and the contexts in which one speaks of Unix sh are very different from those in which Sh is mentioned. It is highly unlikely that GPUs or similar architectures will be targeted by the Unix shell in the future.
What does metaprogramming mean?
Metaprograms are programs that write other programs. Sh supports metaprogramming implicitly: you do not even need to be aware of it, but when you write an Sh program you are really writing a C++ program that generates an Sh program. If that sounds odd, don't worry — you do not need to know about it in order to use Sh.
How Sh Compares with Other Shading Languages
Many shading languages exist. Cg, HLSL and the OpenGL Shading Language are probably the most prominent ones used on GPUs today, and there are also offline shading languages such as Renderman, which are not treated here. All of the other GPU shading languages are essentially syntactic variants of one another, with at most a few extra function calls, whereas Sh is something entirely different.
With the other shading languages, shaders are written either as strings in the host application or as separate files. With Sh, shaders are written directly in C++, together with the host application. This makes a significant difference:
- Shaders can share variables with the application, eliminating the need for parameter binding (glue) code. For small shaders this more or less means throwing away half the code necessary to write a shader.
- The host application can very easily generate GPU programs on the fly, without having to generate some sort of text representation of the programs. This is very important for generating subtle variants of shader programs, for example for different numbers of light sources or varying levels of complexity.
- Sh also integrates texture handling, taking away much of the burden associated with updating textures and using them from shader programs.
Beyond this crucial basic difference, there are a few other notable differences worth mentioning:
- While all of these shader languages are free, Sh is completely open source. Some other languages provide an open source frontend (the lexer and parser), but Sh makes everything freely available, including the optimizer and code generators.
- The Sh licence is very permissive, stating that you can basically do anything with the language except claim to have written it. This means you can integrate Sh into commercial applications without any sort of obligation, and can make your own derivatives of it.
- Sh is also cross-platform. While the official version currently supports only Windows and Linux, a Mac OS X port is to be integrated soon.
- Being mostly written by university researchers, Sh has no strong ties to a particular platform, API (such as OpenGL or DirectX) or graphics vendor. Compared to Cg, HLSL and the OpenGL Shading Language, it is the most independent shading language out there.
- The research origins of Sh also mean that we are very interested in trying out new ideas in relation to shading. For example, our Shader Algebra paper from SIGGRAPH 2004 illustrates a mechanism built into Sh to take existing Sh programs and easily generate modified programs from these at runtime.
- Lastly, our goal for Sh is to not just be a shading language. GPUs are becoming increasingly suitable for general purpose computation, which is interesting for a number of reasons, not the least of which is the amazing speed that GPUs offer at commodity prices. Thus we are aiming for Sh to be a language suitable for any kind of computation on GPUs, whether graphical or not.
Performance and Compiler Questions
Is Sh slower than Cg, HLSL or the OpenGL Shading Language?
The short answer is no: there is nothing intrinsic about Sh that makes it slower than Cg, HLSL or the OpenGL Shading Language. As always, there is a longer answer too. Sh is really a GPU programming toolkit — it does much more than other shading languages. For example, Sh can set up textures for you, handle your uniform variables automatically (no more glue code!) and allow programs to be transformed in various ways. Some of these features may be more efficiently implemented manually. For this reason, Sh also tries very hard to give you, the developer, the flexibility to set things up on your own. For example, textures and uniform variables can be bound to existing OpenGL state in the OpenGL backends, allowing you to set these up as you see fit. This effectively makes Sh behave the same way other shading languages do, allowing more flexibility but taking away a lot of the convenience it provides by default. Furthermore, Sh includes a full compiler, including an optimizer, register allocator and code generator. It is certainly the case that for certain programs other shader compilers will generate better code than Sh. However, the converse is also true — there are optimizations which at the time of writing only Sh performs (for example, automatically determining subexpressions that only depend on uniforms, and lifting these to the host instead of the GPU). However, we are also working on adding compiler backends for Sh that target other high-level languages (for example, at the time of writing we are very close to completing our OpenGL Shading Language backend). This will allow you to take advantage of vendor-supplied compiler optimizations if you find that Sh's optimizer is not sufficient.
How does Sh compare to Brook?
Brook is a stream processing language developed at Stanford. Brook for GPUs is an implementation of Brook that runs directly on modern GPUs, implemented as a translator frontend that generates Cg code together with a C++ runtime. Sh also has a stream processing subset. The main functional difference between Sh and Brook is that Brook is intended only for general purpose computation, whereas Sh targets both graphics and general stream processing. Brook has features that Sh lacks, and Sh has features not found in Brook, but both projects are under active development.
How does Sh work?
This is a summary of a more detailed explanation of how Sh works. Sh is simply a C++ library. Matrix-vector libraries, for small-scale matrix and vector operations, are commonplace amongst graphics program developers.
Explore More
- Sh: a quick introduction
- How Sh Works
- Sm, the simulator
- Shrike
- Shmedia
- Sample Code
- Metaprogramming GPUs with Sh
- Frequently Asked Questions
- Main Page
- Recent changes
- Random page
- Upload file
- Special pages
- About ShWiki
Download Sh Read the Licence Back to Home Report an Issue Join the Developers List
Related tools: Subversion, TortoiseSVN, RapidMind, and MediaWiki.