[PATCH] render: export TriStrip and TriFan to the drivers

[Chris Wilson]

On Thu, 15 Sep 2011 14:37:01 -0700, Aaron Plattner <aplattner at nvidia.com> wrote:
> Reviewed-by: Aaron Plattner <aplattner at nvidia.com>
> 
> Thanks for doing this, it was bugging me that we couldn't wrap these
> functions at this level.
> 
> Only somewhat related, but what do you think of the idea of creating RENDER
> path objects to allow clients to shove entire path descriptions over to the
> server for evaluation server-side (possibly on the GPU)?  E.g., like
> http://www.youtube.com/watch?v=bCrohG6PJQE but happening server-side.

Sticking to the principles of first solving the immediate mode problem
before introducing the complexity of retained path objects, I've put
together the necessary patches to render paths directly using Render:

http://cgit.freedesktop.org/~ickle/xserver/commit/?h=path
http://cgit.freedesktop.org/~ickle/renderproto.git
http://cgit.freedesktop.org/~ickle/xcb-proto.git
http://cgit.freedesktop.org/~ickle/libXrender.git

It is missing an implementation of arc-to (just need to find a 10-line
method to convert it to cubic-to ;-), fixed point is using 26.6 rather
than 16.16 (in order to accommodate large paths without loss of
precision), paths are given in device space with no transforms, paths are
rasterised only using the intents given by PolyMode/PolyEdge (no
intermediate mask specification). And I pretty sure I've broken the
swapping code for path.points.

Sadly of the two machines I tested on, only the PineView has sufficient
infrastructure ready for more favourable testing.  Hooking the
CompositePath up into the ddx, I measured a 10% performance increase when
rending the PS tiger on the PineView machine (with a 30% reduction in
total CPU time). Using the default miPath on an i3-330m, it was 2x slower
than the ddx's CompositeTrapezoids, the profiling indicated that this was
entirely due to the extra buffer copying of the intermediate data but I
suspect a loss of parallelism also hurt.

As a proof-of-principle, not too shabby ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre