Bug 7671 - Small EXA enhancements "bug".
Small EXA enhancements "bug".
Status: RESOLVED WONTFIX
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA
git
x86 (IA32) Linux (All)
: high enhancement
Assigned To: Xorg Project Team
Xorg Project Team
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-28 05:37 UTC by Thomas Hellström
Modified: 2010-03-27 06:36 UTC (History)
1 user (show)

See Also:


Attachments
Patch to fix a case where a pinned source pixmap forces no acceleration (1.31 KB, patch)
2006-07-28 05:41 UTC, Thomas Hellström
no flags Details | Splinter Review
Always accelerate movement of transparent and shadowed windows. (2.21 KB, patch)
2006-07-28 05:54 UTC, Thomas Hellström
no flags Details | Splinter Review
Always accelerate movement of transparent and shadowed windows. (2.22 KB, patch)
2006-07-28 08:20 UTC, Thomas Hellström
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hellström 2006-07-28 05:37:40 UTC
A bug for review of small EXA enhancements.
Comment 1 Thomas Hellström 2006-07-28 05:41:13 UTC
Created attachment 6375 [details] [review]
Patch to fix a case where a pinned source pixmap forces no acceleration

This patch fixes the case where a single src or mask pixmap, which is pinned in
system memory stops acceleration. It relies on uploadToScratch, if present, to
upload the pixmap to a scratch area and the compositing operation will be
accelerated. This seems to be a quite common case. 

In the current form it's only implemented for "greedy", but it could probably
be moved up to be valid for all heuristics.
Comment 2 Thomas Hellström 2006-07-28 05:54:45 UTC
Created attachment 6376 [details] [review]
Always accelerate movement of transparent and shadowed windows.

This patch requires that the driver can always accelerate one-pixel repeat
source and mask pixmaps regardless of their location. It might be only the via
driver that does this ATM?

Anyway, If all drivers can detect that the address of the pixmap is not in FB
memory and fail prepareComposite it should be safe to commit. (All drivers
implementing uploadToScratch need to be able to do this today anyway, since if
uploadToScratch fails, prepareComposite will be called with a system pixmap
address). 

This patch fixes the case where the destination is in FB and both the source
and mask is in system memory. Either because of a bad greedy score (Netscape,
skype), or because one of them is pinned. AND one of the pixmaps is a one-pixel
repeat pixmap.

This case might seem awkward, but it's a typical case with the "greedy"
heuristic and an application that does a lot of software compositing and then
displays the result in a transparent window. 

With this patch, movement of transparent and shaded windows with the "greedy"
heuristic should always be accelerated, provided the driver implements
uploadtoscratch and the scratch area is large enough to hold the pixmap.
Comment 3 Thomas Hellström 2006-07-28 08:20:08 UTC
Created attachment 6378 [details] [review]
Always accelerate movement of transparent and shadowed windows.

Fixes segfault in patch 6376
Comment 4 Daniel Stone 2007-02-27 01:33:01 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 5 Corbin Simpson 2010-03-27 05:02:04 UTC
Tagging patches; will triage later.
Comment 6 Michel Dänzer 2010-03-27 06:36:22 UTC
EXA isn't using the UploadToScratch driver hook any more, and it is scheduled to be removed next time the ABI needs to be bumped. It was basically a bandaid for bad migration, better to just fix that.