05:19 gfxstrand: Something's wrong with Windows CI: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/52085675
05:19 gfxstrand: I'm going to go to bed and hope it's fixed in the morning.
05:54 jenatali: alatiera: ^^
05:56 jenatali: Looks like a disk space issue
07:06 DemiMarie: I noticed that virtio-GPU native contexts still rely on the userspace VMM and asynchronous messaging. Would it be possible to have a synchronous version that instead relied on hypercalls? If so, would this provide any advantages?
07:44 ishitatsuyuki: DemiMarie: iirc the virtio-gpu presentation explicitly mentioned that the async design is to avoid hypercall overhead
07:44 ishitatsuyuki: and it's an OK assumption that submits always succeed or trigger a device loss
07:45 ishitatsuyuki: memory allocation may fail due to insufficient memory, so a hypercall version may allow avoiding overcommit maybe
08:44 DemiMarie: ishitatsuyuki: the latency in the video (millisecond+ IIRC) is completely absurd for a direct hypercall, unless KVM does something silly I’m not aware of. It’s much more consistent with having to go through a queue somewhere. I’m very glad that virtio-GPU native contexts took the approach they did as it makes Xen support much easier, but I am curious why that approach was taken.
09:34 tzimmermann: sima, airlied, could you please update drm-next to 6.3-rc3 ? needed to get 8d6ef26501 ("drm/ast: Disconnect BMC if physical connector is connected") into drm-misc-next
09:36 tzimmermann: javierm, what happened to the double-framebuffer patch?
09:39 javierm: tzimmermann: nothing, the EFI and OF people didn't answer anymore after your comment. I'll ask in that thread again
09:40 tzimmermann: ah, ok
09:40 tzimmermann: javierm, btw i'll wait another day and then land that fbdev fops patchset
09:40 javierm: tzimmermann: sure
10:06 wv: using weston_direct_display_v1 protocol, is there a way to instruct the drm driver where to put the output? I have 2 hardware planes (primary and overlay). Is there a way to know what goes where?
10:57 sima: tzimmermann, compiling now, I'll ping you when it's pushed
11:00 jani: sima: agd5f: there hasn't been a -next pull request for amd yet, has there? I'm just wondering when to do the drm-next -> drm-intel-next backmerge, and iiuc it would be better to hold off until amd has been merged.
11:00 jani: rodrigovivi: the backmerge is actually for you, once we have a go ;)
11:00 sima: jani, I haven't heard anything from agd5f that one is planned ...
11:01 jani: sima: isn't there a conflict still between the branches?
11:01 sima: imo you can backmerge already ...
11:01 sima: jani, should be resolved in drm-next
11:01 jani: mmkay
11:01 sima: if you want paranoid, wait for agd5f to confirm that it's looking ok, but I guess needs a bit more recovery from thanksgiving
11:02 sima: *recovery time
11:24 glehmann: is there a NIR pass that can shrink shared memory arrays by gathering the largest index used?
11:27 glehmann: nir_shrink_vec_array_vars kind of sounds like that but it only allows shader/function temps
11:48 sima: tzimmermann, -rc3 backmerge pushed
11:48 sima: airlied, ^^ fyi
11:48 tzimmermann: sima, thanks
11:48 eric_engestrom: PSA: there is an issue with Marge-bot right now, looks like it's failing on every MR since yesterday
11:49 eric_engestrom: if your MR gets random commits added and then when the pipeline passes Marge fails with "I couldn't merge this branch: had some issue with GitLab" anyway, it's a known issue but we don't understand it yet
11:50 eric_engestrom: in the meantime, there's probably no point assigning anything to marge, it will use the resources but not do anything useful :]
11:52 austriancoder: eric_engestrom: thanks for the information
12:26 pinchartl: slightly out of topic, but asking here as there's a large number of people with the relevant experience: what's the recommended way to run tests in a VM with the gitlab.fd.o infrastructure ? the ci-templates documentation mentions .fdo.qemu-build jobs, but those seem to have disappeared (except for freebsd)
12:26 pinchartl: (and if there's a better place to ask question about gitlab.fd.o CI, please let me know)
12:50 eric_engestrom: pinchartl: for fdo infra questions, #freedesktop is your best bet
12:51 eric_engestrom: (and for your specific question, I don't know)
12:53 pinchartl: eric_engestrom: thank you
13:03 Company: i915 question: If the kernel spends way too much time in shmem_sg_alloc_table() while trying to glTexIamge2d() a big texture (this one is 7k x 7k), what's the reason for that?
13:04 Company: more context: https://gitlab.gnome.org/GNOME/gtk/-/issues/6235#note_1929717
13:04 dj-death: Company: better ask on #intel-gfx
13:05 Company:does so
13:14 alatiera: jenatali, gfxstrand the windows runner seems to be running, but I will restart it anyway
13:15 alatiera: well, at a time with later that's not peak load hour
13:15 jenatali: 👍
13:15 alatiera: if you see more failures link me
13:39 eric_engestrom: PSA: the Marge-bot problem seems to have been resolved, you can now go back to using it :)
14:14 agd5f: sima, jani, just trying to dig out from thanksgiving. Can send a -next PR this week if that helps
19:38 songafear: So imagine if one generates the banks into a word a bank of all shader invocations as well as alus, it has compiler specification and runtime specification to compile those banks and to decompress and start using those alus uniforms varyings etc. now but if state has been changed, you want to execute the depth state removal, reassembly to the hash advertised. so this scheme technically should be talked about. So any state affecting the shader
19:38 songafear: execution has their range where its data lives in the hash, to remove this range there are banks in the header that says the number what to remove and if you reassemble, so a little state tracker needs to be written, that can add new depth values to the hash, or if for an example depth test is not enabled anymore removes the logic etc. otherwise on state changing in the client api it would right away produce rendering artifacts. So such bank assembly
19:38 songafear: routines i wanted to demonstrate only, which would open your eyes as to how extreme tech fabricated chips based computers really are, they are made for performance in all the science that every went into it with centuries in a row before it came to reality. So there is nothing to optimize in your compiler, now you need my backend, and i got my batteries and as said in ten days my lab is fully set up for coding this, since i won many tournaments in
19:39 songafear: the low category competitions and finally managed to buy the needed gadgets.
19:39 songafear: the geometry that fragment shader runs on is the viewport
19:39 songafear: and the clips are the other drawcall geometries in a scene
20:03 songafear: it has been the long goal of every opengl and graphics experts i see making sense on the web, to just get rid of the fixed function pipeline and bring in the performance, i send the primitive generator and rasterizer to the rest too.
20:03 songafear: but plan to add new stages into hashes, geometry shader as well as tessellation and compute
20:15 songafear: the success there is granted somewhat, so i am willing to share my progress too, no longer those FF units and blocks are needed in a new paradigm of executing graphics, but as for today, i need to rest, cause i go to work early in the morning
20:15 songafear: cheers.
20:31 mdnavare_: emersion: Do you know if Wayland has a way to request a custom mode? There used to be a way X could do it?
20:32 dj-death: jenatali: do you know of a clc knob that would disable printfs?
20:32 mdnavare_: sima: airlied : Do you know if there is still a way for userspace to request a custom mode DRM_MODE_TYPE_USERDEF ?
20:32 dj-death: jenatali: like they don't appear in the translation from opencl->spirv->nir
20:32 mdnavare_: or is that completely deprecated?
20:32 jenatali: dj-death: Not one that exists right now. Seems useful
20:34 jenatali: dj-death: There should be an intrinsic, which gets lowered to SSBO writes
20:35 emersion: mdnavare_: yes. it depends on the compositor
20:35 emersion: but the KMS uAPI supports it
20:36 emersion: basically, just create a blob with your own generated drmModeModeInfo in there
20:36 emersion: and then set that as MODE_ID
20:38 mdnavare_: and which ioctl gets used to send the drmmodeinfo for a custom mode?
20:38 mdnavare_: It would be great if you could point me to an example for this?
20:39 emersion: there's no IOCTL in particular
20:39 emersion: here's an example https://fs.emersion.fr/protected/presentations/present.html?src=kms-foss-north/index.md#40
20:40 mdnavare_: Thanks emersion let me take a look
20:40 emersion: this was a talk, if you want more details i'd suggest listening
20:40 dj-death: jenatali: yeah, it appears to be stripped somehow
20:40 emersion: here you can replace `mode = &connector->modes[0]` with your own logic to fill the struct
20:40 dj-death: jenatali: weirdly I had this working before :|
20:41 dj-death: jenatali: will dig more
20:41 jenatali: Weird
20:42 mdnavare_: emersion: So basically get the preferred or any mode from the modelist and replace with your own mode timings and atomic commit to modeset to that? Would this then be added to the connector's modelist?
20:42 emersion: no need to get anything from the mode list
20:43 emersion: you can fill your own drmModeModeInfo
20:43 emersion: from scratch
20:44 mdnavare_: okay and that would get added to the non edid mode list? And can be exposed correct?
20:44 mdnavare_: Could you send me the talk link, may be i will listen to that first and then ask more questions
20:48 mdnavare_: emersion: Could you please point me to the talk link?
20:48 emersion: https://git.sr.ht/~emersion/foss-north-kms
20:49 mdnavare_: Great thank you so much let me look through it and come back with questions.
20:50 mdnavare_: Basically I am trying to see if I can use this to create discrete modes corresponding to the VRR range, so if it is 40-120 Hz, can I say create a mode at 50Hz by keeping same clock but different vtotal
21:27 mdnavare_: emersion: For drm_info from your github, I just built with meson setup build and ninja build, but i cant run drm_info
21:27 mdnavare_: am i missing something
21:28 emersion: you mean gitlab?
21:29 emersion: should be able to run with <builddir>/drm_info
21:31 mdnavare_: yes gitlab correct
21:31 mdnavare_: so just run from build dir in drm_info?
21:32 emersion: yeah…
21:32 emersion: are you getting some kind of error?
22:06 mdnavare_: emersion: This is what I get navaremanasi@navaremanasi:~/drm_info/build$ ls
22:06 mdnavare_: build.ninja compile_commands.json drm_info drm_info.p meson-info meson-logs meson-private meson-uninstalled subprojects tables.c
22:06 mdnavare_: navaremanasi@navaremanasi:~/drm_info/build$ drm_info
22:06 mdnavare_: Command drm_info not found
22:06 mdnavare_: navaremanasi@navaremanasi:~/drm_info/build$ ./drm_info
22:06 mdnavare_: drmGetDevices: No such file or directory
22:07 emersion: seems like you don't have any KMS driver loaded?
22:07 emersion: like, /dev/dri doesn't exist or is empty?
22:08 mdnavare_: This is on my dev machine in the cloud, let me run on my DUT
22:14 mdnavare_: okay great yes that works thanks emersion
22:20 mdnavare_: emersion: So on my earlier question, if I create a mode and filled drmModeModeInfo struct for it and then commit, that would modeset to it, but such a mode wont get added to the connector modelist correct?
22:21 emersion: nope
22:21 emersion: there is no API to add to the modelist with the "modern" API
22:21 emersion: in other words, adding to the mode list should not be necessary
22:22 mdnavare_: Okay so if i want to modeset to a mode with a refresh rate that matches the content and falls within VRR range, the compositor can just fill in drmModeModeInfo with the corresponding refresh rate and inside kernel I can detect that it is a VRR mode and modeset to it without needing a full modeset or do it with fastset
22:23 mdnavare_: That was my initial idea, so will need a logic in the kernel to process this kind of modeset
22:23 mdnavare_: but from compositor pov that seems doable?
22:24 mdnavare_: emersion: Do you see any concern here?
22:25 emersion: yeah, that could work… not super sure
22:25 emersion: i mean it should work technically
22:25 mdnavare_: okay great thanks Simon, I might send out some RFC for this, will copy you
22:26 emersion: might need to think a bit more about the uAPI we want, no 100% sure this is the way to go
22:26 emersion: not*
22:26 emersion: but maybe it is
22:26 emersion: ok, please cc wayland-devel so that other compositors can provide feedback
22:27 mdnavare_: why would we need a different uAPI? All it needs to create a custom mode and request a modeset to it
23:20 zamundaaa[m]: FWIW the last time this sort of stuff was discussed, the consensus was that you wouldn't want to change the mode at all but make the different refresh rate happen in userspace instead