Add additional Enviornment variable parsing for device and display

[aenertia]

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]

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]

@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]

See this issue on the same in libva-utils: https://github.com/intel/libva-utils/issues/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]

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]

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]

The use case is needing per-session default selection.

We already allow some things to be set as default in the /etc config file.

Whilst I hear you in regards to proper implementation - it is not going to adequately solve the use case. Per session config seems to be the right balance here. LibVa already allows for the render backend to be selected so I really can't see why explicitly allowing the user to specify a device is out of line with existing practice.

On 19 July 2018 at 10:49, Mark Thompson notifications@github.com wrote:

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.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/libva/issues/221#issuecomment-406097988, or mute the thread https://github.com/notifications/unsubscribe-auth/AARer3dDD8yMzzK2lBYcp48JK0FEtVkVks5uH7tcgaJpZM4UqPJt .

[Kabouik]

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]

Hrm; something recently in either the libva i965 or libva itself has broken my previous method of statically compiling the device into programmes which need to select the intel card over the nvidia backend.

The device i.e /dev/dri/render128 in this case is still correct, but as of the last set of pushes to obiaf's ppa from maybe 3 days ago the driver is not being correctly selected:

Example output : enertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ ./fullscreenrgb --nodepth Version: 0.2.0 Environment variables: LOGFILE= Usage: ./fullscreenrgb [-gpu=] [gl | cl | clkde | cuda | cudakde | cpu] [] [-noviewer] [-norgb | -nodepth] [-help] [-version] [-frames ] To pause and unpause: pkill -USR1 Protonect [Info] [Freenect2Impl] enumerating devices... [Info] [Freenect2Impl] 14 usb devices connected [Info] [Freenect2Impl] found valid Kinect v2 @4:2 with serial 134612434547 [Info] [Freenect2Impl] found 1 devices libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) [Error] [VaapiRgbPacketProcessorImpl] vaInitialize(display, &major_ver, &minor_ver): unknown libva error

On 18 August 2018 at 09:24, Kabouik notifications@github.com wrote:

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 https://github.com/mpv-player/mpv/issues/4873 with opengl (and I also experience massive glitches https://reho.st/0x0.st/sJYZ.png 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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/libva/issues/221#issuecomment-413992281, or mute the thread https://github.com/notifications/unsubscribe-auth/AARer_JVtUFYXlwZihATswPQqR6h8aoyks5uRzSkgaJpZM4UqPJt .

[aenertia]

Manually specifying both driver and device from a cli that supports it (i.e recent version of vainfo) still works; so something has changed the driver detection in the last week or so - and now it fails.

aenertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ LIBVA_DRIVER_NAME=i965 vainfo --display drm --device /dev/dri/renderD128 libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'i965' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.0) vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.1.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointEncSliceLP VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointEncSlice VAProfileVP9Profile2 : VAEntrypointVLD

On 18 August 2018 at 09:34, Joel Wirāmu Pauling aenertia@aenertia.net wrote:

Hrm; something recently in either the libva i965 or libva itself has broken my previous method of statically compiling the device into programmes which need to select the intel card over the nvidia backend.

The device i.e /dev/dri/render128 in this case is still correct, but as of the last set of pushes to obiaf's ppa from maybe 3 days ago the driver is not being correctly selected:

Example output : enertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ ./fullscreenrgb --nodepth Version: 0.2.0 Environment variables: LOGFILE= Usage: ./fullscreenrgb [-gpu=] [gl | cl | clkde | cuda | cudakde | cpu] [] [-noviewer] [-norgb | -nodepth] [-help] [-version] [-frames ] To pause and unpause: pkill -USR1 Protonect [Info] [Freenect2Impl] enumerating devices... [Info] [Freenect2Impl] 14 usb devices connected [Info] [Freenect2Impl] found valid Kinect v2 @4:2 with serial 134612434547 [Info] [Freenect2Impl] found 1 devices libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) [Error] [VaapiRgbPacketProcessorImpl] vaInitialize(display, &major_ver, &minor_ver): unknown libva error

On 18 August 2018 at 09:24, Kabouik notifications@github.com wrote:

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 https://github.com/mpv-player/mpv/issues/4873 with opengl (and I also experience massive glitches https://reho.st/0x0.st/sJYZ.png 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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/libva/issues/221#issuecomment-413992281, or mute the thread https://github.com/notifications/unsubscribe-auth/AARer_JVtUFYXlwZihATswPQqR6h8aoyks5uRzSkgaJpZM4UqPJt .

[aenertia]

Explicity setting the Driver in the environment get's a little further:

aenertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ LIBVA_DRIVER_NAME=i965 ./fullscreenrgb -nodepth Version: 0.2.0 Environment variables: LOGFILE= Usage: ./fullscreenrgb [-gpu=] [gl | cl | clkde | cuda | cudakde | cpu] [] [-noviewer] [-norgb | -nodepth] [-help] [-version] [-frames ] To pause and unpause: pkill -USR1 Protonect [Info] [Freenect2Impl] enumerating devices... [Info] [Freenect2Impl] 14 usb devices connected [Info] [Freenect2Impl] found valid Kinect v2 @4:2 with serial 134612434547 [Info] [Freenect2Impl] found 1 devices libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns -1 libva info: User requested driver 'i965' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed libva info: va_openDriver() returns -1 [Error] [VaapiRgbPacketProcessorImpl] vaInitialize(display, &major_ver, &minor_ver): unknown libva error

On 18 August 2018 at 09:36, Joel Wirāmu Pauling aenertia@aenertia.net wrote:

Manually specifying both driver and device from a cli that supports it (i.e recent version of vainfo) still works; so something has changed the driver detection in the last week or so - and now it fails.

aenertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ LIBVA_DRIVER_NAME=i965 vainfo --display drm --device /dev/dri/renderD128 libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'i965' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.0) vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.1.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointEncSliceLP VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointEncSlice VAProfileVP9Profile2 : VAEntrypointVLD

On 18 August 2018 at 09:34, Joel Wirāmu Pauling aenertia@aenertia.net wrote:

Hrm; something recently in either the libva i965 or libva itself has broken my previous method of statically compiling the device into programmes which need to select the intel card over the nvidia backend.

The device i.e /dev/dri/render128 in this case is still correct, but as of the last set of pushes to obiaf's ppa from maybe 3 days ago the driver is not being correctly selected:

Example output : enertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ ./fullscreenrgb --nodepth Version: 0.2.0 Environment variables: LOGFILE= Usage: ./fullscreenrgb [-gpu=] [gl | cl | clkde | cuda | cudakde | cpu] [] [-noviewer] [-norgb | -nodepth] [-help] [-version] [-frames ] To pause and unpause: pkill -USR1 Protonect [Info] [Freenect2Impl] enumerating devices... [Info] [Freenect2Impl] 14 usb devices connected [Info] [Freenect2Impl] found valid Kinect v2 @4:2 with serial 134612434547 [Info] [Freenect2Impl] found 1 devices libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) [Error] [VaapiRgbPacketProcessorImpl] vaInitialize(display, &major_ver, &minor_ver): unknown libva error

On 18 August 2018 at 09:24, Kabouik notifications@github.com wrote:

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 https://github.com/mpv-player/mpv/issues/4873 with opengl (and I also experience massive glitches https://reho.st/0x0.st/sJYZ.png 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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/libva/issues/221#issuecomment-413992281, or mute the thread https://github.com/notifications/unsubscribe-auth/AARer_JVtUFYXlwZihATswPQqR6h8aoyks5uRzSkgaJpZM4UqPJt .

[aenertia]

My guess is that libva is not longer implying drm when initing?

On 18 August 2018 at 09:40, Joel Wirāmu Pauling aenertia@aenertia.net wrote:

Explicity setting the Driver in the environment get's a little further:

aenertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ LIBVA_DRIVER_NAME=i965 ./fullscreenrgb -nodepth Version: 0.2.0 Environment variables: LOGFILE= Usage: ./fullscreenrgb [-gpu=] [gl | cl | clkde | cuda | cudakde | cpu] [] [-noviewer] [-norgb | -nodepth] [-help] [-version] [-frames ] To pause and unpause: pkill -USR1 Protonect [Info] [Freenect2Impl] enumerating devices... [Info] [Freenect2Impl] 14 usb devices connected [Info] [Freenect2Impl] found valid Kinect v2 @4:2 with serial 134612434547 [Info] [Freenect2Impl] found 1 devices libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns -1 libva info: User requested driver 'i965' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed libva info: va_openDriver() returns -1 [Error] [VaapiRgbPacketProcessorImpl] vaInitialize(display, &major_ver, &minor_ver): unknown libva error

On 18 August 2018 at 09:36, Joel Wirāmu Pauling aenertia@aenertia.net wrote:

Manually specifying both driver and device from a cli that supports it (i.e recent version of vainfo) still works; so something has changed the driver detection in the last week or so - and now it fails.

aenertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ LIBVA_DRIVER_NAME=i965 vainfo --display drm --device /dev/dri/renderD128 libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'i965' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/ i965_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.0) vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.1.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointEncSliceLP VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointEncSlice VAProfileVP9Profile2 : VAEntrypointVLD

On 18 August 2018 at 09:34, Joel Wirāmu Pauling aenertia@aenertia.net wrote:

Hrm; something recently in either the libva i965 or libva itself has broken my previous method of statically compiling the device into programmes which need to select the intel card over the nvidia backend.

The device i.e /dev/dri/render128 in this case is still correct, but as of the last set of pushes to obiaf's ppa from maybe 3 days ago the driver is not being correctly selected:

Example output : enertia@kiorewha:~/buildlocal/libfreenect2/rgbviewer/bin$ ./fullscreenrgb --nodepth Version: 0.2.0 Environment variables: LOGFILE= Usage: ./fullscreenrgb [-gpu=] [gl | cl | clkde | cuda | cudakde | cpu] [] [-noviewer] [-norgb | -nodepth] [-help] [-version] [-frames ] To pause and unpause: pkill -USR1 Protonect [Info] [Freenect2Impl] enumerating devices... [Info] [Freenect2Impl] 14 usb devices connected [Info] [Freenect2Impl] found valid Kinect v2 @4:2 with serial 134612434547 [Info] [Freenect2Impl] found 1 devices libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) [Error] [VaapiRgbPacketProcessorImpl] vaInitialize(display, &major_ver, &minor_ver): unknown libva error

On 18 August 2018 at 09:24, Kabouik notifications@github.com wrote:

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 https://github.com/mpv-player/mpv/issues/4873 with opengl (and I also experience massive glitches https://reho.st/0x0.st/sJYZ.png 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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/libva/issues/221#issuecomment-413992281, or mute the thread https://github.com/notifications/unsubscribe-auth/AARer_JVtUFYXlwZihATswPQqR6h8aoyks5uRzSkgaJpZM4UqPJt .

[takov751]

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]

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

[telans]

Any updates to this?

[newcanopies]

updates?

[eero-t]

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]

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]

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: https://github.com/mpv-player/mpv/pull/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).