03:00 xeyler: can i get some feedback on this patch? https://lore.kernel.org/lkml/20250624062728.4424-1-me@brighamcampbell.com/
03:07 xeyler: assuming no change is necessary and the change is agreeable, i'd like to see the patch considered before the deadline for 6.17
03:54 Shibe: Hi, I was wondering it if is correct that when importing dmabufs with implicit modifiers you should not use VK_EXT_image_drm_format_modifier at all. In my case trying to import an image with the modifier set to FORMAT_MOD_INVALID seems to not work, but removing ImageDrmFormatModifierExplicitCreateInfo from the pnext chain in createImage works
11:06 karolherbst: zmike: any good reason why zink_fence_server_signal is flushing the context?
11:08 karolherbst: though doesn't really matter as long as it's not stalling
12:04 zmike: required by spec
12:21 karolherbst: I see... how can I check the status of a binary semaphore? I see how I can do that for a timeline one, but binary?
12:21 glehmann: you can't
12:22 glehmann: binary semaphores weren't meant for device->host sync, only device->device
12:22 glehmann: you had to use fences for device->host
12:24 karolherbst: I don't want to sync
12:24 karolherbst: I just want to know if they are signalled
12:24 glehmann: well you can't know that either
12:25 karolherbst: mhhh.. maybe I can kinda fake it enough
13:12 demarchi: agd5f: I think you left a broken drm-tip when resolving conflict for d2f9002426a7 ("drm/amd/display: Fix annotations for dc state functions")
13:13 agd5f: demarchi, I didn't touch anything to drm-tip
13:14 demarchi: this commit went to drm-next, right?
13:14 agd5f: yeah
13:15 demarchi: so when drm-next got merged in drm-tip it had the wrong commit resolution... not by you then?
13:16 agd5f: yeah
13:22 alyssa: jnoorman: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13481 *sweats*
13:32 sima: demarchi, probably airlied in one of the commits last week
13:33 sima: 283ac96f108ceee3b57799856c33cfb57dcaa695 probably
13:33 demarchi: yep... Merge remote-tracking branch 'drm/drm-next' into drm-tip
13:33 sima: oh it's in the actual tree, not just drm-tip?
13:34 demarchi: apparently the merge back in drm-tip is wrong
13:35 demarchi: I looked at that commit in rerere, but it's not there
13:35 demarchi: it's in dc.c that is not in that image
13:38 tzimmermann: javierm, i bought an ssd1309 display for the rpi. do i need to do anything to get it to work?
13:39 demarchi: sima: did you fix it?
13:41 sima: demarchi, what's even broken, I missed that part?
13:41 demarchi: dc_get_host_router_index() is implemented twice
13:42 demarchi: I was doing a rebuild-tip here but didn't find it there... I think I was checking the wrong tree, let me do it again
13:46 sima: demarchi, I think this needs a manual fixup, git doesn't even show it as a conflict
13:46 sima: at least not with git show --remerge-diff
13:46 sima: or I'm blind
13:46 sima: demarchi, are you on that fixup or should I?
13:46 demarchi: yes... what I didn't understand was why it was not a conflict... doesn't make much sense
13:46 sima: agd5f, ^^ did sfr not spot this ahead?
13:46 demarchi: on it, about to commit
13:46 sima: demarchi, thx a lot!
13:47 sima: demarchi, yeah me neither, no idea how git got confused on this, but it seems to
13:47 demarchi: we have these commits involved: 29e178d13979cf, 3251b69b7efb82 and then a fix in 158b9201c17fc9
13:47 jnoorman: alyssa: nasty 😬 It might be too heavy handed but `nir_opt_gcm` does seem fix simple cases I've tried.
13:47 sima: yeah
13:48 sima: and 325... even has the nice cherry-picked from annotation (thanks agd5f for doing these now again)
13:48 sima: demarchi, somehow git blame also believes 4465dd0e41e82 sits in there for some reaso
13:49 alyssa: jnoorman: yeah, it just also has random effects on performance (:
13:50 alyssa: anholt: ^ might be worthwhile trying nir_opt_gcm against your turnip trace set
13:51 alyssa: if we can just enable GCM and end up no worse off, we don't have to solve the hard problem :p
13:51 demarchi: sima: should be fixed now
13:52 sima: demarchi, thx
14:38 javierm: tzimmermann: it should be supported by the driver, although I only have ssd1306s. You need to add a dtoverlay= entry in your config.txt
14:38 javierm: tzimmermann: https://blog.dowhile0.org/2022/08/18/using-an-i2c-ssd1306-oled-on-fedora-with-a-raspberry-pi/ and https://blog.dowhile0.org/2024/09/27/using-an-spi-ssd1306-oled-on-fedora-with-a-raspberry-pi/
14:39 javierm: but https://github.com/raspberrypi/firmware/blob/master/boot/overlays/ only has dtbo for ssd1306. Looking at the contants for the variants is mostly the same, you could try using these
14:40 javierm: tzimmermann: if that doesn't work, you might need to compile your own dtbo that use compatible = "solomon,ssd1309" for the DT nodes
14:46 tzimmermann: javierm, thanks
14:47 tzimmermann: that will certainly help
14:48 javierm: tzimmermann: cool, let me know if you find any issues
14:49 tzimmermann: javierm, i have not received it. it's only 2 colors. i wonder if i'll be able to recognize anything on the screen
14:51 javierm: tzimmermann: it's 2 colors but because the pixels have fixed colors (e.g: a few lines in yellow and the rest in blue)
14:52 javierm: from a SW point of view is just R1 (1 color per pixel)
14:53 javierm: the ssd1306 I've one is blue-on-black for all the pixels and the other one is white-on-black
14:53 tzimmermann: right, that's what i meant. 1 bit -> 2 state. IIRC the shop had various colors to choose from
14:53 javierm: tzimmermann: right
14:55 javierm: tzimmermann: that's one thing that I pondered, how to improve the XRGB -> R1 thresholding algorithm
14:56 javierm: right now, the threshold is 128 for all the pixels, but it could be smarter
14:56 robclark: karolherbst: any opinions about whether we should support (swallow) -qcom-accelerate-16-bit and things like that? Apps tend to decide to use blob cl flags when they encounter a qc device
14:57 karolherbst: robclark: if we can just ignore them then we can just ignore them
14:57 karolherbst: ohh I thought I already landed that one intel one...
14:58 robclark: I _think_ we can
14:58 javierm: tzimmermann: https://en.wikipedia.org/wiki/Otsu%27s_method for example seems to be much smarter and could led to better results
14:59 javierm: tzimmermann: but I'm unsure if improving the naive algorithm in drm_fb_gray8_to_mono_line() is worth the effort
14:59 karolherbst: `-cl-intel-greater-than-4GB-buffer-required` is the one I was thinking about...
14:59 karolherbst: but uhm.. we can't support buffers that huge anyway oops
15:00 karolherbst: robclark: what's -qcom-accelerate-16-bit doing?
15:00 tzimmermann: javierm, i'll have some time available later this year for experimenting. i currently intent to spend it on dithering the results from the xrgb8888_to_ conversion helpers
15:00 karolherbst: but yeah.. we _can_ support them it's just a bit messy if there aren't published extensions for it and it's just "check our docs for details" or even worse, no docs
15:01 javierm: tzimmermann: ah, that would be great
15:01 tzimmermann: thanks for the link
15:01 tzimmermann: my biggest concern is performance overhead
15:02 robclark: karolherbst: I think just enabling/disabling fp16 lowering.. so far I've been hacking apps to not pass it so I guess we can remove it
15:02 karolherbst: huh...
15:02 karolherbst: what's the reason for it?
15:02 karolherbst: like 16 bits can be slower sometimes and applications should have control or what's up?
15:02 javierm: tzimmermann: honestly, I wouldn't be that worried about that since I'm pretty sure that the bottleneck is data transfer more than compute in most cases
15:03 javierm: tzimmermann: for example, in my rpi4 I see a huge difference in the I2C vs SPI displays
15:03 karolherbst: feels like uhm.. maybe we should just eat the flag and ignore it indeed if it's just a hint
15:03 karolherbst: I'm more concerned if those flags impact correctness
15:03 tzimmermann: javierm, i'm concered about fetching the data from the source buffers. some of that is currently handled as uncached memory. we can fix that, but still...
15:04 tzimmermann: writes remain the same AFAICS
15:04 tzimmermann: but i've really not spent time on it; except for basic research and some general thoughts
15:05 javierm: tzimmermann: I could play gameboy advance games using retroarch in the SPI displays but the I2C is unusable for that. It's only usable as a VT with fbcon
15:05 tzimmermann: haha
15:05 javierm: that's why my gut feeling is that even if the memory is uncached, it should be fine and the bottleneck will be the data write to the chip VRAM using I2C/SPI commands
15:06 tzimmermann: i guess, we could add suport for Cn and Rn formats to weston and emulators for simple displays. might make a difference
15:07 javierm: tzimmermann: yeah but as a said, even the drm_fb_xrgb8888_to_mono() didn't look like the problem and more the I2C writes being slow
15:07 javierm: but I've to admit that only tested on an rpi4, not on less powerful arm boards
15:09 tzimmermann: BTW, did you see the 8-bit patchset for vesadrm?
15:09 sima: agd5f, https://paste.debian.net/hidden/f199e6e2/ amdgpu seems to be unhappy with !CONFIG_DEBUG_FS
15:10 agd5f: sima, will take a look. thanks
15:10 sima: agd5f, might also be an artifact of drm-tip or something, dunno
15:10 sima: also on aarch64
15:11 tzimmermann: if you haven't, could you add it to your todo list for friday reviews? :)
15:15 tagr: hm... is anyone else seeing merge conflicts when rebuilding drm-tip for drm-misc?
15:15 tzimmermann: its conversion to rgb332 is not great, but still recognizable. it could also benefit from dithering
15:15 tzimmermann: javierm ^
15:18 jenatali: zmike: Merging !35900 now, then if you're cool with it, I'll rebase your fence branch and add fixups. Want them as separate fixup commits or should I squash 'em in?
15:19 zmike: squash pls
15:19 zmike: and thanks
15:19 jenatali: 👍
15:28 robclark: karolherbst: google'ing for "-qcom-accelerate-16-bit=false" gives me an AI summary of what that flag may (or may not be).. but not really much else.. I suspect it is something that people just copy/paste all over the place, so just ignoring it is probably ok
15:28 karolherbst: yeah, that's why I hate those flags :D
15:47 javierm: tzimmermann: I've it in my TODO :) sorry that I couldn't review it before
16:30 jenatali: zmike: Hopefully that looks okay
16:32 zmike: jenatali: can you tl;dr me on what if anything you changed outside of d3d12/mft?
16:33 jenatali: That's pretty much it. Added one field to a pipe video struct for a fence value, and deleted the set_timeline_fence_value
16:35 zmike: jenatali: seems good
16:35 zmike: I think we're good to go
16:38 jenatali: zmike: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/79935061 I think this is from you, not me
16:39 zmike: ugh
16:49 zmike: I'm not even sure where that comes from
16:50 zmike: mareko / idr: where does extension ordering come from to fail this test https://gitlab.freedesktop.org/mesa/mesa/-/jobs/79935061
16:50 jenatali: Oh it fails on Windows too. Need me to debug?
16:50 zmike: it's something with xml I think
16:51 zmike: but I'm not sure where the ordering is determined
16:52 jenatali: zmike: it's extensions_table.h
16:52 zmike: oh is it?
16:52 jenatali: NV_timeline_semaphore is at the end of the NV list, it needs to be in the middle
16:52 zmike: I see
16:52 zmike: there, fixed
16:52 zmike: hopefully
16:55 idr: zmike: If you do 'ninja test' locally, you will know if you got it right.
16:56 zmike: it passes, so I guess I did
17:04 tzimmermann: javierm, no worries
17:08 karolherbst: If I have a vulkan semaphore exported via VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT, can I import it with pipe_context::create_fence_fd and type == PIPE_FD_TYPE_NATIVE_SYNC?
17:09 agd5f: sima, looks like Sunil's MQD patches in drm-misc. Will ask him to fix it up
17:09 zmike: karolherbst: I think that would be PIPE_FD_TYPE_SYNCOBJ
17:09 sima: agd5f, thx
17:10 zmike: or at least that's what it is in zink
17:50 cmarcelo: I've noticed some strange username in GitLab, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35928 (see the last push). Folks know what this is about?
17:51 cmarcelo: (will re-ask on #freedesktop)
17:59 idr: No idea. That's odd.
18:04 mattst88: it looks like it added your R-b tag to the commit summary
18:04 mattst88: that's cool
18:04 cmarcelo: in #freedesktop karol says is something the MR author set it up. I'll ask sushma later.
18:15 karolherbst: zmike: huh... interesting
18:15 karolherbst: zmike: like there is also the syncobj fd thing so...
18:16 karolherbst: VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR
18:16 karolherbst: but if it's supposed to map to PIPE_FD_TYPE_SYNCOBJ that's fine with me, just surprising
18:18 karolherbst: heh... that works
18:18 karolherbst: guess I do more digging
18:33 karolherbst: ohh.. VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT can't be used on binary semaphores.. annoying
19:46 zmike: jenatali: were you looking at the remaining build issues?
19:49 jenatali: zmike: was there more?
19:49 jenatali: I thought it was just that test failure
19:49 zmike: I guess I'll run the pipeline and see
19:49 zmike: I think this might be my first full GL extension impl
19:49 zmike: very exciting
19:58 zmike: jenatali: seems like there's some d3d12 errors
19:58 zmike: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/1465492
20:03 jenatali: Ahhh Linux build, got it
20:04 jenatali: static function defined but never used. Just go ahead and delete it
20:04 jenatali: I can do it if you want, I just don't want to stomp your branch with a force-push unless you want me to :)
20:05 zmike: stomp away
20:05 zmike:is couch-moded
20:05 jenatali: Ack
20:29 zmike: nice, looks like it's all green now
20:31 jenatali: Great. Missing anything before merging?
20:32 zmike: don't think so
20:32 zmike: just have to apply the rbs and acks
23:24 karolherbst: Can I import fences from pipe_screen::fence_get_fd only with the PIPE_FD_TYPE_NATIVE_SYNC type?
23:25 karolherbst: kinda hoped I could use PIPE_FD_TYPE_SYNCOBJ for everything, but that doesn't work to well
23:26 zmike: I think you can do whatever drivers support
23:27 karolherbst: well.. iris requires PIPE_FD_TYPE_NATIVE_SYNC, but maybe I just add an argument to fence_get_fd to be explicit? dunno...
23:28 karolherbst: none of this is really documented, so it's all a guessing game anyway..
23:32 karolherbst: also.. it doesn't seem like drivers would tell what they support