Hirdetés

Hozzászólok Aktív témák

  • ROBOTER

    addikt

    Abu, ezt ki tudnád pontosabban fejteni, hogyan kell eképzelni?

    "de hatékonyabban működik, mivel nem kell minden rajzolási operáció előtt beállítani a szükséges állapotot, hanem maguk a kreált és elmentett objektumok reprezentálhatják ezt."

    Ez azt jelenti, hogy nem (csak) vertex és index puffer van, hanem objektum puffer is, és ehhez tartozik valamilyen objektum-shader is? Így két scene között ha van olyan objektum, ami megegyezik, csak az objektum attribútumát elég megváltoztati, a többi GPU feladat?

    [ Szerkesztve ]

  • Meteorhead

    aktív tag

    A WebGPU egy emberiség elleni bűntett: a RenderScript grafikai megfelelője az Apple tollából. Egy gyártó agymenése ami a többiek megkérdezése nélkül született. Az Obsidian pedig nem titkoltan a Vulkant célozza, ami pedig már elég sok szűrőn átment.

    Ha a Vulkan jó desktopra, akkor webre is. A Vulkan tudtommal igenis garantálja, hogy egyetlen process sem nyúlhat hozzá másik memóriájához, ugyanakkor az egyetlen kitétel csupán annyi, hogy ha ilyen "hiba" történik, akkor ennek nem szabad magával vinnie a teljes rendszert (trappelni kell a hibát, és maximum a kiváltó process omolhat össze). Ez a weben is teljesen vállalható, ahol a process egy kellően modularizált böngészőben csak az adott fülre korlátozódik.

    Obisidan amúgy JavaScripttel egyértelmű, hogy nem használható, és a Mozillások sem így gondolkodnak. Ők WebAssembly-vel együtt szeretnék használni, ahol az ember megnyeri az ÖSSZES WebAssemblyre fordítható nyelvet a létező összes Vulkan wrapperrel. Ha valaki nagyon OpenGL-hez szokott, akkor behúz egy olyan libet, mint az OpenGL overload és kész is van. Az igazi munka megtalálni azt a Vulkan subsetet, ami tényleg működik (valószínűleg az egész), és hogyan néz ki egy HTML5 surface binding egy ablakoló rendszer helyett.

    Nem nulla munka, de kozmikus véletlenek folytán (jó software engineering) nem halálosan sok meló.

  • Meteorhead

    aktív tag

    válasz ROBOTER #1 üzenetére

    Ez a HSZ egy törölt részre hivatkozhat, de ha jól értem erre utal:

    DX12-ben és VK-ban is készhez kapja az ember a teljes render_state_descriptor objektumot, amit állítgathat a program ahogy jónak látja. Ez az objektum magába foglalja az összes létező (amit az API elérhetővé tesz) állapotot, ami egy rajzolási parancsot befolyásolhat. Te, mint programozó, olyan objektumokat csinálhatsz, mint mondjuk

    struct drawable {
    vbo m_vbo;
    ibo m_ibo;
    render_state_descriptor m_desc;
    };

    Ilyen objektumokat behánysz egy tömbbe

    std::vector<drawable> my_scene{ ... };

    Te úgy akarod az összes objektumot kirajzolni, hogy a lehető legkevesebbet kelljen state-et váltani, mert az a költséges buli. Csinálhatod ezt mondjuk úgy, hogy:

    auto it = std::cbegin(my_scene);

    while (it != std::cend(my_scene))
    {
    render_state_descriptor state = *(it).m_desc;

    auto next = std::partition(std::par, it, std::cend(m_scene), [&](const drawable& obj) { return obj.m_desc = state; });

    Vk::set_state(state);
    std::for_each(std::par, it, next, draw);

    it = next;
    }

    Ez a gagyi kódnak látszó tárgy a gép összes magját felhasználva a tömb elejére gyűjti azokat, akiket ugyanúgy kell kirajzolni, mint az első olyan, ami még nem volt kirajzolva, aztán pedig az összes magot felhasználva rajzolási parancsokat ad ki (feltéve, hogy a draw egy globális függvény). A lényeg, pedig hogy a draw() függvényben már nincs ellenőrzés, hogy kell-e state-et váltani, mert kívül tudom garantálni, hogy a draw már mindig helyes állapottal van meghívva.

    Ettől persze egy valódi engine 10.000-szer bonyolultabb, de ilyesmire lehet gondolni, hogy nem kell minden rajzolás előtt állapotot állítani, mert ez reprezentálható magában a rajzolandó cuccban. Eddig ezt a driver ellenőrizte DX11-ben és OpenGL-ben, hogy az egymás után kiadott rajzolási parancsok "ugye tényleg nem állítják a render state-et", és amikor kijött egy játék, akkor minden ilyen ellenőrzést szelektíve kapcsolgattak ki a gyártók, hogy mit lehet elhagyni, mert tényleg jól használod az API-t. Itt a te kezedben van minden és jobban is csinálhatod, mint a driver, mert neked globális információd van arról, hogy mit akarsz csinálni, ami az egyes rajzolási parancsokból külön már nem látszik.

    [ Szerkesztve ]

  • ROBOTER

    addikt

    válasz Meteorhead #3 üzenetére

    Nem állítom, hogy minden részletben értem az alap GL gyakorlatommal, de kezd összeállni. Köszi!

  • MikeMyers

    tag

    valami új generációs video codec standard sem lenne rossz.

    No pain - no game

Hozzászólok Aktív témák

Hirdetés