Purge SSE2/SSE3

[GovanifY]

People are going to hate me for this one.

This removes all the dead code used to support SSE2/SSE3 accelerations.

[TellowKrinkle]

Not sure what happened but GSVector4.h has a bunch of random spaces added

[TellowKrinkle]

Also check the recompilers for checks to x86caps.hasStreamingSIMD*

[GovanifY]

Also check the recompilers for checks to x86caps.hasStreamingSIMD*

Did that and looked at non GS source too, I kept the SSE2 checks for the "features detected" log though

[GovanifY]

Not sure what happened but GSVector4.h has a bunch of random spaces added

Went over the patch and fixed the spacing issues, there were some on GSVector4i.h too

[lightningterror]

Keep solution, spu, core changes in separate commits.
If we want to completely wipe sse2 I think I saw a bunch in x86emitter and ipu for example.

[GovanifY]

Keep solution, spu, core changes in separate commits.

Ack

If we want to completely wipe sse2 I think I saw a bunch in x86emitter and ipu for example.

I didn't find any relevant use of x86caps or _M_SSE, you'll have to point me to them

[TellowKrinkle]

Also GSDrawScanlineCodeGenerator.x86.cpp and GSDrawScanlineCodeGenerator.cpp have some m_cpu.has(util::Cpu::tSSE41)s including a massive disgusting thing in ReadTexel_SSE

[GovanifY]

Keep solution, spu, core changes in separate commits.

split everything into different commits

[xddxd]

You’re welcome. Old hardware should not block progress from being made. What modern Pentiums don’t support SSE4? Pentiums support it since Sandy Bridge.

[TellowKrinkle]

There's 2 main issues

1. The plan for the GSdx merge involves disabling multiply-built GSdx as we carry out the merge. GSdx benefits most from SSE4 (AVX/AVX2 affect it much less), so the officially built PCSX2 will definitely drop SSE3 for that period whether we keep it as a build-time option or not
2. We keep accidentally breaking SSE3. SSE4 has a lot of useful instructions (min/max of integers, pinsr/pextr, movsx/movzx) that we end up adding to new code and not noticing until someone comes in with a sigill later. Most recently, SSE3 was broken for two months from ee07f86 to f9d96f5

I'll probably try to maintain SSE2 on my fork through the next official release as I'd like to have a fallback for Mac users (on Windows we can say "use 1.6.0" but there is no 1.6.0 for Mac), and since that'll include the plugin merge, going from there will probably not have too many merge conflicts to deal with for anyone else who wants to have SSE2 support, and anyone who is trying to keep SSE2 alive probably actually has an SSE2 computer they can test on to make sure new changes actually work

[asturur]

Again if the project is hard to mantain, you loose the ability to run newer versions entirely, because developers may stop doing the emulator at all. Have developers do what they have to do.

[ghost]

Again if the project is hard to mantain, you loose the ability to run newer versions entirely, because developers may stop doing the emulator at all. Have developers do what they have to do.

I am talking with the devs as you are seeing here. Let the conversation run, please.

We keep accidentally breaking SSE3. SSE4 has a lot of useful instructions (min/max of integers, pinsr/pextr, movsx/movzx) that we end up adding to new code and not noticing until someone comes in with a sigill later. Most recently, SSE3 was broken for two months.

I see... Well, that is understandable. But isn't it possible to shield all the SSE4 stuff from SSE2/SSE3 stuffs? Excuse me if I am talking nonsense but I am just asking because you can do this very thing to shield x86 code from x86_64 code.

I'll probably try to maintain SSE2 on my fork through the next official release as I'd like to have a fallback for Mac users

My fork will also keep SSE2 support. But all of the backwards and legacy support aside, I am currently trying to find a way to continue #4199 because I, again, do not have a SSE4-compatible system on hand. If it was not for the GSdx merge this would have been simple, just edit the plugin itself, but it will be much more difficult after the merge.

Perhaps I can find a workaround to this but we will see.

[fantesykikachu]

I see... Well, that is understandable. But isn't it possible to shield all the SSE4 stuff from SSE2/SSE3 stuffs? Excuse me if I am talking nonsense but I am just asking because you can do this very thing to shield x86 code from x86_64 code.

By shield you mean duplicate, and yes in theory they could keep it but it would be horrible to maintain. It is the same way with x86 and x86_64, right now there is a lot of duplication but as soon as x86_64 is fully working the plan is to drop x86 (32bit) support, just like many other emulators did like five years ago.

[tadanokojin]

Steam Surveys cannot be applied to emulation

Then nothing can be used because there are no stats that applies specifically to ps2 emulation (at least without telepathy, which is non-starter afaic) and we effectively have no data to rely on. Did you see the qualifier "potentially" in that sentence? I don't mean to be condescending but I'm not sure you realized that word is doing the work of telling you that this isn't meant to be interpreted as 1:1 with emulation users.

It's a decent sampling of gamers more broadly but even so I'm accounting for the fact that the sample might be slightly bias and I still don't think SSE2 is worth it. I think it's fair to recognize the overlap between this two groups of computer users and account for any potential bias in the data rather than just dismiss it outright.

Additionally, you're welcome to present other stats you feel are more accurately represent out user-base.

Not everyone who emulated will be rockin' a 1080 Ti or a Ryzen 7 or somethin',

I didn't suggest everyone does and neither does steam. AMD is barely a quarter of the market let alone a Ryzen 7 and a 1080ti isn't even in the top 10. I'm assuming you're exaggerating for effect but I'm not really sure what you're trying to suggest here.

the great deal with emulation is accessibility. And removing SSE2 will just stand against this.

You need to draw the line somewhere and It's clearly balancing act. Bring more than an absolutest stance about accessibility. Where is the line and why?

KH and Soulcalibur are NOT the only games I run

Nothing about that suggested they were the only games you run, just that they were games I'm aware you run which I preemptively addressed before they came up. KH in particular I wanted to address preemptively because it's an exceptional case that I suspected would come up given the nature of the conversation.

I wasn't even aware that you played SC specifically, I said "2D fighting games" because that seemed more charitable than the other 2D games I could think of as an example (visual novels). SC is a 3D fighting game last I checked.

Quoting one guy who said 'If you still use a CPU without SSE4 at this point it's likely under the minimum regardless so it wouldn't be supported anyway.' above.

That's not saying you can't use it. It's saying we likely won't provide support for it because it's too under-powered, which is true. I'm going to be charitable and say you probably just didn't understand what they were saying.

I can understand cutting support on deprecated APIs (DX9) or unsupported OSes (Win7, Win8) even though I do not support those decisions. But it seems baffling to e that you would cut out a supported architecture (All modern OSes will still run on SSE2) and in fact one that many of your peers still use.

We're not developing an OS or anything close to it. This is a confused point, d3d9 isn't deprecated afaik and I'm pretty sure there are operating systems that require at least SSE4 (MacOS and some linux distros I'm pretty sure).

[seta-san]

I feel for you. But we're talking about computers 10 to 15 years old. We dump computers by the dozens half as old.. I think you said you had a 775 socket computer. Don't core 2 quads supports sse4?

[TellowKrinkle]

My fork will also keep SSE2 support. But all of the backwards and legacy support aside, I am currently trying to find a way to continue #4199 because I, again, do not have a SSE4-compatible system on hand. If it was not for the GSdx merge this would have been simple, just edit the plugin itself, but it will be much more difficult after the merge.

I usually have two branches for PRs, one with MacOS patches and one without

I work on the one with patches, and when I'm done I git cherry-pick the commits onto the one I actually PR

You can git cherry-pick start..end to cherry-pick a range of commits at once

[asturur]

Again if the project is hard to mantain, you loose the ability to run newer versions entirely, because developers may stop doing the emulator at all. Have developers do what they have to do.

I am talking with the devs as you are seeing here. Let the conversation run, please.

I do not think this is the way to facilitate any running conversation. You should use any private channel with developers if you can't stand other points of view.

[lightningterror]

I think it looks good, could use some testing just to make sure nothing broke.
Maybe Tellow or Li can double check if something got left out.

[GovanifY]

@Mrlinkwii tested the PR and it seemed fine, @TellowKrinkle care to double check the PR in case?

[RedDevilus]

https://github.com/PCSX2/pcsx2/blob/master/pcsx2/Docs/PCSX2_FAQ.md#question-5-what-are-the-pc-requirements-to-use-pcsx2
Minimum: SSE2 will turn into SSE4. (W7 to W8.1 as well for 1.8)

[TellowKrinkle]

Looks good to me, though I'd prefer if you reordered the commits so that they all build (build system changes first)

Edit: Also rebase the part where you un-delete things you deleted together so it remains unchanged by any of the commits

[tadanokojin]

GS stuff looks okay to me, I think you should merge the two GS commits.

[GovanifY]

Looks good to me, though I'd prefer if you reordered the commits so that they all build (build system changes first)

Edit: Also rebase the part where you un-delete things you deleted together so it remains unchanged by any of the commits

done

GS stuff looks okay to me, I think you should merge the two GS commits.

done

[RedDevilus]

LGTM.