Catalyst 9.2 Released, Still Fails To Deliver XvBA

[phoronix]

Phoronix: Catalyst 9.2 Released, Still Fails To Deliver XvBA

A day after the ATI Catalyst 9.2 driver update was issued for Windows, Catalyst 9.2 for Linux is now available. However, there really isn't much at all to see with this release...

http://www.phoronix.com/vr.php?view=NzA4MA

[gzahl]

No real changes :-/
Well maybe it is time to buy some other graphic card. i wish Intel would build motherboards with a IGP. :-(

[bulletxt]

What about this title:

Catalyst 9.2 Released: The NeverEnding Failure.


I also love this Known Issue that they state in their Release Notes:

"With some system configurations Catalyst Control Center may take up to 30 seconds to start."

I wonder how "dirty" is fglrx code. I think they can't handle the code anymore for how bad/messed up it is.

[Melcar]

CCC takes like 15sec. to load on my main machine (Intrepid 64bit), yet it loads instantly on my laptop (Intrepid 32bit). This only really started happening since 9.1 really. Go figure.

[dungeon]

Canabyst 1.0omega Released: HI! We are completely new dev team.

[Kano]

Well could not test yet, but there are 5 readded devices:
RADEON 9500 (RADEON 9500 4144)
RADEON 9600TX (RADEON 9600TX 4146)
RADEON 9700 PRO (RADEON 9700 PRO 4E44)
RADEON 9500 PRO / 9700 (RADEON 9500 PRO / 9700 4E45)
ATI MOBILITY RADEON 9600/9700 Series (M10-P 4E50)

Also the name changed from 9-1 to 9.2. Basically 8-x was used from 8-3 on... My script currently defaults to it.

[aaaantoine]

You guys are just ravenous. At least wait for the field tests to come in.

[oyvind]

More or less the same as 9.1, except:
* aticonfig now, for the first time, says that POWERplay is not supported by my GPU. Strangely, I've been using POWERplay for many fglrx-releases (via the old atieventsd method), but support is obviously completely gone now. Even more funny is that "Auto powerstates" still seems to be enabled by default, and this crashes X when I unplug AC. So I still need to do an "aticonfig --auto-powerstates=off" to get stable operation, even though the driver says POWERplay is unsupported with "aticonfig --lsp" !

Otherwise, much the same. XVideo still unusably slow with Compiz, works OK without.

A few positive points:
* General performance is obviously improved in the later Catalyst-releases, both 2D and 3D, it's never been this good before (if disregarding video). Easily noticable when using Compiz.
* Execpt for the problems mentioned above, the driver is stable, even if running Compiz and using suspend/resume.


--
ATI X1400 Radeon mobile, Ubuntu 8.10 x86.

[NSLW]

Funny drivers :) There is so much bugs and everybody waits and they only fix the minor things. Sixteen bug in 21 days it isn't even a one poor bug per day. There is only one i can say:

Choose nvidia, have no problems :D I did so, now it's you turn ...

[jonnycat26]

A few positive points:
* General performance is obviously improved in the later Catalyst-releases, both 2D and 3D, it's never been this good before (if disregarding video). Easily noticable when using Compiz.


I'm seeing *drastic* improvements with video playback using XV. I don't know if it applies across the board to all cards, but for me, it's dramatically better than 9.1. No more distortions and Xine doesn't flake out anymore.

Wow. Color me almost satisifed. :)

Edit: OpenGL apps + composite are still bad. Google earth still flickers like a candle if you've got desktop effects enabled in KDE4.

[oyvind]

Funny drivers :) There is so much bugs and everybody waits and they only fix the minor things. There is only one i can say:

Choose nvidia, have no problems :D I did so, now it's you turn ...

One cannot always choose that easily.. I have nvidia on some machines, and I'm very pleased with that. The ATI-card is in my work laptop, and it's a Lenovo that I really like, and I chose it because it's generally nice :) Also, Lenovo's nvidia-offerings were few and far apart at the time (couple of years ago, I guess).

However, life is not care-free with nVidia binary driver. Look at nvnews-forum, and you'll see quite a lot of people having problems with nvidia as well. I have another laptop with a nVidia GeForce Go 6600 in it, and only just now, with the latest 180.29-driver, and after quite a few years(!), are things working without any significant problem (except for VCs getting garbled beyond recognition when X initializes :D, and xrandr shows no available resolutions except flat panel native). Luck, if you can call it that, most definitely plays a role with nvidia-hw+Linux as well.

[oyvind]

I'm seeing *drastic* improvements with video playback using XV. I don't know if it applies across the board to all cards, but for me, it's dramatically better than 9.1. No more distortions and Xine doesn't flake out anymore.

Wow. Color me almost satisifed. :)

Cool 4 u :)

My main problem with XVideo is the general drop in performance in the later Catalyst-releases, and especially when using Compiz. I don't expect it to be perfect in Compiz, because I realize the current limitations in DRI framework and X, but at least AMD should be able to do as well as the open source alternatives. Maybe my GPU is getting too old for AMD to bother prioritizing it.

[bommelid]

I installed the leaked Catalyst 9.2 beta on 15th of january. This was before the official catalyst 9.1 was released. The version number of the files inside are fglrx_*_8.580_*.
The files inside the new catalyst 9.2 final are version 8.582.
Seams to be not so much progress. Don't know, what version number 9.1 was but I wonder what they do in over a month.

regards

[sundown]

Catalyst 9.2 Released, Still Fails To Deliver XvBA

Catalyst is generally a fail :)

[bridgman]

My main problem with XVideo is the general drop in performance in the later Catalyst-releases, and especially when using Compiz. I don't expect it to be perfect in Compiz, because I realize the current limitations in DRI framework and X, but at least AMD should be able to do as well as the open source alternatives. Maybe my GPU is getting too old for AMD to bother prioritizing it.

Oyvind, how would you summarize the performance difference :

- cpu util is higher so maxed out there ?

- seems like GPU is maxed out; gets slower when the playback window is bigger ?

- seems like something else is slow; CPU not maxed and speed doesn't change when playback window is bigger/smaller ?

My guess is that the problem is more related to your GPU being relatively small than to its age. We are reaching the point where it's getting difficult to make a single driver which takes full advantage of new hardware and doesn't overload older hardware (without making it essentially two different drivers duct-taped together).

AFAIK your X1400 is what we call an RV515 with 4 pixel shaders. The new fglrx video stack probably does more complex video processing than the code in the open source driver (to get better video quality) and the result is that the GPU is maxing out.

I'm not sure if there are any options in aticonfig or cccle for disabling video quality options but it would be worth checking. It would also be useful for someone with a high-end 5xx (same age but more shader power) to see how the recent drivers perform on their GPUs. I suspect that their video performance would be fine -- in which case the simpler shaders on the open source driver might be a better fit for your GPU.

[Qaridarium]

overall it works for me...

infobash -v3
Host/Kernel/OS "ass" running Linux 2.6.28-6-generic i686 [ sidux 2008-04 Πόντος - kde-lite - (200812222321) ]
CPU Info (1) AMD Engineering Sample 1024 KB cache flags( sse3 nx lm svm ) clocked at [ 2600.000 MHz ]
(2) AMD Engineering Sample 1024 KB cache flags( sse3 nx lm svm ) clocked at [ 2600.000 MHz ]
(3) Dual-Core AMD Opteron 8218 1024 KB cache flags( sse3 nx lm svm ) clocked at [ 1000.000 MHz ]
(4) Dual-Core AMD Opteron 8218 1024 KB cache flags( sse3 nx lm svm ) clocked at [ 1000.000 MHz ]
Videocard ATI RV710 [Radeon HD 4350] X.Org 1.4.2 [ 1920x1200@60.0hz ]
Network cards 2x Broadcom NetXtreme BCM5754 Gigabit Ethernet PCI Express
Processes 149 | Uptime 2:54 | Memory 394.2/3276.9MB | HDD ATA SAMSUNG SP2014N,ATA SAMSUNG HD103UJ Size 1200GB (92%used) | GLX Renderer ATI Radeon HD 4350 | GLX Version 2.1.8494 Release | Client Shell | Infobash v3.05


wine 1.1.15 and cat 9-2 has nice looking @ the aquamark3 benchmark first timt for me that a see aquamark on wine looks like on windows XP i think its looks better.

3dmark03 is broken by a wine bug (not cat bug) on wine 1.1.15 for me so i can't test this..

sauerbraten runs fast :-)

for me and for the future 9-3 beta has XvBA lib's so i can't unterstand why AMD don't drop 9-2 (8.582) and jump direktly to 8.592 (9-3beta)...

Yes Yes I'm not the AMD release manager..

[falloutboy]

I guess there's still no tear-free Xv with the 780g igp. I switched the mainboard to one with an 8200 nvidia igp a few weeks back, when they fixed the 2D sloooooowness with the new driver. Now I've got accelerated HD video playback with zero cpu usage in contrast to not being able to watch HD content at all, because I had to use opengl for video playback before, which was using so much cpu-time even on SD content

[oyvind]

Oyvind, how would you summarize the performance difference :

- cpu util is higher so maxed out there ?

- seems like GPU is maxed out; gets slower as I drag the window bigger ?

- seems like something else is slow; CPU not maxed and speed doesn't change when playback window is bigger/smaller ?

My guess is that the problem is more to do with your GPU being relatively small more than its age. AFAIK your X1400 is what we call an RV515 with 4 pixel shaders. The new fglrx video stack probably does more complex video processing than the code in the open source driver (to get better video quality) and the result is that the GPU is maxing out sooner. The corresponding GPU in the 6xx family has roughly 2x the shader power, and the corresponding 7xx has more than 4x.

I'm not sure if there are any options in aticonfig or cccle for disabling video quality options but it would be worth checking.

Thanks for the reply, here are some observations:
* Starting with Catalyst 8.12, I think something changed with XVideo (might be 8.11, cannot remember exactly). I suddenly noticed that when running my GPU with a lower powerstate, XVideo suffered greatly. I could not remember seeing that before. At the same release, power-state switching turned unstable, so I've stopped using it completely.

* Ever since Catalyst 8.12, XVideo has not been flickering in Compiz-environment, but performance is abysmal, especially when going fullscreen. It does *not* peg CPU, and something very weird is going on, so probably hits some kind of GPU-limitations. 2-3 FPS (!) and extreme jerking/tearing with mplayer+XV in fullscreen, a little better with VLC, but still far below 25 FPS (or whatever the FPS of the movie being played back). CPU usage is normal/low while video is jerking and stopping/starting like crazy. Sometimes X crashes (black screen + Xorg 100% CPU) when I run XV in fullscreen in Compiz.

XVideo in non-Compiz environment works much better, and doesn't seem more CPU demanding than before. But probably more GPU demanding (harder to tell really, other than the powerstate-hint).

* Playing back video with OpenGL is suddenly much better than it used to be with fglrx, and mplayer now plays normal movies (not super-duper HD) tear-free in fullscreen with OpenGL (Compiz+unredirect) smoothly. That is with the very same test-videos I use with XV (a 1024x576 25 FPS movie, and a 640x480 60 FPS movie).

* XVideo performance is window size dependent.

* The open source radeon driver is able to play back using XVideo in Compiz without a hitch, and has been so for a while (albeit, you have to enable EXA to get it working). I can see no quality difference between open source driver and fglrx' XV output.

* Even though my GPU is limited (I am aware of that and not expecting magic), something still seems odd/wrong with XVideo. As long as the open source driver can do it on the same hw, I'll continue to complain about it :D.

[oyvind]

<snip>
I'm not sure if there are any options in aticonfig or cccle for disabling video quality options but it would be worth checking. It would also be useful for someone with a high-end 5xx (same age but more shader power) to see how the recent drivers perform on their GPUs. I suspect that their video performance would be fine -- in which case the simpler shaders on the open source driver might be a better fit for your GPU.

Oh, and please do tell if you know of any options I can try to lower quality of XVideo to gain some performance back (if that turns out to be the issue). I currently don't use any special options in xorg.conf at all. Basically, the only things I've changed is "aticonfig --auto-powerstates=off" and I've lowered mipmapping-quality in CCC. I start with clean amdpcsdb every time I install a new Catalyst-release ...

[bridgman]

* Starting with Catalyst 8.12, I think something changed with XVideo (might be 8.11, cannot remember exactly). I suddenly noticed that when running my GPU with a lower powerstate, XVideo suffered greatly. I could not remember seeing that before. At the same release, power-state switching turned unstable, so I've stopped using it completely.

Yeah, we dropped in the first release of an all new video stack around that time.

* Ever since Catalyst 8.12, XVideo has not been flickering in Compiz-environment, but performance is abysmal, especially when going fullscreen. It does *not* peg CPU, and something very weird is going on, so probably hits some kind of GPU-limitations. 2-3 FPS (!) and extreme jerking/tearing with mplayer+XV in fullscreen, a little better with VLC, but still far below 25 FPS (or whatever the FPS of the movie being played back). CPU usage is normal/low while video is jerking and stopping/starting like crazy. Sometimes X crashes (black screen + Xorg 100% CPU) when I run XV in fullscreen in Compiz.

OK, that makes sense. Here's an interesting question -- did you ever play videos for any length of time under Compiz before ? The obvious reason for asking is that playing video under Compiz involves at least 2x the pixel pushing of video without Compiz. I'm obviously trying to figure out if the slow performance under Compiz is new, or if it was always slow but you never noticed because the flickering chased you away first :)

XVideo in non-Compiz environment works much better, and doesn't seem more CPU demanding than before. But probably more GPU demanding (harder to tell really, other than the powerstate-hint).

Yep.

* Playing back video with OpenGL is suddenly much better than it used to be with fglrx, and mplayer now plays normal movies (not super-duper HD) tear-free in fullscreen with OpenGL (Compiz+unredirect) smoothly. That is with the very same test-videos I use with XV (a 1024x576 25 FPS movie, and a 640x480 60 FPS movie).

Oh good :)

* XVideo performance is window size dependent.

OK, so that also points to a maxed-out GPU.

* The open source radeon driver is able to play back using XVideo in Compiz without a hitch, and has been so for a while (albeit, you have to enable EXA to get it working). I can see no quality difference between open source driver and fglrx' XV output.

Makes sense. I suspect that you're seeing the difference between hard-coded bicubic filtering with a helper texture on the open source drivers, vs. a more expensive but more flexible adaptive filter on fglrx. Not sure of that though... if it was the case I would expect you to see a quality difference on moving objects more than on fixed objects, FWIW.

* Even though my GPU is limited (I am aware of that and not expecting magic), something still seems odd/wrong with XVideo. As long as the open source driver can do it on the same hw, I'll continue to complain about it :D.

I would expect no less. Thanks ;)

[Odin]

I'm not sure if there are any options in aticonfig or cccle for disabling video quality options but it would be worth checking. It would also be useful for someone with a high-end 5xx (same age but more shader power) to see how the recent drivers perform on their GPUs. I suspect that their video performance would be fine -- in which case the simpler shaders on the open source driver might be a better fit for your GPU.
maybe i can check it on my mobility x1600. I know it's far away from being high-end, but it's faster than the x1400. :)

btw. need Support for X-Server 1.6 T_T

[oyvind]

OK, that makes sense. Here's an interesting question -- did you ever play videos for any length of time under Compiz before ? The obvious reason for asking is that playing video under Compiz involves at least 2x the pixel pushing of video without Compiz. I'm obviously trying to figure out if the slow performance under Compiz is new, or if it was always slow but you never noticed because the flickering chased you away first :)




Yes, you are right about this. The flickering didn't really appeal to me, so I never gave it a chance. It was probably just as slow, only now I'm actually able to see it. Or really, when flickering before, it didn't really involve Compiz, just fighting for the frame buffer ? Now it definitely involves Compiz, since video is transformed/composited properly.

In summary, your reply totally makes sense. Also wrt. to open source radeon driver using bicubic scaling. I remember seeing some of that while peeking into the source code and reverting a patch to radeon-GIT which broke tear-free XV on my hardware (a while back, now).

Anyway, thanks again for your replies.

[kkkk]

hi,
I can't load the fglrx module,
I get


fglrx: Unknown symbol firegl_interrupt_poll
fglrx: Unknown symbol firegl_interrupt_open
fglrx: Unknown symbol firegl_interrupt_release
fglrx: Unknown symbol firegl_interrupt_read
fglrx: Unknown symbol firegl_interrupt_write


with catalyst 9.1 I had no problem..
I have a custom kernel so I guess there are some kernel options I have to adjust...

P.S:

In compiling time I get:


WARNING: "firegl_interrupt_write" [/var/abs/local/cata91/catalyst/src/archive_files/common/lib/modules/fglrx/build_mod/fglrx.ko] undefined!
WARNING: "firegl_interrupt_read" [/var/abs/local/cata91/catalyst/src/archive_files/common/lib/modules/fglrx/build_mod/fglrx.ko] undefined!
WARNING: "firegl_interrupt_release" [/var/abs/local/cata91/catalyst/src/archive_files/common/lib/modules/fglrx/build_mod/fglrx.ko] undefined!
WARNING: "firegl_interrupt_open" [/var/abs/local/cata91/catalyst/src/archive_files/common/lib/modules/fglrx/build_mod/fglrx.ko] undefined!
WARNING: "firegl_interrupt_poll" [/var/abs/local/cata91/catalyst/src/archive_files/common/lib/modules/fglrx/build_mod/fglrx.ko] undefined!



edit:
ok, I've just recompiled the kernel and works fine :D

[Boerkel]

Can't use Xinerama anymore. (screen just gets black after starting xserver and nothing happens...) Without this option this release is useless for me...

[rotarychainsaw]

I am pleased with this release. It's not 100% but it shows progress.

XV under compiz almost works now. The only problem is that video is sized for the whole window's size, not the window minus player controls. Other than that though it was smooth. Hopefully video will be 100% under 9.3

[SyXbiT]

I think I can sum up ATI catalyst releases quite nicely.
And I'll do so by quoting Michael

"Hopefully next month ........"

Keep hoping and waiting guys. Meanwhile, I'm I sold my ATI and bought an nvidia

[RealNC]

Full of problems and bugs.

[storma]

I've seen an increase in FPS while playing savage 2. This is good. :)

EDIT: mythfrontend and opengl seem to be working nicely as well. gw

EDIT2: The FPS increase is unreliable, at times it will drop from 80 to 15 for no obvious reason.
mythfrontend only worked the once with opengl. From subsequent starts, it exhibits the same old bug of not displaying the menu change.

have experienced hardlocks when changing to a VT sometimes. My smooth sailing is over it seems.. :(

[hdas]

Why is it so big? Nvidia's 64-bit drivers that include 32-bit compat libs and pre-built kernel modules are around 20MB. I think they should hire one of the Damn Small Linux (or Puppy) devs to fit it under 50MB :D.

And seriously nobody, I say nobody, cares about xvba, especially when one talks about fglrx. It would be face-saving if they manage to implement even a half-functional vdpau before the radeon, radeonhd and intel guys do it in their sleep :D.

[storma]

Why is it so big? Nvidia's 64-bit drivers that include 32-bit compat libs and pre-built kernel modules are around 20MB. I think they should hire one of the Damn Small Linux (or Puppy) devs to fit it under 50MB :D.

Nvidia offer separate packages depending on what you want. Ati have bundled it all in one.

[jonnycat26]

Full of problems and bugs.

I'm going to have to agree.

XV playback may have improved, but wow.. I'm getting random freezes when X starts, random crashes when I restore applications in KDE, and all sorts of other random oddities. I've reinstalled the drivers twice, so I'm just not sure what's going on.

[King InuYasha]

Finally! With this release, my ATI Mobility Radeon 9600 (M10) works again in Ubuntu with fglrx! Though, it seems that it requires manual screen configuration instead of using Xorg's automatic detection. Now I won't be bothered anymore until the PCSX2 guys clean up their segfaulting in their Linux sources... But at least ZeroGS doesn't complain anymore :D

[LavosPhoenix]

So, the 780G has no improvements at all? Maybe AMD needs a class action suit to convince them to stop raping their customers. They have an implicit contract to get their hardware working properly. If they can't or won't do so, they should have to compensate all the customers that were provided the faulty graphics hardware, both for the hardware itself and the time wasted because of problems caused by their faulty drivers. If this means that they go bankrupt, then good riddance. Another company will eventuallyt take it's place in the market, likely nVidia after they've been given the right to manufacture x86 CPUs by Intel to keep up the x86 processor Duopoly.

[grantek]

XV under compiz almost works now. The only problem is that video is sized for the whole window's size, not the window minus player controls.
+1, I hope the devs are aware of it

[Moronix]

Fails to deliver XvBA? Buddy, it fails to deliver regular old Xv, being all shaky. I don't think Xv can be fixed unless they rewrite it, so I guess the verdict is out. This is like Windows releases: some version in the future will be the fix.

[nbi1]

For 64 bit lenny the kernel module builds ok, but fails to load:

flush_tlb_page

is missing.

C'mon guys this kind of crap shouldn't be happening. The fix doesn't look too difficult, but we shouldn't need to hack the code. :mad:

Fortunately the fix is quite trivial. For 64 bit edit arch/x86/kernel/tlb_64.c by adding "EXPORT_SYMBOL(flush_tlb_page);" (it is present in tlb_32.c so I'm guessing 32 bit systems aren't seeing this problem) right after the end of the flush_tlb_page function. Rebuild and install both kernel and fglrx module and voila, you're good to go.:cool:

Now if 9.2 actually yields any meaningful improvements that remains to be seen.

[nbi1]

Xv is still a disaster. OpenGL is marginally passable if the playback window isn't made too big.

[Heiko]

I managed to get it working:

- Ubuntu 8.04.2
- hybrid crossfire
- HD3450 and internal HD3200 (AMD 780G chipset)
- a monitor and my old analog TV connected to the HD3450

But...

I had to disconnect the TV when installing the driver and setting up crossfire. When that ran properly, I connected the TV and it ran properly as well.

Whenever I tried to install with the TV connected, my TV became my main monitor and after trying to setup crossfire I got booted into a black screen.

I also don't dare to touch the Catalyst control center, because it seems that as soon I do that, I am booting into black screens again.

These kind of problems are already in the driver since version 8.9 (changing overscan options of the TV, cause booting into a black screen). When will it be fixed? I'm running a default Ubuntu 8.04.2 installation. I didn't compile any kernels myself or whatsoever...

[baskin]

I cannot build the driver on fresh Debian Lenny installation.

.....
dpkg-shlibdeps: failure: couldn't find library libfglrx_gamma.so.1 needed by debian/fglrx-driver/usr/bin/fglrx_xgamma (its RPATH is '').
Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH.
dh_shlibdeps: command returned error code 512
make: *** [binary] Error 1
dpkg-buildpackage: failure: debian/rules binary gave error exit status 2
Removing temporary directory: fglrx-install.WNzDfC

Any hints?

[SavageX]

Good release for me so far: Kaffeine (Xine backend) didn't yet crash the machine with Xv output for me. Let's see if this is pure luck or if this nasty and longstanding bug is finally fixed.

[Boerkel]

I went back to 9.1 because of my issue with xinerama. I can't work with a big desktop where maximized window takes both of my screens.
I'm very sad about this, because xv got better with 9.2, but now i can't use it. :(

[grantek]

I went back to 9.1 because of my issue with xinerama. I can't work with a big desktop where maximized window takes both of my screens.
I'm very sad about this, because xv got better with 9.2, but now i can't use it. :(
Did you do an "aticonfig --initial" after installing 9.2?

[harishd]

Dont know if this is the right place to post, but doing so in all ignorance.

I installed the new driver hoping it would have support for geometry shaders. but glxinfo still does not show the presence of the GL_EXT_geometry_shader4 extension. When I tried a simple application with geometry shaders, the glProgramParameteriEXT() method is seg faulting.

Anyone knows if there is a way to get geometry shaders to work? any help is appreciated :)

(btw i have a HD4850 card)

[Boerkel]

Did you do an "aticonfig --initial" after installing 9.2?

No and yes. I didn't, but i tried now and it doesn't help.

[NeoBrain]

Okay, first impressions:
1. Well... I got used to the fact, that the driver is always increasing, so now wonder it's 80 MB now
2. Compiz "blur windows" effect still doesn't work
3. amdcccle starts fine and fast for me
4. Warcraft 3 runs just as slow (maybe 5 fps faster) as (than) with 9.1 after it decreased by 50% in January
5. Uhm... my xorg.log says the module was build on 4th February... Why has the driver been released that late then?
6. Just checking wether starting a second X server works now... At least it's listed in the known issues now! EDIT: okay, hardlock
7. Testing S2RAM with Compiz, too, now... That one has been in the known issues for quite some time now, though. EDIT: okay, corrupted+lookup (though I could still move my mouse)

By the way, for everyone who complains about no changes: This release has fixed that many bugs and added many other bugs I was confronted with to the known issues list, and I like that MUCH more than support for crossfire which breaks everything else.

[bulletxt]

Someone kill fglrx driver, please. He'll do a favour to humanity.

[storma]

My initial post was positive, unfortunately things have changed.

The FPS increase is unreliable, at times it will drop from 80 to 15 for no obvious reason.
mythfrontend only worked the once with opengl. From subsequent starts, it exhibits the same old bug of not displaying the menu change.

Have experienced hardlocks when changing to a VT sometimes. My smooth sailing is over it seems..

[jonnycat26]

Did you do an "aticonfig --initial" after installing 9.2?

No... were there radical enough changes between 9.1 and 9.2 to warrant this?

To be honest, I had seen the "X crash on startup" problem with 9.1, but it was a very random thing. With 9.2 it was more often that X crashed than it started up properly.

9.2 is basically unusuable for me at this point.

[Odin]

I've seen an increase in FPS while playing savage 2. This is good. :)
I haven't measured the result but I think I got an increase too.

Card: 4850/512MB

Did you do an "aticonfig --initial" after installing 9.2?
If he had previously installed 9.1 (or even an older one), this step is not necessary....AFAIK, please correct me if i'm wrong. ^^

[Melcar]

You perform --initial to load the module in xorg.conf (if it's already there it won't do anything). I don't know how you guys install the drivers, but when I do it I first completely uninstall the older ones (run the uninstall script and remove /etc/ati), rebuild and restart X, install the new drivers, and finally reboot. This I found to be the best way to go about installation.

[Odin]

If you don't remove the old one, you don't have to execute aticonfig...at least I did it like that and haven't got any problems. :/

[elsie]

Has anyone else experienced X crashing/system freezes with XV video playback?
Crashes computer everytime I go fullscreen. This happened to me on 9.1 and 9.2.
Doesn't make a difference if compiz is enabled, either way computer crashes every time I play a video.
I'm using ubuntu 8.04 and x1600 mobile.

[oyvind]

Has anyone else experienced X crashing/system freezes with XV video playback?
Crashes computer everytime I go fullscreen. This happened to me on 9.1 and 9.2.
Doesn't make a difference if compiz is enabled, either way computer crashes every time I play a video.
I'm using ubuntu 8.04 and x1600 mobile.

Same here. X1400 mobile. It seems AMD is forgetting about older/weaker cards wrt. video playback. They should provide a cheaper XV playback method in their driver for older gen cards. I really don't care if it's simpler and looks marginally worse than their fancy adaptive filtering, I just want it to work. Period. Also, I find it really funny to read this:
http://ati.amd.com/products/MobilityRadeonx1400/index.html

Especially the section about "Avivo™ video and display perfection" .. Ah, the irony.

[bridgman]

With respect, I don't think that page talks about running with the additional GPU overhead of a compositor layered on top of the video acceleration. Realistically, I think the open source drivers will probably become that "simpler option" for older/weaker cards running under a compositor.

I *think* the "Unredirect Fullscreen Windows" option should let the video accel code go straight to the front buffer and skip the extra overhead.

[Moronix]

With respect, I don't think that page talks about running with the additional GPU overhead of a compositor layered on top of the video acceleration. Realistically, I think the open source drivers will probably become that "simpler option" for older/weaker cards running under a compositor.

I *think* the "Unredirect Fullscreen Windows" option should let the video accel code go straight to the front buffer and skip the extra overhead.

There is Xv flicker without composite on older cards. It's unusual and happens with cpu spikes more. Xv implementation is extremely wobbly on that hardware. In fact, with composite on said cards, Xv won't even show so it's moot. I'm talking about things like the older Xpress series which worse yet doesn't seem like radeonhd will support properly.

[dungeon]

Why just ATI don't do one good drop on support for pre HD cards, that way fglrx could be much easier to maintain/develop?

[oyvind]

With respect, I don't think that page talks about running with the additional GPU overhead of a compositor layered on top of the video acceleration.

I *think* the "Unredirect Fullscreen Windows" option should let the video accel code go straight to the front buffer and skip the extra overhead.

Yes. That page talks about plain Windows XP, I would assume. Though the words are really shiny and HD is definitely part of them. I'm just venting and being bitter because of all the troubles I've had with Linux+fglrx over the last couple of years, most of the time in a non-composited environment :).

Unredirect-fullscreen is very quirky and moody, and does not always work (i.e. many things simply go fullscreen without being unredirected). This might be a Compiz-problem, but it's been like that for a long time.

[Melcar]

Why just ATI don't do one good drop on support for pre HD cards, that way fglrx could be much easier to maintain/develop?

Then people would complain why their +5yr. card is not supported anymore :). What I think they should do is offer support for pre-HD cards up to a certain release and then stop, with future driver release dropping said support and focusing on newer cards. That "legacy" driver should then only be updated so that it keeps working with newer kernels and xservers. If you still want new features on your ancient card, then look at the open source drivers or something (which is what I think people should do anyway).
Unfortunately, people are likely to also complain if such a thing were done, like when active support for pre-9500 cards was dropped... "why is my card not actively supported anymore?". People will never be happy with the driver.

[oyvind]

Why just ATI don't do one good drop on support for pre HD cards, that way fglrx could be much easier to maintain/develop?

Even though I am an owner of a pre-HD-era card, I would tend to agree with you. If support becomes more theoretical than real/practical, it would be better to officially drop it. And since AMD is doing many good things for open source development of drivers for their hardware, they can actually pull that off without too much grief. Give the open alternatives some more time to mature, and fglrx won't be necessary for older cards (hopefully:D).

[Moronix]

Then people would complain why their +5yr. card is not supported anymore :). What I think they should do is offer support for pre-HD cards up to a certain release and then stop, with future driver release dropping said support and focusing on newer cards. That "legacy" driver should then only be updated so that it keeps working with newer kernels and xservers. If you still want new features on your ancient card, then look at the open source drivers or something (which is what I think people should do anyway).
Unfortunately, people are likely to also complain if such a thing were done, like when active support for pre-9500 cards was dropped... "why is my card not actively supported anymore?". People will never be happy with the driver.

What a load of bollocks. It would be perfectly sufficient to release a single driver that runs all the capabilities of the card and the feature software that existed at it's release, this that you propose Nvidia has done for a long time already. This is not something that has been done ever in fglrx. So don't try to blame the users for having bought them at one point. They're not the ones who implied a fully working driver would exist either.

[Melcar]

What a load of bollocks. It would be perfectly sufficient to release a single driver that runs all the capabilities of the card and the feature software that existed at it's release, this that you propose Nvidia has done for a long time already. This is not something that has been done ever in fglrx. So don't try to blame the users for having bought them at one point. They're not the ones who implied a fully working driver would exist either.


Did you even read or are just randomly venting?

[oyvind]

<snip>
Realistically, I think the open source drivers will probably become that "simpler option" for older/weaker cards running under a compositor.
<snip>

Yep, I hope so. And that's not a bad solution at all, considering that documentation is available and progress seems to be good.

[jonnycat26]

Has anyone else experienced X crashing/system freezes with XV video playback?
Crashes computer everytime I go fullscreen.

Same here... hard crash when I take an XV video to fullscreen.

[rotarychainsaw]

I'm getting a hard crash when turning compiz off... Usually I do this to start up a game, so it is quite a PITA right now.

[bridgman]

rotarychainsaw, if you "unredirect fullscreen windows" in the Compiz options then run your game fullscreen *without* stopping Compiz do you still get the crash ?

[rotarychainsaw]

No I can run the games with compiz on, its just that I have noticed that I usually take a FPS hit (which shouldn't happen I would think). Also issues with compiz and fullscreen windows when a notification bubble pops up and stuff like that.

[storma]

I'm getting a hard crash when turning compiz off... Usually I do this to start up a game, so it is quite a PITA right now.

I'm getting that as well though not 100% of the time but close to.
Also happens when I want to drop back to a VT or switch to one, again not 100% but close to.

[storma]

The FPS increase is unreliable, at times it will drop from 80 to 15 for no obvious reason.

It seems this occurs from enabling AA ingame, turning AA off, things have smoothed out again.

[JeanPaul145]

Has anyone else experienced X crashing/system freezes with XV video playback?
Crashes computer everytime I go fullscreen. This happened to me on 9.1 and 9.2.
Doesn't make a difference if compiz is enabled, either way computer crashes every time I play a video.
I'm using ubuntu 8.04 and x1600 mobile.

I also get hard crashes when watching a fullscreen vid, but only when compiz is enabled though. In this regard, the recent improvements haven't really really improved anything for me at all: when I was using fglrx 8.10, videoplayback would flicker when using compiz, so I would turn it off then too. The main difference is that it didn't used to lock up, so right now, one mistake (forgetting to turn off compiz when watching a video) and it's off to rebootland...
I'm using a Radeon HD4870 with 1 GB of GDDR5 on Ubuntu Intrepid AMD64 here.


I'm also wondering (q for the AMD devvers): once Gallium3D goes stable in Mesa, will fglrx be switching to support it (and DRI2, etc etc) instead of the old driver arch? and if so, what time do you guys see youselves involving yourselves with it?

[bridgman]

JeanPaul145, same question; do you have "unredirect fullscreen windows" checked ? Could you try both settings (checked, unchecked) ?

We moved our OpenGL driver onto an architecture similar to Gallium3D a couple of years ago (based around our proprietary IL rather than TGSI), so no plans to change there.

On the open source side we plan to jump across to Gallium3D pretty soon, but we want to get the "classic mesa" implementation running at 5xx level first. That code will be needed for distros which aren't running with DRI2, KMS and GEM; KMS is coming along well but it will be at least a year before all the major distros move over to use it.

We could implement a Gallium3D-based Mesa that didn`t need DRI2 and GEM, of course, but nobody seems to think that would be a good use of time.

[bridgman]

There is Xv flicker without composite on older cards. It's unusual and happens with cpu spikes more. Xv implementation is extremely wobbly on that hardware. In fact, with composite on said cards, Xv won't even show so it's moot.

Xv should be flicker-free and tear-free with radeon these days. I`m hoping you`re talking about fglrx re: flicker...

I'm talking about things like the older Xpress series which worse yet doesn't seem like radeonhd will support properly.

It`s not a matter of `supporting it properly`, there are no plans to support pre-5xx in radeonhd at all. The modesetting hardware is completely different on the older chips, and nobody sees any benefit to porting the pre-5xx modesetting and acceleration code across from radeon.

[JeanPaul145]

JeanPaul145, same question; do you have "unredirect fullscreen windows" checked ? Could you try both settings (checked, unchecked) ?

We moved fglrx to a driver model like Gallium3D a couple of years ago, so no plans to change there. On the open source side we plan to jump across to Gallium3D pretty soon; we want to get the "classic mesa" implementation running at 5xx level first, for the distros which aren't running with DRI2, KMS and GEM.

We could make a version of Gallium3D which doesn't need DRI2 and GEM, but that doesn't seem like a good use of time.

Well right now I've found that the "undirect fullscreen windows" checkbox in the compiz manager is set to enabled (before changing anything), so that's problematic for sure. I'll try it with the check disabled and edit this post then.

EDIT: watching a video with the "undirect fullscreen windows" checkbox disabled SEEMS to go without lockups.
I haven't had any so far anyway :)
Could you give me an explanation why this is?
(curiousity killed the cat, but I'm just so very catlike in this regard :P)

[bridgman]

I can never remember whether checked or unchecked is what changes the behavior, so I can`t give you a full answer yet.

Normally when running under a compositing manager the Composite extension is used which allows the output of the application to be redirected to an offscreen buffer, then Compiz combines all those offscreen buffers into a single desktop image.

The checkbox allows you to alter that behaviour when an app is running full screen (which would block all the other apps anyways) -- rather than drawing to an offscreen buffer the app is allowed to draw directly to the screen.

The crash could be happening when the window switches from being redirected to *not* being redirected, or it could be crashing when the app switches to fullscreen *while* redirected -- in order to know which I need to remember which checkbox setting really unredirects :confused:

Since there was also at least one report about crashing when exiting Compiz I suspect there might be a problem with unredirecting, ie telling the app "stop drawing to an offscreen buffer and start drawing directly to the screen again".

[susikala]

Hm, since many people complain about xv, why don't you use radeon? It's as bridgman said, flicker- and tearfree, and it's a joy to watch 1080p videos with it (on an onboard HD3200, which isn't the fastest GPU on earth). The driver's also in my experience _very_ stable to use, even though it's still marked as experimental. Never hangs, no corruption, everything's fast. At least, it's more stable for me than Catalyst ever was.

I use XFCE, and it works flawlessly even with compositing enabled (I haven't checked if performance suffers, but the picture still looks awesome). No idea about Compiz.

So if you mainly watch video, there's a very good alternative with the FOSS drivers.

There are some helpful instructions how to compile and use both FOSS drivers at:

http://xorg.freedesktop.org/wiki/radeon:r6xx_r7xx_branch
http://xorg.freedesktop.org/wiki/radeonhd:r6xx_r7xx_branch

Now I understand if people had reasons to complain previously when Catalyst was the only option and they were more or less _forced_ to use it to watch HD video, and even then tearfree only over opengl, which is very CPU-intensive and quite beats the point. But cut ATI/AMD some slack here for their hard work, the FOSS drivers are already _now_ great and they're improving at a tremendous rate. There's no doubt at all that AMD is the future of graphics on GNU/Linux.

[rahman.duran]

Hm, since many people complain about xv, why don't you use radeon? It's as bridgman said, flicker- and tearfree, and it's a joy to watch 1080p videos with it (on an onboard HD3200, which isn't the fastest GPU on earth). The driver's also in my experience _very_ stable to use, even though it's still marked as experimental. Never hangs, no corruption, everything's fast. At least, it's more stable for me than Catalyst ever was.

I use XFCE, and it works flawlessly even with compositing enabled (I haven't checked if performance suffers, but the picture still looks awesome). No idea about Compiz.

So if you mainly watch video, there's a very good alternative with the FOSS drivers.

There are some helpful instructions how to compile and use both FOSS drivers at:

http://xorg.freedesktop.org/wiki/radeon:r6xx_r7xx_branch
http://xorg.freedesktop.org/wiki/radeonhd:r6xx_r7xx_branch

Now I understand if people had reasons to complain previously when Catalyst was the only option and they were more or less _forced_ to use it to watch HD video, and even then tearfree only over opengl, which is very CPU-intensive and quite beats the point. But cut ATI/AMD some slack here for their hard work, the FOSS drivers are already _now_ great and they're improving at a tremendous rate. There's no doubt at all that AMD is the future of graphics on GNU/Linux.


So what kind of CPU do you have? Becouse it is nothing to do with XV, there is no acceleration for hd content on amd/ati side neither on fglrx nor foss drivers. It is completely CPU related to play hd videos. So I can't play 1080p videos on my x2 4000+ CPU without frame drops. So if you don't have a fast enough CPU you can't play any hd content both on fglrx and radeon/radeonhd drivers.

[hpestilence]

Hmm, I just realized that the glsl 1.3 spec requires new opengl minimal max limits, are these in the driver somewhere?

//
// Implementation dependent constants. The example values below
// are the minimum values allowed for these maximums.
//
const int gl_MaxTextureUnits = 16;
const int gl_MaxVertexAttribs = 16;
const int gl_MaxVertexUniformComponents = 1024;
const int gl_MaxVaryingFloats = 64; // Deprecated
const int gl_MaxVaryingComponents = 64;
const int gl_MaxVertexTextureImageUnits = 16;
const int gl_MaxCombinedTextureImageUnits = 16;
const int gl_MaxTextureImageUnits = 16;
const int gl_MaxFragmentUniformComponents = 1024;
const int gl_MaxDrawBuffers = 8;
const int gl_MaxClipDistances = 8;
//
// The following are deprecated.
//
const int gl_MaxClipPlanes = 8; // deprecated
const int gl_MaxTextureCoords = 8; // deprecated

[JeanPaul145]

Hm, since many people complain about xv, why don't you use radeon? It's as bridgman said, flicker- and tearfree, and it's a joy to watch 1080p videos with it (on an onboard HD3200, which isn't the fastest GPU on earth). The driver's also in my experience _very_ stable to use, even though it's still marked as experimental. Never hangs, no corruption, everything's fast. At least, it's more stable for me than Catalyst ever was.

I use XFCE, and it works flawlessly even with compositing enabled (I haven't checked if performance suffers, but the picture still looks awesome). No idea about Compiz.

So if you mainly watch video, there's a very good alternative with the FOSS drivers.

There are some helpful instructions how to compile and use both FOSS drivers at:

http://xorg.freedesktop.org/wiki/radeon:r6xx_r7xx_branch
http://xorg.freedesktop.org/wiki/radeonhd:r6xx_r7xx_branch

Now I understand if people had reasons to complain previously when Catalyst was the only option and they were more or less _forced_ to use it to watch HD video, and even then tearfree only over opengl, which is very CPU-intensive and quite beats the point. But cut ATI/AMD some slack here for their hard work, the FOSS drivers are already _now_ great and they're improving at a tremendous rate. There's no doubt at all that AMD is the future of graphics on GNU/Linux.

First off: I've got the "undirect fullscreen windows" checkbox set to disabled since my last post (the default is enabled) but now I;ve found it is still a possibility that it makes the system hang. next to that, the fullscreen vid will start to jitter etc.

So I want to try the FOSS experimental branch.
Only, I get a make error. First, the last couple of lines of the autogen output (which goes fine btw):

config.status: creating Makefile
config.status: creating man/Makefile
config.status: creating src/Makefile
config.status: creating utils/conntest/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands

NOTE: DRI support is disabled



Next the make output.This is where things go wrong:

j@Brutus:~/git_clones/xf86-video-radeonhd$ make
make all-recursive
make[1]: Entering directory `/home/j/git_clones/xf86-video-radeonhd'
Making all in src
make[2]: Entering directory `/home/j/git_clones/xf86-video-radeonhd/src'
/bin/bash ../git_version.sh -k -s .. -o git_version.h
git_version.sh: Output is unchanged, keeping git_version.h
make all-am
make[3]: Entering directory `/home/j/git_clones/xf86-video-radeonhd/src'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -I/usr/include/xorg -I/usr/include/pixman-1 -Wall -Wextra -Wno-unused-parameter -Werror-implicit-function-declaration -Wstrict-aliasing -Wstrict-overflow -Wpointer-arith -Woverlength-strings -Wvolatile-register-var -Winit-self -Wbad-function-cast -Wstrict-prototypes -Wold-style-definition -Wnested-externs -Wdisabled-optimization -pedantic -Wno-long-long -Wno-variadic-macros -g -O2 -finline-functions -MT radeonhd_drv_la-rhd_driver.lo -MD -MP -MF .deps/radeonhd_drv_la-rhd_driver.Tpo -c -o radeonhd_drv_la-rhd_driver.lo `test -f 'rhd_driver.c' || echo './'`rhd_driver.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -I/usr/include/xorg -I/usr/include/pixman-1 -Wall -Wextra -Wno-unused-parameter -Werror-implicit-function-declaration -Wstrict-aliasing -Wstrict-overflow -Wpointer-arith -Woverlength-strings -Wvolatile-register-var -Winit-self -Wbad-function-cast -Wstrict-prototypes -Wold-style-definition -Wnested-externs -Wdisabled-optimization -pedantic -Wno-long-long -Wno-variadic-macros -g -O2 -finline-functions -MT radeonhd_drv_la-rhd_driver.lo -MD -MP -MF .deps/radeonhd_drv_la-rhd_driver.Tpo -c rhd_driver.c -fPIC -DPIC -o .libs/radeonhd_drv_la-rhd_driver.o
In file included from rhd_driver.c:121:
r6xx_accel.h:4:21: error: xf86drm.h: No such file or directory
In file included from rhd_driver.c:121:
r6xx_accel.h:54: error: expected specifier-qualifier-list before ‘drmBufPtr’
r6xx_accel.h:57:5: warning: C++ style comments are not allowed in ISO C90
r6xx_accel.h:57:5: warning: (this will be reported only once per input file)
make[3]: *** [radeonhd_drv_la-rhd_driver.lo] Error 1
make[3]: Leaving directory `/home/j/git_clones/xf86-video-radeonhd/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/j/git_clones/xf86-video-radeonhd/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/j/git_clones/xf86-video-radeonhd'
make: *** [all] Error 2
j@Brutus:~/git_clones/xf86-video-radeonhd$



So what gives? What am I doing wrong? I have a Radeon HD4780 if it matters.

[rahman.duran]

@JeanPaul145

Which distro are you on? you have to install xserver-sdk package. On opensuse it is xorg-x11-server-sdk. I don't know what other ditros name this package.

[JeanPaul145]

@JeanPaul145

Which distro are you on? you have to install xserver-sdk package. On opensuse it is xorg-x11-server-sdk. I don't know what other ditros name this package.

I'm using Ubuntu Intrepid AMD64. I think the package there is called xserver-xorg-dev, but I already have that installed.

[rahman.duran]

I'm using Ubuntu Intrepid AMD64. I think the package there is called xserver-xorg-dev, but I already have that installed.

Nope, the dev package is different. You need sdk package.

[JeanPaul145]

Nope, the dev package is different. You need sdk package.

Then I'm starting to think it simply isn't present in the repo's. There certainly isn't a single package which has xserver,m or xorg, combined with sdk in the name.
Any idea where I can get a version compatible with my installed x.org version?

[rahman.duran]

Then I'm starting to think it simply isn't present in the repo's. There certainly isn't a single package which has xserver,m or xorg, combined with sdk in the name.
Any idea where I can get a version compatible with my installed x.org version?

I dont know how ubuntu developers packaged them but on opensuse the -dev package contains header files that needed to compile X apps. The sdk package contains stuff for driver development. My be you should ask this on #radeonhd irc cahnnel.

[susikala]

So what kind of CPU do you have? Becouse it is nothing to do with XV, there is no acceleration for hd content on amd/ati side neither on fglrx nor foss drivers. It is completely CPU related to play hd videos. So I can't play 1080p videos on my x2 4000+ CPU without frame drops. So if you don't have a fast enough CPU you can't play any hd content both on fglrx and radeon/radeonhd drivers.

I have a Phenom 9550, so 2.2GHz each core. Quite below what you normally need for 1080p (> 3 GHz). There are _some_ 1080p videos where I either have to resort to framedropping or use ffmpeg-mt, but only with the really killer bitrates (or on some cases where audio lags behind, and that's really a CPU issue). Most 1080p actually _works_ for me. Which it has never with (teary) xv or (nonteary) opengl on Catalyst. So it's most definitely a driver issue.

[rahman.duran]

I have a Phenom 9550, so 2.2GHz each core. Quite below what you normally need for 1080p (> 3 GHz). There are _some_ 1080p videos where I either have to resort to framedropping or use ffmpeg-mt, but only with the really killer bitrates (or on some cases where audio lags behind, and that's really a CPU issue). Most 1080p actually _works_ for me. Which it has never with (teary) xv (nonteary) or opengl on catalyst. So it's most definitely a driver issue.

I know tearing is driver related. I have hd3200 igp and using radeonhd r6xx-r7xx brunch. And I am quite pleased with the xv performance. I didnt mean to say anything about tearing, all I wanted to say, xv has nothing to do to watch 1080p hd videos.

[rahman.duran]

Then I'm starting to think it simply isn't present in the repo's. There certainly isn't a single package which has xserver,m or xorg, combined with sdk in the name.
Any idea where I can get a version compatible with my installed x.org version?

You can check if xutils-dev makes the trick.

[JeanPaul145]

You can check if xutils-dev makes the trick.

Unfortunately, it doesn't. I already had it installed, but I reinstalled it and tried again. Alas, no succes.

EDIT:
The package I needed is called libdrm-dev. I never would've thought of that...

[susikala]

I know tearing is driver related. I have hd3200 igp and using radeonhd r6xx-r7xx brunch. And I am quite pleased with the xv performance. I didnt mean to say anything about tearing, all I wanted to say, xv has nothing to do to watch 1080p hd videos.

Well, there is the rudimentary difference that with Xv, scaling is handled by the GPU and not by the CPU (if I understand it correctly, correct me if I'm wrong). So some processing power is still offloaded to the GPU.

[susikala]

Unfortunately, it doesn't. I already had it installed, but I reinstalled it and tried again. Alas, no succes.

I use the same platform. Do you have xorg-dev installed too?

[rahman.duran]

Well, there is the rudimentary difference that with Xv, scaling is handled by the GPU and not by the CPU (if I understand it correctly, correct me if I'm wrong). So some processing power is still offloaded to the GPU.

You are right about scaling. But as I have 1920x1200 lcd the video out doesn't need to be scaled. Scaling is important is you are watching small res videos on hd lcd, maybe. Am I wrong?

[susikala]

You are right about scaling. But as I have 1920x1200 lcd the video out doesn't need to be scaled. Scaling is important is you are watching small res videos on hd lcd, maybe. Am I wrong?

1080p (1920x1080) would still be lightly scaled-up on your monitor. :)

[rahman.duran]

1080p (1920x1080) would still be lightly scaled-up on your monitor. :)


Nope, there are black borders on top and bottom :)

[susikala]

Nope, there are black borders on top and bottom :)

Isn't that already a player issue? You can define the ratio in mplayer etc.

[rahman.duran]

Unfortunately, it doesn't. I already had it installed, but I reinstalled it and tried again. Alas, no succes.

EDIT:
The package I needed is called libdrm-dev. I never would've thought of that...

Cool :)

[rahman.duran]

Isn't that already a player issue? You can define the ratio in mplayer etc.

Nope, this is normal. My lcd is 1200px tall not 1080px :) if you want it to fit entire screen than it will strech up. There will be black border even you have a 1920x1080 lcd because it depends on the movies aspect ratio and most of them are below 16:9. For example I have a pixar animated trailer is 1920x1080 res which will fit on hd tvs perfectly, and X-men trailer in 1920x816 that you will have black borders on eiher 1200px or 1080px display.

So, It doesnt mean all 1080p vidoes will fit perfect on 1080p displays.

[susikala]

Nope, this is normal. My lcd is 1200px tall not 1080px :) if you want it to fit entire screen than it will strech up. There will be black border even you have a 1920x1080 lcd because it depends on the movies aspect ratio and most of them are below 16:9. For example I have a pixar animated trailer is 1920x1080 res which will fit on hd tvs perfectly, and X-men trailer in 1920x816 that you will have black borders on eiher 1200px or 1080px display.

So, It doesnt mean all 1080p vidoes will fit perfect on 1080p displays.

I meant you could tell your player to stretch the video to fit the screen. And a 1920x816 video shouldn't be 1080p. XD 1080p is always 1080 vertical lines, with implied aspect ratio of 16:9, so 1920x1080.

[rahman.duran]

I meant you could tell your player to stretch the video to fit the screen.

If you strech it will look bad like egg headed people :)

And a 1920x816 video shouldn't be 1080p. XD 1080p is always 1080 vertical lines, with implied aspect ratio of 16:9, so 1920x1080.

Tell this to movie studios :)

[bugmenot]

I had to go back to 9.1 because the "black borders" workaround (aticonfig --set-dispattrib=tmds2i,positionX:0 etc.) for 1920x1080 stopped working. Xrandr now says "DFP2" instead of previous "default", and trying to set tmds2i dispattribs with aticonfig ends in error. Doing --query functions I figured out aticonfig now would recognize "dfp" output, but nevertheless I cannot set display attributes for any display name I can think of.

Using HD 3450, HDMI-over-DVI and having the famous underscan (and following hang if you don't reset to amdpcsdb defaults every time you logout) problem. Setting display attributes at every login works with 9.1.
Quite a mess.

If anyone knows how to set the parameters in 9.2, let us know.

[JeanPaul145]

I use the same platform. Do you have xorg-dev installed too?

Yep. As I posted earlier (I edited a previous post) libdrm-dev was needed. Now I can compile, make and make install both the drm and the driver modules properly.

However, when I set the Driver in the Device section to "radeonhd", all I get is a garbled screen.

next to the

Option "AccelMethod" "exa" # default shadowfb
Option "DRI" "on"


options in the xorg.conf file, are there any other settings of interest for a radeon hd 4870?

[rahman.duran]

Yep. As I posted earlier (I edited a previous post) libdrm-dev was needed. Now I can compile, make and make install both the drm and the driver modules properly.

However, when I set the Driver in the Device section to "radeonhd", all I get is a garbled screen.

next to the

Option "AccelMethod" "exa" # default shadowfb
Option "DRI" "on"


options in the xorg.conf file, are there any other settings of interest for a radeon hd 4870?

can you pastebin your xorg.0.log ?

[JeanPaul145]

can you pastebin your xorg.0.log ?

here are the xorg.0.log (http://pastebin.com/m57555410) and xorg.0.log.old (http://pastebin.com/m1da4c20b) (I don't know if the logfile is wiped clean after a reboot, but I imagine it is).

here id the xorg.conf I used (I left out a big block of comments, but that shouldn't matter):


Section "Device"
Identifier "Configured Video Device"
Driver "radeonhd"
Option "AccelMethod" "exa" # default shadowfb
Option "DRI" "on"
EndSection



I'll reboot, reproduce the error, and then, before I reboot again, I'll pastebin those logs.

EDIT: I rebooted and looked at the logs. It seems that at the time radeonHD is supposed to be loaded, it thinks that fglrx is already loaded. It is true I have fglrx installed, but I always thought the loading process was done by xorg.conf.
So I'll uninstall fglrx and try again.