AMD Releases OpenCL SDK For Linux Too

[phoronix]

Phoronix: AMD Releases OpenCL SDK For Linux Too

As part of their Stream 2.0 Beta, AMD announced yesterday their OpenCL (Open Computing Language) Software Development Kit designed for multi-core x86 CPUs. They have submitted this SDK to the Khronos Group for certification, but it is available now...

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

[Vighy]

Hey, Michael you should also note that (differently from before), starting with Stream SDK 1.4, AMD operated a fetch restriction on downloads. You now need to be registered. Before I used to create ebuilds for gentoo ( http://bugs.gentoo.org/show_bug.cgi?id=257626 ) to take advantage of this sdk.

Now an automated procedure is no more as easy as before.

I also look with suspect at an operation of closure on downloads to only registered people..

[Drago]

Why they are so pedantic. I have having one zillion registrations all around, and not remembering them. Stupid move :mad:

[bulletxt]

Don't worry... in 10 years we will have to register even to buy a box of milk in a mini market :) And when you buy the product it gets associated to your account... so they always know what you buy and who bought it :p

[Louise]

Could the SDK end up being Open Source as well?

[Drago]

Could the SDK end up being Open Source as well?

I don't think so for Steam, but OpenCL is. Gallium3D also is open source.

[Craig73]

Don't worry... in 10 years we will have to register even to buy a box of milk in a mini market :) And when you buy the product it gets associated to your account... so they always know what you buy and who bought it :p

People willing do this today... it's call air miles (or any other rewards program)

[deanjo]

When it comes to AMD's Linux support, they are currently supporting this new SDK under OpenSuSE 11.0 and Ubuntu 8.04 LTS. WTH? Why on earth are they supporting openSUSE 11.0 instead of 11.1? The kernel on that distro doesn't properly support their flagship CPU's (power management , stepping and chipset features for example). Not to mention that it's replacement, 11.1 has already been out for about 8 months. There is also the fact that SLE 11 should be supported as well.

[bridgman]

I'll ask. Might be a typo, but most likely answer is that the devs picked distro releases which would be stable throughout the development cycle and still be supported when the SDK hit the beta milestone. The release notes basically say "this is what we used when testing the beta SDK", so treat it as "history" not "policy".

[deanjo]

I'll ask. Might be a typo, but most likely answer is that the devs picked distro releases which would be stable throughout the development cycle and still be supported when the SDK hit the beta milestone. The release notes basically say "this is what we used when testing the beta SDK", so treat it as "history" not "policy".

Still, 11.0 is nearing EOL (10 months to go). While I appreciate that they are using openSUSE as a test platform, 11.1 support would be excluded from testing as well as SLE. I can see using Ubuntu LTS as it has some supported life left on it, but not testing it against 11.1 or SLE is IMHO a bad move. I also find it odd that Intel compilers are supported but not AMD tuned compilers such as Pathscale or PGI which are aimed at big core count setups.

[bridgman]

Remember that this is a beta, not a final release. I expect that everyone will have moved from beta to release code long before 10 months is up.

[deanjo]

Remember that this is a beta, not a final release. I expect that everyone will have moved from beta to release code long before 10 months is up.

I understand that but I would wager most people who are beta testing are doing so on their latest release of their distro. It's rather unusual to see a beta tester not running at least the current release.

[mirv]

"Supported on" and "runs on" are two different things. Especially for a beta product. In all likelyhood, it'll run on just about everything.

[AdrenalineJunky]

"Supported on" and "runs on" are two different things. Especially for a beta product. In all likelyhood, it'll run on just about everything.

exactly...

[deanjo]

exactly...

Exactly what? When I see instructions recommending downgrading to a old ass version it makes me wonder. Really to try out a beta product against a old and little used version does very little to addressing issues that may creep up in the newer official distro. If a bug is submitted against a newer in use mainstream distro then the developers can say "well it's not supported" and that gets nobody nowhere.

The SDK may work on configurations that fall outside the list below. However, if your operating system, compiler or processor is not listed below, we recommend that you modify your configuration to a supported configuration for the best possible ATI Stream programming experience.

[mirv]

I think you're just looking for things to complain about now.
For beta programs, you need some kind of baseline to test it against. Guess what - if openSuse 11 is older than 11.1, it's likely to be stable (i.e they know the ins & outs of it). If it doesn't work on 11.1 then they've got a good start of where to look.

[deanjo]

I think you're just looking for things to complain about now.
For beta programs, you need some kind of baseline to test it against. Guess what - if openSuse 11 is older than 11.1, it's likely to be stable (i.e they know the ins & outs of it). If it doesn't work on 11.1 then they've got a good start of where to look.

Guess what when a official release is put out of a distro it is STABLE. Also distro's often mark a bug "To be fixed in next release" and those older releases never get the fix backported unless it's a security issue.

[AdrenalineJunky]

Exactly what? When I see instructions recommending downgrading to a old ass version it makes me wonder. Really to try out a beta product against a old and little used version does very little to addressing issues that may creep up in the newer official distro. If a bug is submitted against a newer in use mainstream distro then the developers can say "well it's not supported" and that gets nobody nowhere.

there are tons of programs everyone uses that are only "supported" on certian distro's, doesn't mean it won't work, if you have a problem with it, THEN complain, or rather, file a report. no reason to jump the gun.

Guess what when a official release is put out of a distro it is STABLE. Also distro's often mark a bug "To be fixed in next release" and those older releases never get the fix backported unless it's a security issue.

its relatively stable - big difference between relatively stable and very stable.

perfect example - kubuntu 8,10 was not what i would call stable.

now i've never used suse 11.0 or 11.1 for more then a half hour or so, so i'm not entirely sure where they rank, but thats besides the point anyway, like i said earlier, if you try it, and it doesn't work, that sucks, if its "unsupported" but works just fine, then be happy.

[deanjo]

there are tons of programs everyone uses that are only "supported" on certian distro's, doesn't mean it won't work, if you have a problem with it, THEN complain, or rather, file a report. no reason to jump the gun.

To get the largest and most worthy feedback one has to test against what the largest share in a particular distro. With openSUSE that would be 11.1, 11.0 users make up for <10 % of current opensuse users.



its relatively stable - big difference between relatively stable and very stable.

perfect example - kubuntu 8,10 was not what i would call stable.

now i've never used suse 11.0 or 11.1 for more then a half hour or so, so i'm not entirely sure where they rank, but thats besides the point anyway, like i said earlier, if you try it, and it doesn't work, that sucks, if its "unsupported" but works just fine, then be happy.

The only fixes placed in openSUSE are critical and security updates. For a update to be put out as a critical it must meet this criteria.

A vulnerability that could be easily exploited by a remote attacker to execute arbitrary code without prior authentication. In other words a vulnerability that could be leveraged by an Internet worm to spread without user interaction.
NonSecurity : A software issue which might cause data loss or data corruption.
Occasionally they will issue a patch marked as important, this is classified as


A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of users data, or of the integrity or availability of processing resources.
An update to fix annoyance bugs are very rare and more often then not people are referred to running the unsupported upgrades to fix those issues. It is even more rare to see those fixes backported to older versions of the distro.

[mirv]

To get the largest and most worthy feedback one has to test against what the largest share in a particular distro. With openSUSE that would be 11.1, 11.0 users make up for <10 % of current opensuse users.


Maybe they're using 11.0 in-house. It's beta, not production. The most worthy feedback they can have is if it works on their systems, but not on others - then they can look at the differences, what makes it break, and most importantly: why. Or have you never debugged a large project before?

[deanjo]

Or have you never debugged a large project before?

Very large projects. I do it for a living. We constantly qualify our products against not only against current releases of OS's AND OS's that are set to be released in the future once developer previews are released. That's the whole idea of developer releases of OS's.

[Veerappan]

Looks like a good development to me. Between Gallium3D and this OpenCL SDK, it should hopefully allow developers to write/test their OpenCL code against multiple compilers/libraries, which sounds great to me.

Not only that, but it means that anyone who doesn't have a strong graphics card in their machine can still run OpenCL programs, albeit at a slower pace.

And really, if they started development 8+ months ago, OpenSUSE 11.0 possibly was the latest release. They started developing on that version on some of their machines, and instead of upgrading their distro halfway through the development cycle, they finished on that release. Would you really want to introduce a completely unknown set of possible issues into your troubleshooting process halfway through a development cycle after you had already pinpointed a good number of the 11.0 release's issues? I don't know about you, but I'd finish development using my development system's current setup, and then worry about working the kinks out on newer versions.

As has been said before, this is a beta release. They know it works on OpenSUSE 11.0, and Ubuntu 8.04. They'll eventually officially support newer versions, after they've tested the SDK on them more extensively. They've probably ran the SDK on newer versions, but just haven't really put it through its paces on newer releases yet.

[deanjo]

Looks like a good development to me. Between Gallium3D and this OpenCL SDK, it should hopefully allow developers to write/test their OpenCL code against multiple compilers/libraries, which sounds great to me.

Not only that, but it means that anyone who doesn't have a strong graphics card in their machine can still run OpenCL programs, albeit at a slower pace.

And really, if they started development 8+ months ago, OpenSUSE 11.0 possibly was the latest release. They started developing on that version on some of their machines, and instead of upgrading their distro halfway through the development cycle, they finished on that release. Would you really want to introduce a completely unknown set of possible issues into your troubleshooting process halfway through a development cycle after you had already pinpointed a good number of the 11.0 release's issues? I don't know about you, but I'd finish development using my development system's current setup, and then worry about working the kinks out on newer versions.

As has been said before, this is a beta release. They know it works on OpenSUSE 11.0, and Ubuntu 8.04. They'll eventually officially support newer versions, after they've tested the SDK on them more extensively. They've probably ran the SDK on newer versions, but just haven't really put it through its paces on newer releases yet.


I'm sure they did start development 8 or months ago, I'm not disputing that fact. Now let's look at the same type of project for Nvidia. Cuda 2.2 was in development months before openSUSE 11.1's release. Upon first released beta it was already qualified against openSUSE 10.1 - 11.1, SLED 10 - 11, RHEL 3 - 5, Fedora 7 - 10, Ubuntu 7.04 - 9.04. The latest official release even supports Win 7. The same goes for their openCL driver and SDK.

Is it any wonder why nvidia constantly beats ATI to the punch in supporting new distro's?

[crumja]

I know that nvidia is overflowing with devs who work on driver and OS support. They're also more aggressive in targeting newer OS releases. ATI's drivers and software are mainly targeted at the professional market, where the latest OS is not as popular as it is for consumers.

[deanjo]

I know that nvidia is overflowing with devs who work on driver and OS support. They're also more aggressive in targeting newer OS releases. ATI's drivers and software are mainly targeted at the professional market, where the latest OS is not as popular as it is for consumers.

If that was the case then they would be testing against SLED instead of openSUSE.

[mirv]

I might point out that amd would know what systems their customers use better than anyone else. These things are not chosen willy-nilly.
But on topic, it's really good to see amd getting behind opencl like this. It will hopefully help tie cpu & gpu processing together to get the best performance overall with less tweaking effort.

[deanjo]

I might point out that amd would know what systems their customers use better than anyone else.

This doesn't seem to be the case. Professional workstations typically use long term support releases over short term edge releases. This is why distributors of workstation class machines (ones that offer a suse flavor) bundle with SLE instead of openSUSE. SLE does get bug fixes that are not limited to critical or security releases where as openSUSE more often then not those fixes are incorporated in the next release.