Radeon Pro SSG is volt már, de senkit nem érdekelt. Ez lehet valamivel rugalmasabb konstrukció, de nem látom, hogy mindenki rohanna érte, max egy pár speciális projekt ahol megéri az extra macera a teljesítményt.

An open mind is like a fortress with its gates unbarred and unguarded.

Nekem is ez jutott eszembe errol, epp ket napja teszteltek Linusek, ha valakit erdekel.

ééés ugyanezt akartam írni, az AMD részéről szerintem kicsit idejekorai dobás volt, pedig abszolút van értelme.

az mondjuk egy másik kérdés hogy nagy rákfenéje volt hogy a NVMe SSD elérését tulajdonképpen nem maga a GPU végezte, csak közel volt hozzá. egy olyan megoldás aminél a GPU közvetlenül, lényegében a saját memóriavezérlőjének a kiegészítésével éri el a tárhelyet, na az nagyot dobna.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

bitblueduck, fatpingvin: Pont ezt akartam írni én is .
Annyi volt a különbség, persze, ha jól értem, hogy az AMD esetében egyfajta RAM-ként funkcionált az SSD az adott kártyán, valahol itt is ez a helyzet.

A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...

nem egészen. az AMD megoldásában pont hogy csak nonvolatile cache volt a fő funkciója. amit én írtam az pont az, (amit amúgy pl a Linux kernel egy experimental featureként tud, mondjuk a host CPUról) hogy kokrétan memóriaként térképezi, nyilván lassabb lesz de ha jól emlékszem volt anno valami ilyen megoldás vmi nvidia kártyán hogy heterogén ramot használt...

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Aha! Akkor, Te már tájékozottabb vagy, köszi .

A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...

Elméletileg bármilyen területen fel lehet majd használni, játékokban is akár.
Igazából képes lehet arra amire a Directstorage csak Microsoft API támogatás nélkül is.
Szerintem nem véletlenül lesz hatalmas L2 az új Ada kártyákban. lehetséges L3 nak egy 1 Terrás SSD?

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Ezt biztosan nem jó máshova. A végfelhasználókhoz ilyen megoldásokat sose fognak levinni, mert egy cellaírással bukható az összes tárolt adat az SSD-n, ha nem figyelnek oda. Szerverben erre azért tudnak ellenszert, mert az egész folyamat pontosan ismert, de egy usert megtanítani rá, hogy mit szabad és mit nem, az marhára nehéz. Emiatt olyan dolgokat ide be sem hoznak, aminél egy random user workload az összes adatot olvashatatlanná teheti az adattárolón. Végfelhasználói szintre "hülyebiztos" megoldások kellenek, amik akkor is megőrzik az adatok integritását, ha a user száz-kétszáz alkalmazással olvassa-írja ugyanazokat a területeket, vagy legalább visszajelzik a user felé, hogy ne basztasd azt az adatot, mert éppen valami másik program használja. A BaM esetében ilyen nincs. A CPU és a GPU el van vágva egymástól, így nem látnak rá egymás munkájára, tehát halvány fingjuk nincs arról, hogy esetlegesen egyszerre olvashatják és írhatják pont ugyanazt a cellát az SSD-n. Ez azért marhára nem jó dolog, ha nem ismered a hardver logikai működését, és ezáltal nem tudod, hogy pontosan mit tehetsz meg, és mit nem.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Perszelogikus nem ebben a formában, nem is ez a platform célja, ezért írtam a Dirtectstorage szerű megoldást,.API és direkt játéktámogatás nélkül.Dylan Patel is ezt jósolja Twitteren ,hogy képes lehet ebből profitálni majd egyszer egy olyan játék is ami nem D.S. támogatott ha nem is olyan mértékben mint ha direkt támogatást kap.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Ennek nincs másik formája. A BaM lényege, hogy a GPU a CPU teljes kizárásával is dolgozni tudjon, de ha kizárod a CPU-t, akkor manuálisan kell gondoskodnod arról, hogy a GPU munkájáról mit sem tudó CPU egyáltalán ne nyúljon azokhoz a cellákhoz az SSD-n, amelyekkel éppen dolgozik a GPU. Ezt nyilván egy szerveren, egy specifikált workloaddal nem nehéz megtenni, mert rendszergazdaként tudod, hogy mi az, amivel gond lehet, és egyszerűen nem adsz utasítást annak végrehajtására.

Ettől függetlenül nem véletlenül vannak API-k, mivel tök szar lenne minden hardverre külön implementációt írni, illetve nem véletlen, hogy még a DirectStorage sem zárja ki a CPU-t a munkából, csak offloadolja az egyes kitömörítési feladatokat a GPU-ra. De erről tökre tud a CPU, hogy a rendszernek legyen képe arról, hogy éppen mi történik a gyorsítón belül. Ha ezt meg lehetne oldani egyszerűbben, akkor a Microsoft is úgy oldaná meg.

Aminek van realitása az a konzoloknál való alkalmazhatóság, de valószínűleg nem nyersz annyit vele, hogy érdemes legyen vele vesződni, mert ott eleve fix a hardver, így a szinkronizálásra eleve tudnak optimalizálni a fejlesztők.

Én kb. nulla realitását látom, hogy mondjuk a Microsoft egy olyan funkciót vigyen be a Windows-ba, amivel a user figyelmeztetés nélkül tönkre tudja tenni az SSD-n tárolt adatokat. Az egyik elsődleges szabály a végfelhasználóknak szánt OS-eknél, hogy a user ne tudnak kihúzni maga alól a talajt. A BaM pedig pont egy olyan koncepció, ami ezt nagyon is lehetővé teszi, és ez nyilván a szerverben oké, mert az üzemeltető tudja, hogy mit csinál, de asztali szinten félelmetesen nagy kockázatokat hordoz.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Értem, Hát majd meglátjuk merre fejlesztik tovább. Egyelőre vannak más vélemények is.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Nem vitatkozásból: Ha erre tartasz egy dedikált meghajtót, amit csak a GPU ír olvas, azzal meg lehet óvni a user egyéb adatait és a konkurens terhelések kérdése is megoldódik.
Kérdés, hogy enduser szinten van-e ekkora szükség a cpu offload-ra.

ez nem CPU offload... ez konkrétan a hardveres megvalósítása annak, hogy a nagyméretű tárhelyet a GPU közvetlenül tudja kezelni, ne legyen arra szükség hogy a CPU a saját root komplexén keresztül eléri a SSD-t, lekéri az adatokat aztán átmásolja a vagy a GPU RAMjába vagy a megosztott memóriaterületre, hanem ezt az egész manővert a GPU a CPU bevonása nélkül el tudja végezni.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Átfogalmazom: Mivel desktop környezetben az 1 db gpu okozta i/o terhelés owerhead-je sejthetően nem teszi szűk keresztmetszetté a cpu-t vagy memória alrendszert, nem hinném hogy itt egyáltalán foglalkoznak az implementálásával. Ezt jobb kifogásnak gondolom, mint azt hogy a user adatai esetleg koruptálódhatnak ha nincs elég körültekintően kezelve az hogy a cpu is módosíthatja ugyanezeknek a cellák a tartalmát.
Mivel nincs bedugulás ami megszűnhetne miatta ezért az endjuzer szempontból ez a technológia maximum csak cpu terhelés csökintésre lenne alkalmas.

hogy kerül ide a desktop meg az endjúzer? ez baromira HPC történet...

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Ja de olvasd a #7.- től a hozzászólásokat és megérted hogy keveredett ide a desktop user esete..

látom és már ott baromság volt no offense.

végtelenül röhejesnek tartom hogy a fórum nagyrésze egyszerűen képtelen valamit NEM a videojátékok rózsaszín üvegén keresztül nézni.

persze, lehet róla fantáziálni hogy egyszer majd eljut odáig is hogy a játszódásban is megjelenik, de könyörgöm ne ez legyen már az eslő gondolat egy új koncepciós HPC designnál...

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Ne haragudj meg,de ostobasag ostobasagnak tartani az otletet.a legtobb szakmai cikk pl The verge vagy HPC Wire The Register s parhuzamba tette a geforce vonallal,sot maga az Nidia is kiter a Microsoft Direcstorage es a Radeon SSG parhuzamara es normal NVMe SSD vel való működését is tesztelték benne.Abunak abban igaza van hogy itt a mukodesben az A100 nal nem latja a CPU a GPU-t,de azt nem irjak hogy ne lehetne Linux alatt a BaM mukodeset a CPU szamara nyitotabba tenni egy erre deikalt SSD vel.Nyílt forraskódú eszkoz ,ezt jó eszbentartani.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

nm az öttletet tartom ostobaságnak hanem azt, hogy egy ilyen cikk kapcsán ami nyilvánvalóan még egy kísérleti stádiumban lévő HPC technológiát tárgyal, az első reakció: windóóóz? géééming? aztán ha valaki rávilágít hogy ez nem az a nóta akkor lényegében le van rázva hogy nem is érdekes.

ezzel az állandó mintával van egyedül fenntartásom, nem az egyes fórumozókkal és nem is azzal hogy valaki elgondolkozik a felhasználási területen.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Itt pont nem win,hanem linux ez lehetne jo benne API nelkul.En is ezt irtam az altalad kifogasolt kommentben.
Nagyon sok nvidia HPC fejlesztes kotott ki geforce vonalon.pl Nvlink,RT core,tensor core stb...
Szinte minden egyedi hardveres fejlesztes alapja ebbol a szegmensből indul.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Itt eleve az a gond, hogy API nélkül. Tehát minden egyes GPU-ra külön kell majd megírni az egészet. A PC-piacon van kb. 200 különálló specifikáció, amire így 200 implementáció is kell, és még nem is biztonságos a megoldás, mert a user kiránthatja maga alól a talajt, ha akarja, nincs semmi, ami megvédje az adatait.

És fontos, hogy bármi, amit kiadsz így, az nem lesz kompatibilis a fél év múlva érkező hardverekkel, és addig kell csinálni a patch-cselést, amíg érkezik új hardver a piacra, mert amint leállsz vele, már nem fog működni a program a későbbi GPU-kon.

Emiatt hülyeség, amikor azt írja egy média, hogy DirectStorage, meg géming, mert nagyon nem ugyanarról van szó.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Kiemelten,Microsoft directstorage API nelkul igy a helyes.Ettol Linuxon lehetne egysegesitett megkozelites.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Linuxon sem lehet. Az API arra kell, hogy a különböző hardverek kezelve legyenek. Mivel a GPU-k esetében nincs egységes ISA, így minden egyes új lapka teljesen más binárist igényelne Linuxon is.

Az egyetlen egységes megközelítése ennek egy alacsony szintű virtuális ISA lenne, akkor tényleg nem kellene sok dologra API, de azt a virtuális ISA-t muszáj lenne mindenkinek támogatnia. Az egyik ilyen megközelítés volt a HSA, de abból láthatod, hogy mára mi lett. Hiába épített rá több gyártó is saját környezetet, a szabványt elkezdték saját megoldásokkal kiegészíteni, így ma már ezek a környezetek a HSA ellenére sem kompatibilisek egymással. Tehát végeredményben adtunk a szarnak egy pofont, mert az egész csak arra volt jó, hogy egy alapvető fejlesztési hátteret megosszanak egymással a cégek. Még az AMD is, amely cég ezt az egészet kitalálta van saját HSA+ kiterjesztése, és emiatt a ROCm sem HSA megoldás már. Tehát egyszer ezt már kipróbáltuk, és nem nagyon értette meg a piac, hogy mi a cél.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.