[drm-kmod] Help completing the compatibility matrix "Intel GPUs vs FreeBSD versions"

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 :)
 
Snurg said:
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 :)
Click to expand...

Even without the script the info being collated is incredibly useful, do you intend to add it to the FreeBSD Wiki?

olli@ said:
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.
Click to expand...

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?
 
SirDice said:
I've not looked if there's a performance difference between the drivers.
Click to expand...
IMHO for average "office desktop" usage, even basic software-only acceleration is fully sufficient.
SirDice said:
That might be interesting to look at,
Click to expand...
Yes, e.g. for watching a video, hardware acceleration does make a significant, noticeable difference.
SirDice said:
if someone knows a nice simple application to test/measure 2D acceleration I can try to get some measurements.
Click to expand...
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
Code: 
Section "Module"
    load "glamoregl"
EndSection
Section "Device"
    ...
    Option     "AccelMethod"   "glamor"
    ...
claims to provide reasonable, decent 2D acceleration for any hardware.
 
JAW said:
... the info being collated is incredibly useful, do you intend to add it to the FreeBSD Wiki?
Click to expand...
Good idea!
I'd have been happy if such info already would have been on the wiki.
Maybe when the info got somewhat complete and reliable (e.g. sufficient number of confirmations), somebody who is on the wiki maintainers' email whitelist could try to contact them?

JAW said:
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?
Click to expand...
Good to learn about this! 👍
This phenomenon seems applies to ATI/AMD too. Their tearing is just unbearable for me. It gets much better with TearFree.
For the sake of good UX (user experience), I think for Intel and ATI/AMD GPUs it may be best to have them always configured with their respective driver installed and TearFree enabled (via small files in /etc/X11/conf.d).

Mjölnir said:
... for watching a video, hardware acceleration does make a significant, noticeable difference.
Click to expand...
Thus should imho be enabled when hardware/FreeBSD version combination permits.
We don't want interested newcomers give the impression that they cannot even watch YT with FreeBSD, when they can with other OSes, right?
Do you know a good page telling about how to enable/configure HW acceleration?

Mjölnir said:
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.
Click to expand...
Aww yes, I didn't even think of Glamor, until JAW and you pointed at it!
This should be enabled by default when possible, right?

The only thing I don't know... can enabling TearFree and/or Glamor cause problems/instabilities in particular configurations?
Do you know?
 
Alexander88207 said:
/boot/kernel/i915kms.ko from the base system have or had^^ to be loaded.
Click to expand...
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?

Edit:
Given the fact that possibly the merge of the later Intel drivers into the original "old" x11-drivers/xf86-video-intel driver and the continued development could have been resulted in adding KMS support for the Gen. 1-3 GPUs, the info in k.jacker 's thread is possibly no longer correct.
So I guess this should be tested and verified again, and the "No KMS" tags replaced with question marks.

Maybe we are lucky, and somebody volunteers to check, whether KMS and Xorg meanwhile has been implemented and works for these legacy GPUs, and drm-kmod somehow behaves well, too?
 
Snurg said:
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?
Click to expand...
Alexander88207 said:
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...
Click to expand...

I guess they didn't notice that they had a non-accelerated desktop running.
 
  • X11 acceleration: The default UXA or the newer SNA once it has matured, is preferable to glamor, because the latter is 2D-only. Of course, for "office desktop" use case, 3D does not matter, but nowadays "consumer desktop" means a multimedia-capable system with some 3D added.
  • If you intend to contribute to the Wiki more often, then just ask for an account. Else I can put in your findings as one of my 1st actions on the wiki.
I guess you already have my system in your DB?
pciconf -lv | fgrep -A1 -B3 display
Code: 
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
Code: 
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
Despite 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.
 
oops said:
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.
Click to expand...
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.
I have to admit that I did only cursorily look at the code, and my tummy feeling told me that it would be definitely worth testing user and kernel mode.

User mode did seem to work when Trihexagonal (see posts #11 and #13) and SirDice tested/verified it, see his report and logs in post #29.
And I have to admit I am glad that it seems to work, at least in some verified configurations!

This way people probably can use even the most new GPUs as soon as Intel releases the driver, long before the Linux upstream drm update finally can trickle through into a release FreeBSD version.
So no more frustration "cannot use that new GPU with FreeBSD" :)

Mjölnir said:
...I can put .. our findings ... on the wiki.
Click to expand...

This is a great forums community collaboration effort, collecting information and knowledge for the larger FreeBSD community!
Personally, I'd appreciate very much if you could take care of making that available on the wiki!

Mjölnir said:
I guess you already have my system in your DB?
Click to expand...
For Intel, I am still not sure what needs to go into the "DB".
The output of the Intel PCI ID lookup table generator script for now looks like this, and is populated according to the matrix table we are working on.

Code: 
   '1616' ==> [ 'BDW',       '?',     '8.0',    '12.2?',  'Yes',    'Yes',    'Yes',    '2015?',    'Broadwell GT2 ULT [ULT_GT2]' ],
Second field CPU generation, not really necessary. But I like when installers tell me technical details.
Fourth field minimum FreeBSD version, can go away as well. Last field, some more info to tell the user.

Not sure yet whether more flags are needed.
For example maybe if particular series or generations don't take well TearFree, or other possibly essential options.
This then would have to be taken care of.

I don't really know about these options you listed below, but have read that some of them can cause problems, preventing boot or starting X. So these must be handled with caution.

Mjölnir said:
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
Click to expand...

The actual interactive installation and configuration stuff I want to do with a browser via CGI, as soon as the "xorginstaller tool" has prepared the system ready to fire up X and browser with the postinstaller greeting page. There I think all details like these should be configured.

But right now, I focus on the xorginstaller part, which has also good use cases standalone or as module for other postinstallers.
So it should probably start with conservative settings that are unlikely to fail.
 
I don't know if this will help you in what you're looking for but this is from my T400 with Radeon driver in use :

Code: 
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".
 
Alexander88207 said:
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?
Click to expand...
Umm... something "i3"... and "HD Graphics"... does this help? 🤦‍♂️

Zirias said:
So you only need such a script if you don't know ... ;)
Click to expand...

He is right, isn't he? :)

Alexander88207 said:
That way you can split up a lot of things. Example: .if ${INTELGEN} >= i10 then .....use 13+ or something like that.
Click to expand...
Personally, I prefer to avoid hard-coding as much as possible.
Imagine the nightmares when new versions come out and you have to untangle and rewire hardcoded spaghetti 🤢
 
Thank you all again for your help! :)

I updated the text of the first post as well as the table.

There are still quite some uncertainties especially with the chipsets that are around 2018 (the time when Linux 4.16 came out) and around somewhere 2020 (Linux 5.4).
For these entries, marked with "Need confirmation", it would be awesome if people who run these combinations could post and confirm that they either work or not.

For 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.
Personally I have only an old PC with i810 in the closet, and it needs some work (HDD replace etc) before I can test the first GPU generation whether drm-kmod support works on it.
Thus data about Gen. 2 to Gen. 5 GPUs would be particularly appreciated!

Mjölnir I consider your last post as trolling, so I just ignore it.
Can you please tell me what formatting markup you need for the Wiki?
 
Minbari said:
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.
Click to expand...
I have not yet managed to find a list of supported cards or PCI IDs for Linux 4.16s' DRM.

Sevendogsbsd said:
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.
Click to expand...
Kaby Lake is Gen. 9.5.
This makes me doubt that FreeBSD only supports up to Gen. 8.
Also considering that Gen. 8 stuff was released in the 2014-16 years, and Linux 4.16 is from 2018, makes me doubt that it is true what I often have read about FreeBSD 12 only supporting up to Gen. 8.

So I really would appreciate if there would be some more confirmations that Kaby Lake works on 12.x, or even an accurate list what's supported.
Of particular interest also would be confirmations for Comet Lake (Gen. 10, released 2018). Because of the release date, it could also be already supported in Linux 4.16 and FreeBSD 12.x.
 
Snurg said:
For 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.
Click to expand...
I'd love to help with that
Code: 
CPU: Intel(R) Core(TM) i3 CPU         550  @ 3.20GHz (3197.79-MHz K8-class CPU)
Unfortunately the mainboard manufacturer (Gigabyte) did not feel the necessity to include a graphics port of some kind on that mainboard 😳
 
The FreeBSD drm-kmod are numbered after the linux kernel (eg. graphics/drm-fbsd12.0-kmod port has version 4.16 just like the linux kernel from which the code was imported; graphics/drm-fbsd13-kmod version is 5.4, etc.). To find that list you need to search the linux-firmware. Also graphics/drm-fbsd13-kmod is working fine on Ivy Bridge.

Code: 
[ ~ ]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
 
Module graphics/drm-kmod need to be built from ports tree and not in package repository to avoid confusions. This is working fine for Ivy Bridge and AMD's BRAT SUMO. Some how it is loadable and working for Intel PINEVIEW of 2010. Also it is now good for Whisky Lake ( not r/12.2).
Code: 
# 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
 
FYI & TWIMC: after contacting Snurg he told me that some topics are still open for further investigation & should be fixed/cleared clarified before commiting into the wiki.
 
mickey said:
I'd love to help with that
Code: 
CPU: Intel(R) Core(TM) i3 CPU         550  @ 3.20GHz (3197.79-MHz K8-class CPU)
Unfortunately the mainboard manufacturer (Gigabyte) did not feel the necessity to include a graphics port of some kind on that mainboard 😳
Click to expand...
Did they donate that board to you? No? Then the mickey "did not feel the necessity to" check that before buying that MB?
 
SirDice said:
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.
Click to expand...
wasn't there some xperf command? It's been 25 years since I used it, so might be gone or my memory is bad.
 
It would need to be something that opens a bunch of X windows with some content, maybe move them around and resize them. I think that would give a good representation of some simple desktop usage. Performance measurements on video-playback might be good too. But I'm not sure if any of these drivers can use any hardware decoding, would still get some interesting results, even if it's all done in software.

Oddly enough, a quick search on "Xperf" shows a bunch of Microsoft documents. Hmmm.
 
Mjölnir said:
Did they donate that board to you? No? Then the mickey "did not feel the necessity to" check that before buying that MB?
Click to expand...
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.
 
Sorry tl;dr.

Some 2D test application for verifying the graphics functionality and stability would be indeed nice.
It is hard enough to judge the reports how credible they are, and inhowfar one can say "is working".
For example, there is now a confirmation that Kaby Lake (GPU Gen. 9.5) "works" with FreeBSD 12.2 using the /boot/modules driver.
However the issues the guy reported look like that it is "working", but possibly not very well. But the issue could also be due to other factors.
In general, we could need more user reports to make reasonably safe conclusions.
So it might be a good idea to publish the matrix in the Wiki, even if some question marks still are open.
Many people don't even notice when they are running the vesa driver, and so good proof is necessary.
For example the reports from SirDice and from Minbari are first-class proofs, as they show that they are actually running KMS and the card driver (xorg log or glxinfo/inxi output). If this information is missing, the report is of far reduced proof value.

So I am not sure yet how to best describe how to make a report which provides good proof that stuff is working (eg. FreeBSD version, hardware details, either xorg log or inxi/glxinfo data), but does not demand too much work from the users reporting.
Any suggestions?

gnath 's report lacks this info, but he is well known here.
And so I guess one can assume that GPU Gen. 4 could be categorized as "works fine, but need more reports".
Many thanks for the report, gnath 👍
Another thing I am not sure yet how to deal with is the driver mashup in FreeBSD 12.
The saying is that the drivers in /boot/kernel are older, and so don't work for more recent GPUs.
But if my impression is correct, possibly some people with sufficiently old hardware use these. Sounds plausible, as there are indications that these could be from Linux 4.1 or 4.6. I will check out that soon with a T420 with Intel graphics.
If this works indeed, I could imagine it could be useful to split the FreeBSD 12 compatibility row into two rows, one for /boot/kernel and one for /boot/modules drivers.
Such might have the advantage of saving a lot of users the need for building the drivers themselves.
I will have time tomorrow or over-tomorrow to rework and update the table and the intro.
So I'd be grateful to know what you think, and for all suggestions.
 
You must log in or register to reply here.
Back
Top