Bug 6772

Summary:

EXA shouldn't support SHM pixmaps

Product:

xorg

Reporter:

Eric Anholt <eric>

Component:

Server/Acceleration/EXA

Assignee:

Eric Anholt <eric>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

high

CC:

alexdeucher, fufutos610, leio, michel, mmacleod

Version:

git

Keywords:

patch

Hardware:

Other

OS:

FreeBSD

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Patch to disable sharedPixmaps.	none

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.