Re: SOLVED Re: Sloow blender on FreeBSD (vs Ubuntu)

On 2021-01-17 02:35, Mathias Picker wrote:
> ...
>>>> Then I tried my 1st gen Surface Go 8Gb running Ubuntu: Blender is 
>>>> blazing fast for these simple tasks. Fluid rotation, allmost real 
>>>> time grease pencil：WTF?
>>>> ...
>> Just tried a live CD of Ubuntu on the same machine, with the demo 
>> Race Spaceship 
>> https://download.blender.org/demo/eevee/race_spaceship/race_spaceship.blend
>>
>> This is a compley scene and can be rotated with ubuntu in real time 
>> in material
>> mode, and is only very slightly lagging in rendered mode.
>>
>> On FreeBSD that spaceship rotates about as slow and stuttery as the 
>> default
>> cube.
>> So it does not seem to be dependent on the complexity of the scene.
>>
>> Any ideas where to look?
>>
>> Any ideas whom to ask?
>>
>> Thanks, Mathias
>
> Using either
>
> vblank_mode=0 blender
>
> or
>
> LIBGL_DRI3_DISABLE=1 blender
>
> gives me the speed I need. Now it’s faster than the surface go ;)


Thanks for sharing!
Unfortunately I don't have a good understanding of the whole DRI 
infrastructure.
Just recently had an issue with xfwm4 (can't remember the symptoms) 
where altering "vblank_mode" was the solution too
(xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "off" 
--create in that case)

And regarding performance, I'd like to share that
using  x11-drivers/xf86-video-intel slows down XFCE4 by some orders of 
magnitude compared to the 'modesetting' (xorg builtin component) driver.

On FreeBSD and GPUs starting with KabyLake (Haswell-GT2), you get an 
amazing responsive GUI setup simply by installing
drm-(515-)kmod,
using 'Driver "modesetting"' (in 'Section "Device"') and
'Load  "glamoregl"' in 'Section "Module"' in your xorg.conf.

Also utilizing/configuring libinput(4) with X.org  isn't documented 
well. Even worse, x11-servers/xorg-server doesn't depend on 
x11-drivers/xf86-input-libinput.
Which I found to be the best way to deal with input devices on recent 
FreeBSD versions.
Despite unrelated to the topic, here's a xorg.conf snippet, which brings 
a reasonable mouse pointer acceleration, disables (virtual) moused(8) 
and kbdmux(4) devices prefering the real HID hardware, supported by 
kernels compiled with 'options EVDEV_SUPPORT' & 'device evdev' - which 
GENERIC/MINIMAL do have by default for quiet some time.
There were so many great improvements, it's a pity so few people make 
use of it - at least the available guides don't reflect them...


cat /usr/local/etc/X11/xorg.conf.d/00-keyboard.conf
Section "InputClass"
     Identifier "local keyboard defaults"
     MatchIsKeyboard "on"
     Option  "XkbLayout"    "us"
     Option  "XkbModel"    "pc104"
     Option  "XkbVariant"    "altgr-intl"
     Option  "XkbOptions"    "terminate:ctrl_alt_bksp"
EndSection

Section "InputClass"
         Identifier      "FreeBSD system keyboard by kbdmux(4)"
         MatchIsKeyboard  "on"
         MatchProduct    "System keyboard multiplexer"
         Option  "Ignore" "on"
EndSection


cat /usr/local/etc/X11/xorg.conf.d/10-mouse.conf
Section "InputClass"
     Identifier    "HP Omen 600 Gaming Mouse"
     MatchProduct    "HP HP Gaming Mouse"
     MatchIsPointer    "on"
#     MatchUSBID    "03f0:1c41"
     Option    "AccelProfile"     "custom"
     Option    "AccelPointsMotion" "0 0.8 1.5 2.0 4.0"
     Option    "AccelStepMotion"   "2.5"
     Option    "NaturalScrolling" "on"
# def:    Option    "ScrollButton"     "2"
     Option    "ScrollMethod"     "button"
# def:    Option    "ScrollPixelDistance" "15"
EndSection

Section "InputClass"
         Identifier    "FreeBSD sysmouse by moused(8)"
         MatchIsPointer    "on"
     MatchProduct    "System mouse"
#        MatchDevicePath    "/dev/input/event*"
         Option    "Ignore" "on"
EndSection


-harry