An issue with split barriers in D3D12
Hi!
Just upgraded to 3.2.4 and noticed an odd issue with your D3D12 renderer.
We have a code that draws a View into an offscreen RenderTarget, nothing fancy:
This worked fine before and seems to works fine with Win10 + Nvidia GPU, but when I try the same build on Win11 + Intel Xe the debug layer throws an exception:
Looking at your D3D12RenderDevice code I see that BEGIN_ONLY is called inside Resolve method and END_ONLY is deferred until the texture is needed in a draw batch. However in our case the texture won't be used until the next frame and thus begin and end halves are indeed in separate command lists.
Curiously since we don't use AA and stencil for this RT there's no need to call Resolve anymore and so the error can be avoided, however this doesn't look like a proper solution.
I can't find any useful documentation from Microsoft (or anyone else) about this error and for now I'll just remove the split barrier code from the renderer, but I just want to ask your opinion about the issue.
Just upgraded to 3.2.4 and noticed an odd issue with your D3D12 renderer.
We have a code that draws a View into an offscreen RenderTarget, nothing fancy:
Code: Select all
pDevice->SetRenderTarget(pRT);
pView->GetRenderer()->Render(false,false);
pDevice->ResolveRenderTarget(pRT,0,0);(all typos verbatim :) )D3D12 ERROR: ID3D12CommandQueue::ExecuteCommandLists: Begin split on ... has no matching END_ONLY barrier in the same ExecuteCommandLists scope. Splitting barriers acrossExecuteCommandLists boundaries is not supported. It also serves no benefit since all syncronization and cache flush operations are guaranteed to be completed in the preceding ExecuteCommandLists scope. [ RESOURCE_MANIPULATION ERROR #535: RESOURCE_BARRIER_UNMATCHED_BEGIN]
Looking at your D3D12RenderDevice code I see that BEGIN_ONLY is called inside Resolve method and END_ONLY is deferred until the texture is needed in a draw batch. However in our case the texture won't be used until the next frame and thus begin and end halves are indeed in separate command lists.
Curiously since we don't use AA and stencil for this RT there's no need to call Resolve anymore and so the error can be avoided, however this doesn't look like a proper solution.
I can't find any useful documentation from Microsoft (or anyone else) about this error and for now I'll just remove the split barrier code from the renderer, but I just want to ask your opinion about the issue.
Re: An issue with split barriers in D3D12
This is very interesting, could you please create a ticket? The initial motivation for using split barriers in 3.2.4 was to fix a bug in a few Nvidia drivers and also to get better performance. But it seems we didn't consider the case where the barrier is ended in a different command buffer. This must be fixed.
Who is online
Users browsing this forum: Semrush [Bot] and 3 guests