Vincent Diepeveen (diep@xs4all.nl) on 4/22/11 wrote:
---------------------------
>David Kanter (dkanter@realworldtech.com) on 4/21/11 wrote:
>---------------------------
>>EduardoS (no@spam.com) on 4/20/11 wrote:
>>---------------------------
>>>Heikki Kultala (hkultala@iki.NOSPAM.fi) on 4/20/11 wrote:
>>>---------------------------
>>>>Texture fetches consume the execution slots of the >instruction word, ALU operations
>>cannot be started at same >cycle.
>>>
>>>No they don't, they are even on different clauses, the only >memory-like operation
>>>that consumes ALU slots is the LDS load/store, starting with >Evergreen, on R700 it was executed on TMUs too.
>>
>>My understanding (http://www.realworldtech.com/page.cfm?ArticleID=RWT121410213827&p=7)
>>is that on Cayman and Cypress, the ALUs are used for address calculations. So you
>>cannot simultaneously execute ALU clauses and initiate a texture fetch. However,
>>initiating a texture fetch is fairly quick - most of the time is spent waiting for
>>data. While you are waiting for data, the ALUs are free for independent computations.
>>
>>David
>
>Texture memory is not the adviced method to get things >done as texture memory is
>not so fast (though faster than main memory).

Well there aren't many other options besides the register file and local data store.

>In the first place you need to split up your software in >wavefronts that realistically
>only calculate within the compute units and don't use any >resources outside of it.
>
>Please note your artice is one of the few on the internet >which describes the Cayman architecture a bit.

Thank you for the compliment!

>The interesting thing to know obviously now is when AMD >has managed to fully improve
>the opencl compiler to support this new architecture >pretty well.
>
>Nvidia also seems to struggle supporting OpenCL well. This >where OpenCL really seems like an interesting thing.

I think NV probably has quite good OpenCL support, since they are basically just re-using a lot of their CUDA work.

>As for AMD gpu's, only opencl will get kept supported by >AMD for their GPU's, so there are not really choices there.

AMD also has CPU support.

>Beforehand OpenCL doesn't really seem like the perfect language yet, as a big droop
>for some will be that the current opencl 1.1 specs give 25% of the RAM as the maximum
>object size, which has the implication you can allocate only 25% for that whereas
>there will be several applications that want from this >tiny amount of RAM of course everything.

What OpenCL restriction are you thinking of? I haven't seen anything like that before (but I wasn't looking either).

>Yet it is a big step forward if you think about it how the entire HPC world will
>be supporting OpenCL and how also the other manufacturers will in the end be forced
>to produce hardware that uses the manycore concept, as this is seemingly (to hardware
>laymen like me) the only concept that will give enough >crunching power at a cheap price in the close future.

GPUs don't have that many cores. They are still at around ~10-20, but they use vectorization and VLIW to achieve a higher number of FLOP/core than a traditional CPU.

Honestly, Tilera has more cores than any GPU.

>Of course the compiler quality will be very important then.
>
>There is a lot to win there, for example having logics in >the compiler to recognize
>whether the programmer is trying to use the actual carry, >caused for example by
>an overflow adding 2 (unsigned) integers.

Compiler quality is always a significant factor!

David