00:00 jekstrand: Your WSI commit reminds me that we should make a bunch of the WSI wrapper garbage common at some point as well.
00:00 jekstrand: Sounds like a good task for an intern. Too bad I don't have one of those right now...
00:01 airlied: jekstrand: moving the wsi device into the new device common code might make it pretty easy
00:01 jekstrand: airlied: Yeah, we could move it in or we could keep it separate but still make vk_device imply it somehow.
00:46 airlied: jekstrand: one thingradv has a is a deubg feature to enable all entry points
00:56 airlied: jekstrand: and radv also has the sqtt dispatch table
01:14 airlied: jekstrand, bnieuwenhuizen : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8686
01:14 airlied: wip radv port
01:19 jekstrand: airlied: sqtt?
01:19 jekstrand: airlied: We can easily make enabling everything a common option.
01:19 jekstrand: That's kind-of why I want stuff common. If someone comes up with something clever and useful, I want it for ANV too. :)
01:20 bnieuwenhuizen: jekstrand: some kind of cmdbuffer HW tracing
01:20 bnieuwenhuizen: where we put some markers in the HW cmdbuffer around vulkan commands
01:21 jekstrand: bnieuwenhuizen: Ok. I don't see why common dispatch would be a problem for that.
01:22 bnieuwenhuizen: kinda like a layer except we cheated because we statically knew our next step
01:22 bnieuwenhuizen: I don't know, just providing context :)
01:22 jekstrand: k
01:25 airlied: jekstrand, bnieuwenhuizen I've hooked it up as a device prefix for now to generate things, but have to hook it in
01:25 airlied: bnieuwenhuizen: do we still use the all rentypoints bits again?
01:26 airlied:remembers them being useful in the early days, but not so sure now
01:26 bnieuwenhuizen: I haven't heard anybody complai in ages. I think the last complainant was somebody trying to run it without the loader?
01:27 bnieuwenhuizen: IMO not a problem if you remove the bit
01:37 airlied: jekstrand, bnieuwenhuizen : okay updated the MR I think it should work now
03:04 jekstrand: airlied: \o/
09:25 cwabbott: jekstrand: ping again on !7989... there's only the one vec4 commit deleting code to review, and it already got new merge conflicts
09:27 cwabbott: I'm rebasing it now, hopefully for the last time
09:36 jekstrand: cwabbott: Right. Let me give it a quick look.
09:39 jekstrand: cwabbott: rb
09:39 jekstrand: on the vec4 patch.
09:39 jekstrand: cwabbott: Hooray deleted code!
09:45 cwabbott: ok, the only merge conflict was a trivial radv one
09:59 jekstrand: \o/
12:09 kusma: dcbaker: I just realized that 5282210c0b96f75630a5271a8956f8ae69a0ca1b has the wrong Fixes tag... What's the right way to remedy that? :)
12:10 kusma: It should have been 'Fixes: 3f9a6d333b3 ("zink: export shader image caps using features")' instead...
12:16 emersion: vsyrjala: i'm confused, there is hdr_metadata_infoframe.metadata_type and hdr_output_metadata.metadata_type
12:16 emersion: what's the difference?
12:18 vsyrjala: last time i looked i got too very confused as well
12:19 emersion: :S
12:20 vsyrjala: I guess the higher level thing was added so we could tell different types apart w/o actually looking into the actual medata itself
12:21 vsyrjala: but the display won't even get that higher level thing, so seems pointless for the most part
12:47 cwabbott: jekstrand: just my luck... after doing all this, someone made the robustness shaders no longer use spirv 1.4 so we don't need VK_KHR_spirv_1_4 anymore for VK_EXT_robustness2 once we update CTS...
12:47 cwabbott: still, we should fix vtn
13:51 pendingchaos: kernel+rootfs_arm64 and kernel+rootfs_armhf are broken: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/261153
14:01 unidan: Hi, is egl_khr_display_reference planned to be implemented in mesa?
14:11 pendingchaos: kernel+rootfs_arm64 and kernel+rootfs_armhf seem to be working now
15:00 bl4ckb0ne: could i have a review/merge on this please https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8638
15:27 jekstrand: cwabbott: :-/
15:35 alyssa: How are people's experiences with madvise?
15:36 alyssa: Panfrost has used madv for a while but in my experience, it makes the system significantly _less_ stable, and recoverable OOM conditions end up causing system hangs.
15:36 alyssa: But Intel/freedreno/others? are shipping madv and it's not clear whether we have something seriously wrong with our implementation or what.
15:39 alyssa: The failure case seems to be overzealous memory allocation --> madvise cleaning the BO cache --> all the reclaimed memory getting reallocated immediately after for the next frame's command buffers --> repeat.
15:41 alyssa: And since madv eviction is a bit of a "stop the world" operation, that functionally can cause a hang. (I also suspect we have multiple kernel bugs in the implementation when evicting...)
15:52 ichernev: hello guys, Is this the right chat for simple-panel related kernel inquiries
15:52 alyssa: Probably
16:12 robclark: alyssa: we had a few madv related kernel bugs that were fixed along the way.. I don't think anything fundamentally wrong w/ madv but there are plenty of ways to screw up implementation in ways that only show up under memory pressure
16:17 alyssa: robclark: I see.. does fd not have troubles with user/kernelspace "fighting"?
16:17 robclark: "fighting"?
16:17 alyssa: (Note that we allocate command 'buffers' from the same cache as textures, possibly discriminating madv based on usage might help.)
16:18 alyssa: Kernel evicting something that userspace has to allocate the next frame anyway, so you haven't saved memory, you've just disabled the BO cache and added huge amounts of overhead.
16:18 robclark: we do split bo cache, cmdstream has it's own.. but largely because we used to vmap cmdstream buffers on kernel side more frequently
16:19 robclark: I mean when the system is low on memory, it's low on memory
16:19 robclark: I suppose purging things in LRU fashion might be a good idea
16:20 alyssa: We do have userspace LRU eviction, which might be why disabling madv isn't breaking the world.
16:23 robclark: we do as well, but 1sec granularity is too coarse.. somewhere around here I have a branch where I started trying to tune that better
16:49 enunes: hi, I have a question about https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_rg.txt in mesa GLES2
16:50 jekstrand: go for it
16:50 enunes: I added those color formats to lima and it seems to work, but the CTS dEQP-GLES2.functional.fbo.completeness.renderable.texture.color0.rg8 gives this: https://paste.centos.org/view/raw/f2f81dc2
16:50 enunes: so... the extension is on GLES2, but it fails because it says attaching that texture should only be successful on GLES3, does that make sense?
16:51 jekstrand: Maybe the CTS isn't aware of the extension? That seems off...
16:51 enunes: mostly this * Unsupported texture format * requires any of the extensions or combinations: - GLES3 compatible context
16:52 enunes: yeah, I think it can be a bug in the CTS
16:52 enunes: I'm using the same tag that mesa CI uses
16:53 jekstrand: If you can figure out how to fix it, you can make a MR against https://github.com/KhronosGroup/vk-gl-cts
16:53 jekstrand: Or you can file a bug
16:54 enunes: I did try a local change that "fixes" it, just want to make sure I'm not missing anything from that extension spec
16:54 enunes: change in the CTS
16:54 jekstrand: The extension says it's written against 2.0
16:55 jekstrand: I'm not immediately seeing anything
16:57 jekstrand: Looks like RG is core in 3.0
16:58 jekstrand: So it's probably an oversight in the CTS
16:58 enunes: alright, thanks for double checking, I'll file a MR there later then
17:17 alyssa: bbrezillon: I wonder if there is a cheap way to have a 'watchdog' for LRU eviction? so if nothing is rendered after a certain amount of time, we evict the cache
17:18 alyssa: (such that it only triggers when nothing else is happening and only once to keep overhead low)
17:20 alyssa: Probably no portable way
17:37 zmike: is there a functional difference between PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 and PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_R600?
17:37 zmike: it looks like there's two enum values for the same functionality
17:37 bbrezillon: alyssa: a thread running in background, but I'm not sure creating threads in the app back is a great idea
17:39 alyssa: bbrezillon: Linux is missing a lot of async primitives i think :<
17:45 zmike: and on a related topic to PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK, it doesn't seem like u_blitter respects this?
17:46 zmike: imirkin: I guess you'd have some idea here since it seems like a nouveau-related thing
17:47 imirkin: zmike: something to do with swizzles iirc
17:47 imirkin: i.e. whether the border color should respect texture swizzle or not
17:47 zmike: imirkin: right, it's about pre-swizzling the border color
17:47 zmike: but it doesn't seem like u_blitter does that?
17:47 imirkin: nouveau does not use u_blitter.
17:47 zmike: ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
17:47 zmike: that explains so much
17:48 imirkin: iirc it didn't exist at the time, or didn't support what we needed, or ... who knows
17:48 zmike: makes sense
17:48 imirkin: i've looked at using it, but didn't seem easily feasible.
17:49 imirkin: (we have to employ lots of cheating to make it all work)
17:50 zmike: yeah I know the feeling
17:50 imirkin: like doing MSAA blits but without per-sample shading
17:50 zmike: huh
17:50 imirkin: not to mention depth/stencil
17:52 zmike: yes, that's another pita
17:52 imirkin: there's no shader stencil export
17:52 imirkin: so we have to play games
17:53 imirkin: binding ZS as a color buffer, etc
17:53 zmike: nice
17:53 zmike: looking forward to zink on nvidia in the near future
17:53 imirkin: unless it's Z32F_S8 ;)
17:53 imirkin: actually, no we still bind it as color for that
17:54 zmike: time to annoy mareko with another poorly-thought-out u_blitter series I guess
17:55 alyssa: zmike: lol
17:55 ccr: development through passive-aggressive patches?
17:55 zmike: development through trying to write good code but not being that good at writing code
17:56 alyssa: superquestionablecode.blog
17:56 zmike: the name went through a lot of iterations
17:57 ccr: :)
17:58 alyssa: zmike: don't see a difference between the two quirks either fwiw
17:58 zmike: ok so at least I'm not missing anything
18:07 dcbaker: kusma: not as easily as I had hoped :/ It doesn't look like the commit you meant to fix is in the stable branch though
18:13 kusma: dcbaker: OK, so then it probablt doesn't matter
20:17 notgull: Where is the "currentContextTag" field of the gl_context struct set?
20:20 notgull: I can see it gets set in indirect_glx.c on line 125 but I don't see where it gets set in DRI
20:22 ajax: it doesn't get set for DRI, apparently
20:24 ajax: which... do you really need the context tag for anything for a direct context?
20:25 ajax: you're not sending GLXRender commands, so,
20:25 notgull: https://github.com/mesa3d/mesa/blob/master/src/glx/glxcmds.c#L870 mainly because of this?
20:29 ajax: how are you not doing the pdraw->psc->driScreen->swapBuffers() above? this is a direct context and presumably you're trying to swap a drawable you've made current at some point...
20:30 notgull: I am
20:31 notgull: Oh wait, I accidentally pressed "D" in Vim while over that return statement
20:31 notgull: That makes a lot more sense now
20:32 ajax: you're probably right that not setting currentContextTag is a problem though
20:35 Kayden: mareko: is util_live_shader_cache still useful for drivers using NIR? I thought that st/mesa already returned the same pipe_shader_state for programs with identical serialized NIR, thanks to the shader cache stuff there
20:36 Kayden: mareko: I know util_live_shader_cache was written before most of that landed, and is definitely useful when using TGSI
20:48 Kayden: airlied: I'm looking at an old patch of yours, https://gitlab.freedesktop.org/mesa/mesa/-/commit/0ea386128b8fe4a4c0dc32101c4d4dd565723341 - now that I'm looking at it again, I don't think it makes much sense
20:49 Kayden: in the PIPE_CAP_SHAREABLE_SHADERS world, shaders can be used across contexts, so it would seem that binding a pipe_shader_state would have to increment refcounts. and delete should only happen when refcount would hit zero. at which point it cannot be bound in any contexts
20:50 Kayden: same for the idea of sharing the same pipe_shader_state for multiple shaders with identical assembly (thanks to caches)...would need refcounting
20:50 Kayden: it seems like calling delete_vs_state while it's still bound is a state tracker bug
20:51 Kayden: but I also vaguely have this recollection that it was allowed at one point, and did happen...
20:51 anholt: the gallium api is so ill-defined.
20:51 anholt: delete while bound is pretty common, though.
20:51 imirkin: there were definitely situations with surfaces
20:51 imirkin: being bound via one context, deleted via another
20:51 imirkin: which is technically a violation, but hard to prevent
20:51 Kayden: v3d and nvc0 don't seem to do this. radeonsi uses u_live_shader_cache so everything is refcounted
20:52 Kayden: yeah, that's the situation I'm concerned about
20:52 Kayden: it seems like if you allow binding in multiple contexts, deleting can't be in any particular context
20:52 Kayden: so it needs to be refcounted and unbound first
20:52 anholt: v3d's only going to look at the bound shader state at a draw, so as long as you rebind to new thing or null by next draw, you're fine.
20:53 Kayden: ah...while I look at the old one at bind() time, to compare new/old state and dirty things
20:53 imirkin: ah yeah, we never look at the old one in nouveau
21:17 airlied: Kayden: might also have been clover not mesa/st
21:18 airlied: since me playing with compute shaders likely involved clover
21:19 anholt: Kayden: fwiw, I'm thoroughly in favor of the frontend having to keep bound shaders from being deleted.
21:19 zmike: is there a way to go "backwards" in gallium atom updates? for example, I'm doing a sampler-related change which may require a shader recompile, but shader states are updated before samplers
21:20 zmike: I'm trying to move my GL_CLAMP emulation code into st, but this seems to be the final issue
21:24 zmike: or maybe the question should be why gfx shader updates are ahead of sampler updates?
21:24 zmike:has many questions
21:24 anholt: you want current shader state so you can decide what textures at the GL API level need to be bound at the gallium level.
21:24 anholt: you can ignore anything set that the shaders don't use.
21:25 zmike: hmm okay that makes sense
21:25 zmike: I guess that can't entirely be handled by precompile
21:25 Kayden: airlied: that's what I was thinking too. the patch has a comment saying the CSO cache prevents delete-while-bound from happening, because it tracks things. so I was thinking it must have been clover
21:25 anholt: so, if your shader state depends on sampler state, then make sampler updates flag the ST_NEW_*_STATE for the shader and look at the GL API state to decide.
21:25 anholt: (I think)
21:26 zmike: anholt: but it looks like the update loop copies the flags and then doesn't iterate again once they're processed?
21:26 zmike: at the bottom of st_atom.c
21:26 anholt: sounds right to me?
21:26 zmike: yeah
21:26 anholt: not sure what you're getting at
21:27 zmike: well I'm saying that during sampler update I may need to recompile the corresponding shader
21:27 zmike: but by that point the shader updates have been processed
21:27 zmike: e.g., ST_NEW_FS_STATE
21:27 anholt: and I'm saying that when you're computing shader state, you look at GL sampler state. you don't look at gallium sampler state.
21:27 anholt: so you don't depend on the atom
21:28 zmike: right, that's sort of the problem I'm getting at here
21:28 Kayden: zmike: Perhaps what you need is a new ctx->DriverFlags.NewSamplersWithClamp entry, and have mesa/main flag that when samplers change to/from GL_CLAMP
21:29 zmike: I guess I just have to do this part in the driver
21:29 zmike: ooh
21:29 Kayden: and then st/mesa can set that to ST_NEW_<SHADER>_STATE and ST_NEW_SAMPLER_STATE if PIPE_CAP_EMULATE_GL_CLAMP_PLZ is set
21:29 zmike: this seems workable
21:30 zmike: I'm going to use that cap name too even though I was originally going to use another one
21:30 Kayden: please don't XD
21:30 zmike: I've already written the docs for it
21:30 anholt: Please call it PIPE_CAP_GL_CLAMP
21:31 zmike: I was going to call it PIPE_CAP_EMULATE_GL_CLAMP
21:31 Kayden: the Intel HW name for it isn't terrible either
21:31 Kayden: they call that mode HALF_BORDER
21:31 anholt: Kayden: ha
21:31 Kayden: since it blends half the edge texel and half the border color
21:31 anholt: Kayden: emphasizing just what a bad idea it is
21:31 Kayden: so you could have PIPE_CAP_HALF_BORDER = 0 -> emulate it
21:32 zmike: I like having the GL enum name in the cap to make it very obvious
21:32 Kayden: I kind of like it because it describes it very well, and is much more obvious what it does than "CLAMP"
21:32 zmike: that's true
21:32 Kayden: but GL_CLAMP is much more commonly used
21:33 Kayden: as a name
21:33 anholt: +1 to GL_CLAMP
21:33 Kayden: I'm fine with that :)
21:33 Kayden: I don't think that mode exists in any API outside of GL anyway
21:40 bl4ckb0ne: xexaxo1: so there's 1.7 to do before removing wl_shell?
21:40 Kayden: airlied: ah, yeah, it looks like clover is indeed calling pipe->delete_compute_state when various things change, without unbinding
21:41 xexaxo1: bl4ckb0ne: yup, tried to merge the branch earlier but gitlab is failing badly :-\
21:41 bl4ckb0ne: yeah i got an email
21:41 xexaxo1: merge the branch and thus roll out 1.7.
21:42 bl4ckb0ne: want me to rebase it?
21:43 xexaxo1: I meant - gitlab ci is failing to create the image/container. barf during "podman push" - see https://gitlab.freedesktop.org/evelikov/waffle/-/jobs/6874618
21:44 bl4ckb0ne: ah yeah, ci stuff is always painful
21:44 bl4ckb0ne: did you bumped the FDO_DISTRIBUTION_TAG ?
21:45 xexaxo1: yup, it was working fine a few days ago. I'm suspecting some temporary infra glitch.
21:46 bl4ckb0ne: i think there was a gitlab update a few days, might be why
21:50 xexaxo1: nicely spotted, thanks. poked the infra team - fingers crossed they will figure it out easily
21:51 zmike: Kayden: I'm looking into your DriverFlags idea; how do I know which shader to flag for updates from a sampler if I'm in mesa core?
21:53 bl4ckb0ne: id bump the TAG to the present date just in case though
21:54 Kayden: zmike: So, mesa/main just flags ctx->DriverFlags.NewFoo, whatever that may be. Classic "drivers" like st/mesa or i965 set ctx->DriverFlags.NewFoo to whatever they want (like ST_NEW_FOO)
21:54 Kayden: (or 0 if they don't care about that)
21:55 Kayden: that way "drivers" (again, st here) can pick whatever flags they want for a scenario
21:55 zmike: Kayden: right
21:55 zmike: I've set that up
21:55 zmike: e.g., f->NewSamplersWithClamp[MESA_SHADER_VERTEX] = ST_NEW_VS_STATE | ST_NEW_VS_SAMPLERS;
21:56 zmike: but I'm not sure how I'd know which shader stage to flag just from sampler param changes
21:56 zmike:is less an expert in mesa core than gallium
21:56 Kayden: ah, because it's just a sampler changing and you don't know what stage it is
21:56 zmike: right
21:56 Kayden: or what stages might reference that
21:57 Kayden: I think you'd just want to flag them all
21:57 zmike: can do 👍
21:57 Kayden: that's a bit overkill but it's easier than going and looking at what shaders might reference the samplers
21:57 zmike: right
21:57 Kayden: and the consequence of overflagging is that the st shader atoms trigger more often than necessary
21:58 Kayden: but it should only happen if something suddenly starts/stops using GL_CLAMP
21:58 Kayden: at which point...it's OK to punish people
21:58 zmike: haha
21:58 Kayden: the main thing is to avoid punishing people who don't use GL_CLAMP :)
21:58 zmike: right
22:11 alyssa: jekstrand: Would you be interested in syntax sugar for nir_push_if and friends?
22:12 jekstrand: alyssa: I thought they were pretty sweet already but I'm happy for them to be bade better.
22:13 alyssa: bbrezillon came up with `for (nir_loop *l = nir_push_loop(b); l != NULL; nir_pop_loop(b, l), l = NULL)
22:13 alyssa: `
22:13 alyssa: and then you can write `nir_build_loop { whatever }` and so forth and it feels a bit more natural for constructing big shaders with ugly control flow
22:13 xexaxo1: Dr Freud would be amazed - made + bad = bade ;-)
22:14 alyssa: I was put off when I first saw them in review but it's sort of growing on me the more I think about it
22:14 jekstrand: alyssa: Yeah, that's not bad.
22:14 alyssa: And having them in nir_builder.h instead of vendored to a single file would make me feel less bad about them ;P
22:15 jekstrand: alyssa: I often do nir_push_loop(b, thing) { stuff } nir_pop_loop(b, NULL) and go ahead and indent "stuff"
22:16 jekstrand: Not quite as suggary but it still gets the point across and gives you a scope on the stuff in the loop
22:18 Venemo: jekstrand: how mad would you be if I proposed to remove the union from shader_info so that one shader info can hold the info of multiple stages at the same time?
22:19 jekstrand: Venemo: Not angry but maybe confused
22:19 Venemo: I know this'd increase the memory use for everyone, but would this be severe?
22:19 Venemo: jekstrand: confused how?
22:19 jekstrand: Venemo: I don't understand what we gain from having multiple stages supported
22:20 jekstrand: Other than less liklihood that gather_info will accidentally stomp something it shouldn't
22:21 Venemo: jekstrand: are you familiar with our merged shaders? I finally mustered the courage to work on doing those in NIR
22:21 Kayden: ah...
22:22 alyssa: jekstrand: see the function update_vertex_attribs in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8700.patch for what's motivating this
22:22 Venemo: This means that I will have a NIR pass which will merge them before they get to the backend
22:22 Kayden: where you run e.g. both the VS and TCS together in a single shader
22:22 jekstrand: Venemo: Oh...
22:22 alyssa: (Indirect draws are implemented by a massive compute shader monkey patching the cmdstream. Even on the blob.)
22:23 jekstrand: Venemo: I guess that makes sense
22:23 jekstrand: Venemo: What do you intend to do with info.stage?
22:23 Kayden: bitfield of stages? or....?
22:24 Kayden: seems like that could make a real mess of a lot of assumptions across the codebase
22:24 alyssa: Yeah, I'd be very nervous
22:24 Venemo: info.stage can be the later stage, that will be self explanatory
22:24 Kayden: ah, the stage it actually runs on?
22:24 alyssa: Venemo: where do you plan to merge stages?
22:24 alyssa: (and this is for radv I guess?)
22:24 Kayden: (it actually -is- a TCS, it's just also running VS functions too?)
22:25 Venemo: The possible combinations are VS+GS, VS+TCS and TES+GS
22:26 imirkin: Kayden: amd bundles stuff together, so it'll run e.g. a merged VS + GS in one stage. etc.
22:26 imirkin: (if there's no tess)
22:26 Venemo: Currently we bolt these together in the backend, and each 3 backend (RadeonSI/LLVM, RADV/LLVM and RADV/ACO) has to reimplement the logic to handle them and the I/O between them
22:27 bnieuwenhuizen: the other option would be to extract the shader_info before the merge and not use the per-stage stuff post-merge at all?
22:27 alyssa: bnieuwenhuizen: ^ was going to suggest that hence why I asked when the merge happens
22:27 bnieuwenhuizen: I presume that as part of the merge we lower a bunch of IO into intrinsics anyway so it is not using the nir standard for IO anymore
22:28 Venemo: Yes, bnieuwenhuizen that is also a possibility, but then we'd have to store the 2 shader info's somewhere
22:28 alyssa: That seems like an easier problem
22:28 Kayden: or maybe a new merged_shader_info
22:28 Venemo: However, the info ain't just about I/O
22:28 bnieuwenhuizen: Venemo: we can pass them around just like the radv shader info or shader keys
22:28 Venemo: So, yes, I lower all I/O to memory intrinsics, but there's other info we might need
22:29 Venemo: That's exactly what I wanted to avoid
22:29 Venemo: Don't wanna invent yet another shader info
22:31 bnieuwenhuizen: okay, random question: what do we need to keep the per-stage info around for ?
22:31 alyssa: struct { nir_shader_info vs, tes, gs } -- that doesn't suffice?
22:32 bnieuwenhuizen: like I think we can fill in all the required bith in radv_shader_info at merge time instead of at backend compile time?
22:32 bnieuwenhuizen: all the required bits that depend on the nir shader stage info*
22:32 Venemo: Well, if you look at what the shader info has, there is more than just IO info, and we'd need to store that somewhere
22:33 bnieuwenhuizen: in the radv_shader_info?
22:34 bnieuwenhuizen: though maybe just amking it a struct instead of an union ain't the worst
22:34 Venemo: also we might still want to do some NIR passes on the merged shader
22:35 Venemo: For cross-stage optimization
22:35 bnieuwenhuizen: but those shouldn't need the per-stage bits because the standard per-stage IO intrinsics aren't used anumore
22:37 bnieuwenhuizen: and if you also rename stage->stage_bits or something I think we can do that change fairly safely
22:37 Venemo: I don't wanna change the stage
22:38 Venemo: Would be too much refactoring for 0 benefit
22:42 Venemo: alyssa: the merge would happen pretty late, on fully lowered shaders. I'm considering whether it's worth to optimize the merged result. There isn't likely to be much benefit
22:42 Venemo: Maybe GCM could do some magic there evetually
23:02 alyssa: This might be too many layers of macro magic.
23:02 alyssa: `nir_build_if(..) { foo } else { bar }`
23:36 zmike: Kayden: I got it working 🎉
23:37 zmike: thanks for the ideas!
23:38 alyssa: Is uclz(~0) defined?
23:39 alyssa: looks like that's equal to -1, if I'm reading the const folding right
23:41 imirkin: iirc that should be 0
23:42 imirkin: as there are 0 leading zero's
23:42 Kayden: zmike: \o/