07:39 pq: van... argh
07:40 pq: always off-line when I'd like to reply
11:37 danvet: melissawen, [PATCH 05/24] drm/vkms: Use devm_drm_dev_alloc <- would be great if you can review this one
11:37 danvet: also did you push your maintainers patch already?
11:38 danvet: melissawen, [PATCH 04/24] drm/vgem: Use devm_drm_dev_alloc <- very similar patch for vgem, if you have time for that one too
11:38 danvet: pinchartl, [PATCH] drm/xlnx: Use devm_drm_dev_alloc <- looking for an ack
12:00 pinchartl: danvet: slowly going through my mailbox
12:59 DPA: I've sent my first message to the dri-devel mailing list yesterday (1053506ddfbb352ba0fe96c6576f78fd@abrecht.li), but it seams that ML doesn't deal particularly well with DMARC.
12:59 DPA: I wonder if anyone even got the message...
13:29 cheakoirccloud: https://www.reddit.com/r/vulkan/comments/iotjvb/timeline_semaphores_first_attempt/
14:29 melissawen: danvet, ok! I'll review these two... and I also owe the push. But I'm right now starting to resolve these pending issues. :)
14:37 MrCooper: DPA: I received your post from the list; if the sender address isn't subscribed to the list, it goes through a moderation queue (to keep spam away), which can take up to ~1 business day to process
14:48 pinchartl: robher: back to graph.yaml... :-) what's the right way to get the schema selected ? can the select attribute express that the schema should apply to all "ports" nodes that have a "port(@n)" child ?
15:00 mripard: pinchartl: select makes the rest of the schema to validate if the schema under the select clause is valid
15:02 mripard: so something like that should work https://paste.ack.tf/de8a8c
15:02 robher: pinchartl: I think we'll have a problem that there's no such thing as a 'pattern required' for the port(@n) child.
15:03 mripard: robher: can't we make the assumption that if we have port@(> 0), then we have port@0 ?
15:03 mripard: in which case, we can only require port@0
15:03 DPA: MrCooper: Thanks, good to know.
15:05 robher: pinchartl, mripard: The problem is the schema will be true with no '^port' properties. We'll have collisions with ethernet switch bindings which use 'ports' and then 'port' or 'ethernet-port'.
15:06 robher: There's probably a few cases that don't have 'port@0'.
15:06 mripard: I guess we can match on a child node being endpoint then?
15:08 robher: mripard: Probably. I solved this for dtc already with something like that.
15:09 mripard: but do we really want a select? I guess just referencing the schema would also work, right?
15:09 mripard: and we would have a reference to the fact that it's using the OF graph somewhere in the "main" schema anyway
15:10 pinchartl: mripard: thanks for the explanation about select
15:10 robher: mripard: Yes, that's the other option.
15:10 pinchartl: referencing the schema explicitly would be another option
15:10 pinchartl: it's less automatic, but probably easier to implement
15:11 pinchartl: should we start with that, and then see if we can improve it on top ?
15:11 robher: Though we'll still have a similar problem...
15:11 pinchartl: it would allow simplifying all the schemas that use ports today
15:11 pinchartl: would we ?
15:11 mripard: pinchartl: I mean, like I said, if we're going to have say a camera binding we would have somewhere in that binding that it's using the OF graph
15:11 mripard: so I don't really think we need to have an automatic selection, it's already essentially opt-in
15:12 pinchartl: with select: false in the graph.yaml schema, we would explicitly reference the graph.yaml#ports, right ?
15:13 robher: I don't want to have to say in every review to add a $ref, so we'd need a meta-schema to check that. If 'ports' then '$ref: graph.yaml' required. And then we're back to the same collision...
15:14 pinchartl: I understand, but wouldn't it be a good first step to go for a manual $ref, and improve things on top of that ?
15:14 pinchartl: especially given that most yaml conversions are done by copy&paste
15:15 pinchartl: so if we can get the $ref in the yaml schemas that use the OF graph today, there's a high chance you won't have to repeat it in every review
15:15 robher: Yes. And the meta-schema doesn't have to be 100%, so we could look for 'port@0' and not worry about missing ones with no 0 port.
15:16 pinchartl: ok, I'll start with the schema first and send a patch series. the meta schema will be part of it if I figure out how it works, or may go on top otherwise
15:16 robher: pinchartl: Another game of whack-a-mole. :)
15:17 robher: pinchartl: write the meta-schema and you don't have to search for the cases.
15:17 pinchartl: that means Documentation/devicetree/bindings/graph.txt will disappear. or rather should I replace it with a single sentence that points to the dt-schema repository, as there are .txt bindings referencing it ?
15:18 robher: pinchartl: I can take a stab at the meta-schema.
15:18 pinchartl: thanks, that would be very appreciated
15:18 pinchartl: I'll focus on the schema then
15:31 pcercuei: is it possible to have two DRM applications control one plane each? Or is that only possible with a WM middleware?
15:33 daniels: pcercuei: the latter
15:33 pcercuei: alright, that's what I thought
15:33 pcercuei: thanks
15:34 pinchartl: daniels: speaking of that, any advice on how an application based on Qt with the lighthouse backend (direct DRM/KMS access) could use an overlay plane to display a video blended with the UI ?
15:34 pinchartl: or should I go full weston for that ?
15:35 pinchartl: the platform is an i.MX7 without a GPU
15:37 daniels: pinchartl: mmm, we don't currently have any facility for importing dmabufs without the GL renderer :\
15:38 pinchartl: I can probably hack my way around by disabling the single master requirement of DRM and carefully using the second plane with async commits, but I'd like a solution that wouldn't require such big hacks
15:38 daniels: it's possible to do - just quite niche, and we do have to assume for the generic case that we can't be guaranteed to be able to get stuff on planes, so we import the dmabuf into EGL to make sure that we can fall back there if needed
15:39 daniels: and no-one's asked for dmabuf support with the pixman renderer yet :P
15:39 daniels: but it shouldn't be difficult to do at all in Weston
15:44 pinchartl: daniels: "shouldn't be difficult" - how much work is that for someone with no prior experience with weston ? :-)
15:45 daniels: pinchartl: hmm, probably like a couple of days I'd suggest?
15:45 pinchartl: ok, that's not bad
15:45 pinchartl: I may give it a try, not sure yet
15:47 pinchartl: given how underpowered the platform is, will I run into issues with weston trying to be generic and falling back to software rendering for any reason ? the only resource I have to blend planes is the display controller, and it has two planes, spanning the whole screen (no control of the pitch or anything, it's very rudimentary). I need to use one plane for the UI (rendered full screen by Qt), and one
15:47 pinchartl: plane for the video
15:52 daniels: well, you'd need some way for Qt to allocate a dumb buffer (?) or something else which could be scanned out
15:52 daniels: but apart from that, I can't see why not
15:52 daniels: we sunk a fair bit of time into making it work in a whole bunch of situations
15:52 emersion: dumb buffers can't be dmabuf'ed
15:53 pinchartl: emersion: in theory or in practice ? last time I tried I could share dumb buffers without any issue
15:53 emersion: in practice
15:53 emersion: hm
15:54 emersion: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gbm/backends/dri/gbm_dri.c#L675
15:54 emersion: bo->image is NULL for dumb buffers
15:55 pinchartl: ok, I don't use gbm, maybe that's why it works :-)
15:55 daniels: but that's only through GBM
15:55 daniels: right
15:55 emersion: ah, i just assumed it wouldn't work without gbm
15:55 emersion: ok, good to know!
15:56 mripard: iirc, dumb buffers only guarantee is that the scanout can access it
15:56 pinchartl: we embedded people like to go low level, I don't even use libdrm ;-)
15:56 pinchartl: mripard: correct
15:56 mripard: so in theory, you don't know if it works or not
15:56 mripard: in practice, I guess it would work with most embedded systems
15:56 pinchartl: there's no guarantee that the GPU can use those buffers
15:56 pcercuei: pinchartl: just syscalls with magic hex values!
15:56 emersion: pinchartl: i don't blame you, libdrm isn't great :P
15:57 pinchartl: but in practice, for the i.MX7D, as there's no GPU, it's not much of an issue ;-)
15:57 mripard: the GPU or anything else I guess?
15:58 pinchartl: the only anything else I have is the camera. and it's equally dumb...
15:59 pinchartl: the i.MX7 is a low-power platform. I initially thought it only meant low-watts :-)
15:59 mripard: that's pretty mean
15:59 mripard: no wonder it doesn't work as you'd expect :)
19:00 jenatali: Ugh... somehow I'm failing CL's sin/cos/tan for vec16, but passing for vec8...
19:18 jekstrand: jenatali: 😥
19:22 karolherbst: jenatali: maybe you also run out of scratch space?
19:22 jenatali: karolherbst: No scratch used by sin/cos/tan
19:22 karolherbst: on a side note: I probably won't be able to do much with CL this week.. a bit occupied with other things :/
19:23 jenatali: No worries, thanks for the heads up
19:50 jenatali: Huh, it looks like it's always the 13th component that's wrong...
19:52 jenatali: Er, 14th
20:01 jenatali: Oh... the shader's too big and our LLVM encoding messes up and starts outputting constants instead of SSA values... cool
20:06 HEX0: hello
20:06 HEX0: https://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2/es2tri.c
20:06 HEX0: why does this have VMware... All Rights Reserved ?
20:06 jatedev: I am using dw_hdmi on 4.19 with hdmi on my i.mx6. Using i2c-ddc-bus for edid on an i2c bus shared with two other devices can cause contention.
20:13 robclark: HEX0: presumably because someone from vmware wrote it?
20:14 HEX0: is it still MIT? or proprietary?
20:15 robclark: not proprietary
20:15 robclark: I guess mesa-demos defaults to MIT?
20:26 jekstrand: jenatali: That's.... fun?
20:26 jenatali: jekstrand: Indeed...
20:37 airlied: ah nuts mismerged amd to next, will fix up and force push
20:37 karolherbst: jekstrand: seems like brian paul wrote those files: https://cgit.freedesktop.org/mesa/demos/commit/src/es2/xegl/tri.c?id=56e7d86f1ce5eea31d6a222577cd4b474b504984
20:38 karolherbst: but that opengl-es branch doesn't exist anymore
20:39 jekstrand: Heh, Tungsten was in Cedar Park, TX. I live like 10 miles from there. :)
20:42 mslusarz: karolherbst: IIRC mesa/demos was splitted from mesa/mesa and the opengl-es branch still exists in mesa repo
20:42 jenatali: Damn, looks like that's not my problem... *sigh*
20:43 karolherbst: let's see then
20:44 karolherbst: https://cgit.freedesktop.org/mesa/mesa/commit/progs/es2/xegl/tri.c?h=opengl-es&id=cf1412fa7805c57c2fe1722c1e7c41a7dbd5c417
20:44 karolherbst: there ya go
20:44 airlied: jekstrand: dont think tungsten had a physical office
20:49 ajax: i think cedar park was where frank lamonica lived
20:49 ajax: he having also been the founder of precision insight
21:18 jenatali: Huh... the nir codegen completely changes between components 13 and 14
21:20 jenatali: jekstrand: Any thoughts on how to investigate further? Right now I'm just comparing the final nir after all optimizations - components 12 and 13 are identical, but 13 and 14 are drastically different. I'm not sure where that difference is getting introduced...
21:20 jenatali: Ugh I hope it's not coming from libclc...
21:24 jenatali: Nope, the SPIR-V exactly matches the source: recurse into sin on vec8s
21:38 karolherbst: jenatali: maybe another vec8/16 bug?
21:38 jenatali: karolherbst: Maybe. I did a search for '4' in all of nir (and found several bugs) but fixing them didn't fix my problem
21:39 jenatali: And I still don't understand why 8 would be fine, or why the problem would show up on component 14 instead of 9
21:39 karolherbst: memory being less random than we hope for :p
21:39 karolherbst: libasan/libmsan or valgrind might be able to spot more stuff
21:40 karolherbst: jenatali: you could also print the shader after each pass and try to figure out when it starts to break
21:40 karolherbst: or is it wrong straight out of vtn?
21:40 jenatali: karolherbst: Yeah.. but it's a *big* shader
21:41 karolherbst: yeah...
21:41 jenatali: And it's a matter of diffing the 12th component vs the 13th when they have different SSA IDs (though the same general structure), so I'm not sure if there's a good way to do that
21:41 karolherbst: hope that sanitizers/valgrind spot something :p
21:42 jenatali: Yeah...
21:42 karolherbst: but it could also be a local array without a size specified or so
21:44 airlied: oh it wasn't a mismerge, phew
22:05 jenatali: I'm not seeing any memory overruns :(
22:09 HEX0: karolherbst: is it considered "free" license?
22:17 karolherbst: HEX0: not sure, but brian can just relicense in case we have doubt
22:18 jenatali: karolherbst: 1.5GB of text so far from a NIR_PRINT attempt :P
22:18 karolherbst: ...
22:18 karolherbst: good luck I guess?
22:19 karolherbst: jenatali: were you able to check with valgrind or so?
22:19 jenatali: karolherbst: I'm on Windows but I tried with the debug heap, VS's stack guards, and app verifier. No luck
22:19 karolherbst: mhh
22:19 karolherbst: which test is it?
22:20 jenatali: test_bruteforce -16 cos
22:20 jenatali: 1.8GB of text to sift through, though there's some repeats in here, so I can actually chunk it down quite a bit
22:22 airlied: HEX0, karolherbst : I'll file an issue for Brian in demos
22:22 HEX0: thanks
22:23 airlied: https://gitlab.freedesktop.org/mesa/demos/-/issues/17
22:27 karolherbst: nice... "<built-in>:1:10: fatal error: 'opencl-c.h' file not found"
22:27 karolherbst: *sigh*
22:27 karolherbst: totally forgot we have this issue as well
22:27 jenatali: Hm?
22:27 karolherbst: we hardcode paths
22:28 karolherbst: so if system clang gets a minor update and some paths change, we are screwed
22:28 jenatali: Ah
22:29 karolherbst: heh.. but something else is odd..
22:29 karolherbst: wait
22:30 karolherbst: heh.. wait what?
22:30 karolherbst: CLANG_RESOURCE_DIR = /usr/lib64/clang/10.0.1/include
22:30 karolherbst: but
22:30 karolherbst: "/usr/lib64/clang/10.0.0/include/opencl-c.h" ...
22:31 karolherbst: ....
22:31 karolherbst: the heck
22:31 karolherbst: _why_
22:32 karolherbst: so there is a llvm 10.0.1 release
22:32 karolherbst: but no clang 10.0.1
22:34 jenatali: ... huh, it's *only* the 14th component that's wrong I think
22:37 karolherbst: jenatali: how many "dots" do I have to wait?
22:37 jenatali: Not long
22:38 jenatali: I've been running with "-w" as well
22:38 karolherbst: 1: cos fp32 ................Wimp pass 2.00 @ 0x1.bd56p+21
22:38 jenatali: Awesome... so it's not a core nir problem, probably
22:39 karolherbst: I've been running with libasan enabled though
22:39 karolherbst: could mess with it
22:39 jenatali: I'll get to the bottom of it
22:39 jenatali: This NIR_PRINT output's actually pretty useful
22:39 karolherbst: this is fp32 which is wrong, right?
22:39 jenatali: Yeah
22:39 karolherbst: fp64 is quite busted, but I couldn't begin to care really...
22:40 karolherbst: fp64 is sooo slow anyway
22:40 karolherbst: jenatali: mhh.. I have my high precision patches though
22:41 jenatali: karolherbst: I've got scaled div too if that's what you mean
22:41 karolherbst: right
22:42 karolherbst: what error do you get btw?
22:42 jenatali: Wrong value
22:42 karolherbst: right, but I mean.. what's the message printed? maybe I have an idea what's up
22:43 jenatali: ERROR: cos16: -9.652066 ulp error at 12164352.000000 (211357) (0x4b399d00): *0.001946 vs. 0.001946
22:43 karolherbst: mhhh
22:43 karolherbst: that's on hw?
22:44 karolherbst: could be something dumb as ffma vs fmad or so
22:44 karolherbst: it does sound like a small precision issue
22:44 jenatali: Nah, if I let it run multithreaded I get all kinds of weird errors
22:45 karolherbst: well.. that's expected as each thread hits the same issue, no?
22:45 jenatali: Every multithreaded test group that's in the valid range for the function gets a wrong component 14
22:45 jenatali: But they're not just off by a little bit, they're super off
22:45 karolherbst: sure.. but that can still be hw
22:45 karolherbst: ahhh
22:45 jenatali: Repros on our software driver too
22:45 karolherbst: super off sounds wrong
22:45 karolherbst: okay
22:45 jenatali: Same exact error
22:46 karolherbst: well, the error you posted looks like a small precision issue, that's why I was wondering
22:47 karolherbst: mhhh
22:47 karolherbst: I see the fma vs mad if :D
22:47 jenatali: Yeah
22:48 karolherbst: huh...
22:48 karolherbst: jenatali: is that if depending on undefined for you as well?
22:49 karolherbst: vec1 32 ssa_3 = undefined
22:49 jenatali: ?
22:49 karolherbst: vec1 32 ssa_442 = inot ssa_3
22:49 karolherbst: if ssa_442 { // mad } else { // fma }
22:49 karolherbst: that's what I see in the nouveau backend
22:50 karolherbst: not that this causes issues for you?
22:50 karolherbst: shouldn't but who knows
22:50 jenatali: karolherbst: I haven't tried dumping the pre-inlined libclc
22:51 karolherbst: that's the final result
22:51 jenatali: Eh we have an opt_undef, so it'd be 0 for us, but I don't think that's it
22:51 karolherbst: mhhhh...
22:51 karolherbst: let me try with opt_undef :D
22:53 karolherbst: right.. so no difference for me
22:54 karolherbst: but regs not written to are 0.. so
22:58 jenatali: My problem is that I end up with bcsel on load_const (true) in this particular inlining instance
22:58 jenatali: Trying to trace where they're coming from now...
23:05 jekstrand: jenatali: valgrind? Maybe we have a nir_ssa_def *foo[4] somewhere. :-(
23:06 jenatali: Doesn't seem to be the case
23:07 jenatali: Looks like nir_opt_if is turning some if conditions into true somehow...
23:07 karolherbst: uff
23:07 karolherbst: I mean.. it's probably right to do so?
23:07 karolherbst: that's what nir_opt_if is all about anyway :D
23:08 karolherbst: jenatali: ohhh.. wait...
23:08 jenatali: karolherbst: No, these conditions definitely shouldn't be flushed to true
23:09 karolherbst: are those by any chance checks of NaN and the like?
23:09 jekstrand: It's weird that it'd be different per-component though
23:09 jenatali: karolherbst: No. I'm pasting the relevant bits now, gimme a minute to extract it into something readable
23:09 karolherbst: jekstrand: can you should an example
23:09 karolherbst: ahh, cool
23:13 jekstrand: karolherbst: ?
23:13 karolherbst: ehh
23:13 karolherbst: I meant jenatali and I meant show
23:14 jenatali: karolherbst: I got you :P
23:16 jenatali: https://pastebin.com/63UVZWBC
23:16 jenatali: That should have all the necessary SSAs. 173695 is getting replaced with true by nir_opt_if
23:17 jenatali: jekstrand, karolherbst: ^^
23:17 jekstrand: Those SSA indexs make me want to cry
23:17 jenatali: :D
23:17 karolherbst: :D
23:17 karolherbst: jenatali: yeah.. well.. doesn't look like a true to me
23:18 jenatali: This is after inlining and during an early optimization loop
23:18 jekstrand: jenatali: opt_if does propagate stuff into the then and the else
23:18 karolherbst: mind doing constant_folding before?
23:18 jekstrand: jenatali: What's the if condition?
23:18 jenatali: I'm not re-generating a paste after that, FYI :P
23:18 jenatali: jekstrand: It's 173695
23:19 jekstrand: jenatali: I'm very confused. I can't see any of the control-flow so I have no idea what opt_if would be doing
23:20 jenatali: Sure, I can grab some more control flow
23:20 karolherbst: jekstrand: do you know what we need?
23:20 jenatali: They're all empty if/else, whose only purpose is to produce phis, and they get converted to bcsel in the next pass
23:20 karolherbst: imagine being able to run a nir shader with precomputed input in software after each pass
23:20 jekstrand: jenatali: Oh...
23:20 karolherbst: and detect when the result changes
23:21 jenatali: jekstrand: After nir_opt_if, only one of the ifs which depends on 173695 is left, and all the rest are replaced with true
23:21 karolherbst: maybe just take the shader and just constant fold the heck out of it
23:21 jekstrand: jenatali: opt_if does sometimes propagate the if condition into the stuff dominated by the then and !condition into the stuff dominated by the else
23:21 karolherbst: but then it depends on constant folding
23:22 jenatali: jekstrand: Let me grab some more code for you
23:22 karolherbst: what do you say we write a nir interpreter... :D
23:22 karolherbst: I honestly think it could actually help debug such shaders and tell when stuff changes
23:23 jenatali: jekstrand: https://pastebin.com/LBpEmDjj
23:24 karolherbst: jenatali: I think it also would help to know how the values generated by the ifs are used
23:25 jenatali: I'm happy to rearrange passes if you think it's necessary or would help, but I doubt I'll recollect the multi-gig dump
23:25 karolherbst: maybe it does make indeed sense
23:25 jenatali: karolherbst: Yes, they're used
23:25 jenatali: karolherbst: It's this for the record: https://github.com/llvm/llvm-project/blob/master/libclc/generic/lib/math/sincos_helpers.cl#L211
23:25 karolherbst: jenatali: so how the if literally generate the same value?
23:25 karolherbst: in either branch
23:25 jenatali: Like I said, it's just there for the phis
23:25 karolherbst: yeah, so opt_if is right
23:26 jenatali: No, it's not. The phi doesn't look at the values produced *inside* the blocks
23:26 jenatali: Just which block it came from
23:26 karolherbst: ohhhh
23:26 karolherbst: evil..
23:26 karolherbst: phis are evil anyway
23:26 jenatali: Unoptimized LLVM
23:26 jenatali: Peephole select converts it to bcsel shortly after
23:26 jenatali: Maybe I just need to re-order those passes?
23:26 jenatali: But this still just seems odd
23:26 karolherbst: yeah... I think you need the phi as phi instructions, not deref_vars?
23:27 karolherbst: dunno
23:27 jenatali: karolherbst: They are phi instructions right after the blocks
23:27 karolherbst: sure
23:27 karolherbst: but if you look at the ifs
23:27 karolherbst: they have a deref_var in either branch
23:27 karolherbst: of the same value
23:27 karolherbst: *variable
23:27 jenatali: karolherbst: And that deref is dead code
23:27 karolherbst: if it's dead code, then opt_if is right?
23:28 jenatali: Check the phi after the blocks
23:28 karolherbst: ahhh
23:28 karolherbst: now I get it :)
23:28 karolherbst: right..
23:28 karolherbst: so the if is just there for the phi after it
23:28 jenatali: Exactly
23:28 karolherbst: mhhhhh
23:28 jenatali: And it should be converted into a bcsel, to match the semantics of the ternary that was in the source it came from
23:28 karolherbst: sure
23:29 karolherbst: but nir_opt_if should be able to detect that, no?
23:29 karolherbst: but...
23:29 jenatali:shrugs
23:29 karolherbst: that would be a hell of a pass to scan for phis depending on it
23:29 karolherbst: mhhh..
23:30 jenatali:tries reordering peephole select before opt_if
23:30 karolherbst: yeah...
23:30 karolherbst: yeah, that probably helps
23:30 karolherbst: I think we kind of want to detect this?
23:30 karolherbst: mhhh
23:30 jenatali: Yeah, I mean the pass is definitely busted
23:30 karolherbst: that's just evil though :D
23:30 jenatali: You can clearly see that it leaves one if/else/phi construct alone but converts the rest to true
23:30 jenatali: But only in this 14th identical sequence...
23:31 karolherbst: maybe it tries to detect this or something.. but the code is a bit hard to follow anyway
23:31 jenatali: karolherbst: Yeah, it's not done being optimized yet :P
23:32 karolherbst: phis are just evil :D
23:33 jenatali: Well... that did it
23:33 karolherbst: yeah.. kind of expected
23:33 karolherbst: mhhhh
23:34 karolherbst: jenatali: maybe we need a pre pass for opt_if which scans for phis and marks nir_ifs as "not dead" in case a phi depends on it
23:34 karolherbst: or something?
23:34 jenatali: karolherbst: I just don't understand why it left the first one alone...
23:35 jenatali: There should at least be comments somewhere indicating that nir_opt_if isn't safe to run before peephole select perhaps? Though again, it worked for 15/16 inlined implementations
23:35 karolherbst: maybe it tries to do something
23:35 jenatali: I'd say uninitialized memory but it's way too consistent for that
23:35 karolherbst: yeah.,,
23:36 jenatali: jekstrand: Any thoughts?
23:37 karolherbst: mhhh
23:37 karolherbst: idr isn't around :/
23:42 jenatali: Looks like the logic in evaluate_if_condition is wrong... Block domination isn't sufficient to rewrite the conditions
23:44 jenatali: Though I still don't understand why it works 15/16 times here
23:45 jenatali: Heh, wonder if there's smaller integer sizes used somewhere and the large SSA/block IDs throws it off somehow
23:47 jekstrand: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6655
23:47 jekstrand: jenatali: There's one or two in there that might be biting you
23:48 jekstrand:goes back to reading the bogus NIR
23:48 jenatali: jekstrand: Thanks. Let me reconcile the ones I found against this MR, I might have another patch for you if you didn't find the same ones :)
23:48 jenatali: None of the ones I found fixed it though
23:50 jenatali: Oh, lower_regs_to_ssa might be it... I didn't touch that one since we don't use it but now I see it's implicitly used by opt_if...
23:51 jekstrand: jenatali: It is implicitly used by opt_if :)
23:51 jenatali: Let me see if that also fixes it...
23:52 jekstrand: jenatali: Better than 50% of stuff which does control-flow manipulation converts phis to regs and then runs regs_to_ssa afterwards.
23:52 jenatali: Makes sense
23:53 jenatali: jekstrand: Nope, still happens if I let opt_if run before peephole with regs_to_ssa :(
23:54 jekstrand: jenatali: Yeah, that looks like our if propagation is busted
23:56 jekstrand: jenatali: opt_if_evaluate_condition_use isn't doing any dominance checks. :-(
23:57 jenatali: jekstrand: evaluate_if_condition does?
23:58 jekstrand: jenatali: Right