NVidia SLI Problem

I have two MSI GTX 660 Ti cards in SLI. I’m running vvvv 28.1, this is due to 30.2 having some weird issues with textures (not loading larger than 1024 in some cases). It seems that vvvv only uses single card, I’m not sure how this is possible. when I run occt and any other 3d app running directx both cards are under load. While running vvvv only one card is under load, this is kind of weird. I’m still at about 50-60 fps. but this is using only one layer. I have multiple scenes rendered with shadow mapping and multiple passes, then post effecting and layer mixing. So I need as much power as I could get. It seems that only first card is under load, I’m using GPU Meter windows gadget and MSI Afterburner to monitor the cards. Few months ago I have been using two cards in non SLI to run 7 displays and I didn’t have any problems, both cards under load, but this was to expect. Is there some solution to this, I have no idea…

first i’d be interested with the problems you mentioned with b30.2
please provide a demopatch that works in b28.1 but fails in b30.2 so we can have a look at that.

concerning SLI i cannot comment much. i am not aware how vvvv could opt out of using SLI if it is enabled. probably a driver setting per application?

This patch that I’m currently working on is based on 28.1, because I have lots of custom nodes I didn’t recompile everything after having problems with 30.2… I will address texture problems on different time. It might be problem with my video rendering nodes that are based on direct show, but uses system memory much like vlc, for use on multiple devices… Textures just does not load. Sometimes FileTexture loads 3 of 10 files, then I push reload and it loads some other few, really weird. Path that I used that had texture problems is huge and it uses much of my nodes for mesh editing and some other stuff. As I recall now I have switched to vlc and texture problem remained. I will cut down that patch and try to replicate the problem, when I finis with this. I will check driver settings, but I don’t think that I did special settings for vvvv. Another problem that i have is that backbuffer sometime fails when I load patch, then I set antialiasing to 1 and back to none on renderer and it resets device I guess and comes ok. This is not a big problem I do this when I see it after load, but… I had some problems with driver reseting, much like gpus are overheating, but this is not the case. Now I did set PhysX from auto to second graphics card and problem is no longer there, I tried switching back to auto, and vvvv continues to use single card. Thanks anyway, I will check driver settings and reply…

Some time have passed and I wanted to write some thoughts about these problems. I have been using this patch for three days for vj-ing (3d mapping) and I did have some problems but after watching Renderer TTY I did come to conclusion that vvvv is running out of ram (Usable ram anyways, 32bit). This seems to affect collada file loading and texture loading. Even if vvvv is below 1GB, this is what task manager says. Some threads here say that 2GB is the limit for vvvv, but I have different experience… I have removed texture preloader, because I did load lots of textures into memory to reduce patch replace/load time. This allowed me to load big collada files, keeping vvv under 800-900MB of ram usage seems to do the trick.

As for SLI I think that it is working, but vvvv is not utilizing rendering properly, because of its single threaded nature and value fetch system which is not fastest way to go around when using tons of nodes for simple arithmetic. vvvv is kind of made for automation, not for 3D rendering, it is not made like game engine… Best thing would be to rewrite core from scratch with parallelism in mind, and to avoid this evaluate system that is currently in use. 3D engines update all the values every frame (well most of it, there is no need to check if some node need some value, and go up the tree). Nodes could go to sleep mode and stop evaluating. Ambient occlusion can be used… if unified rendering engine is used… Another thing that could be done is to compile parts of patch with simple arithmetic thus accelerating these parts of code massively and utilize multiple threads in these parts (and others)… async execution where threads will wait for other threads that run within… All of this will make vvvv way much faster. I don’t know how to monitor memory access times to see just how much vvvv works around ram, but my cpu is not tasked, my gpu is not tasked, only thing that comes to mind is that vvvv is just not using ram efficiently and I believe this is due to pin value set get system.

This is all lots of talk and very little doing. I have a plan to use some of my existing code and a little bit of new one to write vvvv like system (with plugins and stuff) that could utilize parallel processing and all the goodies I have been talking about. With 3D rendering in mind, game engine like thinking… Some designer like vvvv, but more modern, all based in .NET 4 however this will probably wait for winter and will probably be only used by me, because vvvv has such large community, it is what makes it great.

bump here, i am thinking about getting Aorus X7 Pro with GTX970M-SLI, which is helll of a beast but all posts seems to suggest that VVVV is not very friendly with SLI, should i rather focus on getting most powerfull single GPU notebook?

I just want to know if there havent beeen any updates regarding this

yes, single GPU. SLI does not help vvvv very much.

I’m interested in SLI / CrossFireX
The technologies are somewhat brick-walls for small devs.
(that there aren’t clear API’s for these systems with documentation e.g. like CUDA on multiple Quadro’s) and you have to rely on ‘best practises’ and manufacturer automagic.

Generally games are written for a vast variety of systems, whilst most people here will have projects generally written with specific systems in mind, which means we can optimise for a known system configuration.

some notes:

Even if the options are relatively complex to implement, it would be great to have some SLI/CrossFire options within VVVV (esp DX11, hint hint :).

About SLI/Crossfire in DX11, I only heard some use case from users:

  • “Perfect SLI setup” : means each frame can be rendered independently (scene + post), split frame rendering give an effective near 2x gain.
  • Use results from previous frame (particle systems for example): Since now memory needs to be transferred across gpus, in general it’s a significant slowdown.

As a side note, I could not try/bench the results above, as I don’t have this setup at home (maybe i’ll do crossfire at some point since I tend to prefer AMD over NV nowadays, but that’s personal opinion).

If anyone (hint here too ;) , brings a SLI setup at Node, I’ll be very happy to profile and do tests :)

Ah great!

I thought there was still an issue with SLI not supporting windowed mode (since your fullscreen is kind of a windowed mode, or that has changed?), or is that windowed issue only with CrossFire?

How does it detect whether you are using data from a previous frame?
Is it based on whether you call ‘Clear’ on your Renderers?
If you had an interim buffer which didn’t change between frames, would you then just mark Renderer Enabled to 0? And then it wouldn’t be an issue? (rather than marking Clear to 0)

Happy to hear!

p.s. does this mean that SLI increases latency by 1 frame? (with AFR mode)

Fullscreen is still borderless window (as real fullscreen requires a top level control, and usercontrol in plugin is not).

There is a real window renderer in experimental nodes (in github), which allows real fullscreen. Please note you are not allowed more than one fullscreen window per device (only time it worked was on windows vista, at least this OS had something good :D

About how it does detect, since I don’t have a setup I can’t really easily make assumptions, so it’s pretty hard to know what’s done under the hood for now.

I’m also very interested in this topic. I hope after NODE15 there is some feeling of SLI being supported, at least in the future.