2017-04-17: fencing, NEON, HDMI PM, CoC

First, a meta update: I’ve moved away from my ancient Livejournal for hosting this blog. LJ recently updated their TOS with a bunch of moderately scary stuff about following Russian law, including requirements to register as a media outlet if your blog gets too popular. While Russian internet censorship probably wouldn’t ever apply to this blog, and it’s unlikely to become popular enough to be a media outlet, I don’t want to support them after this move.

I landed the VC4 V3D fencing code last week. This allows drivers like tinydrm (for the little SPI-attached panels for Raspberry Pi) or PL111 (for my bcm911360 phone) to correctly synchronize display pageflipping to V3D rendering. In the process of writing my V3D code, I found a bug and my reviewers found a cleanup, which I have also submitted for msm and etnaviv.

I also worked on fixing up the NEON tiling code for Mesa 17.1. With what I had landed recently, we weren’t doing runtime detection of NEON being present – I just used NEON if we were on an ARMv7 build. This works for Debian or Fedora’s builds that would support Pi 2/3, but not for Raspbian’s ARMv6 builds that support Raspberry Pi 0-3. I’ve got runtime detection now, and I’m just working on cleaning up all the ARMv6 and ARMv8 cases.

Boris submitted a patch for HDMI runtime power management. This will reduce power consumption (by an amount we haven’t measured) when the HDMI display is off on VC4, but will also result in being able to switch from HDMI to SDTV and back, which was previously broken. I’ll be testing and hopefully landing it this week.

I received an entertaining Mesa patch from the developers of Exagear: They wrote SSE code for V3D’s tiling format, to improve the performance of texture uploads in their x86 emulation environment on Raspberry Pi. We’re still doing patch review (their SSE code doesn’t runtime SSE detection yet), but it should be ready soon. Has anyone experimented with qemu-user for x86 emulation on Raspberry Pis?

Other projects last week: I reviewed and landed the STM32 DRM display driver, tested Meson upstream fixes for the X Server’s build system, reviewed a small performance fix for Mesa’s GL name lookups, and reviewed Gustavo’s patch series to clean up cursor handling on drivers like vc4.

Finally, something that’s not quite vc4-related but that I wanted to highlight: Daniel Vetter posted a patch to document the new code of conduct that applies to DRM kernel development. Many have been pushing for better behavior on our mailing lists (a process in which I’ve been an occasional participant), but until now it’s always been in the form of polite requests. The new patch gives us a bit of a stick for when people refuse to change their behavior. The response was clear, with 22 Reviewed-bys and Acked-bys flooding in in the next few days. This is a huge step forward for our community, and hopefully the patch will land this week.