X-Plane 12 Performance Issues

[bogdansrb 230]

Since this has been discusses in various topics here, I thought I'd make one dedicated for it. Myself and many others have been reporting poor performance with XP12. So I thought I'd investigate this issue.

I installed a vanilla copy of XP12 and loaded up the default 737 at LOWI. Graphics settings and FPS figures are as follows:

- texture quality and SSAO to max

- FSR off

- AA to FXAA

- Anisotropic filtering to 4x

- cloud quality to medium

- shadow quality to medium

- rendering distance and w.o and vegetation density to high

- 3D vegetation enabled, parked aircraft disabled

FPS was around 40. CPU time was ~0.2 and GPU time 0.1

I started increasing these further to see what impacts what:

- AA to 4xMSAA: no impact on FPS (2xMSAA brings horizontal stripes to the screen, so I omitted that)

- cloud quality to maximum: no impact (weather was set to VFR scattered)

- shadow quality to maximum: no impact

- w.o. density to max: no impact

 I then installed some 3rd party aircraft to see how those impact the FPS:

- zibo 737: 20-25FPS and CPU time increased to 0.5, GPU time 0.03. With no trees and scenery it goes up to 30-35FPS

- phenom 300: same

- q4xp: even worse, 15-20 FPS

- toliss a319: 20-24 FPS

Playing around with the settings again made no visible impact.

So something that these 3rd party aircraft use is causing very high CPU time and FPS loss. In the plugin admin nothing reports as "costing" FPS, but for example disabling some of the aircraft specific plugins bring the FPS back up:

- for the toliss I disabled all plugins at once (disabling them independently does nothing)

- zibomod plugin brings back almost all of the FPS

- disabling SASL in q4xp crashes the sim, so I can't test

As far as I've read, the culprit is an openGL-vulkan bridge. Almost all 3rd party aircraft draw their 2d panels using openGL (still), and that has to be converted to vulkan. It seems to be mostly an AMD issue.

Needless to say, on the same machine, with the same aircraft and even more stuff added to the sim (ortho, global forests, some plugins, hd mesh etc), this does not happen and the FPS is even higher. That excludes hardware not being capable enough.

Log: https://pastebin.com/9YtTxnwR

[peroni 541]

Have you tried 12.01r1 to see if you get any improvements? You could do this on the vanilla copy.
What screen resolution are you using?

[bogdansrb 230]

Just now, peroni said:

Have you tried 12.01r1 to see if you get any improvements? You could do this on the vanilla copy.
What screen resolution are you using?

No improvement. 

Resolution is 2560x1080.

[Mike_CFII_MEL 789]

Hi,

I've fooled around with Nvidia's control panel and have been very successful in getting smooth performance.

Nvidia Control Panel Settings, everything default except the following.

DSR - Factors: 1.78x DL;2.25x DL
DSR Smoothness: 33% (default)
Power Management Mode: Prefer Maximum Performance
Shader Cache Size: Unlimited
Texture Filtering - Quality: High Performance
Vertical sync: Adaptive (half refresh rate)

Resolution set @ 60Hz

 

[peroni 541]

8 minutes ago, Mike_CFII_MEL said:

I've fooled around with Nvidia's control panel and have been very successful in getting smooth performance.

But he has an AMD graphic card

[mSparks 2,086]

6 hours ago, bogdansrb said:

So something that these 3rd party aircraft use is causing very high CPU time and FPS loss.

Yes, try the Sparky744, I put a lot of effort into doing complex systems for VR fps.

https://github.com/mSparks43/747-400

Code -> download as zip for the latest, for windows you need to have installed basic multithreading and modern C++ support, installers for which are bundled with any of the releases, also check the FAQ in the readme for other important Q&As.

And see how it compares with

(reference photo)

Edited January 12, 2023 by mSparks

[GoranM 3,764]

7 hours ago, bogdansrb said:

texture quality and SSAO to max

Turn your SSAO down to minimum.  I went from between 90 and 100fps with it off, down to 50 with it turned up to max.

[fluffyflops 1,858]

same here patch has made no difference whatsoever at night. frames still tank.

 

Still an unfinished beta product not for general sale.  its a burger with out any lettuce or tomato, couple of pieces of bread and a manky patty. 

[bogdansrb 230]

Quote

Yes, try the Sparky744, I put a lot of effort into doing complex systems for VR fps.

I will. I see you're not using any SASL?

Quote

Turn your SSAO down to minimum.  I went from between 90 and 100fps with it off, down to 50 with it turned up to max.

I'll try this and report back.

[MrBitstFlyer 3,874]

5 hours ago, GoranM said:

Turn your SSAO down to minimum.  I went from between 90 and 100fps with it off, down to 50 with it turned up to max.

I used to find that during the beta, but turning it up now it doesn't have a negative effect on fps for me.

[GoranM 3,764]

9 minutes ago, MrBitstFlyer said:

I used to find that during the beta, but turning it up now it doesn't have a negative effect on fps for me.

It might depend on GPU or system.  I tried it on my Mac after I saw his post, and turning it up killed fps.  I was actually a bit surprised it hit it that hard.

[bogdansrb 230]

I found the references to the openGL-vulkan bridge that I mentioned:

https://www.supergoodcode.com/do-not/

Quote

 

X-Plane 11 has a VULKAN and an OPENGL implementation (somewhere internally when it comes to graphics).

Problems with flickering occur based on the fact that rendering using the VULKAN API is not synchronized with rendering using the OPENGL API in parallel.

That should be a task the graphic driver is responsible for.

AMD did not implement a solution at all - which produced extensive flickering. Sometimes. The scala for flickering here goes from 0 to 100% based on a huge amount of different factors.

NVIDIA implemented some dirty workarounds but so does not have the big flickering issues.

Switching back to OPENGL in X-Plane 11 "solves" the flickering problem because no synchronization is required.

X-Plane 12's internal implementation uses VULKAN only (clean approach) - so you cannot switch back to OPENGL.

The synchronization problem is still there and still the graphic driver is in charge for solving it.

ZINK now solves this problem by beeing an OPENGL implementation that does not do OPENGL stuff in the background but uses the VULKAN API in its implementation. This will omit the requirement of synchronization.

ZINK is also "driver independent" which removes the responsibility from the graphic driver crews (AMD, NVIDIA, INTEL,...) to a new group of people.

So if I currently run the open source AMD driver on my Fedora 36 (64BIT) OS, a newer version of this driver will NOT solve the problem. I have to wait for a layer in between the graphic driver and the application?

OR ZINK has to be used explicitly internally in the driver which then requires the driver crews to do this.

 

https://gitlab.freedesktop.org/mesa/mesa/-/issues/7405

[mSparks 2,086]

8 hours ago, bogdansrb said:

I found the references to the openGL-vulkan bridge that I mentioned:

https://www.supergoodcode.com/do-not/

Also generally important to the topic

https://www.trustedreviews.com/explainer/what-are-cuda-cores-4226433

https://en.wikipedia.org/wiki/OpenCL

https://www.khronos.org/spir/

8 hours ago, bogdansrb said:

So if I currently run the open source AMD driver on my Fedora 36 (64BIT) OS, a newer version of this driver will NOT solve the problem. I have to wait for a layer in between the graphic driver and the application?

OR ZINK has to be used explicitly internally in the driver which then requires the driver crews to do this.

I'll take on this here (it may also be answered somewhat at the OP https://gitlab.freedesktop.org/mesa/mesa/-/issues/7405)

The "opengl bridge" is a mechansim whereby plugin devs can do very very customised drawing in XP12, its a step up in complexity over using the planemaker 3D panel (which doesn't use it and is 100% vulkan)

The problem AMD users have is AMD drivers are a steaming pile of brown substance developers use to describe windows, and that very very customised drawing often explodes on AMD cards for no easy to fix reason.

Zink takes AMD opengl drivers completely out of the equation, plugin devs can do very very customised drawing in XP12 using exactly the same code they used before, but that drawing never actually goes anywhere near opengl, its all handled by X-Plane.

Right now LR have a zink build that:

1. "Works" in 2D and resolves the issues created by AMD and Microsofts' incompetence/malice.

2. Is in the hands of 3PDs doing very very customised drawing being tested

3. Doesn't work in VR yet.

 

[turbomax 3,285]

19 hours ago, Mike_CFII_MEL said:

Resolution set @ 60Hz

??

my resolution is @ 3.840 Hz. 😀

[bogdansrb 230]

3 hours ago, mSparks said:

Also generally important to the topic

https://www.trustedreviews.com/explainer/what-are-cuda-cores-4226433

https://en.wikipedia.org/wiki/OpenCL

https://www.khronos.org/spir/

I'll take on this here (it may also be answered somewhat at the OP https://gitlab.freedesktop.org/mesa/mesa/-/issues/7405)

The "opengl bridge" is a mechansim whereby plugin devs can do very very customised drawing in XP12, its a step up in complexity over using the planemaker 3D panel (which doesn't use it and is 100% vulkan)

The problem AMD users have is AMD drivers are a steaming pile of brown substance developers use to describe windows, and that very very customised drawing often explodes on AMD cards for no easy to fix reason.

Zink takes AMD opengl drivers completely out of the equation, plugin devs can do very very customised drawing in XP12 using exactly the same code they used before, but that drawing never actually goes anywhere near opengl, its all handled by X-Plane.

Right now LR have a zink build that:

1. "Works" in 2D and resolves the issues created by AMD and Microsofts' incompetence/malice.

2. Is in the hands of 3PDs doing very very customised drawing being tested

3. Doesn't work in VR yet.

 

True, but:

1. X-Plane is the only plane that has that many issues with AMD GPUs

2. There's also a problem on Linux (mesa) where all 2D panels are flickering, which is also what zink is supposed to fix