Questions about experimental Spice compositor rebase

[Fabio Fantoni]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160320/e2be079c/attachment-0001.html>