If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Turning Mesa Into JavaScript For The Web?

03-06-2012, 09:20 AM

Phoronix: Turning Mesa Into JavaScript For The Web?

Besides the recent talk about using Gallium3D's LLVMpipe for Mozilla Firefox, there's another interesting technical discussion happening now about using Mesa on the web to emulate the full OpenGL API using the WebGL API...

Comment

So this is to allow games written to use OpenGL to be played within a browser so wouldn't there a performance hit in doing that?

There would be a great performance loss as nor javascript is as fast as C/C++ or webgl to opengl. Although I could think that its a quite interesting project. If in future, browsers could achive near native performence in graphics level, complex games could be created entirely on web and thus Linux users will also get a verity of game to play.

Although I would like to see what the current status of the browsers. How much they will support right now heavy gaming. A benchmark will be much appreciate; Michael?

Comment

Even if not strictly for games one interesting use from this project could even allow online collaboration on 3D graphics projects as well. If browsers could be beefed up to handle such JS code without too much of a hit in performance then cloud based games where the game code resides in the cloud and a client piece as a browser plugin/extension could be theoretically possible.

Comment

Even if not strictly for games one interesting use from this project could even allow online collaboration on 3D graphics projects as well. If browsers could be beefed up to handle such JS code without too much of a hit in performance then cloud based games where the game code resides in the cloud and a client piece as a browser plugin/extension could be theoretically possible.

Oh, you mean Java Applets? That sounds like a great idea.

Comment

Regarding speed, JS is indeed slower than C/C++. But it is getting fast quickly. Right now on several benchmarks JS is just 1.5x slower than C/C++. On most benchmarks JS is 2x-6x slower than C/C++. We are working hard to improve both the LLVM=>JS compiler and the JS engine itself, which should get most benchmarks to the lower end of that range - which would basically be as fast as Java, i.e. "fast enough".

Comment

Not sure how useful this can really be given that most modern desktop OpenGL apps use various APIs and features that are not implemented in GLES/WebGL.

Likewise, while emacripten is a neat hack, there are a great many limitations imposed by JavaScript that hampers the ability to port a lot of interesting C/C++ code, not to mention the massive overhead compared even to well-written native JS. (I gave a talk a few months back on optimizing JS game engines, and needless to say it requires a great deal of hand tweaking and low-level knowledge of the language that retargetting compilers abstract away from the programmer.

A better solution would be to just get Firefox to support NativeClient. Especially as Unity 3D (an another two major game engines I can't disclose atm) are going to support NaCl as a target in the next year or so. Funnily enough, they're using that to claim Linux support without any "native" Linux binaries.

Comment

Even if not strictly for games one interesting use from this project could even allow online collaboration on 3D graphics projects as well. If browsers could be beefed up to handle such JS code without too much of a hit in performance then cloud based games where the game code resides in the cloud and a client piece as a browser plugin/extension could be theoretically possible.

sounds like quark live.

Comment

Likewise, while emacripten is a neat hack, there are a great many limitations imposed by JavaScript that hampers the ability to port a lot of interesting C/C++ code, not to mention the massive overhead compared even to well-written native JS

Actually, we are seeing that fully-optimized compiled code is faster than handwritten JS. For one thing, compiled code doesn't use GC at all. Also, it doesn't use objects which are hard to optimize; the code instead does low-level operations you wouldn't normally write in regular JS. But, JS engines can optimize that low-level stuff much better.

For example, Box2D compiled with emscripten is significantly faster than Box2D's manual JS port. We see the same on most other benchmarks as well.

A better solution would be to just get Firefox to support NativeClient. Especially as Unity 3D (an another two major game engines I can't disclose atm) are going to support NaCl as a target in the next year or so. Funnily enough, they're using that to claim Linux support without any "native" Linux binaries.

NaCl isn't going to happen anywhere but Chrome - and even there, not sure it will be outside the Chrome App Store.

NaCl is nonportable, which is the opposite of what the web needs. NaCl apps do not run on ARM devices, for example. Also, while open source, it depends on PPAPI. Those two technologies are nonstandard and basically controlled and constantly modified by Google, for that reason, no other browser vendor wants to touch them.