00:00 karolherbst: true
00:00 jekstrand: karolherbst: Yeah, not sure what to do about sqrt and friends.
00:00 airlied: any everyone just runs inference workloads nowadays don't they? :-P
00:00 jekstrand: karolherbst: With the exception of ffma, I'm inclined to think that we just have higher precision requirements for CL somehow.
00:00 imirkin: airlied: one can infer that.
00:00 karolherbst: jekstrand: I mean.. I don't mind doing it in vtn.. I just don't want to have it inside vtn_alu _and_ vtn_opencl :D
00:00 mattst88: 4-bit floats FTW!
00:00 airlied: fp64 myst have 0 use cases :-P
00:01 jekstrand: But I really don't want opt_algebraic to become api-aware.
00:01 karolherbst: mattst88: :D
00:01 imirkin: jekstrand: fwiw nvidia doesn't just do 1/rsq for sqrt -- they have a whole separate thing which approximates it better.
00:01 ngcortes: Kayden, craftyguy mareko, is a revert an option in the meantime?
00:01 karolherbst: imirkin: yeah, argument scaling
00:02 karolherbst: huh?
00:02 karolherbst: but they do use sqrt
00:02 karolherbst: ohh..
00:02 imirkin: karolherbst: for fp64
00:02 karolherbst: I didn't check pre maxwell2
00:02 karolherbst: ahhh
00:02 imirkin: i figured that was implied :p
00:03 karolherbst: I was discussing fp32 stuff with jekstrand though :p
00:03 imirkin: oh. i just saw lots of fp64 talk
00:03 karolherbst: for fun reasons, even the fp32 ops are not enough for CL
00:03 karolherbst: we just need a place where to lower that
00:03 imirkin: even the MUFU.SQRT/etc isn't enough? sigh
00:03 karolherbst: fdiv isn't enough
00:03 imirkin: fdiv isn't a thing
00:03 karolherbst: well.. right
00:04 imirkin: hence not enough.
00:04 karolherbst: but yeah. sqrt also fails
00:04 imirkin: but the things that are things - are they enough?
00:04 jekstrand: karolherbst: My feeling is that we just don't want sqrt -> 1/rsq for Vulkan. We want to enable a more precise lowering somehow.
00:04 Kayden: craftyguy, ngcortes, mareko: Looks like new asserts that aren't the case on iris. We haven't calculated num_outputs when edgeflag lowering is run, in our route through all the lowering stuff. I moved the asserts into the new code block (which iris doesn't use), and it's happy again
00:04 jekstrand: Because OpenCL sqrt() is also going to have higher precision requirements
00:04 Kayden: craftyguy, ngcortes, mareko: testing a second patch - hopefully that'll take care of the regressions
00:04 karolherbst: imirkin: it fails for very small or very big numbers
00:04 imirkin: jekstrand: fwiw with tgsi, we had a PIPE_CAP_TGSI_SQRT or whatever
00:04 jekstrand: karolherbst: Same with fdiv and x*rcp(y)
00:04 karolherbst: so you need to scale it up/down a little
00:04 imirkin: which indicated whether you supported the SQRT op or not, and if not, it lowered to ... something
00:05 jekstrand: imirkin: Yeah, we have some bits like that in nir_compiler_options. It's just that the "normal" lowerings aren't precise enough.
00:05 imirkin: right, if you care about denorms, life is tough.
00:05 karolherbst: jekstrand: sure.. but at this point I am mainly wondering about where to do that stuff
00:05 imirkin: esp if you simultaneously don't care about denorms
00:05 imirkin: depending on the use-case
00:05 karolherbst: and the issue is rather we have to fix fdiv and sqrt, whiich are "different" things
00:06 karolherbst: imirkin: that's even optional in CL...
00:06 karolherbst: but I am testing with denorm support enabled
00:06 karolherbst: just so that I know where stuff fails
00:06 ngcortes: Kayden, \o/
00:06 karolherbst: for fp64 it is required to handle denorms though :D
00:07 karolherbst: jekstrand: sooo.. the idea I had was that we could just run a nir lowering pass adding a bit of precision after we converted to nir
00:07 karolherbst: but
00:07 karolherbst: that won't "work"
00:07 karolherbst: it totally does work,but we would also lower native_sqrt etc...
00:08 karolherbst: which.. makes those native_* variants pointless
00:08 karolherbst: so I was wondering.. should we just abuse .exact for that?
00:08 karolherbst: I mean.. we probably want to mark _all_ cl ops as exact anyway
00:08 karolherbst: except -cl-fast-math is set or whatever
00:09 karolherbst: mhh.. "cl-unsafe-math-optimizations" is the thing
00:09 karolherbst: "cl-opt-disable" how pointless..
00:09 karolherbst: why adding stuff like this? :D
00:10 karolherbst: it's just annoying that CL has different compiler flags
00:10 karolherbst: cl-fast-relaxed-math... cl-finite-math-only... cl-no-signed-zeros
00:10 karolherbst: etc...
00:11 karolherbst: but I guess before we really really care about performance it won't makes much sense to care
00:11 karolherbst: but I guess for CL everything should be .exact by default
00:11 karolherbst: and we could skip that for all native_* opcodes
00:11 karolherbst: and really just add precision for ops marked as exact?
00:12 karolherbst: jenatali: how are you dealing with that on a dxil level?
00:12 karolherbst: I am sure the backend compiler will break stuff
00:12 jenatali: We don't send them to DXIL at the moment
00:13 karolherbst: huh?
00:13 karolherbst: ohh
00:13 karolherbst: I meant the general stuff
00:14 jenatali: Which stuff?
00:14 karolherbst: like I am sure that backends will just optimize thinking it's for graphics
00:14 karolherbst: and breaking CL precision requiernments
00:14 jenatali: Yeah, that seems to be the case, at least to some extent
00:15 karolherbst: does dxil has some concept of exact like we do in nir?
00:15 karolherbst: but even with that I am sure nvidia outsmarts everybody and breaks it for CL :p
00:16 jenatali: I'm actually not sure... I'd have to look
00:17 karolherbst: but I think we really just want to mark everything as precise with CL mhhh...
00:17 karolherbst: jekstrand: any thoughts on this?
00:58 Kayden: craftyguy, ngcortes, mareko, anholt: just posted https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6450 to fix the regressions
00:58 Kayden: it looks to be clean in CI (build kwg #2024)
01:03 craftyguy: awesome, thanks Kayden!
05:08 Yuti: Can we call drm_connector_set_link_status_property from atomic functions? I am getting mutex deadlock when I call from atomic enable.
06:53 tomba: Can someone update drm-misc-fixes to the latest rc? I have a fix for rc1.
07:15 sravn_: mripard: ^
07:15 sravn_: mlankhorst: ^
07:29 MrCooper: DPA: I suspect it's an etnaviv bug, using the wrong DRM file description in some cases; been having "fun" related to that with radeonsi as well
07:40 DPA: Ok, I'll look into that.
07:48 pq: emersion, that's awesome, but how do you scrape the docs? Would it not have been slightly more reliable to link to kernel.org doc pages?
07:48 emersion: ah, i didn't even thought of that, and just assumed scraping the source code would be easier
07:49 emersion: https://git.sr.ht/~emersion/drmdb/tree/master/drmdoc/generate.go
07:51 emersion: also, linking to individual doc properties isn't possible
07:51 emersion: i could link to "standard connector properties", but not e.g. CRTC_ID in particular
07:51 emersion: i suppose maybe it's fixable
07:52 emersion: … in which case it would result in being able to just link to the #CRTC_ID anchor or something
07:56 emersion: something i'm worried about is having two objects with the same property name
07:56 emersion: e.g. GAMMA_LUT on the plane *and* on the CRTC
07:57 emersion: how the current docs are written make it complicated to tell which is a plane prop and which is a CRTC prop
08:03 MrCooper: DPA: to be clear, I mean the Mesa Gallium driver
08:03 pq: emersion, good points. Maybe the kernel docs would need some refactoring anyway... :-p
08:04 pq: if there are websites like drmdb linking directly to kernel doc elements, would be element anchors be considered UAPI?
08:04 emersion: ahahah
08:05 pq: half joking... but only half
08:05 emersion: :D
08:06 emersion: my main beef with kernel docs right now is that it's not for user-space
08:06 emersion: "to use this prop driver should call drm_whatever()"
08:06 emersion: and other internal kernel details
08:06 pq: yeah, and when that's solved, I'd assume linking to them would be practically a solved issue
08:30 mlankhorst: tomba: ok
08:31 tomba: mlankhorst: thanks
09:00 mlankhorst: tomba: any official reason for the fix
09:01 tomba: mlankhorst: hmm, what do you mean? The fix is this one: https://patchwork.kernel.org/patch/11723455/
09:02 mlankhorst: ty
09:02 EdB: karolherbst: sure :)
09:02 EdB: I saw it but since you didn't mention it, I was not sure it was ready
09:03 mlankhorst: tomba: pushed!
09:06 tomba: mlankhorst: alright, thanks
10:30 tanty: dcbaker: could you review:
10:30 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/351
10:30 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/352
10:30 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/353
10:30 tanty: ?
10:35 tanty: kusma: could you take a look at:
10:35 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/351
10:35 tanty: ?
10:43 kusma: tanty: I don't think I know this code well enough to quite get what's going on, sadly...
10:43 tanty: OK, no prob, I CCed you because you had some changes in the commit history
10:44 tanty: thanks!
13:08 TheRealJohnGalt: Is it worth reporting LTO runtime bugs that occur on both clang and gcc? Or should they be reported to the compilers instead?
13:16 agd5f_: hanetzer, I don't personally, but other people on the Linux team do
13:17 hanetzer: agd5f_: cool stuff. Looking forward to it. Currently I'm going to be trying some vendor bios modding, because my mobo+gpu doesn't output over dp (old gpu rx480 did work)
14:25 mripard: airlied: there's been a screw-up on my side and my mail queue wasn't sending anything for the last week, hence the mismatch between the PR date and when you actually received it
14:25 mripard: sorry
14:32 MrCooper: TheRealJohnGalt: if it's the same with both compilers, a Mesa issue seems more likely
18:30 sravn_: airlied: I would be heppy if you could chime in on my feedback on Hikey 970 - the part about the DSI driver. Would be good to have a second opinion on the suggestion to use a bridge driver
18:30 sravn_: s/heppy/happy
18:31 sravn_: narmstrong: ^ - feedback from you or one of your fellow bridge friends would be nice too
19:08 pinchartl: sravn_: I think a bridge driver makes sense if it's a separate IP. I haven't checked the details, is it a separate node in DT ?
19:17 ajax: wtf does __glXInitialize try to load all of dri's 3 2 1 and sw?
19:18 ajax: other than "more organs means more human, dib"
19:20 jenatali: That reference makes me happy
19:28 ajax: i'm just happy someone caught it
19:43 sravn_: pinchartl: There are two different bindings files: https://lore.kernel.org/dri-devel/6471642f74779fecfc9d5e990d90f9475d8b32d4.1597833138.git.mchehab+huawei@kernel.org/
19:44 sravn_: pinchartl: And here you see it is two different nodes: https://lore.kernel.org/dri-devel/0f87d492431d4163873498c954d87595bf8776a0.1597833138.git.mchehab+huawei@kernel.org/
19:45 sravn_: pinchartl: I have not reviewed the bindings yet. The patch was not named dt-bindings and I deleted the mail.
19:45 sravn_: pinchartl: I could dig it out of lore...
19:46 pinchartl: sravn_: the reg entries of the two nodes overlap :-S
19:47 pinchartl: I have a feeling some of it will need to go to a syscon node
19:48 pinchartl: and reg: minItems: 1 seems weird
19:50 sravn_: I am a bit concerned that the mux-gpio is part of the dsi binding, where I thought it would belogn to the display driver
19:50 sravn_: mux-gpio is used to select either a panel or HDMI.
19:50 sravn_: There is some coe that trigger on hot-plug that updates the gpio.
19:50 sravn_: s/coe/code
19:51 sravn_: But the overlapping memory is also a good hint something needs to be done differently
19:51 pinchartl: I'm looking at the code, lots of registers are hardcoded with no explanation
19:51 pinchartl: + noc_dss_base = ctx->noc_dss_base;
19:51 pinchartl: +
19:51 pinchartl: + writel(0x2, noc_dss_base + 0xc);
19:51 pinchartl: + writel(0x2, noc_dss_base + 0x8c);
19:51 pinchartl: + writel(0x2, noc_dss_base + 0x10c);
19:51 pinchartl: + writel(0x2, noc_dss_base + 0x18c);
19:52 pinchartl: that's pretty much unreviewable
19:53 sravn_: TAll the HW manipulation I blindly skipped assuming it was OK as it works.
19:54 pinchartl: the above code is in a function named hisi_dss_qos_on()
19:54 pinchartl: and it's the only code that touched that registers block
19:54 sravn_: We see the same in other bridge drivers with lots and lots of HW manipulation where one needs the datasheet
19:54 pinchartl: sounds really fishy to me
19:55 pinchartl: it seems those registers are part of some system controller that deals with QoS
19:55 pinchartl: it doesn't belong to that driver, at least not without using a syscon
19:56 pinchartl: or hisi_dss_smmu_on()
19:56 sravn_: The bindings should describe the reg entries - as a minimum,
19:56 pinchartl: that should be implemented in an IOMMU driver
19:58 pinchartl: it all looks like a vendor code dump, quite well below the mainline quality standards
19:58 pinchartl: which is fine in staging
19:58 sravn_: If we have iommu stuff in the driver the I get why there is so much I do not understand there
19:58 pinchartl: but all that will have to be cleaned up
19:59 sravn_: My review have focused on what I know - so that has been trivialities and some driver sturcture things.
19:59 sravn_: Feedback like "this part should be in an iommu driver" would be great as this can point Mauro in the right direction
20:00 sravn_: There is also some phy stuff, but I do not know when things is supposed to be a phy driver. That may or may not be the case here
20:01 pinchartl: looking at the DSI DT node, there are references to two DPHY instances
20:02 pinchartl: clocks are duplicated
20:02 pinchartl: I thus wonder if there are two DSI blocks or a single one
20:03 pinchartl: the mux-gpio should be moved to a separate DT node
20:03 pinchartl: it should be DPE -> DSI -> video mux -> { adv7533, panel }
20:04 pinchartl: as there's no mux in the DSI bridge itself, I expect the mux to be a separate on-board component
20:05 sravn_: So you think the panel goes via DSI too. That would make sense yes. How would we model the video mux? Do we have something similar in other drivers?
20:05 pinchartl: a DT node with one input node and two output nodes
20:06 pinchartl: in DRM it becomes a problem though, as bridge chains are assumed to be linear
20:06 pinchartl: we'll need some more infrastructure
20:06 sravn_: I had hoped we could do it with the toolbox we already have, sigh
20:07 pinchartl: with drm_bridge, unfortunately not
20:07 pinchartl: without drm_bridge display drivers can implement that internally
20:07 sravn_: We could ask Mauro to focus on HDMI first, then the video-mux challenge could wait.
20:07 pinchartl: but I don't we should extend drm_bridge instead
20:07 pinchartl: yes, the video mux can probably wait
20:08 sravn_: Then it would look like this: DPE -> DSI -> adv7533 -> {hdmi?}
20:09 sravn_: And we are back to the original open Q - if the DSI part should be a drm_bridge.
20:10 sravn_: From what we have discussed here the answer is yes, and then we shall be open that we will need to do something to support the video-mux later.
20:16 pinchartl: I think it should be a bridge, yes
20:17 pinchartl: but first we need to clarify why it shares so many register blocks with the DSE
20:21 sravn_: pinchartl: Thanks, I have made a short summary in a mail and sent to Mauro. Then lets see what comes next
20:22 pinchartl: thanks
20:32 cr0sis: Hey, not really sure where I should be or who to speak to for this, but I'm experiencing issues with mortal shell and after posting on reddit someone suggested it's perhaps a mesa problem
20:35 ajax: i guess part of the answer (re __glXInitialize, supra) is it's possible to have different screens that support different DRIs
20:35 ajax: i'm not entirely convinced this is a thing to care about
20:45 airlied: at leats dri1 vs 2/3 definitely not
20:50 pendingchaos: cr0sis: mesa bugs can be reported at https://gitlab.freedesktop.org/mesa/mesa/-/issues/
20:51 pendingchaos: usually a renderdoc capture is useful
20:51 pendingchaos: one thing to try is to set d3d11.invariantPosition to "True"
20:52 pendingchaos: that works around a common kind of game bug that often looks like a driver bug
20:54 cr0sis: ok nevermind then
20:54 cr0sis: thanks
20:55 pendingchaos: d3d11.invariantPosition fixed it?
20:55 cr0sis: nope i just have no idea how to do any of what you said
20:56 cr0sis: it's fine, though, really
20:57 kisak: cr0sis: in general, irc discussions get forgotten relatively quickly, so you'll want to report it over in the gitlab so that it doesn't go completely uninvestigated.
20:58 pendingchaos: the d3d11.invariantPosition thing should be pretty easy
20:58 pendingchaos: creating a file with "d3d11.invariantPosition = True" called dxvk.conf in the directory with the game's .exe should work
20:59 pendingchaos: (this directory should also contain files with names ending with "_d3d11.log" and ".dxvk-cache")
21:00 cr0sis: those files are one level above, i think i've got my working directory set up a bit odd
21:01 pendingchaos: then I think the dxvk.conf should be in the directory with the _d3d11.log
21:03 cr0sis: no change
21:40 Lyude: Anyone know if there's any users of the max_bpc connector prop in DRM yet?
21:40 vsyrjala: does xrandr count?
21:40 Lyude: yeah, I suppose xrandr counts
21:40 Lyude: was just kind of curious, since it seems like we'd also want a min_bpc property?
21:42 Lyude: example: user has a bunch of displays, but there's one big boy in the center that has nice HDR features and they need to make sure that monitor always uses the highest bpc possible even if that means lowering the bpc of other displays
21:44 vsyrjala: could just reduce the max bpc for the other displays. but i guess not quite as convenient as a min bpc prop
21:50 Lyude: vsyrjala: yeah-my other thought with that though is that I don't see how we'd be able to figure out what the resulting bpc for a display is going to be just from using the max_bpc property. Like, pretend we suddenly support max_bpc properly on mst. We might want to be able to show the user what the resulting bpc for a given mode configuration will be before setting it. This might be possible
21:50 Lyude: with min_bpc since userspace could list all of the displays without a min_bpc set as "auto", while displays the user has explicitly forced to a higher bpc would show the final resulting bpc of the new state. But, I don't see any way we could give the user that info just with max_bpc, all we can do is check whether the whole display configuration passes atomic check or not - we can't retreive the
21:50 Lyude: resulting bpcs for the new state for each respective display
21:54 Lyude: anyway-i'm writing up a bunch of issues for the gnome gitlab (will probably get kde/sway involved in the discussion too) since I'm planning on working on this stuff soon for nouveau (finally, MST DSC helpers and fallback link retraining support!), and it's probably good if I start figuring out what's missing in the kernel/what we need to do better ahead of time
21:54 dviola: I want to add a Tested-by to a patch, will downloading the mbox and applying it to my linux repo clone, amend the commit and resend the patch via git send-email do it?
21:55 Lyude: dviola: yeah it should, if it's explicitly drm related you might want to apply it to drm-tip/drm-tip instead
21:55 dviola: Lyude: ok, thanks :)
21:55 Lyude: dviola: also see https://drm.pages.freedesktop.org/maintainer-tools/dim.html , it has a nice command called commit-add-tag
22:03 dviola: forgot to add Re: to the subject, oops
22:04 Lyude: not sure that matters?
22:04 dviola: https://lkml.org/lkml/2020/8/25/1171
22:05 Lyude: if you're trying to add a new version of a single patch in a multi-patch series, just making sure you have the in-reply-to header set correctly should be enough for patchwork to notice
22:05 Lyude: but that's just a single patch so it should be fine
22:05 Lyude: dviola: you do need to add a "v2" to the subject though
22:05 Lyude: (git send-email --reroll-count=2)
22:09 dviola: thanks
22:14 dviola: I did a format-patch and emailed the patch as an attachment to Gerd Hoffmann :D
22:14 dviola: easier for me
22:14 dviola: I'll red on git more though
22:14 dviola: read*