Hirdetés
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy S20 FE - tényleg nem lite
- Honor Magic V5 - méret a kamera mögött
- Xiaomi 15T Pro - a téma nincs lezárva
- Bemutatkozott a Poco X7 és X7 Pro
- Google Pixel topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Olyan lesz a Google Térkép, mint a segítőkész haver az anyósülésen
- Csőtörés lett a Red Magic 11 Pro gyötréstesztjéből
Új hozzászólás Aktív témák
-
-
#26
Abu85
HÁZIGAZDA
vérjancsika
#25
Abu85
HÁZIGAZDA
válasz
vérjancsika
#25
üzenetére
Mert a gyakorlatban nem működik jól. Nem csak kicsit lehet lassabb az optimalizálatlan kód a kezdetben, hanem sokkal is. Néha játszhatatlan szintre eshet a sebesség. Ez már eleve probléma, mert nehéz lenne megértetni a userekkel, hogy csak játssz a játékkal, és majd begyorsul idővel. Ez nem felhasználóbarát, mert csak szenvednének, és nem értenék, hogy miért kell ezt csinálniuk. És ott van az a gond, hogy a user nem tudja, hogy az optimalizált kód fut-e már, és ha mondjuk igen, és úgy van kis sebessége, akkor csak játszani fog akadozva, miközben nem tudja, hogy mikor jön a gyorsulás, nyilván sosem fog. Ezen túlmenően az efféle nem determinisztikus viselkedés nehezíti a tesztelést, tehát nem csak a usert szopatnák vele a fejlesztők, hanem saját magukat is.
Szóval ez a megoldás nem megoldás, nem véletlen, hogy senki sem erőlteti.
-
#25
vérjancsika
újonc
vérjancsika
újonc
Egyébként jut eszembe, a MS által is javasolt megoldás miért nem működik, vagy miért nincs használatban?
Annak az a lényege, hogy pipeline-kreáláskor a driver csak egy optimalizálatlan objektumot csinál, ahol a lényeg a gyártás sebességén van. Az LLVM-binárisból is lehet(ne) egy optimalizálatlan, sok regisztert felzabáló fordítást csinálni.Ezt azonnal lehet is használni rajzoláshoz, viszont közben a dx12 runtime egy háttérszálon beütemezi az optimalizált verzió legyártását. Amint elkészült, az optimalizálatlan xart kicseréli a háttérben, az alkalmazás tudta nélkül, tök transzparens módon. Ennek tiltására még valami flag is van, szóval elvileg üzemben kell lennie a dolognak a gyakorlatban is.
Ilyen módon az optimalizálatlan pipeline-okkal kisebb FPS-t kap az ember egy rövid időre, ami aztán fel is kúszik, cserébe nincs akadozás. -
#23
hapakj
őstag
pelgrim_v1
#20
hapakj
őstag
válasz
pelgrim_v1
#20
üzenetére
Kis cég? Semmiképpen
nagyonnagy? Rendelésre beépítik nekik
- hát nemtom. Mi is kis cég voltunk, mégis túrtuk az Unreal Engine-t. Vagy a NetherRealm sem egy nagy studió szerintem mégis sokat kihoztak az UE-ből. -
#22
hapakj
őstag
vérjancsika
#19
hapakj
őstag
válasz
vérjancsika
#19
üzenetére
A SPIR volt LLVM alapú, a SPIR-V már nem az.
am keverted az implicit és az explicit api-kat.
Szerintem alapvetően az a gond, hogy alapvetően több százezres pipelineszámokról beszélünk, amelyek tapasztalat, hogy a töredéke sincs használva. Innentől kezdve hogy ezek mégis előállítódnak az engine design probléma. Főleg mivel még az engine architektúrálisan DX9-11 érából származnak.
Szóval én inkább úgy látom az on demand pipeline létrehozással a probléma inkább el volt maszatolva / driverre tolva, mintsem megoldva. S valszeg a GPU-k fejlődésével egyre bonyolultabb is lett volna.
Amúgy nem tudom mennyire szignifikáns a probléma. Több játéknál nem is tapasztalom (valszeg a modern engine design miatt) néhánynál, meg driver updateknél pár perc fordítás. Igazából nem is látom, hogy akkora hatalmas probléma amire annyira megoldást kellett adni
-
#21
pelgrim_v1
tag
vérjancsika
#19
pelgrim_v1
tag
válasz
vérjancsika
#19
üzenetére
Te nem voltál lusta elmagyarázni mint én
-
#19
vérjancsika
újonc
vérjancsika
újonc
Hogyan jutottunk idáig? Egy kis technikai magyarázat:
Egy fordítási folyamat alapvetően 2 részből áll:forráskód -> köztes bináris reprezentáció (IL) -> tárgykód
Azaz, a compiler frontend felparsolja a forrást, átalakítja köztes reprezentációvá, ami aztán a backendnek, azaz a kódgenerátornak lesz a bemenete. Nos, egészen DX11-ig a tárgykód "DXBC" bináris volt. Ez egy IR típusú bináris reprezentáció, amely teljesen alacsony szintű, közvetlenül regiszterfogalmakkal és atomi utasításokkal dolgozik. Ezt a bájtkódot közvetlenül semmilyen GPU nem tudta értelmezni, de nyilván úgy alkották meg (kb. gombhoz a kabátot elv mentén), hogy az akkor GPU-k tulajdonságaihoz és képességeihez a legközelebbálljon. Ebből következően a drivernek a shadert viszonylag "egyszerű" volt kezelni, egy "kódtranszpájler" (kódátlapátoló) végigment rajta, és az absztrakt utasításokat átfordította az adott architektúra egy megfelelő utasításává. Pl. az "add r0, c2, v1" utasításhoz az architektúra összeadásnak megfelelő utasítását generálta, belekódolva a már a fordító által előre allokált regiszterek (temporális, constbuff, input) megfelelőit. Ezt gyorsan meg lehetettcsinálni, mert a fordító által generált kód már eleve optimalizált volt. Persze szükség szerint a driver végezhetett mégtovábbi kisebb optimalizációkat, de ez a lényegen nem változtat.
Aztán a GPU mint hardverarchitektúra továbbfejlődött, és olyan fogalmak/elemek jelentek meg benne, amelyeket a DXBC-sfogalmakkal már nem lehetett leírni (pl. a wave). A DXBC tehát elavult lett, és jött helyette egy másik leíró, a DXIL bináris. A Vulkan eleve a SPIR-V-vel jelent meg, de alapvetően mindkettő egy LLVM-származék. És itt kezdődnek a bajok. Ezek a reprezentációk gyakorlatilag nem tárgykódok, hanem köztes IL binárisok. Ezekben nincsenek előre allokált regiszterek pl.,csakis absztrakt változók. Azaz, a korábbi kódátlapátolás már nem működik, a drivernek egy compiler backendjét kell biztosítania ahhoz, hogy ebből architektúra-specifikus kódot fordítson. A kódgenerálás nem egy egyszerű művelet, főleg akkor, ha optimalizáltnak kell lennie a kimenetnek. Regiszterallokáció, függések kezelése, sorrendiség megváltoztatása, összevonások, stb., ez bizony időigényes. Oké, jönnek itt mindig az SSA-val (Single Static Assingment), ami az LLVM jellemzője, és hogy az könnyebbé teszi a kódgenerálást. Igen, valóban, de ettől még mindig q költséges marad. Mivel egy teljes, forrásból történő fordításnak a nagy részét (80+ %-át) a kódgenerálás viszi el, nem pedig a forrás felparsolása, kb. visszajutottunk oda, mint az OpenGL-es időkben, amikor a drivernek forráskódot kellett beadni, és ő azt lefordította magának, ahogy akarta. És ezt mindahányszor megcsinálta, ahányszor futtatta az ember a játékot, miközben az akkori DX-ekben csak az előre lefordított binárisok "kódlapátolása" ment on-demand, a Draw-hívásokban. Hála az LLVM-majmolásnak (ami rohadtul nem "realtime" rendszerekhez való lenne), visszább léptünk egy jó nagyot az OpenGL felé.
És ez még nem minden, a helyzeten az implicit API-k (DX12/Vulkan) jellege még tovább rontott. Egy GPU pipeline különböző shaderkódokbólés egyéb állapotokból áll. Explicit API-kban, DX11-ig ezeket külön lehetett állítgatni, és a driver feladata volt a Draw-hívásbanezeket "összekötögetni" (összelinkelni) egy konkrét pipeline-ná. Ennek nyilván van overhead-je CPU-n, és az eredmény sem feltétlenül lesz a lehető legoptimálisabb a GPU-n, mert nem történik mindent átfogó (whole program) optimizáció. Ezért aztán az implicit API-khozaz volt a nagy ötlet, hogy a legkisebb elemi rész, amit a driver kezelni tud a rajzoláshoz, maga a pipeline legyen. Azaz, majd az alkalmazás előre legyártja ezeket, és jujjdejó, mert egyrészt a lehető legoptimálisabbak lesznek, másrészt eltűnik a Draw-hívásokbóla CPU-overhead. Elsőre nem hangzik rosszul, de az a helyzet, hogy a pipeline-ok száma az azokat leíró állapotok számának a szorzata. Nem elég, hogy egy adott shaderből is lehetnek különböző variánsok (már önmagukban azok is közel exponenciálisan tudnak szaporodni), de ezek száma még a többiekével is szorzódik... Ha megvan minden pipeline objektumunk, akkor onnan kezdve örülünk, mert a Draw-hívások is olcsóak lesznek CPU-n, és az objektumok is a lehető legoptimálisabbak lesznek a GPU-hoz, tehát a rendering sebességet kimaxoltuk. Csak azt nem reklámozta senki, hogy mindehhez a végtelen számú objektum legyártása irtó lassú lesz, és menet közben sem igen lehet őket legyártani az LLVM-es köztes kódból történő lassú kódgenerálás miatt. Jut eszembe, ebben még az is benne van, hogy ha ugyanazt a shaderkódot (pl. egy pixel shadert) több pipeline-objektumban is felhasználunk (amelyek csak pl. egy alpha blendingben különböznek), a driver jó eséllyel akkor is újra és újra elvégzi a kódgenerálást, tehát még shader bájtkód szintjén sem biztos, hogy lehet cache-elni.
A GPU architektúrák igencsak sokat fejlődtek, cserébe szoftveres oldalról már csak elég undormány én hatékonytalan módon lehetőket kezelni. Elveszett a szépsége az egésznek. Röhejes, hogy játékok futtatásához gigás-terás GPU-binárisokat kell letölteni. Mintha a GPU nem is GPU lenne, hanem egy másik számítógép vagy virtuális gép, amit a CPU-ról vezérlünk.
Ha még mindig a Draw-hívásokban történő pipeline-linkelgetés menne úgy, hogy alacsonyszintű (IR) shaderbinárisokkal dolgoznánk, "kódlapátolással", akkor nem létezne ez az egész probléma.
-
#18
hapakj
őstag
pelgrim_v1
#17
hapakj
őstag
válasz
pelgrim_v1
#17
üzenetére
Az nem annyira értelemszerű, hogy game engine kódjába nem nyúlhatnak.
-
#17
pelgrim_v1
tag
csibe1
#4
pelgrim_v1
tag
Vannak gondok amiket látnak a fejlesztők, nagyon szívesen meg is csinálnának de nem tehetik mert directx vagy game engine probléma, aminek a kódjába értelemszerűen nem nyúlhatnak
ez is ilyen. Ment a devmagic, ne lásd, ne vedd észre, stb, de nem lehetett eltüntetni teljesen, ez konkrétan nem a devek hibája, régóta ülnek rajta, sokadrangú dolog volt
-
#16
Abu85
HÁZIGAZDA
Mooka-Miki
#6
Abu85
HÁZIGAZDA
válasz
Mooka-Miki
#6
üzenetére
A shader fordítás mindig része volt a rendszernek, és a valós idejű módszer mindig akadozásokat okozott. Az explicit API-k annyiban változtattak, hogy itt már elkerülhető az akadás, de előre cache-elni kell munkát, amit pár program már meg is csinál első indításkor, és ismétel akkor, amikor új drivert telepítesz.
Az Advanced Shader Delivery egy szofisztikáltabb megoldás erre, meg tudja akadályozni a valós idejű fordítást, illetve az első indításkorit vagy a driver frissítése utánit is.
#7 tlac : A letöltögetős megoldás az Advanced Shader Delivery. Amúgy olyan tényleg van ma, hogy driver telepítés után fordít egyet a játék, és kész, de ez sem tartják elég barátinak, mert percekbe kerül. Jobb, ha ez sincs. Konzolszerűbb az élmény.
#8 CPT.Pirk : Egyszerűen oldják meg a konzolok. A hardver megkapja magát bináris kódot, és azt futtatja. PC-n ez nyilván kizárt, mert a program csak a meghatározott GPU-kon futna, és ha jönne valami új generáció, akkor el sem indulna. Úgy kell megoldani ezt a gondot, hogy a következő generációs hardvereken is elinduljon a PC-s port.
#10 paprobert : Az elvét tekintve nem sokban, de amúgy annyiban más, hogy a Steam nem biztos, hogy le tudja tölteni minden hardvernek a megfelelő adatokat. Tehát ez inkább egy opcionális szolgáltatás, ami vagy működik, vagy akad a játék, és nem tudod előre, hogy mi vár rád. Az Advanced Shader Delivery viszont a támogatott hardvereken garantáltan működő funkció.
-
-
#13
hapakj
őstag
Mooka-Miki
#6
hapakj
őstag
válasz
Mooka-Miki
#6
üzenetére
Úgy hogy DX11 és előtte nem volt lehetőség elkerülni az akadásokat, de a driverek sok magicket csinálhattak a minimalizálásukra.
DX12 és Vulkan viszont lehetővé teszi az akadásoknak a felszámolását, de inkább az engine fejlesztőkre tolja a felelősséget (btw amúgy ezt ők kérték
). S hát az a baj az engine fejlesztők nem oldják meg jól. -
#11
Busterftw
nagyúr
Mooka-Miki
#6
Busterftw
nagyúr
válasz
Mooka-Miki
#6
üzenetére
En sem ertem, mert vannak jatekok ahol meg nincs stutter es akadozas, aztan ott is van shader forditas. Es ezek a jatekok aztan ugy kerulnek be a hirekbe, hogy koppra jol vannak megcsinlva es optimalizalva.
Szoval en is inkabb azt mondom, ne adjanak ki szart a kezuk kozul es akkor nem lesz stutter.A jatek elotti shader cache meg eddig nem volt tobb mint 10 sec.
-
-
#2
Plazmacucci
félisten
Egy jó kis gamepass áremelés?
Új hozzászólás Aktív témák
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Bestbuy játékok
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Autós topik
- Fujifilm X
- Szeged és környéke adok-veszek-beszélgetek
- Philips LCD és LED TV-k
- Elon Musk billiomos lesz, ha kitör a gépek forradalma
- Xiaomi 15 - kicsi telefon nagy energiával
- További aktív témák...
- Telenor 5G Indoor WiFi Router (FA7550) + töltő
- Telefon felvásárlás!! Xiaomi Redmi 9, Xiaomi Redmi 9AT, Xiaomi Redmi 10, Xiaomi Redmi 10 2022
- DELL Precision 5540 Workstation i7-9850H Nvidia Quadro T2000 32GB 512GB 15.6" 1év garancia
- GYÖNYÖRŰ iPhone 12 64GB Black-1 ÉV GARANCIA - Kártyafüggetlen, MS3653,100% Akkumulátor
- Okosóra felvásárlás!! Samsung Galaxy Watch 6, Samsung Galaxy Watch 7, Samsung Galaxy Watch Ultra
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest