12 Replies Latest reply on Aug 26, 2008 2:16 AM by zpdixon

    SDK 1.1 beta on ubuntu Hardy

    bigdog
      does sdk 1.1 beta work on ubuntu hardy?

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

       

      Thanks

      Mike

        • SDK 1.1 beta on ubuntu Hardy
          ssclift

          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..

            • SDK 1.1 beta on ubuntu Hardy
              ssclift

              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.

                • SDK 1.1 beta on ubuntu Hardy
                  ssclift

                  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.

                    • SDK 1.1 beta on ubuntu Hardy
                      ssclift

                      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... 

                        • SDK 1.1 beta on ubuntu Hardy
                          rahulgarg
                          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.
                            • SDK 1.1 beta on ubuntu Hardy
                              ssclift

                              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.  

                    • SDK 1.1 beta on ubuntu Hardy
                      MicahVillmow
                      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;
                      }
                      • SDK 1.1 beta on ubuntu Hardy
                        rahulgarg
                        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.
                          • SDK 1.1 beta on ubuntu Hardy
                            D.Grady

                            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.

                              • SDK 1.1 beta on ubuntu Hardy
                                uytvbn

                                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.

                                  • SDK 1.1 beta on ubuntu Hardy
                                    rafal.lewczuk@gmail.com

                                    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

                                     

                                      • SDK 1.1 beta on ubuntu Hardy
                                        zpdixon

                                         

                                        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.