DX 12 open source e-multigpu work around

[ARCT3CH]

DX12 provides a very interesting and superior alternative to SLI or Crossfire. 
Rather than have the game driver take turns producing frames, they just split the frames, and therefore, the work 50/50 through the apu. 
This is much less taxing as it removes much of the post processing and allows for mixing of graphics cards. The problem is it has to be implemented into the 

dx12 game itself by the developers who often times don't feel the need since most people don't rock dual gpus. 

Is there an open source work around for this? Perhaps something similar to "different sli auto" but for the explicit multi gpu feature of dx12?

Or perhaps a way to personally implement it into my fav games?

 

[ARCT3CH]

Let me know if this should be in software instead of programming as I wasn't sure and felt it could fit in both categories depending on what the possible solution is. 

[Radium_Angel]

5 minutes ago, ARCT3CH said:

DX12 provides a very interesting and superior alternative to SLI or Crossfire. 
Rather than have the game driver take turns producing frames, they just split the frames, and therefore, the work 50/50 through the apu. 
This is much less taxing as it removes much of the post processing and allows for mixing of graphics cards. The problem is it has to be implemented into the 

dx12 game itself by the developers who often times don't feel the need since most people don't rock dual gpus. 

Is there an open source work around for this? Perhaps something similar to "different sli auto" but for the explicit multi gpu feature of dx12?

Or perhaps a way to personally implement it into my fav games?

 

Not that I am aware of.

 

[Sauron]

A workaround for what, developers not implementing the feature? There's a reason it needs to be implemented, otherwise it would just always be automatic...

[Franck]

2 hours ago, Sauron said:

A workaround for what, developers not implementing the feature? There's a reason it needs to be implemented, otherwise it would just always be automatic...

True. if it was that easy we would do it. There are many problem but synching is probably the worst one. Yes you run multithreaded features but at one point they need to be sync on your screen. We can't have the bullet hitting the wall arrive after the physx effect particles from the collision happening. What if the 2 GPU are not the same (which you can totally do) then for sure (even if the they are the same) they are not equally fast. You need to delay one on queue so the second can kick in later.

[riklaunim]

18 hours ago, ARCT3CH said:

Rather than have the game driver take turns producing frames, they just split the frames, and therefore, the work 50/50 through the apu. 

DX12 doesn't have any SLI or CrossFire mode. It's up to game engine developer to support multiple GPUs and the implementation doesn't have to be alternate frame rendering or splitting frame into parts. It's more likely that each GPU (like dGPU and iGPU would be most common) would get it own set of tasks. Like the game dev can use iGPU for some smaller task helping the dGPU in finishing a frame bit faster. Multiple different dGPU could also be coded for but the market of PCs with multiple dGPU is close to non-existent. There is like ONE GAME that does that.

 

19 hours ago, ARCT3CH said:

Is there an open source work around for this? Perhaps something similar to "different sli auto" but for the explicit multi gpu feature of dx12?

DX12 is a low level API and it's up to the game engine to use multiple GPUs and schedule tasks as they see fit. Any Auto-SLI would have to be hidden behind that API - like Nvidia drivers/scheduler level - which is what Nvidia nor AMD want to do any more.