Windows 10, Directx 12, and GSDX

[Carsomyr]

With the release of Windows 10 on the horizon and along with it coming Directx 12 (and Vulkan on the OpenGL side of things) I was just wondering if there is anyone in the community with the skills to make a DX12 plugin? The benefits the new API brings to making more efficient use of multithread CPUs and reducing CPU bottlenecking on lower end CPUs can not be ignored in my mind.

(more on the benefits of Directx 12 here: http://blogs.msdn.com/b/directx/archive/...tx-12.aspx ).

However in my time at the forums I have seen multiple posts saying the author of GSDX is long gone... Thus my question: Do we have any coders capable of making this happen? I myself do have some C++ and python experience but I am a pretty entry level coder... I would love to work on it but fear I lack the skills and experience

[dogen]

If the benefits are worth the work required, maybe gregory will work on adding a Vulkan path to GSdx.

[Carsomyr]

Yes I have seen Gregory doing amazing things on the linux side of things and his name is all over the majority of the GIT builds (give that guy a round of applause and a gold medal or something, he deserves it ). I haven't looked into Vulkan that much as I have been vigorously testing the Windows 10 Insider Preview, but I understand it is basically the OpenGL equivalent to compete against DX12.

(For anyone interested, here is the main page for information on Vulkan: https://www.khronos.org/vulkan )

[gregory]

I think it might be better to fix GSdx emulation first. I'm not sure the work to port to a new API worth it (except for mobile stuff).
The new API requires that each applications develop their own part drivers (I mean the top layer). It would help us because it would allow to tune it properly for emulation. But
1/ GPU makers already optimize their codes.
2/ Gs geometry rates is 60M/s (if not limited by "FS" part). So 1M by frame. Honestly I don't think we need more than 10K draw call by frame (MTGS3 is around 10K but I need to double check it).
3/ lots of draw call imply lots of geometry imply EE/VU processing! I think the VU thread is already the limited factor.
4/ A MT API is nice but I'm not sure it suits well emulation.
* standard game do: upload texture/upload texture/upload texture ... draw/draw/draw ...
* emulation do: upload texture draw, upload texture draw, upload texture draw

Anyway, let's wait final API, working driver, working debugger tools. And real benchmark (I'm counting on dolphin guys). There no need to rush it.

[Carsomyr]

That all makes sense I mean obviously part of me asking was to see if the benefits were great enough and how much work would be required I would be super interested to get involved with coding something like this myself but as I said before I have no solid code writing experience... I can do simple things with C++/Python but that is about it

[gregory]

Honestly, new API requires to redo a lots of code. Because you need to code the memory management and synchronization. Thread management. Code validation. In short, all codes that used to be done inside the driver. Otherwise it would be slower than current code. So it is hard (even harder without bug-free driver/debug tool).

By the way, I'm not against DX12, but I would prefer a cross-platform solution.

However you can start to help to fix various effect with DX11/OGL features. Yes there is no marketing hype to use those API but I'm sure it is possible to increase speed with them. And to fix various stuff.

[ssakash]

gabest usually implements the new API's so, I think there is still a hope for DX12 on PCSX2.

[dogen]

gabest usually implements the new API's so, I think there is still a hope for DX12 on PCSX2.

Yeah, who knows.