HTML5 on consoles

[rpg.314]

What they have in common, developed by Google and adopted by Apple is multi-threading.

No. Apple independently developed a totally different mechanism for process isolation. I believe that apple and google are using different (aka forked) mechanisms at this point.

Besides allowing, now requiring, multi-threading support in the OS which is also needed for multiple CPUs which increases page redraw speeds,

EDIT: AFAIK, webkit uses multiple processes only for isolation. Individual page render is still serial.

The call is object oriented and yes you can, by following object oriented language rules, use anything to call those routines.

I don't know what you mean by "call is object oriented". To me, a function call is a function call. Single dispatch, perhaps?

Also, I believe JIT cannot be implemented on PS3 as it strictly enforces W^X. So any webkit port will probably have to use javascript core interpreter.

 

[jeff_rigby]

No. Apple independently developed a totally different mechanism for process isolation. I believe that apple and google are using different (aka forked) mechanisms at this point.

https://trac.webkit.org/wiki/WebKit2

WebKit2 is a new API layer for WebKit designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it.

EDIT: AFAIK, webkit uses multiple processes only for isolation. Individual page render is still serial.

My understanding is they render in layers serially. The individual layers being separate processes.

Webkit has accepted both Firefox and Google changes for this feature and it's similar to what Apple developed after Google released their version. Webkit has changed so much in the last 6 months that if you blink you may miss something.

The Apple site I cite is describing Chromium not Google Chrome. They use both Chrome and Chromium in the article interchangeably without describing the differences. Perhaps this is where our differences are coming from.

I don't know what you mean by "call is object oriented". To me, a function call is a function call. Single dispatch, perhaps?

http://www.webopedia.com/TERM/O/object_oriented_programming_OOP.html

For Google Chrome any object oriented language can call routines. The article for the Apple Webkit2 version mentions C+ APIs not any object oriented language. Of course "C" is an object oriented language.

Also, I believe JIT cannot be implemented on PS3 as it strictly enforces W^X. So any webkit port will probably have to use javascript core interpreter.

You lost me here, what is "W^X".

 

[Demirug]

Also, I believe JIT cannot be implemented on PS3 as it strictly enforces W^X. So any webkit port will probably have to use javascript core interpreter.

It is possible to do JIT on Cell but the PS3 OS doesn’t support it in its public interface as it is forbidden to generate PPU code at runtime. If Sony wants they can do it but it’s a big if.

 

[jeff_rigby]

It is possible to do JIT on Cell but the PS3 OS doesn’t support it in its public interface as it is forbidden to generate PPU code at runtime. If Sony wants they can do it but it’s a big if.

Thanks...another Gem of information.

http://www.powerdeveloper.org/forums/viewtopic.php?t=1649

Javascript JIT compiler for Power PC processors

http://www.llvm.org/

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines, though it does provide helpful libraries that can be used to build them.

 

[rpg.314]

https://trac.webkit.org/wiki/WebKit2

It Webkit2's process isolation model was implemented by Apple. Chromium's isolation model was implemented by Google. Both are separate pieces of code.

My understanding is they render in layers serially. The individual layers being separate processes.

Not sure why you say that. I have never heard or read about this anywhere.

The Apple site I cite is describing Chromium not Google Chrome. They use both Chrome and Chromium in the article interchangeably without describing the differences. Perhaps this is where our differences are coming from.

No. For all practical purposes, Chrome and chromium are identical.

Of course "C" is an object oriented language.

You lost me here, what is "W^X".

http://en.wikipedia.org/wiki/W^X

Also see demirug's post.

 

[rpg.314]

http://vergiss-blackjack.de/diploma-thesis_georg-sorst_java-on-cell.pdf

I've run across this before in a discussion in another forum. The technique described could be used for a Java, Android and possibly a javascript JIT engine.

They are jitting code to spu and not ppu. JS running on spu would be pathetic from a performance standpoint.

PS3 OS support will certainly be required.

 

[patsu]

Correct, but I don’t expect a COD style game with a general plugin like Flash either. We might see more such games with custom plugins. But the only reason for this is that average people have fewer problems to download and install a custom browser plugin than a full traditional game client.

In general the target audience for browser games currently expect only something like Farmville when it comes to the presentation.

... or use a Gaikai-like plugin and service ?

 

[patsu]

My understanding is they render in layers serially. The individual layers being separate processes.

Not sure why you say that. I have never heard or read about this anywhere.

He's probably referring to something like Apple's CoreAnimation layers. You can render "asynchronously" to one layer in a process and hand the layer off to another process to composite (in parallel).

http://www.taranfx.com/webkit2-browser-improvements

Taking a step further, WebKit2 split processes directly into the rendering engine and separates each plugin and its instance to separate processes.

CoreAnimation rendering already exists in today's Netscape Plugin API... not sure who uses it now; but it's doable:
https://wiki.mozilla.org/NPAPI:CoreAnimationDrawingModel

Currently, the only way for a plug-in on Mac to use OpenGL is to attach an AGL surface manually. This has a number of drawbacks:

* The plug-in has to move the surface in response to page scrolling, window resizing, etc

* The plug-in needs access to the browser window's WindowRef

* AGL is a Carbon based API and does not work in 64-bit

The Core Animation drawing model aims to solve these problems (and more) by letting the plug-in hand off a Core Animation layer to the browser. It is then up to the browser to position and size the layer.

 

[Demirug]

... or use a Gaikai-like plugin and service ?

To be honest I am not a big fan of this approach at all.

 

[patsu]

It's a natural extension to streaming music and video services, probably usable for certain kinds of games at this stage.

Doesn't require HTML5 compliance though.

 

[jeff_rigby]

It is possible to do JIT on Cell but the PS3 OS doesn’t support it in its public interface as it is forbidden to generate PPU code at runtime. If Sony wants they can do it but it’s a big if.

Home, Android, Java, Javascript would all benefit from JIT compiling to native language. The articles I've read seem to indicate it can be faster than compiled to native language C code (If that C code was poorly done). Repeat code is cached and does not need to be recompiled resulting in a performance increase. The hit in performance seems to be with large complex routines and memory access. For small routines the 256K cache in the SPUs can be used. For larger then the main memory must be used. You then get PPU and memory use conflicts.

From what I understand, once the routines are written in assembler to insure they are the smallest fastest possible, the same technique and much of the same code can be used for the other JIT compilers/engines. Massive amount of work.

The talk on this is about finding routines to do this for each CPU so it does not have to be done over and over again. Google's V8 and Webkit's JIT javascript engine already supports several CPUs but not the Power PC or Cell. The Wii, Xbox and PS3 all have Power PC CPUs and are not supported.

For Sony, it already has Home that could benifit from JIT....is the Home client engine already JIT? If so then the work done for that gives Sony a start for a Javascript JIT . If not then the work on the Javascript JIT engine could also be used for Home.

IF Sony is going to use the Cell for other platforms then the work on JIT might be useful for other platforms. Sony just bought back the Nagasaki Cell fabrication plant from Toshiba. Rumors are to produce Cmos imaging elements for cameras. This may be in error and the published Cell patent might be the tip of an iceberg.

 

[patsu]

While a dynamic language JIT compiler has some (new) optimization techniques during run-time, a typed dynamic language should perform even better.

Untyped dynamic language (e.g., JavaScript V8 run-time) should not run as fast as optimized C-code.

Sony acquired the Cell factory back to make CMOS image sensors. What they intend to do for Cell production is unknown to us at this point.

 

[jeff_rigby]

While a dynamic language has some (new) optimization techniques during run-time, a typed dynamic language should perform even better.

Untyped dynamic language (e.g., JavaScript V8 run-time) should not run as fast as optimized C-code.

I can quote the Google Chrome V8 article. The qualifier is, it can be faster than poorly coded C.

If the code is tight enough, the design of the Cell and the memory used by the PS3 gives the PS3 an advantage over other platforms when running a JIT engine.

It's explained that the JIT routine stores a copy of the compiled to native language code and if the same routine is used again it does not need to be recompiled or even loaded again if in the cell SPU memory or XDR memory. There are many repetitive tasks in media which is why the cell performs so well for that and in drawing routines again repetitive tasks which is why the SPU works well as a shader for the RSX/SPU combo.

Going further the first doctorate paper for a Java JIT engine using a SPU mentioned slower performance given larger routines as the PPU is required to setup DMA transfers to/from SPU memory. You then get both PPU and memory conflict/scheduling issues.

There have always been tradeoffs between CISC and RISC CPUs. CISC chips are bound by complex internal routine libraries and registers but use memory less, RISC chips have fewer internal routines but use Memory more. The SPU is a super RISC, an idiot -Savant which must be managed and hand fed by the PPU which is more CISC like. This is a heterogeneous CPU and is how many newer CPUs are designed.

 

[patsu]

I can quote the Google Chrome V8 article. The qualifier is, it can be faster than poorly coded C.

Poorly coded C can run slower than php. I suggest we don't go there. ^_^

 

[Demirug]

The problem here is not RISC vs. CICS. While CELL is still a PowerPC CPU they remove most runtime optimizations. While most desktop CPUs can optimize crappy code during execution CELL requires a code compiler to do this work in advanced. Unfortunately dynamic languages like JavaScript are very hard to optimize at compile time. As a JIT needs to do this although fast the situation becomes worse.

 

[jeff_rigby]

The problem here is not RISC vs. CICS. While CELL is still a PowerPC CPU they remove most runtime optimizations. While most desktop CPUs can optimize crappy code during execution CELL requires a code compiler to do this work in advanced. Unfortunately dynamic languages like JavaScript are very hard to optimize at compile time. As a JIT needs to do this although fast the situation becomes worse.

And we also have that HTML5 is not finished. The javascript engine will most likely need updating.

 

[jeff_rigby]

http://www.mono-project.com/Scripting_With_Mono

Seems like there are tools out there to make JIT easier to implement.

The early results of switching showed that there was a 50 to 150 times performance increase in switching from LSL/interpreted to LSL/Mono.

The Unity3D game design engine uses Mono to provide scripting capabilities to the applications and games built with it by supporting Boo, C# and UnityScript (a strongly-typed version of Javascript which helps make the code faster).

Mono is an open source technology that can be used freely under the terms of the GNU LGPL license. Novell alternatively offers commercial licenses of the Mono runtime if you require to use Mono in any of the following situations:

On Windows or Mac games, if:
Static linking Mono into your application.
Preventing Mono or its class libraries from being upgraded (for example, to prevent gamers from cheating).
You want to add proprietary extensions that you want to keep.
On Consoles where the end user is not allowed to upgrade the Mono runtime and repackage the game:
Wii, PS3 or Xbox360

http://tirania.org/blog/archive/2008/Feb-26.html

Mono is currently being used by a major publisher [1] to script a new version of a popular franchise (the new edition) and Mono is also the engine that drives Unity3D for scripting and SecondLife is beta testing Mono now on their beta grid.

At the conference some people asked as to whether it would be possible to take advantage of the PlayStation3 six SPE processors. During the conference I had no idea that (Feb 2008 there was already a project using Mono on the PS3 with Linux that already does this, but the idea sounded fascinating.

It is particularly fascinating because the SPEs on the PS3 do not have the same limitations than GPU computations have, these are full blown CPUs (with some memory limitations) but still general purpose computation devices.

Paolo pointed me to CellDotNet: A project to make it possible to run .NET code on the Cell architecture.. CellDotNet is basically a JIT compiler (written in entirely in C#) that can compile CIL bytecodes into native code for the PS3 SPE processors (this is a project from Klaus Hansen and Rasmus Halland).

Given that ,NET and LUA are highly structured and lend themselves to JIT more than Javascript does but it appears early on this was possible for homebrew (read individuals with limited resources) to create JIT engines for the cell.

 

[rpg.314]

http://www.mono-project.com/Scripting_With_Mono

Seems like there are tools out there to make JIT easier to implement.



http://tirania.org/blog/archive/2008/Feb-26.html






Given that ,NET and LUA are highly structured and lend themselves to JIT more than Javascript does but it appears early on this was possible for homebrew (read individuals with limited resources) to create JIT engines for the cell.

a) Mono uses use AOT compilation, and NOT JIT compilation on PS3.
b) Lua is just as hard to JIT as JS, as it is also dynamically typed.
c) JITing on PS3 != JITing on Cell due to gameos's enforcement of W^X.

 

[rpg.314]

There have always been tradeoffs between CISC and RISC CPUs. CISC chips are bound by complex internal routine libraries and registers but use memory less, RISC chips have fewer internal routines but use Memory more. The SPU is a super RISC, an idiot -Savant which must be managed and hand fed by the PPU which is more CISC like. This is a heterogeneous CPU and is how many newer CPUs are designed.

BOTH SPU and PPU are RISC's.

 

[scooby_dooby]

What they have in common.. multi-threading.

Sortof... but not really. Chrome splits rendering on one core, and script execution on another other. Realistically you get one thread to render your game. For games, this means you hit a rendering bottleneck almost immediately, and won't get any help from additional cores.

Also, Flash 10.2 is not multithreaded at all, but this is coming soon.

Also, while AIR 2.5 does an embedded HTML5 Compatible Webkit it's only for Desktop Applications. The "HTML" API is not included in AIR for Mobile or AIR for TV.
http://help.adobe.com/en_US/air/build/WS144092a96ffef7cc16ddeea2126bb46b82f-8000.html. This HTML5 featureset is quite limited as well, it's based off Safari 4, a full version behind the latest, and it doesn't include any support for Audio/Video tags, SVG graphics, or Web Workers.


Lastly, Adobe would not be writing any specific codec for H264. Flash Player 10.2 includes StageVideo which offloads all decoding to the GPU, we're still waiting for a build of AIR 2.6 which includes this...