• 12
• 10
• 10
• 13
• 10
• ### Similar Content

• By Krypt0n
Finally the ray tracing geekyness starts:
https://blogs.msdn.microsoft.com/directx/2018/03/19/announcing-microsoft-directx-raytracing/

https://www.remedygames.com/experiments-with-directx-raytracing-in-remedys-northlight-engine/
• By lubbe75
What is the best practice when you want to draw a surface (for instance a triangle strip) with a uniform color?
At the moment I send vertices to the shader, where each vertice has both position and color information. Since all vertices for that triangle strip have the same color I thought I could reduce memory use by sending the color separate somehow. A vertex could then be represented by three floats instead of seven (xyz instead of xys + rgba).
Does it make sense? What's the best practice?

• Hey all,
I'm trying to understand implicit state promotion for directx 12 as well as its intended use case. https://msdn.microsoft.com/en-us/library/windows/desktop/dn899226(v=vs.85).aspx#implicit_state_transitions
I'm attempting to utilize copy queues and finding that there's a lot of book-keeping I need to do to first "pre-transition" from my Graphics / Compute Read-Only state (P-SRV | NP-SRV) to Common, Common to Copy Dest, perform the copy on the copy command list, transition back to common, and then find another graphics command list to do the final Common -> (P-SRV | NP-SRV) again.
With state promotion, it would seem that I can 'nix the Common -> Copy Dest, Copy Dest -> Common bits on the copy queue easily enough, but I'm curious whether I could just keep all of my "read-only" buffers and images in the common state and effectively not perform any barriers at all.
This seems to be encouraged by the docs, but I'm not sure I fully understand the implications. Does this sound right?
Thanks.
• By NikiTo
I need to share heap between RTV and Stencil. I need to render to a texture and without copying it(only changing the barriers, etc) to be able to use that texture as stencil. without copying nothing around. But the creating of the placed resource fails. I think it could be because of the D3D12_RESOURCE_DESC has 8_UINT format, but D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL enabled too, and MSDN says Stencil does not support that format. Is the format the problem? And if the format is the problem, what format I have to use?

For the texture of that resource I have the flags like: "D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET | D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL" and it fails, but when I remove the allow-stencil flag, it works.

• I know vertex buffer is just another GPU resource represented by ID3D12Resource, but why is it said that vertex buffer don’t need a descriptor heap??
Other resources like depth/stencil resource, swap chain’s buffer need to have descriptor heaps. How does these resources differ from vertex buffer.

# DX12 UINT64 for resource size but only UINT32 for the resource view

## Recommended Posts

Hello guys,

I am wondering why D3D12 resource size has type UINT64 while resource view size is limited to UINT32.

typedef struct D3D12_RESOURCE_DESC {
…
UINT64                   Width;
…
} D3D12_RESOURCE_DESC;

Vertex buffer view can be described in UINT32 types.

typedef struct D3D12_VERTEX_BUFFER_VIEW {
UINT                      SizeInBytes;
UINT                      StrideInBytes;
} D3D12_VERTEX_BUFFER_VIEW;

For the buffer we can specify offset for the first element as UINT64 but the buffer view should still be defined in UINT32 terms.

typedef struct D3D12_BUFFER_SRV {
UINT64                 FirstElement;
UINT                   NumElements;
UINT                   StructureByteStride;
D3D12_BUFFER_SRV_FLAGS Flags;
} D3D12_BUFFER_SRV;

Does it really mean that we can create, for instance, structured buffer of floats having MAX_UNIT64 elements (MAX_UNIT64 * sizeof(float) in byte size) but are not be able to create shader resource view which will enclose it completely since we are limited by UINT range?

Is there a specific reason for this? HLSL is restricted to UINT32 values. Calling function GetDimensions() on the resource of UINT64 size will not be able to produce valid values. I guess, it could be one of the reasons.

Thanks!

##### Share on other sites

GPU address space is likely 64bit, so the memory allocator will work with these sizes, however descriptors are generally bitpacked as small as possible, so some sensible limits are chosen to help that goal.

##### Share on other sites

The GPU's address space is likely quite a bit smaller than the full 64-bits. It may be as small as 32-bits on some older Intel parts, limiting you to resources no larger than 4GB in size, but 38 on newer ones I think. AMD's parts have generally been around the 40-bit or 48-bit range, and I think NVIDIA is 40 too.

You can query for MaxGPUVirtualAddressBitsPerResource from this structure: https://msdn.microsoft.com/en-us/library/windows/desktop/dn770364(v=vs.85).aspx

I've come pretty close with my sparse voxel work to hitting the 40-bit limit (an 8K * 8K * 8K R8 texture is 512GB / 39 bits), but generally only the 32-bit limit is going to pose anyone any problems.

##### Share on other sites
Quote

but generally only the 32-bit limit is going to pose anyone any problems.

Thank you for the info! Can you please rephrase the statetement I do not really grasp what you mean here

Edited by _void_

##### Share on other sites
15 minutes ago, _void_ said:

Thank you for the info! Can you please rephrase the statetement I do not really grasp what you mean here

Sorry, I was referring specifically to the older Intel Haswell parts only supporting a 32-bit virtual address per resource, it was actually 31-bits according to this table https://en.wikipedia.org/wiki/Feature_levels_in_Direct3D#Support_matrix. If on the Haswell GPUs you can only have a 2GB resource, or even 2GB per process as that table suggests, then it can be a bit restrictive.

One way to do Texture Streaming on D3D12 is to reserve virtual address space for the entire texture's mip chain, even including higher resolution mips that aren't yet streamed in due to proximity to the object. You can then using the Reserved Resources (aka Tiled Resources) API to commit physical memory to higher resolution mips as and when they get loaded. However, if you're always going to allocate the full amount of virtual memory, then you can run out of it very quickly, even if you're careful to only use 1GB of physical memory at any one time.

##### Share on other sites

This has nothing to do with VA sizes.  The problem is that lots of HW is restricted to the HW limits that D3D11 specifies.

See VB:

D3D11_REQ_DRAW_VERTEX_COUNT_2_TO_EXP (2³²)

See SRV:

D3D11_REQ_BUFFER_RESOURCE_TEXEL_COUNT_2_TO_EXP (2²⁷) texels

Your resource can be larger than these values because a single resource can be offsetted for each of their bindings.

##### Share on other sites
On 10/12/2017 at 8:14 AM, _void_ said:

Hello guys,

Does it really mean that we can create, for instance, structured buffer of floats having MAX_UNIT64 elements (MAX_UNIT64 * sizeof(float) in byte size) but are not be able to create shader resource view which will enclose it completely since we are limited by UINT range?

Yes. Everyone has cleared up that his is a HW limitation.

But I don't think nobody has hinted the obvious: You can create more than one view. The most common scenario is for manually managing memory: creating a large pool, and then having different meshes / const buffers / structured buffers living as views to subregions of it.

You just can't access all of it all at once. Though for example if you have a 6GB buffer, you could create 3 views of 2GBs each and bind them all 3 to the same shader.