1# AVDVirglRenderer 2 3This project implements an alternative for 'virglrenderer', a part of the 4Virgil 3D GPU project that normally implements the translation from the 5virtio-gpu-3d command stream & tgsi/gallium shaders, to desktop OpenGL. 6 7This version of the library keeps translation to a minimum and only works with 8a true EGL/GLES driver implementation on the host. It won't intercept and 9translate shaders, and no part of the GL state machine is processed in the 10emulated guest. 11 12The wire protocol used between the virtio-gpu DRM driver and QEMU's 13virtio-gpu-3d device is the same as that used by goldfish (the classic Android 14emulator). Submits (writes) are made with an `DRM_VIRTGPU_EXECBUFFER` call; the 15response comes back through a separate memory mapped buffer. Responses are very 16expensive and are minimized where possible, as they involve a pipeline flush and 17roundtrip to the host. 18 19## Structure 20 21### [`AVDVirglRenderer`](AVDVirglRenderer.cpp)[](#AVDVirglRenderer) 22 23Provides the entrypoints expected by QEMU for its libvirglrenderer integration. 24 25This is where contexts, resources and fences are monitored. 26 27### [`RenderControl`](RenderControl.cpp) [`Header`](RenderControl.h) [`Decoder`](renderControl_dec)[](#RenderControl) 28 29The RenderControl is analogous to EGL on the guest side. It has a similar API to 30EGL, except that not every EGL function can be implemented as one API call, and 31instead multiple RenderControl calls are made. The RenderControl architecture 32was precipitated by goldfish's requirement that EGL window surfaces and images 33would be directly mapped to GL texture names, but in AVDVirglRenderer we 34preserve them as EGL objects on the host side. 35 36This component contains a decoder for the wire protocol, and stubs for any 37functions that we do not need to implement. The wire protocol is completely 38unmodified. 39 40### [`GLESv1`](GLESv1.cpp) [`Header`](GLESv1.h) [`Decoder`](GLESv1_dec)[](#GLESv1) 41 42This component contains a decoder for the wire protocol, and stubs for any 43functions that we do not need to implement. Only the GL ES 1.1 extensions 44implemented by SwiftShader are implemented, and only if they are needed by 45Android. Any extensions provided by the wire protocol that are not supported by 46either are intentionally stubbed. 47 48### [`GLESv3`](GLESv3.cpp) [`Header`](GLESv3.h) [`Decoder`](GLESv3_dec)[](#GLESv3) 49 50This component contains a decoder for the wire protocol, and stubs for any 51functions that we do not need to implement. Only the core GL ES 3.0 API is 52implemented; no ES 2.0 extensions are supported, unless they are remappable to 53GL ES 3.0 features. GL ES 3.1 is not currently supported. Any extensions 54provided by the wire protocol that are not supported by either Android or 55SwiftShader are intentionally stubbed. 56 57Note that we are *not* stubbing ES 3.1 functions; these will crash if called. 58 59### [`ChecksumCalculator`](OpenglRenderer/ChecksumCalculator.cpp)[`Header`](ChecksumCalculator.h)[](#ChecksumCalculator) 60 61This code was taken from the Android emulator. The header has been slightly 62trimmed but its functionality has not been changed. 63 64### [`ChecksumCalculatorThreadInfo`](ChecksumCalculatorThreadInfo.h)[](#ChecksumCalculatorThreadInfo) 65 66This header has been added for compatibility with the decoder code generated by 67the `emugen_cuttlefish` tool. Unlike the original implementation, it is not 68thread safe. We do not require thread safety because no decoder state is shared 69between threads in AVDVirglRenderer without its own locking. 70 71### [`Context`](Context.h)[](#Context) 72 73The Context structure represents a virglrenderer context assigned by QEMU. Each 74time the driver's device node is opened by the guest, a new context is created. 75In the design of AVDVirglRenderer, there are two kinds of context. The first 76kind of context is for `gralloc`, and there is one of these contexts per guest 77process. The second kind of context is per-thread, used by the EGL/GLES 78implementation. This second kind of context can receive 3D commands, which are 79processed in their own thread by AVDVirglRenderer so as to minimize the number 80of synthetic calls we have to make (such as eglMakeCurrent()). 81 82### [`Resource`](Resource.h)[](#Resource) 83 84The Resource structure represents a virglrenderer resource assigned by QEMU. 85Each time the driver allocates memory through the device driver's interface, a 86new resource is created. Resources can be owned by the kernel (for example, the 87primary framebuffer surfaces), Gralloc (EGL window surfaces or images), or used 88for other purposes such as the Context response buffer and fencing. 89 90### [`EglConfig`](EglConfig.h)[](EglConfig) 91 92The EglConfig structure maintains a list of available EGLConfigs. 93 94### [`EglContext`](EglContext.h)[](EglContext) 95 96The EglContext structure maintains a list of active EGLContexts, and decides 97when they can be disposed of. 98 99### [`EglImage`](EglImage.h)[](EglImage) 100 101The EglImage structure maintains a list of active EGLImageKHRs, and decides 102when they can be disposed of. 103 104### [`EglSurface`](EglSurface.h)[](EglSurface) 105 106The EglSurface structure maintains a list of active EGLSurfaces, and decides 107when they can be disposed of. 108 109### [`EglSync`](EglSync.h)[](EglSync) 110 111The EglSync structure maintains a list of active EGLSyncKHRs, and decides 112when they can be disposed of. 113