Announcement

Collapse
No announcement yet.

Turning Mesa Into JavaScript For The Web?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Turning Mesa Into JavaScript For The Web?

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

    http://www.phoronix.com/vr.php?view=MTA2NjY

  • #2
    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?

    Comment


    • #3
      Originally posted by DeepDayze View Post
      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


      • #4
        With sites like github already laggy due to too much javascript, I'm certainly not looking forward to the day some site tries to force a few million lines of javascript down...

        Comment


        • #5
          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


          • #6
            Originally posted by DeepDayze View Post
            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


            • #7
              Speed

              Hi everyone,

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

              - azakai

              Comment


              • #8
                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


                • #9
                  Originally posted by DeepDayze View Post
                  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


                  • #10
                    Originally posted by elanthis View Post
                    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.

                    Comment


                    • #11
                      Originally posted by elanthis View Post
                      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.
                      That's sort of like suggesting they use Flash instead of WebGL. Probably a great idea in the short term, but rather missing the point of the exercise.

                      Comment


                      • #12
                        Originally posted by locovaca View Post
                        Oh, you mean Java Applets? That sounds like a great idea.
                        No ActiveX :-)

                        (seriously, I've seen games in a long lost time of IE5, made with ActiveX which used Direct3D and all that)

                        Comment


                        • #13
                          Originally posted by elanthis View Post
                          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.
                          The web wasn't meant to be tied to any platform (Windows or Linux, BSD, Mac, BeOS, whatever), should it really be tied to processor instead ?

                          This is something Mozilla is very unlikely to adopt, Mozilla is about the open web. For everyone, everywhere.

                          Comment


                          • #14
                            Originally posted by azakai View Post
                            NaCl apps do not run on ARM devices
                            Not that I would want NaCl, I think it would be a bad thing for the web, but Wikipedia does mention:

                            "An ARM implementation was released in March 2010. x86-64 and IA-32 are also supported. As of March 2011, however, all three implementations could only use code compiled to the host's native instruction set."

                            Although if you read this article:

                            http://www.h-online.com/open/news/it...nd-957478.html

                            Then their plan is to do the same things emscripten is doing. ;-)

                            The take LLVM and great some intermediate format and have that interpreted in the browser and execute it.
                            Last edited by Lennie; 11-29-2012, 07:47 AM.

                            Comment

                            Working...
                            X