Poll: Keep or Drop legacy SuperVU
You do not have permission to vote in this poll.
Keep it.
32.00%
16 32.00%
Drop it.
68.00%
34 68.00%
Total 50 vote(s) 100%
* You voted for this item. [Show Results]

Keep or drop superVU
#11
my advice is to keep it!
Core i3 9100f 3.6Ghz
RAM=8GB
nvidia GT 1030
pcsx2 version-1.3.1  
Reply

Sponsored links

#12
(07-20-2014, 03:46 PM)Blyss Sarania Wrote: removing 12k lines of complexity from the code far outweighs that IMO.

^This, PCSX2 source is becoming much larger and more complex as time progresses and the emulation becomes more accurate; as such I would think dropping sVU in favour of the more modern and accurate mVU would help keep the project more readable, which IMO is also a very important criteria.

Also while I do understand that more accurate is relative (as mentioned some games fail to work with mVU) I think having different recompilers for different CPUs is an unnecessary complexity/mess, specially as sVU is sort of outdated, and focusing current efforts on fixing those 'broken' games (if anyone cares about them and/or requests this) would be the right approach towards the future.

I think dropping it is the sensible way to go, mVU with MTVU is much better than sVU even if compatibility on those 20 or so games suffers (which is only 0.008% of all games on the compatibility list), removing outdated code is the logical way to proceed to keep the source manageable.
Reply
#13
Just my 2 cents, this is actually a complicated problem. Having a second core helps a lot with finding bugs. I hate to use Dolphin as an example, but I think it applies here. JITIL is a second core that's slower, isn't really worked on, and has been up on the chopping block at least once. Yet, it's been integral in finding/fixing bugs in the JIT and even Interpreter twice this year alone. This is because the behavior differs (right or wrong) on this core, which, also seems to happen on SVU vs MVU. Even though JITIL hasn't been touched, its helped solve crashing bugs, collision bugs, and without it, tracking down the ghost problem in Mario Kart games would have been impossible.

It's always good to have a secondary care to fall-back on when reporting bugs; it can help track things down. As PCSX2 gets more accurate, what is considered accurate in the MVU may not be so accurate any more, and differences found between it and the SVU could prove invaluable.

Considering the state of PCSX2's code base, I don't know how portable/plausible it is to isolate/maintain the SVU. Dropping it will increase the testing on the MicroVU and put a higher demand on it being more accurate for the times that it does have problems, because of the lack of an alternative. So, it really depends on what is wanted.
Reply
#14
I think is better drop it and focus only of make upgrade and fix only for microVU.....And much less code to maintain....
Reply
#15
Here's a question that might aid perspective on this for those of us who don't actually work on the emulator, whatever the answer is.

By removing it, 12,000~ lines of code would be removed, but aren't most of those segmented off in their own module(s) to only be called upon when SVU is used? How many of those lines are cluttering up other parts of the codebase and making it hard to add new code elsewhere in the emulator or at least understand the existing code?

Obviously if most of those lines are segmented off, it doesn't necessarily clean up the code as much as it first appears to remove them since most of what you'd remove is just stuff that coders won't look at unless they're working on the SVU in the first place. However, if the SVU accounts for tons of code scattered everywhere throughout the emulator then removing it might be as valuable to people trying to understand the existing code or write new code as it appears when one sees the number 12,000.
Reply
#16
(07-20-2014, 11:55 PM)BlackTelomeres Wrote: Here's a question that might aid perspective on this for those of us who don't actually work on the emulator, whatever the answer is.

By removing it, 12,000~ lines of code would be removed, but aren't most of those segmented off in their own module(s) to only be called upon when SVU is used? How many of those lines are cluttering up other parts of the codebase and making it hard to add new code elsewhere in the emulator or at least understand the existing code?

Obviously if most of those lines are segmented off, it doesn't necessarily clean up the code as much as it first appears to remove them since most of what you'd remove is just stuff that coders won't look at unless they're working on the SVU in the first place. However, if the SVU accounts for tons of code scattered everywhere throughout the emulator then removing it might be as valuable to people trying to understand the existing code or write new code as it appears when one sees the number 12,000.

Well the 12K are only the dedicated SVU files. However as far as I understand, various structure are shared between interp/SVU, interp/Mvu, interp/SVU/MVU. So it might help to improve the code in the future.

If someone want to port PCSX2 to another arch, superVu will likely be dropped.

I think the first step before any action is to gather a recent list of all games that work only with superVU
Reply
#17
(07-21-2014, 09:50 AM)gregory Wrote: I think the first step before any action is to gather a recent list of all games that work only with superVU

I couldn't agree more, dropping a core needed for popular games is not a good idea
Reply
#18
Well if 20 games are bugged in mVU it will take quite some time to fix them. Specially if you drop sVU, because it could help tracking those bugged games.

Also it doesn't look good seeing the Unplayable bar increase.
CPU:
Intel Core2 Duo T5450 (1.666 GHz)
[Image: gzztty.png]
GPU:
Mobile Intel® 965 Express Chipset Family (500 MHz)
GPU-Z Validation
Other:
RAM: DDR2-666 (2 GB)
---
Not a gaming PC, but I'll try to get a better one in the future.
Reply
#19
It is very likely that these 20 games have issues when run with sVU.
Those issues may prevent mVU running the games at all, while sVU somehow
copes with them and just causes glitches or memory fills up until it crashes.

I'm in favor of removing sVU to make way for other archs (thinking x86-64).
People working towards this goal get easily annoyed by a huge, incompatible module like sVU.
There are a lot of lingering issues in the code for it, issues that can affect stability eventhough
the rec isn't even being used.

Still, since there is a use for it as long as it compiles, maybe it should be #ifdef 0'd instead outright deletion.
Are there other solutions that move it out of the way for those that don't want to deal with it? Anyone? Tongue2
Reply
#20
Well, if said games work with sVU right now, since it isn't like it is going to be updated by anyone whether we keep it or not, so people can just download 1.2.1/2 and use that to play those games until mVU improves enough to play said games.
Reply




Users browsing this thread: 1 Guest(s)