transition barrier strictness

Started by
4 comments, last by Dingleberry 8 years, 2 months ago

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.

Advertisement

You're right, the debug layer does not notify you of all transition issues yet, so the fact that it doesn't complain about things doesn't mean that your code is correct. Expect these issues to turn into errors at some point in time.

There's not a lot of hand holding in D3D12, make sure to do your research and cover all cases.

I gets all your texture budgets!

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.

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.

Adam Miles - Principal Software Development Engineer - Microsoft Xbox Advanced Technology Group

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?


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.

This topic is closed to new replies.

Advertisement