Robert Morell <[email protected]> writes: > Hmm, I guess that depends on whether we're already fetching coordinates > directly out of the request "fresh off the wire", or copying them. If > there is already a copy, then scaling up to 2x wider integers may > admittedly trash 2x more cachelines on write, but I wouldn't expect > anything too drastic.
The driver is handed the raw request buffer, so widening it would
require allocating a new buffer and copying the data.
> I think "a couple of lines of code" is a bit optimistic for how much
> libfb would need to change :)
It really is just fbSetSpans and fbFillSpans, each just needing to add
the drawable origin to the span coordinate.
> In the case of miFillPolygon, for example, the polygon is decomposed
> into spans by miFill{Convex,General}Poly(). The number of points which
> need to be translated by the lower rendering layers after it's been
> decomposed is potentially much larger than the initial polygon
> coordinates.
You're talking about core polygons and wide primitives. Nothing else
goes through spans at this point. None of those operations are going to
see a significant impact from having the CPU do a couple more integer
operations per scanline.
> Anyway, there are some performance tradeoffs here that aren't
> immediately obvious. Unless anyone has any better ideas, I'll look into
> writing up some preliminary changes to compare.
The tradeoff is pretty obvious to me -- core operations that currently
go directly to hardware acceleration (thin lines, points and rectangles)
would take a performance hit while operations rendered with spans would
do a translation per span instead of a translation per vertex.
--
[email protected]
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
