Installing latest xf86-video-ati for r500 on Gentoo

[DragonionS]

Thanks a lot! I have ATI Mobility Radeon X1600 and now I have a well working my videocard! This is amazing! xf86-video-ati is a great driver that is much better than fglrx. 3.3 Mb is the weight of open source driver and it is working much better than fglrx with its 56 Mb.
I know that xf86-video-ati has no full support of ATI Radeon opportunities and they have a lot of work to do but now I can just use it and not switch to metacity every time when I want to watch some video.

Thank you!

[RealNC]

Very promising driver. It works on my X1950XT (R580) with compiz fusion while fglrx doesn't.

However, I've encountered a bug and wonder if anyone else is getting it too. I've filed a but report about it: http://bugs.freedesktop.org/show_bug.cgi?id=16850

I'll recap here: Switching from X (plain 2D or in Compiz) to a console results in the kernel spitting out those:

do_IRQ: 0.83 No irq handler for vector
do_IRQ: 0.83 No irq handler for vector
do_IRQ: 0.83 No irq handler for vector

Trying to do opengl vsync (vlank_mode 1) results in glxgears running at exactly 0.333 FPS and saying:

do_wait: drmWaitVBlank returned -1, IRQs don't seem
  to be working correctly.

Also, I just found out that driconf complains with:

IRQ's not enabled, falling back to busy waits: 0 24

When changing fthrottle_mode ("Method to limit rendering latency").

Does someone know what's going on? Anyone else getting those or just me?

[bridgman]

RealNC, I have seen this mentioned in the last few days on one of the IRC channels, probably dri-devel. I'll see if I can find it. Seems like a recent regression, possibly related to some of the vblank / IRQ work being done over the last couple of weeks. You can see the pain if you read through the dri-devel mailing list archives -- this is a pretty complex part of the code.

[RealNC]

Meanwhile, I've built a kernel with DRM completely disabled and ran fglrx on X.Org 1.4.2. The warnings were still there. So it might be entirely a kernel 2.6.26-only issue?

Also, disabling MSI (Message Signaled Interrupt support: CONFIG_PCI_MSI) replaces each "do_IRQ" warning with:

+------ PCI-Express Device Error ------+
  Error Severity          : Uncorrected (Non-Fatal)
  PCIE Bus Error type     : Transaction Layer
  Flow Control Protocol   : First
  Receiver ID             : 0010
  VendorID=1106h, DeviceID=a208h, Bus=00h, Device=02h, Function=00h
  Broadcast error_detected message
  Broadcast mmio_enabled message
  Broadcast resume message
  AER driver successfully recovered

See http://bugs.freedesktop.org/show_bug.cgi?id=16850

[bridgman]

RealNC, are you getting these messages with fglrx or one of the open drivers ? I thought you were talking about the open driver.

Reading again I think you're saying you get the messages with both open *and* closed drivers ?

[RealNC]

Yes, with both. (And *only* with a 2.6.26 kernel.) So I guess it's a kernel problem.

I wonder if vsync with opengl (vblank_mode 1) is actually supposed to work at all with xf86-video-ati 6.9.0. If not, then I guess I can live with the warnings

Edit:
I hope it's not due to my card not being recognized correctly; it's a somewhat rare one. A 512MB X1950XT (Sapphire). lspci seems to think it only has 256MB, not 512.

[agd5f]

I hope it's not due to my card not being recognized correctly; it's a somewhat rare one. A 512MB X1950XT (Sapphire). lspci seems to think it only has 256MB, not 512.

lspci doesn't show the size of vram, rather it shows the size of the PCI BAR. This often, but not always, corresponds to the amount of vram on the card. The max PCI BAR size is 256 MB that's the largest aperture you can map. For cards with more the 256 MB of vram, only 256 MB can be mapped for access by the CPU. The GPU, however, can access the entire amount of vram.

[RealNC]

Thanks for the explanation. Do you know if vsync in OpenGL (vblank_mode 1) is supposed to work with R500 chips yet?