03:48user21: noob here, I want to compile from sources + apply some patches before compiling, how do I install and how do I tell all went well and the MESA is working as supposed
04:20soreau: user21: you probably want to install to a nonstandard prefix such as /opt/mesa/, apply the patches before running meson/ninja to configure+build it
04:20soreau: Then at runtime, use LD_LIBRARY_PATH=/opt/mesa/lib/$libdir/ (actual path may vary) before starting an app that will use your patched mesa
04:21soreau: check the configure output to make sure it's configured the way you expect
04:23soreau: the runtime test will let you know it's working, e.g. `LD_LIBRARY_PATH=/opt/mesa/lib glxinfo | grep "OpenGL renderer string"`
04:24soreau: this way, you can use your patched mesa on-demand and not mess with your system mesa installation in /usr
04:25user21: thank you, I compiling on debian, having some config error like this `Run-time dependency libtizonia found: NO (tried pkgconfig and cmake)`
04:25user21: where to install these from
04:25K900: You don't need to install every single thing it asks for
04:25soreau: you will have to work out the dependencies, yes.. though you can configure mesa to build without the things you don't need
04:26soreau: check mesa/meson_options.txt for configure options
07:49sima: pinchartl, if you still need an ack for your renesas color mgmt patch: a-b: me
08:39javierm: tzimmermann: what do you think about https://lists.freedesktop.org/archives/dri-devel/2025-May/503950.html ?
09:00tzimmermann: javierm, sure why not
09:00tzimmermann: a-b me, if you want
09:05javierm: tzimmermann: IMO tiny and simple-KMS are somewhat related and likely we would like to get rid of both
09:05javierm: tzimmermann: thanks, I'll merged that patch then
09:05tzimmermann: there's one major issue in the patch, i'll commenton it
09:05javierm: tzimmermann: ah, Ok
09:05tzimmermann: tiny is for everything that has only one source file
09:06tzimmermann: so keeping it is preferred
09:06tzimmermann: simple-kms can go
09:06javierm: tzimmermann: yes I know but AFAICT it started as drivers (with one source file) but that were using simple-kms
09:07javierm: then it seems that other small drivers were added too
09:07javierm: anyways, no strong opinion to keep that dir
09:08tzimmermann: IIRC noralf made mipi-dbi and simple-kms, and several one-file drivers using them. and we had a few other one-file drivers. eventually those drivers all ended up in tiny/
09:09tzimmermann: simple-kms became independend from mipi-dbi and got adopted in other drivers.
09:09javierm: tzimmermann: I see
09:09sima: I think tiny/ just for one-file drivers independent of drivers using simple-kms makes sense
09:09tzimmermann: i did some of that actually
09:09sima: also promoting a pile of tiny drivers all from same vendor or otherwise related into their own dir/ makes sense too
09:10javierm: tzimmermann: btw, I disagree with your comment about the Kconfig symbol. AFAIK that is not an ABI, just like is not a driver file name
09:10tzimmermann: simple-kms should rathre go away or become a mipi-dbi thing again
09:10javierm: if we are moving the drivers out of tiny/ there's no point on having their symbols a TINYDRM prefix
09:10javierm: in fact, that prefix always looked weird to me and I noticed that newer tiny/ drivers don't have it
09:10tzimmermann: if you run olddefconfig ith that patch, it'll disable these drivers then
09:11javierm: tzimmermann: yes, but that is usually the case with new kernel versions and kconfig symbols change over time
09:11sima: could probably keep the old config name around doing nothing as a hidden thing and for the new one default y if DRM_TINYDRM_FOO or something like that?
09:11tzimmermann: yeah, TINY looks weird, that's why we don't use them any longer
09:11sima: for one kernel release
09:12sima: for build backwards compat
09:12tzimmermann: sima, if we can go with such a workaround, i'm all for changing the names
09:12tzimmermann: we just shouldn't do it 'because we can'
09:12sima: imo entirely fine to do, but kconfig is sometimes a heated thing
09:13javierm: sima: agreed with tzimmermann and I don't know of any case where old config symbols were kept for backward compat as you suggest
09:13sima: wouldn't be the first thing where dri-devel goes first :-P
09:13javierm: what I can tell from helping with the fedora kernel package maintanance is that both kconfig symbols and drivers .ko names change over time
09:14javierm: sima: fair :)
09:16tzimmermann: mripard, thanks for taking care of drm-misc-fixes last week
09:16javierm: sima, tzimmermann: I just found that https://docs.kernel.org/admin-guide/abi.html explicitly states that kconfig symbols are not an ABI
09:17tzimmermann: javierm, sure, but distro maintainers will curse you anyway
09:18sima: javierm, yeah, but being friendly is still nice I guess
09:18javierm: tzimmermann: yes, with my distro maintainer hat I will probably curse me but with my upstream developer hat I think that not keeping that TINYDRM prefix is the correct thing to do
09:18sima: wrt simple-kms I'd look at it as "does it help with collaboration?" and not so much whether it's technically the best thing
09:18sima: it's a midlayer, but at least the idea was to encourage the fbtft drivers to get into drm, or similar stuff
09:19tzimmermann: javierm, it says "Userspace should not rely on the presence or absence of any particular Kconfig symbol"
09:19javierm: sima: IMO having reusable helpers ease collaboration more than having a midlayer
09:19tzimmermann: is that really what we discuss?
09:19sima: javierm, yeah it's a tradeoff
09:19tzimmermann: javierm, agree
09:19javierm: for example, the panic handler can't be implemented with simple-kms
09:20sima: just wanted to bring into the discussion that the goal of simple-kms was a lot more non-technical than maybe other helpers
09:20sima: but if the more modular helps caught up, we can phase it out
09:20javierm: sima: oh, yes I can see that and it was very helpful I would guess at the time to abstract the atomic helpers away
09:21javierm: in fact, when I implemented the ssd130x driver I used it because for me was easier to wrap my head around
09:21tzimmermann: sima, to me simple-kms teaches the wrong abstractions and the wrong way of thinking. hence, i've been slowly pushing to phase it out
09:21sima: yeah it was a good sweet spot between yolo fbdev and the full atomic kms complexity
09:21javierm: but then tzimmermann did a lot of work to clean up and provide better atomic helpers and migrating away from simple-kms lead to a cleaner driver
09:21javierm: specially once I added support for other IC families from the same vendor
09:22sima: tzimmermann, yeah I think a more gradual ramp between fbtft/simple-kms and the full complexity of atomic kms is better, probably
09:22javierm: sima: we have now a lot of macros that drivers can use to define default helpers
09:22sima: yeah it's much better than years ago
09:23sima: it's just kinda hard to judge whether people can quickly whip up a driver or whether too many implied concepts are needed
09:23sima: if you know atomic kms inside out having worked on it for years
09:23sima: I'm even less qualified on that question :-/
09:24javierm: e.g,: DRM_GEM_SHADOW_PLANE_HELPER_FUNCS, DRM_GEM_SHMEM_DRIVER_OPS or DRM_FBDEV_SHMEM_DRIVER_OPS. I believe none of these existed when I first used simple-kms
09:24javierm: but tzimmermann should know since he wrote most of them :)
09:25javierm: tzimmermann, sima: going back to the kconfig symbol name discussion, I think what the ABI doc says is exactly what we are discussing:
09:25javierm: Kconfig. Userspace should not rely on the presence or absence of any particular Kconfig symbol, in /proc/config.gz, in the copy of .config commonly installed to /boot, or in any invocation of the kernel build process.
09:26javierm: tzimmermann: for me the last bit is related to kernel package maintainers
09:26tzimmermann: yeah, could be. i made a lot of the more-reusable artifacts and put them behind initializer macros. makes it easy to copy-pase a simple driver
09:26tzimmermann: javierm, fair point on that last part
09:27javierm: tzimmermann: I know is a pita and as mentioned I've suffered myself, but still upstream development should not be constrained by these...
09:28javierm: tzimmermann: and on the other topic, absolutely agreed with your approach that reusable artifacts abstracted away behind initializer macros is much better than simple-kms
09:29javierm: because it gives you both a simpler model while remaining flexible since a driver could implement its own helper(s) if needed
09:31tzimmermann: can we have one realease where we change all our kconfig symbols? just for watching the fallout and the lulz? >:-)
09:52javierm: tzimmermann: haha
16:11zmike: enunes / austriancoder: any updates on framebuffer stuff?
16:15austriancoder: zmike: can reproduce it locally and spend some time debugging .. should have something on Wednesday
16:15zmike: cool
16:15enunes: zmike: yes, something is indeed terribly broken now in the way lima manages its jobs relying on things like if cbuf == NULL
16:15zmike: 😬
16:15zmike: you should check cbuf->texture now
16:15zmike: I guess I missed some cases
16:20enunes: zmike: could be that, it's a bit hidden since it's casted to a driver struct
16:20zmike: ah
16:21enunes: but it's kinda everywhere
16:35mattst88: zmike: do you have any insights on https://gitlab.freedesktop.org/mesa/mesa/-/issues/12048 ?
16:36mattst88: I'd like to be able to move ppc/ppc64 to current mesa in Gentoo
16:36zmike: not really, I don't have anything big endian to test with
16:37mattst88: how about if you had ssh and root on an iMac G4? :)
16:37zmike: uhhhhhhhh
16:38zmike: I also don't really know how graphics work on big endian? 😬
16:38zmike: it's like component reversal or whatever I guess
16:38zmike: seems like probably it's using the wrong rgba variant or somesuch
16:38mattst88: yeah, it's gotta be some nonsense like that
17:55enunes: zmike: I think it breaks because util_framebuffer_init doesn't reset cbufs > nr_cbufs to 0, so if a new set_framebuffer_state goes with e.g. nr_cbufs=0 the previous ones remain there
17:57zmike: enunes: oh you mean if the previous state had nr_cbufs>0 and the new state is nr_cbufs=0 it doesn't unref?
17:57zmike: or ?
18:01enunes: zmike: yes that, at least that fixed the test I was working on
18:01zmike: that's the responsibility of the driver to handle
18:02zmike: the driver should only access cbufs based on the size of nr_cbufs
18:03enunes: can be, at least the existing code just checked if cbufs[0] is NULL rather than nr_cbufs so that is probably the bug
18:03zmike: ah
18:03zmike: I mean you can always call framebuffer_unreference before init if you want to ensure your state is zeroed
18:04zmike: the idea with this MR is to just get an initial implementation working on each driver and then everyone can optimize how they want
18:12zmike: austriancoder: maybe this is the same issue you have^
18:25enunes: zmike: I'm not sure if it needs to be unreferenced, but can't util_framebuffer_init set the remaining cbufs to NULL to avoid this? I think for zsbuf it already does
18:25enunes: otherwise, I think the easiest way is to do that in the driver set_framebuffer_state
18:25zmike: I suppose
18:25enunes: I also want to just figure out how to unblock that MR and this all probably needs to be reworked later
18:29zmike: okay, pushed an update which should handle that
18:30enunes: thanks, my local piglit run is still ongoing, but I think it's worth to run that through CI again since now it should at least not crash/timeout
19:25zmike: enunes: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/75729534 nice, big improvement
19:27zmike: I wonder if you're hitting the same synchronization thing some other drivers have been hitting with u_blitter
19:54enunes: zmike: I think it is, I read the commends and added a flush in lima_blit and it seems to be fixed
19:54zmike: oh great
19:54zmike: you can push to the branch if you want
19:57enunes: I'll do some more tests with it and then add a commit on top
19:57zmike: 👍
19:57zmike: thanks for figuring it out so quickly
21:08abhinav__: imre vsyrjala Hi, I had a question on https://patchwork.freedesktop.org/patch/394235/ . Can you pls point me to which section of the spec mentions "Besides power-saving, the advantages of this are that the maximum number
21:08abhinav__: of LTTPRs can only be used in non-transparent mode"
21:09abhinav__: I am unable to locate where it mentions, non-transparent mode is more power efficient and that it supports more number of LTTPRs in the DP 2.1a spec