Bug 6772 - EXA shouldn't support SHM pixmaps
Summary: EXA shouldn't support SHM pixmaps
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: git
Hardware: Other FreeBSD
: high normal
Assignee: Eric Anholt
QA Contact:
Keywords: patch
Depends on:
Reported: 2006-04-28 13:39 UTC by Eric Anholt
Modified: 2008-06-23 09:08 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

Patch to disable sharedPixmaps. (772 bytes, patch)
2006-04-28 13:40 UTC, Eric Anholt
no flags Details | Splinter Review

Description Eric Anholt 2006-04-28 13:39:39 UTC
MIT-SHM shared pixmaps are used by GTK to keep some pixbuf caches out of
framebuffer when they're going to have Render calls done from them that would
have been slow in XAA.  There's no performance win for EXA in having a SHM
pixmap and avoiding migration, so we really don't want to let people achieve
this.  If we disable the CreatePixmap shmfunc, it will get us that, while still
allowing the SHM PutImage that avoids wire transfers.  (We could also accelerate
SHM PutImage some more, but I'll leave that for later if we care).

The fallbacks caused by these render operations from SHM pixmaps hurt our
compositing performance significantly, which is why I really want them to go away.

This patch is uncommitted, because it results in misrendering on my radeon that
I haven't tracked down yet.
Comment 1 Eric Anholt 2006-04-28 13:40:58 UTC
Created attachment 5512 [details] [review]
Patch to disable sharedPixmaps.
Comment 2 Eric Anholt 2006-05-03 05:01:51 UTC
Bug #6819 covers the rendering issue -- I consider this committable now but
haven't yet.
Comment 3 Michel Dänzer 2006-08-09 12:55:28 UTC
This could be pushed now?
Comment 4 Michel Dänzer 2006-12-19 07:16:02 UTC
Pushed to master as commit 6b1e354dbb6e8ed9f2c654bbe7f8bbf241843d1c .
Comment 5 Owen Taylor 2008-06-23 09:08:15 UTC
This is misunderstanding of the reasoning of the GTK+ ues 

The *main* reason for the use of shared pixmaps is to improve the speed
and robustness of fetching data back from the server. 

 CopyArea => good semantics (off screen data undefined)
 GetImage => bad semantics (off screen causes X error)

When shared memory pixmaps are missing, GTK+:

 - Grabs the display
 - Does an XTranslateCoordinates call to figure out where the window
   is so it can clip
 - Does the GetImage
 - Ungrabs

So, this is a significant slowdown. However, fetching data back from
the server is mostly just a screen-shot thing these days (it was 
originally used to do alpha-compositing when the RENDER extension
was missing, not relevant with EXA.)

So, the change may be fine - and if the end result of EXA compositing
from a system-memory-locked pixmap is slower than PutImage to a 
temporary pixmap - a good thing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.