drm/i915: Restore default setting for enable_guc again [FreeBSD]#446
drm/i915: Restore default setting for enable_guc again [FreeBSD]#446dumbbell wants to merge 1 commit into
enable_guc again [FreeBSD]#446Conversation
dumbbell
force-pushed
the
re-enable-guc-autodetection
branch
from
dbe51a4 to
885f7ba
Compare
dumbbell
force-pushed
the
re-enable-guc-autodetection
branch
from
885f7ba to
cfbfec3
Compare
... except that GuC submission is still disabled on FreeBSD by default. Some recent GPUs require this to work (see freebsd#418). If we need to disable GuC for some GPUs, we can add them in `uc_expand_default_options()` in `drivers/gpu/drm/i915/gt/uc/intel_uc.c`. It will be better than disabling it for everyone, requiring some user to mess with an obscure setting in `/boot/loader.conf`. As said at the beginning however, we still disable GuC submission by default on FreeBSD. The reason is that is often prevents a computer from powering off: the kernel stops everything, the display is turned off, but the power LED is on and the fans are audible. Sponsored by: The FreeBSD Foundation
dumbbell
force-pushed
the
re-enable-guc-autodetection
branch
from
cfbfec3 to
de7eac7
Compare
|
@amshafer, @dasTor: I modified the initial patch slightly. The default is autodetection ( I believe it will allow you to use the driver without messing with this setting. What do you think? |
| * is turned off, but the power LED is still on and the fans are | ||
| * running. The computer is obviously unreachable. | ||
| */ | ||
| i915->params.enable_guc = ENABLE_GUC_LOAD_HUC; |
There was a problem hiding this comment.
I think we do actually want GuC submission, at least for meteorlake+. GuC submission I believe is required on these newer platforms because graphics work has to happen via GuC. Without submission work can't be handed to the GPU so no drawing can be done. I think this is why dasTor ran into things not working with enable_guc=2 but enable_guc=3 (or enable_guc=1 that I've tested with) provides a working setup.
Me personally, I'd much prefer that we provide a working out-of- the-box experience for users on modern hardware with a caveat that the machine has to be forcefully powered off vs not providing a working setup at all.
There was a problem hiding this comment.
fwiw on my meteorlake laptop I do usually see it shut down properly, although occasionally it will run into the issue you describe. Hard to confirm that it's for sure the drm driver though
There was a problem hiding this comment.
In my case, it refuses to shutdown 90% of the time with GuC submission enabled (Intel 12th gen).
I forgot: it affects reboot too. Like the computer hangs just before actually rebooting.
My attempt to use sysbeep() to trace where the driver stops doesn't work: it relies on interrupts which are probably disabled. I will try something else.
There was a problem hiding this comment.
Even if it causes problems on shutdown I'd still prefer we give users a working desktop when they first try drm-kmod since they can force poweroff as a workaround. Maybe only defaulting to GuC submission enabled for meteorlake and newer is a good compromise?
I agree we do want a fix for this long-term though since I'm guessing it affects suspend/resume as well. I can't test that on my laptop until intel modern standby lands.
2 participants
... except that GuC submission is still disabled on FreeBSD by default.
Some recent GPUs require this to work (see #418). If we need to disable GuC for some GPUs, we can add them in
uc_expand_default_options()indrivers/gpu/drm/i915/gt/uc/intel_uc.c. It will be better than disabling it for everyone, requiring some user to mess with an obscure setting in/boot/loader.conf.As said at the beginning however, we still disable GuC submission by default on FreeBSD. The reason is that is often prevents a computer from powering off: the kernel stops everything, the display is turned off, but the power LED is on and the fans are lightly audible.