Dolphin, the GameCube and Wii emulator - Forums

I'd love to give feedback. But I'm not sure if we want to copy the same design issues as D3D11 already has :/

Hi!

It's been a while since I was last active in the forums, but well.. I feel my 2c might be appropriate here, given that I introduced the D3D11 backend originally. There have been some positive words about this change already, so I won't get into repeating those and instead move on to real talk immediately Do note that this is my personal opinion though, and the more active members of the Dolphin development team may have different understandings of code quality than I do.

tl;dr: I don't think it makes a lot of sense to introduce a D3D12 backend to Dolphin, currently. Here's a quote of mine from today's IRC explaining why:

Quote:17:52 <@neobrain> meanwhile, we still have little actual code sharing [between GPU emulation backends], so that new backend reinvents a lot of the concepts already used in D3D11 and OGL, while introducing new frameworks (e.g. the threaded rendering stuff) which should *really* be a common infrastructure instead
17:53 <@neobrain> You might argue that fixing up such infrastructural problems should not be his concern, and I would probably agree
17:54 <@neobrain> but at the same time the lack of common infrastructure makes introducing a d3d12 backend a huge maintenance bottleneck
17:54 < Bh44L> so, it might be worthwhile trying to implement that threaded rendering stuff first as common piece?
17:55 < Bh44L> (and generalize the other stuff to use a common base, where applicable)
17:55 <@neobrain> the threaded rendering was just an example, but yes.
17:56 <@neobrain> Even if it ends up only being used by d3d12, having it part of the core infrastructure makes sure it's maintained as a first-class citizen rather than ending up with situations like "uh right, my new patch runs on d3d11 and ogl, but not on d3d12 with its weird threaded rendering stuff... idk how to fix it, let's keep it broken"
17:56 <@neobrain> The only thing which *actually* should be handled by the API backends is resource and state management - anything else (especially emulator logic) should be in VideoCommon

Long story short: I'm not expecting hdcmeta to fix all of this mess, but at the same time that doesn't mean it's sensible to merge his work into Dolphin just because it has already been written. Introducing an OS specific (and even OS version specific!) backend introduces a huge maintenance overhead, which may slow down overall progress to the point where there is no net gain to be obtained. Time spent porting changes to the various backends may be better invested into general code infrastructure work.

In the end, we have to ask ourselves: Is there any actual long-term advantage to gain from introducing /yet/ another backend?

This is absolutely beautiful
tested for a bit
Heavy games and moments are faster now, shader compilation is kinda faster too
but, backend crashes if Per Pixel Lightning or Load custom textures is enabled
and hangs if MSAA is enabled

I'll do a ton of testing with my library of games/

First thing I noticed is, is setting the res and internal res to 4k, seems to cause crashes. Not sure if it's dsr or just the resolution causing it.

Thanks ZEROx and rlaugh0095 for the bug reports, I'll see if I can repro.

Hi Neo, first thanks for all the code you've written here, this is obviously building on that (all the shaders are identical actually..). Your feedback makes sense, I'll be on IRC tonight or tomorrow to provide a bit more color on what is different between the D3D11 and D3D12 back ends, and why the threading thing is needed. My current opinion is that it is something that is only needed on D3D12, since D3D11 and OpenGL drivers actually do this automatically (though might be worth experimenting with the app managing this..).

For what it's worth state management is simplified (I think?) due to how D3D12 groups state.. pushing and popping states isn't needed anymore, if that was an area of concern.

If push comes to shove, going the Ishiiruka route could still be cool.

(12-19-2015, 05:18 AM)UltraJake Wrote: [ -> ]If push comes to shove, going the Ishiiruka route could still be cool.

He and Tino should team up 
I've always wondered if dx12 could improve performance of taxing postprocessing shaders such as ssao.

Post processing shaders probably doesn't give a crap about what backend you use. They're applied after you render the frame after all.

(12-19-2015, 06:45 AM)helios747 Wrote: [ -> ]Post processing shaders probably doesn't give a crap about what backend you use. They're applied after you render the frame after all.

Such a shame :/

Anyway I don't think it was resolution or dsr that caused the crashes for me. I believe now that it was per pixel lighting. After disabling PPL, I was able to to go to 4k. At 4k res, I noticed a much higher performance gain in dx12's favor. Im uploading a comparison video as we speak using metroid prime 3 as an example.

Oh and I ran into this issue. I hit yes and then everything worked nicely.



https://www.youtube.com/watch?v=scJeU_w5GPQ&feature=youtu.be