Sign in to follow this  

Direct3D 12 Staging Resources

This topic is 1344 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

D3D:
- No more cap-bits (at least, no more new cap-bits), nobody need another extension/capabilities hell...
- Unified virtual memory between CPU and GPU (AMD and NVIDIA are working on that on HSA/hUMA and CUDA 6 respectively, dunno Intel...), this also should resolve what Jason Z is asking... EDIT: intel has a similar thing called "Direct Resource Access"..
- Depth Bounds Test, AMD and NVIDIA have their own extensions...
- Adaptive Order Independent Transparency/Order-Independent Transparency Approximation with Pixel Synchronization... intel did it...
 
DXGI:
-10-bit output in windowed mode (not only in full-screen), 10-bit IPS monitor are becoming common on gamers too (well, fake 10 bit, they are mostly "true 8-bit with A-FRC"..)
-truly working v-sync in windowed mode
 
Tools:
-better hlsl support, with auto-complete  and code analysis ohmy.png Edited by Alessio1989

Share this post


Link to post
Share on other sites

AFAIK, D3D12 is going to support hardware all the way back to 9.3 level, so this would have to work across old and new architectures.

 

Newer devices can just put the resource into a memory location that's mapped in the address space of your CPU project and in the GPU's address space. No staging/copies required (just manual fencing by the application to avoid race conditions).

Older devices will still require you the creation of a CPU staging resource, which the GPU can transfer the data into.

 

So - I guess you'd want this staging resource to be a driver-internal detail, rather than an application detail? Instead, at creation time we tell the driver that we want both CPU & GPU access (which lets the driver create a GPU-local and CPU-staging allocaiton if required), and then at runtime we issue these barriers to tell the driver when to transition from CPU-ownership to GPU-ownership and back. On newer devices, this could be a NOP, but on other devices it would perform the copying between staging resources as required?

 

[edit] The alternative is what mantle is doing, described by the Dice guys here: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Rendering-Battlefield-4-with-Mantle-Johan-Andersson.ppsx

Where the application can choose where resources will be placed -- and would have to implement 'staging' resources themselves (and the required copies) if there was no GPU+CPU mapped heap reported as available by the driver, or if they decide there's no heap that has high enough GPU-write and CPU-read performance.

Edited by Hodgman

Share this post


Link to post
Share on other sites

I think I'm missing something.


Newer devices can just put the resource into a memory location that's mapped in the address space of your CPU project and in the GPU's address space
Ok but the performance level isn't going to be the same. If I understand correctly what you're writing this would solve the issue of which component takes care of syncronization and use but I'm having difficulty in understanding the performance pattern involved.

I mean, suppose I have this resource GPU-only resource and I make it staging. Even on a device that allows mapping of device memory, isn't the access performance going to be very different?

 

I sure understand the problem, but I don't get the solution ticking in my head.

 

Also, why a resource is to be staging in the first place? OpenCL allows host buffers to be bound as kernel outputs, which is a smart thing to do if you're building incremental queues with like .001% chance of a Work Item result to get there.

Again, this methodology does have its own set of issues regarding bandwidth and latency but it sounds good to me. There's no explicit concept of staging in OCL, just the flags and the location (like Mantle, as far as I understand).

Share this post


Link to post
Share on other sites

This topic is 1344 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this