Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz adamssss #3 üzenetére

    [link] - itt van.

    Jelenlegi verzióval támogatott hardverek: [link] - ezt a listát kell majd nézni, mert hardverből mindegyik jó, csak lesz-e hozzá driver.

    (#6) DraXoN: Semmi köze ehhez. A HSA az nem egy technológia, hanem egy specifikáció, illetve egy alapítvány, ami szabványt alkot. Ehhez vannak implementációk a gyártóknál. Az AMD-nél ez a ROCm. Elérhető itt: [link]

    Windows-ra nem lesz, mert oda ott a WDDM 2.x. Nagyrészt ugyanazt kínálja. Minek oda még egy alternatíva?

    [ 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 arn #9 üzenetére

    Persze. Minek rajta változtatni? Egyáltalán nem limitál jelenleg. Majd a Zen2-ben, amikor változik maga a mag is. Ott picit gyorsabb lesz a belső összeköttetés.

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

  • Abu85

    HÁZIGAZDA

    válasz Blindmouse #11 üzenetére

    De olvastam. Viszont egyrészt ez márciusi elemzés, ami azért gond, mert a késleltetést az AGESA 1.0.0.4-es verziója optimalizálta, ami áprilisban jött. Tehát minden mérés, ami korábban volt kidobható, mert már van új BIOS, ami ezen nagyon sokat dob.
    Semmi köze a CCX-nek a nyolcmagos eredményekhez. Ezt onnan lehet tudni, hogy az új BIOS-okban behozták a gyártók azt a lehetőséget, hogy manuálisan konfigurálhatod a nyolcmagos lapkákat. Megcsinálhatod, hogy a modulon belüli négy magot tiltod le, vagy két-két magot a két modulon. Az eredmény ugyanúgy négymagos, és az a helyzet, hogy a teljesítmény mindkét opcióval ugyanaz, tehát nem korlátozó a busz. Egyszerűen a kiadáskori AGESA kód megtréfált mindenkit. Ezt egyébként több gyártó elismert, hogy valóban a kiadáskori BIOS-okkal tényleg lehetett olyan következtetéseket levonni, hogy az összeköttetésekkel van gond, mert az AGESA kód nem volt maximális teljesítményre optimalizálva. Nem készült el a startra ez a verzió. Ezért teszteljük mi is újra az egészet. Bár minket ez annyira nem érint, mert a tesztcsomagunkban nincs igazán késleltetésre érzékeny alkalmazás.

    A játékok alatt a gond specifikus. Egyrészt egy motort specifikusan is optimalizálnak egy architektúrára, tehát amíg az Intelnek már volt megjelenéskor assembly szintű optimalizálása, addig a Zenhez csak áprilisban kezdett el jönni, másrészt az AMD régi inicializáló kódja a játékokat nyolc szálig engedte skálázni, de a Ryzenhez 16 szál kell, így ezt is frissíteni kell a programkódokban. Pár régebbi program kapott javítást (plusz van új energiagazdálkodási séma), illetve az új játékoknál már figyelnek erre, így mindegyik április második fele óta kiadott játék tartalmaz Zen optimalizálást, és az AMD kódja is 16 szálig engedi a skálázást. Ennek pedig látható az eredménye [link] , [link] , [link] - itt látható az is, hogy egy ilyen optimalizálás mit jelent direkt gyorsulásban

    [ 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 Jack@l #29 üzenetére

    Nem kijavítják. Kijavították már! Április közepe óta minden alaplaphoz elérhető az AGESA 1.0.0.4-es BIOS.

    (#33) Resike: A legnagyobb modell teljesítménye az i7-6900K és az i7-6950X között van továbbra is. Csak az AGESA 1.0.0.4-es BIOS csökkentette a késleltetést, így a késleltetésre érzékeny tesztekben már jobban teljesít a hardver a startkor elvégzett mérésekhez képest.

    (#32) hapakj: Olyan lett, amilyennek ígérték. A gondot az jelenti, hogy senki sem számított rá, hogy ennyire gyors lesz.

    [ 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 mzso #37 üzenetére

    Nem. A HSA egy alapítvány lett, ami egy specifikációt épít az egyes tagoknak. A tagok erre terveznek egy implementációt, ami a specifikáció szerint írt kódot futtatja. Mivel ezek az implementációk készek, így mostantól a gyártók a HSA helyett az implementációkról beszélnek. Az AMD esetében ez a ROCm. [link] , [link] - ez a HSA-ra épül, pontosabban annak egy HSA+ verziójára, mert a HSA nem teszi lehetővé a dedikált GPU-k támogatását, de a HSA+ kiegészíti úgy a rendszert, hogy ez is megoldható legyen. Mostantól az AMD-nél az egyes hardverek nem HSA-t támogatnak, hanem ROCm platformot, ami magába foglalja a HSA-t és a HSA+-t is.

    [ 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 Abu85 #51 üzenetére

    Ehhez még annyit, hogy a HSA mellett az egész problémára léteznek alternatív stackek. Például a Windows esetében a WDDM 2.x nagyjából tudja a legfontosabb direktíváit a HSA-nak, tehát itt a HSA-ra igazából nincs szükség, mert a Microsoft saját megoldást kínál a problémára. Erre építenek is egy új IR-t, ami már ki is próbálható. Ez a DXIL, és ez ráadásul openszósz, meg a Clang/LLVM keretrendszerre épül, tehát rendkívül egyszerűen kiegészíthető. Hasonló ez a SPIR-V-hez, egy kiegészíthető IR, amire kezdésnek van egy alapszintű shader nyelvre vonatkozó támogatás, de az ökoszisztéma miatt ez kiegészíthető akármilyen magas szintű nyelvre.

    De ott van még a SYCL is, ami egy teljesen szabványos alternatíva a gyártói implementációk helyett.

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #50 üzenetére

    A régi programok nem lesznek frissítve. Az újak már az új kódot kapnak a CPU magok detektálására az AMD-től, ami nem csak nyolc szálig enged skálázni, mint a korábbi. Ezt pár meglévő programba visszapatchelték, plusz megkapta az általános assembly optimalizálásokat is.
    Minden új architektúra ezzel fog küzdeni az elején, mert az assembly optimalizálások újra terjednek PC-n. A régi programok nem ismerték az architektúrát, így nem lehetett rá optimalizálni. Az újak már ismerik. Ez az AMD-nél az április közepe utáni programokat jelenti, mert április elejétől szállítanak Ryzenhez való detektáló kódokat a fejlesztőknek. Emiatt van az, hogy DoW 3-ban és a Sniper GW 3-ban már az élen van a Ryzen 7 1800X. Egyszerűen az új, áprilisi frissített detektáló kóddal nem csak az fizikailag beépített erőforrások felét tudja használni.
    Ezt egyébként bárki megteheti különösebb bejelentés nélkül is, mert a kód elérhető. Tehát elképzelhető, hogy hirtelen más lesz az egyes programokban az eddigiekhez képest a Ryzen teljesítménye 1080p-ben, mert beépítették az AMD új detektáló kódját, így nem csak a proci fele van használva.

    [ 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 Resike #58 üzenetére

    A Microsoft nem kötelez rá senkit, hogy a saját rendszereit használja. A legtöbb motor például inkább alternatív ütemezésre épít, mert hatékonyabban tudják vele kezelni a rendszert. Az alternatív megoldás két részből áll. Egyrészt a procigyártók biztosítanak a detektáláshoz egy kódot, amit minden fejlesztő elérhet, és ezt egyszerűen csak be kell másolni. Másrészt az adott program az így detektált erőforrásokhoz hozzárendeli az alkalmazás egyes rendszereit. Nem minden játék működik így, de nagyon nagy részük igen. Ebben a rendszerben az a lényeg, hogy a procigyártó által biztosított detektáló kód detektálja is az erőforrásokat. Mondjuk a Ryzen esetében a 16 szálat. Ami már megvalósul, de a régi kód csak nyolc szálig detektált.

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

  • Abu85

    HÁZIGAZDA

    válasz Resike #61 üzenetére

    Ez a kód mondja meg a programnak, hogy az adott CPUID-hez mennyi erőforrás tartozik, vagy ha ismeretlen a CPUID, akkor mit tegyen. Jegyzi azt is, hogy maximum hány erőforrás lehet használatban. Értsd hány mag. A Grid 2-ben ez volt a gond a tesztben, mert az egyik fejlesztő visszaírta, hogy hiába 16 szálas a proci, max négyet enged meg belőle kihasználni az AMD-től kapott detektálómodul.
    Maga a probléma eléggé bonyolult, ha önálló ütemezést használ egy program. Számos megoldás van, de mégis a legtöbben a gyártói CPUID detektálást alkalmazzák. Vannak olyan cégek egyébként akik írtak saját detektálási rendszert. Lásd Crytek, Frostbite Team, stb. A járható utak száma sok, csak az a kérdés, hogy mennyi pénzt és időt lehet szánni az adott rendszerre való validálásra.

    A Ryzen teljesítménye most azért változott meg, mert az AMD kirakott egy rakás fejlesztői kódot, amiket többen visszaírtak egy patch formájában. Így például a DOTA 2 már nem csak négy magot használ a nyolcból, vagy az AotS-ben bejöttek az assembly optimalizálások, amiket a többi proci már megkapott, de a Ryzenhez is igazítani kellett ezeket. Ezekkel jönnek most a 20-30%-os pluszok, amik a megjelenéskor hiányoztak. Pár új játék alapból ezekkel az optimalizálásokkal jött (mostantól nyilván ez lesz a trend, mert tesztelhető/validálható a hardver), lásd Sniper GW3, DoW3, és ezekben teljesen más teljesítményt mutat a Ryzen 7 1800X. Befoghatók a benne lévő erőforrások.

    [ 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 Resike #69 üzenetére

    Aki munkára veszi annak már most jó, ugyanis ezekben az alkalmazásokban nem jellemző, hogy a fejlesztők saját szálmenedzsmentet írnak. Jó a Windows beépített menedzsmentje is. Emiatt nagyon sok workstation esetében már inkább Ryzent vesznek, mert 500 dollárért gyorsabb az 1000 dolláros nyolcmagos Intelnél.

    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