Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add additional Enviornment variable parsing for device and display #221

Open
aenertia opened this issue Jun 15, 2018 · 19 comments
Open

Add additional Enviornment variable parsing for device and display #221

aenertia opened this issue Jun 15, 2018 · 19 comments

Comments

@aenertia
Copy link

Currently the environment variable LIBVA_DRIVER_NAME=

is the only tuneable. However having a define for LIBVA_DEVICE=</dev/cardX> and LIBVA_DISPLAY=<xll,wayland,drm>

should also be defined.

This is especially important for multi GPU systems where say the display device isn't the target for encoding/decoding acceleration.
@fhvwy
Copy link
Contributor

fhvwy commented Jul 1, 2018

This is directly controlled by the calling application - all of the vaGetDisplay*() functions take an argument defining the device. If you wanted this to work, I think you would need to add a new vaGetDisplayFromNothing(void) function which creates the device without any existing connection.

@Brainiarc7
Copy link

@fhvwy ,

That is well and good.

However, on prebuilt applications where that variable cannot be set, a global option (such as the solution he described above) would be very useful, and would eliminate many libva init errors.

@Brainiarc7
Copy link

See this issue on the same in libva-utils: intel/libva-utils#120

Assumptions are dangerous, and they make error handling harder than it should be.

An optional environment variable that would allow a sysadmin to override device selection on a system-wide (or via an environment-module override for (a) specific user(s) would go a long way towards enabling usability.

This is particularly useful on multi-user environments, such as HPC clusters, where more than one VAAPI-capable accelerator may be available. Case in point: Multiple AMD GCN-class GPUs on a HPC node.

@Brainiarc7
Copy link

Applications such as FFmpeg have robust hwaccel init codepaths that allow for device selection on a per-session basis (encode, decode, filter chain usage, etc) as shown here.

However, that cannot be said of all software, and the results can be catastrophic.

Defaults are well and good. However, that does not call for shipping software that's broken on deployment without a reasonable override mechanism in place.

@fhvwy
Copy link
Contributor

fhvwy commented Jul 18, 2018

Please look at how the current API works. The user application /must/ open a specific device to use (DRM device, X11 / Wayland / Android display) and pass that to libva to create the VADisplay handle on. They might also use other functions on this device, so having a way to not use it and instead open a completely different device transparently to the application would cause very weird problems.

Hence my suggestion above that what you need here is a vaGetDisplayFromNothing(void) function, which would act like the existing vaGetDisplayFromSomething(something) functions but look at environment variables (or guess) to open a new device rather than using the device provided by the user. Applications which don't need to set the backing device and don't want to perform any other operations on it (like Wayland surface mapping or whatever) could then use this function to allow external user control without needing to make their own ad-hoc code for it - that seems nicer than the current situation where they are forced to go looking for a specific device when they don't want to care about it. It also doesn't change anything for existing applications which do know about the device and handle it appropriately. (Though they could still use it - if such a function existed, FFmpeg would use it for the -init_hw_device case with no argument instead of the current code which tries to guess a device.)

@aenertia
Copy link
Author

aenertia commented Jul 19, 2018 via email

@Kabouik
Copy link

Kabouik commented Aug 17, 2018

I would also be very interested in a way to specify a LIBVA_DEVICE, since I am using an AMD GPU and radeonsi as VA driver cause bugs with opengl (and I also experience massive glitches for H264; what you are seeing is the H264 stream from a cloud computing application, this is why it looks like a Windows desktop). If I could specify that I want to use my Intel GPU (previously activated in the BIOS) for VA with the i965 driver, and the AMD GPU for other things like gaming or multimonitor, then all my needs would be covered.

@aenertia
Copy link
Author

aenertia commented Aug 17, 2018 via email

@aenertia
Copy link
Author

aenertia commented Aug 17, 2018 via email

@aenertia
Copy link
Author

aenertia commented Aug 17, 2018 via email

@aenertia
Copy link
Author

aenertia commented Aug 17, 2018 via email

@takov751
Copy link

takov751 commented Dec 17, 2018 •
edited

As a geforce 840m user i would be very-very intrested in this topic thus my card does not support vdpau nor nvenc. So all hw acc done via opengl which is not the most efficent things to do in my case.

@Brainiarc7
Copy link

Another prime example of why this is needed: https://trac.ffmpeg.org/ticket/7649

@telans
Copy link

telans commented Feb 17, 2020

Any updates to this?

@5l1v3r1
Copy link

5l1v3r1 commented Oct 12, 2020

any updates? this is really vital.

@newcanopies
Copy link

updates?

@satmandu satmandu mentioned this issue Apr 9, 2021
Closed
@eero-t eero-t mentioned this issue Oct 8, 2021
Closed
@eero-t
Copy link

eero-t commented Oct 8, 2021

Please look at how the current API works. The user application /must/ open a specific device to use (DRM device, X11 / Wayland / Android display) and pass that to libva to create the VADisplay handle on. They might also use other functions on this device, so having a way to not use it and instead open a completely different device transparently to the application would cause very weird problems.

Hence my suggestion above that what you need here is a vaGetDisplayFromNothing(void) function,

I'd suggest vaGetDisplay*Default() , which would also implement device discovery functionality in addition to supporting the environment variable. It's silly that each application needs to implement device discovery in their own subtly broken way instead of library providing best implementation of that.

which would act like the existing vaGetDisplayFromSomething(something) functions but look at environment variables (or guess) to open a new device rather than using the device provided by the user. Applications which don't need to set the backing device and don't want to perform any other operations on it (like Wayland surface mapping or whatever) could then use this function to allow external user control without needing to make their own ad-hoc code for it - that seems nicer than the current situation where they are forced to go looking for a specific device when they don't want to care about it. It also doesn't change anything for existing applications which do know about the device and handle it appropriately.

Additionally documentation for vaGetDisplayDRM() and similar functions could strongly recommend that applications not using the *Default() function for scanning the devices, would at least check this same environment variable.

@XinfengZhang
Copy link
Contributor

let me recap this discussion:

  1. for old applications which could not specify the device by parameter like ffmpeg using "-hwaccel_device /dev/dri/renderDxxx", need a method to specify the device node. the options could be:
    a: an environment variable which will override the device node from application
    b: change the old application design to support multiple device ---- seems it is difficult for different applications

  2. adding new api
    a. vaGetDisplayDefault/vaGetDisplayFromNothing or vaGetDisplay with nullptr as the parameter
    this function call will respect the environment variable , but will not resolve the problem of1.b

to handle the device discovery for all application. seems libva need add a interface which could be called before vaInitialize. it will enumerate the devices and the vendors , then application could select one ?

@eero-t
Copy link

eero-t commented Oct 15, 2021

b: change the old application design to support multiple device ---- seems it is difficult for different applications

I only see link to old 2017 MPV bug, but MPV got device selection option in 2018: mpv-player/mpv#5685

No other applications are mentioned where one could not manually specify the device to the application. IMHO those are application specific bugs any way, so 1.b should not be any more relevant for discussion?

adding new api
a. vaGetDisplayDefault/vaGetDisplayFromNothing or vaGetDisplay with nullptr as the parameter this function call will respect the environment variable

Here's the summary of the reasons:

  • There can be problems if libva uses different FD that what the application requested it to use, so a new libva API for device discovery (as @fhvwy suggested in 2018) is needed, where the default device selection can be safely overridden.
  • Discovery API is needed when it's not possible to manually specify to applications what GPU device should be used on given node (although apps themselves would have option for that). This can be the case cluster environments. When discovery is done in single place it can easily be fixed if there are problems (and fix upstreamed to libva).
  • Override ability is needed when (manual) device choice must be applied to a large number of applications, e.g. everything that runs on user's desktop session. Environment variable is natural choice for specifying it. Reasons for needing this could be temporary driver bugs, preference for results quality of specific HW, testing different HW & drivers etc.

to handle the device discovery for all application. seems libva need add a interface which could be called before vaInitialize. it will enumerate the devices and the vendors , then application could select one

IMHO application should be offered only devices that are supported by the available libva backend driver(s), so vendor info is redundant for that API [1].

Discovery in other APIs (3D & compute ones) includes frontend querying from backend drivers whether they support given device. They also have some builtin logic in which order to do the querying, in case there are multiple backends supporting the same HW (e.g. "iris", "i965" and "crocus" drivers in Mesa).

Like with libva, driver selection can also be overidden in those APIs. Display selection should also be overridable, if it can affect device discovery (as nowadays most desktops run Wayland + Xwayland, and DRM is available always).

[1] If application intends user to select one of the available devices, I think another API should be used for querying device information to show to user (relevant information for user decision can be vendor, driver and device name, possibly also what VA-API features given driver/device combination supports).

@eero-t eero-t mentioned this issue Dec 10, 2021
Merged
@Brainiarc7 Brainiarc7 mentioned this issue Dec 11, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@aenertia @Brainiarc7 @eero-t @Kabouik @fhvwy @XinfengZhang @5l1v3r1 @takov751 @telans @newcanopies