Re: [PATCH 00/36] DRM backend fixes / take 2

On Sat, Dec 12, 2015 at 10:19:26PM +0100, Uli Schlachter wrote:
> Am 12.12.2015 um 19:51 schrieb Enrico Weigelt, metux IT consult:
> > Hi folks,
> > 
> > 
> > here's the second take of my DRM backend fixes for review
> > 
> > * incorporated suggestions from prev review
> > * squashed some patches of same topic in individual backends
> >   (generic intel, i915, i965)
> > * added some more fixes for i965
> > 
> > Would be nice if you guys could give my your signed-off for
> > patches that are okay / ready for mainline.
> 
> Well, I don't really know the drm backend and don't have a lot of time to look
> into it. I believe you that it is completely broken, so I'd suggest that we wait
> for you to reach some working state and that merge that (unless some else
> complains).

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).

I would keep that set of patches into 2 groups core/non-drm and drm. The
core patches will need careful review in case they have side-effects for
other backends, but as the drm backend is experiemental self-contained
patches to it I feel comformtable with just merging.

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 :)

The biggest change to cairo-drm (other than plugging in other GPUs) I
made for xf86-video-intel was multithreading the scanline convertor.
It's a bit more hairy to make cairo's scan-convertor threaded, and
certainly there are other ideas on how to thread cairo (from the user
input to final image). Also my idea for how to create batchbuffers and
fences has evolved quite considerably since then. Though I still feel
the biggest limitation for accelerating cairo (and by extension Render)
is the immediate mode API. If I ever had time, I wanted to do a
surface-level path/shape-centric interface (i.e. lower then the retained
state model of cairo_t - trading ease of use for performance, as the
application toolkit would have to do the state tracking rather than
cairo) that looked more like NV_path_rendering (and Direct2D), and could
interoperate with OpenGL (+others) in the same manner as
NV_path_rendering.

I hope you find playing with a lowlevel backend a source for many great
ideas (especially for finding improvements to the common code). And I
hope you find it a lot of fun!
-Chris

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