Future of my support for ATI

[siggma]

Your comment was "So, now I upgrade to a new x1650 (r560) card and vuala, no support for most of it's features under linux." I was asking which features you were talking about.

Video playback.

If we wanted to do that, why would we bother investing in Linux support at all ? Wouldn't it be easier to only support Windows and MacOS ?

Then why is it do difficult to get this working?

My primary machine is running Ubuntu 8.10 with the in-box open drivers on an X1950PRO (ie rv570), running Compiz with wobbly windows, rotating cube etc... No artifacts or problems that I can see. Haven't played any DVDs though, just video files including some high-def H.264 files (eg Big Buck Bunny) which all play very cleanly. I have a fairly recent quad-core CPU though, maybe that is helping.

I'm currently running radeon rather than radeonhd because the radeon package on 8.10 works properly with 3D while the radeonhd package does not, but I'm hoping to get the latest radeonhd built and running later this week.

I'm running the same. Tried compiling a git radeon two weeks ago. I also compiled the git radeonhd and it's really messed up. Menus drop down but don't redraw background, xv won't work, gl is unusably slow, gl2 flashes wildly etc. So far the best driver I've seen is the straight radeon. I don't care that much about fancy rotating desktops but when I do enable them I see horrible tearing in ALL video output. My definition of "tearing" is when the update is interrupted by a second update. I'm running a 2 Ghz Core Duo that runs flawlessly under Vista. In fact I can't get it to tear no matter what I do.

Yesterday I was fiddling with mediamonkey in Vista to see what framerates I could get. With mutisampling set to 6X using desktop mode I get 52 frames average at 1440x900 on my digital panel. I doubt I have a cpu issue so unless there is something specific to my Gigabyte motherboard, it's got to be the driver.

The card is an X1650 PCIE 256DDR2 from Visiontek. CPU is an Intel 2140 Core Duo O-clocked a bit (from 200 - 240). Ram is a 1gig pair running Dual Layer at 799Mhz (I think). I doubt this box is too slow to reder the pages. I can play 5 640x videos at once and still see no frame drops so...

The patch blocks all rendering activity until the next vblank. If your primary use of the system is for video playback this isn't a problem, but it does slow down 3d and some 2d drawing. Alex was pretty clear that this would probably not make it in as a general purpose solution, just as something which would help users whose primary application was video playback.

So, how do I install it. I'm familiar with compiling and I can do a git get but I can't find the correct url to fetch it. Can you post the url, I'd be happy to give it a try.
-Tom

[Kjella]

The Windows video system includes support for all the things you are talking about below -- triple buffering, flow control for video through the compositor etc... -- all of those are being added to the Linxu/X stack over time but they are not there yet. Even syncing Xv playback to vblank is problematic and keeps getting yanked and/or rewritten in the open source driver stack.

Here we are at the real source of the problem - it's not ATI but it's the parts that Microsoft write in the Windows market that suck on Linux. From what I've read, the reason the nVidia driver works is that it takes over most of what xorg is trying to do. With all due respect to the people that have tried fixing X through extensions, it's still a mess. Graphics cards shouldn't have to implement more than the lowest layer of modesetting / gallium3d shaders / video acceleration / dual+ screen, the rest is (or rather should be) common.

The really sad thing is that after the xfree86/xorg breakup I thought things would be different. Or well I suppose they're better, but the whole X subsystem has almost as many delays and dropped out features as Vista. I just hope that it's really so extendable as some people tend to think, because there's sure a lot that needs fixing still. I sound a little glum but it is improvign, just not nearly as fast as I'd like.

[bridgman]

There has been a bit of a chicken-and-egg problem here. One thing that wasn't so obvious to us back in 2002/2003 was that major advances in the X framework were totally dependent on availability of decent open source drivers for a majority of GPU vendors, since any API-breaking changes to the framework couldn't even be tested unless the same developers could make co-ordinated changes to the drivers.

This is obvious in hindsight, but what isn't ?

Now that we are actively supporting open source driver development for ATI graphics again the xorg developers have access to open source drivers for enough of the hardware installed base that it is now feasible to make "big scary changes" to the X/DRI framework and have those changes be available on most of the commonly used hardware.

There has been a lot of real progress made by the xorg community over the last year. So far it has all been down in the foundation portion of the xorg/DRI framework (memory management, KMS, DRI2) with little or no visible benefit for users, but I think we are only a few months away from the point where developers can start to build on the last year's efforts and show some real user-visible progress.

Anyways, that's my 2 cents...

[siggma]

I can't find a zip for the tear-free video patch. I see the commit log but I don't really know how to get the actual patch. Can one of you give me a hint?

i just got the latest radeon video source and compiled it and I'm about to test it before I apply any patches.
-Tom

[bridgman]

I have asked Alex for advice on this, particularly re: whether the patch is likely to still work on the latest code (it was posted back in July I think). He is on vacation this week but might pop in anyways.

[siggma]

Yea, I don't think so. I copied the diff++ and patch won't apply it.

siggma@ibex:~/xf86-video-ati$ sudo patch -p001 < ../tearfreepatch.txt 
patching file src/atombios_crtc.c
patch: **** malformed patch at line 6: OUTREG(AVIVO_D1MODE_VIEWPORT_SIZE + radeon_crtc->crtc_offset,

Either copying it from the web messed up line endings or it's not valid for the current version.

Thanks anyway.

Update:

For those who care the latest radeonhd works better now and is almost usable.
Git compile instructions are here: http://www.digitalself.org/2008/06/1...ri-3d-support/

Relevant xorg.conf for r560 (x1650) using HDMI->DMI adapter ->LG 19" panel below:

Section "Device"
    Identifier    "Configured Video Device"
    Driver "radeonhd"
#    Option "AccelMethod" "EXA"
    Option "DRI" "true"
    Option "UseFastTLS" "2"
    Option "BackingStore" "on" 
    Option "MaxGARTSize" "512"
    Option "ColorTiling" "on"
    Option "EnablePageFlip" "on"
    Option "DisplayPriority" "HIGH" #BIOS or AUTO   
EndSection

NOTE: Page flipping makes a HUGE difference for me. I still see video artifacts but it's nowhere near as bad as it has been.

[duby229]

There has been a bit of a chicken-and-egg problem here. One thing that wasn't so obvious to us back in 2002/2003 was that major advances in the X framework were totally dependent on availability of decent open source drivers for a majority of GPU vendors, since any API-breaking changes to the framework couldn't even be tested unless the same developers could make co-ordinated changes to the drivers.

This is obvious in hindsight, but what isn't ?

You know what???

Freakin Bravo man...

I couldnt possibley have said it any better myself even if I had tried. And that really is the crux of it isnt it? A radeon 7000 works beautifully in linux. Its a wonderful experience. All of the features that card supports are also supported by X. Now that we finally have newer hardware with open source support with more features, those should be supported in due time as well.

[legume]

I can't find a zip for the tear-free video patch. I see the commit log but I don't really know how to get the actual patch. Can one of you give me a hint?

i just got the latest radeon video source and compiled it and I'm about to test it before I apply any patches.
-Tom

There is currently more work going on to get vsync for R500, so it may be worth waiting a bit.

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