11:35 mareko: I have a pretty solid idea now about how to lower any vec4 indirect IO such that each component is a separate scalar array and elements are only 1 component apart, and I know how to shrink varying arrays and compact them, as well as how to get to component-level addressing and lower the high_16bits thing
11:47 pinchartl: sima: Dave has acked https://lore.kernel.org/dri-devel/20260407104951.1781047-1-laurent.pinchart+renesas@ideasonboard.com/
11:48 pinchartl: but tomba told me he's not comfortable merging that through drm-misc
11:48 pinchartl: as he thinks it's a bit of a stretch of drm-misc's mission statement
11:48 pinchartl: tomba: ^^
11:48 pinchartl: should it go through drm-misc, or should I send a PR for drm ?
11:48 sima: https://drm.pages.freedesktop.org/maintainer-tools/repositories/drm-misc.html
11:48 sima: not sure which mission statement tomba is referencing, but this one is pretty clear that it's all included
11:49 pinchartl: thank you
11:49 tzimmermann: pinchartl, tomba, this series looks perfectly fine for drm-misc-next
11:49 sima: get_maintainers.pl concurs
11:50 pinchartl: thank you
11:50 pinchartl: sorry for the noise
11:50 sima: better check than clean up a mess afterwards, so no worries
11:52 tomba: I consider myself a maintainer for the pieces I'm marked as a maintainer. So I'm happy to merge changes to those parts. I guess merging to other parts is fine too when I'm working on the relevant content (i.e. if I'm the author of the patch). But merging other people's patches to core DRM parts, when I'm not in the development loop at all... That feels a bit of a stretch. So I didn't mean it couldn't be merged via drm-misc. I meant I
11:52 tomba: don't think I'm supposed to push them.
11:52 sima: ah yeah, that seems entirely reasonable
12:45 mahkoh: When RADV_DEBUG=zerovram is used, does radv wait for the zeroing to complete before it returns the memory to the application?
13:02 glehmann: the kernel zeros the vram and applications will not be able to observe the pre zero content
13:02 glehmann: at least if the kernel is working correctly
13:06 mahkoh: The zeroing creates a fence that is imported with DMA_RESV_USAGE_KERNEL. Is that flag what causes subsequent reads/writes to block even if those reads/writes don't use implicit sync?
13:07 mahkoh: The docs seem to imply this: Drivers *always* must wait for those fences before accessing the resource protected by the dma_resv object.
13:08 CounterPillow: vsyrjala: when you get the time, I'd appreciate a review on the changes you requested in https://lore.kernel.org/dri-devel/20260422-hot-plug-passup-v9-0-aef804255986@collabora.com/ and the i915-specific bits in https://lore.kernel.org/dri-devel/20260423-color-format-v14-0-449a419ccbd4@collabora.com/ Thanks :)
13:09 zmike: this latest gitlab update is killing me
13:10 zmike: why tf does the sidebar scroll
13:10 CounterPillow: zmike: I'm sure it's killing whatever poor CPU has to run it as well, so you're in good company
13:10 zmike: and only enough to make the reviewers line look like assignees
13:14 CounterPillow: @ any AMD peeps in here (e.g. hwentlan__ ), I'd also appreciate a review on the two amdgpu patches in color format v14 <https://lore.kernel.org/dri-devel/20260423-color-format-v14-0-449a419ccbd4@collabora.com/>, it's been 14 revisions with no feedback on those so far and I'd rather not have to drop them in order to get this slow-cooked stew of a series served.
13:31 MrCooper: zmike: the reviewer / assignee confusion is older than the latest update
13:33 zmike: the latest update was in 2024 wasn't it?
13:34 zmike: it's only 2025 now
13:34 zmike: January
13:34 mareko: yeah 2025
13:34 zmike: ok good
13:34 zmike: thought I was losing it
13:34 zmike: heh
13:34 zmike: heheh
13:34 zmike: hahahahahahah
13:34 mareko: not 2025?
13:35 MrCooper: there are updates all the time
13:35 cssushiman: Random question: If I decide to make a compositor, should I add support for YUV and/or RGB color channels wider than 8 bits?
13:36 MrCooper: pretty sure there's rarely more than a month between them
13:36 cssushiman: or is it unnecessary?
13:37 MrCooper: the TL;DR: is yes, you should, definitely 10 bpc RGB formats
13:38 MrCooper: hmm, actually are you asking about formats exposed to clients, and/or for the compositor's output? (my response applies to both though :)
13:38 cssushiman: I'm also asking about both
13:46 cssushiman: Thanks for the answer. :-)
13:51 pinchartl: tzimmermann: tomba: sima: could someone merge the patch ? I don't mind who does it :-)
13:56 tomba: tzimmermann: sima: as we're still discussing this... can you clarify what my role as a "can push to drm-misc"-person is? my understanding is that I'm the maintainer of a few specific drivers, to which I can push patches via drm-misc. so I will never push e.g. drm_fourcc.h, except perhaps when a drm_fourcc.h change is part of a driver series, and the change is acked by a drm_fourcc.h maintainer. or am I overcomplicating this and I
13:56 tomba: should just push Laurent's patches? =)
13:59 tzimmermann: tomba, maybe you should just push them and see what happens
14:00 pinchartl: tomba: I'll take the blame for consequences
14:00 tzimmermann: you have the ack from dave airlie. what else do you need?
14:10 tomba: tzimmermann: so anything that's maintained via drm-misc is ok, even if you're not a maintainer for that piece, as long as a maintainer for that piece has acked it?
14:14 sima: yeah, that sounds pretty good rule of thumb
14:15 sima: usually for regular contributors we just hand out commit rights so they can push themselves, but pinchartl is special
14:16 sima: mostly when you push for others there's some kind of mentor/reviewer relationship going on until they've graduated to commit rights and can do it themselves
14:18 tomba: sima: indeed. try to bear with my protégé pinchartl. I'll try to teach him git so that he could get the commit rights and stop bugging me...
14:19 tomba: pinchartl: pushed! =)
14:28 pinchartl: tomba: appreciated
14:52 pinchartl: sima: my mom says I'm special
15:21 CounterPillow:resists the temptation of a "your mom" joke, knowing that this is a serious channel for serious people to have serious discussions in
19:46 BlueMatt: okay. i have a whole conservative patchset for Large GRF on Xe2 that is a nice speedup on some (few, but some!) of the tiny set of shaders I have, but I have like 3 versions of the last commit and a knob to tune. what's the best way to go about that? Should I open a WIP MR and hope someone has the spare time to run it through their fossil-db (anyone interested? :) or open an issue and link the WIP branch? I asked the aforementioned discord user
19:46 BlueMatt: but no response yet (just now tho).
19:52 dery: hi!
19:53 dery: is there a way to instantiate a "fake" video card so that I can debug device selection?
19:55 pendingchaos: several drivers support drm-shim
19:55 pendingchaos: for example, with radv you can LD_PRELOAD=libamdgpu_noop_drm_shim.so AMDGPU_GPU_ID=gfx1201
19:55 dery: nice, thank you!
19:55 dery: I suppose that this won't actually render though, right?
19:56 pendingchaos: no, it won't
19:56 dery: that should still do
19:56 pendingchaos: no idea if it would crash or just do nothing
19:56 dery: well I just need to figure out why my old device selection experiments didn't work. Hopefully it initializes OpenGL at least
19:56 pendingchaos: you should be able to compile shaders and look at the device info fine though
19:57 dery: my last experiments with egl_ext_explicit_device resulted in enumeration, egl display creation but still when querying opengl it returned whatever was the default gpu
20:00 rodrigovivi: airlied: sima: please chyme in: https://lore.kernel.org/dri-devel/20260504193420.1232842-3-badal.nilawar@intel.com/
20:03 sima: rodrigovivi, I have no idea what all the abbreviations in there mean, but I think with the only other network/drm shared driver we went with option two
20:03 sima: might want to chat with ogabbay (if he's around anywhere), since he has some actual clue
20:04 sima: I think the network people do not like networking drivers outsider of drivers/net
20:04 sima: *outside
21:02 cmarcelo: BlueMatt: I can try to run numbers later this week if you don't get access in the next days, but in the long run you want to get access to the database that was discussed before. you can still run on the public fossils, at least to get your setup good to go when you get access (shader-db repo has some fossils, and the fossil_replay an report_fossil scripts).
21:03 cmarcelo: (oh it seems you already handled the reports :)
21:03 cmarcelo: BlueMatt: post the branch somewhere and let me know, i can run the numbers