You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, this is my first time writing a GitHub issue so bear with me if this isn't the best attempt at one.
Right now, shaders decompiled with VertexProgramDecompiler ignore BRI instructions. If you start homebrew games you will get a bunch of messages in the log like "unknown vp sca_opcode 0x9". The reason the BRI instruction code is commented out is because it crashes your graphics driver when enabled. The error code you get is a timeout, which leads me to think that inflinite loops are being accidentally produced.
This is a vertex shader decompiled with the current version of rpcs3, where the BRI instruction is commented out/ignored. . As you can see, it's just a while loop with a break at the end that is always reached the first time, so it's basically just a continuous block of code. This removes a lot of functionality from the shaders since they basically cannot loop.
This is what's produced if you uncomment it. I added a comment to the continue statement generated from each BRI instruction -- "// FROM BROKEN BRI INSTRUCTION".
I think the control flow is incorrect when the instruction is enabled. If I'm understanding the flow properly, each jump_position within the while loop is basically simulating a loop in the original shader written for PS3. If you look at the second continue;, it didn't get its own jump_position section, so when the if block on 94 is entered, we start the whole while loop again. At this point I think either
a) the first loop executes again normally in its entirety, reaches the condition for the second loop again, and starts the first loop again, etc.
or
b) the first loop's ending condition can now never be met due to some changes in variable values that took place during the execution of the loop the first time through (or during the execution of the code between 72-93) so the loop continues forever without ever reaching line 72 again.
I don't understand the project (or git) well enough yet to try the changes on my own, but my naive opinion is that it's possible that the issue stems from there not being a new jump_position generated after 72.
The text was updated successfully, but these errors were encountered:
Hi, this is my first time writing a GitHub issue so bear with me if this isn't the best attempt at one.
Right now, shaders decompiled with VertexProgramDecompiler ignore BRI instructions. If you start homebrew games you will get a bunch of messages in the log like "unknown vp sca_opcode 0x9". The reason the BRI instruction code is commented out is because it crashes your graphics driver when enabled. The error code you get is a timeout, which leads me to think that inflinite loops are being accidentally produced.
http://pastebin.com/pViEyHfQ
This is a vertex shader decompiled with the current version of rpcs3, where the BRI instruction is commented out/ignored. . As you can see, it's just a while loop with a break at the end that is always reached the first time, so it's basically just a continuous block of code. This removes a lot of functionality from the shaders since they basically cannot loop.
http://pastebin.com/6L4vEPTe
This is what's produced if you uncomment it. I added a comment to the continue statement generated from each BRI instruction -- "// FROM BROKEN BRI INSTRUCTION".
I think the control flow is incorrect when the instruction is enabled. If I'm understanding the flow properly, each jump_position within the while loop is basically simulating a loop in the original shader written for PS3. If you look at the second
continue;
, it didn't get its own jump_position section, so when the if block on 94 is entered, we start the whole while loop again. At this point I think eithera) the first loop executes again normally in its entirety, reaches the condition for the second loop again, and starts the first loop again, etc.
or
b) the first loop's ending condition can now never be met due to some changes in variable values that took place during the execution of the loop the first time through (or during the execution of the code between 72-93) so the loop continues forever without ever reaching line 72 again.
I don't understand the project (or git) well enough yet to try the changes on my own, but my naive opinion is that it's possible that the issue stems from there not being a new jump_position generated after 72.
The text was updated successfully, but these errors were encountered: