xpra icon
Bug tracker and wiki

Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#67 closed enhancement (fixed)

mmap improvements: zero-copy, avoid wrap-around, memcopy, mmap.ACCESS_COPY

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 0.0.7.x
Component: server Version:
Keywords: Cc:

Description

mmap is fast but can be made faster:

  • rather than extracting the pixel data from the mmap area, use it in place by creating a pixel buffer pointing to the mmap location
  • avoid wrapping around the end of the mmap area (split buffer) when we have enough free area: this avoids having to re-construct the buffer from 2 non-contiguous chunks and allows us to write it more quickly too
  • set the mmap area as mmap.ACCESS_COPY so the OS does not try to keep it in sync - this may require us to flush it, may not work/be worthwhile
  • use memcopy to copy the pixbuf pixels into the mmap area?
  • probably not do-able: create a pixbuf (or even the pixmap?) backed by an mmap area so we don't need to call get_pixels() at all

Attachments (1)

xpra-mmap-zerocopy.patch (2.7 KB) - added by Antoine Martin 8 years ago.
patch for measuring the improvement using zerocopy

Download all attachments as: .zip

Change History (8)

Changed 8 years ago by Antoine Martin

Attachment: xpra-mmap-zerocopy.patch added

patch for measuring the improvement using zerocopy

comment:1 Changed 8 years ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newaccepted

Part 1: zero-copy
The patch above allows us to measure the zero-copy case against the standard code (one must add and False to make it go through the non zero-copy case for non-split areas).
Some numbers with a 1024x1024 glxgears on a fast system (ignoring small screen updates which skew the number due to the high overhead of method calls compared to the actual time spent preparing the data - which means the benefit is less, almost negligible, when used on small pixel buffers):

  • in all cases, the actual draw_rgb_image takes from 1ms to 10ms (average around 5ms)
  • with "directly from mmap", creating the pixel data reference takes about 0.01ms
  • with the regular copy case, creating the pixel data buffer takes about 1ms

So the benefit is in the 10% to 50% range, average around 20%.

Merged in r400

comment:2 Changed 8 years ago by Antoine Martin

Component: androidserver
Milestone: currentv0.8
Priority: majorminor

Part 2: avoid wrapping around
Done in r401, which also adds diagrams to show how the mmap transfers work.

comment:3 Changed 8 years ago by Antoine Martin

Milestone: 0.0.7.x0.2

comment:4 Changed 8 years ago by Antoine Martin

Milestone: 0.2future

This is good enough for now, the only features left to consider are:

  • set the mmap area as mmap.ACCESS_COPY so the OS does not try to keep it in sync - this may require us to flush it, may not work/be worthwhile - does not seem to work!
  • use memcopy to copy the pixbuf pixels into the mmap area
  • probably not do-able: create a pixbuf (or even the pixmap / cairo draw) backed by an mmap area so we don't need to call get_pixels() at all?

comment:5 Changed 6 years ago by Antoine Martin

Status: acceptednew

We now use XShm (see #345).

comment:6 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

comment:7 Changed 6 years ago by Antoine Martin

Milestone: future0.0.7.x

(setting correct milestone the work was completed in)

Note: See TracTickets for help on using tickets.