Slashdot Mirror

You can; look at Brook GPU and libSh.

Another great idea that will no doubt be poorly implemented and suffer from a closed spec, stifling developer input.

At the risk of becoming -1 redundant, many other posters have already pointed out that stuff like this should be done in a generic shader language so that it can be run across a gamut of GFX cards - I'm no programmer, but in my mind this would be like current CPU apps asking "do you support MMX? SSE? SSE2?" etc etc etc. Interesting projects like LibSh offer to provide a platform-independent method of integrating GPU shader routines into standard C++ programs.

I'm afraid I can't get too worked up about ATI's implementation though. What with their "what's Linux?" reputation and the heavily competitive/proprietary world of GPU subsystems, I find it unlikely that they'd open up an API to allow non-ATI apps to hook into the GFX card, meaning that I wouldn't be able to use my GPU to speed up my XviD transcodes in VDubMod. I wish they'd prove me wrong, but I doubt it somehow. All glitz and no geek (unless of course it does turn out to be written in a platform independent shader language that allows anyone to hook into it, then I'll eat my words ;)).

Ok, then we agree. My fault if I misunderstood what you were saying. I was just using OpenGL as an example, but you're obviously well versed on the matter.

I've been checking out the Sh project and it's a lot of fun. I agree; I'd like to see other vendors embrace the GPU as an 'it isn't just for graphics anymore' processor.

There are libraries for some of that here... http://graphics.stanford.edu/projects/brookgpu/ and here... http://libsh.org/

I had a play with BrookGPU a while back, running parallel test jobs an AGP GF4 GPU, and PCI GFFX GPU. Worked well enough, but that was on PCI and AGP bus, and it killed the CPU trying to keep up with the GPUs. Probably needed bigger datasets to keep the GPUs busy or something...

Anyway, if there's an easy way to load-share accross these things using a single graphics context, I reckon it's got huge GPGPU potential.

See here.

Although in theory modern GPUs can do arbitrary computations, that doesn't mean that you'd always benefit from doing the math there. However, for statistical computing, I'd think you could potentially see a large benefit.

There's a poster for the implementation of the Worley basis functions available on the website. You can also get the source code for these shaders by downloading "shrike", our demo application, from the http://libsh.org/ website.

Call it "shlang" if it makes you happy. Also easier to pronounce ;-). But it's not really a language; it's really a library. The website is http://libsh.org/, so calling it "libsh" is also acceptable if you would like to avoid confusion.

A lot of other shading languages don't even really have names. The OpenGL shading language is called... the OpenGL Shading Language. The Microsoft shading language is called... the High-Level Shading Language. More of a marketing statement, really ;-). The Renderman Shading Language is called... the Renderman Shading Language. The Stanford Real-Time Shading Language is called... Ok, so Cg has a real name. The exception ;-) The bottom line is that it's really hard to come up with names that are meaningful and haven't been taken.

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.

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.

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.