cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

quadboon
Journeyman III

Implications of the deprecation of CAL

I was very happy when i read about the deprecation of CAL. I have two reasons:

The first one is very selfish. Since all my GPGPU projects base on OpenCL I hope AMD can now move some developer ressources from CAL development  to OpenCL development and by doing this finally have the manpower fixing all these annoying bugs in OpenCL that havent been fixed for years. Or add some needed features.

The second is that CAL requires kernel code written in IL. IL? What is that? If you are new to GPGPU you might find this is a very strange language. I can talk from my own experience. With OpenCL you dont need to learn a new language. You can simply code in C. I can see why many developer think CUDA is easy. Its because they can write in C. In OpenCL they can do it, too. So that most powerful argument they had was that its easy. Its not more easy than OpenCL now.

This is just my opinion. Good decision AMD!

0 Likes
adm271828
Journeyman III

Implications of the deprecation of CAL

Originally posted by: quadboon

 

The second is that CAL requires kernel code written in IL. IL? What is that? If you are new to GPGPU you might find this is a very strange language. I can talk from my own experience. With OpenCL you dont need to learn a new language. You can simply code in C. I can see why many developer think CUDA is easy. Its because they can write in C. In OpenCL they can do it, too. So that most powerful argument they had was that its easy. Its not more easy than OpenCL now.

 

This is just my opinion. Good decision AMD!

 

Programming GPGPU is not a language issue, it is about understanding how the hardware works, and about developping new algorithms, new data representations, ... in one word: new way of thinking that will allow you use the hardware at its best. The effort to learn a new language is nothing compared to this. When Jawed says he spent many hours to optimize his BLAS implementation, I think it was certainly not a language issue.

AMD's decision to drop CAL/IL is not a bad decision. The bad decision is to do it without being able to provide a working replacement solution to access the hardware at low level (I will start to repeat my-self...). 

I'm still waiting for AMD to provide us their vision about this, but I'm not that much confident, because I think they are in a rush.

Best regards,

Antoine

0 Likes
ryta1203
Journeyman III

Implications of the deprecation of CAL

@Lee: When I said "little reason not to use CUDA" I didn't mean it was at a different level but that it totally outperforms AMD's OpenCL. Their compiler is just so much more mature and the simplicity of the hardware (non-VLIW) makes for easier optimizations and better overall usage. CUDA also outperforms AMD in just about every irregular application or memory bound application that I can think of.

@Jawed: I disagree about the MM for CUDA. Volkov's SC 08 paper shows good percentages very early on, particularly when you think of the timeframe of SC and the months and months of submitting, reviewing, finalizing to actual being published.

0 Likes
Meteorhead
Challenger

Implications of the deprecation of CAL

Ryta, it is not true that NV outperforms ATi in every application. OpenCL is a port to CUDA in the NV compiler (the same way as it is a port to CAL on AMD HW) and there is a certain application that employs HEAPS of random number generations and bitshifts and bitwise operations. Basically the only floating point operation is the random number comparison to a preset value. On NV cards, FP and INT unit is seperate HW and one sits idle almost the entire time. 1 Cypress outperforms a C2070 by 1.44X, and 1 Hemlock by 2.31X. Memory movement is minimal.

VLIW architecture is very powerful and is the strength of AMD. That should not be modified.

0 Likes
himanshu_gautam
Grandmaster

Implications of the deprecation of CAL

Originally posted by: Jawed Image buffers give you access to essentially all the memory, though a single buffer can't be as large as the card's memory. I've never used those environment variables.

 

The memory allocation size restriction problems people have are with normal buffers as opposed to image buffers.

 

Micah, some examples of errors in Revision 1.0 (February 2011) of HD 6900 Series Instruction Set Architecture:

 

  1. Section 2.3 erroneously includes "local data share" as a type of clause, a feature that is restricted to R7xx GPUs
  2. Table 2.7 says that an ALU clause contains 5 ALU_WORDs
  3. Section 4.3, second sentence, repeats the error relatig to 5 ALU instructions
  4. Section 4.4 doesn't present the algorithm it says it is presenting.


 

Thanks for reporting this.

0 Likes
sgratton
Adept I

Implications of the deprecation of CAL

 

Hi there,

 

Himanshu, you might also want to remove the trans unit from fig. 4.3!

 

Jawed, I remember now why I couldn't use images: I wanted to do an in-place algorithm (Cholesky factorization) and writes and reads to the same image in the same kernel are not allowed. 

 

In any case, I am a bit puzzled as to why images aren't also bound by the CL_MAX_MEM_ALLOC_SIZE restraint.  That seems to set the max size of a memory object allocation, and an image is a type of memory object...

 

By the way, is there an environment variable one can set to adjust this, like with GPU_MAX_HEAP_SIZE, even if it is experimental?

 

Thanks,

Steven.

 

0 Likes
ryta1203
Journeyman III

Implications of the deprecation of CAL

Originally posted by: Meteorhead Ryta, it is not true that NV outperforms ATi in every application. OpenCL is a port to CUDA in the NV compiler (the same way as it is a port to CAL on AMD HW) and there is a certain application that employs HEAPS of random number generations and bitshifts and bitwise operations. Basically the only floating point operation is the random number comparison to a preset value. On NV cards, FP and INT unit is seperate HW and one sits idle almost the entire time. 1 Cypress outperforms a C2070 by 1.44X, and 1 Hemlock by 2.31X. Memory movement is minimal.

VLIW architecture is very powerful and is the strength of AMD. That should not be modified.

I think you need to reread my post.

0 Likes
ryta1203
Journeyman III

Implications of the deprecation of CAL

So Nvidia is letting developers embed PTX code? Is this correct? Does AMD have any plans for this type of implementation in the future?

0 Likes
MicahVillmow
Staff
Staff

Implications of the deprecation of CAL

Ryta,
Do you have a reference? Would be interested in seeing if they do allow this. Also, AMD is only deprecating CAL support, not IL support. OpenCL compiler targets IL, so this will still be used and updated.
0 Likes
Meteorhead
Challenger

Implications of the deprecation of CAL

Let me ask something very naive: if CAL translates to IL, just like OCL, and CAL has GWS, I take it that there's a single IL instruction that stands for GWS. If this is true, how come there'is no GWS in OpenCL?

Inserting IL code into OCL is basically all the same thing that porting CAL to OCL.

Since this is not done yet I take it that it takes a lot more on IL level to achieve GWS.

0 Likes