ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
iive has quit [Quit: They came for me...]
danvet has quit [Ping timeout: 480 seconds]
krushia has quit [Read error: Connection reset by peer]
Haaninjo has quit [Quit: Ex-Chat]
smiles has joined #dri-devel
<mareko> tarceri: I'm trying to move the nir_lower_io_passes call closer to it, wish me luck
vliaskov has quit []
pcercuei has quit [Quit: dodo]
dviola has left #dri-devel [WeeChat 3.7.1]
co1umbarius has joined #dri-devel
dviola has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
danilo has joined #dri-devel
dakr has quit [Read error: Connection reset by peer]
danilo has quit []
dakr has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
moony has joined #dri-devel
probablymoony has quit [Ping timeout: 480 seconds]
<kode54> karolherbst: sorry for nitpicking a single comment with a typo
<karolherbst> ehh...
<karolherbst> I now, I was too lazy to fix it :D
<karolherbst> *know
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
<kode54> hi
<kode54> llyyr: you need CONFIG_CHECKPOINT_RESTORE
<kode54> it's the only way to enable KCMP, which is needed to see if two different fds refer to the same file
aravind has joined #dri-devel
<karolherbst> airlied: lp_vec_add_offset_ptr is wrong
<karolherbst> it hard codes 64 bit int types
<karolherbst> if you don't write a patch until I wake up tomorrow, I'll submit an MR
Zopolis4 has joined #dri-devel
krushia has joined #dri-devel
bmodem has joined #dri-devel
smiles has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
ngcortes has quit [Quit: Leaving]
aravind has quit [Read error: Connection reset by peer]
Mangix has quit [Remote host closed the connection]
Mangix has joined #dri-devel
smiles has joined #dri-devel
phire has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
phire has joined #dri-devel
smiles has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
smiles has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
Mangix has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
jagan_ has quit [Remote host closed the connection]
kzd has quit [Quit: kzd]
Zopolis4 has quit []
jagan_ has joined #dri-devel
<khfeng> can someone please see if this is ready to be merged: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20449
itoral has joined #dri-devel
mvlad has joined #dri-devel
bgs has quit [Remote host closed the connection]
quantum5 has quit [Quit: ZNC - https://znc.in]
quantum5 has joined #dri-devel
fab has joined #dri-devel
kts has joined #dri-devel
aravind has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
camus1 has joined #dri-devel
fab has quit [Quit: fab]
jagan_ has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nchery is now known as Guest6257
nchery has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
Mangix has joined #dri-devel
frieder has joined #dri-devel
Guest6257 has quit [Ping timeout: 480 seconds]
nchery is now known as Guest6258
nchery has joined #dri-devel
jagan_ has joined #dri-devel
danvet has joined #dri-devel
Guest6258 has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
tzimmermann has joined #dri-devel
Mangix has joined #dri-devel
hansg has joined #dri-devel
nchery is now known as Guest6259
nchery has joined #dri-devel
jagan_ has quit [Quit: Page closed]
jagan_ has joined #dri-devel
jkrzyszt has joined #dri-devel
Guest6259 has quit [Ping timeout: 480 seconds]
nchery is now known as Guest6260
nchery has joined #dri-devel
fab has joined #dri-devel
MajorBiscuit has joined #dri-devel
bluetail has quit [Quit: The Lounge - https://thelounge.chat]
Guest6260 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
nchery is now known as Guest6261
nchery has joined #dri-devel
ahajda has joined #dri-devel
nchery is now known as Guest6262
nchery has joined #dri-devel
Guest6261 has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
jagan_ has quit [Remote host closed the connection]
Guest6262 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest6264
srslypascal has joined #dri-devel
bluetail has joined #dri-devel
Guest6264 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
lynxeye has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
Company has joined #dri-devel
JohnnyonFlame has joined #dri-devel
pcercuei has joined #dri-devel
gfxstrand has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
gfxstrand has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
sgruszka has joined #dri-devel
Zopolis4 has joined #dri-devel
Haaninjo has joined #dri-devel
V has quit [Remote host closed the connection]
V has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
djbw has quit [Remote host closed the connection]
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
bluetail has quit [Quit: The Lounge - https://thelounge.chat]
Haaninjo has quit [Quit: Ex-Chat]
<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> like
<mripard> why?
<mripard> also, DSIM will apparently probe just fine without waiting for exynos' DSI bind
<mripard> so why is it even a component driver
<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.
gfxstrand has joined #dri-devel
<karolherbst> tomeu: not for CL sadly
<karolherbst> it's a lavapipe only thing anyway
<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.
<emersion> MrCooper: maybe you have an idea? ^
<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?
<MrCooper> emersion: I'm not sure, but in mutter!1880 I'm waiting for all of them just in case
<dcbaker> karolherbst: I have an idea, but I won’t have time to look till later
<karolherbst> okay, cool!
<danvet> MrCooper, yeah I think that's the one
<danvet> gfxstrand, ^^
<MrCooper> haasn: ^
<karolherbst> dcbaker: in case you need a simple reproducer: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21612
<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]
jkrzyszt has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest6318
srslypascal has joined #dri-devel
Guest6318 has quit [Ping timeout: 480 seconds]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
Hazematman has joined #dri-devel
fxkamd has joined #dri-devel
<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]
alyssa has joined #dri-devel
Haaninjo has joined #dri-devel
<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
<TimurTabi> airlied: sudo ninja -C builddir/ install
<TimurTabi> like the instructions say
<agd5f> danvet, right, problematic in the sense that it wouldn't work unless you explicitly picked the right exporter and importer
<Hazematman> Thanks robclark!! Yeah that feels like a more sane solution to me that wouldn't destroy the interface
<airlied> TimurTabi: but what --prefix on the meson line did you use?
<robclark> yeah
<airlied> TimurTabi: you have to set LD_LIBRARY_PATH to point to the installed libdir
<TimurTabi> The web page just says this:
<TimurTabi> The general approach is:
<TimurTabi> meson setup builddir/
<TimurTabi> ninja -C builddir/
<TimurTabi> sudo ninja -C builddir/ install
<danvet> agd5f, yeah but that's not new
<danvet> it might fail at a) import time b) addfb2 time c) modeset time
<danvet> and all for legit reasons
<agd5f> yup
<danvet> legit as in drivers which really can't reject it earlier because it would break certain use-cases
<TimurTabi> airlied: so no --prefix. It seems to have installed everything in /usr/local/
<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
<airlied> TimurTabi: okay not the greatest instructions, rarely do you want things in /usr/local :-)
<danvet> but otherwise I think helpers are unified enough that there's really no reason not to support it
<TimurTabi> airlied: So what should I have done?
fab has quit [Quit: fab]
<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
<mareko> math people, is this true? interp(x) + interp(y) = interp(x+y), same for * and fma and any combination of those
<airlied> TimurTabi: yes so normally I'd recommend not replacing your system mesa at all, unless you have a good reason
<mareko> hoping to do algebraic opts across shaders
<airlied> and just --prefix to somewhere and set LD_LIBRARY_PATH to <install>/lib
<TimurTabi> airlied: export LD_LIBRARY_PATH=/usr/local/lib
<TimurTabi> that didn't seem to work.
<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
<karolherbst> airlied: if you have time, mind looking at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21604 ?
ybogdano has joined #dri-devel
ZenWalker has joined #dri-devel
<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
<DavidHeidelberg[m]> *expert
srslypascal is now known as Guest6331
srslypascal has joined #dri-devel
<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
Zopolis4 has quit []