Aerosoft official retail partner for Microsoft Flight Simulator !! 
Click here for more information

Jump to content
Flightrookie

Es ist soweit, XP11.50b1 (BETA) ist da 😇😇

Recommended Posts

Hat eigentlich außerm mir noch jemand den Eindruck dass die Atmosphäre (bzw. der Nebel) in der 11.50 irgendwie besser aussieht? Ich habe den Eindruck, dass da alles irgendwie harmonischer nun wirkt, kann das aber nicht an etwas konkretem festmachen, ist nur so ein Eindruck, 11.50 fühlt sich visuell angenehmer an.

Share this post


Link to post
Share on other sites
vor 1 hour , FlyAgi sagte:

Hat eigentlich außerm mir noch jemand den Eindruck dass die Atmosphäre (bzw. der Nebel) in der 11.50 irgendwie besser aussieht? Ich habe den Eindruck, dass da alles irgendwie harmonischer nun wirkt, kann das aber nicht an etwas konkretem festmachen, ist nur so ein Eindruck, 11.50 fühlt sich visuell angenehmer an.

Dein Gefühl kann ich bestätigen und das Sonnenlicht blendet nicht mehr so.

Share this post


Link to post
Share on other sites

Danke... also wohl keine Einbildung meinerseits. 🙂

Share this post


Link to post
Share on other sites

Und das Wasser sieht auch viel schöner aus.

Und noch 'was komisches, bisher haben diverse Zeigerinstrmente der KingAir 350 nach einer Replay Sequenz einen Veitstanz aufgeführt, das ist ebenfalls nicht mehr der Fall.

Das kann aber eigentlich nicht sein?!?

Oder doch? Ich muss das gleich nochmals testen 🙂

 

 

EDIT: Eben nochmals üperprüft, es ist so, keine durchdrehenden Anzeigen mehr.

 

Share this post


Link to post
Share on other sites

Wasser sieht aber nur mit Reflexionen besser aus. Ohne sieht das aus als wäre das eine milchige Masse.

Share this post


Link to post
Share on other sites

Es sieht trotzdem deutlich besser aus, zumindest was die repitative Struktur anbelangt.

Das alte Muster war eher Leinengewebe als Wasser. 

 

Und ja, 2. Stufe Relexionen habe ich eingeschaltet (Regler um 1 nach rechts)

 

EDIT

Das hier meine ich

 

xxx.JPG.d694e229fd106072f3d139c82ed954e7.JPG

 

 

11.41

 

wa2.JPG.c0cba34981dd165c6723715e1165c28c.JPG

Share this post


Link to post
Share on other sites
On 4. April 2020 at 15:32, FlyAgi sagte:

Im allgemeinen gilt auch, dass die FPS nur dann deutlich steigen gegenüber der 11.40 wenn man nicht schon vorher durch die CPU limitiert war, Vulkan entlastet die GPU in erster Linie und Nutzer, die im GPU-Limit sind sehen deutliche Steigerungen, Nutzer die durch die CPU limitiert sind sehen hingegen meist gar keine besseren FPS.

 

https://forums.x-plane.org/index.php?/forums/topic/208639-fps-anomalies-with-vulkan/&do=findComment&comment=1888536

 

Tatsächlich wie ich meinte, genau das Gegenteil deiner Aussage!

Share this post


Link to post
Share on other sites

Das ergibt nur unter der Bedingung Sinn, dass die CPU nun weniger Verwaltungsaufwand für die GPU hat und dadurch die GPU nicht mehr durch die CPU limitiert wird, was effektiv auf eine Leistungssteigerung auf der GPU-Seite hinausläuft. Wie sonst sind da Leistungszuwächse auf GPU-Seite von 30-50% zu erklären?

 

 

Share this post


Link to post
Share on other sites

Vermutlich wirklich dadurch, dass jetzt die GPU teils nicht mehr so lang auf die CPU warten muss.

Share this post


Link to post
Share on other sites

Ja... das hatte auch im von dir verlinkten Thread jemand relativ detailiert erklärt:

 

https://forums.x-plane.org/index.php?/forums/topic/208639-fps-anomalies-with-vulkan/&do=findComment&comment=1889159

 

Effektiv ist im Endergebnis die GPU deutlich schneller unterwegs als vorher weil sie nicht mehr auf die Steuerung durch die CPU warten muss, wobei aber die CPU bei ihren sonstigen Aufgaben keinen Deut schneller geworden ist. Das Ergebnis ist dann, dass da wo die CPU vorher limitierte sie auch jetzt noch limitiert (Sonderfälle wie effizientere Reflektionen mal außen vor gelassen), ich habe zum Beispiel über New York City nicht einen Frame gewonnen und auch sonst nirgends, wo die CPU die Leistung begrenzt. Möglicherweise sieht das bei Nutzern mit weniger CPU-Kernen (ich habe 8C/16T) anders aus, da diese verwaltung nicht zwingend auf dem Main-Thread laufen muss - das würde dann die Unterschiedlichen Aussagen bezüglich der Steigerung der CPU-Leistung erklären - je mehr Kerne/Threads vorhanden sind desto weniger Vorteil bringt dann das Vulkan-Update auf CPU-Seite. Gleichzeitig schmilzt dann der Vorteil aktueller CPUs gegenüber älteren Intel-Cpus (i7 zweite bis siebte Generation) theoretisch deutlich zusammen.

 

 

 

Share this post


Link to post
Share on other sites

Kann gut sein. Ich habe ja mit meinem recht alten i7-6700k und einer GTX 1080 einen super Sprung bei der CPU Leistung.

Share this post


Link to post
Share on other sites

Ich habe da noch irgend etwas von Ben im "Ohr".

Mit OpenGL ist die Karte dann, wenn der VRAM nicht mehr reicht, permanent am Swappen (Aus- Einlagern von Daten).

Jetzt wird der CPU mehr Arbeit aufgebürdet, diese muss jetzt genau bestimmen, wann welche Daten im VRAM stehen sollen, das ist erst mal Mehrarbeit für die CPU, jedoch weniger Last für die GPU.

Wo die CPU das Mehr an Arbeit wieder gut macht, weiß ich nicht.

 

 

Nachtrag.

Meine Vermutung ist, vorher war der eine maßgebliche Core ausgelastet, jetzt, da wichtige Routinen auf andere Kerne verlagert wurden, ist der Grad der Parallelisierung höher, dadurch wird das Mehr an Arbeit trozdem in kürzerer Zeit geleistet, und für die FPS ist nur die Dauer und nicht der Arbeitsaufwand von Belang.

 

Zitat Ben:

We now have finished our third generation strategy: besides automatic texture res control based on VRAM pressure, we now set the relative resolution of non-orthophoto textures by distance to the aircraft. A background task on another core “crawls” the scenery near your aircraft and reevaluates the texture res of nearby scenery constantly, effectively transferring VRAM to where it is needed most. This process is completely transparent; authors do not need to modify scenery in any way for it to work, and since it runs on another core (as does the paging), it does not affect framerate.

 

 

Gruß

Günther

 

Share this post


Link to post
Share on other sites

Kann das Paging nicht auf einem eigenen Thread laufen? In diesem Fall sollte es keine effektive Zusatzlast erzeugen, da ja meist noch massig Threads mehr oder weniger unausgelastet sind, wenn es aber über den Main-Thread läuft dürften CPUs mit vielen Kernen/Threads unter Vulkan jetzt tatsächlich Leistung verlieren (wenn der Main-Thread das Limit darstellt, was bei mir normal gegeben ist).

Share this post


Link to post
Share on other sites

Oops, ich habe meine Nachricht nochmals aktualisiert, leider etwas zu spät.

 

Ich stelle je ebenfalls nur Vermutungen an. Eine Quelle meiner Überlegungen ist z.B. das Video von Austin in diesem Thread (4.April)

Share this post


Link to post
Share on other sites

Ja... aber so in etwa meinte ich das auch... das Paging sollte sich nicht negativ auf den Mainthread auswirken und daher sollte effektiv kein Leistungsverlust spürbar sein.

 

🙂

Share this post


Link to post
Share on other sites

Ja, jetzt mit Vulkan.

Die CPU entlastet die GPU, die Mehrarbeit ist multi-core, daher kann die CPU selbst schneller mit der angestiegenen Arbeitslast fertig werden--> beide sind schneller

 

Share this post


Link to post
Share on other sites

Na, da lag ich doch ziemlich daneben ...

Ich habe die nachstehende Antwort von Ben bzgl ein Anfrage erst jetzt entdeckt.

Allerdings glaube ich jetzt noch weniger zu verstehen als vorher, denn dass die GPU ebenfalls schneller geworden ist, kann man deutlich an der Zeit für einen Frame sehen.

Aber macht euch selbst ein Bild:

 

Zitat Ben Supnik

 

Wait, this is exactly backward. Vulkan brings optimizations almost entirely to the CPU, not the GPU.

The GPU’s performance is mostly limited by the shaders we write, the rendering passes we choose to render, how big the framebuffers we render to are,

and sometimes the blending options. This stuff has changed a little bit in Vulkan, but not much.

To the extent that it’s better, it’s only better because with much better tools, we can see what we’re doing more easily.

The CPU’s performance is where the win is – the CPU spends some time in X-plane code and some time in the Vulkan or OpenGL driver

building up instructions to send to the GPU to execute.

The cost of building up the instructions was really big in OpenGL – seeing this take 30,40,50% of a frame was not uncommon.

These costs are _much_ lower in Vulkan, allowing the CPU to render a frame in less time.

We have also fixed a number of CPU performance problems in our own code – once we got Vulkan running it became obvious where our

worst pain points were, so we fixed those too. The result is big improvements in CPU time.

The same is true for Metal as well – same dynamic – faster CPU frame time because less time

in the driver making command lists, no real change in GPU time.

So if your machine was CPU bound (and many users who have a nice graphics card are) Vulkan is a big win.

That’s why we see users with Vegas going “wow” – that GPU was bored waiting for CPU instructions via the slow AMD GL driver.

With Vulkan, the CPU can tell the GPU what to do fast.

I have seen some Mac users go “this isn’t faster at all” and this isn’t surprising.

Apple doesn’t ship a lot of GPU power relative to their display resolutions, so if you run X-Plane on a Mac at the MAX screen res,

odds are the GPU can’t keep up. E.g. my 5K iMac runs pretty well at, say, 1440p, but there’s no way this GPU can run at 5K with any kind of perf.

So my _suspicion_ is that these users are GPU compute power limited and that hasn’t gotten any better.

We’ll know more when we do more serious perf analysis of user machines.

There is still more we can do with the CPU in the future – there is more code that can be optimized, and now that we have a driver

that is more multi-thread friendly, we can start doing some of the build-the-frame work on multiple threads.

We are NOT doing this for 11.50 but we do have more room for improvement.

IF you aren’t seeing CPU time get better, that’s something we can profile later in the beta.

Share this post


Link to post
Share on other sites
vor 21 Stunden , FlyAgi sagte:

Effektiv ist im Endergebnis die GPU deutlich schneller unterwegs als vorher weil sie nicht mehr auf die Steuerung durch die CPU warten muss, wobei aber die CPU bei ihren sonstigen Aufgaben keinen Deut schneller geworden ist. Das Ergebnis ist dann, dass da wo die CPU vorher limitierte sie auch jetzt noch limitiert

 

Danke für die Aussage, denn ich verspüre unter 11.503 keine echte Leistungsverbesserung (FPS) bei meinen Vergleichsflügen (unter gleichen Bedingungen = Scenery, Wetter etc.), da die GPU (NV 1080 TI 11GB) der CPU (I7-7700K 4,4 Ghz) deutlich voraus war und ist.

Insoweit ist ggf. die Verbesserung im Detail vorhanden, aber der große Zugewinn bleibt für mich aus.

 

 

Share this post


Link to post
Share on other sites

Das beschreibt ja den Grund, warum die Low-Level-APIs primär entwickelt wurden, nämlich um die Abhängigkeit der GPU von der CPU-Steuerung zu minimieren. Technisch gesehen wird hier die CPU entlastet aber in der Anwendung scheint die GPU letztlich schneller zu sein weil sie eben nicht mehr durch die CPU begrenzt wird und effektiv ist am Ende mehr GPU-Leistung nutzbar. Wenn die GPU auf die CPU-Informationen wartet steigen ja deren Frametimes auch obwohl sie dabei nicht viel zu tun hat und das ist jetzt anders und darum ist die GPU effektiv schneller.

 

vor 1 hour , Othello sagte:

The cost of building up the instructions was really big in OpenGL – seeing this take 30,40,50% of a frame was not uncommon.

 

Diese Werte entsprechen etwa dem Zuwachs an GPU-Leistung bzw. der Reduktion der GPU-Zeit bei mir, das passt ganz gut.

 

Das problem ist bei der Diskussion hier nun, dass der Effekt 'GPU wartet auf CPU' nicht an den Frametimes abzulesen ist. GPU im Leerlauf aber wartend auf Instruktionen führt ja auch dazu, dass sie länger braucht um den Frame zu rendern und somit zu höheren Frametimes was wiederum dann so aussieht als würde die GPU limitieren wobei auf CPU-Seite die vielen Cores/Threads, die diese Verwaltung der GPU vornehmen können dazu führen, dass die Frametimes nun nicht viel anders aussehen als vorher da die CPU-Zeit in erster Linie vom Main-Thread begrenzt wird und sich dort nicht viel getan hat.

 

 

 

 

 

Share this post


Link to post
Share on other sites
vor 44 Minuten, Frank J. Herter sagte:

hast du den Untergang von Venedig schon beschleunigt?

Was genau meinst du da? 🤔 Venedig ist doch vorhanden

Share this post


Link to post
Share on other sites
vor 36 Minuten, PilotBalu sagte:

Was genau meinst du da? 🤔 Venedig ist doch vorhanden

Schau mal was da alles im Wasser steht. Ist das so gewollt?

 

Share this post


Link to post
Share on other sites

X-Europe wirkt sich absolut gar nicht auf das Mesh aus, das Zuviel an Wasser hat definitiv einen anderen Ursprung.

Share this post


Link to post
Share on other sites
vor 1 minute, FlyAgi sagte:

X-Europe wirkt sich absolut gar nicht auf das Mesh aus, das Zuviel an Wasser hat definitiv einen anderen Ursprung.

Was könnte das sein? 

Ich nutze die 11.50b3 nur XE4 ist da drauf sonst rein gar nix.

Nichtmal ein Addon Airport für Venedig. Nein auch keinerlei Mesh.

Share this post


Link to post
Share on other sites

Das muss schon irgendwie am Mesh liegen, XP-Wasser lässt sich anders nicht platzieren. Wenn wirklich kein weiteres Mesh installiert ist würde ich die XP-Standard-Szenerie mal mit dem Installer updaten oder löschen und neu herunterladen.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...