![vulkan_lava[1].jpg](https://i.imgur.com/SGRqCvv.jpg "vulkan_lava[1].jpg")
how can engine devs exploit multi-GPU setups using the new graphics APIs? keeping in mind current hardware limitations such as
>pci-e to pci-e bandwidth/latency
>one cable between GPU and display
>discrepancies in performance even across identical models
are the following possible?
>buffering over multiple GPUs
>preloading scenes in unused vram for instant loading
>daisy chain rendering (eg gpu 1 does geometry/textures -> gpu 2 does shaders -> igpu draws UI -> done)
>one engine, multiple scenes (eg local hotseat)
>striping vram (8gb + 8gb = 16gb)
or we will still be stuck with shitty parallel rendering techniques that barely make it worthwhile?
>>55520525
I'm hoping to see DP cables with even more and more bandwidth so that we can daisy chain GPUs and displays and enjoy contiguous video memory as well as indiscriminate rendering
In the end your computer would be one seamless pool of resources and your monitor setup just one big canvas as far as software is concerned
This shit require devs to actually think. Not gonna happen.
>>55520699
>every engine is gamebryo
sure, most engines will continue being low effort shit but there are geniuses all over the place.
I'm personally interested in seeing what croteam, Id and epic accomplish
>>55520735
>geniuses
AAA studios aren't interested in "geniuses". They just care about the cost and time required to develop a competitive engine.
>>55520699
Hopefully what happens is devs can use Vulkan on top of existing OpenGL to circumvent driver issues.
Stuff like GPU Open, Open Source stuff like AMD has been doing would really help getting shit going.
>>55520789
>AAA studios aren't interested in "geniuses".
you've obviously never spoken to a manager.
>They just care about the cost and time required to develop a competitive engine.
which is why they license engines. and engine devs do care about marketable features and out-performing the competition. specifically because of the devs that license their engines.
why are you so pessimistic?
>>55520924
I'd rather see opengl run on top of vulkan so that it can be phased out of drivers. although I guess the opposite wouldn't cause too much overhead either.
Anything that requires devs to code for a minority of users is going to be put on the side and/or ignored entirely.
>>55520699
>t. /g/aymer faggot
>>55520525
Most of it is already technically possible in one way or another, but not implemented anywhere.
>>55521172
Triple A studios are compromised mainly of marketers and code monkeys. That's not all that smart. If they were physicist and engineers that'd make more sense
Asynchronous thingies are very handy for that sort of business now.
>>55525025
"Daisy chain rendering" is not possible in some apis like OpenGL, because you need to make a shared context for that, but it's not what you need to share buffers, etc(at least, its not thread safe)
>>55522844
This. The only way we'll ever see multigpu work in the majority of new AAA games is if the new consoles have two GPUs.
>>55520525
>daisy chain rendering (eg gpu 1 does geometry/textures -> gpu 2 does shaders -> igpu draws UI -> done)
No, but
>gpu 1 does shadows/gpu physics
>gpu 2 does the main scene
>igpu does UI
would work
>>55520525
>preloading scenes in unused vram for instant loading
We already can do that, but most games tend to use up all the vram they can with streaming textures and such.
>>55520735
>croteam, Id and epic accomplish
Ever since Carmack finished up megatextures in 2009, ID has just been doing mediocre engine stuff. Croteam is bretty gud, but they are too small of a team to do any crazy stuff. Epic still does some neat shit, but they are too obsessed with screenspace reflections.
I am hyped for the engine that RESET runs on. Their latest video showing the weather was amazing.
>>55520525
Easy, I would split renderable objects into groups by textures/models and share them across gpu-s so that the weakest gpu gets least amount of objects to render and the fastest gpu gets the most.
>>55525201
you don't say
