Hi all,
The machine we’ve just taken delivery of has 2x 2080Ti cards, though at the time when we were specifying it there was no option to add an NVlink bridge. I understand that once there is an NVlink you effectively double the VRAM capacity. Does it also affect rendering performance/speed too? (asking here but also curious about vraygpu too)
Lavina can’t use NVLink currently and I am not sure it will be able to in the future since it’s built on DirectX.
Greetings,
Vladimir Nedev
So then do we need to remove the NVlink if we want to use 2 cards, or it will automatically ignore the NVlink and just use 2 cards anyway?
Today you need to disable SLI in the driver or remove the physical bridge that connects the cards in order for Lavina to use both GPUs for its performance.
If the bridge is in place, and SLI is enabled, then Lavina just sees one GPU and the second GPU doesn’t contribute.
We are looking into ways to make this easier in the future.
- Phil
With today’s update (0.5.0), you should be able to use the linked cards without disabling SLI. This may also provide higher framerates in some cases, compared to the same two cards with the link disabled, because the maximum framerate for a given resolution (e.g. with empty scene) is limited by the link speed between the GPUs.
Note that while we’re taking advantage of the link speed, this does not automatically mean we have double the memory. Sharing resources between the two devices is something we will try to do in the future.
I’m new to Lavina so I might be missing something here but… I seem to be have a different experience to the earlier posts. I’m unable to run update (0.5.0) with Nvlink enabled. Before installing I rolled back my Nvidia drivers to 446.14 as suggested in the install requirements and have been able to run all earlier updates of Lavina without hitch. Whilst as suggested, Lavina just ignores one of one my cards, I have been able to load scenes in excess of the 10Gb limit on the card. I’m currently testing a scene that’s using 13Gb VRAM with Nvlink enabled in update (0.4.4). The only way I can get update (0.5.0) to run is with Nvlink off. Then obviously I’m running into VRAM issues again with the 10Gb limit. Does anyone know what might be going on here? I have 2x 2080Ti Nvlink, Threadripper 3990X and 256Gb RAM. Thank you.
Will Mclardy
Hi Will - thank you for specifying your machine configuration.
We recently discovered an NVLink incompatibility with CPUs having a great many cores, and your 64-core CPU certainly qualifies here.
While this should get fixed in our next update, there is a temporary work around using an environment variable.
Open a command console in your Lavina folder and enter: set VRAY_NUM_THREADS=8 and then type lavina.exe to launch Lavina.
If that works, you can put that into a .bat routine and make a shortcut to it on your desktop to make it easier if you’d like.
Kind regards,
- Phil
Wow thanks Phillip, That works a treat. Both cards up and running with Nvlink and now managing to load the larger scene files. I wasn’t expecting to see a huge jump in performance but I can confirm there is definitely a marked improvement esp. on rendering out a sequence. Now I can melt both GPUs instead of just one!!! (hitting 85C!!)
Kind regards
Will
You can probably do more than 8 threads, something like 32 should be safe as well.
The lower thread count will slow down the loading of textures and meshes, so you will wait longer for the .vrscene to load.
Greetings,
Vladimir Nedev
In any case this is only a temporary workaround. Future Lavina releases will limit their resource usage internally, so you won’t have to set this environment variable (actually you should get rid of it when this time comes).
Version 0.5.1 released today should work without hacking VRAY_NUM_THREADS.
This all sounds promising. Can someone confirm that using NVLink effectively doubles the memory capacity when using Lavina?
The two 2080ti’s I have aren’t NVLinked and it is crashing on load all the time because (I suspect) the scenes are too large.
No, unfortunately it doesn’t magically double the memory. It nearly doubles the render speed, but we have to explicitly manage memory in some complicated way (i.e. write a bunch more code) to make it share the memory pool. It’s also not quite clear what the performance impact would be of storing render resources on the neighbor GPU because it is guaranteed to increase memory access latency.
Is it possible to share the crashing scene with us ?
The crash might be caused by something else.
Also we want to fix these crashes and we need more scenes to test with.
Greetings,
Vladimir Nedev