Repository navigation
Conversation
Naga declares StorageBuffer16BitAccess and UniformAndStorageBuffer16BitAccess for any f16 type, but the Vulkan backend enabled the matching device features only when cooperative matrix reported f16 shapes. Devices with shaderFloat16 and no f16 cooperative matrix (MI300X on RADV, lavapipe) got f16 shaders declaring features that were never enabled. Report shader_float16 only when both 16-bit storage features are present, and enable them whenever shader_float16 is. The cooperative matrix f16 shapes now key off the same flag, so the old auto-enable is redundant. Taken from the MI300 experiments in #405. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W9jSvpnbXEXmoHFuUVFdUN
There was a problem hiding this comment.
Slop-focused review of 0dcb01c.
-
Keep FP16 arithmetic capability separate from FP16 storage capability. In
vulkan/init.rs,shader_float16now requiresshaderFloat16and both 16-bit storage-buffer features. That changes the meaning of a capability named/documented as shader FP16 support into "FP16 plus this storage layout happens to work." Those are different contracts. Please expose arithmetic/type support independently and gate storage-using shaders on the storage feature they actually need. Cooperative-matrix discovery can then depend on the precise combination required instead of redefining the base capability. -
Keep MI300 bring-up machinery out of the generic project surface. This PR adds ~800 lines of hardware-specific smoke/throughput programs plus scripts with MI300 device ID
0x74b5,RADV_EXPERIMENTAL_CDNA, XCC controls, and default/root/...Mesa/libdrm paths. That is useful bring-up evidence, but it reads like temporary lab infrastructure rather than durable Blade examples. Please keep the reusable correctness probes small/generic and move MI300-specific orchestration/configuration into a dedicated hardware bring-up/test area (or external experiment harness) so normal examples remain representative of the API rather than one machine. -
Isolate the crash-marker barrier if it is a driver workaround.
command.rsnow emits a TRANSFER→TRANSFER buffer barrier before every marker write. If this is needed for AMD marker ordering or a specific driver, document the exact hazard and gate it as narrowly as possible. An unconditional synchronization point in the generic command path is the kind of workaround that becomes permanent and hard to reason about later.
The goal here is not to remove the MI300 work; it is to prevent one bring-up target from redefining core capability semantics and generic command behavior.
No description provided.