Phison esitteli yli 12 Gt/s lukunopeuksiin yltävää PCIe 5.0 NVMe SSD-asemaa

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
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

Linkki alkuperäiseen juttuun

 

[Zacksa]

Kuinka paljon tämä asema kärsii nopeudessa jos emolta löytyy vain pcie 4.0?

 

[Hannibal]

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ä.

 

[AeshmA]

Kuinka paljon tämä asema kärsii nopeudessa jos emolta löytyy vain pcie 4.0?

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.

 

[Sepander]

Tässähän vois sitten suoraan hypätä pcie3->5 ssdeehen seuraavassa päivitysrumbassa

 

[Härkönen]

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 väylöjä ei ole ollut enää aikoihin käytössä. Ne on pcie.

 

[Marti77]

Varman vaatii jo kunnon jäähyn.

 

[kurkimies]

Jokos ne ovat saaneet pienten tiedostojen kirjoituksen ja luvun nostettua myös sinne +10 Gt/s nopeuksiin?

 

[jessus]

Jokos ne ovat saaneet pienten tiedostojen kirjoituksen ja luvun nostettua myös sinne +10 Gt/s nopeuksiin?

niinpä, eli käytännön suorituskyky ei kasva samassa suhteessa kun väylä nopeutuu, mutta odotan innolla testejä.

 

[Kaotik]

Varman vaatii jo kunnon jäähyn.

Nuo lukemat on saatu ilman mitään jäähyä eikä se studiokaan varmaan pakkasella ollut

 

[PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼]

Jokos ne ovat saaneet pienten tiedostojen kirjoituksen ja luvun nostettua myös sinne +10 Gt/s nopeuksiin?

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.

 

[kurkimies]

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.

 

[finWeazel]

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.

Olis mielenkiintoista nähdä millaisia lukemia direct storagella saisi tuollaisessa testissä. CPU overhead perinteisellä yksittäisiä lukuja tekevällä apilla lienee merkittävä tekijä hidastaen menoa. Toki ei DS ihmeitä tee, mutta tyyliin jos pyynnöt kasataan vaikka 256*4kB hakua läjiin yksittäisten 4kb palasten lukemisen sijaan niin cpu tekisi oleellisesti vähemmän työtä.

edit. tulee kyllä mieleen sekin, että vaikka DirectStorage olisi täydellinen niin kuinka paljon ssd;n firmwarella on merkitystä? luulisi, että DS vaatii omanlaisensa optimoinnit ssd:n ohjaimeen, että saadaan maksimaalinen suorituskyky irti. Jännä nähdä mitä löytyy kun DS saadaan kunnolla käyttöön peleissä ja aletaan mittaamaan eri ssd-levyjen todellista suorituskykyä DS pelikuormilla.

 

[PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼]

Olis mielenkiintoista nähdä millaisia lukemia direct storagella saisi tuollaisessa testissä. CPU overhead perinteisellä yksittäisiä lukuja tekevällä apilla lienee merkittävä tekijä hidastaen menoa. Toki ei DS ihmeitä tee, mutta tyyliin jos pyynnöt kasataan vaikka 256*4kB hakua läjiin yksittäisten 4kb palasten lukemisen sijaan niin cpu tekisi oleellisesti vähemmän työtä.

edit. tulee kyllä mieleen sekin, että vaikka DirectStorage olisi täydellinen niin kuinka paljon ssd;n firmwarella on merkitystä? luulisi, että DS vaatii omanlaisensa optimoinnit ssd:n ohjaimeen, että saadaan maksimaalinen suorituskyky irti. Jännä nähdä mitä löytyy kun DS saadaan kunnolla käyttöön peleissä ja aletaan mittaamaan eri ssd-levyjen todellista suorituskykyä DS pelikuormilla.

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.

 

[finWeazel]

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 tilanteessa 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. Striimaustapauksessa,jos 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?

ps5:ssa ssd luku+purku taisi olla optimoitu jollekin 256kB tai 512kB palasille. Tuo lienee sen takia, että kovin pienillä palasilla ei saada hyvää pakkaussuhdetta.

 

[Hannibal]

Pci väylöjä ei ole ollut enää aikoihin käytössä. Ne on pcie.

Wanha

 

[kurkimies]

Pci väylöjä ei ole ollut enää aikoihin käytössä. Ne on pcie.

Jeps, vielä osassa Z97-emoja löytyy

 

[PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼]

Mietin tilannetta missä peli on täysin striimaava. Tällaisessa tilanteessa tulee paljon pieniä lukuja, jotka vaikuttavat levyn kannalta satunnaisilta.

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.

• Random reads: Big no!
• Sequential reads: YES!

 

[hkultala]

Ihan EVVK paljonko sitä teoreettista kaistaa on, kun NAND-flashillä oikea pullonkaula on kuitenkin kaikessa normaalikäytössä hakuajoissa.

Oikeasti supernopea levy vaatisi jotain muuta, hakuajoiltaan selvästi nopeampaa tekniikkaa kuin NAND-flash.

 

[finWeazel]

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.

• Random reads: Big no!
• Sequential reads: YES!

Ei sitä oikeastaan voida suunnitella geometrian ja tekstuurien osalta noin muuten kuin piperun peleissä tai jos koko kenttä on ladattu kerralla muistiin. Esimerkiksi ue5:ssa jos menet tyyliin 1cm päähän 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 10x10 pikseliä kokoinen niin muistissa on vain erittäin matala mip level tekstuureista ja matala lod taso geometrialle. Nenägeometriaa 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 pelimoottori saa tietää mitä alipalasia tekstuurista engine yritti käyttää, jotka eivät olleet muistissa. Sampler feedback:in avulla voidaan ladata juuri ne alipalaset tekstuurin oikeasta mip levelistä joita tarvitaan. Ei ole mitään tarvetta ladata koko tekstuuria/mip tasoa muistiin, jos framen piirtämiseen tarvitaan vain pieniä osia tekstuurista. Toki sampler feedback.in kaveriksi kannattaa 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

 

[PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼]

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äähän 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 10x10 pikseliä kokoinen niin muistissa on vain erittäin matala mip level tekstuureista ja matala lod taso geometrialle. Nenägeometriaa 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 pelimoottori saa tietää mitä alipalasia tekstuurista engine yritti käyttää, jotka eivät olleet muistissa. Sampler feedback:in avulla voidaan ladata juuri ne alipalaset tekstuurin oikeasta mip levelistä joita tarvitaan. Ei ole mitään tarvetta ladata koko tekstuuria/mip tasoa muistiin, jos framen piirtämiseen tarvitaan vain pieniä osia tekstuurista. Toki sampler feedback.in kaveriksi kannattaa 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.

 

[finWeazel]

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.

 

[Griffin]

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.

Ei mikään IO ole koskaan liian nopea.

Myös PCIe5:n nopeutta voidaan hyödyntaa vallan hyvin ja siitä on paljonkin hyötyä.