Dolphin, the GameCube and Wii emulator - Forums

What is the problem if it's not removed? Is it difficult to improve Dolphin further if D3D9 is still supported?

Currently, Dolphin is quite good. Why the rush to remove an important feature for some users? I would understand if it was version 0.8 that still needed a lot of work and D3D9 happened to get in the way.

(09-03-2013, 05:10 AM)xemnas Wrote: [ -> ]What is the problem if it's not removed? Is it difficult to improve Dolphin further if D3D9 is still supported?

Yes.

(09-03-2013, 05:10 AM)xemnas Wrote: [ -> ]Currently, Dolphin is quite good. Why the rush to remove an important feature for some users?

How is it even a rush? The first serious discussions about removing D3D9 date back to March of this year. The ranting about it started long before.

Every single one of the features I quoted in my previous message, which each would potentially provide a performance or accuracy improvement, is impossible to implement with the same codebase for D3D9 and D3D11/GL.

By rush, I mean there are issues with D3D11 that doesn't occur with D3D9. And if I understand correctly, OGL is the slowest. If all the D3D11 issues are fixed then D3D9 is dropped, then it's no rush.

Is it impossible to restructure the code in a way that D3D11/OGL can be improved while D3D9 can still be supported?

I believe that one of the reasons that some of D3D11 issues haven't been reported because the users just switch the back-end to D3D9 and it works. Removing D3D9 might force the users to report the issues or might not. They might just use the old build and use D3D9. However, in the long run this might work out.

xemnas Wrote:And if I understand correctly, OGL is the slowest.

Depends on the drivers, the hardware, and the game you're running. Linux OGL performance can match D3D9/11 performance, as some users have reported.

xemnas Wrote:Is it impossible to restructure the code in a way that D3D11/OGL can be improved while D3D9 can still be supported?

How many ways can delroth say no? :/

xemnas Wrote:Removing D3D9 might force the users to report the issues or might not. They might just use the old build and use D3D9. However, in the long run this might work out.

The people most affected by not reporting D3D11 issues are the people not reporting D3D11 issues. The issues won't get fixed, and they'll be stuck with old builds (which will have issues newer revisions have fixed, not just related to graphics) just to use D3D9. It's in their interest to report them even if they do stick with older revisions.

Yes, that could be done by maintaining a fork of VideoCommon, or making a 2-layer VideoCommon that is abstract enough to handle both a D3D9-compatible implem and a common D3D11-GL implem. This means basically making our code 2-3x more complicated than it currently is.

Are you or any other person that wants to keep D3D9 support able to write this code and support it in the near future (at least 2+ years)? If you are not, your opinion does not matter. End of the discussion.

Keeping D3D9 support would be easy-ish if our VideoCommon code didn't suck as much as it did. When writing most of it the focus was getting stuff to work at all, which was a good thing at the time, but really is the reason for most of the problems we're facing with it today.

Getting VideoCommon into a better shape basically boils down to rewriting the whole thing and if there was any interest in keeping D3D9 compatibility it certainly would be possible without having to fork everything (delroth apparently disagrees), but I don't see any point for keeping d3d9 compatibility when the work going into that could just be spent on getting the VideoCommon rewrite done faster.

Anyway, seconding what delroth said - we're the ones who develop most of the code, so it's up to us what kind of decisions are taken. User opinions are taken into consideration, but generally the developers can judge the big picture better than end users, and I'm fairly sure this rule applies here as well.

> Having proper state tracking instead of our current stupid "flush everything on changes"
very importend. This would speed up all of our backends, dx11 the most as it internally also use state objects which are created and destroyed per flush.
> caching transformed vertices with Transform Feedback
I don't think this helps much. I think it's more importend to strip down the amout of streamed data by using gpu side lookup tables and only upload small integers. atm we do this on cpu in our VertexLoader
> doing texture decoding on GPU
Yeah, we have an opencl one, but I still don't get it why nobody created util shader for this work. All other (not so importend) texture transforming (efb2ram, real xfb) are already done in this way. btw: we also have to support lookup tables here ;-)
> using integer shaders instead of our hacks
I don't think this will speed up much, but it will fix almost all tev issues and is still faster (a bit)
> having a proper buffer/memory manager
Nice streaming is importend, the performance of our VertexStreamingHack is possible without dirty hacks, but we need a redesign of our buffers.

tbh, half (but not more) of the above is possible with dx9, but mostly in a dirty hacky way. So the only funny way (neither neobrain nor me will do it else) is to not care about dx9 :-(

> That would most likely be degasus
hm?

(09-03-2013, 06:20 AM)Shonumi Wrote: [ -> ]Depends on the drivers, the hardware, and the game you're running. Linux OGL performance can match D3D9/11 performance, as some users have reported.

Thanks for the information.

(09-03-2013, 06:20 AM)Shonumi Wrote: [ -> ]How many ways can delroth say no? :/

It's technically possible. I wanted to know how difficult it is.

(09-03-2013, 06:20 AM)Shonumi Wrote: [ -> ]The people most affected by not reporting D3D11 issues are the people not reporting D3D11 issues. The issues won't get fixed, and they'll be stuck with old builds (which will have issues newer revisions have fixed, not just related to graphics) just to use D3D9. It's in their interest to report them even if they do stick with older revisions.

Yes. That is why I said in the long run it might work out. I didn't say that the people who don't report the issues aren't affected. The issues affect everyone who use D3D11. It doesn't matter whether they report the issues.

(09-03-2013, 06:20 AM)delroth Wrote: [ -> ]Yes, that could be done by maintaining a fork of VideoCommon, or making a 2-layer VideoCommon that is abstract enough to handle both a D3D9-compatible implem and a common D3D11-GL implem. This means basically making our code 2-3x more complicated than it currently is.

Are you or any other person that wants to keep D3D9 support able to write this code and support it in the near future (at least 2+ years)? If you are not, your opinion does not matter. End of the discussion.

Thanks for the information. It seems my opinion doesn't matter. So no need to discuss this any further.

(09-03-2013, 06:28 AM)degasus Wrote: [ -> ]hm?

This means everyone is now looking to you when DX9 gets removed, so you can bring DX9 speed to the other backends. I hope you're prepared.

(09-03-2013, 06:43 AM)xemnas Wrote: [ -> ]Thanks for the information. It seems my opinion doesn't matter. So no need to discuss this any further.

Don't read too much into it, that's just the way he is. I was planning on sending him to a "management and communication skills" seminar, but he probably wouldn't go anyway..