Pcsx2: 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?

[gregory38]

Now that I removed mmx. The full flush is sometimes a couple of xmm registers. And likely 0 int register... I hope to restore an efficient register allocation in 64 bits. However, maybe I will use the same trick to conpress the 4GB memory space. You can't use 64 bits address directly (or displacement). Otherwise it would require to reserve a register to contains a base address. I have a better plan for them ;)

64 bits port isn't really started. Removal of 32 bits can wait. My opinion is that we can keep dx9 (and therefore xp) until it just breaks. We are far from a 1.6 release. We can rediscuss it before the release.

[gregory38]

Win7/8 users got a free upgrade ticket to Win10. I think it will end in August. It seem they want to release a Win10.1 too. Therefore I propose to do a summary in September (if XP build doesn't completely break before). And hopefully old GPU will be upgrade too.

[BlackTelomeres]

DX9 is significantly faster on many games. Please just leave it and mark it as depreciated.

[escape209]

@BlackTelomeres The only reason it's faster is because it doesn't support a lot of the stuff that later DirectX versions do - that's my understanding of it, anyway.

[BlackTelomeres]

@DPersonalized
I know, but some people just want to be able to play the games at full speed on their machine and don't care about sacrificing accuracy to do it (especially if it doesn't really noticeably affect the games they're playing). Some explosions for example will noticeably drop FPS on DX11 but go off without a hitch on DX9 while looking the same as far as anyone not analyzing them pixel for pixel will notice.

[tsunami2311]

July 29th is the end of the free upgrade to Win10 for Win7/8 http://windows.microsoft.com/en-us/windows-10/upgrade-to-windows-10-faq

What is the free upgrade to windows 10

[MrCK1]

What is the free upgrade to windows 10

Users can upgrade to 10 for free until July 29. After installing, they have a 30 day period in-case they desire to roll back to their previous OS. The upgrade is the full OS, it's not a trial or anything. Personally, it wasn't my taste - forced updates, annoying gripes and explorer freezes.

DX9 is significantly faster on many games. Please just leave it and mark it as depreciated.

Before I got a dedicated gpu; I was using my integrated Intel Graphics 4600 (i5-4460)
That was the only time where DX9 was faster. After I got my GTX 750, I went to OGL and never looked back

[BlackTelomeres]

@MrCK1
Would you be okay with essentially dropping support for integrated GPU users? Because they are the ones who benefit from having DX9 as an option.

[ssakash]

I'm also now having second thoughts on dropping D3D9. initially I thought it would help removing the DX SDK dependency but if it can still be removed while also having D3D9 as @turtleli stated then I don't see a reasonable reason to remove it.

The other possible conflict is when people who aren't much aware of video renderers use D3D9 and get problems with it (which are fixed on D3D11/OGL) and report it to the forums. ( it's a bit troublesome to always say them to switch to D3D11/OGL :P )

[BlackTelomeres]

The other possible conflict is when people who aren't much aware of video renderers use D3D9 and get problems with it (which are fixed on D3D11/OGL) and report it to the forums. ( it's a bit troublesome to always say them to switch to D3D11/OGL :P )

I think marking it as depreciated/"for legacy support only" or "no longer in active development" in the UI itself would help with that so people would realize not to report bugs with it and just try DX11 or OGL to see if the bug is fixed there on their own. I only have up to version 1.4.0 but in that version there's still no real indicator of that which I can see.

[willkuer]

Bug reporting requires testing of all available options. I haven't seen a dx9-only report for quite a long time - if ever.

However i think all agree on keeping it until it would require time or energy to keep/maintain it. For intel igpu's and amd gpu's its a possible/reasonable speedhack.

[Nobbs66]

Now that @BlackTelomeres has brought up the iGPU situation, I'm starting to
think that he's right in just marking it as legacy. That's only if we can
remove the DX SDK dependency.

On Fri, Feb 12, 2016 at 10:21 AM, BlackTelomeres [email protected]
wrote:

The other possible conflict is when people who aren't much aware of video
renderers use D3D9 and get problems with it (which are fixed on D3D11/OGL)
and report it to the forums. ( it's a bit troublesome to always say them to
switch to D3D11/OGL :P )

I think marking it as depreciated/"for legacy support only" or "no longer
in active development" in the UI itself would help with that so people
would realize not to report bugs with it and just try DX11 or OGL to see if
the bug is fixed there on their own. I only have up to version 1.4.0 but in
that version there's still no real indicator of that which I can see.

—
Reply to this email directly or view it on GitHub
https://github.com/PCSX2/pcsx2/issues/1171#issuecomment-183394080.

[mirh]

We cannot, we already said this.
For the moment, I'd just stick with what gregory said

[tsunami2311]

iGPU are not bound to DX9 they run DX11 just fine and are faster in that mode providing the drivers are done right, like how Opengl would be great on amd if they fixed there driver implementation.

[refractionpcsx2]

It depends how old the iGPU is.

[tsunami2311]

that is true but if there iGPU is that old that it dont support latest DX10 chances are the cpu is to old and slow to run pcsx2 to begin with special if it on laptop

[refractionpcsx2]

The same arguement can be given for a computer running XP as they stopped selling PC's with that before 2010. DirectX 11 wasn't even thought of then.

[BlackTelomeres]

iGPU are not bound to DX9 they run DX11 just fine and are faster in that mode providing the drivers are done right, like how Opengl would be great on amd if they fixed there driver implementation.

that is true but if there iGPU is that old that it dont support it chances are the cpu is to old and slow to run pcsx2 to begin with

DX11 might be faster on Intel iGPUs if Intel knew how to write their drivers properly (or cared to do so) but the fact is they don't and will never learn, so in practical situations DX9 is often faster, even on somewhat modern iGPUs like the HD4000 series.

[MrCK1]

I don't mean for this to sound mean, but I feel like every other user should not be expected to carry the "extra weight" because of the lowest denominator.

XP support ended almost 2 years ago; and we are at the point where devs expect users to be running at least Win 7 with modern HW - especially for an emulator

[i30817]

There are people running pcsx2 in portables from 2008 running at 15 fps (ie: me). But quite frankly, if they are doing that, like me, they should be doing it in linux, like me.

[BlackTelomeres]

@MrCK1
Windows 8.1 user here. I don't really see what weight I'm shouldering so people can keep using XP with PCSX2 anyway. It doesn't feel like any weight at all. The devs may be shouldering weight in code complexity or the like but other users aren't really AFAIK.

And in 5 years or so if you want to be able to keep using W7 or 8.1 due to MS' creepy W10 policies, you might not like the position of throwing away support for old OSes so easily when someone brings up throwing out support for 7 and 8.1. Of course you may be fine with the way W10 is going, I dunno.

[MrCK1]

@BlackTelomeres I won't mind upgrading when it's time. I dual boot w/ Debian and Win 7 support lasts until 2020. Win 10 needs to mature alot more before it's going on my PC :P

[willkuer]

I don't think this discussion yields anything countable. We had exactly the same points in all past discussions about this subject. The main reason for this issue was that ssakash wanted to remove the dx depedency. It is not possible so that this discussion is dead. Removing dx9 would be quite easy and can be done shortly before 1.6 is this is the wish of the devs.

[gregory38]

DX9 is a requirement for the Wineskin of the Mac "pseudo port". So DX9 will stay longer.

[ssakash]

Closing this issue since currently there are no beneficial reasons to remove the _D3D9_ backend.

[ssakash]

According to the following thread, @gregory38 is planning on removing D3D9 support for future builds. However it'll be available on the legacy build of GSdx.

Some reasonable quotes from the thread :

I don't see how moving DX9 to the legacy plugin could upset anyone. Or at least it shouldn't.

The fact is our DX9 backend isn't being worked on. And it isn't gonna be worked on. It's not gonna change. Whether it stays in mainline or gets pushed to legacy, the DX9 backend will be EXACTLY the same. So yeah, I don't see how it could be an issue really. There's nothing to lose and a good bit of code simplicity to gain.
-- Blyss Sarania

Please drop the support for the legacy hardware, it's not like users are going to be able to play more demanding games on their 10 year old toasters anyway. Focus on the current tech and making the emu as compatible as it can be.
-- Exos

So the idea was to create a legacy GSdx for openGL. So why not put DX9 in the same boat.
-- Gregory

[refractionpcsx2]

Is this still the case though? As said by gregory

DX9 is a requirement for the Wineskin of the Mac "pseudo port". So DX9 will stay longer.

[ssakash]

Is this still the case though? As said by gregory

That comment was made on February 27, Gregory created the D3D9 removal thread on forums at 3rd of March. Guess he had a change of mind :P

[refractionpcsx2]

i guess :P

[gregory38]

well. It seems to help iGPU. So far it doesn't bother me so I didn't delete it. To be honest, it is a Windows related issue so I don't really care ;)

[mirh]

I don't think "dropping" and "moving to legacy" actually mean the same thing.

Isn't dx9 still getting some -incidental- kind of improvement from dx11 renderer development then?
I can think to recent GTA color filter issue for example.

[gregory38]

bad example, I broke it when I change the handling of depth format in openGL. I'm nearly sure it will break other game. So I'm not even sure I will merge it anyway.

[ramapcsx2]

At this point, I don't see a use for the DX9 renderer anymore. DX10/11 have superseded it and offer better emulation and comparable speed. Some games can run faster with DX9 but usually that's because of missing effects. OpenGL offers a 2nd great renderer for Windows users.
I'm all for shedding DX9 and moving on.

[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]

1. 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.

2. 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.