Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Jul 1999
Offline Last Active Yesterday, 10:05 PM

Topics I've Started

[D3D12] Uploading Texture Data

01 May 2016 - 09:51 AM

In the first iteration of my code for uploading texture data for use in a shader, i just did a basic call to UpdateSubresources:

D3D12_SUBRESOURCE_DATA uploadData = {};
uploadData.pData = data;
uploadData.RowPitch = width * bytesPerPixel;
uploadData.SlicePitch = totalSize;
UpdateSubresources(list, resource.Get(), uploadResource.Get(), 0, 0, 1, &uploadData);

This worked just fine until I introduced a cube map that had mip maps.  Suddenly it started to crash in UpdateSubresources.  I tried setting the NumSubresources field of UpdateSubresources to (numLayers(6) * numMipMaps(11)), but it still crashed.  So I rewrote this portion of the code to call GetCopyableFootprint and fill out an array of D3D12_PLACED_SUBRESOURCE_FOOTPRINT structures, map the intermediate resource and copy to it manually using the aforementioned structures, and then finally call CopyTextureRegion for each sub resource.


This worked just fine, for mipmapped, array, and singular textures alike, until I tried to load a 4x4 32 bit non-mipmapped texture.  Suddenly it started to crash again.  After some digging, I found that the rowPitch of my footprint structure, returned from GetCopyableFootprint, was coming back as 256.  I presume it should be 16.


So then... what is the best way to load texture data?  I think I'd honestly like to just call UpdateSubresources and get it to work properly for the mip-mapped cubemap.

HLSL: next free register binding

22 April 2016 - 06:35 PM

I have a shader that #includes two other pieces of code.  Each of those #include files declares a Texture2D.  Is there any way to know in my main code what the currently "free" register is?  Like:



// Effect1.hlsl
Texture2D fx1;

// Effect2.hlsl
Texture2D fx2;

// Main.hlsl
#include "Effect1.hlsl"
#include "Effect2.hlsl"

Texture2D firstTexture : register(t#)
Texture2D secondTexture : register(t#)



Is there any way to know what those t#'s would be (in this case t2 and t3)?  Perhaps by some trick of a preprocessor directive with a #define passed from the engine code?  I know that explicitly declaring the register is optional, but I'm still curious.

[D3D12] Resource Barriers in Multiple Command Lists

06 April 2016 - 06:44 AM

Let's say I'm going to submit Command List 'A' and Command List 'B'.  I'm guaranteed to submit 'A' before 'B'.  I put 100 commands in 'A', and then a Resource Barrier to transition a resource from a pixel shader resource to a render target.  The only thing I put in 'B' is a Resource Barrier to transition that same resource from a render target to a pixel shader resource.


Do I have any assurance that 'A' will transition the resource before 'B' does?

[D3D12] What is the benefit of descriptor table ranges?

05 March 2016 - 07:21 PM

In regard to root signatures for descriptor heaps, what is the point of having a descriptor table with a range of multiple descriptors?  Is it just to minimize the number of calls to SetGraphicsRootDescriptorTable/SetComputeRootDescriptorTable?  That seems like a small victory for the price of ensuring that your descriptors are contiguous within the heap.  Sharing resources between shaders then requires more complicated root signature creation.  And changing a resource at runtime (like switching to a different texture) requires either: a stall in the rendering so the descriptor can be reused, copying a bunch of descriptors to create another contiguous section, or creating a new root signature on the fly to accommodate the new breakdown of resource descriptors.


Is it really that big of a win over calling SetGraphicsRootDescriptorTable for each individual resource, and defining the root signature along the same lines?

Debugging this Vulkan crash

26 February 2016 - 03:19 PM

So I've slowly been throwing together a vulkan example so that I can get an understanding of how everything works.  Right now I get an access violation, and what I'm really wondering is if anyone has any suggestions on how to debug it.


I've read through SaschaWillems' code, and I thought I'd done everything he did (I've also compared it against the demo code that comes with the Lunar SDK, and everything seems in order).  But I get a crash when I call vkQueuePresentKHR, with the error being "Access violation reading location 0xBAADF00D".  So that's an interesting hex value, and googling it reveals that it's generally "used by Microsoft's LocalAlloc to indicate uninitialized allocated heap memory".  In my debugger (Visual Studio 2015), it pops open a window that says "No symbols loaded" and is looking for VkLayer_swapchain.dll.


 If I disable that call to vkQueuePresentKHR, the program will run (and obviously not display anything), but will crash on VkDestroySurfaceKHR, with an Access Violation at 0xBAADF025.  The combination of these crashes makes it seem like my surface is uninitialized, but I've walked through that code several times and everything seems in order.  I have checks for VK_SUCCESS on every vulkan function and nothing is failing or indicating an error.


So I'm not really looking to dump my Vulkan test code here, as it's a lot, and I'm not sure exactly where the issue is yet.  Really what I'm wondering is if anyone has any tips on debugging this problem.  Maybe a better way to look into VkLayer_swapchain.dll?