Radeon Driver Gets Tear-Free X-Video

[chrisr]

Latest radeon DDX driver toxic on Fedora 9!

Hi,

I have a Radeon 9550 card, and I thought I'd give the latest DDX driver a spin on my Fedora 9 machine (vanilla 2.6.27.10 kernel). The git log's last entry is:

commit c0c33dab44e6966b1702d4e8cfba3537fc6e2d5c
Author: Patrick Haller <[email protected]>
Date:   Mon Dec 22 03:06:23 2008 -0500

    Fix off by one in EXA composite limit checking
    
    Patch from Patrick, with some updates from me:
    - fix r200 limits
    - note about r100 limits

However, as soon as I tried logging in, Xorg went into an endless spin-cycle with 100% usage of one CPU. I was eventually able to ssh in from a remote box and swap the driver back out again, but although I managed to "neutralize" the rogue process, I couldn't remove it from the process table completely without rebooting!

Am I missing a dependency somewhere? E.g. does the DDX driver in git need Fedora 10's version of Xorg?

[sundown]

Wow, I'm just extreamely happy! This brought some tears in my eyes.

Recently Debian moved this to the experimental repos and only now have I been able to fully test it.

It freaking does work!

Thank you, guys!!!

[agd5f]

Hi,

I have a Radeon 9550 card, and I thought I'd give the latest DDX driver a spin on my Fedora 9 machine (vanilla 2.6.27.10 kernel). The git log's last entry is:

commit c0c33dab44e6966b1702d4e8cfba3537fc6e2d5c
Author: Patrick Haller <[email protected]>
Date:   Mon Dec 22 03:06:23 2008 -0500

    Fix off by one in EXA composite limit checking
    
    Patch from Patrick, with some updates from me:
    - fix r200 limits
    - note about r100 limits

However, as soon as I tried logging in, Xorg went into an endless spin-cycle with 100% usage of one CPU. I was eventually able to ssh in from a remote box and swap the driver back out again, but although I managed to "neutralize" the rogue process, I couldn't remove it from the process table completely without rebooting!

Am I missing a dependency somewhere? E.g. does the DDX driver in git need Fedora 10's version of Xorg?

Remove the EXAVSync option if you have it enabled in your config. It doesn't seem to work reliably on all r3xx cards at the moment.

[hobbes]

Wow, I'm just extreamely happy! This brought some tears in my eyes.

Recently Debian moved this to the experimental repos and only now have I been able to fully test it.

It freaking does work!

Thank you, guys!!!

I've just updated to very latest ubuntu jaunty packages and the problem (tearing) persists.

xserver-xorg-video-ati (1:6.9.0.91-1ubuntu1) jaunty; urgency=low

  * Merge from debian experimental, remaining changes:
    - Add 104_use_exa.patch: Switches to EXA acceleration by default.

xserver-xorg-video-ati (1:6.9.0.91-1) experimental; urgency=low

  * New upstream release candidate.

xserver-xorg-video-ati (1:6.9.0+git20081129.783cdb73-1) experimental; urgency=low

  * Pull upstream snapshot, up to commit 783cdb73.
    + Add AGPMode quirk table, closes: #461144, #462590, #467460.

xserver-xorg-video-ati (1:6.9.0+git20081012.c0e6cb6d-1) experimental; urgency=low

  * Pull upstream snapshot, up to commit c0e6cb6d, closes: 500903.

Date: Fri, 02 Jan 2009 13:27:30 +0200
Changed-By: Timo Aaltonen <tjaalton at ubuntu.com>
Maintainer: Ubuntu X-SWAT <ubuntu-x at lists.debian.org>
https://launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-ati/1:6.9.0.91-1ubuntu1

$ egrep EXA* /var/log/Xorg.0.log
(**) RADEON(0): Option "EXAVSync" "1"
(==) RADEON(0): Using EXA acceleration architecture
(==) RADEON(0): Not using accelerated EXA DownloadFromScreen hook
(II) RADEON(0): Setting EXA maxPitchBytes
(II) RADEON(0): EXA VSync enabled

$ egrep "AGP 8x" /var/log/Xorg.0.log
(**) RADEON(0): Using AGP 8x

(--) RADEON(0): Chipset: "ATI Radeon X1600" (ChipID = 0x71c2)

My Hardware:

Sapphire AGP x1600pro 512MB

Apparently, we have the very same packages by now and no tear-free xv for me.

Any help would be appreciated.

Thanks For Reading.

[TechMage89]

You don't need EXAVsync for Xv vsync.

It works for me, with an x1600xt and the 6.9.1 RC driver (no tearing on Xv at all)

What media player are you using? Are you sure it's using Xv for video out? OpenGL still isn't vsynced.

[hobbes]

You don't need EXAVsync for Xv vsync.

It works for me, with an x1600xt and the 6.9.1 RC driver (no tearing on Xv at all)

What media player are you using? Are you sure it's using Xv for video out? OpenGL still isn't vsynced.

Are you using Jaunty Alpha 2 with the very latest packages?

Totem is my main player.

Compiz is on by the way and it gets some tearing (horizontal lines) when I zoom in/zoom out on a gnome-terminal window or move around nautilus.

yes, Totem is set to use Xv (as default)

[bridgman]

Tear free won't work if you have Compiz running; it will just deliver tear-free video to Compiz then Compiz will copy it in a tear-y manner to the screen.

I am not aware of a tear-free solution for Compiz.

[hobbes]

Tear free won't work if you have Compiz running; it will just deliver tear-free video to Compiz then Compiz will copy it in a tear-y manner to the screen.

I am not aware of a tear-free solution for Compiz.

Hum.. now I see.

So, GEM/DRI2 Won't actually solve this issue in the future?

[bridgman]

So, GEM/DRI2 Won't actually solve this issue in the future?

Not really; DRI2 (actually RDR, built on DRI2) will help to solve the flicker problems when direct-rendering 3D apps run under Compiz, but flickering and tearing are two different problems.

What is really needed is for Compiz to synchronize *it's* drawing operations to vertical retrace (rather than the individual driver stacks like Xv) and for it to have a flow control mechanism to tell the individual apps when to start and stop drawing. My guess is that most of what is needed is in place but nobody is looking at the end-to-end solution.

[calica]

My guess is that most of what is needed is in place but nobody is looking at the end-to-end solution.

And it needs to be standardized across compositing managers. It would be horrible for Compiz and kwin to do it differently.