<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`
<karolherbst>
any ideas?
<karolherbst>
I don't see that added for e.g. clc which is a C++ target and also uses dep_llvm
dviola has left #dri-devel [#dri-devel]
dviola has joined #dri-devel
bluetail has joined #dri-devel
jagan_ has joined #dri-devel
jagan_ is now known as jaganteki
vliaskov has quit [Read error: Connection reset by peer]
tales-aparecida63 has joined #dri-devel
grillo_0 has quit [Remote host closed the connection]
grillo_0 has joined #dri-devel
tonyk has quit [Remote host closed the connection]
mairacanal9 has joined #dri-devel
tonyk has joined #dri-devel
nekit1 has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
mairacanal has quit [Ping timeout: 480 seconds]
tales-aparecida6 has quit [Ping timeout: 480 seconds]
nekit has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
opotin6 has joined #dri-devel
aleasto has joined #dri-devel
invertedoftc09 has joined #dri-devel
macc24_ has quit [Remote host closed the connection]
macc24 has joined #dri-devel
Emantor_ has joined #dri-devel
aleasto- has quit [Read error: Connection reset by peer]
gallo77 has joined #dri-devel
opotin has quit [Write error: connection closed]
leandrohrb has quit [Read error: Connection reset by peer]
italove has quit [Write error: connection closed]
lfrb has quit [Read error: Connection reset by peer]
padovan has quit [Read error: Connection reset by peer]
BobBeck1 has quit [Write error: connection closed]
gallo7 has quit [Read error: Connection reset by peer]
gallo72 has quit [Read error: Connection reset by peer]
invertedoftc0 has quit [Read error: Connection reset by peer]
Emantor has quit [Ping timeout: 480 seconds]
fzwoch has joined #dri-devel
wooosaiiii has joined #dri-devel
leandrohrb has joined #dri-devel
lfrb has joined #dri-devel
italove has joined #dri-devel
BobBeck has joined #dri-devel
padovan has joined #dri-devel
gallo775 has joined #dri-devel
gallo7 has joined #dri-devel
mriesch_ has quit [Read error: Connection reset by peer]
invertedoftc096 has joined #dri-devel
Stary has quit [Read error: Connection reset by peer]
aleasto has quit [Write error: connection closed]
aleasto- has joined #dri-devel
Stary has joined #dri-devel
jannau has quit [Remote host closed the connection]
jannau has joined #dri-devel
mriesch has joined #dri-devel
yoslin has quit [Remote host closed the connection]
yoslin has joined #dri-devel
invertedoftc09 has quit [Write error: connection closed]
gallo77 has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
MajorBiscuit has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
<marex>
mripard: got any idea /wrt the circular dependency between DSIM and DSI83 ?
Leopold___ has quit [Remote host closed the connection]
nekit1 has quit []
Leopold has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
nekit1 has joined #dri-devel
jkrzyszt has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
nekit1 has quit []
nekit has joined #dri-devel
fab has quit [Read error: No route to host]
fab has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
mairacanal9 is now known as mairacanal
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<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 :)
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Zopolis4 has quit []
kts has quit [Quit: Konversation terminated!]
yuq825 has left #dri-devel [#dri-devel]
<mareko>
alright I've moved nir_lower_io_passes into the GLSL linker right after varying opts, so now I can replace the opts
<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
<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
<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.
Major_Biscuit has quit [Ping timeout: 480 seconds]
karolherbst is now known as karolherbst_
karolherbst_ is now known as karolherbst
<karolherbst>
I think strictly speaking that MR only needs llvmpipe reviews
Major_Biscuit has joined #dri-devel
tomeu has quit []
tomeu has joined #dri-devel
kts has joined #dri-devel
<mripard>
marex: actually, I don't even get the design of DSIM
<mripard>
it's not the only one, there's plenty of those calls in DSIM too
<jaganteki>
mripard: DSIM uses in imx8mm, so the imx8mm drm drivers are non-component
<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?
<jaganteki>
mripard: I will look again on samsung-dsim if any redundant's are there and fix it in next version.
<mripard>
jaganteki: that's a statement, not an explanation
<jaganteki>
This happens because of typo mistake, will remove it.
<mripard>
I was talking about "DSIM uses in imx8mm, so the imx8mm drm drivers are non-component"
fab has quit [Quit: fab]
<jaganteki>
mripard: bridges in drivers/gpu/drm/bridge doesn't use component framework and imx8mm drm drivers are non-component based.
<jaganteki>
samsung-dsim has non-component bridge handle imx8m stuff
<jaganteki>
exynos_dsi is component based and has glue code which uses samsung-dsim for bridge functionality.
<marex>
mripard: my question really is only /wrt the circular dependency, maybe we should sort that one first ?
<marex>
mripard: the DSIM host needs to look up bridge in probe, while bridge needs the host to be available in probe
<marex>
mripard: how does one deal with that
<mripard>
marex: I mean, the overall design is the reason why you have to use probe in the first place
<dcbaker>
karolherbst: maybe? isystem is such a disaster
<mripard>
dw-hdmi is a bridge, used by several drivers, and works just fine for example
<marex>
mripard: except you can't have a DSI bridge past DW-HDMI, so that's not a good example
<marex>
mripard: hm ... wait a minute, can you connect TI SN65DSI83 to VC4 ?
<marex>
mripard: I would expect that to suffer from the same probe problem
<mripard>
yes you can, precisely because I spent way too much time figuring it out and writing the doc.
<marex>
er, no, it won't because the VC4 is component based
<mripard>
so if you don't want to follow that, fine, I'm done arguing
<mripard>
move the helper into DSIM, and go ahead
<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
<marex>
mripard: the component based DSI host avoids that circular depenency
<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
<marex>
mripard: because I don't want to end up with poor DSIM driver ?
<marex>
mripard: is the suggestion to move imx to component based DSI host driver or what ?
<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
<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
<mripard>
the other part comes from the fact that you want to support component and non-component based devices
<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
<mripard>
and that's what the component framework is about
<marex>
uh, lcdif is completely separate block from the DSIM
<marex>
lynxeye: ^
<marex>
I'm really unsure why component framework would be the right choice here
gfxstrand has quit [Ping timeout: 480 seconds]
<mripard>
maybe I'm not talking about the right IP then? Is there some diagram or explanation about how it all fits together?
<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.
<lynxeye>
marex: Back to the basics: why does the DSIM need to look up the next bridge in its probe?
<marex>
lynxeye: its about the DSIM bridge v13/v14 series
<marex>
lynxeye: mripard suggested that it shouldn't happen in the host_attach callback where it is now
<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() ?
<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.
<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.
<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)
<mripard>
lynxeye: and I don't really see why we should make the component framework go away, but that's a separate discussion
<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
<karolherbst>
dcbaker: yeah.. I'm just confused why it gets added at all
<tomeu>
karolherbst: what I'm trying to do is to emit the global work offsets in the cmdstream
<karolherbst>
normal C++ targets aren't getting that
<tomeu>
tbh, I haven't found a case where that would make a difference, but the blob does it...
<karolherbst>
tomeu: you can't
<karolherbst>
well
<karolherbst>
I'm sure you can do it to _some_ degree
<karolherbst>
but the spec doens't limit this value afaik
<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
<karolherbst>
if your hardware supports full 64 bit offsets? cool I guess
<mripard>
then we got carried away by the drmm discussion, how to get the drm_device, etc.
<karolherbst>
I think supporting hw based offsets isn't a bad idea, because that gets rid of a bit of match within kernels
<karolherbst>
*math
<mripard>
but it all starts from this.
<mripard>
if you don't make that helper, I'm fine with everything else
<marex>
jaganteki: ^
<marex>
mripard: all right, let's do that for v...uh... 15 ?
<mripard>
at least it doesn't encourage a bad practice anymore, and it's isolated in a driver that is already unsafe
<tomeu>
karolherbst: oh, I think I see now what you mean
<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.
<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
<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?
<jenatali>
karolherbst: Yeah we do kernel variants already for this kind of thing
<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
<jenatali>
Also because DXIL requires local size to be a literal...
<karolherbst>
ah yes...
<jaganteki>
marex: mripard: yes, will not make helper even if it has common code due to unsafe.
<jannau>
lynxeye: I think the removal of the boot framebuffer (simpledrm) breaks it
fzwoch has quit [Quit: leaving]
<mripard>
I mean, it doesn't have any common code if it's used by a single driver.
<karolherbst>
I was also considering kernel variants for gl_sharing to support cubemap faces :pain:
<karolherbst>
but not having to do variants makes things a lot simpler
<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?
<emersion>
ready == POLLIN
<jaganteki>
mripard: i always think it is common to across all dsi panel or bridge hook, may be you are correct.
<danvet>
MrCooper, essentially we can "fix" it by moving the deadlock into the kernel :-P
<karolherbst>
ehh wait.. did I forgot to push my last changes?
<karolherbst>
I did..
kzd has joined #dri-devel
<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
<danvet>
ah cool gfxstrand with the escape hatch
<emersion>
MrCooper: ok, thx
fab has joined #dri-devel
<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
<danvet>
the earlier one before timeline semaphores were I think has the escape hatch shut off
<karolherbst>
dcbaker: pushed.. now it should trigger the bug
<danvet>
but I never remember the name
<dcbaker>
karolherbst: sweet, thanks!
<gfxstrand>
MrCooper: Yeah, it's more than deadlocks in the kernel.
<gfxstrand>
MrCooper: I just closed it. The spec text exists for EXACTLY this purpose.
<gfxstrand>
Welcome to timeline semaphores: We gave you the ability to deadlock userspace and told you the rules. Y'all broke the rules.
<MrCooper>
thanks
<gfxstrand>
The filer of the bug was fantastically self-aware and even labled it as "spec-violating"
<gfxstrand>
IDK why they went "I know, I should file the bug anyway" but that's a different question. 😅
<MrCooper>
I think he meant Mesa was violating the spec
<gfxstrand>
Oh, well that's possible. But isn't that every mesa bug, then?
<karolherbst>
you talk about deadlicking userspace and I immediately thought of CL, what's wrong with me
<jenatali>
Because CL lets you deadlock userspace too
<karolherbst>
I know :')
<MrCooper>
"deadlicking" weirdly sounds slightly less bad than "deadlocking"
pallavim has joined #dri-devel
<karolherbst>
uhhh
<gfxstrand>
Maybe to you. :-|
<zmike>
uhhh
* ccr
boggles at the concept.
bluetail9 has joined #dri-devel
<MrCooper>
yeah, on second thought it's gross
<karolherbst>
thanks for clarifying your position on this, no shaming tho
<ccr>
too much testing of Resident Evil games?
<mareko>
this is hilarious
bluetail has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
dviola has quit [Quit: WeeChat 3.7.1]
fxkamd has joined #dri-devel
ManMower has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
konstantin has joined #dri-devel
fxkamd has quit [Remote host closed the connection]
Leopold has joined #dri-devel
konstantin_ has quit [Ping timeout: 480 seconds]
dviola has quit [Quit: WeeChat 3.8]
dviola has joined #dri-devel
djbw has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<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).
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
peelz has joined #dri-devel
Major_Biscuit has quit []
peelz is now known as Guest6310
jaganteki has quit [Remote host closed the connection]
smiles has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
dviola has quit [Read error: No route to host]
nchery has joined #dri-devel
agneli has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
gfxstrand has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
OftenTimeConsuming is now known as Guest6316
OftenTimeConsuming has joined #dri-devel
Guest6316 has quit [Ping timeout: 480 seconds]
robertfoss has joined #dri-devel
gfxstrand has joined #dri-devel
jaganteki has joined #dri-devel
pallavim has quit [Remote host closed the connection]
<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>)
fxkamd has quit []
junaid has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
gouchi has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<Lynne>
any plans or anyone working on descriptor_buffers for anv?
agneli has quit [Remote host closed the connection]
agneli has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<alyssa>
whoops I deleted even more ir3 code
<Sachiel>
Lynne: yes, dj-death is torturing himself with it
* alyssa
looks at gpu
<alyssa>
so THIS is the bad place
kts has quit [Quit: Konversation terminated!]
hansg has quit [Quit: Leaving]
<Lynne>
thanks, keep it up, dj-death!
* ccr
thinks he hears "oops, I did it again" playing somewhere in the distance.
caseif_ has quit []
caseif has joined #dri-devel
nchery has quit [Quit: Leaving]
nchery has joined #dri-devel
rmckeever has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Zopolis4 has joined #dri-devel
ahajda has joined #dri-devel
<robclark>
Hazematman: so it looks like that check in dri is to differentiate btwn supporting dmabuf import vs export
<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?
<robclark>
Hazematman: but you might want to push a standalone MR with only that change, you might get more eyes on it that way
khfeng_ has joined #dri-devel
<emersion>
drmdb doesn't know about a driver which only supports one but not the other
khfeng has quit [Ping timeout: 480 seconds]
<robclark>
oh, nice, I didn't know about drmdb before
<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
jaganteki has quit [Remote host closed the connection]
<robclark>
emersion: but you are missing the mesamatrix style leaderboard :-P
<emersion>
ahah
<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
<robclark>
the pipe cap should be overriden to zero if the driver doesn't support import AND doesn't support export
<robclark>
the `u_pipe_screen_get_param_defaults()` just returns what 99% of drivers support
<emersion>
danvet: see ^, does it make sense for a driver to not support both import and export?
<emersion>
danvet: should we support import/export to save driver in DRM core?
<emersion>
to same driver*
<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?
<danvet>
emersion, I have vague memories we had that case ...
TimurTabi has joined #dri-devel
<robclark>
Hazematman: the drmGetCap() one
<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..
<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.
<airlied>
how are you installing it, into a separate prefix?
<airlied>
or using devenv?
<danvet>
emersion, maybe ask tzimmermann? maybe one of the tons of cleanups unified this
<airlied>
I'm sure we have display drivers that are import only, but a gpu driver seems less likely
<danvet>
airlied, not after the Great Refactorings
<danvet>
or at least I can't see any
Duke`` has quit [Ping timeout: 480 seconds]
ngcortes_ has joined #dri-devel
<danvet>
but yeah I have vague memories we had that case
<emersion>
guaranteed import/export to same driver would help wlroots work there
<danvet>
well not all drivers have it wired up I think
<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
<Hazematman>
robclark: I think you do throught `pscreen->get_screen_fd()`
<Hazematman>
s/throught/through/
<danvet>
ok I found at least one, udl
<danvet>
prime added in 2011, export only 2014
<robclark>
Hazematman: oh, true.. that was added recently
<robclark>
danvet: notably we are only concerned about things that have a gallium driver
<danvet>
I frankly wonder whether we shouldn't make prime mandatory ...
<danvet>
at least for DRIVER_MODESET
<danvet>
robclark, kmsro?
<robclark>
sure, but this is about whether gl can import/export
<robclark>
so the thing that matters is the gpu side of things
<danvet>
yeah, but I guess emersion also cares about the display side
<emersion>
+1 for mandatory PRIME
<danvet>
emersion, type the patch? I think at least for DRIVER_MODESET it really makes no sense not to have it
<danvet>
and with the helpers now you need to actively type to not get it
<emersion>
should we auto-add helpers?
<emersion>
probably not right?
<robclark>
modeset only could have trouble with non-contiguous but I guess the import just fails in that case?
<danvet>
you still need to pick the rights ones
<danvet>
robclark, yup
<robclark>
danvet: sure but root question was whether gallium should bother doing the drmGetCap()
<robclark>
or rather, that was what started the discussion
<robclark>
because Hazematman is adding support for kernel that isn't drm but has dmabuf (making the drmGetCap() problematic)
ngcortes has quit [Ping timeout: 480 seconds]
<danvet>
that sounds like a very funny kernel
<danvet>
I guess the android ones?
* airlied
isn't really big on making kgsl sized holes on our interfaces though :-P
<Hazematman>
Yes the android ones 🙃
<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
<agd5f>
I guess display hardware that requires CMA and render hardware that supports scatter/gather could be problematic. Ideally the CMA device would export
<robclark>
and yeah, android
<danvet>
agd5f, fails on import
<danvet>
and yeah the export should work
<robclark>
airlied: yeah, agreed.. but I think we can limit the damage to something sane
<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
<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
junaid has quit [Ping timeout: 480 seconds]
<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
<airlied>
TimurTabi: I'm not sure how clinfo works, I assume you build opencl
<airlied>
building clover or rusticl is quite intricate
<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.
<airlied>
I'd get out of /usr/local to start and make a proper install prefix
<airlied>
then you should have libRusticlOpenCL.so.1 in the lib dir
<airlied>
but you might need to copy the icd config file into place, from <prefix>/etc/OpenCL/vendors/rusticl.icd to /etc/OpenCL/vendors/
<Sachiel>
does meson devenv set stuff up for rusticl?
<airlied>
apart from /etc bit
<airlied>
if you configure rusticl
<TimurTabi>
Do I need any other meson build options to build rusticl?
alyssa has quit [Quit: leaving]
<airlied>
-Dgallium-rusticl=true -Drust_std=2021
ZenWalker has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<karolherbst>
Sachiel: yes, meson devenv just works
<emersion>
gah gma500 predates the fancy drm core stuff
ngcortes_ has quit []
ngcortes has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
gouchi has quit [Remote host closed the connection]
<mareko>
I guess I'll ask ChatGPT
<TimurTabi>
meson.build:1893:2: ERROR: Dependency "LLVMSPIRVLib" not found, tried pkgconfig
<DavidHeidelberg[m]>
TimurTabi: something like libllvmspirvlib-14-dev # replace 14 with your ver
<TimurTabi>
both 14 and 15 are available. I guess I want 15?
<mareko>
I've crashed ChatGPT
<DavidHeidelberg[m]>
mareko: congrats!
<DavidHeidelberg[m]>
TimurTabi: you want what 1. meson picks as a default or 2. what you configured as you want to build with :D
<DavidHeidelberg[m]>
for default it's 14 (on Debian testing)
wind has joined #dri-devel
<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.
<mareko>
ChatGPT gave me the correct math proof that something is always true, and then proceeded to tell me that it's not true
<psykose>
you can chat to GUID Partition Tables?
windleaves has quit [Ping timeout: 480 seconds]
ybogdano is now known as Guest6330
Guest6190 is now known as ybogdano
<DavidHeidelberg[m]>
psykose: that redundancy is sexy, everyone loves to talk to GPT :D I remember these painful experiences with MBR loss
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<psykose>
so true
<TimurTabi>
Platform Version OpenCL 1.1 Mesa 22.3.6
<TimurTabi>
woohoo! Thanks everyone
<DavidHeidelberg[m]>
TimurTabi: no CL export, shouldn't it say "Mesa 23.x" and OCL 3.x?
<TimurTabi>
hmmm
<DavidHeidelberg[m]>
this seems like you're not using the new mesa you just compiled
<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.
<DavidHeidelberg[m]>
3.0 should be rusticl
<DavidHeidelberg[m]>
oh, I see the log, you been trying to get 22.3 working, not the main branch.. so everything is fine :)
<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
Guest6331 has quit [Ping timeout: 480 seconds]
<TimurTabi>
DavidHeidelberg[m]: if I were to use the main branch, would it say something else?
<mareko>
yeah
<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.
<airlied>
TimurTabi: remove the /etc/OpenCL/vendors/mesa.icd
<TimurTabi>
Ah, that helped, thanks.
<TimurTabi>
Was the first platform mesa 22.3 with the opencl from 22.2?
<airlied>
probably some clover pieces being picked up
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
ahajda has quit [Ping timeout: 480 seconds]
<tarceri>
mareko: yeah that requirement list sounds good to me
<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