AMD kertoi mikä FSR 4.1:n INT8-version julkaisussa vie aikaa

  • Keskustelun aloittaja Keskustelun aloittaja Kaotik
  • Aloitettu Aloitettu

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
25 539
RDNA 3 -näytönohjaimilla teknologia saadaan käyttöön nopeammin sen INT8-tarkkuutta tukevien kiihdytinten kautta, mutta RDNA 2 -sukupolvi joutuu pyörittämään sitä Compute Unit -yksiköillä muun koodin mukana, mikä vaatii rutkasti optimointia suorituskyvyn näkökulmasta.
amd-fsr-logo-20260514.jpg

AMD:n FSR 4 -teknologian lipsahdettua hetkellisesti julki avoimena lähdekoodina harrastajat ovat viritelleet sen kehitteillä olleen INT8-version toimimaan jo useissa peleissä. Suurempi yleisö on kuitenkin jäänyt odottamaan INT8-version virallista julkaisua.

AMD kertoi hiljattain, että INT8-tarkkuuteen perustuva versio pykälää tuoreemmasta FSR 4.1 -versiosta on tulossa RDNA 3 -näytönohjaimille heinäkuun aikana. RDNA 2 -sukupolven näytönohjaimet joutuvat kuitenkin odottamaan teknologiaa ensi vuoteen saakka. AMD kertoi Computex-messuilla TechPowerUpille miksi RDNA 2 -versiossa kestää pidempään, vaikka INT8-versio teknisesti toimiikin arkkitehtuurilla riippumatta erillisestä versiosta.

AMD:n mukaan RDNA 3 -näytönohjaimet tulevat saamaan FSR 4.1 -tuen nopeammin, koska niiden tekoälykiihdyttimet tukevat nopeampaa INT8-laskemista. Yhtiö kertoo, että INT8-versiossa on kestänyt näin pitkään, koska se haluaa varmistua mallin olevan optimoitu kunnolla ja ettei eri tarkkuuteen vaihtaminen vaikuta näkyvästi kuvanlaatuun.

RDNA 2 -näytönohjaimissa ei ole vastaavia kiihdyttimiä, vaan FSR 4.1 pyörii samaan tapaan kuin kaikki muukin koodi normaalisti vain sen Compute Unit -yksiköiden stream-prosessoreiden voimin. AMD:n mukaan on todellinen haaste optimoida FSR-mallin suoritusta kuluttamaan mahdollisimman vähän aikaa ilman erillistä kiihdytystä ja siten tarjoamaan käyttäjille hyvä kokemus romahtavan suorituskyvyn sijaan. Tämä optimointityö vie aikaa, jonka vuoksi malli tullaan julkaisemaan RDNA 2:lle vasta ensi vuoden puolella.

AMD kertoi samassa haastattelussa, että se opettaa FSR-mallia yhtiön omilla Instinct MI -sarjan kiihdyttimillä ROCm-alustalla ja mallin pienuuden vuoksi se vaatii vain muutamia laskentaklustereita kokonaisten supertietokoneiden sijasta. ROCm tukee Instinct-kiihdyttimien lisäksi myös tavallisia Radeoneita sekä Radeon Pro -ammattilaismalleja, joista jälkimmäisiä käytetään mallin hienosäätöön ja valmisteluun loppukäyttöön pelinäytönohjaimilla.

Lähde: TechPowerUp
 
Viimeksi muokattu:
Tuota vähän arvelinkin. AMD:n markkinointiosaston mielestä näyttäisi huonolta, jos kortti on monta kertaa hitaampi kuin Nvidian lappu, käytettäessä scaalausta, joten huonompi laatu 3:lla on ollut heistä parempi vaihtoehto kuin suuri hitaus nelosella.
Saas nähdä mitä joutuvat tekemään, että saavat nelosen 6000 sarjalaisille. Pitääkö jo laatua tiputtaa jotenkin vai millä lisänoupeus aiotaan saavuttaa...
 
Varmaankin kaikilla korteilla pitää pudottaa renderöintiresoluutiota fsr3 nähden. Oletettavasti käyttökelpoinen nopeimmilla korteilla, mutta yllättyisin jos hitaammat jaksavat skaalata 720p->4k järkevällä nopeudella. Eiköhän tämä ole enemmän tai vähemmän tempaus yrittää pitää asiakkaat radeon leirissä.
 
Ihme spinnausta. Compute uniteilla tuo lasketaan kaikilla mainituilla arkkitehtuureilla RDNA 2, 3, 4.
 
Ihme spinnausta. Compute uniteilla tuo lasketaan kaikilla mainituilla arkkitehtuureilla RDNA 2, 3, 4.
RDNA 3:lla (INT8) ja 4:llä (FP8) on dedikoituja yksiköitä siellä Compute Uniteissa kiihdyttämässä näitä hommia vaikka stream prosessoreita käytetään toki myös. RDNA 2:lla on pelkät stream prosessorit.
 
RDNA 3:lla (INT8) ja 4:llä (FP8) on dedikoituja yksiköitä siellä Compute Uniteissa kiihdyttämässä näitä hommia vaikka stream prosessoreita käytetään toki myös. RDNA 2:lla on pelkät stream prosessorit.
Eli kaikissa homma tapahtuu CU :n sisällä.

”Dedikoituja” yksiköitäkään ei ole olemassa, vaan ne samat laskentayksikön sisäiset palat vaan saadaan tehokkaammin hyödynnettyä matalemman bittisyvyyden lukuja käsiteltäessä. Eli esim. yksi int16 laskentayksikkö saadaankin konffattua laskemaan samanaikaisesti kaksi int8 laskutoimitusta. Se laskentayksikkö ei samanaikaisesti voi sitä int16 laskentayksikköä käyttää silloin kun sillä lasketaan niitä int8 laskuja.
 
Eli kaikissa homma tapahtuu CU :n sisällä.

”Dedikoituja” yksiköitäkään ei ole olemassa, vaan ne samat laskentayksikön sisäiset palat vaan saadaan tehokkaammin hyödynnettyä matalemman bittisyvyyden lukuja käsiteltäessä. Eli esim. yksi int16 laskentayksikkö saadaankin konffattua laskemaan samanaikaisesti kaksi int8 laskutoimitusta. Se laskentayksikkö ei samanaikaisesti voi sitä int16 laskentayksikköä käyttää silloin kun sillä lasketaan niitä int8 laskuja.
Siellä on erilliset yksiköt jotka tekevät niistä matriisilaskuista nopeampia, vaikka ne käyttävät resursseinaan stream prosessoreita. Seuraavaksi varmaan olet sitä mieltä ettei siellä ole mitään säteenseurantakiihdyttimiäkään koska siinäkin käytetään stream prosessoreita (ja teksturointiyksikön resursseja)
 
Siellä on erilliset yksiköt jotka tekevät niistä matriisilaskuista nopeampia, vaikka ne käyttävät resursseinaan stream prosessoreita. Seuraavaksi varmaan olet sitä mieltä ettei siellä ole mitään säteenseurantakiihdyttimiäkään koska siinäkin käytetään stream prosessoreita (ja teksturointiyksikön resursseja)
Kunhan huomautin että kaikissa mainituissa arkkitehtuureissa laskenta tapahtuu seuraavasti:
FSR 4.1 pyörii samaan tapaan kuin kaikki muukin koodi normaalisti sen Compute Unit -yksiköillä.
Toki uudet arkkitehtuurit ovat usein nopeampia kuin vanhat. Tämä tuskin on yllätys kenellekkään.
 
Kunhan huomautin että kaikissa mainituissa arkkitehtuureissa laskenta tapahtuu seuraavasti:

Toki uudet arkkitehtuurit ovat usein nopeampia kuin vanhat. Tämä tuskin on yllätys kenellekkään.
Olisin voinut olla tarkempi ja puhua stream prosessoreista, mutta ko. termi on jätetty aika taka-alalle niin se on vähän itseltäkin jäänyt. Käyn tarkentamassa niin ei jää epäselväksi, olihan se epäselvä ilmaisu.
Nyt se on "RDNA 2 -näytönohjaimissa ei ole vastaavia kiihdyttimiä, vaan FSR 4.1 pyörii samaan tapaan kuin kaikki muukin koodi normaalisti vain sen Compute Unit -yksiköiden stream-prosessoreiden voimin."
 
Olisin voinut olla tarkempi ja puhua stream prosessoreista, mutta ko. termi on jätetty aika taka-alalle niin se on vähän itseltäkin jäänyt. Käyn tarkentamassa niin ei jää epäselväksi, olihan se epäselvä ilmaisu.
Nyt se on "RDNA 2 -näytönohjaimissa ei ole vastaavia kiihdyttimiä, vaan FSR 4.1 pyörii samaan tapaan kuin kaikki muukin koodi normaalisti vain sen Compute Unit -yksiköiden stream-prosessoreiden voimin."
Jes, hyvä tarkennus.
:thumbsup:


Jos ne AI matriisivääntimet olisi ollu CU:n ulkopuolella niin toi aiempikin olis toki mennyt ihan hyvin. Stream matriisivääntimet ja AI matriisivääntimet on siellä CU:ssa kuitenkin näissä arkkitehtuureissa samanarvoisessa asemassa ja molemmilla tapahtuva laskenta on ”normaalia” CU:n sisäistä laskentaa.
 
Eli käytännössä joutuneet kirjoittamaan suurimman osan koodista uusiksi joka sukupolvelle. Ei ihme, että kestää
 
Varmaankin kaikilla korteilla pitää pudottaa renderöintiresoluutiota fsr3 nähden. Oletettavasti käyttökelpoinen nopeimmilla korteilla, mutta yllättyisin jos hitaammat jaksavat skaalata 720p->4k järkevällä nopeudella. Eiköhän tämä ole enemmän tai vähemmän tempaus yrittää pitää asiakkaat radeon leirissä.
No ainakin Unreal Engine 5 pelien kohdalla voin sanoa että FSR4.0.2 on tuonut huomattavaa suorituskykyetua vs FSR3.1.5 ihan samoilla skaalauksilla 1440p pelatessa. Syyllinen lienee puhtaasti se että uudet pelit ja unreal engine 5 on suoraan vaan paremmin optimoitu FSR4:lle. Olen tämän useamman pelin kohdalla todennut. Eli mistään tappiosta suorituskyvyn osalta ei ainakaan UE5 peleissä voida puhua. Tilanne voi olla toki toinen jos skaalataan 720p kuvaa 4k:lle mutta itse siis pelaan lähes natiivilla skaalauksella 1440p:llä FSR4:lla
 
Eikö fsr3 ja 4 vaadi pitkälti samoja inputteja peliltä, eli nopeuseron pitäisi tulla puhtaasti skaalauskustannuksesta.

Löysin YouTubesta rx6750xt fsr4 ja fsr3 vertailun 1440p resoluutiolla. Ainakin tässä tapauksessa fsr3 quality ja fsr4 performance ovat nopeudeltaan samaa luokkaa, eli fsr4 käytössä pitää pudottaa input resoluutiota pari pykälää. Kuvanlaatu on samaa luokkaa tai parempi.
 
Eikö fsr3 ja 4 vaadi pitkälti samoja inputteja peliltä, eli nopeuseron pitäisi tulla puhtaasti skaalauskustannuksesta.

Löysin YouTubesta rx6750xt fsr4 ja fsr3 vertailun 1440p resoluutiolla. Ainakin tässä tapauksessa fsr3 quality ja fsr4 performance ovat nopeudeltaan samaa luokkaa, eli fsr4 käytössä pitää pudottaa input resoluutiota pari pykälää. Kuvanlaatu on samaa luokkaa tai parempi.
Selittänee sen minkä takia lähes natiivilla resoluutiolla skaalattuna tuo suorituskykyero on siis olematon eikä niin suuri mitä väitetään aina puheissa. Toki mitä muistelen noita aikasempia FSR4.0.2 testejä youtubesta niin ei se suorituskykyero todellakaan ollut suuri. Omassa empiirisessä käytössä kuitenkin suurin ero on huomattava nimenomaan ollut noissa UE5 peleissä. En siis puhu pelkästä FPS erosta vaan FSR3.1.5 stutteroi huomattavasti enemmän vs FSR4. Viimeisempänä esimerkiksi Fatekeeper joka oli FSR3.1.5:lla lähes pelaamaton mutta kun vaihdoin FSR4.0.2 peli muuttui täysin sulavaksi kokemukseksi. Molemmissa tapauksessa resoluutio slideri oli natiivilla.
 
Juurikin niin, techspot on testannut tätä kattavammin ja nimenomaan fsr4 nativella suorituskykyero on minimaalinen myös vanhemmilla korteilla.
 
AMD:n videolta löytyy myös vertailu viralliseen versioon ja yhteisömodiin. Parissa esimerkissä nopeutta on tullut noin 7% lisää, joka on tietenkin enemmän kuin ei mitään. RDNA3.x APUihin tuki tulee AMD:n mukaan myöhemmin, eli vielä ei pääse itse testaamaan.
 
AMD:n videolta löytyy myös vertailu viralliseen versioon ja yhteisömodiin. Parissa esimerkissä nopeutta on tullut noin 7% lisää, joka on tietenkin enemmän kuin ei mitään. RDNA3.x APUihin tuki tulee AMD:n mukaan myöhemmin, eli vielä ei pääse itse testaamaan.
Ainakin optiscalerin kanssa Valven julkaisemilla DLL-tiedostoilla toimii jo nyt RDNA 3.5
 
Liekö sattumaa mutta samoihin aikoihin 26.6.2 ajureiden tultua jakoon Valve laittoi höyrykoneensa varattavaksi 🤔
 
Liekö sattumaa mutta samoihin aikoihin 26.6.2 ajureiden tultua jakoon Valve laittoi höyrykoneensa varattavaksi 🤔
Riippuen keltä kysyy joko AMD joutui odottamaan Steam Machinen julkaisuun jostain sopimussyystä x tai vaihtoehtoisesti AMD päätyi aikaistamaan julkaisua vähän (heinäkuussa piti vasta) koska Valve pisti DLL:t jakoon jo eilen
 
Mistäs sen 4.1 päälläolon nyt sitten näkee? Tuo AMD:n statistiikkaikkuna kun ei näytä kuin supported joka taas kuulostaa siltä, että se näyttää vain tukeeko peli vai ei, mutta ei päälläoloa
 
Linuxin puolella tuo FSR4.1.1 toimii ainakin ongelmitta tällä hetkellä viimesimmällä optiscaler 0.9.3:lla ja redditistä löytyvällä FSR4.1.1 ajuri filulla. amd_fidelityfx_upscaler_dx12.dll otetaan suoraan AMD:n SDK:sta tällä kertaa.
 
Mistäs sen 4.1 päälläolon nyt sitten näkee? Tuo AMD:n statistiikkaikkuna kun ei näytä kuin supported joka taas kuulostaa siltä, että se näyttää vain tukeeko peli vai ei, mutta ei päälläoloa
jotkut pelit on vähän hankalia tapauksia ja FSR pitää laittaa pelinasetuksista päälle vasta itse peliin päästyä jotta Supported muuttuu Active.
 
jotkut pelit on vähän hankalia tapauksia ja FSR pitää laittaa pelinasetuksista päälle vasta itse peliin päästyä jotta Supported muuttuu Active.
Ok, eli siinä pitää olla active, että se toimii. Hyvä tietää
 
Ok, eli siinä pitää olla active, että se toimii. Hyvä tietää
En kyllä saa sitä Active moodiin kuin Oblivion Remakella. Dragonwilds ja Titan Quest II joiden pitäisi sitä tukea eivät siirry active moodiin teki mitä tahansa. Ajuri kyllä tunnistaa, että peli tukee, mutta ei mene aktiiviseksi
 

Statistiikka

Viestiketjuista
310 382
Viestejä
5 264 171
Jäsenet
83 804
Uusin jäsen
vonhande

Hinta.fi

Back
Ylös Bottom