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