(03-24-2016, 09:15 PM)NoleNation Wrote: [ -> ]If it benefits even a little why not do it? We can't stay on DX11 forever.
Because the developers don't want to do it. I don't see any reason why you can't use DirectX 11/OpenGL forever.
(03-24-2016, 09:18 PM)tsunami2311 Wrote: [ -> ]Just cause it help dolphin dont mean it will do the same for pcsx2 either
Exactly, it won't have the same benefit as dolphin, we have already spoken to the dolphin devs and the Wii (and possibly GC) pushes a lot more draw calls than the PS2 ever does, so they will see a reasonable improvement. We won't as driver overhead isn't really an issue.
I still say to making sticky about DX12 to stop asking with reason why, so people stop ask. Not that people read things like stickys or rules lmao
Short of Gabest geting the needy feeling to do this it not happen any time soon last I heard, It all about Opengl and Vulcan going foward if Gregory has his way!! I waited years for Opengl to become thing in pcsx2 and now it is and it was worth the wait it far better then the other options and it maintained.
(03-24-2016, 09:15 PM)NoleNation Wrote: [ -> ]If it benefits even a little why not do it? We can't stay on DX11 forever. Dolphin has already started work on the DX12 backend and it definitely helps.
Because it's been determined that the benefit would be so little that it wouldn't justify the added developer load. The PS2 is not a Wii, and has significantly different emulation requirements.
(03-25-2016, 08:22 AM)Akio Wrote: [ -> ]How do you know this?
Because I work closely with h gregory who does a lot of gpu debugging
(03-24-2016, 09:15 PM)NoleNation Wrote: [ -> ]If it benefits even a little why not do it? We can't stay on DX11 forever. Dolphin has already started work on the DX12 backend and it definitely helps.
DX12 is barely out, we are far from forever. Dx12 dev investment won't be free. Instead if we invest this time in openGL, how many bug could we fix ? (mipmap? fmv black screen? missing texture? ....)
(03-25-2016, 08:22 AM)Akio Wrote: [ -> ]How do you know this?
The openGL driver is running in a separate driver thread. If we were driver limited, any improvement on the GSdx side won't have any impact on the performance.
* I made a small change recently to avoid useless copy of data in GSdx, it gives 5/10% increases on various games.
* I made a hack for snowblind engine to reduce the internal cache management of GSdx. Games got a 50%/100% speed increase.
* Accurate blending / full depth requires lots of extra draw calls. Yet you can enable it in most game without a major speed impact.
Some games are maybe limited by the driver. But most are GPU limited, so limited that various people uses DX9 instead of DX11 for the speed (whereas DX11/GL CPU overhead ought to be smaller)
DX12/Vulkan will allow to brute force the GPU. But it won't solve all the bugs in the texture cache/management. And trust me, there are lots of them.
Quote: * Accurate blending / full depth requires lots of extra draw calls. Yet you can enable it in most game without a major speed impact.
As a side note, the same option on AMD driver is awful for the performance. So you can easily conclude that AMD driver is draw call limited. (and driver limited). The solution is to multithread GSdx not to port it to a new API (that will requires multi thread anyway).
(03-25-2016, 12:29 PM)refraction Wrote: [ -> ]Because I work closely with h gregory who does a lot of gpu debugging
Thank you for the information.
(03-25-2016, 12:34 PM)gregory Wrote: [ -> ]The openGL driver is running in a separate driver thread. If we were driver limited, any improvement on the GSdx side won't have any impact on the performance.
If that is the case, then why does enabling the Threaded Optimizations option improve the performance? Also, I suppose it should benefit dual-core systems. What about software mode?
(03-25-2016, 12:43 PM)gregory Wrote: [ -> ]As a side note, the same option on AMD driver is awful for the performance. So you can easily conclude that AMD driver is draw call limited. (and driver limited). The solution is to multithread GSdx not to port it to a new API (that will requires multi thread anyway).
Do you mean using a new API will also solve the problem, but it's not a logical solution?
Quote: If that is the case, then why does enabling the Threaded Optimizations option improve the performance? Also, I suppose it should benefit dual-core systems. What about software mode?
SW barely uses the GPU so there is 0 driver overhead. (less than 5 draw call by frame)
If you want the best speed on PCSX2, you need 4 cores for MTVU anyway. And the purpose of Vulkan/DX12 is to use more thread, so it requires 4 core too.
Here an example of the MT impact:
* G is 1 cycle in GSdx
* D is 1 cycle in the driver
* _ is 1 idle cycle
Without multithread you have
With multithread you have
Code:
GGGGGGGGGGG
____D___DDDD
Even if the driver overhead was 0. The time spent to convert GS texture to the GPU format won't be 0. There are possibilities to reduce further the driver overhead even with openGL. However it will cost extra GPU cycles.
AMD openGL doesn't support multithread, however AMD DX11 supports it. Actually maybe MS provide it for all drivers. New APIs are lower level, so the multithread part must be done by the application.