Thursday, 22 July 2010

When accleration came to browser

HW accelerating in website rendering has become an hot topic along the HTML5. Mozillas answer to this demand is their new Layers architecture.
Mozilla's Layers allows browser to take the suitable parts of the rendering to GPU and of course along that to get some eye candy to the end users. Idea is to divide the logically different parts of the rendered content to different layers allowing better division between the CPU and GPU.

The Layers will structure a layer tree which constructs the final webpage. To simplify, they have a container (representing the surface) and its leafs (including the actual graphical data). The final render is constructed from the textures generated from the leafs and composited to the screen.

The basic layer infra will include ThebesLayers, ContainerLayers and a LayerManager.

The Manager is responsible of constructing the layer tree and rendering that to the destination context. The rendering is always happening as an result of an transaction to the tree and only happening to the visible region parts of the texture.

The Container layers task is to group together the child layers beneath it. It represents the surface into which its children are composited and handles the Z order of the its children.

Thebes in general is nothing new. It has been part of the Mozilla gfx architecture already quite awhile as an C++ wrapper for Cairo API's and as an API for text handling.
The ThebesLayer abstracts the Thebes surface which is used to display items that will be rendered (surprise, surpise) using Thebes. So Cairo Image surface drawn to by Cairo. The question is of course - why not doing this directly with Cairo? Why the wrapper? - Some discussions about this from Bas's blog comments.

There is bit of an older bug in Mozilla bugzilla explaining this basic functionality in detailed. In principle what you get with the basic functionality is what you already have - Cairo content shown to the screen. Of course besides the basic functionality you will also need some additional layers for video, something for webgl plus you would also like to have optimized way of doing the rendering. So not all about just basics.

What from my point of view makes this layers especially in interesting are the plans to bring layers to also to Fennec 2.0 along the other goodies like Electrolysis. It will be most definitely interesting to see how it performs and behaves in a more limited environment.

BTW the first bits of layers are already available through the latest nightly builds of Firefox4. The usage of the layers is still limited to Windows/GL, full-screen video only but the sources are available for seeing and testing.

Monday, 5 July 2010

Difficulty of developing Open Source Linux drivers for GPU

During the last few days there as been an active discussion ongoing at dri-devel list about Open Source Graphics drivers. The discussion was initiated by Qualcomm's RFC message - [RFC] Qualcomm 2D/3D graphics driver.

Qualcomm's Linux team has been working on Open Sourced Kernel drivers for their chipset. What they have done so far is that they have build DRM driver with a limited set of supported functionality to enable DRI2. Their own userland parts of the drivers do still utilize the KGSL (Kernel Graphics Support Layer) interface to allocate memory making DRM just as an API to be more closer with the mainstream Linux Graphics stack. Qualcomm does still have some plans in the future to move to an standard design - possibly TTM.

The dri-devel list the opinions about drivers with an userland binary blobs was made quite clear - if you aren't going to open the whole drivers don't try to push them to mainline. Basically the door was slammed from the Qualcomm efforts for pushing the drivers in.

In between the lines I think there were some excellent point made in this discussion.
The bottom line is that the community cannot work with the drivers if there exists and dependency to closed sourced userland - this is definitely clear. With this kind of an setup it is just impossible to work with the drivers. On the otherhand if the community is going to bombard down all the drivers with the closed userland parts (even without making sure what are the attemts to open source them) how are we ever going to see open sourced mobile GPU drivers? From my point of view the community also has the means to guide this work to right direction - giving comments to the request. It really seems that the Qualcomm guys do have the enthusiasm to develop the open source drivers. How about making sure that these guys are taking the correct steps also with the userland and making sure that the Kernel bits are as they should?