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