Talk:Hardware video acceleration

From ArchWiki
Revision as of 10:03, 26 March 2017 by DoctorJellyface (talk | contribs) (re)
Jump to navigation Jump to search


This variable may need to be set when using older AMD cards even with open source drivers. I fixed this by adding a simlink in /usr/lib/dri/ --> but this may have been able to be fixed with this environmental variable. It seems to work alright and doesn't break anything with my old backup laptop but this is probably not a preferred solution.

VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV515/M52 [Mobility Radeon X1300]
pacman -Qqs vdpau && pacman -Qqs mesa

TheChickenMan (talk) 02:39, 26 May 2016 (UTC)

The Hardware_video_acceleration#Configuring_VDPAU section says:
"For the open source AMD/ATI driver set it to the proper driver version depending on your GPU (see below)."
So yes, you should have set the VDPAU_DRIVER variable instead of creating the symlink.
-- Lahwaacz (talk) 10:04, 28 May 2016 (UTC)
Yes, I probably should change it but I had that as a solution before finding that info in the wiki. I bring this up because it seemed to be indicated that that information may be unnecessary for open source AMD drivers. Maybe it isn't needed for newer AMD cards? The above example is from a laptop which is at least 11 years old this summer. Anyway, I still think that information is useful to keep in the wiki.
TheChickenMan (talk) 22:07, 28 May 2016 (UTC)
I've been thinking about swapping Configuring and Verifying for exactly this reason, but the problem is that I don't know when it is needed to set the the variable, it seems to very from system to system.
-- DoctorJellyface (talk) 15:31, 29 May 2016 (UTC)
I have an idea. If you look at the third line of the output of vainfo, it lists a file in the directory /usr/lib/dri/ As far as I am aware, all drivers which do not need to have the variable set will have the file asked for provided somewhere in a package. NOTE: I ran out this example on my workstation which uses the nvidia driver which is why it is asking for /usr/lib/dri/ below.
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/
libva info: Found init function __vaDriverInit_0_35
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG4Simple            :	VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    :	VAEntrypointVLD
      VAProfileH264Baseline           :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
Then you can use pkgfile -d /usr/lib/dri to list all packages in Arch which contain the listed directory.
Finally, you can use pkgfile -l on each listed package and put together a list of what would be supported by each package. If someone runs vainfo and gets a /usr/lib/dri/ in that third line which is not listed, then they would need to set the variable or possibly vaapi might just not be supported by anything.
extra/libva			/usr/lib/dri/
extra/libva-intel-driver	/usr/lib/dri/
extra/libva-mesa-driver		/usr/lib/dri/
extra/libva-vdpau-driver	/usr/lib/dri/
extra/libva-vdpau-driver	/usr/lib/dri/
extra/libva-vdpau-driver	/usr/lib/dri/
Example: Running vainfo on my old HP laptop which I cited above asks for a file name /usr/lib/dri/ which is not included on the above list and therefore requires the environmental variable be set. Apologies for the length of this discussion but I couldn't really think of a better way of working through this. Not sure how to best represent this on the wiki, perhaps a table of some kind?
Just taking a second to look at the results of that list, it seems that anyone with an AMD card which does not use /usr/lib/dri/ from the libva-mesa-driver package or anyone using AMD and installing libva-vdpau-driver will need to set the variable. There may be additional situations but I think that would cover the most common ones.
TheChickenMan (talk) 21:20, 29 May 2016 (UTC)
Now you're talking about VA-API, not VDPAU, i.e. you'd need to set LIBVA_DRIVER_NAME instead of VDPAU_DRIVER. -- Lahwaacz (talk) 07:33, 30 May 2016 (UTC)
I was always talking about that. Perhaps a bit misled because the package libva-vdpau-driver. Like I said, I'm no great expert in video acceleration. Just had some time to research that a bit and try to put some stuff together. It is still part of the same (type) of issue though. Perhaps a similar procedure could be used to determine which conditions would require the other variable be set as well? I'm guessing that would be on Intel chips mostly as they tend to be what uses native VAAPI to get VDPAU.
TheChickenMan (talk) 09:58, 30 May 2016 (UTC)
Check the wiki page now, should explain it all better.
-- DoctorJellyface (talk) 16:58, 7 June 2016 (UTC)
Yeah that seems a lot less confusing now.
TheChickenMan (talk) 00:53, 8 June 2016 (UTC)
Well it seems like Lahwaacz reverted the changes. Lahwaacz: why did you do this? The changes were carefully thought out and removed a ton a useless misleading mess. The changes were too complex to change in several commits though. I mean I basically put together this page and already spent more than 6 hours on it and this was the final change making it complete in my eyes (disregarding a few small details).
-- DoctorJellyface (talk) 12:29, 8 June 2016 (UTC)
Changes are never too complex to split in multiple edits -- bulking them together makes them complex, splitting makes them simpler. In this case, you should have first swapped the order of the sections, then deal with the content, e.g. one section after another. Among other benefits, you would have had much more space in edit summaries to describe the complexity.
As for the "useless misleading mess", why have you removed the link to [1] and the explicit suggestions of VA-API and VDPAU drivers? Your changes don't indicate that at all and considering the AMD case, I somewhat doubt that the details are as useless as you suggest.
And the original authors are shown here and here. You have merged the two pages and reduced duplication, for which we are very grateful, but now we're past that. The pages are a community effort.
-- Lahwaacz (talk) 13:14, 8 June 2016 (UTC)
Wait, don't take me wrong, I am not taking authorship for this page, but I am taking (at least some) responsibility for it. I'm sorry if I sounded like another bigheaded idiot and I assure you I'm not (at least I try to, heh). I just (for the first and probably the last time) mentioned the time it took to do it all to prove that I'm not a vandal, that I'm trying my best to make the wiki better, and that I hope it earned me at least a teeny bit of trust in making edits like this. As for the edits, I know it is important and I take care to lay them out usually, but this one edit took at least an hour to make which is a lot of time for me unfortunately, and since I was going away for a few days I wanted to get it done and I just put the final state to a higher priority than making the edits slightly clearer.
As for the 'useless misleading mess', let me clarify it: VDPAU and VA-API are actually really good at guessing the driver and it only fails if the driver doesn't exist; it's still guessed correctly though. Therefore the user should not manually configure the driver if everything works. The current layout suggests that not only the drivers have to (or should) be configured manually, but also that different cards need different drivers - if you look at the checksums of them you can see that many of the drivers are just copies with a different name (all the libraries in mesa-vdpau (r300, r600, radeonsi, nouveau) or libva-mesa-driver (nvidia, s3g and vpdau) are identical), the names are there just for compatibility reasons or something. And also the line about overriding the driver based on what VDPAU guessed itself is just nonsense. I tried to a) explain how the variable actually works, b) teach the user to test and try instead of relying on an (obselete/incomplete) table and c) make it at least a bit more future-proof while hopefully getting better results at the same time.
As for the link - I looked at it a bit more carefully I see it's not a list of supported cards as I thought earlier, but it's still just a subsection of an already mentioned link and doesn't say much useful. It should be under installation though anyway, but I admit I shouldn't've removed it.
With you permission I'd like to apply the changes again, this time in seperate commits though. Sorry for the trouble.
-- DoctorJellyface (talk) 13:17, 11 June 2016 (UTC)
I apologize for the delay, unfortunately I was rather busy back then and somewhat forgot about this...
Now where were we... OK, the mess is pretty much useless and misleading, except for the AMD case, which I think deserves at least some hand-holding. The installation section sounds as if libva-mesa-driver and libva-vdpau-driver were equivalent alternatives for all cards, but that is not the case since there is no r300 VAAPI driver in libva-mesa-driver, not to mention that AMDGPU is not mentioned at all on the page. Further, the vdpau and va_gl drivers are never automatically detected (for NVIDIA it's only thanks to the -> symlink), so in this case it's not "only proceed if something fails", but "unless you do this, something fails" (i.e. normal configuration). Your approach to the introduction of the section of course works generally, but I'm afraid that mixing these cases will always cause some confusion on one side or the other.
So of course please feel free to continue improving the page, e.g. by combining your changes with my comments above ;)
-- Lahwaacz (talk) 10:32, 4 August 2016 (UTC)
Hey, I can't believe it took me half a year to get to this, sorry for that.
The wiki has changed quite a bit since I last edited it, I've been reading it but I still need to figure some stuff out, but until then, please clarify the AMD thingy.
The wiki says (quote):
  • For radeon the driver name can determined by running:
$ grep -iE 'vdpau|dri driver' ~/.local/share/xorg/Xorg.0.log
(II) RADEON(0): [DRI2] DRI driver: radeonsi
(II) RADEON(0): [DRI2] VDPAU driver: radeonsi
In this case you want to use radeonsi for both VA-API and VDPAU.
End of quote.
Here VDPAU guesses radeonsi, and applies it too. Why would we want to override something to something already automatically set? The only way this could be useful is to find out what to use for VA-API, but that might not work, as the drivers aren't identical.
Also, looks like the difference between VA-API and VDPAU for the open-source AMD driver is non-existent, it really depends on the app, according to this:
-- DoctorJellyface (talk) 21:11, 26 December 2016 (UTC)
I updated some parts of the wiki, it should solve most (if not all) of the above issues.
-- DoctorJellyface (talk) 10:03, 26 March 2017 (UTC)