AHB fix plus placed-memmory

[abesmon]

TLDR: this one fixes AHB problems (very broken image) plus fixes black screen.

This fix primarely made for nintendo switch running android, but i've tryed to made it as much platform indepedent as i can. This Was heavily tested with dozens of A/B on my switch, but never tested on aby other devices, since i dont have one

---

Summary

This series fixes two independent omissions encountered when a direct Android
hardware-buffer swapchain is used together with the wrapper's emulated placed
memory maps:

1. release exclusive direct-swapchain images to
   VK_QUEUE_FAMILY_FOREIGN_EXT before the Android consumer uses them;
2. retain VkMemoryAllocateInfo::allocationSize in the wrapper memory object
   used by placed mappings.

The commits are kept separate so each invariant and its gating can be reviewed
independently.

1. Release direct AHardwareBuffer images

The Android hardware-buffer specification treats Android producers and
consumers as foreign devices for ownership transfer. Vulkan's queue-family
rules require explicit ownership transfer for external resources; without it,
reads by the second queue family have undefined contents even if memory
dependencies were otherwise expressed.

The first commit pre-records a release command for every usable queue family
and submits the matching command during present. It uses GENERAL as the
shared external layout and a generic memory-write source dependency because
WSI cannot know which application pipeline stage produced the image.

The behavioral change is structurally restricted to Android swapchain images
which are all of the following:

• backed directly by an AHardwareBuffer (WSI_SWAPCHAIN_NO_BLIT);
• created with VK_SHARING_MODE_EXCLUSIVE;
• presented through this Android WSI path.

Concurrent images are excluded because legacy VkImageMemoryBarrier does not
permit the same foreign-family transfer for concurrent sharing, and blit
swapchains keep their existing presentation command path. There is no device,
vendor, application, or Switch-specific check.

Specification references:

• Queue-family ownership transfer
• VK_ANDROID_external_memory_android_hardware_buffer

2. Retain allocation size for placed mappings

wrapper_device_memory::alloc_size is already used to select the backing fd of
a multi-fd AHardwareBuffer and to resolve VK_WHOLE_SIZE, but the emulated
allocation path leaves it zero-initialized. That makes the first seekable
metadata fd look large enough and can produce a successful, truncated mapping.

The second commit stores the authoritative
VkMemoryAllocateInfo::allocationSize when that wrapper memory object is
created. This is a one-line bookkeeping fix. The existing control flow limits
it to the host-visible placed-allocation emulation path with
memoryMapPlaced/VK_EXT_map_memory_placed enabled. Imported, exported,
non-host-visible, and ordinary driver mappings keep their previous behavior.

This also matches the extension's model: VK_WHOLE_SIZE means the remainder of
the Vulkan allocation, and placed-map validity and reservation size are defined
using VkMemoryAllocateInfo::allocationSize.

Specification references:

• VkMemoryMapInfo size and placed-map requirements
• VK_EXT_map_memory_placed proposal and example

Validation

Tested on an NVIDIA Tegra X1 Android device with the proprietary Vulkan ICD.
Every visual verdict below was checked on the physical display; exit status and
FPS were not used as corruption oracles.

Controlled A/B for AHardwareBuffer ownership, five runs per cell:

Workload	Parent	With release
Vulkan 64-bit	0/5 correct	5/5 correct
DX9 64-bit	0/5 correct	5/5 correct

Controlled production A/B for placed mapping, DX9 32-bit, five runs per arm:

Build	Visual result	Selected map size
assignment removed	0/5 correct	4096 bytes (metadata fd)
assignment present	5/5 correct	16777216 bytes (backing fd)

Final two-commit interaction smoke:

• Vulkan 64-bit: correct image, exit 0;
• DX9 64-bit: correct image, exit 0;
• DX9 32-bit: correct image, exit 0;
• instrumented last process recorded three 16 MiB placed maps, two direct
  no-blit swapchains, and six ownership-release barrier recordings.

For every evidence-producing run, the wrapper SHA in the container imagefs was
matched to the build artifact and a unique WRAPPER_LOG_FILE canary plus the
launcher's final guest environment confirmed that the intended binary and
configuration executed.

[utkarshdalal]

Thanks, really solid work, the alloc_size fix is a clear bug fix

On the release barrier: it changes the present path for every device on the direct no-blit path, and on Adreno the PRESENT_SRC -> GENERAL transition may force UBWC decompression, which we can't easily verify across our device base. Could you gate the info->finish_create assignment in wsi_configure_android_image on driverID == VK_DRIVER_ID_NVIDIA_PROPRIETARY (plumbed through wsi_device)? Spec-wise the barrier is probably right everywhere, but I'd rather widen the allowlist as devices prove they need it than risk a fleet-wide regression. Also please drop the per-image "Recorded AHB ownership release barriers" log to debug level.

[abesmon]

just for future generations: this is how bad release look like

I think it could help somebody in future, if similar problem occur

[abesmon]

@utkarshdalal i've pushed update with logs and ENV vars.

now its working this way:

WRAPPER_AHB_OWNERSHIP_RELEASE	Effective policy	Visual result
unset	NVIDIA default: enabled	both correct
false	forced disabled	expected artifacts in both
true	forced enabled	both correct