If you meant just non-graphic uses of a gpu, I don't
know much in that area, but I do know of a very neat graphics related
(but irregular on standard gpus) topic; ray tracing.
[Note: if you are willing to watch both of these I
recommend watching Dr. Shirley's first. Also, note that some videos have delayed
starts.]
Shortly thereafter, their groups make a number of
advancements in ray tracing, and they created a working RPU (http://graphics.cs.uni-sb.de/SaarCOR/)
on a FPGA board that is capable of rendering basic scenes in realtime as
well as come out with a software solution that does roughly the same called
OpenRT (http://www.openrt.de/). Both
implementations scale accross multiple processors very well due to inherent
parallelism in ray tracing. My guess is that a realtime engine (and a good
game) using software ray tracing will help it gain popularity, but then
dedicated boards made from the FPGA designs will take over shortly thereafter
("High end graphics cards from NVIDIA provide 23 times more programmable
floating point performance and 100 times more memory bandwidth as our
prototype").
Concurrently there has also been work of doing ray
tracing on existing GPUs. Here's a neat paper from someone at my
university, on structures for using a gpu for ray tracing, "Fast GPU Ray Tracing
of Dynamic Meshes using Geometry Images" (http://graphics.cs.uiuc.edu/geomrt/geomrt2006.pdf).
I'm unaware if he applies any of the breakthrough techniques learned from
OpenRT's research (since it's very recent), but if not, that would
certainly be a viable topic to explore within the realm of GPGPU-ish
work.
Getting a really performance optimized haskell
implementation of OpenRT or bindings to an existing library (http://liris.cnrs.fr/~bsegovia/yacort/ or
http://xfrt.sourceforge.net/) would be
very cool, especially when combined with a shader dsl, a procedural generation
library+dsl, overall graphics engine, and *dreams on*. At that
point, someone could easily write the world's most beautiful nethack
with little artistic skill.
-----------------
Non-graphics related GPGPU uses:
Both of these allow you to code in "the standard C
language" and "low level assembly language layer and driver interface". A
number of open source GPGPU libraries (BrookGPU http://graphics.stanford.edu/projects/brookgpu/index.html and
Sh http://libsh.org/) shoot for "C++". One
would think that given how well programming GPUs lends itself to a
functional language, clearly, they must be appealing to the
lowest common denominator, but their language for the "hardcore" is some god
awful assembly language...
[defense]
I
get that they're performance nuts, but when's the last time you wrote a large
and meaningful application in assembly (not a single inlined assembly
function) by hand, that beat using your compiler (it terms of developer+system
execute time)? If you can answer, my guess is either you're
working on a compiler, or yours is broken.
[/defense]
Writing a real language for general progamming on GPUs
would be pretty cool, although you'd have to then think of something to do with
it as otherwise it might be a short project (rough guess considering the
existing work in the area).
Did either of these help?
-- Joseph Re
Hi Joseph,
no, I don't mind if you cc the list.
I just
skimmed the two papers on Vertigo and Renaissance. Very interesting ... and not
just that. I have been following in the last months/years the advances of GPGPU.
Surely a lot of people think this is nothing of practical usage, especially if
it comes to serious mathematical computation, or is there already a GPU which
supports double float by now? ...
Something in this direction would surely
be nice ...
Can you point to some more papers like
those?
Thanks
walter.
On 7/12/07, Re, Joseph
(IT) <
Joseph.Re@morganstanley.com> wrote:
No problem. I have
a strong interest in the non-graphics portions of game engines and
simulations, but as good visual representations are a critical part of
expressing those parts, I prefer keeping my exposure to the graphics systems
as painless as possible. Therefore, while I'm by no means an expert, I
occasionally think/read papers about a graphics engine "done right"
and other lib/tools I only see as a means to an end (and thus not
something I plan on tackling myself) just so I'm ready when people like you come along.
;)
I tried to cover a wide range
of different areas to get something that strikes your fancy, but if
you're especially interested in any specific area, I can provide additional
help (mostly in terms of papers to check out, but a few original ideas as
well).
[I prefer CCing the list if that's
alright with you, because I'm limited to certain a mailbox during
weekdays and another during nights/weekends]
From: wp [mailto:walter1003@gmail.com]
Sent: Thursday, July 12, 2007 4:11 PM
To: Re, Joseph
(IT)
Subject: Re: [Haskell-cafe] Looking for final year
project - using Haskell,or another functional
language
Hi Joseph,
this is an impressive summary of ideas!
By far the best someone sent me so far.
Thank you very much for
this. At this point I really don't mind about the formatting:)
So, as I
like programming, but it's still the case that I am a beginner in Haskell some
of the ideas might be quite advanced for me; further, I never really did
graphics programming, but I would for sure learn a lot doing something in this
direction.
Another company suggested a similar idea to yours, building a
DSL for textures and model generation ... DSL seems anyway a hot topic at the
moment (or is it a revival?).
I am working with q/kdb+ and am particularly
interested in seeing that Credit Suisse is currently building a DSL embedded
in Haskell .... hopefully some more of these languages will follow soon:) IT
people would certainly have more fun doing their job, avoiding long debugging
session:)
Again, thank you very much for your
effort!
walter
NOTICE:
If received in error, please destroy and notify sender. Sender does not intend
to waive confidentiality or privilege. Use of this email is prohibited when
received in error.