Dabar forume
[ Administratorius ] [ Moderatorius ]
|
|
Daugiau
|
|
|
|
|
| Rodyti ankstesnę temą :: Rodyti sekančią temą |
| Pranešimas |
Autorius |
Parašytas: Tr. 11 30, 2011 13:13 Rašyti temą: |
|
|
GPU sprendžia problemas, kurios šiaip surytų 99% CPU resursų - matomumas, šešėliai, atspindžiai, kreivių glotninimas, tekstūros, subpikseliai... Nėra didelio skirtumo, per kokį API tuos objektus sukiši į GPU. Scenos valdymas ir objektų perstumdymas nuo senų laikų programuojamas skriptais - REXX, Lua ir panašiomis kalbomis, kurių interpretatoriai nė iš tolo našumu ir galimybėmis negali lygintis su JägerMonkey, Tamarin, jau nekalbant apie MSIL ar JRE, kurių našumas gali smarkiai lenkti prekompiliuotą C++ kodą priklausomai nuo uždavinio ir algoritmo.
Jei rašysi žaidimą su Canvas API arba SVG - tai tas pats kaip su BGI ar VESA. Turi geriausiu atveju interaktyvius 2D primityvus plokštumoje, kuriuos gali pritaikyti arkadai, stalo žaidimams, bet realistinio 3D taip paprastai nepadarysi, ir visas 3D transformacijas tektų rašyti su Javascript.
Ar .NET'e yra 3D API palaikymas - tiesą sakant, nežinau. Apskritai, nematau prasmės 3D variklio rašyti su C#, jei jis veiktų tik po Windowsais ir Direct3D, ir tas 3D kodas CSIL atžvilgiu būtų unmanaged.
Tuo tarpu, ką duoda bibliotekos kaip Khronos/WebGL arba Java3D - tai kad leidžia programuoti žemo lygio OpenGL/Direct3D iš managed kodo. Tai yra tik plonas abstrakcijos sluoksnelis, kompiliuojantis 3D komandas, "programas", shaderių algoritmus. Kaip minėjau, WebGL atveju jie aprašomi net ne Javascriptu, o visai kitu C kalbos poaibiu, kuris kompiliuojamas ir vykdomas visai kitaip nei "paprastas" JS. Ir tai daroma ne kiekviename kadre, o užkraunant atitinkamą shaderį ar pan., todėl teoriškai tai turėtų veikti taip pat optimaliai, kaip ir įprastuose kompiliuotuose varikliuose (aišku, niekas netrukdo shaderių programas generuoti dinamiškai iš JS atskirai kiekvienam kadrui, bet nelabai įsivaizduoju tam būtinybės). Taigi, kritika apie JS arba CSIL lėtumą čia kaip ir netinka.
Dėl Direct3D vs. OpenGL vs. thin layer - tai daugiausia skonio reikalas. Savaime suprantama, kad pagal egzotiškas galimybes D3D visuomet bus pusmečiu priekyje, nes API diktuoja Microsoft, o plokščių gamintojai stengiasi jam įtikti dar plokščių projektavimo stadijoje. OGL/WebGL yra atviri standartai, kuriuose dėl kiekvieno API pakeitimo turi susitarti daugybė rinkos žaidėjų nuo plokščių/GPU gamintojų iki OS, žaidimų, bibliotekų, grafikos programų autorių, ir dar prisideda naršyklės bei Web standartų organizacijos. Kai tėra viena platforma, gali vartotojui pasakyti "parsisiųsk DirectX 11 iš [čia]".
Dėl konsolių ir kišeninių aparatų - tai nesutinku, kad juose nėra rinkos. 3D spartinimą palaiko bene visi šiuolaikiniai telefonai su J2ME, ir jiems yra pridaryta visokių lenktynių žaidimukų, Androidams - Google Earth, vartotojo sąsajų su kompozicijom, tekstūrom bei 3D langų vartymais ir panašių. Tame ir yra 3D aparatūros gerumas - kad ji nupiešia tiek efektų, kiek spėja, neapkraudama CPU. Gal nespės užmauti tekstūros, paskaičiuoti atspindžio ar suglotninti kreivės - bet vis tiek matysi kampuotus 3D objektus.
N.B. QuakeLive nenaudoja WebGL, todėl jo sparta nėra rodiklis.
Čia reiktų prisiminti dar vieną technologiją - Google nativeclient Plugin'ą, kuris naršyklės "sandboxe" vykdo kompiliuotas C/C++/whatever programas ( informacijos nuoroda , informacijos nuoroda , informacijos nuoroda ). Teoriškai, Quake sukompiliuotas jam, turėtų veikti naršyklėje tokia pat sparta, kaip ir sukompiliuotas konkrečiai architektūrai. |
|
rwc
Prisijungė: 2008 10 12 Žinutės: 4930
|
|
Atgal į viršų |
 |
Parašytas: Tr. 11 30, 2011 14:47 Rašyti temą: |
|
|
| rwc rašo: |
| GPU sprendžia problemas, kurios šiaip surytų 99% CPU resursų - matomumas, šešėliai, atspindžiai, kreivių glotninimas, tekstūros, subpikseliai... Nėra didelio skirtumo, per kokį API tuos objektus sukiši į GPU. Scenos valdymas ir objektų perstumdymas nuo senų laikų programuojamas skriptais - REXX, Lua ir panašiomis kalbomis, kurių interpretatoriai nė iš tolo našumu ir galimybėmis negali lygintis su JägerMonkey, Tamarin, jau nekalbant apie MSIL ar JRE, kurių našumas gali smarkiai lenkti prekompiliuotą C++ kodą priklausomai nuo uždavinio ir algoritmo. |
| Citata: |
Tuo tarpu, ką duoda bibliotekos kaip Khronos/WebGL arba Java3D - tai kad leidžia programuoti žemo lygio OpenGL/Direct3D iš managed kodo. Tai yra tik plonas abstrakcijos sluoksnelis, kompiliuojantis 3D komandas, "programas", shaderių algoritmus. Kaip minėjau, WebGL atveju jie aprašomi net ne Javascriptu, o visai kitu C kalbos poaibiu, kuris kompiliuojamas ir vykdomas visai kitaip nei "paprastas" JS. Ir tai daroma ne kiekviename kadre, o užkraunant atitinkamą shaderį ar pan., todėl teoriškai tai turėtų veikti taip pat optimaliai, kaip ir įprastuose kompiliuotuose varikliuose (aišku, niekas netrukdo shaderių programas generuoti dinamiškai iš JS atskirai kiekvienam kadrui, bet nelabai įsivaizduoju tam būtinybės). Taigi, kritika apie JS arba CSIL lėtumą čia kaip ir netinka. |
Mhm. Tik, kad as kalbejau apie CPU algoritmus kurie yra rasomi i pati varikli, pvz.: fizika, AI, collision detection ir t.t. Ar uz juos jau siais laikais irgi atsakinga GPU?
| Citata: |
| Ar .NET'e yra 3D API palaikymas - tiesą sakant, nežinau. Apskritai, nematau prasmės 3D variklio rašyti su C#, jei jis veiktų tik po Windowsais ir Direct3D, ir tas 3D kodas CSIL atžvilgiu būtų unmanaged. |
Ir ant Xbox, ir ant WP7, ir ant Silverlight(greitai). Ir siaip yra nauju zaidimu, kurie yra kuriami tik Windows platformai, bet jie visvien rasomi tik su C++.
| Citata: |
Dėl konsolių ir kišeninių aparatų - tai nesutinku, kad juose nėra rinkos. 3D spartinimą palaiko bene visi šiuolaikiniai telefonai su J2ME, ir jiems yra pridaryta visokių lenktynių žaidimukų, Androidams - Google Earth, vartotojo sąsajų su kompozicijom, tekstūrom bei 3D langų vartymais ir panašių. Tame ir yra 3D aparatūros gerumas - kad ji nupiešia tiek efektų, kiek spėja, neapkraudama CPU. Gal nespės užmauti tekstūros, paskaičiuoti atspindžio ar suglotninti kreivės - bet vis tiek matysi kampuotus 3D objektus. |
Yra labai didelis skirtumas tarp 3D palaikymo ir AAA zaidimu, netgi jei mobilus irenginiai turetu galios palaikyti tokius zaidimus - jie tiesiog nera jiems pritaikyti: niekam nebutu idomu zaisti kokio nors Crysis ant mobiliako.
| Citata: |
| N.B. QuakeLive nenaudoja WebGL, todėl jo sparta nėra rodiklis. |
QuakeLive yra pavizdys projekto kuris puikiai tiktu WebGL'ui, taciau jau dabar jis yra multiplatforminis.
Kaip ir rasiau anksciau - pati technologija daug zadanti ir labai idomi, bet ne kaip rimta zaidimu platforma.
Netgi jeigu technologija leistu kurti AAA zaidimus narsykleje - to vistiek nieks nedarytu, dabar yra 2 zaidimu tipai:
PC + Xbox + PS3
PC + Mac
Pirmo tipo zaidimu kurejams tai neaktualu - konsoles neturi narsykliu. Antro tipo zaidimu kurejai jau ir taip kuria zaidimus ant abieju jiems idomiu platformu, linuksai ju nedomina, jei jie noretu, jie galetu lengvai perkelti Mac -> linux.
| Citata: |
| Čia reiktų prisiminti dar vieną technologiją - Google nativeclient Plugin'ą, kuris naršyklės "sandboxe" vykdo kompiliuotas C/C++/whatever programas ( informacijos nuoroda , informacijos nuoroda , informacijos nuoroda ). Teoriškai, Quake sukompiliuotas jam, turėtų veikti naršyklėje tokia pat sparta, kaip ir sukompiliuotas konkrečiai architektūrai. |
Situo projektu domejausi anksciau, bet kazkaip jis ne per smarkiai stumiamas. _________________ "The waking dream called
the world is constantly changing.
What's so sad about that?" -Seiichi Kirima |
|
KeeperMustDie
Prisijungė: 2009 05 07 Žinutės: 707
|
|
Atgal į viršų |
 |
Parašytas: Kv. 12 01, 2011 11:51 Rašyti temą: |
|
|
| KeeperMustDie rašo: |
| Mhm. Tik, kad as kalbejau apie CPU algoritmus kurie yra rasomi i pati varikli, pvz.: fizika, AI, collision detection ir t.t. Ar uz juos jau siais laikais irgi atsakinga GPU? |
Iš principo įmanoma, ir vis dažniau taip daroma. GPU paskirstytų skaičiavimų taikymas fizikos modeliavime - viena iš aktyviausių informatikos mokslo tyrimų sričių.
Jei gūglas sugeba DBMS pastatyti ant GPU, tai kolizijų (ar "potencialių kolizijų") aptikimas - palyginus saldainiukas.
Kuo šiuolaikiniai GPU yra geri - kad jie gali realizuoti bet kokį algoritmą (pasistengus, Turing-complete), bet jį labai gerai lygiagretina. Kitaip tariant, bet kokį tiesinį algoritmą gali perrašyti į logaritminį naudodamas GPU, jei lygiagretinamų srautų kiekis neviršija branduolių skaičiaus.
| Citata: |
| Ir ant Xbox, ir ant WP7, ir ant Silverlight(greitai). Ir siaip yra nauju zaidimu, kurie yra kuriami tik Windows platformai, bet jie visvien rasomi tik su C++. |
Ar tik ne tam, kad nereikėtų palaikyti dviejų kodo bazių? Dubliuotų duomenų struktūrų, konversijų, maršalingo tarp skirtingų kalbų?
Su Java3D niekas nesirūpina JNI ir panašiais mechanizmais, nebent reikia išnaudoti kažką panašaus į CUDA. Tiesiog viską rašo Javoj ir nesuka sau plaučių, kad scenos inicializacija gal(?) bus lėtesnė dalimi procento, nei sukodinus su JNI ir C++. Arba kad scenos parametrų pakeitimas truks ne 10ms, o 10.001.
Visai kitas klausimas, kiek dirbant su GPU išnaudojamos VM galimybės. Neturi exceptionų, stack trace'ų, deterministinio konkurenciškumo, polimorfizmo ir moduliškumo galimybės taip pat ribotos... Šiuo požiūriu, kodinti GPU aukšta kalba nėra prasmės, nes tas kodas kaip kokio mikrokontrolerio.
WebGL atveju, nauda yra - multiplatformiškumas (write once execute everywhere).
| Citata: |
| Yra labai didelis skirtumas tarp 3D palaikymo ir AAA zaidimu, netgi jei mobilus irenginiai turetu galios palaikyti tokius zaidimus - jie tiesiog nera jiems pritaikyti: niekam nebutu idomu zaisti kokio nors Crysis ant mobiliako. |
Tai kodėl 3D technologijas tapatinam vien su state-of-art žaidimais? Autocadas planšetei neturėtų perpektyvos? Arba webinis AutoCAD WS su pilna akseleracija? Arba koks Second-Life klonas Androidui? WoW?
Kad mobilūs įrenginiai FPS'ams (kur reikia tikslumo, reakcijos ir ypatingos ergonomikos) netinka - faktas, bet yra daugybė kitų 3D taikymų, kur mobilūs įrenginiai netgi turi pranašumą prieš desktopus.
| Citata: |
| QuakeLive yra pavizdys projekto kuris puikiai tiktu WebGL'ui, taciau jau dabar jis yra multiplatforminis. |
Būtent, ne, bet tai yra QL architektūros minusas, o ne išnaudojamų technologijų. QL tektų iš pagrindų perrašyti ir atsisakyti daugumos naudojamų optimizacijų.
| Citata: |
Netgi jeigu technologija leistu kurti AAA zaidimus narsykleje - to vistiek nieks nedarytu, dabar yra 2 zaidimu tipai:
PC + Xbox + PS3
PC + Mac
Pirmo tipo zaidimu kurejams tai neaktualu - konsoles neturi narsykliu. Antro tipo zaidimu kurejai jau ir taip kuria zaidimus ant abieju jiems idomiu platformu, linuksai ju nedomina, jei jie noretu, jie galetu lengvai perkelti Mac -> linux. |
Tai... Mac kurį variklį naudoja? Direct3D ar OpenGL?
Nuportinti Mac->Linux - tai iš esmės perkompiliuoti... Vienas BET: Mac'ai emuliuoja GPU tais atvejais, kai kažkuri OpenGL funkcija nepalaikoma arba palaikoma neteisingai (LLVM). Kuo tai skiriasi nuo WebGL?
| Citata: |
| Situo projektu domejausi anksciau, bet kazkaip jis ne per smarkiai stumiamas. |
Man apskritai keista, kad NaCl stumiamas, ir dar Google, o ne kokių IBM ar MIT. Iš UNIX padaryti Java/.NET/Mono kažkaip kreivokai atrodo. Tačiau yra veikiantis Proof of Concept, gal kažkas ir gausis.
P.S. WebGL nėra išimtinai webinė technologija. Niekas netrukdo rašyti žaidimus su C++ Gecko/Chromium/Webkit bazėje. Kompiliuoti visoms jų palaikomoms platformoms. Išnaudoti tą patį know-how visur, pradedant FPS ir baigiant reklamos banneriais. |
|
rwc
Prisijungė: 2008 10 12 Žinutės: 4930
|
|
Atgal į viršų |
 |
Parašytas: Kv. 12 01, 2011 13:56 Rašyti temą: |
|
|
| rwc rašo: |
Tai kodėl 3D technologijas tapatinam vien su state-of-art žaidimais? Autocadas planšetei neturėtų perpektyvos? Arba webinis AutoCAD WS su pilna akseleracija? Arba koks Second-Life klonas Androidui? WoW?
Kad mobilūs įrenginiai FPS'ams (kur reikia tikslumo, reakcijos ir ypatingos ergonomikos) netinka - faktas, bet yra daugybė kitų 3D taikymų, kur mobilūs įrenginiai netgi turi pranašumą prieš desktopus. |
Butent ta ir noriu pasakyti - WebGL yra labai naudingas ir idomus projektas turintys daug pritaikymo budu, bet nesutinku su straipsnio ir kai kuriu komentatoriu nuomone, kad interneto narsykle taps zaidimu platforma - not gonna happen, vienas ar kitas zaidimas ar flash'inio lygio zaidymeliai - tai dar ne platforma.
| Citata: |
| Tai... Mac kurį variklį naudoja? Direct3D ar OpenGL? |
OpenGL.
| Citata: |
| Nuportinti Mac->Linux - tai iš esmės perkompiliuoti... Vienas BET: Mac'ai emuliuoja GPU tais atvejais, kai kažkuri OpenGL funkcija nepalaikoma arba palaikoma neteisingai (LLVM). Kuo tai skiriasi nuo WebGL? |
Nieko? WebGL stebuklingai neispres problemu kurias turi OpenGL. _________________ "The waking dream called
the world is constantly changing.
What's so sad about that?" -Seiichi Kirima |
|
KeeperMustDie
Prisijungė: 2009 05 07 Žinutės: 707
|
|
Atgal į viršų |
 |
Parašytas: Kv. 12 01, 2011 14:41 Rašyti temą: |
|
|
| KeeperMustDie rašo: |
| Butent ta ir noriu pasakyti - WebGL yra labai naudingas ir idomus projektas turintys daug pritaikymo budu, bet nesutinku su straipsnio ir kai kuriu komentatoriu nuomone, kad interneto narsykle taps zaidimu platforma - not gonna happen, vienas ar kitas zaidimas ar flash'inio lygio zaidymeliai - tai dar ne platforma. |
Tame ir esmė, kad WebGL nėra platforma vien flashinio lygio žaidimėliams. Jos labai realus tikslas (vienas iš daugelio) - ištrinti ribą tarp kompiliuotų žaidimų ir webinių.
| Citata: |
| Citata: |
| Tai... Mac kurį variklį naudoja? Direct3D ar OpenGL? |
OpenGL. |
Tai ir klausimas, koks tolkas rašyti du atskirus variklius - D3D windozėm ir OGL Macui? Kokia problema perkompiliuoti Mac'ines programas Linuxui?
WebGL siūlo dar geresnį sprendimą, ir todėl jis yra (perspektyvoje gali būti) ateitis. straipsnis apie žaidimus, bet, kaip ir minėjau, 3D nėra vien FPS.
| Citata: |
| Citata: |
| Nuportinti Mac->Linux - tai iš esmės perkompiliuoti... Vienas BET: Mac'ai emuliuoja GPU tais atvejais, kai kažkuri OpenGL funkcija nepalaikoma arba palaikoma neteisingai (LLVM). Kuo tai skiriasi nuo WebGL? |
Nieko? WebGL stebuklingai neispres problemu kurias turi OpenGL. |
Gali išspręsti. Aukšto lygio frameworkai tam ir rašomi, kad išspręstų tokias problemas kaip žemesnio lygio nesuderinamumai. Ilgainiui jie patys tampa standartais. Nenustebsiu, jei kitąmet NVidia pademonstruos low-end plokštę, tiesiogiai palaikančią WebGL. |
|
rwc
Prisijungė: 2008 10 12 Žinutės: 4930
|
|
Atgal į viršų |
 |
|
|
|
|
Jūs negalite rašyti naujų pranešimų šiame forume Jūs negalite atsakinti į pranešimus šiame forume Jūs negalite redaguoti savo pranešimų šiame forume Jūs negalite ištrinti savo pranešimų šiame forume Jūs negalite dalyvauti apklausose šiame forume
|
|