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
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
