Hardware tone mapping fails on Intel Arc A310 (DG2): bundled OpenCL runtime doesn't recognise the GPU

[blurbery 0]

Hardware tone mapping fails on Intel Arc A310 (DG2): bundled OpenCL runtime doesn't support the GPU

Hi all,

Hardware tone mapping fails on my Intel Arc A310 because the Intel OpenCL runtime bundled with 4.10 doesn't recognise Arc (DG2 / Alchemist) GPUs. Details below, including a test with Intel's official runtime showing that the card and Emby's tone mapping pipeline both work once the runtime supports the GPU.

Setup

• Emby Server 4.10.0.40 in Docker (linuxserver/emby image), Linux kernel 7.0.6, i915 driver
• Intel Arc A310 LP (DG2 / Alchemist), PCI ID 8086:56A6 rev 05, passed through as /dev/dri/renderD128
• Hardware acceleration: Advanced. QuickSync and VA-API decoding and encoding work well (H.264 and HEVC, 8x+ real-time)
• The Intel runtime prints "Small BAR detected" for this card

Problem
With "Enable hardware tone mapping" turned on, every HDR10 transcode fails. Emby builds this pipeline:

hevc_qsv > vpp_qsv > setparams > hwmap (derive OpenCL) > tonemap_opencl > hwmap (QSV) > h264_qsv / hevc_qsv

ffmpeg then fails with:

    Failed to get number of OpenCL platforms: -1001.
    Failed to created derived device context: -19.
    Failed to configure output pad on hwmap
    Error reinitializing filters!

Emby falls back to full software transcoding (libx264, or libx265 when HEVC encoding is on). For 4K HDR10 that runs at 0.02 to 0.04x real-time, so playback is unusable. With tone mapping off, the same files transcode normally on the GPU, just without tone mapping. The hardware detection log also reports OpenCL platforms: -1001.

Cause
Running Emby's bundled clinfo with Intel's debug output turned on:

    cd /app/emby
    LD_LIBRARY_PATH=/app/emby/lib OCL_ICD_VENDORS=/app/emby/etc/OpenCL/vendors \
    NEOReadDebugKeys=1 PrintDebugMessages=1 /app/emby/bin/clinfo -l

    FATAL: Unknown device: deviceId: 56a6, revisionId: 0005

Both bundled runtimes reject the device: libigdrcl.so (compute-runtime 25.18) and libigdrcl_legacy1.so (24.35). Intel's official 25.18.33578.6 release lists Alchemist as a supported platform, and the bundled libigdrcl.so is about 3 MB smaller than Intel's build. It looks as if DG2 was left out of the bundled build.

Test with Intel's official runtime

• Intel's official 25.18.33578.6 libigdrcl.so won't load in Emby's environment: it needs GLIBC_2.38, and Emby's bundled glibc is 2.34.
• Intel's official 24.35.30872.22 libigdrcl.so (from intel-opencl-icd_24.35.30872.22_amd64.deb, checksum verified against the release) needs only GLIBC_2.34. It links against libigc.so.1, libigdfcl.so.1 and libigdgmm.so.12, which Emby already bundles. Loaded with OCL_ICD_FILENAMES alongside Emby's own libraries:

      Platform #0: Intel(R) OpenCL Graphics
       `-- Device #0: Intel(R) Arc(TM) A310 LP Graphics

• I ran Emby's exact tone mapping filter chain (copied from Emby's own transcode log) with Emby's bundled ffmpeg and that runtime, converting HDR10 to 1080p SDR:
•   4K HDR10 to H.264: 1.65x. To HEVC: 1.6x
•   1080p HDR10 to H.264: 2.4x. To HEVC: 3.5x
•   No errors and no software fallback.

So the card and Emby's pipeline are fine. Only the bundled runtime is missing DG2 support.

Related: VA-API native tone mapping isn't used
Hardware detection marks the VA-API decoders on this card as SupportsNativeToneMapping: true, but only QSV encoders are offered. With the HEVC VA-API decoder set to a higher priority than QSV, Emby still routes tone mapping through OpenCL (vaapi > hwmap > qsv > hwmap > tonemap_opencl) and fails the same way. A manual VA-API-only test with Emby's ffmpeg (scale_vaapi > tonemap_vaapi > h264_vaapi) converts 4K HDR10 to 1080p SDR at about 2.5x.

Requests

1. Include DG2 / Alchemist support in the bundled Intel compute-runtime.
2. When hardware detection reports no OpenCL platform, don't build an OpenCL tone mapping pipeline that is certain to fail and drop to software. Either transcode on the GPU without tone mapping, or use VA-API native tone mapping where detection reports it as supported.
3. Minor: the tonemap_opencl step doesn't set output primaries or matrix, so the SDR output keeps BT.2020 tags (bt2020nc/bt2020/bt709). Adding p=bt709:m=bt709 would give clean BT.709 output.

Other notes

• The linuxserver start script doesn't set NEOReadDebugKeys=1 / OverrideGpuAddressSpace=48 the way Emby's own emby-server launcher does. I tested with both set, and it isn't the cause here.
• Happy to test a beta build or provide more logs.

Thanks!

[Luke 43389]

Hi @blurberywe will have ffmpeg updated on the beta channel very soon, so stay tuned for that. Thanks.