On 2/5/26 8:52 PM, Phyllis Smith wrote:
As time
permits, try this AppImage and please let me know if Vulkan
and Onevpl capabilities are there. I cobbled together the
binary on the CinGG website Download page in the testing
subdirectory: vulkan_onevpl-x86_64.AppImage. It was built on
kernel version 6.18.5-100, libc version 2.41.
Tested the vulkan_onevpl-x86_64.AppImage on two Intel machines ,
Coffee Lake / UHD 620 iGPU and Alder Lake / DG2 dGPU, both with
current Slowroll.
Unhappily the actual rendering methods failed:
VPL: cant find codec h264_qsv or hevc_qsv.
Sad. :(
I wonder if it was just path mismatch like with vaapi, or something else?
Can you unpack appimage, delete onevpl lib, and let it link to system's onevpl loader, like with vaapi before?
Vulkan: compression was not available. (tried to adapt and edit
tje h264_vaapi preset to cin_hw_dev=vulkan which didn't work).
you need to change actual codec name, too.
ffmpeg on termux says something like
ffmpeg -encoders | grep vulkan
V....D av1_vulkan AV1 (Vulkan) (codec av1)
V....D ffv1_vulkan FFmpeg video codec #1 (Vulkan) (codec ffv1)
V....D h264_vulkan H.264/AVC (Vulkan) (codec h264)
V....D hevc_vulkan H.265/HEVC (Vulkan) (codec hevc)
Tested also my own appimage (20241120) where still VPL works on
Leap15.6
FYI,
I did get --with-vulkan to compile but not
--with-onevpl. Still working on and got errors
when making AppImage so am not done yet.
root@fedora:~#
dnf install libvpl-2.16.0-1.fc42
Updating and loading repositories:
Repositories loaded.
Package "libvpl-1:2.16.0-1.fc42.x86_64" is
already installed.
Try libvpl-devel ?
Nothing to do.
root@fedora:~# dnf install vulkan
Updating and loading repositories:
Repositories loaded.
Package "vulkan-loader-1.4.313.0-1.fc42.x86_64"
is already installed.
Just in case you can add
?
But may be they were already pulled in ...
if you say --enable-vulkan works.
Nothing
to do.
Problem --with-onevpl:
configure: error: requires onevpl support.
make: *** No targets specified and no makefile
found. Stop.
Andrew, added
"--with vulkan --with-onvpl" to the
configure line. This is what I get in
the log:
checking for
vaGetDisplayDRM in -lva-drm... yes
checking for MFXCreateSession in
-lvpl... no
checking for vkQueueSubmit in
-lvulkan... no
configure: error: requires vulkan
support.
make: *** No targets specified and
no makefile found. Stop.
AND configure: error: requires
onevpl support.
you need to install onevpl-devel
package, and vulkan-sdk ..... (on your build
machine)
Andrew,
did I miss something?
-
I checked into GIT, the
0026-Attempt-at-fixing-prefix-system-install-with-libzmpe.patch,
with the changes to
configure.ac
and Makefile.am.
-
Was there another specific
patch for this? Quote="I
think we traced failure
back to wrong shell used
for our configure (mksh vs
bash)." If so, I missed
it.
No, it should be
enough, just T2's recipe fetch
*release* tarball, not git commit,
so install still fails there, even
if we fixed that in git.
-
I will gladly make a new
test AppImage with
enabling Vulkan, but I
thought that it had to be
built on a computer that
had specific hardware
capabilities. Am I wrong?
or can I just add
"--enable-vulkan" to the
"configure" line? Same
question about ONEVPL?
Well, good question!
While building
cinelerra-10 on T2SDE I noticed
ffmpeg 5.1 for example outright
fail to build with new vulkan
headers (no configure check tight
enough, I guess).
Depending on what
kind of vulkan sdk your build OS
for new appimage have it may or
may not work with different
distros ... I think only way to
test is try!
You also can try to
enable openvpl, and see if it get
pulled into appimage so at least
it starts on system without OneVPL
installed? Mismatches still
possible, with all those moving
parts ...
On
Fri, Jan 30, 2026
at 10:24 PM Andrea
paz via Cin
<cin@lists.cinelerra-gg.org>
wrote:
>
> My Arch has
gcc 15.2.1. The
build from git was
successful without
errors.
> Do I need to
do any specific
tests?
Thanks.
I will try to
replicate this
error, just for
now T2 does not
build on
my Slackware, but
hopefully should
build on itself in
qemu VM ...
I think
we traced failure back
to wrong shell used
for our configure
(mksh vs bash).
Dear
Phyllis, I hope
everything is more
than less ok on your
end?
Can we
make new release so T2
picks our fix for
non-thirdparty
install? While at it
you can try to enable
Vulkan for new
appimage so Terje will
have chance to test
it?