00:00 zmike: I never disabled for zink
00:00 zmike: crashes just make my users stronger
00:00 zmike: user*
00:03 kisak: zmike: that didn't work out too well last time https://www.youtube.com/watch?v=mYSSmZVYTkE (movie clip)
00:03 Sachiel: safety critical zink when?
00:04 HdkR: OpenGL through Vulkan SC
00:04 zmike: I imagine it more like https://youtu.be/wuTcctu_DfM?t=32
00:06 alyssa: Sachiel: anglesc? :p
00:06 Sachiel: alyssa: rounded-angle
00:13 alyssa: do we have any test coverage for clip distance enable masks?
00:13 alyssa: the desktop gl kind
00:14 zmike:handwaves at piglit
00:14 alyssa: do we have piglits for it though
00:16 alyssa: like that would fail if you didn't respect the mask
00:19 zmike:handwaves
00:19 alyssa: helpful
00:20 alyssa: thanks
00:20 zmike: there's a lot of clipdist testing
00:20 zmike: glcts gtf has a bunch too
00:20 alyssa: gtf oh
00:20 alyssa: :p
00:20 zmike: 😬
00:21 alyssa: i love how extensivelt documented NIR_COMPACT_ARRAYS is ...
00:22 gfxstrand: Oh, clipdist...
00:29 alyssa: why did we put that in vulkan again
00:52 alyssa: meh, this is easier than making lower_clip_fs work with lowered I/O
00:52 alyssa: and with this + late lower_blend + late lower_tex_replace, I can finally preprocess at CSO create time
00:52 alyssa: well
00:52 alyssa: "finally" as if I haven't been shipping that downstream for months :p
00:52 HdkR: \o/
00:57 alyssa: i still can't tell how any of this is supposed to work
01:01 alyssa: what does this CAP do?!
01:01 alyssa: Seemingly spirv-to-nir always produces clip_dist0
01:02 alyssa: with compact=true
01:04 alyssa: and then the vk runtime calls nir_lower_clip_cull_distance_arrays which again gets us the compact thing
01:06 alyssa: so... seemingly CLIP_DIST1 can't ever happen with vulkan, or with gl if NIR_COMPACT_ARRAYS is set
01:07 alyssa: so... why do ir3/zink/etc handle it..
01:08 zmike: can get some weird things happening when xfb is involved there
01:10 jenatali: alyssa: With clip + cull, you can get a second var with location of clip1, or a fractional loc within clip0/1
01:11 mareko: alyssa: yes
01:22 alyssa: jenatali: hm. I don't really know anything about cull distances.
01:23 jenatali: IIRC clip distance can partially clip primitives, where cull distances only apply if all vertices fail the distance test
01:23 alyssa: tbh tempted to say this is "good enough" and revisit later if needed..
01:23 alyssa: "fs-clip-distance-interpolated.shader_test" does seem unhappy though
01:23 jenatali: There's a separate info bit to indicate how many of them are supposed to be clip
01:25 alyssa: i see
01:25 alyssa: well, I don't have cull distances in my hardware
01:25 alyssa: and don't advertise ARB_cull_distance, so
01:26 alyssa: GL4.5 grumble
01:27 alyssa: why we did we make this core
01:29 alyssa: Is this even possible to lower...
01:31 alyssa: not good.
01:31 mareko: because directx
01:32 alyssa: evidently
01:32 mareko: it's possible to lower on AMD or if you have GS
01:32 alyssa: hm, yeah, I see how you would do it with a GS
01:36 alyssa: ok, yeah, this can be lowered with excessive cost. meh
01:37 alyssa: or... do we actually need to cull in the geometry processing stage?
01:37 alyssa: could we instead just discard every fragment in the primitive?
01:37 alyssa: obviously that's not efficient but it's better than what the GS-lite approach would need
01:38 alyssa: i'm suspicious that NV_fragment_shader_barycentric might be possible on AGX, unsure
01:39 HdkR: Everyone loves exposed barycentrics. Unless they aren't stable :)
01:43 mareko: using discard disables early Z
01:44 jenatali: Unless you force enable it
01:45 alyssa: mareko: least of my worries right now
02:14 alyssa: hmmm I wonder how my hardware interpolates NaN varyings
02:25 alyssa: seemingly the whole triangle lights up if there's just one NaN varying and the rest 0
02:26 alyssa:isn't sure what's happening
02:51 alyssa: piglit: error: Failed to create waffle_context for OpenGL ES 4.0 Context
02:51 alyssa: ummm
02:57 alyssa: inexplicably AGX has decided that the interpolation of NaN, 0, and 0 is 0x7f7fffff
02:57 alyssa: which is extremely large but finite
02:58 alyssa: whatever, I can work with this
03:02 alyssa: woahh infinity is different
03:03 alyssa: I assume I'm hitting all kinds of hardware undefined behaviour lol
03:03 alyssa: ahahaha no
03:03 alyssa: 0x7f7fffff is the maximum representible *finite* single precision float
03:05 alyssa: so it's carrying the NaN through and clamping to finite at the end, seemingly
03:05 alyssa: I can work with this!!
03:05 jenatali: O.o
03:06 gfxstrand: tarceri_: I'll try to get back to copy-prop-vars on Monday. I've had a lot going on this week.
03:06 alyssa: jenatali: No this is great
03:07 alyssa: jenatali: So here's what I'm going to do :3
03:07 gfxstrand: alyssa: What vile magic are you attempting?
03:07 alyssa: gfxstrand: gl_CullDistance lowering
03:07 alyssa: on hardware with no cull distances, no geometry shaders, and no NV_fragment_shader_barycentric
03:08 gfxstrand: Oh
03:08 gfxstrand: This is gonna be entertaining
03:08 alyssa: gfxstrand: faith you're gonna love this
03:08 gfxstrand: :D
03:08 alyssa: so, the relevant spec text is
03:08 alyssa: > Primitives whose vertices all have a negative clip distance for plane i will be discarded.
03:08 alyssa: Culling happens after XFB (I think) so this can be validly implemented by discarding every pixel inside the primitive
03:09 alyssa: So conceptually we just need to insert at the beginning of the fragment shader
03:09 alyssa: if (cull_distance[0] < 0 && cull_distance[1] < 0 && cull_distance[2] < 0) discard;
03:10 alyssa: The problem is that we don't have access to the cull distance varying at each vertex, we only have it at the provoking vertex (if flat) or we have the interpolation of them (if smooth)
03:11 alyssa: Maybe interpolation is ok? Like, if the interpolated value is negative, that implies all 3 distances are negative so we discard, right?
03:11 alyssa: True, but..
03:11 alyssa: the converse fails
03:11 alyssa: er
03:11 alyssa: no that's the thing that fails
03:11 alyssa: The converse is true, that's false
03:12 alyssa: If the distances are (-1, -1, 1) then any pixel along the edge between -1 and -1 will have an interpolated value of -1 regardless of how positive the 1 is
03:12 alyssa: So we're out of luck.... or are we?
03:12 alyssa: Recall how varying interpolation works mathemtically, it's something of the form
03:12 tarceri: gfxstrand: sure no problem. I'm just about to push the changes you suggested. Thanks!
03:13 alyssa: (value_0 * coefficient_0) + (value_1 * coefficient_1) + (value_2 * coefficient_2)
03:13 alyssa: now, if that interpolation happens with IEEE 754 arithmetic, a very interesting property emerges
03:13 alyssa: if *any* vertex's value is NaN, then the interpolated value *everywhere on the primitive* is NaN
03:14 alyssa: even if we have (0, 0, NaN), the values along the shared 0/0 edge will *still* be NaN because NaN * 0 = NaN and NaN + 0 = NaN and the NaN poisons the whole primitive
03:14 alyssa: but that's exactly what we needed!
03:15 alyssa: With that property, we now have a way to check for any pixel whether a boolean condition is true for any vertex
03:15 alyssa: or by De Morgan's, whether a boolean condition is true for all vertices
03:15 alyssa: So here's what we're gonna do
03:16 alyssa: In the vertex shader, `gl_CullDistance = dist` is going to become instead `lowered_value = (dist >= 0.0) ? NaN : 0.0`
03:16 alyssa: with `out highp float lowered_value`
03:16 alyssa: then in the fragment shader, we're going to insert a prolog
03:16 alyssa: `if (lowered_value == 0.0) discard;`
03:17 alyssa: To check that this works: if all cull distances are negative, then all lowered values will be 0.0 so every pixel in the primitive will interpolate 0.0 so every pixel will in the primitive will be discarded
03:18 alyssa: otherwise, some lowered value will be NaN so every pixel in the primitive will interpolate NaN so no pixel will be discard
03:18 alyssa: One wrinkle... at least on the M1, varying interpolation *doesn't* happen with IEEE 754 arithmetic
03:18 gfxstrand: I wonder if you could short-cut the discard bit and just do if (gl_cullDist < 0) gl_FragCoord.x = NaN
03:19 gfxstrand: Or .w or something
03:19 alyssa: in the VS or the FS?
03:19 gfxstrand: in the VS
03:19 alyssa: no, that won't work
03:19 gfxstrand: And hope the clipper freaks and tosses the whole thing
03:19 alyssa: because it's an AND not an OR
03:20 gfxstrand: Oh
03:20 gfxstrand: Well that's dumb
03:20 gfxstrand: But ok
03:20 alyssa: if you're drawing triangle strips or something, you can have a vertex whose negative value contributes to culling in one primitive but not the other
03:20 gfxstrand: sure
03:20 gfxstrand: Makes sense, I guess
03:20 alyssa: so no pure VS lowering is possible unless you unroll everything
03:20 gfxstrand: :(
03:20 alyssa: 03:19 < gfxstrand> And hope the clipper freaks
03:20 alyssa: it's too busy freaking from when I ran t-rex this morning
03:24 gfxstrand: Yeah, TRex is mean to clippers
03:28 alyssa: there are some annoying details about making that scheme work with separate shaders
03:28 alyssa: (for GL it doesn't matter. for Vulkan monolithic it doesn't either. Might screw over GPL fast link.)
03:33 gfxstrand: Eh, it can be made to work, I think.
03:33 gfxstrand: Just need to push a mask into the shader or something
03:35 alyssa: more thinking about how to link the internal extra varyings
03:35 alyssa: definitely can be made to work, just unsure whether it would slow down everything separable to be conservative about it
04:26 alyssa: meanwhile on gl_ClipDistance
04:26 alyssa: I need nir_lower_clip_disable, but that is in itself an early pass that I need to do a late version of for this
04:27 alyssa: ....and I have decent evidence that AGX can't interpolate gl_ClipDistance so the varyings need to be duplicated anyway
04:28 alyssa: so maybe I want to punt on this and figure out if I can make lower_clip_fs happen late and revisit this come Vulkan
06:29 RAOF: Hm. Would anyone object to me making it possible to add drirc.d directories from an environment variable?
06:29 RAOF: It would be convenient, and it looks like it might allow removing some cludges added to support tests?
06:43 mupuf: RAOF: no objections from me, provided we find a way to make it unsurprising. Were you thinking about purely adding, or overriding the default one?
06:47 RAOF: 🤷‍♀️
06:47 RAOF: Purely adding would be sufficient for my purpose, but if replacing was preferred I could certainly do that.
06:49 mupuf: I would go for whichever would be least surprising... which may be the override one or may not
06:49 mupuf: were you planning on a coma-separated list of directories?
06:49 RAOF: Following the vulkan loader, something like a colon-delimited MESA_ADD_DRIRC_PATH would be my first thought.
06:50 mupuf: well, at least, it wouldn't be surprising :)
06:52 RAOF: I guess the most surprising behaviour would be how combining multiple settings would be handled.
06:54 RAOF: Although that's not a novel problem, since drirc.d already aggregates multiple configs.
11:17 X512: Is it possible to link libnir as shared library?
11:20 tomeu: X512: it could be possible, but if you can extend on your use case, maybe somebody can give some opinions on whether that would be a good idea
11:20 X512: It looks wasteful to duplicate libnir to each driver.
11:22 tomeu: ah, drivers should be all together in a single .so
11:22 tomeu: so no waste
11:27 X512: Not for Gallium and Vulkan drivers.
11:29 lynxeye: X512: not sure about vulkan, but gallium drivers are megadrivers, where all the drivers are linked into a single .so and the different names are just hardlinks
11:35 danvet: mairacanal, for the rust bindings also chat with lina
11:36 danvet: even right lina, yay
11:37 X512: Rust bindings for internal Mesa API (Gallium etc.)?
11:37 X512: Internal API seems often change.
11:46 MrCooper: lynxeye: I think X512's point was that libnir is still duplicated between the Gallium mega-driver and Vulkan drivers at least
12:20 melissawen: Is there any dependency between degamma and ctm atomic color properties on the DRM side? I mean, if the driver doesn't advertise degamma, it can still advertise CTM and gamma properties independently, right?
12:57 mairacanal: danvet, I was checking lina 's DRM bindings which are looking pretty neat btw, but I currently I'm thinking mostly on the dma-buf bindings as they are a crucial part of vgem
13:19 emersion: melissawen: AFAIK yes
13:19 emersion: would be the same as DEGAMMA = null (zero object ID)
13:30 melissawen: emersion, thanks for confirming. I've also double-checked with drm_info that the property keeps there, so I suspect there is a dependency between these properties in the userspace case.
13:31 emersion: you mean some user-space expects these two to be supported together, or not at all?
13:31 emersion: sounds like a user-space bug indeed
13:41 melissawen: yeah, I suspect the userspace expects degamma support to advertise CTM, since I don't find any dependency on the kernel side.
16:50 alyssa: off by one in user-clip-all-planes hmm
16:51 alyssa: maybe buggy test, it's failing on a lot of drivers
16:52 alyssa: including radeonsi, the reference driver :p
16:52 alyssa: freedreno-a420-fails.txt says
16:52 alyssa: # The clipped polygon is off-by-one pixel from the directly drawn one
16:52 alyssa: spec@!opengl 1.0@gl-1.0-user-clip-all-planes,Fail
16:53 alyssa: which is what I'm seeing too
16:54 alyssa: wonder if it's a test bug with float math or something, idk
17:00 jenatali: I think we pass it
17:10 alyssa: yeah, it passes with hw clip distance interpolation, just not nir_lower_clip_fs
19:24 danvet: mairacanal, I also wonder whether we should look into the drm_exec stuff that's floating around
19:24 danvet: otoh vgem doesn't really need that
19:25 danvet: for dma-buf bindings there's also the question of whether we need ww_mutex bindings first, or just wrap that all as a dma-buf implementation detail
19:32 mairacanal: danvet, afaik we need the ww_mutex bindings first to make the safe abstraction for dma-buf, just like semaphores, rw_semaphore and other sync objects
19:41 danvet: mairacanal, btw are you in the rust-for-linux zulip, or need an invite?
19:42 danvet: I quickly discussed the ww_mutex binding stuff with the rust folks this week, if you want I think would be good if you also join
19:42 danvet: there's also some sync meeting on gpu rust upstreaming in 2 weeks again
19:49 mairacanal: danvet, yeah, I'm in zulip, I will try to take a look at the ww_mutex discussion. do you remember in which stream happened this discussion?
19:49 DemiMarie: Any plans to deal with the "sleeping in atomic context causes UaF" unsoundness?
19:50 DemiMarie: alyssa: mind if I DM you?
19:50 alyssa: DemiMarie: about?
19:50 alyssa: also, do I know you?
19:51 alyssa: irc logs indicate yes
19:51 DemiMarie: GuC stuff
19:52 alyssa: I don't work on that hardware
19:52 alyssa: try #intel-gfx
19:56 danvet: DemiMarie, what's that atomic uaf unsoundness thing?
19:56 DemiMarie: We’ve talked about graphics stuff before
19:56 danvet: also no idea what uaf means and urban dict is decidely less useful
19:57 airlied: use after free
19:57 danvet: ah
19:57 danvet: I guess I'm very firmly in w/e mode
20:01 alyssa: DemiMarie: anyway, I don't know anything about GuC except what's been discussed in here, and I don't work on Intel hardware or (usually) the kernel at all, so I don't think I have much to say, sorry! :)
20:01 alyssa:is glad she's not touching that :-p
20:01 alyssa: ---
20:02 alyssa: I added some milestones for tracking MR's through the review/merge process
20:02 alyssa: and tagged my own MR's
20:02 zmike: is one of them Sisyphus
20:02 alyssa: I'm not sure how well this is going to work but I figure it's a very low cost thing to try, and I've seen it for a few other projects I think
20:03 DemiMarie: danvet: I believe that on CONFIG_PREEMPT=n, scheduling in a RCU read-side critical section will cause the critical section to end too soon.
20:03 alyssa: and it makes it really easy for reviewers to check what they have to review
20:03 alyssa: e.g. panfrost review backlog -- https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&state=opened&label_name[]=panfrost&milestone_title=Needs%20review
20:04 alyssa: asahi review backlog -- https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&state=opened&label_name[]=asahi&milestone_title=Needs%20review
20:04 DemiMarie: alyssa: I meant the “I don’t and you shouldn't” about the GuC firmware.
20:04 alyssa: Hmm?
20:04 HdkR: alyssa: Nice!
20:06 DemiMarie: alyssa: regarding the security of that firmware against malicious inputs
20:06 alyssa: oh
20:07 alyssa: right. again I don't know anything, I'm just a loud rando :-p
20:09 HdkR: Big same
20:47 alyssa: airlied: anholt: what's the rules for landing draft UAPIs into Mesa (behind a build flag), subject to change and before they've landed in stable form in mainline?
20:47 alyssa: I thought that was a huge no-no (and have been suffering through the rebases as a consequence) but danvet said I should ping you two about it
20:49 danvet: probably needs something really scary like do-not-enable-unless-you-are-hacking-on-axg-drivers
20:50 alyssa: i'm good with scary if it means an end to rebase fail
20:50 danvet: but I think we've done that a few times in different places now
20:50 alyssa: s/fail/pain
20:59 airlied: i think we did it for vc4, i worry a bit with asahi though
21:00 airlied: since there seems to be a bit of distro competition around apple hw
21:00 airlied: if a distro is going to turnthe flag on, then i dont want it in mesa
21:01 airlied: because when the mainline diverges, we will end up owning a can of worms, and Linus
21:03 alyssa: airlied: Yeah, that's very fair
21:03 alyssa: manjaro definitely would flip the flag...
21:04 anarsoul: but does Linus run Manjaro? :)
21:04 alyssa: ;p
21:04 airlied: and their users will cry loudly if a new kernel breaks their desktop
21:04 alyssa: unfortunately Linus does run Asahi Linux ....
21:05 anarsoul: alyssa: why not to add ioctl to query uapi version?
21:06 airlied: why not create a stable api :-p
21:07 anarsoul: airlied: for an REd driver?
21:09 airlied: at some point you have to trust you understand enough to build on
21:10 danvet: aren't the non-re'ed driver uapi's in the minority?
22:44 gawin: airlied: iirc crocus is doing internally fallback for d16, maybe it would be better to not advertise d16 at all? (gallium nine fails into weird codepath, and Axel suggested avoiding it if possible)
22:57 gawin: I mean d16 as real d16, but overridden later