   GPGPU stuff
  Hey folks. I am currently looking to take advantage of the stream processing nature of the graphics card to do some general number twisting.I am new to all this so I would like to know your personal experiences with the technology. Anecdotes and other subtle things that one is unlikely to find in papers, wikipedia, articles etc. I already have a number of those to look at.What I would like is the human side to this. If you have used it on a project I would to know your experience with it. Why did you choose it, what was your project, did it end up fitting?As well general advice is good. What are the common misconceptions, pitfalls of the inexperienced, limitations and misapplications of the technology. What are its benefits? I know nothing about graphics cards. What type of parallelism is going on in the gpu (I have a general idea on why this is but fortification is required), how is it different to your average quad core?  These little things will give me a head start as I try to properly encode the algorithms to this paradigm.Cheers.edit: oh ye. why did you choose the language and what is your opinion of it with respect to other offerings. I know some here have used CUDA for example.[Edited by - Daerax on June 6, 2008 5:45:21 PM]
  My current work consists of developing programs that use GPGPU technologies.Where it really shines is processing large amounts of data. Otherwise the overhead kind of offsets the performance on smaller data sets. What do you have to consider? - Splitting up data sets to sizes that fit on the cards- Buying a card with lots of memory is quite advantageous, with a memory bus that will keep up with it.- Making a library to access the card and read/write from it- What if you add another GPU?- Will you use SLI? - How will they communicate?- What is going to manage your threads?- Do they have to be synchronized?- Most current GPGPU stuff is restricted to 32 bit precision (but this will change shortly!)- Will it be supported on different machines if you decide to release your program?My personal opinion:GPGPU is great for operating on massive data sets, so if you aren't doing that, then cpu code might be better for you.   ;Quote:Original post by DaeraxWhat type of parallelism is going on in the gpu (I have a general idea on why this is but fortification is required), how is it different to your average quad core?It varies quite a bit between different architectures (between ATI and NVIDIA and between different generations of one company's hardware) but the latest ATI and NVIDIA GPUs have many architectural similarities. NVIDIA's GeForce 8/9 series cards with CUDA are probably the most popular choice for GPGPU stuff at the moment. Beyond3D is a good resource for details on the design of graphics hardware and the forums have a lot of posters who are very knowledgeable about 3D hardware. Take a look at this introduction to the G80 (the original GeForce 8 series chip) for an idea how the chip is organised: http://www.beyond3d.com/content/reviews/1/1.   ;  CUDA is great because you're basically writing C code that executes on the GPU.  There are a few minor differences and limitations, especially with regard to memory sharing, but for the most part you should be able to work around those.  The downside is that it's only available on G80+ chipsets (i.e. nVidia GeForce 8800 and above).  But there's an emulator, meaning you can still development in the language and test your code until you actually have hardware that implements it.   ;  A good introduction to CUDA, G80 and parallel programming in general is the lecture course given by David Kirk (NVIDIA's chief scientist): http://courses.ece.uiuc.edu/ece498/al1/Syllabus.html;  If you're doing this for a business and/or for multiple applications, one thing I'd recommend is checking out these guys: http://www.rapidmind.net/. I have no experience with it, but I saw a presentation that was given recently by them and some of the results they had were really impressive.   ;  Another link that should be infinitely helpful: http://www.gpgpu.org/