Jump to content
  • Advertisement
Sign in to follow this  
Dingleberry

transition barrier strictness

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

I noticed I can get away without using a lot of barriers. The first noticable one is switching from present to render target on swap chain buffers. Some things make the debug runtime yell at me but some don't. If the debug runtime doesn't complain, does it just not matter?

 

It's kind of irritating how it doesn't make any noise about them sometimes. I worry that something will change turning them into errors at some point, perhaps on different hardware or drivers. Presently there isn't a simple way to validate them, is there?

To repro this just try deleting some of the barriers in the msft github samples.

Share this post


Link to post
Share on other sites
Advertisement
D3D12 is explicitly targetted at "expert" graphic programmers with already a background with GPU hardware and modern APIs.
This is why D3D11 is not going away and still being updated (i.e. D3D11.3).
Note I'm not calling you a rookie. I'm just saying this what to expect from D3D12.
 

If the debug runtime doesn't complain, does it just not matter?

No, it just means the debug layer didn't catch it. Hopefully it will improve with time. Edited by Matias Goldberg

Share this post


Link to post
Share on other sites

There are going to be cases where the debug layer cannot infer incorrect usage of barriers since it cannot know at record time what the state of the resource will be when the command list is eventually executed.

 

If a command list contains a single transition barrier from Render Target to Shader Resource, that's fine. However, to execute two such command lists in sequence would result in invalidly attempting to transition from Render Target to Shader Resource twice. The resource would already be in the Shader Resource State after execution of the first command list. Nothing was incorrectly recorded at draw time that the debug layer could alert you to, it's only at Execute time that this could possibly be detected.

Share this post


Link to post
Share on other sites

Nothing was incorrectly recorded at draw time that the debug layer could alert you to, it's only at Execute time that this could possibly be detected.

Hopefully they'll add an "IntrusivenessLevelTwo" option to the debug layer to detect this type of error too :)

[edit]actually does the ref/warp device catch this stuff?

Share this post


Link to post
Share on other sites


D3D12 is explicitly targetted at "expert" graphic programmers with already a background with GPU hardware and modern APIs.

 

I'm well aware. It's because of that that I'm interested in the best way to validate resource states.

 


[edit]actually does the ref/warp device catch this stuff?

 

Not presently.

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!