Jump to content
  • Advertisement
Sign in to follow this  
FrozenS

OpenGL DirectX12's terrible documenation -- some questions

This topic is 1078 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

Having only used OpenGL and read Mantle's documentation (which is excellent) before, I'm having a very hard time learning DirectX12. The documentation is almost nonexistent, some of it hyperlinks on accident to pages of an old preliminary versions that differs greatly, and in code examples they've done mistakes such as trying to call CreateConstantBufferView using a command list instead of a device. So not only is it very sparse, it's plain wrong. This may not seem like a big deal to some since it's easily caught, but it's very exhausting to have to deal with wrong documentation on top of sparse documentation.

 

Concepts are not explained at all which makes learning the API very exhausting. You have to remember the whole API without understanding it, and try to interpret what it is you're supposed to do based on how the API has been layed out and based on what little has been said. It would be great if someone put in the time to create a short tutorial explaining concepts such as ConstantBufferViews which aren't even mentioned in the documentation except for acknowledging its existence. Some knowledge can be gained from DirectX11 which has better resources online, but not everything.

 

Therefore I'm hoping to use this thread to get answers to a few questions I have now and questions I may have later. Here are my questions:

 

1) What are the differences between Shader Resource Views and Constant Buffer Views?

2) What are the different ways for uploading data to the GPU and does the recommended manner differ based on usage patterns?

 

Thanks.

Edited by FrozenS

Share this post


Link to post
Share on other sites
Advertisement

Thanks Radikalizm,

 

Though it's still a bit unclear to me when one would pick a CBV over a SRV as SRVs can reference buffers which presumably can be accessed in shaders. And if they can be accessed in shaders then it must be in a similar manner?

 

On a different note it's interesting to see the different approaches Mantle and DX12 have taken with memory management. Both seem to have the concept of preferred memory pools because in the DX12 heap properties, the memory pool entry is named "MemoryPoolPreference". So it sounds to me like the driver makes the decision for you as it does in Mantle, though I'm not sure. However, only Mantle has you specify the priority of the heap which says how important it is to have the heap in the preferred memory pool vs having them in less preferred pools or all together paged out.

 

Then when you submit a Command List to a queue you have to specify all the heaps used so the driver can make sure they're resident. In DX12 however, everything is automatically resident unless you call Evict which suggests to the driver that he can, well.. Evict the memory.

 

It seems to me that you have more control with the DirectX API whereas Mantle holds your hand a bit and helps you (or forces you) to have a page-out friendly implementation. That's my newbie take on the matter and it may be wrong. In any case it's interesting to learn two such APIs and their differences because it helps you recognize what decisions the driver developers have decided to handle for you, versus what decisions were made simply to fit modern GPU hardware. Both approaches are interesting and I look forward to seeing what Vulkan will do.

Edited by FrozenS

Share this post


Link to post
Share on other sites


Though it's still a bit unclear to me when one would pick a CBV over a SRV as SRVs can reference buffers which presumably can be accessed in shaders. And if they can be accessed in shaders then it must be in a similar manner?

 

This is a good question.  Yes you can put data you would typically put in a constant buffer in a structured buffer and then bind an SRV to the structured buffer and index it in your vertex shader.  You would have to profile and see if one performs more optimally.  

 

In the d3d11 days, I assumed constant buffers were distinguished in that they were designed for changing a small amount of constants often (per draw call), and so had special optimizations for this usage, whereas a structured buffer would not be changed by the CPU very often and would be accessed more like a texture.  

 

I'm not sure if future hardware will continue to make a distinction or if it is all the same.

Share this post


Link to post
Share on other sites

This might be related:

 

http://www.yosoygames.com.ar/wp/2015/01/uniform-buffers-vs-texture-buffers-the-2015-edition/

 

I'm not terribly sure whats the difference between "shader storage buffer" (a "structured buffer" in D3Dland) and "texture buffer object". I mean, I know that TBOs uses samplers, texture cache and all of that, but it looks like both *could* be resolved the same way in the GPU, I'm not sure. If it is the case, the particulars noted in the article could be useful (typed buffer access vs untyped buffer access). Just in case, "uniform buffer" is a "constant buffer" in D3D.

 

I hope it helps. Maybe Mathias will pop in the discussion...

Share this post


Link to post
Share on other sites

This might be related:

 

http://www.yosoygames.com.ar/wp/2015/01/uniform-buffers-vs-texture-buffers-the-2015-edition/

 

I'm not terribly sure whats the difference between "shader storage buffer" (a "structured buffer" in D3Dland) and "texture buffer object". I mean, I know that TBOs uses samplers, texture cache and all of that, but it looks like both *could* be resolved the same way in the GPU, I'm not sure. If it is the case, the particulars noted in the article could be useful (typed buffer access vs untyped buffer access). Just in case, "uniform buffer" is a "constant buffer" in D3D.

 

I hope it helps. Maybe Mathias will pop in the discussion...

From an API perspective, shader storage buffer (aka SSBO, structured buffers) are very different from a texture buffer object (aka TBO). SSBOs can have read and/or write access, may alias to other objects (e.g. a structured buffer is read-only but turns out another variable points to the same memory and has write access; see restrict in C for an explanation of the same problem in CPUs) and are subject to less restrictions than TBOs (more relaxed alignment rules, unbounded indexing).

If it were C/C++, a TBO is more like a read-only array in the stack that may need lots of padding (an array that can be huge though... like 128MB huge) that is guaranteed to not alias with anything that has write access, while SSBOs is much more like a random pointer C with less padding/packing.

 

From a GCN arch point of view, there is virtually no difference between the two; however the shader compiler may produce better code with TBOs due to the strong assumptions enforced by the API (always read only, size may be known at compile time, doesn't alias with other variables that may have write access, the alignment restrictions can help avoiding bank conflicts, etc)

 

Needless to say from a historical point of view, lots of old GPUs couldn't do SSBOs (a feature introduced with DX11 hardware) but they could do TBOs (supported since the GeForce 8).

 

NVIDIA has now also published it's three-part series of "recommended practices" in Structured Buffers. Note that alignment still plays a vital role with SSBOs, but now you have to pad your objects explicitly, whereas TBOs forced the padding (e.g. either you performed two fetches of RGBA_FLOAT32, or avoid padding with 6 fetches of R_FLOAT32.).

Share this post


Link to post
Share on other sites

 

1) What are the differences between Shader Resource Views and Constant Buffer Views?

2) What are the different ways for uploading data to the GPU and does the recommended manner differ based on usage patterns?

 

 

Re #1: Take a look at Amar's binding tutorial on our official DirectX YT channel: https://www.youtube.com/playlist?list=PLeHvwXyqearVU8fvo2Oq7otKDlLLDAaHW fo

Re #2: We are hoping to post a video soon relating to #2 on the channel as well soon. I'll let you know when we do.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!