While reading the article and the mentioned VRAM usage by other programs, I got the idea to activate the processor integrated one as well to make use of both,
the IGPU for everything except X-Plane on a smaller monitor and
my GTX1070 for X-Plane only in fullscreen.
That leads to a big problem. X-Plane obviously opens on the Windows main monitor first even if this is not shown and then moves to the preferenced one defined in the settings.
The problem here is, the IGPU of my I6700 is not capable of driving Vulkan but the attached monitor to it should be the main monitor to have several taskbar items (right) available while flying in full screen on the big monitor attached to the nvidia card.
This is set in X-Plane (settings and quit once) as well as the monitor settings in the application. Additionally it’s set in the windows ! settings to use the high end graphics card.
Starting with this Setup X-Plane immediately pops up an error on the main screen complaining about OpenGL-Bridge (log extract see below).

So Ok, then move over to big monitor as main screen. Setting this it works but leads to every window is at first now opening on this screen. But X-Plane is at fullscreen here and the other applications then eat the VRAM of this until you manually move then out of the way.

I haven’t found a trick to to make it work, but should we use workarounds anyhow to make an application work 😉
Hope you see the dilemma.

Last lines of the log after autoquit on wrong monitor:
0:00:00.000 E/SYS: MACIBM_alert: Failed to initialize OpenGL bridge
0:00:00.000 E/SYS: MACIBM_alert: X-Plane can’t run Vulkan or Metal without the OpenGL bridge and will fall back to OpenGL on next launch
0:00:00.000 E/SYS: MACIBM_alert:
0:00:00.000 E/SYS: MACIBM_alert: See the Log.txt file for detailed error information.
0:00:00.000 E/SYS: MACIBM_alert: C:/jenkins/design-triggered/source_code/app/X-Plane-f/../../core/gfx/gfx_glue.cpp:248

Good idea.

The following plugin may be of interest to you (I use it when I take longer breaks without shutting the simulation down).
https://forums.x-plane.org/index.php?/files/file/16764-freeze-x-plane-plugin/

1. While my in-flight experience with Vulkan is always stable (no crashes so far), I tend to freeze up often if I make changes in the flight config menu right after starting XP_Vulkan. Instead, if I immediately start a flight without making changes, I can always come back to the flight config menu to make whatever selections I wish, with no issues. And when it occurs, it is a nasty freezeout – I cannot even kill XP from Task manager (flags some permission violation), I have to forcefully power the PC down and restart. This happens with or without overclocking.

2. Under OGL, I always reached full resource utilization on a flight (one of my four CPU cores reaching 100% with the other three slightly lower, GPU and RAM at moderate utilization), provided I enabled “thread optimization” on the Nvidia control panel (and this gave the highest fps). Under Vulkan, I do get about 6 fps of boost compared to OGL, for most of the default aircraft (very small difference though with heavier duty aircraft such as ZIBO 737), and the flights are smooth as well without stutters. However, I no longer achieve CPU saturation, with or without “thread optimization” enabled; i.e., all of the four cores run around 80% utilization, with GPU and RAM being at moderate loading. I feel that I still have more unused juice left. Where is the bottleneck under Vulkan???

3. Under Vulkan, unless I select an infinite visible range in the flight config menu (I limit it to around 25 mi to get decent fps), I see spurious triangular shaped mountains in the distance, beyond the visible range selected.

If anybody has had similar experiences, or advice, I’ll appreciate if you could share.

Thank you.

I think I have filed a bug report on this several beta versions earlier.

I like to replay my approach and landing from the tower view. But as I zoom, in the aircraft is still shimmering like a chameleon on speed…

I agree. For example, if the user hasn’t made any input after pausing for one minute, the rendering pauses. As soon as the next input occurs, whether three seconds or three hours later, the rendering resumes.

I believe David is talking about anisotropic filtering here. An easy test to see whether “blurry textures” have always been there or are new with Vulkan or Metal, you can just switch to OpenGL. If the runways look the same as in Vulkan, it’s not blurry because of the pager but because of anisotropic filtering. Alternatively, the Pager Info tab of the Texture Browser can also be used to see if the sim is reducing textures in size. If the “Target scale” column is greater or equal to 1, then textures aren’t being paged down.

While I’ll mention, if you use a vram hungry plane (zibo for one , but alot of 3rd party planes can be as well) it can make a big difference vs stock planes. Also how resource intensive the scenary is (think JFK vs desert strip – even with default scenery ) But i’ll wager it is probably happening on some level to everyone. Whether they are noticing it or not. Ive watched 11.50 streams on 8gb cards that ‘looked’ perfect (from what i could see from the stream)

but anyways… they are not asking for the bug reports as proof that the blurring is happening, they need the bug reports because they contain the data to fix it.

(if i misunderstood your point, I apologize)

The problem is that paging textures around takes time. The whole point of moving high resolution textures out of VRAM is that they are far away from VRAM, so getting them back in there takes time. Even if they are already in system memory and not on disk, there is substantial latency involved with getting the texture back into VRAM ready for rendering. So any paging scheme that requires the ability to instantaneously switch out textures just doesn’t fly (and if it did, we’d not have any blurry texture issues to begin with because we could just switch out textures for free). This is why the camera is a bad anchor for paging decisions, it can move way too fast and jump between places. That’s also the reason why eye tracking doesn’t work, the eye can focus on the blurry section just so much faster than the paging system can shovel textures around.