WEBVTT 00:00.000 --> 00:10.800 So, everyone, my name is Mark Bikua, I'm from Samsung R&D City of Poland, and today I'm 00:10.800 --> 00:17.800 going to present a project I've been working on for throughout the last year, which is 00:17.800 --> 00:20.280 CI Multiplotform. 00:20.280 --> 00:28.480 So first, if you words about myself, I have background in FPGA engineering, and that Samsung 00:28.480 --> 00:32.280 I'm working mostly on platform software. 00:32.280 --> 00:39.560 The main goal for me was recently porting Tizen OS to respite, and then supporting some 00:39.560 --> 00:44.920 system libraries, and porting them to respite, and because of that, I also got involved 00:44.920 --> 00:49.320 with CI and the enablement of CI for respite. 00:49.320 --> 00:54.600 So jumping straight into the problem, I'm trying to solve with a multiplotform, so if you 00:54.600 --> 00:59.840 have a library or an application that has some platform specific code, because some specific 00:59.840 --> 01:05.760 optimizations or some specific behavior, which is very much platform oriented or architecture 01:05.760 --> 01:13.400 oriented, then you need to either cross compile it, or try to do some weird stuff, and 01:13.400 --> 01:19.160 you quickly run into an issue that if you have some dependencies, you need to somehow include 01:19.160 --> 01:24.240 them in the build, then you need to somehow run the test, and it can get really tricky 01:24.320 --> 01:25.920 fast. 01:25.920 --> 01:32.000 And second point is that when you're trying to push your code upstream, maintainers need 01:32.000 --> 01:33.480 confidence in your code. 01:33.480 --> 01:41.640 So in our case, we are trying to upstream our respite vector extension support for a 01:41.640 --> 01:49.320 pixel library, and well, there was no support for respite in CI pipeline at 3dc.org 01:49.320 --> 01:55.080 at this time, and so the maintainers simply didn't know the specifics of respite vector, 01:55.080 --> 02:03.760 so we couldn't really prove that we are able to do the stuff that libraries needs. 02:03.760 --> 02:13.240 And third point is hardware scarcity, so in case of respite, there are no respite CI runners 02:13.240 --> 02:18.400 available pretty much, and also the boards that supported respite vectors at the time were 02:18.400 --> 02:25.880 pretty scar, so the maintainers couldn't really just go by a board and test our patches. 02:25.880 --> 02:30.400 So let's try to make a multi-architecture CI as boring as possible, I want to base it 02:30.400 --> 02:37.160 on reusable GitLab CI templates, it's GitLab because we target the 3dc.org at first. 02:37.160 --> 02:44.000 We want to use layer to CI or Docker images to have flexibility for the projects. 02:44.000 --> 02:51.920 We want to use user mode emulation because we don't have a harder support for everything, 02:51.920 --> 02:58.560 and we also want to include coverage and coverage summary across all the targets that we have. 02:58.560 --> 03:00.160 So what are the building blocks? 03:00.160 --> 03:04.600 First we have the OCI images, which are a layer, so you can have depending on your project 03:04.600 --> 03:10.440 you could have a base GNU layer, then add LLVM as well, if you want to test both compilers, 03:10.440 --> 03:16.960 then you can add your build tool, in our case we support for now, we have plans to extend 03:16.960 --> 03:22.760 it to see make-and-autotals, and then you can add another layer with your project dependencies, 03:22.760 --> 03:28.800 then we have reusable templates, in our case as I said it's only for resin, but if you have 03:28.800 --> 03:33.760 your own scripts that you want to run on those different targets you can use it, and we 03:33.800 --> 03:39.840 extensively use a QME user mode, which pretty seamless integrates with the OCI images. 03:39.840 --> 03:47.040 A few words about targets naming, so we have currently Linux 90 targets and Windows 03:47.040 --> 03:53.040 cross compilation targets using wine, then we have native and cross targets, because for 03:53.040 --> 03:59.040 some targets, for example, 32 bits, big end-ion maps, there is no DBN image, so unfortunately 03:59.040 --> 04:06.760 we need to cross compile for those targets, and then the final part is the architecture, 04:06.760 --> 04:12.040 so how to use the project, here's a little bit kind of call for action, if you have some 04:12.040 --> 04:17.040 platform specific code in your project and you use GitLab CI, then you can try to use this, 04:17.040 --> 04:22.000 so first you need to check which targets have native runners on your GitLab instance, 04:22.000 --> 04:28.200 currently we support natively, GitLab.com and free desktop.org runners, which is X86 and 04:28.200 --> 04:34.680 ARM, second, do I need custom dependencies or build system, if yes, then you need to define 04:34.680 --> 04:45.320 those layers on by yourself, if not then you can straight-up use pre-built images, and then 04:45.320 --> 04:52.160 either if you use Amazon then it's great because you can use the templates which we provide, 04:52.160 --> 04:59.440 or if not you can just run your specific build and test by yourself, on the left you can 04:59.440 --> 05:07.640 see basically example using parallel matrix for three different architectures, running some 05:07.640 --> 05:14.720 basic script, so if you hope takes that's what we came here for, so how to make it 05:14.720 --> 05:21.280 all possible, we have DBN based images, we chose DBN because it has the widest support 05:21.280 --> 05:29.560 for different architectures, first there are multiple natively supported, official architectures 05:29.560 --> 05:35.080 and also there is extensive library of ports for DBN, so for the upstream pre-built images 05:35.160 --> 05:41.880 we can just pull them from upstream and use them, but for the ports we need kind of elaborate 05:41.880 --> 05:51.080 setup, in this case I tried to do this on a little privilege, the possible runners, so first 05:51.080 --> 05:58.480 we have build main builder image, this is our first layer of abstraction, then we have the 05:58.480 --> 06:04.920 build-strap builder base image, it's standard DBN tool for building base images, and then 06:04.920 --> 06:12.080 we have the DBN base image builder layer which internally uses prudes, which adds another 06:12.080 --> 06:20.880 layer of abstraction, and it was pretty fun debugging, it all in CI, and yeah it's I was 06:20.880 --> 06:26.680 really skeptical at first if it will work, but magically it works in one very specific version 06:26.680 --> 06:35.080 of a Dora base image, but it works, and that allows us to utilize OCI caching, so that we 06:35.080 --> 06:41.680 don't need to rebuild the DBN images every time we run the CI, and that allows us to have 06:41.680 --> 06:47.680 the very similar base line, because the bird type and the bootstrap are the tools that 06:47.680 --> 06:53.880 are used for the official upstream images, so we have very similar base images for all the 06:54.080 --> 07:00.080 architectures that we support, and then on top of that as I said we build additional layers 07:00.080 --> 07:08.080 so GNU tool chain, OVM, Amazon, and whatever you have in your project, yeah second nice 07:08.080 --> 07:16.480 nice thing about utilizing QMU for running the test is, well first you can of course have 07:16.480 --> 07:21.080 your native runners, if you have risk five boards and you can add them to your CI, then that's 07:21.080 --> 07:28.280 great, but on the other hand utilizing QMU allows you to have some very specific virtual target 07:28.280 --> 07:34.880 configuration, so in case of risk five vectors, you could configure the vector length vector 07:34.880 --> 07:42.680 register length in QMU, which allows you to easily change the virtual hardware configuration, 07:42.680 --> 07:50.080 and that's actually allowed us to cache some early bugs in our RVV implementation, and yeah 07:50.080 --> 07:57.680 it extends platform coverage beyond what is already available, so at this time that we're developing 07:57.680 --> 08:05.480 the patches we had only board with VLAN of 256, but in future there will be boards with bigger 08:05.480 --> 08:13.480 VLANs, and right now we can test those scenarios and be ready for future hardware, so what's 08:13.480 --> 08:19.680 next for the project, first it's a call for action to all of you, if you have a project that 08:19.680 --> 08:28.560 has some platform specific code, then I'm really happy and it runs on GitLab, and I will 08:28.560 --> 08:35.240 really happy if you came and tested it, I would really appreciate any kind of feedback and 08:35.240 --> 08:44.040 the back reports, you could push them to the official GitLab repo, and if you have any suggestions 08:44.040 --> 08:51.040 what could be done to improve this, of course besides adding more features, but what are the 08:51.040 --> 08:58.240 specific scenarios that you see useful for you, there's also this nice batch that you can stamp 08:58.240 --> 09:04.040 on your project if you're using CI multi platform, and in the pipeline there are more 09:04.040 --> 09:10.240 build tools, so we plan to support also CI make and auto tools with extensive templates and 09:10.240 --> 09:21.320 coverage summarization, yeah I think it's really nice to have this aggregate coverage summary 09:21.320 --> 09:26.160 because if you have multiple targets then well you have multiple summary ports for different 09:26.160 --> 09:34.040 targets, but then you're able to compress all this into one single result and present it nicely 09:34.040 --> 09:44.440 in GitLab for example for pull request, yeah so that's about it, here's the QR code for the project, 09:44.440 --> 09:50.800 and yeah please contact me, please use the project and I would very much appreciate the feedback 09:50.800 --> 09:55.840 and if you have any questions, I'll be there around or I'll answer questions online. 09:55.840 --> 10:00.800 That's five minutes that you can take questions now, yeah that would be great actually. 10:00.800 --> 10:05.800 So do we have questions for one question? 10:05.800 --> 10:11.480 Can I say something about performance and entity when you're running about difficulties 10:11.480 --> 10:13.480 on our electrical knowledge? 10:13.480 --> 10:18.840 Yeah so the question is about the question is about performance penalty when you're running 10:18.880 --> 10:26.160 QMU, so well first of all sometimes running in QMU is the only way because you don't have the native runners 10:26.160 --> 10:36.640 and in case of risk five actually because there are starting to appear some options to include native runners for risk five 10:36.640 --> 10:47.280 and we tested them with the cloud V cloud five runners and curiously the current hardware is slower than QMU running on 10:47.360 --> 10:54.360 QMU like big runners available at pre-dustable torque, so that's interesting thing. 10:54.360 --> 11:02.600 On the other hand when you have some similar extensions in case of risk five it runs much slower than on real hardware 11:02.600 --> 11:10.040 so it's kind of trade-off, so for building images I would say running with QMU is the fastest 11:10.040 --> 11:16.360 if you have some very specific performance oriented code then using the native runners is always the best idea 11:16.440 --> 11:23.560 and this project allows you to interchange those, so you could build your images on the native runner 11:23.560 --> 11:30.520 and then use the QMU runner and then use the native runner to run your actual tests. 11:30.520 --> 11:34.520 Any more questions? 11:34.520 --> 12:04.040 Yes, the question is about integrated integration with QMU basically, so honestly I'm not really familiar with how QMU 12:04.960 --> 12:12.200 does CI, so I'm not sure but what you could do for sure is to just mirror your repo on some GitLab instance 12:12.200 --> 12:20.760 be it's the official GitLab.com or pre-dustable.org or wherever and you could just grab those templates 12:20.760 --> 12:28.960 but yeah I'm not 100% certain how it works on code work, so any other questions? 12:29.040 --> 12:31.480 Are you having one more question maybe? 12:31.480 --> 12:34.480 You have three minutes, I need one more. 12:34.480 --> 12:49.760 Yeah, so the question is about why not cross compiling, so it's an option for sure for some projects 12:49.760 --> 12:56.720 but once you get to more and more complex projects which like multiple dependencies and maybe some 12:59.040 --> 13:09.840 target specific dependencies then you quickly run into a lot of maintenance overheads when trying to do it properly 13:09.840 --> 13:18.400 and yeah in case of CI multi platform it's much easier because you have basically native 13:18.400 --> 13:25.120 the DB images in your dependency layer you could just upgats whatever dependency you need 13:25.200 --> 13:29.840 and you don't need to worry about cross compiling those dependencies and so on so 13:29.840 --> 13:43.120 and because we use OCI multiple targets for the OCI images you could have very specific dependencies 13:43.120 --> 13:49.280 for each platform that you support so you don't need to have like one set of dependencies you could 13:49.360 --> 13:54.800 have multiple variants of dependencies based on the platform. 14:02.800 --> 14:04.800 Thank you very much.