WebGL és Linux

Egészen pontosan Chrome és OpenSuse... és nem megy... :(

Ti próbáltátok? Megy? Ha igen, mi a trükk? Ha nem, akkor szomorkodjunk együtt... :)

Hozzászólások

Tudsz adni urlt ahol tesztelhetem?

Chrome alatt itt tudod megnézni:
chrome://gpu/
Nekem WebGL: Unavailable :(

pch
--
http://www.buster.hu "A" számlázó
--

Hm... nekem nem megy... hm-hm... lehet, hogy nincs is 3D támogatásom...

# glxspheres
Polygons in scene: 62464
Xlib: extension "GLX" missing on display ":0".
ERROR (610): Could not obtain RGB visual with requested properties
Xlib: extension "GLX" missing on display ":0".

Akkor egy lépést hátrálok... :)

Na, pénteken este megszivattam magam egy kis Bumblebee-vel (mert ilyen NVidia Optimus van a laptopban), ami után nem indult el rendesen a laptopt, szóval ígyhagytam... Szombaton aztán elmentem Bécsbe forraltbort inni, ma újratelepítettem az NVidia csomagokat és most lett WebGL... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Chrome beta alatt megy.
Verzió: 40.0.2214.45 beta

Graphics Feature Status
Canvas: Software only, hardware acceleration unavailable
Flash: Hardware accelerated
Flash Stage3D: Software only, hardware acceleration unavailable
Flash Stage3D Baseline profile: Software only, hardware acceleration unavailable
Compositing: Hardware accelerated
Multiple Raster Threads: Disabled
Rasterization: Software only, hardware acceleration unavailable
Threaded Rasterization: Enabled
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Hardware accelerated
WebGL: Hardware accelerated

pch
--
http://www.buster.hu "A" számlázó
--

Kabbe! :D

Számomra ijesztő, hogy alkalmazás rétegből így meg lehet borítani egy gépet. Azért leírom, hogyan volt ez.

Linkre kattintás után Firefox megdöglend, helyesebben szólva talán VGA driver közelében keletkeztek a bajok. Egér kurzor nem moccan. Jó, akkor lépjünk konzolra, ahol láttam VGA driver hibaüzeneteket.

Gondoltam, init 3, majd init 5 megoldja. Hát nem. Be tudtam lépni, de Compiz megdöglend. Mondom neki init 3 után, hogy reboot. Elkezd leállni, de systemd vagy kernel meghala vala, kb. 5 perc után hardware reset. Itt meglepetés: gép RESET után nem indult! Jó, akkor kikapcs. Újabb meglepetés: gép bekapcsolás után sem indult. Ekkor már kezdtem némi tiszteletet érezni a kolléga iránt. :D Úgy értem, a BIOS POST sem futott le, tehát BIOS SETUP-ba lépés, mint olyan, nem opció. Jó, még van a tarsolyomban ötlet, semmi pánik. Tápegység kikapcsol fizikai kapcsolóval, várakozás, visszakapcsolás.

Gép bekapcsol, nagy piros felirat, mely szerint ez az overclocking nem kellene - sohasem „húztam” a gépet -, szóval valaki végigszántotta a CMOS RAM-ot. Remek. Akkor BIOS SETUP-ba be, default értékek betöltése, majd menüpontonként mindenen átrágtam magam, azért, hogy beállítsam, amit másképp akartam. Aztán boot, gép megy, gondolom, miután journalból helyreállt a filerendszer konzisztencia.

Hmm... mondtam már, hogy kabbe? :DD

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

:)

A BIOS szerintem csak azért óbégatott, mert nem futott végig az inicializálás a beragadt GPU miatt, aztán arra tippelt, hogy talán szénné vagy tuningolva a gép, azért fagy már az elején. A CMOS beállításaid szerintem megvoltak.

Milyen VGA? Elvileg kezelni kéne egy watchdog-nak a túlterhelést, driver gond lehet.

Mit értesz driver alatt? Netán VGA firmware-t? Mert reset után úgy gondolom, nem fut a kernel, hanem a BIOS-ra kerül a vezérlés, s a BIOS inicializálja még a DRAM frissítést is, meg ami kell. Onnan már semmi sincs, ami a reset előtt volt. Illetve egy dolog igen: ha egyes hardware-ek ignorálják a reset-et, akkor más állapotban lehetnek, mint power on reset után lennének. Ezért is vettem el a tápot annyira, hogy a standby +5 V is megszűnjön. A durva, hogy sima kikapcsolásra elmegy a +5 V, +12 V, -12 V, gondolom, a +3.3 V is, egyedül a standby +5 V marad, s még ezután sem javult meg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak ötletelek unalmamba, de olyasmire gondolok, hogy ez az armageddon több független jelenségből áll össze:
1. a driver nem képes a gpu-t korrektül kiresetelni
2. a cpu/bus reset nem üti ki a gpu állapotát nullára - lehet hiba, de lehet valami feature
3. a BIOS csak azért anyázott a tuningra, mert a beakadt vga miatt nem ment végig az init és erre az esetre ez a standard warning üzenete

Lehet hogy van 1db hiba a driverben, a többi pedig már csak következmény. Mondjuk a GPU reset nem olyan triviális dolog, talán megoldhatatlan azon a vason korrektül, de akkor is a driver felé kell elindulni.

Biztos vagy te abban, hogy ez a "script" csinálta? Nem egyszerűen szerencsétlen véletlenek sorozata? Az oldalt megnyitva ~10s-et laggol a Firefox és ennyi. A logok üresek, mindösszesen arra "panaszkodik" az X hogy a monitor nem támogatja a 3D Vision stereo-t.

Natúr 14.10-es Ubuntu alatt.

Mire gondolsz? Ha történetesen az öreg VGA, kevés VGA RAM miatt elfogytak az erőforrások, s emiatt megborult a gép, akkor az szerintem továbbra is a kernel sara, mert nem ellenőrizte a paramétereket.

Nyilván nem azt feltételezem, hogy szándékosan címzett valaki a CMOS RAM-ba, de már az is rég rossz, ha ellenőrizetlen helyre átadódott a vezérlés, s konrollálatlanul futhatott valami RAM-szemét. Védett mód, ring 0, miegymás, szóval azért akárhogy is nézem, ez probléma, azt hiszem.

Szerk.: Amilyen gyors egy ilyen gép, pillanatok alatt óriási pusztítást tud végezni egy zagyva kód futása, még ha nem is gyakori ez.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az a baj, hogy egy egyszerű túlterhelés miatt, nem szabadna ilyet művelnie (ahogy írod is), pont ezért próbáltam ki én is itthon. Megmondom őszintén, én első körben nem a kernelre és a megkerült biztonsági intézkedésekre gondolok, hanem driver vagy hardver gondra.

Ne érts félre, hiszek neked hogy ez történt, de nagyobb minta kellene a pontos képhez.

>linux
>2014

meanwhile in windowsland: "a grafikus eszközillesztő nem válaszolt, majd helyreállt" (wddm ftw)

kárpótlásképp: http://apps.playcanvas.com/will/doom3/gangnamstyle
ebben nincs semmi meglepetés (bár a fentiek után nem tudom, nekem az előző demo sem okozott ilyen galibát linux alatt)

egyébként webgl.disabled is obligatory

_____________________________
Powered by 1,3,7-trimetilxantin

+1, ugyanez volt nekem, csak meglepo volt hogy ez a 3 eves hunger.hus oldal meg most is megfekteti a GPU drivereket. Foleg hogy remlett valami olyasmi hogy csak Win+AMD kombon mukodott, mert ott hasznalt ki valamit, de ezekszerint rosszul emlekeztem. Pedig mintha az akkori Linuxos Intel driveremet nem akasztotta volna meg, ugy remlik.

Sztem jóval kevesebb konfigot fektet meg mint amit nem, csak ők a hangosabbak, nekik fáj. Ez egy ismert probléma a kezdetektől, emiatt jött létre a GL_ARB_robustness, mindennek illene lekezelni a helyzetet.

Kíváncsi lennék egy HTML galériára, amiben óriási képek vannak, hány ember gépe swappelné halálba magát tőle. Simán lehet, hogy több mint amennyi meghal a webgl DoS-tól.

Te hulye vagy! Szerinted tenyleg normalis hogy megfektet egy weblap egy bongeszon keresztul egy videokartyadrivert? Es azon keresztul OS szintu hibauzenetet kapsz, es nem a bongeszod dob egy excpetiont ahogy normalis lenne? Egy weblap ne tudjon elerni oprendszer szintu hibat semmilyen korulmenyek kozt, ne mondd hogy ezzel nem lehet egyeterteni, akkor se ha "a driver a szar". De majd aki exploitot akar irni ami reszben ezt is hasznalja ki, azt is megkered majd szepen hogy "de hat hasznalnod kene a GL_ARB_robustness-t", es akkor nem is tudnad megirni? Biztos sokat fog erni!

Bar ahogy nezem a multkor ota mar fejlodtel:

"mint amennyi meghal a webgl DoS-tól." - 2014

vs

"Az nem DoS, hogy 10mp-re megakad a gépem HA megnézem az oldalad" - 2011

2018-ra talan eljutunk odaig, hogy azt mondod majd hogy "oke, vegulis, ciki hogy 7 ev utan meg mindig az OS-t fekteti meg, de {...es ide jon majd a bullshited...}"

Bocs, nem figyeltem kire replyzek. Legközelebb óvatosabb leszek.

Mindenesetre jó hogy eszembejuttattad a topicot, eltelt 3 év, mára a webgl default a major böngészőkben, olyan huszadrangú alkalmazások használják by default mint a Google Maps.

Hol maradt az apokalipszis? Hol a webgl-lel zombivá tett gépek hada? Még mindig ez a 2 másodperces(!) lag minden amit azóta sikerült felmutatni? :) Sokat kell még várni..?

Ha mar igy vegig akarsz menni azokon a baromsagokon amiket akkor mondtal:

"csak Windowsra igaz"

Aha, epp a topikban beszeltunk tobben rola hogy oesiksz meg lunix is meghalt alatta (es midnketto OS szintu hibat dobott)

folytathatjuk? ;) ne folytassuk, nincs kedvem, es holnap mar idom se lesz

glxinfo | grep robustness
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
    GL_ARB_robustness, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map, 
    GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects, 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tudom, hogy régi, 6 és fél éves a gép. Azóta CPU-t cseréltem AMD Phenom II X4, 3.2 GHz-re, meg 4 GiB RAM-ot tettem bele. Ami kellemetlen manapság, hogy még DDR2-es RAM-ok vannak benne 800 MHz-ről, ennek ellenére mindennapi használatra nem érzem gyengének, még egy live image-et is elkészít belátható idő alatt, ami becslésem szerint úgy fél óra lehet. A VGA is ezeket az időket idézi, de már újonnan sem játékra volt kitalálva.

Ezt azért nem fogom reportolni, mert eléggé fogalmatlan vagyok hozzá, bele kellene ásnom magam, hogy értelmes legyen, amit írok, másfelől normál körülmények között nem okoz felfordulást. Mondjuk az tény, hogy csúnyán borult a gép, de nem vagyok ijedős, megoldom. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Huh, most nézem, ez egy nyamvadt java-script. Oprendszer fölött user space-ben, felhasználói joggal, és eljutott a dolog odáig, hogy szétkaristolta a CMOS RAM-ot, hardware konfigurációt. Dícséretes, és fájdalmas egyben a Linux kernelre nézvést. Pedig nem régi, 3.17.7-es.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nálam először win8 kiírta, hogy az videóillesztő nem reagált, de sikeresen helyreállt.
F5 után meg kiírta a chrome, hogy "A nemjóját! A WebGL akadályba ütközött." :D

-------------
I made an NTP joke once. The timing was perfect.
DevMeme, fejlesztői pillanatok...

Szia,
Jelenleg nem linux alatt vagyok, és, linux alatt sincs Chrome-m ... Csak kerestem a kérdésedre ( "Ha igen, mi a trükk? Ha nem, akkor szomorkodjunk együtt... :)" ) választ, és azért így, mert nem írtad le, hogy kísérleteztél vele.
Mostanában elég sok olyan kérdésbe futottam bele, amikor egy google megoldotta volna...
Bocs, ha elhamarkodott volt, de nem látszott belőle, hogy kísérleteztél volna a második linkben leírt opciókkal...
Üdv,
LuiseX

chrome://settings -> legalul hardveres gyorsítás és pipa. Esetleg? Nálam így működik.

(Google Chrome 39.0.2171.95)

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Kipróbáltam a LibGDX-et, ami tud fordítani Android és WebGL/GWT kimenetet (illetve iOS és Desktop target is megadható, de ezeket egyelőre hanyagolom), ehhez kellett a WebGL támogatás a böngészőbe: https://test.gacivs.info/webgl/

Van szimpla HTML5 frontend is, ha nem lenne WebGL támogatás, sőt, egyelőre csak ez van, de reményeim szerint nemsokára a WebGL is hasonlóképp fog működni, csak jobban fog kinézni: https://test.gacivs.info/

:)

Script kiddie... :)

Hunger oldalán egy teszt van a sok közül, amelyet a Khonos kidolgozott: https://www.khronos.org/opengles/adopters/
Itt van több példa is: https://github.com/mapbox/headless-gl/tree/master/test/conformance-suite

Ez kicsit olyan, mint amilyenek anno a JavaScript támadások voltak, csak ez esetben a GPU-t "támadják", a friss eszközök pedig eléggé jól védekeznek...

Ahja... mind a három.

A többi nemzetközileg el nem ismert biztonsági szakértő pedig tudott értő módon olvasni és képes volt megérteni, hogy miről is írtam. A nemzetközileg elismert biztonsági szakértők pedig végig a saját állításaikat támadták. A részleteket pedig lásd a http://a.te.ervelesi.hibad.hu/szalmabab oldalon.

Egyéb?

Próbáld meg elolvasni újra az egész szálat... olyan módon, hogy megpróbálod érteni is, ami le volt írva, nem pedig egy szövegkörnyezetéből kiragadott egyetlen mondaton lovagolsz éveken át. Nézd végig, hogy mit írtam, mire írtam, Te (illetve Ti) mire reagáltatok, és mi ellen érveltetek... ennél többet nem tudok segíteni. Vagy diszlexiás az egész csapat vagy már akkor is árnyékra vetődtetek csak már ciki lenne beismerni.

Szerkesztve: 2020. 10. 12., h – 09:53

Sziasztok, 

bocsi hogy ilyen régi szálat élesztek fel, de nem akartam újat nyitni. 

Tanácsot szeretnék kérni: egy Linuxos kioszk gépet építünk. Eredetileg egy embedded vasra gondoltam, pl Jetson Nanora, de közben kiderült, hogy a böngésző intenzíven fog WebGL renderelni, amit nem tud a Nano. Következő tipp a Xavier volt (link lejjebb), de azt olvasom hogy a WebGL jobban szereti a x86_64 architektúrát, és ezért vszeg bölcsebb lenne egy MiniITX/ATX és egy gyors videokártya... Kb 200k a keret, mit javasoltok?

 

https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetso…

Mi az, hogy "intenzíven"? Iszonyú sokat fejlődtek a grafikus hardverek, simán lehet, hogy egy beágyazott Intel GPU is elegendő. 60 FPS fölé gondolom nem kell menni, ahhoz kell belőni a teljesítményt. Ha megvan a konkrét program, akkor mérni kellene előbb, és utána vasat venni. Persze ha one shot projekt, akkor a befektetett időt sem éri meg a méregetés, de ha sorozatban eladott termék, akkor nem érdemes túllőni. A 200EFt-s nagyon soknak tűnik egy kioszk mögé. Vagy 4K-ban renderelt AAA játék-szerű színtér fog futni benne?

A 200k a limit, a Xavier csak 400USD+áfa+béfa. Ez egy one shot prototípus. Nehéz megsaccolni a teljesítményigényt, ezek a demok állítólag megizzasztanak egy GTX 1070 kártyát is:

https://docs.lookingglassfactory.com/Holoplayjs/examples/?_ga=2.19761336.1800763512.1602486410-1751695862.1602055406