UL Benchmarks päivitti 3DMark NVIDIA DLSS -ominaisuustestiä DLSS 4- ja Frame Generation tuella

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
22 865
1738293751995.jpeg


UL Benchmarks on ilmoittanut päivittäneensä 3DMark NVIDIA DLSS -ominaisuustestin DLSS 4- ja Frame Generation teknologioilla, eli nyt mukana on varmasti myös Multi Frame Generation -tuki. Tiedotteessa ei mainittu mahdollisesta uudempien mallien käyttöä skaalauksessa.

Lähde: Sähköposti
 
Minne unohtui mainospuheet kun dx12:sta kanssa piti tuoda lisätehoa jos laittoi kaksi eri näytönohjainta samaan kokoonpanoon
 
Minne unohtui mainospuheet kun dx12:sta kanssa piti tuoda lisätehoa jos laittoi kaksi eri näytönohjainta samaan kokoonpanoon

DX12 tukee sitä. Pelintekijät eivät vain käytä sitä. Ongelma on ns. muna-kana. Kukaan ei omista useampaa korttia koska mikään softa ei tue DX12 explicit multi-GPUta ja NVIDIA veti tuen ajurien hoitamalta versiolta pois. Ja kun kellään ei ole konetta jossa tästä on iloa, miksi käyttää potentiaalisesti kuukausia kovapalkkaisen devaajan aikaa toteutukseen jota kukaan ei käytä. Homma kun ei ole ihan yksinkertainen toteuttaa ja varsinkin jos halutaan tukea myös erilaisten korttien sekotusta (jota sitäkin DX12 tukee) pitäisi jotenkin ennustaa miten kumpikin kortti käyttäytyy jotta duunit voidaan jakaa tasaisesti. Kristallipallo-API uupuu vielä DirectXstä, joten...

Yksittäiset kortit ovat ns. Tarpeeksi Nopeita varsinkin ultra high endissä ja useamman kytkeminen koneeseen on jo fyysisesti hankalaa (ne ovat niin isoja) ja teoreettiset kokoonpanot niin kalliita ja vaatisivat niin järeitä virtalähteitä (2x RTX 5090 taitaa olla jenkkien sähköverkolle jo aika kova rasti kun 110V töpseliin tappivirtalähde taitaa olla 1600W) että maailma nyt vain ajoi tämän usemaman kortin käytön ohi ainakin pelikäytön osalta. Enkä näe että tilanne muuttuu ellei joku isotaskuinen firma lähde tätä ajamaan ja sponsoroimaan pelintekijöitä käyttämään tätä ominaisuutta, joka sitten toisi softaa minkä vuoksi hankkia useampi kortti, joka sitten taas ajaisi pelintekijöitä tukemaan.

Ja 3DMark haluaa yleisellä tasolla olla realistinen "näin pelit todennäköisesti pyörivät korteilla tulevaisuudessa"-mittari. Tällä hetkellä siinä tulevaisuudessa ei ole useamman kortin kokoonpanoja käytössä, joten niiden tukeminen antaisi väärän kuvan. Eikä UL Benchmarkskaan halua pistää merkittäviä resursseja ominaisuuten jonka käyttämiseen kellään ei ole rautaa ja joka monimutkaistaa asioita rendauskoodissa melkoisesti.
 
DX12 tukee sitä. Pelintekijät eivät vain käytä sitä.
Tämä on varmaan käsitelty moneen kertaan jo, mutta minkähän vuoksi pelin pitää erikseen tukea tuota? Eikö DX:n tarkoitus olisi nimenomaan olla rajapinta, joka häivyttää tämmöiset pelin kannalta tällaiset irrelevantit detailit, kuten montako gpu:ta koneessa sattuu olemaan. Kunhan niitä vähintään yksi on, ja hoitavat hommansa eli generoivat frameja pelin käytettäväksi. Ja jos oikein lennokkaaksi menisi, niin DX voisi tukea myös pilvestä saatavilla olevia gpu:ta. Tyypillisissä peleissä on varmaan aika vähän mahdollisuuksia semmoista järkevästi hyödyntää, mutta pointti onkin, että DX voisi silti mahdollistaa sellaisen.

Yksittäiset kortit ovat ns. Tarpeeksi Nopeita varsinkin ultra high endissä
Ne ultra high end -kortit maksaakin tänä päivänä 3000+ euroa, tuskin kovin moni niitä olisi pelikäyttöön useampaa koneeseensa laittamassa. Ideahan on, että halpoja kortteja yhdistämällä tehoa löytyisi enemmän (eihän se suoraan skaalaudu, mutta ei tarvitsekaan).
 
Ei halpojen korttien yhdistely kannata. Ei ole koskaan kannattanut. Multi-GPUsta on iloa vasta jos se yksi maailman paras kortti ei riitä ja tarvitaan lisää vääntöä. Se on aina ollut pienen pienen marginaaliporukan välineurheilua ja jotain kertoo se että NVIDIAkin heitti ns. hanskat tiskiin ja luovutti sen tukemisen.

Ja mitä tulee pilvijuttuihin... kerro sitten kun pilviGPU vastaa parin millisekunnin latenssilla. Ja siis tämän pitää sisältää se renderointiduuni, ei vain verkkoviive. Täysin haihattelua. Jo se että peli pyöritetään kokonaan sielä pilvessä ja vain streamataan lokaalivehkeelle on vain juuri ja juuri toimivaa (joidenkin mielestä edes ei ole) eikä siinä yritetä ympätä lokaalisti ajavaa pelilogiikkaa toimimaan etänä pyörivän GPUn kanssa, vaan ainoastaan lähetetään pelaajan inputteja ja otetaan vastaan valmiita frameja. Ja kun maailma on menossa kohti korkeamman virkistystaajuuden ruutuja - 240Hz on normisettiä jo, 480Hz/500Hz jo kurkistaa... kurkkaa paljonko on millisekunteina aikaa tehdä frame kun framerate on 500. Pilvestä voi ehkä streamata dataa (ks. MS Flight Simulator) ja pyörittää moninpelijuttuja, mutta muuten voi ihan suoraan unohtaa.

Multi-GPUn kohdalla jo se viive mitä on kahden GPUn välillä datansiirrossa (PCIE-väylä on hidas ja SLI-tyyliset väylät on haudattu) on iso ongelma ja se on kahden, sentin päässä toisistaan olevan GPUn välistä liikennettä. Katso paljonko NVIDIA polttaa rahaa datakeskuksissa "räkkikokoisen SLIn" datasiirtoon, ja siellä ongelma on pääasiassa kaista, ei latenssi. Pelikäytössä ongelma on kaista JA latenssi.

Ja edelleenkin, se että DX12 mahdollistaa jotain ei tarkoita että se on ilmaista ja helppoa. DX12 multi-GPUn suurin ongelma pelintekijöiden kannalta on miten jakaa duuni eri GPUiden kesken ja pitää huoli että lopputulos pysyy kasassa kun pitäisi se lopullinen frame pistää sinne ruudulle. Ja kun pelimoottorien rendausputket aina vain monimutkaistuvat, joka hemmetin rakoon pitäisi lisätä "mutta entäs jos näitä GPUIta on monta?" ja "entäs jos ne eivät ole saman tehoisia?" -kysymyksiin vastauksia. Tällä hetkellä ketään ei napostele lähteä tuota matopurkkia avaamaan, koska kellään ei ole rautaa millä moista koodia ikinä ajettaisiin. Muna-kana.

Näköpiirissä on että se seuraava askel on chipletit ja siinäkin - saman kortin sisällä useamman piipalan välillä - suurin ongelma on latenssi ja kaista kun mennään kahden piipalan väliseen liikenteeseen. Jos hommaa vaikeuttaa jo tämä kommunikointi, PCIE väylä on siihen verrattuna savumerkkejä.

Ehkä multiGPUsta tulee taas relevantti jos chiplettiratkaisuja kehitettäessä saadaan useamman GPU-chipletin kanssa leivottaessa abstraktoitua tämä ongelma piiloon pelinkehittäjiltä, mutta pelkään pahoin että eri korteilla olevien piirien välisen liikenteen pullonkaula sanoo "ei tule tapahtumaan".
 
Viimeksi muokattu:
Missasit pointin kokonaan. Muutaman SLI-kokoonpanon omistaneena tiedän kyllä sen ongelmat ja pilvipelaamistakin tuli joskus kokeiltua.

Mun edellisen viestin pointti oli, että miksi DX12 multi-GPU-tuki on toteutettu niin pölhösti, että pelintekijän pitäisi noita mainitsemiasi iffejä sinne sirotella. Juuri siksi nykytoteutus on niin hölmön kuuloinen, koska se johtaa tuohon mitä tuossa kirjoittelit, eikä kukaan täysjärkinen sellaista ala tekemään.

Haluan kuitenkin uskoa, että tuota asiaa on suunniteltu ja mietitty, niin siihen on varmaan jokin hyvä syy, miksi gpu:t eivät ole yhtenä poolina rajapinnan takana. Mutta mikä se hyvä syy on? Monimutkainen sisäinen toteutus, jolloin tehohäviöt syövät saavutetun voiton?
 
Missasit pointin kokonaan. Muutaman SLI-kokoonpanon omistaneena tiedän kyllä sen ongelmat ja pilvipelaamistakin tuli joskus kokeiltua.

Mun edellisen viestin pointti oli, että miksi DX12 multi-GPU-tuki on toteutettu niin pölhösti, että pelintekijän pitäisi noita mainitsemiasi iffejä sinne sirotella. Juuri siksi nykytoteutus on niin hölmön kuuloinen, koska se johtaa tuohon mitä tuossa kirjoittelit, eikä kukaan täysjärkinen sellaista ala tekemään.

Haluan kuitenkin uskoa, että tuota asiaa on suunniteltu ja mietitty, niin siihen on varmaan jokin hyvä syy, miksi gpu:t eivät ole yhtenä poolina rajapinnan takana. Mutta mikä se hyvä syy on? Monimutkainen sisäinen toteutus, jolloin tehohäviöt syövät saavutetun voiton?
Koska se on ainut tapa millä sen saisi järkevästi toimimaan nykypäivänä. Vanhanmallin CrossFiret ja SLI:t eivät toimisi järkevästi.
 
Koska se on ainut tapa millä sen saisi järkevästi toimimaan nykypäivänä. Vanhanmallin CrossFiret ja SLI:t eivät toimisi järkevästi.
No käännetään kysymys sitten näin päin, että mikä sitten on se lisäarvo, jonka tämä nyky-DX12 antaa siihen väliin multi-gpu-skenaarioissa? Jos koodi täytyy kuitenkin kirjoittaa sellaisella tavalla, ettei sitä kukaan ala ainakaan omalla rahalla rakentamaan.
 
Koodin tekemisessä oli jo aiemmin SLI/Crossfire -aikana oma säätönsä - tiedät kyllä lukemattomia pelejä jossa esim. varjot välkkyvät SLI/Crossfire -koneissa kun ei devaajaa kiinnostanut säätää. DX12 tarjosi lähinnä geneerisen tavan pistää duunia ihan niin monelle eri GPUlle eri malleja/valmistajia myöten mitä koneesta löytyy. Mutta tämä tehtiin todellakin geneerisesti. Tarkoittaa että pelintekijöiden hommaksi jää käskyttää jokaista GPUta tekemään jotain fiksua. Tämä on aika savotta tehdä edes yhdelle prosentille käyttäjistä, puhumattakaan että nykyään se prosentti taitaa olla prosentin murto-osa. NVIDIA jaksoi jonkin aikaa ajureilla toteuttaa DX12 "linked node" SLI-tukea joka vaati identtiset kortit (joka helpottaa elämää toteutuksessa) kun kerran oli siihen soppaan lähtenyt ja tällöin ajuri teki suurimman osan hommista ja loput kävi NVIDIAn insinöörit väsäämässä pelintekijöiden luona sponssina. Markkinointityötä SLIn myymiseksi.

Jossain kohtaa sitten todettiin että tuotto-hyötysuhde ei ole enää järkevä. Ja heti kun NVIDIA tämän luovutti, AMD ilo mielin säästi myös työtä tältä osin.

En jaksa edelleenkään uskoa että multi-GPU on todellisuutta enää tulevaisuudessa. Korttien nopeus ja muistikaista ovat kasvaneen niin järkyttävästi ja mitenkään järkevä high end toteutus vaatisi hirveästi vaivaa ihan rautatasolla. Katso paljonko 5090 muistikaistaa on. 1.792 TB/s. Paljonko on kaistaa kahden 5090n välillä PCIE 16x 5.0 väylän yli? Noin 60GB/s.

Pitäisi saada kaksi (tai useampi!) kortti leikkimään yhdessä ja synkkaamaan kaikki 60GB/s minigrip-pillin läpi samalla kun GPU itse mälvää muistiaan melkein 2 TERAA sekunnissa. Tai sitten rendata vuorotellen frameja ja taistella näiden synkkaamisen, mikrostutterin ja latenssilisän kanssa... Ei maksa vaivaa. Melkein voisi sanoa että hyvä että tämä unohdettiin. Paljon säästyy devaajien ja testaajien vaivaa pienen prosentin touhujen tukemiseksi. Pääsyy hankalaan toteutukseen on tässä datasiirron pullonkaulassa. Jos halutaan tehdä kaikilla GPUilla tehokkaasti duunia, niillä pitää olla kaikki data synkattuna muistissaan. Tätä ei vo toteuttaa "typerästi" koska kaista ei riitä. 32GB VRAM kopioiden PCIE-väylän yli joka framelle? Kun se kopiointi vie puoli sekuntia olettaen ettei väylällä ole mitään liikennettä. 2 fps SLI! Okei, ei kannata kopioida kaikkea, kopioidaan vaan se muuttunut data. Eli käytännössä päästään tekemään engineen hirveä määrä lisäkoodia jossa aina kun jotain tehdään, siitä pitää lähettää kopio naapurikorteille jottei kopsata mitään tyhmää. Puhumattakaan sitten jos pitäisi tukea kahta erilaista korttia jota DX12 teoriassa tukee. Päälle sitten se että modernien korttien kellot on "it depends". Eka kortti throttlaa, hidastaa, ei enää ole synkassa tokan kortin kanssa... no hei tehdään purkkaa joka hidastaa nopeampaa korttia ja yrittää pitää synkassa, joka sitten heittelehtii hieman framesta toiseen ja katso, taas saatiin yksi lähde stutterille.

Rendaus/laskentakäytössä monta GPUta toimii oikein hienosti, koska lopputulos ei ole mitenkään aikakriittinen. Heitetään joka GPUlle kopio datasetistä, pistetään jokainen laskemaan omaa osuuttaan siitä ja kerätään valmis data ulos kun ehditään ja yhdistellään vaikka ihan prossulla. Ei ole juuri kiirus jos Blender rendaa yhtä muuttumatonta framea minuutin. Ei toimi peligrafiikan rendaamiseen.
 
Viimeksi muokattu:
Kyllähän igputa voi myös käyttää ja se löytyy hyvin monelta.

iGPUn teho on niin kämäinen verrattuna edes keskitason dGPUhun että kahden GPUn overheadiin voi hukkua enemmän kuin mitä se iGPU jaksaa puskea. Lisäksi iGPU on yleensä VIELÄ kämäisemmän minigrip-pillin takana. Muistikaistaa nihkeästi (yay DDR5-6000) ja kaikki PCIE-kama on pakko kierrattää keskusmuistin kautta. Jos et tiedä niin läppäreissä oli jonkin aikaa ratkaisu jossa dGPUn rendaama kuva vedettiin sen keskusmuistin kautta iGPUlle ja siitä sitten näyttöön. Tästä oli pakko luopua peliläppäreissä ja laittaa hardware-mux (dGPU ja iGPU vaihtavat kuka antaa kuvaa näytölle) kun jo jossain 120-140fps nurkilla se siirtokaista oli liian hidas kopioimaan valmiita frameja näytölle. Huono myydä 240hz näytön läppäriä jos dGPU ei pysty kopioimaan 240 kuvaa sekunnissa iGPUlle.

Ja tämän kaistan läpi pitäisi sitten tehdä mGPUta? Uummmmm.... ei?
 
Toki 10v vanha juttu mistä tuo, mutta onhan igputkin siinä ajassa kehittyneet. Mutta kai siihen tosiaan hyvä syy on oltava ettei tuota käytetä. Liian työlästä etuun nähden jne.
 
Tuollaisilla framerateilla hommasta on vielä jotain iloa. Ongelma on että kun pitäisi pyöritellä vaikkapa 144fps+ niin se datasiirron pullonkaula tulee vastaan.

Jos koko maailma pelaisi 30fps niin uskoisin että nykyteknologialla iGPU+dGPU kombosta multiGPUna olisi ehkä jotain iloa, tosin silloinkin jos se olisi "jee FPS nousi 10%" niin onko se vaivan arvoista?
 
Pääsyy hankalaan toteutukseen on tässä datasiirron pullonkaulassa. Jos halutaan tehdä kaikilla GPUilla tehokkaasti duunia, niillä pitää olla kaikki data synkattuna muistissaan.
Ok, vähän hankala oli löytää villakoiran ydintä, mutta tämä kuulostaa sellaiselta hakemaltani tekniseltä syyltä, joka selittää miksi nykytoteutus on sellainen kuin on. Kiitos.
 

Statistiikka

Viestiketjuista
266 692
Viestejä
4 618 552
Jäsenet
75 896
Uusin jäsen
peterkallio

Hinta.fi

Back
Ylös Bottom