-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
+00:00:04 00:12:53
+Hi, I am Eleni Maria Stea and I am going to talk to you about some
+ideas I explored and the 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.
+=======================
+
+Before I begin, let's se what ANGLE is and what we want to do with it
+in WebKit.
So,ANGLE is an EGL/GLES implementation.
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
+As ANGLE renders on a GLES two 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
+later assembled 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.
+===================
+
+Let's see a list of these experiments.
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
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
+In the follow up slides I am going to explain them in detail.
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
+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
+with GDB. 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.
+You can read about these modifications 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
+==========================
+
+So in my first test, I've rendered two images. one from a context
+created with ANGLE and
+one with 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
+One 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
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.
+So, in a rendering loop like the one of the slide, ANGLE would not be
+aware of any EGL changes to the context (for example that EGL changed
+a texture) it will only see angle_MakeCurrent being called with the
+same context and so, it might not update it.
+
+In that case we'd need to invalidate the cached context by calling
+angle_MakeCurrent using a null context at the beginning 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 in my blog in the blog post sections
+mentioned in the bullets.
-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
+Let's jump to 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.
+the shared context can be directly accessed from the new context while
+in 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.
+process and both contexts 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.
+This means that we couldn't use shared context directly between EGL and ANGLE,
+but we could use it between the EGL/OpenGL native system driver and the
+EGL/OpenGL ANGLE backend that uses the native driver as well.
==========
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
+and to write an ANGLE extension that could tell ANGLE when the shared
context is native and not ANGLE so that it's used in the backend call.
=========
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.
+These are a few programs I've written to test the extension, and the ANGLE
+shared context implementation
===========
Why we've rejected this method?
========================
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.
+as backing storage for textures from other drivers. It is handy
+because if two textures from two drivers 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.
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.
+from context B.
-In the exporter that is context A, we create an EGL image from contextA
+In the exporter that is context A, we create an EGL image from tex A
and we export some information about it as well as the file descriptor
that corresponds to its underlying kernel dma buffer.
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 worked well, filling a texture would fill the other without
+copy which is what we want in WebKit!
+So, I've tested also the multiple processes case.
==============================
projects / webkit_codecamp / commitdiff