The AMD/ATI Bar & Grill

falconindy · 2010-09-13 01:52:09

Vi0L0 wrote:

I just talked with some archlinux project members and they told me that autofglrx daemon isn't bad. Ofcourse there could be better solution, but they didn't mention any.

I'm the supposed "some archlinux project members".

For clarifcation, I'm not an "archlinux project member". Please don't confuse the situation any further than you already have. I'm just a curious user, and I'd appreciate it if you wouldn't mince my words by removing them from their context. I mentioned several times that this is a ridiculous solution. I share Cyberpatrol's lengthy list of concerns and objections. Several times I stated that the better way to do this is by manual invocation after a kernel build. Before you again try to remind me that typing is for lazy people, I'd like to point out that Arch is not a distro tailored for those that are too "lazy" to type a few extra commands here and there.

Vi0L0 · 2010-09-13 16:46:02

falconindy wrote:

Vi0L0 wrote:
I just talked with some archlinux project members and they told me that autofglrx daemon isn't bad. Ofcourse there could be better solution, but they didn't mention any.
I'm the supposed "some archlinux project members".

Yes, you are all of them, and i am a Legion
Since you are so sure about it i think you should read again a log from sniffers/keyloggers you (apparently) installed on my systems.

cyberpatrol wrote:

Vi0L0 wrote:
I do understand you. You are right in some cases, and your posts here are useful.
I can see it's wasting system's resources (a little).
I can see it could be not so safe - that's why i asked for testing.
It's wasting system resources not only a little.
It's not that's not only not so safe, it can break and the user's compile options aren't set at this time. So the user probably get's a less performant module. And it can really break your system resp.

This is actually a good topic to talk about.
We should to look closer at fglrx module when we was moving hook into catalyst.
Because now when i'm looking at it i see that we made (a little) mistake.
Let me explain...

Most of users doesn't set any compile flags. Those flags aren't env vars at all until user (in our case root because you need root privilages to run catalyst_build_module) will set it (see your env vars with `printenv` command).
I'm not setting compile flags also.

So in my case (in most users cases) catalyst_build_module ISN'T using ANY compile flags (ofcourse except ati's own extraflags, and information provided by `uname`) - while in older pre-hook method those flags were taken from /etc/makepkg.conf by makepkg itself.

I also checked that forcing catalyst_build_module to use some CFLAGS (or CXXFLAGS btw) makes no difference in the module. ONLY forcing LDFLAGS (linker flags) is making little changes, but without any difference in funcionality or performance.

It's not a big case i guess since hook is working fine, and there were no complains from users.
Although i think i need to change it (and at least load flags from makepkg.conf).

Now as for a daemon...

(when not using own flags - so by default) I compared
- fglrx module built by daemon
with
- fglrx module built by 'catalyst_build_module' after logging

using vbindiff (from aur) - which is a simple hex editor able to compare binary files

and the ONLY difference is in information about where was fglrx_public.c file
placed during compilation - this information is simply different because
'catalyst_build_module' is using different directory in /tmp with every run.

So for most users module built with a daemon and with a hook is the same module.

And those who are using own flags will only have to add those flags into catalyst_build_module if they've got problems with a daemon.

Edit: oh and please, please, don't repeat your "20ms" mantra again... We already remembered it (it's good, yes, but ie. vedic's mantras are better)...

Last edited by Vi0L0 (2010-09-13 18:55:55)

ragnarok2040 · 2010-09-14 00:38:19

I can't say I like this method but that's not your fault. It's just the limitation of the system.

Any files created and installed using this method would be orphans, as far as pacman is concerned. It's also highly likely the build step might result in always failing on systems with custom kernels or such.

Also, the building process looks like it's run under root privileges. Any rogue command, that breaks out of its sandbox at that stage in a Makefile or script could be detrimental. It would suck especially if there's a "rm -r $UNDEFINED_VAR/*" lurking somewhere...

Maybe you can split the package up between catalyst, which just does the normal build/install, and catalyst-rebuild, which adds the rebuilding script and source files.

Vi0L0 · 2010-09-14 01:06:22

ragnarok2040 wrote:

I can't say I like this method but that's not your fault. It's just the limitation of the system.
Any files created and installed using this method would be orphans, as far as pacman is concerned. It's also highly likely the build step might result in always failing on systems with custom kernels or such.
Also, the building process looks like it's run under root privileges. Any rogue command, that breaks out of its sandbox at that stage in a Makefile or script could be detrimental. It would suck especially if there's a "rm -r $UNDEFINED_VAR/*" lurking somewhere...
Maybe you can split the package up between catalyst, which just does the normal build/install, and catalyst-rebuild, which adds the rebuilding script and source files.

Well... you are right.

I guess i will do such split:
- catalyst (module for stock kernel)
- catalyst-utils (libs and stuff)
- catalyst-hook, catalyst-daemon (rebuilding script and source files).

catalyst-utils because those who will use hook/daemon won't need catalyst.

I think dependencies should look like this:
catalyst <-> catalyst-utils <- catalyst-hook/daemon
catalyst-hook/daemon will provide (and replace) catalyst.

I'm just not sure when i will find time for this - i guess when 10.9 will appear.

Last edited by Vi0L0 (2010-09-14 02:22:19)

Berseker · 2010-09-14 10:29:07

Hi all guys

The last ATI Card I had was an old 9600, and the situation for that card was really bad.. switched to NVIDIA since then.

In the next days anyway I'm going to get an ASUS Mini ITX MB, model M4A88T-I-Deluxe (link) with an integrated 4350 videochip, and I'm going to use it for my HTPC. My question is very predictible and simple: does Vaapi support needs Catalyst drivers or I can go with the open one?

Surfing the net the answer seems to be the first one, but I'm asking also here just to be sure.

I will read some previous pages of this thread in order to understand the situation with Catalyst and so on (I knew from some friends running Ubuntu that often Catalyst force to mantain old versions of kernel and X server..)

Last edited by Berseker (2010-09-14 10:30:59)

Cdh · 2010-09-14 11:31:10

For features of the open source driver look here:
http://www.x.org/wiki/RadeonFeature
As you can see nothing has be done for vaapi.

Yes, catalyst is your only choice.

I don't understand what's the problem with new kernels. I have used catalyst since 10.4 and was always using the latest kernel and even 2.6.34-rcX kernels. It always worked with very, very little patches that Vi0L0 provided nearly instantly.

With X there is a problem:
catalyst did in fact work well with xorg 1.8 for a long time but it refused to when xorg reported that it was 1.8.
Now with 1.9 I am pretty positive that catalyst will support it very fast, because the next ubuntu version will have xorg 1.9 and ubuntu is officially supported by amd.

windscape · 2010-09-14 13:08:32

Berseker,

Based on my experience with an HTPC running Arch 64-bit with an integrated HD 3200 AMD/ATI chipset, you may not even need Vaapi to smoothly playback HD videos. The Athlon 64 X2 5200+ 2.7 GHz CPU with 2 GB of RAM in my HTPC is more than enough to smoothly playback 1080p H.264 videos without using hardware acceleration. I'm currently using the Catalyst drivers, since I'm not sure if the open-source ones can handle XBMC properly, but I might test them someday soon.

When I did try the git version of XBMC and hardware-accelerated playback using vaapi, I found that only videos encoded at Level 4.1 would play without artifacts.

Last edited by windscape (2010-09-14 13:09:48)

Berseker · 2010-09-14 14:42:19

I understand.. thank you both for your answers.

@windscape
I know that with these modern systems, you can watch full-hd videos without any issues (with the MB, an AM3 Athlon II X2 250 is coming): the video-accel thing was only for keeping power consumption, fan noise and temperatures low.

Anyway I'll try to use vaapi, and if it is unstable\causes glitches I will keep on temporarily on CPU-only playback.
I'm going to use XBMC too, but on an i686 system

Cdh · 2010-09-14 22:07:31

There are some video files that don't work properly with vaapi. But I have ever come across only two of them:
One is the mp4 Sintel Trailer:
http://durian.blender.org/download/
The divx Version works great...

Berseker · 2010-09-15 12:06:18

Vi0L0 wrote:

I'm just not sure when i will find time for this - i guess when 10.9 will appear.

according to this

http://twitter.com/CatalystMaker/statuses/24535328792

they're gonna to be released today - USA time

Vi0L0 · 2010-09-15 16:26:12

Berseker wrote:

Vi0L0 wrote:
I'm just not sure when i will find time for this - i guess when 10.9 will appear.
according to this
http://twitter.com/CatalystMaker/statuses/24535328792
they're gonna to be released today - USA time

Thanks

10.9 is available and i'm downloading it already from www2.ati.com/drivers/linux/ati-driver-i … x86_64.run

Edit: Release notes is here: www2.ati.com/drivers/linux/catalyst_109_linux.pdf.

- v-sync is working fine again
- xorg-server 1.9 is not supported
- looks like after quick tests theres no artifacts in firefox when using ATi 2D acceleration

Soon i will update aur (edit: done)
repo and wiki later

Last edited by Vi0L0 (2010-09-15 21:13:41)

yimm · 2010-09-15 16:41:09

For those using KDE4 with catalyst, have you got tricks for performance?
With or without kwin effects, I found that KDE is a little slow, and not reactive. I'm using direct2d.

Last edited by yimm (2010-09-15 17:07:09)

windscape · 2010-09-15 17:44:16

Cdh wrote:

There are some video files that don't work properly with vaapi. But I have ever come across only two of them:
One is the mp4 Sintel Trailer:
http://durian.blender.org/download/
The divx Version works great...

This would be an example of the issues with the vaapi implementation that AMD/ATI uses on Linux currently. I downloaded the 1080p, 720p, and 480p mp4 versions of that trailer. I examined each using MediaInfo. As it turns out, the 720p and 480p versions of the trailer will probably play back just fine using vaapi on AMD/ATI hardware because the 720p version was encoded using a High Profile at Level 3.1 and the 480p version was encoded using a High Profile at Level 3.0. The 1080p version, however, was encoded using a High Profile at Level 5.0.

On Windows 7 running XBMC, I found that any and all H.264/AVC videos played back just fine, regardless of the Level they were encoded at. I think this is because XBMC uses DxVA (DirectX Video Acceleration) or UVD2 on Windows and they don't have the limitations that vaapi does on Linux currently with AMD/ATI hardware. I should note that VDPAU on NVIDIA hardware on Linux does not have the limitations that vaapi on AMD/ATI hardware currently has.

Last edited by windscape (2010-09-15 18:13:00)

Cdh · 2010-09-15 19:06:10

That seems to be the difference:
divx, plays fine: Format profile : High@L4.0
mp4, block artifacts: Format profile : High@L5.0

Cdh · 2010-09-15 20:09:27

Vi0L0 wrote:

Edit: Release notes is here: www2.ati.com/drivers/linux/catalyst_108_linux.pdf.

I believe you wanted www2.ati.com/drivers/linux/catalyst_109_linux.pdf, not 108.
(Have you ever noticed that this release notes are written with Microsoft Word and converted to pdf with Acrobat Distiller 7.0.5 (Windows)?)

Vi0L0 · 2010-09-15 20:50:19

[catalyst] repo has been updated to 10.9

Edit: update it with:
pacman -Sy
pacman -Rd catalyst
pacman -S catalyst catalyst-utils

older repos, like [catalyst-10.6] [catalyst-10.7] and [catalyst-10.8], have been moved to:
http://catalyst.apocalypsus.net/repo/catalyst-archive

Wiki will be updated soon.

Plus i would like to repeat:

catalyst package has been splited between:
- catalyst (module for stock kernel26)
- catalyst-utils (libs and stuff)

and optional packages that provides automatic re-compilation:
- catalyst-hook (auto rebuilding script and source files)
- catalyst-daemon (auto rebuilding script and source files)

I know it's maybe less "user-friendly" but this split had to be done.

Cdh wrote:

Vi0L0 wrote:
Edit: Release notes is here: www2.ati.com/drivers/linux/catalyst_108_linux.pdf.
I believe you wanted www2.ati.com/drivers/linux/catalyst_109_linux.pdf, not 108.

Yes thanks, typo, i will fix it now

Cdh wrote:

(Have you ever noticed that this release notes are written with Microsoft Word and converted to pdf with Acrobat Distiller 7.0.5 (Windows)?)

Yes, hehe, i have seen it long time ago

Last edited by Vi0L0 (2010-09-15 21:00:52)

*vitali* · 2010-09-15 20:52:21

10.8-2 - > 10.9-1
error: failed to commit transaction (conflicting files)
catalyst-utils: /usr/lib/libatiuki.so.1 exists in filesystem
catalyst: /lib/modules/2.6.35-ARCH/video/fglrx.ko exists in filesystem
Errors occurred, no packages were upgraded.

Vi0L0 · 2010-09-15 20:58:20

*vitali* wrote:

10.8-2 - > 10.9-1
error: failed to commit transaction (conflicting files)
catalyst-utils: /usr/lib/libatiuki.so.1 exists in filesystem
catalyst: /lib/modules/2.6.35-ARCH/video/fglrx.ko exists in filesystem
Errors occurred, no packages were upgraded.

pacman -Rd catalyst
pacman -S catalyst catalyst-utils

DarksideEE7 · 2010-09-15 21:59:35

Vi0L0 wrote:

*vitali* wrote:
10.8-2 - > 10.9-1
error: failed to commit transaction (conflicting files)
catalyst-utils: /usr/lib/libatiuki.so.1 exists in filesystem
catalyst: /lib/modules/2.6.35-ARCH/video/fglrx.ko exists in filesystem
Errors occurred, no packages were upgraded.
pacman -Rd catalyst
pacman -S catalyst catalyst-utils

Yep, that's what I had to do. It also looks like we no longer have to use bin32-catalyst-utils. Now we have just catalyst-utils, which is nice.

So far I installed 10.9 on my x86_64 system with a 4870X2....so far nothing seems broken. I'm going to run the unigine-heaven benchmark and compare performance to the 10.8.

Also I wonder if we still need the xorg-server-catalyst-maxmimize-fix?

Another thing that should be mentioned is that catalyst_build_module is no longer used, which I found strange. I take it that the fglrx kernel module will always be compiled from now on?

Vi0L0 · 2010-09-15 22:25:55

DarksideEE7 wrote:

It also looks like we no longer have to use bin32-catalyst-utils. Now we have just catalyst-utils, which is nice.

No, not at all, catalyst-utils is providing just libs and utils for native architecture.
Older (not splitted) catalyst was providing both catalyst (fglrx module) and catalyst-utils (libs and utils) in one package.
You still need lib32-catalyst-utils if you wanna use 32-bit apps/games.

DarksideEE7 wrote:

Also I wonder if we still need the xorg-server-catalyst-maxmimize-fix?

I dunno, i'm not removing it from the repo because it's too early to tell that ATi 2D accel is always working.

DarksideEE7 wrote:

Another thing that should be mentioned is that catalyst_build_module is no longer used, which I found strange. I take it that the fglrx kernel module will always be compiled from now on?

catalyst_build_module and whole 'auto re-compilation' functionality has been removed from catalyst package. In the repo i will try to provide fglrx module for current kernel26 asap. If you want to use 'auto re-compilation' functionality you have to install catalyst-hook or catalyst-daemon.

ATM I am updating wiki with all those infos.

Last edited by Vi0L0 (2010-09-15 22:38:43)

Cdh · 2010-09-15 23:42:07

For me there are also no artifacts anymore. D2d feels GOOD.

Vsync does work but with vaapi it is still not 100%, even with vaapi:gl, still slight shifts. I also had to enable "doublebuffering" in smplayer to get the movie.

Some windows are slow in resizing with the xfwm compositor.
An example is meld with two larger documents. Without compositing resizing the window is very good, but with it kind of lags and doesn't react instantly.

ragnarok2040 · 2010-09-16 00:12:53

Thanks Vi0L0, . The separate catalyst package really helps when I need to upgrade my kernel.

The D2d acceleration is working for me also. Firefox renders fine. Compiz now runs with direct rendering, too. You no longer need a hardware accelerated compositing window manager to get tear free fullscreen flash video, as well.

There are a couple bugs for me, however.

Fullscreen flash in compiz, with direct or indirect rendering, flickers between the video framebuffer and a white framebuffer. It seems to be some sort of double-buffering code. I found a fix for it by enabling "Unredirect Fullscreen Windows" under "General Options", "General" tab. Without compiz, fullscreen flash runs fine, too.

If you switch fullscreen off at the wrong time, the main framebuffer gets replaced with the all white version. It's easily fixed by switching to a terminal and switching back to Xorg, (ctrl+alt f8, ctrl+alt f7). Seems to happen regardless if I'm running compiz or not, direct or indirect.

Vi0L0 · 2010-09-16 00:45:39

Hmm... on my kde 4.5 everything is working fine, even blur effect when v-sync is enabled.

As for me it's the best catalyst.

Wiki has been updated.

And I have got good news, as stated here:

Qaridarium wrote:

there are allready a beta 10.10 with xserver 1.9 support and there is a 10.11 beta.
in 20 days amd will push a 10.10 catalyst into the ubuntu 10.10 repo .

DarkFoss wrote:

Also a great score with Heaven 2.1 almost as good as Win 7 dx 11 normal tess.

edit:

ragnarok2040 wrote:

Thanks Vi0L0, .

You are welcome and thanks for a good tip.

ragnarok2040 wrote:

The separate catalyst package really helps when I need to upgrade my kernel.

It's also much easier to upload it on my slow connection.
Plus catalyst-utils will help users who aren't using kernel26 (because they don't need catalyst).

Last edited by Vi0L0 (2010-09-16 01:00:19)

DarksideEE7 · 2010-09-16 02:08:53

Vi0L0 wrote:

DarksideEE7 wrote:
It also looks like we no longer have to use bin32-catalyst-utils. Now we have just catalyst-utils, which is nice.
No, not at all, catalyst-utils is providing just libs and utils for native architecture.
Older (not splitted) catalyst was providing both catalyst (fglrx module) and catalyst-utils (libs and utils) in one package.
You still need lib32-catalyst-utils if you wanna use 32-bit apps/games.
DarksideEE7 wrote:
Also I wonder if we still need the xorg-server-catalyst-maxmimize-fix?
I dunno, i'm not removing it from the repo because it's too early to tell that ATi 2D accel is always working.
DarksideEE7 wrote:
Another thing that should be mentioned is that catalyst_build_module is no longer used, which I found strange. I take it that the fglrx kernel module will always be compiled from now on?
catalyst_build_module and whole 'auto re-compilation' functionality has been removed from catalyst package. In the repo i will try to provide fglrx module for current kernel26 asap. If you want to use 'auto re-compilation' functionality you have to install catalyst-hook or catalyst-daemon.
ATM I am updating wiki with all those infos.

All right, thanks for that info. I'll go ahead and install bin32-catalyst-utils. I don't really care to use the auto-recompilation. I'm using the Catalyst package from the AUR also. I don't really care if it auto-compiles or not, but I prefer to minimize the number of installed packages, especially from the AUR.

I ran the unigine-heaven benchmark and it's almost exactly the same score as my previous run....however I didn't run it at my native resolution last time (derp), so I was lesse GPU-bound than I would like.

Window resizing seems to be faster in KDE 4.5 with compositing enabled, which is very nice. So far so good!

I'm also going to test in Starcraft 2. Performance on the last driver was abysmal......

Last edited by DarksideEE7 (2010-09-16 02:26:37)

subzero316 · 2010-09-16 02:11:40

Flash player 64 bit Out.
Yaeeee!!!... About time Phew!...
http://labs.adobe.com/downloads/flashplayer10.html

Arch Linux

#2376 2010-09-13 01:52:09

Re: The AMD/ATI Bar & Grill

#2377 2010-09-13 16:46:02

Re: The AMD/ATI Bar & Grill

#2378 2010-09-14 00:38:19

Re: The AMD/ATI Bar & Grill

#2379 2010-09-14 01:06:22

Re: The AMD/ATI Bar & Grill

#2380 2010-09-14 10:29:07

Re: The AMD/ATI Bar & Grill

#2381 2010-09-14 11:31:10

Re: The AMD/ATI Bar & Grill

#2382 2010-09-14 13:08:32

Re: The AMD/ATI Bar & Grill

#2383 2010-09-14 14:42:19

Re: The AMD/ATI Bar & Grill

#2384 2010-09-14 22:07:31

Re: The AMD/ATI Bar & Grill

#2385 2010-09-15 12:06:18

Re: The AMD/ATI Bar & Grill

#2386 2010-09-15 16:26:12

Re: The AMD/ATI Bar & Grill

#2387 2010-09-15 16:41:09

Re: The AMD/ATI Bar & Grill

#2388 2010-09-15 17:44:16

Re: The AMD/ATI Bar & Grill

#2389 2010-09-15 19:06:10

Re: The AMD/ATI Bar & Grill

#2390 2010-09-15 20:09:27

Re: The AMD/ATI Bar & Grill

#2391 2010-09-15 20:50:19

Re: The AMD/ATI Bar & Grill

#2392 2010-09-15 20:52:21

Re: The AMD/ATI Bar & Grill

#2393 2010-09-15 20:58:20

Re: The AMD/ATI Bar & Grill

#2394 2010-09-15 21:59:35

Re: The AMD/ATI Bar & Grill

#2395 2010-09-15 22:25:55

Re: The AMD/ATI Bar & Grill

#2396 2010-09-15 23:42:07

Re: The AMD/ATI Bar & Grill

#2397 2010-09-16 00:12:53

Re: The AMD/ATI Bar & Grill

#2398 2010-09-16 00:45:39

Re: The AMD/ATI Bar & Grill

#2399 2010-09-16 02:08:53

Re: The AMD/ATI Bar & Grill

#2400 2010-09-16 02:11:40

Re: The AMD/ATI Bar & Grill

Board footer