Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

109 Neutral

About billkris

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @turanszkij is mostly correct. A resource in the COMMON state can be incrementally promoted to multiple read-only states without the need for explicit resource barriers. Such resources will also decay back to COMMON when the associated ExecuteCommandLists operation completes. Therefore, it is true that static textures can be left in the COMMON state indefinitely, never needing resource barriers once they are initialized. However, non-simultaneous-access textures only decay to COMMON if they were written to in a COPY command queue. DIRECT command queues can promote textures from COMMON to COPY_DEST, but these will not decay back to COMMON. This is because DIRECT command queues may perform copy operations as a render op, resulting in compressed texture data that may need to be decompressed to allow read-access, requiring a resource state barrier. If possible, I suggest creating static textures in the COMMON state and use a COPY queue to initialize the data. This way you will never need a resource barrier for these textures. Let me know if you have any additional questions.
  2. billkris

    Implicit State Promotion

    Implicit promotion takes advantage of the fact that resources in the COMMON state can be read from or copied to without a layout change (such as a compress or decompress operation) and that first access requires no synchronization or cache flushing. Texture resources in the COMMON state can only be promoted to PIXEL_SHADER_RESOURCE, NON_PIXEL_SHADER_RESOURCE, COPY_SOURCE and COPY_DEST. Buffers and simultaneous-access textures, which are required to always be in a common layout, can be promoted to any state. Implicit decay occurs once all read/write operations on a buffer or simultaneous-access resource are completed, indicated by completion of ExecuteCommandLists. This is because all caches are flushed, there are no pending synchronization barriers, and the layout of the resource is still common. Note: Non-simultaneous-access textures initially in the COMMON state (at the start of the first command list in ExecuteCommandLists) can technically be implicitly decayed. Unfortunately, the current release of the debug layer validates against this. An updated version of the debug layer is available for Windows insider builds that corrects this.
  3. billkris

    WriteBufferImmediate use-cases

    SoldierOfLight is correct that one of the main purposes of WriteBufferImmediate is to provide synchronized writes with work done in the pipeline using MARKER_IN and MARKER_OUT modes. However, MODE_DEFAULT is not a synchronizing operation. In fact, the purpose of MODE_DEFAULT is to enable quick, stochastic writes to buffer locations, such as updating a few constants. This also eliminates the need for an upload-heap staging buffer for these cases. The buffer must be in either the COPY_DEST or COMMON state (will be promoted to COPY_DEST). We would love to hear your feedback on how this affects your application performance. Also, let me know if you have any more questions.
  4. Glad you got it figured out. -Bill
  5. Bovine, Have you tried re-scanning for updates after updating your OS? You may need to reboot afterward. Can you send a dxdiag.txt, or reply with a copy of the System Information portion of your dxgiag.txt file? -Bill
  6. billkris

    D3D12CreateDevice fails

    Ok, new theory.  We think this has to do with using GBV on hybrid systems and we think we know how to fix it.  Thanks for reporting this. I should add that we don't think this is an application error.  You can also ignore my previous question about transitioning the back buffer in Copy command queue. Looks like that would not cause this problem.
  7. billkris

    D3D12CreateDevice fails

    We are working on a theory.  Any chance you are explicitly transitioning the back buffer to the COMMON state in a Copy command list using a ResourceBarrier?  We have found a possible bug (working on a repro) that could produce the error you are seeing.
  8. billkris

    D3D12CreateDevice fails

    Looks like you are hitting a suspected bug in GPU-Based Validation that we are having a difficult time reproducing here at MS.  At least one other customer has reported a similar error.  Sounds like you are getting this error and also getting a crash.  Any chance you can share a crash dump?
  9. Thanks red75prime.   We believe we have a fix for this bug internally and will use your repro to confirm.  Thanks for taking the time to help us with this.   -Bill
  • Advertisement

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!