Re: status of gallium backend

On Wed, Dec 16, 2015 at 04:21:43PM +0100, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> 
> 
> what's the status of the gallium backend ? Is it already usable ?

Dead; incomplete; barely even started.
> 
> I'm currently trying to get the DRM backend running, as the basis for
> my planned embedded GUI toolkit.
> 
> But, OTOH, if gallium backend is already working, it might be a better
> solution to drop the other DRM stuff in favour of gallium.

Yes, that's pretty much the appeal.
 
> The interesting questions remains: how will it perform on small
> systems w/o (usable) GPU (IOW: softraster) - compared to a an own
> 2D-only implementation ?

Poorly compared to cairo-image. There is room for improvement there, in
terms of sampler fidelity trade-off, faster bspline rendering, but
pixman has a pretty good set of kernels, that jitted code would find
very hard to beat.
 
> And how complex would be using other units like DMA controllers
> (bitblt etc), IPUs (overlays, colorspace conversions, etc) directly
> in cairo vs. gallium ?

Since there is no general interface, you need something like gallium to
supply the driver or rewrite your own.
 
> In the long run, setting ontop of gallium seems the economically
> best option (wider userbase for SoC specific optimizations, etc),
> if it's not too complex and 2d performance wont suffer.
> 
> What's your oppinon on that ?

Accelerating path rendering is hard. Accelerating layer composition is
relatively easy, and can be pretty much done on top of any OpenGL (or
similar) driver. If you wanted to aim wide, I would just use cairo-image
and whatever platform specific layer you have for pushing images to the
display. On the next step up the ladder would be to use OpenGL to
accelerate the blending of multiple layers (or just painting the image).
Becoming increasingly more specialised (now requiring a modern
programmable GPU), I would pencil in a Vulkan backend. (Such a backend
would require a lot of work since it would just present a lowlevel
abstract GPU device, you would need to build surface table and shaders
on top of that. Basically OpenGL with no hand holding - almost a device
specific DRM backend but using generic interface blocks instead of GPU
specific commands.)

If you goal is to enable lots of SoC, cairo-drm is not the path you want
to take. If those SoC are resonably recent (say OpenGLES 3.0), then
planning a vulkan backend should give you the best performance/value
(having said that playing with cairo-drm is going to get you experience
with what a future cairo-vulkan backend would look like). If you just want
something to work, then look at accelerating cairo-image (e.g. threading
the rasterising, adding JIT to the path rendering, using offset curves for
strokes etc.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo