06:50demarchi: sima: it looks like someone pushed this branch by mistake ? drm-tip/drm-misc-next. This is throwing off dim create-workdir as now we have 2 remotes with the same branch name
06:51sima: demarchi, yeah no idea how that happened since dim should never
06:52sima: demarchi, I guess just force delete it? I got to run some errands rn, but can do it when I'm back if you want me to do it
06:52demarchi: I think I can workaround that in dim with my latest updates... but probably better to nuke that
06:52sima: nah this looks very wrong
06:52demarchi: ok, lemme nuke it then
06:52sima: not even sure this can happen without bypassing dim
06:53sima: but looks like it's half a year old so probably no one remembers what happened :-/
06:53demarchi: To ssh://git.freedesktop.org/git/drm-tip
06:53demarchi: ! [remote rejected] drm-misc-next (pre-receive hook declined)
06:53demarchi: error: failed to push some refs to 'ssh://git.freedesktop.org/git/drm-tip'
06:54demarchi: humn... I think there's a magic switch
06:54demarchi: ok... deleted
07:29mareko: how many physical machines does the Mesa CI have?
07:30mareko: globally
07:55luc: i wonder if GL_STENCIL_INDEX is skipped over on purpose when i read the line https://elixir.bootlin.com/mesa/mesa-23.3.2/source/src/mesa/state_tracker/st_cb_readpixels.c#L447
08:00luc: as the comment above explains, if there is an incomplete stencil blit implementation in some drivers, GL_STENCIL_INDEX should also fallback to slow path, shouldn't it?
08:28mareko: mupuf: why did you unassign the MR?
08:29mupuf: mareko: because I thought it still disabled the CI
08:29mupuf: I am looking at it now
08:29mupuf: and it doesn't so, I'll reassign
08:29mareko: I see
08:30mupuf: mareko: no review though?
08:30mareko: mupuf: it's reviewed except for the bump
08:30mupuf: ack
08:31mupuf: mareko: reassigned
08:31mupuf: sorry for the noise
10:26jani: agd5f: the amdgpu Makefile has "# Need this to avoid recursive variable evaluation issues" - do you have any recollection what exactly that's all about?
11:29karolherbst: anybody caring about how we link libgalliumvl? I've opened an MR and wanted to let people know if we want to do it that way or not... https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26680
11:31karolherbst: but also needed to fix some linking issue in some cases
12:12pq: abhinav__, I see you tried to ask me something on Dec 19 about UAPI structs, can you ask again if there is still a question? Or will I find the question in my email?
12:34pq: any1, no, I don't know or recall why the HDMI color model UAPI work stopped.
12:35any1: pq: Ok. I revived it (partially) anyway.
12:36pq: I don't even remember commenting on it, though I can well believe I did. :-)
12:40pq: maybe lack of userspace to prove the UAPI?
12:48mairacanal: Is it possible to allocate a shmem buffer contiguously for a arbitrary page size? Currently, when I check shmem_obj->sgt, my objs are contiguosly allocated by 4096 (PAGE_SIZE)
12:54emersion: any1: ty for reviving that thread!
12:54emersion: any1: i think something discussed was that the "preferred" design was not super flexible when it comes to picking the fallback?
12:55emersion: one of the TODO items from the previous series was to change it to "force"
12:56emersion: any1: also the point of "active" was to figure out what "auto" picked, iirc
13:27any1: emersion: Hmm, yeah, it makes sense with regard to auto to have the "actual". Daniel Vetter said that there were some concurrency issues with how it's implemented. I was thinking of dropping the whole thing, but it would be preferable to get some feedback with "auto".
14:31dolphin: airlied, sima: I've prepared a drm-intel-next-fixes pull but waiting for CI results, will send it anyway tomorrow
14:52agd5f: jani, not sure. I'll ask Hamza
15:06jani: agd5f: thanks!
16:23agd5f: jani, Hamza said if you try something like `subdir-ccflags-y += $call cc-option, -Wunused-but-set-variable`, it will refuse to eval with certain build configs
16:23jani: agd5f: that's odd. I don't think we've faced that in i915
16:24jani: agd5f: I'm asking because I'm preparing a new version of https://lore.kernel.org/r/20231129181219.1237887-1-jani.nikula@intel.com
16:34agd5f: jani, He said if you try building just amdgpu.ko (i.e. $ make M=drivers/gpu/drm/amd/amdgpu), you should see the following error:
16:34agd5f: ```
16:34agd5f: scripts/Makefile.lib:10: *** Recursive variable 'KBUILD_CFLAGS' references itself (eventually). Stop.
16:34agd5f: make: *** [Makefile:1755: modules] Error 2
16:34agd5f: ```
16:36jani: agd5f: isn't M= for external modules? If I want to build just i915.ko, I'll do make drivers/gpu/drm/i915/i915.ko
16:42agd5f: Is it not fair game for in tree too? I dunno.
16:43jani: not sure
16:50abhinav__: pq no worries, I got it answered on another channel . thanks
17:17mattst88: > Alyssa Rosenzweig @alyssa
17:17mattst88: > Left project
17:17mattst88: ???
17:18mattst88: left the IRC channel around the same time
17:25zf: I have a question about driver-side performance optimizations, specifically in iris I think. I'm trying to update a uniform buffer, and I find that creating a small BO and updating the whole thing with glBufferSubData() is performing better than either suballocating slices from a larger BO [and using glBufferSubData() / glBindBufferRange()] or similarly suballocating but rebinding new slices which I know are unused by the GPU. I'd like to know if this
17:25zf: is expected, and if so why?
17:45MrCooper: agd5f: a while ago I submitted a patch for an issue with M=drivers/gpu/drm/, and Masahiro Yamada (one of the build system maintainers) responded: "M= is intended for building external modules. I do not recommend it for in-tree drivers."
17:59javierm: MrCooper: really? first time I heard that
18:00javierm: I use M= all the time for in-kernel modules
18:00MrCooper: yeah, that was a few years ago, I'd been using it for a long time before as well
18:01demarchi: MrCooper: javierm I use it for a long time too
18:02MrCooper: enjoy it while it lasts :)
18:02javierm: hahaha
18:03demarchi: I remember having issues with specifying the .ko directly when using "dirty" builds... if there were changes in drm it would fail and I'd have to build drm first, or something like that
18:03javierm: jani: even when drivers/gpu/drm/i915/i915.ko works, M= is very handy when you want to build all the modules of a given subsystem, e.g: M=drivers/gpu/drm/
18:03demarchi: while with M= it didn't have that issue
19:36jani: demarchi: mmh I think I've seen issues with modpost with specifying .ko directly