Ok so I bought an HD 4850 yesterday. I know it's not yet completely officially supported by the SDK yet, but I wanted an r700 family gpu anyway. After a long day of attempting to get the SDK to work, I barely managed to run some of the samples. Here are the problems I hit and how I managed to resolve them. This may help others.
First of all, I am running Ubuntu 8.04 amd64. The current fglrx driver that ships with the SDK (ati-driver 8.49.4) is extremely buggy. There are 64-bit bugs related to fglrx_dri.so that cause Xorg to segfault on startup. Forget about using this version of the driver. Instead install version 8.6 from [1] (or is it 8.501 ? the package is labelled 8.6 but files inside it refer to it as 8.501). Before installing it you will need:
$ apt-get install linux-headers-generic dkms
Then, after downloading ati-driver-installer-8-6-x86.x86_64.run from [1], I wanted to check what the scripts were doing before running them so I ran each step manually:
$ ./ati-driver-installer-8-6-x86.x86_64.run --extract ati-driver-installer-8-6-x86.x86_64
$ cd ati-driver-installer-8-6-x86.x86_64
$ ./ati-installer.sh 8.501 --buildpkg Ubuntu/hardy
$ cd ..
$ dpkg -i fglrx-kernel-source_8.501-0ubuntu1_amd64.deb
$ dpkg -i xorg-driver-fglrx_8.501-0ubuntu1_amd64.deb
At this point, make sure that the fglrx kernel module is loaded. If not, modprobe it yourself. (I didn't put it in my notes and don't remember whether dpkg -i fglrx-kernel-source_... does it or not).
Update your xorg.conf to use the 'fglrx' driver.
Then my preferred way to install the CAL and Brook RPMs on Ubuntu is to not use 'alien' but to do it the manual way:
$ apt-get install rpm
$ unzip cal_brook_1.01.0_beta_lnx64.zip
$ dd if=amdcal-1.01.1_beta.x86_64.run bs=16384 skip=1 of=amdcal-1.01.1_beta.x86_64.rpm
$ rpm2cpio amdcal-1.01.1_beta.x86_64.rpm > amdcal-1.01.1_beta.x86_64.cpio
$ cd / && cpio -i --make-dir < $OLDPWD/amdcal-1.01.1_beta.x86_64.cpio
The cpio archive extracts itself under /usr/local/amdcal. Repeat the same commands for the Brook RPM. Then set up the dynamic library paths:
$ echo /usr/local/amdcal/lib64 >/etc/ld.so.conf.d/amd-stream.conf
$ echo /usr/local/amdbrook/sdk/lib >>/etc/ld.so.conf.d/amd-stream.conf
Compile the CAL samples:
$ cd /usr/local/amdcal && make
And test them. If you ssh into a remote dev box, you need to define the DISPLAY variable.
$ export DISPLAY=:0
$ ./samples/app/hellocal/hellocal
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f2ad39cf97c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f2ad39cfa84]
#2 /usr/lib/libX11.so.6(_XReply+0x10f) [0x7f2ad3e19f4f]
#3 /usr/local/amdcal/lib64/libamdcalrt.so [0x7f2ad533a197]
#4 /usr/local/amdcal/lib64/libamdcalrt.so [0x7f2ad5339d53]
#5 /usr/local/amdcal/lib64/libamdcalrt.so [0x7f2ad5339429]
#6 /usr/local/amdcal/lib64/libamdcalrt.so(calInit+0x35) [0x7f2ad5340a45]
#7 ./samples/app/hellocal/hellocal [0x402dea]
#8 /lib/libc.so.6(__libc_start_main+0xf4) [0x7f2ad47291c4]
#9 ./samples/app/hellocal/hellocal(__gxx_personality_v0+0xa1) [0x4019c9]
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f2ad39cf97c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x15) [0x7f2ad39cfa15]
#2 /usr/lib/libX11.so.6 [0x7f2ad3e19323]
#3 /usr/lib/libX11.so.6(XFreeGC+0x18) [0x7f2ad3df59a8]
#4 /usr/lib/libX11.so.6(XCloseDisplay+0x4c) [0x7f2ad3dee88c]
#5 /usr/local/amdcal/lib64/libamdcalrt.so [0x7f2ad5339d62]
#6 /usr/local/amdcal/lib64/libamdcalrt.so [0x7f2ad5339429]
#7 /usr/local/amdcal/lib64/libamdcalrt.so(calInit+0x35) [0x7f2ad5340a45]
#8 ./samples/app/hellocal/hellocal [0x402dea]
#9 /lib/libc.so.6(__libc_start_main+0xf4) [0x7f2ad47291c4]
#10 ./samples/app/hellocal/hellocal(__gxx_personality_v0+0xa1) [0x4019c9]
0.000000 0.500000 1.000000 1.500000 2.000000 2.500000 3.000000 3.500000
128.000000 128.500000 129.000000 129.500000 130.000000 130.500000 131.000000 131.500000
256.000000 256.500000 257.000000 257.500000 258.000000 258.500000 259.000000 259.500000
384.000000 384.500000 385.000000 385.500000 386.000000 386.500000 387.000000 387.500000
512.000000 512.500000 513.000000 513.500000 514.000000 514.500000 515.000000 515.500000
640.000000 640.500000 641.000000 641.500000 642.000000 642.500000 643.000000 643.500000
768.000000 768.500000 769.000000 769.500000 770.000000 770.500000 771.000000 771.500000
896.000000 896.500000 897.000000 897.500000 898.000000 898.500000 899.000000 899.500000
Press enter to exit...
I'll explain the "assertion failure" in a minute, but before I'd like to mention that if I run this sample (hellocal) as root, then it HANGS right after the assertion failure warning is displayed. More specifically the sample program never displays the 8 lines of floats, I can control-C it, but at this point Xorg uses 100% cpu (system time, not user time), meaning the fglrx kernel module is probably stuck in an infinite loop. Consequence: "pkill -9 xorg" has no effect, the only way to recover is to reboot (!). Instead, if I run the sample program as a non-privileged user, it appears to have more chance of working reliably (it works about 2 out of 3 tries). But maybe the correlation between crashes and root/non-root is just a coincidence.
I would really appreciate if someone from AMD could investigate what's going on there. Of course it might be due to the fact that the HD 4850 is not fully supported yet, and that their QA team only QA the driver that ships with the SDK (8.49.4) and not the latest one (8.6 or 8.501, could you clear this up too: which is the right version number ?).
Now, about the "assertion failure" warning. There are lots of confusion about the meaning of this warning, and lots of incorrect advices. I have done some research and found out the following. Linux distributions used to either not ship libxcb1 (a X client library), or to configure it in a way to tolerate sloppy locking. Recent distros (such as Ubuntu 8.04) took the decision of not tolerating that anymore, in order to uncover long-standing bugs in broken X clients. So they started enforcing a stricter locking rule (that was instantly aborting X clients detected as broken), while at the same time giving the option to disable it via the LIBXCB_ALLOW_SLOPPY_LOCK environment variable on a per-client basis. As expected this uncovered lots of problems (in 3d games, java apps, cal/fglrx apps, etc). It was so disrupting that distros changed their mind [2]. In Ubuntu 8.04 for example, in libxcb1 version 1.1-1ubuntu1 and above, they now make the sloppy locking rule the default again (the code to support the LIBXCB_ALLOW_SLOPPY_LOCK env var tweak was removed). The warning message is *still* displayed (there is no way to hide it) however it is now completely benign (X clients are not aborted). In fact in Ubuntu there is now instead a *new* env var (LIBXCB_DISABLE_SLOPPY_LOCK) to explicitely re-enable the stricter locking rule and force broken clients to be aborted.
What this all means to CAL/Brook apps is that if you see this warning and are using Ubuntu 8.04 with libxcb1 1.1-1ubuntu1 or above, then don't panic. It's just a warning and won't interfere with the app.
However it *does* mean CAL/fglrx libraries/drivers are broken, and AMD will eventually need to fix them.
[1] http://ati.amd.com/support/drivers/linux64/linux64-radeon.html
[2] http://lists.freedesktop.org/archives/xcb/2008-May/003541.html
