[Cin] libaom 3.2.0 patch1 fixed for arm/linux?

[Andrew Randrianasulu]

On Wednesday, January 12, 2022, <mnieuw at zap.a2000.nl> wrote:

> On Tue, 11 Jan 2022 22:26:51 +0300
> Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
>
> > On Tuesday, January 11, 2022, Andrew Randrianasulu
> > <randrianasulu at gmail.com> wrote:
> >
> > >
> > >
> > > On Tuesday, January 11, 2022, <mnieuw at zap.a2000.nl> wrote:
> > >
> > >> On Tue, 11 Jan 2022 18:46:59 +0300
> > >> Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
> > >>
> > >> <snip>
> > >> > > > I think you already using system mode (full system emulation
> > >> > > > - so you can run NetBsd or MacOS or windows - they see
> > >> > > > emulated/virtual machine to run on..) User-mode qemu run
> > >> > > > Linux binaries on top of same kernel BUT they can belong to
> > >> > > > another architecture! So overhead can be less.. (no mmu
> > >> > > > emulation). You can edit files inside proot 'vm' from host -
> > >> > > > no need for samba/nfs.
> > >> > >
> > >> > > I have macOS in user mode, it runs fine (but need to
> > >> > > re-install). It also ran fine in system mode (since deleted).
> > >> > > I have not checked if there is a speed difference between the
> > >> > > two nodes, nothing very noticable anyway.
> > >> >
> > >> >
> > >> > I think your terminology on system/user modes a bit different
> > >> > from assumed by qemu?
> > >> >
> > >> > Can you try to explain what you mean by those two modes in your
> > >> > own words/experience?
> > >>
> > >> In virt-manager you can have two kinds of VMs: QEMU/KVM and
> > >> QEMU/KVM User Session. The first is referred to as "system", the
> > >> second as "session". The default on Fedora_35 is (user) session,
> > >> where qemu runs under the user's profile. If you use virsh to e.g.
> > >> edit the VM's config you can type e.g. "virsh edit
> > >> Debian11_aarch64" . If you want to use a VM under system, you have
> > >> to type "virsh --connect qemu:///system edit Debian11_aarch64".
> > >> The VMs have a different domain specified in the XML that defines
> > >> a VM. user mode has domain "qemu", system mode domain "kvm".
> > >> I noticed that whereas in user (session) mode you can define pretty
> > >> much any hardware for the VM, in system mode some things are not
> > >> available, like PCIe controllers.
> > >
> > >
> >
> >
> > https://wiki.libvirt.org/page/FAQ#What_is_the_difference_
> between_qemu:.2F.2F.2Fsystem_and_qemu:.2F.2F.2Fsession.3F_
> Which_one_should_I_use.3F
> >
> > ====
> > What is the difference between qemu:///system and qemu:///session?
> > Which one should I use?
> > All 'system' URIs (be it qemu, lxc, uml, ...) connect to the libvirtd
> > daemon running as root which is launched at system startup. Virtual
> > machines created and run using 'system' are usually launched as root,
> > unless configured otherwise (for example in /etc/libvirt/qemu.conf).
> >
> > All 'session' URIs launch a libvirtd instance as your local user, and
> > all VMs are run with local user permissions.
> >
> > You will definitely want to use qemu:///system if your VMs are acting
> > as servers. VM autostart on host boot only works for 'system', and
> > the root libvirtd instance has necessary permissions to use proper
> > networkings via bridges or virtual networks. qemu:///system is
> > generally what tools like virt-manager default to.
>
> Not anymore. virsh default is session (user), virt-manager shows
> whatever VMs are existing, in two list depending on the connection.



good to know, in case someone will need this info!


> > qemu:///session has a serious drawback: since the libvirtd instance
> > does not have sufficient privileges, the only out of the box network
> > option is qemu's usermode networking, which has nonobvious
> > limitations, so its usage is discouraged. More info on qemu
> > networking options:
> > http://people.gnome.org/~markmc/qemu-networking.html
>
> This networking info is out-of-date, at least for Fedora_35. The Fedora
> default setup already creates a bridge device, which is needed for user
> mode networking. It simply worked out of the box, even a network install
> where the booted system is at a minimum. On none of the three VMs I
> created so far was networking a problem. I don't remember if the first
> instance on install was NAT or bridge.


good!



> >
> > The benefit of qemu:///session is that permission issues vanish: disk
> > images can easily be stored in $HOME, serial PTYs are owned by the
> > user, etc.
>
> What is a problem is file sharing, cut-and-paste, audio. Not of course
> for real hardware, but would be nice-to-have for the VMs. On Fedora_35,
> you get either frequent SELinux errors (some of which you can negate),
> or the solutions found on the web simple don't work, presumable because
> their qemu was much older.


well, hopefully we can troubleshut them one by one. Just on new email
thread.



> > ====
> >
> > well... this is something virt-manager specific as I guessed..  all
> > qemu modes likely run qemu-system-* under the hood (but uml is
> > user-mode linux and lxc is container... mode. non-system, as far as
> > guest kernel not needed for them... if I recall things correctly!).
> > you can check with top while vm is running...
>
> virt-manager is a GUI front-end for libvirt, which is what really
> interfaces to a VM. Multiple VM types are supported by libvirt, like XEN
> and QEMU, but virt-manager is much more limited .
>
> You'll find many instructions to use virsh or cmd line to configure
> qemu. Very uncomfortable compared to virt-manager, which is more like
> VirtualBox in this respect, although I use virsh as well, but only if I
> cannot get a new VM install going using virt-manager.
>
> Indeed all qemu emulations are called qemu-system-xxxx . When a system
> emulation is installed (like aarch64) then virt-manager puts it in the
> list of options for the architecture of a new VM. I have X86_64, armhf,
> and aarch64 at the moment.



I found two papers/slideshows describing qemu-system vs qemu-user

back in qemu-0.12.5 days proot + qemu-user was like 2x-4x faster than
qemu-system (compilers tend to use integer arithmetic units, not fpu/simd).
But since those days qemu in general improved and some devices now
virtualized (less overhead)

https://web.archive.org/web/20111119183403if_/http://adt.cs.upb.de:80/quf/quf11/quf2011_13.pdf

https://web.archive.org/web/20150301073841if_/http://adt.cs.upb.de:80/quf/quf2011_proceedings.pdf

(see p. 48)



>
> My new CPU arrived, and I see a big increase in speed.
> 2400G versus 5700G:
> 4 minute 1080p30 video render with default settings: 32.5 fps -> 78 fps
> (no hardware support). But CPU was never 100%, 80% was peak,
> obviously there are some non-CPU limits there). It could be it is
> faster on Mint 20.2 where I can use vaapi for rendering (Fedora does not
> seem to support that).


it should - one more item to troubleshoot..


Compile CinGG after "make new" 12 minutes -> 4 minutes (just enough
> time to make myself a new coffee...)


3x faster! nice


> Boot Debian_11_aarch64 until login screen: 86 secs -> 55 secs.
> Login until desktop ready (CPU load drops stark): 68 secs -> 38 secs.
> If feels much more responsive too.


cool! I was afraid new cpu might be delayed into infinity due to electroncs
components shortages/delays...

>
> Regrettable, I don't think building on aarch64 will be much faster
> (will time it): virt-manager does not allow more than 8
> vCPUs to that VM, maybe it is architecture dependent. However, in many
> places there are single threaded pieces in the build, they will
> definitely speed up because the turbo is 30% higher, and there are more
> instructions per clock.


I hope cooling part (fan assembly) and PSU/motherboard will handle this
well..

good luck with new machine!

>
> MatN
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220112/dd49f99d/attachment-0001.htm>