03:09 HdkR: Should I be watching the i915 driver for Ice Lake never going above 100Mhz, or some random thermal driver problem?
03:22 jekstrand: Uh... 100 Mhz is really low
03:22 jekstrand: That sounds worse than a thermal driver problem
03:24 HdkR: It's a great experience </s>
03:25 jekstrand: What laptop do you have?
03:28 HdkR: Dell XPS 13 2020
03:28 HdkR: 2-in-1
03:28 HdkR: https://www.dell.com/en-us/shop/dell-laptops/new-xps-13-2-in-1-laptop/spd/xps-13-7390-2-in-1-laptop
03:28 HdkR: 7390 model number
03:28 HdkR: i7-1065G7
03:29 jekstrand: Oh... You have one of those....
03:30 jekstrand: Depending on how much CPU you're burning, the GPU could easily be having a hard time clocking up.
03:30 jekstrand: Dell has that laptop configured to run at 12W even though it's running a potentially 25W chip.
03:30 jekstrand: It's awesome
03:30 jekstrand: thermald and dptfextract will fix that for you
03:30 jekstrand: But your laptop will run hot
03:31 jekstrand: How hot? Not sure. Dangerously hot? Not sure.
03:32 jekstrand: That's the laptop Larabel used to decide that Linux on ICL is 60% slower than (40% the speed of) windows.
03:33 HdkR: Dangerously hot with alacritty and gnu screen running? :)
03:33 jekstrand: It's 90% a power management problem. Windows can clock up thanks to the DPTF driver. Linux can't without thermald and dptfextract
03:33 HdkR: It's 100Mhz with no load
03:33 imirkin: "In India, "cold weather" is merely a phrase to distinguish between weather which will melt a brass doorknob and weather which only makes it mushy." - Mark Twain.
03:33 HdkR: No CPU load I should say
03:33 jekstrand: Hrm...
03:34 jekstrand: And you're running enough of a GPU workload that you expect it to go higher?
03:35 jekstrand: I guess I'm confused. Are you asking if it not going above 100 Mhz is a problem or are you claiming that it not going above 100 Mhz is a problem and asking how to solve it?
03:35 jekstrand: If it's the former, I don't know. Alacritty doesn't seem like that much of a load if it's fixed to 60 Hz.
03:35 jekstrand: If it's the later, see above.
03:36 HdkR: I'll have the laptop idling with alacritty, but then load up chrome to go to a web page and it'll just chug because the GPU never gets past 100Mhz
03:37 jekstrand: Ah
03:37 jekstrand: That sounds like a problem. Chrome is likely to actually burn GPU cycles.
03:37 jekstrand: What's your kernel version?
03:38 HdkR: Linux XPS13 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
03:39 jekstrand: Hrm... I'm on 5.6 and my GPU can clock up ok, last I checked.
03:40 jekstrand: How are you measuring frequency?
03:40 HdkR: intel_gpu_top
03:41 HdkR: `intel-gpu-top - 18/ 18 MHz` That line will show something like `intel-gpu-top - 100/ 1100 MHz`
03:42 HdkR: And GPU utilization pegged to 100%
03:42 HdkR: Render/3D specifically
03:43 HdkR: It's just a normal day of leaving screen+mosh open all day, maybe the laptop falling asleep periodically. Using Chrome periodically
03:44 jekstrand: Do you have the problem when you first turn it on or only after it's gone through suspend/resume?
03:44 HdkR: restart works around it temporarily, haven't watched it close enough if it actually needs to sleep first before the problem occurs
03:49 jekstrand: That seems likely. I suggest filing a bug.
03:50 jekstrand: I wouldn't know if there's a suspend problem in my laptop can't suspend on 5.6. Some ACPI issue. :-(
03:50 HdkR: Nice
03:50 jekstrand: It can't even halt properly. :-(
03:50 HdkR: ACPI problems are always great
03:50 HdkR: Filled with voodoo
03:50 jekstrand: Well, I'm not actually sure it's ACPI. It could be any number of things.
03:51 jekstrand: But the machine gets to halt and/or suspend with no errors that I've seen and then just fails to change power states. At least that's what it looks like.
03:54 jekstrand: It was working great with F31 and then I updated...
04:07 airlied: oh man gcc seems to be misoptimisng my bitfield again
04:08 jekstrand: :-(
05:35 airlied:files a bug, hopes the gcc ppl can figure it out :-P
05:35 airlied: https://bugzilla.redhat.com/show_bug.cgi?id=1842362
12:47 bernie_: Hello. I'm trying to turn on 10bpc output on amdgpu
12:48 bernie_: I'm already using a depth 30 visual in xorg
12:49 bernie_: but the display is still reporting "HDR: OFF", which I believe means the framebuffer scanout on the DisplayPort connector is till in 8bpc mode
12:50 bernie_: This causes the display to blank for a moment, as if switching to a new mode:
12:50 pq: bernie_, I think HDR is quite a lot more than just 10 bpc.
12:51 bernie_: xrandr --output DisplayPort-0 --set 'max bpc' 10
12:51 pq: I mean, 10 bpc is not necessarily HDR I think
12:51 bernie_: pq: well, what does Windows 10 *do* to make the screen say "HDR: ON" ?
12:52 pq: I have absolutely no idea
12:52 MrCooper: there is separate HDR metadata which needs to be sent to the monitor AFAIUI
12:53 pq: look in https://www.kernel.org/doc/html/latest/gpu/drm-kms.html for HDR_OUTPUT_METADATA I guess
12:53 bernie_: I just tried booting into windows to confirm that the AMD card, the DP cable and the BENQ display work together in HDR mode
12:55 bernie_: MrCooper, pq: hmm... looks like HDR_OUTPUT_METADATA is set to "0" on all my connectors:
12:55 bernie_: https://codewiz.org/pub/drm_info.out
12:56 MrCooper: there's definitely no HDR support in X yet, and I wouldn't hold my breath for that :)
12:56 pq: bernie_, yeah, if I read it correctly, it is something the displar server need to set to enable HDR, or something like that.
12:56 pq: *display server
12:57 pq: makes me curious what was the userspace used to validate HDR_OUTPUT_METADATA... Chromium OS?
12:57 bernie_: pq: would this work with Xorg? or do i need to switch to a wayland compositor?
12:58 pq: if I bothered to dig up the commit, I'd know :-)
12:58 bernie_: i have a chromium os developer in chat who is helping me :-)
12:58 MrCooper: pq: IGT has some code for it
12:58 pq: bernie_, well, I don't personally know of *any* display server doing HDR yet.
12:58 pq: MrCooper, but igt alone isn't enough.
12:59 bernie_: but he mostly only knows about integrated gpus with unified memory and eDP panels
12:59 pq: the Wayland protocol extension for HDR is on my plate though
12:59 bernie_: pq: oh! so someone _is_ working on it
13:00 bernie_: pq: i thought i was alone in trying this...
13:00 emersion: pq: kodi
13:00 pq: yes, people are wanting it, it's just really slow going, because on Wayland it first need color management extension
13:00 pq: oooh, kodi at a DRM KMS app
13:00 pq: *as
13:00 emersion: yup
13:04 pq: bernie_, so, if you try kodi, you might get HDR going, but obviously that's not a desktop. :-)
13:04 pq: specifically without any display server
14:18 bernie_: pq: Just spoke with the chromium os video driver guy
14:19 bernie_: pq: he told me that they don't use HDR_OUTPUT_METADATA because it appeared in a more recent kernel than what they're shipping on devices right now
14:20 bernie_: pq: if codi enables HDR output, i'd love to see the source code and copy-paste the relevant bits to kwin or whatever
14:22 emersion: bernie_: it's not as simple as that unfortunately
14:22 vsyrjala: you can't just simply copy paste a few lines of code. you need to convert all your sdr content into hdr
14:23 emersion: wayland clients can't communicate the HDR metadata to the compositor right now
14:24 pq: Wasn't NVIDIA working on HDR Xorg? Or was it just high-depth/floating-point color?
14:24 vsyrjala: fp16 only i think
14:25 pq: what use did they have for fp16?
14:26 pq: or maybe it's the usual X11 exercise? Xorg doesn't case, some random app pokes at KMS properties via RandR and some other random app just happens to paint fp16 that happens to look nice when interpreted as HDR?
14:26 pq: *doesn't care
14:27 vsyrjala: i presume there is a step 2 of some sort. but don't think i ever saw one
14:29 pq: bernie_, as implied here, enabling HDR is of little use until you have HDR content. If you tried to simply switch HDR on and changed nothing else, you might be "blinded" by the traditional imagery and get horrible banding or whatever when the old-school 8 or even 10 bpc pixels suddenly get interpreted as HDR.
15:37 alyssa: Hey, just to make sure I understand the release schedule - since the 20.1 dev just branched off, any new commits that aren't fixed/cc'd are delayed until 20.2, yes?
15:38 alyssa: (I'd like to flip on fp16 but it could use wider testing before hitting distributions. I figure if you're bold enough to run master you can file a bug report if you find a bug that's not covered by CI.)
15:45 imirkin: alyssa: generally speaking, yes - only things marked as fixes/cc mesa-stable are included
15:46 imirkin: alyssa: there have been some rare cases where major things are merged in after-the-fact, but ... i can only remember like one time, with freedreno, some new generation being added - that sort of thing
15:46 imirkin: i.e. no regression possible since it was just not going to work at all before
15:47 alyssa: imirkin: cool, might as well land it then :-)
16:50 jenatali: jekstrand: Any suggestions for an optimization that may be missing that would help elide the (clearly unnecessary) int64 usage here? https://pastebin.com/4BKQM2k6
16:51 jenatali: This is a 64-bit system value, loaded as 32-bit and cast to 64, then cast to float and added to 1.5f. The lowering/optimization passes end up doing the 1.5f addition in integer space, and then the conversion to int64 kicks in, and then back to float
16:54 alyssa: jenatali:if I'm reading right, it *isn't* immediately obvious that the int64 is unnecessary
16:54 jenatali: What's the behavior of int64 to float? What's supposed to happen to the high bits?
16:55 alyssa: It is - but it's not simple anyway
16:55 alyssa:wonder if range tracking could chew through this
16:57 alyssa: Probably not as is, hrm
16:59 alyssa: jenatali: for u2f32 behaviour with 64-bit, looking at the (generated) const folding code it looks like it matches the C semantics
17:00 jenatali: Hm, I actually don't know what that is off the top of my head
17:01 alyssa: I don't either, wondering if it might be UB
17:02 jenatali: Oh, I was misreading the nir, this is just an int64 add, then converting to float. I was thinking it was a bitcast, but it's not
17:02 karolherbst: jenatali: btw, if any missing review is blocking you please ping.. I am sure I could squeeze things in. I kind of busy with stuff for the whole week I think.. no idea if I said this about last week or this one actually :d
17:02 alyssa: ^ likewise here
17:02 jekstrand: jenatali: Is it? That ior looks like it's setting bit 32 to me
17:03 jenatali: karolherbst: Appreciate the heads up, you did mention that last week. I don't think I'm blocked :)
17:03 karolherbst: okay
17:03 alyssa: jekstrand: --Wait, yes, I misread that as decimal 20 it's Monday
17:03 jenatali: jekstrand, yeah I think you're right, this could actually end up with a legit int64->float cast where the high bits matter
17:04 mareko: anholt_: are you the right person to ack this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5002/diffs?commit_id=6accbcc5e7416738a5a13695d154a609c278997d
17:06 alyssa: robclark: ^
17:06 robclark: mareko: I don't suppose you know which commit on that branch fixes that test? Hypothetically I guess that commit should be squashed into whatever commit fixes that test
17:07 robclark: if you aren't sure, one of us can bisect..
17:08 anholt_: mareko: oh, right, that's what I meant to do this morning
17:08 anholt_: give me just a minute.
17:08 mareko: robclark: yeah I don't know which commit fixes it
17:08 anholt_: mareko: mind if I push to your branch once I identify the commit and do the improved fix (remove the special noubo fails file)?
17:09 mareko: anholt_: feel free
17:09 alyssa: mareko: I'm excited to see the series land :-)
17:10 anholt_:was deep in trying to figure out how to figure out the sizes of ubos for ubo-to-push-constant lowering
17:10 mareko: there is more to do for mediump there though
17:11 alyssa: still, progress is nice to see
17:11 anholt_: looks like intel hasn't had to do this, because they don't do indirects on pushed ubos
17:11 alyssa: anholt_: for the not-make-UBO0-special crusade? :)
17:12 anholt_: alyssa: sort of, actually for "make ubos not suck more than gl uniforms"
17:12 mareko: constbuf0 is also special in radeonsi
17:12 karolherbst: doesn't understand why regs and ubos are different :p
17:12 karolherbst: well.. besides the read only thing
17:13 karolherbst: does it really make a perf difference on some hw if you read from a reg or ubo/uniform?
17:14 robclark: karolherbst: for ir3 we can directly address (even indirected) push consts from alu instructions (with some constraints), but not ubo.. otoh that is more a question of which ubo accesses are lowered to push consts
17:15 karolherbst: robclark: ohh I see. you have this special push const space.. totally forgot about it
17:15 robclark: anholt_: can't you just use ir3_glsl_type_size(nirvar->type, false) to get the size.. iirc that will return zero if size is unknown (ie. array without size specified)
17:15 karolherbst: robclark: we have indirect on all ubos but not regs.. so mhh, we have other issues :D
17:16 alyssa: We have push constant space with no indirect access (preloaded -- access "free"), and regular UBO with indirects allowed (one cycle per read)
17:16 robclark: we can indirect all the things (regs, push consts, etc)..
17:16 karolherbst: robclark: lucky you :p
17:16 alyssa: atm we just say "first N uniforms are pushed, the rest are UBO 0, the other UBOs are UBOs 1+"
17:16 alyssa: which... sucks
17:16 karolherbst: alyssa: yeah...
17:17 karolherbst: apparently ubo and reg access are equally expensive for us
17:17 karolherbst: except
17:17 karolherbst: the indirection is non uniform
17:17 karolherbst: than it can even get worse than VRAM
17:17 karolherbst: *then
17:17 karolherbst: ubo accesses are serialized across all threads
17:22 HdkR: Always a fun performance tradeoff there
17:23 anholt_: robclark: nope, that doesn't know about the layout of uniforms, it's just for attributes/varyings.
17:24 anholt_: (git grep for std430_size and std140_size for more info)
17:24 robclark: I mean, we need to map the ubo offset back to the uniform var for cb0..
17:26 imirkin: (note that std430 is only for ssbo, not ubo)
17:26 robclark: I guess you have to ignore uniforms that are samplers
17:27 anholt_: samplers are not relevant for ubos
17:28 anholt_: imirkin: interesting! that would certainly make things easier
17:28 imirkin: (except the bindless kind, which have actual storage associated with them)
17:29 imirkin: anholt_: 99% sure that's right. but i'm not sure what we do when there's no explicit layout specified, or layout=shared.
17:36 anholt_: mareko: looks like mediump branch is good to go from our perspective
17:50 Kayden: anholt_: it'd be nice to do indirects on pushed UBOs...we did them with regular uniforms, before switching to iris made regular uniforms not really a thing anymore
17:52 Kayden: I remember running into the problem of no bounds on intrinsics, but I don't remember beyond that
17:52 Kayden: probably other problems
17:52 anholt_: Kayden: regular uniforms lowered intrinsics have a range associated
17:53 Kayden: yeah, but not UBOs :(
17:53 anholt_: yeah. so, honestly, I think that would be the thing to fix -- give nir lowered ubo accesses a range
18:50 krh: yeah, when I looked last, we drop the range when we lower at some point, should be possible to retain the array size though
18:50 krh: I didn't have anything at hand that would indirect on UBO arrays, so I didn't pursue, but it looked quite doable
18:55 krh: (reading more scrollback) but was looking at determining the array size, which is more relevant than the ubo size, if there a bunch of unused stuff elsewhere in the ubo
18:56 anholt_: krh: yeah, this is why I think instead of ubo size, I should work on getting a range on the intrinsic
18:56 anholt_: but first, fixing gmaps.
18:56 krh: yup, I was thinking that's something we could extend the deref lowering to do
18:58 mareko: anholt_: radeonsi uses nir_shader::num_uniforms to compute the size of UBO 0
18:59 anholt_: mareko: ubo non-0 was what I was trying to find a size for
19:55 airlied: gcc 10 miscompiles mesa bug for this year: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
19:56 mattst88: ouch
20:10 jekstrand: bnieuwen1uizen, mareko: Am I remembering correctly that radeon has an "add three things" opcode?
20:12 bnieuwenhuizen: jekstrand: ADD3_U32
20:19 imirkin: nvidia does too
20:20 imirkin: airlied: phew! glad you caught it, that means my code should be safe for another year.
20:21 ElBarto: anyone who could have a look at merging this : https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/393
20:21 ElBarto: or tell me if there is a more appropriate channel for xorg-related talk
20:22 imirkin: #xorg-devel maybe?
20:24 ElBarto: thanks, I'll try there :)
20:37 jekstrand: bnieuwenhuizen: Do we have a NIR opcode for it?
20:37 jekstrand: bnieuwenhuizen: I couldn't find it with a quick search
20:38 jekstrand: I would expect it to be called iadd3
20:38 bnieuwenhuizen: jekstrand: Pretty sure we just deal with it in the backend
20:38 jekstrand: Ok
20:39 jekstrand: bnieuwenhuizen: Is it only u32 or can you do it for more stuff?
20:39 jekstrand: Wondering if a generic NIR op makes sense
20:39 imirkin: jekstrand: what are the other options? or you mean like u16/etc?
20:39 airlied: jekstrand: only u32 I think
20:40 jekstrand: Float and other integer sizes
20:40 bnieuwenhuizen: jekstrand: only vector & only u32
20:40 imirkin: nvidia just has it for integers
20:40 imirkin: (32-bit)
20:40 imirkin: (starting with SM50, i.e. maxwell)
20:41 imirkin: we have an opt which tries to bundle multiple adds together, but it triggers very rarely
20:46 mareko: we have add3, or3, xor3, min3, max3, med3 (median using min+max)
20:47 mareko: min/max/med are also for float
20:47 jekstrand: Yeah, I think it's actually minmax that I was thinking of.
20:48 karolherbst: imirkin: I actually have some patches somewhere
20:48 bnieuwenhuizen: jekstrand: those we have in 16/32 bit U/I/F
20:49 imirkin: karolherbst: oh, i thought those landed?
20:49 karolherbst: imirkin: iadd3 has one big advantage over iadd though: you can have two modifiers
20:49 karolherbst: not yet
20:49 imirkin: karolherbst: well, more importantly you can have 2 neg modifiers
20:49 karolherbst: so you can do an iadd neg a 0 neg b
20:49 karolherbst: yeah
20:49 karolherbst: that's what I meant
20:50 karolherbst: sadly the benefits are often very small with those kind of opts :/
20:50 bnieuwenhuizen: karolherbst: I assume there is a workload for which it matters very much, otherwise it wouldn't be implemented in HW?
20:50 HdkR: We just really need an add3 with scale so you can really optimize the case of `ssbo base + ssbo array base offset + (index * scale)` and we will have reimplemented x86 LEA
20:52 jekstrand: We should just implement x86 in a compute shader. :-P
20:53 imirkin: and run llvmpipe on it!
20:53 jekstrand: Or maybe SPIR-V. That'd get our shader compile times down!
20:53 imirkin: HdkR: aka IMAD?
20:53 imirkin: oh, you want an extra one
20:54 jekstrand: imirkin: I think he's asking for IMAAD
20:54 imirkin: yeah. or hulk smash.
20:55 HdkR: :D
20:55 karolherbst: bnieuwenhuizen: to be more precise: it doesn't matter enough so it's high priority to implement it in nouveau
20:57 imirkin: bnieuwenhuizen: tbh, dunno. i could see it for floats (e.g. 1 - a - b), but with integers it seems a bit more far-fetched
20:57 imirkin: however it's the integer op that's there
20:57 jekstrand: It probably makes bitcoin faster :P
20:58 bnieuwenhuizen: imirkin: I'd expect the integer op to be relevant to some obscure thing like some hash function?
20:58 alyssa: https://gitlab.freedesktop.org/alyssa/mesa/-/jobs/2908316 Broken deps...?
20:58 karolherbst: alyssa: yeah.. I ran into it as well
20:58 bnieuwenhuizen: IIRC some of the 3-operand bitops were introduced for that reason
20:58 karolherbst: short: apt is stupid
20:58 jekstrand: alyssa: Uh.... That seems not so good
20:59 airlied: alyssa: rebase onto master
20:59 karolherbst: MrCooper wanted to look into it
20:59 karolherbst: ohh, was it fixed?
20:59 airlied: pretty sure at least the libc6 one is fixed
20:59 alyssa: oof, okay.
20:59 alyssa: will let marge deal.
20:59 karolherbst: no, then it doesn't help
20:59 karolherbst: this is a new issue
21:00 alyssa: blink
21:00 imirkin: bnieuwenhuizen: yeah. would be surprising if several separate arch's had a weird op like that in them for _no_ reason
21:00 airlied: karolherbst: ? seems like the same one, wants gcc and libc from testing
21:00 imirkin: but that doesn't make the reason itself any more apparent
21:00 karolherbst: airlied: nope, not the problem here
21:00 anholt_: airlied: I don't see any commit that might fix that?
21:00 anholt_: it's showing up in marge attempts
21:01 karolherbst: the issue is more annoying
21:01 karolherbst: you essentially need to update the entire libgcc runtime
21:01 airlied: 1fc1b877622e3477272a17a43fd438453484bb79 was commit I was thinking
21:01 alyssa: yo, I heard you like compilers..
21:01 karolherbst: airlied: I have this commit in my branch and it didn't help
21:01 alyssa: airlied: I mean, Marge was working for me a few hours ago, then I got back from lunch to that.
21:02 airlied: maybe it needs to be done for another build then
21:02 karolherbst: maybe
21:02 karolherbst: but just updating gcc doesn't help
21:03 karolherbst: apt is stupid, so you need to update all libraries as well breaking the dep tree
21:03 karolherbst: and this doesn't just include libgcc but several other things as well
21:03 anholt_: c1a290bdd57536d6afcff6a02f1512fba7328729 is triggering a rebuild, but since marge runs in the author's context, and that date is old, probably dylan just had an old image laying around from before upstream debian stuff broke this
21:03 karolherbst: like libmpx etc...
21:03 MrCooper: it's not solved for x86_build yet, I'm on it, should be able to post an MR tomorrow
21:04 anholt_: MrCooper: can we roll an image with some component disabled so we can unblock people for today?
21:04 MrCooper: not that simple I'm afraid
21:04 MrCooper: requires major surgery actually
21:04 alyssa: did something break upstream?
21:05 MrCooper: yeah, GCC 8 packages from buster are no longer compatible with libc6 from testing
21:05 alyssa: I'm almost afraid to ask but why are we running a frankendebian
21:05 MrCooper: and all kinds of fun dependency hell stemming from that
21:06 MrCooper: the solution I'm working is exactly to stop doing that
21:06 alyssa: fair enough
21:06 alyssa: running testing directly in CI and pinning known good versions?
21:07 karolherbst: alyssa: it's not a "bug" if that's what you mean
21:07 MrCooper: nope, you'll see tomorrow :)
21:07 karolherbst: upstream is fine, you just can mix and match the last release and testing as you please
21:07 alyssa: karolherbst: https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian
21:07 karolherbst: more or less
21:07 alyssa: Literally item #1.1 :>
21:08 karolherbst: yeah...
21:09 MrCooper: it works fine... until it doesn't :)
21:09 alyssa: \o
21:09 karolherbst: if there just would be a distribution optimized against building containers :p
21:09 karolherbst: like Clear Linux or so
21:09 karolherbst: dunno
21:09 karolherbst: would be nice if that would exist :p
21:09 alyssa: Alpine
21:09 alyssa: ?
21:10 karolherbst: no "Clear Linux" is the one :p
21:10 karolherbst: alpine is old news
21:10 karolherbst: or. wait
21:10 alyssa: I mean I assume Clear doesn't build for arm which is a showstopper for some of us :v
21:10 karolherbst: do I confuse something here?
21:10 MrCooper: does Clear have LLVM packages from 3.9 to current?
21:11 karolherbst: no.. alpine is the proper stuff and clear was the garbage version
21:12 karolherbst: MrCooper: I don't think it has multiple versions of the same thing though... as usually that's super uninteresting for container folks :/
21:13 karolherbst: they do have older versions of the entire distribution though
21:14 anholt_: really what I want is something that pins exact debian package versions like cargo lockfiles.
21:14 alyssa: afaik apt can do that
21:14 anholt_: lwn's recent article on ostree had some stuff like that based around debs, though it doesn't solve the "how do I actually get these specific versions from the mirrors" iirc
21:14 MrCooper: it's called "stable" :)
21:15 alyssa: MrCooper: Oof ;)
21:15 jekstrand: Just run arch in the container and update nightly. :-P
21:15 karolherbst: at some point it gets less annoying to just maintain our own gentoo based distribution for CI :p
21:15 karolherbst: but gentoo also only gets back to llvm-8...
21:16 karolherbst: seriously.. why do we care about llvm 3.9?
21:16 jekstrand: llvmpipe!
21:16 karolherbst:already feels like this question to backfire
21:16 karolherbst: jekstrand: yeah.. but llvmpipe doesn't require 3.9 does it?
21:16 karolherbst: :p
21:16 alyssa: I have been building with -Dllvm=false and happy about it.. :p
21:17 karolherbst: maybe we should just require llvm-9+ and tell people to update their llvm :p
21:17 alyssa: karolherbst: Don't break compat with old hw that has llvm 3.9 burned into ROM! or something :p
21:17 jekstrand: I'd be ok with that. I feel like projects like Mesa support ancient stuff "just because" a bit too much.
21:17 karolherbst: yeah...
21:17 karolherbst: llvm-3.9 feels too old anyway
21:18 karolherbst: mhh.. sep 2016
21:18 karolherbst: which qualifies as too old :p
21:18 jekstrand: Yeah....
21:18 alyssa: jekstrand: Personally I draw the line at e-waste stuff... If aging hw is still in active use, it makes sense to support so to keep the hw in use instead of bitrotting.
21:18 alyssa: But with sw, there's no real reason old hw can't run new sw, unless the new sw has terrible perf regressions.
21:19 karolherbst: sure, but modern llvm still runs on aging hw
21:19 alyssa: ^^ that
21:19 karolherbst: normally compiler try their best to not punish older hw
21:19 karolherbst: or only to a very small dagree
21:19 karolherbst: *degree
21:19 jekstrand: alyssa: Try telling that to the OpenBSD folks who are still on GCC 4.2 :-(
21:19 alyssa: jekstrand: *blink*
21:19 karolherbst: well, they use clang now :p
21:19 jekstrand: With a few patches.
21:20 karolherbst: yeah, but no reason to support gcc 4.2
21:20 jekstrand: A few years back, I made them back-port a feature from GCC 4.6 or so to make mesa build again.
21:20 karolherbst: :/
21:20 imirkin: gcc 4.2 was the last GPLv2 release
21:20 karolherbst: jekstrand: didn't they move to clang now as well?
21:20 jekstrand: karolherbst: I don't think so.
21:20 karolherbst: ufff
21:20 karolherbst: oh well
21:20 karolherbst: then I'd ignore OpenBSD
21:21 jekstrand: The moment they do, I'm bumping the mesa GCC requirement to at least 6 or maybe 8
21:21 karolherbst: they can make their life miserable for themselves, just leave others out
21:21 ElBarto: OpenBSD moved to clang for a few arches
21:21 jekstrand: ElBarto: Did they move to clang for the core?
21:21 ElBarto: they still have gcc for m68k and sparc32 iirc
21:21 karolherbst: jekstrand: we already require c++17
21:21 karolherbst: ehh
21:21 jekstrand: That's always been the problem. They have Mesa in core becasue they have X in core.
21:21 karolherbst: 14
21:22 ElBarto: jekstrand: they move to clang because 4,2 was too much pain :)
21:22 jekstrand: But clang wasn't in core
21:22 ElBarto: by core you mean in the src tree ?
21:22 karolherbst: I just repeate myself: "they can make their life miserable for themselves, just leave others out"
21:22 karolherbst: *repeat
21:22 jekstrand: ElBarto: I don't know how OpenBSD is structured.
21:22 jekstrand: I just know they had some set of components they couldn't build with clang because clang wasn't in core
21:22 jekstrand: And mesa was one of them
21:23 MrCooper: the reason for LLVM 3.9 is actually Android IIRC
21:23 ElBarto: jekstrand: same as all bsd basically, you have the main source tree with kernel+userland and aside you have ports (that are used to compile packages)
21:23 ElBarto: and yes they have clang in the base system
21:23 jekstrand: Ok, cool
21:23 jekstrand: Maybe we can finally drop ancient GCC support then
21:23 ElBarto: I think nobody would care
21:23 airlied: once modern gcc stop breaking bitfields on me
21:23 ElBarto: we don't on the FreeBSD side
21:24 jekstrand: airlied: Oh?
21:24 airlied: jekstrand: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
21:24 airlied: we found an RA bug in gcc :-P
21:25 karolherbst: not the first time we find bugs in gcc :p
21:25 karolherbst:filed a bug recently as well
21:25 jekstrand: airlied: Oh, that's fantastic
21:26 jekstrand: Yeah, I've seen GCC and clang bugs before
21:26 airlied: this is at least the 3rd time bitfields in mesa have busted gcc
21:26 alyssa: airlied: Wow. Nice.
21:26 alyssa: Should we be, uh, not using bitfields...? This seems contentious.
21:26 Sachiel: or double down on them
21:27 imirkin: that's a dangerous approach to dealing with compiler bugs
21:27 alyssa: Either way wfm I think :p
21:27 imirkin: "compiler is buggy? well, let's just work around it"
21:27 alyssa:looks sadly at dEQP-GLES31.functional.shaders.*
21:27 jekstrand: imirkin: Have you seen the macro in X that adds 8 do { } while() loops?
21:27 HdkR: Is GCC the new CodeWarrior? Find out in this next exciting episode of Compilers and You
21:28 imirkin: jekstrand: iirc that was for synatctic niceness though
21:28 imirkin: so that you could have a ;
21:28 imirkin: jekstrand: also X probably had to work with a couple more compilers.
21:28 jekstrand: imirkin: Syntactic niceness is why you add one. Adding eight is to work around ancient compiler bugs. :D
21:28 imirkin: hehe
21:30 alyssa: 8..?
21:30 jekstrand: nested
21:30 airlied: karolherbst: what is your strange cts crash in nouevau again?
21:30 karolherbst: something invalid memory access
21:30 airlied: a read outisde bounds?
21:30 karolherbst: hard to tell
21:30 karolherbst: could be
21:31 airlied: karolherbst: any test name?
21:31 karolherbst: running the CTS and on the third iteration it happens at some point
21:31 karolherbst: but I think there was some consistency
21:31 airlied: I found a corner case in one of the tests last night
21:31 karolherbst: ahh
21:31 airlied: it is missing glpack/unpack
21:31 karolherbst: what bug?
21:31 karolherbst: mhhh
21:31 karolherbst: if you have a patch I could try it
21:31 airlied: and accesses a 3-byte format with an odd width
21:32 airlied: https://paste.centos.org/view/c63890a6 is my current hacks
21:33 airlied: pretty much fixing any ASAN error
21:33 karolherbst: mhh... I was more talking about issues on the GPU, but maybe that was also just stale memory somewhere
21:34 airlied: well it could potentially cause the gpu to access some memory outside
21:34 karolherbst: yeah..
21:34 airlied: if the transfers hit properly
21:34 airlied: like ASAN hits inside mesa for that
21:34 airlied: in llvmpipe
21:34 karolherbst: ohh, interesting
21:35 airlied: since it reads one byte over and writes one byte over
21:39 dcbaker: mareko, eric_engestrom: there's a patch from each of you near the top of the staging/20.0 branch that I had to do some backporting to get them to apply, could you take a look and make sure everything looks okay?
21:39 imirkin: airlied: nouveau doesn't expose any 3-byte formats
21:40 eric_engestrom: dcbaker: sure, looking now
21:40 eric_engestrom: mareko: for ease: https://gitlab.freedesktop.org/mesa/mesa/-/commits/staging/20.0
21:41 eric_engestrom: dcbaker: fyi that grep|sed is exactly what I ran to make that commit in the first place :)
21:41 airlied: imirkin: guess you then have an even wierder bug :-P
21:42 dcbaker[m]: eric_engestrom: cool, that makes things easy :)
21:42 imirkin: fwiw i get the issue pretty consistently on the first run
21:42 imirkin: and in the same spot
21:42 imirkin: but only happens on full runs
21:43 imirkin: with the gpu trying to read (or write, i forget), a pretty stale page which is no longer in the page tables
21:43 eric_engestrom: dcbaker: ah no actually, I grepped for `mesa/mesa/[a-z]` and you didn't, which made you add too many `/-/`
21:44 eric_engestrom: there's a couple of `/-/-/` that you added, grep for those and drop them :)
21:47 dcbaker[m]: oops, okay, I'll re-run `git grep` then :)
22:06 dcbaker[m]: Alright, updated version pushed
22:36 mareko: dcbaker: it looks ok
22:36 dcbaker[m]: thanks
22:58 eric_engestrom: dcbaker: heads up, looks like your meson bump series broke master: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/2908249
23:00 dcbaker[m]: that looks more like debgian testing is broken on s390x, probably because of an in process rebuild of gcc
23:01 eric_engestrom: indeed, looks like debian shifted under our feet and the rebuild just happened to fall on your MR
23:02 eric_engestrom: not sure what the process should be right now? we won't be able to merge anything through Marge until debian is fixed upstream :/
23:03 airlied: pretty much we wait for MrCooper fix tomorrow
23:04 eric_engestrom: hehe
23:04 airlied: then people suggest 20 other OSes we should use, and we switch everytime one of them screws up
23:05 airlied: oh that already happened in irc :-P
23:05 anholt_: the main fix we need is marge mrs happening in mesa/mesa context, not sure if that's even possible, though.
23:06 anholt_: an alternative would be that we back out dylan's meson bump until we can sort out new debian containers, even though those commits were innocent.