00:15karolherbst: I can finally wire up proper nir_validate support in rusticl, but that also requires me to bump to meson 1.2.. oh well.. need it for some of the external crate support anyway.
00:15karolherbst: dcbaker: how much of that already works btw?
00:16dcbaker: karolherbst: all that landed for 1.2 was the core classes and functions unfortunately :/
00:17karolherbst: ahh... so I guess proper crate.io support might come in 1.3?
00:17karolherbst: I kinda want to see something like this: https://github.com/mesonbuild/meson/pull/11856#issuecomment-1586106520 :D
06:25daniels: jenatali: we don’t even manage them though, alatiera isn’t us …
08:23sravn: javierm: Did you consider to pull out the logo stuff from fbmem and place it all in video/logo/*
08:24javierm: sravn: that's an option to. The functions though are named fb_* so probably that should be changed too
08:25javierm: sravn: I actually don't have a strong opinion on this, just wondered and asked Geert since he was touching that
08:25sravn: javierm: Yep, it should be clear this is logo stuff and not core fb stuff
08:25javierm: sravn: agreed. I just noticed that inconsistency so thought that either everything should be in fbdev/core or in video/logo
09:02DavidHeidelberg[m]: eric_engestrom: hey! I'm still looking at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24305#note_2013552 and trying find better approach.. while it would be best to merge it asap, do you have any insight on how to solve this?
10:15maxv: Hi. If I export gbm_bo, is it safe to immediately call gbm_bo_destroy, or should I keep it around while the buffer is used by another process?
10:17emersion: you can destroy the bo immediately
10:18MrCooper: maxv: export to dma-buf fd, or to KMS handle?
10:28maxv: emerson: great, thanks
10:29maxv: MrCooper: dma-buf
10:30MrCooper: then yes, the dma-buf fd keeps the underlying kernel BO alive (a KMS handle wouldn't though)
10:39emersion: MrCooper: a KMS FB would i believe?
10:39MrCooper: yeah, I think so
10:40emersion: did you mean "GEM handle" instead of "KMS handle"?
10:40emersion: and i believe a GEM handle would retain a ref as well
10:41emersion: (modulo the GEM_CLOSE weirdness)
10:42MrCooper: indeed I did, used the Mesa radeonsi terminology
10:43MrCooper: gbm_bo_get_handle may (or may not) return the same GEM handle used by GBM itself, in which case destroying the gbm_bo may destroy the kernel BO and invalidate the GEM handle
10:44MrCooper: so a GEM handle cannot be relied on for keeping the BO alive
10:45eric_engestrom: DavidHeidelberg[m]: I was off yesterday, I hadn't seen your comment yet; IMO stable branches should get `sed /'compare_to: main'/d` since they don't get any benefit from not using the previous push's state, and there is a downside to specifying anything, since I see 3 possibilities: 1) you leave `main` and you get a completely wrong pipeline, 2) you set `XX.Y-branchpoint` and you get a pipeline with everything that has
10:45eric_engestrom: ever changed in the stable branch, or 3) you set it to `staging/XX.Y` and you get the same pipeline as if you hadn't specified anything while working on a release, and when making a release you get a completely wrong pipeline
10:46eric_engestrom: DavidHeidelberg[m]: as for where to document this `sed`, https://docs.mesa3d.org/releasing#making-a-branchpoint would be the place
10:47eric_engestrom: IMO it would be good to have this doc update in the same commit
10:51maxv: One more question: do I understand correctly that in order to resize an EGLSurface created from gbm_surface, I need to release current EGL context, destroy EGLSurface and gbm_surface, and create new GBM/EGL surfaces with the new size? And why isn't there a resizing mechanism for gbm_surface?
10:54zamundaaa[m]: Of what use would a resizing mechanism be? The surface doesn't matter, KMS only works with buffers
10:55maxv: but GBM+EGL is not limited to KMS, as noted in https://mesa-dev.freedesktop.narkive.com/buxk7VLG/gbm-surface
10:59maxv: In particular I'm implementing a wayland client and currently I create an EGLImage from gbm_bo and set it as a gl renderbuffer storage. I know that EGLSurface can be created for native wl_surface, but I'm experimenting with other wayland libraries.
11:54DavidHeidelberg[m]: eric_engestrom: can it look like I wrote it? This part doc isn't my strong side :P
11:55eric_engestrom: haha, I was just looking at your new push
11:55eric_engestrom: I can't parse the first half of your message though?
11:55eric_engestrom: (the "can it look like I wrote it?")
12:05DavidHeidelberg[m]: eric_engestrom: updated, Marge assigned, thanks!
12:49zmike: DavidHeidelberg[m]: have you had any time to make progress on splitting the CI CTS updates for GL versions?
12:50DavidHeidelberg[m]: zmike: I'm working on doing viable package for it, so I guess it counts as yes? :D (not progressed much yet)
12:52zmike: 🤝
13:09dj-death: someone knows of a pass that would eliminate a pattern like a temporary variable stored with a value from a ubo and then read back in the next block ?
13:09dj-death: when the variable could be completely removed and just the load_ubo replacing the temporary variable read
13:10pendingchaos: nir_opt_copy_prop_vars + nir_opt_sink
13:13dj-death: pendingchaos: thanks a lot
13:21dj-death: pendingchaos: doesn't seem to work on temporaries
13:22dj-death: nir_variable_mode ignore = nir_var_read_only_modes & ~nir_var_vec_indexable_modes;
13:25dj-death: or maybe reading this wrong :/
13:29pendingchaos: temporaries shouldn't be in nir_var_read_only_modes
13:45dj-death: pendingchaos: maybe my case is too complex then
13:46dj-death: pendingchaos: it's a vec2[24] loaded with a bunch of vec2 sequentially from a UBO (like memcpy exactly) and then there is an indirect indexing in the temporary array
13:47dj-death: pendingchaos: do you happen to know if this pass can deal with that?
13:47pendingchaos: I don't think it can
13:48pendingchaos: maybe if the copy was done with a copy_deref intrinsic?
13:49pendingchaos: would probably also remove the need for nir_opt_sink
14:13dj-death: pendingchaos: ah damn, this is not a contiguous UBO array unfortunately
14:17maxv: Do you think implementing gbm_surface_resize is desirable? I think it should be pretty easy and I probably can do it, but I'm not sure if something like this would be accepted.
14:18emersion: is it cumbersome to destroy and recreate?
14:19emersion: because that's exactly what happens when a surface is "resized" AFAIK
14:19alyssa: gfxstrand: !24326 is teaching me about the limits of gitlab
14:22gfxstrand: alyssa: Well, yes. Someone's got to stress-test the system. :joy:
14:25maxv: emersion: It kinda is. When resize happens some buffers are locked and wait for a release event. gbm_surface_destroy docs say that all buffers need to be released and EGLSurface destroyed before calling it. This leads to a state when multiple (maybe even more than two) surfaces must exist at the same time, which is awkward.
14:27maxv: The context switch also seems unnecessary
14:27alyssa: gfxstrand: do they? my 1-line NIR patches usually stress the system just fine ;~P
14:36dj-death: pendingchaos: would you happen to know what would vectorize scratch load/stores? :)
14:41alyssa: dj-death: i/o vectorizer can't do it?
14:41alyssa: er
14:41alyssa: load/store vectorizer
14:41alyssa: nir_opt_load_store_vectorize.c
14:41pendingchaos: the load/store vectorizer could probably be made to do that, if they aren't derefs
14:41pendingchaos: before deref lowering, nir_opt_combine_stores/nir_opt_cse is part of a solution
14:41alyssa: i guess that doesn't do scratch
14:43alyssa: that thing scares me ngl
14:43pendingchaos: I think that was because AMD hardware doesn't benefit from vectorizing scratch access
14:43pendingchaos: but I don't think that's actually true, so I'm not sure why it doesn't do scratch
14:48alyssa:needs to setup load/store vectorizing on agx, we'd benefit
14:49alyssa: (and I'm working on a lowering pass that emits piles of scalar stores in a row that are just begging to be vectorized. not trivial to emit them as vector, loop unrolling happens in the middle)
14:53dj-death: also _nir_shader_variable_has_mode asserts on temp
14:54dj-death: but anyway I probably want to find some other trick
14:54dj-death: maybe promote those UBO loads to shared memory
14:56dj-death: ah but no, it's not going work for FS :/
14:59dj-death: pendingchaos: will you send a fix for the lower_shader_calls ?
15:00dj-death: pendingchaos: I can Rb
15:00pendingchaos: the "resume_shaders[i]" thing?
15:00pendingchaos: I don't have any way to test that it does anything, at the moment
15:00pendingchaos: If I'm reading stuff right, RADV doesn't use this load/store vectorizer yet
15:01pendingchaos: if I get it working, I guess I can make a fix
15:07dj-death: okay I can test it
15:07dj-death: we use it
15:16pendingchaos: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24334
15:54zmike: what's the difference between nir_intrinsic_io_xfb and nir_intrinsic_io_xfb2
15:55zmike: oh
15:55zmike: 😬
15:56dj-death: it's twice as good
15:56zmike: twice as incoherent :/
15:56dj-death: that's so true for intel
15:56zmike: as you know I test everything on intel first
16:51mareko: zmike: xfb describes xy and xfb2 describes zw channels
16:53mareko: it's also twice as good
17:07dj-death: pendingchaos: yeah enabling vectorization of scratch load/store seems to massively improve things
19:22dj-death: people know of a NIR pass that groups the scratch loads/stores
19:23dj-death: in particular if the stores are in the block just before the loads which are in an if block
19:23dj-death: sounds like GCM would do that, but that doesn't seem to deal with variables
19:27dj-death: ah... store_scratch is not marked a reorderable
19:28dj-death: nor store_deref apparently
19:45alyssa: dj-death: can't move stores across loads
19:45alyssa: CAN_REORDER is a pretty blunt flag
19:49anholt: daniels: do you have some time to actually do dri image format #define collapsing?
19:50dj-death: alyssa: I meant just move then before the loads
19:50dj-death: alyssa: in the same if block
19:51dj-death: alyssa: avoiding a bunch of writes if it's not going to be used
19:55cwabbott: dj-death: you can't sink stores into an if except if you know that the store won't be used after the if
19:56cwabbott: I don't think we have anything ATM that can do that type of analysis
19:57cwabbott: it would probably have to use derefs in order to know what could potentially be a use
19:59dj-death: cwabbott: yeah, the shader I'm looking at has that one temporary variable written entirely just before an if block that will read from it
20:04daniels: anholt: I think it's going to become ~necessary, so yeah
20:05anholt: daniels: looks like the #defines aren't abi any more, which is great.
20:05anholt: I think we can #define them to PIPE_FORMATs then just start deleting no-op code.
20:06daniels: anholt: you mean __DRI_IMAGE_FORMAT?
20:06anholt: yeah
20:11daniels: anholt: ok, neat - I guess pull that up to src/util/, then into a table which adds canonical conversions to at least DRM_FORMAT as well as sizes/shifts, then start pulling all the hand-rolled conversions?
20:15anholt: daniels: I was thinking that basically once you #define to PIPE_FORMAT/MESA_FORMAT in the header, one could start just collapsing the lookup tables translating between them. and then, you can probably delete the shifts/offsets from those tables since you should be able to get them from the format descriptions.
20:15anholt: not sure we need to build a new thing first
20:25daniels: anholt: ah yeah, so it is
20:29alyssa: hero
20:38zmike: still waiting on driver rbs for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24117
20:39zmike: don't get left behind
20:39zmike: review now before your driver is broken!
21:11alyssa:pretends to be a lima developer
21:12alyssa: zmike: I think that MR will let us compile VS prologs at CSO create time
21:12alyssa: so that's nifty
21:14zmike: 💪
21:19airlied: zmike: you know the wierd things, what is EXT_depth_clamp_zero_one and why does mesa expose it only for anv and badly at that? :-)
21:19zmike: well
21:20zmike: it's for clamping depth to zero and one
21:20zmike: so it can't go negative or unrestri,cted
21:20zmike: but I can only answer that part of the question
21:21alyssa: for Z32F?
21:22airlied: so hasvk seems to expose it properly, anv half exposes it, neither of them deal with VkDeviceCreateInfo accepting the feature extension
21:23airlied: though maybe that is magic now
21:23Sachiel: that is magic now
21:23airlied: ah I loves the magic
21:24alyssa: can't have bugs if magic
21:24alyssa: or something
21:25airlied: ah so the driver just doesn't seem to care if the ext is set or not
21:25alyssa:vaguely apologizes
21:25airlied: which maybe is fine
21:25Sachiel: yeah... we do that a lot
21:25Sachiel: I don't see hasvk setting the feature bit though
21:26Sachiel: not sure if that's intended
21:26airlied: hasvk sets it directly in features->
21:26Sachiel: ah, yeah, hasvk doesn't use magic
21:26airlied: as opposed to magic
21:27alyssa: why is hasvk in tree
21:34alyssa: anarsoul: could I get an ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24341 ? thanks :)
21:35alyssa: it's enunes' code, just split off from the draft MR
21:35anarsoul: hmm, I thought that enunes is working on it
21:35anarsoul: sure, let me take a look
21:35alyssa: the draft MR has ppir working and gpir not working
21:35alyssa: I split off just the ppir commit so that can land now, while gpir gets sorted
21:36airlied: alyssa: where else would it be? probably has more users than panfrost :-P
21:36alyssa: airlied: good point, let's kick out panfrost too ;~P
21:36airlied: like why is anything in tree? let's just kick it all out to other trees
21:38alyssa: ambitious!
21:38alyssa: =D
21:39anarsoul: alyssa: It's quite a change, I'll take a look later tonight, I made a note for myself
21:40alyssa: anarsoul: thanks!
21:40alyssa: (enunes wrote it and says deqp is happy, and I reviewed it with my NIR hat on and I'm happy, I just don't want to randomly merge it without an ack since I pulled it off a draft MR)
21:42anarsoul: why not to ask for enunes' ack then? :)
21:43alyssa: I would also accept that ;~P
21:46enunes[m]: alyssa: anarsoul: I'll get back to that in the next days, unfortunately didnt have much time to followup on it since the weekend
21:47alyssa: enunes[m]: thanks :) can I land the ppir commit now though?
21:48alyssa: (would let me busy myself deleting abs/neg/sat)
21:49anarsoul: enunes[m]: btw, are there any functional changes? or differences in shader-db?
21:54enunes[m]: as far as I could tell no changes in deqp or piglit for that patch, CI should confirm that, but shaderdb takes a hit
21:56enunes[m]: minor things can be improved on that patch like the remaining is_ssa and removing reg_base, but I don't necessarily object going with it now if it helps unblock work...
21:58enunes[m]: if anarsoul is ok with it merge it :)
21:58anarsoul: can I see shader-db diff first?
22:03enunes[m]: I don't have it at hand now
23:01Kayden: zmike: thanks for the heads up, testing a tidied iris patch now
23:03zmike: I've been pinging for two weeks and I'll probably need to ping for another two before it has a chance of landing
23:03zmike: the struggle of refactoring 🤕
23:04Kayden: yeah :(