https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/ce5096a51ce1f... see, they set "LIBVA_DRIVERS_PATH=/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri" I wonder if we should do the same ....
It is worth a try. I will try that tomorrow. On Mon, May 6, 2024, 18:06 Andrew Randrianasulu <[email protected]> wrote:
https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/ce5096a51ce1f...
see, they set
"LIBVA_DRIVERS_PATH=/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri"
I wonder if we should do the same ....
This is what I tried, but it made no difference. Is there some other way for me to try? 1) in creating the AppImage, I ran the following 2 lines. The 2nd line is the usual. export "LIBVA_DRIVERS_PATH=/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri" /proj/appimage/linuxdeploy-x86_64.AppImage --appdir=AppDir -o appimage ... That made no difference. 2) so I did the full build again, using the export line first and then ran linuxdeploy to make the appimage. Still no difference. The reason I know it made no difference is because instead of the path being /usr/lib/dri:..., I changed it to exporting the path to a dummy value of /etc/fstab instead and the vaapi and vdpau settings still worked. Any suggestions? "LIBVA_DRIVERS_PATH=/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri"
ср, 8 мая 2024 г., 01:39 Phyllis Smith <[email protected]>:
This is what I tried, but it made no difference. Is there some other way for me to try?
1) in creating the AppImage, I ran the following 2 lines. The 2nd line is the usual. export "LIBVA_DRIVERS_PATH=/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri" /proj/appimage/linuxdeploy-x86_64.AppImage --appdir=AppDir -o appimage ... That made no difference. 2) so I did the full build again, using the export line first and then ran linuxdeploy to make the appimage. Still no difference.
well, we are c++ and thus *I think* we can try to hardcode this like I did with DRI3 disable patch ... diff --git a/cinelerra-5.1/cinelerra/main.C b/cinelerra-5.1/cinelerra/main.C index 0def64b7..3f123b98 100644 --- cinelerra/main.C +++ cinelerra/main.C @@ -168,6 +168,15 @@ int main(int argc, char *argv[]) batch_path[0] = 0; deamon_path[0] = 0; Units::init(); + + /* disable dri3 for non_prime, it broke hw effects on nouveau as of 26-08-2020 */ + const char *prime = getenv("DRI_PRIME"); + if (prime) + setenv("LIBGL_DRI3_DISABLE", "0", 1); + else + setenv("LIBGL_DRI3_DISABLE", "1", 1); + === in your case just single setenv() should work,I hope? just replace variable name and second argument (long string in "") .... ?
The reason I know it made no difference is because instead of the path being /usr/lib/dri:..., I changed it to exporting the path to a dummy value of /etc/fstab instead and the vaapi and vdpau settings still worked. Any suggestions?
"LIBVA_DRIVERS_PATH=/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri"
Your way seems to be working correctly but I will have to do better experiments tomorrow using various computers/hardware setup to make sure. Lots more tests to do. Below is how I added line to main.C.
batch_path[0] = 0; deamon_path[0] = 0; Units::init(); * setenv("LIBVA_DRIVERS_PATH","/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri",1);* const char *lang = getenv("LANGUAGE");
Since I don't quite understand what to do, is it possible to have a patch to compile? PS: is it possible to do something similar with vulkan?
Attached is the patch which you apply when in the cinelerra subdirectory. The patch is not complete yet because of accommodation for 32-bit and I really have to test more too. If the patch does not work for you, just edit cinelerra/main.C and add the line: setenv("LIBVA_DRIVERS_PATH","/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri",1); after line 180 (line 180 is Units::init(); On Wed, May 8, 2024 at 5:26 AM Andrea paz <[email protected]> wrote:
Since I don't quite understand what to do, is it possible to have a patch to compile?
PS: is it possible to do something similar with vulkan?
Andrew, Unfortunately, the setenv for LIBVA_DRIVERS_PATH in main.C used in an AppImage does not solve the problem of being able to use the Hardware Vaapi/Vdpau capability of the computer CinGG is executed on. I am assuming that this was the goal? Here is what I tested: 1. Compiled CinGG with the setenv in main.c on AMD computer that had no graphics hardware/software installed. 2. Verified that on this computer when I changed Settings/Preferences/Performance hw device to either vaapi or vdpau and executed the binary, I would get "operation not permitted ... using software". 3. Created AppImage on same computer. 4. Ran that AppImage on laptop where the hardware/software supports both vaapi and vdpau. This failed to allow using either vaapi or vdpau. So I fail to see any advantage to adding the setenv. Am I wrong? What does it solve, if anything? On Mon, May 6, 2024 at 6:06 PM Andrew Randrianasulu <[email protected]> wrote:
https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/ce5096a51ce1f...
see, they set
"LIBVA_DRIVERS_PATH=/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri"
I wonder if we should do the same ....
I put the patch for vaapi, but I don't notice any change in decoding. There are no warnings in the terminal but the GPU does not affect the decoding. I used CinGG compiled, not the appimage.
As far as I know, the goal is for the new released AppImages to work on other computers that have VAAPI and VDPAU hardware graphics capabilities even if at different levels of the operating system than the computer where the AppImage was created. But so far, I have not been able to either get a good test or any good results. (BTW credit goes to Andrew for suggestion to try this + all of the advice I need to do so). Latest test results: - created AppImage on older Fedora version 31 which is HP/Intel chip where both VAAPI and VDPAU work. - main.C currently contains the 2 lines shown below (have not tested Andrew's newest suggestion yet)
setenv("LIBVA_DRIVERS_PATH","/usr/lib/dri:/usr/lib64/dri:/usr/lib/x86_64-linux-gnu/dri:/usr/lib/aarch64-linux-gnu/dri",1);
setenv("VDPAU_DRIVER_PATH","/usr/lib/vdpau:/var/lib/snapd/lib/gl/vdpau:/var/lib/snapd/lib/gl",1);
- on the AMD laptop running Fedora 32 VAAPI gives the following errors just doing a single load:
Failed HW device create. dev:vaapi err: Input/output error HW device init failed, using SW decode. file:/root/media/tutorial.mp4 err: Operation not permitted Failed HW device create. dev:vaapi err: Input/output error
HW device init failed, using SW decode.
file:/root/media/tutorial.mp4 err: Operation not permitted Failed HW device create. dev:vaapi err: Input/output error HW device init failed, using SW decode. file:/root/media/tutorial.mp4 err: Operation not permitted Failed HW device create. dev:vaapi err: Input/output error HW device init failed, using SW decode.
file:/root/media/tutorial.mp4
err: Operation not permitted
- a single load of VDPAU works (but I seem to have in my brain, that this gets simulated somehow) More experimentation is coming with some variations. On Fri, May 10, 2024 at 8:08 AM Andrea paz <[email protected]> wrote:
I put the patch for vaapi, but I don't notice any change in decoding. There are no warnings in the terminal but the GPU does not affect the decoding. I used CinGG compiled, not the appimage.
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith