7 Replies Latest reply on Jul 25, 2008 7:55 PM by theo.borm

    newbie: fglrx driver dreadfully slow - is this normal and does it affect GPGPU performance?

    theo.borm
      Scientific linux 5.2 - HD4xxx - what can be done?

      Hi,

      Bought a test rig and installed SL 5.2 (RHEL 5.2 community rebuild sponsored by CERN/Fermilab ). Installation of frglx went well, both version 8.49 (supplied with sdk) and 8.51. However moving around windows and scrolling is dreadfully slow, glxgears < 1300 fps AND regularly crashes Xorg (7.1.1). no compiz in sight.

      This doesn't make me very optimistic about using this OS/card combination in a production system, so before I invest more time into configuring this setup I have a few questions:

      0) Did i miss something obvious?

      1) Does anyone have similar experiences with SL 5.2/RHEL 5.2 and is this an issue that can easily be resolved?

      2) Is it possible to still use the card without using fglrx driver (it performs better as a vesa-fb device) or not being the primary display adapter?

      3) does anyone have experience/tips for use with Suse 11 (seems supported)?

      regards,

      Theo

       

       

        • newbie: fglrx driver dreadfully slow - is this normal and does it affect GPGPU performance?
          Poozon

          I had the same with fglrx 8.49. Try to use fglrx 8.6. It works properly with the Stream SDK. I do not recommend to use fglrx 8.7 for this purpose. It does not work for me.

          And it is definitely worth to try to write a couple of programs to run them on HD 48xx. So do not be discouraged and give it a try.

          I have a 500x accelleration over one 2.4 GHz Intel core in some cases. The speed is astonishing.

            • newbie: fglrx driver no longer dreadfully slow - xcb locking issue now
              theo.borm

               

              Originally posted by: Poozon I had the same with fglrx 8.49. Try to use fglrx 8.6. It works properly with the Stream SDK. I do not recommend to use fglrx 8.7 for this purpose. It does not work for me.


              ok. I'll try 8.6 later.

              Meanwhile I've swapped hd's and installed opensuse 11.0, driver that came with the distribution didn't work, however 8.7 from amd website does.

              After discovering that there are some issues with the location of header files (http://en.opensuse.org/GCC_4.3_Transition) I added #include <stdlib.h> and #include <string.h> to basic.cpp and got that to compile.

              running the program results in:

              libxcb: WARNING! Program tries to unlock a connection without having acquired
                      a lock first, which indicates a programming error.
                      There will be no further warnings about this issue.
              libxcb: WARNING! Program tries to lock an already locked connection,
                      which indicates a programming error.
                      There will be no further warnings about this issue.
              basic: xcb_io.c:352: _XReply: Assertion `!dpy->xcb->reply_data' failed.
              Aborted

               

              :-/

              so it's back to the drawing board.

               

               

               

              And it is definitely worth to try to write a couple of programs to run them on HD 48xx. So do not be discouraged and give it a try.

               

              I have a 500x accelleration over one 2.4 GHz Intel core in some cases. The speed is astonishing.

               

              it would be truly amazing if things would work "out of the box" ;-)

              cheers, Theo

                • newbie: fglrx driver no longer dreadfully slow - xcb locking issue now
                  Poozon

                   

                  Originally posted by: theo.borm 

                   

                  running the program results in:

                   

                  libxcb: WARNING! Program tries to unlock a connection without having acquired         a lock first, which indicates a programming error.         There will be no further warnings about this issue. libxcb: WARNING! Program tries to lock an already locked connection,         which indicates a programming error.         There will be no further warnings about this issue. basic: xcb_io.c:352: _XReply: Assertion `!dpy->xcb->reply_data' failed. Aborted

                   

                   

                  I told you man, start from fglrx 8.6. I have the same bug as you using fglrx 8.7

                  Best regards,

                  Poozon



                    • newbie: fglrx driver issue solved - SL 5.2+catalyst 8.6
                      theo.borm

                       

                      I told you man, start from fglrx 8.6. I have the same bug as you using fglrx 8.7

                       

                      Best regards,

                       

                      Poozon

                       

                      Ok. Thanks, it seems to work now. I didn't realize that things were so picky.

                      So, to summarize (and help anyone else stumbling upon these problems), here my experiences with fresh OS installs:

                      SL 5.2 with catalyst 8.6 (frglx 8.50*) works "out of the box" after adding a few lines to ld.so.conf (/usr/local/amdcal/lib64 and /usr/local/amdbrook/sdk/lib) and running ldconfig.

                      SL 5.2 with catalyst 8.7 (frglx 8.51*) driver doesn't work properly - dreadfully slow scrolling and moving of windows). Have not tried any of the CAL/Brook examples.

                      SL 5.2 with frglx 8.49* (shipping with SDK) driver doesn't work properly - dreadfully slow scrolling and moving of windows). Have not tried any of the CAL/Brook examples.

                      Opensuse 11.0: frglx 8.51* seems to work as a basic/3d video driver. CAL programs don't compile unless you add extra #includes, and don't run because of XCB locking issues.

                      I haven't tried Opensuse with the other frglx versions because an update of libxcb and other Xorg libraries was borked and X could not start (missing modules/no device found) anymore.

                      This makes me wonder how these issues will affect portability of stream computing in general (and my own programs in particular) - and thereby user acceptance - Saying "you need XP/sp2 to run this program" may work in the world of the other OS, but I imagine that *nix users  will not accept a similar "you need RHEL 5.2 to run this program" stance. Maybe it's just the fate of "early adopters" and things will shortly get better, maybe its an indicator of more fundamental problems (related to supporting a heterogenous sw environment).

                      Regards, Theo

                • newbie: fglrx driver dreadfully slow - is this normal and does it affect GPGPU performance?
                  MicahVillmow
                  Theo some other users had the same problem with the XCB locking issue and this is the solution that they posted about it:
                  http://forums.amd.com/forum/me...eyword1=sloppy%20lock

                  Basically its to set the environment variable LIBXCB_ALLOW_SLOPPY_LOCK=true.
                    • newbie: fglrx driver dreadfully slow - is this normal and does it affect GPGPU performance?
                      theo.borm

                       

                      Originally posted by: MicahVillmow Theo some other users had the same problem with the XCB locking issue and this is the solution that they posted about it: http://forums.amd.com/forum/me...eyword1=sloppy%20lock Basically its to set the environment variable LIBXCB_ALLOW_SLOPPY_LOCK=true.


                       

                      Hi,

                      I forgot to mention that I tried that too - and it didn't work for me - same error (also after restarting X).

                      regards, Theo

                        • newbie: fglrx driver dreadfully slow - is this normal and does it affect GPGPU performance?
                          theo.borm

                          OK, to make matters more confusing:

                          I was (unintentionally) using a XEN SL 5.2 kernel - and this turns out to be the root cause for the slowness.

                          XEN kernel with fglrx 8.501 (catalyst 6) and 8.512 (catalyst 7) are slow: glxgears barely gets past 1300 fps.

                          NORMAL kernel with fglrx 8.501 (catalyst 6) and 8.512 (catalyst 7) are fine: glxgears achieves 11000+ fps.

                          HOWEVER, running brook+ demo programs with fglrx 8.512 (catalyst 7) results in:

                          Xlib: sequence lost (0x10000 > 0xa) in reply type 0x0!
                          X Error of failed request:  0
                            Major opcode of failed request:  0 ()
                            Serial number of failed request:  0
                            Current serial number in output stream:  10

                          So to wrap things up: (maybe something for the faq?)

                          • XEN kernels currently do not work with fglrx.
                          • Stick to fglrx 8.501 (catalyst 6) for now.

                          Thanks Poozon for pointing out the latter.

                          Cheers, Theo

                          (actually, not being able to use XEN is a bit of a downer to me - now I'm stuck with using linux - not my favorite os)