Re: [Mesa-dev] [PATCH 4/4] drisw/glx: use XShm if possible

2015-06-10 Thread Adam Jackson
On Wed, 2015-06-10 at 18:08 +0200, Marc-André Lureau wrote:

 +   if (!xshm_error  shmid = 0) {
 +  pdp-shminfo.shmid = shmid;
 +  pdp-ximage = XShmCreateImage(dpy,
 +pdp-visinfo-visual,
 +pdp-visinfo-depth,
 +ZPixmap,  /* format */
 +NULL, /* data */
 +pdp-shminfo,/* shminfo */
 +0, 0);/* width, height */
 +  if (pdp-ximage == NULL) {
 + int (*old_handler)(Display *, XErrorEvent *);
 +
 + /* dispatch pending errors */
 + XSync(dpy, False);
 +
 + old_handler = XSetErrorHandler(handle_xerror);
 + /* This may trigger the X protocol error we're ready to catch: */
 + XShmAttach(dpy, pdp-shminfo);
 + XSync(dpy, False);
 

Telling the server to attach the image only if creating it failed ain't
gonna work too great:

X Error of failed request:  BadShmSeg (invalid shared segment
parameter)
  Major opcode of failed request:  130 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Segment id in failed request:  0x1a5
  Serial number of failed request:  31
  Current serial number in output stream:  32

But with the == changed to !=, this does seem to work! Under
(accelerated) gnome-shell, llvmpipe gears gets around 1280fps at its
default window size and 110 fullscreen, compared to about 1110 and 40
with PutImage, respectively. Nice one.

PutImage's semantics are that when it returns the app owns the image
data again: the image has been either copied into xlib's request buffer
or written to the socket. Not so ShmPutImage, which just enqueues the
request and lets the server pick the data up whenever. So it's
possible, if we dirty the front buffer before xserver finishes the
ShmPutImage, that we'd see an inconsistent screen state for a moment.
So I think this wants an XSync after XShmPutImage (which dings windowed
fps by ~50 but doesn't seem to bother fullscreen at all).

With those two things fixed, the series is:

Reviewed-by: Adam Jackson a...@redhat.com

Any chance you feel like trying the same trick with ShmGetImage and
EXT_texture_from_pixmap?

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/4] drisw/glx: use XShm if possible

2015-06-10 Thread Marc-André Lureau
Hi

On Wed, Jun 10, 2015 at 6:17 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:

 I did not find how you serialised the XServer reading from the SHM
 following the call to XShmPutImage (which you may want to flush?) with
 subsequent rendering into the image.


Correct, there is no sync. And I think that explains the temporary glitches
I observe with gnome-shell when moving windows around for ex (they are
always temporary, there is fortunately always a pending update to fix it).
I am afraid it would have to wait for ShmCompletionEvent, unfortunately in
sync, since there is a single buffer, and mesa doesn't own the event
queueloop (I think). Note that the sw x11 backend also seems to suffer
from this.

Another trick you may like to investigate is using the X server to do
 format conversions and tune the swrast for a small number of local
 formats (i.e. rgb16, argb32). This of course requires using XRender
 after the PutImage - and at that point keeping it as a ShmPixmap is
 hugely beneficial to UMA drivers.


That's an interesting optimization. However, my use case is mostly with
spice/vnc, so I don't think that would improve performance here since it's
all software-based.

thanks

-- 
Marc-André Lureau
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev