[cairo] [PATCH 00/36] DRM backend fixes / take 2

[Chris Wilson]

On Mon, Dec 14, 2015 at 12:28:44PM +0100, Enrico Weigelt, metux IT consult wrote:
> On 13.12.2015 15:22, Chris Wilson wrote:
> 
> Hi folks,
> 
> > Yes, the drm backend bitrotted. If you want to play with it, by all
> > means, we will take whatever patches you have to make it work again
> > (iirc i965 was never completed, at least not as far as i915).
> 
> By the way: did it ever work w/ plain DRM/KMS framebuffer ?
> (w/o any GPU acceleration)

In theory, yes. It predates the dumb KMS framework though. The basic of
that framework is just to get at an image surface, and then you can just
pass it to cairo_image_surface_create_from_data().

However, that dumb framebuffer is often slow so in many cases it is
preferrable to use a shadow and damage tracking. At which point you have
the basics of a migration layer for mixing GPU acceleration and
fallbacks.

> > I would keep that set of patches into 2 groups core/non-drm and drm. 
> 
> I've already sorted them that way.
> 
> Maybe you've already seen that my core patches introduce some helper
> macros, which aren't used outside my DRM patches yet. I'd suggest a
> deeper discussion about generic helpers, eg. for conversion between
> boxes and rects, etc. ... in a later stage, we could add some more
> optimizations there (eg. use vector ops, etc)
> 
> > The core patches will need careful review in case they have side-effects
> > for other backends,
> 
> Of course. Therefore I'd appreciate if some more people could have a
> closer look and give signed-off for those which seem fine.
> 
> Is anybody here willing to maintain a separate incubator branch for that
> or should I keep it on my side ?

I would just put it on fdo or github, and point to it when sending
patches. It is nice to see the whole as well as the individual parts
without having to suck them in through the mailer.

> > but as the drm backend is experiemental self-contained
> > patches to it I feel comformtable with just merging.
> 
> I'd like to get some more feedback, as my understanding of the whole
> architecture is still pretty low.

GPU works in one way, cairo works in an entirely different way. Making
them meet in the middle is why it is so intimidating. Especially when
you then mix in vector page description languages (PDF, SVG), which look
like they should be so easy to integrate, then turn out to be complex
beasts of their own.
 
> > The biggest change in cairo since cairo-drm, as you have probably
> > observed, was the restructing of the compositor architecture. I would
> > suggest restructing cairo-drm on top of that pipeline would be a good
> > place to begin. As always, just creating a base layer that can open a
> > dumb GEM buffer (i.e. common for DRM drivers), render to it and pass it
> > around between libraries/applications is the first step. Maybe look at
> > GBM for that piece of middleware. Adding acceleration is where the fun
> > is though :)
> 
> Well, I dont really know where to start w/ that yet. Unfortunately,
> that change was really huge, so it's hard to understand, what's really
> going on here. Some documentation would be very helpful.

The best way to find areas to document is to watch people stumble
around... Sorry.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre