Sunday, November 24, 2013

freedreno update

It's been a while since I've posted an update about the progress of freedreno.. so no major/big headlines, just lots of small stuff.

Mesa 10

I finally polished up the support for emulating (via index buffer) GL_QUAD and other desktop GL primitives which aren't supported in hardware by adreno.  This is needed for gnome-shell and compiz (and probably other compositing window managers using opengl).  The u_primconvert utility could be handy in case any of the other upcoming drivers for SoC GPU's need to emulate any GL primitives which are not in GLES.  This, plus some other fixes needed for latest gnome-shell in fedora 20 where merged prior to the mesa 10.0 branch point, meaning that once Mesa 10 trickles into distributions, you should be able to use distro packaged freedreno rather than needing to rebuild mesa from git.


Since last blog post, I've added support for relative addressing (needed by chromium gl rendering, and a bunch of piglit tests), and fixed a whole bunch of little bugs or missing bits.  And I've started publishing piglit results.  Don't read too much into the absolute numbers, the all_es2 tests from Tom Gall's gles2-all branch still has a number of bogus tests (ie. shaders with precision specifier issues, etc), so not all the failures are freedreno bugs.  But there has been an increase in pass's (and no more crashers) over last few months.

I do really badly need a better collection of GLES2 tests ;-)


The IFC6410 is finally shipping out in larger numbers, as more folks in #freedreno are starting to receive their boards.  This board has been my primary freedreno dev platform for a while now.  If you are looking for a nice small SBC type ARM board with open source graphics, this is a pretty sweet little board.  Pico-itx, APQ8064 (1.5GHz quad core krait + adreno 320), 2GiB DDR3, SATA and gigabit-ethernet (hooked up via pci-e, not usb :-)).  Only downside is upstream kernel support for APQ8064 is pretty non-existent[1], there is only a downstream msm-3.4 based kernel (see ifc6410-drm branch).

And more recently I received a bStem board.  This board is more targeted at robotics (bunch of sensors, FPGA, and various add on boards for motor/RC control, etc).  But it has APQ8060A (1.7GHz dual core krait + adreno 320), and the typical hdmi and usb connectors.  I've pushed initial kernel msm drm/kms support to the bstem-drm branch.  I'm using the same Fedora 20 filesystem that I use with the ifc.

[1] APQ8x74 (aka snapdragon 800) seems to be getting into better shape in upstream kernel, so hopefully we start seeing APQ8074 versions of some of these boards at some point.

Adreno 4xx

Last week qualcomm announced their first adreno 420 device.  We knew this was coming, since support has been starting to show up in qualcomm's downstream android kernel driver (kgsl) in the last few months.  It unfortunately doesn't contain nearly as many useful hints as kgsl did for 2xx and 3xx, but it does give us a few register names.  And fwiw, more recent versions of the android blob userspace GLES drivers appear to have support for 4xx.

The recent announcements don't give too much details, but previous leaked specs indicate DX11 feature-set, and this seems to be backed up by handful of register names we can see from downstream kgsl driver.  (ie. hull/tesselator/domain/geometry shaders, etc).

From what I can tell so far, 4xx appears to be same shader ISA as 3xx (phew!), but pretty much all registers change or at least move, and a lot more features in hw.  So hopefully shouldn't take as long to figure out compared to 3xx (which had both new shader ISA plus register reshuffling).. at least for getting basics running.

Since the recent blob drivers have 4xx support, it should be possible to make a reasonable amount of progress on 4xx r/e before we can get our hands on actual devices.  Of course, there is still much to do on 3xx, so for the time being 4xx is not a priority.

Mailing List, etc

Since more folks are starting to play with freedreno (on IFC6410 and other devices), the whole email-questions-directly-to-rob thing is starting to look like it might not scale too well in the long run.  And, asking questions on IRC doesn't work out too well if you don't have a bip or screen setup to keep your connection alive until someone has a chance to wake up and answer.  So now we have a mailing list:

That plus steadily improving docs and info on the wiki should hopefully help.