пт, 11 окт. 2024 г., 14:58 Terje J. Hanssen <[email protected]>:
Den 28.09.2024 21:24, skrev Andrew Randrianasulu:
сб, 28 сент. 2024 г., 21:59 Terje J. Hanssen <[email protected]>:
Den 28.09.2024 19:10, skrev Andrew Randrianasulu:
May be ffmpeg tries onevpl on new hardware?
https://bugs.gentoo.org/590752
example output
I think so because Intel VPL GPU Runtime is for use on Intel DG1 (Iris Xe graphics and newer), while Intel Media SDK for use on older, legacy Intel graphics, selected by the VPL dispatcher
https://github.com/intel/libvpl/?tab=readme-ov-file#intel-video-processing-l...
I searched a time back for the vpl-inspect tool, but I could not find it among my installed RT Intel packages
try https://github.com/intel/libvpl-tools/ ?
either as package name or your own source build ... (may be ping libvpl maintainer in suse?)
Yeah, libvpl-tools is now built for openSUSE, and I ran two of them on Slowroll/Arc A750 according to this article:
https://www.intel.com/content/www/us/en/developer/articles/technical/overvie...
*oneVPL Tools There are oneVPL tools available in the oneVPL base repository which are a good starting point to get familiar with the oneVPL functionalities. The command line tools for checking available implementation supported by the current system are in the cli directory and the ‘sample-*’ tools are in the legacy directory. Tools for Checking Implementation Capabilities To check the implementation capabilities of oneVPL the following approaches can be used:, First Approach: vpl-inspect|grep Implementation*
vpl-inspect|grep Implementation libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Implementation #0: mfx-gen
=================
* Second Approach (improved visibility in Linux environment): system_analyzer .........snip Here, it is oneVPL dispatcher’s responsibility to load GPU runtimes (libmfxhw64.so or libmfxgen.so) depending on the system’s compatibility and selected codec. There are no plans for libmfxhw64.xo.1 to support new Gen (Gen12 or newer) platforms. Media SDK GPU runtime (libmfxhw64.so) runs on Gen9 and Gen11 while oneVPL GPU runtime (libmfxgen.so) supports Gen12, Xe, and newer hardware. Media SDK runtime supports API 1.35 and VPL runtime supports API 2.x (currently 2.8) * system_analyzer ------------------------------------ Looking for GPU interfaces available to OS... FOUND: /dev/dri/renderD128 GPU interfaces found: 1 ------------------------------------
------------------------------------ Available implementation details: libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0
Implementation #0: mfx-gen Library path: /usr/lib64/libmfx-gen.so.1.2.12 AccelerationMode: MFX_ACCEL_MODE_VIA_VAAPI ApiVersion: 2.12 Impl: MFX_IMPL_TYPE_HARDWARE ImplName: mfx-gen MediaAdapterType: MFX_MEDIA_DISCRETE VendorID: 0x8086 DeviceID: 0x56A1 GPU name: Intel® Arc(TM) A750 graphics (arch=Xe HPG codename=DG2) PCI BDF: 0000:03:00.00 PCI RevisionID: 0x0008 DRMRenderNodeNum: 128 DeviceName: mfx-gen ------------------------------------
I am not quite sure what the essence of this output really tell? There are also additional "sample_* tools " mentioned in the article, that possibly are useful (?)
Hopefully it tells us that vpl stack working, or at least in consistent state? Can uou try vpl-inspect without |grep just for seeing full output? Does it lust codecs? Can sample tools like encoder be used for encoding (from yuv/y4m I guess? they should contain brief help) just to see if anything can use vpl stack as intended, so we can move to ffmpeg troubleshooting?
https://www.intel.com/content/www/us/en/developer/articles/technical/overvie...