Patch for maintainerless i128 driver

[Thomas Jaeger]

Adam Jackson wrote:
> On Fri, 2009-01-30 at 17:18 -0500, Thomas Jaeger wrote:
>> I don't know if anyone's still using this hardware.  My main motivation
>> here is to make sure that drivers implement the various repeat modes in
>> exa's composite operation correctly  (that is, fall back to software if
>> they don't), so that cairo's performance-crippling client-side fallback
>> for EXTEND_PAD can hopefully disabled someday.  It'd be nice if someone
>> with git access could commit this patch.
> 
> The EXA support in i128 is wildly incomplete.  I'm happy to give advice
> wherever possible (I do have the docs, though I can't distribute them)
> but I don't work on it nearly as much as I'd like to.
> 
> I don't remember offhand whether i128 can handle repeat modes well
> enough for Render, but it definitely has bilinear interpolation.  The
> major problem though is that I never did get it drawing triangles at
> all, let alone correctly.
> 
> - ajax

I don't actually own this hardware, so I can't do any testing, but it is
clear from looking at the source that the driver is broken because it
doesn't access repeatType or filter anywhere.  It's just an educated
guess on my part based on the comments in CheckComposite that it is
using nearest-neighbor interpolation (it may well be that supporting
bilinear interpolation is easy, but it's more important that the driver
not make promises it can't keep).  The repeatType issue is actually more
serious though because it has far-reaching consequences:  Currently,
cairo won't use XRender at all for repeat modes other than None/Normal
because a lot of the drivers have [1] (or had in the past) broken
implementations.  This in turn means that applications like firefox are
forced to use nearest-neighbor interpolation (on any hardware!) because
bilinear interpolation would require enabling EXTEND_PAD and thus
sending a pixmap over the wire for every image paint, which hurts
performance.  Server-side software fallbacks, on the other hand, don't
incur nearly as big a performance penalty, so getting the drivers to
correctly advertise which operations they currently accelerate would
actually help a lot.


[1] The drivers that I'm aware of that are still broken are radeonhd,
mga and i128:
https://bugs.freedesktop.org/show_bug.cgi?id=19728
https://bugs.freedesktop.org/show_bug.cgi?id=19839