[Mesa-dev] BCM7268 V3D3.3 ("vc5") driver release

[Eric Anholt]

I've just pushed a "vc5" branch to my Mesa tree
(https://github.com/anholt/mesa/commits/vc5).  This is the culmination
of a couple of months of work on building a new driver for Broadcom's
V3D 3.3.  V3D 3.3 is a GLES3.1 part, though I'm nowhere near conformance
yet.

This driver is for BCM7268, a set-top-box SOC that boots an upstream
Linux kernel.  I'm really excited to be working on a modern GLES
implementation, and one that has its core platform support upstream
already.

In comparison to VC4, the QPU instruction set has changed significantly,
though it's still recognizable.  There is no more register A/B file, so
basic 32-bit value register allocation is simple.  One of the new
challenges, though, is going to be supporting its half-precision float
operations -- you can do twice as many add/sub/mul/min/maxes per cycle
if you can pack them in the same register.  I'm hoping that Intel has
made some progress on this for the i965 driver, though I haven't looked
into it.

The driver I've pushed is pretty primitive, and looks suspiciously like
vc4.  The compiler backend still uess a similar QIR before compiling to
QPU instructions.  While backpacking this weekend I decided that QIR was
a waste, now that I have some nice QPU instruction packing/unpacking
helpers.  I think instead I want to have the QIR-level instructions be
just an unpacked QPU instruction with some data on the side for the
virtual register allocation and tracking what push-constant uniform or
varying value is used.  This may be an interesting idea to backport to
vc4 as well.  The compiler backend still needs a lot of basic
functionality, like instruction pairing and threading.

I haven't yet pulled the surface layout code out to a library for reuse
by Vulkan.  I currently have some software tiling inside the gallium
driver for upload/download, though I may decide to switch over to always
using the rendering engine for that (and I should try that for vc4 as
well, particularly given the pain of trying to get Raspbian builds to do
NEON).

I haven't written a kernel driver for 7268 yet.  I delayed on starting
that until I had something to show on the userspace side in simulation,
and was closer to deciding on what I wanted the CL submit interface to
be.  That may also wait until I've done some more research on how Vulkan
wants memory allocation to work -- IIRC Intel's using a different kernel
interface for most Vulkan BO allocation than we used for GL.

As far as merging to Mesa, I think I'll want to get the QPU parts in
soon, since I feel good about them and their unit tests.  I may wait on
the CLIF dumping, and see if I can take from Intel's stuff instead.  NIR
may or may not wait until I redo QIR.

Merging the final vc5 driver code has two tricky things: One is the
linking against simulation, just like vc4, which I need to clean up.
The other is that I'm hoping Dave will be OK with development of
experimental Mesa userspace in-tree for some time, like I did for vc4,
before we can merge a kernel driver.  Maybe we could not list the driver
in ./configure --help and default it off until then?

Anyway, this is part of why I've been quieter in Mesa than I used to be,
and I'm happy to be back working in the open!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170706/f6f6bfcc/attachment.sig>