GSdx Merge

[tadanokojin]

I'll start our first discussion with merging GSdx.

First a few blockers

• imine pr to fix bo sky issue: GS-hw: fix Burnout games black sky. #4094 GS-hw, TC: improve tex in rt. #3895
• nicer person made a pr for wayland support Wayland support #4075
• red PR to change some gui stuff GSdx-GUI: Conservative buffer allocation, reordering and more #3973
• tellow vertex tracer improvement GSVertexTrace::FindMinMax improvements #3940
• tellow jit work GSdx: Merge SetupPrim asm #3579 GS: Merge assembly files in GS #3577

Red stuff should be done soon. Vertex tracer stuff can go in (need to find time to review it). I think we can sneak wayland support in. I'm less optimistic about the jit stuff making it in time because it's such a large change. The imine stuff is in limbo right now, I'd like to see it done before but I think imine will understand if we can't get it in in time.

Some stuff that needs to be discussed:

1. What to do about intrinsics/GSVector.
2. Converting GSdx from mcbs to unicode to match the rest of the codebase
3. Creation of a gui for gsdumps in the main application
4. Porting the jit to support cpu detection

If I miss any blockers/outstanding issues please let me know.

[GovanifY]

Reviewed the wayland PR, I'll focus on getting this one in first. I'll let you handle the pure GS ones.
The JIT PRs aren't finalized iirc, has this changed?

[tadanokojin]

Possible Compiler Intrinsics Solutions

Personally I hate GSVector. I think it just makes the code confusing and it's not worth the reduction of code duplication. I'd almost prefer some utility functions with ifdefed instrinsics. But rewriting it now will be troublesome. So for now we are stuck with it.

Runtime Detection
As far as I know only GCC/Clang support this and MSVC it needs to be handled manually.
But even if we do get it working, I'm concerned about the added complexity. At a glance it seems like a mess to get it right on MSVC.

If anyone has more information (documentation, insight, etc) please post.

Minimum Support
This is my favorite of the options. We simply choose a minimum SIMD level and run with that. We can expose more advanced SIMD through a compiler flag for people who want to mess with it but our chosen level should be something supported by most processors.

• AVX2 is probably out of the question
• AVX is on the table but we lose support for modern Pentium G without AVX. Some of these are more than capable of running PCSX2 at above recommended specs.
• SSE4 is my favorite option. Most CPUs support it.
• SSE2 is dead to me and I think if you are stuck on SSE2 you need to get with the times.

Compromise Runtime and Minimum Support
We can do something like support SSE4 and add a runtime check for AVX. This was something suggested by Greg.

Plugin But Not (but actually yes)
Another idea I've seen floated around is we dynamically load GSVector. I'm not a big fan of this idea personally. I think it's kind of antithetical to the goal of merging GSdx in the first place. Additionally I think it would be a nightmare considering how GSVector is implemented, you'd be checking for the GSVector8* implementations all over.

Separate Versions of PCSX2
Non-starter for me. I won't even entertain the idea.

This is one of the things I'd like done before the actual merger. The potential for bugs is big and debugging these kinds of problems with a giant merge in the middle is going to be a PITA. Please feel free to correct any information I might have gotten wrong here.

[tadanokojin]

Yes but detection is one thing, will it compile the SSE4 code with an AVX function in it even if it is if'd out. I think MSVC will just fail to compile in this case (I can be wrong) or will compile AVX. My understanding is GCC/Clang have flags for this.

[GovanifY]

According to what I just read we can force it to compile such cases, but testing will have to be done
source: https://stackoverflow.com/questions/55747789/the-effect-of-architecture-when-using-sse-avx-intrinisics/55753275

[TellowKrinkle]

To have versions for multiple ISAs, we need to compile the same functions multiple times, to make one version for each target ISA. IMO the easiest way to do this is to use one source file, with a preprocessor-added prefix / namespace on the function names, and compile it multiple times with the different settings.

I know how to do that with cmake (add extra object file targets that reference the same files with extra definitions, link them all with the gsdx target) but I don't know how to do this for msbuild

Also you can't dynamically load GSVector or you'll be making one function call per instruction, and would be slower than just compiling for SSE2

[Anuskuss]

When was the last time you guys did an analytics/survey? Are there really that many people using Pentiums and actively playing PCSX2? What about folks without x64 processors? Would also be interesting to know how many people are still using Win7, considering it lacks some features. It's probably too early to drop support although they're only at 3.68% according to Steam.

[tadanokojin]

We dropped support of Win7 in 1.7.0 already.

[gregory38]

My feeling
1/ First raise the bar to SSE4.1 (or 4.2 not sure it is used) minimum. It doesn't solve anything but it would make thing "easier"
2/ I would postpone the real merge of gsdx after 64 bits.
As an intermediate step, you can keep 2 builds (SSE4.x and AVX2), and open the plugin automatically based on the CPU detection. So users aren't aware of the plugin-ess of the emu.
3/ Until 64 bits is done, you can still do preliminary work (resolve name conflict, replayer, ... whatever you need to merge gsdx).
4/ When 64 bits is ready => port GSdx SW to automatically pick up AVX2 or SSE.
5/ Next step would be to automatically dispatch some function based on the CPU support. For example, it might doable to add an AVX bool template parameter to GSBlock function.

[GovanifY]

fwiw 64 bit memcard issues are fixed by this PR: #4113

[gregory38]

@GovanifY Just to be sure, your tellow comment is about the GSdx SW JIT ? Or something else

[GovanifY]

They are

[TellowKrinkle]

Yeah GSdx SW x64 Windows

I personally think it's outside of the JIT, I did all sorts of things with the JIT and couldn't get the bug to happen on macOS or not happen on Windows.

And while I'm not going to say I won't work on it, I don't spend much time in Windows and am not especially looking forward to searching for this bug in it

[TellowKrinkle]

Revisited JIT on Windows, turns out the issue was improper saving of callee-saved xmm registers, now runs successfully

[gregory38]

Ah I don't bother to do fine grain check. Just check SSE support (means SSE4 which should be checked once by the emu at startup). And check AVX2 (so both AVX2 and AVX1 should be required). The gain of AVX1 alone is not big so no need to bother

[lightningterror]

Adding support for gsdump debugging should be done before the merge. Only then we can proceed with the merge.

[GovanifY]

This was already said in point 3. of the top comment, moreso this will more probably happen during the merge than before it.

[tadanokojin]

No, before.

All 1-4 will be handled before.

[GovanifY]

Current state of things:

blockers:

• Unicode merged in GSdx: switch to unicode #4188
• Vectors/Intrinsincs multiple ISA mostly done in GS: Single build with all ISAs #4193
• GS Dump debugger reimplem mostly done in GS/Core: Implement the new generation of GS Debugger #4271
• JIT work not started yet but should be trivial.

All PRs listed in the first message have been delayed until the merge is done.

I expect blockers to be done within this month if I'm not getting too busy/lazy, and then the merge will happen

[GovanifY]

Small update: the GS Debugger is now merged, leaving the JIT runtime and multi ISA work.

The multi ISA PR contains work making the JIT able to automatically switch, and currently only miss its windows implementation, so we are getting there!

[tadanokojin]

Updated Plan:

1. Drop SSE2/3
2. Compile GSdx to SSE4/AVX only
3. Do the merge
4. Tellow is going to rework the CMAKE project to support windows and handle multi-isa
5. Rework the JIT to handle runtime AVX2

[GovanifY]

The GS merge is finally there: #4436

[RedDevilus]

It's over :)