I picked up an X800 XL a few days ago.  Apparently ATI is using a
different chipset than the previously-tested X800 board mentioned on
the r300 website; this one has an R430 in it.

  01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 554d
  01:00.1 Display controller: ATI Technologies Inc: Unknown device 556d

To see if I could get it working, I threw "R430" stuff into the Mesa
and drm source pretty much wherever I found "R420" mentioned.  I used
the 0x554d ID.

  [drm] Initialized radeon 1.17.0 20050720 on minor 0: PCI device 1002:554d 
(ATI Technologies Inc)
  mtrr: 0xd0000000,0x10000000 overlaps existing 0xd0000000,0x8000000
  mtrr: 0xd0000000,0x10000000 overlaps existing 0xd0000000,0x8000000
  mtrr: 0xd0000000,0x10000000 overlaps existing 0xd0000000,0x8000000
  agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
  agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
  agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
  [drm] Loading R300 Microcode

X.org seems to recognize the board, though it incorrectly claims it's PCIE:

  (--) RADEON(0): Chipset: "ATI Radeon X800 XL (R430) (PCIE)" (ChipID = 0x554d)

I'm using kernel 2.6.11 plus some distribution-specific (GoboLinux) patches.
I believe the Gobo patches are mainly for the filesystem and shouldn't be
impacting DRI.

The good news is that it does at least enable DRI, and I do seem to
get stable 2D support (although in some cases it seems slower than the
old Voodoo3 it replaced).

  $ glxinfo
  name of display: :0.0
  *********************************WARN_ONCE*********************************
  File r300_state.c function r300Enable line 456
  TODO - double side stencil !
  ***************************************************************************
  No ctx->FragmentProgram._Current!!
  display: :0  screen: 0
  direct rendering: Yes
  ...

  $ glxgears
  *********************************WARN_ONCE*********************************
  File r300_state.c function r300Enable line 456
  TODO - double side stencil !
  ***************************************************************************
  No ctx->FragmentProgram._Current!!
  *********************************WARN_ONCE*********************************
  File r300_render.c function r300_get_num_verts line 188
  user error: Need more than 2 vertices to draw primitive QS !
  ***************************************************************************
  4587 frames in 5.0 seconds = 917.248 FPS
  4605 frames in 5.0 seconds = 920.863 FPS
  ...

If the FPS seems low, note that the test machine is an old P3-500MHz.

Now the bad stuff:

- Some programs run without acceleration.  LIBGL_DEBUG=verbose reports
  things like:

    libGL error: dlopen .../r300_dri.so failed (.../r300_dri.so: undefined 
symbol: _glapi_add_dispatch)

  strace shows it opening the right versions of libGL and r300_dri,
  and libGL does have that symbol, and of course glxinfo and glxgears
  do run with direct rendering.  So this is a mystery.

- Software GL consistently segfaults the X server whenever certain
  operations (such as a window resize) are attempted.  For example one
  of my test programs that does _not_ run with direct rendering does a
  glutReshapeWindow on startup and it segfaults X.org every time.  The
  good news is that the server seems to restart easily and e.g. the
  machine has not completely locked up on me yet.

- The "Building" page on the wiki seems to be out of date.  Mesa now
  requires libdrm to be installed and registered with pkg-config.

                                                  -Dave Dodge


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to