00:44 imirkin: kallisti5: you have a K80?
00:45 imirkin: i thought those were a wee bit pricey
00:52 imirkin: or is this one of the virtual ones through amazon compute or whatever?
01:49 airlied: jekstrand: I test it with cts at the moment, I think there were like 30-40 fails left for vulkan 1.0
01:50 airlied: https://paste.centos.org/view/raw/1705e32e is the last set of fails
01:51 airlied: there is also one outstanding bug with vertex inputs, my fix broke GL, so I need to rework it
03:51 airlied: jekstrand: i plan on enabling ci with a subset of cts once i fix the vertex input bug
04:52 jekstrand: airlied: If you've got a reasonable test setup, I pushed some fresh patches to !5275 including one for vallium which I've tested with crucible but not the CTS. I expect the CTS should work but I didn't give it a run.
10:37 pinchartl: danvet_: is there anything blocking "[GIT PULL FOR v5.10 - v2] R-Car display drivers miscellaneous changes" ?
10:38 danvet_: airlied having taken a few days off I think
10:38 danvet_: he said he's back tomorrow
10:38 pinchartl: I'll try to ping him tomorrow then
10:38 pinchartl: it was originally sent two weeks ago :S
10:39 danvet_: hm then just lost
12:02 vsyrjala: anyone know if there's an eta for fixing kernel doc vs. sphinx3?
12:26 pcercuei: Why is the 'gamma_lut_property' a CRTC, and not a plane property?
12:28 pcercuei: I'm trying to figure out how to use DRM_FORMAT_C8
12:29 vsyrjala: legacy reasons
12:29 vsyrjala: + we have no per-plane gamma atm
12:29 vsyrjala: but yeah, ideally c8 would get its palette from a per-plane lut
12:32 pcercuei: Ok, should I add a 'gamma_lut_property' to my plane then?
12:32 vsyrjala: no
12:33 vsyrjala: that's a bigger discussion where we need everyone to agree on the new uapi. + we have to make sure the new uapi is actually good enough, which the current thing isn't
12:34 vsyrjala: also existing userspace assumes the crtc gamma applies to c8. so you would have no userspace ofr your new uapi anyway
12:36 pcercuei: Well, I could also use the CRTC's gamma_lut_property, but it feels wrong, since only one of my planes supports C8
12:37 vsyrjala: that's the way it works atm
12:41 pq: Curious, does anyone even know of userspace that could use C8?
12:42 vsyrjala: xorg
12:42 pq: *cough*
12:43 pq: what about "actually wants or benefits from C8"? :-)
12:43 vsyrjala: also fbcon is a good use for it imo. which reminds i had some fixes around the fb_helper gamma stuff i need to dig up again
12:44 vsyrjala: as in why would you want a 16 color (or whatever it is) terminal wasing 4 bytes per pixel
12:44 vsyrjala: we need a high resolution text mode in hw!
12:46 pq: Does fbcon really use C8 or is that a wish?
12:48 vsyrjala: it can use it. but the lut handling in fb_helper was a bit borked last i looked. as in it didn't always seem to restore the lut properly on vt switch
12:49 linkmauve: pq, the countless old games which used to use all of 256 colours?
12:49 pq: linkmauve, how many of those run straing on KMS?
12:50 linkmauve: SDL 1.2 had a fbdev backend, if they were ported to SDL2 they could use DRM.
12:50 pq: hm, if fbcon is in C8, does that mean that /dev/fb is in C8 as well?
12:51 pq: the modern KMS doesn't support modesets via /dev/fb, does it?
12:51 pcercuei: pq: I'd use C8 in SDL1
12:52 pcercuei: it's useful when emulating old computers and game consoles
12:52 pcercuei: also Doom etc.
12:54 pcercuei: linkmauve, I have a KMS/DRM backend for SDL1 (https://github.com/OpenDingux/SDL/tree/SDL-1.2)
12:54 linkmauve: pcercuei, emulators can trivially use a 256 values Texture1D to emulate C8 for modern consumption.
12:54 linkmauve: pcercuei, why is it not upstream? :)
12:54 vsyrjala: pq: yeah, no modesets/etc. via drm_fb_helper. it's rather limited in what it can do
12:55 pcercuei: linkmauve: It's still brand new, it's the plan to upstream it
12:55 pcercuei: although upstream SDL doesn't really care about SDL1 anymore
12:56 vsyrjala: did it ever? *cough* X -bs *cough*
12:56 linkmauve: pcercuei, btw you might be interested in a project I started recently for another toolkit, https://github.com/linkmauve/glfw2to3
12:57 pcercuei: < linkmauve> pcercuei, emulators can trivially use a 256 values Texture1D to emulate C8 for modern consumption.
12:57 pcercuei: Instead of submitting a C8 dumb buffer, you submit a Texture1D to the GPU, which will render it to a buffer that you then send to the video hardware
12:58 pcercuei: That's extremely costly in terms of performance
12:58 pcercuei: Besides... not all devices I work on have a GPU
13:01 pq: old-school, cool
13:03 kisak: pcercuei: get a chance to play around with sdl12-compat?
13:10 danvet_: sumits, you have drm-misc commit rights ...
13:10 danvet_: for your panel patches
13:16 sumits: danvet_, of course :) the question was also to check if there are any other comments. if I don't hear by eod, I will push them myself
13:18 danvet_: you can also ping here
13:22 sumits: ack
13:26 danvet_: sumits, I think tagr and sravn for panel stuff
13:38 sumits: sure, danvet_. tagr / sravn, if you guys are ok with the panel patches I posted, please let me know if I should go ahead and push them
14:02 hakzsam: dcbaker: why 20.2 has been soo delayed? branchpoint is two months old
14:05 vivijim: airlied danvet_: any issue with last week's pool request?
14:05 jekstrand: hakzsam: According to the release calendar, eric_engestrom is responsible for 20.2.
14:05 danvet_: vivijim, airlied took a few days off apparently
14:05 danvet_: so should be all fine
14:06 hakzsam: jekstrand: https://docs.mesa3d.org/release-calendar.html#calendar it's Dylan for 20.2 ?
14:07 vivijim: danvet_: no worries then... thanks
14:07 jekstrand: hakzsam: You're right. I misread. Not sure how that happened.
14:09 dcbaker[m]: hakzsam: getting the release out is my project for today. Sorry it's been delayed,I was on bonding leave and it's taken me a week to get into the groove
14:10 hakzsam: no worries and great news!
14:19 kisak: dcbaker[m]: thanks for letting us know. https://gitlab.freedesktop.org/mesa/mesa/-/issues/3513 is probably bad enough to be a release blocker, so it'd be nice to have !6776 in 20.2.0.
14:25 kallisti5: imirkin: cheaper now :-)
14:25 kallisti5: (K80's)
14:26 kallisti5: found one on ebay for $130... neat toy for that price
15:25 pcercuei: kisak: yes, the problem with sdl12-compat, is SDL2 :)
15:27 pcercuei: kisak: SDL2's KMSDRM backend only has the bare minimum to enable EGL. So it requires a GPU, even if you render in software, and if you do, the software buffer is mapped to a texture then rendered by the GPU to a GEM buffer, while it'd be much faster to just software-render to a dumb buffer
15:58 champagneg: hi, i've noticed ioctl sent by drmModeGetConnector may end up in a poll loop with some drivers (in my case, xilinx DP connector). Any tips to mitigate the impact of this on compositor startup time? Maybe the driver shouldn't be actively waiting to detect a monitor?
16:13 thaytan: Lyude, finally got a chance to try the OLED backlight patch stack. Some minor merge issues against drm-tip already, but works great
16:13 Lyude: thaytan: awesome, was yours one of the laptops that broke with the original dpcd control patch?
16:18 thaytan: Lyude, I'm not sure any more, I've forgotten what I tested since June. I remember that it worked when the Samsung panel line was in the quirks table and matched
16:19 thaytan: It's a 2020 HP Spectre, if you're keeping a list
16:23 Lyude: thaytan: ah, gotcha
18:09 airlied: pinchartl: not forgotten, but next has been a bit slack, will roujd it up today
18:12 pinchartl: airlied: thanks
18:12 pinchartl: I've sent a v3 of the pull request in the meantime
18:12 pinchartl: as there was a small bug introduced in one of the patches
18:12 pinchartl: I wanted to send a fix on top, and realized the bug wasn't in -next yet :-)
18:14 airlied: pinchartl: yay my laziness prevents bugs :-p
18:17 pinchartl: :-)
20:35 sravn: sumits: Will take a look tomorrow and maybe do a swipe on panel patches at the same time. Just back from a one week vacation so stuff has piled up
20:46 karolherbst: jekstrand: how well does your generic pointer stuff work?
20:46 imirkin_: pq: fyi, nouveau causes C8 to be used by fbcon for low-vram GPUs
20:47 imirkin_: i forget the cut-off, might also have to do with the resolution of the primary display
20:47 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_fbcon.c#L569
20:48 imirkin_: looks like it's just based on vram. 32MB and under gets C8.
20:48 jekstrand: karolherbst: Seems to be working
20:48 jekstrand: karolherbst: Not sure how to measure "well" though
20:48 karolherbst: right..
20:48 karolherbst: two of the SVM CTS tests need generic pointers, so I am planning to run them on top of your patches and see how that goes...
20:48 imirkin_: (and 32MB happens even on some MCP8x GPUs, when you configure the bios not to steal too much system memory)
20:49 jekstrand: karolherbst: Cool. AFAIK, they should work.
20:50 imirkin_: er, make that MCP7x, i.e. MCP77/79, aka nvaa/nvac.
20:55 airlied: I think radeon does it for low VRAM gpus as well
20:55 airlied: or mabye only 16bpp
20:55 imirkin_: and last i checked (which was admittedly a while ago, probably around 4.3 or so), it worked fine (after we fixed it after breaking it)
20:56 imirkin_: i also added some stuff to modetest to be able to easily exercise it
21:06 airlied: pinchartl: something ate the PR
21:06 airlied: the branch name is missing
21:11 pinchartl: airlied: ok ?
21:11 pinchartl: let me check
21:11 pinchartl: strange
21:14 pinchartl: airlied: I've replied with the tag name. not sure what happened
21:16 imirkin_: airlied: do any practical X drivers support an indexed root visual? nouveau doesn't, fwiw.
21:17 imirkin_: i sorta assume the core allows for it
21:29 vsyrjala: intel
21:29 vsyrjala: dunno about others
22:10 dcbaker[m]: kisak: That looks pretty important. I've added it to the milestone, and I'll try to get out another RC today or tomorrow
22:11 dcbaker[m]: oops, I see the fix already landed
22:31 jenatali: Hm, is this a known freedreno CI issue? I'm not seeing it in the tracker: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4640355
22:33 imirkin_: anholt: robclark --^
22:35 robclark: hmm, that is new
22:37 anholt: yeah, new to me
22:39 robclark: I have to think somehow some memory corruption..
22:40 robclark: or something not great about memory map, and we think some thing is normal pages when it isn't..
22:43 jenatali: Awesome
22:47 robclark: jenatali: add it to the tracker.. I can see if we see it showing up in any of our crash reporting.. (unfortunately the hw we have in the CI farm is, for now, an older and not really well supported thing, until we have a chance to replace those boards.. which means stuck on some half-baked/unsupported fw, etc)
22:50 robclark: anholt: btw, https://patchwork.freedesktop.org/series/81979/ is probably a good thing to get into cheza kernel.. although from that log I'm not seeing indication of shrinker kicking in.. although maybe we already have the patch that converts that to a tracepoint
22:50 robclark: that is the closest thing I can think of which might be related
22:50 jenatali: robclark: I see a discussion thread at the bottom with a different Cheza kernel panic - do you want it in the checklist or should I just add it to that thread?
22:51 anholt: new comment thread for a first instance of the thing would be nice
22:52 jenatali: Sounds good
22:59 robclark: so, async SError.. that is usually someone accessing some unclocked hw block.. and it is async so it could really have nothing to do with the call stack