This is great news, congratulations on this first milestone! :) Iago
On Fri, 2022-03-04 at 09:26 -0800, Emma Anholt wrote: > Welcome! I'm really excited to see this happening, and your early > upstreaming work. > > On Fri, Mar 4, 2022 at 7:44 AM <frank.bi...@imgtec.com> wrote: > > Hi All, > > > > I'm excited to share that over the last year we've been working on > > a new > > Vulkan driver, compiler and Linux kernel DRM driver for our PowerVR > > GPUs. As it was important for us to do things "right", we got > > Collabora > > involved early on in the project. They've been a big help and have > > guided us with the approach and overall design of the driver. > > > > I've sent an initial merge request for the Mesa parts of the driver > > here: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15243 > > > > The corresponding MRs for the kernel driver and firmware haven't > > been > > sent yet, as the kernel driver still has a few things that need > > finalising. We're currently exploring the best approach for getting > > it > > merged upstream while temporarily maintaining enough flexibility to > > make > > changes to the uAPI (any guidance here is very welcome). In the > > meantime > > you can find the kernel code here: > > > > https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/powervr-next > > > > and the firmware here: > > > > https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr > > I took a look through the UAPI. The only real red flag to me was the > UAPI structs talking about firmware versions. Have you thought about > how you're going to ship updates to the kernel and firmware, but > still > run with old userspace? This is not something you have to deal with > in most software stacks, but for desktop Linux, we have the > expectation that you can uprev the kernel (and probably also > linux-firmware) and break existing userspace. Usually, we try to > design UAPI so we can map userspace's request onto whatever the > HW/firmware's layout might be in the future, and you only require > updated userspace when supporting new hardware. > > If you actually expect new firmware API to change in a way you can't > just remap (e.g. some of those iovas point to structs in GPU memory > set up by userspace and interpreted by the firmware), I guess you > could delay poweron and firmware load until userspace comes in and > tells you what API it needs and then you can load the corresponding > firmware version, so you can at least dynamically choose a firmware > per boot at least. > > This can all be solved, just something that looks like maybe is going > to take a bit of thought. > > > In addition to highlighting the MR, I also wanted to take the > > opportunity to provide a bit more information and to introduce > > myself > > and the rest of the team. > > > > As mentioned in the MR, the driver will initially support three > > GPUs > > based on our Rogue architecture. The first of these (GX6250) is one > > of > > our earlier Rogue based GPUs, whereas the other two (AXE-1-16M and > > BXS-4-64) are some of our most recently available GPUs. > > > > For initial development we've been using an Acer Chromebook R13 as > > a > > target device (this contains a Mediatek MT8173 SoC/GX6250 GPU). We > > also > > hope to gain support for the TI AM62 SoC (AXE-1-16M GPU), which is > > in > > the process of having support upstreamed [1]. > > > > To help speed up development, we've been making use of the existing > > open > > source, but not upstream, kernel mode driver (pvrsrvkm) from our > > DDK. A > > kernel with the pvrsrvkm sources in-tree can be found here: > > > > https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/ddk/1.14@6193520 > > > > The Vulkan driver has a thin abstraction layer (inspired by radv) > > to > > allow it to make use of the pvrsrvkm driver and the new powervr > > kernel > > driver (support for the former being hidden behind a build config > > option). > > We have something similar on the Qualcomm side (not really even > abstraction, though!), where we can run on either upstream DRM or > downstream KGSL. Definitely the right way to go, because it means > you > get to swap the components out to try to isolate whether it's your > userspace driver or something in the software stack underneath you > (DRM getting PTEs right? devfreq? that one weird interconnect > driver > you forgot about because it's so ugly nobody's wanted to look at > upstreaming it?) that's causing whatever slowdown you're > investigating. > > > Unlike other driver efforts, we chose to start with a Vulkan driver > > as > > we thought that this would be a more interesting proposition than a > > native OpenGL ES driver. Obviously there's a lot of OpenGL ES > > content > > out there, but in recent years there's been a lot of effort put > > into GL > > to Vulkan translation layers. We therefore felt that a Vulkan > > driver > > together with Zink/ANGLE would be a good way to support multiple > > APIs > > from the get go. > > Absolutely agree here. You've got to make Vulkan good anyway, so > focus your efforts. > > > I know a lot of effort has been put into Mesa CI over the last few > > years, so we'll be looking to add support for our driver once it's > > upstream. The aim is to start looking at what's required in the > > next > > week or two in preparation for this (again, any guidance here is > > very > > welcome). > > The good news is if you're working with Collabora and your targets > include Chromebooks, you've got a great team there with a ton of > experience to support a CI lab for you. If you decide to go it on > your own, we've got some docs on setting things up, and I'm happy to > answer questions. > > > The final thing to do is to introduce myself and the rest of the > > team. I've been following and working with a number of the graphics > > related projects (Mesa, the DRM subsystem, Wayland/Weston, X.Org) > > for > > many years now. In this time I've made a few minor contributions > > here > > and there, but nothing major. I'm super excited to be leading our > > open > > source driver effort and I'm really looking forward to getting more > > involved! > > > > In addition to myself, the team consists of Rajnesh & Karmjit, who > > are > > the main contributors to the Vulkan driver, Simon, who has been > > working > > on the compiler, and Sarah & Matt, who are the main contributors to > > the > > kernel driver. > > > > The rest of the team are new to Mesa and DRM, but eager to learn > > and > > become an active part of the community. With this in mind, you'll > > be > > able to reach us via the standard channels (#dri-devel irc and the > > mesa-dev and dri-devel mailing lists). > > > > We look forward to getting involved and hearing any feedback! > > I'm glad to see you all on IRC already. Again, welcome! >