Metaprogramming GPUs with Sh

Martin Ecker writes "With the advent of powerful, programmable GPUs in consumer graphics hardware, an increasing number of shading languages to program these GPUs has become available. One quite interesting language that - in many ways - has a very different approach than other mainstream shading languages (such as Cg or the OpenGL Shading Language) is Sh. The recently released book "Metaprogramming GPUs with Sh" by Michael McCool and Stefanus Du Toit, both major contributors to the Sh project, explains the basics of the Sh high-level shading language and the corresponding API and also goes into some of the details of the implementation. The book is intended for an audience that is already familiar with traditional shader development for programmable GPUs. Also, a firm background in 3D graphics programming and C++ is a must for the interested reader." Read on for the rest. Metaprogramming GPUs with Sh author Michael McCool, Stefanus Du Toit pages 308 publisher A K Peters rating 7/10 reviewer Martin Ecker ISBN 0321197895 summary A book that describes an interesting shading language and accompanying API to program GPUs.

Before discussing the book in more detail, I will try to give a basic overview of Sh, since most readers will not be familiar with it. For a more in-depth look at Sh, I recommend taking a look at a recently posted Gamasutra article by Michael McCool (http://www.gamasutra.com/features/20040716/mccool _01.shtml), the paper on Sh from the authors presented at the recently held SIGGRAPH 2004 conference (http://www.cgl.uwaterloo.ca/Projects/rendering/Pa pers/#algebra), and of course the Sh homepage at http://www.libsh.org.

Sh started out as a research project at the University of Waterloo (http://www.cgl.uwaterloo.ca), and it is both a shading language and a runtime API to use the Sh shaders. As a shading language Sh is embedded into C++ as a domain-specific language, which is made possible by using C++ operator overloading and by defining special tuple and matrix types that are used extensively in shader code. So instead of defining its own language that requires a full compiler, like other shading languages do, Sh uses regular C++ syntax to describe shader code, which is then dynamically (at runtime) compiled to a specific backend, such as a GPU or possibly even the CPU. In addition to compiling to a specific GPU or CPU target, Sh can also be used in a special stream mode where a shader is applied to a stream of input tuples. This is very useful for general purpose GPU programming where the GPU is basically used as an additional processor to the host CPU (see http://www.gpgpu.org for more information on the subject). Finally, Sh code can also be executed in an immediate mode where every Sh statement is directly executed on the host CPU (without being compiled into a shader program), which makes it very easy to debug shaders with any host debugger running on the CPU.

Due to the way Sh is embedded into C++, the full range of abstraction mechanisms offered by C++ can be used to structure and modularize shader code. Abstract base classes, regular functions, templates, and any other features offered by C++ can be used to develop shaders. This is an interesting consequence of the metaprogramming approach of Sh that also allows the use of software engineering principles in shader development, such as object orientation, that other shading languages currently cannot offer.
This kind of metaprogramming in C++ is used by an increasing number of libraries. For example, the Spirit parser framework (see http://spirit.sourceforge.net) uses a similar approach to describe and generate parsers directly in C++ instead of using traditional external tools, such as yacc or bison.

One of the most fascinating features of the Sh toolkit is the possibility to combine and connect shader programs to form new shader programs, which allows one to easily build complex shaders out of simple shader fragments. In a more general sense, Sh provides what can be called a shader algebra (see also the aforementioned SIGGRAPH 2004 paper), where shader programs are the objects on which special operators to combine and connect them are defined. An interesting application of this shader algebra is to specifically bind certain varying shader inputs to uniform variables and the other way around (this is what functional programming languages usually call currying). Also combining a matrix palette skinning shader with any light model shader (or any shaders that perform specific tasks, for that matter) is easily possible.

After this short introduction to the Sh toolkit, we shall now take a closer look at the book "Metaprogramming GPUs with Sh".
The book is split into three parts, an introduction, a reference, and an engineering overview.

The introduction consists of the first five chapters and discusses the basics of the Sh shading language and the API. In particular, the tuple and matrix types and the operators defined on them are presented. The way shader programs are defined and how parameters and attributes are handled is discussed, followed by the way textures are represented. Finally, the stream and channel concept used to feed data into shader programs is discussed. These introductory chapters contain a number of examples that demonstrate the presented concepts. Chapter three contains a quite interesting sample shader that uses constructive solid geometry techniques and metaprogramming in Sh to render text. While not the most useful use case, the shader shows some interesting capabilities of Sh, in particular the shader algebra operators. Chapter four on textures has some more nice sample shaders for doing shiny bump mapping, rendering wood and marble, and using Worley noise.

The second part of the book is a reference on Sh. Unlike references in many other computer books, this is not just a technical listing of the available features of Sh but is written in regular prose (with the occasional reference-like table here and there). The six chapters of the reference section describe how to setup and use the Sh library, and then discuss the available types, operators, and standard library functions more thoroughly than in the introduction. Additionally, the available backends are mentioned in the last chapter of this part of the book. A draft of the reference manual can also be found online at http://www.libsh.org/ref/online.

The final part of the book deals with engineering aspects of Sh. These final five chapters of the book discuss the details of the current implementation. The intermediate representation for shaders that is used by Sh is presented as well as how streams and textures are managed and stored internally. The interface between the Sh frontend and the various specific backends is discussed, as well as the current state of the optimizer including some further improvements that are planned in the future.

The images in the book are all in black and white except for 14 color plates in the middle of the book. The color plates and other images usually show teapots or animals, so they aren't all that exciting, but do demonstrate what the sample shaders presented in the book look like.

The book does not come with a CD-ROM, but with such a young library that is still under heavy development, putting a snapshot of the library's source code base on a CD-ROM would be a waste of resources. Sh itself as well as all sample shaders presented in the book can be downloaded from the Sh homepage at http://www.libsh.org. This website also has additional documentation, including some papers and the API reference documentation generated with Doxygen from the sources. Sh is distributed under a very liberal open source license (based on the zlib/libpng license) that also allows commercial use.

For the reader with enough expertise in 3D and shader programming, this book provides a concise and well-written introduction to Sh. The book will definitely contribute to enlarging the currently relative small user base of Sh and hopefully help the library grow and get more refined in the near future. Everyone familiar with "regular" high-level shading languages, such as Cg or the OpenGL Shading Language, should take a look at this book to see a new and interesting way of programming GPUs that the aforementioned languages do not offer.

About the review author:
The author has been involved in real-time graphics programming for more than 9 years and works as a games developer for arcade games. In his rare spare time he works on a graphics-related open source project called XEngine http://xengine.sourceforge.net.

You can purchase Metaprogramming GPUs with Sh from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Wow

[Anonymous Coward]

I thought I'd accidentally clicked on this article.

Re:Wow

[Evangelion]

Dude, /. is the bottom of the hill.

Re:Wow

[Infinityis]

(1) Don't link article
(2) Set blurb = article
(3) ???
(4) Profit!*

*by saving on bandwidth and the cost of replacing a toasted server

Anyone Else Notice...

[jchawk]

Is this the longest headline blurb ever?

Re:Anyone Else Notice...

[Anonymous Coward]

No I didn't. But now since you mention...

Template broken?

[Carnildo]

Is the book review template broken or something? This is the second review in as many days that's been misclassified.

Front Page Story

[mnemonic_]

Awesome story formatting. Looks great!

Shhhh

[Anonymous Coward]

Don't tell anybody about it.

Let me just be the first to say:

[Anonymous Coward]

Huh?

That is sooo... awesome....

[illumin8]

Schweet!!! I always wanted to write my own CounterStrike-like 3D FPS as a shell script! Now my uber-leet shell hacking skills can make me rock-star dollars as a video game developer!

Largest tease post evar!

[Chuck Bucket]

it really has to be, I thought I had hit the wrong link when I got to the page! someone wake up Tacoman and see whatup on the whois!

CB

/bin/sh

[philfr]

At first read I thought they ported bash to the Radeon GPU...

Re:/bin/sh

[Anonymous Coward]

sh != bash

Re:/bin/sh

[einhverfr]

isn't sh the basic (old-school) Bourne Shell and bash a version with enhanced scripting abilities?

Yes I know-- sh in this case is shading language...

But on a more serious note, is there any reason why once cannot write to the video card (as root) with a bash script? Is there any technological reason why one cannot send in the OpenGL information this way?

If not, maybe we need command-line programs to connect to irrlicht then we can do all this :-)

Re:/bin/sh

[Anonymous Coward]

If somebody told me they'd written something in sh, I'd think they meant shell script. I think I'll pass on these shading languages until they can pick better names for them... Silly windows children

Re:/bin/sh

[Anonymous Coward]

Hypothetically there could be an addition to bash that would basically be a wrapper for the opengl function calls, but this technically would not allow one to "write to the video card (as root) with a bash script". Bash itself was made to just handle the shell, not really be a full coding language (so I'm not sure why you would want to write opengl applications in bash), but with these wrappers, hypothetically it could be done.

Re:/bin/sh

[fitten]

sh -> Bourne Shell
bash -> Bourne Again Shell

Re:/bin/sh

[jericho4.0]

On SGI machines there is a '/dev/opengl', that one can pipe openGL bytecode to.

Re:/bin/sh

[Anonymous Coward]

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Sep 24 2003 /bin/sh -> bash

Re:/bin/sh

[trippinonbsd]

Linux developers get off on that. Sh isn't bash! Fix your broken systems. Sh and bash behave differently. Linking sh to bash creates portability issues for shell scripts.

Re:/bin/sh

[marcansoft]

What does "cat /dev/urandom > /dev/opengl" do?

Re:/bin/sh

[Anonymous Coward]

Absolute nonsense. From the bash man page:

If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well.

And what is BSD's sh? I'd like to see who's is more sh-compliant.

Re:/bin/sh

[robbo]

#!/bin/sh

for n in pixbuf/* ; do
if [ $n -nt screen/${n##*/} ]; then
cat $n > screen/${n##*/}
else
touch screen/${n##*/}
fi
done

Re:/bin/sh

[j3110]

Just to completely blow away any idea of using /bin/sh for shading, I would like to say that if you spawned a new process for every opengl command you sent to the card, you would be waiting for the first frame over a cup of coffee. :)

Don't feel bad, I read the title the same way. Maybe they should change the title to not be so misleading, maybe something with fire in the name. :)

There is no reason why you couldn't modify bash to add internals to support opengl calls, but bash is completely interpreted, and it may not be able to keep up with the GPU for anything complicated.

If you really wanted to mess with GPU's in a scripting language, I suggest something designed to do something a little more programatically... like everyone's favorite snake, Python. I'm pretty sure there are opengl wrappers, which, by extension, would mean there is probably shading support in there somewhere.

Other than that, you could use SH to write a program to play with the shader. :)

Re:/bin/sh

[mvdw]

Linking sh to bash creates portability issues for shell scripts.

Why? From the bash man page:

A non-interactive shell invoked with the name sh does not
attempt to read any other startup files. When invoked as sh, bash
enters posix mode after the startup files are read.

Bottom line: bash when invoked as #!/bin/sh will behave pretty much the same as sh. Bash invoked as #!/bin/bash behaves much more sanely :-).

Try writing a shell script under linux invoked as #!/bin/sh, then write one invoked as #!/bin/bash. They behave differently, despite /bin/sh being a symlink to /bin/bash.

Re:/bin/sh

[T-Ranger]

I beleive it involves display of 2d clowds, white over a blue background... And if you stare at the clowds long enough you can see a horse.

Re:/bin/sh

[trippinonbsd]

I was not aware of this. Thanks

Re:/bin/sh

[Trejkaz]

Maybe if someone would do this, we could hack together a new driver in shell script that doesn't suck.

SDL-perl

[Speare]

I've done some OpenGL work with SDL's Perl bindings, but the SDL-perl group has been quite fractured over the past several months. Forks, missing maintainers, etc. I finally got texture-mapping to work, but there are some persistent bugs with missing GL constants or missing APIs which have put my spare-time projects on the shelf for now.

This is a shame, because perl's a nice quick way of working through the edit-try-edit-try-edit development process when working with OpenGL and 3D geometrical stuff in general.

I don't want to learn Yet Another Scripting Language just to try out some OpenGL routines, and I don't want to slog through a ton of C code makefile junk either. Script languages are a great help there.

Re:SDL-perl

[Anonymous Coward]

Hi Speare :)

I agree about the sad state of SDL-perl :/ I tried to switch to irrlicht, but since there is no Perl interface yet I need to write one first - and this is way too much work because the everchanging nature of irrlicht, my lack of C++ experience and the way Perl interfaces with C++ (e.g. badly).

But I still find Sh a very interesting concept...

Hm, Inline::Sh? :)

If you are still interested in perl and 3d stuff, drop me a note (user tels at the host bloodgate.com :o)

best wishes,

tels

Re:SDL-perl

[Anonymous Coward]

Games in Perl? Either you only know Perl or you just like to be tricky. Games are one of those niches that "easier" languages such as Perl and Java aren't well suited for. In college, my prof made us write a game in LISP just to prove that some languages are bad at certain things. If you want to test some OpenGL code to see what it does, then SDL-perl might be nice, but once you decide upon your primitives or at least the algorithms, use a language more suited to the task.

Re:SDL-perl

[Anonymous Coward]

In college, my prof made us write a game in LISP just to prove that some languages are bad at certain things.

Then your prof, and/or you (you're ultimately responsible for your education) was an idiot.

I've known LISP implementations that were hacked together to do a lot of the high level logic for some games. LISP is such a generic term that I don't see how it is fundamentally unsuited for any particular task, especially something as generic and extensive as "games". What the fuck do you mean by "games"? I thought college was supposed to teach you to avoid over-generalizations amongst other things.

In a complex game, where there are so many subsystems that using any one tool for the whole thing is stupid (i.e. many games have their core written in C++, but use either home grown or something like Lua for scripting).

It sounds like your prof just couldn't write good "game" code period (i.e. the assignment was contrived), I don't think using LISP had anything to do with it.

While I don't like Perl for a number of reasons, SDL-perl might still be the right level of abstraction (and therefore "more suited to the task" than say C) for a large subset of games and graphics programs.

I think there is even a game development system for Python. Granted, you're probably not going to produce GTA4 in it, but there are certainly a few people that have written "games" they are happy with.

While I will admit that certain languages are poorly suited for specific tasks and that the right tool for the job is important, you sound like one of those people that parrots that statement without really knowing what it means.

Re:SDL-perl

[Anonymous Coward]

Lua and Python are probably more widely used for game programming and SDL programming than Perl, so if you are looking for a scripting language to play around with with APIs, those are the ones to use.

As for "not wanting to learn yet another scripting language", well, that's the way scripting languages are, and you just end up having to know several. Lots of people would also prefer never to have to deal with Perl, but the real world forces them to.

Re:SDL-perl

[ventonegro]

Try the Lua bindings. Lua is a much better language than PERL anyway.

Amazon linkage

[bujoojoo]

Or, buy it from Amazon

poinis

[Anonymous Coward]

poinis

Hilarioius

[Anonymous Coward]

Gamasutra article by Michael McCool

Gamasutra? Anybody else rofl?

Re:Hilarioius

[Jason1729]

Hey, I had McCool as a prof for CS 246 at UWaterloo.

Re:Hilarioius

[Anonymous Coward]

Yeah i had both for CS 251. Weird. Too bad they didn't mention of this in class, i would have woke then.

Re:Hilarioius

[p2sam]

yeah I had him for cs251 as well... That guy may be an amzing graphics guy ... but he can't teach himself out of a paper bag.

Re:Hilarioius

[mdmccool]

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.

Re:Hilarioius

[Jason1729]

It must have been CS241 then. I didn't take CS251 (I took E&CE 221 towards the EEE option instead). This was also back when it was CS351, not CS251.

Jason
ProfQuotes

/bin/sh

[rcamera]

i always do my low level device programming in sh. my graphics card has never been faster!

sed | awk | sed | grep | awk | sed | awk

Michael McCool and Stefanus Du Toit

[stratjakt]

hee hee

funny names

sh?

[courier12point5]

What if I want to use korn or csh?

Re:sh?

[Anonymous Coward]

We all know that korn gives your sh a better artistic texture. Like peanuts and raisins,

I see

[dickens]

...thought that was shooting a little high for Bourne Shell...

lol

[here4fun]

Before discussing the book in more detail, I will try to give a basic overview of Sh, since most readers will not be familiar with it.

lol, how many languages do we need? back in the day, knowing 2 or 3 languages very well (like c and some db language) would have been enough to land a job. add to that knowing another 2 or 3 languages well enough to feel comfortable doing small coding, and you have an excellent programmer. now it seems like there are so many languages, from python to cobol to fortran. there must easily be over 50. it is like if i wanted to work at the united nations and said i knew english and spanish and german, and they asked "well what about sanskrit and tagalog". how much is enough?

Re:lol

[stratjakt]

Everyone in the OSS community needs to have either their own linux distro (gentoo forks), their own desktop environment (gnome forks), or their own scripting language.

In the real world, I would expect a professional programmer with a background in OO to be able to perform competently in any OO language with very little learning curve. The only thing that really changes from language to language is the syntax.

Big paradigm shifts have been few (Sequential to functional to object oriented). There are of course logical languages like ProLog but only massochists use them.

Re:lol

[revscat]

In the real world, I would expect a professional programmer with a background in OO to be able to perform competently in any OO language with very little learning curve. The only thing that really changes from language to language is the syntax.

Have to disagree with you there. OO languages are different in implementation, shorcomings, and strengths depending on the language in question. Java can do things that are difficult in Ruby, and vice versa (functions as objects), and Smalltalk can do things that neither can do without tacking on some hack or (for Java) dinking with the bytecote (e.g. continuations.)

There are similarities between languages, but there are frequently differences that are far more fundamental than mere syntax.

Re:lol

[ZorbaTHut]

How many do we need? Two. Personally, I'd pick C++ and assembly, though I know quite a few people who'd pick Java and assembly. (And assembly's only so we can make OSes.)

How many do we want? More.

Imagine I want to do some quick parsing. Both C++ and Java suck at this. So I'll use Perl instead.

Imagine I want to write code for a GPU. Sure, I could do it in bytecode. I could do it with some library for C++. Or I could write a custom language - say, Cg or Sh - that works well for that purpose.

Imagine I want to embed code in a virtual machine. I wouldn't want to try this with C++ or Java, but Python does it easily.

Any other languages you've used occasionally? Shellscript? VB? Javascript? (Yes, that's right, all your web browsers must now also function as C++ interpreters!) PHP? SQL?

I consider myself an expert in precisely one language - C++. I can get by in Java, Python, SQL, C#, and PHP. I suck at shellscript and Perl. All of these languages have their uses, and I use them all when it's appropriate. (Well, except Perl, which I pretty much avoid.)

On the other hand - learning new languages isn't hard. I can look at just about any sane language (no Brainfuck comments, please) and tell what it does quickly. I say "I can get by in Python" because I realized I needed to write some Python code, and learned enough Python in a day to do it. I'm told that people who learn human languages can do something similar.

So it's not like your analogy at all - it's more like if you wanted to work at the United Nations and said you knew English and Spanish, and also that you could learn new languages easily, and they said "Okay, go learn Sanskrit and Tagalog."

Re:lol

[d_jedi]

I'll agree that there is little learning curve in being able to write a program that will compile and run in another language.. but being a competent programmer in that language requires much more.

I guess it depends on how similar the languages are, but from personal experience:
a good Java programmer != a good C++ programmer, and vice versa.

Re:lol

[d_jedi]

There are actually more than 1000 programming languages.. although many of those aren't in wide use! Different languages are suited for different tasks. Some things that are trivial in one programming language are exceedingly difficult in others.

Re:lol

[Lord Omlette]

"I've got a hammer, and I use it for everything!"

Excellent plan.

Re:lol

[here4fun]

How many do we need? Two. Personally, I'd pick C++ and assembly, though I know quite a few people who'd pick Java and assembly. (And assembly's only so we can make OSes.)

This is exactly what I thought, except I never knew anyone who works doing assembly. It might be nice for some theory, but in practice it is never applied. I would think someone who is expert in assembly has a small niche market for themseleves and they probably make good money. My thinking is either C or C++ is a must (or maybe Java, it seems many schools are teaching it instead of C).

How many do we want? More.

LOL!!! You must search for jobs at monster too. What is it with a company "Looking for a webmaster.... We seek someone who can program in HTML, JavaScrip, VB, Java, Cobol, Fortran, lisp....". It seems like the HR people, who don't know any better are listing every language.

I consider myself an expert in precisely one language - C++. I can get by in Java, Python, SQL, C#, and PHP. I suck at shellscript and Perl. All of these languages have their uses, and I use them all when it's appropriate. (Well, except Perl, which I pretty much avoid.)

This sounds like a good programmer to have. You know one thing expert, better than 99% of other people. You can do other things to get by, but you allocate your time to keep current with your one best skill. I wonder if most companies look for someone like you, or the jack of all trades?

On the other hand - learning new languages isn't hard. I can look at just about any sane language (no Brainfuck comments, please) and tell what it does quickly. I say "I can get by in Python" because I realized I needed to write some Python code, and learned enough Python in a day to do it. I'm told that people who learn human languages can do something similar.

It can take time. I remember I had a project where someone on the buisness side was convinced we needed one project coded in VB. Most of the tech people complained, some kissed butt. Suprisingly, I never had a class in VB, so it was time for Borders bookstore. While VB is an easy language, I did spend a fair amount of time learning it, time I could have used doing something else.

Re:lol

[lukewarmfusion]

I think that's the point, though. A competent programmer will look at another language with the confidence that he could pick it up and start working in it (maybe not 100%) "with very little learning curve." Sure, there are intricacies of every language - but those are the things that you pick up over time as you learn.

In college, I watched entire classes go through the same intro topics (how hard is it to switch between C++ and Java when you're only talking about freakin' conditionals?!) for weeks... I think the grandparent poster meant that a competent programmer would look at that and pick it up in minutes.

I know a handful of programming languages. I also have studied a handful of real-world languages. I spent six years studying Japanese... talk about fundamental differences!

Re:lol

[mod_parent_down]

How many do we want? More.

First off, I totally agree with this, people always make the analogy that languages are like tools and each job should be implemented with the most appropriate tool. Who would argue against more tools in the workshop?

But there's a huge missing link here: Languages are horribly inoperable. Even C to C++ requires some tomfoolery like

#ifdef CPLUSPLUS
extern "C" {
#endif
#include ...
#ifdef CPLUSPLUS
}
#endif

Is this a joke? The problem is that once you've used that nice bandsaw, you can't smooth the edges by hand. You can't use Python to parse into C++ data structures which then use asm inner loops.

I know projects exist that have this as their goal, but let's face it... languages are successful these days because they can be used (with varying degrees of difficulty) in isolation for a job.

Re:lol

[ZorbaTHut]

Personally I use text files as the links. Yes, this means I end up doing things step-by-step, but for my work that's usually what I do anyway.

You're right, with some exceptions, languages aren't very interoperable. Python is an exception, and the entire .net family is an exception - I've made some great tools combining C++ and C# with .net, and to be honest, I was very very impressed by the whole thing.

COM and CORBA and so on and so forth do a reasonably good job of bridging most gaps, but unfortunately they have a learning curve best described as "astronomical".

It's obviously an area there's a lot of work left to do in.

Re:lol

[Anonymous Coward]

lol, how many languages do we need? back in the day, knowing 2 or 3 languages very well (like c and some db language) would have been enough to land a job. add to that knowing another 2 or 3 languages well enough to feel comfortable doing small coding, and you have an excellent programmer. now it seems like there are so many languages, from python to cobol to fortran. there must easily be over 50. it is like if i wanted to work at the united nations and said i knew english and spanish and german, and they asked "well what about sanskrit and tagalog". how much is enough?


I assume you are very young or completely inexperienced in this field based on your statements. I would surmise that since the 1970s the number of viable languages has been about constant (from your list, cobol isn't exactly new, nor is FORTRAN).
One of the mistakes people make is equating human languages to computer languages. They are cognitively completely unrelated. Learning computer languages is much more like a pilot becoming type certified on certain aircraft or an telephone technician learning a new switching system.
The computer languages are simply tools. The hard core stuff in CS has always been the algorithms and applied math (at least that USED to be the case until many unis turned CS into a degree mill for glorified computer operators).

It is still the case that knowing 2 or 3 languages very well is all you need for specific domains. How many embedded programmers that in addition to C, C++, and make, know say JCL for the AS/400? Very few people reach language lawyer status on every language they use.

The point is, the most successful computer scientists and engineers learn the underlying fundamentals of computing and the languages are simply tools for expressing the abstract concepts in some concrete manner.

There is a tendency to fill resumes with "keyword" language references. This is done by the morons because they think it is impressive to "know so many languages" and it is done by the smart people because they have to just to get past the idiots screening applicants in HR. As someone who has interviewed numerous candidates I can tell you that those lists mean absolutely nothing. I am not impressed that you can use a UNIX shell and write "hello, world" in Python. I am impressed if you understand computing fundamentals and can apply them in a number of languages based on the task at hand. This also means that I am more concerned that you being an expert say in LISP and C can pick up a book on python or MATLAB and hack some code properly in the next 3 days. Those that can't do that may be capable computer operators (a job that doesn't or shouldn't require a CS degree), but they are not engineers or scientists. Its the old Djikstra quote about telescopes. Operating a telescope is not why astronomers go into the field, but they may have to use one as a tool.

If after reading this you still don't get it, you are simply not CS/computer engineer material and any success you may have had is tied to the dot-com boom which was like CASE take II. As the field matures, I think it is going to get increasingly harder for those that really don't know shit about software and computing architecture to get real engineering positions anymore. (At the very least it is going to be cyclical)

Re:lol

[Anonymous Coward]

It can take time. I remember I had a project where someone on the buisness side was convinced we needed one project coded in VB. Most of the tech people complained, some kissed butt. Suprisingly, I never had a class in VB, so it was time for Borders bookstore. While VB is an easy language, I did spend a fair amount of time learning it, time I could have used doing something else.


For an intelligent practitioner, VB is one of the hardest languages to learn. I know this because I have had to integrate with VB and teach flunkies how to use it. The problem with VB is that it is adhoc. With python (and even perl), for example, there is a core protocol and semantics that is relatively consistent throughout. Yes, there are a handful of inconsistencies, but they are not so bad (like len being a function). This is why python is compared to LISP by the experts so much, even though the languages are very different.
In VB, you have the old QuickBASIC era stuff for File I/O which uses its own weird syntax, and the "objects" don't integrate with other objects. The string ops are lame and also based on the legacy syntax. The COM integration is weird to say the least. Class objects can't have public types. The Collection object is actually COM based and very lame. There is no simple and consistent, and elegant list and mapping construct like there is in just about any high level language designed after 1980. Oh yeah, the error handling is very hilarious. Simple yes, but you need to know a whole bunch of rules when you want to integrate with something complex. This is where the typical VB coder stops and orders the $49 COM control written by some teenage kid who's actually smarter than the shithead VB programmer that is running the anti H1-B visa site in his spare time (coded in VB of course).

For populating some controls on a form and doing some simple ass shit with the FileScriptingObject or a database (that a UNIX weenie would probably do in 3 seconds with a shell pipeline) VB works relatively OK. Also, its OK as a high level extension language when whatever product you're extending has a thorough enough API in COM that you don't need to worry about doing the advanced stuff in VB but I still think Python and Lua are cleaner in these instances.

Personally I like languages with an abstract set of constructs that I can grok even if there are a few syntatic warts. VB has the syntatic warts and no consistent base abstraction. It is an amalgamation of the God awful QuickBASIC, the Win32 API (ironic that calling the Win32 API is generally easier eith Python and Perl than it is with VB), and COM. Of course books sold very well, because the typical VB "coder" can't grok why they need to do weird things to call some basic function of the Win32 API. There was some Appleman guy that made a killing with books on how to simply call the Win32 API from VB. It also set up a whole cottage industry of people that write COM controls to wrap things that are too difficult to do natively in VB like socket programming and regular expressions. The "inexpensive" $49-99 controls add up really quickly. Writing them (which I did for a while when I was between real jobs) consists of taking whatever MIT/BSD/LGPL licensed library does what you need and knowing enough about COM and ATL to wrap it up. Some German guy wrote a complete CORBA ORB in straight VB. I still don't know what to make of that, though it was superbly written considering everything.

Yeah, I have a lot of disdain for the typical VB coders and these idiots put food on my plate for a while. I guess they were/are good for something.

Re:lol

[Eivind Eklund]

VB is NOT an easy language. VB is a very, very hard language.

It is a language that it is simple to get started with, sure, but it is, for a professional programmer, a language full of tedium and details that need to be remembered.

EIvind.

What about other kinds of GPU programming?

[Angst Badger]

It may well be my utter ignorance of how GPUs work, but it would be nice, if possible, to have tools to utilize all of that computing power when I'm just displaying a simple GUI or text interface. I understand GPUs are heavily optimized for what they do, but I expect they're still good for general purpose tasks and might be really useful in some math-heavy applications.

Re:What about other kinds of GPU programming?

[j7953]

As far as I know, one problem is the AGP interface, which gets data from main memory to the graphics card fast but not the other way. This will be fixed with PCI Express, so maybe when more computers have that we will also see some non-display applications of GPUs.

Re:What about other kinds of GPU programming?

[Hast]

You can use it for some things, like anti-aliasing for text and such. That is pretty much what all 3d accelerated window managers are doing. (Though I'm not aware of one for Linux, upcoming Avalon in Windows Longhorn is an example, possibly something like it in OSX too.)

Using GPU for searching in text and stuff like that is not useful though. The point with a GPU is that it is massively parallel and has very deep pipelines. As such it is perfect for doing the same computation on a large image but pretty useless for implementing a standard sequential search. Interestingly the chapter on parallel algorithms was removed from my edition of "An introduction to algorithms" and we got a copied ex of it. At the time I took the course (a few years ago) my though was "Why learn about algorithms which use multiple processors per element, that's never going to be useful." Naturally something like that is pretty trivial to implement with shaders.

In conclusion, with a normal GUI what you could do is to put the entire window manager and display stuff in shaders. Well not all, but a lot of it. Seems like a language like this (Sh) would be perfect for that job. It wouldn't be very useful though, but the amount of useless flashy stuff you could add is immense. ;-)

Sh? maybe. Brook? Definitely.

[Esterhaus_48]

The GPGPU course was at the top of my list for SIGGRAPH 2004 this year, and I was impressed with all of the presenters' material. However, in my estimation, Sh is built to more closely resemble the existing HLSL for DX and similar GLSLang from the ARB.

Brook, on the other hand, was written from a more C-like perspective, and approaches the GPU as a massively data-parallel stream processor (well, Sh does as well, but IMHO Brook achieves that aim more directly as is evidenced by things like iterator streams and similar kernels).

Not there yet for "real" interactive framerates

[adisakp]

I'm a graphics and systems programmer at Midway Games.

I think it will be a while before sh / GPU metaprogramming will be commonly used for "real" games programming. For example, their paper on Worley shaders claimed interactive rates of 14 FPS on a very simple single model for stone shading on the fastest video hardware (6800GT) currently available.

The benefit of HLSL and Cg are that they achieve performance close to or better than the PS/VS-Asembler implementations and are orders of magnitude easier to program. This allows them to be used on hundreds of objects per frame at video game "interactive" framerates (which usually starts at 30 FPS, with 60 FPS as a gold standard, and 300 FPS or other crazy numbers as the Doom/Quake standard for some reason).

Still it's good to see that there are languages evolving that will handle more complex shading algorithms and as the hardware becomes faster in 2 or 3 years from now, this may be practical for real-time use in video games.

Re:Not there yet for "real" interactive framerates

[sdt]

(Disclaimer: I'm Stefanus Du Toit, one of the authors of this book and implementer of most of the Sh compiler/library)

I think it will be a while before sh / GPU metaprogramming will be commonly used for "real" games programming. For example, their paper on Worley shaders claimed interactive rates of 14 FPS on a very simple single model for stone shading on the fastest video hardware (6800GT) currently available.

I should point out that the Worley shaders are rather large shaders. It's not that they're written in Sh that makes them so huge, it's simply the way the algorithm works. The shaders would be approximately the same size if written in Cg (or HLSL, etc.).

The benefit of HLSL and Cg are that they achieve performance close to or better than the PS/VS-Asembler implementations and are orders of magnitude easier to program.

The same holds true for Sh. Both Sh and Cg target "assembly" interfaces such as RB_fragment_program. Sh provides a superset of Cg's functionality. Because in both the case of Sh and Cg the actual program is executed by the GPU, not in any way the system itself, the only difference in performance that might be caused between the two languages would be due to the optimizer. I've actually just rewritten the Sh optimizer, and the only major optimization left to do is common subexpression elimination, and some arithmetic simplifications.

In fact, we already provide an optimization that no other shading language provides (this will be in the next release, and is working in the subversion repository) called uniform lifting. Sh will automatically discover computations which do not change from one fragment to the next, and move them to the host where they can be evaluated more efficiently. This is something that would be difficult to do in other shading languages.

So, to summarize, there is nothing intrinsic about Sh that makes it any slower than Cg. In fact, we're thinking of adding a Cg backend, so that your Sh code can automatically be converted to equivalent Cg code. Then, if you really want, you can take advantage of the backends and optimizations provided by Cg while using the modularity facilities of Sh.

Re:Not there yet for "real" interactive framerates

[Anonymous Coward]

"(Disclaimer: I'm Stefanus Du Toit, one of the authors of this book and implementer of most of the Sh compiler/library)"

Not only that, you have a 4-digit slashdot ID - which makes you a hero in my book :)

(Btw, I think Sh is a _very_ interesting project!)

Best wishes,

Tels

Re:Not there yet for "real" interactive framerates

[spworley]

Yes, 14 fps seems slow, doesn't it? But what are you comparing the 14 fps to? The simple stone model they show isn't an image map, it's fully procedural and not just a texture lookup.

I happen to know a bit about that specific procedural model, and on a modern CPU, I'd expect perhaps about 0.5s to render the same pixels.
So that example is already an order of magnitude faster than CPU evaluations. And GPU speeds scale faster than CPU so this gulf will widen, quickly, with time.

But the poster is correct, GPU metaprogramming is NOT going to be common in games quite yet. But it's going to happen, absolutely, and the time frame is measured in just a year or two, not some vague future date. sh is fascinating because it is a solid attempt to give developers tools to start using the GPU for different kinds of computations, not just polygons/pixels/shading.

And the important applications are likely NOT to be games. Think 3D movie renderering, think fluid simulators, think finite element analysis, think fracture simulation.. all of those massively parallel, highly numeric applications. Graphics is just one of them.

Re:Not there yet for "real" interactive framerates

[adisakp]

Well that's good to know Stefanus. If your performance claims are true, I guess I'll have to take a look at Sh then :-) Now that MK6 is just about wrapped up, the guys on my team are eager to get a chance to learn and explore new technology for upcoming games.

And here's a question that's sure to anger the general Slashdot crowd -- however, the answer will be important in whether or not your language makes it into common usage in the game industry. How do you feel about the use of your technology in closed source proprietary products (like video games)?

Re:Not there yet for "real" interactive framerates

[adisakp]

Hey Steve, nice to see you on this thread. It's been about ten years since we last chatted about graphics back on the Amiga days :-)

I agree with your time frame of a couple years. The stuff in the games industry has been moving crazy fast. Every time we hear about something at SIGGRAPH that can't be done "yet" in realtime, it seems to be about 2-3 years before the hardware is catching up and someone figures out a clever technique to do it.

Re:Not there yet for "real" interactive framerates

[FlunkedFlank]

Too funny, I was about to say the same thing about the ID. And I feel thankful for having one under 800k. Sheesh. :)

Re:Not there yet for "real" interactive framerates

[adisakp]

I happen to know a bit about that specific procedural model

BTW, that's a minor understatement considering it's named after you - LOL :)

Re:Not there yet for "real" interactive framerates

[GooberToo]

Considering the license that he released his efforts under, I think it speaks clear and loud.

The zlib/libpng License

Copyright (c)

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

Re:Not there yet for "real" interactive framerates

[mdmccool]

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.

Re:Not there yet for "real" interactive framerates

[Tei]

which usually starts at 30 FPS, with 60 FPS as a gold standard, and 300 FPS or other crazy numbers as the Doom/Quake standard for some reason).
- - -

Phisics affected by framerate bugs:
[netquake] you can jump higher and cross water faster with faster framerate
[quakeworld] relation with mouse lag, or something similar, etc..

Re:Not there yet for "real" interactive framerates

[mrnohbdy]

In fact, we already provide an optimization that no other shading language provides (this will be in the next release, and is working in the subversion repository) called uniform lifting. Sh will automatically discover computations which do not change from one fragment to the next, and move them to the host where they can be evaluated more efficiently. This is something that would be difficult to do in other shading languages.

How is this different from the preshaders introduced in DirectX 9.0c? Not that I'm an expert on compilers or optimizations, but it sounds to me like they're the same (doing any calculations that aren't dependent on vertex data or data passed from the vertex program on the host system and use them as constants).

Re:Not there yet for "real" interactive framerates

[mdmccool]

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...

sh is awesome!

[thelenm]

I just installed this "sh" thing in /bin, and now all my shell scripts run with 3D shading! This rules!!

Great!

[standsolid]

I was just thinking to myself, "You know what 00 these Bash scripts I wrote are clean, efficient, work well and are extremely portable across multiple platforms... but they lack pizazz." Nwo I have the perfect solution!

too bad this joke doesn't even work because the blurb was basically the whole book article anywyas

/bin/sh

[Tokerat]

Look out for the second book, "Metaprogramming GPUs with bash", and a third and final "Metaprogramming GPUs with X11", comming soon to all fine book retailers.

haha reqs

[comet69]

"Also, a firm background in 3D graphics programming and C++ is a must for the interested reader."

in other words, you must be a slashdot regular

Re:haha reqs

[stratjakt]

Haha, what slashdotter has a "firm background" in anything more technical than "how to plug in an ethernet cable"?

Maybe 5 years ago, not now.

Re:haha reqs

[DNS-and-BIND]

Yeah, there are exactly 4 real posts. The rest are clowning around about how they heard /bin/sh was a unix shell.

Re:haha reqs

[comet69]

hahaha you make me wanna bust out my bad ass red jeans.

Mr. McCool and Mr. Du Toit

[borwells]

I don't care what anyone says. With names like that the book has to be awesome.

Re:Mr. McCool and Mr. Du Toit

[stratjakt]

I got modded troll for noting the authors funny names.

UNFAIR!

Du Toit's first name is Steph-ANUS!

I've seen plenty of Stephans and Stephanies, but never a Steph-ANUS!

I've heard of Staph-Anus, you get that from yo momma.

Re:Mr. McCool and Mr. Du Toit

[Anonymous Coward]

idiot asswipe yeah that's right, I posted AC

triangle drawing example in sh

[dfiguero]

#!/bin/sh

echo #
echo ###
echo ##### :] oh come on!!!

Re:That is sooo... awesome....

[Anonymous Coward]

Seriously, what's with these people? It's not like they've never heard of bourne shell, or that they're running out of names... This is even worse and more blatant than Javascript vs Java. Sheesh!

That was a preemptive Sh

[worst_name_ever]

Sh! Even before you start, that was a preemptive Sh. Just know I have a whole bag of Sh with your name on it.

If nothing else, it serves to confuse outsiders

[pjt33]

Imagine how must fun it must be explaining to the human resource people that yes, you do have experience in sh and Sh, and yes, those are different.

Wow!

[slavemowgli]

Wow. It really is amazing what you can use the good ol' bourne shell for!

"Metaprogramming"?

[geophile]

From the review, it sounds like SH is basically a library, and that library invocations are dressed up through the use of operator overloading.

Is this "metaprogramming"? Googling turns up a variety of definitions of the term, but the term sounds like it should mean writing a program which generates a program. Which is different from a library and syntactic sugar.

Re:"Metaprogramming"?

[sdt]

From the review, it sounds like SH is basically a library, and that library invocations are dressed up through the use of operator overloading. Is this "metaprogramming"?

Yes, because rather than just executing the the operations you specify, Sh has a special "retained mode", which instead collects these operations, builds an intermediate representation of them, runs an optimizer and passes them on to a backend compiler. For example:

void foo() {
ShAttrib3f x, y, z; // three Sh variables
x = y + z; // Executes immediately
ShProgram prg = SH_BEGIN_PROGRAM() {
ShAttrib3f i, j, k;
i = j + k; // Doesn't execute, gets collected
} SH_END;
}

So, the bits that are written inside the declaration of "prg" (the above is valid C++/Sh), are actually collected into prg, instead of being executed. prg can then be compiled to a GPU (or CPU) backend and sent to the GPU to run. Thus, your C++ program is used to write Sh programs at runtime. This allows all sorts of metaprogramming techniques.

We also provide further levels of metaprogramming with the shader algebra operations, but that's at an even higher level. These let you take previously written Sh programs and combine them in various ways, at run time. See our SIGGRAPH paper for details.

The About Page on our homepage tries to explain this in more detail.

Re:"Metaprogramming"?

[mdmccool]

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.

Re:"Metaprogramming"?

[mdmccool]

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 ;-)

Re:"Metaprogramming"?

[Anonymous Coward]

Yes, because rather than just executing the the operations you specify, Sh has a special "retained mode", which instead collects these operations, builds an intermediate representation of them, runs an optimizer and passes them on to a backend compiler.

It sounds like you just described incremental compilation. Incremental compilation is still not the same thing as metaprogramming, even if it means you can target the GPU at runtime and optimize the code at runtime.

You didn't give any indication that the user's C++ code can dynamically create semantically different code at runtime. Instead, you just gave an example that makes it looks like you can defer compilation of static code (which probably is even syntax-checked at compile time!) until later. So, maybe your system does allow metaprogramming, but if so, you still haven't really made it clear that you know what metaprogramming means.

Re:"Metaprogramming"?

[mdmccool]

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.

SMP GPU's

[thelinuxjunkie]

Is anyone working on a method of using the GPU on some of the faster video cards to offload processing power to from the cpu?

Is it even feasible?

Re:SMP GPU's

[Anonymous Coward]

RTFA
This is excactly what this library does. Search for GPGPU...

Don't Believe Everything You Read

[Exos]

Unfortunately, the developers of Sh chose to publish the book which details features which are not yet supported in the library. Since the software is currently in the alpha stage of development and constantly changing, many of the examples described in their book do not work as expected (the minimal GLUT example doesn't even compile).

In short, a lot of work remains before they meet their full project goals. The name, however, which is an abbreviation of Serious Hack, seems quite appropriate.

Re:Don't Believe Everything You Read

[sdt]

Unfortunately, the developers of Sh chose to publish the book which details features which are not yet supported in the library.

Yes, this is true. If we had written the book based entirely on what we had implemented at the time, it would however have become out of date completely very quickly. Instead we chose to write the book as a specification. Too many programming language books, and books describing systems become out of date as soon as they are published, so it's a tough decision to make.

I should point out that we are getting closer to full support of everything in the book every day. Most of the missing features are very simple things like missing library functions. Sh works, right now, and can be used to write real shaders.

With the next release I will post a fixed version of the glut example. As unfortunately happens so often, the example got broken during book writing stage...

You're welcome to browse our Issue Tracker. Progress has been slow of late because I've been working hard on the optimizer, and we've been busy with non-Sh-related things. However, note that most of the issues in the track are either "easy" or "bitesized", and once development gets on track again (in a week or so) I expect most of them to be resolved quite quickly.

Re:Don't Believe Everything You Read

[mdmccool]

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.

And math, too!

[meburke]

The GPU ought to be able to be optimized for FP arithmetic, also.

This idea is not mine, but back when the first Netra came out, a couple of guys here in Houston who used to optimize Crays figured out how to use the GPU to do floating point arithmetic a whole magnitude faster than Sun knew it could be done.

My optimization skills are a little rusty, but the same architectural elements are there in the ATI graphics cards.

If some one does this, drop me a line and tell me how you did it.

Re:And math, too!

[Jerry Talton]

The big problem with FP operations on GPU hardware right now is that nobody conforms to the IEEE standard. There's been some work at Stanford on determining exactly how much error propagates, but there's variation not only between the major card companies, but between individual cards and even between vertex and fragment FP units on a given same card!

Floating point operations aren't much use unless you have some idea how accurate they are.

Re:And math, too!

[mdmccool]

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 ;-)

Mods on crack.

[gatekeep]

C'mon.. someone has to make a post to point out an obvious problem like that. When I first saw this article there were no posts yet. Would you prefer I just ignore that eyesore?!

Re:Not really.

[tiger99]

Yes, and I don't see why you could not run an entire GUI in the GPU. Maybe not right now, but if the chip manufacturers wanted to make it possible it would not be too difficult. Just imagine, X running in the GPU, the CPU(s) free to get on with non-graphical tasks....

It is one place that an OS architecture which makes a clean separation of GUI and kernel would win over the mess of sundry .dlls from the Criminal Monopoly. The other place would have been the ill-fated tablet computer, had it been correctly designed, with the X serevr on the portable bit.

Because simple single-processor relatively high-performance silicon is now very affordable, the time is right to go back to parallelism, dedicated I/O and graphics processors, etc, to get even better performance.

It would be nice to have a GPU compiler to run ordinary code, such as X, but the compiler would be different for each architecture, not like AMD vs Intel, where you can use the same compiler with just the optimisations tweaked. But my thinking is to replicate a full CPU in the GPU chip or at least on the graphics card. You could put a Pentium/Athlon there, feeding the gPU as usual, fed itself from the AGP bus or its successor via a big FIFO.

But whatever way things go, I do think we are in for some big steps forward in graphics processing, at least. I am not into shaders and so on, I don't need fast 3-D or anything like that, but I know that many people do, and not just for games. But if it offloads things from my main CPU, I would find immediate benefit.

I saw this a long time ago

[Anonymous Coward]

I'm going to say the obvious here, but the biggest problem is that it is metacode. There is no separation between code and data. The only way you could load shaders dynamically is if you compiled the shader into a DLL and loaded that at runtime. I work in the games industry and we use and have coded inhouse tools that let the artists and level designers make and tweak shaders. It would be a total nightmare for us devs if they were to use this to create shaders as opposed to something like Cg or HLSL.

We have experimented with a few dynamic shaders (mainly to create specialized ones for LOD and to reduce the number of light/shadow passes), ones that you build with string concatenations and send to the shader to compile at runtime. I'd prefer doing it that way as opposed to Sh still because we can offload that sort of stuff to our embedded scripting language which makes working with strings a bit easier and more natural than C++.

It's an impressive hack, but not something I would use for creating a real world app.

Re:I saw this a long time ago

[mdmccool]

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.

Re:I saw this a long time ago

[Anonymous Coward]

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.

Precompiled representation: security, less bloat(?), and more portable since it doesn't rely on the host's instructions/executable format. DLL one: more flexible since you have unrestricted access to the CPU.

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...

I'm not targetting embedded devices so this really isn't an issue. The compilation speed and memory requirements of dynamically coded shaders/metacode has been negligable for us so far. It sure as hell saves us the headache of compiling shaders with the thosands of different permutations of parameters and or LOD system more than makes up for the tiny compilation hit. We did even code up a LRU cache for them just incase.

I agree, the relationship thing is a huge problem. It's not as cleanly done in *any* of the GPU shading languages mostly due to the legacy fixed function pipeline, vendor implementation flexibility, and dare I say it: people ripping off Renderman without knowing why Renderman's shading language was specified the way it is.

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.

How is that different than mapping those to something that concatenates strings? It seems to me that would do the exact same thing as Sh but without the extra level of indirection. Maybe Sh offers more optimization opportunity?

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++.

Our Maya setup lets us create or use prebuilt shaders, hook them up in the scene graph, and play around with the parameters like sliders or input textures. It lets the artists play around with this stuff in real time on their model without having to load our game or *shudder* integrate the game renderer to the content creation tool. Most importantly we have it where it can access the source tree and it touches a minimum amount of files and doesn't require them to run a slow compilation phase.

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.

I can see where you're going with Sh though, provide an extra level of indirection to shading languages so you can code the stuff directly in C++ (or write your own bindings for it). I think Apple did something similar with coregraphics that creates optimized shaders on the fly to run their new realtime effects in Tiger and Motion.

Re:I saw this a long time ago

[mdmccool]

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.

Re:That is sooo... awesome....

[mdmccool]

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".

Re:That is sooo... awesome....

[Anonymous Coward]

But, we figured no-one would be silly enough to confuse a C++ library with a scripting language

Uh, no. *nix users use sh a lot. The whole OS is basically started with the Bourne shell language. There's a precedent for the Unix sh language. going all the way back to the 1970's.

You're posting to Slashdot of all places and defending that misnomer?! How 'bout you broaden your horizons from the Windows world?

How long to a GPU card only computer?

[Anonymous Coward]

How long will it be before we see a modded GPU graphics card with a power supply being the only hard used to make a computer?

Re:Not really.

[Technonotice_Dom]

Just to pick up on a little bit from your comment:

The other place would have been the ill-fated tablet computer, had it been correctly designed, with the X serevr on the portable bit.

I thought about this a couple of months ago - how great it'd be to have a tablet PC that was literally just an X/VNC/RDC/Citrix server. With a GPU that most of the hard work could be dedicated to, and possibly something like a Transmeta/C3 etc type CPU for networking, device management etc - which wouldn't require much work.

I did some searching on it a while back but only found some Windows CE (or something similar, Tablet edition possibly?) powered tablets that were somehow designed to use RDC normally... I don't want to run an fully-fledged operating system when I'm logged into a remote server! Save the battery power for the display and get rid of that big CPU, it isn't needed.

You could probably make them smaller, consume much less power (or make it last even longer). Combined with systems where you can detach your session at your desktop PC and move it to your tablet remote client, it'd be an excellent tool.

Surely somebody's thinking about doing this or already has done? As I said, the only ones I've found run Windows in the background.

Re:That is sooo... awesome....

[Erik Hollensbe]

I'm glad that I wasn't the only one that thought that this meant finding a vertex meant using 'grep'....

Re:That is sooo... awesome....

[mdmccool]

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.

Re:Not really.

[Hast]

I have to say that I'm not well versed in the specifics of how a normal window manager works. From what I've understood of Avalon the idea there is to put as much as possible in the OS, and let the OS delegate stuff to the GPU as it sees fit. So your app would write stuff to a buffer but the OS handles double buffering and all things like that.

Putting all of X on a GPU would probably not be a good idea however. (For reasons to be mentioned later.) And while you can free up your CPU from the specifics of GUI handling even on my old 233MHz Pentium X and Fluxbox only use a percent or so of CPU power. We're not talking a significant amount of saving here. The main benefits would be lots more flash (some even useful) and perhaps things like really nicely rendered text.

Running general code on a GPU is not something you want to do though. The entire idea of having a processor optimized for parallel processing is to NOT run sequential code on it. Furthermore a standard GPU has very long pipelines (on the order of several hundred stages, compared to 20'ies for a CPU with long pipelines) this means that branching is expensive. Currently you can't even do real branching on GPUs, that stuff is still handled by the CPU.

Furthermore a GPU is only fast if you can use parallelism. Most common programs have very little parallelism, and even the most advanced compiler algorithms are hard pressed to extract what little parallelism there exist. To make things even worse GPUs want to execute in SIMD structure, so it uses the same general instruction but on many sets of data. Typical example is doing the same calculation on every pixel in an image, that is very parallel even if all the individual pixels may be different. Doing a histogram (where you sum all individual instances of each pixel value) is something which a CPU will be better at doing.

You could naturally spend a lot of time to make a GPU general enough to execute code like a CPU but then you'd only end up with another CPU. That's pretty stupid since it's much cheaper and efficient to just add one in SMP or SMT (or even hyper threading) manner.

And FYI all modern GPUs can run ARB shaders, which are general. (Well, in reality the drivers translate it to internal shaders, but the programmer doesn't have to care.) So you don't have to compile separately for each GPU. Much like how the internal micro-code on CPUs differ but the exposed assembly is x86 style.

Currently the biggest problem with General-GPU applications is that the AGP is pretty slow at reading data back from the card. Future standards will hopefully help us there though.

All that said, I recommend you and others to play around some with shaders on modern GPUs. It's quite fantastic what you can pull off with little effort.

Re:That is sooo... awesome....

[Anonymous Coward]

Yeah, nobody would ever confuse the two, except perhaps, I dunno, SEARCH ENGINES.

Tards.

lisp for games

[dododge]

In college, my prof made us write a game in LISP just to prove that some languages are bad at certain things.

Just a data point: Naughty Dog is well-known for the heavy use of Lisp (an in-house dialect called GOAL) in their games, including the Crash Bandicoot and Jak and Daxter series.

Re:That is sooo... awesome....

[Anonymous Coward]

But, we figured no-one would be silly enough to confuse a C++ library with a scripting language

If I were you, I'd be a wee bit more careful with calling half the software professionals in the world "silly". Look at the title of this article, think of the titles of other articles and books that would be written, think of the many graphics programmers who'll get calls by recruiters offering them Unix admin jobs...

Get over it.

Fuck you asshole.

Pygame - SDL-Python

[Anonymous Coward]

Check it out.
http://pygame.org/

http://pyopengl.sourceforge.net/

Hello world

[fikx]

"Chapter three contains a quite interesting sample shader that uses constructive solid geometry techniques and metaprogramming in Sh to render text." Which means it can do one of the most complicated sounding "Hello World" programs of any language!

Slight digression

[delphi125]

You are suggesting that the CPU and GPU - which are very different beasts, as other posts mention - try to work as effectively a multi-processor system.

The only problem with that is that when there is a lot of work, they are often both working full-out already. I agree it would be nice if GPUs could also do less specialized (i.e. completely different) parallel processes, but I am sure someone will be able to hack even the current generation to do say weather modelling if they really want to.

Anyway, to digress as promised: I think that for the near future, asymmetric multi-processing might have some promise. By this I mean a slow processor, a fast processor, and a parallel (graphics) processor - perhaps multiple of the latter two.

The point of this would be to allow the entire system to run... without the 'CPU' or GPU even being powered up - and nor, for that matter, all the memory either, necessarily.

So you would have the efficiency of mobile chips combined with the available power (kWh and MHz) of the newest and greatest as and when required.

Now the 'slow' CPU is actually the master. As such, it runs the core OS, I/O - including screen refreshes if and when necessary, and also simpler programs.

The 'fast CPU' kicks in when needed or asked to, to run heavier tasks, such as a compile cycle. When it has no threads left, it returns to dormancy, and low power.

Similarly, the GPU only runs when needed. Typically this would be for games or other graphically intensive applications. As I mentioned, if they could be made able to cope with other parallel chores too, then they might be used just for that too.

Once the infrastructure exists on the motherboard to have three disimilar processors working together, there is no reason not to extend this concept to multiple 'fast' processors.

For example, two fast CPUs and two fast GPUs. This might be a standard home system for a couple or family: no more expensive than two seperate systems, yet much more flexible. Can run as a server at low power, or have two hungry games at the same time, or one DoomIV, using the two GPUs for half the work each.

Also overclocking and other such risks on such a system would be far less of a problem. At worst, the expensive process crashes - but the slow CPU takes over straight away.

Of course the slow CPU does have to run a genuine real-time OS, and be stable.

The only problems I can see are overcomeable. For example, utterly different processors might mean that some kind of byte-code is preferable - or you have to use the lowest common denominator. Similarly switching a program to the fast processor from the slow when needed would require state to be saved and then reloaded etc. - less of a problem for games than office work.

To return to graphics: this kind of architecture would allow lots/dozens/bazillions of GPUs to work in parallel. Just allow each a certain amount of screen/wall. Merging results at edges would take care of some alias-type problems, I think - that is to say, if each 'tile' were responsible for 120x120 pixels, it could actually render 128x128 - leaving 8 on each side of the border to be balanced according to a quick weighting scheme.

As I said - a digression.

Playstation Super-computers and Clusters

[billstewart]

Been Done, more or less. NCSA's Scientific Computing on Playstation 2 web page. Supercomputer Cluster of ~70 Playstations, Easy-to-read glossy BBC Article. GPUs and DSPs aren't particularly good at general I/O or interrupt handling, but they're really good at chowing down on a stream of data fed to them by a more general processor, so projects like this generally use the GPU for computation and the main CPU for communications and user interface.

There have been systems like this using DSPs for years; I've worked with some of them in the mid-late-80s. The Bell Labs DSP supercomputer had a tree-structured network of DSPs, and I think a more general-purpose processor at the root, back when 25 MFLOPS was blazingly fast for a single floating-point DSP, and the box had 127 of them, producing up to about 2 GFLOPS on applications like FFTs. It was one of the fastest ray-tracers around.