How can I control memory for command allocators and command queues in D3D12?
$begingroup$
The D3D12 programming guide suggests specific allocation strategies for command queues and allocators, but the creation methods for those objects operate directly 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?
c++ gpu directx12 memory api
$endgroup$
add a comment |
$begingroup$
The D3D12 programming guide suggests specific allocation strategies for command queues and allocators, but the creation methods for those objects operate directly 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?
c++ gpu directx12 memory api
$endgroup$
add a comment |
$begingroup$
The D3D12 programming guide suggests specific allocation strategies for command queues and allocators, but the creation methods for those objects operate directly 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?
c++ gpu directx12 memory api
$endgroup$
The D3D12 programming guide suggests specific allocation strategies for command queues and allocators, but the creation methods for those objects operate directly 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?
c++ gpu directx12 memory api
c++ gpu directx12 memory api
asked 18 hours ago
Paul FerrisPaul Ferris
1528
1528
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
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.
$endgroup$
$begingroup$
Ah, that makes more sense. Thanks for the quick answer :)
$endgroup$
– Paul Ferris
17 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "633"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcomputergraphics.stackexchange.com%2fquestions%2f8608%2fhow-can-i-control-memory-for-command-allocators-and-command-queues-in-d3d12%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
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.
$endgroup$
$begingroup$
Ah, that makes more sense. Thanks for the quick answer :)
$endgroup$
– Paul Ferris
17 hours ago
add a comment |
$begingroup$
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.
$endgroup$
$begingroup$
Ah, that makes more sense. Thanks for the quick answer :)
$endgroup$
– Paul Ferris
17 hours ago
add a comment |
$begingroup$
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.
$endgroup$
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.
answered 18 hours ago
Nicol BolasNicol Bolas
4,034519
4,034519
$begingroup$
Ah, that makes more sense. Thanks for the quick answer :)
$endgroup$
– Paul Ferris
17 hours ago
add a comment |
$begingroup$
Ah, that makes more sense. Thanks for the quick answer :)
$endgroup$
– Paul Ferris
17 hours ago
$begingroup$
Ah, that makes more sense. Thanks for the quick answer :)
$endgroup$
– Paul Ferris
17 hours ago
$begingroup$
Ah, that makes more sense. Thanks for the quick answer :)
$endgroup$
– Paul Ferris
17 hours ago
add a comment |
Thanks for contributing an answer to Computer Graphics Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcomputergraphics.stackexchange.com%2fquestions%2f8608%2fhow-can-i-control-memory-for-command-allocators-and-command-queues-in-d3d12%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown