08:52 jani: mripard: mlankhorst: tzimmermann: which branch should I push this to? https://lore.kernel.org/r/20250514063511.4151780-1-feijuan.li@samsung.com
09:06 javierm: jani: does it need a Fixes tag?
09:07 tzimmermann: jani, javierm, yeah. that looks like a fix for stable, but it's missing a fixes tag
09:09 jani: javierm: mmh, I guess Fixes: e85959d6cbe0 ("drm: Parse HDR metadata info from EDID")
09:09 jani: Cc: <stable@vger.kernel.org> # v5.3+
09:10 jani: drm-misc-fixes?
09:10 tzimmermann: jani, yeah
09:10 jani: thanks
09:10 javierm: jani: yeah, that sounds right
10:22 jani: tzimmermann: javierm: thanks, merged
13:26 mlankhorst: I've pushed drm-misc-next-fixes btw
15:28 tomba: Could a core maintainer have a look at "[PATCH v12 0/5] drm/atomic-helper: Re-order CRTC and Bridge ops" and ack/merge?
21:06 austriancoder: Company: GLES3 is coming along slowly, but it's moving forward steadily.
21:07 Company: good to know
21:07 Company: when we dropped GLES2, pinephone and librem5 were the 2 devices that were left behind
21:07 Company: so nice to know the librem is catching up again
21:09 Company: do you know of people who keep testing things? Not that changes in GTK break it again...
21:14 austriancoder: I only look at cts results and nightly ci runs of them
21:15 Company: yeah, it would need to be someone who regularly compiles together a build with recent Mesa/GTK and runs it
21:15 Mis012[m]: Also everything with adreno a3xx and I heard claims that a4xx is not great either. a3xx has GLES3 support but it's kinda broken, currently firefox and Gtk are known to be unusable because of triggering bugs in the driver.
21:17 Company: yeah, the pmOS people were testing that
21:17 Company: but there was nobody who was really working on it anymore
21:17 Mis012[m]: yep
21:18 Company: that's why I didn't really worry about it
21:18 Mis012[m]: well, nobody is working on a3xx
21:19 Mis012[m]: people are still using SoCs that have a3xx
21:19 Mis012[m]: although Gtk not having working hw accell will probably be the end of that
21:20 Company: well, people can keep GTK on 4.16 on those devices
21:20 Company: but yeah, sooner rather than later that's not gonna be much fun anymore
21:21 Mis012[m]: pmOS decided to force cairo renderer, I guess it works for simple apps at least
21:23 Company: I think the a3xx is pretty crappy, so it's not that much of a change
21:24 Mis012[m]: well, my device has a 540p display so in my case maybe :P
21:24 Company: to really benefit from hw accel with GTK, you need big screens (read: lots of pixels to render to) or Vulkan-capable GPus
21:26 Company: same thing on the desktop, but there's very few people who still run GPUs worse than Sandybridge
21:29 Company: the thing with GTK is that we do damage tracking, so 95% of the time it's fast enough anyway
21:29 Company: and on mobile you don't resize - which is one of the performance-relevant things
21:30 Company: and that leaves scrolling as the only thing that's slow
21:31 Mis012[m]: well, GSKPath is certainly closer to skia than to cairo, but I don't recall if that was also the case with Gtk itself using cairo backend so maybe the issue with cairo isn't even the lack of acceleration
21:33 Mis012[m]: slow scrolling is definitely sad, don't recall how bad it was
21:51 Company: GskPath isn't even done yet and always uses Cairo
21:51 Company: the shaders had issues and weren't merged in time and then we got busy with other stuff...
21:56 Mis012[m]: guess it uses Cairo much more intelligently than I did then
21:56 Mis012[m]: or maybe the speedup is in matrix manipulation
23:37 lumag: karolherbst: hei. Stupid question about RustiCL. I noticed that it has bumped some of the limits for the version checks (max_const_buffer0_size, local_mem_size). Is there any reason for that bump?
23:39 lumag: I'm asking since some of the MSM GPUs have cs_shared_mem_size fixed of 16 K (which brings them to CL 1.0). Otherwise they look like CL 1.2 at least.
23:45 karolherbst: lumag: well, the spec requires 32k for CL local memory for anything above 1.0
23:45 karolherbst: however, embedded devices only need 1k
23:46 lumag: karolherbst: so it needs to be extended with the full/embedded switch
23:46 lumag: ack :-)
23:46 karolherbst: yeah
23:47 lumag: and for the 32k I got confused by the comment in the code.
23:47 karolherbst: the selection is a bit automatic, but maybe it's better to let drivers decide if they want to go for full or embedded, but...
23:47 karolherbst: not that it matters much
23:47 karolherbst: right
23:49 lumag: Ah, it was a part of 1.2
23:56 lumag: and 1.1. But anyway, I see, where to look. Thanks!