06:40 mlankhorst: Hmm, should I make dma_buf_get() a C _Generic() that can increase the refcount of an existing dma-buf too?
06:51 vsyrjala: why not simply rename the current dma_buf_get() to something more appropriate?
06:51 mlankhorst: dma_buf_fdget?
06:52 mlankhorst: hm dma_buf_fget then
06:52 mlankhorst: Yeha doing that too
12:47 karolherbst: soo.. who wants to open the MR to start the discussion on disallowing LLM generated code? 🙃
12:51 kode54: but don't you want to have to review submissions whose authors couldn't be bothered to either write or review their own code?
12:51 kode54: \/s
12:52 kode54: at least if they reviewed it before submitting, there's even a chance that it doesn't reek of AI smell
12:54 karolherbst: well that's already forbidden
12:54 karolherbst: author understanding the code they submit is a requirement now
12:55 karolherbst: which well.. was already de-factor a requirement 🙃
12:55 karolherbst: *de-facto
12:55 kode54: sounds perfectly reasonable
12:55 kode54: how can one reasonably submit code without understanding how it works?
12:56 kode54: I only use the best AI code crafters when I'm being lazy and don't want to spend hours learning how to understand to get a quick task done
12:56 karolherbst: well... beats me
12:56 kode54: but I don't do that when I'm submitting code to a major project
12:57 kode54: I either learn what I need to do, or I leave it to the professionals
13:22 simon-perretta-img: curl seems to have had luck with the AI policy they implemented earlier this year, although it does seem to be more for bug reports rather than code submission; I wonder if there's any inspiration that could be drawn from there for mesa
13:26 karolherbst: right... the gentoo policy also got linked on the MR
13:29 simon-perretta-img: Oh right sorry, I hadn't realised there was an MR open
13:30 karolherbst: there isn't
13:30 karolherbst: I meant on the other MR
13:31 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37233#note_3102631
13:31 simon-perretta-img: I missed that one too haha - cheers
13:33 bl4ckb0ne: could that be applied to the whole gitlab instance?
13:33 bl4ckb0ne: or every project has to add it themselves
14:37 melissawen: hey tzimmermann, I'm taking a look in this series https://lore.kernel.org/dri-devel/20250711093744.120962-1-tzimmermann@suse.de/ and AFAIU you removed the first two reverts from the version that ended up applied, right?
14:37 melissawen: to resolve later...
14:37 melissawen: was it resolved in the end by any follow-up series?
14:38 melissawen: asking because I'm on mainline kernel and I'm having a hard time trying to unload amdgpu driver (always in use)
14:39 melissawen: and I only managed to unload it after reverting those two patches about references on GEM handles
14:43 tzimmermann: melissawen, hi. yes the first two patches never got reverted
14:43 tzimmermann: they partially solved a problem
14:43 tzimmermann: but i guess we could revert them as well
14:44 tzimmermann: these changes were a complete mess anyway
14:47 melissawen: When trying to unload amdgpu, looks like there is something that cannot be completely released and I got this: `modprobe: FATAL: Module amdgpu is in use`
14:47 melissawen: but I didn't see any process using it
14:48 melissawen: not sure how serious is the problem partially solved by those two patches TBH
14:49 melissawen: so I understand it's a matter of weighing
14:49 melissawen: also, no idea if other drivers are also afected or not
14:54 tzimmermann: melissawen, please send reverts for those patches. i guess we can discuss there. since we reverted all the later patches already, we don't need those two patches either. we'd just go back ot the old behavior
14:56 tzimmermann: i tried to simplify dma_buf handling, but it ended in dangling pointers. we had to revert across several trees and those two patches are the ones still left
14:59 melissawen: tzimmermann, I see... I'm not involved in this work, but indeed reverting the whole thing seems consistent. I'll sent the reverts. Thanks for explaining the situation
15:00 tzimmermann: melissawen, thanks a lot
15:26 melissawen: np :)
15:35 alyssa: PSA: `nir_src_as_uint(alu->src[i].src)` is almost never what you want, because it ignores the swizzle. Use `nir_alu_src_as_uint(alu->src[i].src)` instead.
15:35 alyssa: grepping I see multiple backends getting this wrong
15:36 glehmann: for backends with scalar constants it doesn't matter, fwiw
15:37 alyssa: that's probably true
16:13 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37467 for the mesa patch
16:18 gfxstrand: Kayden: Uh... Yeah, should probably fix that
16:19 gfxstrand: There's another helper right next to it that has the same problem. (-:
16:40 eric_engestrom: mattst88, elibrokeit: thanks for the link to the script! I'll integrate it into our build when I have a minute :)
18:35 cwabbott: if you loved float64.glsl, get ready for float32.glsl, yes really
18:36 eric_engestrom: mattst88, elibrokeit: CI side in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37490
18:36 eric_engestrom: but it can't be merged until the meson side is fixed, which I'll get to next week if nobody wants to beat me to it :P
18:47 idr: cwabbott: WAT?
18:47 idr: fp16-only hardware? Integer-only hardware?
18:48 glehmann: hw without fp32 denormals, I guess
18:48 glehmann: although I'm not aware of any game that requires those
18:49 cwabbott: yes, hw without fp32 denormals
18:51 cwabbott: microsoft decided to make supporting them mandatory, but to have denorms preserved you have to use a compiler switch that afaik no games use
18:51 cwabbott: so it's like the GL4.0 situation all over again, but it's microsoft's fault this time
18:52 idr: Don't try to run shaders on an Itanium.
18:54 idr: Or VAX.
18:54 cwabbott: and yes, qualcomm's native dx12 driver will give you soft-floats if you set that compiler switch
18:54 HdkR: :D
18:54 HdkR: I do love me a soft float.
18:54 alyssa: HdkR: They're so squishy!
18:55 HdkR: Like a freshly poured gelatin out of a mould.
18:56 alyssa: Or mold
18:56 HdkR: "Don't breath this!"
19:32 Kayden: float32.glsl D:
19:33 Kayden: god. I am sorry you are having to write that.
19:48 alyssa: I so wish we could use vtn_bindgen2 for softfloat
19:50 glehmann: write it in nir_builder
20:35 jenatali: cwabbott: Yes they're required to be preserve-able in shader model 6.2, but yes nobody really uses that AFAIK. Are you saying the "X Elite" chips use soft floats in that mode?
20:36 cwabbott: jenatali: yes
20:36 jenatali: O.o
20:36 jenatali: I knew they stopped at 6.1 on the previous gen because of the denorm issue but I just assumed they had hardware support in the later gen...
20:36 jenatali: Wow
20:36 cwabbott: we have a trace confirming it
20:37 jenatali: Sigh
20:39 jenatali: I'm so sorry. For what it's worth, while yes it's mostly our fault for adding that dumb feature as required, it's also partly QC's fault for not talking to us and telling us not to