00:02 imirkin_: ajax: right, it has to get from the internal representation to the on-the-wire data somehow. on nvidia, the mechansim behind this is configurable -- can dither either statically or temporally, or just cut bits off
00:13 Kayden: CI seems to be stuck on a few things...
00:14 Kayden: https://gitlab.freedesktop.org/kwg/mesa/pipelines/166429
00:14 Kayden: tried it twice, both lima jobs and panfrost t820 seem AFK
00:15 Kayden: am not sure what to do about that
00:20 airlied: Kayden: normally disable them temporarily
01:25 mareko: mediump isn't lowered with control flow, because it doesn't lower GLSL IR temps, only expressions, sigh
01:30 robclark: oh, is that why things caught up in phi webs tend to not be lowered?
02:12 mareko: robclark: yes, ?: is control flow too
02:17 mareko: there is so much work left to do for mediump that I'm not even too interested in enabling it for radeonsi
02:23 mareko: SPECviewperf stuff likely to have a higher priority for me
02:25 robclark: I guess ?: normally gets lowered to csel? I know there is still some room for improvement on phi stuff, although that hasn't been highest priority yet as far as benchmarks we are looking at.
02:25 mareko: robclark: in GLSL IR, ?: is if-then-else
02:25 Kayden: Yeah, because things might have side effects
02:25 Kayden: we could use csel if they don't
02:25 Kayden: I had a patch to do that like 8 years ago, but we never bothered because it'd get cleaned up later anyway
02:27 robclark: it seems to *mostly* end up in csel.. mostly what I'm looking at these days in the fps wars (since pretty much all play store games are doing fine) is gfxbench.. and there before mh31 I'm not seeing much frag shaders with flow control..
02:27 robclark: mh31 and above has some, but there the low hanging fruit atm looks like teaching our ubo lowering about indirect ubo access
02:29 Kayden: daniels, tomeu, others: I'm disabling Panfrost T820 and Lima 400/450 as the runners seem to be totally out to lunch. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5619
02:29 Kayden: just a heads up so that you can get it turned back on
02:31 robclark: Kayden: tag them in the MR and land it.. I think that is the standard procedure
02:32 Kayden: cool. I tagged daniels
03:09 Kayden: gah
03:09 Kayden: now it's failing elsewhere
03:13 Kayden: ok, that seemd transitory, I think it'll work this time ...
03:17 robclark: Kayden: if you get "gitlab rejected branch" type message, immediately re-assign to marge (if you get in there before marge picks up another MR it seems to always go thru immediately the 2nd time).. not sure if that is what you hit
03:23 jekstrand: Marge kicked it out again. But I just clicked "merge when pipeline succeeds" so if no one touches it, I think it'll merge in a couple minutes.
03:24 jekstrand: Kayden: merged.
03:25 jekstrand: And, aparently, made marge angry....
03:25 jekstrand: Oh, well. Marge can get over it. We needed to land that revert.
03:29 Kayden: Yeah... I kept trying
03:29 Kayden: I think it was about to work this time
03:31 airlied: we should write a bot to feed the bot
03:52 jekstrand: airlied: 😡
03:52 jekstrand: airlied: Marge is supposed to be that bot. We have a "merge when pipeline succeeds" bot that's built into GitLab. Marge is the bot that feeds that bot. If you're suggesting we need a third turtle in the chain.....
03:54 Sachiel: we need at least four turtles
03:54 Sachiel: and they need to be ninja
03:57 airlied: I support the use of ninja turtles
03:58 airlied: jekstrand: yeah maybe marge needs an option to try 3 times until gitlab is fixed
03:59 ccr: bots all the way down.
03:59 robclark: yeah, marge retrying a couple/few times would be a useful improvement..
05:28 danvet: airlied, uh did you see sfr's report?
05:45 airlied: danvet: wierd I'm pretty sure I put that patch in ther merge
05:45 airlied: gonna guessI forgot to actually git commit
05:47 airlied: doh, force push ftw
05:53 danvet: airlied, :-)
06:17 tomeu: anholt_: I'm planning to move the rootfs and kernel builds out of arm_build and into a new job that would build those for armhf, arm64 and x86
06:18 tomeu: the idea is for the artifacts to be uploaded to minio
06:21 tomeu: then each lab can have a minio cache to speed things up
06:21 tomeu: anholt_: guess baremetal could use the same?
07:05 MrCooper: Lyude: since they're only called from the DRM_IOCTL_MODESET_CTL ioctl (which is only used by UMS userspace BTW), maybe that's considered to provide sufficient locking?
07:25 danvet: mripard, [PATCH 5/8] drm/vc4: Use __drm_atomic_helper_crtc_reset <- pls review
09:04 mripard: danvet: done :)
09:04 danvet: thx
09:04 danvet: mripard, first patch in series maybe too if you're bored?
09:05 danvet: that's kinda the motivation for the entire thing
09:20 danvet: MrCooper, do you have time to review "drm/fb-helper: Fix vt restore"?
09:24 MrCooper: I'll try, but can't make any promises as to when I'll get a chance
09:29 danvet: MrCooper, thx
09:29 danvet: hm maybe also ping for hwentlan or agd5f since the regression is against -amdgpu ddx
09:29 danvet: no idea whether I broke other stuff too
09:30 ickle: https://gitlab.freedesktop.org/drm/intel/-/issues/2027
09:32 MrCooper: danvet: what I've seen so far sounded like it should be Xorg in general, not driver specific
09:32 danvet: yeah I think its in the generic code
09:34 danvet: ickle, that one sounds different
09:34 danvet: but maybe it's the same
09:40 MrCooper: danvet: would it be possible to do it when master is dropped instead? Though I guess it might not make any difference while there's no atomic master handover
09:41 danvet: MrCooper, I kinda didn't want to roll out the entire scaffolding to make it possible at drop_master
09:42 danvet: I also just noticed from more digging that we never had any checks in set_par
09:42 danvet: just relying on KD_GRAPHICS mode and fbdev userspace not being nasty
09:43 danvet: all the othe entry points had checks since forever
09:43 danvet: so there might be more surprises, and if we're unlucky the uapi is actually "fbdev can always do a modeset over native kms client" :-/
09:45 MrCooper: seems clear to me that set_par should only have an effect while the fbdev fb is scanned out
09:45 danvet: yeah but we never enforced that I think
09:45 MrCooper: fun :)
09:46 danvet: also the "are we being scanned out" check is very inaccurate, which is why I'd like the drm masta one much more
09:46 danvet: e.g. we had bugs where Xorg did all dpms off
09:46 danvet: and then fbcon did a dpms on and figured hey this is all mine now
09:46 danvet: or we had cases where Xorg left some overlay behind, and then fbcon thought "uh still in use"
09:47 danvet: there's also the startup race when Xorg tries to do a smooth takeover from whatever boot-up splash there was (which could be fbcon)
09:57 melissawen: Hi mlankhost, I was taking a look at the function igt_put_cairo_ctx in IGT (lib/igt_fb.c). It has three parameters, but it looks like only one (cairo_t *cr) seems to be used.
09:57 melissawen: So, I saw that your commit added this function, and I wanted to know if there is some reason for these two extra parameters to be there that I am not seeing.
10:47 MrCooper: danvet: anyway your patch sounds good, but I'm not deep enough into that code to certify it actually does what it says on the tin :)
10:49 danvet: MrCooper, appreciated and I understand that enthusiasm to work out how vt code works is limited :-)
11:26 thaytan: Why would PSR be disabled OOTB on this new x360?
11:26 thaytan: Sink support: yes [0x01]
11:26 thaytan: PSR mode: disabled
11:26 thaytan: PSR sink not reliable: no
13:10 kusma: Hmm, master doesn't compile for me... I'm getting a problem compiling RADV: src/amd/vulkan/gfx10_format_table.h:5:53: error: VK_FORMAT_RANGE_SIZE undeclared here (not in a function); did you mean VK_FORMAT_R8G8_SINT
13:12 bnieuwenhuizen: kusma: remove ${BUILDDIR}/src/amd/vulkan/gfx10_format_table.h and rebuild
13:15 kusma: bnieuwenhuizen: OK, that did the trick. But what gives here, why did this change? Are we missing a dependency on the generator-script perhaps?
13:18 kusma: I even tried "ninja clean" first, *shrug*
13:18 bnieuwenhuizen: kusma: generated file moved but the old file is getting picked up
13:19 kusma: bnieuwenhuizen: actually, it just took a bit longer, but now I got the same error.
13:19 bnieuwenhuizen: Which won't get removed by ninja clean because after the update it is not in the meson files anymore
13:19 bnieuwenhuizen: Still radv or is it radeonsi now?
13:19 orbea: could use git clean -xdf as a workaround.
13:20 kusma: Ah, no. Not same, just similar for some other generated file
13:20 kusma: orbea: I don't build in-tree
13:20 orbea: nvm :)
13:20 kusma: bnieuwenhuizen: yeah, radeonsi
13:22 kusma: bnieuwenhuizen: OK, I think I understand. To bad it's not an easy way to fix things like this, I bet this affected a lot of people.
14:10 MrCooper: kusma: always running ninja clean before checking out a different Git commit can avoid issues like this
14:18 kusma: MrCooper: Yeah, if I want to melt the polar caps faster than we already do ;-)
14:19 MrCooper: that's what ccache is for :)
14:24 agd5f: danvet, I read it over yesterday. looks good to me, but wanted to give it a closer look today.
14:31 danvet: agd5f, thx
15:22 hakzsam: daniels: https://gitlab.freedesktop.org/pendingchaos/mesa/-/jobs/3275620
15:22 hakzsam: disk is full :)
15:29 daniels: god I can't wait to replace that machine
15:29 daniels: hopefully in the next week or two \o/
15:31 hakzsam: nice :)
18:41 Lyude: danvet: think we could actually just get rid of ->pending from drm_vblank_work and make the wait_event() condition for flushing just a read barrier + list_empty()?
18:45 danvet: Lyude, not sure the list_empty works
18:45 danvet: might be better to just take the spinlock
18:45 Lyude: makes sense
18:45 danvet: iirc there's a wait_event variant for that already which grabs the spinlock for you around the (re)checking of the condition
18:45 Lyude: mhm-wait_event_lock_irq
19:35 danvet: mripard, mlankhorst there's a pile of -fixes queued up, pls help me remind tzimmermann to do the pull request tomorrow to get them out
19:35 danvet: I just pust a regression fix on top
19:35 danvet: probably should have landed in -rc2, not sure why not
20:55 Lyude: Anyone know what the license for drm_vblank.c would be? wondering for the SPDX identifiers I'm putting into the new drm_vblank_work.[ch] files
20:59 vsyrjala: should be mit
21:17 mdnavare: hwentlan: Do you ack on merging the vrr debugfs amd patch r-bed by Nicholas through drm-misc along with the drm core patch that it depends on
21:34 hwentlan: mdnavare: ack
21:44 Tom^: hi i stumbled on this page https://docs.mesa3d.org/perf.html how actual is 5. and if so how do i apply "-lXext to XLIBS" now when its using ninja? adding -DSHM to cflags i get, but not -lXext
21:44 airlied: Tom^: that page is all out of date
21:44 mattst88: I got a bug report about that in Gentoo recently
21:45 Tom^: airlied: yeah suspected as much
21:45 airlied: are you truing to get better sw rendering performance?
21:45 mattst88: I told the reporter that I thought that was super out of date, and that I didn't see any evidence that linking libX11 with -lXext or compiling with -DSHM would do anything
21:46 Tom^: airlied: not really no, if thats the only thing it would help with i got no need for it :p , using intel atm and soon a amdgpu card in a egpu setup
21:47 airlied: the top of that page says "for software rendering"
21:47 Tom^: oh i missed that fact lol
21:55 airlied: Tom^: we aren't in the habit of hiding perf enhancements behind magic
21:56 airlied: most perf increaes require profiling and code writing
21:57 ccr: what? I've been doing arcane gestures and dancing around to appease the dark gods to make my Haswell faster .. and it's been all for nothing? :O
21:58 Sachiel: no, mesa needs profiling, hw needs black magic
22:00 kisak: isn't LTO + PGO without actually knowing what you're doing exactly that? magic
22:02 airlied: kisak: pretty much, and pointless
22:06 HdkR: LTO can at least save your from some bad helper designs which I've seen in a lot of places
22:07 HdkR: save you*
22:08 HdkR: Personal favourite are the helpers that either load a variable or return a constant in a release build but something else under debug. Don't get saved from the function call in bad designs :)
22:08 jenatali: Can someone explain to me what the 'exact' bit in an alu instruction is supposed to convey and where it comes from? jekstrand maybe?
22:10 mdnavare: hwentlan: Thanks Harry
22:43 kisak: jenatali: I believe it's to tell the shader compiler that it's not allowed to use fast, lower precision substitutes for the particular instruction (not very familular with it myself)
22:43 jenatali: kisak: Yeah that makes sense. I'm just very confused as to where it's supposed to come from
22:52 mdnavare: hwentlan: agd5f_: Actually hitting a merge conflict while merging through drm-misc-next, which i dont see when i pull in the patch in drm-tip, can i manually resolve the conflict in amdgpu/display and amend before merging?
22:59 pendingchaos: jenatali: it means that the instruction can't be replaced with something which doesn't give the exact same result (even if it's higher precision)
22:59 pendingchaos: it comes from glsl's invarant/precise keywords (and the similar things in spir-v)
23:00 mdnavare: hwentlan: agd5f_: This patch: https://patchwork.freedesktop.org/patch/372868/?series=78671&rev=2 is a revert so I think we need to merge through amdgpu tree
23:00 jenatali: Ah, I see it now, thanks pendingchaos
23:00 mdnavare: hwentlan: I can merge the core drm patch through drm-misc and then can you aor any of AMD folks merge the revert patch through amdgpu
23:02 hwentlan: mdnavare: if the conflict is trivial might be easier to take them all through drm-misc
23:02 hwentlan: If it isn't we can take the revert in amd-stg once we rebase
23:12 mdnavare: hwentlan: so even its a revert of a SHA from amdgpu tree, i can apply it in drm-misc?
23:16 mdnavare: hwentlan: any will check the conflicts
23:22 mdnavare: hwentlan: okay i see the prob is that the amdgpu tree in drm-tip has more hdcp related changes and the revert patch takes those into account but they are not pulled into the drm-misc tree yet
23:24 Lyude: anholt_: ended up needing a lot of time to finish up the nouveau crc stuff today, but I haven't forgotten about the bl stuff. probably can start on it tommorrow, as i'm going off work now