Xpra: Ticket #67: mmap improvements: zero-copy, avoid wrap-around, memcopy, mmap.ACCESS_COPY
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
Fri, 06 Jan 2012 09:59:38 GMT - Antoine Martin: attachment set
- attachment
set to xpra-mmap-zerocopy.patch
patch for measuring the improvement using zerocopy
Fri, 06 Jan 2012 10:16:35 GMT - Antoine Martin: owner, status changed
- owner
changed from Antoine Martin to Antoine Martin
- status
changed from new to accepted
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
Fri, 06 Jan 2012 10:57:58 GMT - Antoine Martin: priority, component, milestone changed
- priority
changed from major to minor
- component
changed from android to server
- milestone
changed from current to v0.8
Part 2: avoid wrapping around
Done in r401, which also adds diagrams to show how the mmap transfers work.
Mon, 20 Feb 2012 19:32:52 GMT - Antoine Martin: milestone changed
- milestone
changed from 0.0.7.x to 0.2
Fri, 04 May 2012 09:57:33 GMT - Antoine Martin: milestone changed
- milestone
changed from 0.2 to future
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?
Tue, 16 Jul 2013 06:02:16 GMT - Antoine Martin: status changed
- status
changed from accepted to new
We now use XShm
(see #345).
Tue, 16 Jul 2013 06:02:54 GMT - Antoine Martin: status changed; resolution set
- status
changed from new to closed
- resolution
set to fixed
Mon, 19 May 2014 12:36:14 GMT - Antoine Martin: milestone changed
- milestone
changed from future to 0.0.7.x
(setting correct milestone the work was completed in)
Sat, 23 Jan 2021 04:44:38 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/67