llyyr has quit [Remote host closed the connection]
llyyr has joined #dri-devel
surajkandpal has joined #dri-devel
evadot_ has joined #dri-devel
apinheiro has joined #dri-devel
evadot has quit [Ping timeout: 480 seconds]
bbrezillon has joined #dri-devel
<karolherbst>
yeah....
fab has quit [Ping timeout: 480 seconds]
<karolherbst>
dj-death: so... I think we need to make the memcpy optimization smarter, but I don't really have a good idea how. Maybe we check there if we have a cast from/to something we could optimize to copy_deref there. Or like casting a struct to a primitive is kinda "normal" in compute, so we could certainly special case it there. I'm convinced that `opt_replace_struct_wrapper_cast` is only valid for a few corner cases and is only safe "by chance"
surajkandpal has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
yyds has quit [Remote host closed the connection]
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
<dj-death>
karolherbst: hmmm
pjakobsson_ has joined #dri-devel
kts has joined #dri-devel
vliaskov has joined #dri-devel
pjakobss- has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
pjakobsson_ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has quit [Ping timeout: 480 seconds]
itoral has quit [Quit: Leaving]
apinheiro has quit [Quit: Leaving]
bmodem has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
ninjaaaaa has quit [Read error: No route to host]
simondnnsn has quit [Read error: No route to host]
<karolherbst>
though I think we can only do that with explicit types and _if_ the field offset is 0
<karolherbst>
but we could probably special case it...
<karolherbst>
dunno...
<karolherbst>
gfxstrand: if you are up to taking a look at some deref stuff we need to deal with since llvm-17 or so ^^
<karolherbst>
we kinda need to do the same opt which is possible in the llvm-16 case also with llvm-17, which gives us weird casts in the middle
<karolherbst>
and I've tried converting that cast to a deref_struct, but that can mess up all sorts of other things
jernej has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
jernej_ has quit []
jernej has joined #dri-devel
<dj-death>
karolherbst: ah wtf llvm
<dj-death>
karolherbst: using 2 different pointers for the same thing...
<dj-death>
karolherbst: this looks like a pattern we would to optimize
<dj-death>
karolherbst: try to unify all the pointer cast to the same location
<dj-death>
karolherbst: but I could also see llvm trying generating different load/store
kts has joined #dri-devel
<dj-death>
like store 2 vec2, load 1 vec4
<dj-death>
maybe our vectorizer can optimize that in which case it's not an issue
rasterman has quit [Quit: Gettin' stinky!]
<MrCooper>
is DRM_IOCTL_PRIME_HANDLE_TO_FD officially supposed to work for a dumb BO?
<emersion>
yes
<MrCooper>
is DRM_IOCTL_MODE_MAP_DUMB supposed to work for any BO imported with DRM_IOCTL_PRIME_FD_TO_HANDLE, even if the original exported BO wasn't dumb?
<emersion>
i don't think so
<emersion>
like, there is "DUMB" in the name?
bolson has joined #dri-devel
<emersion>
have you found out that it happens to work in some cases?
<emersion>
dumb buffers are for modesetting purposes only!
<emersion>
is there any chance to use a DMA-heap here instead?
<emersion>
doesn't vgem has a way to allocate buffers?
jeeeun841351908 has quit [Remote host closed the connection]
<emersion>
sima, see that MR linked above
<emersion>
hm sima not here
jeeeun841351908 has joined #dri-devel
<karolherbst>
dj-death: yeah... well.. with llvm-17 there is just "pointer", not "pointer to X", so we kinda have to figure out how to map that to derefs to properly optimize. Like.. in that example, it doesn't really matter what types are involved, just that at the same logical/actual location we have a write and a read
neobrain has quit []
<cmarcelo>
karolherbst: dj-death: havent looked at details, but wonder how much that relates to *spirv* untyped ptrs. that would be mapped in NIR as adding casts everywhere, so NIR would still be somehow typed. I guess the issues you are facing are at NIR level?
<karolherbst>
afaik spirv untyped pointer exist only because of llvm dropping typed pointers
<cmarcelo>
(I have some but not complete work on untyped ptrs, just trying to gauge if it would be helpful to jump it to the front of the stack here)
<cmarcelo>
karolherbst: on paper there are some benefits to it, but yeah likely makes life easier for people using LLVM stacks at various levels.
<cmarcelo>
"likely the motivator is..."
<karolherbst>
this all will probably become obsolete with the spirv LLVM target anyway...
<cmarcelo>
"main motivator"
<karolherbst>
but I doubt that's ready before llvm-19
<cmarcelo>
karolherbst: what part of "this all" you mean
<karolherbst>
the middle end IR in llvm still has typed pointers, no? So the spirv target shouldn't have the same issue here (and overall give us better code probably)
<karolherbst>
not sure if they'd emit untyped pointers in spirv?
<cmarcelo>
AFAIK untyped ptrs even in LLVM means: the types are in the operations, so part of the benefit of having such way to do things in SPIR-V.
<karolherbst>
but the issue is, you don't even know your function types anymore
<karolherbst>
like if you only see the decl of a function, on the LLVM IR level you have 0 idea what the actual pointer types are
<karolherbst>
and that leads to all sorts of annoying issues
<cmarcelo>
oh I see
<karolherbst>
like..
<karolherbst>
linking spirvs is entire busted
<karolherbst>
*entirely
<karolherbst>
if llvm calls into memcpy the pointers are also random
<karolherbst>
but anyway.. kinda need to figure out how to optimize that stuff so we don't end up with pointless scratch memory :D
<dj-death>
karolherbst: private variables are not part of the function interface right?
<karolherbst>
they are
<karolherbst>
well
<dj-death>
karolherbst: shader_temp ?
<karolherbst>
depends on what you mean
<karolherbst>
shader_temp doesn't really exist in CL anyway
heat has joined #dri-devel
<dj-death>
I mean function_temp should not be something we need to exchange between modules we link togehter
<karolherbst>
yeah... though you can have function_temp arguments
<dj-death>
heh yeah
<dj-death>
let say if you have a function call with local pointer and that function is not part of your current module
<dj-death>
I think all my cases are not that currently
<dj-death>
GRL or other internal opencl functions
<karolherbst>
you can still have things like indirects
anujp has joined #dri-devel
<daniels>
kusma: if you want more BGRA fun, I've just spotted that though EXT_texture_format_BGRA8888 adds GL_BGRA_EXT (unsized) as a color-renderable renderbuffer 'sized internal format', glRenderbufferStorage rejects both BGRA_EXT and BGRA8_EXT ...
<daniels>
I wonder if that's because the renderbuffer stuff was only added later by Tobias
<Hazematman>
thanks zmike ! I'll test with that version. the crash only happens with validation layers enabled. I don't know if the exact crash the CI is seeing but I was able to reproduce a crash on debian 11 with older validation layers and it seems it was renaming a handling and then that renamed handled got passed into the driver instead of the original handle.
mbrost has joined #dri-devel
<zmike>
check the log
<zmike>
ci is configured to crash on unrecognized vvl errors
<Hazematman>
the log is just "segfault" with nothing else printed out for the test running
<zmike>
could be a vvl bug then
yyds has quit [Remote host closed the connection]
<karolherbst>
ahhh.. I can't decide how this should optimize :')
kts has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
frieder has quit [Remote host closed the connection]