PowerVR Vulkan driver

[Frank Binns]

Hi Emma,

Emma Anholt <emma at anholt.net> writes:
>
> Welcome!  I'm really excited to see this happening, and your early
> upstreaming work.

Thanks!

> On Fri, Mar 4, 2022 at 7:44 AM <frank.binns at 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.

We've given it a bit of thought and have an idea of how things could
work. As you might have already seen, this topic also came up on the MR
and I've provided some details about this there (I thought the MR might
be the best place to discuss things).

> 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.

Thanks, that's good to know! As you've already seen, Matt has already
started getting his teeth into CI and has found the CI docs very
useful. We're looking to set up our own CI farm and have ordered a bunch
of Chromebooks to get things started. I'm sure we'll have plenty of
questions along the way :)

>> 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! 

Thank you for all the feedback Emma!