Giovanni Mascellani (@giomasce) commented about libs/vkd3d/command.c:
+ struct d3d12_heap *heap_impl = unsafe_impl_from_ID3D12Heap(heap); + struct vkd3d_cs_op_data *op; + + TRACE("iface %p, resource %p, region_count %u, region_start_coordinates %p, " "region_sizes %p, heap %p, range_count %u, range_flags %p, heap_range_offsets %p, " - "range_tile_counts %p, flags %#x stub!\n", + "range_tile_counts %p, flags %#x.\n", iface, resource, region_count, region_start_coordinates, region_sizes, heap, range_count, range_flags, heap_range_offsets, range_tile_counts, flags); + + if (!region_count || !range_count) + return; + + if (!command_queue->supports_sparse_binding) + { + FIXME("Command queue %p does not support sparse binding.\n", command_queue); I guess the robust solution should be to potentially have a dedicated queue for sparse binding, and then put in place appropriate synchronization when updating mappings? In Vulkan it seems that a device could offer no queue which has both graphics and sparse binding capabilities. With D3D12 is seems that tile updating is always possible on graphics queues.
-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/216#note_35268