00:02haasn: is there a way to get some sort of stats (hud/overlay? ftrace? log? anything?) for swapchain stuff? e.g. knowing when frames enter and exit the swapchain, so you can get a better idea of the effective frame latency when debugging a low-latency application
00:05haasn: it's basically impossible to do this from the vulkan API alone because I don't know when your x11_present_to_x11 gets called
00:08airlied: might be something you could do with gpuvis, but I'm just throwing things around rather than knowing
00:16bnieuwenhuizen: haasn: if you set permissions up right for userspace: https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/tree/wsi-tracing
00:16bnieuwenhuizen: adds markers for use in gpuvis
00:17bnieuwenhuizen: IIRC you need some manual action to make the trace marker writable from your user though
00:42alyssa: hm, seeing ('fmul', ('fmul', x, ('fabs', #a)), #b)
00:42alyssa: In theory, the fabs should constant fold, then the fmuls reassociate, then the extra multiply is constant folded again
00:43alyssa: Trying to figure out where that's not happening..
01:26FreeFull: I think the 20.1 release might have reduced CPU usage for some programs, which is nice
01:27FreeFull: Unless I'm wrong and it's something else
01:28alyssa: FreeFull: If it improved, it's mesa
01:28alyssa: If it broke, it's not.
01:41FreeFull: alyssa: Right ;)
03:32yshui: amdgpu seems to be pretty careless about sleeping with preemption disabled... https://bugzilla.kernel.org/show_bug.cgi?id=208135
07:01tzimmermann: danvet, mripard, which branch is the fastest way to get yesterday's ast fix into the upstream kernel? drm-misc-fixes?
07:02mripard: tzimmermann: next-fixes
07:03mripard: 5.7 is out, so the closest you can aim for is -rc1
07:03tzimmermann: mripard, thanks!
07:06dj-death: dcbaker: the 20.0 backports look fine
07:14airlied: tzimmermann: how far back is broken?
07:14tzimmermann: airlied, 5.6
07:14airlied: I'm going to throw it onto my tree now
07:15airlied: and resend a pull to Linus
07:15tzimmermann: i already pushed the patch into drm-misc-next-fixes
07:15airlied: tzimmermann: do you know if there's anything else in there?
07:16tzimmermann: airlied, 2 other patches. i wanted to send you a PR later today
07:17airlied: tzimmermann: can you do it now? :-)
07:17airlied: I'll try and beat the linus race
07:17tzimmermann: i'm going to prepare the PR now
07:40hakzsam: dcbaker[m]: looks good
07:46pq: pepp, a normal compositor must always import to EGL to guarantee that it has a fallback path just in case putting it on a hw plane is not possible. The Wayland extension for avoiding EGL import violates this, so it's only useful in very restricted (not desktop) systems.
07:47pq: danvet, thanks! I'd hope more people would ack the hot-unplug doc. I have no personal contacts.
07:50pepp: pq: I see. So if import fails, weston chooses to kill the client; but another compositor could decide to draw a dummy image as a fallback path when putting on hw plane is not possible, right?
07:50tzimmermann: airlied, sent
07:51danvet: pq, I think if amd acks we're good
07:51pq: emersion, how would a "create_immed that doesn't kill you" differ from "create" that is already there? I see using the round-trippy "create" as the only way to not die randomly.
07:51danvet: pq, maybe noral (but he's a bit away) or someone else who's done an usb/spi panel driver or so
07:51danvet: not sure anyone from nouveau cares
07:51danvet: maybe ping skeggsb for that
07:52emersion: pq: yeah, that was a bad idea
07:53airlied: tzimmermann: thanks, processing it now, and frying salmon, we'll see which wins
07:56MrCooper: daniels: Marge failing with 'Branch cannot be merged' is still an issue, though thankfully not as often anymore; but yeah, the correct response to that is re-assigning to Marge again, not merging directly
08:00pq: pepp, yes, compositor are "allowed" to do whatever, but for a desktop compositor I would consider it a bug to use placeholder graphics because didn't verify the buffer is always usable.
08:02pq: pepp, btw. there is a further consideration: since the compositor can choose to show anything anywhere, having both secured and insecure outputs likely means the compositor shouldn't accept TMZ buffers. Unless it can somehow guarantee the TMZ'd window cannot be moved to an insecure output.
08:03pq: pepp, OTOH, Weston has a protocol extension for HDCP-required content for a model where the compositor is trusted (no TMZ necessary), and that explicitly allows the compositor to use placeholder graphics when necessary.
08:05pepp: pq: is the protocol extension this one: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/48 ?
08:06pq: pepp, hmm, that's the DRM-backend side, but where's the protocol...
08:07pq: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/protocol/weston-content-protection.xml is the protocol
08:09pepp: pq: thanks
08:10pq: in hindsight, maybe that protocol should include feedback about whether placeholder graphics was used
08:10pq: it's kinda silly if the client can't know if it's showing garbage
08:11daniels: MrCooper: thanks
08:14pq: danvet, Andrey is in cc already, should I add someone else from amd too?
08:15danvet: pq, könig probably cares the most, hwentlan for display side
08:16pq: danvet, ok. I'll add everyone you mentioned for the next version. I hope gmail agrees to send it...
08:17danvet: pq, I'd just reply to the patch and ping them, they should all be on dri-devel ...
08:17danvet: karolherbst, might also comment from nouveau side
08:17pq: ping? as in irc?
08:19danvet: reply all + add them to To: + put a personal note on top of why you ping them
08:20danvet: e.g. "HI Ben&Karol, any thoughts from nouveau side on this hotunplug work in progress spec?"
08:20danvet: or also irc
08:20danvet: but könig isn't on irc
08:20danvet: and skeggsb is generally not around when I'm awake
08:21pq: ookay, thanks
09:15MrCooper: airlied: the disk cache seems to have made the llvmpipe CI jobs quick enough that it might make sense the leave NIR_VALIDATE enabled for them?
10:03bbrezillon: jekstrand: quick question about copy_prop_vars, I'm not sure I understand why we only care about Acquire on scoped-barriers
10:06mareko: alyssa: regarding your bcsel mediump issue, is it something that can be fixed in lower_precision?
10:06mareko: alyssa: if so, having a test in lower_precision_test.py would be useful
10:07mareko: if it's a NIR issue, then ignore
10:31bbrezillon: jekstrand: IOW, shouldn't we call apply_barrier_for_modes() for both Acq and Rel in copy_prop_vars_block()
11:16karolherbst: does any driver in mesa have a script to parse C header files containing register definitions or something? I'd like to turn the qmd.h headers we have in nouveau now into proper structs and enums
11:16karolherbst: with a python script
11:34danvet: tzimmermann, I have a patch here which at least converts ast over to managed pci functions
11:34danvet: not the other stuff, but a start
11:34danvet: should I send it out?
11:35danvet: oh I did already, and we discussed it a bit, but no a-b or r-b yet
11:36danvet: drm/ast: Use managed pci functions
11:58tzimmermann: danvet, i don't remember
11:59tzimmermann: i'm going to convert ast over during the next weeks
11:59tzimmermann: i can build upon your patch
12:01tzimmermann: danvet, found it. you answered my question. but i never go back to it
12:01danvet: yeah np, I'll let you decide whether you want to merge or pull in your series or drop it
12:02danvet: I'll later to review your ast series later today, need to take care of laundry now first
12:02danvet: nag me tomorrow if I've forgotten
14:12alyssa: mareko: unclear but I think so, I'll try to figure out a minimal test
14:34jekstrand: bbrezillon: Uh.... There's a reason. I'm going to have to give it a good think to remember what it is
17:19Lyude: huh, just got an email from gitlab saying that the ci pipeline failed for drm/igt-gpu-tools after I pushed a patch
17:21Lyude: oh-retrying it made it work
17:36bernie_: pq: https://codewiz.org/pub/hdr-is-on.jpg
17:36bernie_: pq: great success :-)
17:38FreeFull: bernie_: Beautiful
17:38bernie_: so trippy
17:39bernie_: Now the monitor likes my HDR_OUTPUT_METADATA blob... it was hard to convince
17:39bernie_: The fb is still setup wrong and I'm trying to figure out why
17:40bernie_: I know it works fine in X11 by setting "DefaultDepth 30" with xf86-video-amdgpu
17:41bernie_: so It's just a matter of finding the bug in the BGM / EGL initialization path... I guess?
18:02agd5f_: bernie_, depth30 != HDR
18:13bernie_: agd5f_: it's a pre-requisite, though...
18:15bernie_: agd5f_: my thinking is that depth 30 + hdr metadata + a video player decoding 10bpc content + any common 10bit video will get me there.
18:18bernie_: (if there's a gap in these assumptions I'd like to be corrected now rather than find out the hard way)
18:19imirkin: bernie_: well, the video would have to be encoded in BT.2020
18:19imirkin: not just 10bpc
18:20bernie_: [vd] Decoder format: 1920x1080 [0:1] yuv420p10 bt.709/bt.709/bt.1886/limited/auto CL=unknown
18:20bernie_: hmm... then this one is no good
18:20imirkin: or the decoder isn't smart enough
18:20bernie_: it's bt something else
18:20imirkin: bt.709 is the "standard" thing
18:20imirkin: never heard of bt.1886
18:20imirkin: but i'm not an expert
18:21imirkin: numerically it's closer to bt.2020 than bt.709 though :)
18:24bernie_: does anyone have a test video file?
18:24bernie_: looks like mpv can make various color space conversions while decoding
18:24emersion: i use files from 4kmedia.org
18:25ajax: i thought there was a big buck bunny render in bt.2020 or similar?
18:26emersion: i can only find 8bit big buck bunny :(
18:26imirkin: (looks like BT.1886 is a replacement for BT.709 gamma function... basically the same, but slightly different)
18:27linkmauve: haasn, you may be interested in ↑
18:27ajax: i can find it in HD, in HFR, and in 4k, but not in HDR
18:28ajax: but yeah 4kmedia looks like they've got plenty
18:29bernie_: i picked one at random (Samsung: Travel With My Pet HDR)
18:31haasn: bt.709 is an OETF, bt.1886 is an EOTF
18:31haasn: they're not really comparable
18:31bernie_: but I'm still seeing FB_ID->Depth: 24
18:32haasn: imirkin: BT.2020 is orthogonal to HDR
18:32haasn: also mpv can output HDR signal no matter the content
18:32haasn: --target-trc=pq *
18:33TheRealJohnGalt: Display will still be in wrong colorspace though?
18:33haasn: if you just need a source of PQ signal for testing ^ bernie_
18:33bernie_: oh, I think I figured it... it's a parameter of drmModeAddFB()
18:34bernie_: haasn: thanks
18:35bernie_: i can't believe it, mpv is too slow to decode this on a beefy cpu
18:36haasn: is it a HEVC sample?
18:36bernie_: haasn: no, .ts
18:36haasn: that's just the container
18:36agd5f_: bernie_, I think Kodi has support for HDR
18:36haasn: but it'd surprise me if it wasn't HEVC if you have it in MPEG-TS :p
18:36bernie_: haasn: ah yes, HEVC
18:37bernie_: and, incidentally, it's also a video of my hometown!
18:37bernie_: this: https://4kmedia.org/samsung-travel-with-my-pet-hdr-uhd-4k-demo/
18:38bernie_: agd5f_: I took inspiration from Kodi's initialization code to hack HDR into kwin_wayland
18:43bernie_: WOOHOO! I got a non-crippled display in 30bpp!
18:44bernie_: agd5f_, haasn, emersion: https://codewiz.org/pub/drm_info-kwinft.out
18:44bernie_: can't see any difference when playing the demo UHD video
18:47bernie_: actually, it's somewhat darker in the HDR display
18:52emersion: are you sure kodi sets the HDR metadata?
18:53emersion: iirc it only does it when hw decoding is used or something
18:54emersion: (so direct vaapi → scanout)
19:17swick: bernie_: sounds like it's working then
19:18swick: the slightly darker content is typical when playing PQ encoded data
19:18bernie_: it wasn't hard, in hindsight... I was just totally clueless on a number of things: https://gitlab.com/berniecodewiz/kwinft/-/commit/1b5effddaf0fe4daa39ba6a8ae59575b9f3eb34e
19:19bernie_: swick: oh, really? phew...
19:19swick: but you should be able to spot brighter highlights though
19:20swick: yeah, the PQ encoding is absolute and everything else isn't. for some reason I forgot it doesn't properly line up most of the time with the SDR brightness.
19:23haasn: I wonder what HDMI_EOTF_TRADITIONAL_GAMMA_HDR is
19:25haasn: https://gitlab.com/berniecodewiz/kwinft/-/commit/1b5effddaf0fe4daa39ba6a8ae59575b9f3eb34e#9a9496d074c4a769b196292dd310bc8e35bcd7d2_568_634 why those values?
19:26bernie_: haasn: I decoded my EDID and tried to match the values in it
19:26bernie_: the monitor also supports SMPTE ST2084
19:26bernie_: i should have used that one instead
19:27bernie_: haasn: https://codewiz.org/pub/edid-benq-ex3501r.txt
19:27swick: iirc you can chose pq, hlq or traditional gamma which I guess is bt709
19:28haasn: bernie_: oh, I see; interesting
19:28haasn: but probably wrong, it should be forwarded from the content source
19:28bernie_: haasn: some of the values are just guesses... i kept tweaking them until the monitor agreed to turn on the HDR indicator
19:29bernie_: haasn: i'm really that clueless, yes :)
19:29swick: you should be able to zero out everything except eotf and type
19:30bernie_: haasn: ah, but I am using HDMI_EOTF_SMPTE_ST2084...
19:30bernie_: swick: no, with the last two zeroed, I wasn't getting HDR ON in the osd
19:30bernie_: swick: max_cll and max_fall
19:31swick: that's weird. I was told it should work.
19:31bernie_: swick: I'd have to check again to be sure... at times I got confused by forgetting to install the new binary after building it
19:31haasn: if in doubt, assume the monitor doesn't implement HDR correctly
19:32swick: and at the very least you should take max_cll and max_fall from the content
19:33bernie_: swick: trying now...
19:35bernie_: swick: you were right, eotf = 2 and metadata_type = 1
19:35bernie_: swick: ...and everything else zeroed works ok
19:36swick: good. would have been really bad for me if it didnt
19:36bernie_: swick: I think I was not setting 10bpc before
19:36bernie_: swick: it's been several nights ago
19:37bernie_: ok, i should hit the bed, it's 4:37am here
19:37bernie_: thank you for your help, it was fun
19:38bernie_: swick: wait a second... this is weird. Now I have "HDR: ON" also in the X11 session
19:38swick: no really weird, just the way KMS works
19:39bernie_: swick: lol, kms doesn't clear the HDR_OUTPUT_META blob when switching vt
19:39swick: well, Xorg doesn't
19:39bernie_: ah ok... WORKSASINTENDED
19:40Lyude: (for those curious, it's preferable for kms not to do anything on it's own because then you can do nice stuff like seamless boot transitions :), although I doubt that was the original reason it was made that way)
19:40bernie_: swick: colors are bad in some applications... I guess the compositor should turn this on only when a videoplayer goes fullscreen
19:41bernie_: swick: i'll read the wayland protocol draft when i have some time
19:41swick: apparently some people abuse this to turn on vrr on compositors that don't support it
19:41bernie_: Lyude: oh, I see
19:42swick: yes, that's one approach that should work
19:42swick: or rather only turn it on when the application is in fullscreen and sends HDR information
19:43swick: if you want mixed SDR and HDR things get a lot more complicated
19:44emersion: ^ this is an understatement
19:44bernie_: Lyude: though there's an update problem with this approach: as soon as one compositor starts setting some new property, all the older ones must be updated to at least clear it
19:44bernie_: swick: i was just wondering how this could even be done
19:44emersion: bernie_: yup! this is a known issue with no solution yet
19:45emersion: there are some recent-ish threads about it on dri-devel
19:45bernie_: emersion: i guess... you filter all content through some shader at composition time? sounds expensive.
19:46bernie_: emersion: what does Windows 10 do? it used to show strange colors when HDR10 is enabled, but now it doesn't any more
19:46Lord: /b alac
19:47swick: since applications assume SDR to just work and we can't break that yes, it requires transformations either at composition or scanout time
19:48swick: I think emersion was talking about KMS properties not resetting
19:49emersion: for HDR there is a plan
19:49swick: don't have a windows machine here but I've seen HDR working on a windowed VLC
19:49swick: so they seem to be doing something that works, kind of?
19:50bernie_: on Windows?
19:51bernie_: one last question: is it safe for a desktop compositor like kwin to just set 30bpp by default if it's supported?
19:51bernie_: or are drivers and apps still way too buggy?
19:51emersion: it's not always a good choice
19:51emersion: you may not be able to light up all outputs if you choose 30bpp
19:51Lyude: ideally as well, the driver is supposed to be able to scale down bpps as needed
19:51bernie_: i hit a bug with 10bpc in spectacle (the kde screen capture utility)
19:51Lyude: but it's not implemented everywhere quite yet
19:52Lyude: mst for instance needs to be better about it
19:52emersion: so it should probably be a user setting
19:53swick: Lyude: I have yet to figure out how exactly scale down the bpp
19:53swick: apparently Nvidia and AMD support dithering there
19:53Lyude: swick: by 'scale down' i mean just forcing displays to lower bpps if bandwidth limitations wouldn't allow for higher bpps
19:53bernie_: could it be that composing ARGB8888 windows to a fb in XRGB2101010 is much slower?
19:53Lyude: swick: yeah nvidia has hw dithering
19:54Lyude: i915 does as well
19:54swick: would be nice if this kind of stuff would be discoverable with KMS
19:54Lyude: swick: coincidentally I am actually hooking up the dithering property for nouveau in igt, since we need to manually disable it for crc readback to be reliable
19:55imirkin: bernie_: many applications aren't ready for a default 30bpp visual
19:55swick: Lyude: so there is a property?
19:55Lyude: if you've got any ideas, cc lyude at redhat bot com
19:55bernie_: imirkin: thanks, it's what i feared
19:55Lyude: swick: for nouveau, I don't think it's universal for other drivers
19:55imirkin: bernie_: e.g. my terminal of choice, which is admittedly older than time, doesn't handle transparency with a 30bpp root visual
19:56bernie_: imirkin: i've been running my desktop in 30bpp for some time and I occasionally see purple boxes when apps redraw
19:57swick: Lyude: some video player people said they don't trust the hardware to get dithering right and they just do it themselves on 8bpc framebuffers
19:57Lyude: those video player people whose project name likely starts with the letter m say many things
19:58swick: spot on
19:59swick: anyway, would be kind of neat to advertise 10bpc to clients and get at least somewhat better pictures out by dithering them down with hardware
20:01ajax: swick: https://paste.centos.org/view/raw/f90a1e12 perhaps
20:03swick: ajax: that looks like X. I don't understand anything related to X.
20:03swick: but I mean only advertising 10bpc if the hardware actually can use the extra information
20:05ajax: radeon and intel have both supported 30bpp scanout in hardware since... dx9 i think?
20:05emersion: can we know whether the screen supports 10bpc?
20:05imirkin: nvidia since dx10
20:05imirkin: including fp16
20:05airlied: MrCooper: might have to give it a try next week see how much it blows out
20:05imirkin: emersion: yeah, in EDID
20:05emersion: ok, cool
20:06ajax: which for real-dvi has always meant dithering down to 8bpc
20:06airlied: MrCooper: but I'm going to enable GL4.5 soon on llvmpipe, and that'll blow out the test list
20:06emersion: fp16 scanout is pretty cool
20:06imirkin: ajax: i'm told there was some sort of insanity where you could actually get 10bpc over DVI.
20:06imirkin: with specialized monitors
20:06emersion: since there's no need to have a shadow buffer anymore
20:07swick: but surely not all hardware supports dithering down to 8bpc and not all displays support 10bpc
20:07ajax: imirkin: probably you just wiggle the pins as if it's hdmi 10bpc and rely on the monitor to tell you that's a thing.
20:07imirkin: emersion: supported on nouveau since G80, i think. but 1024-sized LUT only available starting with GF119
20:07imirkin: ajax: well, with HDMI you specify it in the infoframe ... no such thing with DVI
20:07ajax: swick: every gpu i'm aware of that can do 10bpc scanout _will_ dither down to 8bpc if that's what the output is
20:07daniels: bernie_: btw you _really_ want to use drmModeAddFB2 instead of drmModeAddFB
20:08ajax: (unless you tell them not to ofc)
20:08imirkin: yeah, nvidia will dither down to whatever you tell it. you can actually disable the dithering too
20:08ajax: correct that not all displays can do anything meaningful with 10bpc streams
20:08swick: imirkin: slightly unrelated but in fp16 scanout what range gets mapped?
20:08imirkin: swick: 0..1
20:08imirkin: on pre-fermi, it was actually 0..1024, but there was an extra thing to just divide everything by 1024 there :)
20:08imirkin: er, multiply i guess
20:09swick: because I've seen microsoft APIs where fp16 is used in HDR with 1.0 being "reference white" and values over 1.0 still getting mapped
20:09imirkin: swick: i think you might be able to use values outside the 0..1 range to play CSC games, not sure.
20:09imirkin: but everything else is essentially clamped to 0..1 since it has to go through the LUT anyways
20:10ajax: the thing "on the wire", for both dp and hdmi, is an unsigned normalized integer per channel
20:10swick: mh, maybe they just don't do direct scanout on those buffers
20:11ajax: the framebuffer format and the LUT determine the mapping into that unorm's range
20:11imirkin: swick: at least nvidia GPUs can apply a (fixed) scaling factor to all the values
20:11ajax: so, yes, it's not "direct"ly sending the fp16 pixel to the monitor
20:11swick: right, that much I know
20:11ajax: (which is true for 8bpc too, technically, if the LUT is not an identity map)
20:11swick: imirkin: that might work then
20:12swick: imirkin: is that exposed in KMS?
20:12imirkin: for KMS, the expectation is that the buffers contain 0..1 values
20:13swick: it would be really useful if it was configurable
20:13imirkin: so i set the fudge factor to 1024 for pre-fermi, since the underlying hw wants values 0..1024
20:14imirkin: (in case it's not intuitively obvious, format 0xca == fp16, and 0x6400 == 1024 in fp16
20:17imirkin: https://nvidia.github.io/open-gpu-doc/classes/display/cl507c.h -- look for SET_CONVERSION
20:17imirkin: can specify a gain and offset
20:19imirkin: looks like it was still there on volta, but gone on turing (which is the latest nvidia gen)
20:19imirkin: all that can be integrated into the CSC though
20:20imirkin: (earlier GPUs, DX10 and early DX11-class, had no such facility though)
20:29vsyrjala: unfortunately w/ intel hw + modesetting ddx you can't actually get 10bpc since the use of the legacy gamma forces everything to get truncated to 8bpc
20:30ajax: surely using the legacy gamma isn't mandatory, just that nobody wants to touch the ddx, right?
20:31imirkin: vsyrjala: hmmm ... that sounds right. but i also think there were some patches to make it 10bpc friendly from Mario Kleiner
20:31imirkin: unfortunately i don't remember what it was that he was making work exactly
20:31vsyrjala: i don't think he had patches to actually use the GAMMA_LUT prop, which is what it would take
20:31imirkin: i think it was around allowing X internals to use a 1024-sized LUT if one was presented via legacy
20:32imirkin: of course presenting > 256 causes problems for just about everything, so ... can't do that.
20:34agd5f_: we exposed the newer color management stuff in xf86-video-amdgpu
20:36vsyrjala: i added it to the intel ddx as well. but i haven't found a way to trick anyone to do the same for modesetting
20:38imirkin: i should add it to -nouveau
20:40vsyrjala: so far i don't need 10bpc on modesetting myself since cfl can't do 10bpc compressed scanout anyway, and i want compression more than i want 10bpc
20:57imirkin: vsyrjala: yeah, my only 10bpc monitor (aka tv) is presently out of cable range from my computer
21:03vsyrjala: i could sell you a lightly used 10m hdmi cable where the metal shell of the plug decided to stay inside the tv receptacle when i pulled the rest of the cable out
21:07imirkin: sounds efficient :)
21:07imirkin: i actually have a 10m hdmi cable
21:07imirkin: i think it needs to be more like 15m
21:07imirkin: i take that back. i have a 10-foot cable.
21:08imirkin: and the king couldn't quite muster up a full 1-meter foot.
21:18alyssa: mareko: https://people.collabora.com/~alyssa/0001-WIP-glsl-Test-GLSL-ternary-statement-in-precision-lo.patch
21:18alyssa: ^ As asked
21:18hanetzer: hey alyssa :)
21:18alyssa: hi :)
21:36alyssa: looking into ways to fix that test. certainly easier than getting lost on the nir side, so thanks :-)
21:38mattst88: airlied, dcbaker: wrt issue 2863, I suggest that we just ignore this for now and release 20.0.8
21:38mattst88: and if we figure it out and fix it, we can just make a 20.0.9 or something
21:39mattst88: but a lack of a 20.0.x release without the webgl regression is really starting to hold things up for Gentoo
21:39mattst88: we'd like to stabilize llvm-10, but we need a Mesa that supports llvm-10 first, etc
21:39dcbaker[m]: I'm happy to make the release if airlied is okay with it, everything ran through CI okay
21:52alyssa: it adds a conversion to float16
21:52alyssa: after each rvalue and a conversion back to float before storing
21:53alyssa: ^ I guess that's the crux of the issue. Not that it should be too hard to change but it departs markedly from how the pass was conceived.
21:57alyssa: working on a RFC-level patch
22:02alyssa: working on a RFC-level patch
22:02alyssa: oops, sorry, too many terminals open
22:07HdkR: I understand, I stack too many levels of gnu screen