cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

rahulgarg
Adept II

Will AMD IL be updated?

Anandtech says CAL frozen, no new releases

Will we see a new public release of the CAL SDK after 1.4?

Will there be some extensions to AMD IL to reflect any new hardware features of the new chip?

According to Anandtech, the public portion of the CAL API is being frozen and no updates will come to CAL SDK.

Clarity on this question will be appreciated.

"Compute Abstract Layer (CAL) lives on since it’s what AMD’s OpenCL support is built upon, however it’s not going to see any further public development with the interface frozen at the current 1.4 standard. AMD is discouraging any CAL development in favor of OpenCL, although it’s likely the High Performance Computing (HPC) crowd will continue to use it in conjunction with AMD’s FireStream cards to squeeze every bit of performance out of AMD’s hardware."

http://anandtech.com/video/showdoc.aspx?i=3643&p=8

 

 

 

0 Likes
14 Replies

We will be releasing an IL document that includes the new instructions available on the Evergreen family of products. We do believe the majority o fusers will start migrating their applications to OpenCL for the portability advantage and will be exposing most of the new features at that level.

0 Likes

Originally posted by: michael.chu We will be releasing an IL document that includes the new instructions available on the Evergreen family of products. We do believe the majority o fusers will start migrating their applications to OpenCL for the portability advantage and will be exposing most of the new features at that level.

So does that mean you are going to stop supporting CAL/IL altogether and only expose new features at that level and not at the CAL level? So CAL/IL is essentially going to be obsolete?

 

0 Likes

In nVidia terms CAL is just driver level API. IL is ptx. Shortly, CAL/IL is the lowest API level possible for developer. All others APIs built based on CAL/IL.

Now ATI trying to replace Brook+ built on CAL/IL with OpenCL built (again) on CAL/IL. OpenCL is more mature thing so Brook+ will totally abandoned (actually it's already happens). CAL/IL going to live as long as GPGPU on ATI cards.

As CAL/IL binaries updates with every Catalysts release there barely a point to update CAL SDK itself. Currently only changes are 2 more targets for compile (870 & 830) and it's no problem to add them by yourself. If there'll be released "R800-Family_Instruction_Set_Architecture.pdf" as it was done for R700 it'll be more than enough to program new GPUs even with 1.4beta SDK.

0 Likes

I just hope some breakthrough just like when NV tries to built C++ right into their hardware along with ability to do kernel call inside GPU

That's awesome

0 Likes

There won't by any breakthroughs. We'll be really lucky if OpenCL for ATI GPUs will be released this year. And it'll be totally awesome if it'll be possible to use it in anything except "Hello, world!" applications.

From the other side, there are almost no chances that Fermi will go live this year. And when (if )) it'll go live prices will be rocket high.

It's kinda boring...

0 Likes

You will most definitely see OpenCL running on ATI GPUs easily before the year is out. It's actually going to be coming much sooner than that, so just watch for stuff coming out... And, yes, more than "Hello, world!" applications will run with it. 🙂

Won't comment on Fermi. 🙂 But I won't argue with your comments either... 🙂

0 Likes

@ Michael,

I notice you haven't denied or made a remark re. Brook+ being abandoned.

I really hope this isn't the case!  However, I can't help noticing that commits on the new brook+ sourceforge site are very rare.

Brook+  is agreeably high level, allowing the rapid development and testing of small algorithms for which OpenCL just doesn't seem adapted (spending more time on "useless" code than on actual kernel code is frustrating!). Moreover, I have read that OpenCL will not expose double precision operation capabilities on the gpu. Is this true? If so, all the more reason to maintain brook+ active and bug-free!

Thanks,

Olivier

0 Likes

Hi, I agree with dukeleto. Brook+ is a nice approach to rapid application development and offers quite good performance.

Even if AMD is going to stop developing it, I hope there would be a bug fix release. There are some bugs reported that could be difficult to workaround, for example incorrect gathers or address translation failure.

There are also some minor bugs that I think could be easily fixed like writing code in the first line of a ".br" file, ternary operator bug with doubles or some compiler crashes.

I would appreciate any comments on this from AMD because it could influde on porting many people projects.

Thanks.

0 Likes

Hi dukeleto,

Brook+ was purposefully put onto SourceForge since we believed, as you do, that there is value in that programming environment. However, since the focus of our teams have largely been put towards bringing the best OpenCL development platform to our users, we thought it would be best to put Brook+ in an open source environment where not only AMD but others in the developer community to continue improving it.

And, as far as OpenCL not exposing DPFP on the GPU... that isn't true. We certainly do intend to expose DPFP on the GPU. We are going to be introducing support for it in a staged manner once we reach our first production target for ATI Stream SDK v2.0. The basic arithmetic operations will be introduced first, followed by more and more of the math library.

Michael

0 Likes

No, that isn't what it means. We will continue to support CAL/IL in ATI Stream SDK v2.0. What it does mean is that, since we believe the focus for many developers will be on OpenCL, we will be exposing new features there first and make those as high performance as possible. If there is a feature that cannot perform well and is in high enough demand, we will evaluate it for inclusion into exposed CAL.

But, we definitely recognize the value of the CAL/IL layer and are not planning to obsolete it. There are some very wide-spread programs using this programming API and we intend to make sure those continue to work for our customers.

Michael.

0 Likes

Originally posted by: michael.chu No, that isn't what it means. We will continue to support CAL/IL in ATI Stream SDK v2.0. What it does mean is that, since we believe the focus for many developers will be on OpenCL, we will be exposing new features there first and make those as high performance as possible. If there is a feature that cannot perform well and is in high enough demand, we will evaluate it for inclusion into exposed CAL.

But, we definitely recognize the value of the CAL/IL layer and are not planning to obsolete it. There are some very wide-spread programs using this programming API and we intend to make sure those continue to work for our customers.

Michael.

If OpenCL is built on top of CAL/IL then wouldn't it be pretty simple to expose the new features at the CAL/IL level if they are going to be exposed in OpenCL.... that is, if OpenCL is indeed built on top of CAL/IL?

 

0 Likes

Hi ryta1203,

Yes, OpenCL is indeed built on top of CAL/IL. The necessary features are indeed plumbed through to the CAL/IL layer. However, some of them may be brought through with only the features and interfaces needed by our OpenCL team. Productizing those interfaces, testing them for general use and documenting them for general use is what will be done as there is demand.

Michael.

0 Likes

Please, please by any means, to fix the bug in Brook+

Not all people have the knowledge needed to fix a compiler.

All I know, HPC people need working tools, not fixing the tools itself.

So AMD, we need expert to fix it.

0 Likes

Yes, developing a compiler requires a lot of experience and knowledge. If AMD is not planning to fix the bugs for now it would be nice to get at least Radeon 58xx and Win7 support in both Brook+ and Stream KernelAnalyzer.

0 Likes