AMD Releases OpenCL ATI GPU Support For Linux [Archive]

View Full Version : AMD Releases OpenCL ATI GPU Support For Linux

phoronix

10-13-2009, 02:40 PM

Phoronix: AMD Releases OpenCL ATI GPU Support For Linux

AMD has released the fourth beta of the ATI Stream SDK 2.0, which provides a complete OpenCL development platform with OpenCL ATI GPU support for the ATI Radeon HD 4000/5000 series. Besides running OpenCL on the GPU, this ATI SDK also supports running OpenCL on SSE3-capable, multi-core CPUs from both AMD and Intel too...

http://www.phoronix.com/vr.php?view=NzYwOA

xeros

10-13-2009, 03:31 PM

Great news!
I can't wait to see benchmarks...

Tares

10-13-2009, 03:49 PM

Awesome. Go ATI ;-) Now we just need a video acceleration :>

Louise

10-13-2009, 03:55 PM

Looking at
http://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx

Integrated GPU's are not supported. Is that because they are not meant for heavy work load, and would therefore over heat?

Or does these lack some hardware features, so not even the open source version of OpenCL would support integrated GPU's?

Of course OpenCL makes the most sense of high end cards =)

RealNC

10-13-2009, 03:57 PM

Reading the released specs of NVidia's G300, there is "native support for execution of C++ on GPU." That means running "real C++ applications" on the GPU. Does ATI allow that too now with OpenCL or is this something entirely different?

bridgman

10-13-2009, 04:02 PM

Integrated GPU's are not supported. Is that because they are not meant for heavy work load, and would therefore over heat? Or does these lack some hardware features, so not even the open source version of OpenCL would support integrated GPU's?

The OpenCL code only supports HD4xxx and higher GPUs. The IGP parts all use cores from earlier generations.

I believe the issue is the on-chip LDS/GDS memory blocks which allow data sharing between GPU threads. Those blocks first appeared in the HD4xxx family.

Louise

10-13-2009, 04:19 PM

The OpenCL code only supports HD4xxx and higher GPUs. The IGP parts all use cores from earlier generations.

I believe the issue is the on-chip LDS/GDS memory blocks which allow data sharing between GPU threads. Those blocks first appeared in the HD4xxx family.

Interesting stuff.

Thanks :)

sandain

10-13-2009, 04:22 PM

bridgman

10-13-2009, 04:28 PM

Quick answer is "I don't know", but there will definitely be Gallium3D drivers for those parts and AFAIK the OpenCL work being done by TG/VMWare is still happening (although Zack seems to be having a brief but intense fling with the xorg state tracker at the moment), so there should be support one way or another.

What I don't know is how much those hardware features will affect the useability of OpenCL on earlier parts.

chithanh

10-13-2009, 06:24 PM

What about the Radeon HD 4200 IGP? Is that new enough?

bridgman

10-13-2009, 06:29 PM

I don't think so. IIRC the HD4200 picks up display and UVD improvements from the HD4xxx family but the 3D engine is from the HD3xxx generation.

BlackStar

10-13-2009, 06:52 PM

Reading the released specs of NVidia's G300, there is "native support for execution of C++ on GPU." That means running "real C++ applications" on the GPU.

lol (http://www.youtube.com/watch?v=bJJyG67by0U)

Does ATI allow that too now with OpenCL or is this something entirely different?

Yes, it's something different entirely. Something called vapourware.

RealNC

10-13-2009, 07:23 PM

I can't make sense of that video. NVidia announced C++ support. You claim this won't happen? Sounds a bit strange to me, so I suppose this video is by people who spread too much FUD or something.

illissius

10-13-2009, 07:29 PM

It will happen, but it might happen a little or a lot late. Basically, yes, nvidia designed the cards, and yes, they will run C++; what they're alleging is that they're having a ton of trouble trying to actually produce them, and are trying to cover that up and failing at it.

Louise

10-13-2009, 08:24 PM

lol (http://www.youtube.com/watch?v=bJJyG67by0U)

Yes, it's something different entirely. Something called vapourware.

Nvidia fakes Fermi boards at GPU Technology Conference
http://www.semiaccurate.com/2009/10/01/nvidia-fakes-fermi-boards-gtc/

I looked at the presentation from NV's website, and I really question the "proof" that Fermi exists. It looks very much like a pre rendered animation they are playing, where they have dropped some of the frames in "the slow one".

Update 3 in the article backs up the theory, that those just were pre rendered and mock ups as well :)

smitty3268

10-13-2009, 09:04 PM

Back to the original question, the C++ support NVidia is claiming is like a C++ version of CUDA. It really doesn't have anything to do with OpenCL support.

And given that they had to make hardware changes in their upcoming hardware to do it, and the fact that AMD hasn't announced something similar in response, plus the fact that NVidia seems to be focusing more on those types of features than AMD is makes me assume that it's not in the R800 cards.

To be honest, I'm not entirely sure that's a very big deal. It seems to me like the vast majority of code you'd want to run on a GPU would be easily written in C anyway, although I'm sure that eventually it will become a wanted feature. AMD will probably add support for it about that time, maybe in a generation or 2.

ernstp

10-14-2009, 03:10 AM

Does this depend on the FGLRX driver and a specific version of that in that case?

Qaridarium

10-14-2009, 04:20 AM

Qaridarium

10-14-2009, 04:23 AM

So does that mean that there will be no forthcoming support for the HD2xxx and HD3xxx families? If so, that makes me want to cry...

the only REAL HD2xxx cart is the 2900 but yes no support for the HD3870 is realy---->want to cry

i have a 3850... i realy realy should sell this cart on ebay very fast..

rohcQaH

10-14-2009, 04:48 AM

why? Do you suddenly need openCL to live? I'd expect another year to pass before openCL is used by widespread software. If your card can do what you need right now, keep it.

BlackStar

10-14-2009, 05:37 AM

I can't make sense of that video. NVidia announced C++ support. You claim this won't happen? Sounds a bit strange to me, so I suppose this video is by people who spread too much FUD or something.

As the previous posters said, the issue is that Nvidia is having troubles producing the actual cards. This video showed the (failed) damage control they are trying to do: the features sound great on paper, but they are useless without the actual hardware to run them - and the hardware is nowhere to be found (edit: the card and the videos they showed are obviously fake).

Every indication is that they won't release sooner than Q1 or Q2 of 2010.

Personally, I don't doubt that we'll see some form of C++ running on those GPUs. However, I believe this will be *far* from what C++ will look like on the CPU - I doubt we'll see stuff like multiple inheritance (or even single virtual inheritance), partial template specialization or any of the other features that make C++ more than C-with-classes. Don't expect to take your favorite C++ application (e.g. Firefox) and compile it for the GPU anytime soon (before Larbee at least). ;)

Note that DX11 already supports C-with-classes, so Nvidia won't be bringing anything new to the table...

highlandsun

10-14-2009, 06:24 AM

Eh, screw C++. I don't need a fully general purpose GPU, I just want apps that make sense to accelerate, to be accelerated. Like video decoding...

Qaridarium

10-14-2009, 08:33 AM

why? Do you suddenly need openCL to live? I'd expect another year to pass before openCL is used by widespread software. If your card can do what you need right now, keep it.

i hope abaut the opensource driver... i think the opensource driver will support openCL on an hd 38xx

alazyworkaholic

10-14-2009, 09:43 AM

LavosPhoenix

10-14-2009, 10:11 AM

So ATI purposely screws over it's previous generation yet again. First by not providing stable drivers, now by providing OpenCL support only to the newest cards. ATI's OpenCL implementation should have provided support for all graphics cards that they support in their drivers. Oh well, yet another reason why AMD doesn't deserve any more of my support or money.

bridgman

10-14-2009, 10:14 AM

"ATI releases OpenCL ATI GPU support for Linux"

So what? What does this mean? What's OpenCL good for? What applications might start to take advantage of this? Why should I care? That's what I'd really like to read in the article.

If you follow the "AMD Developer Central" link Michael provided, and scroll down to "Related Resources", you will see a number of links providing overview information for OpenCL.

So ATI purposely screws over it's previous generation yet again. First by not providing stable drivers, now by providing OpenCL support only to the newest cards. ATI's OpenCL implementation should have provided support for all graphics cards that they support in their drivers. Oh well, yet another reason why AMD doesn't deserve any more of my support or money.

I believe the issue here is that OpenCL (an industry standard developed in 2008 to provide an open standard for computing in 2010 and beyond) requires hardware capabilities which were not included in our 2006 and 2007 GPUs in order to be fully compliant. It's probably possible to do some kind of subset implementation, and I'm sure the open source drivers will implement one anyways, but right now I don't know how useful an implementation without the local and global data share memories would be.

I guess I'd better apologize for DX11 right now before things get any worse :D

BlackStar

10-14-2009, 10:38 AM

energyman

10-14-2009, 11:11 AM

Ex-Cyber

10-14-2009, 12:56 PM

I really don't buy into 'c++ in hardware'. Are you guys sure you don't misinterpret something? Something like 'the cuda compiler can eat c++ and turn it into the instruction stream needed by the card'?Well, that would legitimately be "C++ on GPU", but the notion of that somehow being tied to "real applications" running on the GPU makes no sense to me. No matter what language a GPU-targeted compiler supports, a GPU is not going to have the general-purpose libraries, OS facilities, or I/O capabilities demanded by "real applications". To the extent that applications use any kind of C++-on-GPU capability, I don't see how it would be any more or less "real" than using OpenCL, Cg, or whatever.

smitty3268

10-14-2009, 01:38 PM

I really don't buy into 'c++ in hardware'. Are you guys sure you don't misinterpret something? Something like 'the cuda compiler can eat c++ and turn it into the instruction stream needed by the card'?

What NVidia is saying is that certain C++ features weren't possible in previous generations because the hardware lacked the necessary support. See this anandtech article for some more info: http://www.anandtech.com/video/showdoc.aspx?i=3651&p=6

In previous architectures there was a different load instruction depending on the type of memory: local (per thread), shared (per group of threads) or global (per kernel). This created issues with pointers and generally made a mess that programmers had to clean up.

Fermi unifies the address space so that there's only one instruction and the address of the memory is what determines where it's stored. The lowest bits are for local memory, the next set is for shared and then the remainder of the address space is global.

The unified address space is apparently necessary to enable C++ support for NVIDIA GPUs, which Fermi is designed to do.

Fermi implements a wide set of changes to its ISA, primarily designed at enabling C++ support. Virtual functions, new/delete, try/catch are all parts of C++ and enabled on Fermi.

mattmatteh

10-14-2009, 01:53 PM

energyman

10-14-2009, 01:58 PM

What NVidia is saying is that certain C++ features weren't possible in previous generations because the hardware lacked the necessary support. See this anandtech article for some more info: http://www.anandtech.com/video/showdoc.aspx?i=3651&p=6

yes, I read that. Sounds like 'you will be able to use c++ to program for the gpu' and not 'you can write c++ code and the card will eat it directly'.

smitty3268

10-14-2009, 02:21 PM

Yep. That's probably for the best anyway - it's a really bad idea to just run normal c++ application code on a GPU, because it's almost certainly going to be mostly single-threaded and run much faster on a normal CPU. Where I see this being useful is for things like C++ matrix libraries, etc., and I imagine even then you'll have to write code specifically for the hardware in order to get any kind of decent performance, just like you do with CUDA now.

smitty3268

10-14-2009, 02:25 PM

This is great that AMD/ATI is supporting linux, but i assume this is proprietary. Is there an open source alternative, eiher as an independent package or with xorg-ati? Is there any aditional documentation needed for this ?

I wonder how impossible it would be for this to work on older cards, and if an open source driver could take advantage of this.

matt

There's an open source gallium state tracker currently under development, but it's going to be awhile before the r600g driver is working. They haven't even started it yet (12 months?).

I don't think it will work for anything earlier than r600 because of hardware limitations - at that point you'd just be running it through the software pipe on the CPU.

bridgman

10-14-2009, 03:03 PM

Chad Page

10-14-2009, 03:19 PM

Gallium's OpenCL tracker is pre-alpha, IIRC. Free OpenCL will happen, just not yet. AFAIK there's no complete free OpenCL platform for any OS, so I'm not going to split any hairs.

nVidia and AMD's OpenCL Linux development is (probably) shared with Windows driver development, so now that fglrx is sync'd with the Windows codebase it's a cheap ride. Of course there's packaging, testing, etc, which is actually a lot of work - but the core code is shared.

Pre-4xxx cards can do interesting GPGPU work, but OpenCL demands more than what older cards can do. OpenCL won't run fully on a GeForce <8k either!

As for me, I'm planning to put my 4830 back in my quad-core and start playing with it this weekend. :) If I really get into it I'll probably snag a 58xx whenever it's a good enough value for me to upgrade.

mtippett

10-14-2009, 04:44 PM

This is great that AMD/ATI is supporting linux, but i assume this is proprietary. Is there an open source alternative, eiher as an independent package or with xorg-ati? Is there any aditional documentation needed for this ?

I wonder how impossible it would be for this to work on older cards, and if an open source driver could take advantage of this.

matt

Remember that OpenCL is fundamentally HW agnostic. Multi-core CPU and multi-core GPUs are both targets (albiet for differing workloads).

The AMD OpenCL driver that was released supports both CPU (AMD and Intel) and GPU (ATI).

As others have suggested, OpenCL expects a certain level of capability that is very difficult to provide using older GPU hardware. If the hardware capability isn't there then you would simulate the missing functionality on the CPU. If a punt to software occurs, you may as well be using the CPU OpenCL implementation anyway.

Regards,

Matthew

smitty3268

10-15-2009, 01:44 AM

If we thought the r600g driver was going to take a year to write we would have started it a long time ago :D

Once we have a solid r300g base I don't think it should take too long to port the 6xx/7xx code across from the classic Mesa driver.

Well that's very good news to hear. I know people complain when they think you guys are missing deadlines that they've heard, but a little bit more info on when these upcoming things are going to be ready would be nice even if it's very vague, like sometime next summer.

I was just guessing based on what I've heard that the 300g driver wouldn't be ready until mesa 7.8 which i figured would be 6 months, and then tacked on another 6 to do the 600g driver.

agd5f

10-15-2009, 01:52 AM

Only r7xx (and rv670) GPUs support double precision ops.

bridgman

10-15-2009, 10:33 AM

Well that's very good news to hear. I know people complain when they think you guys are missing deadlines that they've heard, but a little bit more info on when these upcoming things are going to be ready would be nice even if it's very vague, like sometime next summer.

Well, there's the first mistake (not yours) :D

There are no deadlines. We make rough estimates for how long a small group of developers, all working on multiple projects, will take to do something they've never done before. We try to update the estimates as new information comes in, but if anyone thinks of that as a deadline the discussion is out of control already.

If we were talking about the third or fourth Gallium3D driver to go into everyday use we could talk about hard plans and maybe even deadlines, but the primary schedule risk for 300g is the fact that (right now) there's a good chance it will be the first. That implies more of a learning curve and even more schedule uncertainty.

I was just guessing based on what I've heard that the 300g driver wouldn't be ready until mesa 7.8 which i figured would be 6 months, and then tacked on another 6 to do the 600g driver.

Ahh, I see your reasoning. It makes sense, but the thinking is 300g in 7.8 because 7.7 is too close for anyone to have confidence so 7.8 is the next option. However, the devs don't need to wait until 7.8 before starting work on 600g, just until 300g has progressed far enough that the remaining work looks like bug fixing rather than architectural or API changes. My guess is that 300g and 600g will finish quite close together in time, and hopefully by doing all the heavy lifting in 300g rather than "learning everything twice" the overall time will be minimized. That's the hope anyways ;)

smitty3268

10-15-2009, 09:06 PM

Well, there's the first mistake (not yours) :D

There are no deadlines. We make rough estimates for how long a small group of developers, all working on multiple projects, will take to do something they've never done before. We try to update the estimates as new information comes in, but if anyone thinks of that as a deadline the discussion is out of control already.

A poor choice of words on my part there. What I was referring to was when Michael writes a post about how some feature is going to be done next week, or later this month, and then nothing visible to users happens on that front for another 6 months. People get frustrated because they were expecting something to be done even if it actually wasn't anywhere close, so I know the usual tendency is to try to be as vague as possible about when things are going to be done.

I know it's tough to give good estimates the first time you do something, especially when it involves a whole framework as large as Gallium that may not be working 100% since you are one of the first to try to get it all working.

BlackStar

10-16-2009, 02:19 AM

I know it's tough to give good estimates the first time you do something, especially when it involves a whole framework as large as Gallium that may not be working 100% since you are one of the first to try to get it all working.

When you hear an estimate on software, a good bet is to double it and then increase it by an order of magnitude. In other words, when you hear "it will be ready by tomorrow", you should translate that to "it should be ready in two weeks from now".

As an added bonus, sometimes you'll be pleasantly surprised ("hey cool, it only took one week after all!")

bridgman

10-16-2009, 12:06 PM

Ah yes, the good old "times two and add thirty" rule :D

When I joined ATI I made myself unpopular in a variety of ways. One of them was asking "what level of confidence do you want ?" when someone asked me for a schedule. If you look at the typical distribution of completion times for a given project, as you increase time the probability of completing at that time goes up quickly to a "most likely" value then trails off slowly with a long tail, ie where the time to complete may be 5x, 10x or higher than the most likely time.

http://pages.interlog.com/~johnb/ht/project.png

If you measure the area under the curve you can calculate the probability of the project finishing on or before a certain time. The 50% point (half the time early, half the time late) is normally close to, but not the same as the most likely time to complete.

Each project has :

- a lower bound (essentially no chance of finishing before this time)
- a "most likely" schedule
- a 50% confidence or "50/50" schedule, ie half the time you'll finish before, half the time you'll finish after
- various "high confidence" points, typically 80% and 90% confidence are used
- maximum time is usually unbounded... projects are sometimes just doomed and can suck up resources forever

The exact shape of the curve, and therefore the relationship between the different points, is a complex function of risks, task sensitivity to those risks, and task interdependence. I'm not including even scarier things like changes to requirements or priorities during the project.

This is where it gets complicated, of course. The "high confidence" schedules are quite far down the tail of the curve, and are much longer than the most likely or 50/50 times.

One of the great joys of project management is that when you are managing a portfolio of projects with shared resources you need to use the 50/50 point for each task so that over time your resource usage matches the estimate, but you don't want to make commitments based on the 50/50 point because that means you'll be late half the time. You end up having to keep two schedules - one that you use for internal management and one that you use to make commitments, and the two numbers are usually pretty far apart. Eliyahu Goldratt's Critical Chain describes how to integrate the two schedules in a manageable way.

Where am I going with all this ?

1. When an individual developer talks about how long an individual task might take, they are usually either talking about the minimum (ie "it will take at least this long") or the "most likely" time. This is what you would normally call a SWAG.

2. When we talk about project schedules (a project being a collection of tasks) within a larger rearchitecture initiative we are normally talking about the 50/50 point, which is optimum for allocating resources and figuring out how much work should be bitten off at a time. This is what you would normally call "a plan".

3. When something "really needs to be done by a certain time" you need to plan with 80% or 90% confidence, which either means significantly longer schedules or significantly fewer features. This is what you would normally call "a deadline".

So... one more time... how long is Gallium3D gonna take ?

Ant P.

10-16-2009, 01:01 PM

My guess is it'll be announced as "coming next week" by Phoronix perpetually, then eventually get a stable release in April-May.

tball

11-14-2009, 07:41 AM

Well have anyone got the opencl baby to run?

I just downloaded the beta driver from ati's stream site and the stream sdk.

I got this system:
ubuntu 9.10
radeon 4650

The driver runs, but I got a "Testing use only, Unsupported hardware", bottom right off my screen. 2d, 3d and so works fine, but when I try run a demo sample from the SDK, I get a segmentation fault.

(gdb) run
Starting program: ~/ati-stream-sdk-v2.0-beta4-lnx64/samples/opencl/bin/x86_64/HelloCL
[Thread debugging using libthread_db enabled]
HelloCL!
Creating a context
For test only: Expires on Sun Feb 28 00:00:00 2010

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4b946ea in ?? () from /usr/lib/libaticaldd.so

Anyone got any ideas?

bridgman

11-14-2009, 10:10 AM

Probably best to post on the Stream forum at developer.amd.com; that's where the Stream folks hang out. Don't think there has been much testing on Ubuntu 9.10 but that wouldn't explain the Unsupported Hardware icon; first thought is some kind of installation issue with the driver.

Kano

11-14-2009, 12:38 PM

There are 2 watermarks possible, one is unsupported hardware, that means you have to replace the /etc/control file and the other is a check for /etc/signature which is missing on beta drivers. You can take both files from any other driver.

bridgman

11-14-2009, 01:08 PM

Good point, I forgot that beta drivers displayed the watermark. Thanks.

tball

11-14-2009, 11:04 PM

But That wont solve my segmentation fault I guess. I don't care about the watermark actually. I just want the opencl driver to work. :)

bridgman

11-14-2009, 11:50 PM

tball

11-15-2009, 07:27 AM

Yeah, the watermark was a red herring. I don't suppose you have a free partition to try it with Ubuntu 9.04, do you ?

The SDK is a beta, tested on 9.04, and I would be surprised if it were trouble free on 9.10.

I will se if I have time installing it on an external harddisk. But yes, it might be better running it on a supported OS :-)

I created a thread on amd's developer forum. I can see other have the same problem, so I believe it will get fixed.

bridgman

11-15-2009, 11:03 AM

Sounds good. There's nothing like running it on a supported configuration and still having a problem to get the developers attention :D

tball

11-15-2009, 12:59 PM

I still get the device unsupported, but opencl works. :-)

Though for some of the samples I get:
Error: Device does not support sub 32bit writes!

Well maybe my card just doesn't support 23bit writes.