08:21 danvet: MrCooper, mupuf on https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/443
08:21 danvet: dp mst connectors actually disappear once they're no longer used by anything
08:22 danvet: so yeah any modeset will fail
08:22 danvet: if you replug, you might or might not get the same thing back, but then modeset should work
08:22 danvet: this should have nothing to do with link training, link training fail only results in a black screen for the user
08:23 danvet: from the kernel/userspace pov the output is still considered to be enabled and should (at least in theory) complete pageflips and stuff
08:23 danvet: otherwise any link training fail would immediately result in frozen compositors, because handling async events is inheritedly racy
08:26 danvet: wrt disconnected: with dp and hdmi (not even mst) we need to be able to talk to the other end to figure out how wide/fast the link is
08:27 danvet: that's needed to validate the requested mode
08:27 danvet: so if the other end isn't there for these connectors, modeset fails
08:27 danvet: with older outputs like vga or dvi we allow driving past the monitor limits
08:28 danvet: but with the new link training stuff there's really not anything you can do, you'd need to pass along the entire link training set and config
08:29 danvet: so entervt should probably work like initial configuration at start-up
08:29 danvet: except you're using your saved config as starting point, and not the existing one for smooth booting
08:32 danvet: mupuf, also we do link train in the background
08:32 danvet: it fails when the current mode doesn't work anymore for a degraded link
11:46 karolherbst: mhhh.. we have a race on the shader cache in EGLs multithreading tests :/
11:46 karolherbst: https://gist.githubusercontent.com/karolherbst/0a2fb0a72ca093e39e235874ab7240c2/raw/4291be0ec5beb845fb52afcd3415ca331476e155/gistfile1.txt
12:18 tomeu: anholt: regarding running gfxreconstruct on CI for fdo, it currently requires either a X or a Wayland server
12:18 tomeu: guess it should be hard to come up with a Null platform implementation for headless rendering
12:18 tomeu: *shouldn't
12:21 daniels: you can just use the weston headless backend for now
13:51 bnieuwenhuizen: daniels: what does it "mean" to set the GBM_BO_USE_SCANOUT on a gbm_bo_import with modifiers?
13:51 MrCooper: "imported buffer must be scanout capable"
13:51 bnieuwenhuizen: (context: weston seems to unconditionally set that flag on import, which doesn't work too well with a modifier that is not displayable on the given GPU)
13:52 MrCooper: sounds like a weston bug
13:52 bnieuwenhuizen: even if the kernel is supposed to advertize what modifiers it can scan out?
13:52 MrCooper: it needs to have a fallback for then importing with GBM_BO_USE_SCANOUT fails
13:53 MrCooper: *for when
13:53 emersion: gbm_bo_import with modifiers doesn't have usage flags
13:54 bnieuwenhuizen: emersion: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/fb.c#L297 ?
13:55 emersion: oh, it does have them then
13:55 emersion: mixed it up with gbm_bo_create
13:55 emersion: my bad
13:55 bnieuwenhuizen: then again, it seems it needs it there
13:55 emersion: but then it should be fine if it fails
13:55 bnieuwenhuizen: and I can see nothing broken with weston yet, so maybe the bo_import failing is WAI on both sides
13:55 emersion: weston only needs to import a gbm_bo if it'll use direct scanout
13:55 emersion: with planes
13:56 emersion: if that fails, it'll fallback to composition with GL
13:56 bnieuwenhuizen: okay, thanks
14:00 pq: bnieuwenhuizen, how did you figure out in the first place that that is failing? Just curious. :-)
14:01 bnieuwenhuizen: pq: logging failing imports while debugging other reasons the imports were failing
14:02 pq: heh
16:47 mupuf: danvet: what you described is indeed my understanding
16:49 mupuf: Well, minus the fact that it would seem like modeset still requires AUX communication
16:50 mupuf: as in, synchronously
17:04 zmike_: are there difficulty labels for gitlab issues? (like 'easy', 'medium', 'jekstrand save me', ...)
17:08 jekstrand: zmike_: No, there aren't.
17:08 jekstrand: zmike_: Which one are you looking at?
17:08 jekstrand: zmike_: We might have a low hanging fruit label for really easy stuff but I don't remember.
17:08 zmike_: jekstrand: I was imagining it might be nice for issues I'm creating
17:09 jekstrand: zmike_: What category do you think they fit into? :-P
17:09 zmike_: oh
17:09 zmike_: zink
17:09 zmike_: easy
17:10 zmike_: example https://gitlab.freedesktop.org/mesa/mesa/-/issues/3359
17:25 danvet: mupuf, we cache it
17:25 danvet: well, for atomic_check we cache it
17:25 danvet: which is the only part that can fail
17:25 danvet: the modeset part just muddles on, to avoid surprises
17:25 mupuf: Even after suspend?
17:25 danvet: well the cache gets updated on probe
17:26 danvet: and we reprobe after suspend
17:26 danvet: I only meant that there's no direct path from a synchronous aux transaction to userspace getting an -EINVAL
17:26 mupuf: Here we go, that's prob the source of my confusion
17:26 danvet: so we probe, update the dpcd stuff
17:26 danvet: I think atomic_check then validates against that, hoping it's correct
17:26 danvet: and then the modeset hammers it into hw
17:27 danvet: if actual link training fails, we set link-status to bad (but link keeps working)
17:27 danvet: and send another uevent
17:27 danvet: now page-flips are supposed to go through still even if link-status is bad
17:27 danvet: page-flip == !ALLOW_MODESET
17:27 danvet: now the legacy SETCRTC ioctl always has ALLOW_MODESET enabled
17:34 mupuf: Ack, thanks. I'll get back to it after my vacation
17:35 mupuf: (next week)
17:55 alyssa:looking into lowering varying precision in NIR while linking
17:55 alyssa: Looks like it should work well with nir_link_opt_varyings
17:56 alyssa: Currently we do it in the driver (at a cmdstream level), but this has considerable draw-time overhead since Gallium doesn't expose the concept of linked shaders
17:56 jenatali: jekstrand, karolherbst: I think I need to add explicit opcodes for f2f16 with ru/rd semantics. I'm having trouble coming up with a nir algorithm that can handle denorms, that'd be implemented in terms of other rounding ops -- flt flushes denorms in DXIL
17:57 alyssa: (and for us - it doesn't work for int16 varyings since the hw saturates instead of wraps - easily solved by adding an i2i16 op, which is facilitated by linking info)
17:57 jenatali: Any objections? I know karolherbst has been talking about potentially doing it for lots of conversion types
17:57 jekstrand: jenatali: We don't have explicit denorm handling in NIR. We leave it fuzzy today.
17:57 jekstrand: jenatali: Exactly what semantics are you thinking here?
17:57 alyssa: jenatali: Is it "NIR conversions are problematic" time of the day already? ;)
17:57 jenatali: jekstrand: That's fine, except that CL's conversions to/from half *must* support denorms :(
17:58 jenatali: Just adding 'ru' and 'rd' on top of 'rte' and 'rtz' for f2f16 instructions
17:58 alyssa: round up/down?
17:58 jenatali: Yep
17:58 jenatali: Or positive/negative infinity
17:58 alyssa: rtp/rtn to be consistent maybe
17:58 jenatali: alyssa: There's already nir_rounding_mode_{ru/rd}
17:58 alyssa: matches CL that way too
17:59 karolherbst: jenatali: we need all them explicitly, yes
17:59 jenatali: ... at least in our fork, but I thought that came from upstream
17:59 jekstrand: jenatali: Right... That seems really odd for fp32 -> fp16 conversion, though.
17:59 jekstrand: Why would you ever want that behavior?
17:59 alyssa: jenatali: so there is, I'll stop bikeshedding :p
17:59 jenatali: jekstrand: Beats me?
17:59 jekstrand: I can get float -> int conversion with up/down rounding but float conversion makes no sense.
18:00 karolherbst: jekstrand: why not?
18:00 jekstrand: I guess maybe if you were going to fp32 -> fp16 -> int
18:00 alyssa: jenatali: _ru, _rd are unused upstream
18:00 karolherbst: so you do cut precision when going from fp32 to fp16
18:00 karolherbst: and deciding how to round is needed
18:00 jekstrand: karolherbst: In my mind, up/down is a rounding operation, not a loss of precision.
18:00 alyssa: so might as well rename while we're repainting the bikeshed
18:01 karolherbst: jekstrand: huh?
18:02 jekstrand: I can't think of a case where it's mathematically sensible to explicitly round up or down to an unknown point which is what you're doing when you do fp32 -> fp16 conversion unless the intention is to then round down to some known point immediately afterwards.
18:02 jekstrand: With float -> int, you're rounding down to the nearest integer. That makes mathematical sense.
18:02 jenatali: jekstrand: A float32 outside of the float16 range (i.e. > 65504) would end up with different results for rtp/rtn/rtz
18:03 jenatali: rtp => inf, rtn/rtz => 65504
18:03 jekstrand: But with float -> float conversion, you typically want rtne because it helps balance out the precision loss so it doesn't shove your mathematical error in one particular direction.
18:03 karolherbst: jekstrand: CL is explicit about rounding
18:03 jenatali: Typically, sure
18:03 jekstrand: Sure, if CL requires it then I guess we give it to them.
18:03 karolherbst: you can choose whatever rounding
18:04 jekstrand: It just seems odd to me, that's all.
18:04 jenatali: I don't disagree
18:04 karolherbst: conversions are odd...
18:04 jekstrand: Also, we have a *lot* of conversion opcodes. 😭
18:04 karolherbst: you can choose the type, rounding mode _and_ sat flag
18:04 karolherbst: all combinations
18:04 jenatali: karolherbst: For now I'm planning to leave float->int conversions in vtn, to avoid adding all the nir op variations
18:04 jenatali: If you want to do that, you can do it :P
18:04 karolherbst: jenatali: gpus generally can do them all in hw though
18:05 karolherbst: :D
18:05 karolherbst: right
18:05 karolherbst: I kind of prefer having the nir opcodes + nir lowering
18:05 jenatali: Yeah, makes sense and seems worthwhile to do at some point
18:05 jenatali: Something tells me the conversions implementation we have will never land upstream as-is, and that's probably okay
18:06 jekstrand: Some days, I'm tempted to add a new nir_instr_type_convert
18:06 jekstrand: And just have it take a nir_alu_type for the source and destination and a rounding mode and saturate falg.
18:06 jenatali: Oof but then you'd lose algebraic lowering? :(
18:06 jekstrand: *flag
18:06 jekstrand: Yeah, making it work with opt_algebraic would be annoying
18:06 jekstrand: Possible but annoying
18:07 jenatali: Seems like a good idea though
18:07 jekstrand: A million opcodes has the advantage of working everywhere.
18:07 jekstrand: It just means that anywhere that consumes NIR has a *lot* of switch cases.
18:07 karolherbst: jekstrand: sounds good :p
18:07 jenatali: Yeah, until your algebraic lowering falls over because you have to reference *all* of them
18:07 jekstrand: Yeah
18:08 karolherbst: jenatali: I think we can "magic" it away
18:08 jekstrand: There are kind-of no good options
18:08 karolherbst: and keep the i2i syntax
18:08 karolherbst: just that the code to encode/decode is somewhere else
18:08 jekstrand: karolherbst: You only say that because *I* am the one who's going to have to write the magic. :P
18:08 karolherbst: jekstrand: I already wrote the constant folding code
18:08 jekstrand: Fair
18:08 jekstrand: I'm mostly joking
18:08 jenatali: Oof... yeah I forgot I have to add constant folding for the new conversions
18:09 karolherbst: :D
18:09 jenatali:sighs
18:09 jekstrand: But, yeah, this problem is annoying.
18:09 karolherbst: jenatali: check what I've done
18:09 karolherbst: it works, except for _sat
18:09 jenatali: There's no _sat for float->float
18:09 Kayden: Extending algebraic to handle an nir_instr_convert would probably be very doable
18:09 karolherbst: jenatali: of course there is
18:10 jenatali: karolherbst: Conversions to floating-point type shall conform to IEEE-754 rounding rules. The _sat modifier may not be used for conversions to floating-point formats.
18:10 karolherbst: ehh..
18:10 karolherbst: ohh, somehow I missed that
18:10 karolherbst: oh well
18:10 karolherbst: less work
18:12 karolherbst: jenatali: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/cf2fd99c9e0f65aa50011333de9d533e18ff08b2 ...
18:12 karolherbst:really wishes there is an awesome C lib doing that without being stupid
18:12 karolherbst: x86 fpu is just broken
18:13 karolherbst: and I have no idea what SSE extension gave us rounding modes on operation
18:13 jenatali: karolherbst: Thanks for that
18:13 karolherbst: anyway.. I really want there to be a C library doing all of that :D
18:14 karolherbst: int -> float just kills it
18:14 karolherbst: don't ask my why it works :D
18:15 karolherbst: I think one of the issue was that a float compared to int where the float is out of range is undefined
18:15 karolherbst: and this is just annoying
18:17 karolherbst: jenatali: ohhh, I think libclc had an implementation for all of that?
18:17 karolherbst: or was it pocl?
18:17 karolherbst: mhhh
18:17 karolherbst: but no matter.. spir-vs doing those explicitly need to be supported anyway
18:17 jenatali: karolherbst: Yeah I think libclc has implementations of some of it, not sure though
18:18 karolherbst: but honestly.. we can't be the only one with this problem...
18:18 karolherbst: and I think the CTS was doing something stupid
18:18 jenatali: Anyway, I'll keep fighting with this, see if I can get all the various denorms to convert in all the rounding modes
18:18 karolherbst: like only supporting x86 and arm or something
18:19 karolherbst: jenatali: I guess there is no way to be more explicit in dxil?
18:19 jenatali: karolherbst: Nope :D
18:19 karolherbst: or some weirdo state flag on d3d to flip behaviour?
18:19 jenatali: Not yet, it's now on our backlog
18:20 karolherbst: jenatali: wanna have more fun? we also don't supported unordered comparisons :p
18:20 karolherbst: only ne is unordered
18:20 karolherbst: and I bet dxil also doesn't?
18:20 jenatali: karolherbst: It's hooked up in vtn?
18:20 jenatali: Actually it does, at least at the IL level
18:20 jenatali: Since LLVM does support distinctions between the two
18:21 karolherbst: jenatali: heh? maybe I missed some of that landing
18:21 karolherbst: but at least nir opcodes are not
18:21 jenatali: Right
18:22 karolherbst: but that is quite easy to fix
18:22 jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/compiler/spirv/vtn_alu.c#L521
18:22 karolherbst: rne renamed to rneu
18:22 karolherbst: and the others added
18:22 karolherbst: jenatali: right.. but vtn_nir_alu_op_for_spirv_opcode
18:23 karolherbst: for graphics it usually doesn't matter
18:23 karolherbst: but that's really not much work I think
18:23 karolherbst: I had some patches at some point but super outdated
18:23 jenatali: Sure, it's a nir sequence rather than a nir opcode
18:23 jenatali: At least it's correct if not optimal
18:24 karolherbst: ohhh
18:24 karolherbst: I missed the bottom part
18:24 karolherbst: right
18:24 karolherbst: I just think it's not correct :p
18:24 jenatali: It is - it passes the test_relations CL CTS at least
18:25 karolherbst: I mean.. with drivers
18:25 karolherbst: but maybe it's fine
18:25 karolherbst: the weird thing is, on a source level != is neu, not ne
18:25 jenatali: There's also the weird CL ordered and unordered functions: https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/167
18:26 karolherbst: but yeah.. I think like this it might actually be fine
18:26 karolherbst: I just think it makes sense to be also more explicit about this here
18:26 karolherbst: oh well
18:26 karolherbst: hw usually supports all of it
18:26 karolherbst: it just.. breaks sometimes the mind of people writing optimizations
18:27 karolherbst: not(eq) == neu
18:27 karolherbst: but we do not(eq) == ne
18:27 karolherbst: so it's a bit harder to actually trigger bugs CL would care about
18:29 karolherbst: jenatali: if you are good enough, you can write a kernel which has weird beahviour where (a != b) == (a == b) is true
18:29 karolherbst: just need to trick the optimization enough
18:30 karolherbst: ehh wait.. for NaN true is actually correct
18:30 karolherbst: uhm
18:30 karolherbst: nope
18:30 karolherbst: with NaN that's false
18:46 jenatali: karolherbst: Had you seen https://gitlab.freedesktop.org/mesa/mesa/-/commit/ef681cf9713664bcd3e95d54cc158b93b3542dc8 ?
18:47 karolherbst: jenatali: ehhhhh
18:47 karolherbst: that's why I said that the x86 fpu is busted :p
18:48 karolherbst: apparently you have a cpu wide control thingy to flip behaviour and it gets context switched or something. but the thing is, once you flip it in a thread, it is flipped for all threads
18:49 karolherbst: or something stupid like this
18:49 jenatali: Yeah, I'm vaguely aware that it's a stupid thing
18:52 karolherbst: some SSE version added explicit instructions though...
18:52 karolherbst: but still.. doesn't really help with other archs
19:47 sravn_: tagr: do you see any reason to keep drm_panel_{attach,detach}
19:48 sravn_: In the past drm_panel_attach was used to provide access to drm_device, but we no longer do so.
19:49 sravn_: I cannot see any use today, but I may miss something
19:50 sravn_: tagr: Joe Perches posted following patch to remove the calls: https://lore.kernel.org/dri-devel/9e13761020750b1ce2f1fabee23ef6e2a2942882.camel@perches.com/
19:51 sravn_: I have it applied and fixed up locally but would like an ack from you before I push it
20:57 bnieuwenhuizen: emersion: are there any plans to upstream https://gitlab.freedesktop.org/emersion/wayland-protocols/-/commit/6da6137270374a4efc5f8d6c9157a454d26e9878 ?