[Xcb] XPutImage and context switches / roundtrips?

[Jamey Sharp]

On Thu, Sep 11, 2008 at 12:03:04AM +0200, Clemens Eisserer wrote:
> SHM is no real option for me, because after every 32x32 tile the
> higher-level framework expects the rendering to be done.
> This would mean for every 32x32 tile (or even smaller) I would have to
> force a sync.

I see from your blog that you eventually did get good results by keeping
a SHM tile pool of at least four to eight buffers, which is cool.
http://linuxhippy.blogspot.com/2008/09/mask-upload-performance.html

But yes, it's worth addressing the problem for the non-SHM case. Note
that without the handoff patches, your use case is also burning quite a
bit of CPU in the client on locks and memory copies, in addition to the
undesirably high number of system calls and context switches.

> Well, compile-time would mean all applications would have to use the
> fixed-size buffer, regardless wether they need it or not.

On a system with virtual memory--that is, anything that isn't
embedded--you probably won't get memory pages allocated until you touch
them. We'd be pretty much guaranteed not to waste memory if we picked a
buffer size of, say, 1MB. 16kB might actually be too small to avoid
wasting memory on such systems, since it's below malloc's minimum mmap
size. :-)

Embedded systems, on the other hand, usually need to conserve memory at
the cost of performance, and there a tiny buffer makes a lot more sense.

Either way, it's a decision based mostly on your hardware, not your
application.

On Fri, Sep 26, 2008 at 08:14:50PM +0200, Julien Danjou wrote:
> ...
> --- a/src/xcbint.h
> +++ b/src/xcbint.h
> @@ -72,7 +72,7 @@ typedef struct _xcb_out {
>      pthread_cond_t cond;
>      int writing;
>  
> -    char queue[4096];
> +    char queue[XCB_QUEUE_BUFFER_SIZE];
>      int queue_len;
>  
>      unsigned int request;
> ...

Thanks, Julien! Please feel free to commit this. It's a nice, simple,
obviously correct patch.

However, I don't think that the input queue size should change--Xlib
only reads 32 bytes per system call (insert a bunch of handwaving here),
so 4kB is already tons better than Xlib. The only reason to have a
buffer that big is when you're absolutely flooded with incoming events.
If anything we might want to tune it down some.

On Wed, Sep 10, 2008 at 02:35:08PM -0700, Barton C Massey wrote:
> We chose the 4K output buffer size a long time ago because
> we just didn't care, and wanted XCB to be usable on very
> small devices.  I'm not so up for having some run-time
> mechanism to be able to configure the buffer size, because
> it introduces some complications and is almost never needed,
> but there probably should be a config option to change it
> when compiling for a platform, and the default could then be
> something like 256K rather than 4K.  Jamey or Josh?

On Fri, Sep 26, 2008 at 01:18:11PM -0700, Barton C Massey wrote:
> Failing good QA, I think just bumping the default buffer
> size to something like 64KB and calling it a day is a better
> plan.  This should be sufficient to solve our immediate
> problem, without creating new things to tweak and manage.

Right, that. :-) I agree, though I think Julien's 16kB default is fine.

> However, I'm reluctant to accept the environment variable
> and runtime part of the patch until someone can demonstrate
> to me that (a) they understand XCB's use of the buffer well
> enough to make a plausible argument that we won't break
> things in subtle ways (Jamey and Josh automatically qualify
> if they take the time to respond :-) ...

On Thu, Sep 11, 2008 at 02:48:58AM -0700, Barton C Massey wrote:
> I'm concerned because some things (cough Xlib cough)
> may know a little more than they should about the buffer
> size and other internals of XCB.

Nah, we solved that whole class of problems already. xcb_connection_t is
opaque to all clients, including Xlib. And the handoff work gets rid of
the last Xlib-specific bit of API, making Xlib just another user of XCB.

But I'd rather not add the environment variable unless someone has a
very strong argument that it's necessary.

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20081013/609aee05/attachment.pgp