06:53 tzimmermann: sima, do you have comments on the series for supporting arbitrary drm clients? https://patchwork.freedesktop.org/series/137391/
07:27 airlied: nowrep: vcn can't do hevc b-frames can it?
07:34 nowrep: no, only h264
07:35 JEEB: that's the AMD ASIC, right?
07:42 MrCooper: right
07:45 sima: tzimmermann, not really, I'm personally not sure we really need this, but on the other hand a bit more unification won't hurt either long term
07:45 sima: so figured I'm not going to pipe up with a comment
07:45 tzimmermann: sima, ok, no problem
07:46 sima: imo if all the folks involved in getting towards the great new drm-panic/log/vt (which parts in userspace still tbd) thinks it's good, go ahead
08:15 javierm: tzimmermann: TIL about drivers/firmware/google/framebuffer-coreboot.c https://lore.kernel.org/all/ZuCG-DggNThuF4pj@b20ea791c01f/T/#ma7fb65acbc1a56042258adac910992bb225a20d2
08:16 javierm: tzimmermann: I think we discussed before, but I wonder if wouldn't be better to unify all the platform code and just fill a struct screen_info for sysfb to handle the pdev registration
08:16 javierm: IIRC you mentioned that preferred the OF code to keep their own pdev registration
08:17 Kayden: DavidHeidelberg, daniels: thanks for enabling rusticl testing for iris! just caught a nasty bug I was about to introduce with legacy HDC scratch loads for sub-32-bit values
08:18 DavidHeidelberg: Kayden: np, thou it's only in nightly (?)
08:19 Kayden: seems to be on pre-merge
08:19 DavidHeidelberg: oopsie :D my bad.
08:19 javierm: tzimmermann: there's also arch/mips/n64/init.c (which also hardcodes to 0 instead of using PLATFORM_DEVID_AUTO btw)
08:19 tzimmermann: javierm, i'm in a meeting
08:19 javierm: tzimmermann: Ok, sorry
08:27 linusw: Oh haven't used the drm tree and dim since the switch to gitlab, trying to reinitialize the whole environment then and see if that works
09:00 tzimmermann: javierm, i've also looked into this problem today. think we might see something like with DT/OF systems, where the firmware framebuffer is referenced via DT and via the bootloader-provided screen_info. and we can only use it once
09:01 tzimmermann: in the case of OF framebuffers, we explicitly display the sysfb handling if we see a framebuffer. https://elixir.bootlin.com/linux/v6.10.9/source/drivers/of/platform.c#L595
09:02 tzimmermann: i think, we likely need something similar for coreboot
09:05 daniels: DavidHeidelberg, Kayden: tbf, since it’s both useful and reliable, might as well just make it pre?
09:06 Kayden: makes sense to me
09:10 DavidHeidelberg: I'm more than happy.
10:21 javierm: tzimmermann: right. That was the context of the discussion I remembered
10:21 javierm: tzimmermann: oh, it was even a change from me LOL
10:29 javierm: tzimmermann: I'll type a patch then for the Coreboot uses to try
10:59 javierm: tzimmermann: something that confuses me though is who fills the screen_info in this case, because AFAICT from the report they are using Coreboot + SeaBIOS as payload
10:59 javierm: but in this case, a screen_info should only be filled by the x86 early boot code when using a vga= kernel cmdline param
10:59 javierm: at least that's the case on legacy BIOS and UEFI on CSM mode
11:10 tzimmermann: javierm, i only did an an educated guess here. IDK if that's really the problem
11:11 tzimmermann: i have to get coreboot hardware first. maybe i can reproduce it
11:12 javierm: tzimmermann: I'm convinced that you are correct, is just the mechanism of how the framebuffer is provided in both the Coreboot table (seems to be entry LB_TAG_FRAMEBUFFER) and a VGA mode as boot params that I'm unsure
11:13 javierm: I'll also type in the commit message my educated guess and could let the reporters to correct me
11:37 javierm: tzimmermann: patch sent. Written the patch took me 1 min, but looking at Coreboot + SeaBIOS code and the x86 boot code more than 1 hour so that I could write the commit message :)
11:37 javierm: *Write
12:12 tzimmermann: :)
12:50 cwabbott: gfxstrand: I started looking at what it would take to convert turnip to the common pipeline code, and there are a few sticky points
12:51 cwabbott: we'd have to handle the driver_rp thing - which, I guess it should be simple to create a driver op somewhere and then call that to fill out a driver_rp
12:53 cwabbott: but there's something even stickier, which is that when compiling we need to know which input attachments are "real" (i.e. actually point to tile memory if in tiled mode) and which are "fake" (i.e. are never written earlier in the render pass)
12:54 cwabbott: right now this is done entirely sideband, when filling out driver_rp we also fill out a bitmask, then it flows into the FS key and into nir_lower_input_attachments
12:55 cwabbott: with DRLR this would be part of the input attachment mapping state, I think
12:56 cwabbott: but we have to handle DRLR a bit differently in turnip due to the possibility of depth/stencil not having an index, so the codepaths don't exactly line up
12:57 cwabbott: I'm not sure exactly how to proceed, the only thing i can think of is a very ugly turnip-specific sideband thing in the driver_rp
14:41 rodrigovivi: airlied: sima: I just noticed that drm/drm-fixes is still in v6.11-rc6 .... so a dim pull-request of drm-xe-fixes was trying to take more stuff from v6.11-rc7 to drm/drm-fixes... I guess at this point I should just move drm-xe-fixes back to -rc6?
14:41 sima: rodrigovivi, fixed
14:42 sima: please don't rebase onto -rc6
14:42 rodrigovivi: that was quick! thank you a lot
17:08 jenatali: Is there some way to merge a driconf-only change without having to run all of CI?
17:11 sghuge: any idea how to decode steam mini dump files?
17:11 zmike: nope
17:11 zmike: jenatali: sure would be nice though
17:11 jenatali: Yeah...
17:11 jenatali: I don't feel good wasting so much time and compute power for a change that's literally untested by all of that work
17:12 K900: zmike sorry for the snipe again but can I get an official +1 on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31074