07:03 thellstrom: mlankhorst:, tzimmermann: drm-misc-next has a build breakage in the xe driver. There was a manual fixup patch that got lost in the backmerge.
08:53 tzimmermann: thellstrom, i see. do you have a link to the fixup patch?
08:54 tzimmermann: thellstrom, https://cgit.freedesktop.org/drm-tip/tree/fixups/drm-misc-next.patch?h=rerere-cache&id=c39c6e3d74203820ef630884a5323237696bd36c ?
09:12 thellstrom: tzimmermann, yes that looks like the right one. I wonder whether we should enable xe in the drm-rerere defconfigs?
09:16 tzimmermann: thellstrom, are drm-rerere defconfigs used for testing? then it would make sense to enable the driver
09:18 sima: tzimmermann, I thought it was just me using them for build-testing ...
09:19 sima: should do this on gitlab or something and automatically enable all drm drivers, but never got around to that yet
09:19 thellstrom: tzimmerman, not sure what they are used for actually, but at least we could point our developers to those for build testing....
09:22 tzimmermann: sima, 'just you' is still one person using them for testing. i guess it counts then :)
09:24 mripard: sima: for the record, I use them too :)
09:25 sima: mripard, yay!
09:26 tzimmermann: thellstrom, mripard, i see if i can fix the build
13:03 tzimmermann: thellstrom, sima, mripard, drm-misc-next is now at v6.8-rc3. the backmerge includes the fix for xe. i've removed the fixup from drm-rerere. AFAICT drm-misc-next and drm-tip build now
14:30 demarchi: sima: not sure if we should or if it's desired, but I'm trying to generalize the way we maintain our config in xe side so we could in theory have a single build for xe and i915 in our CI: https://gitlab.freedesktop.org/drm/xe/ci/-/merge_requests/37
14:31 demarchi: I'm trying to maintain the required options for each driver on .fragment files and use merge_config to glue everything together
14:32 demarchi: if we extend that to other drivers, each of them could have a .fragment with their required configs
14:34 demarchi: that could be just an idea for a different gitlab repo instead of extending it
15:33 sima: demarchi, yeah I think that's roughly my idea too
15:33 sima: well maybe with some trickery that tries to enable all drivers and then complains if across a set of platforms/config fragments it cannot enable all drivers automatically
15:33 sima: so you can adjust the fragments accordingly
15:34 sima: thus far arm32, arm64 and x86_64 is enough to cover everything in drm
15:36 javierm: sima: I think there are a couple of drivers that are only for mips
15:36 sima: javierm, oh we have those by now?
15:37 javierm: git grep "depends on" -- drivers/gpu/drm/ | grep MIPS
15:37 javierm: drivers/gpu/drm/ingenic/Kconfig: depends on MIPS || COMPILE_TEST
15:37 javierm: drivers/gpu/drm/loongson/Kconfig: depends on LOONGARCH || MIPS || COMPILE_TEST
15:37 sima: oh I guess I have that covered with COMPILE_TEST
15:37 javierm: LOONGARCH too I see :P
15:37 javierm: sima: yeah
16:54 cwabbott: dj-death: why did you end up going the shader variant route for dynamic_rendering_local_read? adding relocations and whatnot just for this one use case to turnip seems like it would be really painful, but is there some reason why remapping the attachments/blend state was even more painful?
16:55 dj-death: cwabbott: dropping render target writes is really not trivial
16:55 dj-death: cwabbott: the only alternative seems to be what radv does
16:56 dj-death: cwabbott: especially if the one you drop is the same message that ends the thread
16:56 cwabbott: ah ok, so it's an intel-specific thing
16:57 dj-death: cwabbott: is it easy for you to change the RT writes in a final binary?
16:57 cwabbott: it's trivial for us, just set the format to 0 and off you go iirc
16:57 dj-death: I see
16:57 dj-death: remapping too?
16:58 cwabbott: well, we'd have to re-emit attachment state
16:58 dj-death: yeah
16:58 dj-death: I wanted to avoid that too
16:58 dj-death: because that requires a flush of the render target cache for us
16:59 dj-death: we have a bit to drop the writes
16:59 cwabbott: yeah, that's not the case for us
16:59 dj-death: I might use that
16:59 dj-death: but it's only Gfx11+
16:59 dj-death: so for SKL/KBL we have to find some other way
17:00 cwabbott: yeah, just seems like the cost/benefit is different because of the HW
17:00 cwabbott: good to know I won't be screwed before starting working on it
17:07 cwabbott: dj-death: you had a branch implementing the rewriting attachments approach at some point, right? did that need any extra common runtime changes?
17:31 dj-death: cwabbott: yeah it's probably still on the khronos gitlab
17:32 dj-death: cwabbott: I think what is in main now should be enough to do it
17:47 cwabbott: dj-death: ook
17:48 cwabbott: btw, how do you handle NULL attachments in dynamic rendering, if it's so hard to drop RT writes
17:48 dj-death: you can add a null surface descriptor in the binding table
17:48 dj-death: then your writes go to /dev/null
17:48 cwabbott: then why couldn't use that for the remapping?
17:49 dj-death: again, render target cache flush
17:49 cwabbott: ah, so really the design is about avoid that
17:49 dj-death: yeah
17:49 cwabbott: it seems a bit weird, because presumably anyone using it is porting from classic renderpasses
17:49 cwabbott: where you'd need to flush it anyway
17:50 dj-death: we didn't use to require this
17:50 dj-death: this was just a workaround on Gfx11+
17:50 dj-death: and that kind of became how the HW works
17:51 dj-death: the other reason for the relocation stuff is that I would like to use that for embedded samplers
17:52 dj-death: that way an identical shader with a different sampler type can just be copied and rewrite some bits in the final binary to use the right sampler
18:06 cwabbott: dj-death: another question, how did you resolve the alpha-to-coverage thing with the shader remapping impl? did you find some way to use a non-zero attachment for the alpha value?
18:40 dj-death: cwabbott: I think our HW can do it on any render target actually
18:40 dj-death: cwabbott: I looked up the PRMs I remember
18:41 dj-death: cwabbott: so that didn't seem to be a problem for us
18:42 cwabbott: hmm ok
19:04 dj-death: cwabbott: also : https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/5499#note_442566
19:05 dj-death: cwabbott: so remapping doesn't matter for that case
20:30 airlied: robclark: you forgot a subject line in that pull req
20:39 robclark: doh
20:42 karolherbst: are there some meson experts here and can one tell me how I can turn an object generated with `include_directories` into a list of absolute paths?
20:43 karolherbst: as strings I mean
22:56 jenatali: Uh, I'm getting a nir_validate failure after nir_opt_dce in a shader from RDR2. That seems... odd
23:18 jenatali: Eh, nevermind, I think I'm misreading this crash