Radeon GLAMOR vs. Radeon EXA vs. Catalyst On X.Org Server 1.17

[zanny]

I just have the Arch mainline packages installed - their Mesa 10.5.1 does not ship with gallium_drv_video / r600_drv_video / radeonsi_drv_video, and none of the main repo packages provide any of them according to pkgfile. I'll put it on my todo list to try it whenever they enable the vaapi tracker on Gallium in the stable packages, though.

Like I said, I really don't care if I have hardware accelerated h264 or not since I have an i7 that barely uses 4% cpu to decode 60 fps 1080p anyway, and hardware accelerated video is just a huge insane horrible mess (is anyone ever going to just adopt openmax for encode / decode and be done with it?) that I'd rather not bother trying anymore.

[Gusar]

I just have the Arch mainline packages installed - their Mesa 10.5.1 does not ship with gallium_drv_video / r600_drv_video / radeonsi_drv_video, and none of the main repo packages provide any of them according to pkgfile.

libva-mesa-driver is the package you want. Then you need to create a r600 or radeonsi symlink like V10lator explains, or you export LIBVA_DRIVER_NAME=gallium

However, the video pipelines in browsers are totally not ready for hardware decoding, so you won't gain anything but troubles. It only makes sense to use hardware decoding with dedicated players. mpv being the best at this I'd say.

But vdpau (or vdpau as a vaapi backend) for radoensi on a 290 is definitely completely broken on Arch.

Even with mpv? You could test both vdpau and vaapi with mpv. Not via any wrappers, but using the specific API directly ("--hwdec=vdpau --vo=vdpau" or "--hwdec=vaapi --vo=vaapi"). To get vdpau, the package is mesa-vdpau.

is anyone ever going to just adopt openmax for encode / decode and be done with it?) that I'd rather not bother trying anymore.

Openmax is a *far* bigger mess than VAAPI or VDPAU. There's no standards library (in the sense of libva and libvdpau) and every vendor does their own thing, so you pretty much end up coding vendor-specific support in your app. You can read a bit about it in this mpv bug: https://github.com/mpv-player/mpv/issues/528. So openmax is *not* the answer. Reporting bugs in mesa's vaapi and vdpau (if there really are any, I can't test, I'm all Intel here) so that they can be fixed is the answer.

[treba]

In firefox, vdpau only works well when opengl accel. is enabled.
For me i set

layers.acceleration.force-enabled;true
layers.offmainthreadcomposition.enabled;true
layers.offmainthreadcomposition.async-animations;true

in firefox and

export MOZ_USE_OMTC=1
export vblank_mode=0

in .bashrc and i have quite a good video experience on all sites i tested so far (on a radeon 6320, mesa 10.4.3, firefox 36, flash not installed)
Hope these settings become the default soon

[liam]

In firefox, vdpau only works well when opengl accel. is enabled.
For me i set

layers.acceleration.force-enabled;true
layers.offmainthreadcomposition.enabled;true
layers.offmainthreadcomposition.async-animations;true

in firefox and

export MOZ_USE_OMTC=1
export vblank_mode=0

in .bashrc and i have quite a good video experience on all sites i tested so far (on a radeon 6320, mesa 10.4.3, firefox 36, flash not installed)
Hope these settings become the default soon

How's your stability? I've had serious issues with omtc on Intel.
Also, do you need the environment variables?

[treba]

How's your stability? I've had serious issues with omtc on Intel.
Also, do you need the environment variables?

yes you do need the env. vars.
this is why the omtc var is needed:

Now X11 platforms don't have the pref layers.offmainthreadcomposition.enabled anymore. Instead they enable omtc using an environment variable because it is not currently possible to access prefs before the first call to XOpenDisplay and we don't want to have the overhead of XInitThreads when OMTC is not used.
On every platforms, whether or not we use OMTC is decided only once per execution (as opposed to every time we create a nsBaseWidget) and other ports of the code should access this state using nsBseWidget::UseOffMainThreadCompositing instead of accessing the pref directly.

vblanc is radeon only, don't know why they set it as default.
disabeling it gives me a much better experience with the gnome shell in general, but there's also one glitch when opening firefox (like with many opengl apps), which is less visible without vblanc.

Stability is great so far and i'm browsing and watching videos (on different sites) quite a lot. only the glitch when opening firefox should defenetly be fixed. but i guess that's a radeon issue, as it also occurs with source-engine games for example.

[liam]

yes you do need the env. vars.
this is why the omtc var is needed:


vblanc is radeon only, don't know why they set it as default.
disabeling it gives me a much better experience with the gnome shell in general, but there's also one glitch when opening firefox (like with many opengl apps), which is less visible without vblanc.

Stability is great so far and i'm browsing and watching videos (on different sites) quite a lot. only the glitch when opening firefox should defenetly be fixed. but i guess that's a radeon issue, as it also occurs with source-engine games for example.

Fantastic. Thanks for the info.