eglCreateImageKHR for nested Mir
alexandros.frantzis at canonical.com
Mon Sep 9 12:05:39 UTC 2013
On Fri, Sep 06, 2013 at 09:24:16PM +0300, Alexandros Frantzis wrote:
> Hi all,
> I have been working on eglCreateImageKHR for the Mir EGL platform in
> Mesa, using gbm_bo as the "native pixmap" type (EGL_NATIVE_PIXMAP_KHR).
> This is needed by nested Mir, but could also be useful in general.
> The current state of the (still very hacky) WIP can be found at:
> (it is the diff against https://github.com/RAOF/mesa/ branch
> I have run into the following problem: when a client connects to the
> nested mir server, it fails almost immediately because of what seems to
> be a problem referencing a buffer that was created earlier. In
> particular, we create gbm_bos (using GEM objects internally) for the
> buffers backing the surface of the client, but, sometimes, when trying
> to reference these GEM objects, e.g. when trying to create an EGLImage
> for them we can't find them anymore!
> An interesting observation is that if the client submits the first 3
> buffers slowly (which trigger the gbm_bo creation and EGLImage
> initialization and rendering on the server), the problem doesn't occur,
> which indicates that there is some kind of synchronization problem.
> For anyone interested, things to try with the code above:
> !!! Make sure you run against the modified Mesa
> (e.g. set your LD_LIBRARY_PATH)
> First run the host server:
> $ sudo LD_LIBRARY_PATH=... bin/mir_demo_server_basic -f /tmp/mir_host
> Run the nested server:
> $ sudo LD_LIBRARY_PATH=... bin/mir_demo_server_basic --nested-mode /tmp/mir_host --enable-input off
> Run a normal client and watch the nested server crash:
> $ sudo LD_LIBRARY_PATH=... bin/mir_demo_client_egltriangle
> Run an (initially) slow client and watch it work (I have modified this
> example to start slow and speed up):
> $ sudo LD_LIBRARY_PATH=... bin/mir_demo_client_scroll
> To aid the investigation I created a client that stresses multi-threaded
> gbm_bo and EGLImage creation and rendering, trying to approximate nested
> mir behavior, but I can't get it to fail! :
> $ sudo LD_LIBRARY_PATH=... bin/mir_demo_client_egl_image -m /tmp/mir_host
> Thoughts welcome :)
> Note that I have only tried this on an Intel GPU. It would be interesting
> to see if the behavior is different with Radeon or Nouveau.
Further investigation uncovered that this happens only when using PRIME
fds in Mesa. Using GEM names works correctly.
I have updated the branch lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack/
to send both a PRIME fd and a GEM name for each buffer for testing
The diff (against https://github.com/RAOF/mesa/) at:
allows selecting which handle to use (set USE_PRIME in platform_mir.c to
0 to use GEM names).
More information about the Mir-devel