Pcsx2: PCSX2: Drop (or) Keep SuperVU Recompiler?

[ssakash]

Advantages on removing SuperVU Recompiler:

• Removal of large number of code -> faster building time
• No need to explicitly disable building it at some cases where it's not compatible yet. (https://github.com/PCSX2/pcsx2/pull/1335)
• Less VU recompiler options for configuration. Also allows removal of one Gamefix (VuClipFlag hack)
• All mentions of "MicroVU Recompiler" could probably be changed to "Recompiler" as that's the only recompiler other than SVU.
• Helps avoid #1599 (That's the main reason on why I opened this lol)

Disdvantages on removing SuperVU Recompiler:

• Potentially SuperVU might be faster on some games as it is less accurate.

At most cases, it looks like MicroVU is more accurate compared to SuperVU so it would be nice to remove the latter unless there's any need for it.

[FlatOutPS2]

Some games need SuperVU, so dropping it would be senseless as long as those issues haven't been resolved.

[refractionpcsx2]

I wouldn't remove it, as FlatOutPS2 said, some games require it to function properly (not sure why tbh, not looked in to it) and it is advantageous for lower spec machines as it is a bit quicker than microVU.

[MrCK1]

SuperVU can still be a helpful diagnostic tool for broken games (although Irridum Runners is still a clusterfuck right now)

[ssakash]

Some games need SuperVU, so dropping it would be senseless as long as those issues haven't been resolved.
some games require it to function properly (not sure why tbh, not looked in to it)

Agreed, it would be best to collect the list of all such games on a separate issue tracker so @refractionpcsx2 could look into them :)

[sudonim1]

Personally I'd like it gone, but microVU may well not be the last VU recompiler so I wouldn't count on changing everything with the assumption of there only being one VU recompiler. MicroVU is very unfriendly to work on currently and entirely different approaches to code generation are still an option worth looking into. An issue with all games that still work significantly better with SuperVU would be useful.

[jcdenton2k]

Until the compatibility and accuracy issues are resolved fully for EVERY PS2 game, it might be better to leave the alternative compilers in place just in case.

While it would make for cleaner code, PCSX2 doesn't seem to have a clear-cut way of dividing the two compilers into their own modules to allow the user to choose which one to use. Unless PCSX2 wants to start making decisions for the user instead of letting the user choose, the current system will ideally remain in place (aka let the user choose).

Once thing I absolutely love about PCSX2 is the variety of options that let the user choose between speed and accuracy with sliders and detailed descriptions. This setup is one of the reasons that PCSX2 wins major kudos for usability in my view.

I wish we could have nearly every emulator set up the same way where the end-user can have 'automatic' options set up and they can choose to override on a game by game basis if desired.

Please leave the 'old' compilers in place just in case. :)

[refractionpcsx2]

Once thing I absolutely love about PCSX2 is the variety of options that let the user choose between speed and accuracy with sliders and detailed descriptions. This setup is one of the reasons that PCSX2 wins major kudos for usability in my view.

This is how I see it personally, it's great to have variety and find the best balance for the games you are playing, but a lot of people see the vast array of options as overwhelming; they want something as simple as a console where you just turn it on and play, of course we need to strike a balance.

[jcdenton2k]

@refractionpcsx2

If people want a 'plug and play' device they already have the option of playing on the original console.

PCSX2 already has 'presets' and that can default to 'Safe' or 'Safest' so that they get their 'plug and play' experience without making a 'simplified' special build just for them.

Now if PCSX2 was able to be turned into a LibRetro module (with safest options hardcoded) then that could also be an option for them. I'm unaware of how feasible or practical it is to do that on the dev side.

PCSX2 compared to many other emulators is already so feature-rich and descriptive and user-friendly that even my own mother and my elderly neighbors can use it without issues (with those handy presets). The story of how I got them into emulation can be saved for another time, but whatever people are complaining about 'too many options' may want to just use the original console instead.

A bit of paranoia here but many of these advocates for 'plug and play' may potentially want it that way so they can rip off PCSX2, stick it on some Chinese pirate controller 'console on a chip' style device and sell it for a profit with some prepackaged ISOs.

The presets should be enough for those who want 'plug and play' unless they don't care about taking ~5 mins or less to set up their input devices.

[sudonim1]

A largely vestigial recompiler is an unnecessary maintenance burden. I don't know how necessary SuperVU is, but if it's <10 games running a little better or a little faster then it isn't necessary as old versions of pcsx2 do exist. If it's more or more significant issues such as games being unplayable or entirely a mess of seemingly random coordinates from miscalculated transformation matrices then it needs to stay until we've sorted that.

[refractionpcsx2]

If it's more or more significant issues such as games being unplayable or entirely a mess of seemingly random coordinates from miscalculated transformation matrices then it needs to stay until we've sorted that.

It's that, some games just don't work at all on microVU, they just freeze and throw infinite loop errors

[rz5]

Gotta start naming those games if we wanna create the 'Runs better on SuperVU' issue.

[jcdenton2k]

@sudonim1
Rendering certain games completely unplayable and telling people 'use an older version' is not user-friendly nor a sane development practice. Why 'break' backwards compatibility when it works fine right now?

If you insist on going down this path, you might want to fork a separate branch without the extra compiler and do your coding on that. Those who want 'easy maintenance' like you can go to that team while the rest can maintain the current codebase.

However, splitting the codebase like this would introduce drama and unnecessary code duplication (good luck porting patches back and forth). It would also split developer time/attention towards the singular purpose of 'make every PS2 game work as accurately as possible with a playable framerate on a decently modern set of hardware'.

This problem has been seen before in NES and SNES and Genesis emulation but particularly SNES emulation. The idea that 'good enough' emulation of only the most popular games with hacky coding and solutions is better for 'easy maintenance' and there's no need to strive for better.

I do NOT want to go down the path of bsnes/higan where we go so far extremely towards accuracy that we utterly ignore the end-user. But I do want to see PCSX2 maintain the current user-configurable balance of speed and accuracy depending on the hardware being used.

Just because YOU don't care about ~10 games doesn't mean we throw out backwards compatibility for the sake of 'code maintenance'.

Ultimately it is up to the devs but this is an open-source project and such a radical change may be best done by forking from this project and treading water as best ya can. Good luck.

If you do fork, then let's hope you end up a useful fork like Ubuntu forking from Debian instead of a dead fork like the people that disagree with Linus over how to code the Linux kernel, fork it, and then abandon the fork shortly afterwards (rendering it effectively useless). I do hope you maintain your fork for at least a few years :)

It would be useful to identify the games that require SuperVU and go from there. 'Runs better' can be debatable based on the hardware/drivers being used and testing has been limited at best. Just the ones that mandate 'SuperVU or it isn't playable from start to finish'.

[sudonim1]

Reading comprehension, please (also calm down). I said if there are major issues it needs to stay until we know what causes them, this is so we can make microVU as completely correct as is possible given the nature of the VU's non-IEEE compliant floating point implementation. Nobody's named a single game yet, by the way.

[FlatOutPS2]

One I know for sure is still affected is Driving Emotion Type-S. It goes back to the disc selection in BIOS when loading a race with microVU. It needs SuperVU

I know I've played one or two more games that had mVU issues that were solved by superVU, but I'll have to look into which ones.

I also had a look at the wiki, but I found mostly out of date v1.1.0 microVU issues that have since been resolved. Dawn Of Mana seems to have an issue reaching the MicroVU cache limit.

[gregory38]

The fact are that
1/ VU is a very complex topic
2/ we don't have manpower to keep an extra recompiler (PS2 emulation is already complex enough)
3/ it won't be ported to 64 bits (or any others arch)
4/ users still don't trust us to make right choices ;)

However, it would be nice to open an issue with all the affected game. (might need to search on the forum). Potentially MVU can be fixed/improved. But ultimately sVu will died (likely not soon)

[refractionpcsx2]

Just checked Driving Emotion Type-S, that seems to just crash in superVU and microVU resets the PS2, so not sure what's going on there. I'm sure there are games that don't work, just need to remember them 📦

Edit: Found one! DT Racer PAL version, that infinite loops on the PAL 50/60 selector screen if you use microVU, but works fine on superVU. Swapping to the microVU's later has the same effect also.

[rz5]

Alright, went ahead and made an issue for those types of games. If the devs are able and willing to keep the list freshened up, go for it. If not, I'll pop in once in a while to edit the first post. Not sure what's most convenient in terms of getting info at a glance - multiple posts from different users or a first megapost with checkboxes

[refractionpcsx2]

Megapost with checkboxes is probably best, Most of the regular users on here can edit your posts, so we can update it if we find any.

[pixelherodev]

Quick question (and I apologize if I sound stupid): Dawn of Mana reaches the mVU cache limit which causes performance problems. Couldn't a hack be created to increase the cache size for games with that problem?

Unless increasing cache size would just make it take more time for the cache to be filled...

[FlatOutPS2]

Quick question (and I apologize if I sound stupid): Dawn of Mana reaches the mVU cache limit which causes performance problems. Couldn't a hack be created to increase the cache size for games with that problem?

Does using SuperVU cause problems in the game?

[pixelherodev]

On Sunday, January 1, 2017 3:56:08 PM EST FlatOutPS2 wrote:

Quick question (and I apologize if I sound stupid): Dawn of Mana reaches
the mVU cache limit which causes performance problems. Couldn't a hack be
created to increase the cache size for games with that problem?
Does using SuperVU cause problems in the game?
I wouldn't know - I don't have the game.

I just was curious as to whether that would work or not.

[lightningterror]

Closing as supervu was removed in #3386