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



## Snurg (Mar 15, 2021)

*[Table below last updated Apr.1. Updated table according to recent compatibility reports. Added market names. Cut down text to keep post <25k chars.]*

Explanation of entries:

*Yes*: Known to work.
*Yes? Need confirmation*: Probably works, but not sure (forum posts exist that sound like GPU works on particular version, but not detailed whether with or without drm-kmod
*No: Known not to work (but still high probabilty it will work with user mode switching, eg without i915kms.ko and drm-kmod)*
drmXX = drm-kmod of FreeBSD XX
drmXXd = drm-devel-kmod (avoid if possible)



GPU GenCodeNameMarket namesdrm12drm13drm13ddrm14IntroCPU GenSources12.0TGLTiger LakeIris·Xe·Graphics*No**No**Yes**Yes*2020120,311.0JSLJasper Lake*No**Yes? Need confirmation**Yes**Yes*2020?113,4011.0ICLIce LakeIris·Plus·Graphics·655, Iris·Plus·Graphics*No**Yes? Need confirmation**Yes**Yes*2019100,37,411.0EHLElkhart Lake*No**Yes? Need confirmation**Yes**Yes*2020?1139,910.0CNLCannon Lake*Yes? Need confirmation**Yes**Yes**Yes*2018?821,359.5WHLWhiskey Lake*Yes**Yes**Yes**Yes*201881,32,4,459.5KBLKaby LakeHD·Graphics·610, HD·Graphics·615, HD·Graphics·620, UHD·Graphics·620, HD·Graphics·630, HD·Graphics·P630, Iris·Plus·Graphics·640, Iris·Plus·Graphics·650,*Yes**Yes**Yes**Yes*2017?25,4,9,a9.5GLKGemini Lake (Goldmont Plus, Gemini Lake Refresh)UHD·Graphics·600, UHD·Graphics·605*Yes? Need confirmation**Yes**Yes**Yes*2017?349.5CMLComet Lake*Yes? Need confirmation**Yes**Yes**Yes*2020?101,31,49.5CFLCoffee LakeUHD·Graphics·610, UHD·Graphics·630, Iris·Plus·Graphics·645, Iris·Plus·Graphics·655*Yes**Yes**Yes**Yes*2018821,33,4,459.5AMLAmber Lake Y*Yes? Need confirmation**Yes**Yes**Yes*2019101,36,449.0SKLSkylakeHD·Graphics·510, HD·Graphics·515, HD·Graphics·520, HD·Graphics·530, HD·Graphics·P530, Iris·Graphics·540, Iris·Graphics·550, Iris·Pro·Graphics·P555, Iris·Pro·Graphics·580, Iris·Pro·Graphics·P580*Yes**Yes**Yes**Yes*2015?21,30,9,a9.0BXTBroxton (Goldmont Apollo Lake)HD·Graphics·500, HD·Graphics·505*Yes**Yes**Yes**Yes*2016?428.0CHVCherry Trail (Braswell, Cherry View)HD·Graphics, HD·Graphics·400, HD·Graphics·405*Yes**Yes**Yes**Yes*2015/16?438.0BDWBroadwellHD·Graphics, HD·Graphics·5300, HD·Graphics·5500, HD·Graphics·5600, HD·Graphics·P5700, , HD·Graphics·6000, Iris·Graphics·6100, Iris·Pro·Graphics·6200, Iris·Pro·Graphics·P6300*Yes**Yes**Yes**Yes*2014/15?21,28,6,97.5HSWHaswellHD·Graphics, HD·Graphics·4200, HD·Graphics·4400, HD·Graphics·4600, HD·Graphics·P4600, HD·Graphics·P4700, HD·Graphics·5000, Iris·Graphics·5100*Yes**Yes**Yes**Yes*2013421,5,9,a7.5CRWCrystal WellHD·Graphics, HD·Graphics·4600, Iris·Pro·Graphics·5200*Yes**Yes**Yes**Yes*2013IGP20,27,b7.0VLVBay Trail (Valleyview)HD·Graphics*Yes**Yes**Yes**Yes*2013SOC19,24,9,b7.0IVBIvy BridgeHD·Graphics, HD·Graphics·2500, HD·Graphics·4000, HD·Graphics·P4000*Yes**Yes**Yes**Yes*2012321,26,7,9,a6.0SNBSandy BridgeHD·Graphics, HD·Graphics·2000, HD·Graphics·3000, HD·Graphics·P3000*Yes**Yes**Yes**Yes*2011221,8,9,a5IRONLAKEIronlakeHD·Graphics*Yes?**Yes?**Yes?**Yes?*2010118,2,94.5GM45CantigaGMA·4500MHD*Yes?**Yes?**Yes?**Yes?*2008GMCH14,15,21,9,a4.5G45EaglelakeGMA·X4500HD*Yes?**Yes?**Yes?**Yes?*2008GMA15,16,21,9,a4I965GMCrestlineGMA·X3100*Yes?**Yes?**Yes?**Yes?*2007ICH12,94I965GBroadwater Bearlake LakeportGMA·3000*Yes?**Yes?**Yes?**Yes?*2006ICH12,93PINEVIEWPineviewGMA·3150*Yes?**Yes?**Yes?**Yes?*2010GMA17,9,c3I945GMCalistogaGMA·950*Yes?**Yes?**Yes?**Yes?*2006ICH12,9,c3I945GLakeportGMA·950*Yes?**Yes?**Yes?**Yes?*2005ICH12,9,c3I915GMAlvisoGMA·900*Yes?**Yes?**Yes?**Yes?*2005ICH12,9,c3I915GGrantsdaleGMA·900*Yes?**Yes?**Yes?**Yes?*2004ICH12,9,c3G33BearlakeGMA·3100*Yes?**Yes?**Yes?**Yes?*2007GMCH13,9,c2I865GSpringdaleExtreme·Graphics·2*Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation*2003ICH12,9,c2I85XMontaraExtreme·Graphics·2*Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation*2003ICH12,9,c2I845GBrookdaleExtreme·Graphics*Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation*2002ICH12,22,9,c2I830AlmadorExtreme·Graphics*Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation**Yes? Need confirmation*2001ICH12,22,9,c1I815Solanoi754*No**No**No**No*2000ICH12,22,46,9,c1I810Whitneyi752*No**No**No**No*1999ICH12,22,46,9,c



*Notes:*

All entries which contain a question mark have no confirmation source in the "Sources" row yet, and thus might be incorrect.
The chronological order is only roughly exact. The items are ordered only by GPU generation, but not ordered inside-generation.
The "Code" row shows the code string parts from which you can recognize and associate the #defined constants and macros used in the freedesktop.org xf86-video-intel sources.
For GPU generations 4-6 to work on 12.2, according to this thread, it seems necessary to first deinstall graphics/drm-kmod, then explicitly install graphics/drm-fbsd12.0-kmod (needs still to be verified whether this is really necessary when doing fresh install).

*The source links below are not listed above, as they affect all:*
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units
https://wiki.freebsd.org/MarkLinimon/WorkAreaGraphics/DRM
https://wiki.freebsd.org/MarkLinimon/WorkAreaGraphics/AMD
https://wiki.freebsd.org/Graphics

*Big thanks to all people who contributed by confirming particular GPU/OS combinations' working or not working!*


----------



## Alexander88207 (Mar 15, 2021)

Someone once did something similar or the same:









						How to use the "old" or the "new" i915kms driver for Intel integrated graphics with Xorg..
					

This is a short as possible overview over the "old" and the "new" kms video drivers for Intel integrated graphics and the how and when they should be used.  I wrote this as an attempt to clear up confusion and hopefully reduce the amount of threads with the same questions about that topic on the...




					forums.freebsd.org


----------



## Snurg (Mar 16, 2021)

Thank you very much for this great link, Alexander88207 !
Some really interesting info there. 

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.


----------



## JAW (Mar 16, 2021)

Would it be useful to also add the year of introduction for each GPU, to assist with determining which gen a particular machine may have? My current laptop is a 2015 model (Broadwell based) and going strong, i'm quite suprised there is already talk of dropping Haswell, which is only one GPU gen before this one!


----------



## Snurg (Mar 16, 2021)

JAW said:


> Would it be useful to also add the year of introduction for each GPU, to assist with determining which gen a particular machine may have? My current laptop is a 2015 model (Broadwell based) and going strong, i'm quite suprised there is already talk of dropping Haswell, which is only one GPU gen before this one!



Great idea!
I'll update the table in post #1 today or tomorrow to include the introduction year of each GPU.
I am also considering to add another row, which displays the respective CPU generation, as it is important not to confuse *C*PU and *G*PU generations.
This might make things even easier, as the *C*PU generation is easy to determine:
1. CPU gen: i?-XXX
2.-9. CPU gen: i?-*X*XXX
10.+ CPU gen: i?-*XX*XX

Btw, the autodetecting/autoconfiguring postinstaller I am working on will tell the user the exact GPU information, including its generation.
I initially assumed that this would not be necessary. But I recently learned that I need to add functionality that tells the user which FreeBSD version can be used, if hs FreeBSD version does either _not yet_ or _no longer_ support a particular GPU. (=> the actual reason for this thread)

*Learning of the plan to drop support for most to all Intel-GPU-based laptops and desktops that are older than circa 7 years was a hefty surprise to me, too.*
Sadly I have not yet managed to find any text about the reasons.
I really would appreciate to learn why that is deemed necessary.


----------



## bsduck (Mar 16, 2021)

I am surprised. My laptop has an Ivy Bridge (3rd gen.) chip, which is older than Haswell (4th gen.) and should not work with i915kms, according to what I read here. However I do use it daily with that driver on 12.2 and it works well.

Should I expect it not to work anymore with 13.0?

Since graphics/drm-legacy-kmod has been deprecated, this would mean I will have to choose between sticking with 12.2 until its end of support (but what then?) or accept a massive loss of video performance and use 13.0 without a DRM driver. Quite annoying.


----------



## Phishfry (Mar 16, 2021)

Snurg said:


> Learning of the plan to drop support for most to all Intel-GPU-based laptops and desktops that are older than circa 7 years was a hefty surprise to me, too.


Could you show any documents about this.
This is the first I am hearing of it. I use SandyBridge and IvyBridge laptops with i915kms from base (11.4)


----------



## Snurg (Mar 16, 2021)

https://freebsddesktop.github.io/2018/12/08/drm-kmod-primer.html :



> So what do you need?
> 
> A system with *Haswell or newer* Intel HD Graphics (see here for a list) or a system with AMD Radeon HD7000 AMD GPU or newer (see here for a list).
> [...]
> ...



I already have been accused of spreading misinformation.
Please let me again emphasize that, for the autodetect/autoconfiguration script, I *need data as correct and exact as possible*.

I have found several similar references to the removal of support for hardware older than Haswell, for example in notes on Freshports.org.
Now I heavily regret not having bookmarked these pages when I was sifting through countless pages to collect information for the compatibility matrix table.

This drm-legacy-kmod module has been removed very recently.
Sadly I have not yet found any information whether possibly (and hopefully) the plan to drop support for legacy GPU hardware might have been abandoned, leading to dropping drm-legacy-kmod.

What now particularly worries me is that from what I read, apparently some xf86-video-something drivers do no longer work in user mode, only in KMS mode. If KMS support for this hardware is dropped, this potentially could mean that the affected hardware can no longer be used with FreeBSD

As a Nvidia user, personally do not care much about Intel or AMD support. I can also use my Thinkpad with Linux if necessary.
*My main interest to get these questions clarified is to make sure that the postinstaller does the correct installation, and if some hardware is not supported, also detects this and informs the user accordingly.*


----------



## Minbari (Mar 16, 2021)

Don't panic FreeBSD 12 branch has support till 2024. By that time your hardware will really be obsolete.


----------



## Snurg (Mar 16, 2021)

I have updated the table, added introduction years and CPU generation.

Please guys, please understand that this thread is *not* about worries of obsolete hardware.

*The thread is about collecting exact information which GPUs work with which FreeBSD versions' drm-kmod.*
I need this information for correct autodetection and autoconfiguration.
So that the user can install and run Xorg easily without having to deal with the installation and the configuration.

*Currently I am particularly looking for:*

Confirmations that pre-Haswell GPU hardware runs or does not run on FreeBSD 13, and whether it still works using the xf86-video-intel driver, without KMS and drm-kmod, if it is no longer supported by KMS
Any information that helps understand what is being planned regarding dropping support for older hardware
Any information that can tell which GPU generations (or sub-generations JSL, ICL, EHL of gen 11) are supported by 13-RELEASE, and which not yet. For example, I read somewhere that GPU generation 12 allegedly is only usable with graphics/drm-devel-kmod.


----------



## Deleted member 30996 (Mar 17, 2021)

This is what ThinkWiki says I have on mine:

The T43 comes with:
Intel Graphics Media Accelerator X3100 (Intel 965)

The X61 comes in two versions:
Intel 915GM northbridge with integrated Intel Graphics Media Accelerator 900 (not capable of DVI output) using shared system RAM

Intel 915PM northbridge and an ATI Mobility Radeon X300 with 64MB on-chip dedicated RAM. Supports DVI output through a dock or port replicator

The T61 comes with
Intel Graphics Media Accelerator X3100


----------



## Snurg (Mar 17, 2021)

Trihexagonal Great! 

On which FreeBSD versions do the Thinkpads run?
Do they work with i915kms.ko, drm-kmod and xf86-video-intel, or with userspace mode setting, with xf86-video-intel only?
Do they run the "intel" driver, or something else like scfb or fb?

Knowing this would be very helpful!


----------



## Deleted member 30996 (Mar 17, 2021)

I initially install the drivers from the list provided during the build of Xorg. I was trying to think if I istallled the Intel and ATI driver separately for my T43 but figrured they would all be included in the MetaPort pkg so proably not. I know I did install them separately when building OpenBSD and for Switchable Graphics on my GateWay.

All have just been updated to 12.2-RELEASE. p4 except my W520 running 12.i- RELEASE. p3.

My Sony Vaio is running i386 FreeBSD- 11.2-RELEASE. p3 and has an Intel 82945GM (945GM GMCH) SVGA controller.

They all use the Intel driver but will default to scfb if that's not working.

I've never installed i915kms.ko.


----------



## Snurg (Mar 17, 2021)

bsduck said:


> I am surprised. My laptop has an Ivy Bridge (3rd gen.) chip, which is older than Haswell (4th gen.) and should not work with i915kms, according to what I read here. However I do use it daily with that driver on 12.2 and it works well.


Confusing *C*PU and *G*PU generations is easy.
I also had to learn to avoid this trap. Regarding the drm-kmod support, only the *G*PU generation matters.
The table update to include both GPU and CPU generations, might help avoid this kind of confusion.

Haswell has GPU generation 7.5, IvyBridge has probably a bit less.
So your computer is a very interesting "border line" case!
Could you possibly look into the xorg log and check which driver does the actual work, to make sure it is "intel" and not "scfb", "vesa", or the like?



bsduck said:


> Should I expect it not to work anymore with 13.0?
> 
> Since graphics/drm-legacy-kmod has been deprecated, this would mean I will have to choose between sticking with 12.2 until its end of support (but what then?) or accept a massive loss of video performance and use 13.0 without a DRM driver. Quite annoying.


I honestly do not know, but I am curious... 
The information about the deletion of graphics/drm-legacy-kmod does not give detail, it just says



> Legacy DRM driver that used to be in FreeBSD base before the removal in FreeBSD 13. (...) The drm-legacy-kmod port can be enabled for older Intel and ATI/AMD graphics adapters as well as legacy graphics adapters through kld_list in /etc/rc.conf.


I honestly do not understand, how can that legacy port be enabled by `kld_list` if it is gone?

Maybe it just means exactly what you said: that the "scfb" or "fb", or even "vesa" drivers will take over?
On fast computers many people tend to not notice such anymore, but on older computers the performance difference is very obvious indeed...

Maybe some guru can enlighten?


Edit:
I have updated the table to reflect the high probability that support for GPU generations below 6 has been dropped in FreeBSD 13.
Looking at the maintainer messages for graphics/drm-legacy-kmod, I am quite sure that this is final:


> drm-legacy-kmod is holding back changes in the FreeBSD VM subsystem, and it requires substantial changes to be updated to work with the VM changes. Remove[d] expired port



*My main focus now is to find out whether in FreeBSD 13 the GPUs Gen. 7 are still supported or not, as they are below Haswell (Gen. 7.5).*


----------



## Mjölnir (Mar 17, 2021)

Minbari said:


> Don't panic FreeBSD 12 branch has support till 2024. By that time your hardware will really be obsolete.


I _do care_ that I can use my then >15 year old previous laptop with FreeBSD.  It's a dual core 64-bit machine.  Why should I throw it in the trash bin while the hardware is still working fine?  That's yesterday's western living style with lots of cheap chinese use-once low-quality products.  Very oldschool & not contemporary.  Please follow the _"Off-Topic -> Environmentalist"_ thread.


----------



## Snurg (Mar 17, 2021)

Trying to understand the status of pre-Haswell GPUs (down to Sandy Bridge) on FreeBSD 12.2, I still feel confused.

Freshports says there is no graphics/drm-fbsd12.0-kmod package, and it needs to be built from ports.


> *To install the port:* cd /usr/ports/graphics/drm-fbsd12.0-kmod/ && make install clean
> *A package is not available for ports marked as: Forbidden / Broken / Ignore / Restricted*



However, I read


SirDice said:


> Note that graphics/drm-kmod is a meta-port/package. It has nothing of itself, it simply depends on, in this case, graphics/drm-fbsd12.0-kmod. Removing and reinstalling drm-kmod is a no-op. Force a reinstall of drm-fbsd12.0-kmod to make sure you're getting the rebuilt version; `pkg install -f drm-fbsd12.0-kmod`. From pkg(8)'s point of view, nothing has changed, so it's not going to (re)install it automatically.



I tried what SirDice suggested, and indeed, there a package got installed.

```
# pkg install -f drm-fbsd12.0-kmod
[...]
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        drm-fbsd12.0-kmod: 4.16.g20201016_1
        gpu-firmware-kmod: g20201213

Number of packages to be installed: 2

The process will require 56 MiB more space.
7 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching drm-fbsd12.0-kmod-4.16.g20201016_1.txz: 100%    2 MiB   2.1MB/s    00:01
[2/2] Fetching gpu-firmware-kmod-g20201213.txz: 100%    5 MiB   5.1MB/s    00:01
Checking integrity... done (0 conflicting)
[1/2] Installing gpu-firmware-kmod-g20201213...
[1/2] Extracting gpu-firmware-kmod-g20201213: 100%
[2/2] Installing drm-fbsd12.0-kmod-4.16.g20201016_1...
[2/2] Extracting drm-fbsd12.0-kmod-4.16.g20201016_1: 100%
=====
Message from drm-fbsd12.0-kmod-4.16.g20201016_1:
--
The drm-fbsd12.0-kmod port can be enabled for [...] i915kms (for Intel APUs starting with
HD3000 / Sandy Bridge) through kld_list in /etc/rc.conf.
```
So it looks like that the metapackage does some magic and installs graphics/drm-fbsd12.0-kmod as a package!
No need to build it! 

*Will that work until 12.2 EOLs in 2024?*



olli@ said:


> It is _wrong_ that pre-Haswell graphics will stop working [in KMS mode on FreeBSD 13+].


If I understand you correctly, they still work, respective can be used in KMS mode with the VESA driver (assuming that Intel graphics BIOS in general supports VESA?)?

Does x11-drivers/xf86-video-vesa have to be installed then?
Or are there faster drivers available that do not depend on UEFI like x11-drivers-scfb?

Or might it even on FreeBSD 13 still be possible to just ditch KMS and drm-kmod, and use x11-drivers/xf86-video-intel with traditional user space modesetting?[/B]


olli@ said:


> If you have graphics hardware that is even more ancient (like ~20 years old), then you can probably use one of the xf86-video-* drivers. Note that OpenGL acceleration for old GPUs was already dropped about 8 years ago.


From what Trihexagonal reported, it looks like that it is still possible to use x11-drivers/xf86-video-intel _without_ also loading i915kms.ko and graphics/drm-whatever-kmod?
If 2D acceleration with userspace mode switching can be used, most end users would just be happy!

Can it be confirmed that it is generally possible to use x11-drivers/xf86-video-intel in userspace mode?

Thank you all again for your patience and your invaluable help!


----------



## SirDice (Mar 17, 2021)

Snurg said:


> Will that work until 12.2 EOLs in 2024?


12.2 will be EoL three months after the release of 12.3. Which I expect to get released sometime in September or October 2021. Then in September/October 2022 we'll probably also see a 12.4 appear. The expected EoL date of 2024 is for the entire 12 branch.


----------



## olli@ (Mar 17, 2021)

Snurg said:


> Can it be confirmed that it is generally possible to use x11-drivers/xf86-video-intel in userspace mode?


I can’t test that myself because I don’t have hardware from the previous century. But I’m pretty sure that all of the legacy xf86-video-* ports should still work, otherwise they would have been removed long ago (or at least marked as deprecated, which is not the case). 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.

As I wrote elsewhere, the current drm-kmod port supports Intel GPUs at least back to Sandy Bridge, which predates Haswell and Ivy Bridge. Older GPUs like Nehalem _might_ be supported, but there may be bugs because most of  the developers don’t have such old hardware themselves, so they cannot test it.

By the way, switching to Linux won’t make things better because they have the same driver situation.


----------



## SirDice (Mar 17, 2021)

I have a Zotac ID 70 plus, which has an Intel Core i3-2100T (that's a Sandy Bridge according to wikipedia; HD Graphics 2000 ). It's currently running 13.0-RC2 but I had 12.2 on it before. It's running on x11-drivers/xf86-video-intel. That works fine. I do also have drm-fbsd13-kmod installed (previously that was drm-fbsd12.0-kmod). With the Intel driver everything works, this machine is hooked up to my TV. I'll see if I can try it without the Intel driver tonight.


----------



## Snurg (Mar 17, 2021)

olli@ said:


> I can’t test that myself because I don’t have hardware from the previous century. But I’m pretty sure that all of the legacy xf86-video-* ports should still work, otherwise they would have been removed long ago (or at least marked as deprecated, which is not the case). 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.


The x11-drivers/xf86-video-intel for long time did indeed contain only legacy drivers (for GPU generation 1+2).

I originally missed out that, I think three or four years ago, there was a big driver merge at freedesktop.
Possibly initiated by Intel, as they seem to develop the actual drivers.
This eliminated the need for the xf86-video-i915 driver (or something else, I forgot).
To me this sounds completely plausible, as most people would intuitively choose an "-intel" instead of some cryptic "-i915" driver.

So the current driver sources are a strange mix of historic, less-historic and top modern code.
When you look at https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/blob/master/src/i915_pciids.h you can see that the driver not only supports last centuries' chips, but even the 12th GPU generation (Tiger Lake)!

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.
_If this turns out to be possible, then one could use even the most top modern Intel chips on 12.2, no matter the drm-kmod version!_



olli@ said:


> As I wrote elsewhere, the current drm-kmod port supports Intel GPUs at least back to Sandy Bridge, which predates Haswell and Ivy Bridge.


You make me think about adding an "experimentator feature" in the postinstaller, so people could actually test this and report back how far backward the particular drm-kmod versions actually work, so community knowledge could be gained.
If it could easily be reconfigured to non-KMS, if that turns out to not work on the particular computer, that at least won't result in bad UX!



SirDice said:


> I have a Zotac ID 70 plus, which has an Intel Core i3-2100T (that's a Sandy Bridge according to wikipedia; HD Graphics 2000 ). It's currently running 13.0-RC2 but I had 12.2 on it before. It's running on x11-drivers/xf86-video-intel. That works fine. I do also have drm-fbsd13-kmod installed (previously that was drm-fbsd12.0-kmod). With the Intel driver everything works, this machine is hooked up to my TV. I'll see if I can try it without the Intel driver tonight.


That would be awesome!
If it turns out that older GPUs really still work with FreeBSD 13, that would be just wonderful!  
Even without any "official warranty" or support!


----------



## olli@ (Mar 17, 2021)

Note that, without drm-kmod, you won’t get OpenGL or VAAPI acceleration, AFAIK.


----------



## zirias@ (Mar 17, 2021)

Yes. Well, you can have OpenGL, but implemented entirely in software, so IOW, pretty useless.


----------



## SirDice (Mar 17, 2021)

So, some tests done. All of them on the same Zotac ID 70 plus. It does UEFI boot, not entirely sure if that matters. All of the tests were done on 13.0-RC2. 

Only graphics/drm-fbsd13-kmod installed: Works, driver is auto-detected no need for a xorg.conf; https://termbin.com/k1cw
Only x11-drivers/xf86-video-intel installed: Works, driver is auto-detected; https://termbin.com/abz4
Both installed: Works, without a config the intel(4) driver is picked; https://termbin.com/x6jj

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.


----------



## Snurg (Mar 17, 2021)

This is just wonderful news, SirDice! 

I just reworked the matrix table to show official and inofficial support for 12, 13 and 13-drm-devel-kmod.
(Done) Will update it again, so your confirmation can be referred as proof! (might take until tomorrow morning, as I am not so satisfied with the new layout yet)

olli@ and Zirias
OpenGL and VA-API are nice extras, but not really necessary.

Many users don't even notice that they are using the vesa driver.
So I believe it is more benefit in a script that just detects the GPU hardware, chooses the correct driver, installs it and configures the system as optimally as hardware/OS combo permits, so one can go start X afterwards, without hassle.


----------



## zirias@ (Mar 17, 2021)

Snurg said:


> So I believe it is more benefit in a script that just detects the GPU hardware, chooses the correct driver, installs it and configures the system as optimally as hardware/OS combo permits, so one can go start X afterwards, without hassle.


Well, except when there's "hassle" of course:








						Some personal FreeBSD advocacy
					

Guess it was time to write my 2¢ as well, so here it is: http://sekrit.de/webdocs/freebsd/advocacy.html Ironically currently hosted on a Linux machine ;)




					forums.freebsd.org
				




I'm pretty sceptical about such scripts. If you know what you do, installing graphics/drm-kmod and loading the correct driver really isn't much work, done in a minute. So you only _need_ such a script if you _don't_ know what you do. But then, running into any problem, you're really stuck.

Still I have no doubt some people would find it useful. Just saying…


----------



## Snurg (Mar 17, 2021)

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


----------



## JAW (Mar 17, 2021)

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



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.



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?


----------



## Mjölnir (Mar 17, 2021)

SirDice said:


> I've not looked if there's a performance difference between the drivers.


IMHO for average "office desktop" usage, even basic software-only acceleration is fully sufficient.


SirDice said:


> That might be interesting to look at,


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.


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
	
	



```
Section "Module"
    load "glamoregl"
EndSection
Section "Device"
    ...
    Option     "AccelMethod"   "glamor"
    ...
```
claims to provide reasonable, decent 2D acceleration for any hardware.


----------



## Alexander88207 (Mar 17, 2021)

Snurg said:


> 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.



/boot/kernel/i915kms.ko from the base system have or had^^ to be loaded.


----------



## Snurg (Mar 17, 2021)

JAW said:


> ... the info being collated is incredibly useful, do you intend to add it to the FreeBSD Wiki?


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?


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.


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.


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?*


----------



## Snurg (Mar 17, 2021)

Alexander88207 said:


> /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?

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?


----------



## Alexander88207 (Mar 17, 2021)

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?





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...



I guess they didn't notice that they had a non-accelerated desktop running.


----------



## oops (Mar 18, 2021)

Snurg said:


> 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.


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.


----------



## Mjölnir (Mar 18, 2021)

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`

```
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
```
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.


----------



## Snurg (Mar 18, 2021)

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.


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.



*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?


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.


```
'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
> ...



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.


----------



## Deleted member 30996 (Mar 18, 2021)

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 :


```
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".
```


----------



## Snurg (Mar 18, 2021)

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?


Umm... something "i3"... and "HD Graphics"...  does this help?    



Zirias said:


> So you only _need_ such a script if you _don't_ know ...



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.


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


----------



## Mjölnir (Mar 18, 2021)

I'd like to kindly note that _"Testing is for cowards.  __Real programmers don't test their gushs__.  It was hard to write, it should be hard to use, right?  Let them noob users find your bugs, right?"_


----------



## Snurg (Mar 19, 2021)

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?


----------



## Snurg (Mar 19, 2021)

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.


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.


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.


----------



## mickey (Mar 20, 2021)

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.


I'd love to help with that

```
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


----------



## Minbari (Mar 20, 2021)

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.


```
[ ~ ]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
```


----------



## gnath (Mar 22, 2021)

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).

```
# 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
```


----------



## Mjölnir (Mar 29, 2021)

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.


----------



## Mjölnir (Mar 29, 2021)

mickey said:


> I'd love to help with that
> 
> ```
> CPU: Intel(R) Core(TM) i3 CPU         550  @ 3.20GHz (3197.79-MHz K8-class CPU)
> ...


Did they donate that board to you?  No? Then the mickey _"did not feel the necessity to"_ check that before buying that MB?


----------



## Crivens (Mar 29, 2021)

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.


wasn't there some xperf command? It's been 25 years since I used it, so might be gone or my memory is bad.


----------



## SirDice (Mar 29, 2021)

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.


----------



## Crivens (Mar 29, 2021)

X11PERF(1) manual page


----------



## mickey (Mar 29, 2021)

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?


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.


----------



## Snurg (Mar 29, 2021)

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.


----------



## Snurg (Apr 1, 2021)

Updated the table again.
The approach trying to collect information in the forums didn't really work out, as too few people use brand-new Intel stuff.

Better is probably letting the installer send the success/failure data of all combos marked with ? to a server, so the people using the installer can effortlessly help collecting good data, quantity- and quality-wise, if they want, while keeping traffic to a minimum.

Will send Mjölnir the table generator script, so he can use and optimize the thing for the Wiki. Thank you very much, Mjölnir!

And many thanks to all posters!
Your help was essential to prove these old statements wrong that drm-kmod soon will only work with Haswell and higher.


----------



## olli@ (Apr 6, 2021)

Snurg said:


> Many people don't even notice when they are running the vesa driver, and so good proof is necessary.


A quick test to see if you’re running with the VESA driver is using `glxgears` from the graphics/mesa-demos port.
A not-so-quick, but much more fun test is to play some games/crack-attack. Be sure to select highest resolution and graphics details in the settings.


----------



## mickey (Apr 6, 2021)

olli@ said:


> A quick test to see if you’re running with the VESA drive is using `glxgears` from the graphics/mesa-demos port.


The same port installs the `glxinfo` command, running `glxinfo -B` should give a good overview.


----------



## grahamperrin@ (Jun 28, 2021)

Edge case …


```
kld_list="drm"
```

– drm in lieu of i915kms, where i915kms is normally recommended.

<https://lists.freebsd.org/pipermail/freebsd-questions/2021-May/294001.html>


----------



## mr8ash (Jun 29, 2021)

hi....i am using a haswell i7 cpu.....2013 model....it comes with a Haswell-ULT Integrated Graphics Controller n a nvidia GF117M. my kld_list=i915kms. freebsd 12.2 works. i could run 3k video clips with mpv by installing libva-intel-driver n libva-intel-hybrid-driver running hardware rendering. without those 2 libva drivers, 3k runs on software rendering. the same thing also works on freebsd 13 RELEASE, but not on freebsd 13 STABLE. on 13 STABLE, I could not load i915kms module. i even tried installing xf86-video-intel but still didn't work. i tried both drivers from binary n ports...


----------



## Alexander88207 (Jun 29, 2021)

mr8ash said:


> hi....i am using a haswell i7 cpu.....2013 model....it comes with a Haswell-ULT Integrated Graphics Controller n a nvidia GF117M. my kld_list=i915kms. freebsd 12.2 works. i could run 3k video clips with mpv by installing libva-intel-driver n libva-intel-hybrid-driver running hardware rendering. without those 2 libva drivers, 3k runs on software rendering. the same thing also works on freebsd 13 RELEASE, but not on freebsd 13 STABLE. on 13 STABLE, I could not load i915kms module. i even tried installing xf86-video-intel but still didn't work. i tried both drivers from binary n ports...


Hello,

you need to build graphics/drm-kmod from ports if you are using 13 STABLE because there could be a kernel mismatch by using the official binary version because they are built for 13-RELEASE.

To cleanup drm-kmod correctly do

`pkg remove drm-kmod && pkg autoremove`.

If you move from packages to ports on this port.


----------



## mr8ash (Jun 30, 2021)

Alexander88207 said:


> Hello,
> 
> you need to build graphics/drm-kmod from ports if you are using 13 STABLE because there could be a kernel mismatch by using the official binary version because they are built for 13-RELEASE.
> 
> ...


i did those...... i tried both drivers from binary n ports...dint u read it


----------



## Alexander88207 (Jun 30, 2021)

mr8ash said:


> i did those...... i tried both drivers from binary n ports...dint u read it


Oh ok, then do you can provide a log of /var/log/messages after trying to load the kernel module?


----------



## mr8ash (Jun 30, 2021)

is this the one.....


Alexander88207 said:


> Oh ok, then do you can provide a log of /var/log/messages after trying to load the kernel module?




```
[504] drmn0: <drmn> on vgapci0
kernel: [504] vgapci0: child drmn0 requested pci_enable_io
kernel: [504] <5>[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
kernel: [504] Successfully added WC MTRR for [0xd0000000-0xdfffffff]: 0; 
kernel: [504] <6>[drm] Got stolen memory base 0xcda00000, size 0x2000000
kernel: [504] <6>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
kernel: [504] <6>[drm] Driver supports precise vblank timestamp query.
kernel: [504] <6>[drm] Connector eDP-1: get mode from tunables:
kernel: [504] <6>[drm]   - kern.vt.fb.modes.eDP-1
kernel: [504] <6>[drm]   - kern.vt.fb.default_mode
kernel: [504] <6>[drm] Connector HDMI-A-1: get mode from tunables:
kernel: [504] <6>[drm]   - kern.vt.fb.modes.HDMI-A-1
kernel: [504] <6>[drm]   - kern.vt.fb.default_mode
kernel: [504] <6>[drm] Connector DP-1: get mode from tunables:
kernel: [504] <6>[drm]   - kern.vt.fb.modes.DP-1
kernel: [504] <6>[drm]   - kern.vt.fb.default_mode
kernel: [504] <6>[drm] Connector HDMI-A-2: get mode from tunables:
kernel: [504] <6>[drm]   - kern.vt.fb.modes.HDMI-A-2
kernel: [504] <6>[drm]   - kern.vt.fb.default_mode
kernel: [504] sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
kernel: [504] <6>[drm] Initialized i915 1.6.0 20190822 for drmn0 on minor 0
kernel: [504] WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
kernel: [504] VT: Replacing driver "efifb" with new "fb".
kernel: [506] start FB_INFO:
kernel: [506] type=11 height=768 width=1366 depth=32
kernel: [506] cmsize=16 size=8294400
kernel: [506] pbase=0xd0419000 vbase=0xfffff800d0419000
kernel: [506] name=drmn0 flags=0x0 stride=7680 bpp=32
kernel: [506] cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
kernel: [506] end FB_INFO
kernel: [506] drmn0: fb0: i915drmfb frame buffer device
```


----------



## Alexander88207 (Jun 30, 2021)

This looks good for me.


----------



## Babinio74 (Sep 22, 2021)

According to the previous conversation among the members of the group does my current  installed version of freeBSD 13 (xfce4)

automatic detects the Intel HD Graphics 4400 GPU on my machine?

Im attaching the GPU details of my system

thank you

P.S im asking because my knowledge about hardware and freeBSD has confused me


----------



## SirDice (Sep 22, 2021)

Babinio74 said:


> According to the previous conversation among the members of the group does my current installed version of freeBSD 13 (xfce4) automatic detects the Intel HD Graphics 4400 GPU on my machine?


Just look at /var/log/Xorg.0.log and check it yourself.


----------



## Babinio74 (Sep 22, 2021)

SirDice said:


> Just look at /var/log/Xorg.0.log and check it yourself.


check exactly what?


----------



## Deleted member 30996 (Sep 22, 2021)

Babinio74 said:


> check exactly what?


This is how it looks for my Nvidia Quadro 1000M. You're looking for Intel or something related to a GPU:
/var/log/xorg.0.log

```
*snip*
[2266933.737] (II) LoadModule: "glx"
[2266933.788] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[2266934.160] (II) Module glx: vendor="NVIDIA Corporation"
[2266934.160]     compiled for 4.0.2, module version = 1.0.0
[2266934.160]     Module class: X.Org Server Extension
[2266934.161] (II) NVIDIA GLX Module  340.108  Wed Dec 11 14:27:50 PST 2019
[2266934.161] (II) LoadModule: "nvidia"
[2266934.161] (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so
[2266934.269] (II) Module nvidia: vendor="NVIDIA Corporation"
[2266934.269]     compiled for 4.0.2, module version = 1.0.0
[2266934.269]     Module class: X.Org Video Driver
[2266934.291] (II) NVIDIA dlloader X Driver  340.108  Wed Dec 11 14:09:07 PST 2019
[2266934.291] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[2266934.292] (--) Using syscons driver with X support (version 2.0)
[2266934.292] (--) using VT number 9

[2266934.388] (II) Loading sub module "fb"
[2266934.388] (II) LoadModule: "fb"
[2266934.388] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[2266934.428] (II) Module fb: vendor="X.Org Foundation"
[2266934.428]     compiled for 1.20.11, module version = 1.0.0
[2266934.428]     ABI class: X.Org ANSI C Emulation, version 0.4
[2266934.428] (WW) Unresolved symbol: fbGetGCPrivateKey
[2266934.428] (II) Loading sub module "wfb"
[2266934.428] (II) LoadModule: "wfb"
[2266934.491] (II) Loading /usr/local/lib/xorg/modules/libwfb.so
[2266934.521] (II) Module wfb: vendor="X.Org Foundation"
[2266934.521]     compiled for 1.20.11, module version = 1.0.0
[2266934.521]     ABI class: X.Org ANSI C Emulation, version 0.4
[2266934.521] (II) Loading sub module "ramdac"
[2266934.521] (II) LoadModule: "ramdac"
[2266934.522] (II) Module "ramdac" already built-in
[2266934.611] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[2266934.612] (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
[2266934.612] (==) NVIDIA(0): RGB weight 888
[2266934.612] (==) NVIDIA(0): Default visual is TrueColor
[2266934.612] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[2266934.639] (**) NVIDIA(0): Enabling 2D acceleration
[2266935.223] (II) NVIDIA(0): NVIDIA GPU Quadro 1000M (GF108GL) at PCI:1:0:0 (GPU-0)
[2266935.223] (--) NVIDIA(0): Memory: 2097152 kBytes
[2266935.223] (--) NVIDIA(0): VideoBIOS: 70.08.55.00.0c
[2266935.223] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[2266935.252] (--) NVIDIA(0): Valid display device(s) on Quadro 1000M at PCI:1:0:0
[2266935.252] (--) NVIDIA(0):     CRT-0
[2266935.252] (--) NVIDIA(0):     Lenovo Group Limited (DFP-0) (boot, connected)
[2266935.252] (--) NVIDIA(0):     DFP-1
[2266935.252] (--) NVIDIA(0):     DFP-2
[2266935.252] (--) NVIDIA(0):     DFP-3
[2266935.252] (--) NVIDIA(0):     DFP-4
[2266935.252] (--) NVIDIA(0):     DFP-5
[2266935.252] (--) NVIDIA(0):     DFP-6
[2266935.252] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[2266935.252] (--) NVIDIA(0): Lenovo Group Limited (DFP-0): Internal LVDS
[2266935.252] (--) NVIDIA(GPU-0): Lenovo Group Limited (DFP-0): 330.0 MHz maximum pixel clock
[2266935.252] (--) NVIDIA(0): DFP-1: Internal TMDS
[2266935.252] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock
[2266935.252] (--) NVIDIA(0): DFP-2: Internal TMDS
[2266935.252] (--) NVIDIA(GPU-0): DFP-2: 165.0 MHz maximum pixel clock
[2266935.252] (--) NVIDIA(0): DFP-3: Internal TMDS
[2266935.252] (--) NVIDIA(GPU-0): DFP-3: 165.0 MHz maximum pixel clock
[2266935.252] (--) NVIDIA(0): DFP-4: Internal DisplayPort
[2266935.252] (--) NVIDIA(GPU-0): DFP-4: 480.0 MHz maximum pixel clock
[2266935.252] (--) NVIDIA(0): DFP-5: Internal DisplayPort
[2266935.252] (--) NVIDIA(GPU-0): DFP-5: 480.0 MHz maximum pixel clock
[2266935.252] (--) NVIDIA(0): DFP-6: Internal DisplayPort
[2266935.252] (--) NVIDIA(GPU-0): DFP-6: 480.0 MHz maximum pixel clock
[2266935.252] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[2266935.252] (**) NVIDIA(0):     device Lenovo Group Limited (DFP-0) (Using EDID
[2266935.252] (**) NVIDIA(0):     frequencies has been enabled on all display devices.)
[2266935.252] (==) NVIDIA(0): 
[2266935.253] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select"
[2266935.253] (==) NVIDIA(0):     will be used as the requested mode.
[2266935.253] (==) NVIDIA(0): 
[2266935.253] (II) NVIDIA(0): Validated MetaModes:
[2266935.253] (II) NVIDIA(0):     "DFP-0:nvidia-auto-select"
[2266935.253] (II) NVIDIA(0): Virtual screen size determined to be 1600 x 900
[2266936.316] (--) NVIDIA(0): DPI set to (119, 120); computed from "UseEdidDpi" X config
[2266936.316] (--) NVIDIA(0):     option
[2266936.316] (II) NVIDIA: Reserving 3072.00 MB of virtual memory for indirect memory
[2266936.316] (II) NVIDIA:     access.
[2266936.324] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
[2266936.824] (==) NVIDIA(0): Disabling shared memory pixmaps
[2266936.824] (==) NVIDIA(0): Backing store enabled
[2266936.824] (==) NVIDIA(0): Silken mouse enabled
[2266936.851] (**) NVIDIA(0): DPMS enabled
[2266936.858] (II) Loading sub module "dri2"
[2266936.858] (II) LoadModule: "dri2"
[2266936.858] (II) Module "dri2" already built-in
[2266936.864] (II) NVIDIA(0): [DRI2] Setup complete
[2266936.864] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia
*snip*
```


----------



## Babinio74 (Sep 23, 2021)

Thanks mate


----------



## benat (Oct 10, 2022)

Hello everyone,

The i915 driver is reported to work on the table above, but it in my case with a fresh 13.1-RELEASE install, it doesn't. The driver isn't loaded as reported in bug report #245443, and vgapci is used instead.

Seeing the graphics/gpu-firmware-intel-kmod port and it's Makefile, it looks like flavor CometLake is missing, while earlier CoffeLake is still available. As far as I understand this wiki page, CometLake is supported by Linux 5.4 and should be available with FreeBSD 13. In bug report #245443 it was suggested to use drm-devel-kmod instead of drm-kmod with 13.0-CURRENT, but neither the port nor the package are there anymore.

Any idea to get i915/cometLake loaded by Xorg? Thanks a lot.


----------

