2. Fórumok
  3. Videokártyák
  4. Saját Resizable BAR implementációval készül az Intel
Keresés

Hirdetés

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

  • #5 Abu85 HÁZIGAZDA Hellwhatever #3
    Új Válasz #5
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Hellwhatever #3 üzenetére

    A tesztek alapján az AMD oldalán úgy 7-17% extra teljesítmény sok játékra levetítve. Az NVIDIA oldalán átlag 3-7% a támogatott 17 játékra levetítve, míg a többiben nyilván nem működik, hiszen nincsenek benne a whitelistben.

    #4 Reggie0 : Ez a koherencia tekintetében nem jelent sokat. Itt arról van szó, hogy a VRAM-nak mekkora része úgynevezett host-visible típus. Korábban 256 MB volt ez a határ, ami abból a szempontból baj, hogy ezt már nem egy játék igen jelentősen túllépi, vagyis elég sok az adatcsere a host-visible területeket a VRAM és a rendszermemória között. Ezzel az újítással viszont erre nincs szükség, mivel az egész VRAM host-visible, vagyis az adatmásolás csak a CPU felé valósul meg, ami jóval ritkábban történik. Tipikusan azok a játékok tudnak belőle nagyot nyerni, amelyek jelentősen kicsúsznak a 256 MB-os határból (például Total War Saga: Troy, Assassin’s Creed: Valhalla, Call of Duty: Black Ops Cold War, Borderlands 3, Forza Horizon 4, stb., ezek jó 500 MB-nyi host-visible adattal dolgoznak). Működik is nagyon a Smart Access Memory, hiszen 15%-os extrát ad az említett játékokban.

    Valamennyire az NV implementációja is működik, de mivel se az Intel, se az AMD nem optimalizál rájuk a mikrokódban, így nyilván nem tudnak olyan hatékonyak lenni. Náluk még az is gond, hogy némelyik játékban lassulás lenne, és immáron fél éve győzködik az Intelt és az AMD-t, hogy ezt meg lehetne oldani pár módosíátssal, de látszólag mindkét cég leszarja a fejüket, így az NV is nehezen tud továbblépni innen. De ha megkapnák ugyanazt a támogatás, amit mondjuk az AMD biztosít a saját hardvereinek, akkor ők is tudnának 7-17%-nyi extrákat hozni.

    [ Szerkesztve ]

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

  • #7 Abu85 HÁZIGAZDA Reggie0 #6
    Új Válasz #7
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Reggie0 #6 üzenetére

    Ez nem arról szól, hogy szarul van implementálva, hanem arról, hogy mennyi adatot tesz a játék host-visible memóriatípusba. Korábban a 256 MB-ba fixen bele kellett férni. Ma már nem nagyon törődnek ezzel, mert egyrészt nem tudnak beleférni (10 éve még nyilván ment, de már 2021-et írunk), másrészt van megoldás a problémára.

    A probléma alapvetően az, hogy ha nem férsz bele a 256 MB-ba, akkor azt kell csinálni, hogy a rendszermemóriában kell allokálni egy akkora szeletet, amelybe belefér a szükséges adat. Mondjuk 500 MB-ot. Ez belekerül egy host-visible flages host-coherent memóriatípusba, amit a CPU tökéletesen tud kezelni, de a GPU-ba el kell juttatni. Ez rögtön nem olyan egyszerű, mert amit tárolsz adatot a rendszermemóriában, az nem kompatibilis a VRAM-on belüli, eszközlokális flages memóriatípussal. Tehát mielőtt másolod ezeket az adatokat a VRAM-ban, át is kell konvertálni, ami extra CPU-időt és memóriát igényel, és csak a maradék mehet a GPU-oldali 256 MB-ba, ami belefér. Tehát az adat mindenképpen ott lesz azoknál a játékoknál is a GPU memóriájában, amelyek nem férnek bele a 256 MB-os limitbe, csak szükség van hozzá egy rakás konvertálásra és adatmásolásra.

    Ha viszont a GPU teljes eszközlokális flages memóriatípusa egyben host-visible és host-coherent, akkor az egész munka teljesen felesleges, mert minden adat befér, így a PCI Express interfész is sokkal kevésbé van megterhelve, ahogy semmiféle adatkonverzió nem szükséges. Utóbbi viszont inkább csak elmélet, azok a cégek meg tudják így csinálni, amelyek egyszerre CPU-t és GPU-t is gyártanak, hiszen a mikrokód szintjén tudják módosítani a CPU működését, hogy az egyszerűen elfogadja a GPU-side adatokat. Ez az, ami az NV implementációjából hiányzik. A GeForce-ok más GPU oldali kódolással dolgoznak, mint a Radeonok, így ezeket nem kezeli direkten egy mikrokód, vagyis a meghajtónak kell egy konverziót elvégezni hozzá, ami sebességvesztést okoz, és ez tényleg nem egyszerű feladat. A megoldás az lenne, hogy az Intel és az AMD is kiadjon egy módosított mikrokódot, de ha eddig nem tették meg, akkor már nem fogják, egyszerűen nincs különösebb hasznuk belőle, ha az NVIDIA is 7-17%-okat gyorsul az új játékokban egy ReBAR implementációból.

    [ Szerkesztve ]

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

  • #9 Abu85 HÁZIGAZDA Reggie0 #8
    Új Válasz #9
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Reggie0 #8 üzenetére

    Az okoz gyorsulást, hogy ma már 2021-et írunk, és baromira kevés a 256 MB-os limit. Egyszerűen a játékok bonyolultabbak, mint tíz éve. Vannak még olyan cégek, amelyek elavult motort használnak, de nem ez a jellemző. És ha megnézed mondjuk az új motorokat, például az Unreal Engine 5-öt, akkor ott már nagyon-nagyon szűkös a 256 MB.

    A konverzió elkerülése csak egy implementációs tényező. Az elsődleges gond a 256 MB-os kapacitás szűkössége. A másodlagos az, ha ezt javítod azzal, hogy a teljes VRAM-ra lehozod a BAR-t, de közben a mikorkód nem tudja kezelni a GPU memóriakódolását. Utóbbi kell ahhoz, hogy gyors is legyen a ReBAR implementáció, ne csak sok memóriát adjon. Ezért tartott ennyire sokáig implementálni a rendszert, holott a szükséges alap azért már évek óta létezik.

    [ Szerkesztve ]

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

  • #11 Abu85 HÁZIGAZDA Reggie0 #10
    Új Válasz #11
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Reggie0 #10 üzenetére

    Ha beférsz a 256 MB-ba, akkor igazából nincs szükség a ReBAR-ra. A probléma, hogy egy mai modern motornak már ebbe a kapacitásba nem tud beleférni. Ez van, eltelt 10 év, és nem tudunk mit kezdeni a problémával, hacsak nem tesszük az egész VRAM-ot host-visible memóriatípussá. A jelenlegi helyzet ennyire egyszerű. Az más kérdés, hogy ennek a hatékony implementációja platformszintű, tehát csak azok a cégek tudnak igazán mit kezdeni a problémával, amelyek CPU-t és GPU-t is kínálnak.

    Nem ez marad egyébként az egyetlen platformszintű fícsőr a jövőben, az AMD már kettő újon dolgozik, amik Ryzen+Radeon szinten működnek csak, és nyilván az Intel is le tudja ezeket majd másolni Core+Arc szinten. Az NV-nek innentől kell majd egy processzor, tehát ütniük kell a Microsoftot, hogy a Windows licencelését gondolják át az ARM-ra.

    [ Szerkesztve ]

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

  • #14 Abu85 HÁZIGAZDA b. #13
    Új Válasz #14
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz b. #13 üzenetére

    Arról szól, hogy jön ReBAR implementáció Intelen is, és ez olyasmi lesz, mint az AMD-é, nem olyan, mint az NV-é, hiszen az Intelnek van platformja ezt megcsinálni az NV-vel ellentétben.

    Az Intelnek elég csomagban adni a Core-t és az Arc-ot, és máris szereznek egy kivejezetten nagy piacot az árukapcsolással. Persze, majd megbüntetik őket 10 év múlva, de az már a piacot nem hozza a másiknak vissza.

    [ 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