[Spice-devel] Delay in Gimp when using qxl driver

Mon Jan 23 02:26:51 PST 2012

Le 23/01/2012 11:41, Alon Levy a écrit :
> On Sun, Jan 22, 2012 at 11:05:59PM +0100, Dominique Rodrigues wrote:
>> Le 22/01/2012 22:36, Alon Levy a écrit :
>>> On Sun, Jan 22, 2012 at 11:03:47PM +0200, Alon Levy wrote:
>>>> On Sun, Jan 22, 2012 at 06:33:59PM +0100, Dominique Rodrigues wrote:
>>>>> Le 22/01/2012 18:28, Alon Levy a écrit :
>>>>>> On Sun, Jan 22, 2012 at 05:15:42PM +0200, Alon Levy wrote:
>>>>>>> On Sun, Jan 22, 2012 at 03:53:40PM +0100, Dominique Rodrigues wrote:
>>>>>>>> Le 22/01/2012 16:00, Alon Levy a écrit :
>>>>>>>>> On Fri, Jan 20, 2012 at 02:04:47PM -0500, Yaniv Kaul wrote:
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> On Wed, Jan 18, 2012 at 11:59:45AM +0100, Dominique Rodrigues wrote:
>>>>>>>>>>>> Le 18/01/2012 11:48, Alon Levy a écrit :
>>>>>>>>>>>>> On Wed, Jan 18, 2012 at 11:39:13AM +0100, Dominique Rodrigues
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Le 18/01/2012 11:32, Alon Levy a écrit :
>>>>>>>>>>>>>>> On Wed, Jan 18, 2012 at 11:27:14AM +0100, Dominique Rodrigues
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Le 18/01/2012 11:18, Alon Levy a écrit :
>>>>>>>>>>>>>>>>> On Wed, Jan 18, 2012 at 09:54:49AM +0100, Dominique Rodrigues
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Le 18/01/2012 09:44, Alon Levy a écrit :
>>>>>>>>>>>>>>>>>>> On Wed, Jan 18, 2012 at 08:06:40AM +0100, Dominique
>>>>>>>>>>>>>>>>>>> Rodrigues wrote:
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Since I use qxl driver in virtual desktop powered by
>>>>>>>>>>>>>>>>>>>> qemu-kvm, I
>>>>>>>>>>>>>>>>>>>> found a strange problem with Gimp.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> After launching Gimp, open a new windows, and then try to
>>>>>>>>>>>>>>>>>>>> draw
>>>>>>>>>>>>>>>>>>>> something. It appears that the drawing is very slow and
>>>>>>>>>>>>>>>>>>>> does not
>>>>>>>>>>>>>>>>>>>> follow the mouse at all.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is the same if I use spicy, spicec or vnc to connect to
>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>> virtual desktop.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This problem does not appear with cirrus or vmware graphic
>>>>>>>>>>>>>>>>>>>> drivers.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I found that on any Linux distribution (CentOS, RHEL,
>>>>>>>>>>>>>>>>>>>> Scientific
>>>>>>>>>>>>>>>>>>>> Linux, Debian, Ubuntu).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I currently use :
>>>>>>>>>>>>>>>>>>>> - qemu-kvm 1.0 compiled with spice support
>>>>>>>>>>>>>>>>>>>> - spice-protocol 0.10.1
>>>>>>>>>>>>>>>>>>>> - spice 0.10
>>>>>>>>>>>>>>>>>>>> - spice-gtk 0.7
>>>>>>>>>>>>>>>>>>>> - xorg-qxl driver 0.16
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Is there any explanation for that ?
>>>>>>>>>>>>>>>>>>> I would assume it is qxl driver cpu bound on something,
>>>>>>>>>>>>>>>>>>> probably busy
>>>>>>>>>>>>>>>>>>> waiting on the command ring. Can you run perf top on the
>>>>>>>>>>>>>>>>>>> guest?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Indeed, during the drawing in Gimp, Xorg takes between 55%
>>>>>>>>>>>>>>>>>> and 66% of CPU.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> After, Xorg goes down to 0.3%.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (Test done on CentOS 6.2 guest, with 1280 Mb vRAM)
>>>>>>>>>>>>>>>>> ok, can you drill down - you should be able to install the
>>>>>>>>>>>>>>>>> debug symbols
>>>>>>>>>>>>>>>>> for the qxl driver (xorg-x11-drv-qxl package) and see the
>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>> functions that are taking the most time.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I installed qxl driver from freedesktop.org :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> # wget -c
>>>>>>>>>>>>>>>> http://xorg.freedesktop.org/releases/individual/driver/xf86-video-qxl-0.0.16.tar.bz2
>>>>>>>>>>>>>>>> # tar xvfj xf86-video-qxl-0.0.16.tar.bz2
>>>>>>>>>>>>>>>> # cd xf86-video-qxl-0.0.16
>>>>>>>>>>>>>>>> # ./configure --libdir=/usr/lib64 --prefix=/usr CFLAGS='-O3'
>>>>>>>>>>>>>>>> # make
>>>>>>>>>>>>>>>> # make install
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you mean that I should use CFLAGS with "-g" ?
>>>>>>>>>>>>>>> I think that's it, yes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok. So how do you profile debug messages afterwhile ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I "tail -f /var/log/Xorg.0.log", the only message I got is :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Bad bpp: 1 (1)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Other messages look standard.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, that's not interesting. What I meant was:
>>>>>>>>>>>>>
>>>>>>>>>>>>> # yum install perf
>>>>>>>>>>>>> # perf top
>>>>>>>>>>>>> copy paste the top entries.
>>>>>>>>>>>>>
>>>>>>>>>>>> Ok, that's it (from a screenshot of the VM):
>>>>>>>>>>> Try ssh'ing to the vm, you can then use copy-paste.
>>>>>>>>>>>
>>>>>>>>>>>> samples    pcnt    function        DSO
>>>>>>>>>>>>
>>>>>>>>>>>> 3796.00        60.4%    hashlittle
>>>>>>>>>>> This sucks, unfortunately I don't have any quick fix for it. It's the
>>>>>>>>>>> hash computation done on each image. Needless to say it needs to be
>>>>>>>>>>> optimized - either made more efficient or reduce the number of calls.
>>>>>>>>>>>
>>>>>>>>>>> Soren, FYI.
>>>>>>>>>> You could move to murmur2, like Windows' QXL driver (https://bugs.freedesktop.org/show_bug.cgi?id=37465) or murmur3 or other faster ones (https://bugs.freedesktop.org/show_bug.cgi?id=35775).
>>>>>>>>>> At least it's not hashed twice now(https://bugs.freedesktop.org/show_bug.cgi?id=37977 - worth updating bug status?!), but I'm not sure it should be hashed at all, if it's not cached.
>>>>>>>>>> Y.
>>>>>>>>> Looks like this could be x6 performance gain when compared to hashlittle
>>>>>>>>> (lookup3 at http://code.google.com/p/smhasher/). So it would still be
>>>>>>>>> better not to run it at all but it might stop being the bottleneck. I'll
>>>>>>>>> try to do a patch.
>>>>>>>>>
>>>>>>>> Sounds promising.
>>>>>>> Actually only 2x since we use a 32bit hash anyway (x86/x64). Still worth
>>>>>>> a patch.
>>>>>>>
>>>>>> Since the hash is not in use right now at all, but commented out, you
>>>>>> could get an even more remarkable performance improvement by disabling
>>>>>> it. If you can check the branch at
>>>>>>
>>>>>>   git://people.freedesktop.org/~alon/xf86-video-qxl murmur3
>>>>>>
>>>>>> You can tell us how much it actually improves for you. I didn't disable
>>>>>> the hashing, just replaced lookup3 with MurmurHash3 from
>>>>>> http://code.google.com/p/smhasher/wiki/MurmurHash3.
>>>>>>
>>>>> I guess I missed something, because I don't manage to launch the
>>>>> X-server now in my CentOS guest.
>>>>>
>>>>> This what I have done :
>>>>>
>>>>> # git clone git://people.freedesktop.org/~alon/xf86-video-qxl
>>>>> xf86-video-qxl-alon-git
>>>>> # cd xf86-video-qxl-alon-git
>>>>> # git checkout murmur3
>>>>> # git branch
>>>>> * murmur3
>>>>>    surface-fixes
>>>>> # export
>>>>> PKG_CONFIG_PATH=/usr/local//share/pkgconfig/:/usr/local/lib/pkgconfig
>>>>> # ./autogen.sh --libdir=/usr/lib64 --prefix=/usr CFLAGS='-O3'
>>>>> # make
>>>>> # make install
>>>>>
>>>>> Where is my mistake ?
>>>> Not yours, mine. Should have tested that it at least runs (missing
>>>> symbol)
>>> Should be ok now. Tested with Xspice, but it's the same code so should
>>> be fine.
>>>
>> Yes, it works now.
>>
>> Response is also better to draw in Gimp, quite reactive (not as fast
>> however as in the windows version of qxl or with cirrus or vmware
>> xorg display driver in Linux).
> I'm having some problems with sysprof, it's saying writev but it seems
> it is ignoring my libspice-server, so I ran under valgrind and it shows
> now that most of the time is spent in quic. murmur is right after that
> (30% quic, 10% murmur). So I expect if you turn off compression it would
> speed things up, as long as the network doesn't become the bottleneck.

All my test are done with compression OFF (for the spice options) and 
locally on a Linux Workstation (simultaneous Server and Client for my VMs).

> But really the quic is being used to compress images from the uxa
> fallbacks, so I guess again that Xrender would make this go away.
>

Ok, but I don't use the quic compression (and no compression at all).

Dominique
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dominique_rodrigues.vcf
Type: text/x-vcard
Size: 296 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20120123/80858230/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3710 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20120123/80858230/attachment.bin>