06:02 tomasuto: i also realized that getting the inermediate results out from the chiplet, has same latency as for final result, so you have multiple copies of the hash but some offsets will be removed, it is like rolling back a falsely trained ai model. So general exec is highest offset first, then deduct the offset from answer set equally, and downconvert. yeah it works well.
07:36 tzimmermann: sima, airlied, hi. could you please update drm-next to 6.9-rc2 ?
07:36 sima: will do
07:36 tzimmermann: thanks
07:37 tzimmermann: misc-next is still at 6.8-rc and i'd rather avoid to update it to -rc1s
07:41 sima: tzimmermann, both -fixes and -next rolled forward to -rc2
07:41 tzimmermann: cool thanks
08:40 tzimmermann: javierm, have you ever considered adding a dedicated efidrm or vesadrm driver?
08:42 sima: pq, https://gitlab.freedesktop.org/wayland/weston/-/issues/896#note_2351115 I hope this helps ...
08:45 pq: sima, thanks! Sounds like weston is fine to keep the checks then?
08:45 sima: pq, yeah I think for now I just don't see the point of going around and changing that ...
08:46 sima: even if we later on declare them to be a mistake, it's still an upreving of the ecosystem
08:46 pq: alright
08:52 MrCooper: linkmauve: the Gallium draw module uses LLVM even if the driver doesn't
08:57 javierm: tzimmermann: I did yes, mostly to see if we could get proper modesettings without a native DRM driver
08:57 tzimmermann: and? :)
08:58 tzimmermann: what are your thoughts
08:58 javierm: tzimmermann: but at least for vesa is complicated, because vesafb doesn't support changing resolutions IIRC and uvesafb has a user-space component (v86d) that runs emulated BIOS code or something like that
08:58 tzimmermann: yes
08:59 javierm: the EFI_GRAPHICS_OUTPUT_PROTOCOL does support a EFI_GRAPHICS_OUTPUT_PROTOCOL_SET_MODE so in theory we could support it
08:59 tzimmermann: i've been looking at simple features: such as palette support like in vesafb; or edid support
08:59 tzimmermann: and adding this to simpledrm feels like a burden
08:59 javierm: tzimmermann: yeah, I agree that is feature creep for simpledrm
09:00 tzimmermann: instead having a drm driver for vesa and efi would simplify metters
09:00 javierm: tzimmermann: agreed
09:00 tzimmermann: i guess i'll post something somewhen
09:00 javierm: tzimmermann: cool
09:05 javierm: tzimmermann: another aspect I thought that would complicate having a {vesa,efi}drm driver is matching the correct driver with the registered system framebuffer device
09:06 tzimmermann: javierm, how?
09:06 javierm: that is, you could make efidrm match "efi-framebufer" and vesadrm with "vesa-framebuffer" but sysfb registers a "simple-framebuffer" for both vesa and EFI
09:07 javierm: then your DRM drivers wil only work with !CONFIG_SYSFB_SIMPLEFB
09:07 javierm: but then you won't be able to use simpldrm...
09:08 tzimmermann: i see. i'd expect that it's either efidrm or simpledrm for sysfb
09:08 tzimmermann: most of all, simpledrm serves the simple-framebuffer OF nodes
09:08 tzimmermann: so that would remain as-is
09:09 javierm: tzimmermann: that's one option, to make simpledrm only support the "simple-framebuffer" OF nodes
09:09 javierm: but a good thing of simpledrm is that is a single driver that works for any firmware provided FB
09:09 tzimmermann: and there are two platforms that make up their own simple-framebuffer devices
09:10 tzimmermann: coreboot and n64 set up a simple-framebuffer
09:10 javierm: having a efidrm and vesadrm would mean more drivers to enable, bugfix, etc for distros
09:11 tzimmermann: right, code sharing is the one point that i have not yet found a 'nice' solution
09:11 javierm: tzimmermann: maybe what we can do is add a Kconfig symbol CONFIG_SYSFB_MODESET or something like that
09:11 javierm: if a distro enables that, then simpledrm only matches OF and not EFI or VESA
09:11 tzimmermann: TBH, i don't expect efidrm or vesadrm to do any modesetting
09:11 javierm: tzimmermann: hmm, then I don't see what value adds over simpledrm tbh
09:11 tzimmermann: simpledrm has to match platform devices
09:12 tzimmermann: but that's unrelated to efidrm
09:12 tzimmermann: the question is what sysfb creates from screen_info
09:13 tzimmermann: that added value is palette support for vesa (vesafb can do that) and possible edid support
09:13 tzimmermann: adding this into simpledrm feels like a burden to me
09:14 tzimmermann: and quite a bit more than what simple-framebuffer is supposed to do
09:14 javierm: tzimmermann: yes, I agree with that. I wouldn't add it to simpledrm
09:14 javierm: but having a separate vesadrm just for that and make simpledrm not support vesa anymore feels like a burden for distros too
09:15 tzimmermann: they don't have to enable it :)
09:15 tzimmermann: but that's why i said that code sharing is an issue
09:16 tzimmermann: simpledrm, ofdrm and possibly others are very similar. but each is slightly special
09:16 tzimmermann: my previous attempt to make 'firmware FB' helpers was not useful
09:16 javierm: tzimmermann: yes, but if they don't enable vesadrm and sysfb doesn't create a FB from a screen_info for VESA anymore, then won't have early fb anymore
09:17 javierm: hence my comment on {vesa,efi}drm complicating the device -> driver matching
09:17 tzimmermann: CONFiG_SYSFB_SIMPLEFB would remain as-is
09:17 tzimmermann: activate it and you won't see vesadrm/efidrm at all
09:18 javierm: tzimmermann: oh, I see. And OF doesn't use sysfb but the "simple-framebuffer" is registered by OF
09:18 tzimmermann: disable it and simpledrm only serves these simple-framebuffer OF nodes
09:18 javierm: so a distro could just disable CONFIG_SYSFB_SIMPLEFB and enable CONFIG_DRM_EFIDRM and CONFIG_DRM_VESADRM
09:18 tzimmermann: right
09:18 javierm: tzimmermann: go it. You are correct, sorry for the noise then
09:18 tzimmermann: no problem
09:20 tzimmermann: ideally, we would have each driver extract the firmware config from simplefb_platform_data or screen_info and through it into some kind of generic code. but then, each case is slightly different
09:20 tzimmermann: s/through/throw
09:21 tzimmermann: so there's no generic set of helpers for firmware fraembuffers
09:21 tzimmermann: javierm, i'll further look into the issue and maybe post something as RFC
09:22 tzimmermann: some background: i've recently investigated edid support for simpledrm
09:23 tzimmermann: and i've booted bochs (qemu) with 8-bit palette mode. my test system loaded to vesafb, because simpledrm didn't support palettes
15:14 user12345: hi
15:17 user12345: I ran into a problem running linux drm tests and i really appreciate it if you can help. i'm trying to improve drm drivers memory usage and
15:17 user12345: for running tests on them i tried to follow documentation for running tests on gitlab.freedesk.org
15:17 user12345: but when i try to fork linux and create tree in first step i get 409 status code erro
15:18 user12345: with following message "Limit reached You cannot create projects in your personal namespace. Contact your GitLab administrator."
18:57 DemiMarie: Do Intel and AMD GPUs clear registers before executing a shader? I saw that at least some Apple, Nvidia, and Qualcomm GPUs don’t: https://arxiv.org/pdf/2401.08881.pdf
20:03 robclark: DemiMarie: that is _almost_ the same thing as LL .. qcom with newer fw (not rolled out to all devices yet) clears state when switching between processes.. and I believe intel has some similar state clearing. AMD it is a bit more problematic because you can have things from different processes running simultaneously
20:04 DemiMarie: robclark: Thanks! How does AMD prevent one shader from *writing* to another shader's locals/registers? I'm wondering why they could not use the same mechanism here.
20:13 glehmann: each shader wave allocates registers, and it can only write those
20:18 DemiMarie: I see! Why is it not possible to clear registers between execution of two shaders, if there are other shaders running in parallel? Is it because the clearing mechanism clears everything, as opposed to clearing only state for a specific context?
20:20 iive: allocating separate registers would isolate waves from each other, but what happens with register content when the waves are done and register are freed?
20:21 iive: would a new allocation clear them, or could there be remaining old values?
20:22 iive: I do remember some bugs by shaders that relied unused registers are zeroed.
20:34 robclark: DemiMarie: I can't speak for amd in specific, but I'd guess it is still a bit like adreno in that some regs are used for input and/or output values
20:35 robclark: and extra clearing between each shader is an overhead
20:36 robclark: IIRC amd was thinking about a way to not let untrusted things run in parallel
20:36 DemiMarie: did that go anywhere?
20:37 DemiMarie: Clearing all state might well be a cheap broadcast operation that can be done by a broadcast signal.
20:39 robclark: I've not followed it too closely but IIRC they were discussing it for a better long-term soln for the LL thing... it might not be cheap, but it's only done and ctx-switch granularity instead of per draw