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% hashlittleThis 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
<<attachment: dominique_rodrigues.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
