<p>You don't.</p>

<p>These objects typically work with CPU memory, not device memory. And to the extent that they involve device memory, such allocations tend to be rare and/or fixed in size (a queue may have a small spot of device memory that the hardware queue reads commands from or something, but even that is implementation-dependent).</p>

<p>Vulkan allows you to give objects which may allocate non-device memory allocation parameters to allow you to allocate said memory for them. But even then, there is no <em>guarantee</em> that they will always allocate memory through your functions. Such systems can bypass your allocation routines, and only tell you allocator that it is allocating X bytes of memory (this is typically done for memory pages that have to be allocated in a special way). It doesn't let you actually provide it.</p>

<p>That documentation does not seem to be talking about controlling how those objects allocate memory, but when and how you <em>create</em> those objects. Command allocators and queues are critical, so you create X allocators and Y queues at the start and keep them around forever.</p>

CC BY-SA 4.0
2019-02-18T00:00:48.247Z
Ah, that makes more sense. Thanks for the quick answer :)
Paul Ferris
CC BY-SA 4.0
2019-02-17T23:39:20.707Z
2019-02-17T23:39:20.707Z
Nicol Bolas
<p>The D3D12 programming guide suggests specific <a href="https://docs.microsoft.com/en-us/windows/desktop/direct3d12/memory-management-strategies" rel="nofollow noreferrer">allocation strategies</a> for command queues and allocators, but the creation methods for those objects <a href="https://docs.microsoft.com/en-us/windows/desktop/api/d3d12/nf-d3d12-id3d12device-createcommandqueue" rel="nofollow noreferrer">operate</a> <a href="https://docs.microsoft.com/en-us/windows/desktop/api/d3d12/nf-d3d12-id3d12device-createcommandallocator" rel="nofollow noreferrer">directly</a> on queue/allocator pointers without taking a heap and an offset as an argument. How do I explicitly mark the memory I want to use for command processing?</p>

<c++><gpu><directx12><memory><api>
How can I control memory for command allocators and command queues in D3D12?
Paul Ferris
# How can I control memory for command allocators and command queues in D3D12?

(Asked by: username_0 on 2019-02-17)

The D3D12 programming guide suggests specific [allocation strategies](https://docs.microsoft.com/en-us/windows/desktop/direct3d12/memory-management-strategies) for command queues and allocators, but the creation methods for those objects [operate](https://docs.microsoft.com/en-us/windows/desktop/api/d3d12/nf-d3d12-id3d12device-createcommandqueue) [directly](https://docs.microsoft.com/en-us/windows/desktop/api/d3d12/nf-d3d12-id3d12device-createcommandallocator) on queue/allocator pointers without taking a heap and an offset as an argument. How do I explicitly mark the memory I want to use for command processing?

**Tags:** c++, gpu, directx12, memory, api


---

## 1 answers

### Answer by username_1 on 2019-02-17. Score: 2 | Accepted answer

You don't.

These objects typically work with CPU memory, not device memory. And to the extent that they involve device memory, such allocations tend to be rare and/or fixed in size (a queue may have a small spot of device memory that the hardware queue reads commands from or something, but even that is implementation-dependent).

Vulkan allows you to give objects which may allocate non-device memory allocation parameters to allow you to allocate said memory for them. But even then, there is no *guarantee* that they will always allocate memory through your functions. Such systems can bypass your allocation routines, and only tell you allocator that it is allocating X bytes of memory (this is typically done for memory pages that have to be allocated in a special way). It doesn't let you actually provide it.

That documentation does not seem to be talking about controlling how those objects allocate memory, but when and how you *create* those objects. Command allocators and queues are critical, so you create X allocators and Y queues at the start and keep them around forever.

> **Comments:**
> **username_0**: Ah, that makes more sense. Thanks for the quick answer :)  

---

