|adventures in EGL image buffer passing
||[Dec. 17th, 2013|05:06 pm]
So I've been looking into how I can do some buffer passing with EGL and OpenGL with a view to solving my split renderer/viewer problem for qemu.|
contains the hacks I've been playing with so far.
The idea is to have a rendernode + gbm using server side renderer, that creates textures and FBOs attached to them, renders into them, then sends them to a client side, which renders the contents to the screen using GL rendering.
This code reuses keithp's fd passing demo code and some of dvdhrm's simple dma-buf code.
Firstly the server uses GBM and rendernodes to create a texture, that it binds to a FBO. It generates an EGLImage from the texture using EGL_GL_TEXTURE_2D_KHR, then uses EGL_MESA_drm_image to get a handle for it, then uses libdrm drmPrimeHandleToFD to create an fd to pass to the server. It passes the fd using the fdpassing code. It then clears the texture, sends the texture info to the client, along with a dirty rect, clears it again, and sends another dirty rect.
The client side, uses EGL + GLES2 with EXT_image_dma_buf_import to create an EGLImage from the dma-buf, then uses GL_OES_EGL_image to create a 2D texture from the EGLImage then just renders the texture to a window.
Shortcomings I've noticed in the whole stack so far:
a) asymmetric interfaces abound:
1) we have an EGLImage importer for dma-buf EXT_image_dma_buf_import, but we have no EGLImage dma-buf exporter yet - hence the MESA_drm_image + libdrm hack.
2) we have an EGLImage exported for Desktop OpenGL, EGL_KHR_gl_image works fine. But we only have EGLImage importers for GLES, GL_OES_EGL_image - hence why the client is using GLES2 to render not GL like I'd like.
b) gallium is missing dma-buf importing via EXT_image_dma_buf_import, I have a quick patch, since we have the ability to import from fds just not from dma-bufs, I should send out my first hack on this.
The demo also has color reversing issues I need to sort out, due to gallium code needing a few more changes I think, but I've gotten this to at least run on my machine with nouveau and the hacked up dma-buf importer patch.
|disconnected VM operation and 3D
||[Dec. 10th, 2013|02:26 pm]
So one of the stumbling blocks on my road to getting 3D emulation in a VM is how most people use qemu in deployed situations either via libvirt or GNOME boxes frontends.|
If you use are using libvirt and have VMs running they have no connection to the running user session or user X server, they run as the qemu user and are locked down on what they can access. You can restart your user session and the VM will keep trucking. All viewing off the VM is done using SPICE or VNC. GNOME Boxes is similar except it runs things as the user, but still not tied to the user session AFAIK (though I haven't confirmed).
So why does 3D make this difficult?
Well in order to have 3D we need to do two things.
a) talk to the graphics card to render stuff
b) for local users, show the user the rendered stuff without reading it back into system RAM, and sticking it in a pipe like spice or vnc, remote users get readback and all the slowness it entails.
No in order to do a), we face a couple of would like to have scenarios:
1. user using open source GPU drivers via mesa stack
2. user using closed source binary drivers like NVIDIA or worse fglrx.
How to access the graphics card normally is via OpenGL and its window APIs like GLX. However this requires a connection to your X server, if your X server dies your VM dies, if your session restarts your VM dies.
For scenario 1, where we have open source kms based drivers, the upcoming render nodes support in the kernel will allow process outside the X server control to use the capabilities of the graphics card via the EGL API. This means we can render in a process offscreen. This mostly solves problem (a) how to talk to the graphics card at all.
Now for scenario 2, so far NVIDIA has mostly got no EGL support for its desktop GPUs, so in this case we are kinda out in the cold, until they have at least EGL support, in terms of completely disconnecting the rendering process from the running user X server lifecycle.
This leaves problem (b), how do we get the stuff rendered using EGL back to the user session to display it. My first initial hand-wave in this area involved EGL images and dma-buf, but I get the feeling on subsequent reads that this might not be sufficient enough for my requirements. It looks like something like the EGLStream extension might be more suitable, however EGLstream suffers from only being implemented in the nvidia tegra closed source drivers from what I can see. Another option floated was to somehow use an embedded wayland client/server somewhere in the mix, I really haven't figured out the architecture for this yet (i.e. which end has the compositor and which end is the client, perhaps we have both a wayland client and compositor in the qemu process, and then a remote client to display the compositor output, otherwise I wonder about lifetime and disconnect issues). So to properly solve the problem for open source drivers I need to either get EGLstream implemented in mesa, or figure out what the wayland hack looks like.
Now I suppose I can assume at some stage nvidia will ship EGL support with the necessary bits for wayland on desktop x86 and I might not have to do anything special and it will all work, however I'm not really sure how to release anything in the stopgap zone.
So I suspect initially I'll have to live with typing the VM lifecycle to the logged in user lifecycle, maybe putting the VM into suspend if the GPU goes away, but again figuring out to integrate that with the libvirt/boxes style interfaces is quite tricky. I've done most of my development using qemu SDL and GTK+ support for direct running VMs without virt-manager etc. This just looks ugly, though I suppose you could have an SDL window outside the virt-manager screen and virt-manager could still use spice to show you the VM contents slower, but again it seems sucky. Another crazy idea I had was to have the remote viewer open a socket to the X server and pass it through another socket to the qemu process, which would build an X connection on top of the pre opened socket,
therefore avoiding it having to have direct access to the local X server. Again this seems like it could be a largely ugly hack, though it might also work on the nvidia binary drivers as well.
Also as a side-note I discovered SDL2 has OpenGL support and EGL support, however it won't use EGL to give you OpenGL only GLES2, it expects you to use GLX for OPENGL, this is kinda fail since EGL with desktop OpenGL should work fine, so that might be another thing to fix!
||most recent entries