Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken BRI instruction in VertexProgramDecompiler #1165

Closed
dogboydog opened this issue Jul 31, 2015 · 4 comments
Closed

Broken BRI instruction in VertexProgramDecompiler #1165

dogboydog opened this issue Jul 31, 2015 · 4 comments

Comments

@dogboydog
Copy link

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 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.

@tambry
Copy link
Contributor

tambry commented Jul 31, 2015

@dogboydog Would you be able to give any specific games that do this?

@dogboydog
Copy link
Author

Sure -- the example shaders above are from trying to run Scogger HD

@O1L
Copy link
Contributor

O1L commented Aug 1, 2015

This is a known problem. There are several opcodes in shaders, which are hard to proper emulation. DH already made it in his local repository.

@dogboydog
Copy link
Author

Ah I see. Sorry.

@tambry tambry closed this as completed in 4666f19 Sep 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants