cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

bigdog
Journeyman III

SDK 1.1 beta on ubuntu Hardy

does sdk 1.1 beta work on ubuntu hardy?

Does anyone have sdk 1.1 beta up and going on Ubuntu Hardy?

 

Thanks

Mike

0 Likes
12 Replies
ssclift
Journeyman III

I had to install the Ubuntu rpm package.  I then edited the amd*.run scripts from ATI to comment out the clean-up of the /tmp/amdcal and /tmp/amdbrook directories that they generate.  Then I could

    sudo rpm -i --nodeps amdcal-1.01.1_beta-1.x86_64.rpm amdbrook-1.01.0_beta-1.x86_64.rpm

to install the two packages.  AFAICT They basically work, but I'm getting a problem with sample programs:

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f9ba21f397c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f9ba21f3a84]
#2 /usr/lib/libX11.so.6(_XReply+0x10f) [0x7f9ba263df4f]
#3 /usr/local/amdcal/lib64/libamdcalrt.so [0x7f9ba2e46197]
#4 /usr/local/amdcal/lib64/libamdcalrt.so [0x7f9ba2e45d53]

which appears to be related to a problem being discussed on the

  "32 bit Fedora 8 + Linux Brook"

thread.

Now... if only Catalyst supported 3870X2 cards..

0 Likes

https://bugs.launchpad.net/xorg-server/+bug/185311

Seems to be the relevant discussion.  It appears to be a very low-level routine in the XCB library that is failing to release a lock.  There is a "sloppy locking" environment variable that seems to be enabled in some XOrg/Linux distributions, but apparently neither Hardy nor Fedora 8,9 fall into that group.

I'm too tired to take a crack at reworking XCB at this point.  Maybe in the next couple of days.

0 Likes

Hmmm... until the 3870 X2 drivers are there... my test box is a little puny, an AMD 64-bit 4400 and an HD2400 graphics card.   However I can get sample code to compile and run.

The Black-Scholes sample program runs in 10s for 122070 iterations (500M calcs, if I read it correctly) for BRT_RUNTIME=cpu with g++ -O3.  Same runs in 15 seconds with BRT_RUNTIME=cal.  With the "cal" option the "Locking assertion failure" backtrace appears, which makes me suspect that I'm perhaps not actually looking at GPU calculations.  Then again, this is an AGP card and an odd application that probably doesn't stream as well as others.

Anyhow, the SDK running on a Hardy 8.04 machine at least, and I can start coding up some tests of interest to me while I wait, most patiently, for the good folks at AMD/ATI to put 3870X2 support in Linux.

0 Likes

This thread:

  http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=95574&enterthread=y

is the better approach, using the "alien" package translator.

I've just installed using this method using a

  • M3A32-MVP motherboard
  • AMD Phenom 9750
  • 3870 (not X2) graphics card and
  • a new Ubuntu 8.04 Hardy Heron  installation

and I'm getting good results.  The optimized matrix multiple demo for a 1024x1024 matrix, 100 iterations gives me

  • 2.24s at 89 GFLOPS on the GPU (export BRT_RUNTIME=cal)
  • 1774s at 0.11 GFLOPS on CPU

although I note that the code is hardly optimized for CPU

The libxcb problem is still occurring, but doesn't seem to be getting in the way of actually doing computations.

Now, off to see how to do a real problem... 

0 Likes

Two questions :
1. Did you get the locking assertion failure etc? I did LIBXCB_ALLOW_SLOPPY_LOCK=true.

2. Btw is calDeviceGetAttribs working for anyone on Hardy? This particular function is leading to segfaults on my machine.
0 Likes

I still got the locking failure but didn't try LIBXCB_ALLOW_SLOPPY_LOCK=true again, since that seemed to have no effect.   I can check again.

I'm getting some funny segfaults; I'll check the output cal code and see if that was one of them.

I'm getting the impression, although I didn't find it in the docs, that the kernel intrinsic operations (log(), sqrt() etc.) don't work on double data, only on floats.  

0 Likes

Rahul, calDeviceGetAttribs can segfault if the struct_size field is not set correctly. The correct usage is as follows:
CALdeviceattribs attribs;
attribs.struct_size = sizeof(CALdeviceattribs); <-- set the struct size here.
if (calDeviceGetAttribs(&attribs, Info.DeviceNum) != CAL_RESULT_OK)
{
return 1;
}
0 Likes
rahulgarg
Adept II

Thanks Micah. After setting attribs.struct_size, calDeviceGetAttribs does work without segfaulting.

To summarize : after installing on ubuntu hardy 32-bit, I put "export LIBXCB_ALLOW_SLOPPY_LOCK=true" in my .bashrc, restarted X just to be safe, and cal does appear to work correctly. Locking assertion warnings are still printed but there are no segfaults.
0 Likes

I would like to add a little more information here as to what works and what doesn't - noteably, on my ubuntu64 8.04 install with a 4850 the ONLY version of the driver that works is 8.7.  8.6 hard locks my system and I have to reboot.  As many others have mentioned, the SDK only works with 8.6, and so doesn't work on ubuntu64 at this point.

I installed ubuntu32 8.04 on the same machine and lo and behold, 8.6 runs fine.  Once that was the case, then the SDK ran fine as well.  I also used the .bashrc fix above.

Until 8.7 is supported, save yourself a world of pain and don't try this on 64-bit.  If someone has it working on 64-bit, awesome, let me know what you did, but I worked at it for more than a week with basically no progress.

0 Likes

I've actually managed to run 8.6 drivers with Fedora 9 x86-64 and 4850. The driver seems to have some problems with memory management, and the solution is to disable memory remapping in BIOS. This limits maximum usable memory to ~3GB and since I've had other problems with this driver I've gone back to 8.8 and am waiting for the next release of Stream SDK.

0 Likes

I'm running CAL on 64-bit Ubuntu 8.04 with 8GB RAM. There are some quirks and work arounds but it seems to work stably (for me). Catalyst 8.6. You need to:

1. change MTRR settings (incorrectly set by BIOS), my MTRR tinkering script looks like this:

echo "Removing old settings..."
echo "disable=2" >| /proc/mtrr
echo "disable=1" >| /proc/mtrr
echo "disable=3" >| /proc/mtrr
echo "disable=4" >| /proc/mtrr
echo "disable=0" >| /proc/mtrr

echo "base=0x00000000 size=0x80000000 type=write-back" >| /proc/mtrr
echo "base=0x80000000 size=0x40000000 type=write-back" >| /proc/mtrr
echo "base=0xC0000000 size=0x10000000 type=write-back" >| /proc/mtrr
echo "base=0x100000000 size=0x100000000 type=write-back" >| /proc/mtrr
echo "base=0x200000000 size=0x20000000 type=write-back" >| /proc/mtrr
echo "base=0x220000000 size=0x10000000 type=write-back" >| /proc/mtrr

This is for 8GB system. Look at Ubuntu forums for 4GB versions. And there is still some issue with write combining for video RAM - this configuration may have somewhat suboptimal data transfer rates but I didn't care for it too much

Put it into your startup scripts before starting X. Be careful tinkering with MTRR as it locks your system when done incorrectly.

2. Remove Ubuntu startup splash - as it tends to lock fglrx when switching between text mode and X - remove "splash" word from kernel startup parameters.

3. LIBXCB_ALLOW_SLOPPY_LOCK=true.  But I'm not sure it helps much as I'm still getting those error messages (albeit program itself works).

4. Look at http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=97060&enterthread=y for more details.

I was able to reach around 220 GFLOPS on optimized_matmult demo on 4850 card.

Regards,

rle

 

0 Likes

Originally posted by: rafal.lewczuk@gmail.com

3. LIBXCB_ALLOW_SLOPPY_LOCK=true.  But I'm not sure it helps much as I'm still getting those error messages (albeit program itself works).

 

This is correct. As I explained in the thread you linked to in point #4, Ubuntu 8.04 does not use the environment variable LIBXCB_ALLOW_SLOPPY_LOCK anymore, this can be confirmed by reading the source code of the libxcb1 package. There is no way to disable the warning messages, defining the var won't change anything. I think we need a FAQ somewhere.

0 Likes