[Regression] D3D11VA to OpenCL interop is completely broken in 5186_5234 driver #680
Comments
|
Can you take a look at this DX11 regression? @Arturo-Intel |
IGCIT
added
Type: Regression
|
@nyanmisaka on it! |
|
Still an issue in the 5194_5252 driver released on 2/8/2024. |
|
Still an issue in the 5330 driver released on 2/17/2024. |
|
Still an issue in the 5333 driver released on 2/26/2024. @Arturo-Intel May I get an update on this? Has the issue been reproduced? Or is it being processed by Intel and I should stay tuned? If not, you can simply pass the following content to the corresponding DX11 developer. Thanks in advance. // Sharing of arrays of NV12 D3D11 2D textures to OpenCL is broken.
// This is supported via [cl_intel_d3d11_nv12_media_sharing] extension.
// Prepare D3D11 textures for sharing.
D3D11_TEXTURE2D_DESC texDesc = {
.Width = 1920,
.Height = 1080,
.MipLevels = 1,
.Format = DXGI_FORMAT_NV12,
.SampleDesc = { .Count = 1 },
.ArraySize = 10, // greater than 1, arrayed textures
.Usage = D3D11_USAGE_DEFAULT,
.BindFlags = D3D11_BIND_DECODER, // bind decoder
.MiscFlags = D3D11_RESOURCE_MISC_SHARED, // shared resource
};
...
// Create OpenCL image from the shared D3D11 textures.
// github.com/FFmpeg/FFmpeg/blob/69dd1ce610fcffec453a0663c613c9b13165fd9e/libavutil/hwcontext_opencl.c#L2623-L2642
for (i = 0; i < frames_priv->nb_mapped_frames; i++) {
AVOpenCLFrameDescriptor *desc = &frames_priv->mapped_frames[i];
desc->nb_planes = nb_planes; // NV12, nb_planes = 2
for (p = 0; p < nb_planes; p++) {
UINT subresource = 2 * i + p; // As per [cl_intel_d3d11_nv12_media_sharing]
desc->planes[p] =
device_priv->clCreateFromD3D11Texture2DKHR(
dst_dev->context, cl_flags, src_hwctx->texture,
subresource, &cle);
if (!desc->planes[p]) {
av_log(dst_fc, AV_LOG_ERROR, "Failed to create CL "
"image from plane %d of D3D texture "
"index %d (subresource %u): %d.\n",
p, i, (unsigned int)subresource, cle);
err = AVERROR(EIO);
goto fail;
}
}
}
... |
|
@nyanmisaka Thank you for sharing this, I will add it to the report. It's WIP at the moment. I will share any news through this thread. :) |
|
@nyanmisaka can you share me the whole homebrew code to reproduce this behavior, with this we can push harder into the priority queue :) |
|
@Arturo-Intel FYI I forwarded the issue to oneVPL repo because people there are more familiar with this, and now the issue has been fixed in the latest driver 31.0.101.5592. |
|
I am a complete N00b in this area of graphics, but I've been working with computers since 1978, so there's that. I have an Asus / Intel NUC that has a Core i7-9850H with associated Intel UHD Graphics 630. I'm experiencing exactly this issue under Windows 11 with Jellyfin when I enable GPU transcoding. If I disable transcoding and leave it to the CPU, no problems. Unfortunately, I have tried the earliest driver available to me 30.0.101.1660, the latest validated by Microsoft for their driver installation 30.0.101.2110, a newer version 30.0.101.2121, and the absolute latest available from the intel website, 30.0.101.2128. None of them resolve this problem. Clearly the fix applied to the drivers for the Intel Arc A380 Graphics need to be applied to the Intel UHD Graphics 630 drivers for the NUC. But I have no idea how to "cross-post" this bug report to get it addressed. I'm happy to even provide ffmpeg logs and such, but not sure the best place and way to do so. |
I also have a UHD 630, these older gfx/drivers are not affected as they stopped receiving functional updates over a year ago, only security fixes. |
Thanks for the quick reply! Sigh. I really, really don't know what I was thinking when I recently bought this NUC (new in box). In all my years in the IT industry, my experience is that Intel is absolutely horrible at software and long-term support. You'd think I'd learn. |
Jump on Linux and call it a day ;) |
|
OK, wait -- what? I've used Unix / Linux longer than I've used Windows. I use both these days. The NUC came pre-loaded with Windows 11. But I don't see what that has to do with anything. Are you saying that Intel provides driver support for a longer period of time on Linux than Windows? Or are you saying that people have reverse-engineered the Intel UHD Graphics 630 hardware and written Linux open source drivers without Intel assistance? |
That's right. Intel's user-mode (iHD/Mesa/compute-runtime) and kernel-mode drivers (i915) on Linux are open source, so end users can still benefit from regular updates. |
Wow -- surprising. Thank you for all the information! |
Checklist [README]
Application [Required]
FFmpeg / Jellyfin Media Server
Processor / Processor Number [Required]
AMD Ryzen 7 5700G
Graphic Card [Required]
Intel Arc A380 Graphics
GPU Driver Version [Required]
31.0.101.5186
Other GPU Driver version
No response
Rendering API [Required]
Windows Build Number [Required]
Other Windows build number
No response
Intel System Support Utility report
igcit_ssu.txt
Description and steps to reproduce [Required]
Prepare a 1080p or 4k video. It can be any common video format such as H.264, HEVC or AV1.
Download and unzip the jellyfin-ffmpeg6 6.0.1-1, which is the video transcoder of Jellyfin Media Server.
Run the following command in CMD or PowerShell:
You can observe the utilization in
GPU->VideoDecodeandGPU->Computein Task Manager. Note that on a multiple Intel GPU system, if the Arc discrete GPU is not being used, please disable UHD integrated graphics and try again.After the
ffmpeg.exeprocess is exited, play the output fileC:\green_broken.mp4. It should be totally green, which means the empty YUV data was encoded.Downgrade the driver to the old version 5085_5122, re-do the above procedures, you can get back the correct video instead of a green screen.
Device / Platform
No response
Crash dumps [Required, if applicable]
No response
Application / Windows logs
During FFmpeg transcoding, you can observe that the real-time bitrate is always close to 0. This means that the YUV data is empty, that is, the D3D11VA to OpenCL interop failed.
The 5186_5234 driver is advertised as improving performance for many DX11 games, so I have reason to suspect that these optimizations also break the ability to share textures between D3D11VA and OpenCL.
In some cases, Jellyfin Media Server needs to use OpenCL to post-process the D3D11VA decoded video.
The text was updated successfully, but these errors were encountered: