tree: 7ea5fe7f2d0d613a074be82aa9307c3207907b99 [path history] [tgz]
  1. .clang-format
  2. .gitignore
  3. AVDVirglRenderer.cpp
  4. Android.bp
  5. ChecksumCalculator.cpp
  6. ChecksumCalculator.h
  7. ChecksumCalculatorThreadInfo.h
  8. Context.h
  9. EglConfig.h
  10. EglContext.h
  11. EglImage.h
  12. EglSurface.h
  13. EglSync.h
  14. GLESv1.cpp
  15. GLESv1.h
  16. GLESv1_dec/
  17. GLESv3.cpp
  18. GLESv3.h
  19. GLESv3_dec/
  20. Gralloc1.cpp
  21. OpenGLESDispatch/
  22. OpenglRender/
  23. ProtocolUtils.h
  24. README.md
  25. RenderControl.cpp
  26. RenderControl.h
  27. Resource.h
  28. emugl/
  29. include/
  30. libOpenglRender/
  31. libvirglrenderer.lds
  32. renderControl_dec/
host/libs/virglrenderer/README.md

AVDVirglRenderer

This project implements an alternative for ‘virglrenderer’, a part of the Virgil 3D GPU project that normally implements the translation from the virtio-gpu-3d command stream & tgsi/gallium shaders, to desktop OpenGL.

This version of the library keeps translation to a minimum and only works with a true EGL/GLES driver implementation on the host. It won't intercept and translate shaders, and no part of the GL state machine is processed in the emulated guest.

The wire protocol used between the virtio-gpu DRM driver and QEMU's virtio-gpu-3d device is the same as that used by goldfish (the classic Android emulator). Submits (writes) are made with an DRM_VIRTGPU_EXECBUFFER call; the response comes back through a separate memory mapped buffer. Responses are very expensive and are minimized where possible, as they involve a pipeline flush and roundtrip to the host.

Structure

AVDVirglRenderer

Provides the entrypoints expected by QEMU for its libvirglrenderer integration.

This is where contexts, resources and fences are monitored.

RenderControl Header Decoder

The RenderControl is analogous to EGL on the guest side. It has a similar API to EGL, except that not every EGL function can be implemented as one API call, and instead multiple RenderControl calls are made. The RenderControl architecture was precipitated by goldfish's requirement that EGL window surfaces and images would be directly mapped to GL texture names, but in AVDVirglRenderer we preserve them as EGL objects on the host side.

This component contains a decoder for the wire protocol, and stubs for any functions that we do not need to implement. The wire protocol is completely unmodified.

GLESv1 Header Decoder

This component contains a decoder for the wire protocol, and stubs for any functions that we do not need to implement. Only the GL ES 1.1 extensions implemented by SwiftShader are implemented, and only if they are needed by Android. Any extensions provided by the wire protocol that are not supported by either are intentionally stubbed.

GLESv3 Header Decoder

This component contains a decoder for the wire protocol, and stubs for any functions that we do not need to implement. Only the core GL ES 3.0 API is implemented; no ES 2.0 extensions are supported, unless they are remappable to GL ES 3.0 features. GL ES 3.1 is not currently supported. Any extensions provided by the wire protocol that are not supported by either Android or SwiftShader are intentionally stubbed.

Note that we are not stubbing ES 3.1 functions; these will crash if called.

ChecksumCalculatorHeader

This code was taken from the Android emulator. The header has been slightly trimmed but its functionality has not been changed.

ChecksumCalculatorThreadInfo

This header has been added for compatibility with the decoder code generated by the emugen_cuttlefish tool. Unlike the original implementation, it is not thread safe. We do not require thread safety because no decoder state is shared between threads in AVDVirglRenderer without its own locking.

Context

The Context structure represents a virglrenderer context assigned by QEMU. Each time the driver's device node is opened by the guest, a new context is created. In the design of AVDVirglRenderer, there are two kinds of context. The first kind of context is for gralloc, and there is one of these contexts per guest process. The second kind of context is per-thread, used by the EGL/GLES implementation. This second kind of context can receive 3D commands, which are processed in their own thread by AVDVirglRenderer so as to minimize the number of synthetic calls we have to make (such as eglMakeCurrent()).

Resource

The Resource structure represents a virglrenderer resource assigned by QEMU. Each time the driver allocates memory through the device driver's interface, a new resource is created. Resources can be owned by the kernel (for example, the primary framebuffer surfaces), Gralloc (EGL window surfaces or images), or used for other purposes such as the Context response buffer and fencing.

EglConfig

The EglConfig structure maintains a list of available EGLConfigs.

EglContext

The EglContext structure maintains a list of active EGLContexts, and decides when they can be disposed of.

EglImage

The EglImage structure maintains a list of active EGLImageKHRs, and decides when they can be disposed of.

EglSurface

The EglSurface structure maintains a list of active EGLSurfaces, and decides when they can be disposed of.

EglSync

The EglSync structure maintains a list of active EGLSyncKHRs, and decides when they can be disposed of.