Announcement

Collapse
No announcement yet.

Why don't we use the Intel ClearLinux Kernel - As AMD owners?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why don't we use the Intel ClearLinux Kernel - As AMD owners?

    So I have been having some audio skipping issues of late with my screen grabs on Linux. I tested on Windows and the issues went away and easily maintained 1x. With Linux I was barely able to get over 0.9 speed sometimes it would get to around 0.996.

    PC spec is 3900X with 32GB 3200Mhz, 5700XT and I use Arcolinux (Arch) KDE - Fully update to date as at 1 Oct 2020.

    I decided to install Linux-Clear due to my issues. This is just some rough benchmark results encoding two files with ffmpeg. The source files are saved on my ram drive and encoded to the same ram drive. On Windows I just used a 1TB NVme running ExFAT. For each kernel I tested each file twice and took the avg. I also rebooted between each test so basically each kernel got tested 4x.

    Source file 1080p15 (CRF 0) -> 1080p15 Nice compressed superb quality small file
    A) 180MB -> 12MB
    B) 3GB - > 254MB

    1. Linux-lts (5.4) = A) 91fps, B) 108fps
    2. Linux-arch (5.8.12) = A) 96fps, B) 111 fps
    3. Linux-AMD (5.8.12) = A) 96fps, B) 111 fps
    4. Linux-clear (5.8.12) = A) 155fps B) 182fps
    5. Windows 10 = A) 105fps B) 122fps

    I was SO surprised by how fast it is on my AMD hardware that I almost want to buy Intel again just to say thanks. Hopefully they don't read this and gimp me...

    The only negative I have encountered so far is my fstab samba shares don't mount at all "An error occurred while accessing '/media/Zips', the system responded: Couldn't chdir to /media/Zips: No such device". I can smb:// in Dolphin though.

    I almost forgot on file A) my times go from 63s -> 40s and CPU usage while doing my screengrabs goes from like 70% for FFMPEG -> 22% with Clearlinux. Not only is it WAY faster but uses less % in all the tasks I monitored, viewing YouTube, my Online meetings (Brave 40% -> 17%). I am gob smacked.

    ffmpeg 4.3.1 - GCC 10.1.0

    My screengrab code for source file
    ffmpeg -rtbufsize 100M -f x11grab -thread_queue_size 1024 -probesize 50M -s 1920x1080 -r 15 -i :0.0+1920,0 -f p
    ulse -thread_queue_size 2048 -ac 2 -i 3 -ar 44100 -filter:a "asetpts=N/SR/TB" -c:v libx264 -tune zerolatency -crf 0
    -preset ultrafast -c:a pcm_s16le -y a.mkv


    On Windows
    ffmpeg -rtbufsize 100M -f gdigrab -thread_queue_size 1024 -probesize 50M -s 1920x1080 -r 15 -offset_x 1920 -i desktop -f dshow -i audio="Stereo Mix (Realtek(R) Audio)" -ac 2 -ar 44100 -filter:a "asetpts=N/SR/TB" -c:v libx264 -tune zerolatency -crf 0 -preset ultrafast -c:a aac -b:a 64k -y a.mkv
    CPU Usage around 7% - Oddly GPU shows "Video Encode" of 20% even though I'm not using amf.

    Code for generating small file
    ffmpeg -i a.mkv -c:v libx264 -crf 27 -x264-params cabac=1:ref=5:analyse=0x133:me=umh:subme=9:chroma-me=1:d
    eadzone-inter=21:deadzone-intra=11:b-adapt=2:rc-lookahead=60:vbv-maxrate=10000:vbv-bufsize=10000:qpmax=69:bframes=5:
    b-adapt=2:direct=auto:crf-max=51:weightp=2:merange=24:chroma-qp-offset=-1:sync-lookahead=2sy-rd=1.00,0.15:trellis=
    2:min-keyint=23artitions=all -c:a aac -ac 1 22050 -b:a 32k $(date "+%Y-%m-%d_%H-%M").mkv

    So...Assuming I can fix my fstab shares, why would anyone want to use the normal kernel? I'm keen to try some games.
    "//192.168.1.4/Music /media/music cifs noauto,defaults,vers=1.0,username=xx,password=xxxx ,x-systemd.automount,_netdev,users 0 0"
    Last edited by dfyt; 01 October 2020, 02:01 PM.

  • #2
    I used to be able to use SimpleScreenRecorder on VERYSLOW and CRF 23 but lately the OpenGL part stopped working and when doing normal "screen" recording with it my audio samples get lost and I have skipping issues. So I USED to be able to go straight from screen recording - > small file but not lately. +- 6 weeks - some sort of regression somewhere. Hopefully with ClearLinux I can use SSR again and go direct.
    Last edited by dfyt; 01 October 2020, 02:14 PM.

    Comment

    Working...
    X