Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Metaprogramming GPUs with Sh

Posted by timothy on Wed Sep 22, '04 03:30 PM
from the at-least-it's-not-obscure dept.
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.


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.

This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • Wow

    (Score:4, Funny)
    by Anonymous Coward on Wednesday September 22, @03:31PM (#10321809)
    I thought I'd accidentally clicked on this article.
  • Anyone Else Notice...

    (Score:1, Offtopic)
    by jchawk (127686) on Wednesday September 22, @03:31PM (#10321813)
    (http://www.tr0n.com/ | Last Journal: Thursday September 26, @09:47PM)
    Is this the longest headline blurb ever?

    • 1 reply beneath your current threshold.
  • Template broken?

    (Score:2, Offtopic)
    by Carnildo (712617) on Wednesday September 22, @03:31PM (#10321814)
    (http://secondlife.com/ | Last Journal: Monday December 27, @09:12PM)
    Is the book review template broken or something? This is the second review in as many days that's been misclassified.
  • Front Page Story

    (Score:4, Funny)
    by mnemonic_ (164550) <jamec@@@umich...edu> on Wednesday September 22, @03:31PM (#10321815)
    (http://www.umich.edu/~jamec)
    Awesome story formatting. Looks great!
  • That is sooo... awesome....

    (Score:5, Funny)
    by illumin8 (148082) on Wednesday September 22, @03:32PM (#10321822)
    (Last Journal: Thursday April 28, @08:02PM)
    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!

    (Score:1, Offtopic)
    by Chuck Bucket (142633) on Wednesday September 22, @03:34PM (#10321847)
    (http://pitchforkmedia.com/ | Last Journal: Tuesday March 23, @10:08PM)
    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

    (Score:5, Funny)
    by philfr (89798) on Wednesday September 22, @03:35PM (#10321857)
    At first read I thought they ported bash to the Radeon GPU...
    • Re:/bin/sh by robbo (Score:2)Wednesday September 22, @07:13PM
    • Re:/bin/sh by Trejkaz (Score:2)Wednesday September 22, @11:34PM
    • Re:/bin/sh by einhverfr (Score:3)Wednesday September 22, @03:48PM
      • Re:/bin/sh by fitten (Score:1)Wednesday September 22, @04:45PM
        • Re:/bin/sh by trippinonbsd (Score:2)Wednesday September 22, @06:26PM
          • Re:/bin/sh by mvdw (Score:2)Wednesday September 22, @07:55PM
            • Re:/bin/sh by trippinonbsd (Score:2)Wednesday September 22, @08:50PM
          • 1 reply beneath your current threshold.
        • 1 reply beneath your current threshold.
      • Re:/bin/sh

        (Score:4, Interesting)
        by jericho4.0 (565125) on Wednesday September 22, @05:20PM (#10323157)
        On SGI machines there is a '/dev/opengl', that one can pipe openGL bytecode to.
        [ Parent ]
        • Re:/bin/sh by marcansoft (Score:1)Wednesday September 22, @06:40PM
          • Re:/bin/sh by T-Ranger (Score:2)Wednesday September 22, @08:14PM
      • Re:/bin/sh by j3110 (Score:2)Wednesday September 22, @07:43PM
      • 1 reply beneath your current threshold.
    • 2 replies beneath your current threshold.
  • SDL-perl

    (Score:4, Insightful)
    by Speare (84249) on Wednesday September 22, @03:37PM (#10321881)
    (http://www.halley.cc/ed/)
    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 by ventonegro (Score:1)Thursday September 23, @09:16AM
    • lisp for games by dododge (Score:1)Wednesday September 22, @11:36PM
    • 4 replies beneath your current threshold.
  • Amazon linkage

    (Score:4, Informative)
    by bujoojoo (161227) on Wednesday September 22, @03:37PM (#10321885)
    Or, buy it from Amazon [amazon.com]
  • /bin/sh

    (Score:4, Funny)
    by rcamera (517595) on Wednesday September 22, @03:41PM (#10321934)
    (http://rcamera.org/)
    i always do my low level device programming in sh. my graphics card has never been faster!

    sed | awk | sed | grep | awk | sed | awk
  • sh?

    (Score:2, Funny)
    by courier12point5 (662279) on Wednesday September 22, @03:43PM (#10321950)
    (http://www.courier12point5.com/ | Last Journal: Saturday April 19, @12:35AM)
    What if I want to use korn or csh?
    • 1 reply beneath your current threshold.
  • lol

    (Score:3, Insightful)
    by here4fun (813136) on Wednesday September 22, @03:44PM (#10321968)
    (http://forum.penpals.com/index.php? | Last Journal: Monday September 13, @02:52PM)
    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?

  • by Angst Badger (8636) on Wednesday September 22, @03:45PM (#10321986)
    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? by j7953 (Score:2)Wednesday September 22, @04:40PM
    • Re:What about other kinds of GPU programming? by Hast (Score:2)Wednesday September 22, @04:54PM
      • Re:Not really.

        (Score:4, Interesting)
        by tiger99 (725715) on Wednesday September 22, @05:14PM (#10323077)
        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.

        [ Parent ]
  • Sh? maybe. Brook? Definitely.

    (Score:5, Informative)
    by Esterhaus_48 (634600) on Wednesday September 22, @03:47PM (#10322002)
    (http://gridjack.net/)
    The GPGPU course [gpgpu.org] 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 [stanford.edu], 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).
  • by adisakp (705706) on Wednesday September 22, @03:50PM (#10322037)
    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.
    • by sdt (7606) on Wednesday September 22, @04:09PM (#10322222)
      (http://3.141592.org/)

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

      [ Parent ]
      • by adisakp (705706) on Wednesday September 22, @04:43PM (#10322661)
        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)?
        [ Parent ]
        • by GooberToo (74388) on Wednesday September 22, @06:02PM (#10323704)
          (Last Journal: Tuesday September 30, @10:54AM)
          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.
          [ Parent ]
      • Re:Not there yet for "real" interactive framerates by mrnohbdy (Score:1)Thursday September 23, @12:21AM
      • Re:Not there yet for "real" interactive framerates by FlunkedFlank (Score:1)Wednesday September 22, @04:49PM
      • 1 reply beneath your current threshold.
    • by spworley (121031) on Wednesday September 22, @04:37PM (#10322588)
      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.
      [ Parent ]
    • Re:Not there yet for "real" interactive framerates by Tei (Score:1)Wednesday September 22, @08:57PM
    • Re:I saw this a long time ago by mdmccool (Score:2)Wednesday September 22, @08:35PM
    • 1 reply beneath your current threshold.
  • sh is awesome!

    (Score:3, Funny)
    I just installed this "sh" thing in /bin, and now all my shell scripts run with 3D shading! This rules!!
  • 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

    (Score:3, Funny)
    by Tokerat (150341) on Wednesday September 22, @04:02PM (#10322163)
    (Last Journal: Tuesday August 10, @02:19AM)

    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

    (Score:1)
    by comet69 (198367) on Wednesday September 22, @04:05PM (#10322187)
    (http://www.theaudiorevenge.com/ | Last Journal: Wednesday December 15, @03:02PM)
    "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 by stratjakt (Score:2)Wednesday September 22, @04:08PM
      • Re:haha reqs by DNS-and-BIND (Score:2)Wednesday September 22, @04:24PM
      • Re:haha reqs by comet69 (Score:1)Wednesday September 22, @04:31PM
  • Mr. McCool and Mr. Du Toit

    (Score:4, Funny)
    by borwells (566148) on Wednesday September 22, @04:09PM (#10322226)
    (http://www.flickr.com/photos/txgeek/)
    I don't care what anyone says. With names like that the book has to be awesome.
  • by dfiguero (324827) on Wednesday September 22, @04:09PM (#10322238)
    #!/bin/sh

    echo #
    echo ###
    echo ##### :] oh come on!!!
  • That was a preemptive Sh

    (Score:3, Funny)
    by worst_name_ever (633374) on Wednesday September 22, @04:27PM (#10322459)
    Sh! Even before you start, that was a preemptive Sh. Just know I have a whole bag of Sh with your name on it.
  • Wow!

    (Score:2)
    by slavemowgli (585321) on Wednesday September 22, @04:38PM (#10322600)
    (http://tinyurl.com/ajlpf)
    Wow. It really is amazing what you can use the good ol' bourne shell for!
  • "Metaprogramming"?

    (Score:2)
    by geophile (16995) <jaoNO@SPAMgeophile.com> on Wednesday September 22, @04:50PM (#10322743)
    (http://geophile.com/)
    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"?

      (Score:5, Informative)
      by sdt (7606) on Wednesday September 22, @05:00PM (#10322870)
      (http://3.141592.org/)

      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 [libsh.org] on our homepage [libsh.org] tries to explain this in more detail.

      [ Parent ]
  • SMP GPU's

    (Score:1)


    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?
    • 1 reply beneath your current threshold.
  • by Exos (241632) on Wednesday September 22, @05:00PM (#10322866)
    (http://home.myuw.net/dgerstma)

    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 [serioushack.com], seems quite appropriate.

    • Re:Don't Believe Everything You Read

      (Score:5, Informative)
      by sdt (7606) on Wednesday September 22, @05:06PM (#10322954)
      (http://3.141592.org/)

      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 [libsh.org]. 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.

      [ Parent ]
  • And math, too!

    (Score:2, Interesting)
    by meburke (736645) on Wednesday September 22, @05:08PM (#10322994)
    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.
  • Hello world

    (Score:1)
    by fikx (704101) on Thursday September 23, @10:38AM (#10328896)
    "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!
  • Re:Hilarioius

    (Score:2)
    by Jason1729 (561790) on Wednesday September 22, @03:49PM (#10322026)
    Hey, I had McCool as a prof for CS 246 at UWaterloo.
    [ Parent ]
    • Re:Hilarioius by mdmccool (Score:1)Wednesday September 22, @05:33PM
      • Re:Hilarioius by Jason1729 (Score:2)Wednesday September 22, @08:07PM
    • Re:Hilarioius by p2sam (Score:2)Wednesday September 22, @04:41PM
    • 1 reply beneath your current threshold.
  • Mods on crack.

    (Score:2)
    by gatekeep (122108) on Wednesday September 22, @05:14PM (#10323070)
    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?!
    [ Parent ]
  • 15 replies beneath your current threshold.