Forum Discussion

Forux's avatar
Forux
Explorer
11 days ago

Renderdock Meta Fork For Mac Bug (VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT)

## Description of Bug

This looks like the same underlying bug class as #3571, but on live Android launch/injection instead of when opening a capture.

I have a Vulkan + OpenXR Android app running on Meta Quest 3. The app works normally on-device without RenderDoc. The crash happened only when I launched the app through RenderDoc Meta Fork using the Quest replay context and `Launch Application`.

The app uses app-owned transient MSAA color/depth attachments for the scene pass. On the normal non-RenderDoc path, the app can create those images with a lazily allocated memory type on the same headset and driver.

When the same APK was launched through RenderDoc Meta Fork, the app reached first-frame render setup and then failed while creating the transient MSAA color image. I added app-side Vulkan logging around `vkGetImageMemoryRequirements` and the memory-type selection path, and the injected run showed that the image’s allowed memory types were changed so that the lazily allocated type was no longer permitted.

The exact app-side log from the injected run was:

`ERROR: VULKAN: Failed to find matching image memory type. lazy=1 transient=1 debug_name=scene_msaa_color_image ... required_flags=0x11 memory_type_bits=0x1 ... available_types=#0:heap=0:flags=0x1:matches_required=0`

In other words:

- the image requires `VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT`

- under RenderDoc, `memoryTypeBits` becomes `0x1`

- only memory type `#0` is allowed

- memory type `#0` is only `DEVICE_LOCAL`

- the lazily allocated type is excluded

- image creation fails

- the app traps on first frame

I then created a dedicated RenderDoc-specific build of the same app that changes only one thing: it disables the lazy-allocation request for the app-owned transient MSAA scene attachments, while keeping the same RenderDoc launch path, same headset, same driver, same app logic, and same MSAA topology.

That RenderDoc-specific build launches successfully under RenderDoc Meta Fork.

So the current evidence strongly suggests that RenderDoc changes Vulkan memory-type admissibility for this Android/Adreno workload in a way that excludes the valid lazily allocated memory type that is available and works without RenderDoc.

This seems to be the same root-cause family as #3571:

https://github.com/baldurk/renderdoc/issues/3571

The difference is that my case happens during live Quest Android launch/injection, not when opening a capture for replay.

I cannot share the app publicly right now, but I can provide private logs and, if needed, a private APK or a reduced repro.

## Steps to reproduce

1. Use a debuggable Vulkan Android app on Quest 3 that creates app-owned transient MSAA scene attachments and requests `VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT` for them.

2. Confirm the app launches and renders normally on-device without RenderDoc.

3. Connect Quest 3 to RenderDoc Meta Fork over ADB.

4. Select the normal `Oculus Quest 3` replay context.

5. Use `Launch Application` to launch the APK from RenderDoc Meta Fork.

6. Let the app reach first-frame rendering.

7. The app crashes before normal rendering continues.

8. Check app-side logcat output around the Vulkan image creation path.

Observed result:

- under RenderDoc launch/injection, the transient MSAA color image gets `memoryTypeBits=0x1`

- the lazy memory type is excluded

- image creation fails on first frame

Expected result:

- RenderDoc should not change the image memory requirements in a way that excludes the lazily allocated memory type when the same app and same headset/driver work correctly without RenderDoc

Additional confirmation:

- a build that disables only the lazy-allocation request for those app-owned transient MSAA scene attachments launches successfully under RenderDoc on the same headset/driver

- this workaround is not the desired final app behavior, but it isolates the failure to RenderDoc’s interaction with the lazy memory type requirement

I can privately share the exact logcat excerpt and tombstone if helpful.

## Environment

* RenderDoc version: RenderDoc Meta Fork v68.15 (forked from v1.41)

* Operating System: macOS host, Quest 3 device on Android 14 / Horizon OS

* Graphics API: Vulkan (OpenXR app on Android)

Additional details:

- Device: Meta Quest 3

- GPU: Adreno 740

- Driver seen by the app/RenderDoc path: Adreno 740, driver 512.837 patch 0x6

- App is debuggable/profileable and launches correctly without RenderDoc

- Crash happens only when launched through RenderDoc Meta Fork

- The RenderDoc-specific workaround build succeeds if the app stops requesting `VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT` for the transient scene MSAA attachments

1 Reply

  • Degly's avatar
    Degly
    Start Partner

    Looking at some info online and after some research it does seem that RenderDoc does not reliably support VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT, especially on tiled GPUs (Adreno), and it can alter memoryTypeBits during injection.

    I think that you should keep your current workaround 

    if (isRenderDoc)

    disable VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT;

    And detect RenderDoc via:

      • VK_LAYER_RENDERDOC_Capture
      • or env/debug flags

    You will have to disable it for capture/debug builds though

→ Find helpful resources to begin your development journey in Getting Started

→ Get the latest information about HorizonOS development in News & Announcements.

→ Access Start program mentor videos and share knowledge, tutorials, and videos in Community Resources.

→ Get support or provide help in Questions & Discussions.

→ Show off your work in What I’m Building to get feedback and find playtesters.

→ Looking for documentation?  Developer Docs

→ Looking for account support?  Support Center

→ Looking for the previous forum?  Forum Archive

→ Looking to join the Start program? Apply here.

 

Recent Discussions