Phison nousi viimeistään PCIe 4.0 SSD-asemien myötä kaikkien alaa seuraavien huulille suositun ohjainpiirinsä myötä. Nyt yhtiö on esitellyt käytännössä tulevaa PCIe 5.0 -väylää tukevaa SSD-ohjaintaan.
Phison on esitellyt PCI Express 5.0 -standardia tukevaa PS5026-E26-ohjaintaan prototyyppi-SSD:llä, joka oli varustettu tuntemattoman kokoisella DRAM-välimuistilla ja teratavulla Micronin TLC 3D NAND -Flash-piirejä. Suositun CrystalDiskMarkin testissä prototyyppi-SSD ylsi peräti 12 457 Mt/s perättäisluku- ja 10 023 Mt/s -kirjoitusnopeuteen. Satunnaislukuoperaatioissa SSD ylsi 1,31 miljoonaan IOPSiin ja kirjoituksessa 1,16 miljoonaan IOPSiin.
Tom’s Hardwaren mukaan itse ohjainpiiri sisältää Armin suunnittelemia Cortex-R5-ytimiä sekä Phisonin omia CoXProcessor 2.0 -perheen kiihdyttimiä. Ohjaimen kerrotaan tukevan kaikkia moderneja ja lähitulevaisuudessa julkaistavia 3D NAND Flash-muisteja.
PCI Express 5.0 SSD-asemien odotetaan saapuvan markkinoille kuluvan vuoden aikana. Tällä hetkellä standardia tukevat vain Intelin Alder Lake -työpöytäprosessorit ja nekin ovat pyhittäneet 16 PCIe 5.0 -linjaansa oletuksena näytönohjaimelle. AMD on jo varmistanut tulevien B650, X670 ja X670E AM5-emolevyjen tukevan PCIe 5.0 -standardia aina vähintään yhdelle M.2-liittimelle ja prosessoreissa on tuki yhteensä 28 PCIe 5.0 -linjalle, joista neljä on varattu piirisarjayhteydelle.
Lähde: Tom’s Hardware
Kuinka paljon tämä asema kärsii nopeudessa jos emolta löytyy vain pcie 4.0?
Nopeimmat pci 4.0 asemat on siellä 8000 MT hujakoilla, eli sinne se tipahtaa.
Mielenkiintoisempaa olisi tietää, mitä todellinen nopeus on PCI5.0 väylässä.
Mutta jos käytössä ei ole PCI 5.0 väylää, niin nopeus tippuu siihen mitä väylä sallii, eli noin 7500-8000 pci 4.0 ja jokunen 3500 Mt pci 3.0 väylässä.
PCI-E 4.0 x4 teoreettinen maksimi jää hieman vajaaseen 8Gt/s, joten hyödyntämättä jää ~4,5Gt/s tuosta testatusta lukunopeudesta ja ~2Gt/s kirjoitusnopeudesta.
Pci väylöjä ei ole ollut enää aikoihin käytössä. Ne on pcie.
Varman vaatii jo kunnon jäähyn.
niinpä, eli käytännön suorituskyky ei kasva samassa suhteessa kun väylä nopeutuu, mutta odotan innolla testejä.
Nuo lukemat on saatu ilman mitään jäähyä eikä se studiokaan varmaan pakkasella ollut
Ei ole tapahtumassa. Ja ne jotka tuommoista työkuormaa tarvitsee niin niille on käsittääkseni Intelin optane tarjolla enterprise tasolla edelleen.
60MB/s näyttää olevan uudella phisonin protolla 4k random read testi.
Joskus kokeilin DDR3:sella tehdä aseman, niin pienten tiedostojen lukunopeus oli aivan eri luokassa kuin noilla.
Olis mielenkiintoista nähdä millaisia lukemia direct storagella saisi tuollaisessa testissä. CPU overhead perinteisellä apilla lienee merkittävä ja hidastaa menoa. Toki ei DS ihmeitä tee, mutta tyyliin jos pyynnöt kasataan vaikka 256 haun läjiin yksittäisten 4kb palasten lukemisen sijaan niin cpu tekisi oleellisesti vähemmän työtä.
Siis crystal diskmark testaa jo synteettistä maksimi throughputtia eri skenaarioissa eikä tietääkseni ole prossu rajoitteinen. Nuo on ne lukemat johon voidaan kuvitella pääsevän jos optimoit I/O kerroksen pelistäsi/softastasi täydellisesti. Jos esim pelin data on tallennettu täysin sattumanvaraisesti levylle ja luet yhdellä threadilla directstoragen läpi sitä niin todennäköisesti kaista on luokkaa 60MB/s koska se on se maksimi mitä tuommoisella typeryydellä saa läpi.
I/O on paljon muutakin kuin yhden APIn käyttämistä. Optimi tilanteessa data on aina luettavissa sequential muodossa ja se on aina pakattu ja se luetaan sitten yhdellä kutsulla sitä maksimi kaistaa 12GB/s ja puretaan jolloin realisoitunut bittivirta on jollain kertoimella >1x.
Mietin tilannetta missä peli on täysin striimaava. Tällaisessa tilanteess tulee paljon pieniä lukuja, jotka vaikuttavat levyn kannalta satunnaisilta. Tilanne on toki erilainen, jos peli lataa koko kentän kerralla muistiin eikä striimaile tarpeen mukaan. Striimauystapauksessa jos niitä pyyntöjä tehdään yksi kerrallaan eikä kasoittain niin cpu huutaa hoosiannaa. Toinen juttu on polku mitä pitkin data liikkuu. Onko ei DS rajapinnoissa ylimääräisiä datan kopiointeja/kuittauksia esimerkiksi ajuri/kernelistä user spaceen?
ps5ssa ssd luku+purku taisi olla optimotu jollekin 256kB tai 512kB palasille. Tuo lienee sen takia, että kovin pienillä palasilla ei saada hyvää pakkaussuhdetta.
Wanha
Jeps, vielä osassa Z97-emoja löytyy
Lähtökohtaisesti se pelin data suunnitellaan niin että se ei vaikuta satunnaiselta vaikka niitä assetteja striimataankin. Se on huonoa pelidesignia että pelidata on pirstoutunut jolloin streamaus on hidasta, koska nämä levyt eivät toimi optimaalisesti satunnaisella lukemisella ei vaikka mitä firmware kikkoja tehdään. Eli pelidata pyritään rakentamaan niin, että kun sitä striimataan niin sitä streamataan mahdollisimman sequentiaalisesti.
DirectStorage ei ratkaise fyysisiä raudan rajoitteita eikä huonoa file I/O designia pelienginessä. Se mahdollistaa toki paremmin nykyaikaiset streamaavat file I/O paradigmat, mutta pelienginen arkkitehtien homma on laittaa se homma lentämään niissä puitteissa mitä rauta antaa myöden.
Oikeasti supernopea levy vaatisi jotain muuta, hakuajoiltaan selvästi nopeampaa tekniikkaa kuin NAND-flash.
Ei sitä oikeastaan voida suunnitella geometrian ja tekstuurien osalta noin muuten kuin piperun peleissä tai jos koko kenttä on ladattu keralla muistiin. Esimerkiksi ue5:ssa jos menet tyyliin 1cm päästä patsaasta ja patsaan nenä täyttää koko ruudun niin ladataan 8k tekstuurit ja source level assetit nenälle. Jos katsot samaa patsasta 50m päästä patsaan olessa 10×10 pikseliä kokoinen niin muistissa on vain erittäin matala mip level tekstuureista ja matala lod taso geometrialle. Nenää ei välttämättä edes ole enää tässä geometriassa olemassa kiitos dynaamisen lod:in ja patsaan pienuuden ruudulla. UE5 siirtää haasteen massamuistin koko ongelmaksi, koska lennosta voidaan striimata juuri ne assetit ja lod/mip tasot mitä tarvitaan.
Yhdessä äärimäisessä päässä on sampler feedback. Sen avulla engine saa tietää mitä alipalasia tekstuurista engine yritti käyttää, jotka eivät olleet muistissa. Sampler feedback:in avulla voidaan ladata juuri ne palaset tekstuurin oikeasta mip levelistä joita tarvitaan. Ei ole mitään tarvetta ladata koko tekstuuria/korkeinta mip leveliä muistiin, jos framen piirtämiseen tarvitaan vain pieniä osia tekstuurista. Toki sampler feedback.in kaveriksi kannattaa myös toteuttaa hyvää heuristiikkaa striimaamiseen eikä luottaa vain huteihin,… Parempi on, jos hutia ei edes tule ja data oli sekunnin ennen käyttöä muistissa.
https://www.intel.com/content/dam/develop/external/us/en/documents/pdf/july-gdc-2021-sampler-feedback-texture-space-shading-direct-storage.pdf
Juu kyllä me ollaan pääpiirteittään samaa mieltä. Ja ei tietenkään mitään voi suunnitella niin että joku SSD striimaa täydellisesti 12GB/s. Ei se ole edes realistista. Reaaliskenaariossa hyvin optimoidussa seuraavan sukupolven pelienginessä (sanotaan sitä vaikka Unreal Engine 6:ksi) voitaisi kuvitella että pelidataa striimataan optimaalisesti esim 400MB/s että kameralla on koko ajan lisää assettia eri leveleillä renderöitävänä kun pelissä liikutaan. Kovolta tulisi sitä tarkempaa gigamiljoona polygonista patsasta kun sitä lähestytään tai jotain muuta vastaavaa.
Nythän UE5:ssa niissä muutamassa super-high-res-assets demossa eli Valley of Jotain ja Matrix demo, puhutaan alle 100MB/s striimausnopeudesta vaikka assetteina on ihan törkeän tarkkaa palikkaa. Tämä siis UE5:n kehittäjiltä tietona.
Mitä tulee näihin PCIx gen5 nopeuksiin niin sanoisin että täysin turhaa vielä vuosikausia.
Joo. Ollaan samaa mieltä isoista linjoista. Toki ketjuun linkattu 4kB benchmark on aika äärimmäinen esimerkki, kun ainakin mun muistin mukaan ps5 käyttää 256kB/512kB palasia levyä lukiessaan. 4kB lienee sellainen patologinen tapaus mitä pelienginessä nähdään harvemmin. Lienee pc:llakin DS pelit tulevat käyttämään jotain pakkauksen tiiviyden, purkunopeuden ja satunnaisen haun kompromissia. Ehkä sama palaskoko löytyy pc.sta kuin ps5:sta?
UE5 käyttää keskusmuistia cachena. Jos source level assetti on pieni ja keskusmuisti suuri niin IO voi vähentyä oleellisesti kiitos cachen. Tietenkin pelien tapauksissa kaikki kovin pienet assetit kannattaa cachettaa muistissa. Tyyliin ps4:lla spiderman pitää kaikki pienet assetit kuten postilaatikot aina muistissa että saadaan pieniä satunnaisia hakuja poistettua.
ue5:en tapauksessa riippuu ihan source asseteista ja resoluutiosta kuinka paljon tarvii striimata. 1 kolmio per pikseli. 4k versus 1080p niin on 4x ero tarvittavan datan(geometria, tekstuurit) määrässä. Tähän mennessä ue5 demot on olleet pieniä fyysiseltä kooltansa(muutamia kymmeniä gigoja). UE5:lla vois tehdä vaikka autopelin missä on lidar-skanneista ratageometria. Yksi rata voisi olla teratavujen kokoinen. Pelatessa rouskutetaan levyltä dataa ennakoivasti muistiin sitä mukaa kun auto kiertää radalla.
Ei mikään IO ole koskaan liian nopea.
Myös PCIe5:n nopeutta voidaan hyödyntaa vallan hyvin ja siitä on paljonkin hyötyä.