AMD:n RDNA 2 -arkkitehtuuri säteenseurantatuella jo ensi vuonna

[mäsä-79]

Huomaa että RDNA on paremmin peleihin suunnattu. On selvästi enemmän potentiaalia tulevaisuutta kohden, kun vertaa GCN. Noihin pilvihömpötyksiin en edelleenkään usko.

 

[Lepakomäyrä]

Pilvi hömpät on toistaiseksi liian tulevaisuuden tekniikaa ettei jaksa edes järkeillä vakavasti.
Kunnon rautaa ja tehoa että RT pyörii suoraan omasta koneesta.

Saas nähdä kuinka hyvin Cyberpunk 2077 sitten pyörii RDNA 2 korteilla ja tuleeko RT coreille käyttöä. Erityisen jännäksi käy tuleeko uuteen koneeseen sitten Ryzen 4000 ja RDNA2 teknologiat, vai julkaiseeko kilpailijat vielä jotain houkuttelevampaa.

Tiedä sitten miten toteutetaan kun yhteistyö kumppani on kuitenkin Nvidia.
"For Cyberpunk 2077, we’ve partnered with CD PROJEKT RED as an official technology partner to bring real-time ray tracing to the game."
Cyberpunk 2077: NVIDIA Partnership Brings Ray Tracing To Hugely-Anticipated Game

 

[AvatarX]

RDNA1 jäänee aika lyhytikäiseksi kun jo ensi vuonna joka paikassa on hardware raytracingiä, konsoleista lähtien. Luultavasti RT yleistyy silloin myös halvemmissa korteissa.

 

[mRkukov]

Eipä ole yhtä ainoaa lukua tehokkuudesta tai kuvausta algorimista tuolla.

Mutta siellä on juuri se mitä väitinkin, eli codec ei ole syypää viiveisiin.

Alkuperäinen väite kun kuului näin:

Se videokodekki nimenomaan helposti on se viiveen aiheuttaja

Kodekki on lähes 100% varmuudella h264/h265 ja todistin että h264 voidaan pakata raudalla alle 10ms viiveellä. H265 puolella löytyy yhtä lailla nopeita pakkauskeinoja.

Se että millaista kuvanlaatua tuolla ja 35Mbps saadaan, onkin toinen kysymys. Paljon huonompaa kuin 2-pass ajolla ja high preseteillä, mutta silti tuo voi olla riittävää monelle pelaajalle. Youtube 4k60 on monelle riittävä kuvanlaatu. Sitä ei tosin tuolla 35Mbps low-latencyllä tehdä, ellei siellä ole oikeasti jotain laadukasta encoderia väsätty. Siksi sanoin että eiköhän sieltä vielä tule 40-60Mbps vaihtoehdotkin tarjolle. Aivan turha silti maalailla 150ms viiveitä vain siksi että "ei videota voi pakata nopeammin".

 

[Zisu]

Yritin tuossa jo sanoa että tuo Mbps nopeus on vähän huono määre kun puhutaan reaaliaikaisuudesta. Tuo viimeinen s on sekunti, ja tuon sekunnin aikana voi lähettää vaikkapa sen 50Mbittiä. Jos 100ms aikana käytetään 25Mbit (varsinkin I frame saattaa olla todella suuri) niin se lähetys ei tapahdu 100ms aikana vaan tulee aikamoinen latenssi. (Huonossa tapauksessa vastaanottajan täytyy saada koko frame ennenkuin pystyy edes aloittamaan purkamista, riippuu toteutuksesta).

Lähetys käyttää aina UDP tai vastaavaa, jos uudelleenlähetystä halutaan niin sekin toteutetaan UDP päälle. Kuvaan tulee pieni jäätyminen ja pikakelaus.

Väitän että tällaisissa toteutuksissa on parin framen (forward) puskurointi puretulle datalle että pystyy välttämään viiveistä johtuvan jäätymisen ja vain hidastamaan videota. Toimii erinomaisesti esim videoneuvotteluissa.

Toki vaihtoehtona on myös aggressiivisesti rajoittaa jokaisen framen kokoa joka auttaa latenssiin, mutta tämä myös tekee Blur efektin hetkeksi.

 

[hkultala]

Mutta siellä on juuri se mitä väitinkin, eli codec ei ole syypää viiveisiin.

Alkuperäinen väite kun kuului näin:

Se videokodekki nimenomaan helposti on se viiveen aiheuttaja

Kodekki on lähes 100% varmuudella h264/h265 ja todistin että h264 voidaan pakata raudalla alle 10ms viiveellä. H265 puolella löytyy yhtä lailla nopeita pakkauskeinoja.

Halusit sitten alkaa venkoilemaan ja viilaamaan pilkkua termeistä, paitsi että pilkunviilaamisesi menee pieleen, olet itse pihalla termeistä.

h264 ja h265 ovat vain videonpakkausstandardeja jotka määrittelevät, miten jotain pakattua bitstreamia pitää tulkita että siitä saadaan kuva. Se sitoo sitä purkupäätä, sen pitää osata purkaa mikä tahansa standardinmukainen videosttream, mutta antaa edelleen hyvin vapaat kädet hyvin erilaisille enkoodereille, että mitä kaikkea se enkooderi tekee. Enkooderi voi aivan hyvin jättää suurimman osan standardin mahdollistamista ominaisuuksista käyttämättä.

Ne eivät ole videocodekkeja.

Codekki on sitten softa tai rauta, joka toteuttaa sen h264- tai h265-standardin.

Se, että codecci (koodinpätkä tai rauta) toteuttaa h264/h265-standardin ei takaa vielä yhtään mitään siitä kuvanlaadusta/pakkaussuhteesta.

Jos P- ja B-framet ovat standardissa optionaalisia(luulisin, että on, mutta en ole tästä 100% varma) , voidaan tehdä modernin h265-standardin mukaista bitstreamia pelkillä I-frameilla. Jolloin viive on melko pieni, mutta pakkaussuhde on samaa tasoa kuin jossain muinaisessa motion-JPEGissä, eli todella onneton.

Ottamalla käyttöön pari P-framea saadaa näiden P-framejen kaistantarvetta pudotettua selvästi, mutta sitten tulee muutama ongelma:

1)
Niiden I-framejen siirto ei nopeudu ei yhtään siitä, että P-frameja otetaan käyttöön. Jos P-framen siirto verkon yli vie 30 ms, ja meillä on kolme P-framea, joista jokaisen siirto vie 5ms, neljän framen data saadaan kyllä siirrettyä 45 ms:ssä (kun siihen aikaa kaistan puolesta olisi 66.66 ms) mutta se puskurointi sen I-framen siirtoa varten tarkoittaa kuitenkin vähintään 30ms viivettä. Eka frame saapuu kokonaisuudessaan perille vasta 30ms päästä siitä kun sen lähettäminen aloitettiin.

2) Ja heti kun kuvaan tulee yhtään isompia muutoksia, niiden P-framejen data alkaa eksyä liian kauas siitä, mikä sen ratan pitäisi olla, ja stten esim. tähtäys menee selvästi pieleen kunnes saadaan seuraava I-frame jossa taas siirtyy koko kuva.

3) B-frame ratkoisi tätä 2-ongelmaa mutta yksikin B-frame tekisi heti sen >33.3 ms viivettä. Kuten B-framet voidaan viivekriittisessä systeemissä unohtaa heti.


Käytännössä ainoa keino saada homma toimimaan todella pienellä viiveellä pienellä kaistantarpeella on käyttää pelkkiä I-frameja, ja pakata ne niin huonolla laadulla, että ne saadaan siirrettyä käytössä olevassa kaistassa. ja silloin se kuvanlaatu todellakin sukkaa pahasti.

Se että millaista kuvanlaatua tuolla ja 35Mbps saadaan, onkin toinen kysymys.

.. ja millaista viivettä. Olet nyt vetänyt kahdesta täysin eri lähteestä juttuja, toisesta kaistan tarpeita, toisesta jotain viivelukemia, ja kuvittelet että niissä olisi kyse samasta systeemistä.

Paljon huonompaa kuin 2-pass ajolla ja high preseteillä, mutta silti tuo voi olla riittävää monelle pelaajalle. Youtube 4k60 on monelle riittävä kuvanlaatu. Sitä ei tosin tuolla 35Mbps low-latencyllä tehdä, ellei siellä ole oikeasti jotain laadukasta encoderia väsätty. Siksi sanoin että eiköhän sieltä vielä tule 40-60Mbps vaihtoehdotkin tarjolle. Aivan turha silti maalailla 150ms viiveitä vain siksi että "ei videota voi pakata nopeammin".

Hienoa olkiukkoilua. Jo heti ekassa viestissäni otin esimerkiksi jpeg XSn nopeasta videopakkauksesta.


Meillä on kolmen asian tradeoff.

* matala viive
* matala kaistantarve
* kelvollinen kuvanlaatu

Näistä voidaan valita kaksi, ei kolmea.

 

[FireFly Renaissance]

Mutta siellä on juuri se mitä väitinkin, eli codec ei ole syypää viiveisiin.

Alkuperäinen väite kun kuului näin:


Kodekki on lähes 100% varmuudella h264/h265 ja todistin että h264 voidaan pakata raudalla alle 10ms viiveellä. H265 puolella löytyy yhtä lailla nopeita pakkauskeinoja.

Se että millaista kuvanlaatua tuolla ja 35Mbps saadaan, onkin toinen kysymys. Paljon huonompaa kuin 2-pass ajolla ja high preseteillä, mutta silti tuo voi olla riittävää monelle pelaajalle. Youtube 4k60 on monelle riittävä kuvanlaatu. Sitä ei tosin tuolla 35Mbps low-latencyllä tehdä, ellei siellä ole oikeasti jotain laadukasta encoderia väsätty. Siksi sanoin että eiköhän sieltä vielä tule 40-60Mbps vaihtoehdotkin tarjolle. Aivan turha silti maalailla 150ms viiveitä vain siksi että "ei videota voi pakata nopeammin".

h264 ja h265 tehokkuus tulee siitä, että niilä on dataa paljon ja pitkältä ajalta. Jos sitä ei ole, se on kyllä h.264 standardin muotoista, mutta ei tehokkaasti pakattua.

Se videokoodekki on syypää viiveisiin, silloin kun se data on saatava käyttökelpoiseen muotoon. Sellainen kodekki, jonka pakkaussuhde on susipaska, ei tuota dataa joka on millään tavalla käyttökelpoista. Se on siis keskustelun kannalta täysin irrelevanttia.

Tottakai se viive saadaan vaikka nollaksi kun työnnetään bittikarttaa raakana verkon yli vastaanottajalle. Mistä ihmeestä olet saanut päähäsi, että tämä olisi se ongelma. Ongelma on saada minkäänlainen tehokas (järkevä) pakkaus tehtyä ilman viivettä.

 

[mRkukov]

Meillä on kolmen asian tradeoff.

* matala viive
* matala kaistantarve
* kelvollinen kuvanlaatu

Näistä voidaan valita kaksi, ei kolmea.

Viiveestä ei voida liikaa karsia, koska peli ei olisi pelattava.
Kaistantarpeelle on rajat, niistä ei voi karsia.
Kelvollinen kuvanlaatu, subjektiivinen asia josta voidaan varsinkin alkuun joustaa.

Silloin kun spotify tuli markkinoille sen äänenlaatu oli täyttä kuraa. Ei ole enää.

Netflix/hbo tulo markkinoille asetti uusia vaateita nettiliityymille ja ihmisille halun maksaa paremmasta kaistasta. Kuvanlaatu ei ole hääppöistä varsinkaan hbo:lla. Ehkä se 5 vuoden päästä on kelvollisempaa.

Google Stadia... alkuun varmasti rajoitteita ja "ongelmia". 5-10 vuoden päästä se voi silti olla jo korvannut monet muut pelialustat.

 

[Griffin]

Viiveestä ei voida liikaa karsia, koska peli ei olisi pelattava.
Kaistantarpeelle on rajat, niistä ei voi karsia.
Kelvollinen kuvanlaatu, subjektiivinen asia josta voidaan varsinkin alkuun joustaa.

Silloin kun spotify tuli markkinoille sen äänenlaatu oli täyttä kuraa. Ei ole enää.

Netflix/hbo tulo markkinoille asetti uusia vaateita nettiliityymille ja ihmisille halun maksaa paremmasta kaistasta. Kuvanlaatu ei ole hääppöistä varsinkaan hbo:lla. Ehkä se 5 vuoden päästä on kelvollisempaa.

Google Stadia... alkuun varmasti rajoitteita ja "ongelmia". 5-10 vuoden päästä se voi silti olla jo korvannut monet muut pelialustat.

Jotain netflixiä ei todellakaan kannata verrata mihinkään pelaamiseen. Netflixissä viive saa olla vaikka 5000 millisekuntia ja se ei haittaa ketään. Ja jos silti ei saada, kuin paska kuvanlaatu, niin se kertoo ainoastaan sen, että reaaliaikaisen (FPS) pelaamisen kanssa ei todellakaan kannata vaivautua.

 

[FireFly Renaissance]

Viiveestä ei voida liikaa karsia, koska peli ei olisi pelattava.
Kaistantarpeelle on rajat, niistä ei voi karsia.
Kelvollinen kuvanlaatu, subjektiivinen asia josta voidaan varsinkin alkuun joustaa.

Silloin kun spotify tuli markkinoille sen äänenlaatu oli täyttä kuraa. Ei ole enää.

Netflix/hbo tulo markkinoille asetti uusia vaateita nettiliityymille ja ihmisille halun maksaa paremmasta kaistasta. Kuvanlaatu ei ole hääppöistä varsinkaan hbo:lla. Ehkä se 5 vuoden päästä on kelvollisempaa.

Google Stadia... alkuun varmasti rajoitteita ja "ongelmia". 5-10 vuoden päästä se voi silti olla jo korvannut monet muut pelialustat.

Näitä palveluita on ollut jo 10v ja yksikään ei ole menestynyt, koska subjektiivisesti kelvollinen ei ole riittänyt. Voi olla, että se muuttuu, mutta en pidättelisi hengitystä. Tätä on lupailtu jo vähintään se sama 10v korvaamaan pelikoneet "ihan kohta".

Ainakin ne serverit pitäisi saada hajautettua lähelle käyttäjiä, mutta se taas nostaa hintaa ja laskee käyttöastetta. Se, että Haminasta ajetaan kymmeniätuhansia 30 Mbps striimejä reaaliaikavaatimuksella ilman puskurointia koko Suomeen tai vielä Venäjälle ja Pohjoismaihin ei oikein kuulosta vahvalta idealta. 10 000 tuollaista striimiä on 300 Gbps 100 000 on 3 Tbps.

Marginaalituotteena jollekin voi aina olla hyvä palvelu. Sellainen palvelu ei vain usein ole taas liiketaloudellisesti kannattavaa tuottaa, varsinkin jos tarvitaan paljon infraa.

 

[mRkukov]

Näitä palveluita on ollut jo 10v

Ja ennen spotifytä/netflixiä oli vuosikaudet muita stream palveluita.

Voi olla, että se muuttuu, mutta en pidättelisi hengitystä.

Videonpakkaus 15 vuotta sitten oli DivX/Xvid pikselimössöä. Meinaatko oikeasti että h265 ei olisi suorastaan mullistus verrattuna vanhoihin.

Ainakin ne serverit pitäisi saada hajautettua lähelle käyttäjiä

Google on maailman yrityksistä juuri se jolla on tähän rahkeet. Edes microsoft, amazon tai yksikään muu firma ei pääse yhtä kattavaan datakeskusverkkoon. Jos Google failaa niin sitten voidaan katsoa 20 vuoden päästä uudelleen.

Se, että Haminasta ajetaan kymmeniätuhansia 30 Mbps striimejä reaaliaikavaatimuksella ilman puskurointia koko Suomeen tai vielä Venäjälle ja Pohjoismaihin ei oikein kuulosta vahvalta idealta. 10 000 tuollaista striimiä on 300 Gbps 100 000 on 3 Tbps.

Meinaat että kaikki pelaisi aina juuri samana päivänä ja samaan aikaan. Ne 3+ kertaa viikossa pelaavat on taas siinä alle 5% vähemmistössä, joille on edelleen ne 1000-2000€ pelitietokoneet.

 

[FireFly Renaissance]

Ja ennen spotifytä/netflixiä oli vuosikaudet muita stream palveluita.

Videonpakkaus 15 vuotta sitten oli DivX/Xvid pikselimössöä. Meinaatko oikeasti että h265 ei olisi suorastaan mullistus verrattuna vanhoihin.

Eikö se nyt ole jo selitetty, ettei näillä videopakkauksen kehityksillä ole tässä mitään merkitystä kun se kehitys perustuu asioille jotka ovat tämän ongelman ratkaisussa täysin irrelevantteja?

Google on maailman yrityksistä juuri se jolla on tähän rahkeet. Edes microsoft, amazon tai yksikään muu firma ei pääse yhtä kattavaan datakeskusverkkoon. Jos Google failaa niin sitten voidaan katsoa 20 vuoden päästä uudelleen.


Meinaat että kaikki pelaisi aina juuri samana päivänä ja samaan aikaan. Ne 3+ kertaa viikossa pelaavat on taas siinä alle 5% vähemmistössä, joille on edelleen ne 1000-2000€ pelitietokoneet.

Parhaat rahkeet olisivat teleoperaattoreilla, jotka voivat ajaa omiin kuituihinsa palvelua käyttäjien läheltä.

Noihin datamääriin pääsemiseksi kaikkien ei tarvi pelata samaan aikaan. Suurin osa pelaa kuitenkin samaan aikaan, siinä missä esimerkiksi saunookin. Aika harva saunoo maanantaina kello 12, mutta aika perkuleen moni saunoo perjantaina kello 20.00.

 

[Griffin]

Meinaat että kaikki pelaisi aina juuri samana päivänä ja samaan aikaan. Ne 3+ kertaa viikossa pelaavat on taas siinä alle 5% vähemmistössä, joille on edelleen ne 1000-2000€ pelitietokoneet.

Mobiilinetissä ilmiön huomaa selkeästi. Ihmiset ovat tiettyyn aikaan nukkumaassa -> Toimii hyvin.
Ihmiset ovat YLEENSÄ tiettyyn aikaan töissä, koulussa jne -> Toimi hyvin.

Ihmisillä on se tietty aika, joka on suurimmalla osalla ns vapaata, perus matalan bitraten videostriimi tökki.

Eli kyllä sitä kapasiteettiä joutuisi rakentamaan joko sen ruuhkahuipun mukaan, joka olisi kallista
TAI
Jonotussysteemi, joka ärsyttäisi käyttäjiä reippaasti.
TAI
Sallitaan lagaus, hidastelu ja / tai onneton kuvanlaatu, jolloin taas ärsytetään käyttäjiä..
-----------------
Nykytekniikan ja tarvittavan tekniikan välinen kuilu nyt vain on tälläkin hetkellä yksinkertaisesti valtava, jotta tuo toimisi riittävän hyvin.

Lisäksi vaatimustaso nousee kokoajan, kun reso ja FPS vaatimukset kasvavat.

Ainankin itse näen kirjoittelusta päätellen, että monet olisivat tyytyväisiä 4K120Hz yhdistelmään. JA esim MS mainitsee tuonkaltaisia (ei tule toteutumaan järkevästi) tulevan konsolinsa mainospuheissa..

 

[eternality]

Eivätkö pelit toisaalta ole myös helpompia pakata kuin videokuva koska codecin ei tarvitse tehdä mitään kömpelöä motion estimationia videokuvasta, vaan se saa suoraan peliltä vektorit miten mikäkin objekti ruudulla liikkuu? Tämän lisäksi koska peleissä on rajallinen määrä tekstuureja ja objekteja, tuossa voisi varmaan käyttää jotain AI:ta parantamaan kuvanlaatua kuten siinä nvidian antialiasoinnissa.

 

[SatanTwister]

Vähän on keskustelu sivuraiteilla mutta lisättäköön tuohon että noissa palveluissa ei ole ainoastaan ongelmana tekniset vaatimukset. Pelin tai elokuvan ostaminen jostain striimauspalvelusta on vaan ihan vitun typerää koska jos sinulla itsellä ei ole sitä dataa tallessa mikä tahansa ristiriita palveluntarjoajan ja tuotteen myyjän kesken poistaa tuotteen melko varmasti palvelusta.

Pelit eivät ole hyviä vuokrauksen kohteita käyttäjän kannalta koska niistä ei voi tietää kuinka kauan kenelläkin menee koska pelit eivät ole täysin lineaarinen media kuten esimerkiksi elokuvat.

 

[KVahlman]

Mistä johtuu, että Nvidia ja AMD näin yhtä aikaa panostavat säteenseurantaan? Onko tästä sovittu, vai onko syynä esim. se MS:n aloite että DirectX:ään tuli säteenseuranta?

Raudan suorituskyky ja algoritmikehitys on saavuttanut pisteen missä alkaa olla järkevää tuoda teknologiaa kuluttajatuotteisiin. NVIDIA tuotteisti ensimmäisenä mutta kyllä muutkin toimijat on varmasti olleet näissä puuhissa jo ennen RTX jytkyä.

Aika yksinkertaisesti on nyt kypsä, ei sen kummempaa. Näinhän se usein tahtoo mennä.

 

[KVahlman]

Tuo on mielestäni ihan hemmetin turha ominaisuus ja syö suorituskykyä ihan törkeästi saavutettuun hyötyyn verrattuna..

4K resoluutiosta voisin sanoa noin, oikein käytetystä säteenseurannasta en. Makuasioita, luonnollisesti.

 

[mRkukov]

Eivätkö pelit toisaalta ole myös helpompia pakata kuin videokuva koska codecin ei tarvitse tehdä mitään kömpelöä motion estimationia videokuvasta, vaan se saa suoraan peliltä vektorit miten mikäkin objekti ruudulla liikkuu? Tämän lisäksi koska peleissä on rajallinen määrä tekstuureja ja objekteja, tuossa voisi varmaan käyttää jotain AI:ta parantamaan kuvanlaatua kuten siinä nvidian antialiasoinnissa.

Periaatteessa kyllä ja mielenkiinnolla odotellaan että mitä sieltä tulee. Olisi aika kova veto jos osaisi vektorilta käyttää.

 

[Monologi]

Mikä ihmeen säteenseuranta?



Nähtävästi pelatessa ei niin merkityksellinen. Hyvä jos edes huomaa.

Riittää kun peli ei ala nykimään niin tälläiset ominaisuudet karsii vaan pois kuormittamasta.

 

[Sampsa]

Mikä ihmeen säteenseuranta?

Totuus on, että pelikehittäjät ovat vuosien varrella oppineet toteuttamaan valaistuksen varsin näyttävästi ns. keinotekoisesti vs reaaliaikainen säteenseuranta. Nämä ensimmäiset käytännön toteutukset eivät myöskään säteenseurantaa varsinaisesti mairittele, mutta eiköhän tässä lähivuosina tulla näkemään jotain ihan mielenkiintoisiakin toteutuksia.

 

[zepi]

Totuus on, että pelikehittäjät ovat vuosien varrella oppineet toteuttamaan valaistuksen varsin näyttävästi ns. keinotekoisesti vs reaaliaikainen säteenseuranta. Nämä ensimmäiset käytännön toteutukset eivät myöskään säteenseurantaa varsinaisesti mairittele, mutta eiköhän tässä lähivuosina tulla näkemään jotain ihan mielenkiintoisiakin toteutuksia.

Onhan metrossa nyt aika huimaavia parannuksia globaalin valaistuksen realistisuudessa.

 

[Griffin]

Säteenseurannasta kannattaa huomioida, että se on ollut iät ja ajat se tapa, jolla valaistus hoidetaan ammattimaisessa renderöinnissä. Nyt ollaan siten pikkuhiljaa siirtymässä peleissäkin siihen oikeaan tapaan hoitaa tuo asia.

Varsinkin JOS tuota rautaa tulee myös konsoleihin, niin kannattaa varautua siihen, että näyttikset ilman ko ominaisuutta alkavat mennä kohti kierrätyskeskuksia.

Kyseinen asia on ensimmäinen merkittävä kehitysasken näyttisten historiassa, pitkään aikaan. Vähän, niinkuin SSD levy oli käyttislevynä huomattava muutos.

Säteenseurannan järkevä hyödyntäminen vain nyt vaatiin peliengineiden uudestaanrakentamista, melko raskaalla kädellä tietyiltä osin ja siinä, että tulee kunnollisia sovelluksia kestää muutamia vuosia, tuosta ensirautajulkaisusta..

 

[zepi]

Ray tracingin-tyyppisillä ratkaisuilla ne kenttien staattiset valaistukset on tehty ainakin jostain Quake 1 ajoista alkaen.

Ei dynaamisesti ajon aikana, vaan serverifarmissa pelistudiossa.

-
Peliengineiden osalta homma on vähemmän vaikea kuin luulisi. Kun Unity ja Unreal engine julkaistaan sopivilla dxr-tuilla, niin pienet indiepajatkin pääsevät hyödyntämään ominaisuuksia seuraavissa peleissään.

Nykyisin intoa rajoittaa tietty rtx-korttien pienet markkinaosuudet, mutta sekin muuttuu joka viikko parempaan suuntaan kun RTX2000-sarjan kortit syrjäyttävät vanhoja gtx900 sarjalaisia ja ikiaikaisia radeoneita vähitellen.

 

[FireFly Renaissance]

Säteenseurannasta kannattaa huomioida, että se on ollut iät ja ajat se tapa, jolla valaistus hoidetaan ammattimaisessa renderöinnissä. Nyt ollaan siten pikkuhiljaa siirtymässä peleissäkin siihen oikeaan tapaan hoitaa tuo asia.

Varsinkin JOS tuota rautaa tulee myös konsoleihin, niin kannattaa varautua siihen, että näyttikset ilman ko ominaisuutta alkavat mennä kohti kierrätyskeskuksia.

Kyseinen asia on ensimmäinen merkittävä kehitysasken näyttisten historiassa, pitkään aikaan. Vähän, niinkuin SSD levy oli käyttislevynä huomattava muutos.

Säteenseurannan järkevä hyödyntäminen vain nyt vaatiin peliengineiden uudestaanrakentamista, melko raskaalla kädellä tietyiltä osin ja siinä, että tulee kunnollisia sovelluksia kestää muutamia vuosia, tuosta ensirautajulkaisusta..

Jos nyt olen ymmärtänyt okein niin näissä toteutuksissa tosin sitä koko kuvaa ei renderöidä ray tracingillä kuten tehdään jollakin 3d maxilla tai lightwavella vaan sillä ray tracingillä tehdään jotain kerroksia sen perinteisesti renderöidyn kuvan päälle.

Koko kuvan ray tracing taitaa olla edelleen aivan liian raskasta touhua normiresoluutioilla.

 

[zepi]

Jos nyt olen ymmärtänyt okein niin näissä toteutuksissa tosin sitä koko kuvaa ei renderöidä ray tracingillä kuten tehdään jollakin 3d maxilla tai lightwavella vaan sillä raytracingillä tehdään jotain kerroksia sen perinteisesti renderöidyn kuvan päälle.

Koko kuvan ray tracing taitaa olla edelleen aivan liian raskasta touhua normiresoluutioilla.

Q2 pyörii 1080p resolla käpättynä 60fps:ssä jo RTX2070:lla.

Siitä on tietty matkaa moderniin peliengineen ja modeleiden monimutkaisuuteen, mutta jotkut Superhot-tyyliset pelit voisi tehdä täysin raytracettamalla.

 

[Halpuuttaja]

Ray tracingin-tyyppisillä ratkaisuilla ne kenttien staattiset valaistukset on tehty ainakin jostain Quake 1 ajoista alkaen.

Ei dynaamisesti ajon aikana, vaan serverifarmissa pelistudiossa.

Jos en nyt väärin muista niin Quakeenhan oli ihan joku karttaeditori ja staattisen valaistuksen puuhaaminen onnistui ihan kotikoneellakin?

Ja mitä nyt vähän perseilin Unreal engine 4.22:lla tuossa keväällä niin ei siinä kovin kauaa mennyt kun se staattiset valot laski siihen pieneen sandboxiin.

 

[zepi]

Jos en nyt väärin muista niin Quakeenhan oli ihan joku karttaeditori ja staattisen valaistuksen puuhaaminen onnistui ihan kotikoneellakin?

Jep. Kun teet levelin, niin sen jälkeen staattiset valaistukset lasketaan offlinenä ja ”baketetaan” kiinteinä tekstuureina kenttädatan kyytiin.

Riippuen kartan ja valojen monimutkaisuudesta tuohon laskentaan sai käytettyä kymmeniä minuutteja laskenta-aikaa, vaikka Q1:sen lightmapit renderöitiin surkeilla resoluutioolla.

Edit: Koitappa ladata UE:hen joku monimutkainen kartta tuhansilla valoilla ja lasken sen valot.

Ja mieti sitä, että metrossa lasketaan reaaliaikaisesti samaa.

 

[Kaotik]

Edit: Koitappa ladata UE:hen joku monimutkainen kartta tuhansilla valoilla ja lasken sen valot.

Ja mieti sitä, että metrossa lasketaan reaaliaikaisesti samaa.

Sellainen pienen pieni yksityiskohta kannattaa kuitenkin muistaa että metrossa lasketaan säteillä valaistusta vain yhdellä valonlähteellä (skylight "aurinko"), ei tuhansilla

 

[jive]

Sellainen pienen pieni yksityiskohta kannattaa kuitenkin muistaa että metrossa lasketaan säteillä valaistusta vain yhdellä valonlähteellä (skylight "aurinko"), ei tuhansilla

Juu lisää skeneen yksi taskulamppu ja siinä meni offline rendaushyöty. Alan Wake olisi varmaan painajainen pelimoottorille

 

[JiiPee]

Videonpakkaus 15 vuotta sitten oli DivX/Xvid pikselimössöä. Meinaatko oikeasti että h265 ei olisi suorastaan mullistus verrattuna vanhoihin.

Niin tuntuu tytöiltä unohtuvan se että kehitystä tapahtuu myös pakkausrintamalla ja veikkaan että toi googlen käikäre tulee käyttämään AV1 ja pakkaus tapahtuu AMD:n jollain julkaisemattomalla custom raudalla. CPU:lla toi AV1 on vielä aivan tolkuttoman hidas.

 

[KVahlman]

Olisi kyllä mielenkiitoista saada lisätietoa että mitä tarkasti ottaen kiihdytellään, onko toteutus samantyyppinen kuin RTX korteissa vai ehkä jopa laajempi (RTX toteutushan on melko spesifi tietyn vaiheen kiihdytys) tai sitten huonossa tapauksessa teknisesti totta mutta käytännössä vain markkinataktiikkaa... jotenkin aina särähtää korvaan kun ultimate goal on pilvessä, sen verran kova buzzword kyseessä.

 

[FireFly Renaissance]

Niin tuntuu tytöiltä unohtuvan se että kehitystä tapahtuu myös pakkausrintamalla ja veikkaan että toi googlen käikäre tulee käyttämään AV1 ja pakkaus tapahtuu AMD:n jollain julkaisemattomalla custom raudalla. CPU:lla toi AV1 on vielä aivan tolkuttoman hidas.

Edelleen odotetaan innokkaasti tietoa niistä ihan oikeista algoritmeista. Näitähän pitäisi olla esittää vaikka mitä, kun se kehitys on ollut niin vauhdikasta?

 

[Monologi]

OT: Jokunen vuosi sitten AMD tarjosi näytönohjaimelleen ohjelmaa joka pakkasi leffoja mp4 muotoon niin oli kyllä nopea verrattuna muihin pakkausohjelmiin mitä tuli käytettyä.

 

[mRkukov]

Niin tuntuu tytöiltä unohtuvan se että kehitystä tapahtuu myös pakkausrintamalla ja veikkaan että toi googlen käikäre tulee käyttämään AV1 ja pakkaus tapahtuu AMD:n jollain julkaisemattomalla custom raudalla. CPU:lla toi AV1 on vielä aivan tolkuttoman hidas.

Eiköhän pakkausformaatti ole H264/h265 ihan vain rautatuen takia. Nopeampi ja kevyempi purkaa.

 

[jive]

Pikkuhiljaa alkaa pakkauksen ja prediktiivisen kuvan raja hämärtyä. Pakkauksessa ei informaatio lisäänny mutta liikevektoreihin ja fysiikkamallinnukseen nojautuvat menetelmät pyrkivät luomaan informaatiota ennustamalla. Puhtaan häviöttömän pakkauksen raja on tullut jo vastaan enkä millään usko että reaaliaikapakkaus pystyy kehittymään algoritmillisesti muutoin kuin rinnakkaistusta lisäämällä.

 

[jive]

Eiköhän pakkausformaatti ole H264/h265 ihan vain rautatuen takia. Nopeampi ja kevyempi purkaa.

Tämä on haluttu ominaisuus offline medialla mutta reaaliaikapakkaus on parempi olla symmetrinen tai jopa kevyempi pakata kuin purkaa.

 

[JiiPee]

Eiköhän pakkausformaatti ole H264/h265 ihan vain rautatuen takia. Nopeampi ja kevyempi purkaa.

Aivan tosiaan unohtui että eihän AV1 purkuun ole vielä rautatukea. Mutta VP9 on että se olisi vaihtoehto myös.

 

[deMentor]

Mistä johtuu, että Nvidia ja AMD näin yhtä aikaa panostavat säteenseurantaan? Onko tästä sovittu, vai onko syynä esim. se MS:n aloite että DirectX:ään tuli säteenseuranta?

Windowsiin dxr tuki tuli viime syksyn 1809 päivityksessä ja nvidia julkaisi ensimmäiset rt näytönohjaimet hieman aiemmin. Mitä isot edellä sitä pienet perässä, uutisen otsikko on hieman provosoiva koska amd leluihin rautatason rt tuki on tulossa vasta ensi vuosikymmenellä.

 

[mRkukov]

Tämä on haluttu ominaisuus offline medialla mutta reaaliaikapakkaus on parempi olla symmetrinen tai jopa kevyempi pakata kuin purkaa.

Lähinnä se että jos halutaan "tukea kaikkia laitteita joissa pyörii chrome", niin vaihtoehdot on aika vähissä. H264 on tuettu lähes kaikkialla ja kuten todettu sen pakkaus ei sopivilla algoritmeilla aiheuta niitä 100ms viiveitäkään. Rautapurku on vain pakollista ihan siksi että toimisi chromecastilla, kevyellä läppärillä yms eikä tappaisi akunkestoa aivan täydellisesti. Rautapurku on myös vakaampi ja tasaisempi purkaja kuin kuorman mukaan vaihteleva softalaskenta.

AV1 tulee tietysti tuetuksi heti kun sille alkaa tukea tulla. H264/H265 siihen asti.

 

[Kaotik]

Windowsiin dxr tuki tuli viime syksyn 1809 päivityksessä ja nvidia julkaisi ensimmäiset rt näytönohjaimet hieman aiemmin. Mitä isot edellä sitä pienet perässä, uutisen otsikko on hieman provosoiva koska amd leluihin rautatason rt tuki on tulossa vasta ensi vuosikymmenellä.

Noilla ajankohdilla nyt ei ole sen kysymyksen kanssa yhtään mitään tekemistä.

 

[Griffin]

Lähinnä se että jos halutaan "tukea kaikkia laitteita joissa pyörii chrome", niin vaihtoehdot on aika vähissä. H264 on tuettu lähes kaikkialla ja kuten todettu sen pakkaus ei sopivilla algoritmeilla aiheuta niitä 100ms viiveitäkään. Rautapurku on vain pakollista ihan siksi että toimisi chromecastilla, kevyellä läppärillä yms eikä tappaisi akunkestoa aivan täydellisesti. Rautapurku on myös vakaampi ja tasaisempi purkaja kuin kuorman mukaan vaihteleva softalaskenta.

AV1 tulee tietysti tuetuksi heti kun sille alkaa tukea tulla. H264/H265 siihen asti.

JA kuten todettu, jos ei haluta niitä viiveitä, niin sitten pakkauksen taso on surkea TAI kuvanlaatu on surkea. Eli joku kuluu tajuton kaista tai katsotaan kuvaa, jota kovinkaan moni ei viitsi pitempään katsella, Eli ei siitä H264:sesta 265:sta tai muista elokuvien striimaamiseen tarkoitetuista härpäkkeistä nyt vain ole järkevästi pelien striimaukseen.

Pilvihömppää on nyt vain ihan turha jauhaa, se nyt toimii ihan liian huonosti minkään nopeatempoisemman kanssa ja hidastempoisissa taa se kone kykenee piirtämään myös sen kuvan, eli tuo pilvihömpän jauhaminen on (taas tälläkertaa ainankin) täysin turhaa ja älytöntä.

 

[mango]

Ne keiden mielestä tuollanen 50-100ms viive voisi olla vielä pelikelpoinen, niin laittakaahan jossain räiskintäpelissä triple frame buffering päälle ja vaikka 60 fps lukitus päälle. Tuollaisilla asetuksilla hiiren liikuttamisen jälkeen kamera liikkuu vielä hyvän tovin. En ainakaan itse pysty pelaamaan tuollaisilla asetuksilla.

Ei tällä tekniikalla kaikkia pelejä välttämättä voi toteuttaa, mutta monissa peleissä viiveellä ei käytännössä ole mitään väliä. Lähinnä vaan näen huolestuttavana sen, että jos jotkut pelityypit kuolevat pois, koska niiden toteuttaminen pilvipalveluun ei ole järkevää...

 

[mRkukov]

Onnistuisikohan tuossa timewarp tapainen tekniikka?

 

[mRkukov]

Ne keiden mielestä tuollanen 50-100ms viive voisi olla vielä pelikelpoinen, niin laittakaahan jossain räiskintäpelissä triple frame buffering päälle ja vaikka 60 fps lukitus päälle. Tuollaisilla asetuksilla hiiren liikuttamisen jälkeen kamera liikkuu vielä hyvän tovin. En ainakaan itse pysty pelaamaan tuollaisilla asetuksilla.

Kytke konsoli vähän vanhempaan telkkaan ja koita pelata. Ihan sama efekti.

 

[SatanTwister]

Onhan metrossa nyt aika huimaavia parannuksia globaalin valaistuksen realistisuudessa.

Aika harvassa paikkaa kuitenkin ja mitä noista saa maksaa FPS. Karu totuus on se että edes hybridirendauksella voidaan tehdä GI, varjot tai heijaustukset reaallajassa. Kun todellisessa raytracingissä nuo pitäisi olla kaikki yhtä aikaa realtime joten aika kaukana vielä ollaa 60fps pelaamisesta.

 

[Griffin]

Aika harvassa paikkaa kuitenkin ja mitä noista saa maksaa FPS. Karu totuus on se että edes hybridirendauksella voidaan tehdä GI, varjot tai heijaustukset reaallajassa. Kun todellisessa raytracingissä nuo pitäisi olla kaikki yhtä aikaa realtime joten aika kaukana vielä ollaa 60fps pelaamisesta.

Kaikesta karkista saa maksaa FPS. Tosin se ei haittaa, kunhan noita vain kehitellään eteenpäin. Ja nyt ilmeisesti kaikki kehittelevät, joten suunta on erinomainen.
MUTTA
Raudan lisäksi myös ohjelmistoja joudutaan muokkaamaan rajusti, joten lopputulosta saadaan jokatapauksessa odotella vuositolkulla ja softaa tippuu lisää pikkuhiljaa..

 

[Zisu]

Tämä on haluttu ominaisuus offline medialla mutta reaaliaikapakkaus on parempi olla symmetrinen tai jopa kevyempi pakata kuin purkaa.

Muistaakseni H.264 referenssienkooderissa taisi olla niin että dekoodattiin yhtenä enkoodausvaiheena, pakkauksessa kuitenkin pitää tietää paljonko purettu kuva eroaa oikeasta eli miltä streamattu kuva näyttää.

 

[Gameri]

Tämä nyt on varmasti tyhmä kysymys tällä foorumilla mutta asiaan perehtymättömän on vaikea ymmärtää, millä kalustolla näitä lasketaan ja koodataan vaikkapa ensi alkuun miljoonalle yhtäaikaiselle pelaajalle? Joku serverifarmi jossain jossa high end näyttikset ja prossut mitkä laskisi rt:n ja koodaisi ”videon” tai piirrettävän datan pelaajalle? Mikä rauta jaksaa laskea rt:n näille miljoonille pelaajille?

 

[sushukka]

Kovin pitkään täällä jaksetaan nyt lauleskella pelistriimauksen ihmealgoritmien perään, jotka tulevat ja mullistavat kaiken. Lukekaa nyt ketju alusta lähtien (ei ole kuin pari sivua) ettei tarvitse samoja asioista vängätä yhä uudestaan. Lyhyt rautalankareferaatti:

• Raakavideossa vasteajat voivat olla juurikin sen verran mitä menee keskustella palvelinfarmin kanssa. Eli hyvällä tuurilla sitä mitä speedtest sanoo. Ongelmana vain että raakavideon siirto on täysin mahdotonta toteuttaa nyt ja pitkälle tulevaisuuteen koska siirtovaatimukset vain kasvavat 4K:n jne mukana.
• Kaista ja latenssi ovat eri asioita. Nopeus voi olla vaikka 1Gbs, mutta latenssi voi silti olla korkea. Latenssi muodostuu monesta palasesta, joista vain lähinnä kotireitittimeen ja kuinka sen kanssa kommunikoi voi suoraan vaikuttaa.
• Video on pakko pakata ja sitä varten tarvitsee olla useampi kuva informaatiota, jotta pakkauksesta saataisiin millään lailla tarpeeksi tehokasta. Tätä varten ovat sitten I/B/P-framet eli avain- ja muutoskuvat joiden perusteella kuvat pakataan. @hkultala on tämän selittänyt juurta jaksain jo useampi viesti takaperin. Nämä tuovat väkisin latensseja vaikka yhteys olisi kuinka hyvä. Ei ole mitään taikatemppua päästä tämän ohi ja tällä konseptilla jokseenkin kaikki mainstream-videopakkausalgoritmit ovat toimineet jo vuosikymmenet.
  • Yksi tapa on tietenkin mennä pelkästään I-frameilla, mutta kuten jo aikaisemmin todettu kaistan käyttö kasvaisi merkittävästi, koska pakkausta voitaisiin tehdä enää JPEG-tyyliin kuva kerrallaan. Vertailun vuoksi Youtube tuuppaa I-framen oletuksena kahden sekunnin intervallein (4K vaatii +15Mbs) ja muilla palveluilla se liikkuu yleensä 1-10sek luokassa. Toisin sanoen pelit ovat jo näihin verrattuna selkeästi vaativampaa luokkaa ja tulevat tiuhemman I-frameintervallin takia vaatimaan aina selkeästi enemmän kaistaa kuin vastaava video.
• Pelit ovat videoiden pakkausalgoritmien kannalta täysin epäennustettavia. Video on kaksiulotteista rasterikuvaa, joka ei ymmärrä pelin tapahtumista mitään. Kaikki pidemmät ennustusyritykset kaatuvat yksinkertaisesti vaikka siihen kun pelaaja päättää randomina painaa jotain pikamenunappia esim. aseen vaihtoon joka tuo jonkun pikavalikkoympyrän esiin peittäen 60% pelikuvasta.
• Pelitapahtumien ennustaminen vaatii että käytetään jotain monimutkaisempaa mallia kuin videostriimaus, jolloin aletaan luistelemaan kohti sitä ajatusta että laskentaa tehdään client-päässä eli peliä ajetaan kohdekoneella mikä on juurikin sitä mitä näillä yritetään välttää.
• Koska idea on tuoda tämä juuri niille vähemmän tehokkaille laitteille, ei voida käyttää mitään kovin eksoottisia algoritmeja tai malleja. H.264 ja H.265 (joka sekin vaatii jo aika uutta rautaa) ovat de facto millä mennään. Vaikka joku uusi hieno algoritmi keksittäisiinkin, niin siihen pätevät edelleen samat latensseja tuovat ennustussäännöt mitä yllä mainittiin. Normivideoissa tiedetään mitä tapahtuu hetken päästä tai voidaan puskuroida "reaaliaikaistakin" videota jonkun verran, peleissä vaaditaan se aikakone että päästäisiin samaan.
• Kaikki liikenne maksaa. Nyt raskaimpana internet-kuormana ovat videot, mutta niissä voidaan pelata laatuluokilla ja puskuroinneilla. Kuvaa voidaan puskuroida hyvinkin pitkälle eteenpäin ja käyttäjä saa edelleen juonesta selvää vaikka kuva vähän menisikin mössöksi. Peleissä ei ole näihin mihinkään varaa. Puskurointiajat ovat muutamien kymmenien millisekuntien luokkaa ja pikselöityvä kuva voi tehdä pelaamisesta mahdotonta kun strategiset tiedot menevät puuroksi.

Ei tämä kilpaile PC-pelaajien kanssa oikein millään lailla. PC-pelaajat tunnistaa nyt heti alkuun hiiri-näppiskombosta. Samoin näppis-hiiri-kombo on paljon vähemmän anteeksiantava kuin konsolipadit ja niille optimoidut pelit automaattitähtäyksineen yms. Toisekseen PC:llä pelaavat rakentavat koneensa, tuunaavat ja virittelevät sitä mikä on todennäköisesti puoliksi se PC-pelailun suola.

Konsolipelaajat ovat näiden striimijuttjen ykköskohderyhmä. Erityisesti näen että Google yrittää Stadiallaan iskeä Nintendon mukana liikkuvaa Switchiä vastaan. En myöskään näe kovin isona kohteena jotkut padillä tai vanhoilla hitaan ruudun läppäreillä pelaavat, vaan kyllä niitä hienoja ykkösnimiä halutaan pelata isolla ja tarkoitukseen sopivalla ruudulla eli TV:llä. Se liikkuvuus tarvitsee kuitenkin vähintään sen Chromecast Ultran = 80€. Eli jos konsoli maksaa sen 250€ (PS4 Slim), ei tarvitse maksaa jotain striimikuukausihintaa, eikä tarvitse ostaa kalliimpaa nettiliittymää (ja toivoa että se riittää), niin hyvin moni ostaa edelleen sen konsolin.

Ne helpoimmin striimattavat pelit voidaan paradoksaalisesti pyörittää useimmiten myös sillä kohdekoneella, mutta ne enemmän tehoa vaativat ja useimmiten ostohousut jalkaan saavat pelit ovat kaikkein haastavimpia. Näiden striimipalveluidenhan pitää pystyä sitten pyörittämään ne kaikki. Siinä vaiheessa kun tulee muutamakin huonosti pyörivä huippupeli ja pakottaa käyttäjän hankkimaan sen konsolin tai PC:n, niin striimipalvelusta on tullut vain ylimääräinen kuluerä. Toisin sanoen jos ja kun se normipelaaja useimmiten pelaa edes satunnaisesti jotain CS:ää, Fortniteä (pthyi), Dotaa, SC2:sta jne, niin koko striimauspalvelu käy irrelevantiksi.

 

[mRkukov]

Pelit ovat videoiden pakkausalgoritmien kannalta täysin epäennustettavia. Video on kaksiulotteista rasterikuvaa, joka ei ymmärrä pelin tapahtumista mitään. Kaikki pidemmät ennustusyritykset kaatuvat yksinkertaisesti vaikka siihen kun pelaaja päättää randomina painaa jotain pikamenunappia esim. aseen vaihtoon joka tuo jonkun pikavalikkoympyrän esiin peittäen 60% pelikuvasta.

Muuten ihan hyvä postaus, mutta tuollainen asevalikko olisi aika helppo toteuttaa selaimen päässä ilman että siitä tulisi raskasta. Ei youtubenkaan hallintanapit tule streamin mukana.

Mutta joo. Ei tuon kohde ole PC master race 2000€ esports pelikoneineen ja 244Hz 4k näyttöineen. Kyllä kohde on ne joilla on esim ps3 tai vastaava ja eivät halua ostaa uutta konsolia. Kuukausimaksullinen paketti jonka saa helposti katkolle kuulostaa oikein hyvältä. Chromecast ei ole vaatimus. Riittää ihan perus läppäri ja hdmi kaapeli.