47 minutes ago, Matchstick said:

OK but that doesn't alter the fact that something other devs are doing avoids this problem.

These devs are, very likely, using customized generics.  (image based, as opposed to code based). Customized generics are not affected by the AMD bug.

Edited January 10, 20224 yr by GoranM

1 hour ago, rka said:

That's what the people that fixed the issue themselves say. Is there an AMD statement regarding the issue somewhere? 

It should be, when this is a real issue in the AMD driver, shouldn't it? And surely other software suffers from the issue too, not only XP?

Let's be clear here, what do *you* want? 

Are you actually planning to buy the plane and concerned? Or are you here just to "challenge" others on technical matters that you clearly have no knowledge about? If the latter, what's the interest? Are you here just to make conflicts? Just to add oil to the "fire"?

AMD has a bug in their driver, x-plane 12 has a work-around. As long as the work around is not shipped, developers that use code to draw in the 3d space might have a problem.

It's as simple as that to comprehend. If you don't belive, search the matter your self and stop thinking anyone will feed your knowledge or anyone owes you something, there is plenty on that with a simple google search, stop trying to waste others time.

Edited January 10, 20224 yr by mtaxp

42 minutes ago, rka said:

So you could have worked around it, thanks for the clarification.

Ok.  I'm going to try to explain it to you, since you either choose not to understand, or simply can't.  

Customized generics are used by people who can't, or won't draw in 3D space with code.  They use "generics" supplied by Laminar/Planemaker.  These graphics are made in Photoshop or Gimp.

This is not as an efficient or customizable method of drawing in 3D space and drawing glass displays as using OpenGL or Cairo (These are drawing languages).   Customized generics are used in all default X-Plane aircraft, and many freeware aircraft.  

Please tell me that you now understand, because I honestly have no idea how to simplify it any further for you.

 

Edited January 10, 20224 yr by GoranM

@rka, you were asked if you're going to buy the aircraft. You didn't answer the question. I suggest you make your intentions clear.

If you have no intention of buying it there's no need to enter the discussion.

There seems to be a huge confusion about what the "flickering displays" issue caused by, so as a developer whose add-on is plagued by this issue I wanted to provide some insight.

Firstly some clarification about what exactly generic and custom gauges mean - generic gauges are the default gauges provided by X-Plane, which can be somewhat customized by providing custom image files. On the other hand custom gauges are rendered (by using any kind of rendering method, including CPU-based rendering with libraries such as Cairo and GPU-based rendering with APIs like OpenGL and/or libraries like SDL) entirely from scratch without any help of generic gauges. Once rendered, they have to be composited into a designated panel texture in a drawing callback (xplm_Phase_Panel and xplm_Phase_Gauges) provided by X-Plane, so they can be visible on the cockpit.

This issue has started after X-Plane's transition to Vulkan - in order to not break backwards compatibility with add-ons, Laminar has decided to keep plugin rendering in OpenGL while moving X-Plane's its own rendering to Vulkan. In other words, even when X-Plane is running in Vulkan mode, custom add-on rendering is still done in OpenGL. How is this even done? In short, X-Plane creates a Vulkan context for itself and a separate OpenGL context for add-ons. Contexts are somewhat like applications that run on GPU. However this causes an issue, how is the rendering done in the OpenGL context for add-ons is synchronized with the Vulkan context for X-Plane itself in a frame-by-frame basis? Simple, the driver provides functions, or more precisely extensions for synchronization between the OpenGL and Vulkan contexts. With the help of these extensions, add-ons and X-Plane can render their stuff in an exact and predictable order.

These extensions are standardized and supported by all drivers, at least in theory. However in practice AMD's drivers do something wrong and the synchronization sometimes fails. When this occurs, the result is undefined behavior and random things are drawn on the panel, hence the flickering. Running in OpenGL mode instead of Vulkan mode should eliminate this issue as it eliminates the need for synchronization at first place.

 

Now given dynamics of the issue is clear, here is information specific to aircraft add-ons:

Generic gauges are not affected by this issue as they are rendered by X-Plane itself (in the Vulkan context) and therefore not subject to synchronization. However many add-ons do not / cannot use generic gauges, as they are really generic and sometimes simply not flexible enough for specific cases. They are used a lot in default aircraft and some payware, but it depends heavily on the type of avionics one wants to model.

Not all aircraft are affected equally - as this is a synchronization issue, the results are somewhat unpredictable and depends on many variables which are outside the control of add-on developers. Based on the tests I have done FlyJSim Q4XP, iniSimulations aircraft, TorqueSim aircraft, Hot Start TBM, Hot Start CL650, ToLiSS A340 and a few more aircraft are affected.

It is not possible to address this issue - someone mentioned the existence of a workaround, which is not true. There is simply no way to prevent this from occuring with custom gauges. As the issue is unpredictable and heavily depends on timing, it occurs more with some add-ons and less with others, but again this is outside the control of the developers and depends on many complex factors. Some add-ons can exhibit this issue more on specific hardware and even specific GPU & CPU loads. One cannot simply switch to generic gauges either, as they are really limiting or not suitable in some cases. Some avionics might be easy to develop using generic gauges, but other avionics might be plain impossible. It again heavily depends on the style ("UI") of the avionics and how they work internally.

Edited January 10, 20224 yr by BiologicalNanobot

1 hour ago, Ray Proudfoot said:

@rka, you were asked if you're going to buy the aircraft. You didn't answer the question. I suggest you make your intentions clear.

If you have no intention of buying it there's no need to enter the discussion.

Yes Sir, of course I will answer that question as you indicate that this is  relevant with regard to if I may comment here or not.

I am actually very interested in this product. I have not yet decided whether I will buy it or not.

Is that all?

30 minutes ago, rka said:

Yes Sir, of course I will answer that question as you indicate that this is  relevant with regard to if I may comment here or not.

I am actually very interested in this product. I have not yet decided whether I will buy it or not.

Is that all?

You will be aware some posts including yours have been hidden. Keep your comments civil please. Had you done that they wouldn't have been hidden.

14 hours ago, EvidencePlz said:

Did you try to load the saved "engine running" state from the Airframe Manager and calling up the program? I suggest you look into that again.

Hi EvidencePlz,

I got it working now. I reinstalled the program and it is accepting the saved states. It was a good idea to save the "apu running" state. I added a few more states leading up to take off.

Thanks for your assistance.

18 hours ago, BiologicalNanobot said:

It is not possible to address this issue - someone mentioned the existence of a workaround, which is not true. There is simply no way to prevent this from occuring with custom gauges.

If that is the case then we come back to the question of why it doesn't happen with other planes which appear to use use custom gauges,

Are they not using custom agues at all ? Is there something different in underlying framework or optimisations that means they don't use the API calls at fault ?

does this only happen on AMD GPUs?

which other planes are affected?

5 hours ago, Matchstick said:

If that is the case then we come back to the question of why it doesn't happen with other planes which appear to use use custom gauges,

Are they not using custom agues at all ? Is there something different in underlying framework or optimisations that means they don't use the API calls at fault ?

Got an example?

Define "custom gauges". A customized generic or an analogue gauge with a 3D needle will not cause any problems. A good indicator for potential rendering issues in Vulkan on AMD GPUs is using a custom plugin or SASL as these are the primary methods used for drawing custom PDFs, MFDs, etc. If an add-on aircraft only uses xlua as a plugin (which can not draw custom PFDs), it runs fine in Vulkan.

 

4 hours ago, turbomax said:

does this only happen on AMD GPUs?

Yes.

7 hours ago, Matchstick said:

If that is the case then we come back to the question of why it doesn't happen with other planes which appear to use use custom gauges,

Are they not using custom agues at all ? Is there something different in underlying framework or optimisations that means they don't use the API calls at fault ?

I had answered that question in my previous post too, it does happen with other planes. Again based on the tests I have done FlyJSim Q4XP, iniSimulations aircraft, TorqueSim aircraft, Hot Start TBM, Hot Start CL650, ToLiSS A340 and a few more aircraft are affected. You might be experiencing the issue in only Hot Start CL650 but others might be experiencing it in almost all aircraft - as said, this is because it depends heavily on your hardware and other factors, it is "undefined behavior" after all.

6 hours ago, turbomax said:

does this only happen on AMD GPUs?

which other planes are affected?

Yes, it only happens with AMD GPUs when using X-Plane in Vulkan mode.

Affected planes depend on your hardware, software, CPU loads, GPU loads and a ton of other conditions, but FlyJSim Q4XP, iniSimulations aircraft, TorqueSim aircraft, Hot Start TBM, Hot Start CL650, ToLiSS A340 and many more planes are all affected.

Edited January 11, 20224 yr by BiologicalNanobot

1 hour ago, BiologicalNanobot said:

Yes, it only happens with AMD GPUs when using X-Plane in Vulkan mode.

Affected planes depend on your hardware, software, CPU loads, GPU loads and a ton of other conditions, but FlyJSim Q4XP, iniSimulations aircraft, TorqueSim aircraft, Hot Start TBM, Hot Start CL650, ToLiSS A340 and many more planes are all affected.

The reason why when I made my new rig I chose a Ryzen 5 for CPU, but a good'old RTX for the graphics...

Every few times I went AMD for graphics since the early 90s of last century I regret...

Hello there,

From what I understand the aircraft is a "sim within a sim" and Xplane is "just" a container; does it means it could be port over to a different simulator than XPlane without too much hurdles ? If so is it something you are contemplating at some point ? (Yes I think of MSFS)

I had your TBM on Xplane 11 and like it very much and I must say this Challenger 650 is appealing.