Just a quick update, since it has been a while and I haven't had time to update the old blog:
So the next step, which I should hopefully be starting on in a week or two is the gallium driver! Of course this is still going to be a lot of work, but things are coming along nicely so far :-)
- I managed to get stencil buffer working just before XDC, a bit over a month ago.. no exciting looking demo, but the stencil test (which is based on the stencil example in opengles-book-samples) is now working
- Since then I have been starting to get things into shape in order to start on a gallium driver. I've written a libdrm_freedreno module to include the common code for interfacing with the kernel driver, needed by xf86-video-freedreno, fdre, and the eventual gallium driver. Eventually we will need a proper DRM kernel driver, but libdrm_freedreno abstracts this well enough that I can concentrate on the 2d/3d userspace parts. The eventually plan is that when there is a proper DRM kernel driver (supporting a pushbuffer type interface, and synchronization between 2d and 3d pipes), libdrm_freedreno will be the point where we support talking to either the new driver or the existing QCOM kernel driver.
- I've fixed the problems that were preventing batching in the 2d driver, so now the performance is starting to be decent for xf86-video-freedreno. There is still some room for improvement (we fall back to sw for some sorts of blits that the hardware should be able to support, but libC2D2 does not, primarily blits with mask surfaces.. but I think I understand enough of the 2d registers to implement the missing blits. And also there is probably some room to optimize the cmdstream a bit for batches of blits.)
- I've implemented DRI2 support in xf86-video-freedreno and fdre, so now we have: dri2 lols cats:
So the next step, which I should hopefully be starting on in a week or two is the gallium driver! Of course this is still going to be a lot of work, but things are coming along nicely so far :-)
This is really fascinating (and fast) reverse engineering work on your part. Kudos to you!
ReplyDeleteIs this reverse-engineered driver slated to support "full" GL extensions, or the ES subset? I imagine this would open up a bunch of possibilities in terms of running a real distro on a Qualcomm-based device (like the One X and Nexus 4 families).
well, GLES first.. there are some GL features that should be possible to implement, but that isn't really the first goal and I haven't given it too much thought yet.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete