[PATCH xserver 0/3] glamor: Accelerate XY format images

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> On Fri, 2016-09-30 at 22:43 -0700, Keith Packard wrote:
>
>>        1                 2                 Operation
>> ------------   -------------------------   -------------------------
>>      10900.0        99900.0 (     9.165)   PutImage XY 10x10 square 
>>       1740.0         2160.0 (     1.241)   PutImage XY 100x100 square 
>>         83.2           90.4 (     1.087)   PutImage XY 500x500 square 
>
> 90 ops per second is still shameful. No blit should take 11ms.

Agreed. It's all in fb, which just sucks at XYpixmaps. So many
instructions per pixel...

> Where does one get a copy of x11perf that has this test?

Sorry, git://people.freedesktop.org/~keithp/x11perf.git

> Also I assume this is measuring before the whole series vs after. Would
> be nice to see the impact between 2/3 and 3/3 too.

Yeah, I can run measurements per patch.

> On i965, at least, scissor updates are an appreciable amount of gl
> driver time, so small ops get punished.

Sounds like only changing them when necessary would be a good idea
then. I think we should assume that GL at least doesn't mind having
state set to the same value repeatedly, but then we should set these
common state values at the top of each rendering function so we weren't
resetting them at the bottom of any of them.

> With a trivial planemask, sure. With an interesting planemask you
> either need a bitwise write mask to the output fragment (and I'm not
> sure glsl 1.30 gives you that) or you need one of the fb fetch
> extensions.

A non-trivial planemask is just going to suck; we can't draw that
without serious pain anyways. Fallbacks are easier.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161003/f16929f2/attachment.sig>