PowerVR Vulkan driver

[Iago Toral]

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