06:45karolherbst: itoral: I'm trying to debug vulkan on my pi4, but the display side doesn't get properly initialized with an upstream kernel, anything I need to consider there?
06:49itoral: @karolherbst: sorry but I only work with the downstream kernel from Raspberry Pi OS... @mairacanal do you know if there is something specific that needs to be done to use the upstream kernel successfully?
06:49karolherbst: one error I'm seeing is "vc4_hdmi fef00700.hdmi: Could not register PCM component: -517"
06:49karolherbst: and "platform gpu: deferred probe pending"
07:40Company: karolherbst, itoral: Last I tried on my rpi4 a few weeks ago, Vulkan on Fedora was a no-go, too
07:41karolherbst: it looks like something is missing on the audio side of things
07:42karolherbst: mhhhh
07:42karolherbst: "of_dma_find_controller: can't find DMA controller /scb/dma@7e007b00"
07:42Company: is that during boot or related to Vulkan in particular?
07:43karolherbst: it's printed right before "vc4_hdmi fef00700.hdmi: Could not register PCM component: -517"
07:45karolherbst: seems like there is no upstream driver for that one
07:59itoral: Company: there was an issue with Vulkan on Wayland a few months ago: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10111 that was fixed with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26200, wondering if your version of Mesa you had had that problem
08:01karolherbst: I myself simply run into "deqp-vk: ../src/broadcom/vulkan/v3dv_device.c:857: create_physical_device: Assertion `display_device' failed."
08:01karolherbst: and I concluded that was due to vc4 not loading correctly
08:02karolherbst: which is the default behavior on fedora afaik
08:03itoral: but if the display driver is not loading at all then GL should be broken too, but Company was talking specifically about Vulkan, so I think these are two different issues
08:04Company: yeah, that's why I asked
08:04Company: GL worked
08:04Company: itoral: last time I tried was around the time of the Fedora GTK bug a few weeks ago I think
08:05karolherbst: huh.. I wonder why I run into issues then
08:06karolherbst: unless it's something dev board specific
08:06karolherbst: or compute module
08:07Company: the Fedora kernel also spams my syslog every time I use GL
08:10itoral: MMU errors? yeah, that is a known issue, we are looking into it
08:12Company: it was a bit distracting when benchmarking - the journal taking 30% of the recorded CPU time was a bit much
08:14Company: I didn't really dive into the rpi too much though, basically just boot it every few weeks/months to see how well GTK works
08:14Company: because I decided to use it as the example of low end hardware to target for GTK
08:15karolherbst: all I can say is that the vc4 driver doesn't load on my CM4 here
08:15itoral: ouch, yeah
08:16itoral: @karolherbst: ok, maybe @mairacanal can help with that when she is online, not sure if she knows anything about that
08:16javierm: karolherbst: what does cat /sys/kernel/debug/devices_deferred say ?
08:17karolherbst: gpu
08:18karolherbst: but anyway.. I already mentioned above that it's most likely due to "of_dma_find_controller: can't find DMA controller /scb/dma@7e007b00"
08:18karolherbst: and that requires a driver handling "bcm2711-dma"
08:19karolherbst: which doesn't exist upstream
08:21javierm: karolherbst: and are you using the upstream device tree for the CM4 ?
08:21karolherbst: I don't know
08:22javierm: because grep doesn't find that node in arch/arm/boot/dts/broadcom/bcm2711*
08:22karolherbst: how can I check what device tree is used and how can I make it use another one?
08:24javierm: karolherbst: it depends on what firmware you are using to boot (edk2 or u-boot) but if you are using Fedora, you can force the device tree to use by adding a "devicetree" entry to the BLS configs in /boot/loader/entries/
08:24karolherbst: though I guess I'd need to use the "bcm2711-rpi-cm4-io.dtb" one
08:24javierm: karolherbst: it seems so, yeah
08:27karolherbst: there is also this /boot/efi/config.txt file doing some dt stuff
08:28javierm: karolherbst: one sec, I've a rpi4 (not CM4 but the normal board) in a drawer. Let me boot it so we can compare configs
08:29karolherbst: I love how nothing tells me how to use the device_tree property :)
09:15dschuermann: can someone from Intel lend a helping hand and look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617 ?
09:23jani: tzimmermann: this is what I've got for udl: https://gitlab.freedesktop.org/jani/linux/-/commit/c6357a778182eff7acfb1eb832809377f799edaf
09:24jani: tzimmermann: the entire branch is https://gitlab.freedesktop.org/jani/linux/-/commits/drm-edid-conversions
09:25jani: tzimmermann: but I just haven't had the time to polish and double check. you just go ahead with what you're doing
09:58mripard: vsyrjala: Hi, could you review https://lore.kernel.org/dri-devel/20240326-kms-hdmi-connector-state-v11-15-c5680ffcf261@kernel.org/ and https://lore.kernel.org/dri-devel/20240326-kms-hdmi-connector-state-v11-21-c5680ffcf261@kernel.org/? I think I addressed your concerns and would like to merge it soonish.
10:20tzimmermann: jani, i've been working on udl and came up with something. i'll put you in cc
10:22tzimmermann: the one thig that still puzzles me is why drm_edid_read_ddc() even bothers to test connector->force. it could read the edid unconditionally and let other layers deal with connector status
10:32jani: tzimmermann: I think a lot of places use EDID read as a way check if the display is connected. lots of places other than .detect() also have EDID reads. override/firmware EDID read always succeeds.
10:32jani: ddc probe and override/firmware EDID should be orthogonal things
10:33jani: but if you have the connector forced on, for example because the ddc is bust, why would you do ddc probe, possibly leading to errors and timeouts
10:39jani: and finally, why are override/firmware EDIDs handled at the lowest level? this didn't use to be the case. but then we didn't actually use the override/firmware EDID for all information, it was haphazard at best. now they are handled almost exactly the same as regular EDIDs
10:41jani: perhaps you could make the case that we should pass connector to drm_probe_ddc(), and have that check connector forcing
10:42tzimmermann: i'm not saying that there aren't reasons. it's just pretty. it's not obvious or discoverable what's going one
10:43jani: I don't disagree
10:43jani: this is something I could write a bit more documentation on
10:43jani: (I presume you mean "not pretty")
10:48tzimmermann: yeah, "not pretty"
10:49tzimmermann: and "on" instead of "one"
10:50jani: tzimmermann: I also think the bridge funcs .edid_read() hook has lead to some bad habits, some drivers just directly using whatever mechanisms for EDID reads, instead of a) implementing the i2c ddc interface, or b) even using drm_edid_read_custom() or the older version of it
10:50jani: very tedious to fix or get aligned with the rest afterwards
10:50jani: this is the worst thing I've come across https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/bridge/analogix/anx7625.c#n1120
10:57jannau: karolherbst, javierm: https://bugzilla.redhat.com/show_bug.cgi?id=2246428 upstream changed the HDMI audio dma engine. I should have send the patch which just breaks HDMI audio. patch is hacky though
11:02karolherbst: ohh.. so it looks like fedora 39 fixes this?
11:03karolherbst: or did it break recently due to fixing this?
11:04karolherbst: oh wait
11:08jannau: karolherbst: I think it was "fixed" in fedora by always using ext4 as /boot partition
11:09karolherbst: huh? How is that even related?
11:09jannau: the issue was server image specific and caused by fedora's u-boot not being able to load the dtb from disk
11:09karolherbst: ohh....
11:18mairacanal: karolherbst, I tested drm-misc-next on RPi 4 yesterday using Raspberry Pi OS and Vulkan was running just fine
11:18jannau: no, Peter fixed the binary DTBs in bcm283x-firmware https://src.fedoraproject.org/rpms/bcm283x-firmware/c/12a6a27872948064248469ff5790b880b0067a15?branch=rawhide
11:19mairacanal: let me know if this fedora workaround worked for you, otherwise I can grab an sd card and flash F39
12:00tomasuto: liblzma hahaa cool. I said you lose on the path of conspiring against me. I am extremely loved person in life. You get destroyed entirely.
12:17cwabbott: robclark: who's the point of contact for the collabora a618 test farm?
12:17cwabbott: it might need to be disabled because it's causing huge (10 hr+) marge queues
12:19cwabbott: it's not completely broken, but there's some kind of underprovision resulting in 45 min+ job runtimes that's slowing down marge enough to be backed up
12:19robclark: cwabbott: daniels or DavidHeidelberg can check on the status.. I'd been using ci_run_n_monitor.sh yesterday to work on cleaning up a618 expectations yesterday but it should have just been running two jobs
12:19zmike: nah it's been broken overnight too
12:20zmike: so unless you were pulling some extremely long hours...
12:21robclark: collabora does have some usage monitoring, so I guess they can check
12:37robclark: cwabbott, zmike: looks like right now karolherbst, marge, and gfx-ci-bot (nightly runs) are currently running things on them.. but there are a lot of them and they all appear to be running fine.. I think it's just that folks are running lot of jobs. AFAIU, LAVA should attempt to prioritize marge.. but I think it just comes down to busy-ci-day
12:37zmike: gdit karol
12:37zmike: I knew this was all your fault
12:38robclark: maybe they were also getting some drm/ci use, but that isn't massively parallel, I think just uses a couple runners
12:38karolherbst: the perks of touching core stuff
12:40cwabbott: robclark: well, the queue is still really backed up, and looking at what's running now, it's blocked on https://gitlab.freedesktop.org/mesa/mesa/-/jobs/57190723 which took 10 minutes to find a runner
12:41cwabbott: there were only 2 a618 jobs for that, because it only touched zink code, but it still took 10 mins
12:42cwabbott: it does seem like something else is "fighting" for runner bandwidth and marge is losing
12:43karolherbst: that's the a618 one, right?
12:44karolherbst: mhh
12:44karolherbst: a618_vk being split across 12 jobs might be a problem here
12:46robclark: there are a lot of vk tests.. blame khronos, I guess?
13:09prime: autojoin add
13:29tomasuto: My presentation for XDC is very simple, it comes out of my private one man lab testings, and everything is logged from irc on my disk, it's calculations I made in very clever fashion, so I have not kept any secrets. I spent a lot of time to simulate hardware, so if you turn me down, I accept it and promise not to sanction for this decision, I then continue with my own company and with my best friends, but I urge you not to send any
13:29tomasuto: of your braindead terrorists on to my physical territory, to some degree I still respect David airlie and open source programmers, all has worked out great to me imo and you have done good work time to time, I think David is smarter than brainless criminals.
13:51tomasuto: I already gave most the submission data to Karol too, it's all based of that, it has been somewhat clear for me for a little while, so testing was successful, I tested the proof in very clever way, so if you want to see me presenting myself instead of Karol or Dave , then give me some appointment and submission process info to get accepted to XDC or linuxconf or fosdem.
14:25Company: what's the status of Vulkan on Mali?
14:26Company: I guess I'm mostly wondering what's gonna happen to robertmader[m]'s dmabuf stuff once GTK goes Vulkan - that's gonna stay with GL I guess?
14:37DemiMarie: Company: there is a lot of hardware that will never support Vulkan.
14:37DemiMarie: So if GTK requires Vulkan, this hardware will be stuck with lavapipe.
14:38DemiMarie: And it likely has far less CPU resources than Qubes OS VMs do.
14:42Company: nah, we're not gonna require Vulkan - but we might have features that are Vulkan-only
14:47DemiMarie: Company: Such as?
14:49Company: memory management is easier with Vulkan
14:49Company: we can allocate dmabufs with it
14:49robert_mader: Company: why would going Vulkan be any problem? GL and Vulkan are both implemented on top of dmabuf - and Wayland only uses dmabuf as well.
14:49Company: robert_mader: because your rockchip doesn't do Vulkan
14:50robert_mader: Err, do you plan to drop GL from GTK? Then I'd worry about other things :P
14:50Company: no
14:51Company: but there's features that are easy with Vulkan
14:51Company: like creating dmabufs
14:52robert_mader: Sorry, I'm not following you. What does that have to do with "my dmabuf stuff"?
14:53robert_mader: You are referring to wayland offloading, no? In that case we're using dmabufs from other producers anyway.
14:53Company: for now, yes
14:54Company: there's been talk about offloading GtkGLArea for example
14:54zamundaaa[m]: Company: you ideally shouldn't use either Vulkan or OpenGL if you want to create dmabufs. If you want direct scanout to work, you have to use GBM
14:55Company: zamundaaa[m]: if you want the 100% guaranteed thing, maybe
14:56zamundaaa[m]: No, if you want it to work on most hardware
14:56robert_mader: Company: I don't see why you'd ever want to create dmabufs for hardware video decoding :P
14:56Company: robert_mader: I wouldn't - but that's not the only usecase
14:57zamundaaa[m]: EGL's default format modifier selection on modern AMD GPUs at least does not work for direct scanout
14:57Company: robert_mader: actually, we talked about doing it anyway
14:57zamundaaa[m]: And really shouldn't, as scanout formats are usually less efficient for rendering
14:57zamundaaa[m]: Especially on tiler GPUs
14:58Company: zamundaaa[m]: I'll wait for v4l and pipewire to figure things out then
14:59robert_mader: Company: is there any reason why you'd *not* want to support importing dmabufs?
15:00DemiMarie: Company: does GTK work with applications that use Vulkan internally?
15:00Company: robert_mader: importing dmabufs works fine - the fun stuff is offloading CPU memory (we talked about that before) and offloading GtkGLArea
15:01Company: DemiMarie: I have no idea - but I don't see why not, as long as they exchange dmabufs with GTK
15:03DemiMarie: Company: in a portable way, as opposed to Linux-specifc
15:03Company: I have no idea how that would even look
15:03DemiMarie: GTK already has OpenGL support I believe
15:04Company: yes, and that's already bad enough
15:04DemiMarie: In what ways?
15:05Company: it's basically underdefined how sharing works because there's always yet another GL thing that somebody could do
15:06Company: set some TexParameter that GTK doesn't even know about etc
15:06DemiMarie: On Linux: Wayland subsurface
15:06DemiMarie: Also, is there anything that can be done to speed up shader compilation?
15:06DemiMarie: Context: Qubes OS users often use disposable VMs, in which the shader cache will always miss.
15:07Company: you don't want to share subsurfaces
15:07Company: that's as bad as sharing GL textures because of all the extensions
15:07DemiMarie: I meant provide a subsurface for the app to use
15:07Company: same problem
15:08DemiMarie: So GTK is not suitable for games, got it.
15:08Company: you want to share dmabufs or another memory abstraction
15:09Company: I don't think GTK is suitable for games until people start adding support for it - but that has nothing to do with buffer sharing
15:09Company: and more to do with how the frame clock works
16:06mahkoh: Would it be possible to add a syscall to create syncobj fds independently of any DRM fd? I'm running integration tests of my compositor on a headless system with only vkms (IIRC) and I cannot test the explicit sync paths because I cannot create syncobjs.
16:11mairacanal: have you tried vgem?
16:13mahkoh: I have not. All I'm doing right now is `modprobe vkms` before running my tests and then my test backend picks up the first entry in /dev/dri and uses that for rendering + creating syncobjs. I'll look into vgem.
16:33tomasuto: DemiMarie, there is actually no gpu in the world that could not support vulkan, after my presentation i mean you would understand that, i could add those entries, and it is actually possible also to convert opengl to opengl es, as is possible to convert between any rendering api. You would end up doing things in sw land. Today we have everything, i much liked the commit and idea of GUD, it was the last thing i missed.
16:34tomasuto: but finding a way to communicate this process to intel and amd employers , they are not probably fine to employ you to do that, i suppose red hat and such is cool.
16:37mahkoh: I tried using vgem but this causes the following errors: `DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied`. The same does work with vkms. Also as far as I can tell that driver does not support syncobjs either: `.driver_features = DRIVER_GEM | DRIVER_RENDER,`
16:46mahkoh: The reason for the permission denied seems to be that vgem creates a render node and render nodes don't allow creating dumb buffers. vkms does not create a render node so everything works. I'll try deleting the render node before running the tests.
16:48robert_mader: DemiMarie: for the record - GTK *does* unofficially support app-controlled subsurfaces - that's how Firefox works. While that's with GTK3, which won't change much any more, AFAICS it should mostly work with GTK4. But given that it's not officially supported you probably shouldn't build a game with it :)
16:55mahkoh: After deleting the render nodes I'm running into a different problem where it looks like I can no longer create an opengl context. Guess I'll just not be able to run syncobj tests automatically.
19:45DemiMarie: @_oftc_robert_mader:matrix.org: is there a reason it cannot be official? I thought that having different libraries use different subsurfaces was intended behavior.
20:10airlied: dwfreed: ^ just in case you missed it :-)
21:15dwfreed: airlied: yeah, got a PM from another