08:46colinmarc: <emersion> "Colin Marc: OPAQUE_FD may give..." <- Do you mean when going Vulkan -> syncobj? I already have a syncobj, I want a functional timeline semaphore.
08:46colinmarc: It does seem to be working to import it with OPAQUE_FD
08:46colinmarc: Sorry if I'm misunderstanding your point
08:51colinmarc: It seems like it would be enough to update VK_KHR_external_semaphore_fd to allow importing syncobjs with SYNC_FD, with the restriction that the semaphore be a timeline semaphore
08:51colinmarc: I guess it would also require allowing non-temporary imports for SYNC_FD
08:52colinmarc: * It seems like it would be enough to update VK_KHR_external_semaphore_fd to allow importing/exporting syncobjs with SYNC_FD, with the restriction that the semaphore be a timeline semaphore
08:57slovanada: now to receive to needed outcome or behaviour as to compress, we solve the input over a function *2 index=value+length+index-currentindex why it resolves to such formula, if divide by two of the index is 60 it means 60+60 at the addition then 60 in subtraction should lead to correct single result. In other words, 898-60=838 and 898-58 is 840 and when inputed with divide by two index 58 it's
08:57slovanada: 72 and when 60 it's 70. 898 comes as 386+116+512-116=898 or 392+386+120 so it comes back as 898-58=840 aka 72 and 898-60 aka 120 by two. I.e 120 accesses 70 and 115+1 index accesses 115.
08:58slovanada: that is the most efficient compression technology
09:03colinmarc: Couldn't find an issue, so I opened one: https://github.com/KhronosGroup/Vulkan-Docs/issues/2473
09:03colinmarc: I assume there's probably one on the khronos tracker already :)
09:19slovanada: any other function can be implemented on the idnexes but the last has the benefits of accessing the data very fast and insecure as ones might want to say.
09:31slovanada: this function provided to be foundation of the compress class is just coalescing one arithmetic to merge with other, aga matches genuinly the best performance on the least entropy.
09:52MrCooper: with mutter running on an Intel iGPU, I noticed that for alpha blending, the alpha value computed by the fragment shader seems to get quantized to 8 bpc before performing the blend operation (even if the destination format is 10 bpc)
09:52MrCooper: Is this a HW or driver limitation?
09:54dj-death: "seems" is a bit subjective ;)
09:54dj-death: maybe you have actual out values we could at
09:55dj-death: the blending is also not supposed to be done by the fragment shader but the fixed function after it
09:58MrCooper: indeed, and it looks like the quantization happens in/before the fixed function blending unit
09:58dj-death: I don't know how it's implemented in HW but it's more likely to be implemented in terms of 32bit floats (since that's the output of the fragment shader most of the time)
09:59dj-death: if your shader is using floats, I don't see how there could be a 8bpc quantization there
09:59MrCooper: it does indeed write a floating point alpha value
10:00MrCooper: gotta go, I can give more details later
10:00dj-death: unless the computation is somehow 8bpc aware :)
10:00dj-death: but then that would be an app issue
10:12jfalempe: tzimmermann: I plan to push this quick fix for drm client selection shortly on drm-misc-next, https://patchwork.freedesktop.org/patch/628512/?series=142467
10:13tzimmermann: jfalempe, sure
10:14jfalempe: tzimmermann: ok thanks, I think maybe the kconfig scripts also needs to be fixed :)
10:14tzimmermann: jfalempe, please add a commit message and a link to the bug report
10:15tzimmermann: i.e., Reported-by and Closes tags
10:15tzimmermann: and a Fixes tag
10:16tzimmermann: i was looking at the one-line patch file
10:16jfalempe: Yes, I've added the reported-by and Fixes tag, but there is no bug in bugzilla.
10:17tzimmermann: Closes should link to dan's email
10:17tzimmermann: https://lore.kernel.org/dri-devel/20241204160014.1171469-1-jfalempe@redhat.com/T/#md78853bba8904fd7614073f280f721d13ab0b432
10:18tzimmermann: checkpatch.pl will also complain IIRC
10:18jfalempe: tzimmermann: ok thanks, I will add this before pushing
10:18tzimmermann: thanks a lot
10:19tzimmermann: this will help others to find fixes and keep track of bug reports
10:25jfalempe: tzimmermann: thanks, it's now merged in drm-misc-next.
10:56sima: tzimmermann, just dropped an r-b onto your fbdev-dma regression fix
11:28tzimmermann: sima, javierm, thanks
16:39MrCooper: dj-death: never mind, I seem to have misinterpreted the results
17:25jfalempe: arnd: may I push your drm_log fix for font_config to drm-misc-next?
17:49dcbaker: hakzsam: I had to massage a couple of your commits a tiny bit to get the to apply to the staging/24.3 branch. If you could take a peek and make sure everything looks good, I'd be much obliged
17:59kisak: dcbaker: probably would have been less fight to cherry pick https://cgit.freedesktop.org/mesa/mesa/patch/?id=c2f8f20ef75a00917a652e32d4caa48029c68681 since it's the first of the set of game workarounds.
18:01kisak: ah, nevermind. That got rolled into https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/24.3&id=11f322b9500547b861ec8663f62d7810e899c487
18:05hakzsam: dcbaker: which ones?
18:06dcbaker: particularly "radv: fix initializing HTILE when the image has VRS rates"
18:06dcbaker: hakzsam: ^
18:07hakzsam: ok
18:08hakzsam: dcbaker: LGTM
18:08dcbaker: hakzsam: awesome, thanks!
21:06HdkR: Did someone do a PR for userspace submit support in some driver recently? I feel like I saw a PR somewhere for radeon or something but now I can't seem to find it
21:07alyssa: HdkR: panthor I think
21:07alyssa: https://lore.kernel.org/lkml/20240828172605.19176-5-mihail.atanassov@arm.com/T/
21:11HdkR: ah right, that was the one
21:12HdkR: I wanted to take a closelier look at it and forgot
21:16airlied: HdkR: I think there are radeonsi patches as ell
21:21HdkR: The `sync64` flag is a little spooky, but I'm currently assuming that is controlled entirely by if the firmware itself is 32-bit only or 64-bit
21:22HdkR: Rather than userspace needing to make that distinction
21:26DemiMarie: HdkR: There are patches for Panthor, amdgpu, and Xe.
21:30HdkR: Good to know, pretty sure I only caught the panthor one
21:33soreau: can userspace submit be used for mode setting too?
21:33airlied: no
21:41daniels: HdkR: it's userspace
21:47HdkR: daniels: Why is there a distinction when it's a union and 32-bit could just ensure the upper 64-bits of the address are zero?