Keresés

Új hozzászólás Aktív témák

  • Abu85

    HÁZIGAZDA

    válasz b. #7 üzenetére

    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.

  • Abu85

    HÁZIGAZDA

    válasz b. #9 üzenetére

    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.

  • Abu85

    HÁZIGAZDA

    válasz b. #20 üzenetére

    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.

  • Abu85

    HÁZIGAZDA

    válasz b. #23 üzenetére

    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. :D

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Busterftw #28 üzenetére

    Pedig teljesen igaza van abban, hogy ebbe a dologba nem kell a HPC-nél többet belelátni. Senki sem fog végfelhasználói szintre olyan programot kiadni, amit per GPU alapon le kell implementálni. Egyszerűen nincs meg az a réteg, amely kifizeti a program fejlesztési költségeit. Szerverszinten van értelme, mert ott ráírod a szoftverre, hogy tízezer dollár per év a support, és viszlát, meg is van a pénzed. Na most pusztán szerinted, hány játékos van, akik tízezer dollárt fizetnének évente, hogy játsszanak egy játékon? Na emiatt nem kerülhetők meg itt az API-k.

    [ Szerkesztve ]

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

Új hozzászólás Aktív témák