Following up on the memory discussion above, from a device that makes unified memory very visible: an AMD BC-250 (Cyan Skillfish, gfx1013) with 16 GB of unified GDDR6 shared between CPU and GPU.
First, a RustiCL packaging gotcha. On Fedora 44, darktable couldn’t compile basic.cl at all — Internal compilation error: nir_shader not fully linked, so the device was rejected and the OpenCL option stayed greyed out. The cause is that Fedora builds Mesa against upstream libclc rather than the patched mesa-libclc fork RustiCL expects. RustiCL warns about it on stderr, but it’s easy to miss. Building mesa-libclc and rebuilding Mesa against it fixed it entirely. Filed downstream — but worth knowing, since “RustiCL doesn’t work” reports on Fedora may share this cause.
Second, on memory. hannoschwalm noted that RustiCL’s 2 GB MAX MEM ALLOC limits GPU processing to ~125 Mpixel images. On a unified-memory device something else binds much earlier:
GLOBAL MEM SIZE: 16896 MB
MAX MEM ALLOC: 2048 MB
UNIFIED MEM SIZE: 3799 MB reserved
That 3799 MB is about a quarter of system RAM, and it did not change under resourcelevel=large, resourcelevel=unrestricted, opencl_tune_headroom=TRUE, or raising the kernel GTT limit so the device advertised 16.5 GiB instead of 8 GiB.
Exporting a 48 Mpixel raw, denoiseprofile, lens and diffuse all tile (and so blend on CPU), while bilat and hazeremoval fall back to CPU entirely — bilat runs on GPU happily at smaller sizes, so that’s memory pressure rather than a missing kernel. Net result is 1.75× over CPU.
A quarter of system RAM seems a sensible default for an APU sharing DDR, and quite conservative when the GPU has 16 GB of GDDR6 behind it. Is that reservation intentional for unified-memory devices, and would making it configurable be reasonable?
(Minor aside for the RustiCL side: in the tiled export, Read Image (device→host) was the largest single entry in the command queue at 2.0 s of 5.8 s. On a device where CPU and GPU share physical memory, that copy shouldn’t need to happen.)
