#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)
Change History (9)
Changed 9 years ago by
Attachment: | xpra-mmap-zerocopy.patch added |
---|
comment:1 Changed 9 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Status: | new → 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
comment:2 Changed 9 years ago by
Component: | android → server |
---|---|
Milestone: | current → v0.8 |
Priority: | major → minor |
Part 2: avoid wrapping around
Done in r401, which also adds diagrams to show how the mmap transfers work.
comment:3 Changed 9 years ago by
Milestone: | 0.0.7.x → 0.2 |
---|
comment:4 Changed 9 years ago by
Milestone: | 0.2 → 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?
comment:6 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:7 Changed 7 years ago by
Milestone: | future → 0.0.7.x |
---|
(setting correct milestone the work was completed in)
comment:8 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/67
patch for measuring the improvement using zerocopy