| Age | Commit message (Collapse) | Author |
|---|
|
The cost of performing relocations outweigh the advantages of using the
blitter for solids with lots of rectangles.
References:
Bug 22127 - [UXA] 50% performance regression for XRenderFillRectangles
https://bugs.freedesktop.org/show_bug.cgi?id=22127
By using the 3D pipeline we improve our performance by around 4x on
i945, measured by the jxbench microbenchmark, and a factor of 10x by
short-cutting to the 3D pipeline for blended rectangles.
Before, on a i945GME:
19982.412060 Ops/s; rects (!); 15x15
9599.131693 Ops/s; rects (!); 75x75
3803.654743 Ops/s; rects (!); 250x250
6836.743772 Ops/s; rects blended; 15x15
1443.750000 Ops/s; rects blended; 75x75
495.335821 Ops/s; rects blended; 250x250
23247.933884 Ops/s; rects composition (!); 15x15
10993.073048 Ops/s; rects composition (!); 75x75
3595.905172 Ops/s; rects composition (!); 250x250
After:
87271.145975 Ops/s; rects (!); 15x15
32347.744361 Ops/s; rects (!); 75x75
5884.177215 Ops/s; rects (!); 250x250
73500.000000 Ops/s; rects blended; 15x15
33580.882353 Ops/s; rects blended; 75x75
5858.811749 Ops/s; rects blended; 250x250
25582.317073 Ops/s; rects composition (!); 15x15
6664.728682 Ops/s; rects composition (!); 75x75
14965.909091 Ops/s; rects composition (!); 250x250 [suspicious]
This has no impact on Cairo, but I have a suspicion from watching xtrace
that Qt likes to blit thousands of 1x1 rectangles with the same colour.
However, we are still around 2-3x slower than the reported figures for
EXA!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit cb887cfc670bf63993bd313ff33927afb8198eae)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Maintain a small cache of pixmaps to hold SolidFill pictures. Currently
we create a pixmap the size of the damaged region and fill that using
pixman before downloading it to the GPU and compositing. Needless to say
this is extremely expensive compared to simply emitting the solid
colour. To mitigate this cost, we maintain a small cache of 1x1R
pictures which is recognised by the driver as being a solid, but at the
very least is maintained as a GPU ready pixmap.
This gives a good boost to cairo-xcb (which uses solid fills) on a gm45:
Before:
gnome-terminal-vim: 41.9s
After:
gnome-terminal-vim: 31.7s
Compare with using a cache of 1x1R pixmaps in cairo-xcb:
gnome-terminal-vim: 31.6s
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit c1afc831c8fe4cbececee7dfa23506a6746c2425)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
We've talked about doing this since the start of the project, putting it off
until "some convenient time". Just after removing a third of the driver seems
like a convenient time, when backporting's probably not happening much anyway.
(cherry picked from 8ae0e44e42db645abe6d385f561260d2ae4a1960 commit)
|
|
Don't do it, treat this the same as every other prepare access call in uxa.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Owain Ainsworth <zerooa@googlemail.com>
|
|
|
|
|
|
|
|
uxa_prepare_access may fail to map the pixmap into user space. Recover from
this without crashing.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This avoids prepare/finish_access_gc overhead when we're not changing things
(since GCTile is already handled) and get us the RW flag for the prepare on
of the stipple pixmap so thing will be synced correctly.
|
|
This fixes assertion failures when rendering text while VT switched.
|
|
Prepares for a devPrivates system that will store an index.
|
|
All size-related rendering limits should be managed by the driver in the
pixmap_is_offscreen call. There's no need for uxa to even know these values.
|
|
|
|
|
|
Let the driver do whatever sync is necessary from the prepare_access hook
rather than forcing a full sync.
|
|
This eliminates the cost of EXA migration management while providing full
pixmap allocation control to the driver. The goal is to make something
useful for UMA drivers.
|
