At least the SLI/Crossfire configurations i have seen and used, they show up as a single card to Opengl. The driver deals with everything. At least in the “make it really fast for a single screen” mode (or even span 2 screens mode). So it should work out of the box. Other modes probably not. As in need to be aware of different cards/devices and screens.
lwjgl3 already has Vulkan. Something like jME adding a back end to use it is far less work that starting from the ground up (I even looked at doing this). Vendors are pushing vulkan pretty hard in fact. However opengl isn’t going anywhere even if its all Vulkan under the hood. But Vulkan is probably the main standard to use 2-5 years down the line. I expect newer features to be added to Vulkan rather than opengl about a year down the track. But these will be top end features.
But consider than Nvidia have said many times, that there cards will always support opengl 1.1 even! Legacy apps are almost certain to be supported.
TL;DR Opengl 3+ is going to keep good company for a long while yet.
Thanks for your reply. I have a Crossfire system myself and played around with plain lwjgl and sadly the performance didn’t double neither increased any factor. I saw that AMD published years ago an interesting document talking about afr-friendly engine design (afr = alternate frame rendering = let the driver do the load balancing of two or more graphics cards).
So, to sum it up, does a simple app based on jmonkeyengine scales well on a multi gpu system? Maybe I have to try it out for myself.
Is there anybody interested in the result? I just could run a simple scene with a skybox and some textured boxes in it to make sure that there isn’t any bottleneck in the handling of the scenegraph (or anything else).
Regarding the Vulkan API: That is great to hear that lwjgl3 has already Vulkan. Didn’t expect such a fast adaptation!
JMonkeyEngine doesn’t have any special code for this and if it doesn’t work with lwjgl it would be up to the lwjgl guys to improve support.
That being said, you have to do proper measuring, the FPS time just isn’t enough, especially for your mentioned scene.
The reason why you have complex, different and high vert/tri scenes is simple:
Consider you have GPU A pulling out 60 FPS, that means you have 1/60th second for the processor and driver to do the handling.
If you’d now add another GPU B and expect 120 FPS, you’d have 1/120th second for the processor to do the handling of two GPUs, so you actually have 1/240th second for each.
Long story short:
a) Do proper profiling (using the SDK Profiler, for example), so you can actually see the CPU load and the time spent in different methods.
b) Take a GPU stressing scene (this means huge high-vert meshes, NOT many small!)
c) Keep in mind that the GPU Memory might not be doubled, so you can run into that overhead as well, when you try to simply duplicate your scene.
But that’s just my guesses, it could always be the OS, Driver, whatever influencing your results on that as well.
My bother uses SLI, but he runs on a 4K monitor at ultra high settings. He over clocks and water cools. His rig is almost 8k worth (NZD). He only bothers enabling it for a few games. He finds no real improvement for the others since they are maxed out anyway. He obviously has the best cards money can buy.
It should be noted that in the standard SLI mode, both cards act as a single card. I do belive this is on the PCIe bus as well. Hence you don’t send data to each card. You send data and both cards keep lockstep identical states. The one card will render half the screen and the other card the other half. Honestly you don’t need to care about this outside driver configuration. All DX/opengl code will just use since it appears as a single device. Also note that you don’t get free running FPS. The thing about SLI/crossfire is that you get to double your fill rate with 2x the cost of cards and 4x the cost of the rest of the PC