03:19 airlied: karolherbst: jog my memory, I have a CL spirv with global int *values as a kernel input, and it's SPIRV has crossworkgroup, and it's choking vtn
03:19 airlied: is that something that I'm just doing stupid?
03:24 jenatali: airlied: Choking where? I've seen that working just fine in our d3d12 branch
03:31 airlied: jenatali: SPIR-V parsing FAILED:
03:31 airlied: In file ../src/compiler/spirv/vtn_variables.c:1780
03:31 airlied: vtn_var->mode == vtn_variable_mode_ubo || vtn_var->mode == vtn_variable_mode_ssbo || vtn_var->mode == vtn_variable_mode_push_constant
03:31 airlied: 532 bytes into the SPIR-V binary
03:31 airlied: is the first thing I see that's wierd
03:31 airlied: granted I'm in a very wierd scenario, so it's likely I'm missing some pieces of the puzzle
03:31 airlied: I should probably test on llvmpipe/opencl first :-P
03:34 jenatali: airlied: Haven't seen that one, I'm curious, what decoration is it?
03:36 airlied: cross workgroup
03:39 jenatali: I think I'm missing something, that's not a decoration, is it?
03:39 jenatali: (Unless I'm misreading which assert is firing)
03:40 airlied: vtn_variable_mode_cross_workgroup is what vtn_var->mode is
03:41 jenatali: Right, but the assert's firing because there's a decoration op being processed. I'm curious what the decoration is that's supposed to be applied to that variable
03:41 airlied: oh let me see
03:43 airlied: ah LinkageAttributes
03:44 jenatali: Seems like you've got some SPIR-V that hasn't been fully linked
03:47 airlied: yeah it looks like that alright, though that decoration is just on a builtin var
03:51 jekstrand: Yeah, OpenCL has linkage stuff. Not a thing in Vulkan so not implemented, most likely.
03:51 jekstrand: Even after the shader has been linked, it can probably still show up.
03:53 airlied: the difference I'm seeing here is acutally a bit more subtle
03:53 airlied: OpEntryPoint Kernel %2 "test_1_mul24_int" %__spirv_BuiltInGlobalInvocationId
03:53 airlied: vs
03:54 airlied: OpEntryPoint Kernel %10 "cmdlist_add_constant"
03:54 airlied: which I think is somethign kherbst fixed in the spirv-llvm translator, but this spir-v might not be generated with that
03:54 airlied: not even sure if that fixes is upstream
03:54 airlied: as it's choking on all the decorations
03:56 airlied: hmm didn't seem to help
03:59 jenatali: Oh huh, I haven't seen those interface IDs used before
04:07 airlied: ah got it, the builtin was in spirv as uniformconstant vs input
04:07 airlied: which I htink is fixed in the translator, but is a mess anyawys
05:37 danvet: airlied, seems indeed something funny going on with patchwork and pull
05:37 danvet: just tried to find the link there to agd5f latest pull, didn't find it
05:38 danvet: hm or maybe I'm looking at the wrong thing
05:53 airlied: danvet: I sometimes find some in intel-gfx not in dri-devel as well
05:54 airlied: danvet: I have to learn to check manually I suppose, and pull them from lore
05:55 airlied: danvet: maybe we can dim to interface to a lore search or something :-p
05:56 airlied: dim list-pulls and dim pull <msgid>
05:58 airlied: danvet: yeah misc-fixes is missing from dri patchwotk
06:00 airlied: and is again on the intel-gfx pw
06:12 dolphin: airlied: the CI results should for previous PR (from same day) should have been uploaded now, there was some sync error
06:32 hakzsam: karolherbst: thanks for the revert
09:04 karolherbst: why is _mesa_set_random_entry using rand() btw? we could also just use a uninizialed value, no? :D
09:05 MrCooper: ask the Debian SSL maintainers ;)
09:05 karolherbst: :D
09:06 karolherbst: yeah.. but even if we always return the first entry from the table, it's still wouldn't change anything for users of that function :p
09:06 karolherbst: it's not even used...
09:06 karolherbst: so .. meh
09:13 HdkR: Need to have a reason for x86 rdrand and ARMv8.5 rndr register :)
09:19 linkmauve: Speaking of randomness, does anyone want to merge this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2026
10:12 pcercuei: modetest doesn't disable the planes that were not selected?
11:45 linkmauve: Ugh, current master segfaults in mpv or gtk4-demo…
11:45 linkmauve: I’ll bisect.
11:49 TheRealJohnGalt: pepp: thank you for looking at #2967. If you'd like I can also try to get a stacktrace for you over ssh. It's a weird one.
11:50 mripard: danvet: hi! I have a case here where the hardware needs a quite precise disable sequence, and that needs to apply it during the firmware -> kms transition, otherwise things go awry. what would be the proper way to force an atomic_disable on the CRTC on the very first modeset?
11:50 mripard: iirc, this was one thing that could be implemented by rolling our own ->reset hook and reading the state from the hardware
11:51 mripard: but I couldn't find any driver that does something like this?
11:55 danvet: mripard, i915 does full hw state readout and transition
11:55 danvet: mripard, is the problem that your sequence is entirely unique for the fw->drm driver takeover
11:55 danvet: or just that the fw leaves the screen on, and if you mess with it the wrong way the chip dies
11:55 danvet: but aside from that normal modeset code can be used?
11:55 mripard: the latter
11:56 mripard: it doesn't really die, but you get a pixel stuck in a FIFO that shifts all the frames later on
11:56 mripard: so not really "my kernel crashed"-bad, but still pretty bad
11:57 danvet: mripard, specific fw setup, or do you face the issue of lots of panels/configs?
11:58 danvet: also, do you want smooth transitions at boot or full disable to all of ok
12:00 mripard: it's at the (HDMI) CRTC level, so it affects all the HDMI outputs, whatever the resolution
12:00 mripard: and I only need a full disable at the moment, but smooth transition could be a plus
12:00 pepp: TheRealJohnGalt: the dmesg output would be useful
12:01 TheRealJohnGalt: pepp: okay. I also believe we actually have two separate issues in those two apitraces. Sorry for putting them in the same issue.
12:07 TheRealJohnGalt: Btw I don't recommend testing on linux 5.5 and 5.6. There's a separate issue only on those cycles that cause a different crash almost immediately. Fine on 5.4 and fixed in 5.7-rc5.
12:13 mripard: danvet: yeah, I guess I could just make a helper and force disable it at boot
12:13 mripard: danvet: out of curiosity, do you remember where i915 implements that hw readout?
12:15 danvet: mripard, it's all i915 specific
12:15 danvet: but if you feel like it, I could explain the big flows/ideas
12:15 danvet: and you could wire it up for atomic-helpers
12:15 danvet: probably useful long-term
12:16 danvet: just a few callbacks in helpers to get started
12:18 danvet: mripard, so if you want I could type up what I think would be reasonable for helpers and send it to dri-devel?
12:19 danvet: it's not much, but a bit much for irc
12:23 mripard: danvet: if you have some time to spare, it would be great :)
12:38 vsyrjala: the i915 readout is still using a bunch of legacy state pointers btw. so not a super great example verbatim. i have some wip stuff in a branch to switch it to pure atomic age stuff, but it probably needs a bit more work still
12:40 vsyrjala: also thinking we might really want a drm_atomic_state for the readout, which i've not yet started to seriously ponder. iirc danvet suggested the same idea in the past
12:40 vsyrjala: so perhaps any helpers for readout should take that apporach from the start
12:41 mripard: yeah, building a drm_atomic_state makes sense
12:42 mripard: however, I wonder if any hardware is able to do that
12:42 vsyrjala: do what?
12:43 mripard: allow to recreate a full blown atomic state from what is stored in the registers
12:43 vsyrjala: i915 pretty much does it. we have a few bits of state here and there we can't read/derive, but not much
12:45 vsyrjala: oh, we are actually missing a full blown readout of plane state. no problem from hw side to actually do it, but so far we've not truly needed it
12:47 vsyrjala: could use it for the state checker though. so maybe one day i'll bite the bullet and just type it all up
12:47 vsyrjala: state checker being the thing in i915 that does a readout after every modeset and then compares the hw and sw states to make sure we programmed the hw correctly
12:48 vsyrjala: we do a limited plane state readout for taking over the firmware fb
12:50 mripard: how does that work without the planes then, it just creates a dumb plane state based on the CRTC dimensions?
12:51 mripard: nevermind, I spoke too fast :)
12:52 vsyrjala: we read out enough of the primary plane state to populate most of the plane state, then we just do an atomic commit the perform an atomic commit which calculates the rest as normal
12:52 vsyrjala: other planes we just force off immediately
12:52 vsyrjala: not that other planes are ever really enabled by the bios
12:55 vsyrjala: hpefully you can parse that sentence :) stopped mid sentence to get coffee and naturally the brain forgot where i actuall stopped
12:56 mripard: I could, there was no need to delay the coffee any further :)
13:15 danvet: vsyrjala, I'll cc you on the mail, spent a bit of time pondering what might be useful and what a bit too much for a helper
13:36 danvet: mripard, typed up way too long email
14:01 mripard: danvet: I'll have a look, thanks!
16:21 austriancoder: does anybody knows applications in the wild that are using scissored clears?
16:36 anholt: tomeu: do you want to look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5033 before merging? refactors a little bit in LAVA
17:56 linkmauve: daniels, or someone else who takes care of GitLab, the Content-Type it sends for patches is wrong, instead of “text/plain” it should be “text/plain; charset=utf-8”, see for instance here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5052.patch
19:14 LargePrime: hi
19:16 LargePrime: in clear linux. latest update unable to boot on SOME AMD gpu. but cannot find any bug reports. clear rolled back to last version. how does one track the bug?
19:36 jekstrand: NIR folks: How would you feel about a nir_jump_kill instruction?
19:37 jekstrand: The semantics being that, if you hit it, the shader is dead.
19:37 jekstrand: It's like a return but for the whole shader.
19:37 jekstrand: or nir_jump_exit
19:37 jekstrand: or nir_jump_terminate
19:42 Kayden: I like nir_jump_terminate or nir_jump_halt
19:42 Kayden: it'd be nice to have NIR represent either demote-to-helper-invocation or terminate-my-program semantics explicitly
19:43 Kayden: could possibly replace discard with one-or-the-other of those
19:43 jekstrand: Right, I'm thinking proper discard could be demote_to_helper followed by jump_halt
19:43 Kayden: or something more complex - I think the current intel driver behavior is something like vote(condition) ? halt : demote
19:44 jekstrand: That would work too
19:44 jekstrand: Well, I don't know if we want to do that direclty in NIR
19:44 Kayden: or yeah demote followed by vote-halt
19:44 Kayden: Possibly not.
19:44 jekstrand: But we could if wew wanted
19:44 Kayden: it's just kind of interesting to be able to
19:44 jekstrand: Proper GLSL semantics being represented by demote+halt would let us easily dead-code stuff after discard
19:45 jekstrand: Really, that's what I'm looking for. An instruction that NIR can reason about being actual control-flow.
19:45 jekstrand: I'm working on an unrelated (to discards) pass and I have a bunch of places where I want to say "delete everything following this instruction"
19:45 jekstrand: It'd be nice if I could just drop in a HALT and have NIR clean it up for me.
19:46 Kayden: yep
19:47 jekstrand: And such an instruction is utterly trivial for us to implement in FS
19:47 jekstrand: We already have it, basically.
19:47 jekstrand: And it wouldn't be hard to lower away if people want it gone. Just rewrite every halt to a return and run return lowering.
19:47 jekstrand: Once you've inlined functions, of course.
19:47 Kayden: right.
19:48 jekstrand: I wonder if SPIR-V has an opcode for this
20:12 thotypous: hi, I got a regression when upgrading from 20.0.6 to 20.0.7. This gpu has been working fine since mesa 19.3.3 when I first started to use it. stacktrace: https://pastebin.com/5h7adYc7 coredump: https://filesender.rnp.br/?s=download&token=5305a619-1c75-475e-a782-b5e3be2f0543
20:12 thotypous: this crash was with Xwayland, but I get crashes in firefox and even random crashes in allacrity
20:13 thotypous: do you think I should rebuilt mesa with debug symbols?
20:13 thotypous: rebuild*
20:17 thotypous: and this is the firefox crash: https://crash-stats.mozilla.org/report/index/7408d387-2134-429f-b23a-af47a0200515
20:28 thotypous: well, building it with debug symbols, wish me luck
20:37 thotypous: this is with AMD, but a friend who has intel hardware just informed he had a similar regression
20:39 st3r4g: thotypous: which distro?
20:39 thotypous: archlinux
20:39 st3r4g: then it's this https://bugs.archlinux.org/task/66666
20:40 thotypous: ah, so they already fixed it
20:41 thotypous: thanks
20:41 thotypous: shame on the mirrors which take too long to update :S
20:41 alyssa:is trying to remove Z32_UNORM from panfrost
20:42 alyssa: noticing that mesa/st maps DEPTH_COMPONENT+UNSIGNED_INT to Z32 unconditionally
20:42 alyssa: it looks like GLES3.2 allows that to map to Z24 (and maybe even Z16)? confused
20:43 alyssa: (Table 8.2 in GLES3.2)
20:43 alyssa: I can't find a similar equivalence in the desktop spec, so I'm wondering if this is an ES weirndess.
20:55 alyssa: Of course, I'd be perfectly actually supporting Z32_UNORM but I don't know the magic bits for it, and it's not in ES anyway
20:56 Kayden: FWIW Intel doesn't support Z32_UNORM at all
20:56 Kayden: just float
20:56 alyssa: Kayden: Okay, in that case, why does everything break when I don't report it as supported.. :
20:56 alyssa: :|
20:57 alyssa: Z24S8, Z24X8, Z32F, Z32F_S8X24 -- should be enough..
21:00 alyssa: glmark2-es2 -bshadow does `GL_DEPTH_COMPONENT, GL_UNSIGNED_INT,` and `GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D,`, but if I don't report Z32_UNORm supported it fails to check as complete.
21:00 Kayden: it shouldn't...
21:00 alyssa: alyssa what did you go and break
21:01 Kayden: I don't see anything in the format choosing code that would require Z32_UNORM for DEPTH_COMPONENT + UNSIGNED_INT
21:01 Kayden: if you advertise that pipe format, it would prefer it because it maps more exactly
21:01 Kayden: but if you just don't support the format at all, then it shouldn't use it
21:01 alyssa: same, except for Z_UNORM32 line in glformats.c
21:03 Kayden: that's just mapping combos to their exact format, but some caller should see that it isn't supported and bail to another option..
21:04 alyssa: Hrm.
21:04 alyssa: regardless patching that doesn't fix it eithe.
21:04 alyssa: maybe I'm setting some bad cap or... hh
21:05 alyssa: Ahhhh
21:05 alyssa: Kayden: In my "is supported?" check, I have
21:06 alyssa: if (bind & ZS) { switch(...) { .... } }
21:06 alyssa: I guess it's checking Z32 without setting the bind, concluding it's supported, then trying to actually do the FBO with the bind and failing
21:06 alyssa: I should maybe just use a format table at this point
21:07 Kayden: I do like having a format table
21:07 Kayden: but yeah, you want to just disallow those formats regardless of bind
21:07 Kayden: because you probably don't support Z32_UNORM as a texture (PIPE_BIND_SAMPLER_VIEW) either
21:07 Kayden: PIPE_BIND_DEPTH_STENCIL is about depth/stencil framebuffer attachments, IIRC.
21:07 alyssa: Right, right.
21:07 Kayden: nice though, that's an easy fix :)
21:08 alyssa: weeee. unfortunately I'm now like 100+ commits divergent from master uhhh