looks like Catalyst 9.2beta leaked.

[nikopol]

Last version of open source ati solve problem in r300,r400 and r500.

R600 (HD2000 and HD3000 series) and R700 (HD4000 series) will have wait to ati or radeonHD support XV output.

The tearing has really been the bane of my life too (rv630 - hd 2600 xt). I'm not even that bothered about the 3d, all I want it to be able to watch DVDs and video files that don't look like someone is slicing every image in half with a blade.

Is there a version of catalyst that doesn't have tearing on it for my hardware? I'd be tempted to go old school to resolve the issue.

[Tares]

See this thread:

http://www.phoronix.com/forums/showt...libatiadlxx.so

That doesn't help me, even if it would, that just a workaround not a solution :/

[BlackStar]

Has anyone managed to install these on Archlinux? The PKGBUILD scripts complete, the packages are installed, but I get a black screen with some corruption on restart (VT switching works fine, however).

I'll try to find out what is going wrong, but I wonder if anyone has managed to install these correctly.

(System is Archlinux x86_64 with a 4850 video card.)

Edit: It seems that the kernel module fails to load due to "flush_tlb_page" missing.

WARNING: "flush_tlb_page" [/tmp/catalyst/src/archive_files/common/lib/modules/fglrx/build_mod/fglrx.ko] undefined!

A quick search showed this to be an old problem (around kernel 2.6.25) - I'll try the solutions listed there and see if they work.

Edit 2: Aha, the 2.6.27.patch seems to already contain a fix - maybe it didn't get applied?

Edit 3: Indeed, it didn't. Even worse, it doesn't seem to apply anymore. I give up - waiting 2 months isn't so bad after all

[Aphax]

What you are seeing is normally called "shadowfb" acceleration. The primary copy of the frame buffer is kept in system memory, where the CPU can access it really quickly. As the CPU updates portions of your screen, those portions are copied to the "real" frame buffer in video memory. For 2D acceleration it runs pretty much as fast as any acceleration hardware, and faster than some hardware.

Running "no-accel" is different -- the CPU is still doing all the drawing but it is drawing into video memory, where the accesses are much slower. This is why the performance is so different.

The real drawback of shadowfb is that you can't really use it with ANY hardware acceleration, ie it's not practical to have 2D accel done by shadowfb but have video and 3D acceleration done by hardware. It might be possible to make some kind of hybrid but nobody is doing it yet.

When all the HW vendors started dropping dedicated 2D acceleration blocks and using the 3D engine for 2D acceleration, some things (like EXA Render) got better while other things (XAA acceleration) got worse. I think you will see 2D hardware acceleration continue to improve over the next 6-12 months. Shadowfb will continue to be an annoying thorn in our sides as a reminder of what is possible for 2D-only on the CPU. Where the CPU falls down is where you get into computationally expensive things like video scaling and 3D acceleration -- there the 3D engine shines and can run rings around a typical CPU.

Thanks for the explanation That answers a bunch of questions I had about why 2D acceleration seems to be in such a state of flux at the moment. I'm looking forward to the day it's all properly done on the 3D hardware

[TASADAR-F]

Tearing is definitely still a problem though. Anyone know anything about that?

I have the same problem with fglrx,ati and radeonHD. In my 4670.

Last version of open source ati solve problem in r300,r400 and r500.

R600 (HD2000 and HD3000 series) and R700 (HD4000 series) will have wait to ati or radeonHD support XV output.

I hate the tears.

[russell_h]

Installed flawlessly for me. The only issue I've encountered so far is that sometimes, especially if I am skipping around or resizing the window, video playback (mplayer, xv) will just go black. Only way to fix it seems to be to restart mplayer.

Tearing is definitely still a problem though. Anyone know anything about that?

[gsacks]

Maybe you don't know that FF has like all common web browsers a built-in function to resize text when you hold ctrl + use mouse wheel?

Actually, no, I didn't know that, since I never needed that function before I built my HTPC. Thanks for the tip. That will come in handy. It isn't quite as smooth as using compiz zoom, and still does not allow me to quickly make the browser window fill the screen and then scroll it off to the side so I can work on another part of the desktop. (Yes, I do have multiple desktop screens). But I can definitely see myself using that feature sometimes. I will still maintain that composite can add to the user experience, but there are always many different ways to solve a task, and I guess composite desktops don't fit the bill for you. They do for me. So I look forward to a driver that will allow it to work better alongside GL apps. I agree that most of it is eye-candy, but there are a few key features that work well for me in my set-up. Can I live without them? Sure. Do I want to? No. Besides, what is wrong with eye candy, anyway. We could all still be using amber screen 24x80 text console displays. Wouldn't that be fun...

[bridgman]

I gave xf86-video-ati-6.10.0 a try the other day and noticed 2D was blitzing fast compared to fglrx; doing a 'dmesg' in xterm was now instanteneous (with fglrx I'd see it scroll text for a while), resizing gvim was superfast too (seems to do a lot of redrawing, more so than normal gtk+ apps), even the graphs rendered by gnome-system-monitor which are horribly slow on fglrx were smooth as butter on ati.

People in #radeon on freenode told me this is likely because my (C2D E8400) CPU which was now doing all the work because there was no 2D accel for r600+ chips. which I guess makes sense. So I then tried to see what performance was like with the NoAccel option set with fglrx, but that was really way worse :/

I'm not sure what the downsides are of having my CPU doing 2D as it is with xf86-video-ati, I tried it for a few days and didn't notice any other adverse effects other than playing video (understandably) using a lot more CPU time. I was especially happy about gvim, I use it a lot when I hack on code and faster scrolling and window manipulation (split screens etc.) really makes it much more pleasurable

What you are seeing is normally called "shadowfb" acceleration. The primary copy of the frame buffer is kept in system memory, where the CPU can access it really quickly. As the CPU updates portions of your screen, those portions are copied to the "real" frame buffer in video memory. For 2D acceleration it runs pretty much as fast as any acceleration hardware, and faster than some hardware.

Running "no-accel" is different -- the CPU is still doing all the drawing but it is drawing into video memory, where the accesses are much slower. This is why the performance is so different.

The real drawback of shadowfb is that you can't really use it with ANY hardware acceleration, ie it's not practical to have 2D accel done by shadowfb but have video and 3D acceleration done by hardware. It might be possible to make some kind of hybrid but nobody is doing it yet.

When all the HW vendors started dropping dedicated 2D acceleration blocks and using the 3D engine for 2D acceleration, some things (like EXA Render) got better while other things (XAA acceleration) got worse. I think you will see 2D hardware acceleration continue to improve over the next 6-12 months. Shadowfb will continue to be an annoying thorn in our sides as a reminder of what is possible for 2D-only on the CPU. Where the CPU falls down is where you get into computationally expensive things like video scaling and 3D acceleration -- there the 3D engine shines and can run rings around a typical CPU.

[storma]

See this thread:

http://www.phoronix.com/forums/showthread.php?t=14252&highlight=libatiadlxx.so

[Tares]

Anyone has solved the libatiadlxx.so problem ?