notes

[webkit_codecamp] / notes

Hi, I am Eleni Maria Stea and I am going to talk to you about a few
ideas I explored and experiments I've ran concerning the adoption of
ANGLE in WebKit/WPE.

Before I begin, let's se what ANGLE is and what we want to do with it.

So,ANGLE is an EGL/GLES implementation.

GLES is the API we use to render graphics with the GPU
and EGL is the API we use to create the GLES context

Both are implemented on top of other APIs.
In case of EGL these APIs can be the native system EGL, GLX, gbm or others.
In case of GLES they can be the native system driver GLES, OpenGL, Vulkan
or others.

This is because the primary purpose of ANGLE is to provide an EGL/GLES
implementation to systems lacking it.

The users can set the backend they prefer using some extra EGL
extensions provided by ANGLE in eglext_angle.h header file.

On WebKit we'd like to use ANGLE in WebGL two that is implemented in
GLES two. The main reason is the performance.

But there is a problem with our current design:
As ANGLE renders on a GLES 2 texture created by an ANGLE context
and the WebKit graphics pipeline renders on OpenGL textures that are
later assembled in one by the WebKit compositor, we currently need to
copy the WebGL texture data from an ANGLE texture to an OpenGL one.

So all the experiments I am going to present are to replace this copy
with something better.

Let's see a list of them.

First I've written a program that uses ANGLE to render an image on an X11
window and the native system drivers to render another image on another
X11 window and display them.

That was to create a similar situation to the one we have on WebKit.

Then, I experimented with shared context and textures. I've created a
shared texture between the native context and the native context of the
ANGLE backend.

Then I filled it using the ANGLE context and displayed the result using
the native driver context. I had to abandon the shared context idea
for reasons that I'll explain later.

My next experiment was to use the Linux kerne dma buffers framework to
associate two textures with the same kernel memory. Then filling one
texture was automatically filling the other. This method seemed to do
exactly what we want and so I am going to use it in WebKit as well.

Last experiment was to try something similar but with multiple processes.
We might need it in the future.

Let's see them in detail.

First experiment

For all my experiments I've written small standalone programs because
WebKit is complex and building it takes ages. So, in order to use ANGLE
in them I needed to build ANGLe with debugging symbols, and to find some
way to use two implementations of the same API in the same program.

So the first step of the first experiment was to set up ANGLE for debugging
with GDB. I will quickly mention that ANGLE by default redirects the
debugging symbols and uses non-standard paths so I had to modify the
build system arguments and the GDB settings to be able to step into ANGLE
functions.

You can read about these in my blog post.

So in this test, I've rendered two images one from ANGLE context and
one from EGL like in this screenshot where the green image is the ANGLE one
and the XOR pattern comes from the native driver.

In order to have both implementations working together I linked with the
system driver libEGL and libGLES and I dynamically opened ANGLE's libEGL
and libGLES and loaded each EGL and gl function prefixed by angle_.

One other thing I needed for this experiment to work was to invalidate the
ANGLE context before every draw call. This is an interesting ANGLE problem.

ANGLE is using some sort of internal context caching. This is to avoid
calling MakeCurrent when it's not absolutely necessary. So every time we
call angle_MakeCurrent ANGLE checks if the context has been changed and if
not it ignores the call.

When we use two contexts from two drivers in the same process ANGLE
considers it's the only EGL implementation available in the program.
So, in a rendering loop like the one of the slide, ANGLE would always
see angle_MakeCurrent being called with the same context and wouldn't
update it. 
A simple solution is to invalidate it by calling angle_MakeCurrent using
a null context at the top of display. This problem wouldn't happen with
threads or multiple processes but it's interesting to know it.

You can read more about these changes in my blog in the blog post sections
mentioned in the slide.

Let's see the next experiment. In this one I tried to exchange texture data
using shared textures and shared context.

So, what's shared context?

When we create a new context with EGL we can set an existing context
as parameter and use it as "shared". After that all textures created by
the shared context can be directly accessed from the other context without
leaving the GPU.

For the shared context to work both contexts must be created by the same
process and both context must be created by the same API.

This means that we can't use shared context directly between EGL and ANGLE,
but we can use it between the EGL/OpenGL native system driver and the
EGL/OpenGL ANGLE backend.

==========

To do so in WebKit, we'd need to force the EGL/OpenGL backend in ANGLE
and write an ANGLE extension that can tell ANGLE when the shared
context is native and not ANGLE so that it's used in the backend call.

=========

This is how I had designed this extension. In the first picture of the
slide we see how we'd create shared context with native EGL and with
ANGLE.

In the second image we see how we'd pass a native context to ANGLE. One
of the EGL attributes passed to angle_eglCreateContext should indicate
that the context is native
==========

And this is what happens internally in ANGLE:
When the extension attribute is set we create a shared context in the
backend. When not, we handle the shared context as ANGLE shared context.

===========

Why we've rejected this method?
Main reason is that we plan to split the graphics operations in
multiple processes on WebKit.

But fortunately, there was a better approach to follow.

=============================

In that approach, I've used a Linux kernel framework for content sharing:
DMA buffers.

========================

This framework can be used to import dma buffers that are used 
as backing storage for textures from other drivers. This is handy
because if two textures use the same dma buffer storage, filling
one will fill the other.

It has some advantages like that it can easily used by EGL as there are
EGL extensions for it.
it's driver independent
it works with multiple processes and

as long as ANGLE can implement and expose the extensions to import a
dma buffer it's also angle backend independent.

The only problem is that DMA buffers are used from Linux only while
shared context is universal. But in this particular WebKit backend,
we don't care.

===================================

I have a list of the EGL extensions that can be used to share a buffer
among drivers and links to the two example programs I've written.

====================================

Let's see how we could access a DMA buffer from context A in context B.
In this example texture texA corresponds to contextA and texture texB is
from texture B.

In the exporter that is context A, we create an EGL image from contextA
and we export some information about it as well as the file descriptor
that corresponds to its underlying kernel dma buffer.

struct tex_storage_info stores the extra information.

=======================================

In the importer that is context B we can then
create another image that accesses the dma buffer using
the file descriptor and the information we extracted before

and we can use it to create another texture tex B using
where the underline dma buffer is the imported one

Then filling tex B will fill tex A.

=========================================

I've followed these steps with context A being native and context B
being ANGLE and created a similar case to the one we had in WebKit.

It worked well! So, I've tested also the multiple processes case.

==============================

DMA buffers seem to work with multiple processes but require some sort
of Interprocess communication to exchange the file descriptor and the
information about the buffer we've seen before.

I've found a client server example that uses unix sockets to exchange the
file descriptor and works well. Code is on gitlab.

================================

So, finally let's see if this could be integrated to WebKit. 

The extensions to import dma buffers are fully implemented and exposed in
ANGLE and so in WebGL we could import a dma buffer from a graphics pipeline
texture when we create the WebGL render target.

The extension to export dma buffers is implemented on Mesa and so it can be
used in main pipeline. In case it's not found we could fallback to some
alternative that is copying or maybe libgbm.

So this week I am investigating what needs to be done on WebKit.

- I've build ANGLE and fixed the compile errors of that backend
- I am currently fixing some link errors (unfortunately there's one I 
haven't found yet)
- and I've taken a look at the code where I need to make the change.

==========================

References... I intend to upload these slides, and so I've appended a list
of links that could be useful in this task at the end. Feel free to
take a look at it

============================

And Closing
I'd like to thank you very much for watching my talk and for
giving me the opportunity to work on this task!

Goodbye and have a nice day or evening!

==========================