GPUs and Array Operations

[janderson]

Craig Black wrote:
> "janderson" <askme at me.com> wrote in message 
> news:f6rkr3$nbm$1 at digitalmars.com...
>> Craig Black wrote:
>>> Lately I've been learning about GPU's, shaders, and general purpose GPU 
>>> computation. I'm still just getting introduced to it and haven't gotten 
>>> very deep yet, so there's probably a few of you out there who know a lot 
>>> more than me about this subject.  It's probably  been discussed before in 
>>> this news group, but I've been thinking about how important GPU's will be 
>>> in the coming years.
>>>
>>> For those who may not know, GPU performance has been improving at a rate 
>>> faster than Moore's Law.  Current high-end GPU's have many times more 
>>> floating point performance than than high-end CPU's.  The latest GPU's 
>>> from NVidia and AMD/ATI brag a massive 500 and 400 single-precision 
>>> gigaflops respectively.  Traditionally GPU's were used for graphics only. 
>>> But recently GPU's have been used for general purpose computation as 
>>> well.  The newer GPU's are including general purpose computation in 
>>> design considerations.
>>>
>>> The problem with GPU programming is that computation is radically 
>>> different from a conventional CPU.  Because of the way the hardware is 
>>> designed, there are more restrictions for GPU programs.  For example, 
>>> there are no function pointers, no virtual methods, and hence no OOP. 
>>> There is no branching. Because of this conditional statements are highly 
>>> inefficient and should be avoided.  Because of these constraints, special 
>>> purpose programming languages are required to program natively on a GPU. 
>>> These special purpose programming languages are called shading languages, 
>>> and include Cg, HLSL and GLSL.
>>>
>>> GPU computation is performed on data streams in parallel, where 
>>> operations on each item in the stream is independent.  GPU's work most 
>>> effectively on large arrays of data.  The proposed "array operations" 
>>> feature in D has been discussed a lot.  It is even mentioned in the 
>>> "future directions" page on the D web site.  However, I don't remember 
>>> the details of the array operations feature.  What are the design goals 
>>> of the this feature?  To leverage multi-cores and SSE?  Are GPU's also a 
>>> consideration?
>>>
>>> There are already C++ libraries available that provide general purpose 
>>> computation using GPU's without shader programming.  When it comes time 
>>> to implement array operations in D, I feel that GPU's should be the 
>>> primary focus.  (However, I'm not saying that multicore CPU's or SSE 
>>> should be ignored.)  Design goals should be performance, simplicity, and 
>>> flexibility.
>>>
>>> Thoughts?
>>>
>>> -Craig
>> While you can do much of the CPU work with the GPU I think in its present 
>> state it requires a very custom program.  For instance, there are 
>> band-width issues which means you don't get the results back till the next 
>> frame.  Therefore your program has to be designed to work in a particular 
>> way.
>>
>> Secondly the GPU is being used for other things, so the time at which you 
>> use these operations is critical, it can't just happen at any stage 
>> otherwise you blow away the current state of the GPU.
>>
>> Thirdly, you can only run a couple of these huge processing operations on 
>> the GPU at once, or come with a smart way to put them all into the same 
>> operation.  Therefore usability of this is limited.
>>
>> Anyway I think it seems more like an API sort of thing so that the user 
>> has control over when the GUI is used.
>>
>> That's my present understanding.  Maybe things will change when AMD 
>> combines the GPU into the CPU.
> 
> You are right, but don't underplay the importance of GPU computation.   GPU's
> are becoming more and more powerful, so they will be able to increasingly 
> handle more and more general purpose computation.  Modern games use GPU's 
> for more than just rendering, and it has become a design goal of many game 
> engines to transfer more of the workload to the GPU.  Some domains, such as 
> scientific simulations, don't care about graphics at all and would rather 
> use the GPU for computation exclusively.

Having written a couple of these in the past I think they still only 
apply to specific problems where you are doing the same calculation 
loads of times like in physics, collision detection of particle effects. 
    Also you often endup doing more calculations on the GPU then u would 
on the CPU but because its still so much faster.  You can't traverse 
complex structures like deep binary trees very easily at least.  The 
code takes a frame to get back and is normally computed in a particular 
part of the frame cycle (unless you have 2 GPUs), therefore its really 
very specific to the problem that is trying to be solved.

Maybe things have changed since I last worked on this stuff. Man the 
amount of times I've had to re-learn Directx.  I'm sure this thread will 
be out of date by the time i press the send button ;)

> 
> At any rate I think we should keep our eyes peeled for opportunities to 
> leverage this capability.  I personally am trying to learn more about it 
> myself.

I agree.

> 
> -Craig
> 
> -Craig 
> 
>