00:54 apteryx: which mesa driver would work best for a radeon 7600 rx?
06:40 DodoGTA: Why is the lavapipe driver located in src/gallium and (probably) links to llvmpipe? Is it a Vulkan extension of llvmpipe?
07:00 airlied: DodoGTA: yes
07:43 MrCooper: apteryx: for Vulkan there's only RADV; for OpenGL, the default radeonsi should be best in general, you can try zink instead though
08:15 daniels: robclark: thanks!
08:23 jfalempe: I can't build the DRM_XE driver without FB_IOMEM_HELPERS. i915 selects the iomem_helpers only if fbdev emulation is enabled. Should it be the same for Xe ?
08:23 jfalempe: https://elixir.bootlin.com/linux/v6.10.4/source/drivers/gpu/drm/xe/Kconfig#L54
08:23 jfalempe: https://elixir.bootlin.com/linux/v6.10.4/source/drivers/gpu/drm/i915/Kconfig#L20
09:08 tzimmermann: jfalempe, maybe ask in #intel-gfx . but in short, the xe driver should probably behave like i915
09:09 jfalempe: tzimmermann: thanks, I've seen this when compiling without fbdev emulation, the xe driver still selects some fbdev stuff.
09:11 tzimmermann: jfalempe, i have a patchset that cleans up most of the current client handling in the driver. there will only be one common function, where you can add drm_log (or any other client)
09:11 tzimmermann: i'll paost it later this week
09:12 jfalempe: cool thanks ;)
09:13 jfalempe: I've made drm_log works on nouveau too, there was a few problems with my RFC.
09:18 tzimmermann: jfalempe, FYI drm_client buffers use GEM vmap/vunmap interfaces. IIRC some odd drivers don't support that. so the clients likely don't work on all drivers
09:18 tzimmermann: but that's not really a problem for now
09:19 jfalempe: yes, I have to use vmap_local() with nouveau, but that doesn't work with simpledrm.
09:19 tzimmermann: it's drivers like gma500, with obsolete hardware
09:19 tzimmermann: vmap_local doesn't work with simpledrm?
09:19 tzimmermann: it should
09:20 tzimmermann: drm_client_buffer_vmap_local() is the call to use
09:20 tzimmermann: it should work with any common driver (SHMEM, DMA, TTM)
09:20 jfalempe: it never returns in drm_client_framebuffer_flush()
09:21 tzimmermann: because you're still holdign the GEM lock
09:21 tzimmermann: i guess
09:21 tzimmermann: it's called _local, because you can only map within the local function
09:22 tzimmermann: your drawing routine calls drm_client_buffer_vmap_local(), then draws, then calls drm_client_buffer_vunmap_local()
09:22 jfalempe: normally at this point it shouldn't have any lock, but I'm still debugging it.
09:22 tzimmermann: the last call undoes the mapping and releases the GEM reervation lock
09:22 jfalempe: yes, it's what I'm doing now, and it works with nouveau.
09:23 tzimmermann: holding the rservation lock guarantees that the buffer doesn't move
09:23 tzimmermann: there should be no drm_client_framebuffer_flush() in between
09:23 jfalempe: ah the flush should be done after the unmap ?
09:24 tzimmermann: yes
09:25 tzimmermann: here's the vmap_local() pattern: https://elixir.bootlin.com/linux/v6.11-rc1/source/drivers/gpu/drm/drm_fbdev_ttm.c#L200
09:25 jfalempe: ok that explain my problem, thanks, that save me a lot of time ;)
09:25 tzimmermann: and the corresponding flush happens afterwards at: https://elixir.bootlin.com/linux/v6.11-rc1/source/drivers/gpu/drm/drm_fbdev_ttm.c#L230
09:29 tzimmermann: using vmap_local like fbdev-ttm does is the portable pattern. if you see anything else in fbdev-shmem of fbdev-dma, it's for optimization towards these memory managers
09:30 tzimmermann: s/of/or
09:32 jfalempe: tzimmermann: that works, thanks a lot :)
09:32 tzimmermann: np
16:10 sergi: karolherbst, daniels: I saw piglit!940 merged yesterday, and today we have an uprev Piglit in Mesa https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30635 Do you thing it good to have it merged?
16:11 karolherbst: yes
16:11 karolherbst: it fixes the trace differ preview
16:17 daniels: sergi: yep, thanks
16:22 agd5f: airlied, sima: any thoughts on https://lore.kernel.org/lkml/ZO463CUKB3QIHDAu@casper.infradead.org/T/ ?
16:22 agd5f: we are already running into this limit today
16:59 sima: agd5f, looks reasonable, not sure what you need me for since there seems to be a bunch of reviewers/committers on it already
17:00 sima: looking through discussions there was some minor stuff left to fix in libdrm and I guess that never happened
17:00 agd5f: wasn't sure if there was some major blocker or if it's just waiting for a resend.
17:00 agd5f: If Intel doesn't plan to resend it, we could pick it up.
17:05 sima: agd5f, not sure what the plans are, I'd just pick it up if nothing happens the next 1-2 weeks
17:05 sima: since I think summer break is mostly over
20:16 austriancoder: is there a reason src/mesa/main/formats.csv does not contain any yuv formats?
20:35 Company: austriancoder: MESA_FORMAT_RG_RB_UNORM8 etc?
20:36 austriancoder: Company: these are used for emulation with shaders - or?
20:36 Company:not expert enough to know that
20:37 Company: I just know I had to look at that when dealing with bugs in Vulkan yuv stuff a year or so ago
20:38 austriancoder: I am asking, cause my GPU has yuv tiler support so no need for shader work
20:39 Company: I know that in Vulkan I have to use those RGB formats to import the dmabuf
20:39 Company: and then the VkYCbCrConversion takes care of tuning the hardware as-needed
20:40 austriancoder: emulation == color conversion in shader
20:40 Company: though most of that work was with multiplane formats anyway - read: NV12 or VK_FORMAT_G8_B8R8_2PLANE_420_UNORM
20:41 Company: yeah, most of the drivers do the shader thing, but I think robertmader had a device that implemented that in hardware and he reported success
20:42 Company: but I don't remember which one that was
20:42 austriancoder: in my case NV12 is a single plane only
20:43 Company: yeah, because it's not disjoint - but I think it's treated everywhere as multiplane
20:43 Company: it certainly is in Vulkan and dmabuf
20:44 Company: v4l might treat it differently, I don't remember
20:45 austriancoder: kmscube supports its :)
20:45 Company: GTK does, too ;)
20:46 Company: I remember I had the argument with Robert about writing shaders (like Mutter does) and using YCbCrConversion or the equivalent eglCreateImage() flags
20:47 Company: and finally figuring out that there's like 2 pieces of hardware that can do it works on at least one of them
20:47 Company: and then I was triumphant
20:49 Company: and iirc Mesa treats it as 2 planes - R8 and R8G8 respectively, 2nd one with halved width/height
20:50 Company: which is why it works fine if you import it as 2 textures with 2 calls to eglCreateImage()
20:50 Company: and then do the YUV conversion in the shader
20:53 austriancoder: yeah .. and you get this feature out of the box as gallium driver.
20:57 Company: *YUV conversion in a Mutter shader
20:57 Company: and you get gallium shaders if your hardware can't do it
20:57 Company: but you also get hardware shaders if your hardware can do it and the driver implements it
20:58 Company: same with Vulkan, it's some NIR pass I think
21:47 austriancoder: daniels: as I'm not very familiar with this part of mesa, could you please share your thoughts on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418/diffs?commit_id=e0b9d31d126eb4f4e6311cb7e60e2501808901f2 ?