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.
AMD's Robert Hallock on the 5.5 GHz Demo in @PCWorld stream:
▶ AMD Reference Mobo
▶ 280mm AIO cooler
▶ 16 core prototype from April
▶ Plugged in, no OC
Natural freq of that CPU
▶ Most threads around 5.5, depends on scene/game
▶ 5.2-5.5 on all threads was common on the game— 𝐷𝑟. 𝐼𝑎𝑛 𝐶𝑢𝑡𝑟𝑒𝑠𝑠 (@IanCutress) May 24, 2022
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.
data-unfurl="true" data-result-id="324973" data-url="https://wccftech.com/amd-ryzen-7000-desktop-cpus-am5-platform-detailed-robert-hallock-frank-azord-5-5-ghz-stock-clocks-170w-power-rdna-2-igpu-more/" data-host="wccftech.com" data-pending="false">
class="link link--external fauxBlockLink-blockLink"
target="_blank"
rel="nofollow noopener"
data-proxy-href="">
AMD's Robert Hallock & Frank Azor Talk AMD Ryzen 7000 CPUs & AM5 Platform Features: 170W Socket Power Limits, 5.5 GHz Stock Clock Speeds, Smart Access Storage & More
data-onerror="hide-parent"/>
wccftech.com
katso liitettä 866426
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
Kelloa lisää, kakkua lisää, watteja lisää. Toivon mukaan sekaan lipsahtaa jotain hiukan nokkelampaakin parannusta.
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.
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.
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ä normijampalla on viisaudenhampaan poistaminen. Useaman kerran kun pcworldin heput tenttasivat asiasta niin 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.
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.
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ä.
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.
Kyllä, tämän hetkisten tietojen mukaan tulee olemaan kaikissa. Työpöytäprosessoriessa se on osa IO-sirua.
Kommentoi uutista tai artikkelia foorumilla (Kommentointi sivuston puolella toistakseksi pois käytöstä)
Lähetä palautetta / raportoi kirjoitusvirheestä