GSDX: Drop (or) keep D3D9 renderer ?

[ssakash]

It was recently stated that the last stable version (1.4) will be the final version which will have support for windows XP, so having D3D9 renderer isn't as necessary as before since we don't have to worry about people with windows XP.

Advantages on removing D3D9 renderer:

• Initial step on removing DX SDK dependency.
• prevents inexperienced users from using D3D9 since it misses lots of recent changes like Snowblind fix and other stuffs.
• D3D9 renderer also has lots of other issues which aren't present on D3D11/OpenGL. less better choices makes it more user friendly for the users.
• No need to have a logo for D3D9 and also saves space at combo box.

Disadvantages on removing D3D9 renderer:

• People with graphics cards lower than Fermi / AMD equivalent can't use any renderers on GSDX.

[refractionpcsx2]

I think I'm for it. It serves little purpose these days with OpenGL being so good, and as you say, we aren't supporting Windows XP after 1.4, so that's a non-issue.

However, unless it is getting in the way somehow there is no real reason to remove it, we can always make GSDX default to DX11 or OpenGL

[turtleli]

Initial step on removing DX SDK dependency.

It's possible to remove the DX SDK dependency from GSdx without removing the D3D9 renderer.

[Nobbs66]

Like ref said, if it's not getting in the way, then just change the default to OGL or DX11, but still allow those on old hardware to use Dx9

[refractionpcsx2]

Yeh i think the big issue was the windows sdk not supporting windows xp, so it should be fine.

[Nobbs66]

Maybe for 1.6 DX9 can be removed, but the minimum requirements will have to be updated to fit.

[refractionpcsx2]

That's the idea, that's why we are in the development period for 1.6 :P

[Nobbs66]

Yeah, I guess I really don't care if it's there or not. The default does need changing though.

[FlatOutPS2]

Like ref said, if it's not getting in the way, then just change the default to OGL or DX11, but still allow those on old hardware to use Dx9

The default is already DX11. If you use a fresh PCSX2 build and boot into a game without changing any VIdeo Plugin settings DX11 is used, not DX9. Though it does show DX9 as default in the VIdeo Plugin settings menu.

[vsub]

The default is already DX11

Not really...I just downloaded the 1.4.0 binary(and the latest dev build)and run it(no settings exist)and when I hit configure on GSDX,the DX9 was selected(third line from the list)

And I also prefer to keep it

[FlatOutPS2]

Read the rest of what I said. Don't go to the settings, just boot straight into a game without touching the video(GSDX) settings and watch the top of the game window. It uses DX11 HW.

[mirh]

Initial step on removing DX SDK dependency.

This will never be possible to be honest. XAudio 2.7 is going to be required for decades considering Vista and 7 are just fine...
and not to mention DirectInput that will always be irreplaceable.

Said this, if we are really dropping XP (a real pity if you ask me)..
considering even 2008 Intel GMAs are dx10 (dx10 class gpus are supported in dx11, right?) I guess there wouldn't be cases where somebody would be hurt.

[willkuer]

Possibly appveyor will still support xp. Newer visual studio versions won't but i guess except for that there is no hard reason to drop xp. Ogl should as well work on xp btw.

As replacement for xaudio one could use portaudio.
Probably there are open source dinput to xinput wrapper.
Possibly sdk is dropable but why should one remove features without good reasons?

[turtleli]

Since I have been experimenting a bit more on the DX SDK removal stuff, here are my current findings:

• GSdx - can be migrated to Windows SDK without feature removal, but requires a bit of work.
• SPU2-X - can be migrated to Windows SDK without feature removal, but Windows 8 or later is required because of XAudio2 2.8 (unless we also make a Windows Vista/7 build that still uses the DX SDK, that way Windows 8 or later users wouldn't have to install the DX redist stuff).
• LilyPad - can be migrated to Windows SDK without feature removal, but Windows 8 or later is required because of XInput 1.4. DirectInput still seems supported.

On another note: The non-XP compatible toolchains lets us use the Visual Studio code analysis tools.

Just an FYI ;) I don't really have an opinion on keeping/removing D3D9.

[refractionpcsx2]

I knew there was a reason we couldn't remove the DXSDK, I couldn't quite remember and convinced myself it was just XP support.

There is no chance we can drop support for Vista and 7, it's just not even an option for a good long time, so we can remove the DXSDK from GSDX, but it is here to stay for the other projects.

[mirh]

This remembers me of #564 :)
Also, I'm with @willkuer about the lack of an hard reason to drop xp.

And I'm not so sure there aren't noticeable differences between portaudio and XAudio2 in windows. Both as latency and compatibility.

[tsunami2311]

if 1.4 is gona be final version that support XP then going forward i dont see why removing DX9 would be issue, there really should be many people still running XP anymore, and most cards these days support DX10 and up. but i know nothing about programming so .

Then again I think DX9 need to die and stop being used, its one reason why newer versions of DX take for ever to take hold imo

[refractionpcsx2]

There is a hard reason, we are slowly trying to move the emulator to 64bits, something which xp can't do (yes i know there is a 64bit version of xp but hardly anybody uses it)

anyway, 1.4 is out, it's probably going to be another year or 2 until 1.6 is out, by which point anybody still using xp is either insane or incredibly poor :P but we need to move forward too and 64bit seems to give the memory addressing advantages that will see better speeds and potentially we might have better float support if we can get it to use larger floats.

Furthermore the share of windows xp users on the web is currently 11%, it's been dropping at nearly 1% a month over the last year, it's entirely possible in a years time it's going to be less than 1% of users, not really something worth clinging on to if it's going to hinder our progress.

I was one of the ones advocating keeping support of it, up until now where it is looking like less reason to keep supporting it for future versions. 1.4.0 is pretty good, it will do more than enough for the capabilities of a machine running Windows XP, I sincerely doubt people will play many advanced games on those systems, it will be more for the joy of emulating it, even at bad speeds.

[escape209]

This needs an official discussion thread on the forums IMO.

[gregory38]

http://store.steampowered.com/hwsurvey/directx/

Steam stats are potentially more interesting as it is "gamer" oriented. It isn't bias free but I think we can consider than real xp users are closer of 5% rather than 11%. Lots of computers are only used for web browsing.

Agreed, 1.4 is enough for XP user. If they want modern feature, they need to get a modern OS. By the time 1.6 is released. Vista will be EOL too (yeah nobody use it).

In theory, you can use openGL on XP but I'm afraid that drivers aren't updated anymore (maybe Nvidia?).

However, nobody is working on GSdx, so DX9 so far it isn't issue. So I dunno if it is really worth it to drop it now rather than in a couple of months.

[refractionpcsx2]

Steam stats are potentially more interesting as it is "gamer" oriented. It isn't bias free but I think we can consider than real xp users are closer of 5% rather than 11%.

according to the survey its less than 3% :p
then again linux accounts for 0.6% of steam users.

[mirh]

There is a hard reason, we are slowly trying to move the emulator to 64bits, something which xp can't do (yes i know there is a 64bit version of xp but hardly anybody uses it)

You still haven't explained how the two things would be mutually exclusive then :p
And.. I thought there weren't going to be big advantages in 64 bit port, if not for the code cleanup that it would have been needed to get there.

In theory, you can use openGL on XP but I'm afraid that drivers aren't updated anymore (maybe Nvidia?).

Nvidia has no XP driver altogheter with 8xx series and above, but it still continues to update XP drivers up to 7xx series.
As for AMD, latest supported driver is 14.4, that supports up to 2xx series.

There shouldn't be any problems though, even with older drivers (hoping older amd aren't even more lame :s)

then again linux accounts for 0.6% of steam users.

I propose to drop XP when linux will be double of it xD

[refractionpcsx2]

And.. I thought there weren't going to be big advantages in 64 bit port, if not for the code cleanup that it would have been needed to get there.

There aren't any in the sense most people are thinking :P The 64bitness itself provides no measure of speed improvement, period, however the advantage we will have is the same one that Dolphin experienced when rewriting the memory management, we can virtually map the entire PS2 memory to ram (it is a 4gb virtual space) so we can access it quicker and more direct, which will bring a nice performance boost if we do it right.

Zerofrog did try something similar eons ago back in 0.9.2 but it was buggy, users had to set a horrible setting in windows for it to work, which didn't work with everybody, it was messy :P

[Nobbs66]

Honestly, let XP die at this point. Even Microsoft has dropped support for it. XP users can't even use PCSX2 built with VS 2015, which eliminates all builds from the Orphis Buildbot.

[gregory38]

according to the survey its less than 3% :p
then again linux accounts for 0.6% of steam users.

Yes, I know. But I think there is a bias on steam (said by a valve guy) (so I cut the pear in 2). Don't remember the bias (maybe a bit too much American guy on it).

Linux users base doesn't count :p It is free to support, last but not least the main dev is a nice guy ;) And OS isn't 10 years old... However we can propose XP users to switch to linux for free ;)

There aren't any in the sense most people are thinking :P The 64bitness itself provides no measure of speed improvement, period, however the advantage we will have is the same one that Dolphin experienced when rewriting the memory management, we can virtually map the entire PS2 memory to ram (it is a 4gb virtual space) so we can access it quicker and more direct, which will bring a nice performance boost if we do it right.

Zerofrog did try something similar eons ago back in 0.9.2 but it was buggy, users had to set a horrible setting in windows for it to work, which didn't work with everybody, it was messy :P

Well I tried to do it, not perfect (and I need to check the mirroring behavior actually). But perf is around 1% rather than 10%/20%. I don't think it will much better on 64 bits. So current perf limitation is somewhere else.
The main gain of 64 bits are

• reduce complexity emulation of 64 bits operation
• reduce register allocation management
• plenty of memory to avoid to fix GSdx (note: Nvidia linux driver has a workaround to use more than 4G textures on 32 bits)
• direct memory access (potentially faster but so far in the 1% ballpark, but I have a bit more steam)

However there are extra cost for 64 bits. And it would be potentially less portable (due to different ABI on different OS). So globally perf will be in +/- 10%. But once the code is ported to 64 bits, it will be killer to support both 32 bits & 64 bits..... So 2.0 will be 64 bits only ;)

[refractionpcsx2]

Well I tried to do it, not perfect (and I need to check the mirroring behavior actually). But perf is around 1% rather than 10%/20%.

That might be because you didn't do it perfectly :P It needs to be done and working optimally to see any advantage, the current system was done in an optimal way to benefit the most from that style of system, the same will need doing with the new one too.

[mirh]

we can virtually map the entire PS2 memory to ram (it is a 4gb virtual space) so we can access it quicker and more direct

As I already said plenty of time, that's already feasible in 32 bit builds to be honest.
We just needed LAA.

XP users can't even use PCSX2 built with VS 2015

XP users can. Iirc there's just a problem with SPU2-X that for god knows which reasons crashes and needs to be built with vs2013. But I'm not sure conceptually this problem has to be attributed to OS if I can explain.

plenty of memory to avoid to fix GSdx

( ͡° ͜ʖ ͡°)

But once the code is ported to 64 bits, it will be killer to support both 32 bits & 64 bits..... So 2.0 will be 64 bits only

This has something to do with you switching over #634 I guess?

In that case I see why one would prefer to drop x86... but technically I fail to see the "hard implication" this has with XP drop.
Perhaps when we'll necessary need to move over a new VC version (for C++14 or C++17 support reasons I guess?) with no XP support I'd see really the time has come.

[refractionpcsx2]

As I already said plenty of time, that's already feasible in 32 bit builds to be honest.
We just needed LAA.

how? LAA gives you exactly 4gb of user space on a 64bit system, on a 32bit system this is 3gb providing the user has put the 3gb switch on their windows boot ini. If we are mapping 4gb for the virtual memory space (which wouldn't be possible on 32bit regardless), where is the recompiler memory etc going to go? I could be missing something entirely here.

But the way i see it, either option has 32bit totally out, and by extension, windows xp.

[gregory38]

@mirhl
Direct memory access requires to reserve 4GB for the EE memory alone ! On 32 bits, nothing remains for anything. Anyway, XP supports just get costlier every months. Less and less people will report issue with it. And seriously you give money to Microsoft so asked them so support their OS longer. We already give 2 more years than Microsoft (for free). And it is likely be 3 or 4 when 1.6 is out.

That might be because you didn't do it perfectly :P It needs to be done and working optimally to see any advantage, the current system was done in an optimal way to benefit the most from that style of system, the same will need doing with the new one too.

You hard with me :p Honestly I think I'm not too bad. However we can do better. I'm thinking of the function call for basic HW register read. And in the future, we could potentially avoid the flush of some x86 registers (but x86 registers are already flushed every instructions anyway). Now I'm not sure that will really impact the perf.

[refractionpcsx2]

You hard with me :p Honestly I think I'm not too bad. However we can do better. I'm thinking of the function call for basic HW register read.

Not being hard, there is always room for improvement with anybodies code :) It's just finding a way to do it, we can make things better!

And in the future, we could potentially avoid the flush of some x86 registers (but x86 registers are already flushed every instructions anyway). Now I'm not sure that will really impact the perf.

If it's doing it every instruction now, it "might" not impact very often, depending on how much the x86 registers are used, it would be an interesting thing to benchmark on number of register allocations/deallocations and uses, maybe for xmm too, just to see :) But if they are used a lot and flushed a lot, there could be a nice performance increase from avoiding that.

[mirh]

Oh.. EE..
Ok, stupid me. So.. I guess we have three things we should decide when to drop:

• D3D9
• 32bit
• XP

And theoretically the question is always: does it entail more drawbacks than benefits?

[avih]

As said before, it's the only option AFAIK on OS X (with Wine[skin]).

On a similar note, and although I haven't tried it recently, It might be easier to setup PCSX2 with DX9 on a Windows VM than other backends.

It'd be a shame to drop it IMO, unless it frequently hinders progress elsewhere.

[avih]

@avih I think a true OS X port would be a better alternative, even if it took a lot of time and effort.

I don't argue this at all. Are you the one who's going to put the time and effort to make that happen? because if not, for now, that's the only option on OS X.

Even if it was planned, being worked on actively, and "just around the corner", I'd still wait with removing DX9 until it's actually proven to work better than Wineskin on OS X.

[escape209]

@avih Fair enough. Are there many users on OS X, though? And isn't Bootcamp also an alternative?

[avih]

Haven't counted them, but I'd bet an order of magnitude more than Linux.

[ramapcsx2]

I missed the OS X users, yea. On that note, I remember DX9 working pretty okay in VMware while OpenGL didn't.

[gregory38]

Ah yes, OSX. That being said there still the legacy plugin. Because I'm afraid that apple doesn't enough to pay a guy to support recent gl driver.

OpenGL used to work on vm machine before I made several extensions mandatory (potentially I can make them mandatory only for the hw renderer if it doesn't work).

So far dx9 doesn't hurt so it can be kept but I'm afraid it won't be available forever.

[ssakash]

Well, since there's the legacy GSdx plugin right now, any new opinion on dropping the D3D9 renderer?

[FlatOutPS2]

There are games that actually run quite a bit faster with the D3D9 renderer than D3D11 without any downsides, so I wouldn't drop it until any D3D11 issues that D3D9 does not have are fixed.

[gregory38]

At least not before before a 1.6 release.

Faster, CPU or GPU wise ?

[FlatOutPS2]

Faster, CPU or GPU wise ?

Mostly GPU I believe.

[lightningterror]

Pretty much all of the dx10/11 issues that weren't present on dx9 have been fixed so I guess we are one step closer.

[lightningterror]

Adding this to 1.8 milestone.
I don't need to say anything else.

[MokuDuk]

1. As long as pcsx2 DX9 maintained - maintained a 3D stereo support from TriDef.
   [for both software and hardware renderer]

[if it will be dropped - only a chosen ones with external monitor and Nvidia will be able to play]
[or it will be possible to play with smaller GSdx3D compatblty] [however, while it's smaller, it's outstanding] [it's like a demo of an amazing game-possibility] [hardware mode only]

2. I have lines in my memory, when DX10/11 was faster, OGL showed most beatifull full of effects picture and was slow and unplayable, and DX9 was between them - at the time it was free of DX10/11 errors, showed proper waves on ocean, and it was faster then OGL- I played Tekken 4 and NFS: HP II with it.

3. What's about Linux Wine, WineHQ, DXVK?

[willkuer]

If you aim for faster but less accurate emulation you can always use older versions. There are barely any performance improvements (apart from recent the texture cache lookup which improved a few games) nowadays so it doesn’t make much sense to update if you are not interested in accuracy.

In theory the native linux port should be better than wine+dx9 - at least with reasonable gpu drivers. About the others I don’t know.

[mirh]

1. Doesn't TriDef also support d3d11?
2. (putting aside.. I think it should be possible to have some kind of chinaghetto mode with some heavy effect disabled?) I also recall dx9 being said to have some performance advantage once. But I tested it one month ago and not not only it was slower, it of course had quite some bugs.
3. I'm a fan of gallium-nine, but *native* exist. If for some reason you are getting less speed, then by all means it would be something worth investigating. But.. check?

[MokuDuk]

@mirh as for pcsx2 - Tridef is working with dx9 only, https://forums.pcsx2.net/Thread-Gsdx-3D-Stereoscopy-Patch?page=13 I've tried to get work iz3D, but no luck here too. [at least from myself with mostly user experience]. Thank you for gallium-nine mention) - it's the first time when I hear about it.

@willkuer for me pcsx2 always only improving) Thank you for making it better! =D
I know that I can play older version - and I did some time ago for Soulcalibur III, when without shadows game ran faster. But now I can play even with shadows - all thanks to improvements of speed made for accurate versions.

I meant that DX9 for me in the past showed some effects, that DX11 didn't, while still losing some that OGL showed. DX9 was in between, with the speed between them too.

And as for Linux my questions was also about - is there a way to play on Linux with shaders? Or in Compiz Anaglyph? Maybe it's better to have one more output that will have it's own chance of working with shaders and stereoscopy? [and mirh noticed about gallium-nine which relies again on dx9 only, and might be faster then existing wine]

In anyway I want pcsx2 team to decide. Everything is happening.
It's all a matter of what a team like and how they like to make their great magic.
What a world they like to live in.

[mirh]

[and mirh noticed about gallium-nine which relies again on dx9 only, and might be faster then existing wine]

I actually thought that was what you were talking about in the first place, when mentioning "dx9" and "linux". I'm not personally aware of any such situation (and I'd really be grasping at straws if I had to cherry pick some possible edge case from all gpus ever released).

And shaders are just dx10/11 AFAIK, so there's not much else to say about them.

On the other hand, keeping Tridef compatibility really would seem like something "worth it" in my opinion.

Unfortunately some devs are starting to get into uprooting everything remaining about dx9... So unless somebody step up for "assuring it keeps staying maintained" I wouldn't see it getting back.

[gregory38]

Dx9 is a dead end. It was completely broken and unfixable. Worst, it was in the way to improve dx10. You can use older version if you prefer broken but "faster" rendering. Otherwise upgrade your CPU/ GPU.

Wine will eventually get dx10 (if not done already). And if the gl driver is good enough (aka multi-threaded), native gl will be as fast as wine (dx or gl whatever).

Crappy program that depends on dx9 should be fixed.