03:12 clever: i suspect a large chunk of the game was in GTT and wasnt moving back upon closing chrome, will need to analyze amdgpu_gem_info more
04:34 tarceri: mareko: well it should be but it been talked about before and never implemented
08:49 javierm: tzimmermann: where are still discussing the bug for SDDM and missing simpledrm with "nomodeset" due a VESA mode not being set
08:50 javierm: tzimmermann: how do you handle that in OpenSUSE? I think you use SDDM/KDE too?
08:50 tzimmermann: javierm, ?
08:50 clever: [ 14.628] (EE) AMDGPU(0): amdgpu_device_initialize failed
08:50 clever: well, my gpu seems half dead
08:50 javierm: tzimmermann: https://bugzilla.redhat.com/show_bug.cgi?id=2176782, the one that we discussed last week I think
08:51 javierm: in theory grub should be able to pass a mode with gfxpayload=keep and gfxmode but at least I wasn't able to make it work with fedora's grub
08:52 javierm: it's heavily patched though like all the grub packages so maybe there's some regression there...
08:54 javierm: although that wouldn't work on the syslinux / live media case
08:54 tzimmermann: javierm, our grub config sets graphics mode
08:54 javierm: tzimmermann: so probably a regression in fedora's grub then
08:54 tzimmermann: IIRC GRUB_TERMINAL=gfxterm
08:55 javierm: but that wouldn't help in your install media that boots using syslinux right ?
08:55 tzimmermann: it sounds as if your grub runs in va text mode. don't expect vesa then
08:55 tzimmermann: our syslinux also uses graphics by default
08:56 tzimmermann: or it gives an option to select a graphics mode
08:56 javierm: tzimmermann: yes, but I tried with GRUB_TERMINAL=gfxterm too and it didn't work either
08:56 javierm: also doing insmod vbe, setting a gfxmode, etc
08:56 javierm: tzimmermann: anyways, you are relying on grub to set the mode then and it works. That explains why is not an issue for your
08:56 javierm: *you
08:57 javierm: normal fedora workstation images use Gnome and GDM fallbacks to X11 that uses the vesa DDX so that works too
08:57 tzimmermann: the bootloader: grub/syslinux
08:57 javierm: but it seems SDDM/KDE doesn't fallback to X11 when using wayland and that's how this bug is triggered
08:57 tzimmermann: as dicussed in the bugreport, maybe enable graphics by default.
08:58 tzimmermann: i don't know the internals of syslinux, but there is a way of setting the display mode or setting vga=
08:59 javierm: tzimmermann: problem with vga= is that it seems the modes are not consistent accross machines
08:59 javierm: at least according to fedora QA vga=ask list different numbers for the same modes
09:00 tzimmermann: javierm, maybe thesemodes have different timings?
09:00 javierm: hmm, it seems that's only for 32-bit palette but 16-bit and 24-bit are "standard" modes and those are the same on all BIOS
09:01 javierm: not really that familiar with VESA and VBE :)
09:01 javierm: tzimmermann: but all this shows me that maybe there's a need for a vesadrm driver that could expose the supported modes and let user-space set one
09:02 tzimmermann: see http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf on page 18
09:02 tzimmermann: 32-bit vesa is dead
09:03 javierm: tzimmermann: got it
09:03 tzimmermann: javierm, how did it work with efifb?
09:04 javierm: tzimmermann: for efifb it works because the EFI stub uses the EFI-GOP runtime service to get the resolution and framebuffer
09:04 javierm: and same for simpledrm with EFI
09:04 tzimmermann: sorry i meant vesafb. that problem must have been present before
09:04 javierm: tzimmermann: yes, it never worked for vesafb either
09:05 tzimmermann: and in your bug report, it is said that sddm requires x11
09:05 javierm: tzimmermann: Gnome doesn't have a fbdev wayland backend and SDMM was using X11 before too AFAIU
09:05 tzimmermann: IIRC we can blacklist certain userspace or drivers in opensuse for wayland use
09:06 javierm: so in both cases it was vgacon -> X11 with user-space VESA DDX
09:06 javierm: vesafb was only used with a proper VESA mode (which in fedora was only vga= due grub being boot in text mode)
09:06 tzimmermann: and you cannot go back to this setup for sddm?
09:09 tzimmermann: javierm, the vga= value is 0x200 + the vesa code. so vga=318 should give 1024x768
09:09 javierm: tzimmermann: I'm not familiar with SDDM but for some reasons it seems that does not fallback to X11 when no dri device is found?
09:10 javierm: tzimmermann: ahh, interesting
09:10 tzimmermann: no idea about sddm
09:10 tzimmermann: if you wan tto debug, maybe set up a 32-bit qemu and run the live cd
09:10 javierm: tzimmermann: 32-bit qemu does work
09:11 javierm: tzimmermann: ah, you meant for SDDM? Not really that interested in that part
09:11 tzimmermann: javier, see that pdf under 'VBE mode numbers'
09:11 tzimmermann: and accoring to the linux docs, 0x200 needs to be added
09:12 javierm: tzimmermann: vga=791 (hex 0x317 that is 1024x768x16) does work on all machines it seems
09:12 tzimmermann: ok
09:12 javierm: 117h - 1024x768 64K (5:6:5) in your table
09:12 tzimmermann: maybe i got the syntax wrong
09:13 javierm: tzimmermann: no, you are correct. It's just that vga= for some reasons expect a decimal value why vga=ask list in hex and the table is in hex too
09:13 javierm: consistency ftw :)
09:13 tzimmermann: oh :/
09:13 tzimmermann: that's what i'd tell to users.
09:14 javierm: tzimmermann: anyways, this is very useful info. So I'll suggest them to either 1) just set vga=791 along with nomodeset for this "safe graphics mode" or 2) change the bootloader config to gfxterm and let grub set it
09:14 tzimmermann: or maybe hardcode that vga= resolution. :) if the card doesn't support it, you probably don't want to run kde on it
09:15 javierm: tzimmermann: yeah, that's what I meant by option (1). That the tool doing the install images hardcode that vga= resolution in the "safe graphics mode" boot entry
09:16 javierm: tzimmermann: I'll explore though typing a vesadrm driver, not related to this bug but just for fun and to learn more about VESA and VBE :)
09:16 tzimmermann: one of the problems is that all this vesa stuff has been dead and unmaintained for 20yrs. the vesa pdf is (c) 1998. supporting it is really best-effort at this point.
09:17 javierm: tzimmermann: yeah, but still we have some level of support with this vga= param
09:17 javierm: so my idea was just to use that mode get/set logic for a vesadrm
09:18 javierm: or do you think is not really worth the effort?
09:18 tzimmermann: is that possible from within the kernel?
09:23 tzimmermann: javierm, i'm scrolling over uvesafb, which delegates all VBE interactions to the userspace tool. i can't say for sure, but i assume it does this for a reason. https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/uvesafb.c
09:24 javierm: tzimmermann: https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/uvesafb.c#L112
09:24 javierm: this is horrible :)
09:24 javierm: https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/uvesafb.c#L37
09:28 tzimmermann: all hardcoded
09:29 javierm: but also a kernel driver calling a user-space program seems risky
09:29 javierm: so yeah, probably we want to stay away from anything related to VESA and VBE
09:36 javierm: tzimmermann: it seems you are correct and vesa modes can't be changed once in protected mode
09:37 javierm: there seems that VBE 2.0 has support but isn't well documented as you said and no BIOS really implement it
09:37 javierm: tzimmermann: anyways, I'll suggest them setting a vga= and call it a day :)
10:17 vliaskov: When using virtio or qxl driver in a VM and the display is flipped, the cursor is not drawn in the correct coordinates (https://gitlab.gnome.org/GNOME/mutter/-/issues/2692). Happens on both gnome and kde. Is it reasonable to view this as a driver issue? Is there a recommended way to correctly update cursor coordinates for virt drivers? E.g. with a plane rotation property and a relevant drm helper function?
10:32 jadahl: vliaskov: arguably one shouldn't need to special case virt drivers
10:35 mohamexiety: does deqp-runner allow choosing a particular device to run on?
10:55 mohamexiety: yep, through --deqp-vk-device-id. my bad.
12:01 koike: Hi zmike, I was checking with DavidHeidelberg[m] regarding this discussion https://oftc.irclog.whitequark.org/dri-devel/2023-03-21 . You mentioned those weren't flakes, but I noticed on every zink-freedreno-a630-traces job reported as flake, there is a passing job on the same commit. For instance this one:
12:01 koike: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/38428751 there is a passing job on the same commit, so it is classified as flake (since there is a failing and a passing job without any changes on the code). Am I missing something?
12:04 Hazematman: Hello, I'm hoping to get some feedback for an MR I opened a couple weeks back, specifically on the Nouveau, tegra, virgl, and svga changes https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21654
12:04 Hazematman: If developers on those drivers are able to review my changes (its only a couple lines per driver to add a common feature to every gallium driver) I would greatly appreciate it!
12:24 ice9: some apps fail to work throwing this error: libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
12:52 zmike: koike: it looks to me like this is a godot trace timeout. the discussion you're referencing was about source games
13:31 tlwoerner: ... and binhani is gone
13:35 koike: zmike right. The report is getting all the pipelines that were assigned to Marge, even if it didn't get merged, so probably those are errors from previous versions of the code on a MR.
13:35 zmike: yes probably
13:36 DavidHeidelberg[m]: btw. looking into the pipelines, these succeeded
13:36 DavidHeidelberg[m]: The flakes Valve flakes aren't related only to your MR and the runs are final.
13:37 DavidHeidelberg[m]: (Valve+Godot TPS)
13:37 DavidHeidelberg[m]: for example: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/38420244
13:37 zmike: yeah they were deadlocking during the initial runs
13:38 zmike: I had to fix some issues
13:39 koike: DavidHeidelberg[m]: fyi, this is the MR from the error I pointed above https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22025 , there are multiple runs from Marge. let's see if I can improve the report so we remove this false positives
13:43 DavidHeidelberg[m]: zmike: ok, I understand :) thanks
13:49 DavidHeidelberg[m]: zmike: btw. PenumbraOverture started crashing frequently on zink, are you aware? should I create an issue?
13:50 zmike: yes, I think it should be resolved by !22054
13:51 DavidHeidelberg[m]: hehe, the most important job to test is in "pending" state :D
13:51 zmike: surely one day it will run
13:52 DavidHeidelberg[m]: He found the secret how to make the job run. You won't believed!
13:52 zmike: CI experts HATE this one weird trick!
13:52 DavidHeidelberg[m]: :D better
13:52 DavidHeidelberg[m]: (it's the GitLab bug you have to retry any job from same farm, and GL starts sending jobs to the runners again)
13:53 zmike: incredible
13:53 DavidHeidelberg[m]:want to say disclaimer: it's not our CI bug :D
14:20 jenatali: So I was trying to use ci_run_and_monitor.py last night and wasn't able to find an environment where I could get it to work
14:20 jenatali: What Python version are people normally running that with?
14:25 daniels: jenatali: oh ... I've just realised your mistake - pip3 install --user python-gitlab, not just 'gitlab'
14:25 daniels: (personally I'm on Python 3.11 but I've never had a problem with the gitlab module not working on anything for the last 5-6 years)
14:26 jenatali: Oh, obviously (sarcasm). But seriously, thanks I'll try it out
14:26 jenatali: I just assumed that import gitlab meant I needed a package named gitlab
14:33 daniels: yeah, that's a reasonable assumption, but also not true for pypi
14:37 jenatali: daniels: Was there a piece of documentation I missed that said that btw?
14:40 daniels: jenatali: errr ... IRC backlog?
14:41 jenatali: Heh, got it
14:41 jenatali: Could be worth a comment at the top of the script to call out which packages are needed for deps at least
14:42 daniels: DavidHeidelberg[m]: ^
14:48 DavidHeidelberg[m]: Hmm, I had this idea, but it was transferred to `requirements.txt`
14:52 DavidHeidelberg[m]: It's not that intuitive, but in Python world it is kinda default
14:55 jenatali: Yeah but for people running the script rather than authoring it, they might not be familiar with the Python world
15:07 danylo: Could someone review the changes to common VK code from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21931 ? TLDR: In turnip we want to make vk common code to work nice with c++, there are a few trivial changes and two bigger ones: "vk/util: Generate defines to help casting structs with vk_find_struct" and "vk/entry_points: Add option to generate template entrypoints"
15:08 jenatali: Danylo: I looked at most of it and was happy with it, especially the casting, but I didn't follow the template entrypoint bits... I should take another look
15:09 danylo: thanks!
16:22 DavidHeidelberg[m]: jenatali: I'm aware, maybe there could be mention of `requirements.txt` in the header?
16:29 jenatali: David Heidelberg: Sounds like a good idea to me
16:53 tjaalton: any idea about the progress of mesa 23.0.1?
16:54 tjaalton: new stuff keeps getting added to staging
16:54 tjaalton: and it's been four weeks since 23.0.0 already..
17:04 pepp: MrCooper: do you have a link to the dri3 patches you mentionned yesterday please?
17:22 MrCooper: pepp: err, can you remind me where I mentioned something about DRI3 patches? :)
17:41 pepp: MrCooper: yesterday morning "that is because the DRM file descriptor for DRI3 clients is opened by X, there are pending patches which will name the DRI3 clients instead"
17:42 MrCooper: ah, that's kernel patches actually
17:45 MrCooper: pepp: https://patchwork.freedesktop.org/patch/526751/
17:46 pepp: MrCooper: thanks!
18:12 jenatali: David Heidelberg: Looks like gitlab_gql.py can't handle Python 3.8?
18:13 jenatali: Traceback (most recent call last):... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/pDKYaLUNXNdVRTOAcGcgdtHA>)
18:13 DavidHeidelberg[m]: jenatali: not sure if anyone tested with 3.8 :( Can you try with more recent Python?
18:13 jenatali: Yeah lemme update
18:27 jenatali: sigh and now aiohttp won't build?
18:31 jenatali: Yeah looks like the locked-in versions from requirements.txt don't build with Python 3.11 on Windows at least. Fun
18:37 jenatali: Finally got it to work. It's pretty slick. Way too much effort though :(
18:42 DavidHeidelberg[m]: extra advertising for the ci_run_n_monitor: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22078
19:55 anholt_: tarceri: unfortunately, removing vector-indexing lowering in GLSL proved to be full of sharp corners. https://gitlab.freedesktop.org/anholt/mesa/-/commits/glsl-vec-index
19:57 anholt_: if we relaxed nir_var_vec_indexable_modes that would make some of it easier. not sure what to do about that tcs fail, though.
22:54 tarceri: anholt_: yeah I hadn't looked at that one yet because it looked tricky :P
22:55 anholt_: deleted 700 lines of other glsl code to console myself.
22:55 tarceri: I'm currently trying to revive my tree height lowering replacement
22:55 anholt_: nice!