AMD Talks About Stream SDK On Linux

[phoronix]

Phoronix: AMD Talks About Stream SDK On Linux

Late last month AMD had announced the release of the Stream SDK for Linux. This Stream SDK brings support for the CAL and Brook+ libraries on Linux. The version released was Stream SDK 1.1 Beta, which arrived at the same time as the SDK for Windows XP. With this new Linux support, we ran a small Q&A session with Michael Chu, who serves as the product manager for AMD Stream software. In this article are AMD's answers to some of the questions asked by members of the Phoronix Forums.

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

[SavageX]

One interesting question would be when there'll be a cross-vendor stream processing API. If Nvidia and AMD don't happen to be able to agree on one it'll be either Microsoft (using some DirectX thingie) or Intel (apparently their stream-processor efforts are x86 related) setting one in stone.

[yoshi314]

How much of this Linux SDK will be "open" and how much of it is closed-source?

AMD is taking an open-systems approach to its AMD Stream SDK software stack. We document each of the layers of the stack so that tools and library partners can feel free to target whichever layer makes sense for them. We feel that our software partners are a critical part of our success and fully encourage them to add value to the stack wherever they can.

In addition, Brook+ is open-source and the source code is distributed with every Brook+ installer. Also, at appropriate times, changes made to Brook+ are pushed back into the BrookGPU project tree on SourceForge.

did you notice he didn't actually answer the question?

[sc3252]

I also am worried that if both AMD and Nvidia don't agree on a standard that Microsoft will make a closed source implementation that no OSS system will be able to use. Squaring off the market as they have done with directx.
My question is will AMD work with Nvidia to make a solution that both of them can standardize on without making one gpu a priority over another?

[bridgman]

I'm not sure it makes that much of a difference. Most of the serious investment in applications uses higher level tools which AFAIK can be targeted to different APIs relatively easily.

Typically the tool builders port to the APIs we offer, and everyone else writes to the tools. That was one reason we worked with the Brook team; to get most application development up off the hardware while still allowing a decently low level API for special cases like video acceleration or physics.

[SavageX]

Even if it is possible to achieve vendor-neutralness by higher-level tools it makes sense to agree on an interchangeable language to start with (with a formal and stable specification). There are several GPGPU projects out there and it's not clear which projects will "survive" well into the next decade.

I'd like to see a solution similiar to GLSL, where programs are compiled and optimized at runtime, giving vendor-neutralness and preserving the possibility to make good use of the underlying hardware.

Given that both Intel and AMD are going to integrate stream processors into future CPU lines and given that fact that software developers don't want interoperability headaches it's about time to push something vendor-neutral instead of pointing out to the possibility that 3rd-parties may have painkillers in store.

[SavageX]

Being curious I installed the SDK on Ubuntu. The procedure to install this properly albeit the installer is tailored towards RPM systems needs a bit of manual work (this is on x86_64, i386 should work the same):

- Install alien (this converts rpm to deb)
- install libstdc++5 (the SDK needs this to run)
- Start the installer for amdcal. When displaying the license you'll see a file amdcal.tar.gz in your temp dir. Extract amdcal.tar.gz, giving you amdcal-1.01.1_beta-1.x86_64.rpm. You now can abort the installer (this will delete amdcal.tar.gz).
- Start the installer for amdbrook. In the same matter as described above you'll obtain amdbrook.tar.gz, which will give you amdbrook-1.01.0_beta-1.x86_64.rpm
- Run the rpm files through alien, giving you amdcal_1.01.1_beta-2_amd64.deb and amdbrook_1.01.0_beta-2_amd64.deb
- Install those using dpkg

After appending

/usr/local/amdcal/lib64
/usr/local/amdbrook/sdk/lib

to /etc/ld.so.conf.d/x86_64-linux-gnu.conf and doing a ldconfig you should see e.g. brcc working:

maik@maik-desktop:/usr/local/amdbrook/sdk/bin$ ./brcc
Brook+ Compiler
Version: 1.00.0a  Built: May 22 2008, 16:02:43
brcc [-hkrgb] [-o prefix] [-p shader ] foo.br

   -h            help (print this message)
   -k            keep generated IL program (in foo.il)
   -r            diasable address virtualization
   -g            enable fast math (less accurate)
   -o prefix     prefix prepended to all output files
   -p shader     cpu or cal (can specify multiple)
   -s            tokenize into char list generated IL program
   -l            add #line directives
   -b            turn on bison debugging
   -f            turn on flex debugging

Now add e.g. /usr/local/amdbrook/sdk/bin and /usr/local/amdcal/bin/lnx64 to your PATH and you should be able to properly use the SDK.

Note that I haven't really done anything with it yet and for sure won't give any guarantee that it works

edit: Samples compile normally, but they won't actually run due to a "Locking assertion failure". I assume this is due to my fglrx being too old (amdccle gives 8.47.3, the version AMD distributes with the beta seems to be 9.49.4).