Add Queue::submit() for command buffer submission#1057
Open
Add Queue::submit() for command buffer submission#1057
Queue::submit() for command buffer submission#1057Conversation
Command buffer creation and management was previously spread across each backend's executeProgram() with no shared interface, making it impossible to manage command buffers from backend-agnostic code. This introduces a CommandBuffer base class on Device so that higher-level code can create and pass around command buffers without knowing the backend. Per-object allocator/pool ownership also prepares for future async execution where multiple command buffers may be in-flight with independent lifetimes. - DX: DXCommandBuffer owns Allocator, CmdList, Fence, Event - VK: VKCommandBuffer owns CmdPool, CmdBuffer; each submission creates a new CommandBuffer for independent lifetime management - MTL: MTLCommandBuffer wraps MTL::CommandBuffer Device::createCommandBuffer() returns Expected<unique_ptr<CommandBuffer>> with a default "not supported" implementation. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Move command buffer submission logic from each backend's Device into Queue::submit(), which takes ownership of the command buffers. For now it blocks internally until completion; a TODO marks that it will return a Fence once the Fence abstraction from PR llvm#1007 is available. - Metal: commit() + waitUntilCompleted() - Vulkan: vkEndCommandBuffer() + vkQueueSubmit() with temporary fence + vkWaitForFences() - DX12: CmdList::Close() + ExecuteCommandLists() + Queue::Signal()/Fence::SetEventOnCompletion() wait VulkanQueue now stores a VkDevice handle (with a TODO for lifetime management) so it can create/destroy fences independently. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Comment on lines
+327
to
+332
| ComPtr<ID3D12Fence> Fence; | ||
| #ifdef _WIN32 | ||
| HANDLE Event = nullptr; | ||
| #else // WSL | ||
| int Event = -1; | ||
| #endif |
Contributor
There was a problem hiding this comment.
Let's merge the abstract fence PR (#1007 ) first and then use it here instead of using API specific fences/timeline semaphores.
Contributor
Author
|
Looks like this needs some more TLC, from CI: |
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
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.
Depends on #1033
Move command buffer submission logic from each backend's
DeviceintoQueue::submit(), which takes ownership of the command buffers. For now it blocks internally until completion; a TODO marks that it will return aFenceonce theFenceabstraction from PR #1007 is available.commit()+waitUntilCompleted()vkEndCommandBuffer()+vkQueueSubmit()with temporary fence +vkWaitForFences()CmdList::Close()+ExecuteCommandLists()+Queue::Signal()/Fence::SetEventOnCompletion()waitVulkanQueuenow stores aVkDevicehandle (with a TODO for lifetime management) so it can create/destroy fences independently.Co-Authored-By: Claude Opus 4.6 (1M context) [email protected]