ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<RAOF>
Again, these resolve almost immediately and without me submitting any new updates.
<RAOF>
This is not a failure familiar to me, and I can't see anything obvious that I'm doing wrong. I'm hoping this is the sort of thing that a description of the symptoms leads someone to go “Oh, yeah, you haven't $FOOd”.
DemiMarie has joined #dri-devel
<DemiMarie>
<RAOF> "Ok, what am I misunderstanding..." <- Where did the dma-buf come from?
<DemiMarie>
zamundaaa: On Asahi this could also be a Mesa bug, as the driver is explicit-sync-only and implicit sync is emulated.
<RAOF>
DemiMarie: From vkgears, over linux-dmabuf protocol.
<DemiMarie>
RAOF: which driver?
<RAOF>
amdgpu and i915, (across a variety of hardware generations for i915).
<RAOF>
Others see this on non-vkgears clients, but I've not managed to reproduce the required environment.
<soreau>
RAOF: if it's oldish hw, maybe try oldish mesa to see if it solves anything?
<RAOF>
One of the systems (not mine) displaying this is Xe (_my_ i915 system is... gen8? so might be worth trying old mesa on).
<RAOF>
I see this on last-gen amdgpu, too.
<soreau>
does your amdgpu case have modifier support?
<karolherbst>
airlied: could we install a signal handler for llvmpipe compute jobs to catch sigfaults or something?
<karolherbst>
*segfault
vliaskov has quit [Ping timeout: 480 seconds]
<RAOF>
soreau: It does
karenw has quit [Ping timeout: 480 seconds]
CME has quit [Ping timeout: 480 seconds]
<karolherbst>
soo.. I think I got cross device/cross vendor SVM working 🙃
CME has joined #dri-devel
iive has quit [Quit: They came for me...]
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
mwk has quit [Remote host closed the connection]
heat is now known as Guest9248
heat has joined #dri-devel
Guest9248 has quit [Remote host closed the connection]
Lynne has quit [Remote host closed the connection]
melnary has quit [Remote host closed the connection]
melnary has joined #dri-devel
mceier has quit [Quit: Reconnecting]
mceier has joined #dri-devel
<DemiMarie>
karolherbst: Catching segfaults seems scary! What is your reasoning for doing that?
glennk has joined #dri-devel
mwk has joined #dri-devel
alane has quit []
alane has joined #dri-devel
<airlied>
karolherbst: don't I just want it to crash? ideally I'd get to finish my debuginfo support so it could have backtraces at least
<airlied>
probably would want userfaultfd support
kts has joined #dri-devel
The_Company has joined #dri-devel
kts has quit [Quit: Leaving]
Company has quit [Ping timeout: 480 seconds]
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
himal has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
dviola has quit [Quit: WeeChat 4.4.3]
sukuna has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pcercuei has quit [Quit: dodo]
kts has joined #dri-devel
The_Company has quit []
kts has quit [Quit: Leaving]
alphazone has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<jannau>
DemiMarie: zamundaaa[m] wasn't visible on irc. what did you respond to?
<DemiMarie>
jannau: The statement that they were not aware how the missing sync bug could happen.
pzanoni has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
vliaskov has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
jsa1 has joined #dri-devel
sima has joined #dri-devel
bolson_ has quit [Ping timeout: 480 seconds]
vliaskov has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
bbn has joined #dri-devel
Guest9274 has quit []
evadot has quit [Remote host closed the connection]
JLP has joined #dri-devel
evadot has joined #dri-devel
bbn has quit [Remote host closed the connection]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
sghuge has quit [Remote host closed the connection]
jsa1 has joined #dri-devel
fab has joined #dri-devel
sghuge has joined #dri-devel
fab is now known as Guest9281
Guest9281 has quit [Read error: Connection reset by peer]
fab_ has joined #dri-devel
fab_ is now known as Guest9282
kugel has quit [Ping timeout: 480 seconds]
kugel has joined #dri-devel
tarceri has joined #dri-devel
tarceri__ has quit [Read error: Connection reset by peer]
warpme has joined #dri-devel
Lynne has joined #dri-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #dri-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #dri-devel
frankbinns has joined #dri-devel
<MrCooper>
RAOF: do you set the IN_FENCE_FD property in the atomic commit? If not, it sounds like maybe the dma-buf producer didn't populate the implicit synchronization object correctly
frankbinns1 has joined #dri-devel
<MrCooper>
or if the client uses an explicit sync protocol, you might need to handle synchronization with KMS
Lynne has quit [Remote host closed the connection]
Lynne has joined #dri-devel
glennk has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
lynxeye has joined #dri-devel
vliaskov has joined #dri-devel
rasterman has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
apinheiro has joined #dri-devel
u-amarsh04 has quit []
MrCooper_ has joined #dri-devel
u-amarsh04 has joined #dri-devel
bmodem has joined #dri-devel
phasta has quit [Quit: Leaving]
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
anujp has joined #dri-devel
MrCooper_ is now known as MrCooper
<karolherbst>
airlied: that crashes also the CL CTS binary, which is kinda a pain sometimes, but yeah...
<karolherbst>
though I think there is some benefit of reporting an API error on that anyway
<karolherbst>
I mean.. sucks to have launched a kernel triggering a driver bug or just memory bug, but... I think for CL at least it would make sense to report an error, because it's not like with GUIs where you'd have broken rendering, but just an error
lsntvt has joined #dri-devel
anarsoul|2 has quit [Remote host closed the connection]
anarsoul has joined #dri-devel
phasta has joined #dri-devel
frieder has quit [Remote host closed the connection]
feaneron has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
aradhya7 has joined #dri-devel
heat has joined #dri-devel
asrivats_ has quit [Remote host closed the connection]
asrivats_ has joined #dri-devel
jkrzyszt has joined #dri-devel
warpme has quit []
rasterman has quit [Quit: Gettin' stinky!]
vliaskov has joined #dri-devel
kts has joined #dri-devel
vliaskov_ has joined #dri-devel
warpme has joined #dri-devel
asrivats_ has quit [Remote host closed the connection]
himal has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
yshui_ has joined #dri-devel
rasterman has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
rasterman has quit []
cmichael has joined #dri-devel
yshui has joined #dri-devel
yshui_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
davispuh has joined #dri-devel
bmodem has joined #dri-devel
davispuh has quit []
warpme has quit []
davispuh has joined #dri-devel
yshui has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
yshui has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
yshui has quit [Remote host closed the connection]
yshui has joined #dri-devel
pcercuei has joined #dri-devel
warpme has joined #dri-devel
Company has joined #dri-devel
rasterman has joined #dri-devel
hansg has quit [Remote host closed the connection]
hansg has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
kts has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
dolphin has quit [Quit: Leaving]
bl4ckb0ne has joined #dri-devel
pochu has quit [Remote host closed the connection]
DragoonAethis has quit [Remote host closed the connection]
mstoeckl_ has quit [Remote host closed the connection]
mstoeckl has joined #dri-devel
pochu has joined #dri-devel
ellyq has quit [Remote host closed the connection]
leandrohrb565 has joined #dri-devel
iokill has joined #dri-devel
ellyq has joined #dri-devel
DragoonAethis has joined #dri-devel
<karolherbst>
jenatali, gfxstrand: looking at https://gitlab.freedesktop.org/mesa/mesa/-/issues/12149 and there is a bit of a problem we are running into it. When vtn creates the nir_function it takes apart structs/arrays inside vtn_cfg_handle_prepass_instruction through glsl_type_count_function_params. In vtn_emit_kernel_entry_point_wrapper that's causing kind
<karolherbst>
of an issue, because the vtn function type only has the struct as an argument and not the destructed type, causing a count mismatch (e.g. 2 vs 4 in the issue), but it also fails to load the nir variable, because we use the struct type and not the destructed ones.
<karolherbst>
I have... two ideas on how to fix it, but I'm not sure which I'd like to go with...
<karolherbst>
1. turn those into function temp pointers and special case kernels inside vtn_cfg_handle_prepass_instruction
parthiban has joined #dri-devel
<karolherbst>
2. rework vtn_emit_kernel_entry_point_wrapper enough to make it work, which... could be a bit painful
leandrohrb56 has quit [Ping timeout: 480 seconds]
<karolherbst>
"entry_point->num_params" is 4 as well, so the loop kinda needs to deal with the mess there
<karolherbst>
"b->entry_point->func->type->params" is of length 2
<karolherbst>
but maybe it wouldn't be too bad...
<karolherbst>
any thoughts?
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
kts has joined #dri-devel
<jenatali>
karolherbst: it's not valid to pass structs by value to a kernel, I thought? They get passed by pointer?
<karolherbst>
it is, the spirv translator just turned them into pointers
frankbinns1 is now known as frankbinns
<karolherbst>
the source of OpenCL C++ in the bug, so maybe the compiler does things differently
<karolherbst>
at least in OpenCL C it's valid, and I don't see anything in the CL spir-v env spec to disallow it
<karolherbst>
"An OpFunctionParameter for an OpFunction that is identified with OpEntryPoint defines an OpenCL kernel argument. Allowed types for OpenCL kernel arguments are: ... OpTypeStruct"
<jenatali>
IMO unless it's tested by the CTS I don't think we can say it's intended to be valid
<jenatali>
But the spec does read that way I guess. What a pain
<karolherbst>
yeah.. but the CL spec has many gaps and that wouldn't be the first one :D
<karolherbst>
could file a CTS bug to test this
mbrost has joined #dri-devel
<karolherbst>
jenatali: I'll try to write a patch later, I think I have an idea how to deal with it in a non ugly way...
kts has quit [Quit: Leaving]
vliaskov has joined #dri-devel
epoch101 has joined #dri-devel
bolson has joined #dri-devel
dsimic is now known as Guest9315
dsimic has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
Guest9315 has quit [Ping timeout: 480 seconds]
phire has quit [Quit: No Ping reply in 180 seconds.]
<karolherbst>
I think at least in the wrapper we need to keep the struct
<karolherbst>
and then we should load members individually and translate there?
<karolherbst>
or should we make the nir functions take derefs instead?
<karolherbst>
totally forgot that clc uses the spirv to get the args, and rusticl just uses that information...
<karolherbst>
I suspect it's similar for you?
<jenatali>
The C abi can do either depending on calling convention. Just a question of what convention we want here
<karolherbst>
well.. there is the issue that the CL CTS verifies locations of parameters, not sure if checks struct members tho...
<karolherbst>
_but_
<karolherbst>
I think we need to ensure that the application who passes the entire struct by value ends up matching whatever we have in nir
<karolherbst>
so maybe a struct is the better approach, because that gives us the layout guarantees
<jenatali>
I mean at the entrypoint level they need to look the same, loading data out of the kernel arg buffer
<karolherbst>
the question is just, should the wrapper deconstruct the struct and translate from 1 -> N parameters, or should we change vtn?
<karolherbst>
change vtn as in, don't deconstruct struct members inside vtn_cfg_handle_prepass_instruction
<karolherbst>
glsl_type_count_function_params and glsl_type_add_to_function_params are the functions doing that specifically
<karolherbst>
but I suspect that could require changes all over the place
<jenatali>
I don't feel strongly either way about what the wrapper should do tbh. MSVC for example has a small struct optimization which can decompose a struct function arg into registers, otherwise it allocates a copy and passes a poonter
<jenatali>
We can do either and be correct
<karolherbst>
yeah.. nir will end up promoting the entire thing to SSA values as long as there aren't funny pointers around
<jenatali>
I didn't know that nir already decomposed structs into members for function args
<karolherbst>
me neither
<karolherbst>
it also does it for arrays
<karolherbst>
but arrays are illegal as kernel args...
<karolherbst>
but a struct with a member is 🙃
<karolherbst>
*an array member is I think
<karolherbst>
huh..
<karolherbst>
actually it's not
<karolherbst>
but yeah anyway... maybe I just make it the wrappers problem, then I don't risk regressing vulkan or whatever else
<jenatali>
Yeah that seems fine. It needs to load from the kernel arg buffer into the individual struct members to pass them to the main kernel which expects decomposed structs
<karolherbst>
yeah
<karolherbst>
I'm happy to keep CL nonsense in a single place :D
<jenatali>
Hm how would that work if the kernel tries to take the address of the struct and do pointer math?
<karolherbst>
I suspect the compiler is doing something else then
<karolherbst>
like the arg isn't a pointer
<jenatali>
Would be good to verify. I suspect we'll just end up with broken nir
<karolherbst>
well.. can you take the address of a function parameter in spirv?
<jenatali>
I dunno
<karolherbst>
I think the compiler would have to copy to a temporary variable and create a pointer to it
<karolherbst>
and then risking violating the CL spec
<jenatali>
Would be good to confirm
<karolherbst>
yeah.. I left a comment on the issue, because I wouldn't know how to compile clcpp code anyway
<jenatali>
Can't Clang do it?
<karolherbst>
I have no idea
fab has joined #dri-devel
fab is now known as Guest9318
epoch101 has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
epoch101 has quit []
epoch101 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
warpme has quit []
phasta has quit [Quit: Leaving]
kts has quit [Quit: Leaving]
Haaninjo has quit [Quit: Ex-Chat]
rgallaispou has quit [Read error: Connection reset by peer]
cmichael has quit [Quit: Leaving]
rasterman has quit [Ping timeout: 480 seconds]
epoch101 has quit []
rasterman has joined #dri-devel
sukuna has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
tzimmermann has quit [Quit: Leaving]
frankbinns has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
rasterman has joined #dri-devel
feaneron has quit [Quit: feaneron]
warpme has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pzanoni_ has joined #dri-devel
pzanoni_ has quit []
pzanoni_ has joined #dri-devel
yshui has quit [Read error: Connection reset by peer]
pzanoni_ has left #dri-devel [#dri-devel]
pzanoni has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
ao2_collabora has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
lynxeye has quit [Quit: Leaving.]
anujp has joined #dri-devel
epoch101 has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
frieder has quit [Remote host closed the connection]
feaneron has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
hansg has quit [Quit: Leaving]
warpme has quit [Ping timeout: 480 seconds]
luc has quit [Quit: Connection closed for inactivity]
CME_ has joined #dri-devel
CME has quit [Ping timeout: 480 seconds]
yshui has joined #dri-devel
yshui has quit [Read error: Connection reset by peer]
epoch101 has quit []
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
epoch101 has quit []
yshui has joined #dri-devel
<karolherbst>
so yeah... it seems like the spirv was generated with something entirely different 🙃 anyway... I think it's valid so we kinda need to support it (and make the CL CTS test it)
frankbinns has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
gouchi has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<Lynne>
dj-death: could you investigate what happens on intel with the ffv1_vulkan encoder I wrote?
<Lynne>
I've eliminated everything except the uint8_t BDAs that the entropy coding system uses
warpme has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
<dviola>
emersion: thanks for commenting on the bug report: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3921 -- about the mesa bug, sounds possible... in prior tests I seem to remember that /usr/lib/dri/virtio_gpu_dri.so was being loaded in the guest, I don't understand why it isn't anymore
<dviola>
but then again I tested the previous mesa version I was using and that also gave the issue
karenw has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
jhli has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
kzd has quit []
kzd has joined #dri-devel
Calandracas has joined #dri-devel
<dj-death>
Lynne: maybe if you had a simpler reproducer
Calandracas_ has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
warpme has joined #dri-devel
mbrost has joined #dri-devel
<karolherbst>
mhh, for the case I want to load an entire nir_variable (it's a struct) into SSA values, do we have a helper function to to a DFS over the struct fields and load them all as ssa values?
Guest9318 has quit []
warpme has quit [Ping timeout: 480 seconds]
sukuna has quit [Ping timeout: 480 seconds]
melnary has quit [Remote host closed the connection]
melnary has joined #dri-devel
melnary has quit [Remote host closed the connection]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<karolherbst>
jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12149#note_2657643 wasn't too bad. I'll give it a try tomorrow through the CTS, but I think that's a fairly straight forward change. Apparently the reason the spirv-translator is using the variable approach, is due to LLVM internal ABI reasons 🙃
<RAOF>
MrCooper: No, I do not set IN_FENCE_FD (we don't have the synchronisation proto hooked up). Good to know that implicit sync is _meant_ to be working here!
warpme has joined #dri-devel
docmax_ has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
docmax has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
<jenatali>
karolherbst: Yeah that looks pretty reasonable to me
warpme has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
zamundaaa[m] has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
jenatali has quit [Ping timeout: 480 seconds]
x512[m] has quit [Ping timeout: 480 seconds]
heftig has quit [Ping timeout: 480 seconds]
tomeu has quit [Ping timeout: 480 seconds]
robertmader[m] has quit [Ping timeout: 480 seconds]