00:30 airlied: anholt: https://ci.appveyor.com/project/mesa3d/mesa-ftwhm/builds/37919783
00:30 airlied: more appropriate channel :-P
00:30 anholt: scons deps
00:31 anholt: I thought I was supposed to be free of having to care about scons
00:32 anholt: or maybe it's just include dirs being different
00:33 dcbaker: I thought that we were all but ready to delete scons? did that stall again?
00:35 imirkin: the vmware guys like and are happy to maintain it
00:35 jenatali: Someone stage a MR and see if they shout?
00:35 imirkin: breaking scons does not constitue a build break
00:35 imirkin: so everyone's happy
00:35 jenatali: I thought they switched over completely
00:37 dcbaker: someone from vmware had sent patches to get things working
00:37 dcbaker: I know I reviewed some of them
00:49 anholt: or maybe it's just include dirs being different
00:49 anholt: oops
00:53 anholt: more deqp-runner unit tests, still no luck in tracking down our Missing results.
07:00 airlied: jekstrand: with your refcnted descriptorsetlayout how do you pass dEQP-VK.api.object_management.alloc_callback_fail.descriptor_set_layout_empty?
07:00 airlied: for me that fails unless I store the allocator used
07:03 airlied: ah you don't use allocate callbacks for that at all
07:06 airlied: oh you just always use the device allocator and never the supplie one
07:59 airlied: zmike: there is some corner case in GL with depth sampling between GLSL and fixed function and what channels get filled out
08:00 airlied: it's escaping me at the momment, that could also be causing the problem
08:55 danvet: jstultz, can you ack the VM_PFNMAP patch for dma-buf too?
08:55 danvet: sumits, ^^ ping too
10:15 pq: melissawen, danvet, maybe IGT XRGB overlay tests should do something like https://ppaalanen.blogspot.com/2012/04/improved-appearance-for-simplest.html ;-)
10:18 emersion: interesting
10:43 zzag: TIL weston-simple-shm will look crossed out if the compositor uses the X channel as alpha. Neat.
10:53 danvet: pq, hm yeah maybe the background is black and that's why it's not showing ...
10:56 pq: yeah, why wouldn't the background be black :-)
10:56 pq: also, pre-mult vs. not
11:12 emersion: pq: re https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/127#note_816586
11:12 emersion: the S-o-b is there
11:13 emersion: just gitlab is dumb and puts it on the previous line
11:13 emersion: the raw commit message has two newlines between the link and the S-o-b
11:13 emersion: do you want me to remove the R-b tag?
11:14 pq: oh, it was scrolled away
11:15 emersion: yeah
11:16 pq: all commits I've looked at have had an empty line before all S-o-bs
11:16 emersion: yeah, i have one as well
11:16 emersion: not the first time gitlab does something like that
11:17 emersion: i've seen multiple trailers on the same line in the gitlab UI before
11:17 pq: I know the Gitlab UI bug, but seeing the last line started as a link, it never occurred to me there might more in it
11:18 pq: did everyone assume that bug surely is already reported to gitlab, so no-one reported it?
11:19 pq: I did
11:19 pq: ..assume
11:19 emersion: same…
11:35 melissawen: pq, yes, this is an interesting approach to include there something focused on testing color blend, in general.. thanks for sharing
12:50 sumits: danvet, will have a look
14:14 emersion: xexaxo1: any thoughts on this? https://gitlab.freedesktop.org/mesa/mesa/-/issues/4178#note_815040
14:48 mlankhorst: tzimmermann: After a .0 release, there's no need to send a pulll request for -fixes. It becomes part of the next release cycle. :)
15:09 sumits: mlankhorst, tzimmermann, haven't seen a drm-misc-next PR in some time - what's the plan going forward?
15:10 danvet: I checked logs, last one went out on 19th Jan, but -rc6 was on 31th
15:10 danvet: so looks like we missed almost two weeks of work :-/
15:10 danvet: but also, too late to fix anything
15:10 danvet: mripard, ^^ fyi
15:11 mlankhorst: hm must have stopped too early.
15:12 mripard: danvet: I was planning on sending the next one as soon as rc1 is out
15:12 sumits: danvet, mlankhorst, so what's the plan to fix it?
15:12 mripard: did Linus mention anything about the length of this merge window?
15:12 danvet: mripard, yeah but that's for 5.13
15:12 mlankhorst: is the cutoff the week before or after rc6?
15:12 danvet: "roughly -rc6"
15:13 danvet: we've been occasionally a bit lax
15:13 sumits: can we try and make an exception this release cycle, given that linus' cycle is also delayed?
15:13 danvet: is it?
15:13 danvet: I thought linus pretty much caught up, I expect -rc1 like usual
15:13 mripard: danvet: do we have anything really critical that we really need in 5.12?
15:13 danvet: sumits, is there anything specific in -next you want in 5.12?
15:13 mripard: if not, then we can just merge everything in 5.13
15:13 danvet: mripard, yeah same :-)
15:14 danvet: if there's something critical we can cherry-pick to drm-misc-next-fixes and squeeze it in before the friday pull from airlied
15:14 mripard: it would be unfortunate, but not more than that
15:14 danvet: otherwise I'd say mlankhorst owes sumits a few drinks at the next conference or so
15:14 mlankhorst: Likely only virtual drinks!
15:15 mripard: lucky you
15:15 mripard: those are the cheapest ones
15:16 danvet: pretty sure we can find a suitably exquisite delivery service
15:16 sumits: so there are some dma-buf heaps cleanup patches, and the dma-fence timestamp ones atleast that should get through
15:17 sumits: mlankhorst, I'm open to drinks at the next conference too :) - we can figure out the delivery mechanism :)
15:19 danvet: yeah the two timestamp patches landed on 22nd, so sufficiently ahead for that
15:19 danvet: cleanup I guess doesn't matter since userspace doesn't care?
15:19 danvet: and timestamp is just 2 patches
15:20 danvet: but would need to all get in before Fri pull train from airlied
15:20 danvet: sumits, 5a164ac4dbd21b82bcdc03186d40e455ff467fdc and a78e7a51d2fa9d2f482b462be4299784c884d988 should be enough?
15:21 sumits: danvet, checking
15:23 sumits: danvet, along with - 14a117252f57839bdf0123a1c888a96102e3a843 and c7f59e3dd60313071a989227dcb69094f499d310
15:23 sumits: danvet the cleanup is useful from the android pov
15:24 danvet: yeah looks small enough and bugfix-y enough for -next-fixes imo
15:25 sumits: cool, so shall I do the cherry-picking, or one of the maintainers would?
15:29 sumits: mlankhorst? shall I do the c-p and let you know here so it is part of the next PR?
15:32 mlankhorst: Ok tht's good. :)
15:33 mlankhorst: I'll make the pull request when it's done
15:46 sumits: mlankhorst, pushed
16:19 jekstrand: airlied: Yup
17:15 jekstrand: jenatali: FYI: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/922
17:18 jenatali: jekstrand: Cool, thanks
17:19 jekstrand: jenatali: Turns out, no one bothered to use them in the CTS. Who knew?
17:19 jekstrand: Obviously we did because you're passing. 🙃
17:19 jenatali: jekstrand: I did ;) we pass the CTS
17:19 jenatali: Well, mostly anyway... we really need to finish out that effort
17:19 jekstrand: Yeah
17:23 jenatali: jekstrand: Probably worth filing a CTS issue to track that missing coverage
17:25 jekstrand: jenatali: https://github.com/KhronosGroup/OpenCL-CTS/issues/668
17:26 jenatali: Hah
18:24 Lyude: did the maximum column limit for the upstream kernel not actually get bumped to 100?
18:27 Lyude: ah, found something on it https://linux.slashdot.org/story/20/05/31/211211/linus-torvalds-argues-against-80-column-line-length-coding-style-as-linux-kernel-deprecates-it so it looks like we kind of did
18:35 airlied: jekstrand: isn't using the wrong allocator a bug?
18:43 jekstrand: airlied: We're always allowed to use the device or instance allocator
18:49 airlied: jekstrand: oh didn't know that
19:44 karolherbst: Lyude: yes, and I refuse to accept "please use 80" as an excuse ever since :p
21:38 Thaodan_: Hey I have a gpu that does not increase the fanspeed fast enough in relation to the temprature on the gpu. How can I debug this?
21:39 Thaodan_: My gpu went almost so hot so the pc had to restart.
21:40 Thaodan_: this is the sensors output before I killed the application using the gpu
21:40 Thaodan_: https://paste.opensuse.org/87562171
21:45 HdkR: Thaodan_: RX 5000 series GPUs are known to have normal junction temperatures at 110c
21:45 HdkR: edge is the one you would need to be concerned about getting that hot
21:46 HdkR: The firmware will safely downclock the GPU when junction gets too hot
21:48 HdkR: I believe it starts throttling when junction hits 110c even
21:49 Thaodan_: Mine went to because of amdgpu 0000:03:00.0: amdgpu: ERROR: GPU over temperature range(SW CTF) detected!
21:51 Thaodan_: In any case the gpu went to while the cooling in the case is fine and the fan could go faster.
21:51 Thaodan_: it should start throttling because shutting down the computer
21:52 bnieuwenhuizen: Thaodan_: kernel 5.11?
21:53 bnieuwenhuizen: if so, might be worth downgrading to 5.10 ...
21:54 Thaodan_: Yes
21:54 Thaodan_: whats the issue?
21:56 bnieuwenhuizen: I don't know but there have been multiple reports about fan issues on linux 5.11 vs. 5.10
21:59 agd5f_: bnieuwenhuizen, that was related to manual fan control and it was fixed
22:03 bnieuwenhuizen: agd5f_: I have also seen reports on discord about someone card overheating, several people reporting issues with polaris cards and between Sam and I fans on GFX8 cards spin up way to loud since 5.11 on card wake/boot
22:03 bnieuwenhuizen: so I haven't debugged any specific issue but it definitely seems there is something funky going on even with automatic
22:04 agd5f_: hmmm, gfx8 hasn't been touched in ages. that is surprising
22:04 bnieuwenhuizen: enough that I thought it was worth tested in this case
22:04 bnieuwenhuizen: FWIW I don't think the overheat shutdown was gfx8 but GFX10.(3?)
22:04 bnieuwenhuizen: so it may very well be multiple issues
22:10 bnieuwenhuizen: agd5f_: some of the polaris issues have been traced back to 18973c6ec42a6ee15978d887cf40adab2350202d on discord though I'm not sure if my issue with my tonga card is different
22:11 bnieuwenhuizen: (drm/amd/powerplay: separate Polaris fan table setup from Tonga)
22:13 ajax: :/ softpipe's depth_test_quad is just straight up broken for Z32F depth, isn't it?
22:15 ajax: integer comparison isn't going to work on float data
22:15 jekstrand: that would be a problem....
22:20 airlied: didn't write it, but do have a signed-off on it :-P
22:20 airlied: but yes that would an issue I'd guess
22:26 bnieuwenhuizen: hmm, as long at everything is positive and not inf/nan it might even work?
22:35 Thaodan_: Which component would be fan speed issues on amdgpu? (kernel bugzilla)
22:38 pepp: Thaodan_: amdgpu issues should be reported at https://gitlab.freedesktop.org/drm/amd/-/issues now
22:39 Thaodan_: Funny why the kernel bugtracker even exists
22:43 Thaodan_: Is the fan curve code the same for all amd gpus?
22:43 Thaodan_: Because https://gitlab.freedesktop.org/drm/amd/-/issues/1315 sounds similar
23:21 mattst88: xexaxo1: https://gitlab.freedesktop.org/mesa/waffle/-/commit/b71cfa674db5828a2be04a42ce9996d6677629ee#note_784271
23:21 mattst88: can we make a waffle release with that in it?
23:22 xexaxo1: mattst88: could swear it's in 1.6.3 /me takes a look
23:23 mattst88: it's not in v1.6.2, and I've been cherry-picking it into Gentoo for the last year
23:23 mattst88: I'm not really sure I understand why we don't just make a v1.7.0 release?
23:25 xexaxo1: and it's not. for the future please either add an issue, MR, etc. Finding a comment is pretty hard
23:26 mattst88: yeah, I should have
23:26 xexaxo1: 1.7.0 - ETIME to triple-check that wayland xdgshell does not explode in couple of corner-cases.
23:27 xexaxo1: aiming to do that this week, fwiw
23:27 mattst88: nice, thank you
23:31 xexaxo1: do you have the Gentoo bugreport btw?
23:31 xexaxo1: fwiw https://bugs.gentoo.org/768021 will also be fixed with 1.7.0
23:33 mattst88: no, no bug it seems. looks like I added the patch here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=909c1837f2cdc2bf1d93728b33c7c1285dff96bb
23:33 mattst88: I don't actually recall really what it even does
23:34 mattst88: dcbaker knows, I'm sure
23:34 mattst88: IIRC something doesn't detect waffle at build-time without that patch
23:34 xexaxo1: it creates the cmake version of pkg-config files.
23:35 mattst88: right
23:35 xexaxo1: for *nix the pkg-config files should just work - even if the project uses cmake.
23:35 xexaxo1: although Windows is "fun"
23:37 mattst88: oh, it's for apitrace
23:37 dcbaker: Unless it's changed you had to explicitly try to use pkg-config, which is something that a lot of windowsy projects didn't do
23:37 mattst88: the surrounding commits are for bumping apitrace to 9.0
23:37 mattst88: yeah, apitrace uses cmake and cannot find waffle without that patch
23:38 dcbaker:is not surprised
23:41 mattst88: xexaxo1: ^just making sure you saw that conclusion
23:43 xexaxo1: rather tired, so pardon the silly question: apitrace on linux/bsd cannot find waffle with pkg-config?
23:43 xexaxo1: or is that for apitrace/windows only?
23:43 dcbaker: nope, it uses `find_package`, which doesn't query pkg-config
23:44 dcbaker: https://github.com/apitrace/apitrace/blob/master/CMakeLists.txt
23:44 dcbaker: the cmake people really don't like pkg-config
23:44 dcbaker: to be fair, neither do I, lol
23:44 xexaxo1:considers adding pkg-config fallback
23:45 xexaxo1: one line fix in apitrace instead of 50+ in waffle :-P
23:45 dcbaker: I highly doubt that apitrace is the only project that relies on WaffleCmake
23:45 xexaxo1: dcbaker: time for pkg-config++
23:45 dcbaker: though if we bumped the version we could drop the macro definition, because that got fixed in meson 0.51 or 52
23:46 pinchartl: dcbaker: would you, by any chance, have given more consideration to meson + android ?
23:46 dcbaker: I tried to get the ball rolling on that with cps with cmake people and never could get them to take my concerns about their proposal seriously (well, one guy did, but everyone else kinda ignored me or just pushed back)
23:46 dcbaker: pinchartl: nope
23:47 pinchartl: damn, I'll have to solve it myself for libcamera then :-)
23:47 mattst88: xexaxo1: that's a bit of a silly argument whent he fix is already in waffle and has been for 18 months
23:47 xexaxo1: fwiw I adapted mesa's meson/android for waffle - builds like a charm. next runtime test
23:48 xexaxo1: mattst88: yeah that one is going out with 1.7.0.
23:48 dcbaker: we're talking about how to handle being in the android core with their blueprint only build system
23:48 dcbaker: the whole thing is rather frustrating and depressing
23:48 xexaxo1: neat... frustrating - that sounds like Android indeed
23:49 pinchartl: xexaxo1: frustrating would be a huge improvement compared to the current situation
23:51 xexaxo1: pinchartl: you did a talk on lpc on the topic - IIRC some Android folks seemed kind of on-board with the idea
23:51 pinchartl: I'm still considering a middle-ground solution with a meson backend to generate .bp files. that won't be good enough to integrate in aosp, but would simplify my life as I otherwise have to write those files manually
23:51 xexaxo1: did they get pulled to other tasks, or simply not sold on the idea?
23:51 pinchartl: xexaxo1: all our proposals got shot down by the android build system lead
23:51 dcbaker: yeah
23:52 pinchartl: every single one
23:52 dcbaker: even when we offered to do the work
23:52 pinchartl: we offered to write a meson frontend in go. nope
23:52 dcbaker: they basically said "we're android so do what we want or go home"
23:52 pinchartl: we asked if we could get a hook in the build system to add out-of-tree packages after building AOSP and before generating the image. nope
23:53 pinchartl: I don't recall what else was proposed
23:53 dcbaker: we proposed the .bp backend to meson as well
23:53 dcbaker: they didn't like that
23:54 dcbaker: they said "writing a meson -> soong translator for us to live in android or just use .bp files"
23:54 dcbaker: I honestly walked away with zero motivation to do anything else on that front
23:55 pinchartl: I have zero motivation for android in general :-)
23:56 xexaxo1: sounds beyond frustrating - sorry for bringing the topic
23:56 dcbaker: no worries :)
23:57 dcbaker: at least the android folks were upfront about it and didn't string us along
23:59 jenatali: This sounds familiar... we're interested in using the DXIL backend in Mesa for Chromium stuff, which means we'd apparently need GN and CMake build systems for the relevant code