Large coordinates in the X server

[Keith Packard]

Robert Morell <rmorell at nvidia.com> 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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20141212/7d100e1d/attachment.sig>