01:20 xmnm: I see there are a few opengl over vulkan projects, has anyone tried them? I see at least zink, glove and vkgl
01:26 HdkR: Considering VKGL is dead and Glove is targeting ES, zink will be the best of the tree at some point
01:27 HdkR: best of the three*
01:27 jekstrand: Kayden, anholt_: So, my attempt to drop noise busted 4 GLSL parser tests. :-(
01:27 xmnm: I didn't know VKGL was dead. I guess maybe at some point I'll be able to run exanima with zink and see if anything changes
01:27 jekstrand: Is there a way I can make a built-in function that's just a bunch of constants that explicitly fails to compile if it's put in a constant expression?
01:28 jekstrand: Is there a flag I can set on the function signature or something?
01:29 xmnm: hmm loks like arch's mesa package doesn't include zink
01:30 Kayden: I thought that built-in functions of constant values was always allowed
01:32 jekstrand: noise seems to be explicitly called out as not
01:32 jekstrand: even though that doesn't make sense even with older GLSL
01:33 jekstrand: Maybe I can add a quick check
01:42 jekstrand: Kayden: I added a thing.
02:03 Kayden: seems like that maintains the current behavior of the compiler
02:04 Kayden: that looks ok to me with a commit message
02:56 imirkin: jekstrand: maybe dfdx has it too?
04:30 xmnm: regarding the trouble game, I asked a friend who has the game as well as an rx 580 card and a r9 270, polaris runs the game at ~200fps, the r9 270 runs it at 6fps, so similar to what I experience
04:30 xmnm: the 39 270 is a sea islands card, just like my amd hd 7770
04:30 xmnm: so it's possible only sea islands cards are affected
04:31 xmnm: he also has an r9 280 and will test that as well in a while
05:10 jekstrand: Kayden: I was going to just squash it in
05:14 Kayden: oh, sure
05:14 Kayden: feel free to keep the R-b
05:16 xmnm: I just noticed I said sea islands, but they are southern islands instead
05:17 xmnm: and the r9 280 behaves the same
05:17 xmnm: I wonder if sea islands cards have the same problem
05:20 jekstrand: Kayden: Cool. We'll see where my GLSL bug goes. If the GLSL people decide they're ok with us constant-folding noise(), I can write another patch to drop the special case.
05:50 airlied: danvet: the drm-misc-next PR diffstat has mm/slob.c | 2 +
05:50 airlied: and mm/slab.c
05:50 airlied: I'll was going to pull it now, but I'm outta time, will dig into a bit more tomorrow, it's likely harmless noise
05:51 airlied: just in case you happen across tzimmermann wondering what we are doing with it
06:00 xmnm: so finally I was able to boot into radeon!, removing xf86-video-ati wasn't taking all the xorg files with it, but after removing it manually I was able to load radeonw ithout a hitch. unfortunately, the game performs the same under radeon
06:04 xmnm: I'm unsure of where I should report this, I believe the problem is with radeonsi, and only some cards but I don't actually have any proof of it
06:15 danvet: airlied, I think that was me
06:16 danvet: airlied, fd7cb5753ef49964ea9db5121c3fc9a4ec21ed8e
06:16 danvet: properly acked by akpm for merging through drm in 5.8
06:16 danvet: I'll remind tzimmermann when he shows up
06:19 danvet: airlied, or want a new pull summary?
07:04 airlied: danvet: nah it's fine, thanks for trakcing it down
09:38 pinchartl: robher: quick question about DT bindings. can the maintainers section contain mailing lists ?
09:39 pinchartl: I'm thinking about a vendor that has set up a mailing list for upstream maintenance
09:54 MrCooper: kusma: since you're working on documentation, can you maybe work with Brian to get https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3771 merged?
09:59 kusma: MrCooper: Hmm, I haven't seen that one yet, I'm currently not working so much on the content as I'm working on mechanically converting it, though...
10:00 ChrisLane: Is there a user-facing IRC channel for mesa? Hoping to get some help with performance issues.
10:00 MrCooper: kusma: k, never mind, thanks for taking a look
10:01 kusma: MrCooper: I'll keep an eye on it, because I might have to adjust my converter once it lands anyway ;-)
10:01 kusma: MrCooper: Thanks for the heads-up :)
10:02 MrCooper: ChrisLane: this channel should be OK for that
10:02 ChrisLane: MrCooper: Okay thanks
10:13 ChrisLane: I'm running a laptop an nvidia 860M graphics card and Arch Linux 5.6.5-arch3-1, mesa 20.0.4, Wayland 1.18.0, wlroots 0.10.0, sway 1.4.
10:13 ChrisLane: Prior to switching to mesa and wayland, I ran nvidia drivers in X. As an example I'll use Minecraft for performance (the same occurs for glxgears etc.), I used to get well over 100fps and now I get ~30fps.
10:13 ChrisLane: I've tried running with `vblank_mode=0 DRI_PRIME=1`, this helps a small amount.
10:13 ChrisLane: Also compiling/running with the git versions of all the above (besides linux) has no effect.
10:13 ChrisLane: I took a look at https://mesa3d.org/perf.html and most of the suggestions seemed like things I could not alter, though I did try `MESA_NO_DITHER`, there was no effect.
10:13 ChrisLane: I'm unsure what else to try.
10:16 ChrisLane: glxgears with and without DRI_PRIME, you can see it ends up having worse performance with DRI_PRIME https://gist.github.com/ChrisLane/8fdc59da76602c8ec9a7910128149ae7
10:17 pq: ChrisLane, do you still have *any* bits of the NVIDIA proprietary driver installed? They won't allow you to use the GPU for rendering with Sway I believe. You'd have to use Nouveau all the way.
10:18 pq: that is, the kernel driver and the Mesa (GL) driver. The concept of an Xorg driver does not exist with Wayland.
10:20 pq: ChrisLane, check glxinfo. I bet it says "llvmpipe", which is a software GL renderer.
10:21 ChrisLane: Nothing related to nvidia in `dmesg`. The only package installed referencing nvidia is "libvdpau", a dependency of "ffmpeg"
10:21 pq: ok
10:21 pq: Do you have Nouveau installed then?
10:22 pq: should be a kernel module as well as a Mesa component
10:22 ChrisLane: No reference to llvmpipe in glxinfo
10:22 pq: I don't know nvidia cards anymore, so I can't say how well nouveau supports your specific card.
10:23 pq: ChrisLane, what's the "renderer string" in glxinfo?
10:25 ChrisLane: nouveau kernel module is installed and loaded
10:26 ChrisLane: w/o DRI_PRIME: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2)
10:26 ChrisLane: w DRI_PRIME: OpenGL renderer string: NV117
10:26 pq: sounds like it's all good then
10:26 pq: why do you think you have a problem?
10:27 ChrisLane: I've been assuming it's just a lack of performant support for my card since it's fairly old
10:28 pq: quite probably, but also probably not just because it's old
10:28 ChrisLane: But the jump down in performance was unexpectedly large
10:29 pq: you'd have to ask Nouveau people about that - maybe someone here wakes up
10:29 ChrisLane: *fingers crossed
10:30 pq: personally I'd be happy the card works at all, but it has been long time since I had an NVIDIA card
10:30 pendingchaos: ChrisLane: with nouveau, nvidia gpus have have to be reclocked manually
10:30 pendingchaos: did you do that? performance won't be as good as the nvidia driver but it's much better afaik
10:31 ChrisLane: Hmm I think I read about that at some point but no, I haven't done that yet
10:31 ChrisLane: Will take a look into that now
10:33 emersion: https://wiki.archlinux.org/index.php/Nouveau#Power_management
10:46 tomba: danvet: I'm trying to use drmm_kzalloc() for tidss's encoder, but obviously I'm doing something wrong: https://pastebin.ubuntu.com/p/YbKwGmkTFn/ . If I read it right, the encoder is freed via drm_dev_put(), but then used in drm_mode_config_cleanup() which happens after the free.
10:48 tomba: danvet: this is with drm-misc-next and your devm_drm_dev_alloc series on top. any thoughts on where I go wrong
10:48 danvet: tomba, yeah that part doesn't work yet
10:49 tomba: danvet: ah =)
10:49 danvet: my idea for these is a combo macro/helper which allocates the containing struct with drmm
10:49 danvet: and also sets up a cleanup action
10:49 danvet: and drm_*_cleanup will then remove it from the list
10:50 danvet: so drm_mode_config_cleanup won't hit the freed memory
10:50 danvet: drm_mode_config_cleanup will still be needed for some of the other objects like if you have any leftover drm_fb or properties and stuff like that
10:52 danvet: tomba, so right now all you can do is clean up any of your own stuff with drmm_
10:52 danvet: but not yet anything with overlap
10:52 danvet: or at least not anything with overlap with drm_mode_config_cleanup
10:53 danvet: tomba, I think we'll also need a drmm_kzalloc where you can supply the cleanup callback
10:53 danvet: to avoid a bit too much silly allocations
10:55 tomba: danvet: is the HW supposed to be accessible even after the standard devm_* cleanup has been done? I guess not, everything should be disabled already at that point, right?
10:55 danvet: yup
10:55 danvet: devm_ is for cleaning up hw
10:55 danvet: drmm_ for cleaning up the software/interface side of things
10:56 danvet: that's at least the idea
10:56 danvet: mmap() atm unsolved, I'm just pretending that doesn't exist :-/
10:56 tomba: danvet: ok... then I guess tidss doesn't have any "own stuff" to be handled
10:56 danvet: yeah that's more for rendering drivers with exported dma_fence or dma_buf
10:56 danvet: or lots of other fun stuff
10:57 danvet: althought the refcounting for dma_fence/buf isn't fixed yet
11:18 ChrisLane: pendingchaos: With glxgears I can reclock all the way up to the highest setting for the best performance. With Minecraft, anything other than the lowest(original) setting makes the system hang, I switch to another tty and attempt a reboot and then get a kernel panic.
11:18 ChrisLane: So no luck there :/
11:20 ChrisLane: Highest clock for gpu still didn't beat intel on glxgears though O_o
11:22 imirkin: glxgears on a remote gpu is largely a measure of pci-e speed
11:22 imirkin: (or of vsync rate, depending on whether you're syncing to vblank or not)
11:31 pq: ChrisLane, IOW, glxgears rarely measures what you are actually interested in.
11:32 ChrisLane: Demonstrated the correct effects that I'd expect from bumping the clock speeds at least
11:32 ickle: unless you are interested in how fast can you push a buffer through the system
11:33 ChrisLane: Even still, clocks screwed up my system running something more taxing
11:51 imirkin: ChrisLane: increasing pstate tends to bump up pcie speed =]
11:51 imirkin: you can check this with lspci
11:51 imirkin: it'll go from a 2.5GT/s link to 8.0GT/s
11:51 imirkin: (more T/s = more glxgears frames!)
11:52 imirkin: (look under "LnkSta" for the current value)
11:55 malice: imirkin: How many -v's do I have to pass to get this?
11:55 imirkin: 2, i think
11:55 malice: 87818 frames in 5.0 seconds = 17563.439 FPS
11:55 malice: Hmmm
11:55 imirkin: malice: lspci -vv -d 10de:
11:55 imirkin: have to be root
11:55 imirkin: (or run it as root)
11:55 malice: Ah root
11:56 imirkin: for example: https://hastebin.com/gakeqitesa.cs
11:56 imirkin: you can see that it's capable of 8GT/s, but only currently at 2.5GT/s
11:56 imirkin: due to the high level of awesomeness of my motherboard
11:58 malice: Cool
11:58 imirkin: the pcie speeds are specified as part of the pstate, so depending on the actual board, it may or may not happen
11:58 imirkin: however i think it's quite common for laptops
12:12 baedert: Hey, https://gitlab.gnome.org/GNOME/gtk/-/issues/2646 this looks like a problem inside mesa, has anyone seem something similar before?
12:14 imirkin: doesn't ring a bell
12:15 imirkin: baedert: is it easy to run just the one test?
12:16 baedert: imirkin: Yes, but I can't reproduce, I'd have to ask the reporter
12:16 imirkin: oh goodie.
12:26 malice: Does anyone else sometimes randomly see some random horizontal lines?
12:28 ccr: it's just the reality matrix glitching .. oh, you mean on a monitor?
12:30 imirkin: as an aside, The Matrix came out in 1999 - 21 years ago.
12:31 MrCooper: yeah, blew my mind when we watched it again last year
12:43 malice: ccr: Yeah, monitor
12:56 Moiman: malice: tearing?
12:57 malice: Moiman: No, short white horizontal line on my terminal, black background
12:57 malice: But I've seen it on firefox too, and on multiple gpus, even quite old ones
12:57 malice: In entirely different hw setups
12:57 malice: Including monitor
13:00 imirkin: the only common factor is you? :)
13:00 imirkin: i start liking ccr's explanation...
13:05 malice: Really? Noone else seen it? Hmm
13:14 robher: pinchartl: I suppose your case would be ok. I just don't want to see maillists which are covered by the directory location.
14:08 ccr: malice, nothing that I've ever seen brings to mind a "short white line". I've seen things, though .. CGA "update noise", rendering bugs, and a loose DVI-cable causing some rather interesting "pixel noise".
14:19 malice: ccr: Well, it might be gray or multiple shades of gray, not 100% sure, but it's always horizontal
14:20 danvet: tzimmermann, https://paste.debian.net/1141851/ does this look correct?
14:20 ccr:shrugs helplessly.
14:20 danvet: just checked, void* pointer arithmetic is indeed a gcc extension
14:21 tzimmermann: danvet, it looks correct, but it's ugly code :)
14:21 danvet: well you asked for it
14:22 tzimmermann: danvet, :D
14:22 tzimmermann: i think you should just keep the patch as-is
14:22 danvet: tzimmermann, or just the ddev_ prefix?
14:23 danvet: or want to do that yourself?
14:23 tzimmermann: danvet, if you want to change something, than maybe the ddev_
14:23 danvet: I'm not enthusiastic, since I might typo so better to let CI check it again
14:23 danvet: so that would mean merging earlieast tomorrow
14:23 danvet: or I could just start applying
14:24 tzimmermann: if we really care, we should have a bikeshedding session on dri-devel on how to name the drm_device variables
14:24 danvet: anyway quick compile check of the diff looked ok, so right now is the time to stop the git rebase fun
14:25 danvet: hm I think I'll do the grocery run now, then I'll either send out a respin or start applying
14:25 tzimmermann: whatever you prefer
14:26 tzimmermann: danvet, BTW sorry about missing the changes to core mm on the PR
14:26 danvet: no worries on that
14:26 danvet: dim script should dump the diffstat somewhere, that helps with stuff like that
14:26 danvet: but generally it's huge
14:27 danvet: maybe we should have a filter for "stuff not maintained in drm.git" so it sticks out more
14:27 danvet: maybe even pre-fill that in the template
14:27 danvet: e.g. "following patches touch code outside of drm.git:" + list of oneline commit summaries
14:28 tzimmermann: danvet, hmm. could be helpful.
14:28 tzimmermann: it showed me a gitk window of all patches. i could have seen the information there
14:29 danvet: only issue is that we're adding new stuff to drm.git (outside of drivers/gpu) so this is a bit tricky
14:29 danvet: either outdated or I have no idea how to program with just looking at MAINTAINERS
14:30 tzimmermann: one question but dim tooling: is there a way of aborting the pull-request command at any stage?
14:30 danvet: and some of these additions are tricky, e.g. fbdev is in drm-misc
14:30 danvet: but not all in drivers/video is fbdev
14:30 danvet: hit ^C?
14:31 danvet: or run it with --dry-run
14:31 tzimmermann: danvet, ok. it's that easy.
14:31 danvet: but it's not perfectly idempotent
14:31 danvet: since a lot fewer people use it, the maintainer tools are definitely a lot less polished :-/
14:31 tzimmermann: i was worried that ^C only aborts the current step, but the overall script keeps running
14:32 danvet: tzimmermann, so for the programmatic check for "outside stuff" I think you'll need
14:33 danvet: collect the directory/file entries of all MAINTAINERS entries that point at drm-misc.git
14:33 danvet: if a patch is entirely contained within these, it's good
14:33 danvet: if something sticks out, it must be annotated
14:33 danvet: (or maybe we should add a new entry)
14:33 danvet: but that's a bit a thing to type up
14:34 danvet: has the upshot though that it should also work for drm-intel
14:34 danvet: and so would make j4ni happy I think
14:39 tzimmermann: so it's 1) grep MAINTAINERS for drm paths, 2) match each patch against that list 3) filter out those patches that touch additional files
15:04 ElBarto: eric_engestrom: xexaxo1: thanks for your reviews, I think everything should be good now
15:16 Putti: malice, I saw an youtube video titled "worst graphics card ever" or something like that which was built on a bread board and there was similar issue. The cause was (as far as I recall) that the bread board connector acted as a capacitor meaning it charged some electricity in itself, and since the pixel data is sent as a voltage spike that occur every few nanoseconds the extra capacitance caused by the "massive" amount of metal in the
15:16 Putti: bread board connector caused missing some of the pixels because the voltage wouldn't change fast enough. The video has better explanation of this.
15:16 Putti: malice, so given this have you tried another cable?
15:16 Putti: a shorter one maybe
15:16 imirkin: he said he's seen this across hw setups and monitors
15:17 Putti: yes
15:17 imirkin: but all with the same cable? heh.
15:17 Putti: maybe also some big magnet in the environment could cause this
15:17 imirkin: i expect computers don't work too well inside an MRI machine...
15:20 malice: Putti: Seen this on vga too, currently displayport
15:20 malice: Also hdmi
15:21 Putti: malice, okay but separeta cables? there are converters for those..
15:21 malice: There's actually like not a single common component between all these systems left
15:21 Putti: ok
15:21 malice: Except maybe my wooden table
15:21 malice: It's really not a big thing, it only lasts like one frame or something, and fairly rare, was just wondering if anyone else has had that
15:22 Putti: I don't remember ever seeing that
15:22 malice: As I've had it with two separate igpus and an rvii :P
15:22 Putti: malice, and different PSU?
15:22 malice: Yes
15:22 imirkin: malice: except the MRI machine this is all happening inside? :)
15:22 Putti: :D
15:22 malice: imirkin: Well, that too :D
15:23 vsyrjala: aliens!
15:26 imirkin: malice: back in the VGA days, could you see 60hz monitors blink?
15:26 imirkin: (rather, in the CRT days)
15:27 malice: imirkin: Idk, I was a kid back then :P
15:27 imirkin: 60hz monitors gave me a headache pretty swiftly ... had to go to 85hz
15:27 imirkin: anyways, maybe you just have very fast eye reaction times or something
15:28 Putti: malice, also picked up from the video: all white pixel means voltage occuring so still thinking maybe some external interference from the environment.
15:28 Putti: that is with vga
15:28 malice: imirkin: Reacting to what tho? It's a flat color, and a random few white pixels horizontally
15:28 imirkin: heh
15:28 imirkin: i don't have a great theory
15:28 malice: Gotta be at least a full frame probs :P
15:28 Putti: malice, are they in the same horizontal line?
15:29 malice: Putti: I'm not sure if same spot, but it looks quite similar usually
15:29 malice: But it's really quick, don't have time to examine
15:30 Putti: haha, okay. This would be a fun mystery to solve.
15:30 malice: Indeed
15:30 malice: But it's really quite rare
15:30 malice: I notice this maybe like once a week or so
15:30 imirkin: do you see it in non-monitors?
15:30 malice: Might occur more often, but yeah
15:31 malice: imirkin: Never noticed at least
15:31 imirkin: there's gunk that's usually settled at the bottom of the eye, but in various conditions it can float around
15:31 imirkin: which causes "shooting stars" to appear
15:31 malice: Haven't seen that, but these lines are always horizontal on my monitor
15:31 malice: And like one pixel high
15:34 malice: I'm not sure I've seen it on windows, I have a vague memory that I may have, but can't be 100% sure
15:34 malice: If I have, then it's probably unlikely to be a software issue?
15:35 malice: But I mean
15:35 malice: Windows is always artifacting and crashing and blackscreening and rebooting
15:38 ccr: anti-midas touch? :P
15:40 imirkin: there's a great quote in "Inside Llewyn Davis" about that...
15:40 malice: Yes, everything I touch breaks
15:40 Putti: malice, https://askubuntu.com/questions/258899/random-white-pixels-on-screen well other people have this too
15:41 Putti: maybe not exactly the same you have?
15:41 imirkin: something along the liens of "you're like king midas's idiot brother, everything you touch turns to shit"
15:41 malice: Putti: This looks like a different, far worse issue
15:41 malice: imirkin: Haha :D
15:41 imirkin: [it's a really good movie, if you haven't seen it]
15:42 imirkin: [quite sad, imo, but really good]
15:42 malice: Well
15:43 Putti: malice, one more question: has this happened ever on a brand new display?
15:43 malice: Putti: Yes
15:43 Putti: maybe like 1-2 weeks old
15:43 malice: Oh
15:43 malice: Idk, pretty new, but idk if it happened right when I got it
15:43 Putti: maybe all hardware die eventually
15:43 malice: The other one was from 2006 tho
15:45 malice: Btw, noone here has anything to do with amd windows drivers, right?
15:47 malice: Eh, I'd imagine not
16:06 xmnm: hello, I'd like to know if there's some way to determine what's causing low performance in a game, to open a bug report to keep track of the issue, I think that the problem might be radeonsi, but don't really have anything to back me up. Exanima, the game, plays at 12fps while cpu usage remains %10, gpu 3%, and there's low ram and vram usage. I saw this happen in my computer with an amd hd 7770 (southern islands), asked a friend to
16:06 xmnm: test and he didn't have the issue on an rx 580, but had it with his r9 270 and r9 280 (both southern islands cards), this is the only things I really have to go by, I don't know what to try to get useful information
16:15 imirkin: xmnm: probably #radeon is a good start. you can also file a bug at gitlab.freedesktop.org/mesa/mesa
16:16 xmnm: the thing is I'm not sure what part of the stack is having problems so I didn't want to move before being relatively sure
16:17 xmnm: but I will ask again on radeon, thank you
16:17 MrCooper: we can always move the issue as needed, but Mesa is the most likely
16:20 xmnm: whenever gitlab decides to finish loading I'll look int creating an account
16:21 MrCooper: you can log in with credentials from a number of other services FWIW
16:22 xmnm: but it still needs to load first, life on 2g isn't a fast life
16:23 imirkin: yeah, gitlab is extremely heavy unfortunately
16:23 imirkin: i can barely use it on my desktop
16:25 xmnm: well, carrier isn't collaborating with me, I'll have to retry later
16:29 imirkin: xmnm: i hear gigabit is nice :)
16:29 imirkin: i guess not too common in .ve though =/
16:31 zf: I suspect we don't actually need to flip, but I'll have to check that
16:31 zf: whoops, wrong channel
16:31 xexaxo1: ElBarto: sorry to bother you again - gitlab seems unhappy "Fast-forward merge is not possible. Rebase the source branch onto master to allow this merge request to be merged." can you please see my comment and rebase
16:32 xmnm: imirkin, you'd be very lucky to even have 10 megabit down
16:32 xmnm: and I'd be very lucky to have my broadband connection fixed after 3 months of nothing
16:33 imirkin: yeah, it was a tongue in cheek comment before i looked up where you were coming from
16:33 imirkin: sorry
16:33 xmnm: I don't mind at all
16:33 xmnm: don't worry
16:34 imirkin: i don't know too much about the situation there, but i know it's not great, and the current COVID-19 situation couldn't have improved matters
16:34 xmnm: I wouldn't be surprised if we were the only country that got more expensive gas after covid
16:35 imirkin: not what one might expect from a gas exporter...
16:35 xmnm: that's what gas shortage does to you, but I guess I should end this off-topic conversation!
16:39 ElBarto: xexaxo1: yeah I'm on it
16:46 dcbaker: I noticed since I got back from vacation I have to manually trigger all cI jobs in mesa, is this expected or is something wrong with my setup?
16:47 ElBarto: ElBarto: hope my comment anwser your question (and the next one)
16:47 ElBarto: xexaxo1: ^
16:47 imirkin: dcbaker: expected
16:47 imirkin: someone changed it semi-recently to avoid unnecessary runs
16:48 hakzsam: dcbaker: it's mostly for reducing bandwidth and then save money
16:49 hakzsam: only Marge automatically launches pipelines now
17:06 dcbaker: ah, that makes sense
17:11 MrCooper: I posted about it to mesa-dev, but I guess you missed that due to being away
17:22 Lyude: if I had two patches for drm-misc, the first of which is a small fix with a Cc for stable@vger.kernel.org, and the second of which isn't a fix and just does some cleanup (but probably won't apply without the first patch), how should I push them to drm-misc? should they both go to drm-misc-fixes or something else?
18:21 krh: Kayden: yeah +1 to load/store_reg
18:30 pinchartl: robher: thanks a lot for the quick dt schema check fix, very appreciated
18:31 robher: pinchartl: np!
18:33 pinchartl: robher: how painful do you think it would be to convert graph.txt to yaml ?
18:34 pinchartl: I've briefly talked to mripard about it, and we're both scared :-)
18:36 robher: pinchartl: Probably the worst part is handling with and without unit-addresses
18:37 pinchartl: is the fact that the ports node is optional a big issue too ?
18:38 robher: pinchartl: yeah, just another combination...
18:39 robher: pinchartl: I've not worried about it too much as dtc already checks much of what a schema would.
18:40 robher: pinchartl: what we really need is a meta-schema for what device schemas need to define or not define.
18:41 pinchartl:needs to look into what meta-schemas are used for
18:41 robher: pinchartl: device schemas shouldn't need to worry about #address-cells or #size-cells for example.
18:41 robher: pinchartl: the schema for the schema. :)
18:43 robher: pinchartl: they're 'fun' because the json-schema vocabulary are also the properties.
18:44 pinchartl: so the meta-schema will make sure that no yaml bindings file handle #address-cells in the ports node, while #address-cells will be validated by the graph.yaml schema ?
19:05 robher: pinchartl: right.
19:15 emersion: vsyrjala: do you have plans to resurect https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html ?
19:16 emersion: vsyrjala: one of our users is hitting a bug of not being able to configure their screen independently, which both have the same serial and an unstable connector ID (it's a dock)
19:16 emersion: vsyrjala: https://github.com/swaywm/sway/issues/5226
19:17 gitbot: swaywm issue 5226 in sway "Multi Monitor setup - same ID and Serial?" [Open]
19:18 emersion: as always, i can provide user-space for this
19:29 vsyrjala: no plans atm
19:29 emersion: rip
19:55 Lyude: :(, seanpaul - I think we need to consider either reverting 6bb0942e8f46 ("drm/dp_mst: Remove single tx msg restriction.") or only activating multi-tx conditionally based on dp quirks
19:56 Lyude: I just noticed that it completely breaks the lenovo USB-C MST hub I've got here
19:56 Lyude: that + amd's experience with multi-tx breaking things + the DP 2.0 spec saying not to use multi-tx
19:57 Lyude: tbh though, the problem with activating it via quirk i'd imagine is that we can't use multi-tx if anything in the path down to a mstb doesn't support it
19:59 Lyude: also, yikes, why does this hub send RSNs after every payload allocation o.O
20:04 anholt_: seeing a bunch of timeouts from collabora lava right now
20:04 anholt_: tomeu, daniels ^
20:15 daniels: anholt_: eating dinner but will look after. can you link me to a job quickly please?
20:16 anholt_: https://gitlab.freedesktop.org/dbaker/mesa/-/jobs/2375564
20:16 anholt_: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/2374719
20:17 hakzsam: yes, got some CI failures
22:26 Gongjin: Is anyone here familar with wifi drivers?
22:26 Gongjin: I am attempting to connect tothe internet via a ethernet cable on an intel ethernet device and it is not detecting the cable connection.
22:27 anholt_: this is a channel for graphics.
22:27 kisak: Hello Gongjin, this channel is primarily a graphics-oriented channel, you might have some luck over at #linux-wireless
22:28 Gongjin: Ah thanks kisak.
22:30 daniels: anholt_: sorry to have not got back to you. if it's still having issues - caused by physical link problems with our office we can't resolve from home - please just merge an immediate disable with my A-b
22:30 anholt_: seems to have quieted down this afternoon
22:31 daniels: cool. we're trying to change fibre provider, but kind of tough rn
23:04 airlied: karolherbst: so what's needed to land the structirzer? review, is anyone signed up?
23:04 airlied: I don't think it should just live in a branch if it's not changing
23:05 Lyude:realizes we might be missing a bunch of basic retraining for mst ._.
23:13 karolherbst: airlied: reviews, yes
23:14 karolherbst: airlied: It seems that everybody agrees it's working as expected though
23:15 karolherbst: maybe we can start with the vtn changes I made and get this at least done arleady
23:15 karolherbst: and then we can clean up the pass together or so
23:15 karolherbst: the original author doesn't seem to be around anymore, which is quite sad
23:17 karolherbst: airlied: uhh.. I see I don't have the actual newest version for odd reasons, but I think only comments were added
23:17 karolherbst: will look into it tomorrow then
23:18 airlied: karolherbst: I assume review is just asking jekstrand a lot :-P
23:18 jekstrand: ?
23:18 karolherbst: mhh, seems like there are some functional changes as well
23:19 karolherbst: anyway, I'll deal with that tomrrow
23:19 karolherbst: jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2401
23:19 jekstrand: Oh, that....
23:19 karolherbst: no point into looking into the pass yet as I still need to update it to the latest version...
23:19 karolherbst: shouldn't be much though
23:21 karolherbst: heh.. I have an idea..
23:22 karolherbst: pushed
23:25 karolherbst: jekstrand: the code should contain a lot more comments though, so hopefully it's much easier to follow... but I guess revieweing that with no knowledge on what's actually going on there will be challanging
23:25 karolherbst: or....
23:25 karolherbst: we just ack it
23:25 karolherbst: the pass I mean, the rest we can properly review
23:25 karolherbst: but the pass itself won't break stuff... so
23:26 jekstrand: I don't know that I like just ACKing a control-flow structurization pass....
23:26 karolherbst: yeah...
23:26 karolherbst: but only clover would use it
23:27 karolherbst: anyway, I would also prefer a proper review
23:27 airlied: and clover is currently useless without it :-P
23:27 karolherbst: I just think it might get super hard to convince somebody to do it
23:28 karolherbst: and my knowledge about structurizing is basically knowledge I got from my "oh, let me try this, it might work.. oh it broke" approach
23:28 karolherbst: luckily the other patches are wy easier to understand I hope
23:30 karolherbst: airlied: I have an idea, we can convince the others who need this as well to do that for us :p
23:30 karolherbst: they are equally guilty of procrastination, just that I got lucky to get pinged about a proper one :D