01:53sarbes: alyssa: I might have found an argument to have a normalize() op in NIR. The shaders/godot3.4/40-51.shader_test of the shader-db is doing a "normalize(1.0 * normalize(1.0 * xyz))", which seems a bit silly. I'm sure it could be optimized via a NIR pass to a "normalize(xyz)" (instead of "normalize(normalize(xyz))" as it is right now).
01:54sarbes: Or is there a similar optimization pass for GLSL?
01:54sarbes: I know it is a weak argument, but still...
01:55HdkR: Is that godot trying to FTZ NaNs or something?
02:04sarbes: It does not seem to me that the shader is doing some nan trickery. But I'm hardly a floating point expert.
02:05sarbes: Would it be illegal to substitute such a nested normalization?
02:09HdkR: I'm not sure, that shader smells like it was doing some witchcraft to work around a bug.
02:10HdkR: me, not an expert on witchcraft :P
03:08sarbes: Ah, it seems that a normalized vector might not be precise enough, and might have a length != 1.0. That's why some shaders double up.
07:50phasta: If I've got a patch for drm-misc-next that applies fine, but fails for drm-misc-fixes, what should I do? Wait until drm-misc-next gets rebased? mripard
08:48mripard: sima: my point was that we've always considered the first tree in the chain
08:49mripard: sima: so, if we put two trees in MAINTAINERS, there's still going to be only one that gets picked up
08:49mripard: and we can't really change that, because otherwise that means that we would match for DRM or torvalds' tree for every other driver
08:50mripard: sima: and dim aside, I really don't get why we need to put two trees here. It's either maintained through drm-misc or it isn't
08:51sima: mripard, well it is maintained in both trees currently, see the discussion with lynxeye yesterday
08:51sima: and it's not the same situation as drm/linus' git tree, because it's two trees under the one first entry
08:51mripard: we explicitly exclude etnaviv from drm-misc
08:52sima: oh right
08:52sima: would changing that fix it too?
08:52sima: lynxeye, https://paste.debian.net/hidden/9f9fb821/ this one essentially?
08:53mripard: still, I'm not sure why we should make an exception here. it just creates confusion for both maintainers and contributors
08:54sima: well, we have this confusion right now, so documenting it is better than pretending it's not there I feel like
08:54mripard: I'm fine with etnaviv being in drm-misc, I'm fine with being in its own tree, I don't see the point in having it in *both*
08:54sima: personally I'd agree, but it's not where we are
08:54sima: it kinda is in both
08:54sima: same for the other small-ish drivers essentially
08:54sima: *small-ish drivers outside of drm-misc
08:55sima: or maybe this is a bit a forcing function to move more into drm-misc, dunno
08:56sima: but thus far it was always an offer, not a mandate, to have small drivers in drm-misc
08:56mripard: the last PR for etnaviv was in January
08:56mripard: it's de facto where we are
08:56sima: yeah it's about one every odd merge window
08:56sima: for features
08:56sima: and fixes through drm-misc
08:58mripard: and, again, I'm not trying to forcefully put etnaviv under drm-misc or whatever. I'm equally good with it being in its own tree.
08:58sima: but there's some others outside of drm-misc with even less active maintenance
08:58sima: mripard, I guess up to lynxeye to decide which way to clarify this? I think in principle we seem to mostly agree on where we are
08:59sima: I guess current situation could also be covered by officially moving etnaviv under drm-misc in MAINTAINERS
08:59sima: and for the oddball feature pr that could still come from a separate tree
08:59sima: kinda like topic pulls
09:00sima: currently that tree isn't in MAINTAINERS either, so clearly not that important for collaboration outside of the core group
09:01mripard: or, if we put it another way, if there's a patch or a fix or a bug for etnaviv, if we have "shared" maintenance or whatever you want to call it, should I pay attention or can I just let it go?
09:01mripard: basically, I'm ok with paying attention, I'm ok with letting it go, I don't want both group to let it go assuming the other will take care of it
09:01mripard: because that just sucks
09:11mripard: phasta: I'm not sure what you mean, drm-misc-next is never rebased, and how would rebasing drm-misc-next help merge something in drm-misc-fixes?
09:13mripard: phasta: in which branch is the bug you're trying to fix present?
09:15phasta: mripard: The bug is in mainline since years, and the fix is now in drm-misc-fixes. A new patch, not yet applied to drm-misc-next, would cause a merge conflict once the two patches meet
09:16mripard: if the conflicting patch is not yet applied, then just merge the fix in drm-misc-fixes and let the contributor deal with the conflict?
09:17mripard: and / or wait for the next rc to be merged in drm-misc-next, or fix the conflict when applying the drm-misc-next patch
09:19phasta: The conflict doesn't occur in drm-misc-next yet :)
09:19phasta: I guess I'll just wait until the rc merge.
09:38sima: phasta, mripard if the conflict is simple you can also just push the patch to drm-misc-next and sort out the conflict in drm-tip rebuilding
09:38sima: and give drm-misc maintainers a heads-up here about it
11:31sima: mripard, hm yeah, the superposition state really isn't that great after pondering this some more
11:42tomba: How did this go again... I have two fixes for commits in drm-misc-next. As we're in -rc6 now, I think I should push the fixes to drm-misc-next-fixes. But drm-misc-next hasn't been merged to drm-misc-next-fixes. Should I wait until drm-misc-next-fixes is updated, and then push the fixes there? Or something else?
11:45mripard: tomba: we did a late PR and I was waiting for it to be accepted before opening drm-misc-next-fixes
11:46mripard: tomba: I'll open it to last week's tag, and we can always backmerge this week PR if we need to
11:48tomba: mripard: alright
11:48mripard: tomba: it sohuld be good now
11:48tomba: mripard: yep, I see the to-be-fixed commits in drm-misc-next-fixes now. thanks!
18:10K900: Hey folks, can someone give a quick +2 on a one line change fixing gfxstream build on 32-bit platforms? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36231
18:18K900: Thanks zmike :)
18:19K900: Also if anyone wants to backport it to 25.2, please do, if not we'll just ship it as a patch in NixOS
18:19K900: (I would but I have no idea how)
18:41jenatali: K900: Add Cc: mesa-stable as a trailer on the commit message, or add Fixes: <commit> ("<commit title>") as a trailer
18:41jenatali: Or post a merge request targeting the staging/25.2 branch
18:41K900: Too late now I think
18:41K900: It got merged
18:41K900: OK I can do that
18:43K900: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36233, thanks :)
18:44austriancoder: Is there a way that a gallium driver can request a handful of extra sampler_views from st for a specific draw?
18:44karolherbst: austriancoder: why do you need extra sampler views?
18:45K900: (25.1 does not have that log line, FWIW)
18:46austriancoder: karolherbst: lowering one texture fetch multiple texture fetch's (with different lod addresses)
18:46karolherbst: different lod addresses, you mean you need to lower selecting a specific lod or what's the purpose here?
18:48austriancoder: karolherbst: lowering 128 bit texture sampling to 2x 64 bit texture sampling and combining the values in the shader - I have something working and I am in the cleaning up phase. framebuffer state handling was easy, but the sampler view thing needs lot more work and would love if st can support me
18:49karolherbst: you'd bind the same sampler view twice?
18:49karolherbst: but that would kinda run into issues with the sampler view limits, no?
18:50austriancoder: karolherbst: its not that easy, as the 128 bit thing is split into two 64 bit formats - I need two sampler views.
18:50austriancoder: karolherbst: yes .. that's where st would help
18:51karolherbst: 128 bit format as the pixel is 128 bits?
18:53austriancoder: e.g sampling from RGBA32F is done via two RG32F sampler views (with different lod addresses into the same resource)
18:53karolherbst: anyway, I don't know of st handling that for you, but it would basically mean you'd have to half your exposed sampler view limit and then on the shader side index n maps to n * 2 or n * 2 + 1 depending on the format, and I guess you'll just have to handle the binding yourself if you need an extra sampler view
18:54jenatali: That sounds pretty broken to me
18:54karolherbst: other frontends would also need to support it which in the end is just a driver lowering thing
18:54austriancoder: st does it for multi-planar YUV already - but that feature is used by more then one driver
18:54karolherbst: mhhh
18:55austriancoder:fears the moment to create the 128bit emulation MR and I get told I should have done it differently
18:56austriancoder: but yeah .. I will find a way to do it in the driver
18:58karolherbst: I don't really have an opinion on what's the best way to deal with it from a st perspective, just that then other frontends would also have to deal with it
18:58karolherbst: yuv is already enough opengl specific that it doesn't really matter
19:03karolherbst: austriancoder: maybe you can support it through a set_sampler_views wrapper? But dunno.. something has to create the additional sampler views and tidy them up loater...
19:03karolherbst: maybe a helper function...
19:03karolherbst: or two
19:04karolherbst: but that also kinda sucks, because you might want to keep those sampler views for longer
19:05austriancoder: might be as good as my framebuffer state wrapper - worth giving it a try
19:07karolherbst: but also cursed that your hardware only supports RG32F and not RGBA32F
19:09austriancoder: yep
19:09austriancoder: the blob does the same "trick" to work with two samplers - so it is possible to pass gles3 cts :)
19:10karolherbst: how many sampler views can you bind in total?
19:11karolherbst: I hope it's not something ridiculous low as 16
19:12karolherbst: though I highly doubt any hardware has this low limits for sampler views
19:12karolherbst: CL needs 8 minimum, with your trick that means 16 (full profile needs 128)
19:13austriancoder: 16 per shader stage
19:13karolherbst: rough
19:14karolherbst: well that's good enough to expose CL images if you also want to advertise 32 bit RGBA formats 🙃
19:15karolherbst: can you support bindless textures/images?
19:17austriancoder: not sure .. need to check with a cts for gles or vk
19:19karolherbst: I was considering faking 128 sampler view slots, by just using bindless ones instead once a kernel goes beyond the limit of bound sampler views
19:24karolherbst: maybe I should improve my sampler and image view handling...
19:27karolherbst: uhhh.. why are sampler views context specific.. annoying
19:27karolherbst: okay, I have ideas why and not sure I want to look deeper :D
19:37HdkR: That's some aggressive join spam.