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).

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.

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.

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

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.

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.

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.

Vincent