00:00 bnieuwenhuizen: but I dunno ...
00:00 bnieuwenhuizen: can always fallback to a kernel submit if userspace submit fails?
00:00 airlied: yeah that's what I was wondering does it need to do that etc
00:44 X512: jekstrand: I feel that direct-to-FW submission would be beneficial for non Linux open source operating systems such as FreeBSD and Haiku.
00:45 X512: It allow to implement drivers fully in userspace without submission overhead.
00:45 X512: And need less driver code.
00:45 jekstrand: heh.... Not so much. :)
00:46 jekstrand: It really doesn't reduce the size of the kernel implementation that much.
00:46 bnieuwenhuizen: should implement it all in the GSP. That'll help other OSes :P
00:46 jekstrand: You still have to do memory management, eviction, fault handling, pause/resume of contexts when you get over-subscribed, etc.
00:50 X512: But 3D rendering hot path will not require calling kernel driver. So it can be used with microkernel OSes without performance loss.
00:50 jekstrand: Yeah, it probably is better for microkernels
00:53 airlied: but really there's 0 hope of them implementing all the other bits
00:54 airlied: even with GSP there is a sizeable driver
00:54 airlied: and that is probably the smallest x86 gpu kernel driver footprint you could achieve with any vendor
00:57 HdkR: BO eviction and me aren't on good terms
00:57 X512: nVidia open GPU driver have large benefit for other OSes that it is portable and can be easily compiled. The only thing need to be done is writing specific OS kernel interfacing code.
00:58 X512: Unfortuneately other open source GPU kernel driver are hard coded to Linux private unstable kernel API.
01:00 X512: Very bad that Linux don't want to use nVidia open GPU drivers as is and plan to reinvent the wheel with Linux hard coded driver.
01:03 psykose: which ones are you referring to
01:03 psykose: https://github.com/NVIDIA/open-gpu-kernel-modules ?
01:09 X512: Yes.
01:10 X512: nv-kernel.o and nv-modeset-kernel.o compiles on Haiku without problem.
01:16 X512: Haiku may get better nVidia support that Linux because it have no DRM/GBM/implicit sync legacy :)
01:16 psykose: the entire userspace that is usable for those is completely proprietary
01:16 psykose: and it only supports new gpus
01:16 psykose: very open yes
01:17 X512: Recevnt open Vulkan nVidia VNK driver probably can be easily adapted to nVidia open GPU driver ioctl interface.
01:17 X512: NVK: https://www.collabora.com/news-and-blog/news-and-events/introducing-nvk.html
01:19 X512: Supporting older nVidia GPUs by open source seems hopeless because of unability to control power settings and GPU run at lowest performance.
01:38 DavidHeidelberg[m]: X512: but by running older nvidia GPU you save the planet. It always run 100% ecologically on low gpu and mem freq :D
01:39 DavidHeidelberg[m]: Also won't die because it won't overheat!
01:59 X512: Is it possble to know to which GPU dma_buf FD belong to?
10:10 emersion: no
14:44 fodasso: Hello, sway/wayfire segfault here with any mesa higher than 22.2.3. Error message is: nvc0_screen_create:1093 - Base screen init failed: -19
14:45 fodasso: Found this link: https://github.com/swaywm/sway/issues/7335 Why would my RTX 2060 not be compatible with newer mesa? There is even this new NVK driver that should be compatible?
15:04 kisak: sounds like https://gitlab.freedesktop.org/mesa/mesa/-/issues/8007
15:10 fodasso: Indeed. Odd that it also affects the nvk/main branch by the nouveau team.
15:43 pinchartl: airlied: danvet: how does drm-misc handle base branches that need to be merged through multiple trees ? tomba has a series that touches both media and drm, with a base branch on top of v6.2-rc1 with the common commits. can it be merged as-is in drm-misc-next, with additional patches applied on top with dim, or is there a different process ?
15:44 danvet: pinchartl, coordinate with drm-misc maintainers, either they do the topic branch and send pull to the other tree, or they merge the topic branch
15:44 danvet: and yes that sounds reasonable
15:44 danvet: that = shared topic branch for the baseline commits and then the drm stuff in dim on top or something like that
15:45 pinchartl: Mauro has acked all the patches in the base branch for merge through drm. there's a high chance the branch won't need to be merged in the media tree this time as I don't foresee any conflict, but in case last minute changes need to go there, it's good to be prepared
23:46 DemiMarie: bnieuwenhuizen jekstrand: can direct-to-fw please be made optional, even when virtualizing? Because the lack of input validation is going to be a serious problem for those who are virtualizing for security.
23:48 DemiMarie: X512: direct-to-FW will prevent microkernels from losing performance, but only if they trust the FW to properly validate its inputs. I have seen no evidence that the FW is trustworthy.
23:51 DemiMarie: To quote alyssa: “I don't and you shouldn't”
23:54 bnieuwenhuizen: if you don't trust the FW then non-direct-to-fw should be an issue since cmdbuffers are still interpreted by FW?
23:55 bnieuwenhuizen: looks like direct-to-fw is not that different from existing paths to call secondary cmdbuffers
23:57 jenatali: Demi: I think you might have an expectation that the kernel is doing validation. AFAIK it isn't. I don't think direct-to-fw changes anything from a validation/security perspective