Il 14/03/2016 00:09, Fabio Fantoni ha scritto:
Il 12/03/2016 23:13, Fabio Fantoni ha scritto:
Il 10/03/2016 22:58, Yury Shvedov ha scritto:
On 03/10/2016 06:04 PM, Fabio Fantoni wrote:
In recent years have done too little programming and mymemory is
bad lately.
About the performance problem I remember something like a big
problem also in xspice that seems improved a lot with deferred fps:
https://lists.freedesktop.org/archives/spice-devel/2012-August/010276.html
Can be useful for this project or with wayland/weston is possible
do something similar in a different and/or better way?
Of corse this is useful like all the stuff you found in the net last
time. But you chaotically offers me many different things without
any result except my "OK, I will take a look". Because I have not
much time to investigate it with you. You are looking for the
answers on your questions in the internet, while I have a couple in
the code. I see good way for the next steps and have tried to
explain them to you. I'm afraid that you didn't understand them, so
I'll try again at the bottom of this message.
After that I suggest to decide and fix what we will do next.
In the weekend probably I'll look better the weston code but I not
know if I'll have needed freetime and knowledge for doing something
useful for the mainly problem in a short time.
Maybe you better to do something in what you sure? How about fps
tests like ones in your link?
I did a fast test with screen-share for see if it can works also with
other compositor instead rdp but was failed and I not found nothing
in weston log about.
I tried to see if was possible have weston working local normal with
drm (3d and good performance) and additionally add spice session and
after check if was possible and better add a "deferred fps" in
screen-share to limit the screen data that spice-compositor must
elaborate.
I take a fast look also to qemu and xspice code trying to understand
the initial improvement to do about image processing but seems that
qemu do operation with vm qxl drivers and xspice similar copied by it
and using qxl driver.
I I do not know if this is possible in other better way with weston
(I have no knowledge to understand if it is something like what you
mean about making a spice_renderer).
Maybe tomorrow I will have a few more hours of time and do not know
whether to try anyway to add deferred fps quickly from xspice or
looking something about weston things you write below.
Unfortunately I must did other things today and I had only short time
to give another fast look to code, I did also another test (to find
some data on how is useful to proceed without waste time), I found
high cpu usage (only one core, like one spice efficiency problem that
I had noticed long ago instead weston ifself) even if without any
spice session, then I enabled spice debug and I see input fps to 967
(with no spice session and without any screen change I suppose), then
deferred fps seems a good fast workaround to do for start (I'll try to
implement it following xspice next weekend) and try to send only the
difference (where possible) seems probably the best thing as you said.
I unfortunately had short time also this weekend.
I tried to search a more efficient way to limit fps send to spice
(instead of adding another buffer like xspice) and probably I found
something about increase delay with "wl_event_source_timer_update", I
tried to increased delay set to time_start in
spice_output_start_repaint_loop function but the fps are still up near 1000.
I checked in rdp compositor and seems that delay is in
rdp_output_repaint instead of rdp_output_start_repaint_loop:
"wl_event_source_timer_update(output->finish_frame_timer, 16);"
I suppose that now in spice compositor there a delay only at the loop
starts and/or "b->core->timer_start (output->wakeup_timer, 1);" in
"on_wakeup" (if is this the 1 ms delay will explain the actual fps near
to 1000)
Can someone tell me if my assumptions are right and if right what is the
better way to add a delay, using it for limit fps and make it settable
(for example max fps minimum to 10, maximum to 100 and default to 30)
without negative effects please?
I also tried to enable a weston debug to understand something faster and
use it as help in some fast tests, I tried with a fast google search
founding only WAYLAND_DEBUG=1 but seems that weston debug output is
partial or missed, is there another way?
I also found a "#define DEBUG 2" in compositor-spice-conf.h, this I
suppose should force weston debug level using spice compositor (with
COMPOSITOR_SPICE_CONF_H) but I did a grep without finding something
using it, can someone help me to understand please?
is the file compositor-spice-conf.h needed or can be removed? (seem used
only for change debug and set spice compositor version but with a grep
version seems unused and I suppose if will be needed can be setted
always and in compositor-spice.c instead)
For any developer reading this thread for the first time, here the spice
compositor repository: https://github.com/ein-shved/compositor-spice
And here latest patch to make faster see the spice compositor
additions/changes rebased on recently weston upstream:
https://github.com/Fantu/compositor-spice/commit/3a75bb84da4650dd186f3f025c3640a65600bc6d
- https://github.com/Fantu/compositor-spice/commits/rebase/spice-master
Thanks for any reply and sorry for my bad english.
I started to do small things fast and easy for doing something in
short time and start to watch something about weston and this
project code
Things done I think/hope is still something useful because make
possible do some fast tests (I think useful for a project in
development), remote use (lan or wan) that I think is the main goal
of this project, auth (password) is needed for at least an
essential security (mainly for wan test without vpn), image
compression to make it usable on <1gbps network and not throttle
the network, and additional wan compressions to make it usable on
wan connections (if are not too bad) based on my spice experience.
There much more ways to decrease the network usage and increase fps
except compression.
I used/tried many remote access softwares, mainly for virtual
machine but not only, spice is a very good one, with high quality
but with efficiency/latency issues visible in most recent use cases.
I'm trying to help this project because seems the better quality
and full open source project I found to reach one of my purpose:
remote access and remote assistance on linux physical machine; one
missed or bad thing on actual linux machines and one blocking step
for windows->linux migration in many cases. There is also xspice
project in a more advanced state but is based on xorg that is old,
with less potential and I suppose it is a bad long-term choice.
I'm appreciate your help and interest (the windows to linux
migration is really good point!) and I hope one day this project
became something we wand to see.
Another thing is that 3d hw acceration is increasingly necessary
and in future will be essential for any use (also basis) on any
device (including virtual machine). Trying to implement the better
solution as possible to have 3d hw support and improve spice
efficiency and latency seem more easy and fast here before instead
of doing in virtual machine or I'm wrong?
I'm afraid I didn't catch last sentence. What doing in virtual machine?
Returning to our main topic. How do I suppose to increase fps and
decrease network usage?
The main idea is to decrease the amount of image data sended via
network. For example, we have an application window moving on the
desktop background. The bad way is to compose the whole desktop
image on each step on the server and send it to client. But the
better way is to send to client 2 images once and tell him to change
position of one of them when it is needed. I think this example is
obvious for you and you should know that spice can perfectly handle
such tasks (moving images remotely and much more). This is the first
aim I want to achieve: to cache the per-application surface on the
client side, and left the building of final desktop image to it.
This can be done by creating the spice_renderer and using it instead
of pixman_renderer for distributed painting.
Another thing I want to do first is to understand, what does the
rdp-compositor do before sending the image data? The learning how
dose rdp_output_repaint and other functions works will help us to
find another one already passed way to optimisation.
What do you think? Do you have another suggestions about the way of
this spice-compositor developing?
I'm having difficulty to understand at least the basics of what is
needed in a short time, for sure you know much more.
Maybe about tips on what to do can be helpful to post the current
draft of the patch as an RFC (request for comments) on wayland-devel
and spice-devel and probably some expert developers about them can
fastly give some advices.
I did the same with other things and they gave me useful information
to make fast patches I needed analyzing a few specific things instead
of read/understand all the code of large pieces. Probably also with
this can be useful to understand something useful I can do the first
weekends instead spent all time to learn, but if learn many things
before is really needed I'll try to do it. It seems that
unfortunately I'm no longer quick to learn/understand as I did years
ago (years ago unfortunately, however, I wasted thousands of hours
with unnecessary proprietary projects instead) :(
Thanks for any reply and sorry for my bad english.
Kind regards
Yury Shvedov
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
