commit 78aefa90c52b489a3195a12434d5f3381dbc536d
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 01:01:43 2026 +0200

media-libs/rocJPEG: new package, add 10.0.0

Hardware JPEG decode on the GPU's VCN block, reached through VA-API, handing
results back as device memory so a decode-then-infer pipeline never round-trips
pixels through the host. ::gentoo carries no rocJPEG. media-libs rather than
sci-libs: it is an image codec that happens to run on the GPU, and it sits next
to media-libs/libva, which it links.

Three configure traps, and every one of them produces a GREEN BUILD:

- GPU_TARGETS must be passed explicitly, and the amdgpu_targets_* IUSE must
exist for that to mean anything. Upstream computes a good
DEFAULT_GPU_TARGETS, but only applies it when GPU_TARGETS is otherwise
unset -- and rocm.eclass makes AMDGPU_TARGETS a USE_EXPAND, so portage
always exports it. Without amdgpu_targets_* in IUSE it is exported EMPTY,
upstream's
if((AMDGPU_TARGETS OR DEFINED ENV) AND NOT GPU_TARGETS)
fires on "defined but empty", and GPU_TARGETS is cached as the empty
string. The later set(GPU_TARGETS "$" CACHE ...) is
then a no-op, since a CACHE set never overwrites an existing entry. The
build then carries no --offload-arch at all and hipcc falls back to its
built-in default, compiling the colour-conversion kernels for gfx906 alone.

The symptom is not a build failure. Decode is VA-API and works, so
ROCJPEG_OUTPUT_NATIVE, _YUV_PLANAR and _Y return correct pixels, while
_RGB and _RGB_PLANAR return ROCJPEG_STATUS_SUCCESS with an all-zero buffer
-- the kernel launch finds no code object for the running GPU and the
error is swallowed. src_install now asserts that device code for every
requested target is present in the built library.

- The entire add_library() is wrapped in
if(HIP_FOUND AND Libva_FOUND AND Libdrm_amdgpu_FOUND AND Threads_FOUND)
with no else and no fatal error. Miss any one and CMake configures, ninja
runs, the ebuild exits 0 and NOTHING is built. src_install asserts
librocjpeg.so exists. libva is floored at 1.22 for the same reason --
rocJPEG version-checks it and, if too old, quietly sets Libva_FOUND back to
FALSE and prints a message.

- HIP must be found in CONFIG mode. Pointing CMAKE_MODULE_PATH at
dev-util/hip's legacy FindHIP module (which is what sci-libs/rocALUTION
needs) is actively WRONG here: it makes find_package(HIP) resolve to the
module, which sets HIP_FOUND but does not define the hip::device imported
target the link line uses, so configure fails at target_link_libraries. It
also leaks into upstream's config-template lookup, because rocJPEG reuses
CMAKE_MODULE_PATH for that too and its set(... CACHE INTERNAL) does not
displace a command-line value. Passing nothing is correct: hip-config.cmake
is found under the default prefix.

Dependencies confirmed against the built artifact: objdump -p on
librocjpeg.so.1.7.0 reports libva.so.2, libva-drm.so.2, libdrm_amdgpu.so.1,
librocprofiler-register.so.0 and libamdhip64.so.7 -- so nothing is undeclared,
and this is the first consumer of dev-libs/rocprofiler-register in the tree.

Run-verified on gfx1150: all five output formats return real data, and the
interleaved RGB decode of a real 980x760 JPEG has a mean pixel value of 247.27
against 247.25 for a CPU decode of the same file through PIL -- the residual
difference being ordinary hardware-vs-software IDCT and chroma upsampling.
gfx1150 device code is confirmed present in the installed library.