00:27 lumag: robclark, ack, thanks
07:05 dj-death: any interest in having another source hash in shader_info ?
07:06 dj-death: using xxhash.h
07:20 MrCooper: emersion sima: FWIW, in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_1962058 I argued that the fence materializing when the UMF signals should be fine for Wayland compositors (better ignore the musings about pollable drm_syncobj fds though :)
07:55 tomeu: anybody knows why valgrind may fail to break at watchpoints to memory that my kernel driver mmapped and I marked with VALGRIND_MALLOCLIKE_BLOCK ?
08:04 pq: zzoon[m], yes, I know, that's what I've been trying to explain. I gave you a link to the GNOME Mutter MR that lists some approaches.
08:05 pq: zzoon[m], sorry, I confused nicks starting with zz.
08:05 pq: zzxyb[m], yes, I know, that's what I've been trying to explain. I gave you a link to the GNOME Mutter MR that lists some approaches.
08:05 pq: zzxyb[m], but no matter what you do, you still do need to handle format modifiers correctly.
08:07 javierm: tzimmermann: hi, I reviewed the first patches from your screen_info series that I think are not controversial and you could just land
08:07 tzimmermann: javierm, yeah saw it. thanks a lot
08:07 javierm: tzimmermann: I skipped the ones that there are on-going conversations with arnd
08:07 tzimmermann: i'll send out an updated patchset soon
08:08 javierm: tzimmermann: cool, thanks
08:17 karolherbst: gerddie: any plans to support PIPE_CAP_SHAREABLE_SHADERS in r600?
08:33 karolherbst: it's kinda annoying me having to support drivers not supporting it, not sure how hard it would be to support it in r600
08:45 karolherbst: jenatali: any idea where we could document having to rebuilt mesa when CLANG_RESOURCE_DIR changes for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23981?
10:33 akselmo: Hi, i would love to help working on drivers like amdgpu and such. I wouldnt mind starting with simple bug fixes (if there is such thing as simple) or anything like so.
10:34 akselmo: Any tips how to get started? I have been afraid to ask before but im super interested in this even i dont know much lol
10:34 lumag: sima, robclark suggested pinging you regarding https://patchwork.freedesktop.org/patch/527953/?series=115283&rev=2.
10:39 javierm: akselmo: have you seen https://docs.kernel.org/gpu/introduction.html#external-references ?
10:39 emersion: akselmo: https://dri.freedesktop.org/docs/drm/gpu/todo.html
10:40 akselmo: I havent, thank you both
10:40 akselmo: will give them a read at home :)
10:41 akselmo: will also read kernel newbies stuff since im pretty new to linux kernel in general, i just have been very interested in graphics side
10:41 akselmo: hopefully at some point i can help with bugfixing and such
10:44 sima: lumag, maybe extend the kerneldoc to add links for the respective other variant
10:44 sima: imo links make docs and code better to navigate for these
10:45 sima: lumag, with that a-b: me
10:46 sima: lumag, I guess plan B would be to change the current func to treat min/max_scale == 0 as "no limit"
10:46 sima: maybe a notch more flexible, but either works I guess
10:49 lumag: sima, ack, thanks for the comment. I'll update docs when posting next iteration.
10:50 lumag: I didn't want to have 'special' values like that.
10:50 lumag: It usually does more harm IMO
12:07 jenatali: karolherbst: no idea
12:42 MrCooper: I wish Khronos would stop modifying Git tags
12:48 jenatali: Oof
13:02 pq: old habits from Subversion maybe? :-)
13:30 eric_engestrom: yeah, and also deleting "old" tags (which breaks CI and similar systems everywhere for absolutely no reason)
13:32 eric_engestrom: "for absolutely no reason" was supposed to be outside the parentheses, but you get it
13:32 psykose: been hit by that multiple times by now..
13:32 psykose: last year they also missed half the sdk- tags at once (i.e. half the repos with sdk- tag the other only with the 202* one)
14:06 MrCooper: ishitatsuyuki: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23878 broke piglit ext_external_objects-vk-vert-buf-reuse here: ext_external_objects-vk-vert-buf-reuse: ../src/vulkan/runtime/vk_pipeline_cache.c:667: vk_pipeline_cache_destroy: Assertion `cache->object_cache->entries == 0' failed.
14:06 ishitatsuyuki: MrCooper: which runner?
14:07 ishitatsuyuki: in any case, if something it's hitting it, it's leaking pipelines
14:07 MrCooper: piglit's
14:07 MrCooper: sounds like it can't be an assertion
14:07 ishitatsuyuki: I mean which job actually
14:08 ishitatsuyuki: it's not a problem to fail tests if something is blatantly violating VUIDs
14:08 MrCooper: I hit it with a local script, not a CI job
14:08 ishitatsuyuki: I suggest adding it to the fail list
14:09 MrCooper: shouldn't the test be fixed?
14:09 ishitatsuyuki: that too
14:09 MrCooper: it doesn't need to be added to any fail list, or you couldn't have merged that MR :)
14:10 ishitatsuyuki: well, not all configurations are tested pre-merge
14:10 MrCooper: gotcha
15:35 chloekek: ClearBufferfv does not seem to clear depth attachments that are textures, only those that are renderbuffers, but I can't find such discrimination in the OpenGL spec.
15:36 chloekek: Should I report this as a bug or is this something I’m misunderstanding?
15:48 chloekek: Nevermind I’m a fool
17:50 dviola: MrCooper: hello, do you remember what we did to make Xorg pick up system wide radeonsi.so here: https://bugs.freedesktop.org/show_bug.cgi?id=110214#c32 -- was it just changing paths in /etc/ld.so.conf?
17:50 dviola: radeonsi_dri.so*
17:53 dviola: I believe I'm going to have to do something similar for virtio_gpu_dri.so, not sure
18:07 dviola: I'm getting some funny results with Firefox's built-in PDF reader under virtio/virgl (QEMU), works fine on my host with radeonsi: http://0x0.st/H11L.png
18:07 dviola: the fonts look all messed up
18:08 dviola: I'm not sure it's virtio though, I might be blaming the wrong thing
21:00 DavidHeidelberg[m]: zmike: huge drop in fps w/ zink on intel: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7144#note_1989114
21:01 zmike: DavidHeidelberg[m]: ?
21:01 DavidHeidelberg[m]: Well, 2 fps to 1 fps, but still
21:01 zmike: that's a618
21:01 zmike: turnip
21:01 zmike: and imo that trace shouldn't even be running on perf traces cuz 2 fps is pointless
21:01 DavidHeidelberg[m]: Oops, I'm blind. Yes
21:02 DavidHeidelberg[m]: I think it's saved as float but represented here as int. gallo will know more
21:02 zmike: ...you mean like it's really 2.4fps? 🤕
21:05 ccr: 2 fps ought to be enough for everyone - you can even share with one friend and still have 1 fps.
21:07 jannau: the difference between 2 and 1 fps could be factor 4 or meaningless
22:03 DavidHeidelberg[m]: Yes :D