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.
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
[Bug]: DG2 A380 VAAPI doesn't work #1487
Comments
As further information, I was not able to replicate this issue on fedora. it seems to work on that |
More information. Installed ffmpeg-git intel-media-driver-git linux-git linux-firmware-git on arch virtual machine via chaotic AUR. using VAAPI decode on netflix's chimera results in KVM crash on qemu. am experincing similar crashes when using cartwheel
|
A similar crash is now happening in fedora VM
|
what |
Sorry for the late reply, I cannot check the sPC right now since it's running stable linux and I won't be able to reset it until later, however the KVM output of dmesg is this
|
Is that all that you see when the error happens? Btw. I'm assuming you're using KVM PCI pass-through. Regarding this:
You should not be overriding GuC option, unless driver maintainer asks you to do that (I'm not a driver maintainer, just another user). HuC not being supported sounds suspicious though. Related kernel code is here:
But I do not see from that why it would not be supported. |
Correct it is KVM PCI passthrough, I don't have the messages from the crash. that is a dmesg of a fresh boot. enable_guc=3 is what the driver is choosing, the only overrides I am preforming are Although, after some more testing I am getting a similar KVM crash when trying to copy from card to... anything else. for instance, running waypipe headless will have a similar crash, DRI_PRIME sometimes also has a crash, so I'm assuming the issues i'm having are not something to do with vaapi driver. can't say for certain though so i'm leaving the issue open for now, I plan on filing a bug report later, but have not yet had the time. |
What you mean by driver here:
If latter, enabling HuC although it's not supported would make what the kernel is doing even more suspicious => file bug: https://gitlab.freedesktop.org/drm/intel/-/issues |
someone already brought it up... somewhere, I came across the report and it was acknowledged at least, I just shoved it off the the side of my mind since it seems to fail elegantly and doesn't (at least I hope it's not) posing any issue. if I come across the issue again ill chime in for sure though |
you could check /sys/kernel/debug/dri/0/i915_params/enable_guc , it will show current enable_guc parameter |
seems like Im still getting the vaapi issue but my vulkan and other kernel issues seem to have cleared up with now running stable linux 6.0 |
For better dGPU support than what's in upstream 6.x kernels, install kernel DKMS driver(s) as documented here: https://dgpu-docs.intel.com/installation-guides/index.html |
I guess I can try that if I can get a way to download it, so far I have tested arch's zen kernel, arch's regular kernel, and a clean build of https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux. and all present the same problem while using both arch's libva and intem-media-driver as well as building from git |
You wont be able to test this on arch using any typical packages since the only working kernel is afaik unreleased and all the required patches in this have not yet been submitted or accepted by upstreams (drm-next / torvalds), intel instead provides dkms based i915 drivers based on various vendor's stable kernels for you to use. I have tried to package the ubuntu OEM kernel mentioned above and the associated backported i915 driver here https://github.com/kkartaltepe/intel-dg2-arch However it seems that this kernel is not compatible with the latest stable mesa or my inexperienced packaging of linux has resulted in something terrible. When booting I see
Which seems correct except for However any attempt to use mesa from here results in a crash during screen creation in the iris driver (tested mesa git as of a few days ago and mesa 22.2.1 the current arch package as of a few days ago). Though this probably isnt the place for support with mesa or the backports driver if anyone has any ideas id love to hear them. --- edit
|
Ah I have discovered the answer to my question at least, the ubuntu 22.04 backports have intentionally disabled gem_create_ext ioctls that are used in mesa releases from the past year and that this functionality isnt complete in the backports kernel even if you remove the disabling statements. Likely the mesa releases on ubuntu 22.04 dont have this relatively new feature so backports simply disabled it here https://github.com/intel-gpu/intel-gpu-i915-backports/blob/ubuntu/main/drivers/gpu/drm/i915/gem/i915_gem_create.c#L715 I would hope that media-driver team could provide a reference to a compatible kernel that also works with modern mesa, but perhaps there simply isnt one. --- edit |
Still haven't been able to get this to work, it's a real head scratcher, |
h264 encode and decode and av1 decode worked for me on the appropriate backports driver/kernel/mesa/libva. However it seems intel has not upstreamed an ffmpeg implementation of av1 encode (and i could not find any ffmpeg forks from them) so I was unable to test that. |
sadly I wasn't able to get backports to install on zen, vanila or linux LTS here is the log if you happen to be interested, ill look at it later, ill also try the kernel later too thanks for the pkgbuid however. you probably want ffmpeg-carthweel, here is a pkgbuild for it, should work just rename it, and you also probably need to tweak it a bit |
You could try "libvpl-tools" + "libmfxgen1" from Intel package repo. Its "sample_multi_transcode" tool seems to support AV1 encoding: https://github.com/oneapi-src/oneVPL/blob/master/tools/legacy/sample_multi_transcode/src/transcode_utils.cpp#L132 (oneVPL is the frontend/loader, "libmfxgen1" is the backend from: https://github.com/oneapi-src/oneVPL-intel-gpu) |
Cheers, managed to get it working using the ubuntu kernel and dkms, AV1 rarely seems to decode fast enough for some reason, but it seems spotty, ffmpeg vaapi encoding works great with av1 however when buidling ffmpeg cartwheel, I havent tested onevpl yet |
Thanks i might try that if i cannot get the carwheel patches running
Awesome i did not know about this repo, they do have an av1_vaapi patch staged https://github.com/intel-media-ci/cartwheel-ffmpeg/blob/master/patches/0071-lavc-vaapi-support-av1-encode.patch ---edit And building it looks good I can get 400fps av1 encoded with cqp, though the CBR example appears broken on my machine with the encoder failing after sending a few frames to the encoder with |
im getting the same encoding error with cbr and vbr, |
@Tianhaol could you take a look? |
I’ve got everything work on A380 (dec, enc, vpp) with upstream kernel 🎉 Prod/backport KMD is not required anymore if you run with the latest drm-tip kernel, firmware, media-driver and onevpl. Check with Guc and Huc must be correctly loaded so as you can use the CBR and VBR rate controls. Current mainline kernel has an issue on DG2 firmware loading, so you need drm-tip.
I’m on Arch, so it’s trivial to build all these. Good luck ;) |
Confirming things look like they are working (including CBR now) on an A750 with drm-tip kernel and current upstream git heads for the related userspaces. Though it seems no av1 encode patches have been merged into ffmpeg yet so cartwheel is still needed there. |
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc_av1.c QSV AV1 encoder was merged into the mainline in October. |
Ah so it was, sorry we were just using vaapi instead which has not been merged. I do see the qsv enc/dec though. |
That make sense. But you can derive an qsv surface from vaapi surface easily: |
To those referring to "latest" media-driver, do you mean |
22.6.4 or newer works for me. 22.5.x doesn't work. Edit: 22.6.5 and 22.6.6 have a regression on DG2, use 22.6.4 or 23.1.0+. |
Can this be closed now? If not, at least the bug title should be changed to reflect what exactly does not work, and on which HW with which kernel version... |
Not working on my A750.
It does appear to be using CPU decoding. |
Linux 6.1 doesn’t support Arc. |
What do you mean? It detects and loads the i915 device for it, and loads most of the firmware. What, do I need some sort of AUR packaged drm-next kernel? Disregard this, I’ve switched to Windows 11 anyway. E: oh, proprietary OEM kernels and gpu drivers. May as well just run windows instead. |
Yes, we reported our results with the so-called drm-tip kernel repository and you were using a different one. Since changes in drm-tip typically make it into the next upstream linux release, one might say your kernel was too old. It has nothing to do with proprietary kernels and gpu drivers, just that you were using the wrong kernel. Though intel also distributed sources that allowed you enable this functionality prior to upstream linux accepting intel's driver updates, if you wanted to build the kernel and userspace yourself. |
Sorry for being rude. I was just disappointed with what I experienced, and didn't really understand that even the current stable release was missing vital changes that were still in drm-next. If there's ever a next time, I'll be sure to run that until the API stabilizes. |
@kode54 Phoronix news site is pretty good at reporting Linux driver news from different vendors. It e.g. told that full Intel dGPU support was accepted to upstream only in Linux v2.6-rc (i.e. few days ago): https://www.phoronix.com/news/Linux-6.2-rc1-Released And it has tested and tracked that driver support before it was in upstream (using drivers from Intel's public source / package repositories). |
Thank you very much for informing me. I will cease bumping this issue after this, as my initial post was so much noise from using an incomplete DRM implementation. If I install Linux for desktop use again on this machine, I will be sure to wait for 6.2, or use a 6.2 RC kernel, as my preferred custom kernel already supports building the 6.2 RC. |
Sorry for taking so long, I had this put on the back burner, its working for me on kernel 6.2 RC2 so Ill go ahead and close this for now, Thanks! |
Please reopen, 22.6.6 is also broken on DG2. Currently running linux-drm-next-git 6.2.0-rc2-2-drm-next-git-00684-g0b45ac1170ea. 22.6.4 works, though. |
No need to reopen. 22.6.5 and 22.6.6 are two faulty versions for DG2. The latest release is 23.1.0: |
I had no idea v23 was even a thing yet. Edit: Oh, right, the version numbers are tied to the year. |
Which component impacted?
Decode, Encode
Is it regression? Good in old configuration?
No
What happened?
VAAPI does not work on A380 on either ffmpeg or gstreamer
What's the usage scenario when you are seeing the problem?
Transcode for media delivery, Playback
What impacted?
both FFMPEG and Gstreamer are effected, making this effect mpv, vlc, etc.
Debug Information
Arch Linux
Kernel 6.0.0-rc4-1-git-00302-gb96fbd602d35
Intel Media Driver Git 2022.5.3.r76.g45c0eb1df-1
Libva-git-2.2.1.pre1.20180921.r6.gcf11abe-1
ffmpeg-git 5.2.r108102.g60d8c2019f-1 OR ffmpeg-git-5.2.r108117.g2cfc4ac2b3-1-x86_64.pkg.tar.zst from ffmpeg-cartwheel
AVC vaapi playback
avc.tar.gz
VP9 vaapi playback
vp9.tar.gz
Av1 vaapi playback
av1-libva.log
Do you want to contribute a patch to fix the issue?
No response
The text was updated successfully, but these errors were encountered: