Hi, good morning. Welcome to my lightning talk. In this session, I will talk about software
rendering in AUSB. Some disclaimer about the logos and the product names which I have used
in this presentation. About myself, my name is Amit Pundiz. I work in the narrow. I have been
doing Android bring up and maintenance on the open devices for last 10 plus years now. You
can find new on these channels. The reason for this lightning talk is, again, as I mentioned,
it is the software rendering in Android. And then bring up on newer or the source limited devices
is always challenging, but it is a great learning experience and you get to learn a lot
about the Android operating system. And today, I will share my experience and findings of running
Android with software rendering. For the sake of keeping the things simple from the lightning
talk point of view, I am assuming that the audience has a fair bit of understanding of the
software stack. I will be talking about the graphics, okay, the hardware composer and as
the OpenGLS things. The first things first, why do we need software rendering in Android?
Especially, why do we want bother running an interactive and user-oriented OOS like Android
with software rendering? Considering that the overall system performance will be significantly
slayer compared to when using the hardware accelerators. Especially for graphics intensive
tasks where the Android system will now, in that case, rely on CPU based rendering instead
of the GPU. Now, the ASP-based software rendering can be useful for a number of reasons which
have listed down. These are just based on my experience so far. The obvious bit is that
you do not have a GPU on your device, right? So, I think there is no GPU on the device
or the R&D OSP on a device with a very limited GPU capabilities like some legacy hardware
if you have any. All we are running all testing and write on virtual platforms.
Next up is the broken software. Broken or limited software support for the GPU can also
push you or encourage you to press software and bring on your device. You may be running
your ASP on any device prototype with limited software support or the broken software
support because of missing or legacy GPU binary blobs. Another usual suspect here is
the headless envoy. You are running and write on an embedded or low platform device which
do not depend on display for the functionality. Next up is testing in development. You may
be running and write on software rendering to debug or isolate GPU specific issues.
So, how do we do that? How do we enable software rendering and write? Sift share down
if you guys have aware of it is a software OpenGLS implementation used in Android as well
as in Chromium. They got rid of the OpenGL implementation sometime back and they now rely
on something called Project Angle which is almost native graphics layer engine. Now,
to enable the software rendering in a USB-V used, Angle's OpenGLS implementation on top
of Sift share down as well can implementation. So, it is like this not a single library
which does that now. Earlier it used to be only a single library. If you are an old time
that you must be aware of, lib glls and write, it used to be the thing at that time. Then
Sift share down now we have Sift share up plus Angle. This combination I think it is at
least it is been written as S.W. Angle I used to call it swangle. So, I have not seen
anyone talking, it is been saying it lies swangle but at least in online in groups you can
see that there are always clubbed the words as swangle. These are the software development
do I as configurations which we said the standard product packages specific to Angle,
organ implementation and then the properties. Now, for the complete reference you can take
a look at the linear software built target in a USB. It is already upstream it is part
of a USB. It is a software rendering built target developed and tested on call complex forms
but it is general enough to run on any M64 device. The only catch is the Android boot device
which you have to set is in the SESFS but there is a new solution for that as well.
Here at the top of native simple changes that we did in the others software built target.
First one is that this switch to the OpenGL back end of Skiya instead of the default
Vulcan back end because if you use the Skiya Vulcan back end you will see the display
gages. So, we figured out that its limitation in the software stack and if you just use
the OpenGL Skiya back end you will not at least see that kind of glitch. The system
will still be slow compared to the build if you are running with the hardware accelerated
display but at least you will not see the glitches. Then we disable the compressed image
format to simplify the rendering bits. Next up is bringing up Android with software and
rendering that on virtual display. So, stepping back to the previous slide this targets
still needs an actual display to connect to. So, here I am talking about a virtual display
you can use the virtual iOS in the older days they used to be virtual phone buffer. Now,
we have virtual KMS driver which we make use of. This light target build configuration
with no physical display attached the device. So, to begin with the mixture that the
Linux virtual KMS driver is enabled it can be part of your when the GK module if you
are playing with GKI. If you are using a standard kernel build you can just enable it and
get started that. The device configuration is exactly similar to what we have seen with
what you can find in the in our software builds. We just need to take care of certain
details that can make or break the system. So, make sure that the hardware composer device
is pointed towards the correct set of device display node. If you have more than one display
device driver enabled then you will have more device cards or display cards there. So, just
make sure that when the hardware composer DRM device is pointed to the virtual KMS device
then you need to label the if you have a Linux enabled or enforced then make sure that the
this there be a right card of yours is a GPU device device and it is not a graphics device.
And then the last one is the visible the primary cache. It is very useful we will look
at it just thermal upon this after doing some quick graphs in the code base and you have
because not really mentioned spoken about anywhere else otherwise. So, that it does its its speeds
of the boot time by it doubles your sorry it reduces your boot time to half. If you just boot the
standard configurations you will say you will see that it boots in about 120 seconds. If you
just disable the shaders which it which it compiles the shaders before the boot of time
if you just skip that part because you are not actually displaying anything I do not care about
the display then it can bring down the display to 45 to 60 seconds.
And that is all about it if you have any questions on this please.
Sorry I did not get the question is it about the you have the RGB 555 inside the camera and
the display is huge something and this like request a lot of performance you did you find the
way to avoid that. Oh I am not right that. So, this is just a pure configuration which I am using.
So, the question is that instead of using the default RGB 565 or other
formats if you switch to some other display format then can we reduce the boot time.
So, I am not right any of this what I tried was that since it is a virtual display I do not care
about what if I do not boot with that default can it be displayed or that default.
Oh that the way also okay. So, the question was from the real display point of view again sorry
I am not so other than that compressed image part we are not played with that now.
All right so, David's question is about using it as a production build for a headless device
configuration. So, if you have a device which is capable of because we are not getting rid of
the display subsystem as if I we are just making sure that it is running somewhere in the background
and we are not just dealing with that. So, if a system is capable of performing fine even with
let us say with a software stack still running in the background and then sure yeah.
I do not know if you want to do that. So, depends on the use case for example if you have a device
which is I mean so, if you have a application stack which is based on Android right and you
have few services which because and the services are very tangled up right. So, you do not know
at what point you have dependent service will depend on something which is exposed by surface
flinger or any other graphics stack. So, if you want to take care of that then it makes sense to
have maybe a dummy display stack running in the background. So, that at least your application
which has dependencies on this can keep on running. Then that can also help you migrate your
applications from when device to another device because it is the stack is the same right.
So, if you are running it on a server or if you are running it on an edge device then just take
the build and just just pure guess no idea to work on it but yeah.
All right. I think we are right on time. Thank you very much.