CZSK verze 2.0

[Alois Nebel]

@Icik , tak som skúsil už tú optimalizovanú verziu, moja PC zostava je slušne povedané už trocha obstarožná, vo veľkých staniciach už 30FPS neudrží, občas ide aj na 25. Teraz v Nových Zámkoch miesto 27 mám 21 FPS. Skúšal som to v dennej dobe.

Taky si nemyslím, že je optimalizace hotová. Testoval jsem současnou verzi i pomocí diagnostického logu v mém Omezovači FPS, kde si během jízdy zaznamenávám vytížení GPU, spotřebu, teplotu, takt, vytížení CPU a zároveň FPS.

A právě tam je podle mě ještě prostor k optimalizaci. OR si v mém testu držel RTX 3050 kolem 1740 MHz a GPU bralo přibližně 30–32 W, přestože vytížení grafiky bylo většinou jen kolem 45–50 %. Zkusil jsem proto grafiku testovacím způsobem omezit na 1500 MHz. Výsledek byl zajímavý – FPS zůstalo prakticky stejné, ale spotřeba GPU klesla přibližně na 24–25 W a notebook byl znatelně tišší.

Takže hra evidentně dokáže stejný výsledek podat i s nižším výkonem GPU. To podle mě ukazuje, že hospodaření s výkonem ještě není optimální. A u slabších sestav se podobné rezervy nebo úzká hrdla mohou projevit mnohem výrazněji, například právě propady FPS ve velkých stanicích.

Takže pokud „optimalizace“ znamená jen to, že se na některých sestavách podařilo stabilizovat FPS, tak ano, zlepšení tam být může. Za hotovou optimalizaci bych to ale určitě nepovažoval. Optimalizace podle mě není jen o výsledném čísle FPS, ale také o tom, kolik výkonu CPU/GPU je potřeba k jeho dosažení.

 

[RicarCZ]

Ono je hlavně rozdíl jestli se výkon opírá o GPU nebo CPU, velké stanice a aktivity jsou spíše více náročné na CPU.
Nicméně v mém případě jsem po té optimalizaci nezaznamenal žádné rozdíly výkonu oproti předcházejícím verzím ORCZ/SK, testoval jsem to na mnoha místech ve své trati a u obou verzí je využití i spotřeba GPU identická. je to obrovský rozdíl oproti té prvotní testovací verzi.

 

[Alois Nebel]

Ono je hlavně rozdíl jestli se výkon opírá o GPU nebo CPU, velké stanice a aktivity jsou spíše více náročné na CPU.
Nicméně v mém případě jsem po té optimalizaci nezaznamenal žádné rozdíly výkonu oproti předcházejícím verzím ORCZ/SK, testoval jsem to na mnoha místech ve své trati a u obou verzí je využití i spotřeba GPU identická. je to obrovský rozdíl oproti té prvotní testovací verzi.

Nikomu jeho názor neberu. Jen by Icik možná neměl chtít po enginu víc, než je pak sám schopný ukočírovat.

 

[RicarCZ]

Nikomu jeho názor neberu. Jen by Icik možná neměl chtít po enginu víc, než je pak sám schopný ukočírovat.

Tak zrovna dynamické světlo od více než 1 vlaku by snad zvládnout měl bez fatálního dopadu na výkon.

 

[Alois Nebel]

Tak zrovna dynamické světlo od více než 1 vlaku by snad zvládnout měl bez fatálního dopadu na výkon.

Určitě. Jenže jeho odpověď „a dál nevím“ podle mě mluví za vše. To, že má extrémně výkonný počítač a případné nedostatky dokáže potlačit hrubým výkonem procesoru a grafiky, ještě neznamená, že se OR bude stejně chovat i na běžných sestavách.

Pokud se má mluvit o optimalizaci, měla by se podle mě testovat minimálně na slabší, střední i výkonné sestavě. Na high-end PC se totiž spousta problémů vůbec nemusí projevit.

A přístup „u mě se nic takového neděje, takže není co opravovat“ už jsme bohužel slyšeli několikrát. Právě proto jsem si začal výkon OR měřit a logovat, místo abych posuzoval optimalizaci jen podle toho, jestli mi zrovna drží FPS.

 

[Icik]

"A dál nevím" znamená, že momentálně nejsem schopen provést další optimalizaci. Ucpanou pipelinu v shaderu jsem opravil a snímky se vrátily na původní hodnoty u mě i RicaraCZ. To co vidíte, je nějaké úzké hrdlo CPU. A nepodsouvejte mi, že na to kašlu. Aspoň takový dojem z vašich reakcí nabývám.

 

[Alois Nebel]

A nepodsouvejte mi, že na to kašlu. Aspoň takový dojem z vašich reakcí nabývám.

Ano Ten dojem máte částečně správný, ale nechápejte to špatně v celkovém kontextu. Open Rails CZ/SK považuji za dobrý projekt. Problém podle mě není v tom, že byste na projektu nic nedělal – právě naopak. Problém vidím spíš ve způsobu vývoje, testování a vydávání aktualizací.

Podle mě by bylo vhodné důsledně oddělit vývojovou/testovací větev od stabilní uživatelské verze. Mezi uživatele by měla jít až verze, která prošla širším testováním. To, že dokážete na chybu rychle reagovat a vydat opravu, je samozřejmě dobře, ale není to náhrada za testování před vydáním. V praxi se pak může stát, že aktualizace opraví jednu věc, ale rozhodí něco, co předtím fungovalo, následuje další oprava a objeví se zase jiný problém. U projektu, který používá větší množství lidí na velmi rozdílném hardwaru, je to podle mě zbytečný problém.

Stejně tak bych optimalizaci nepovažoval za uzavřenou jen proto, že se výkon vrátil na původní hodnoty u vás a RicaraCZ. Máte velmi výkonnou sestavu a některé problémy se na takovém hardwaru jednoduše nemusí projevit tak výrazně jako na slabším nebo středně výkonném PC. Dva počítače jsou navíc pořád jen dva testovací stroje. Propady FPS přitom zmiňovali i další uživatelé. Jestli je nyní problém skutečně na straně CPU, jak píšete, je to naopak další důvod zjistit, co přesně CPU brzdí a za jakých podmínek.

Proto jsem vám také nabízel pomoc. Nemyslel jsem tím, že se vám budu hrabat v projektu a svévolně něco měnit – je to váš projekt a to respektuji. Myslel jsem tím projít zdrojový kód, podívat se na problematická místa a případně upozornit na věci, které by podle mě šly udělat lépe. Jestli některý můj návrh využijete, nebo ne, je samozřejmě čistě na vás.

Nevím, jestli se profesionálně živíte vývojem softwaru, a nemyslím to jako urážku. Jen si myslím, že po technické stránce má OR CZ/SK stále rezervy a byla by škoda je neřešit, protože jinak je to velmi dobrý projekt.

 

[Dan J.]

Podle tebe, ale velmi špatně. Právě u tvorby aktivit vychytáváš vzniklé chyby. Kdyby to bylo oddělené, jak píšeš, ani zdaleka by nebyl posun ve vychytávkách, tam kde je. Uživatel si může před aktualizací ORCZ zálohovat a pokud mu něco po aktualizaci nepojede, vrátit ORCZ ze zálohy. Tato cesta jaká je, je super.

 

[Alois Nebel]

Podle tebe, ale velmi špatně. Právě u tvorby aktivit vychytáváš vzniklé chyby. Kdyby to bylo oddělené, jak píšeš, ani zdaleka by nebyl posun ve vychytávkách, tam kde je. Uživatel si může před aktualizací ORCZ zálohovat a pokud mu něco po aktualizaci nepojede, vrátit ORCZ ze zálohy. Tato cesta jaká je, je super.

Prosím tě mlč! Vůbec nevíš o čem píšu, tak si nech tvoje moudra peo někoho jiného! Hadat se nechci, ale... nepovažuj se pořád za největší hlas tohoto fóra. Ne jen, že když tě někdo posadí na zadek, tak začneš hned otáčet a sypat si popel na hlavu! Ale mají z tebe srandu i jiní uživatelé s kterými jsem v kontaktu a věř, že Icik v tvorbě vážně nespolupracuje jen s tebou! Jak přijdu večer domů z práce, tak stáhnu icikuv kód a podívám se, jak je to domršené

 

[Dan J.]

Ale vím moc dobře. Programátor nejsem, ale o testingu vím víc než si myslíš. Já se s tebou hádat nemíním a jsi mi úplně jedno. Ale co nejsi? MODERÁTOR A ANI GURU ORCZ. Takže si nech ty kecy a neustálé poučování do svého vlákna programů.

 

[Alois Nebel]

@Icik Tak jsem si ze zvědavosti prošel zdrojáky Release-2.0, hlavně renderer, RenderFrame, Scenery, Lights, shadery a nastavení. Neříkám, že jsem během chvíle našel příčinu všech propadů FPS, ale pár věcí mě zaujalo a podle mě je tam ještě prostor pro optimalizaci.

MSAA: v UserSettings.cs nabízíte až 32× a v RenderProcess.cs se při volbě 32× skutečně nastaví:

case AntiAliasingMethod.MSAA32x:
pp.MultiSampleCount = 32;
break;

Jenže při měření skutečného D3D11 výstupu RunActivity.exe dostávám při nastavení 32× pouze 8 samples. Při nastavení 4× dostanu správně 4. V OR jsem přitom nenašel ověření skutečně podporovaného sample countu pro dané zařízení/formát. Tady by podle mě bylo lepší podporu zjistit podle GPU/rendereru a nenabízet uživateli hodnotu, která se nakonec reálně nepoužije.

Stíny: u Ultra máte 4 shadow mapy po 8192×8192 a při ShadowAllShapes se může do shadow pipeline dostat výrazně víc objektů. V RenderFrame.cs se navíc každý shadow caster testuje proti jednotlivým shadow mapám:

for (var shadowMapIndex = 0;
shadowMapIndex < RenderProcess.ShadowMapCount;
shadowMapIndex++)
Tady už nejde jen o výkon shaderu/GPU, ale také o CPU práci při sestavování snímku.

Dynamická světla: v Viewer.cs máte:

public const int MaxHeadlights = 16;
a SceneryShader.fx následně dělá:

for (int i = 0; i < ActiveHeadlightCount; i++)
Takže s počtem aktivních dynamických světel skutečně roste množství práce shaderu. Proto bych právě více vlaků se světly určitě testoval i na slabší/střední sestavě.

CPU bottleneck: s tím, že problém může být na CPU, souhlasím. Ale neznamená to podle mě, že už není co optimalizovat. Renderer má synchronizaci s updaterem:

Game.UpdaterProcess.WaitTillFinished();
a při přípravě snímku se dělá culling, sestavování render/shadow seznamů, třídění atd. Proto ani třeba 10–15% celkového využití CPU nevylučuje bottleneck jednoho důležitého vlákna. Při pohybu kamery se navíc mění viditelná scéna a právě tam bych hledal dál.

Takže zatím netvrdím „tady je jedna chyba, která způsobuje všechno“. Spíš říkám, že po pohledu do kódu bych optimalizaci určitě nepovažoval za uzavřenou jen proto, že se FPS vrátily na původní hodnoty na dvou výkonných PC. MSAA capability detection, shadow workload, dynamická světla a CPU část PrepareFrame/RenderFrame jsou podle mě konkrétní místa, která by šla ještě projít a udělat lépe.

 

[Alois Nebel]

@Icik Ještě jsem v tom zdrojáku pokračoval a zaměřil se víc na CPU část renderování, když jste zmiňoval, že současný problém vypadá na CPU bottleneck. A právě tady bych podle mě ještě optimalizaci nevzdával.

Zaujala mě například synchronizace rendereru s updaterem:

Game.UpdaterProcess.WaitTillFinished();

Tohle bych určitě profiloval jako jedno z prvních míst. Celkové využití CPU může být klidně jen 10–15 %, ale pokud render v určitém okamžiku čeká na dokončení jednoho důležitého vlákna, pořád může vzniknout CPU bottleneck a propad FPS. Proto bych nesledoval jen celkové CPU, ale hlavně čas jednotlivých částí Update/PrepareFrame/RenderFrame a dobu čekání na updater.

Další kandidát je sestavování renderovacích seznamů. V RenderFrame.cs se provádí například:

sequenceMaterial.Value.Sort(renderItemComparer);
Ve velké stanici a při pohybu kamery bych změřil, kolik položek se každý frame připravuje a třídí a kolik času tato část skutečně zabere. Právě pohyb kamery mění viditelnou scénu, takže případný problém se může projevit výrazněji právě tam.

Podobně bych se podíval na Lights.cs. Je tam culling přes Camera.CanSee(...), další průchody světly a LINQ nad LightPrimitives. Samostatně to samozřejmě nemusí znamenat velký problém, ale s větším počtem vlaků se tahle práce opakuje. Šlo by podle mě omezit počet průchodů a udělat culling světel jednou.

U samotných dynamických světel bych pak zvážil lepší prostorový výběr. V shaderu je nyní:

[loop]
for (int i = 0; i < ActiveHeadlightCount; i++)
tedy až 16 aktivních světlometů. Místo toho, aby každý relevantní pixel/objekt postupně řešil všechna aktivní světla, by podle mě stálo za pokus předem vybrat pouze světla, která mohou danou oblast skutečně ovlivnit. S rostoucím počtem AI vlaků by se tím workload nemusel zvyšovat tak výrazně.

A podobně stíny. Při Ultra se pracuje se čtyřmi shadow mapami 8192×8192 a jednotlivé shadow castery se testují proti jednotlivým mapám. ShadowAllShapes pak množství kandidátů ještě rozšiřuje. Tady bych určitě měřil zvlášť CPU čas přípravy shadow listů a GPU čas jejich vykreslení, protože jinak se snadno řekne „CPU bottleneck“, ale už nevíme, která konkrétní část ho vytváří.

Takže moje doporučení by teď nebylo naslepo něco přepisovat, ale přidat na pár míst jednoduché časování a jeden frame rozdělit například na:

Updater wait → PrepareFrame → scenery/culling → lights → shadows → sorting → Draw

a sledovat to hlavně ve chvíli, kdy FPS skutečně spadne. Pak bude během jednoho testu vidět, jestli těch několik milisekund mizí na čekání updateru, přípravě scény, světlech, stínech nebo někde úplně jinde.

Podle mě je to lepší cesta než optimalizaci uzavřít větou „nějaké úzké hrdlo CPU“. To úzké hrdlo tam klidně opravdu může být, ale zdroják zároveň dává několik konkrétních míst, kde se dá zjistit proč a případně s tím něco udělat.

 

[Zbyněk Šemora]

Podle mě by bylo vhodné důsledně oddělit vývojovou/testovací větev od stabilní uživatelské verze. Mezi uživatele by měla jít až verze, která prošla širším testováním.

Tohle jsem naznačoval hned v počátcích. Mě například odrazuje to, jak tady jsou denně diskuse, že se po nějaké aktualizaci rozhodilo něco jiného. Icik sice obratem opravuje, ale upřímně jej obdivuji, že má takovou výdrž. Já bych tohle na jeho místě nedal.
Ono je hezké mít stále nové vychytávky, ale opravdu je potřebujeme hned, ještě neotestované?
Ale já víc tvořím než jezdím, tedy možná kdokoli jiný to potřebuje hned. Jen názor.

 

[Dan J.]

Zbyňku, právě, že ty stavíš a nejezdíš, nemůžeš tak posoudit, přímý význam aktualizací a jejich prověřování v praxi, při tvorbě aktivit. Ano, když se něco rozhodí, ozvou se tvůrci a Icik to opraví, ale právě díky tomu má ORCZ oproti OR 1.51 takový náskok. Jinak ORMG od Italů fungoval (funguje, nevím nejezdím), úplně stejně. Buď aktualizuješ, nebo ne.

 

[Alois Nebel]

Buď aktualizuješ, nebo ne.

A ty vůbec víš, co aktualizuješ? Jak poznáš, jestli konkrétní aktualizace řeší problém, který máš, když u ní není changelog a informace o změnách se často neobjeví ani tady? I kdyby šlo jen o obyčejnou opravu null chyby, uživatel by podle mě měl vědět, co právě stahuje a co se v programu změnilo.

„Buď aktualizuješ, nebo ne“ podle mě není správný přístup k vývoji programu, který používá větší množství lidí. Právě proto se běžně odděluje vývojová/testovací a stabilní větev a k vydáním existuje changelog. Uživatel pak ví, jestli dostává opravu pádu, změnu rendereru, nové osvětlení AI vlaků nebo zásah do shaderů.

Ostatně tady se pak zpětně objevují otázky typu „všimli jste si, co je v poslední aktualizaci nového?“. To je sice zábavné jako hádanka, ale z hlediska distribuce softwaru by uživatel neměl novinky v aktualizaci objevovat náhodou.

A k výkonu – právě proto jsem si stáhl aktuální zdrojový kód a podíval se do něj. Icik může mít naprostou pravdu, že současný problém je CPU bottleneck. Jenže tím analýza podle mě nekončí. V kódu je například synchronizace:

Game.UpdaterProcess.WaitTillFinished();

dále se při přípravě snímku sestavují a třídí renderovací seznamy:

sequenceMaterial.Value.Sort(renderItemComparer);
a dynamická světla shader zpracovává podle počtu aktivních světlometů:

for (int i = 0; i < ActiveHeadlightCount; i++)
To neznamená, že tyto tři řádky jsou automaticky „chyba“. Znamená to ale, že existují konkrétní místa, která má smysl profilovat, když se hledá CPU/GPU bottleneck.

A právě na velmi výkonném PC se některé neefektivity projevit nemusí, protože je zakryje výkonová rezerva hardwaru. Na slabší nebo střední sestavě už se stejný problém může projevit propadem FPS nebo výrazně vyšší zátěží.

OR CZ/SK vůbec nekritizuji proto, že bych chtěl jeho vývoj shazovat. Naopak – kdyby mě projekt nezajímal, nebudu si stahovat zdrojáky a několik hodin v nich hledat, co by šlo udělat lépe. Jen nesouhlasím s přístupem „funguje to na našich počítačích, takže je hotovo“ nebo „buď aktualizuj, nebo ne“. U takového projektu podle mě mají smysl testovací/stabilní vydání, changelog a testování na různě výkonném hardwaru.

 

[Tom Kanka]

A perioda se nám opět blíží k vrcholu!

 

[Alois Nebel]

Nezkoušejte mě vůbec poučovat, jak má co vypadat. Nemáte na to právo. Nepřeju si vaše rozbory jak a co.

Právě že na to právo mám! Jebete do toho, a přitom ani vy sám pořádně nevíte, co vlastně děláte.

To, že tam přidáte plno nových funkcí a novinek, je sice pěkné, ale že vám samotný engine nestíhá, je vám očividně úplně jedno.

Nevadí! Vaši verzi mám a teď si s ní budu chvíli hrát já. Uvidíme, kdo bude rychlejší.

Popravdě? Tímhle děláte ostudu lidem, kteří tomu opravdu rozumějí. Vy jste spíš takový IT amatér, který si myslí, že dobývá svět.

A teď můžete vyšilovat! Nebo zase psát, že jsem „jak neřízený granát“, jak jste mě jednou nazval v SZ. Jsem, no a co?

Já se programováním živím a vím přesně, kam sáhnout a co upravit. Vy zjevně ani nevíte, jak samotné OR funguje.

 

[Alois Nebel]

A když už máte potřebu tvrdit, že verze, které se běžně stahují, jsou vlastně testovací, bylo by záhodno udělat nějaké přihlášení do beta programu a tyto verze nabízet pouze lidem, kteří je skutečně chtějí testovat.

Ne aby člověk, který chce používat stabilní OR, musel padesátkrát za den klikat na tlačítko Ne, protože je mu neustále nabízena další testovací verze. Vaše argumenty jsou v tomto ohledu opravdu k smíchu.

Původně jste na mě působil dojmem, že kódu opravdu rozumíte. Sám ostatně píšete, že jste se učením dostal k obrovským znalostem C#. Podle toho, co ale vidím, si to nemyslím a za tímto názorem si budu stát.

 

[RicarCZ]

Ne aby člověk, který chce používat stabilní OR, musel padesátkrát za den klikat na tlačítko Ne, protože je mu neustále nabízena další testovací verze.

Klidně můžeš používat jednu stabilní verzi a aktualizovat jen když budeš chtít vyzkoušet nějaké nové funkce, já také neaktualizuji pořád. Aby jsi nemusel pokaždé odmítat aktualizaci stačí ve složce s OR vytvořit soubor "SkipAuto.ini" a aktualizace se nabízet nebude.

 

[Venny]

A perioda se nám opět blíží k vrcholu!

A já si říkal, že už byl nějak dlouho v klidu...