Catalyst 9.2 Released, Still Fails To Deliver XvBA

[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

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?