AMD kertoi lisää Computex-messujen uutuuksista (Ryzen 7000, AM5, SmartAccess Storage)

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
22 495
amd-hallock-azor-pcworld-the-full-nerd-20220525.jpg


Kaotik kirjoitti uutisen/artikkelin:
AMD esitteli Ryzen 7000 -sarjan Raphael-koodinimellisiä Zen 4 -prosessoreita Computex-messujen keynote-esityksessään. Nyt yhtiön teknisen markkinoinnin johtaja Robert Hallock ja Gaming Solution -puolen pääarkkitehti Frank Azor ovat tarkentaneet joitain yksityiskohtia tulevista prosessoreista.



Hallock ja Azor vastasivat PCWorldin The Full Nerd -lähetyksessä joukkoon AM5- ja Ryzen 7000 -aiheisia kysymyksiä. Ensimmäisenä oleellisena yksityiskohtana Hallock tarkensi, että ilmoitettu 170 watin maksimikulutus viittaa PPT-arvoon (Package Power) ja prosessoreiden maksimi TDP tulee olemaan 125 wattia. Käytännössä siis maksimikulutus nousee 28 watilla AM4-kannan 142 watin PPT-katosta.



Prosessorin esittelyvideolla nähty 5,5 GHz:n kellotaajuus oli niin ikään täysin vakiona ajetulla prosessorilla, eikä sen saavuttamiseen käytetty AMD:n mukaan ylikellotusta. Ian Cutress on puolestaan varmistanut, että kyseisessä kokoonpanossa oli huhti-toukokuun vaihteessa valmistettu 16-ytiminen ES-prosessori AMD:n referenssiemolevyllä ja Asetekin 280 mm:n AIO-nestekierrolla jäähdytettynä. Prosessorin ytimet toimivat pelissä tilanteesta riippuen 5,2-5,5 GHz:n kellotaajuudella jopa siten, että useimpien ydinten kellotaajuus oli 5,5 GHz samanaikaisesti.

Zen 4:n suorituskykyparannuksista osa tulee haastattelun mukaan suoraan kaksinkertaiseksi kasvaneesta L2-välimuistista ja Infinity Fabricia ajetaan oletuksena 1:1-kelloilla DDR5-muistien kanssa ainakin virallisesti tuetuilla muistikellotaajuuksilla. Prosessorin IO-siruun integroitu RDNA2-grafiikkaohjain on tarkoitettu lähinnä diagnostiikkakäyttöön tai hätätilanteisiin eikä se tule olemaan yhtä tehokas, kuin mobiiliprosessoreiden integroidut grafiikkaohjaimet. Grafiikkaohjaimessa on kuitenkin mukana videoyksiköt kiihdytettyä pakkausta ja purkua varten. Prosessorilla on fyysisesti 28 PCIe Gen 5 -linjaa, joista neljä on pyhitetty piirisarjalle.

Myös SmartAccess Storagesta kerrottiin hieman lisätietoja. SAS on tuettu, kun käytössä on sekä AMD:n prosessori, näytönohjain ja tuettu SSD-asema. Haastattelussa ei tarkennettu mitä kaikkia ominaisuuksia NVMe SSD -asemalta vaaditaan, mutta pelkkä PCIe Gen 4- tai 5-tuki ei sellaisenaan vielä riitä. SAS:n avulla AMD kertoo voivansa optimoida reittiä ja poistaa pullonkauloja standardiin DirectStorageen verrattuna.

Haastatteluun mahtuu myös muita pieniä yksityiskohtia, joten suosittelemme lämpimästi kaikille asiasta kiinnostuneille koko haastattelun katsomista.

Linkki alkuperäiseen juttuun
 
Myös SmartAccess Storagesta kerrottiin hieman lisätietoja. SAS on tuettu, kun käytössä on sekä AMD:n prosessori, näytönohjain ja tuettu SSD-asema. Haastattelussa ei tarkennettu mitä kaikkia ominaisuuksia NVMe SSD -asemalta vaaditaan, mutta pelkkä PCIe Gen 4- tai 5-tuki ei sellaisenaan vielä riitä. SAS:n avulla AMD kertoo voivansa optimoida reittiä ja poistaa pullonkauloja standardiin DirectStorageen verrattuna.

Liittyisikö jotenkin siihen nämä SAS optimoinnit että aidosti sallitaan SSD:ltä tiedon liikkuminen suoraan GPU:lle? Kun DirectStorage ei tuota taida nyt tai lähitulevaisuudessa aidosti tukea vaan data kierrätetään aina CPU kautta.

Asiaan liittyvää pohdintaa: Yosoygames: DirectStorage speculations & myths

Security and access synchronization.
This applies to PC but can be ignored on consoles. It is the reason I seriously doubt DS will ever give the SSD -> GPU direct path we were promised. Ensuring the following is a nightmare:
  • The GPU respects file access permissions
  • The GPU doesn’t accidentally perform out of bound reads (i.e. read the next file on disk it’s not supposed to; or read filesystem metadata of random files like timestamps or filenames)
  • The GPU somehow becomes able to write to the disk
  • The CPU doesn’t write to the filesystem sections the GPU is currently reading
  • Motherboard bus errors (contrary to popular belief they’re RAMPANT. We just don’t hit them because our SW is designed to avoid them. But if we give widespread access, malware will find a way to trigger it)
If we could ignore this problem, then direct SSD -> GPU transfers could happen. This is possible in locked down platforms like consoles or iOS; but security is a concern in more open platforms like PC.
 
Kelloa lisää, kakkua lisää, watteja lisää. Toivon mukaan sekaan lipsahtaa jotain hiukan nokkelampaakin parannusta.
 
Liittyisikö jotenkin siihen nämä SAS optimoinnit että aidosti sallitaan SSD:ltä tiedon liikkuminen suoraan GPU:lle? Kun DirectStorage ei tuota taida nyt tai lähitulevaisuudessa aidosti tukea vaan data kierrätetään aina CPU kautta.

SAS ja RTX IO on toteutukset jota AMD/NVIDIA tarjoaa siihen ja DirectStorage on se rajapinta jonka taakse ne (optimaalisesti) piiloutuu kehittäjältä. DirectStorage itse ei mitään GPU-spesifistä purkua ymmärrettävästi toteuta. Intel ei ole muistaakseni nimennyt omaansa mutta eiköhän sieltäkin joku IntelliStorage tule markkinoille.

Jos olen oikein asian ymmärtänyt niin DS:llä sanotaan "täällä pakattu datalohko" ja "tuonne videomuistiin kiitos". DS sitten toteuttaa välissä tapahtuvat asiat miten parhaiten pystyy riippuen siitä onko saatavilla GPU-purkua (jos ei niin CPU:n kautta) tai NVMe SSD:tä (jos ei niin ei käytetä sitä uutta i/o apia). Voin toki olla liian sinisilmäinen ja toiveikas kun olen vain pintapuolisesti selaillut esimerkkikoodeja ja dokumentaatiota, mutta olishan se hienoa jos menisi niinkuin luulen.
 
Jos olen oikein asian ymmärtänyt niin DS:llä sanotaan "täällä pakattu datalohko" ja "tuonne videomuistiin kiitos". DS sitten toteuttaa välissä tapahtuvat asiat miten parhaiten pystyy riippuen siitä onko saatavilla GPU-purkua (jos ei niin CPU:n kautta) tai NVMe SSD:tä (jos ei niin ei käytetä sitä uutta i/o apia). Voin toki olla liian sinisilmäinen ja toiveikas kun olen vain pintapuolisesti selaillut esimerkkikoodeja ja dokumentaatiota, mutta olishan se hienoa jos menisi niinkuin luulen.

Ei nyt kuulosta kyllä siltä mitä itse olen ymmärtänyt. Käsittääkseni DirectStorage nimenomaan poistuu kaikesta tuommoisesta "automaagisuudesta" ja fixed-function operoinnista. Joka ikinen operaatio, tuettu feature, whatnot pitää nimenomaan tarkkaan määritellä ja rakentaa ajon aikana ja engine pitää suunnitella nimenomaan alusta asti ottamaan täysi hyöyty uudesta paradigmasta.

DirectStoragen pitäisi olla vähän niin kuin Vulkan grafiikka rajapinta, joka antaa kaiken vastuun itse devaajalle viimeisintä lippua myöten ja jos pipelinestä puuttuu tietyn tärkeän lipun tarkistus tietyssä kohdassa niin koko GPU driveri kaatuu ilman mitään varoitusta. Jopa se että miksi se driveri veti voltin tietyssä kohtaa pitää itse koodata Validation Layerin muodossa joka erikseen tarkkailee sitä tiettyä lohkoa ajossa ja raportoi devaajan itse haluamia parametreja ulos pipelinen tilasta.

Vulkania olen kirjoitellut ja perus hello triangle ynnä muut pikku testailut on tullut koeponnistettua niin sitä kautta joku käsitys on Vulkanista ja ymmärrys on että DirectStorage haluaisi tehdä saman I/O:lle.
 
Integroitu näytönohjain on kiva lisä, niin saa esim. kakkosnäytöllä olevan selaimen videopurun ja renderöinnin pyörimään sen kautta.

Nykyisin videonkatselu tökkii, jos ykkösnäytöllä oleva peli vie kaiken tehon erillisnäytönohjaimelta.
 
PCWorld:in videossa amd:n heput jonkinlaisen pyristelyn jälkeen myönsivät että SAS ei ole uusi rajapinta. SAS toimii DirectStoragen rajapinnan kautta. Samassa amd:n heput sanoivat, että perus DirectStorage ensin siirtää datan levyltä keskusmuistiin ja keskusmuistista gpu:n muistiin. SAS poistaa tuon keskusmuistin kautta datan kierrättämisen.

Ongelma engineille on siinä, että enginet pitäisi muuttaa kokonaan assetteja striimaavaksi. Jos peli ensin lataa koko kentän muistiin ja sitten pelataan niin siinä on iso kasa koodailua, assettien säätämistä striimaskelpoiseksi, testaamista jne. Unreal Engine5 on esimerkki tällaisesta striimaavasta pc enginestä.
 
PCWorld:in videossa amd:n heput jonkinlaisen pyristelyn jälkeen myönsivät että SAS ei ole uusi rajapinta. SAS toimii DirectStoragen rajapinnan kautta. Samassa amd:n heput sanoivat, että perus DirectStorage ensin siirtää datan levyltä keskusmuistiin ja keskusmuistista gpu:n muistiin. SAS poistaa tuon keskusmuistin kautta datan kierrättämisen.

Ongelma engineille on siinä, että enginet pitäisi muuttaa kokonaan assetteja striimaavaksi. Jos peli ensin lataa koko kentän muistiin ja sitten pelataan niin siinä on iso kasa koodailua, assettien säätämistä striimaskelpoiseksi, testaamista jne. Unreal Engine5 on esimerkki tällaisesta striimaavasta pc enginestä.
Myönsivät? Ihan ensi esittelyssä keynotessa jo sanottiin ihan alkuun että kyse on heidän DirectStorage-toteutuksestaan (johon saadaan vähän lisäkarkkia omasta alustasta)
 
Myönsivät? Ihan ensi esittelyssä keynotessa jo sanottiin ihan alkuun että kyse on heidän DirectStorage-toteutuksestaan (johon saadaan vähän lisäkarkkia omasta alustasta)

Jos olet katsonut sen pcworldin videon niin tuon asian myöntäminen vaikutti yhtä mielekkäältä operaatiolta amd:n edustajille kuin mitä normijampalle on viisaudenhampaan poistaminen. Useaman kerran kun pcworldin heput tenttasivat asiasta ennen kuin amd:n vastauksista sai laskettua 1+1=2.
 
Jos olet katsonut sen pcworldin videon niin tuon asian myöntäminen vaikutti yhtä mielekkäältä operaatiolta amd:n edustajille kuin mitä normijampalle on viisaudenhampaan poistaminen. Useaman kerran kun pcworldin heput tenttasivat asiasta ennen kuin amd:n vastauksista sai laskettua 1+1=2.
En nyt uudestaan lähde katsomaan, koska riippumatta miten siinä haastiksessa meni, se sanottiin heti kun ko. ominaisuus esiteltiin keynotessa. Eli mikään salaisuus tms se ei ollut kun tuo haastis julkaistiin.
 
En nyt uudestaan lähde katsomaan, koska riippumatta miten siinä haastiksessa meni, se sanottiin heti kun ko. ominaisuus esiteltiin keynotessa. Eli mikään salaisuus tms se ei ollut kun tuo haastis julkaistiin.

Mulla jäi keynote välistä. Pahoittelut etten ollut sen osalta ajan tasalla. Lueskelin vain anandtechin lyhennelmän asiasta ja katsoin pcworldin podcastin.

Ehkä amd halusi esitellä amd teknologiaa pcworldin podcast:ssa eikä amd toteutusta microsoft teknologialle? Tämä voisi selittää miksi pr miehet tekivät mitä pr miehet tekivät. PR elää ehkä omaa elämäänsä.

-----

Sellainen mielenkiintoinen asia, että jos pelit haluavat käyttää keskusmuistia cachena niin jossain välissä sinne keskusmuistiin kuitenkin tarvii sitä purettua dataa siirtää. UE5:ssa on kolmitasoinen pakkaus. Levyllä on tiukin pakkaus, cachessa vähän löysempi ja gpu.n muistissa data on vähiten pakattu. Ainakin ue5 siis säilyttää löysemmin pakattuja assetteja keskusmuistissa. ue5:en kolmitasoiseen pakkaukseen + keskusmuistin käyttämiseen cachena löytyy viime siggraph messuilta hyvä esitys. Olen linkannut sen varmaan puolentusinaa kertaa niin jätän tällä kertaa linkin laittamatta.
 
Joka ikinen operaatio, tuettu feature, whatnot pitää nimenomaan tarkkaan määritellä ja rakentaa ajon aikana ja engine pitää suunnitella nimenomaan alusta asti ottamaan täysi hyöyty uudesta paradigmasta.

Ei tämä kyllä ole ristiriidassa yksinkertaistetun esimerkin kanssa jonka annoin.

DS (kuten tosiaan Vulkan sen verran kun siitä itse ymmärrän) toimii jonojen kautta, joihin submitataan (mielellään mahdollisimman paljon) pyyntöjä jotka kertoo mistä ja mitä ladataan (tiedosto/keskusmuisti) sekä minne ladataan (keskusmuisti/videomuisti).

Applikaation ei tarvitse kontrolloida sitä tapahtuuko kompressoidun datan purku CPU:lla vai GPU:lla vaan DS valitsee pellin alla parhaan mahdollisen tavan ja yrittää suorittaa pyynnöt jonoista tehokkaasti, lopputuloksena kuitenkin aina sama tilanne että vramissa on purettu tekstuuri tms huolimatta siitä kuka sen purki. Jos haluaa, niin sinne toki voi laittaa oman purkufunktion (koodiesimerkeissä sinne plugataan zlib) mutta DS tukee suoraan tiettyjä formaatteja jotka oletettavasti solahtaa sitten GPU:llekin.

Miten tämä istuu peliengineen on sitten täysin erillinen asia eikä liity tähän rajapintaan tai itse purkuun juurikaan.
 
Ei tämä kyllä ole ristiriidassa yksinkertaistetun esimerkin kanssa jonka annoin.

DS (kuten tosiaan Vulkan sen verran kun siitä itse ymmärrän) toimii jonojen kautta, joihin submitataan (mielellään mahdollisimman paljon) pyyntöjä jotka kertoo mistä ja mitä ladataan (tiedosto/keskusmuisti) sekä minne ladataan (keskusmuisti/videomuisti).

Applikaation ei tarvitse kontrolloida sitä tapahtuuko kompressoidun datan purku CPU:lla vai GPU:lla vaan DS valitsee pellin alla parhaan mahdollisen tavan ja yrittää suorittaa pyynnöt jonoista tehokkaasti, lopputuloksena kuitenkin aina sama tilanne että vramissa on purettu tekstuuri tms huolimatta siitä kuka sen purki. Jos haluaa, niin sinne toki voi laittaa oman purkufunktion (koodiesimerkeissä sinne plugataan zlib) mutta DS tukee suoraan tiettyjä formaatteja jotka oletettavasti solahtaa sitten GPU:llekin.

Miten tämä istuu peliengineen on sitten täysin erillinen asia eikä liity tähän rajapintaan tai itse purkuun juurikaan.
Juu okei, ehkä sain vain semmoisen kuvan että DS olisi joku korkealentoinen API jossa yhdellä simppelillä komennolla tapahtuu sitä sun tätä.

Tosin ei taida tuo datan purkukaan olla automaattinen vaan se jono (custom decompression queue) ilmeisesti rakennetaan itse nuuskimalla ensin supportti liput mitä rauta antaa myöten ja sen jälkeen rakennetaan asianmukainen purkujono jolle syötetään dataa lukujonosta.

Eli se kuva mikä itselle alkaa tästä DS:stä hahmottua on se että uuden paradigman hedelmät kerätään tuossa viiden vuoden aikajänteellä jolloin enginet ovat kunnolla optimoitu tätä varten. Mahtaako GPU purku olla vielä sittenkään saatavilla... mene ja tiedä.
 
Integroitu näytönohjain on kiva lisä, niin saa esim. kakkosnäytöllä olevan selaimen videopurun ja renderöinnin pyörimään sen kautta.

Nykyisin videonkatselu tökkii, jos ykkösnäytöllä oleva peli vie kaiken tehon erillisnäytönohjaimelta.
En itse ole törmännyt siihen että videot tökkisi, vaan siihen että jotkut pelit stutteroivat jos video pyörii taustalla toisella näytöllä. Tuo kuitenkin korjaantuu, kun kytkee toisen näytön integroituun näyttikseen.
 
Oliko nyt näin, että tämänhetkisen tiedon valossa kaikki AM5-kannan Ryzenit sisältäisivät iGPU:n? Vai onkohan tulossa "Föönimalleja" á la Intel siihen kaveriksi.
 
Oliko nyt näin, että tämänhetkisen tiedon valossa kaikki AM5-kannan Ryzenit sisältäisivät iGPU:n? Vai onkohan tulossa "Föönimalleja" á la Intel siihen kaveriksi.
Kyllä, tämän hetkisten tietojen mukaan tulee olemaan kaikissa. Työpöytäprosessoriessa se on osa IO-sirua.
 

Statistiikka

Viestiketjuista
258 669
Viestejä
4 495 554
Jäsenet
74 270
Uusin jäsen
Jautio

Hinta.fi

Back
Ylös Bottom