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@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@morganstanley.com mailto: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. -------------------------------------------------------- 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.