On Thu, 15 Sep 2011 14:37:01 -0700, Aaron Plattner <[email protected]> wrote: > Reviewed-by: Aaron Plattner <[email protected]> > > 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
