Yes, it is for people who don't want to waste time learning useless stuff that is normally needed only once
And such people don't compare unstable versions with matured releases
Note, in particular, that the xf86-video-intel port is still maintained; it received an update to a newer upstream version just a few weeks ago.
IMHO for average "office desktop" usage, even basic software-only acceleration is fully sufficient.I've not looked if there's a performance difference between the drivers.
Yes, e.g. for watching a video, hardware acceleration does make a significant, noticeable difference.That might be interesting to look at,
I learned from a link posted here somewhere in the forum, that surprisingly, 2D accel can be as difficult to implement as 3D accel. The add-on X11 moduleif someone knows a nice simple application to test/measure 2D acceleration I can try to get some measurements.
Section "Module"
load "glamoregl"
EndSection
Section "Device"
...
Option "AccelMethod" "glamor"
...
For example, it showed that for GPU generation 1-3 (or even higher?) i915kms.ko must not be loaded, and drm-kmod must not be installed if one wants to use Xorg.
Good idea!... the info being collated is incredibly useful, do you intend to add it to the FreeBSD Wiki?
Good to learn about this!Just to add to this, I switched a few months ago from using the "modesetting" driver (with "glamor" enabled) to using "xf86-video-intel" because it seems the *only* way to get tear free rendering in practice. I have an SDL demo app which scrolls a checkerboard image very fast across a window, you can immediately spot the tearing with anything other than the intel driver (with or without a compositor). I can't quite get my head around why the modern "modesetting" driver using hardware accelerated OpenGL for rendering (glamor) is unable to provide tear free rendering?
Thus should imho be enabled when hardware/FreeBSD version combination permits.... for watching a video, hardware acceleration does make a significant, noticeable difference.
Aww yes, I didn't even think of Glamor, until JAW and you pointed at it!I learned from a link posted here somewhere in the forum, that surprisingly, 2D accel can be as difficult to implement as 3D accel. The add-on X11 module ... "glamoregl" ... claims to provide reasonable, decent 2D acceleration for any hardware.
Mhh... in the thread of k.jacker which you pointed me at, people wrote a few years ago that they either could have loaded i915kms.ko or run Xorg./boot/kernel/i915kms.ko from the base system have or had^^ to be loaded.
Mhh... in the thread of k.jacker which you pointed me at, people wrote a few years ago that they either could have loaded i915kms.ko or run Xorg.
Maybe that changed meanwhile?
If no drm driver (amdgpu/radeonkms/i915kms.ko) is loaded:
Vesa will be used on legacy boot configurations and loads automatically too.
Scfb will be used on UEFI boot configuartions and needs to be specified in an xorg configuration.Driver "scfb"
etc...
https://gitlab.freedesktop.org/xorg...tel/-/blob/master/src/intel_module.c#L428-433 via #if UMS guard suggests only Gen1 can be used without kernel drivers.This is why I am so interested in knowing whether the x11-drivers/xf86-video-intel can also be used without KMS+drm-kmod, only with user mode switching.
pciconf -lv | fgrep -A1 -B3 display
vgapci0@pci0:0:2:0: class=0x030000 card=0x503617aa chip=0x16168086 rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 5500'
class = display
subclass = VGA
sysctl -n hw.model
Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
(Broadwell) fgrep compat.linuxkpi /boot/loader.conf
compat.linuxkpi.enable_rc6="7" # ENABLE POWER SAVING RENDER C-STATE 6
compat.linuxkpi.enable_dc="2" # ENABLE POWER SAVING DISPLAY C-STATES
compat.linuxkpi.enable_fbc="1" # ENABLE FRAME BUFFER COMPRESSION FOR POWER SAVINGS
compat.linuxkpi.i915_fastboot="1" # SKIP UNNECESSARY MODE SETS AT BOOT TIME
compat.linuxkpi.i915_nuclear_pageflip="1"
compat.linuxkpi.semaphores="1" # USE SEMAPHORES FOR INTER RING SYNC
Option "TearFree" "on"
in /usr/local/etc/X11/xorg.conf.d/video.conf, I still have extensive flickering on the sddm(1) login screen (?), but not when a user loged into KDE. Occasionally, some videos does not seem to be handled well, I guess that's when weird encodings are used.Hmm... yes... I think I saw that, too, but interpreted it in the way that only on 1st Gen there is no KMS option, or the distinction KMS/UMS even completely been given up.https://gitlab.freedesktop.org/xorg...tel/-/blob/master/src/intel_module.c#L428-433 via #if UMS guard suggests only Gen1 can be used without kernel drivers.
...I can put .. our findings ... on the wiki.
For Intel, I am still not sure what needs to go into the "DB".I guess you already have my system in your DB?
'1616' ==> [ 'BDW', '?', '8.0', '12.2?', 'Yes', 'Yes', 'Yes', '2015?', 'Broadwell GT2 ULT [ULT_GT2]' ],
compat.linuxkpi.enable_rc6="7" # ENABLE POWER SAVING RENDER C-STATE 6
compat.linuxkpi.enable_dc="2" # ENABLE POWER SAVING DISPLAY C-STATES
compat.linuxkpi.enable_fbc="1" # ENABLE FRAME BUFFER COMPRESSION FOR POWER SAVINGS
compat.linuxkpi.i915_fastboot="1" # SKIP UNNECESSARY MODE SETS AT BOOT TIME
compat.linuxkpi.i915_nuclear_pageflip="1"
compat.linuxkpi.semaphores="1" # USE SEMAPHORES FOR INTER RING SYNC
jitte@onryo:~ $ dmesg
FreeBSD 12.2-RELEASE-p4 GENERIC amd64
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (2394.05-MHz K8-class CPU)
drmn0: <ATI Mobility Radeon HD 3400 Series> on vgapci0
info: [drm] RADEON_IS_PCIE
info: [drm] initializing kernel modesetting (RV620 0x1002:0x95C4 0x17AA:0x210E).
info: [drm] register mmio base: 0xCFFF0000
info: [drm] register mmio size: 65536
info: [drm] radeon_atrm_get_bios: ===> Try ATRM...
info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002, device=95c4
info: [drm] radeon_atrm_get_bios: Get ACPI device handle
info: [drm] radeon_atrm_get_bios: Get ACPI handle for "ATRM"
info: [drm] radeon_atrm_get_bios: Failed to get "ATRM" handle: AE_NOT_FOUND
info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT...
info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table
info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND
info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM...
info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000
info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes)
info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0xFFFF
info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM...
info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes)
info: [drm] ATOM BIOS: M82
drmn0: info: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used)
drmn0: info: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF
info: [drm] Detected VRAM RAM=256M, BAR=256M
info: [drm] RAM width 64bits DDR
[TTM] Zone kernel: Available graphics memory: 4139498 kiB
[TTM] Zone dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
info: [drm] radeon: 256M of VRAM memory ready
info: [drm] radeon: 512M of GTT memory ready.
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
info: [drm] MSI enabled 1 message(s)
drmn0: info: radeon: using MSI.
info: [drm] radeon: irq initialized.
*
info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xe0000000
radeon_iicbb0 on drmn0
info: [drm] Radeon Display Connectors
info: [drm] Connector 0:
info: [drm] DVI-I-1
info: [drm] HPD3
info: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
info: [drm] Encoders:
info: [drm] DFP1: INTERNAL_UNIPHY
info: [drm] Connector 1:
info: [drm] LVDS-1
info: [drm] Encoders:
info: [drm] LCD1: INTERNAL_KLDSCP_LVTMA
info: [drm] Connector 2:
info: [drm] VGA-1
info: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
info: [drm] Encoders:
info: [drm] CRT1: INTERNAL_KLDSCP_DAC1
info: [drm] radeon: power management initialized
info: [drm] Connector DVI-I-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.DVI-I-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] Connector LVDS-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.LVDS-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] Connector VGA-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.VGA-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] fb mappable at 0xD0142000
info: [drm] vram apper at 0xD0000000
info: [drm] size 4096000
info: [drm] fb depth is 24
info: [drm] pitch is 5120
fbd0 on drmn0
VT: Replacing driver "vga" with new "fb".
Umm... something "i3"... and "HD Graphics"... does this help?The idea is not bad but, isn't it easy to just ask a question via shell dialog to the user which generation he has or from which series or similar he have something?
So you only need such a script if you don't know ...
Personally, I prefer to avoid hard-coding as much as possible.That way you can split up a lot of things. Example: .if ${INTELGEN} >= i10 then .....use 13+ or something like that.
I have not yet managed to find a list of supported cards or PCI IDs for Linux 4.16s' DRM.according to the FreeBSD wiki: " FreeBSD 12, using drm-kmod, support is the same as on Linux 4.16". Linux 4.16 has only support till Coffe Lake (8 Gen). Your CPU/GPU is Comet Lake (Gen 10) so you need a drm-kmod based on Linux 5.4 and that module can only be founded in FreeBSD 13.0.
Kaby Lake is Gen. 9.5.Running an HD630 and it is fine with the graphics/drm-kmod driver meta port. Running this on 12.0-RELEASE p1. I have an Intel i7-7700 Kaby Lake. Not a heavy gamer though: only run older (90's, early 2000's) games. Desktop performance is great.
I'd love to help with thatFor the chipsets below Sandy Bridge, I have listed my personal guesses into the blue air.
These can only be tested by people who have such rare old hardware.
CPU: Intel(R) Core(TM) i3 CPU 550 @ 3.20GHz (3197.79-MHz K8-class CPU)
[ ~ ]freebsd-version -kru
13.0-RC3
13.0-RC3
13.0-RC3
[ ~ ]inxi -G
Graphics: Message: No Device data found.
Display: server: X.Org 1.20.9 driver: modesetting resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 20.2.3
[ ~ ]sysinfo cpu
Generated by SysInfo v1.0.1 by Daniel Gerzo
CPU information
Machine class: amd64
CPU Model: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
No. of Cores: 4
Cores per CPU:
CPU usage statistics:
CPU: 8.9% user, 0.0% nice, 0.8% system, 0.4% interrupt, 90.0% idle
CPU: 14.7% user, 0.0% nice, 2.6% system, 0.8% interrupt, 81.9% idle
# sysinfo cpu
Generated by SysInfo v1.0.1 by Daniel Gerzo
CPU information
Machine class: amd64
CPU Model: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
No. of Cores: 1
Cores per CPU:
CPU usage statistics:
CPU: 1.3% user, 0.0% nice, 0.7% system, 0.0% interrupt, 98.0% idle
CPU: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle
Did they donate that board to you? No? Then the mickey "did not feel the necessity to" check that before buying that MB?I'd love to help with that
Unfortunately the mainboard manufacturer (Gigabyte) did not feel the necessity to include a graphics port of some kind on that mainboardCode:CPU: Intel(R) Core(TM) i3 CPU 550 @ 3.20GHz (3197.79-MHz K8-class CPU)
wasn't there some xperf command? It's been 25 years since I used it, so might be gone or my memory is bad.I've not looked if there's a performance difference between the drivers. That might be interesting to look at, if someone knows a nice simple application to test/measure 2D acceleration I can try to get some measurements.
Traditionally my home servers have always been for the most part assembled from used components that had either been in use in my other machines before, or that I got from other sources. Also I don't replace hardware just because it's trendyness has worn off, as long as it's performance is adequate for the task at hand. I had a Pentium-MMX dual processor board that was happily running FreeBSD for more than 12 years, when it finally got replaced. This particular Gigabyte board I got from a friend and used the opportunity to switch from FreeBSD/i386 to FreeBSD/amd64. Yes, it is first gen core-i processor and the implementation is cumbersome to say the least.Did they donate that board to you? No? Then the mickey "did not feel the necessity to" check that before buying that MB?