00:00 alyssa: gfxstrand: Unity used to embed ancient Mesa, IDK if they still do
00:00 alyssa: glsl-optimizer lol
01:34 alyssa:still can't choose between mesa glsl, glslang, and clang
01:35 Sachiel: don't choose, write a new one
01:35 alyssa: big brain
01:35 alyssa: based on in-tree prior art, it looks like glslang is the most popular option, but not by much
01:37 alyssa: with util/glsl2spirv.py from the anv side, hmm
01:39 alyssa: although you get vulkan-flavour spirv out, which might be annoying to use in a gl driver
01:40 alyssa: (tractable, but annoying)
01:41 alyssa: probably i should just pick one and go with it since there's no perfect option but ugh
01:42 zmike: write a cmdline util that pipes compiler/glsl through ntv you coward
01:43 alyssa: that doesn't solve any of the problems
01:43 zmike: oh now we gotta be solving problems?!
01:46 alyssa: i've just discovered builtin_int64.h
01:46 alyssa: make it stop make it stop make it stop
02:00 zmike: DavidHeidelberg[m]: did libx11 ever get upgraded in ci? looking at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/47403946 I see there's two glx tests hitting the timeout, which means they're almost certainly deadlocking
02:00 zmike: should probably add to skips
08:09 MrCooper: a530_gl 1/6 seems very flaky, multiple flaky tests in there
09:32 DavidHeidelberg[m]: MrCooper: it was almost "flake free", but then anholt fixed some fails, and different stuff started flaking (probably matters which combination of tests are run together), I'm adding another bunch of tests into flakes and we'll see :(
09:33 MrCooper: thanks
09:34 DavidHeidelberg[m]: zmike: into skips everywhere :( (like every driver has Fail/Crash and Flake)
09:35 DavidHeidelberg[m]: zmike: rarely, we had some patches libx11 (older), and with Debian 12 there should be the fixed version as default, let me check the logs
09:35 DavidHeidelberg[m]: *git logs
09:51 DavidHeidelberg[m]: zmike: Debian 12 has 1.8.4-2+deb12u1, seems without patches, looked into changelog of 1.8.5 (buildsystem and locales) and .6 (CVE) there shouldn't be any changes on top
09:53 DavidHeidelberg[m]: aaah, nope. The patch Drop --disable-thread-safety-constructor again. is applied again
09:54 DavidHeidelberg[m]: tjaalton: Why Mr. Anderson, why? Why you fighting the patch? Why do you persist? :D
09:58 tjaalton: DavidHeidelberg[m]: which patch?
09:58 DavidHeidelberg[m]: tjaalton: https://salsa.debian.org/xorg-team/lib/libx11/-/commit/7137bf9f0d1438f00b6498f13481f9de5f026963
09:59 tjaalton: and what about it? why should it remain disabled?
10:04 DavidHeidelberg[m]: I may have inverted the logic here :( I mixed it with previous commit https://salsa.debian.org/xorg-team/lib/libx11/-/commit/98462f21deec8e72fcf752d733b18aaf3df5d2b5
10:05 DavidHeidelberg[m]: I think the revert is right then. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17917#note_1498907
10:07 DavidHeidelberg[m]: zmike: so, this should be the originally requested behavior from libX11 ^
11:06 zmike: ok
15:25 anholt: MrCooper: there's a test that crashes in that job, which takes out random other tests. I've got an MR up that moves it to skips.
15:25 MrCooper: cool
15:25 anholt: (I also have a branch that works on hopefully fixing the crash in that test, but it runs into other fail).
15:32 anholt: I'm kinda grumpy that a530 got enabled when it was so unstable. I had disabled it for exactly this reason.
15:35 linyaa: VK_gpl for venus, anyone want to volunteer to review it? mesa!22419
15:36 linyaa: (the #1 and #2 venus devs are on lengthy vacation. i'm trying to merge it before august ends).
15:38 alyssa: zmike: after extensive thought
15:38 alyssa: i too hate gl point size
15:39 zmike: 😬
15:39 alyssa: why is gles different from gl here this is dumb
15:40 alyssa: how is this supposed to work in gallium drivers
15:41 pac85: So in mesa vkSetDebugUtilsObjectNameEXT relies on all objects passed to it to derive from vk_object_base, but VkSurface in wsi does not and the spec says nothing against passing that to vkSetDebugUtilsObjectNameEXT right? This causes crashes in some games and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24698 fixes the crashes
15:44 alyssa: zmike: "CTS explicitly has “wide points” tests which verify illegal point sizes that are exported by the tessellation and geometry shader stages. Isn’t that cool?"
15:44 alyssa: clown.jpg
15:44 zmike: any issues that existed there are long since fixed
15:47 alyssa: oh i see how this is supposed to work now
15:47 alyssa: I still hate it
15:49 gfxstrand: anholt: What drivers are still using NTT?
15:49 zmike: llvmpipe
15:49 zmike: nine
15:49 anholt: gfxstrand: r300 (for the moment), i915, virgl
15:49 anholt: nine is TTN.
15:49 alyssa: zmike: softpipe, yes. I didn't think llvmpipe?
15:50 zmike: ah right, nvm, I got them mixed up
15:50 anholt: yeah, softpipe.
15:50 gfxstrand: Pretty sure HW atomic counters are subtly busted and I'm trying to decide how much I care.
15:51 anholt: HW atomic counters are I think r600 only, and it's not on ntt any more.
15:51 anholt: (thanks, @gerddie!)
15:52 anholt: oh, I suppose virgl might be HW atomic counters.
15:52 gfxstrand: Yeah, virgl still plumbs them through. :rolls_eyes:
15:53 alyssa: can we tell virgl to stop
15:53 gfxstrand: Gotta make sure virgl on r600 is fast!
15:53 alyssa: :p
15:53 gfxstrand: I do have pseudo-minions who can fix that. :)
15:54 anholt: I would be +1 to virgl just doing ssbos.
15:54 anholt: that HW atomic counter code in NTT was such a fuss.
15:54 alyssa: zmike: i also hate triangles_with_adjacency hbu
15:55 zmike: yup
15:55 alyssa: *triangle_strips_with_adjacency
15:55 alyssa: (I mean all adjacency but especially tri strips)
15:55 zmike: amen
15:55 zmike: things should not be next to other things.
15:55 alyssa: absolutely
15:55 alyssa: wanted geometry shaders anyway for a laugh? we had a tool for that: points
15:55 zmike: or just turn off your computer and go outside
15:56 alyssa: i'm sorry what is this monstrosity https://rosenzweig.io/what.c
15:56 zmike: smh trying another irc-based phishing attack with random links
15:56 gfxstrand: I'm going to see if someone wants to voulenteer to nuke them from virgl and make Google pay for it. :-P
15:59 alyssa: zmike: fwiw, re more NIR churn, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24654
16:00 alyssa: The plan is to land that MR now, so that if people have broken drivers that aren't in CI, they'll hit the assert and can fix stuff
16:00 alyssa: and then after a little reasonable time we'll assume everyone has tested their drivers and will drop the helper treewide
16:00 alyssa: only 146 uses so shouldn't be too much conflict potential
16:00 alyssa: new code should be using src[x].ssa directly
16:02 zmike: 😬
16:02 alyssa: of those 146 uses, only 4 needed adjustements
16:02 alyssa: so hopefully CI caught everything
17:23 alyssa: gfxstrand: could you take a look at !24616? thanks :)
18:27 alyssa:wonders what's up with KHR-GLES31.core.geometry_shader.rendering.rendering.triangles_with_adjacency_input_line_strip_output_triangle_strip_adjacency_drawcall
18:27 alyssa: it's in the xfail list for radeonsi/gfx9 and angle+radv/stoney
18:27 alyssa: it doesn't /seem/ to be doing anything obviously spicy..
18:29 zmike: wfm
18:33 alyssa: I wonder what Zink is doing different than ANGLE
18:34 zmike: not failing ig
18:35 alyssa: I do notice that the GLES spec and the VK spec seemingly disagree on the definition of tri strips with adjacency
18:36 alyssa: er, no, maybe the GLES spec is just written in the most confusing way possible
18:36 alyssa: i think it's that
18:37 anholt: alyssa: zink CI isn't running that test on radv, fwiw.
18:37 alyssa: spicy
18:39 zmike: gotta run manual to get the good stuff
18:40 anholt: which toml do you see running that?
18:41 zmike: $ MESA_DEBUG=silent MESA_LOADER_DRIVER_OVERRIDE=zink ./glcts -n KHR-GLES31.core.geometry_shader.rendering.rendering.triangles_with_adjacency_input_line_strip_output_triangle_strip_adjacency_drawcall
18:41 zmike: Test case 'KHR-GLES31.core.geometry_shader.rendering.rendering.triangles_with_adjacency_input_line_strip_output_triangle_strip_adjacency_drawcall'..
18:41 zmike: Pass (Pass)
18:48 alyssa: Hmm I don't see Zink doing anything special for adjacency..
18:48 alyssa: so presumably this isn't a gl vs vk compat issue (I implemented from the VK spec)
18:49 Sachiel: maybe related to this whole mess https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/4564 ?
18:49 Sachiel: there were a few issues with that in vulkan land
18:49 alyssa: Plausible
18:49 Sachiel: for anv we fixed the zink failures with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23243
18:50 Sachiel: no idea what angle is doing
18:51 alyssa: provoking vertex mode, oh that could be spicy..
18:52 alyssa: Yeah, I bet that's it.
18:52 alyssa: I'm doing special provoking vtx handling for tri strips, but not tri strips w/ adjacency. Yeah, that's gotta be wrong
18:52 alyssa: Thanks :)
18:53 Sachiel: glad to be useful
18:53 alyssa: gles spec you're useless
18:53 alyssa: vk you're up
18:58 HdkR: GLES sitting in the bus being all, "I'm underspecified :>"
18:59 alyssa: I don't think it's that, the GLES spec is just written as confusingly as possible (-:
19:03 alyssa: hm that didn't fix the test but presumably fixed something..
19:03 Sachiel: if angle is failing with everything, then maybe angle is wrong
19:04 alyssa: this isn't angle, I just find it interesting that angle is failing the same tests I am
19:04 Sachiel: oh
19:29 jrpan: IDENTIFY
19:30 alyssa: ALYSSA
19:30 DavidHeidelberg[m]: jrpan: wrong window :D
19:30 DavidHeidelberg[m]: :D
19:30 jrpan: oops. Sry
19:34 zmike: peak #dri-devel energy
19:35 jrpan: Hi all, I’m using an old version of mesa3d, and I’m trying to read the index buffer within Intel Vulkan driver. I succeeded getting the address with formula `addr.bo->map + addr.offset` (addr is anv_address struct) in a simple vulkan sample. But when trying out a real game from Godot engine, the buffer is empty.
19:35 jrpan: ). Is the method of calculating the address correct? Or is there any Vulkan feature that allows the buffer to be set after being bound? I’m a GPU researcher but unfamiliar with computer graphics. Any help would be appreciated!
19:45 anholt: jrpan: index buffer contents are probably being uploaded into that space by some other command. So you'd need to look at the contents after the GPU has finished.
19:47 ccr: "come out with your hands up .. slowly .. keep your editor and compiler visible .."
20:03 jrpan: Thank you! I'm checking the buffer within `void genX(CmdDrawIndexed)` actually. I assume at this point the index buffer should be set. Is my assumption correct?
20:05 anholt: jrpan: no. the command buffer is executed by the GPU asynchronously from the CPU recording into it. that execution may involve filling out the contents of that buffer.
20:14 jrpan: anholt: Thank you very much!
20:32 alyssa: Sachiel: Ok, so the definitions of tri strips with adjacency between the GLES and VK specs are subtly different after all
20:32 alyssa: specifically for the odd cases, the vertex order is different in gl
20:32 alyssa: I assume this is provoking vertex related, but the VK spec is not being especially helpful
20:33 alyssa: if I use the gl ordering, the gles tests are passing
20:33 alyssa: I have no idea how this works on Zink
20:36 Sachiel: yeah, it is provoking vertex defined. GL defaults to last and VK defaults to first, iirc. Zink always sets that, I don't know if because it's aware of the difference or if it's been working correctly by chance
20:37 Sachiel: knowing zmike, I'll go with "working by chance"
20:38 ccr: :O
20:49 alyssa: at any rate, rotating the inputs appropriately to match the gl definition makes the test pass so... sure, whatever
20:50 HdkR: There's some extension for changing behaviour of provoking vertex isn't there? I would assume Zink relies on that
20:50 Sachiel: yup
20:51 alyssa: Sachiel: now i'm looking at the published intel docs to see if I can make sense of your commit
20:51 alyssa: must be so boring
20:51 Kayden: alyssa: yeah, I was really surprised to see that VK switched the convention to be reversed from GL (but presumably match DX)
20:53 Sachiel: oh, 01.org is dead and my prm links no longer work
20:53 alyssa: "Workaround: reorder mode must be set to REORDER_LEADING and reordering must be done in the Geometry shader"
20:53 alyssa: fun.
20:56 Sachiel: on the internal docs thing, there's a "Object Vertex Ordering" that tells you the order for all that stuff on the geometry shaders. I don't know if those titles are preserved when the PRMs are generated
21:05 alyssa: \/
22:23 alyssa: the end-primitive piglit is so cursed.
22:25 HdkR: Cursed unit tests so you don't need to run the cursed games that they came from? :D
22:26 alyssa: HdkR: it has geometry shader invocations that emit stray vertices
22:26 HdkR: That's pretty cursed
22:26 alyssa: they don't form a primitive and just need to be ignored
22:27 alyssa: the problem I hit is that my implementation calculates the number of /actual/ vertices and allocates exactly what's needed
22:27 alyssa: but I didn't predicate the EmitVertex() stores on that bounds check... meaning the writes for those stray vertices race with the first vertices of the next geometry shader
22:28 alyssa: and since the geometry shaders are running in parallel, that means a test flake
22:29 i509vcb: VkPhysicalDeviceExternalImageFormatInfo states the following:
22:29 i509vcb: > To determine the image capabilities compatible with an external memory handle type, add a VkPhysicalDeviceExternalImageFormatInfo structure to the pNext chain of the VkPhysicalDeviceImageFormatInfo2 structure and a VkExternalImageFormatProperties structure to the pNext chain of the VkImageFormatProperties2 structure.
22:29 i509vcb: VkExternalImageFormatProperties doesn't seem to be required? Is this a spec oversight or is there a reasonable reason why you'd want to ignore VkExternalImageFormatProperties (you can't blindly assume the handle type can be exported/imported, you need to check VkExternalImageFormatProperties)
22:29 HdkR: Spicy polygons
22:31 i509vcb: (asking before I file a bug report with the Vulkan spec)