00:47 DavidHeidelberg: mareko: figured out. s390x and ppc64el finished builds one minute later... and since when you crosscompile somehow you need to have synced native and cross packages (at least for stuff like libdrm)....
00:47 DavidHeidelberg: so amd64 was tagged with version one minute younger and that created the conflict
01:03 mareko: alyssa: I don't think transform feedback should be followed by glMemoryBarrier, that should be done automatically in drivers that need it
02:16 alyssa: mareko: Hmm, okay. TBH I find the glMemoryBarrier() spec pretty unclear
02:18 alyssa: I guess the relevant text is "stores performed by shaders", which includes SSBOs but not XFB.
02:18 alyssa: OK, that's annoying but I can figure something out
02:33 DavidHeidelberg: mareko: for the libdrm, believe me it was so much pain from CI maintainer perspective. it was just no-one needed libdrm upgrade for too long, so I worked on different stuff meanwhile as the Debian 12 version was just fine, btw. my MR is fixed, seems that everything working
03:02 jenatali: alyssa: right, ssbos and storage images. Nothing that's "fixed function" which happens after a shader stage
03:08 DavidHeidelberg: Reviews are welcome, it's first package, but lot of others "coming soon ™)
03:08 DavidHeidelberg: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26814
03:20 DavidHeidelberg: mareko: builds working, libdrm is everywhere same, life should be nice, feel free to merge before applying your change :)
03:21 DavidHeidelberg: (I tested with your commit increasing the requirement, so it should be fine)
03:23 mareko: thanks, I added my Rb
03:24 mareko: alyssa: radeonsi adds the barrier when it unbinds streamout buffers
12:44 gio: I guess there is no FOSS Vulkan driver for the Adreno 540, is that right?
13:58 DavidHeidelberg: gio: Nope, only GL
14:55 alyssa: jenatali: :+1:
14:55 alyssa: mareko: Hmm, interesting, ok.
14:56 alyssa: My problem is that I do draw call reordering shenanigans so it'd need to be a full flush (big hammer), though maybe I should just.. stop doing that for XFB lol
15:01 jenatali: Yep
15:01 jenatali: Transform feedback needs to be ordered, doesn't it?
15:02 alyssa: jenatali: Hmm?
15:02 jenatali: Like fragment shader writes, I thought XFB writes need to respect the original draw order
15:03 alyssa: Ah. Yeah
15:03 alyssa: Probably
15:04 alyssa: The problem is that for dubious reasons, right now I execute all the XFB for the render pass before executing any FS, for example
15:04 alyssa: Although to some extent that's kinda inevitable for tilers..
15:25 jenatali: Yeah that seems fine
16:11 alyssa: pac85: So, nir_passthrough_gs with out prim != in prim is broken with transform feedback
16:12 alyssa: E.g. TRIANGLES input, polygon mode set to LINES, transform feedback enabled, edge flags enabled
16:13 alyssa: nir will output LINE_STRIPS from the passthrough GS, which makes edge flags work, but breaks XFB since XFB needs to be triangles
16:13 alyssa: I suspect Zink is affected at least in theory
16:14 alyssa: "edge flags can't be used in the same draw as XFB" would solve this, I just don't know if it's true
16:14 pac85: alyssa: yep, I think we talked about it right? In zink I force the passtrhough gs to tesselate (so triangle out) geometry so that transform feedback behaves (hopefully) to spec, but that means breaking rendering on some cases
16:15 alyssa: ah..
16:15 pac85: alyssa: we also need to handle quads in line mode in zink
16:15 alyssa: :clown:
16:15 alyssa: faith was right I should've gone vulkan
16:20 Wallbraker: *sad trombone*
16:30 alyssa: *tiniest violin*
16:37 ccr: *Benny Hill Yakety Sax -theme*
16:38 Company: the good thing about Vulkan is that all the other drivers aren't debugged as well either, so you're not the only one looking bad
16:38 Company: the bad thing about Vulkan is that all the apps are coded against those drivers and not against the spec
16:39 alyssa: Company: so like gl
16:39 Company: yeah, but gl has had 20 years to get apps and drivers to agree on most stuff
16:40 Company: and even write it down sometimes
16:42 Company: I merged the new GTK renderer today, which can do Vulkan and GL - and now I'm wondering how to select which one to use
16:42 jenatali: alyssa: Our driver has a post-process pass on the XFB buffer to produce a correct output
16:42 Company: because GL is gonna be safer and Vulkan is gonna find all the bugs
16:42 alyssa: jenatali: Oof.
16:42 jenatali: We also do some shenanigans with queries to return correct primitive counts IIRC
16:43 alyssa: jenatali: Oof.
16:43 jenatali: Yeah
16:43 jenatali: I still doubt it's all right, but we try at least
16:44 Company: Is that stuff even used a lot?
16:45 Company: or is this more a case of "make it work well enough so it passes the tests"?
16:46 alyssa: #2
16:49 jenatali: Agreed
16:49 jenatali: The pieces might individually be useful but the combinations absolutely aren't
16:52 Company: so it's a case of doing it wrong when thinking about how it's broken
17:15 soreau: Company: if GL is safer, make it the default and an env var to pick vulkan?
17:16 soreau: Then later, you can switch on Vulkan by default and make phoronix again
17:16 Company: that's how it works already
17:17 Company: but the question is how to determine if that magical "later" has arrived
17:18 soreau: testing, CI, etc..
17:19 soreau: maybe if GL setup fails, try Vulkan before falling back or whatever
17:20 Company: that's also already how it works
17:20 soreau: sounds like you have most loose ends tied up, I assume you aren't going to try zink internally or anything
17:22 soreau: but somehow I doubt folks will complain that it's GL and not Vulkan unless stuff just isn't working
17:23 Company: yeah, but I'd expect "stuff just isn't working" to be more common on Vulkan
17:23 Company: and people aren't complaining either way I don't think
17:23 Company: it's not like anyone but me does performance measurements of GTK
17:25 JoshuaAshton: I would have thought Vulkan would have been pretty robust given the insane shit the majority of games do
17:26 Company: depends - because desktop apps often do the things that games don't do
17:26 JoshuaAshton: Curious as to what you have in mind
17:26 JoshuaAshton: From my perspective desktop apps draw textured quads and not much else :frog:
17:26 Company: yeah
17:26 Company: in that sense that's pretty easy
17:27 Company: the problem is that desktop apps (or rather: toolkits) don't know what they are going to draw
17:27 Company: like, there might be an image viewer deciding to load 5000 images
17:28 Company: and then your vram is full
17:28 Company: or a text editor goes and zooms out and suddenly your command buffers get insanely big
17:28 pac85: That's a problem regardless of vk or gl through isn't it?
17:28 JoshuaAshton: Depends whether you defer resource uploading until first use or not
17:29 Company: GL does better memory management than Vulkan
17:29 JoshuaAshton: Well, VK does no memory management by design
17:29 JoshuaAshton: that is on you now
17:29 Company: yeah, and GL knows what it's doing and I don't
17:29 JoshuaAshton: It is still probably safe-ish though as long as you aren't using bindless
17:30 JoshuaAshton: TTM will page in/out the BOs related to the images you use in your descriptor sets per-submission
17:30 Company: yeah, but you only figure out you messed up when it's too late
17:31 Company: because it's often not me but the app developer or their users who experience it
17:32 Company: and if GTK screws up its GPU stuff, people blame GTK, not the app
17:32 Company: because the other toolkits don't have that problem
17:32 JoshuaAshton: Shout out to all the "gamescope crashes" that are actually just device loss from a game
17:32 Company: whereas if a game screws up its gpu stuff, people blame the game, not the engine
17:33 Company: which is as it should be - but it means I need to judge things differently than games
17:33 JoshuaAshton: At least on AMD discrete you don't have that to worry about, if either side fucks up then absolutely everything goes down ;D
17:34 Company: that's why I'm developing on AMD discrete!
17:34 Company: and in F39 I'm only thrown back into gdm and don't have to reboot, so progress
17:34 JoshuaAshton: Yeah
17:35 Company: that's another thing I haven't thought about much - how to deal with the fact that the GPU is shared
17:35 JoshuaAshton: On Steam Deck at least only the game should die... but some recent gamescope crashes seem to indicate there might have been some regression there in 3.5 that we need to prod at
17:35 Company: people tend to open 20 apps and then launch their game
17:36 JoshuaAshton: There is not much that you can do aside from: don't render when you don't need to, and maybe give yourself a low queue priority.
17:36 Company: I was mostly thinking about freeing the memory
17:36 JoshuaAshton: Eh that's not your job
17:36 JoshuaAshton: TTM can deal with that
17:37 JoshuaAshton: If we had explicit residency, you could manually page things out
17:37 Company: but the usual GTK app needs a few 100k of vram, so meh
17:38 Company: but the fun stuff are always the exceptions
17:38 Company: and yeah, me not having a clue about memory management is one of the examples why Vulkan might be worse than GL
17:39 JoshuaAshton: AIUI, the GL driver isn't automatically freeing memory and reuploading behind the scenes when idle and is simply relying on TTM manage residency, so you also shouldn't need to do anything
17:40 Company: good to know
17:40 Company: on my rpi only the Vulkan driver OOMs for me though
17:40 Company: but that might be the driver, I didn't investigate that far yet
17:44 JoshuaAshton: One thing GTK will probably need to do is it's own suballocation
17:45 JoshuaAshton: That might be what you are seeing there
17:45 Company: I do that already
17:46 Company: a pretty dumb version, but good enough so far
17:47 Company: things get really slow if nautilus puts every thumbnail into its own VkDeviceMemory
17:47 soreau: Company: does anything vulkan oom, or only your gtk test?
17:47 Company: drivers don't like that
17:47 soreau: like vkcube works or anything?
17:47 Company: soreau: if my test goes oom, the gpu resets and all apps using the gpu go down
17:47 Company: because AMD discrete
17:48 soreau: Company: right but I was asking if other vulkan apps work on rpi
17:48 Company: oh, rpi
17:48 Company: I didn't test that yet
17:50 Company: anyway, if anyone has a good heuristic to select Vulkan vs GL, tell me
17:56 Company: good news: vkcube also crashes
18:01 soreau: Company: Does vulkaninfo work?