[Haskell-cafe] Looking for final year project - using Haskell, or another functional language

Fri Jul 13 11:10:26 EDT 2007

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.

First off, a basic idea of what ray tracing is:
http://en.wikipedia.org/wiki/Ray_tracing

Second, for great reasons why ray tracing is useful and probably
neccessary for the future, Dr. Kavita Bala gave a talk in 2005
(abstract:
http://www.acm.uiuc.edu/conference/2005/speakers.php#KavitaBalaAbstract
video:
http://www.acm.uiuc.edu/conference/2005/video/UIUC-ACM-RP05-Kavita-Bala.
wmv).  I don't recall if she explicitly says it, but applying her
"feature" emphasis approach to procedurally generated textures (which
should scale in resolution perfectly) would be a way for a modern engine
to really shine.

During the same conference Dr. Peter Shirley gave the talk "Real Time
Ray Tracing on the Desktop: When and How?" (abtract:
http://www.acm.uiuc.edu/conference/2005/speakers.php#PeteShirleyAbstract
video:
http://www.acm.uiuc.edu/conference/2005/video/UIUC-ACM-RP05-Peter-Shirle
y.wmv) Shirley decides in that video that a hardware based solution is
what he should shoot for, and his group joins the Saarland University
Graphics Group.

[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:

ATI's Stream Computing:
http://ati.amd.com/technology/streamcomputing/index.html
NVIDIA's CUDA: http://developer.nvidia.com/object/cuda.html

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

________________________________

From: wp [mailto:walter1003 at gmail.com] 
Sent: Thursday, July 12, 2007 6:41 PM
To: Re, Joseph (IT)
Subject: Re: [Haskell-cafe] Looking for final year project - using
Haskell,or another functional language

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 at morganstanley.com
<mailto:Joseph.Re at 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 at 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.
--------------------------------------------------------

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070713/e3ac037f/attachment-0001.htm