WEBVTT 00:00.000 --> 00:11.840 Hi, good morning. Welcome to my lightning talk. In this session, I will talk about software 00:11.840 --> 00:18.040 rendering in AUSB. Some disclaimer about the logos and the product names which I have used 00:18.040 --> 00:26.480 in this presentation. About myself, my name is Amit Pundiz. I work in the narrow. I have been 00:26.480 --> 00:33.280 doing Android bring up and maintenance on the open devices for last 10 plus years now. You 00:33.280 --> 00:40.760 can find new on these channels. The reason for this lightning talk is, again, as I mentioned, 00:40.760 --> 00:46.720 it is the software rendering in Android. And then bring up on newer or the source limited devices 00:46.720 --> 00:53.440 is always challenging, but it is a great learning experience and you get to learn a lot 00:53.440 --> 00:59.880 about the Android operating system. And today, I will share my experience and findings of running 00:59.880 --> 01:05.560 Android with software rendering. For the sake of keeping the things simple from the lightning 01:05.560 --> 01:11.160 talk point of view, I am assuming that the audience has a fair bit of understanding of the 01:11.160 --> 01:19.280 software stack. I will be talking about the graphics, okay, the hardware composer and as 01:19.280 --> 01:26.280 the OpenGLS things. The first things first, why do we need software rendering in Android? 01:26.280 --> 01:34.960 Especially, why do we want bother running an interactive and user-oriented OOS like Android 01:34.960 --> 01:39.720 with software rendering? Considering that the overall system performance will be significantly 01:39.720 --> 01:46.160 slayer compared to when using the hardware accelerators. Especially for graphics intensive 01:46.160 --> 01:53.160 tasks where the Android system will now, in that case, rely on CPU based rendering instead 01:53.160 --> 02:01.520 of the GPU. Now, the ASP-based software rendering can be useful for a number of reasons which 02:01.520 --> 02:07.920 have listed down. These are just based on my experience so far. The obvious bit is that 02:07.920 --> 02:14.320 you do not have a GPU on your device, right? So, I think there is no GPU on the device 02:14.320 --> 02:22.080 or the R&D OSP on a device with a very limited GPU capabilities like some legacy hardware 02:22.080 --> 02:29.720 if you have any. All we are running all testing and write on virtual platforms. 02:29.720 --> 02:36.120 Next up is the broken software. Broken or limited software support for the GPU can also 02:36.120 --> 02:41.280 push you or encourage you to press software and bring on your device. You may be running 02:41.280 --> 02:48.560 your ASP on any device prototype with limited software support or the broken software 02:48.560 --> 02:58.720 support because of missing or legacy GPU binary blobs. Another usual suspect here is 02:58.720 --> 03:04.080 the headless envoy. You are running and write on an embedded or low platform device which 03:04.080 --> 03:12.680 do not depend on display for the functionality. Next up is testing in development. You may 03:12.680 --> 03:19.680 be running and write on software rendering to debug or isolate GPU specific issues. 03:19.680 --> 03:28.920 So, how do we do that? How do we enable software rendering and write? Sift share down 03:28.920 --> 03:34.120 if you guys have aware of it is a software OpenGLS implementation used in Android as well 03:34.120 --> 03:39.560 as in Chromium. They got rid of the OpenGL implementation sometime back and they now rely 03:39.560 --> 03:46.560 on something called Project Angle which is almost native graphics layer engine. Now, 03:46.560 --> 03:53.000 to enable the software rendering in a USB-V used, Angle's OpenGLS implementation on top 03:53.000 --> 03:59.040 of Sift share down as well can implementation. So, it is like this not a single library 03:59.040 --> 04:05.480 which does that now. Earlier it used to be only a single library. If you are an old time 04:05.480 --> 04:10.720 that you must be aware of, lib glls and write, it used to be the thing at that time. Then 04:10.720 --> 04:17.160 Sift share down now we have Sift share up plus Angle. This combination I think it is at 04:17.160 --> 04:25.360 least it is been written as S.W. Angle I used to call it swangle. So, I have not seen 04:25.360 --> 04:29.640 anyone talking, it is been saying it lies swangle but at least in online in groups you can 04:29.640 --> 04:36.320 see that there are always clubbed the words as swangle. These are the software development 04:36.320 --> 04:42.960 do I as configurations which we said the standard product packages specific to Angle, 04:43.040 --> 04:50.720 organ implementation and then the properties. Now, for the complete reference you can take 04:50.720 --> 04:55.640 a look at the linear software built target in a USB. It is already upstream it is part 04:55.640 --> 05:03.240 of a USB. It is a software rendering built target developed and tested on call complex forms 05:03.240 --> 05:10.720 but it is general enough to run on any M64 device. The only catch is the Android boot device 05:10.840 --> 05:16.840 which you have to set is in the SESFS but there is a new solution for that as well. 05:16.840 --> 05:22.840 Here at the top of native simple changes that we did in the others software built target. 05:22.840 --> 05:29.080 First one is that this switch to the OpenGL back end of Skiya instead of the default 05:29.080 --> 05:32.880 Vulcan back end because if you use the Skiya Vulcan back end you will see the display 05:32.880 --> 05:38.360 gages. So, we figured out that its limitation in the software stack and if you just use 05:38.440 --> 05:44.440 the OpenGL Skiya back end you will not at least see that kind of glitch. The system 05:44.440 --> 05:49.840 will still be slow compared to the build if you are running with the hardware accelerated 05:49.840 --> 05:56.840 display but at least you will not see the glitches. Then we disable the compressed image 05:56.840 --> 06:08.320 format to simplify the rendering bits. Next up is bringing up Android with software and 06:08.320 --> 06:15.200 rendering that on virtual display. So, stepping back to the previous slide this targets 06:15.200 --> 06:20.240 still needs an actual display to connect to. So, here I am talking about a virtual display 06:20.240 --> 06:25.680 you can use the virtual iOS in the older days they used to be virtual phone buffer. Now, 06:25.680 --> 06:32.240 we have virtual KMS driver which we make use of. This light target build configuration 06:32.240 --> 06:37.920 with no physical display attached the device. So, to begin with the mixture that the 06:38.000 --> 06:44.480 Linux virtual KMS driver is enabled it can be part of your when the GK module if you 06:44.480 --> 06:49.760 are playing with GKI. If you are using a standard kernel build you can just enable it and 06:49.760 --> 06:55.680 get started that. The device configuration is exactly similar to what we have seen with 06:57.760 --> 07:04.320 what you can find in the in our software builds. We just need to take care of certain 07:05.280 --> 07:10.000 details that can make or break the system. So, make sure that the hardware composer device 07:10.960 --> 07:17.680 is pointed towards the correct set of device display node. If you have more than one display 07:17.680 --> 07:24.240 device driver enabled then you will have more device cards or display cards there. So, just 07:24.240 --> 07:30.560 make sure that when the hardware composer DRM device is pointed to the virtual KMS device 07:31.520 --> 07:39.680 then you need to label the if you have a Linux enabled or enforced then make sure that the 07:39.680 --> 07:45.680 this there be a right card of yours is a GPU device device and it is not a graphics device. 07:48.480 --> 07:55.680 And then the last one is the visible the primary cache. It is very useful we will look 07:55.680 --> 08:02.080 at it just thermal upon this after doing some quick graphs in the code base and you have 08:02.080 --> 08:08.560 because not really mentioned spoken about anywhere else otherwise. So, that it does its its speeds 08:08.560 --> 08:15.280 of the boot time by it doubles your sorry it reduces your boot time to half. If you just boot the 08:15.280 --> 08:21.200 standard configurations you will say you will see that it boots in about 120 seconds. If you 08:21.520 --> 08:26.080 just disable the shaders which it which it compiles the shaders before the boot of time 08:26.080 --> 08:30.240 if you just skip that part because you are not actually displaying anything I do not care about 08:30.240 --> 08:34.400 the display then it can bring down the display to 45 to 60 seconds. 08:37.520 --> 08:41.840 And that is all about it if you have any questions on this please. 08:51.200 --> 09:00.000 Sorry I did not get the question is it about the you have the RGB 555 inside the camera and 09:00.000 --> 09:08.400 the display is huge something and this like request a lot of performance you did you find the 09:08.400 --> 09:12.720 way to avoid that. Oh I am not right that. So, this is just a pure configuration which I am using. 09:14.000 --> 09:19.680 So, the question is that instead of using the default RGB 565 or other 09:20.400 --> 09:26.080 formats if you switch to some other display format then can we reduce the boot time. 09:26.880 --> 09:32.560 So, I am not right any of this what I tried was that since it is a virtual display I do not care 09:32.560 --> 09:37.680 about what if I do not boot with that default can it be displayed or that default. 09:42.480 --> 09:47.840 Oh that the way also okay. So, the question was from the real display point of view again sorry 09:47.840 --> 09:52.800 I am not so other than that compressed image part we are not played with that now. 10:06.800 --> 10:14.880 All right so, David's question is about using it as a production build for a headless device 10:14.960 --> 10:19.600 configuration. So, if you have a device which is capable of because we are not getting rid of 10:19.600 --> 10:24.960 the display subsystem as if I we are just making sure that it is running somewhere in the background 10:24.960 --> 10:31.360 and we are not just dealing with that. So, if a system is capable of performing fine even with 10:31.360 --> 10:37.920 let us say with a software stack still running in the background and then sure yeah. 10:39.520 --> 10:44.080 I do not know if you want to do that. So, depends on the use case for example if you have a device 10:44.160 --> 10:49.440 which is I mean so, if you have a application stack which is based on Android right and you 10:49.440 --> 10:53.840 have few services which because and the services are very tangled up right. So, you do not know 10:53.840 --> 10:59.200 at what point you have dependent service will depend on something which is exposed by surface 10:59.200 --> 11:04.560 flinger or any other graphics stack. So, if you want to take care of that then it makes sense to 11:04.560 --> 11:10.000 have maybe a dummy display stack running in the background. So, that at least your application 11:10.080 --> 11:15.680 which has dependencies on this can keep on running. Then that can also help you migrate your 11:15.680 --> 11:21.120 applications from when device to another device because it is the stack is the same right. 11:22.240 --> 11:27.520 So, if you are running it on a server or if you are running it on an edge device then just take 11:27.520 --> 11:32.880 the build and just just pure guess no idea to work on it but yeah. 11:40.000 --> 11:47.840 All right. I think we are right on time. Thank you very much.