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

• #1 ROBOTER addikt

  Új Válasz 2017-03-27 15:49:28 #1

  Ú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

  

  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 ]

• #2 Meteorhead aktív tag

  Új Válasz 2017-03-27 16:49:43 #2

  Ú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

  

  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ó.

• #3 Meteorhead aktív tag ROBOTER #1

  Új Válasz 2017-03-27 17:09:18 #3

  Ú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

  

  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 ]

• #4 ROBOTER addikt Meteorhead #3

  Új Válasz 2017-03-27 17:29:05 #4

  Ú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

  

  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!

• #5 kromatika veterán

  Új Válasz 2017-03-27 20:40:33 #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

  

  kromatika

  veterán

  Kb mikor várható ez a gyakorlatban.?

• #6 MikeMyers tag

  Új Válasz 2017-03-29 18:39:38 #6

  Ú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

  

  MikeMyers

  tag

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

  No pain - no game

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