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!
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
