Level Zero: back hipMallocManaged with shared USM where host USM has no atomics - #1514
Open
pvelesko wants to merge 6 commits into
Open
Level Zero: back hipMallocManaged with shared USM where host USM has no atomics#1514pvelesko wants to merge 6 commits into
pvelesko wants to merge 6 commits into
Conversation
On Intel Data Center GPU Max (PVC) under Level Zero, hipMallocManaged memory is backed by zeMemAllocHost and PVC host USM has no ATOMIC access capability, so a device atomicAdd on a u32 counter silently leaves it at 0 and a u64 atomic raises AtomicAccessViolation. The test runs the 32-bit and 64-bit kernels separately so the log shows the mismatch before a fault kills the process, and also exercises hipMemAdvise(SetCoarseGrain) and hipMemPrefetchAsync the way Kokkos HIPManagedSpace does. #1489
…tomics On Intel Data Center GPU Max (PVC) zeDeviceGetMemoryAccessProperties reports hostAllocCapabilities = RW (no ATOMIC) while sharedSingleDeviceAllocCapabilities = RW|ATOMIC. hipMallocManaged was always backed by zeMemAllocHost, so device atomics on managed memory silently produced 0 (32-bit) or faulted with AtomicAccessViolation (64-bit), which kills Kokkos HIPManagedSpace and its ScatterView test. Query the memory access capabilities once per device and, only for hipMemoryTypeUnified, allocate with zeMemAllocShared associated with the device when host USM lacks ATOMIC and single-device shared USM has it. Every other device keeps host USM (issues #131 and #1110: shared USM page migration on Arc dGPUs unmapped the host side). CHIP_L0_MANAGED_USM= auto|host|shared overrides the capability gate and the choice is logged at info level. hipHostMalloc stays on host USM. The per-queue SharedBuf_ scratch allocations are now requested as hipMemoryTypeHost, which is the same zeMemAllocHost call they made before, so they never take the managed path (and never need the active device during queue construction). hostNativeAtomicSupported and concurrentManagedAccess are now derived from the queried capabilities instead of being hardcoded, and the comment that claimed zeMemAllocShared was already in use is gone. Fixes #1489
…emoryDeviceAtomics On a coarse-grain SVM device (rusticl/radeonsi on the AMD W6400 CI runner) a plain host store to hipMallocManaged memory is not visible to the device unless it goes through the runtime's clEnqueueSVMMap/Unmap; the test's `C64->Min = ~0ull` was never seen by the kernel, so atomicMin reported 0. That is the documented rusticl managed-memory gap, not the atomics capability this test covers, so the initial values now go through hipMemcpy. Verified on rusticl W6400 and Intel OpenCL CPU.
…shared USM The auto gate for CHIP_L0_MANAGED_USM chose zeMemAllocShared whenever host USM lacked ATOMIC and single-device shared USM had it. Arc A380 reports exactly that (host RW, shared RW|ATOMIC) and the x86 Intel GPU CI lane then crashed in Unit_hipMemFaultStackAllocation_Check with SIGSEGV: without CONCURRENT the driver migrates shared pages by mprotect'ing the host mapping PROT_NONE and resolving the fault in its own SIGSEGV handler, and Catch2's non-chaining fatal-condition handler steals that signal (issue #446). Intel's driver sets CONCURRENT on sharedSingleDeviceAllocCapabilities only when page migration is done by the kernel driver, which leaves the host mapping valid (NEO ProductHelperHw::getSingleDeviceSharedMemCapabilities). Require that bit as well, so the auto gate keeps host USM on Arc and on Data Center GPU Max with the stock driver, and picks shared USM where the driver reports RW|ATOMIC|CONCURRENT (Data Center GPU Max with NEOReadDebugKeys=1 UseKmdMigration=1). CHIP_L0_MANAGED_USM=shared still forces shared USM for applications that need managed-memory atomics on Data Center GPU Max and install no SIGSEGV handler of their own.
…ed memory concurrentManagedAccess was taken from sharedSingleDeviceAllocCapabilities even when hipMallocManaged is backed by host USM, so it described a kind the application never gets. Take it from the capabilities of whichever USM kind managedUsesSharedUsm() selected; hostNativeAtomicSupported stays tied to hostAllocCapabilities since it is about host memory.
…=shared The auto gate now selects shared USM on Level Zero only where the driver reports concurrent access for it, which neither Arc nor Data Center GPU Max does with the stock driver, and on Data Center GPU Max the default host USM has no device atomics at all. Force the shared USM path from CTest so the reproducer for #1489 keeps exercising the code it was written for; the test installs no SIGSEGV handler, so the driver's page migration works in it. Other backends ignore the variable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Intel Data Center GPU Max (Aurora PVC) under Level Zero,
zeDeviceGetMemoryAccessPropertiesreports host USM as RW without ATOMIC while single-device shared USM is RW|ATOMIC.hipMallocManagedwas always backed byzeMemAllocHost, so a deviceatomicAddon managed memory silently produced 0 (32-bit) or faulted withAtomicAccessViolation(64-bit), which kills KokkosHIPManagedSpaceand its ScatterView test.The memory access capabilities are now queried once per device and, only for
hipMemoryTypeUnified, the allocation useszeMemAllocSharedassociated with the device when host USM lacks ATOMIC and single-device shared USM has it. Every other device keeps host USM (issues #131 and #1110).CHIP_L0_MANAGED_USM=auto|host|sharedoverrides the gate,hostNativeAtomicSupportedandconcurrentManagedAccessare derived from the queried capabilities, andTestFixManagedMemoryDeviceAtomicscovers 32-bit and 64-bit device atomics on managed memory including thehipMemAdviseandhipMemPrefetchAsyncpattern Kokkos uses.Fixes #1489