[stefanatwork]

embree_instanced_geometry_sycl.exe produced wrong (uncolored) output compared to the CPU reference tutorial whenever
RTC_MAX_INSTANCE_LEVEL_COUNT was built as 2 (it matched when built as 1).

Root cause: instance_id_stack::copy_UU() in kernels/common/instance_stack.h filled the instID array using two separate loops with a runtime-variable split point (depth = context->instStackSize):

for (l = 0; l < depth; ++l) tgt[l] = src[l];
for (l = depth; l < MAX; ++l) tgt[l] = RTC_INVALID_GEOMETRY_ID;

On the Intel GPU SYCL/DPC++ toolchain used for the HW raytracing backend, this two-loop pattern gets miscompiled when depth is a runtime value: the copied value and the invalidation marker end up swapped between tgt[0] and tgt[1]. This was confirmed via device-side printf tracing, showing the valid instance id landing in instID[1] instead of instID[0], so ray.instID[0] (the field tutorials/apps actually read) was always RTC_INVALID_GEOMETRY_ID.

This only affects RTC_MAX_INSTANCE_LEVEL_COUNT > 1, because the ==1 case uses a trivial single assignment (tgt[0] = src[0]) with no loop.

Fix: replace the two loops with a single fused loop using a per-element ternary, which avoids the problematic codegen pattern:

for (l = 0; l < MAX; ++l) tgt[l] = (l < depth) ? src[l] : RTC_INVALID_GEOMETRY_ID;

Verified on real Intel Arc B580 hardware: embree_instanced_geometry_sycl.exe built with RTC_MAX_INSTANCE_LEVEL_COUNT=2 now produces pixel-identical output (0 differing pixels) to embree_instanced_geometry.exe (CPU reference), matching the already-correct RTC_MAX_INSTANCE_LEVEL_COUNT=1 build.

[svenwoop]

Approved, but shorten that comment.