How annotations/bindings are determined #34
-
Didn’t realize this was a thing, so apologies for using issues earlier. In short, I want to ask how what binds to say, fp_c9 is determined. The buffer bindings in the json and from what I can tell, the uniform data in the shader itself, don’t seem to match up. So how were you able to match them? I mean you can do it manually if you compare to renderdoc but you obviously aren’t going to do that for every single file. So how were you able to do it? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
Buffers and also textures are referenced using their binding index. There's not an obvious mapping between the nushdb data and the bindings in the shaders. The names in Ryujinx like "fp_c9_data" are just generated automatically based on integer handles, indexes, etc from the compiled code. There are two main ways to refer to resources in modern graphics APIs. You either explicitly set the handle/index in the shader code or you query the index in code using something like The relevant code from smush_materials. The materials seem to always be in fp_c9 or vp_c9. It should be possible in theory to map all the inputs to the shaders, but it would require a lot of testing to validate. Smush-Material-Research/smush_materials/src/main.rs Lines 756 to 773 in 925fd43 |
Beta Was this translation helpful? Give feedback.
-
In other words, you haven't been able to figure out how/why it usually maps to those numbers specifically (even using envydis to convert the binary to assembly, the code uses the same numbers) , but you do know that the same things tend to be in the same spots in practice? |
Beta Was this translation helpful? Give feedback.
The bindings for uniforms, input/output attributes, textures, and buffers have been applied to the recently uploaded annotated shader dump. For anyone curious as to how the bindings work, please consult the annotation code in smush_materials. The shdr_data module in ssbh_data was also updated recently with new information.
There are some differences between the shaders generated by Ryujinx at runtime and those generated with Ryujinx.ShaderTools that was causing the confusion. I don't have a way to test every single shader, but the new logic is straightforward and matches up with with manually mapping values in Ryujinx and looking at decompiled and dissassembled code.