Another quick update, since it has been a while. I've been working for the last month or so on a gallium driver for freedreno, and now it is finally showing signs of life with es2gears:
There are still a lot of little missing pieces (textures, not translating a lot of tgsi shader opcodes, and it won't work for anything that isn't glClear()ing the color/depth/stencil buffers each frame. Although these shouldn't be too hard to add, just takes time. The work-in-progress mesa code is on github: git://github.com/freedreno/mesa.git
Just a quick update, since it has been a while and I haven't had time to update the old blog:
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 :-)
Last weekend I fixed a few issues w/ the assembler to make more complex fragment shaders work, added support for VBO's. And now I've pushed support to enable GL_BLEND. And as a result, I give you open source lolscat:
The model was borrowed from glmark2, the fragment shader uses phong lighting. And two textures are alpha blended in front to give the text.
managed to bang out some basic texture support.. and also multi-tile rendering so I'm not limited to render targets that can fit in GMEM (512KiB on the a220 that I have in my touchpad), and of course this is using the freedreno shader assembler (no need for the binary blob):
maybe some day I'll figure out how to make better quality videos :-P
For the last month or so, I've been working on deciphering the adreno shader instruction set and creating a disassembler, and now assembler. I've hooked it up in fdre and now I can run all the test apps with shaders assembled from the fdasm assembler syntax, rather than requiring pre-compiled shaders from the adreno binary blob! This means now I can run 3d tests with no dependency on the binary blob!
No new pictures, everything looks the same as before, including the spinning cube. I've updated the cube test with some comments in the shader assembly to make it a bit easier to follow.
Just a quick update about the freedreno project.. after a month or so of not having much time to work on it due to travel and other projects, last weekend I finally had some time to spend on 3d and fdre, a simple library to drive the gpu (similar to limare) and some test apps, and now we have first renders for a few simple test apps.
quad-flat:
triangle-quad:
and triangle-smoothed:
The shaders are currently just binary, extracted via cffdump from egl/gles test apps written to use the same shaders. And for now I'm sticking to smaller render target sizes which can be handled in a single pass without resorting to binning (basically splitting the render up into parts that can each fit within the built in GMEM).
It is of course a long ways from a full blown mesa driver, but I'm making some good progress on figuring out the command stream. No where near the progress of the lima guys, who already have textures working and are pretty far on the vertex and shader compilers.
