02:45HdkR: Hm, Ice Lake not clocking up issue has happened again. Only 1 day 4 hours uptime
03:03airlied_: jekstrand: is there a vulkan version of ARB_compute_variable_group_size.txt
03:03airlied_: (without the .txt)
03:04airlied_: oh maybe I can use specialisation consts
03:05airlied_: hey it even says that in the spec :-P
03:05jekstrand: airlied_: Not yet, no
03:06airlied_: it does mean I have to mangle the spir-v en route though
08:58udovdh: what is wrong when video playback (mpv, vlc, mplayer etc) all display video shifted down and to the right in a window and fullscreen?
08:58udovdh: I see a larger black band at the top of the window and also in fullscreen
08:58udovdh: we cannot see the bottom portion of the video
08:58udovdh: youtube does not suffer from this.
08:58udovdh: where is the problem and how can I fix this?
09:01udovdh: what is wrong when video playback (mpv, vlc, mplayer etc) all display video shifted down and to the right in a window and fullscreen?
09:01MrCooper: robclark: the additional RADV jobs cannot run for MRs because there are no shared runners for them yet
09:15udovdh: restart of Xorg did not help
09:15udovdh: reboot did not help
09:22udovdh: How do I get video playback back to normal?
09:42udovdh: changing the xrander scaling does not help
09:42udovdh: also [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,(etc) still happens on 5.6.x
09:43udovdh: the video playback issue is of higher priority though
09:50udovdh: cd /usr/src/mesa
09:51pepp: udovdh: is this using hw-accelerated video decoding? can you open a bug report for this?
09:52udovdh: pepp, I do not know (yet) if that is using accelerated video decoding. I will first try to go back a few commits to confirm it is mesa as a source for the issue
09:53udovdh: went back to 9f8089139f1be6f30628fad033d87fdb8c804f80 as a test and yes the video now looks normally centered vertically
09:54udovdh: how to proceed from here?
09:56udovdh: when looking at vlc settings VDPau appears to be used
09:56udovdh: pepp is that the acceleration confirmation?
09:58udovdh: which bugzilla to enter a bug in?
09:58pepp: udovdh: if switching to an older Mesa fixes the bug then opening a Mesa issue makes sense. Also I'd suggest using "mpv -v ..." for your tests since it logs which decoder is used.
09:58pepp: udovdh: https://gitlab.freedesktop.org/mesa/mesa/issues/
10:08udovdh: pepp https://gitlab.freedesktop.org/mesa/mesa/-/issues/2989
10:11udovdh: any details I should add?
10:18pepp: udovdh: this is a recent regression. You could try doing a "git bisect" to identify the problematic commit. You can also try reverting 494b7ef0c1a440c57f5a6a8a301fba4f7e551417
10:18udovdh: will try!
10:20udovdh: using the revert things appear to work OK.... (simply rebuilt mesa, installed mesa, restarted playback)
11:00udovdh: pepp thanks for the help!
13:28emersion: is it valid to set ACTIVE to 0 while keeping MODE_ID and CRTC_ID set to non-zero?
13:28emersion: in other words: why does ACTIVE exist?
13:33vsyrjala: replacement for dpms
13:34emersion: why not just make user-space set MODE_ID=0?
13:34emersion: does it make sense to set ACTIVE=0 and MODE_ID!=0?
13:35emersion: it appears to EINVAL on my system
13:36vsyrjala: it should work
13:36emersion: lemme try on intel
13:36emersion: well, does it provide any benefit?
13:36emersion: should i ALLOW_MODESET when changing ACTIVE only?
13:37vsyrjala: i think the idea (or at least on of them) was that having mode_id/etc.!=0 would still make sure all resources are available. hence more or less guaranteeing that the subsequent active 0->1 transition will not fail
13:37pq: wow, never heard of that before
13:37emersion: does it make the active 0→1 commit faster?
13:38vsyrjala: unfortunately i915 at least doesn't follow that mantra in all cases. so some resources do get allocated effectively based on active 0 vs. 1
13:39emersion: context: right now wlroots and weston keep ACTIVE in sync with MODE_ID and CRTC_ID (ie. either all are set to non-zero, either all are zero)
13:39emersion: i'm wonderign whether it's a good idea to change that
13:39MrCooper: emersion: in theory the BO could have been evicted in the meantime, and pinning it into VRAM again could fail
13:39vsyrjala: atm it the full atomic machinery gets run for every modeset. if we did thing right we could in theory skip all the checks for a pure active 0<->1 transition
13:40vsyrjala: MrCooper: bo(s) could be kept pinned as long as fb!=0
13:41MrCooper: right, I guess I mixed that up
13:42vsyrjala: one case where i'd rather want to skip all the checks is resume. atm if anything has changed during suspend the modeset during resume can fail since it re-checks everything
13:42MrCooper: emersion: getting EINVAL on setting ACTIVE=0 sounds like a bug
13:43emersion: i'll try to draft a patch to document ACTIVE
13:43emersion: (funnily enough, the DPMS prop is documented but ACTIVE isn't)
13:43MrCooper: the DPMS documentation does have something about ACTIVE
13:44vsyrjala: and you can't set the dpms prop via atomic. if you set it via legacy setprop the kernel will try to convert it to active yes vs. no. but i have a feeling that code is not entirely robust
13:44vsyrjala: so might result in some funny state if you do some kind of partial dpms things
13:45emersion: right, we don't set DPMS at all when using atomic
13:46emersion: i kind of hoped it would be possible to set active 0→1 without doing a (long) modeset
13:47MrCooper: it should be, but note that e.g. amdgpu will return EINVAL if the primary plane is disabled (e.g. because the FB assigned to it was destroyed)
13:47MrCooper: (and the cursor plane is enabled)
13:48emersion: yeah, i've tried keeping all planes enabled
13:49emersion: basically just changing ACTIVE
13:52emersion: ahah, ACTIVE isn't documented because there are no CRTC prop docs
13:53emersion: danvet: should i add a "standard CRTC properties" section?
14:05pq: What exactly triggers fbcon to reset KMS state after some KMS using program? Is it enough to close the device? Or does it require VT ioctl poking? What if you never told VT to go into GD_GRAPHICS?
14:14vsyrjala: iirc drm_fb_helper has some hacks to stop it from doing things when there's some kms thing active
14:14vsyrjala: hmm. that may have gotted cleanup a bit with the drm_client stuff
14:15pq: I'm reviewing a very simple atomic KMS example which does not bother touching the VT state. I'm wondering if fbcon should somehow magically clean up after the program quits, or does it need to do something to restore fbcon.
14:16vsyrjala: looks like having a drm master turns the fb_helper hooks into nops mostly. but they still get called i think, and also the console will still get drawn into whatever memory was handed to fbdev
14:16vsyrjala: i think
14:16vsyrjala: when the master goes away those should become not nops again
14:16pq: but does fbcon e.g. restore the fbcon FB to KMS, too?
14:17pq: maybe modeset to what it used to have as a mode?
14:17vsyrjala: the fb helper should restore things back to the proper state next time it gets called
14:17vsyrjala: when it gets called not entirely sure. i guess whenever fbcon does more or less anything
14:18pq: cool, it's just a matter of getting anything printed on the VT?
14:20danvet: emersion, sounds like a good idea
14:21vsyrjala: pq: yeah maybe. never really looked at the fbcon code in details so not really sure when it does the set_par & oc.
14:23emersion: okay, just sent a patch
14:27danvet: pq, it might not be wired up on all drivers
14:27danvet: there's a lastclose hook to put in place to get the restoring behaviour on closing the last drm master
14:28danvet: but with the drm_client based fbdev helpers that should happen by default now
14:28danvet: also fbdev overall is blocked on drm master being present like vsyrjala pointed out
14:28danvet: fbcon furthermore is blocked when the current VT is in KD_GRAPHICS mode
14:28pq: danvet, would missing that be something to report as a bug?
14:28danvet: well, if you can get someone to care enough to type the patch :-)
14:29pq: TL;DR: yes, just closing the DRM device should be enough if opening it is all you ever did.
14:29pq: (but might not in practise)
14:34danvet: pq, btw is this a general question or specific drm driver?
14:34pq: general question
14:34danvet: ok not going to review all the kms drivers quickly to check which (if any) are broken :-)
14:35pq: oh, no, please don't :-)
17:59karolherbst: jekstrand: I am wondering.. maybe we should call the structurizer from within spirv_to_nir? that at least would make sure that all users of unstructured spirvs get a structured nir and we could even fail compilation if the structurizer fails
18:02karolherbst: then maybe I can even get rid of the additional argument and make it soley depend on the execution model being kernel or not
18:14pmoreau: EdB: Well done regarding those tests! I’ll have another look at your series this evening.
18:48daniels: karolherbst: that could be a good idea and contain the damage - also having it conditional on being CL?
18:49karolherbst: daniels: well, kernel spir-vs are not legal with OpenGL or Vulkan
18:49karolherbst: I think we even validate this.. let me see
18:49daniels: right, I mean a spv kernel
18:50daniels: i.e. it won't run for gfx shader stages
18:50karolherbst: only the real kernels
18:52karolherbst: daniels: but I think you could add a spir-v kernel into vulkan/gl and this would go through... not 100% sure :p, but maybe we don't care about this... anyway
18:52karolherbst: only the ones which have SpvExecutionModelKernel
18:52karolherbst: and this is sadly per function
18:54karolherbst: or check if the kernel capability is set...
19:09airlied_: karolherbst: I think doing it in spirv->nir is a good plan
19:10karolherbst: yeah.. this way we can also ignore nir_validate :p
19:59EdB: pmoreau: thanks, I've also fix the callback on program compilation not been trigger
20:00EdB: and some other stuff I found will running the whole CTS
20:01EdB: there is still failling tests however
20:04EdB: some test just hang for ever :/
20:14pmoreau: EdB: Yes I saw the callback fix, nice catch!
20:15pmoreau: Sorry something came up so I didn’t had as much time as expected to look through it. Hopefully I should have more time tomorrow, or at least during the weekend.
20:22airlied_:wonders what I've done to deserve a full arm kernel rebuild in my MR :-P
20:25airlied_:also wonders why that kernel build is building a bunch of audio drivers :-P
20:30anholt_: airlied_: I think the answer is "won the race against the master branch build that tries to copy the container image tag"
20:33airlied_: anholt_: yeah looks like it, 31 mins later still chugging through vk-gl-cts :-P
20:37anholt_: I'm not sure if the collabora/baylibre lava labs are x86 or arm runners, but I would bet x86 and if so we should probably ditch the lava rootfses in the arm_build container and just use the x86 one I introduced for lava.
20:38anholt_: these arm testing container builds suck, I've been punting on lots of CI work because it's so miserable. now that I've got x86 images I can at least iterate containers on a beefy system.
20:40daniels: the lava labs are arm
20:41daniels: the ARM builders are pretty underutilised and also stupid wide in terms of number of cores, so I'd be interested to experiment and see if we get faster builds with -j$lots
20:41daniels: well, Collabora's lab is Arm. BayLibre's I understand is x86 but running qemu to fake arm.
20:41anholt_: daniels: we could definitely use the cpu in the builds, it's ninja and kernel builds that are the time spent.
20:42anholt_: if we can get concurrency on the arm builders cranked down, I'm happy to see the jobs tuned up in -j.
20:42daniels: honestly I'm pretty sure you could push it to like -j16
20:42anholt_: do we have the memory to support everyone at -j16?
20:43anholt_: (this part of managing gitlab-runner docker tuning suuuuucks)
20:43EdB: pmoreau: not problem, there is still fix to maka :D
20:43EdB: *to make
20:44daniels: anholt_: 128GB across 32 cores
20:44daniels: right now the concurrency is really really wide, but we don't see many concurrent jobs
20:45daniels: hmm actually, concurrent is only at 4
20:46daniels: so I think you could very definitely launch some test jobs at -j16, and if they help runtime, we could move to concurrent == 2 (with two separate runners); the reduction in execution time should more than compensate for the reduction in theoretical parallelism
20:50airlied_: anholt_: I think something might be going wrong here, it's building a kernel again
20:50airlied_: about to run into the 1h timroue
20:50daniels: it builds two kernels: one for armhf, and one for aarch64
20:51airlied_: okay well it won't do that in < 1h I don't think
20:51airlied_: mabye it'll just make it
20:52daniels: it generally manages to; our builds don't usually fail
22:11anholt_: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/2730277 well it was close!
22:13airlied_: anholt_: cutting it fine :-P
22:14anholt_: yeah, ugh.
22:14anholt_: now that ccache is used more, it should at least be less of a pain when we lose the race.
22:21karolherbst: btw.. what do I have to do to get a new libdrm release?
22:23airlied_: karolherbst: release it :-P
22:24karolherbst: airlied_: just push a tag or do I have to do more?
22:24bnieuwenhuizen: get xorg permissions to push the new tarball to the archive?
22:24airlied_: karolherbst: there's a RELEASING File
22:24karolherbst: totally missed that file
22:25karolherbst: I was searching for that actually...
22:25airlied_: bnieuwenhuizen: i think the mesa group is all you need for libdrm
22:26airlied_: which karolherbst seems to be in
22:26karolherbst: I just hope nobody whoops in and complains about missing signatures or stuff like that :p