Chromium GPU architecture roadmap

[Tom Wiltzius]

Hi all,

The Chromium graphics stack is quite complicated, not least because we have a very large feature configuration matrix -- today we render very differently on different platforms.

To help illuminate what's currently turned on where, and importantly what we're trying to deprecate, some of the folks on the graphics team[1] put together a spreadsheet summarizing our configuration modes. Please refer to

https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome/gpu-architecture-roadmap

for a rundown of the major graphics features in Chromium (e.g. threaded compositing, impl-side painting, ubercompositor, etc) as well as their current status on each configuration. Notably, this also includes our intended end-state of each configuration, and the code paths we want to eventually remove.

If anyone (e.g. content embedders) have long-term dependencies on any of the paths eventually going away, or are considering adding new such dependencies, please get in touch to talk about potential alternatives.

Cheers,

Tom 

[1] thanks to danakj, enne, nduca

[akash.ch...@gmail.com]

Hi Tom,

I want to understand display stack of Chrome OS (above Linux display stack i.e. X-server, mesa, etc).

I have read documents from https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome/gpu-architecture-roadmap , and I want to see & debug how those things are implemented.

So, please help me & suggest guidelines how should I proceed.

Also, GPU process, Compositor, etc. are part of part of Chromium and not ChromiumOS. If I am correct, then what exactly Chrome OS display stack consist of?

Thanks,

Akash H.

[Robert Kroeger]

Hi Akash,

On Mon, Apr 28, 2014 at 10:29 AM, <akash.ch...@gmail.com> wrote:

Hi Tom,

I want to understand display stack of Chrome OS (above Linux display stack i.e. X-server, mesa, etc).

This is quite complicated. :-)

 

I have read documents from https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome/gpu-architecture-roadmap , and I want to see & debug how those things are implemented.

So, please help me & suggest guidelines how should I proceed.

Also, GPU process, Compositor, etc. are part of part of Chromium and not ChromiumOS. If I am correct, then what exactly Chrome OS display stack consist of?

Currently: X11 on DRM/KMS kernel with GL (typically mesa but its platform dependent) provided as a platform library and dynamically linked into Chrome.

This is liable to change: X11 contains functionality not needed on CrOS where windows are managed by aura. We are in the process of developing an alternative where Chrome sits  via the ozone interface directly above the DRM/KMS kernel interface extended with atomic flips and dmafence.

Rob.

[akash h]

Hi Robert,

Thanks for reply.

On Tuesday, April 29, 2014 7:20:40 AM UTC-7, Robert Kroeger wrote:

Hi Akash,

On Mon, Apr 28, 2014 at 10:29 AM, <akash.ch...@gmail.com> wrote:

Hi Tom,

I want to understand display stack of Chrome OS (above Linux display stack i.e. X-server, mesa, etc).

This is quite complicated. :-)

 

I have read documents from https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome/gpu-architecture-roadmap , and I want to see & debug how those things are implemented.

So, please help me & suggest guidelines how should I proceed.

Also, GPU process, Compositor, etc. are part of part of Chromium and not ChromiumOS. If I am correct, then what exactly Chrome OS display stack consist of? 

Currently: X11 on DRM/KMS kernel with GL (typically mesa but its platform dependent) provided as a platform library and dynamically linked into Chrome.

So, I think, I should be starting with Aura (interacting with X-server) for window managing, and with GPU process (interacting with mesa) for rendering. Please suggest that should I go with this path for understanding ChromeOS Graphics stack.

Also, is architecture dependent(on x-server,etc) module will be aura & GPU process(on Mesa) and h/w dependent modules similar to linux? 

 

This is liable to change: X11 contains functionality not needed on CrOS where windows are managed by aura. We are in the process of developing an alternative where Chrome sits  via the ozone interface directly above the DRM/KMS kernel interface extended with atomic flips and dmafence.

Will this alternative have platform dependent (on Wayland,X11etc) module as ozone & h/w dependent(DRM/KMS) similar to linux?

And, is it essential to know Chromium browser Graphics for Chromium OS graphics?

Please help me on above doubts.

Thanks,

Akash H.