If a plugin induces the loading of an X-Plane art asset (OBJ, particles, etc.) VRAM is managed transparently for the plugin using the same mechanism as if the scenery were doing loads:

– Loading the new textures may increase VRAM pressure.
– We may page some stuff out to deal with it.
– If OTHER stuff pages out (e.g. you fly away from Las Vegas and we can page out all of Cristianos’ nice buildings 🙂 then if VRAM pressure releases enough, the plugin loaded art assets might INCREASE their res to use the free space, just like the rest of the scenery system.

If a plugin just uses VRAM directly (e.g. it calls glTexImage2D and allocates a giant 64 MB texture) then we notice VRAM pressure when the Vulkan driver tells us “hey there’s less VRAM now” (cuz the driver sees all) and we may page out some stuff.

I have a large 2Tb SSD that is dedicated only to X-Plane, and since my x-plane is currently 1.83Tb I have no space for two installs (a Beta and a non-Beta) 😀

I was about to post a very similar question regarding the VII. Is it just eliminating the risk of blurred textures?

9700K will run better +15% more FPS

What if on vram starved systems you did a conversion to 16 but textures (5, 6, & 5 bits per channel) at load?

Or would lack of alpha channel blow things up?

Okay thanks. So basically the higher core speed of a CPU with less threads will benefit more, thanks.

I’d be curious to see what the threaded XLua code looks like. A Lua VM is a good candidate to run in a thread in that it has total isolation from the sim _other_ than the holes you poke in it by function calls. So you can build a good sand-box by default.

Slow but steady. We’ve gotten great bug reports from third party devs on the private beta, but the blurry texture problem isn’t a one-day fix kind of thing.

just as a side note small side notification to this part:

->Similarly, plugin code is single core unless plugin authors make it multicore, which is a lot of work since the SDK doesn’t help.

Some work has already begun for the YA747 project to add multithreading to xlua scripts. No real time frame for when or even if this will be successful – a lot of work is putting it mildly. But if and when that makes even a first release this problem should be massively alleviated.