Most of the time, Texture-Memory shouldn't be an issue, but it's good to keep in mind. I'm also not an expert, but in my experience it works like this:
- Most performance problems increase in a linear fashion (time needed for rendering slowly increases with the number triangles or Operator-Evaluation).
- But Video-Memory has two aspects: image-Buffer-Size and fill-rate.
- I think of the fill-rate as the number of pixel-shader-calls that are required to draw a single pixel on your screen. Reading and writing buffers already takes some time, but for really complex pixel-shaders this will take even longer. With a modern graphics card and a 1920x1080 resolution my gut-feeling is that a fillrate between 10 .. 50 is probably okay. (so 10 .. 50 buffers or texture-reads). The details are much more complex and involve the size of caches, read vs. write performance, overdraws from overlapping geometry, etc.
Image-buffer-size is a completely different beast. With 8bit a full HD-buffer is roughly 8MB in size 1920x1080x4 . Since the default rendering in tooll.io is now HDR everything is stored in 16bit (2 bytes). So its more like 16mb. Some render-buffers also store a 32bit z-buffer of the same dimension. So we're at 24mb. This doesn't seem much, but please consider, that every image-operator (the pink ones) holds it's own image-buffer, which gives us roughly 80 buffers on a 2gb graphics card. Since the graphics-cards needs a lot of memory for other things too and we ignored things like mipmaps, it's probably more like 40 buffers. Until we reach this number the performance impact is roughly linear -> more & larger buffers slowly turn down the performance. Bad things happen if you hit this memory limit, then Direct-x has to start swapping texture-buffers (freeing them on the graphics-card and re-uploading things from the main-memory). This can cause performance issues or even frame-drops, but things are probably still manageable. It get's much worse, if the driver doesn't manage to keep all data required for consecutive frames in GPU-memory. In this case, its required to do constant swapping between graphics-cards and main-memory. In this scenario, the framerate suddenly drops to a mere fraction (probably below 5 fps).
There are some performance-monitors like GPU-Z which can help you to monitor the use of video-memory.
If you notice that you're hitting the memory limit, here are some options:
- Add a [SetResolution]-Operator above parts of your graph.
- Use image-editing-software scale down images and textures to good compromise between resolution and required detail. In my experience, only some parts require a texture-resolution of 4k.
- The use of power-of-two dimension is overrated nowadays. The graphics cards can handle all resolutions just fine.
- Link up the graphics-quality-setting of the Player-Startup-Dialog. Frankly, this process is a little tedious, so I just ignored it for my last couple of demos.
I hope that helps. Please add a reply if you want me to clarify some details. I can then ask some people who actually know what they're talking about.