Re: modesetting vs intel in 10.0
(reviving an old tread) On Mon 04 Sep 2023 at 20:18:49 -0400, Greg Troxel wrote: > Earlier the screen would go black for a few seconds pretty often (like 2 > every 30), with modesetting and also intel. I am now pretty sure that > this was because I was running zpool scrub. Without a scrub, I don't > get this. > > My graphics is: > > i915drmkms0 at pci0 dev 2 function 0: Intel UHD Graphics 630 (rev. 0x02) > i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0) > i915drmkms0: notice: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. > Disabling runtime power management. > [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0 > intelfb0 at i915drmkms0 > intelfb0: framebuffer at 0xc004, size 2560x1440, depth 32, stride 10240 Out of desperation, I pulled out my Radeon HD 5450 card and now I am using the same graphics as you are. > With the modesetting driver, it is also mostly great, except: > > same github comment box artifacts I didn't test this. > cursor is often not quite right and it's a little confusing to resize > windows as the change-icon clues are a bit off. It's like the "update > cursor" write calls get garbled output and then resolve. I see this too. I > scrolling in firefox has text with some scan lines messed up and then > over a second or two they resolve. I see this changing virtual > desktops to firefox also. switching to xterms is fine. I see this in firefox (123) menus when moving the mouse through the menus: the highlighting of the entries doesn't get painted right away. It kind of looks like some cached written data doesn't get pushed out to the final destination right away. The same could explain the mouse cursor. nia@ suggested to run xcompmgr. It fixes the Firefox menus for me, but not the mouse cursor. Also it breaks my use of xv (graphics/xv) to set my desktop background (and change it every 5 minutes). I'm trying to use feh for that now. With this config (kernel 10 + intel hw + modesetting driver) the x11/redshift program doesn't work any more (it works on my Thinkpad T470s with kernel 10 + intel hw + intel driver). -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: modesetting vs intel in 10.0
nia writes: > On Sat, Aug 26, 2023 at 06:47:01AM -0400, Greg Troxel wrote: >> I am new to modern intel graphics. I have a UHD 630 with a 9th >> generation (coffee lake?) CPU. It is using intel, and it works for >> xterm :-) But I see artifacts while typing into github comment boxes. >> Is this something I should try modesetting on? >> >> Is there a wiki page that collects "this option works or doesn't work, >> and is or isn't preferred" with various graphics, along with >> instructions for choosing? I know I could figure this out but it would >> probably speed testing to have someone who already knows write it down >> and post a link. > > Yes, the artifacts are a symptom. > > In general the intel driver has been discontinued since 2015 or so. > > In /etc/xorg.conf, try: > > Section "Device" > Identifier "Card0" > Driver "modesetting" > EndSection > > (This is okay for the whole file if it doesn't exist already.) Thanks, that worked fine. Finally a data point (I don't like to exit and restart X because I have too much state). Earlier the screen would go black for a few seconds pretty often (like 2 every 30), with modesetting and also intel. I am now pretty sure that this was because I was running zpool scrub. Without a scrub, I don't get this. My graphics is: i915drmkms0 at pci0 dev 2 function 0: Intel UHD Graphics 630 (rev. 0x02) i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0) i915drmkms0: notice: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0 intelfb0 at i915drmkms0 intelfb0: framebuffer at 0xc004, size 2560x1440, depth 32, stride 10240 which is on a 2019 Dell with 9th gen i7: cpu0: "Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz" cpu0: Intel 7th or 8th gen Core (Kaby Lake, Coffee Lake) or Xeon E (Coffee Lake) (686-class), 3000.00 MHz With the intel driver, it is mostly great except typing text in firefox has artifacts which resolve. xterm is fine. display blanking into hw powersave is fine. With the modesetting driver, it is also mostly great, except: same github comment box artifacts cursor is often not quite right and it's a little confusing to resize windows as the change-icon clues are a bit off. It's like the "update cursor" write calls get garbled output and then resolve. scrolling in firefox has text with some scan lines messed up and then over a second or two they resolve. I see this changing virtual desktops to firefox also. switching to xterms is fine. But really both are quite usable.
Re: modesetting vs intel in 10.0
On Thu, Aug 31, 2023 at 09:17:35PM +0100, Mike Pumford wrote: > On 30/08/2023 09:56, nia wrote: > > > I think detecting the year of manufacture is too much of a hard > > problem - there are simply too many new cards and I have no idea > > about a "cutoff point" where modesetting starts being OK (if it > > even isn't okay for any old cards at all - it should work as long > > as DRM/KMS works AFAIK) > > > Well speaking as someone whose older card worked fine under 9 and now just > ends up as a black screen with both the intel driver and the modesetting one > on 10.0. I'm more interesting in getting back to having a working > accelerated X setup. I did see the tearing on the intel driver on 9.x but it > was never bad enough to make me try the modesetting driver. > > For reference my now broken hardware is: > [ 1.008474] pci1: i/o space, memory space enabled, rd/line, wr/inv ok > [ 1.008474] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell > Integrated Graphics Device (rev. 0x06) > > See kern/57268 for how my hardware fails. > > Mike OK, but this is not the question
Re: modesetting vs intel in 10.0
On 30/08/2023 09:56, nia wrote: I think detecting the year of manufacture is too much of a hard problem - there are simply too many new cards and I have no idea about a "cutoff point" where modesetting starts being OK (if it even isn't okay for any old cards at all - it should work as long as DRM/KMS works AFAIK) > Well speaking as someone whose older card worked fine under 9 and now just ends up as a black screen with both the intel driver and the modesetting one on 10.0. I'm more interesting in getting back to having a working accelerated X setup. I did see the tearing on the intel driver on 9.x but it was never bad enough to make me try the modesetting driver. For reference my now broken hardware is: [ 1.008474] pci1: i/o space, memory space enabled, rd/line, wr/inv ok [ 1.008474] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell Integrated Graphics Device (rev. 0x06) See kern/57268 for how my hardware fails. Mike
Re: modesetting vs intel in 10.0
On Tue, Jul 11, 2023 at 09:58:51AM +1000, matthew green wrote: > > But maybe modesetting is mature enough (and intel bad enough) > > to warrant being the default for Intel GPUs. > > i'm not familiar with the various intel chipsets, i've only had > a couple of them over the years and besides porting the kabylake > bits into the older drm version, i've not really touched it much. > > but, you can adjust the list of drivers used by default here in > the xorg-server sources: > >hw/xfree86/common/xf86pciBus.c:xf86VideoPtrToDriverList() > > where it has a "default:" case for intel of "intel", and if you > can properly figure out how to change this to "modesetting" for > the newer ones (only?) that would be fine by me. > > (one way to handle this without having to patch this code would > be to install the intel driver as some other name, and then make > a copy of the "ati" front end called "intel" that loads either > the real intel driver or modesetting, depending.) It does allow having multiple defaults! This is the case, for example, for nvidia cards, which try nouveau first then fall back to to nv. I think detecting the year of manufacture is too much of a hard problem - there are simply too many new cards and I have no idea about a "cutoff point" where modesetting starts being OK (if it even isn't okay for any old cards at all - it should work as long as DRM/KMS works AFAIK)
re: modesetting vs intel in 10.0
> [ 1.051227] i915drmkms: preliminary hardware support disabled this is a combo of the driver data for tiger lake (11th gen) having "require_force_probe" set to 1 (our drm base), and the netbsd probe code seeing this set and not matching properly. there's nothing you're doing wrong, it just isn't enabled (it may not work, i don't know.) if you want try, edit sys/external/bsd/drm2/i915drm/i915_pci_autoconf.c to disable the check at line 111. .mrg.
Re: modesetting vs intel in 10.0
Brian Stuart wrote:
> Am I correct that even with all the improvements, there are still
> Intel video systems that aren't supported? On a Dell Latitude 7420,
> dmesg shows:
>
> [ 1.051227] pchb0 at pci0 dev 0 function 0: Intel Tiger Lake (UP3
> 4Core) Host (rev. 0x01)
> [ 1.051227] i915drmkms: preliminary hardware support disabled
The NetBSD driver code tests the require_force_probe member of the
pci_device_id struct, it prints the message above and doesnt attach the
DRM driver if it is set.
This is set for Elkhart Lake and Tiger Lake GPUs in the version of the
DRM code in the tree, which is from Linux 5.6-rc3, later GPUs are not
detected at all.
The equivalent Linux probe function doesn't do very much if this flag
is set, you could try just removing the test to see what happens using
the patch below.
If people have got the i915drmkms driver to attach then it would be
helpful if they could try the new native MesaLib, I don't have any
recent Intel systems to test it on. To build new MesaLib set
HAVE_MESA_VER=21 in your /etc/mk.conf before running build.sh.
Index: i915_pci_autoconf.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/i915drm/i915_pci_autoconf.c,v
retrieving revision 1.14
diff -u -r1.14 i915_pci_autoconf.c
--- i915_pci_autoconf.c 15 Oct 2022 15:20:06 - 1.14
+++ i915_pci_autoconf.c 29 Aug 2023 12:55:27 -
@@ -108,11 +108,12 @@
const struct intel_device_info *const info =
(struct intel_device_info *)ent->driver_data;
+#if 0
if (info->require_force_probe) {
printf("i915drmkms: preliminary hardware support disabled\n");
return NULL;
}
-
+#endif
return ent;
}
Re: modesetting vs intel in 10.0
fwiw, my main old machine seems happier with modesetting - I'm yet to see the random artifacts I was seeing with intel; onshape, webgl, etc, seem about as good as before. This is on recent snapshot of netbsd-10. GPU is Sandy Bridge Intel Core i7-2600 3.4GHz (Sandy Bridge-HE-4 id 0x206a7) circa Jan 2011. i915drmkms0 at pci0 dev 2 function 0: Intel Sandy Bridge (desktop) GI1 Integrated Graphics Device (rev. 0x09) -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
Re: modesetting vs intel in 10.0
David Brownlee writes: > That would be correct, though current and -10 support is better than > -9. On a 9th gen cpu, UHD 630 graphics, netbsd-9 is wsfb, but intel driver and modesetting function at least mostly with netbsd-10. I'm typing this from intel driver working totally ok except for font funniness while typing in github comments. It seems that zfs scrub and heavy load leads to periods of all-black screen, with both intel and modesetting drivers. Or it's a coincidence and it's something else.
Re: modesetting vs intel in 10.0
On Sun, 27 Aug 2023 at 18:48, Brian Stuart wrote: > > Am I correct that even with all the improvements, there are still > Intel video systems that aren't supported? On a Dell Latitude 7420, > dmesg shows: > > [ 1.051227] pchb0 at pci0 dev 0 function 0: Intel Tiger Lake (UP3 > 4Core) Host (rev. 0x01) > [ 1.051227] i915drmkms: preliminary hardware support disabled > [ 1.051227] genfb0 at pci0 dev 2 function 0: Intel UHD Graphics > (GT2, 96/80 EU) (rev. 0x01) > [ 1.051227] genfb0: framebuffer at 0x40, size 1920x1080, > depth 32, stride 7680 > [ 1.051227] genfb0: shadow framebuffer enabled, size 8100 KB > [ 1.051227] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 > emulation), using wskbd0 > [ 1.051227] wsmux1: connecting to wsdisplay0 > [ 1.051227] drm at genfb0 not configured > > and X is only working with wsfb. I've been intending to look into > this myself, but $DAYJOB keeps getting in the way. (I even downloaded > about 9000 pages of Intel documentation as a start.) On the other > hand, if there's something I'm doing wrong and am just missing the > boat, I'd love to know. TIA That would be correct, though current and -10 support is better than -9. I have a 13th gen Raptor Lake which also attaches as genfb0, though I would expect non 3D desktop performance to be Just Fine (I'm using it as a server), and a AMD Ryzen 5 Pro 3500U based Thinkpad T495 which I use as my primary machine which attaches a genfb0 and non 3D desktop performance *is* Just Fine :) Definitely don't let that discourage you from looking at adding support - I'd probably look up the pci ids, and the pci ids for a previous supported generation in the current NetBSD drm tree, and then in the upstream Linux source to see what if any special handling the newer codes have. If they don't seem to have anything special. then just add them to the supported list and test a kernel :-p David
Re: modesetting vs intel in 10.0
Am I correct that even with all the improvements, there are still Intel video systems that aren't supported? On a Dell Latitude 7420, dmesg shows: [ 1.051227] pchb0 at pci0 dev 0 function 0: Intel Tiger Lake (UP3 4Core) Host (rev. 0x01) [ 1.051227] i915drmkms: preliminary hardware support disabled [ 1.051227] genfb0 at pci0 dev 2 function 0: Intel UHD Graphics (GT2, 96/80 EU) (rev. 0x01) [ 1.051227] genfb0: framebuffer at 0x40, size 1920x1080, depth 32, stride 7680 [ 1.051227] genfb0: shadow framebuffer enabled, size 8100 KB [ 1.051227] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 1.051227] wsmux1: connecting to wsdisplay0 [ 1.051227] drm at genfb0 not configured and X is only working with wsfb. I've been intending to look into this myself, but $DAYJOB keeps getting in the way. (I even downloaded about 9000 pages of Intel documentation as a start.) On the other hand, if there's something I'm doing wrong and am just missing the boat, I'd love to know. TIA On Sun, Aug 27, 2023 at 3:26 PM David Brownlee wrote: > > On Fri, 25 Aug 2023 at 22:00, nia wrote: > > > > On Fri, Aug 25, 2023 at 08:55:13PM +0100, David Brownlee wrote: > > > Picking up on this, particularly with netbsd-10 looming, I think we > > > should at least whitelist some known good-with-modesetting Intel GPUs, > > > with a plan to swapping over to whitelisting keep-on-intel Intel over > > > time. > > > > I've pretty much only got haswell or newer, all of which are > > better with modesetting. Maybe you have some older GPUs which > > need intel? > > I'll go hunting to see what I can find - last time the machines I > could lay my hands on were happy with modesetting...
Re: modesetting vs intel in 10.0
On Fri, 25 Aug 2023 at 22:00, nia wrote: > > On Fri, Aug 25, 2023 at 08:55:13PM +0100, David Brownlee wrote: > > Picking up on this, particularly with netbsd-10 looming, I think we > > should at least whitelist some known good-with-modesetting Intel GPUs, > > with a plan to swapping over to whitelisting keep-on-intel Intel over > > time. > > I've pretty much only got haswell or newer, all of which are > better with modesetting. Maybe you have some older GPUs which > need intel? I'll go hunting to see what I can find - last time the machines I could lay my hands on were happy with modesetting...
Re: modesetting vs intel in 10.0
On Sat, Aug 26, 2023 at 06:47:01AM -0400, Greg Troxel wrote: > I am new to modern intel graphics. I have a UHD 630 with a 9th > generation (coffee lake?) CPU. It is using intel, and it works for > xterm :-) But I see artifacts while typing into github comment boxes. > Is this something I should try modesetting on? > > Is there a wiki page that collects "this option works or doesn't work, > and is or isn't preferred" with various graphics, along with > instructions for choosing? I know I could figure this out but it would > probably speed testing to have someone who already knows write it down > and post a link. Yes, the artifacts are a symptom. In general the intel driver has been discontinued since 2015 or so. In /etc/xorg.conf, try: Section "Device" Identifier "Card0" Driver "modesetting" EndSection (This is okay for the whole file if it doesn't exist already.)
Re: modesetting vs intel in 10.0
nia writes: > On Fri, Aug 25, 2023 at 08:55:13PM +0100, David Brownlee wrote: >> Picking up on this, particularly with netbsd-10 looming, I think we >> should at least whitelist some known good-with-modesetting Intel GPUs, >> with a plan to swapping over to whitelisting keep-on-intel Intel over >> time. > > I've pretty much only got haswell or newer, all of which are > better with modesetting. Maybe you have some older GPUs which > need intel? I am new to modern intel graphics. I have a UHD 630 with a 9th generation (coffee lake?) CPU. It is using intel, and it works for xterm :-) But I see artifacts while typing into github comment boxes. Is this something I should try modesetting on? Is there a wiki page that collects "this option works or doesn't work, and is or isn't preferred" with various graphics, along with instructions for choosing? I know I could figure this out but it would probably speed testing to have someone who already knows write it down and post a link.
Re: modesetting vs intel in 10.0
On Fri, Aug 25, 2023 at 08:55:13PM +0100, David Brownlee wrote: > Picking up on this, particularly with netbsd-10 looming, I think we > should at least whitelist some known good-with-modesetting Intel GPUs, > with a plan to swapping over to whitelisting keep-on-intel Intel over > time. I've pretty much only got haswell or newer, all of which are better with modesetting. Maybe you have some older GPUs which need intel?
Re: modesetting vs intel in 10.0
On Fri, 7 Jul 2023 at 21:39, nia wrote: > > On Fri, Jul 07, 2023 at 08:18:18PM +0100, David Brownlee wrote: > > On Fri, 7 Jul 2023 at 19:43, nia wrote: > > > > > > After some testing on a Skylake machine, I've concluded > > > that xf86-video-modesetting is far superior to xf86-video-intel > > > on that generation of Intel hardware - the most obvious thing > > > is that modesetting has functional VSync and superior 3D performance > > > with less tearing. > > > > > > Only problem is that we default to intel, modesetting you need > > > to choose explicitly through xorg.conf. > > > > > > I also found similar problems in "radeon", but found that > > > modesetting would somehow pick a display mode that the monitor > > > didn't support. Maybe this is actually a drmkms bug - I'm not > > > sure. > > > > > > But maybe modesetting is mature enough (and intel bad enough) > > > to warrant being the default for Intel GPUs. > > > > Could we start with some form of whitelist to pick modesetting over intel? > > > > David > > Maybe GPUs released after intel became abandonware in 2014 or so... Picking up on this, particularly with netbsd-10 looming, I think we should at least whitelist some known good-with-modesetting Intel GPUs, with a plan to swapping over to whitelisting keep-on-intel Intel over time. Does anyone have any better thoughts? David
Re: modesetting vs intel in 10.0
On Wed, 12 Jul 2023 at 02:50, Paul Ripke wrote: > > On Sun, Jul 09, 2023 at 08:13:45AM +0100, Chavdar Ivanov wrote: > > On Sun, 9 Jul 2023 at 00:55, Lloyd Parkes > > wrote: > > > > > > > > > > > > On 9/07/23 10:06, David Brownlee wrote: > > > > What would be a good benchmark to stress the system a little? > > > > > > A while back someone mentioned pkgsrc/benchmarks/glmark2 and so I > > > started using that. It seems reasonable. > > > > Besides that, I also use cad.onshape.com/check - but using firefox > > ESR, as the current firefox in pkgsrc is stripped from its WebGL > > capabilities. > > I did note after a rolling update of pkgsrc-2023Q2 that webgl was > disabled in firefox-114.0.1, but could be re-enabled in about:config > by setting webgl.disabled=false and/or webgl.force-enabled=true. I knew about these, I had them set accordingly. With 'webgl.disabled=true' you get a nice message telling you that your browser does not support it; otherwise, you get your GL canvas as a green blob and your error stream is filled with messages like: ... Crash Annotation GraphicsCriticalError: |[0][GFX1]: MethodDispatcher<26> not found. Please file a bug! (t=7.7034) |[4111][GFX1]: DispatchCommand(id: 18) failed. Please file a bug! (t=12.0513) |[4112][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0522) |[4098][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0466) |[4099][GFX1]: DispatchCommand(id: 18) failed. Please file a bug! (t=12.0467) |[4100][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0473) |[4101][GFX1]: DispatchCommand(id: 18) failed. Please file a bug! (t=12.0474) |[4102][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0482) |[4103][GFX1]: DispatchCommand(id: 18) failed. Please file a bug! (t=12.0485) |[4104][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0492) |[4105][GFX1]: DispatchCommand(id: 18) failed. Please file a bug! (t=12.0492) |[4106][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0499) |[4107][GFX1]: DispatchCommand(id: 18) failed. Please file a bug! (t=12.0499) |[4108][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0506) |[4109][GFX1]: DispatchCommand(id: 18) failed. Please file a bug! (t=12.0507) |[4110][GFX1]: MethodDispatcher<18> not found. Please file a bug! (t=12.0513) [GFX1]: MethodDispatcher<18> not found. Please file a bug! So no, in my case, both Intel 530 and AMD FirePro W5000, the result is the same and WebGL is missing. At the same time, as I mentioned before, the latest firefox-esr supports it fine, on both systems. > > (netbsd-9 on amd64 with i915, fwiw). > > -- > Paul Ripke > "Great minds discuss ideas, average minds discuss events, small minds > discuss people." > -- Disputed: Often attributed to Eleanor Roosevelt. 1948. Chavdar --
Re: modesetting vs intel in 10.0
On Sun, Jul 09, 2023 at 08:13:45AM +0100, Chavdar Ivanov wrote: > On Sun, 9 Jul 2023 at 00:55, Lloyd Parkes > wrote: > > > > > > > > On 9/07/23 10:06, David Brownlee wrote: > > > What would be a good benchmark to stress the system a little? > > > > A while back someone mentioned pkgsrc/benchmarks/glmark2 and so I > > started using that. It seems reasonable. > > Besides that, I also use cad.onshape.com/check - but using firefox > ESR, as the current firefox in pkgsrc is stripped from its WebGL > capabilities. I did note after a rolling update of pkgsrc-2023Q2 that webgl was disabled in firefox-114.0.1, but could be re-enabled in about:config by setting webgl.disabled=false and/or webgl.force-enabled=true. (netbsd-9 on amd64 with i915, fwiw). -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
re: modesetting vs intel in 10.0
> But maybe modesetting is mature enough (and intel bad enough) > to warrant being the default for Intel GPUs. i'm not familiar with the various intel chipsets, i've only had a couple of them over the years and besides porting the kabylake bits into the older drm version, i've not really touched it much. but, you can adjust the list of drivers used by default here in the xorg-server sources: hw/xfree86/common/xf86pciBus.c:xf86VideoPtrToDriverList() where it has a "default:" case for intel of "intel", and if you can properly figure out how to change this to "modesetting" for the newer ones (only?) that would be fine by me. (one way to handle this without having to patch this code would be to install the intel driver as some other name, and then make a copy of the "ati" front end called "intel" that loads either the real intel driver or modesetting, depending.) .mrg.
Re: modesetting vs intel in 10.0
On Sun, 9 Jul 2023 at 11:14, Mike Pumford wrote: > > On 08/07/2023 23:06, David Brownlee wrote: > > > Would it be worth trying to collect some data on users running NetBSD > > on intel display hardware, to see if there are any cases where > > intel_drv works and modesetting_drv does not? > > > > As a datapoint, on a Thinkpad T480 runs OK with the default intel_dev. > > Renaming away /usr/X11R7/lib/modules/drivers/intel_drv.so and > > restarting X runs fine with modesetting_drv, and "grep Mesa > > /var/log/Xorg.0.log" gives > > > > > (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) > > UHD Graphics 620 (Kabylake GT2) > > > Both are equally bad for me. The console works perfectly but I get stuck > in the blank screen heartbeat death with both (see kern/57268): > > [44.509] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD > Graphics 4600 > [44.509] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, > sse4.2, avx, avx2; using a maximum of 4 threads > > So fiddling with the default X driver for intel hardware is only part of > the solution. We need to address the core issues in the i915kmsdrm that > impact both. Absolutely, though that is an orthogonal issue - providing modesetting_drv is no worse on any hardware than intel_dev then it makes sense to have it used by default, and i915kmsdrm needs to work on more hardware (it's good there is a PR) David
Re: modesetting vs intel in 10.0
nia wrote: > After some testing on a Skylake machine, I've concluded > that xf86-video-modesetting is far superior to xf86-video-intel > on that generation of Intel hardware - the most obvious thing > is that modesetting has functional VSync and superior 3D performance > with less tearing. > > Only problem is that we default to intel, modesetting you need > to choose explicitly through xorg.conf. Another option could be to just have a shell script that will rename intel_drv.so to something that xorg won't find. We have had multiple builds of ati and intel installed at the same time that needed to be renamed to pick the one you wanted. > I also found similar problems in "radeon", but found that > modesetting would somehow pick a display mode that the monitor > didn't support. Maybe this is actually a drmkms bug - I'm not > sure. One reason for using radeon is that it will make use of 2D hardware on older cards, newer ones are 3D only. > But maybe modesetting is mature enough (and intel bad enough) > to warrant being the default for Intel GPUs. I don't have a feel for which generations of Intel GPU have 2D or video HW. What Mesa settings are you using with all of this?
Re: modesetting vs intel in 10.0
On 08/07/2023 23:06, David Brownlee wrote: Would it be worth trying to collect some data on users running NetBSD on intel display hardware, to see if there are any cases where intel_drv works and modesetting_drv does not? As a datapoint, on a Thinkpad T480 runs OK with the default intel_dev. Renaming away /usr/X11R7/lib/modules/drivers/intel_drv.so and restarting X runs fine with modesetting_drv, and "grep Mesa /var/log/Xorg.0.log" gives (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) Both are equally bad for me. The console works perfectly but I get stuck in the blank screen heartbeat death with both (see kern/57268): [44.509] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4600 [44.509] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx, avx2; using a maximum of 4 threads So fiddling with the default X driver for intel hardware is only part of the solution. We need to address the core issues in the i915kmsdrm that impact both. Mike
Re: modesetting vs intel in 10.0
On Sun, 9 Jul 2023 at 00:55, Lloyd Parkes wrote: > > > > On 9/07/23 10:06, David Brownlee wrote: > > What would be a good benchmark to stress the system a little? > > A while back someone mentioned pkgsrc/benchmarks/glmark2 and so I > started using that. It seems reasonable. Besides that, I also use cad.onshape.com/check - but using firefox ESR, as the current firefox in pkgsrc is stripped from its WebGL capabilities. > > Cheers, > Lloyd > --
Re: modesetting vs intel in 10.0
On 9/07/23 10:06, David Brownlee wrote: What would be a good benchmark to stress the system a little? A while back someone mentioned pkgsrc/benchmarks/glmark2 and so I started using that. It seems reasonable. Cheers, Lloyd
Re: modesetting vs intel in 10.0
On Fri, 7 Jul 2023 at 21:39, nia wrote: > > On Fri, Jul 07, 2023 at 08:18:18PM +0100, David Brownlee wrote: > > On Fri, 7 Jul 2023 at 19:43, nia wrote: > > > > > > After some testing on a Skylake machine, I've concluded > > > that xf86-video-modesetting is far superior to xf86-video-intel > > > on that generation of Intel hardware - the most obvious thing > > > is that modesetting has functional VSync and superior 3D performance > > > with less tearing. > > > > > > Only problem is that we default to intel, modesetting you need > > > to choose explicitly through xorg.conf. > > > > > > I also found similar problems in "radeon", but found that > > > modesetting would somehow pick a display mode that the monitor > > > didn't support. Maybe this is actually a drmkms bug - I'm not > > > sure. > > > > > > But maybe modesetting is mature enough (and intel bad enough) > > > to warrant being the default for Intel GPUs. > > > > Could we start with some form of whitelist to pick modesetting over intel? > > > > David > > Maybe GPUs released after intel became abandonware in 2014 or so... Would it be worth trying to collect some data on users running NetBSD on intel display hardware, to see if there are any cases where intel_drv works and modesetting_drv does not? As a datapoint, on a Thinkpad T480 runs OK with the default intel_dev. Renaming away /usr/X11R7/lib/modules/drivers/intel_drv.so and restarting X runs fine with modesetting_drv, and "grep Mesa /var/log/Xorg.0.log" gives (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) What would be a good benchmark to stress the system a little? (I should be able to test on a T430 & T530 & W520 next week :) David
Re: modesetting vs intel in 10.0
On Fri, Jul 07, 2023 at 08:18:18PM +0100, David Brownlee wrote: > On Fri, 7 Jul 2023 at 19:43, nia wrote: > > > > After some testing on a Skylake machine, I've concluded > > that xf86-video-modesetting is far superior to xf86-video-intel > > on that generation of Intel hardware - the most obvious thing > > is that modesetting has functional VSync and superior 3D performance > > with less tearing. > > > > Only problem is that we default to intel, modesetting you need > > to choose explicitly through xorg.conf. > > > > I also found similar problems in "radeon", but found that > > modesetting would somehow pick a display mode that the monitor > > didn't support. Maybe this is actually a drmkms bug - I'm not > > sure. > > > > But maybe modesetting is mature enough (and intel bad enough) > > to warrant being the default for Intel GPUs. > > Could we start with some form of whitelist to pick modesetting over intel? > > David Maybe GPUs released after intel became abandonware in 2014 or so...
Re: modesetting vs intel in 10.0
On Fri, 7 Jul 2023 at 19:43, nia wrote: > > After some testing on a Skylake machine, I've concluded > that xf86-video-modesetting is far superior to xf86-video-intel > on that generation of Intel hardware - the most obvious thing > is that modesetting has functional VSync and superior 3D performance > with less tearing. > > Only problem is that we default to intel, modesetting you need > to choose explicitly through xorg.conf. > > I also found similar problems in "radeon", but found that > modesetting would somehow pick a display mode that the monitor > didn't support. Maybe this is actually a drmkms bug - I'm not > sure. > > But maybe modesetting is mature enough (and intel bad enough) > to warrant being the default for Intel GPUs. Could we start with some form of whitelist to pick modesetting over intel? David
modesetting vs intel in 10.0
After some testing on a Skylake machine, I've concluded that xf86-video-modesetting is far superior to xf86-video-intel on that generation of Intel hardware - the most obvious thing is that modesetting has functional VSync and superior 3D performance with less tearing. Only problem is that we default to intel, modesetting you need to choose explicitly through xorg.conf. I also found similar problems in "radeon", but found that modesetting would somehow pick a display mode that the monitor didn't support. Maybe this is actually a drmkms bug - I'm not sure. But maybe modesetting is mature enough (and intel bad enough) to warrant being the default for Intel GPUs.
