Christian König
2023-Sep-05 13:28 UTC
[Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Am 05.09.23 um 12:38 schrieb Jani Nikula:> On Tue, 05 Sep 2023, Sui Jingfeng <sui.jingfeng at linux.dev> wrote: >> From: Sui Jingfeng <suijingfeng at loongson.cn> >> >> On a machine with multiple GPUs, a Linux user has no control over which >> one is primary at boot time. This series tries to solve above mentioned >> problem by introduced the ->be_primary() function stub. The specific >> device drivers can provide an implementation to hook up with this stub by >> calling the vga_client_register() function. >> >> Once the driver bound the device successfully, VGAARB will call back to >> the device driver. To query if the device drivers want to be primary or >> not. Device drivers can just pass NULL if have no such needs. >> >> Please note that: >> >> 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would >> like to mount at least three video cards.Well, you rarely find a board which can actually handle a single one :)>> >> 2) Typically, those non-86 machines don't have a good UEFI firmware >> support, which doesn't support select primary GPU as firmware stage. >> Even on x86, there are old UEFI firmwares which already made undesired >> decision for you. >> >> 3) This series is attempt to solve the remain problems at the driver level, >> while another series[1] of me is target to solve the majority of the >> problems at device level. >> >> Tested (limited) on x86 with four video card mounted, Intel UHD Graphics >> 630 is the default boot VGA, successfully override by ast2400 with >> ast.modeset=10 append at the kernel cmd line. > The value 10 is incredibly arbitrary, and multiplied as a magic number > all over the place.+1> >> $ lspci | grep VGA >> >> 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] >> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos XTX [Radeon HD 8490 / R5 235X OEM] >> 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 30) >> 05:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 720] (rev a1) > In this example, all of the GPUs are driven by different drivers. What > good does a module parameter do if you have multiple GPUs of the same > model, all driven by the same driver module?Completely agree. Question is what is the benefit for the end user to actually specify this? If you want the initial console on a different device than implement a kernel options for vgaarb and *not* the drivers. Regards, Christian.> > BR, > Jani. > >> $ sudo dmesg | grep vgaarb >> >> pci 0000:00:02.0: vgaarb: setting as boot VGA device >> pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none >> pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none >> pci 0000:04:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none >> pci 0000:05:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none >> vgaarb: loaded >> ast 0000:04:00.0: vgaarb: Override as primary by driver >> i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem >> radeon 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none >> ast 0000:04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none >> >> v2: >> * Add a simple implemment for drm/i915 and drm/ast >> * Pick up all tags (Mario) >> v3: >> * Fix a mistake for drm/i915 implement >> * Fix patch can not be applied problem because of merge conflect. >> v4: >> * Focus on solve the real problem. >> >> v1,v2 at https://patchwork.freedesktop.org/series/120059/ >> v3 at https://patchwork.freedesktop.org/series/120562/ >> >> [1] https://patchwork.freedesktop.org/series/122845/ >> >> Sui Jingfeng (9): >> PCI/VGA: Allowing the user to select the primary video adapter at boot >> time >> drm/nouveau: Implement .be_primary() callback >> drm/radeon: Implement .be_primary() callback >> drm/amdgpu: Implement .be_primary() callback >> drm/i915: Implement .be_primary() callback >> drm/loongson: Implement .be_primary() callback >> drm/ast: Register as a VGA client by calling vga_client_register() >> drm/hibmc: Register as a VGA client by calling vga_client_register() >> drm/gma500: Register as a VGA client by calling vga_client_register() >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +++- >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 ++++- >> drivers/gpu/drm/ast/ast_drv.c | 31 ++++++++++ >> drivers/gpu/drm/gma500/psb_drv.c | 57 ++++++++++++++++++- >> .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 15 +++++ >> drivers/gpu/drm/i915/display/intel_vga.c | 15 ++++- >> drivers/gpu/drm/loongson/loongson_module.c | 2 +- >> drivers/gpu/drm/loongson/loongson_module.h | 1 + >> drivers/gpu/drm/loongson/lsdc_drv.c | 10 +++- >> drivers/gpu/drm/nouveau/nouveau_vga.c | 11 +++- >> drivers/gpu/drm/radeon/radeon_device.c | 10 +++- >> drivers/pci/vgaarb.c | 43 ++++++++++++-- >> drivers/vfio/pci/vfio_pci_core.c | 2 +- >> include/linux/vgaarb.h | 8 ++- >> 14 files changed, 210 insertions(+), 19 deletions(-)
Sui Jingfeng
2023-Sep-05 14:28 UTC
[Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi, On 2023/9/5 21:28, Christian K?nig wrote:>>> >>> 2) Typically, those non-86 machines don't have a good UEFI firmware >>> ??? support, which doesn't support select primary GPU as firmware >>> stage. >>> ??? Even on x86, there are old UEFI firmwares which already made >>> undesired >>> ??? decision for you. >>> >>> 3) This series is attempt to solve the remain problems at the driver >>> level, >>> ??? while another series[1] of me is target to solve the majority of >>> the >>> ??? problems at device level. >>> >>> Tested (limited) on x86 with four video card mounted, Intel UHD >>> Graphics >>> 630 is the default boot VGA, successfully override by ast2400 with >>> ast.modeset=10 append at the kernel cmd line. >> The value 10 is incredibly arbitrary, and multiplied as a magic number >> all over the place. > > +1This is the exact reason why I made this series as RFC, because this is a open-ended problem. The choices of 3,4,5,6,7,8 and 9 are as arbitrary as the number of '10'. '1' and '2' is definitely not suitable, because the seat has already been taken. Take the drm/nouveau as an example: ``` MODULE_PARM_DESC(modeset, "enable driver (default: auto, " "0 = disabled, 1 = enabled, 2 = headless)"); int nouveau_modeset = -1; module_param_named(modeset, nouveau_modeset, int, 0400); ``` '1' is for enable the drm driver, some driver even override the 'nomodeset' parameter. '2' is not suitable, because nouveau use it as headless GPU (render-only or compute class GPU?) '3' is also not likely the best, the concerns is that what if a specific drm driver want to expand the usage in the future? The reason I pick up the digit '10' is that 1) The modeset parameter is unlikely to get expanded up to 10 usages. Other drm drivers only use the '-1', '0' and 1, choose '2' will conflict with drm/nouveau. By pick the digit '10', it leave some space(room) to various device driver authors. It also helps to keep the usage consistent across various drivers. 2) An int taken up 4 byte, I don't want to waste even a single byte, While in the process of defencing my patch, I have to say draft another kernel command line would cause the wasting of precious RAM storage. An int can have 2^31 usage, why we can't improve the utilization rate? 3) Please consider the fact that the modeset is the most common and attractive parameter No name is better than the 'modeset', as other name is not easy to remember. Again, this is for Linux user, thus it is not arbitrary. Despite simple and trivial, I think about it more than one week.