-
|
I am trying to implement a texture double-buffering pattern for a multi-state compute shader pipeline. My problem is the state transitions between stages; specifially the very first transition. More specifically, I am first creating an "original" texture, which I then copy to two other textures that comprise my double-buffer. When I enter Render(), I want to transition the first buffer texture to RESOURCE_STATE_SHADER_RESOURCE, and the second to RESOURCE_STATE_UNORDERED_ACCESS. I am expecting both textures to be in RESOURCE_STATE_COPY_DEST, as they have just received the copy from the "original", but that does not seem to be the case. I always get some kind of state transition error, like:
Obviously, I am targeting Vulkan here. If I can get the first transition to work, then I persumably control the transition state for the remainder of the chain, but I can't get my foot in the door. I'm assuming that I am running afoul of some Diligent Engine automated transition state logic, but I don't really know. Can somebody point me at the correct implementation of this pattern? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 11 replies
-
|
First of all, why do you need to do this manually? Is there anything specific why automatic transitions don't work?
This message suggests that the previous layout is |
Beta Was this translation helpful? Give feedback.
-
|
That seems to be OK, because When you create your resource, can you specify the names? Also, is |
Beta Was this translation helpful? Give feedback.
-
|
I have given distinct names for the textures, which it is why I know that it is T2[0] and T3[0] that are generating the errors. The "state" string was the name of a distinct pair, but I couldn't tell which member of that pair was the source of the error, so I gave each one a numerical suffix. based on their index in the texture pair array. The names are changed in the source code I am posting because I am working with a partner who is very concerned about protecting our IP. While I do not share his concerns, I am obligated to respect them. In the original nomenclature, "state" maps to "T1_0", but I am no longer getting that error since adding the "UnmodifiedXXX" textures to the pass 2 output set, but now I do get errors for "T2_0" and "T3_0", which I know are the input textures for pass2, as they are generatd when I Invoke DispatchCompute:
where currentBufferIndex = 0. All of the compute PSO's should have names, as the CI.Desc.Name field is set for each PSO, so I am unsure as to where the "Implicit signature of PSO" is coming from. Foir the record, here are the current errors:
|
Beta Was this translation helpful? Give feedback.
-
|
Can you reproduce this issue in one of the tutorials (e.g. 14). Obviously, no real logic is needed, only the resources. |
Beta Was this translation helpful? Give feedback.
-
|
I was able to reproduce it as a tutorial but, in the process, I also finally found the problem. When using the double-buffer pattern, any texture that is used as an input for any compute shader, must pass that texture to the next shader in the chain, even if that shader does not use it, and so on for all intermediate compute shaders until the chain reaches the next shader that actually uses it. This is exactly the fix you suggested earlier, but I had two bindings in my pipeline setup that were using the wrong index. Example: Assume I have three compute shaders CS1, CS2 and CS3, and double-buffered Textures T1, T2, T3, and single-buffered texture T4:
T1 and T4 won't give us any problems with state transitions on any of the shaders, but T2 and T3 will. The lack of a clear "chain of custody" (for lack of a better term) seems to mean that the automatic state transition logic will get confused. If I pass all four textures to each shader, whether it needs it or not, and output all four shaders, whether the next shader needs it or not, then I have no problems with automatic state transition. I had initially tried to address this by doing manual state transitions, but that did not work. It could be because I got the bindings wrong somewhere, or maybe I have to turn automatic transitions off? Regardless, manual transistion management just introduces new opportunities for error. If the cost of avoiding that is binding a couple of extra registers, that seems like a fair trade. For anybody who has tracked this post down because they have the same problem, just pass everything through:
Note that the indices for each texture are just to emphasize which copy of the texture the shader will be using for input and output; you would not specify them in your shader code, but you would have to get them right when setting up the shader bindings in your pipeline. T4 has no index because it is not double buffered. For the same reason, CS3 can just output it to the next state (presumably a vertex shader), without having used it as an input, as it is not double buffered. To be clear, I don't think that it is necessary to do it this way. If you get all the indices right on your pipeline setup, and disable automatic state transitions, you might be able to a pipeline like this to work without passing unused textures through intermediate stages. Or maybe it would only work for certain back ends. I was targeting Vulkan, and was pulling my hair out over this. |
Beta Was this translation helpful? Give feedback.
-
Hmm, that does not need to be necessary. |
Beta Was this translation helpful? Give feedback.
-
|
My apologies; I did not make myself clear. I do not believe that this is actually necessary, just that it is the easiest way to avoid issues. If you start bringing buffers in, in the middle of the chain, then you have to be sure that you get the right buffer index, and any changes you make to the pipeline might invalidate that. It's just easier, at least initially, to pass everything through, then optimize it after the pipeline is stable. In my case, I had multiple errors, plus targeting Vulkan, plus being a total noob, and I got seriously confused. Doing this just made getting it straightened out a lot easier. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, this was built as a new tutorial, since it provides so much convenient infrastructure. So that’s kind of already done. I’ll just have to strip the shader logic.
…On Fri, Apr 11, 2025 at 20:33, Assiduous ***@***.***(mailto:On Fri, Apr 11, 2025 at 20:33, Assiduous <<a href=)> wrote:
Can you reproduce this issue in one of the tutorials (e.g. 14). Obviously, no real logic is needed, only the resources.
You will need to write something from the shaders (e.g. 0) to resources, or they will be optimized out.
—
Reply to this email directly, [view it on GitHub](#337 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AG7INTDFM2XUH4EGW7NKYLD2ZBUQLAVCNFSM6AAAAAB25J6LDKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOBQHE3TMMA).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
I was able to reproduce it as a tutorial but, in the process, I also finally found the problem. When using the double-buffer pattern, any texture that is used as an input for any compute shader, must pass that texture to the next shader in the chain, even if that shader does not use it, and so on for all intermediate compute shaders until the chain reaches the next shader that actually uses it.
This is exactly the fix you suggested earlier, but I had two bindings in my pipeline setup that were using the wrong index.
Example:
Assume I have three compute shaders CS1, CS2 and CS3, and double-buffered Textures T1, T2, T3, and single-buffered texture T4: