00:23 Darxus: Anybody have a good way to communicate to AMD that their PPA links on this page are broken? https://www.amd.com/en/support/kb/release-notes/rn-amdgpu-unified-linux-20-45 (One of them is mine.)
00:37 FireBurn: The space is being encoded into the URL
00:42 Darxus: It's more involved than that, they're using the apt source url, instead of the link to the relevant web page.
01:53 Darxus: What's going on here? This failed to upload because the file already exists, but there's no way a file exists with today's date here: https://code.launchpad.net/~darxus/+archive/ubuntu/linux-firmware-daily/+recipebuild/2697065
01:54 Darxus: Oh, I didn't realize it kicked off an automatic build. Nevermind.
03:12 remexre: maybe somewhat OT, but does anything non-nvidia implement EXT_stream_consumer_egloutput etc?
03:22 HdkR: remexre: Only Nvidia supports eglstreams
07:40 uis: Not banned...
08:47 Sumera_: danvet: so I managed to compile Rodrigo's patch and install it. I am able to mount it using `mount -t configfs none /mnt/` but can't enable or disable it as mentioned in the patch.
08:50 Sumera_: Also one of the time when I was playing around with it in tty, doing `sudo systemctl isolate graphical.target` sort of caused things to crash with...um..weird errors that i was unable to capture but I think I saw some mentions of _lock() in the error. Been unable to reproduce it though.
08:53 Sumera_: Plus, everytime I mount it , cursor starts acting weird. Not sure how to exactly describe it but it um leaves traces of itself or the um a small black box where I had clicked (sort of like Windows in early 2000s...). Behaviour remains if I unmount.
08:59 danvet: Sumera_, huh ...
08:59 danvet: can you capture something when you stop the graphical session first, then load vkms?
09:00 danvet: I guess vkms is confusing your main desktop somehow
09:02 Sumera_: danvet: hm, it happens only when I do the configfs thing tho- fine otherwise. Also um you want to me load vkms and the configfs in tty, and then get back to graphical session and check the cursor?
09:04 danvet: Sumera_, like when you only mount configfs, the glitch starts already?
09:05 Sumera_: yep. everything is fine if I only mount vkms
09:05 Sumera_: *load vkms
09:06 danvet: huh
09:06 danvet: can you push your tree somewhere pls?
09:07 danvet: I'd kinda expect some trouble if the cursor gets removed and things like that, but just mounting configfs shouldn't change anything
09:14 Sumera_: danvet: Here you go https://github.com/Sylfrena/linux/commit/00175c289e534cdf2d4d540e19d42e59b5124464
09:17 Sumera_: actually, ignore that one. Check https://github.com/Sylfrena/linux/commit/8c0bb575f526003b1773fe25f65a5bb0a723ce32 instead
09:20 Sumera_: Here is an image https://snipboard.io/nW7y5c.jpg
09:32 danvet: Sumera_, looks like software cursor with some broken damage handling somewhere
09:33 danvet: Sumera_, so just mounting configfs causes the corruption, nothing else needed?
09:35 Sumera_: yep, thats all. `sudo modprobe vkms` `sudo mount -t configfs none /mnt/`
09:35 danvet: I'm totally confused tbh
09:37 danvet: Sumera_, if you load vkms with enable_cursor=1
09:37 danvet: does it still happen?
09:37 Sumera_: yep I don't know what happened. Oh, something I forgot to mention. I tried the writeback test also. That caused a freeze as well.
09:37 Sumera_: Let me try that.
09:38 Sumera_: I will need to restart the machine and all so I will get back to you in sometime.
10:07 Sumera_: danvet: looks like I got it wrong. It happens when I load vkms in a graphical session.
10:07 danvet: Sumera_, ok that makes more sense
10:07 danvet: if you load with enable_cursor=1, does the issue disappear?
10:07 Sumera_: Should it have not happened while using enable_cursor
10:08 danvet: I suspect
10:08 Sumera_: oh,no, issue persists with enable_cursor=1
10:08 danvet: huh
10:08 danvet: but igt cursor tests run fine with that option enabled?
10:10 melissawen: hey, enable_cursor is enable by default... if you want to see other behaviour, you should disable it, enable_cursor=0
10:15 melissawen: I mean, if the patch applied didn't change the current behaviour
10:17 danvet:missed that
10:30 mripard: danvet: can you have a look at https://lore.kernel.org/dri-devel/20201207104231.ipa5dccnxxro3xxc@gilmour/, there's something in that driver I'm not quite sure of and would like your feedback
10:30 mripard: it feels like what paulk-leonov did would belong in some core stuff, but it also feels a bit cargo-culty
10:31 paulk-leonov: I think the bottomline question is: why is the page flip event expected to be handled by the deriver instead of the core, unlike the page flip event
10:31 paulk-leonov: driver*
10:31 danvet: the core cant
10:31 paulk-leonov: unline the vblank event* sorry
10:31 mripard: and why only less than half the drivers seem to be doing it
10:32 danvet: there's a fairly extensive discussion of this entire topic in the drm_crtc_state->event kerneldoc
10:32 danvet: including links to helper functions that might or might not apply
10:32 paulk-leonov: oh ok
10:32 danvet: which have futher discussions
10:32 danvet: if that's not clear, I'm happy to improve the docs
10:33 danvet: this is decidedly not trivial to actually get right in driver code
10:33 danvet: especially since most of the times you wont ever see the race in normal testing
10:58 mripard: danvet: thanks for the links
11:09 mripard: from what that doc says, I guess we only really need to call drm_crtc_send_vblank_event when we get the vblank interrupt and in disable
11:10 mripard: but vkms for example will handle the CRTC disabling as part of atomic_flush (to also handle the case where the "registers" are updated at the next vblank)
11:39 MrCooper: danvet: Raven & Tonga are supported by amdgpu only, not by radeon
11:42 mripard: tzimmermann: can you merge drm/drm-fixes into drm-misc-next? I need some patches that were in -rc7
11:43 tzimmermann: ok
11:46 tanty: tomeu: it would be great if you find some time to go over:
11:46 tanty: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6388
11:47 tanty: and
11:47 tanty: https://gitlab.freedesktop.org/gfx-ci/tracie/tracie_dashboard/-/merge_requests/37
11:49 mripard: tzimmermann: thanks :)
11:50 tzimmermann: mripard, is that allowed?
11:50 tzimmermann: i don't want to mess up git history too much
11:51 tzimmermann: danvet ^
13:15 mripard: tzimmermann: I'm not quite sure what is the policy during the merge window
13:15 mripard: but otherwise it's usually ok
13:28 danvet: MrCooper, hm I guess then maybe similar bug in amdgpu
13:29 danvet: tzimmermann, usually should go through drm trees first
13:29 danvet: and Linus hasn't pulled in the maim merge yet
13:30 danvet: mripard, what's the excuse of the day?
13:30 danvet: hm really a bit awkward right now
13:31 mripard: danvet: the helpers rework for vc4 needs some patches that were in rc7, but drm-misc-next is still at rc4
13:31 mripard: *rc3
13:32 mripard: as far as I'm concerned, the current drm-fixes branch would be fine
13:32 mlankhorst_: I'll forward
13:33 danvet: hu -next is also only at -rc3
13:33 mlankhorst_: if drm forwards
13:33 danvet: yeah drm is a bit awkward right now with merge window and all
13:34 danvet: MrCooper, huh I got a t-b for that patch
13:35 danvet: oh it's the amdgpu variant from könig
13:37 tzimmermann: danvet, mripard; ok, i won't do anything until a decision has been made
13:38 danvet: I decided to yolo, I'm on vacations next week, airlied's problem :-)
13:52 danvet: mlankhorst_, tzimmermann, mripard there's a bit much conflict going on, I'd like to wait for linus' merge first before pushing this one out
13:53 danvet: mripard, is if bugfixes for 5.11 or next material for 5.12?
13:54 tzimmermann: danvet, mlankhorst_, mripard. ok
13:54 tzimmermann: i'm on vacation after tomorrow
13:59 mripard: danvet: next material, it can wait
14:01 danvet: mripard, ok if it waits until after -rc1?
14:02 mripard: yep
14:03 mripard: I just wanted to reduce my backlog, so it's not it should put a burden on anyone if it's an issue
14:29 pq: mupuf, your free.fr email address seems to fail to deliver.
14:38 emersion: can someone assign this MR to marge again? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7898
14:38 emersion: it's Rb and everything
14:40 emersion: thx!
14:42 mupuf: pq: it is a little random... I started moving to another provider months ago, but I need to finish the transition
14:42 mupuf: sorry about that!
14:53 pq: mupuf, I think it was https://lists.freedesktop.org/archives/dri-devel/2020-December/291215.html - nothing too important.
14:54 mupuf: thanks, I'll check it out :)
14:56 emersion: yeah, i mostly cc'ed you just fyi, not expecting any reply
14:56 mupuf: emersion: :)
14:56 mupuf: Not expecting replies on VRR is pretty expected :D
14:57 emersion: lol
15:06 bl4ckb0ne: can i have a review on https://gitlab.freedesktop.org/mesa/waffle/-/merge_requests/76 pls
16:22 Darxus: I'm still looking for a way to communicate to AMD that they have bad links in their latest software release notes, posted this yesterday: https://community.amd.com/t5/general-discussions/bad-links-in-amd-linux-software-release-notes/m-p/430352
16:56 MrCooper: Darxus: I'd file an issue at https://gitlab.freedesktop.org/drm/amd/-/issues
18:12 Darxus: MrCooper: Great, thanks.
18:14 Darxus: They responded to my community.amd.com post and fixed it.
20:52 alyssa: 'note: parameter passing for argument of type ‘bi_index’ {aka ‘struct <anonymous>’} changed in GCC 9.1'
20:52 alyssa: how do I make this go away? :'|
20:57 HdkR: Pass by pointer or reference. It's letting you konw that the ABI has changed and GCC doesn't have a option to remove the warning
20:57 alyssa: I see.
20:57 alyssa: These are all mesa-internal routines, I don't care about the ABI as long as it's correct..
20:57 HdkR: Almost always a oops, they messed up the ABI. So any external interface would break :P
20:59 alyssa: HdkR: Weee! :p
21:01 HdkR: Is this another armhf breakage on GCC's side?
21:01 alyssa: Hmm?
21:01 HdkR: ABI has broken a couple of times on the armhf side. Not sure how many have occured on AArch64 side
23:04 labbott: win 21
23:04 alyssa: ...wrong channel?
23:06 labbott: missing a forward / :)
23:08 alyssa: ---ah, yes :)
23:09 HdkR: win 21 times
23:14 Kayden: mareko: hey, looking at a regression from 63f7d7dd0a843254ffa51a41e2b90d5ab4dc45d7 (mesa: take advantage of sorted parameters in _mesa_load_state_parameters) - your comment says "Parameters are optionally sorted as follows. Uniforms and constants are first, then state vars."
23:14 Kayden: But it certainly doesn't seem to be optional. _mesa_load_state_parameters asserts that LastUniformIndex < FirstStateVarIndex.
23:15 Kayden: ir_to_mesa translating fixed-function fragment shaders from GLSL IR to Mesa IR isn't sorting things, so fixed function FS on ancient classic drivers is just dying
23:15 alyssa: mesa IR? that's still a thing?
23:15 Kayden: for i915 and r200 :/
23:16 Kayden: (it may be finally time for those to go..........)
23:16 anholt: there's an mr for that!
23:17 Kayden: Yeah...but have you seen the TODO list?
23:17 icecream95: alyssa: You can turn off the warning with -Wno-psabi
23:17 Kayden: "Handle any regressions from i915c to i915g" - never gonna happen
23:17 Kayden: and "Finish crocus" - gonna take a bunch of work :(
23:20 alyssa: icecream95: snazzy, thanks!
23:20 anholt: we should probably just drop i915c in favor of g. I think I threw my i915s out in the last purge or I'd probably have an MR up already.
23:20 Kayden: I say "never gonna happen" mostly because i915c and i915g take different approaches. i915c tries harder to be conformant but swrasts more. i915g plays fast and loose and tries to use the HW more.
23:20 Kayden: both are sort of terrible in their own way
23:20 alyssa: icecream95: I suspect setting that for bifrost generally (i.e. in the meson.build) is a Bad Idea but it might make things a bit less annoying locally
23:20 Kayden: (I don't know which is better, I think "hit hardware with sledgehammer" would win in my mind....)
23:20 Kayden: but yeah, maybe it's time to just drop i915c and leave g
23:20 Kayden: I went to look at the bugs and mine doesn't even boot currently, and my distro stopped supporting 32-bit processors
23:20 anholt: note that since draw has some lowering, you'll probably win on some conformance over i915c.
23:21 Kayden: yeah, it does
23:21 Kayden: it's a venn diagram of results, and not all of the c -> g regressions are worth fixing, probably
23:21 Kayden: for r200 there isn't really an alternative
23:22 anholt: (there's also that i915g can get so much more optimization that it can compile a lot more shaders!)
23:22 anholt: but that needs my NTT MR for i915g.
23:22 anholt: which I never merged because how can I even test it?
23:23 alyssa: --Hey, tangent, we should have a "marketing name <--> code name <--> mesa drivers" file in docs/ somewhere, I can only keep track of one vendor at a time and right now that's Mali
23:23 Kayden: that makes sense
23:24 anholt: a table in your driver's .rst docs of what it supports sounds nice.
23:24 alyssa: ---Hey, tangent, I've been meaning to add .rst docs for panfrost since, like, 2018 :p
23:24 Kayden: https://people.freedesktop.org/~kwg/codenames has an outdated list of intel marketing names and codenames
23:24 Kayden: though actually the pci_ids folder is a better one these days
23:25 alyssa: Broadwater != Broadwell? telling you I can't keep this stuff straight :p
23:25 Kayden: correct
23:28 jenatali: I'm still waiting for Windows to drop support for the i915 series. Pretty sure they're the only part that stopped at WDDM1.0 (Vista) and never hit 1.1. It's a constant pain
23:30 alyssa: I didn't realize mesa still had support for GPUs older than the thinkpads supported by libreboot...
23:32 Kayden: :( yeah...
23:33 alyssa: Dunno if I should be in awe or horrified
23:33 jenatali: Why not both?
23:33 alyssa: True
23:34 alyssa: some of these parts are older than i am
23:42 dcbaker[m]:remembers upgrading from a savage s3 to an r200...
23:42 dcbaker[m]: might not have been a savage, I had the misfortune of having a number of different s3 parts