01:01 mareko: tarceri: I'm trying to move the nir_lower_io_passes call closer to it, wish me luck
03:20 kode54: karolherbst: sorry for nitpicking a single comment with a typo
03:20 karolherbst: ehh...
03:20 karolherbst: I now, I was too lazy to fix it :D
03:20 karolherbst: *know
03:33 kode54: hi
03:33 kode54: llyyr: you need CONFIG_CHECKPOINT_RESTORE
03:33 kode54: it's the only way to enable KCMP, which is needed to see if two different fds refer to the same file
03:50 karolherbst: airlied: lp_vec_add_offset_ptr is wrong
03:50 karolherbst: it hard codes 64 bit int types
03:51 karolherbst: if you don't write a patch until I wake up tomorrow, I'll submit an MR
06:22 khfeng: can someone please see if this is ready to be merged: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20449
12:08 karolherbst: dcbaker: is there something special going on in regards to "-isystem" with C++ files in meson? I have the issue that if I pass `dep_llvm` as a dependency to my C++ bindgen target, that meson adds a `-isystem/usr/include` which then fails with `/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/cstdlib:75:15: fatal error: 'stdlib.h' file not found`
12:08 karolherbst: any ideas?
12:09 karolherbst: I don't see that added for e.g. clc which is a C++ target and also uses dep_llvm
13:28 marex: mripard: got any idea /wrt the circular dependency between DSIM and DSI83 ?
14:03 eric_engestrom: khfeng: you just need to update the commit messages with the `Reviewed-by:` tag that was given, and someone will send your MR to our merge bot :)
14:31 mareko: alright I've moved nir_lower_io_passes into the GLSL linker right after varying opts, so now I can replace the opts
14:33 karolherbst: could some iris and llvmpipe folks (and maybe gallium if you want to check out the gallium changes) review the cl_khr_image2d_from_buffer MR? There are no regressions, so it's ready to land https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20378
14:34 mareko: tarceri: just to summarize the IO optimization I'll need, do you agree? 1) dead inputs & outputs 2) propagate constants and uniforms 3) deduplicate SSAs 4) compaction
14:34 mripard: marex: I'm not sure what I can do at this point. Even my suggestion that it doesn't need to be a helper and would be easier to merge in the DSIM driver has been entirely ignored.
14:43 karolherbst: I think strictly speaking that MR only needs llvmpipe reviews
14:52 mripard: marex: actually, I don't even get the design of DSIM
14:52 mripard: like
14:53 mripard: https://github.com/openedev/kernel/blob/d2460b2b08b65bbe52736606a0aa17386da15bd8/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L92
14:53 mripard: why?
14:53 mripard: also, DSIM will apparently probe just fine without waiting for exynos' DSI bind
14:54 mripard: so why is it even a component driver
14:56 jaganteki: mripard: this is redundant and removed in next version patches, https://github.com/openedev/kernel/blob/d2460b2b08b65bbe52736606a0aa17386da15bd8/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L92
14:56 mripard: it's not the only one, there's plenty of those calls in DSIM too
14:56 jaganteki: mripard: DSIM uses in imx8mm, so the imx8mm drm drivers are non-component
14:57 tomeu: karolherbst: I'm a bit surprised by pipe_grid_info.grid_base being set always to zero, shouldn't it contain the global_work_offset of the invocation?
14:58 jaganteki: mripard: I will look again on samsung-dsim if any redundant's are there and fix it in next version.
14:58 mripard: jaganteki: that's a statement, not an explanation
14:59 jaganteki: https://github.com/openedev/kernel/blob/d2460b2b08b65bbe52736606a0aa17386da15bd8/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L92
15:00 jaganteki: This happens because of typo mistake, will remove it.
15:02 mripard: I was talking about "DSIM uses in imx8mm, so the imx8mm drm drivers are non-component"
15:04 jaganteki: mripard: bridges in drivers/gpu/drm/bridge doesn't use component framework and imx8mm drm drivers are non-component based.
15:04 jaganteki: samsung-dsim has non-component bridge handle imx8m stuff
15:05 jaganteki: exynos_dsi is component based and has glue code which uses samsung-dsim for bridge functionality.
15:05 marex: mripard: my question really is only /wrt the circular dependency, maybe we should sort that one first ?
15:06 marex: mripard: the DSIM host needs to look up bridge in probe, while bridge needs the host to be available in probe
15:06 marex: mripard: how does one deal with that
15:06 mripard: marex: I mean, the overall design is the reason why you have to use probe in the first place
15:07 dcbaker: karolherbst: maybe? isystem is such a disaster
15:07 mripard: dw-hdmi is a bridge, used by several drivers, and works just fine for example
15:08 marex: mripard: except you can't have a DSI bridge past DW-HDMI, so that's not a good example
15:08 marex: mripard: hm ... wait a minute, can you connect TI SN65DSI83 to VC4 ?
15:08 marex: mripard: I would expect that to suffer from the same probe problem
15:09 mripard: yes you can, precisely because I spent way too much time figuring it out and writing the doc.
15:09 marex: er, no, it won't because the VC4 is component based
15:09 mripard: so if you don't want to follow that, fine, I'm done arguing
15:09 mripard: move the helper into DSIM, and go ahead
15:10 marex: mripard: this is not helpful really, I am trying to find out how to solve the circular dependency for non-component based DSI host
15:10 marex: mripard: the component based DSI host avoids that circular depenency
15:10 mripard: it is helpful, I'm telling you how you can do whatever you want without me bugging you. I don't see how it's a bad outcome
15:11 marex: mripard: because I don't want to end up with poor DSIM driver ?
15:12 marex: mripard: is the suggestion to move imx to component based DSI host driver or what ?
15:19 mripard: the way I see it, DSIM shouldn't even be a driver in the first place, but a function that KMS drivers would call into that would setup and register the bridge, just like dw-hdmi is
15:19 mripard: part of the current confusion is that bind hooks are supposed to be called once the device is ready, but the DSIM probe function will be called before bind is called in exynos_dsi
15:20 mripard: the other part comes from the fact that you want to support component and non-component based devices
15:21 mripard: and I'm not entirely sure why lcdif isn't using the component framework there: it does need to aggregate multiple devices into a KMS driver
15:21 mripard: and that's what the component framework is about
15:21 marex: uh, lcdif is completely separate block from the DSIM
15:21 marex: lynxeye: ^
15:21 marex: I'm really unsure why component framework would be the right choice here
15:24 mripard: maybe I'm not talking about the right IP then? Is there some diagram or explanation about how it all fits together?
15:24 lynxeye: marex: Sorry, I'm a bit out of the loop with regard to this whole discussion. But the general trend is to move away from component framework an just handle things via probe defers when possible.
15:25 lynxeye: marex: Back to the basics: why does the DSIM need to look up the next bridge in its probe?
15:25 marex: lynxeye: its about the DSIM bridge v13/v14 series
15:26 marex: lynxeye: mripard suggested that it shouldn't happen in the host_attach callback where it is now
15:26 marex: lynxeye: for the component variant (exynos), it has to happen in component bind ; for the non-component variant (imx) it probably has to happen in probe() ?
15:26 lynxeye: Shouldn't the flow simply be DSIM probe -> register DSI host -> next bridge attaches to host on probe -> DSIM exposes own bridge to DRM when next bridge is attached.
15:27 karolherbst: tomeu: not for CL sadly
15:27 marex: mripard: https://www.nxp.com/docs/en/application-note/AN13430.pdf page 2
15:28 karolherbst: it's a lavapipe only thing anyway
15:28 mripard: lynxeye: you can't handle a DSI host through probe defer, the host itself has to be registered all the time to allow for i2c/SPI based devices to look it up and register against it.
15:28 karolherbst: so CL needs a full size_t range, and I still didn't implement the full lowering (fetching the actual hw limit and then loop over launch_grid)
15:30 mripard: lynxeye: and I don't really see why we should make the component framework go away, but that's a separate discussion
15:30 jannau: lynxeye: user space (at least gdm) doesn't handle probe defer of kms drivers well. it breaks if it wins the the race against the deferred probe. may require fast systems like apple silicon based machines
15:30 karolherbst: dcbaker: yeah.. I'm just confused why it gets added at all
15:30 tomeu: karolherbst: what I'm trying to do is to emit the global work offsets in the cmdstream
15:30 karolherbst: normal C++ targets aren't getting that
15:30 tomeu: tbh, I haven't found a case where that would make a difference, but the blob does it...
15:30 karolherbst: tomeu: you can't
15:30 karolherbst: well
15:30 karolherbst: I'm sure you can do it to _some_ degree
15:30 karolherbst: but the spec doens't limit this value afaik
15:31 mripard: marex: but really, the initial discussion started with this: putting back the panel/bridge at remove time isn't safe, we shouldn't make any helper that encourage this
15:31 karolherbst: if your hardware supports full 64 bit offsets? cool I guess
15:31 mripard: then we got carried away by the drmm discussion, how to get the drm_device, etc.
15:31 karolherbst: I think supporting hw based offsets isn't a bad idea, because that gets rid of a bit of match within kernels
15:32 karolherbst: *math
15:32 mripard: but it all starts from this.
15:32 mripard: if you don't make that helper, I'm fine with everything else
15:32 marex: jaganteki: ^
15:32 marex: mripard: all right, let's do that for v...uh... 15 ?
15:32 mripard: at least it doesn't encourage a bad practice anymore, and it's isolated in a driver that is already unsafe
15:32 tomeu: karolherbst: oh, I think I see now what you mean
15:32 lynxeye: mripard: Sure, register the DSI host all the time. But only expose the DSIM bridge once the DSI device has attached, this way the lcdif driver won't expose the DRM device until every bridge in the chain is connected.
15:33 karolherbst: the biggest pain is, if the hardware supports it partially (like a 32 bit range), that's fine on 32 bit GPUs, but if it's a 64 bit GPU you kind of have to do kernel variants, which might be a cool micro optimization anyway
15:33 lynxeye: jannau: As long as the DRM device isn't exposed to userspace before all parts of the display chain are ready, using probe defer is completely safe, isn't it?
15:34 jenatali: karolherbst: Yeah we do kernel variants already for this kind of thing
15:34 karolherbst: but before doing that, I also kind of want to add a state tracking abstraction for all the bound resources, so rusticl doesn't end up rebinding the same stuff over again and then integrated variants into that
15:34 jenatali: Also because DXIL requires local size to be a literal...
15:34 karolherbst: ah yes...
15:34 jaganteki: marex: mripard: yes, will not make helper even if it has common code due to unsafe.
15:34 jannau: lynxeye: I think the removal of the boot framebuffer (simpledrm) breaks it
15:35 mripard: I mean, it doesn't have any common code if it's used by a single driver.
15:35 karolherbst: I was also considering kernel variants for gl_sharing to support cubemap faces :pain:
15:36 karolherbst: but not having to do variants makes things a lot simpler
15:37 emersion: when an image is made up of multiple DMA-BUFs, is it necessary to wait for all DMA-BUFs to be ready? or just the first one?
15:37 emersion: ready == POLLIN
15:37 jaganteki: mripard: i always think it is common to across all dsi panel or bridge hook, may be you are correct.
15:37 emersion: MrCooper: maybe you have an idea? ^
15:38 MrCooper: danvet: if I understood our recent discussion correctly, https://gitlab.freedesktop.org/mesa/mesa/-/issues/8312 cannot be fixed without risking deadlocks in the kernel, right?
15:38 MrCooper: emersion: I'm not sure, but in mutter!1880 I'm waiting for all of them just in case
15:39 dcbaker: karolherbst: I have an idea, but I won’t have time to look till later
15:39 karolherbst: okay, cool!
15:39 danvet: MrCooper, yeah I think that's the one
15:40 danvet: gfxstrand, ^^
15:40 MrCooper: haasn: ^
15:40 karolherbst: dcbaker: in case you need a simple reproducer: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21612
15:40 danvet: MrCooper, essentially we can "fix" it by moving the deadlock into the kernel :-P
15:40 karolherbst: ehh wait.. did I forgot to push my last changes?
15:41 karolherbst: I did..
15:41 marex: mripard: I think the whole thread has been a huge communication breakdown spectacle, some people, me included, just need things spelled out in full before the discussion gets overly heated
15:41 danvet: ah cool gfxstrand with the escape hatch
15:41 emersion: MrCooper: ok, thx
15:42 danvet: MrCooper, if I got it right from all the discussion with gfxstrand there is some vk sync thing which does deadlock and we can't fix it
15:42 danvet: the earlier one before timeline semaphores were I think has the escape hatch shut off
15:42 karolherbst: dcbaker: pushed.. now it should trigger the bug
15:43 danvet: but I never remember the name
15:43 dcbaker: karolherbst: sweet, thanks!
15:44 gfxstrand: MrCooper: Yeah, it's more than deadlocks in the kernel.
15:44 gfxstrand: MrCooper: I just closed it. The spec text exists for EXACTLY this purpose.
15:45 gfxstrand: Welcome to timeline semaphores: We gave you the ability to deadlock userspace and told you the rules. Y'all broke the rules.
15:45 MrCooper: thanks
15:45 gfxstrand: The filer of the bug was fantastically self-aware and even labled it as "spec-violating"
15:46 gfxstrand: IDK why they went "I know, I should file the bug anyway" but that's a different question. 😅
15:47 MrCooper: I think he meant Mesa was violating the spec
15:49 gfxstrand: Oh, well that's possible. But isn't that every mesa bug, then?
15:49 karolherbst: you talk about deadlicking userspace and I immediately thought of CL, what's wrong with me
15:51 jenatali: Because CL lets you deadlock userspace too
15:51 karolherbst: I know :')
15:55 MrCooper: "deadlicking" weirdly sounds slightly less bad than "deadlocking"
15:56 karolherbst: uhhh
15:56 gfxstrand: Maybe to you. :-|
15:56 zmike: uhhh
15:56 ccr:boggles at the concept.
15:58 MrCooper: yeah, on second thought it's gross
15:59 karolherbst: thanks for clarifying your position on this, no shaming tho
16:02 ccr: too much testing of Resident Evil games?
16:02 mareko: this is hilarious
16:52 kisak: I'm getting caught up with mesa 23.0.0 in my PPA. Is there anything in particular that someone would like to see fast tracked into my mesa build (things between 23.0.0 point release and now).
18:58 Hazematman: Hello! I've been working on supporting the KGSL kernel mode driver in gallium/freedreno, and I've run into a bit of an issue with some dri/drm related code inside `gallium/frontends/dri`. The issue is basically that to check if the driver supports importing a dmabuf it will query the capability through libdrm. Unfortunately KGSL is not a... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/YWmYHuxvGzqYLqrqKuuaBijh>)
19:53 alyssa: cmarcelo: whoops I went deleting https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21634
19:53 Lynne: any plans or anyone working on descriptor_buffers for anv?
19:58 alyssa: whoops I deleted even more ir3 code
19:59 Sachiel: Lynne: yes, dj-death is torturing himself with it
19:59 alyssa:looks at gpu
19:59 alyssa: so THIS is the bad place
20:02 Lynne: thanks, keep it up, dj-death!
20:08 ccr:thinks he hears "oops, I did it again" playing somewhere in the distance.
21:16 robclark: Hazematman: so it looks like that check in dri is to differentiate btwn supporting dmabuf import vs export
21:17 robclark: so I'm not sure that your enum makes sense.. we could perhaps have the cap return the appropriate bitmask of DRM_PRIME_CAP_IMPORT/EXPORT directly.. but I'm kinda wondering if there is any actual gpu driver which supports only export or only import?
21:18 robclark: Hazematman: but you might want to push a standalone MR with only that change, you might get more eyes on it that way
21:23 emersion: drmdb doesn't know about a driver which only supports one but not the other
21:25 robclark: oh, nice, I didn't know about drmdb before
21:26 robclark: in that case, I'd kinda lean towards just dropping the cap query.. although maybe there is some old kernel version that supports one but not the other
21:27 robclark: emersion: but you are missing the mesamatrix style leaderboard :-P
21:28 emersion: ahah
21:28 Hazematman: robclark: thanks for the response, a separate MR makes a lot sense. What makes you think its to differentiate between import/export? The way I understood the code is that its trying to verify the underlying kernel driver had the ability to import dmabuf handles since the pipe cap doesn't actually guarantee it can. If you look in `u_pipe_screen_get_param_defaults` it sets it to `1` if you're on linux or BSD
21:30 robclark: the pipe cap should be overriden to zero if the driver doesn't support import AND doesn't support export
21:31 robclark: the `u_pipe_screen_get_param_defaults()` just returns what 99% of drivers support
21:33 emersion: danvet: see ^, does it make sense for a driver to not support both import and export?
21:33 emersion: danvet: should we support import/export to save driver in DRM core?
21:33 emersion: to same driver*
21:35 Hazematman: <robclark> "in that case, I'd kinda lean..." <- When you say dropping the "cap query all together" do mean the drm cap query or the gallium one?
21:35 danvet: emersion, I have vague memories we had that case ...
21:36 robclark: Hazematman: the drmGetCap() one
21:37 robclark: hmm, `u_pipe_screen_get_param_defaults()` doesn't have access to the fd, otherwise it would be convenient to just move the drmGetCap() call there..
21:37 TimurTabi: Hi, I have a beginning question. I'm trying to install Mesa 22.3 on Ubuntu 23.04, which currently only has 22.2. I checked out the 22.3 branch in the git repo and followed the instructions on https://docs.mesa3d.org/install.html#building-with-meson, but after a reboot, clinfo still reports 22.5. I'm guessing I'm missing something basic, but I don't know what it could be.
21:38 airlied: how are you installing it, into a separate prefix?
21:38 airlied: or using devenv?
21:39 danvet: emersion, maybe ask tzimmermann? maybe one of the tons of cleanups unified this
21:39 airlied: I'm sure we have display drivers that are import only, but a gpu driver seems less likely
21:39 danvet: airlied, not after the Great Refactorings
21:40 danvet: or at least I can't see any
21:40 danvet: but yeah I have vague memories we had that case
21:41 emersion: guaranteed import/export to same driver would help wlroots work there
21:41 danvet: well not all drivers have it wired up I think
21:41 robclark: I guess if that was the situation at some point in time, then maybe we have to keep the query to not break things on old kernel? But that seems like _such_ an unlikely corner
21:42 Hazematman: robclark: I think you do throught `pscreen->get_screen_fd()`
21:42 Hazematman: s/throught/through/
21:42 danvet: ok I found at least one, udl
21:43 danvet: prime added in 2011, export only 2014
21:43 robclark: Hazematman: oh, true.. that was added recently
21:43 robclark: danvet: notably we are only concerned about things that have a gallium driver
21:43 danvet: I frankly wonder whether we shouldn't make prime mandatory ...
21:43 danvet: at least for DRIVER_MODESET
21:44 danvet: robclark, kmsro?
21:44 robclark: sure, but this is about whether gl can import/export
21:44 robclark: so the thing that matters is the gpu side of things
21:44 danvet: yeah, but I guess emersion also cares about the display side
21:44 emersion: +1 for mandatory PRIME
21:45 danvet: emersion, type the patch? I think at least for DRIVER_MODESET it really makes no sense not to have it
21:45 danvet: and with the helpers now you need to actively type to not get it
21:45 emersion: should we auto-add helpers?
21:45 emersion: probably not right?
21:45 robclark: modeset only could have trouble with non-contiguous but I guess the import just fails in that case?
21:46 danvet: you still need to pick the rights ones
21:46 danvet: robclark, yup
21:46 robclark: danvet: sure but root question was whether gallium should bother doing the drmGetCap()
21:46 robclark: or rather, that was what started the discussion
21:47 robclark: because Hazematman is adding support for kernel that isn't drm but has dmabuf (making the drmGetCap() problematic)
21:48 danvet: that sounds like a very funny kernel
21:48 danvet: I guess the android ones?
21:48 airlied:isn't really big on making kgsl sized holes on our interfaces though :-P
21:48 Hazematman: Yes the android ones 🙃
21:48 robclark: Hazematman: but yeah, I think the `pscreen->get_screen_fd()` and do the `drmGetCap()` in `u_pipe_screen_get_param_defaults()` seems like a good option.. we can just handle the cap in freedreno to reture CAP_EXPORT | CAP_IMPORT
21:48 agd5f: I guess display hardware that requires CMA and render hardware that supports scatter/gather could be problematic. Ideally the CMA device would export
21:48 robclark: and yeah, android
21:48 danvet: agd5f, fails on import
21:49 danvet: and yeah the export should work
21:49 robclark: airlied: yeah, agreed.. but I think we can limit the damage to something sane
21:49 TimurTabi: airlied: sudo ninja -C builddir/ install
21:49 TimurTabi: like the instructions say
21:50 agd5f: danvet, right, problematic in the sense that it wouldn't work unless you explicitly picked the right exporter and importer
21:50 Hazematman: Thanks robclark!! Yeah that feels like a more sane solution to me that wouldn't destroy the interface
21:51 airlied: TimurTabi: but what --prefix on the meson line did you use?
21:51 robclark: yeah
21:51 airlied: TimurTabi: you have to set LD_LIBRARY_PATH to point to the installed libdir
21:52 TimurTabi: The web page just says this:
21:52 TimurTabi: The general approach is:
21:52 TimurTabi: meson setup builddir/
21:52 TimurTabi: ninja -C builddir/
21:52 TimurTabi: sudo ninja -C builddir/ install
21:52 danvet: agd5f, yeah but that's not new
21:52 danvet: it might fail at a) import time b) addfb2 time c) modeset time
21:52 danvet: and all for legit reasons
21:52 agd5f: yup
21:53 danvet: legit as in drivers which really can't reject it earlier because it would break certain use-cases
21:53 TimurTabi: airlied: so no --prefix. It seems to have installed everything in /usr/local/
21:53 danvet: robclark, emersion really the only reasons I'm not sure we should require prime everywhere is that it might not make much sense for accel
21:53 airlied: TimurTabi: okay not the greatest instructions, rarely do you want things in /usr/local :-)
21:54 danvet: but otherwise I think helpers are unified enough that there's really no reason not to support it
21:54 TimurTabi: airlied: So what should I have done?
21:55 TimurTabi: airlied: Oh I think I see the problem. The normal mesa is installed in /usr/lib, so the one in /usr/local/lib is just being ignored
21:56 mareko: math people, is this true? interp(x) + interp(y) = interp(x+y), same for * and fma and any combination of those
21:57 airlied: TimurTabi: yes so normally I'd recommend not replacing your system mesa at all, unless you have a good reason
21:57 mareko: hoping to do algebraic opts across shaders
21:57 airlied: and just --prefix to somewhere and set LD_LIBRARY_PATH to <install>/lib
21:59 TimurTabi: airlied: export LD_LIBRARY_PATH=/usr/local/lib
21:59 TimurTabi: that didn't seem to work.
21:59 Hazematman: TimurTabi: just as a warning if you replace the system mesa your package manager will probably not be very happy when you go to update
22:01 Hazematman: You also might need to set LD_LIBRARY_PATH in your ~/.profile and then log out and log back in to get have be replaced for your current session. If you just want to play a single game or something with the new version you can set in your terminal and then launch the game from your terminal
22:02 Hazematman: * You also might need to set LD_LIBRARY_PATH in your ~/.profile and then log out and log back in to have it be replaced for your current session. If you just want to play a single game or something with the new version you can set in your terminal and then launch the game from your terminal
22:02 airlied: TimurTabi: I'm not sure how clinfo works, I assume you build opencl
22:02 airlied: building clover or rusticl is quite intricate
22:03 TimurTabi: ugh, I'm trying to debug the geekbench bugs with rusticl, but the geekbench build instructions don't work on Fedora, and Ubuntu is stuck on 22.5.
22:05 airlied: I'd get out of /usr/local to start and make a proper install prefix
22:05 airlied: then you should have libRusticlOpenCL.so.1 in the lib dir
22:06 airlied: but you might need to copy the icd config file into place, from <prefix>/etc/OpenCL/vendors/rusticl.icd to /etc/OpenCL/vendors/
22:06 Sachiel: does meson devenv set stuff up for rusticl?
22:07 airlied: apart from /etc bit
22:07 airlied: if you configure rusticl
22:07 TimurTabi: Do I need any other meson build options to build rusticl?
22:09 airlied: -Dgallium-rusticl=true -Drust_std=2021
22:20 karolherbst: Sachiel: yes, meson devenv just works
22:20 karolherbst: airlied: if you have time, mind looking at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21604 ?
22:25 emersion: gah gma500 predates the fancy drm core stuff
22:37 mareko: I guess I'll ask ChatGPT
22:37 TimurTabi: meson.build:1893:2: ERROR: Dependency "LLVMSPIRVLib" not found, tried pkgconfig
22:38 DavidHeidelberg[m]: TimurTabi: something like libllvmspirvlib-14-dev # replace 14 with your ver
22:39 TimurTabi: both 14 and 15 are available. I guess I want 15?
22:39 mareko: I've crashed ChatGPT
22:41 DavidHeidelberg[m]: mareko: congrats!
22:42 DavidHeidelberg[m]: TimurTabi: you want what 1. meson picks as a default or 2. what you configured as you want to build with :D
22:42 DavidHeidelberg[m]: for default it's 14 (on Debian testing)
22:44 TimurTabi: Hmmm... I'm not sure what meson picked as a default, but it did say that llvm is v15, so I guess I got that right. I also had to install bindgen. So far, it seems to be working now.
22:49 mareko: ChatGPT gave me the correct math proof that something is always true, and then proceeded to tell me that it's not true
22:49 psykose: you can chat to GUID Partition Tables?
22:52 DavidHeidelberg[m]: psykose: that redundancy is sexy, everyone loves to talk to GPT :D I remember these painful experiences with MBR loss
22:57 psykose: so true
23:01 TimurTabi: Platform Version OpenCL 1.1 Mesa 22.3.6
23:01 TimurTabi: woohoo! Thanks everyone
23:06 DavidHeidelberg[m]: TimurTabi: no CL export, shouldn't it say "Mesa 23.x" and OCL 3.x?
23:06 TimurTabi: hmmm
23:06 DavidHeidelberg[m]: this seems like you're not using the new mesa you just compiled
23:06 DavidHeidelberg[m]: *expert
23:07 TimurTabi: https://www.irccloud.com/pastebin/ZNtNLcvi/
23:07 TimurTabi: There are two platforms. One is mesa 22.3 with clover, and the other is rusticl ???? I'm not sure how to read that.
23:08 DavidHeidelberg[m]: 3.0 should be rusticl
23:08 DavidHeidelberg[m]: oh, I see the log, you been trying to get 22.3 working, not the main branch.. so everything is fine :)
23:13 robclark: mareko: ChatGPT seems to do a lot better job of sounding correct than being correct.. I guess that is why it was able to pass MBA exam :-P
23:14 TimurTabi: DavidHeidelberg[m]: if I were to use the main branch, would it say something else?
23:14 mareko: yeah
23:15 TimurTabi: It's really rusticl I care about, not mesa. I was thinking I just need to be sure to use platform #2 for any opencl tests.
23:16 airlied: TimurTabi: remove the /etc/OpenCL/vendors/mesa.icd
23:17 TimurTabi: Ah, that helped, thanks.
23:18 TimurTabi: Was the first platform mesa 22.3 with the opencl from 22.2?
23:19 airlied: probably some clover pieces being picked up
23:41 tarceri: mareko: yeah that requirement list sounds good to me
23:44 tarceri: There is likely plenty of room for tweaking the NIR linkers varying implementation. The first pass was mostly about replacing glsl ir without causing regressions, with minimal work done on trying to redesign anything