Vulkan memory coherence guarantees when HOST_VISIBLE without HOST_COHERENT

Problem Statement

The Vulkan specification defines VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT as allowing CPU access to memory, but leaves cache coherency behavior implementation-defined when HOST_COHERENT is not set. This creates uncertainty for applications targeting multiple GPU vendors where memory types may or may not require explicit flush/invalidate operations.

Key Constraints

• VK_MEMORY_PROPERTY_HOST_COHERENT_BIT is not guaranteed on all memory types
• AMD drivers have exhibited bugs requiring explicit operations even with coherent flags
• NVIDIA drivers historically showed inconsistent multi-threaded behavior
• The spec does not mandate automatic coherency for HOST_VISIBLE memory

Relevant Documentation

According to the Vulkan 1.3 specification, memory barriers (VK_MEMORY_BARRIER) are required for correct host-device synchronization regardless of memory type selection. The VK_KHR_get_memory_requirements2 extension provides tools for runtime detection of memory properties.

Unresolved Behavior

Applications cannot reliably assume HOST_VISIBLE memory is coherent across different vendor implementations and driver versions without explicit runtime testing. This raises questions about portable memory management strategies.

Questions

1. Should applications always implement explicit flush/invalidate paths for HOST_VISIBLE memory regardless of HOST_COHERENT flag presence?
2. How can runtime detection reliably determine whether a given memory type requires explicit cache management operations?
3. What is the recommended pattern for handling vendor-specific memory coherence differences without performance penalties?