Need fedora packaging

[bhepple]

I think this is likely to be an essential package for sway/fedora (waypipe is an alternate perhaps).

I can do the packaging but I need some info before I start:

What release should I target? 0.1.2, head of tree (4799f5f) or are you about to make another release?

any build-time configuration options that should be included in the general case?

Of course, if another fedora packager is already working on this, please let me know to avoid duplication (there's nothing on the bugzilla so far).

[any1]

Wayvnc and waypipe actually serve different roles. Waypipe serves the same role as X11 forwarding; i.e. it can be used to run a single application remotely over ssh and have it show up on your display. I would recommend packaging that as well. Wayvnc is for remote access to the entire desktop.

I do not know of anyone else working on packaging wayvnc for fedora. It's hard to tell when the next release will be. You should be fine with 0.1.2.

[bhepple]

OK, thanks Andri,

waypipe is already in fedora-31.

I'll get started on wayvnc-0.1.2 today hopefully. It'll take a few weeks before it goes live in fedora!! Very conservative and careful distro.

I've had good success with master so far so I'll give 0.1.2 a good workout first.

Cheers

Bob

On Sat, 11 Apr 2020 at 23:22, Andri Yngvason notifications@github.com wrote:

Wayvnc and waypipe actually serve different roles. Waypipe serves the same role as X11 forwarding; i.e. it can be used to run a single application remotely over ssh and have it show up on your display. I would recommend packaging that as well. Wayvnc is for remote access to the entire desktop.

I do not know of anyone else working on packaging wayvnc for fedora. It's hard to tell when the next release will be. You should be fine with 0.1.2.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/any1/wayvnc/issues/33#issuecomment-612420302, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQ6U2SNZIARRLULX26EB2DRMBVK5ANCNFSM4MFYUU4A .

[bhepple]

Hi Andri,

A quiet day indoors today so I made some progress with wayvnc packaging. An initial version is posted here: https://www.reddit.com/r/Fedora/comments/fzrl10/fedora_package_for_wayvnc012_is_now_available/

Next step is to submit this to the fedora gods for review.

BTW - there are a few source files without copyright notices through the 3 packages - you might want to fix that. shm.c may be a bit of a worry as it's behind a paywall. Is there any chance of getting Drew's copyright added there? The fedora people can be sticky about that sort of thing.

Cheers

Bob

On Sun, 12 Apr 2020 at 08:22, Bob Hepple bob.hepple@gmail.com wrote:

OK, thanks Andri,

waypipe is already in fedora-31.

I'll get started on wayvnc-0.1.2 today hopefully. It'll take a few weeks before it goes live in fedora!! Very conservative and careful distro.

I've had good success with master so far so I'll give 0.1.2 a good workout first.

Cheers

Bob

On Sat, 11 Apr 2020 at 23:22, Andri Yngvason notifications@github.com wrote:

Wayvnc and waypipe actually serve different roles. Waypipe serves the same role as X11 forwarding; i.e. it can be used to run a single application remotely over ssh and have it show up on your display. I would recommend packaging that as well. Wayvnc is for remote access to the entire desktop.

I do not know of anyone else working on packaging wayvnc for fedora. It's hard to tell when the next release will be. You should be fine with 0.1.2.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/any1/wayvnc/issues/33#issuecomment-612420302, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQ6U2SNZIARRLULX26EB2DRMBVK5ANCNFSM4MFYUU4A .

[any1]

Hi Bob,

Thanks for packaging wayvnc for fedora and the tips on the copyright notices. I will look into those. The code that shm.c is based on is public domain, so I guess I'll just slap a copyright notice on the file. That should appease copyright sticklers.

Now, you say "3 projects". Version 0.1.2 does not depend on the third one (aml). It depends on libuv instead. We're clear on that right? I was going to take a look at the git repo for the package to check, how it's been put together, but copr tells me that it doesn't exist, btw.

[bhepple]

Hi Andri,

I hadn't grasped that aml was not in 0.1.2 but I've fixed that up in COPR. Latest builds in COPR are at https://copr.fedorainfracloud.org/coprs/wef/wayvnc/build/1335597/

Cheers

Bob

On Sun, 12 Apr 2020 at 22:57, Andri Yngvason notifications@github.com wrote:

Hi Bob,

Thanks for packaging wayvnc for fedora and the tips on the copyright notices. I will look into those. The code that shm.c is based on is public domain, so I guess I'll just slap a copyright notice on the file. That should appease copyright sticklers.

Now, you say "3 projects". Version 0.1.2 does not depend on the third one (aml). It depends on libuv instead. We're clear on that right? I was going to take a look at the git repo for the package to check, how it's been put together, but copr tells me that it doesn't exist, btw.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bhepple]

Hi Andri,

The fedora review progresses ... couple of issues came up.

Are there significant differences in performance between -O2 and -O3 (especially for neatvnc). Do you have any benchmarks to measure it?

In meson.build the review panel want to make this change:

> cpu = host_machine.cpu_family() > > if cpu == 'x86_64' > c_args += '-mavx' > elif cpu == 'arm' > c_args += '-mfpu=neon' > endif It's better to remove that from meson.build with downstream patch. Upstream issue[2] mentions that at least x86_64 works fine without -mavx, although it does not specify if there's any noticeable performance loss. IIRC, Fedora baseline for x86_64 is K8 (no avx support) and for ARM - hardware without neon instruction set support. I could be wrong about ARM, but it's still better to keep optimization limited to distribution-wide optflags. [2] https://github.com/any1/neatvnc/issues/21

Any input you have on that?

Thanks

Bob

On Sun, 12 Apr 2020 at 22:57, Andri Yngvason notifications@github.com wrote:

Hi Bob,

Thanks for packaging wayvnc for fedora and the tips on the copyright notices. I will look into those. The code that shm.c is based on is public domain, so I guess I'll just slap a copyright notice on the file. That should appease copyright sticklers.

Now, you say "3 projects". Version 0.1.2 does not depend on the third one (aml). It depends on libuv instead. We're clear on that right? I was going to take a look at the git repo for the package to check, how it's been put together, but copr tells me that it doesn't exist, btw.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[any1]

This is a matter of reducing CPU load due to pixel conversion, which has been implemented in such a way that the compiler can auto-vectorise it.

I have not run benchmarks on the pixel conversion code recently, but at this time it has probably become a lot less significant compared to other factors such as zlib compression and damage checking.

I guess that not enabling auto-vectorisation might yield about 2% more CPU load on a 5 year old laptop. I'll do some tests later today.

[any1]

I just ran some tests on my Core i5-10210U system. The test is that I run weston-simple-egl in full screen, connect using tigervnc with ZRLE, and check the CPU load. It's hard to see any difference in terms of total CPU load when running with -mavx versus without it.

Looking at the results of "perf record", there is a big difference in how much time is spent inside pixel32_to_cpixel (2% vs. 12%), but most of the time is spent in zlib anyhow and the difference in pixel conversion doesn't really amount to much when looking at the whole picture.

With lossy tight encoding, this doesn't matter at all because pixel conversion (rgb to yuv) happens in the excellent turbojpeg library anyhow.

With the same setup, I also ran some latency tests (for 10s each) and these are the results: Without avx:

Framebuffer update:
    Min, max: 4.9 ms, 49.1 ms
    Average, std.dev.: 21.0 ms, 10.3 ms

Framebuffer update (only sending):
    Min, max: 0.1 ms, 0.8 ms
    Average, std.dev.: 0.1 ms, 0.1 ms

Screencopy:
    Min, max: 4.7 ms, 23.8 ms
    Average, std.dev.: 16.4 ms, 7.3 ms

Render:
    Min, max: 0.9 ms, 3.1 ms
    Average, std.dev.: 1.7 ms, 0.6 ms

Copy damage map:
    Min, max: 3.0 ms, 8.5 ms
    Average, std.dev.: 4.0 ms, 1.0 ms

Copy frame pixels:
    Min, max: 1.6 ms, 3.0 ms
    Average, std.dev.: 2.2 ms, 0.5 ms

With avx:

Framebuffer update:
    Min, max: 0.7 ms, 45.6 ms
    Average, std.dev.: 20.7 ms, 11.1 ms

Framebuffer update (only sending):
    Min, max: 0.1 ms, 0.9 ms
    Average, std.dev.: 0.2 ms, 0.1 ms

Screencopy:
    Min, max: 4.5 ms, 23.8 ms
    Average, std.dev.: 16.4 ms, 7.4 ms

Render:
    Min, max: 1.0 ms, 2.9 ms
    Average, std.dev.: 1.9 ms, 0.6 ms

Copy damage map:
    Min, max: 3.1 ms, 8.5 ms
    Average, std.dev.: 4.1 ms, 1.0 ms

Copy frame pixels:
    Min, max: 1.7 ms, 3.2 ms
    Average, std.dev.: 2.3 ms, 0.5 ms

Compiled without --buildtype=release (-O2):

Framebuffer update:
    Min, max: 1.5 ms, 50.9 ms
    Average, std.dev.: 23.0 ms, 11.7 ms

Framebuffer update (only sending):
    Min, max: 0.1 ms, 1.0 ms
    Average, std.dev.: 0.2 ms, 0.2 ms

Screencopy:
    Min, max: 4.9 ms, 23.7 ms
    Average, std.dev.: 16.5 ms, 7.4 ms

Render:
    Min, max: 1.0 ms, 3.3 ms
    Average, std.dev.: 1.9 ms, 0.6 ms

Copy damage map:
    Min, max: 3.0 ms, 9.1 ms
    Average, std.dev.: 4.4 ms, 1.3 ms

Copy frame pixels:
    Min, max: 1.7 ms, 3.6 ms
    Average, std.dev.: 2.3 ms, 0.5 ms

The latency test is under utils directory on the master branch in case you're interested in doing your own tests.

[bhepple]

Thanks Andri.

Have your results led you to a conclusion?

Cheers

Bob

On Sat, 18 Apr 2020 at 09:30, Andri Yngvason notifications@github.com wrote:

I just ran some tests on my Core i5-10210U system. The test is that I run weston-simple-egl in full screen, connect using tigervnc with ZRLE, and check the CPU load. It's hard to see any difference in terms of total CPU load when running with -mavx versus without it.

Looking at the results of "perf record", there is a big difference in how much time is spent inside pixel32_to_cpixel (2% vs. 12%), but most of the time is spent in zlib anyhow and the difference in pixel conversion doesn't really amount to much when looking at the whole picture.

With lossy tight encoding, this doesn't matter at all because pixel conversion (rgb to yuv) happens in the excellent turbojpeg library anyhow.

With the same setup, I also ran some latency tests (for 10s each) and these are the results: Without avx:

Framebuffer update: Min, max: 4.9 ms, 49.1 ms Average, std.dev.: 21.0 ms, 10.3 ms

Framebuffer update (only sending): Min, max: 0.1 ms, 0.8 ms Average, std.dev.: 0.1 ms, 0.1 ms

Screencopy: Min, max: 4.7 ms, 23.8 ms Average, std.dev.: 16.4 ms, 7.3 ms

Render: Min, max: 0.9 ms, 3.1 ms Average, std.dev.: 1.7 ms, 0.6 ms

Copy damage map: Min, max: 3.0 ms, 8.5 ms Average, std.dev.: 4.0 ms, 1.0 ms

Copy frame pixels: Min, max: 1.6 ms, 3.0 ms Average, std.dev.: 2.2 ms, 0.5 ms

With avx:

Framebuffer update: Min, max: 0.7 ms, 45.6 ms Average, std.dev.: 20.7 ms, 11.1 ms

Framebuffer update (only sending): Min, max: 0.1 ms, 0.9 ms Average, std.dev.: 0.2 ms, 0.1 ms

Screencopy: Min, max: 4.5 ms, 23.8 ms Average, std.dev.: 16.4 ms, 7.4 ms

Render: Min, max: 1.0 ms, 2.9 ms Average, std.dev.: 1.9 ms, 0.6 ms

Copy damage map: Min, max: 3.1 ms, 8.5 ms Average, std.dev.: 4.1 ms, 1.0 ms

Copy frame pixels: Min, max: 1.7 ms, 3.2 ms Average, std.dev.: 2.3 ms, 0.5 ms

Compiled without --buildtype=release (-O2):

Framebuffer update: Min, max: 1.5 ms, 50.9 ms Average, std.dev.: 23.0 ms, 11.7 ms

Framebuffer update (only sending): Min, max: 0.1 ms, 1.0 ms Average, std.dev.: 0.2 ms, 0.2 ms

Screencopy: Min, max: 4.9 ms, 23.7 ms Average, std.dev.: 16.5 ms, 7.4 ms

Render: Min, max: 1.0 ms, 3.3 ms Average, std.dev.: 1.9 ms, 0.6 ms

Copy damage map: Min, max: 3.0 ms, 9.1 ms Average, std.dev.: 4.4 ms, 1.3 ms

Copy frame pixels: Min, max: 1.7 ms, 3.6 ms Average, std.dev.: 2.3 ms, 0.5 ms

The latency test is under utils directory on the master branch in case you're interested in doing your own tests.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/any1/wayvnc/issues/33#issuecomment-615507820, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQ6U2WN4YQ75JTHEUELGQTRNDRCLANCNFSM4MFYUU4A .

[any1]

Have your results led you to a conclusion?

Yes, there is no significant performance difference under the specified conditions on my current laptop.

[bhepple]

Thanks Andri, I'll make a note of that in the spec file. Meanwhile wayvnc has hit the official fedora servers.

Cheers

Bob