00:12 jekstrand: Ugh... Getting bitten by the way the isaspec decoder builds.
00:20 alyssa: danvet: nod ok
00:21 alyssa: FLHerne: I really like your summary of a-b vs r-b, yeah
00:22 alyssa: Kayden: "acks are mostly only meaningful by someone seen as a kind of authority on the topic"
00:22 jekstrand: isaspec/decode.c really needs to be a C++ template.
00:22 jekstrand: Yes, I just said that.
00:22 alyssa: not just authority but also stakeholders
00:23 alyssa: e.g. I may indeed care if a customer acks my patch ("this works for us too"), of course tested-by is also good for that
00:23 jekstrand: Maybe I'll just do that....
00:23 alyssa: bl4ckb0ne: Tested-by might be more appropriate for a bugfix for your bug
00:24 jekstrand: Yeah, if you're not in a position to review but you've verified it fixes a bug, Tested-by is the right tab
00:24 jekstrand: *tag
00:46 bl4ckb0ne: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20473 patch in question
01:47 Lynne:visibly emits hate towards khronos
01:47 Lynne: they could've made VkImageUsageFlags a subset of VkFormatFeatureFlagBits2 with the same values
02:17 alyssa: Lynne: you say to a channel full of Khronos members who all just smile enigmatically
02:30 Lynne: they can try to intimidate me, I'm not afraid, I'm confident I can take on any of them in q3dm5
02:34 HdkR: LUTs on LUTs on LUTs on LUTs
02:37 tarceri: "libGL error: did not find extension DRI_Mesa version 1"
02:38 tarceri: never seen this one before
02:46 mareko: tarceri: libGL and libgallium_dri should be from the same Mesa commit
02:47 mareko: there is no stable interface between the two anymore
02:50 alyssa: mareko: I used to `scp` libgallium_dri around and LIBGL_DRIVERS_PATH=
02:50 alyssa: for dev'ing on-device `meson devenv` is easier and faster than that
02:51 alyssa: but for cross building (fast desktop building for slow mobile boards) that doesn't work anymore
02:51 DemiMarie: Bad news on i915: it appears to be a hardware problem.
02:51 alyssa: IDK if there's a good solution for that, I guess scp libGL too and LD_LIBRARY_PATH
02:52 tarceri: It seemed to be happening with the default fedora mesa build, but will double check
03:34 mareko: alyssa: glvnd
16:20 MrCooper: pendingchaos pepp: it's bin/gl-1.0-no-op-paths
16:21 MrCooper: specifically, "Polygon Stipple set to fail mode"
16:25 MrCooper: that enables GL_POLYGON_STIPPLE with an all-0s stipple pattern, so it discards all fragments
16:58 q4a: eric_engestrom: Hi. Are you maintaining https://github.com/Mesa3D/mesa ? It was not updated for a while and I like github's search. Can you check and fix it?
17:02 dcz_: can eglMakeCurrent be used in a different thread than where the context was created?
17:04 HdkR: yes
17:05 HdkR: Infact it is one of the best ways to make shared contexts. Create a pool of contexts on one thread and allocate to shared threads as needed.
17:06 HdkR: Just don't do it often, as it is costly.
17:06 dcz_: okay, then I'm at a loss :( I create 2 contexts, and I try to use them, switching between them before a bunch of calls. Then I get a system crash because of corrupted file system or some other crap
17:08 dcz_: the etnaviv driver seems very broken regarding kernel memory corruption
17:09 dcz_: the worst part is that I can't even track it down because the corruption doesn't make itself immediately known
17:10 HdkR: And you're making sure to unbind the previous context first by releasing it? Something like `eglMakeCurrent(dpy, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT)`?
17:11 dcz_:immediately checks that
17:11 HdkR: `If context is current to some other thread, or if either draw or read are bound to contexts in another thread, an EGL_BAD_ACCESS error is generated.`
17:11 HdkR: Might be good to enable some logging like KHR_debug or LIBGL_DEBUG
17:11 dcz_: at least that is definitely not working
17:12 HdkR: Shared contexts are tricky and can very easily end up with API abuse that some drivers just work with :)
17:13 dcz_: the Intel driver played along some stuff which I later discovered was no good, so I can confirm
17:14 HdkR: I always ran in to the issue that containers like FBOs can't be shared.
17:16 dcz_: I created the contexts in order to hold the buffer handles and I keep them together, so that should be fine
17:19 HdkR: Maybe valgrind/tsan/asan can find some driver bugs, it's not like shared contexts are heavily abused left and right
17:22 dcz_: the worst problem is the random memory corruption, but that's coming either from the kernel or the GPU's DMA engine, and I'm not aware of anything that could track that
17:23 dcz_: if it was userspace only, I wouldn't be whining so hard :P
17:24 HdkR: Ideally userspace will be corrupting some data sent to the GPU which userspace tooling can pick up
17:26 dcz_: I'll try that once I get more desperate. Hopefully releasing contexts lets me move on
18:55 Siddh[m]: Hi, can anyone review https://lore.kernel.org/lkml/cover.1672078853.git.code@siddh.me/ ? I guess I sent them while people were on a break so it got buried.
18:58 RhineDevil: Having problems with ffmpeg using vaapi reencoding on Radeon HD 8210, this is the log output: https://paste.debian.net/hidden/3b7b6761/
18:58 RhineDevil: According to ffmpeg guys it should work and the driver is buggy
18:59 RhineDevil: Command was ffmpeg -vaapi_device /dev/dri/renderD128 -i "$1" -c copy -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 18 "$2"
18:59 RhineDevil: As you can see it was trying to do software decoding on hevc and then pass the data on VAAPI hardware encoding
19:05 eric_engestrom: q4a: that's just a mirror, the repo we work on is https://gitlab.freedesktop.org/mesa/mesa
19:05 eric_engestrom: q4a: this mirror is kept in sync using a script and it looks like that script stopped working properly around christmas and nobody had noticed yet; thanks for reporting that!
19:08 q4a: I know, that it's mirror. Thanks
19:08 alyssa: eric_engestrom: is that mirror even kosher to maintain in the copilot era...
19:09 eric_engestrom: alyssa: fair... :/
19:11 eric_engestrom: if you want to raise that discussion, feel free to send an email on the ML, but I don't have the energy for it (and I tend to think the battle is already lost whatever we do now, so meh)
19:21 alyssa: eric_engestrom: same
19:23 alatiera: DavidHeidelberg[m] are the woindows runners working okay so far with the new dns?
19:24 DavidHeidelberg[m]: alatiera: no idea :) we'll see failed jobs after midnight :)
19:24 alatiera: ahahaha
19:24 alatiera: do let me know
19:28 alyssa:debates adding the lint into meson.build and seeing who complains
19:35 bl4ckb0ne: what was the goal of the github mirror?
19:50 jenatali: alatiera: They've been working well for me so far
19:53 alatiera: jenatali awesome, thanks
19:53 alatiera: feel free to poke me the moment they inevitably explode again
19:55 jenatali: Don't worry, I will :P
20:12 zmike: jenatali: does d3d12 handle depth mode L/A/I yet?
20:12 jenatali: L/A/I?
20:12 zmike: luminance/alpha/intensity
20:13 zmike: I don't see any code for it and I'm assuming d3d12 doesn't handle it
20:13 jenatali: Yeah D3D12 doesn't have those formats
20:13 zmike: it's not formats
20:13 jenatali: There's a little bit of code for them just creating swizzles for sampler views, but I'm not sure what you mean by "depth mode"
20:13 zmike: it's the depth texturing mode
20:14 zmike: where like alpha mode would be sampling a depth texture as 0/0/0/x
20:14 jenatali: Still no clue what you're talking about so I'd guess no
20:14 zmike: ok
20:14 zmike: feels like this might be a gallium core thing
20:15 jenatali: Isn't that just a swizzle on the sampler view for the depth texture?
20:16 zmike: at the driver level yes, but vulkan at least can't do it since a depth sample is always 1 component
20:17 jenatali: Ooh, interesting. In D3D a depth sample is 4 components, with the depth value usually returned in R
20:18 zmike: oh
20:18 zmike: huh
20:18 jenatali: Unless you're reading stencil in which case it ends up in G
20:18 jenatali: (Unless you swizzle it elsewhere)
20:18 zmike: so then you actually can do this
20:18 jenatali: Yes
20:18 zmike:grumbles about stupid jekstrand decisions
20:18 jenatali: Depth textures only show up specially in HLSL/DXIL when you're going to do comparison sampling on them, which does only return a single channel, but then it's a true/false (or a weighted 0 - 1 for linear)
20:34 jekstrand: zmike: What'd I do?
20:34 zmike: surely something at some point
20:39 jekstrand: Yeah, probably.
22:56 kode54: huh
22:56 kode54: mesa git is now suddenly preferring to install its libraries to /usr/lib64
23:54 Lynne: still /usr/lib/x86_64-linux-gnu/ for me, with --libdir=lib/x86_64-linux-gnu