Jump to content

  • Log In with Google      Sign In   
  • Create Account

Brian Klamik

Member Since 05 Mar 2005
Offline Last Active Apr 21 2016 01:12 PM

Posts I've Made

In Topic: Manually copying texture data from a loaded image

08 March 2016 - 11:54 AM



Minor clarification here:



Apps can fill out these footprint structures themselves, but they must follow the documented alignment restrictions. The samples use GetCopyableFootprints, because its conciseness avoids distracting from the sample's true intention. Apps should take care to avoid GetCopyableFootprints from becoming a bottleneck. Once the restrictions are understood, applications can simplify the logic to fill out these structures. As an example, planar complications could be avoided, and the structure data could even be baked to disk.


-Brian Klamik

In Topic: [D3D12] Copying between upload buffers

07 March 2016 - 07:51 PM



In D3D12, CopyBufferRegion should complain about an UPLOAD destination resource, just like CopyResource does. UPLOAD resources are always in the GENERIC_READ state and cannot be transitioned out. Perhaps the errors have already been muted elsewhere?


Are you sure you actually have to copy over the contents of the old buffer?


That worked basically like std::vector; I'd create a USAGE_DYNAMIC buffer, map it with WRITE_DISCARD, and if the size turned out to be insufficient, I'd unmap it, create a new larger buffer, CopySubResourceRegion() over the old data, and map the new buffer.

The CopySubresourceRegion call is actually discarded in the scenario you describe. Map in D3D11 requires WRITE_DISCARD to be passed when called on USAGE_DYNAMIC vertex buffers, meaning the current data in the buffer becomes undefined.


I hope you actually don't have to copy over the data at all, and your scenario is much simpler than you originally believed. But, if you actually must address the issue, there is another option besides reserved resources to consider. You can resort to a CUSTOM heap type. UPLOAD is just an abstraction that can be removed, if it gets in the way. Using a CUSTOM heap will allow you to transition the destination resource to COPY_DEST for CopyBufferRegion, then back to GENERIC_READ for further normal usage.


See https://msdn.microsoft.com/en-us/library/windows/desktop/dn770374(v=vs.85).aspx  for more info.


Given the choice of reserved vs. CUSTOM heap options, the reserved resource technique should result in better runtime efficiency. Overall, it avoids copying and a much larger spike in residency. The spike occurs when keeping both buffers alive for awhile. Don't forget you'll likely need an aliasing barrier when using reserved resources. There are less obvious downsides of reserved resources: good D3D tool support for reserved resources will likely take longer to come along than for CUSTOM heaps, and reserved resources are currently a less thoroughly tested code path in drivers.


-Brian Klamik


In Topic: D3D11 INFO: Destroy ID3D11ClassLinkage

17 April 2013 - 12:37 PM

It's not clear what you think is a problem. That info message is telling you the object is being destroyed, so did you expect it to be destroyed sooner?


You can figure out what component is creating this object by using the ID3D11InfoQueue interface. Make the debugging infrastructure break on all ClassLinkage object creations by breaking on the following message D3D11_MESSAGE_ID_CREATE_CLASSLINKAGE and examining the call stack. See the following documentation to achieve that: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476538(v=vs.85).aspx

In Topic: Trouble creating swap chain

07 September 2012 - 10:34 AM

I suspect the issue is the flags you pass.

Initialize D3d_Device_Flags to 0 first. The following line is very suspect, because D3d_Device_Flags is declared and read from within the same statement:
UINT D3d_Device_Flags = D3d_Device_Flags | D3D11_CREATE_DEVICE_DEBUG; //device flags

Then, make sure the computer has the SDK installed on it or remove the _DEBUG flag, as CreateDevice will fail with that flag if the SDK is not installed on the computer you run the program on.

In Topic: How do you multithread in Directx 11?

17 August 2012 - 11:29 AM

Did you try MSDN?

'Introduction to Multithreading in Direct3D11' and all the pages it references?