01:44airlied: can someone from intel poke rohan garg, he seems to have uploaded a branch to mesa/mesa
01:46airlied: not actually sure where that branch was, I had a stale ptr to cgit
01:46airlied: oh no it's in mesa/mesa
01:46airlied: zmike: you also pushed zink-stablefix
02:04airlied: zmike, konstantin : I don't think lavapipe yuv stuff is finished, there are some mandatory formats not advertised, and my first attempt at advertising them make things worse
02:05airlied: I'm considered deadvertising the feature
02:34gfxstrand: airlied: What's required and not working?
02:42airlied: gfxstrand: I think for lvp it needs planar stuff supported but not fully sure
02:42airlied: g8_b8_r8_3plane_420_unorm is mandatory
02:43airlied: but advertising it, makes texture sampling try and create a sampler for NV12
02:47gfxstrand: Yeah, I think I fixed that mess. :)
02:48gfxstrand: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619 fixed a lot of gallivm nonsense. :)
02:49gfxstrand: The last patch in particular
02:50airlied: I do wonder why I have nv12 appearing where it does, just juggling 3 other things before I can get to digging in
02:51gfxstrand: I mean, it's totally possible that lavapipe is still using the wrong formats somewhere else.
02:54airlied: case VK_FORMAT_G8_B8R8_2PLANE_420_UNORM:
02:54airlied: return PIPE_FORMAT_NV12;
02:54airlied: I do wonder should we even be creating sampler code for these at this time
02:57airlied: okay that seems to have helped actuallly
04:18gfxstrand: airlied: Yeah, you shouldn't be using any of the YUV PIPE_FORMATs
04:19gfxstrand: airlied: Just do what we did in NVK and do multi-plane with vk_format_ycbcr_info and you'll get all the formats.
04:20gfxstrand: PIPE_FORMAT is NOT your friend.
04:43airlied: gfxstrand: now it dies on multi-plane sampling
04:43airlied: as llvmpipe has no ability to sample planes
04:43airlied: I think lavapipe frontend could work around that, but not sure with descriptor indexing
04:45airlied: like I could allocate a llvmpipe resource per plane, but I'd have figure out how to bind them
06:10airlied: konstantin, zmike : okay I've got a bit of a handle on planar images in lavapipe
08:13airlied: konstantin, zmike : lvp-planar-images-wip is how far I got, still fails a bunch of sampler array tests and need to add disjoint support
08:16pq: I'd love to give Company hints, like vivid for creating YUV dmabuf in software, but he's never here when I want to reply.
08:17emersion: if only FDO offered a bouncer service…
08:17emersion: oh wait
08:19lina: FDO offers a bouncer service?
08:19emersion: (i offered to set it up, but people didn't like it)
08:20lina: oh...
08:20emersion: (https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/459)
11:41konstantin: airlied: How will you implement descriptor buffer support, considering we are at the descriptor size limit?
12:37Deathray: Hey I had a question about a weird (I think) bug that I've noticed in OSMesa in 23.2.1 and I thought I'd ask here to double check that the fault isn't on my end before filing a bug report and wasting more peoples time. Is this the right place to ask or is there a different more specific channel that I should put this in?
12:38pq: This is the IRC channel, FWIW.
12:40Deathray: Sure, idk, I thought there might be more specific channels since mesa is such a massive project with many devs on it.
12:41psykose: this is correct yea
12:41pq: there are, for individual drivers
12:42pq: but not for users AFAIK
12:44Deathray: So the thing is I am making an ofscreen context with 16 depth bits and then binding it (well making it the current context), however afterwards when I read out GL_DEPTH_BITS it seems to say there are 0 depth bits. The thing is that when I directly request the depth buffer through the OSMesa functions it seems to return a valid buffer with 2 bytes per value (so the 16 bits I requested)
15:11dv_: on a system that runs purely with KMS - no wayland, no x11 - is it possible to screengrab for making screenshots?
15:11dv_: with the old framebuffer I was able to just do `dd if=/dev/fb0 of=screenshot.raw`
15:14MrCooper: possible in principle, though not 100% reliably while the DRM master is actively flipping between FBs
15:14MrCooper: only the DRM master itself can do it 100% reliably
15:16emersion: (see ffmpeh kmsgrab)
15:16emersion: ffmpeg*
16:41MrCooper: Company: FYI, you tend to disappear from here before I get a chance to see your questions, let alone try to make any suggestions; others have expressed the same issue
16:43Company: I disappear when I go to bed, yeah
16:43gfxstrand: I'd recommend setting up a bouncer of some sort.
16:44pepp: robclark, digetx: virtio_gpu_do_fence_wait uses "submit->fence_ctx + submit->ring_idx" as a global context id. But "fence_ctx:0 + ring_idx:1" and "fence_ctx:1 + ring_idx:0" are going to be considered the same, aren't they?
16:44Company: if I wanted to be always online, I'd use matrix
16:44gfxstrand: This place runs 24/7 and it's pretty common for the person with the answer to your question to be awake and on IRC at very different hours than you are.
16:44gfxstrand: matrix works. It's a bit clunky but lots of people use it.
16:44Company: but I explicitly do not want that
16:44gfxstrand: :'(
16:44gfxstrand: Fair.
16:45gfxstrand: I leave irssi running in a screen session on a raspberry pi and only log in when I want to be online.
16:45Company: Gnome switched to Matrix and I stopped being in Gnome's chats
16:45gfxstrand: No notifications. :D
16:46Company: yeah, and it's not a messaging game where you only get a reply after a few hours
16:46MrCooper: Company: one pitfall with glMapBuffer is that if you keep reusing the same buffer, the CPU access may implicitly synchronize to GPU access from earlier draws. GL offers some tricks to avoid that, I have to defer to others for the state of the art though
16:46Company: I use chat to have discussions
16:47MrCooper: just be aware that this way you're excluding some people who might otherwise be able to help
16:48MrCooper: which can also be frustrating for those people
16:48Company: yeah, I am aware - but it'd be hard to have discussions with those people anyway
16:48Company: like, you need to explicitly schedule that
16:49robclark: pepp: so when the ctx is created it should reserve however many ring_idx's you request so different ctx's shouldn't have overlapping fence_ctx+ring_idx
16:49Company: but I want a back-and-forth if I'm on IRC because then I can focus on the task at hand
16:50Company: and I can't do that if there's hours between replies
16:50Company: or even if it's minutes
16:50robclark: pepp: see VIRTGPU_CONTEXT_PARAM_NUM_RINGS
16:51MrCooper: k, then maybe I'll just have to try and ignore your questions if I don't happen to be around
16:51pepp: robclark: ah right, I missed that dma_fence_context_alloc was also used for PARAM_NUM_RINGS. All good then, thanks!
16:52robclark: np
16:55Company: MrCooper: my preferred method is that you either wait for me to be around and reply then, so we can chat about it - or forget about it
16:57Company: unless it's expected to just be a one-liner like "udmabuf", then there won't need to be a need for any back-and-forth
16:58emersion: i can't wait around, notice you've re-appeared, remember what i wanted to reply, just for you, sorry
16:59Company: perfectly fine, too
17:00Company: if I want a long-delay discussion where I'm sure I get an answer, I'll file an issue or send a mail
17:14lucenera: Why does SimpleDRM occupy /dev/dri/card0, but not expose it to the system (the file is not created)? My actual graphics card becomes card1, but card0 does not exist among the files.
17:14emersion: it's removed when the real driver gets loaded
17:15emersion: can't have two drivers manage the same connectors
19:26airlied: konstantin: you get a descriptor per plane
19:30alyssa: I just read oftc.irclog.whitequark.org
19:53mdnavare: airlied: danvet: Could you ack this series so I can merge it, its already r-b'd: https://patchwork.freedesktop.org/patch/558949/?series=121945&rev=3
20:02airlied: mdnavare: you should be able to push it without ack, if it's reviewed, but ack anyways
21:59Lynne: wow, radv transfer queue!
22:56acidburn: what's up guys