[webkit-dev] Concurrent display list item writing and reading in the GPU process

[Wenson Hsieh]

Hello webkit-dev!

I’m writing to let folks know that we’re planning heavy refactoring around WebKit’s display list architecture (WebCore::DisplayList) as part of a broader effort to use the GPU process for rendering webpages, without significantly regressing performance (particularly, graphics performance).

Currently, when using the GPU process, calls to GraphicsContext methods in the web process are converted into (largely) platform-agnostic DisplayList::Item objects, which are then propagated to the GPU process via IPC in batches of at most several hundred items. In the GPU process, these decoded display list items are then applied to platform-backed GraphicsContexts (e.g. on CoreGraphics platforms, this is a GraphicsContext with a nonnull CGContextRef).

This introduces significant overhead, due to how:

- The web and GPU processes must respectively encode and decode each display list item, adding overhead for each item that is sent and handled. This hampers both the throughput and latency of display list rendering, by making each item slower to process.
- As the web process is generating and batching these display list items, the GPU process cannot immediately begin processing display list items until they have been received as a single batch (i.e. a WebCore::DisplayList). This primarily affects the latency of display list rendering.

To mitigate this, we plan to transition to an architecture wherein display list items are directly written to and read from shared memory between the web and GPU processes. This allows the web process and GPU process to concurrently write and read display list items, and additionally elides the overhead of encoding and decoding each item.

Additionally, to uphold security guarantees in the GPU process, display list items that are stored in shared memory must have no pointers, and may only contain data structures with no pointers; with careful validation, this should prevent a compromised web content process from writing display list items capable of triggering arbitrary code execution in the GPU process.

In working towards this goal, our first step is to refactor DisplayList::Item and all of its subclasses such that they don’t contain any pointers (including vtable pointers), and that they instead reference any “out of line” resources required (for instance, image data, or extended color information, or an arbitrarily complex WebCore::Path) via fixed-size integer identifiers. Data for these resources would be copied into shared memory, with the expectation that this data is (securely) decoded and validated in the GPU process.

While this email is mostly informative, we are also curious whether this overall architecture will be compatible with non-Cocoa ports (for instance, WPE and GTK), as most of our planning so far has been done within the context of enabling GPU process for Cocoa platforms.

Thanks,
whsieh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201028/58cc9f59/attachment.htm>