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

Mon Jan 23 04:40:14 PST 2012

On 01/23/2012 12:26 PM, Dominique Rodrigues wrote:
> 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.

Would be interesting to see if those are the same images over and over - 
which means caching would have helped a lot.
A network capture could help easily determine this.
Y.

>
> 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