01:35anirudhsriniv: Are amd-gfx and dri-devel moderated lists? do i need to be subscribed to post to them? A radeon patch I sent is appearing on lore under lkml, but not under amd-gfx or dri-devel. They were addressed to all 3.
01:36airlied: yes they are moderated for non-subscribers
01:36airlied: usually a day or two someone will clear the queue
01:36anirudhsriniv: okay, I'll wait a few days and see.
14:07karolherbst: can somebody fix my mesa-clc patch to support 32 bit archs? I kinda want to land the fix soonish https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42948/diffs?commit_id=a0d8cf37d0e1f3cc83e7ab6b9fb67fafa9c92476
14:16alyssa: karolherbst: ack I guess
14:17alyssa: not shipping opencl on i386 was a conscious choice for asahi
14:17alyssa: unless this is for v3d?
14:21karolherbst: alyssa: it is for v3d :)
14:21karolherbst: it's even for 64 bit hosts
14:22karolherbst: just the GPU is 32 bit
14:23alyssa: yeah ok
14:24alyssa: "I want to run an LLM on a Rasperry Pi" statements dreamed up by the absolutely--
14:25karolherbst: alyssa: you'd be surprised how many people have their homeassistant instance on their rpi 🙃
14:25karolherbst: but for that vulkan is the better API anyway atm
14:26alyssa: stop doing fruit deserts
14:26alyssa: raspberries were not meant to be printed circuit boards
14:27karolherbst: I wonder if I'll ever bother enough to wire up CL images on v3d...
14:27alyssa: wanted fruit computers anyway for a laugh? we had that. it was called Apple
14:34tzimmermann: javierm, hi javier. the ssd130x driver is compatible with the ssd1309 chip, right?
14:44karolherbst: jasuarez: wanna test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42948 again or should I just merge it?
14:52javierm: tzimmermann: it is, yes
14:53tzimmermann: javierm, is there an DT overlay file that i could copy onto the rpi?
14:54tzimmermann: i followed your tutorial at https://blog.dowhile0.org/2024/09/27/using-an-spi-ssd1306-oled-on-fedora-with-a-raspberry-pi/ for ssd1306-spi . the ssd1309-spi seems different enough
14:58javierm: tzimmermann: unfortunately there is only a DT overlay for ssd1306: https://github.com/Hexxeh/rpi-firmware/blob/master/overlays/README#L3141
14:58javierm: you could create one based on that and just change the compatible string
14:58javierm: or even give it a try to that one and see if it works, there are only small differences between ssd1306 and ssd1309
14:59javierm: tzimmermann: for the SPI, you can pass as params the GPIO to use for dc_pin, reset_pin, etc
15:00javierm: tzimmermann: and yeah, the SPI pins are labeled and ordered differently depending on the panel vendor. There's no standard pinout...
15:01tzimmermann: i've checked the cable wiring. the ssd1306 doesn't work. according to https://elixir.bootlin.com/linux/v7.1.3/source/drivers/gpu/drm/solomon/ssd130x.c#L181 the ssd1309 requires slightly different parameters
15:01tzimmermann: if i see anything it is only noise
15:02javierm: I see. Sorry I misread and missed that you tested with that already
15:02javierm: tzimmermann: I only have a ssd1306 and a ssd1307. I didn't test with ssd1309.. wonder if those params are not correct
15:02javierm: I took them from the old fbdev driver
15:03tzimmermann: i see
15:07tzimmermann: it might be easier for me to get a 1306 then :)
15:09javierm: yes, those are very cheap :)
15:09javierm: tzimmermann: I need to merge some patches for ssd130x this week. I'll give it another re-test after that with latest drm-misc-next
15:10javierm: and I'll let you know if is still working for me
15:10tzimmermann: cool thanks!
15:11tzimmermann: i mostly have rgb-style hardware. i'm looking for a display with sub-byte pixel layout. the panel with your driver seems the natural choice
15:13javierm: I see. There are a few but some are for e-ink type of displays I think so this driver/panel is the natural choice indeed
15:13javierm: tzimmermann: I'm surprise how much usage and contributions I get for this simple driver, it seems the ssd130x controllers are quite popular
15:17javierm: tzimmermann: also, for your use case get the I2C display. The wiring is much easier to set up
15:17javierm: and the slower I2C is not a bottleneck, since the panel is too small anyways
15:17tzimmermann: ok, will do
15:18tzimmermann: since you mention it. i'd also be interested in an e-ink panel with DRM driver. do you know any?
15:50jasuarez: karolherbst: can't today sorry. If you want I can try tomorrow
15:53karolherbst: jasuarez: yeah, that's fine
16:38alyssa: karolherbst: math_brute_force sin failing for me on f44
16:38alyssa: do I need a newer CTS I guess?
16:38karolherbst: libclc bug :)
16:38alyssa: yeah ok
16:39alyssa: thanks
16:39alyssa:proceeds to ignore
16:39karolherbst: I guess I should get my "use our own libclc" impl thing
16:39karolherbst: alyssa: the best part: llvm-23 is already EoL :)
16:39karolherbst: and I know that I won't run after all the distros to ship patches to their libclc
16:40karolherbst: anyway.. the fix to make it work: https://github.com/llvm/llvm-project/pull/207264
16:40karolherbst: (I've only tested against cos, but I suspect sin uses the same code)
16:41karolherbst: anyway.. I should finish the "use our own libclc" bit on the mesa side to make it simple to backport: add a meson option to specify the path + instructions which libclc to build without those bugs
16:41karolherbst: and that should be easy to backport to all the versions we care
16:50alyssa: I'm still vaguely interested in us replacing libclc with vtn_bindgen2..
17:02karolherbst: yeah.. maybe long-term
17:03karolherbst: for now I just want upstream + patches and that's a bit difficult to track in-tree
17:03karolherbst: just want something that allows us to fix things that doesn't depend on upstream
22:37karolherbst: mhhh how can I install cmake targets from inside mesa 🙃
23:02karolherbst: okay.. looks like meson can't really handle it..