00:16anarsoul: what's up with mesa merge latency? I've assigned my MR to marge 6h ago, but it haven't picked it up yet
00:22alyssa: anarsoul: there's been like 15 MRs in queue all day
00:22alyssa: it's going, just slowly
00:22alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/?sort=updated_desc&state=opened&assignee_username%5B%5D=marge-bot&first_page_size=20
00:23alyssa: you're #2 in line
00:24anarsoul: everyone's merging their stuff prior to migration? :)
00:31pendingchaos: might be from people trying to get stuff into the stable release
00:42psykose: also seems to have a lot of overhead, something got merged and it's been 5 minutes and there's no marge push on any assigned mr yet
00:45psykose: speak of the devil :)
05:27pinchartl: how do GPUs typically handle caching with external textures (GL_TEXTURE_EXTERNAL_OES, create from an egl image itself created from dmabufs) ? when the contents of the backing buffer change, do I need to destroy and recreate the texture to flush GPU caches ? or even recreate the egl image ?
07:40daniels: pinchartl: it’s defined to get new content if you rebind the EGLImage to the GL texture
07:44zzyiwei: is it just me unable to push updates to MESA MRs? also unable to create new MRs either / o \
07:55daniels: zzyiwei: git push is failing? with which error?
07:58valentine: it doesn’t work for me either. I don’t get an error and the output in the terminal looks normal, but nothing actually gets pushed
07:59zzyiwei: That succeeded as usual. Remote branch is also updated correctly. However, the MR linked to the remote branch isn't updated. Meanwhile, I can't create new MRs against any of my already pushed remote branches.
08:00zzyiwei: The issue is specific to mesa, since I see no issues with virglrenderer.
08:04zzyiwei: I vaguely recall the same has happened long ago. Thought was a glitch because things had went back to normal after a coffee ; )
08:06dj-death: then you need more coffee obviously ;)
08:07zzyiwei: nice call =P
08:21dj-death: yeah looks like I don't have enough coffee too
08:21dj-death: I can't create MR too
08:22dj-death: https://gitlab.freedesktop.org/llandwerlin/mesa/-/tree/review/anv-remove-buffer-references is reporting 404
08:22dj-death: yet it is visible in https://gitlab.freedesktop.org/llandwerlin/mesa/-/branches
08:28tzimmermann: jfalempe, FYI: the fbdev-client series for i915/xe got merged. that means that all our drivers are on the generic client interface. So they can all switch clients easily. a few more drivers require vmap/vunmap to work with drm_log IIRC.
08:48daniels: heh ...
08:49daniels: it'll eventually become consistent
08:49daniels: what happens is that, post-push, a background job gets scheduled to update the status in the db from the git repos
08:50daniels: currently background jobs are kinda starved from the cleanup-old-pipelines scheduled jobs
08:51dj-death: alright
08:51dj-death: thanks
08:51dj-death: off to the coffee shop then
09:09jfalempe: tzimmermann: ok, but I think the problem is that without vmap drm_log just crashes, I need to check if it's in drm_log or in the client interface that this can be fixed.
11:36pinchartl: dakr: thank you
11:46ity: What's the env var for dumping final shader machine code for disassembly ? Specifically for Vulkan, anv.
11:47ity: (I figured I'll ask in case someone has it memorized before going source diving for it)
11:47ity: Just as I sent that I found it
11:49ity: Now onto figuring out why the env var is not working
12:16pinchartl: I meant daniels
12:17pinchartl: daniels: is creating an egl image from dmabuf expensive, is it something I should cache, or can I recreate it for every frame I want to display ?
13:01K900: OK, I think https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890 is ready-ish
13:01K900: Would appreciate some reviews
13:04daniels: pinchartl: yeah, you should definitely cache the EGLImage because that involves MMU bashing
13:07pinchartl: thanks
14:02mmind00: ity: as I'm currently trying to understand a shader problem (as a graphics-noob) ... care to share how to get the shader code? ;-)
14:05alyssa: mmind00: it's driver dependent
14:05alyssa: though maybe we should standardize that hmm.
14:06alyssa: https://docs.mesa3d.org/envvars.html
14:06alyssa: i think something like INTEL_DEBUG=vs,fs,cs for anv
14:08mmind00: there also seems to be a set of MESA_SHADER_foo vars
14:12mmind00: I'm of course trying out the newish panvk ... while rekindling childhood memories with the vulkan-reimplementation of the Gothic1+2 engine (originally from 2002) ;-)
14:14mmind00: and want to at least gather some data on the problem before pestering bbrezillon and/or the mesa issue tracker
14:22bbrezillon: mmind00: BIFROST_MESA_DEBUG=shaders if you want to dump the NIR/Mali shaders
14:24ity: mmind00: On Intel (anv), I currently use
14:24ity: INTEL_DEBUG=shaders MESA_SHADER_CACHE_DISABLE=true ./program
14:25alyssa: bbrezillon: lol bifrost
14:25ity: This dumps all stage disassemblies, excluding the shader binaries
14:25ity: It only dumps on compilation; If it's already cached, it doesn't dump anything. I was stuck on that for quite a while :)
14:26mmind00: bbrezillon: was more talking about valhall :-)
14:26ity: (Now I am trying to figure out how the shader assembly format works)
14:26bbrezillon: mmind00: Bifrost and Valhall use the same compiler backend
14:27mmind00: bbrezillon: ah ok :-)
14:27mmind00: bbrezillon: for reference, some visiblity shader not behaving as on all other platforms: bbrezillon: https://github.com/Try/OpenGothic/issues/744
14:28mmind00: (and me being way out of my depth wrt to everything :-D )
14:28ity: mmind00: panvk (covers v10,v11 iirc, so Valhall) has PANVK_DEBUG
15:50gfxstrand: mareko, robclark, cwabbott: Can the layouts that AMD and freedreno use with legacy dma-bufs via the side-band blob always be expressed with modifiers? Or are there layouts that are used in practice in the wild for which modifiers do not exist?
15:50gfxstrand: I'm trying to determine if a "get the modifier for this dma-buf" extension would even be implementable there.
15:51cwabbott: on freedreno the side-band blob is literally just a modifier so yes
15:51gfxstrand: sweet
15:51gfxstrand: On Intel, it's a tiling (X, Y, or Linear) and on nouveau it's a PTE kind and tile mode, both of which are encodable in modifiers.
15:52robclark: yeah, it's just a back door way to pass a modifier
15:52gfxstrand: :D
15:53gfxstrand: I'm burning down the remaining issues with using Zink for your compositor and hit "OMG! What aboutg glXBindTexImageEXT()?!?" :weary:
15:56mareko: gfxstrand: this radeonsi MR exposes modifiers for layouts that currently don't have modifiers: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31658
15:58gfxstrand: Once you add that modifier, will that be all of them?
15:58gfxstrand: I don't know if that's a question that even makes sense.
15:58gfxstrand: IDK what all you stuff in that blob
15:58mareko: gfxstrand: only 2D non-MSAA color modifiers are supported
15:58gfxstrand: Well, yes
15:58gfxstrand: I assume only 2D non-MSAA
15:58alyssa: gfxstrand: tangentially, does import/export of sparse resident images make any sense? :clown:
15:58gfxstrand: No
15:59alyssa: K
15:59gfxstrand: This is literally just so I can implement glXBindTexImageEXT() in Zink.
15:59mareko: I think that MR exposes modifiers for all layouts that can occur with GL textures
15:59gfxstrand: Cool
15:59alyssa:will probably drop DRM_FORMAT_MOD_APPLE_TWIDDLED(_COMPRESSED) in v4 of the fourcc series then since that's just for sparse AFAIK
15:59gfxstrand: I'm going to go with my first plan, then, and the RADV folks can comment if they think it's unimplementable.
16:00sima: tzimmermann, looking at your fbdev events series I'm wondering whether we shouldn't just disable lcd events for drm fbdev emulation
16:00mareko: we could support modifiers for 3D, MSAA and Z/S if needed, they are encodeable using existing definitions
16:00sima: that really shouldn't ever do anything, otherwise there's a drm kms driver bug
16:00gfxstrand: Time to write the most cursed Vulkan extension ever!
16:00sima: backlight otoh is a complete mess, ideally drm kms drivers should handle that, but on x86 they don't because lolz
16:00tzimmermann: sima, but this code is also for regular fbdev drivers
16:01gfxstrand: mareko: Yeah, NVIDIA modifiers are also sufficient for nearly everything.
16:01sima: tzimmermann, yeah so probably a FB_INFO_NO_LCD flag
16:01gfxstrand: IDK about MSAA. We'd have to assume D3D convention.
16:01gfxstrand: But NVIDIA hardware is very opinionated.
16:01tzimmermann: that's a separate series, i think
16:01gfxstrand: And I don't think they're sufficient for sparse, either, though I'd have to double-check.
16:04mareko: sparse is not shareable
16:04gfxstrand: Well, yeah.
16:04gfxstrand: But if someone wanted to go crazy...
16:04mareko: each page could be a separate DMABUF
16:05sima: tzimmermann, yeah just dropping ideas, since fbdev doing stuff drm kms drivers should do just asks for bugs
16:05sima: for backlight untangling it all is unfortunately really messy
16:05tzimmermann: true
16:05tzimmermann: well, backlight is free of fbdev after this series
16:06tzimmermann: and fbdev would need additional handling to be free from backlight calls
16:06sima: I meant the part that fbdev doesn't handle the backlight automatically anymore
16:06tzimmermann: right
16:11sima: but that also leaks into kms uapi, at least on x86 you kinda have to also drive the backlight in some cases
16:11sima: and so this is all really messy
18:17alyssa: gfxstrand: dEQP-VK.binding_model.buffer_device_address.* blowing up since this morning on hk
18:17alyssa: deqp-vk: ../src/vulkan/runtime/vk_buffer.h:71: VkDeviceAddress vk_buffer_address(const struct vk_buffer *, VkDeviceSize): Assertion `buffer->device_address != 0' failed.
18:17alyssa: from GetBufferOpaque
18:18alyssa: I don't think the hk code diverges from nvk though so i'm confused. does this pass CTS on nvk?
19:16zmike: mareko: thinking further on surfaces, is there a reason why they need to exist at all? the only time they're bound in the driver is for framebuffer state, but pipe_framebuffer_state could just as easily be an array of static states
19:17zmike: this would reduce object juggling considerably, not to mention eliminating the current confusion about what exactly owns a pipe_surface
19:17zmike: though it would expand pipe_framebuffer_state quite a bit
19:22alyssa: zmike: i'd probably support that although i'd need to think about it for more than 15 seconds
19:24zmike: most likely I'd hack up all the drivers to create/destroy their own surfaces on set_framebuffer_state for the initial handling and then everyone could optimize/cleanup from there
19:24zmike: the current surface/renderbuffer handling is not exactly intuitive on the frontend side
19:30alyssa: nod
20:11gfxstrand: alyssa: I CTS'd it yesterday, or so I thought.
20:12alyssa: gfxstrand: Hmm
20:38alyssa: zmike: I think if we keep struct pipe_surface in p_state.h, but include the surfaces directly in the fb state rather than as pointers, and kill the create_surface/delete hooks ... I think that would work ok
20:39alyssa: (and kill the reference count on pipe_surf ofc)
20:39zmike: yeah that's the idea
20:39alyssa: cool
20:39alyssa: this is also especially relevant to tilers
20:40alyssa: where we do want to hash-table lookup a pipe framebuffer state, and the obvious way that asahi/panfrost/... do is broken because of surfaces getting freed/reallocated at the same address (hashing ointers instead of content)
20:40alyssa: iirc, freedreno is the only driver that gets this right
20:40alyssa: and it looked like a lot of code and well oops.
20:41alyssa: (freedreno was first and does it right, videocore was second and does it wrong, and then I copied from videocore twice in my career)
20:41zmike: yeah the current state of surface lifetimes is not enjoyable
20:41alyssa: anyway, this change would force everyone to do the correct thing
20:41alyssa: which would be nice as the maintainer of a tiler gl driver
20:42alyssa: it sounds like, potentially a lot of work to port the tree but
20:42zmike: I'm already so deep into this dumpster fire I can't feel my teeth
20:42alyssa: yeah... not volunteering myself. but if good patches showed up i would ack them
20:47alyssa: will i ever have to care about 32768x32768 images
20:48alyssa: apparently nvidia supports that. clown
20:48zmike: 32k is coming.
20:49alyssa: zmike: relevant question is "will I ever see a 2D Array depth/stencil buffer with a layer stride that exceeds 32-bit"
20:49alyssa: i.e., 32768x32768 or bigger
20:52zmike: in real world usage or cts?
20:52zmike: because I can get you cts coverage tomorrow
20:54alyssa: zmike: cts, obviously
20:54alyssa: i don't care about real world, only cts
20:54alyssa: ever
20:54zmike: you pass.
20:58alyssa: =D
20:59alyssa: me when collecting fossils of dEQP-VK.glsl.* because she heard perf is important now
21:00HdkR: Wait, people care about perf?
21:02alyssa: HdkR: only you
21:20HdkR: alyssa: It's true, I'm hungry for perf.