<sima>
airlied, I tried to fix a few misconceptions around what dma_buf/fence is, but I think Linus' take is that this isn't our bug ...?
yyds has quit [Remote host closed the connection]
mriesch has quit []
mriesch has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<MrCooper>
Company: the SUBOPTIMAL thing likely happens because the compositor sends no-change dma-buf feedback to Xwayland; Mesa 24.1 has a workaround for this
<sima>
airlied, ah the fix is in -rc7
<Company>
MrCooper: hrm - nvidia seems to cause OUT_OF_DATE errors in that situation, would that be an issue with nvidia's Vulkan driver?
<MrCooper>
sounds like it
itoral has quit [Quit: Leaving]
lemonzest has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
lemonzest has quit []
halves has quit [Quit: o/]
halves has joined #dri-devel
f_ has joined #dri-devel
mbrost has joined #dri-devel
warpme has joined #dri-devel
Haaninjo has joined #dri-devel
u-amarsh04 has quit []
kzd has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
u-amarsh04 has joined #dri-devel
xroumegue has joined #dri-devel
heat is now known as Guest4202
Guest4202 has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<regularityon>
So dma-buf API has no unified hardware configurator without interrupting to CPU to allow or reject wraparound, currently it handles one or another based of gcc flags on integer overflow arithmetic intrinsics, while windows defaults to wraparound, Linux does currently default on no wraparound based of gcc flags and trackers interrupt. But the opening is the same for normal modes dma wraparound to zero from max vs no wraparound in incremental mode,
<regularityon>
and opener like provided is fairly intelligent, needs no fifo aka circular mode but one shot burst mode. dma-buf API is bulky and primitive, should be advanced to dma compute machine yet.
kts has joined #dri-devel
<regularityon>
Conversion routines for dma offloading are fairly simple , it needs no alu dictionaries, but conversion magic weight numbers, since plus and minus are handled without any answer set logics, and the skeleton is hence the same proportionally for compressed and not formats for back and forth encoding decoding, I've already solved everything but not yet the rounding procedures.
lynxeye has quit [Quit: Leaving.]
vliaskov has quit [Ping timeout: 480 seconds]
<regularityon>
Rounding ceil floor and such are at compile and relink phase, and are fairly simple to add into the logics once I start on the alu dictionaries as to how I see, but I have not looked at all the details of rounding yet, very clear it's not a blocker though.
frankbinns has joined #dri-devel
frankbinns1 has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
kaiwenjon has joined #dri-devel
fab has joined #dri-devel
Simonx22 has quit []
Simonx22 has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
bolson has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kts_ has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
jsa1 has left #dri-devel [#dri-devel]
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
jsa has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
mbrost_ has joined #dri-devel
jhli has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
bolson_ has joined #dri-devel
bolson has quit [Read error: Connection reset by peer]
aswar002_ has joined #dri-devel
rsripada has quit [Read error: Connection reset by peer]
aswar002 has quit [Read error: Connection reset by peer]
unerlige has quit [Read error: Connection reset by peer]
rsripada has joined #dri-devel
alanc has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
alanc has joined #dri-devel
pzanoni` has joined #dri-devel
guludo has quit [Remote host closed the connection]
regularityon has quit [Remote host closed the connection]
pzanoni is now known as Guest4255
pzanoni` is now known as pzanoni
rsripada_ has joined #dri-devel
dolphin` has joined #dri-devel
dolphin is now known as Guest4257
dolphin` is now known as dolphin
sghuge_ has joined #dri-devel
lstrano has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
shankaru1 has joined #dri-devel
Guest4255 has quit [Ping timeout: 480 seconds]
aswar002_ has quit [Ping timeout: 480 seconds]
shankaru has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
kxkamil2 has joined #dri-devel
simon-perretta-img has joined #dri-devel
Guest4257 has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
Ryback_ has quit [Ping timeout: 480 seconds]
sghuge has quit [Ping timeout: 480 seconds]
lstrano_ has quit [Ping timeout: 480 seconds]
bolson_ has quit [Ping timeout: 480 seconds]
rsripada has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
kxkamil has quit [Ping timeout: 480 seconds]
cphealy has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
mbrost has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kasper93 has quit [Remote host closed the connection]
warpme has joined #dri-devel
sghuge_ has quit []
sghuge has joined #dri-devel
<sghuge>
Has anyone encounterd strange issue with LLVM 17 vs LLVM 16? We have some CL kernels those gets compiled for Ray tracing but looks like something has changed between LLVM 16 and LLVM 17..things are failing on LLVM 17 and passing on LLVM 16. I tried to find the delta between spirv but differences are a lot, not sure how to track down the differences/changes. Just checking if someone
<sghuge>
already encounterd similar issue before.
oneforall2 has quit [Remote host closed the connection]
probablymoony has quit [Ping timeout: 480 seconds]
moony has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<mattst88>
karolherbst has dealt with a bunch of issues around llvm-17. he might have some advice
<karolherbst>
sghuge: llvm only has opaque pointers, so that's causing quite some headache, because external functions might have different pointer types in their signature
<karolherbst>
and I wouldn't be surprised if that's the main cause of regressions (or well.. opaque pointers in general)
<karolherbst>
could try enabling them with llvm-16 and see if you get the same regressions
oneforall2 has joined #dri-devel
kasper93 has joined #dri-devel
* sghuge
is reading about the opaque pointers
sukuna has joined #dri-devel
<kisak>
llvm 16 has not-opaque pointers? I thought the forced transition was earlier than that
kaiwenjon has quit [Ping timeout: 480 seconds]
<karolherbst>
16 has them disabled by default
<karolherbst>
or maybe it was enabled by default but we've disabled it
<karolherbst>
something something
<kisak>
my memory says 15 was disabled by default.
<karolherbst>
but non opaque got removed with 17
<kisak>
okay, so the factoid in my memory is incorrect regardless.
<sghuge>
karolherbst: Okay, enabling the opaque-pointers with LLVM 16 reproduces the failure.
<karolherbst>
I don't know if that is a good or a bad thing...
<karolherbst>
what kind of failure btw?
<sghuge>
ray tracing tests are failing with the LLVM 17 :(
<karolherbst>
soo.. runtime behavior changes?
<karolherbst>
given the size of ray tracing kernels... good luck?
<karolherbst>
but it might be that we optimize some strides away or other random things
<karolherbst>
to workaround opaque pointers the translator added a bunch of casts
<karolherbst>
sghuge: it might make sense to check with llvm-18 and llvm-19 and see if it got fixed in the translator
<karolherbst>
backporting stuff only happens on demand there
feaneron has quit [Quit: feaneron]
<sghuge>
yeah it's a runtime behavior change...and yep, it's a hell lot of kernels for RT :(
<karolherbst>
I haven't hit any runtime regressions since moving to llvm-17 sadly, so I can only guess what's up
<sghuge>
let me try and update the llvm version to see if it got fixed in the latest version.
riteo has quit [Remote host closed the connection]
iive has joined #dri-devel
<dcbaker>
karolherbst: I have an... interesting issue, and it might be something particular to my setup. Can you run `meson setup builddir Drust_args="-Clink-arg=-fsanitize=address" -Db_sanitize=address` on that rust test branch you have? When I run that with clang it works, when I run it with GCC it doesn't, and I'm suspecting there's just something wrong with my gcc
sukuna has quit [Remote host closed the connection]
sukuna has joined #dri-devel
mohamexiety has quit [Ping timeout: 480 seconds]
<karolherbst>
dcbaker: you mean like it still fails to link on your end?
<dcbaker>
Yea, but only when use gcc as the linker, when I compile with clang it works fine
<karolherbst>
same, but curious
<karolherbst>
why are we hitting all the compiler bugs...
<karolherbst>
*and lniker
<dcbaker>
This would all be easy if rustc would go ahead and stabilize their sanitizer support, lol
<karolherbst>
heh, fair
<dcbaker>
Because that does work with gcc
<karolherbst>
mhhhhh
sukuna1 has joined #dri-devel
<karolherbst>
with clang: note: /usr/bin/ld: cannot find /usr/bin/../lib/clang/17/lib/linux/libclang_rt.asan_static-x86_64.a: No such file or directory
unerlige has joined #dri-devel
<karolherbst>
but... that sounds like a fedora bug or something? I have no idea
<karolherbst>
dcbaker: mhhhhh, it might have to be caused if things compiled by gcc and rustc are mixed
<karolherbst>
in the final object I mean
<karolherbst>
rusticl_test is special because it basically links against a lot of mesa
<karolherbst>
and probably the reason why the other test binaries compile just fine
<dcbaker>
Yeah, that makes sense to me. I don’t really know where to go with it, since it’s a bug easy to hit on CI, but I don’t know how often people will hit it in production
<karolherbst>
you have to enable the sanitizer, soo...
<karolherbst>
I'm more concerned about the other issue tbh :D
sukuna has quit [Ping timeout: 480 seconds]
<karolherbst>
but that only seems to happen when enabling lto?
samuelig has quit []
mohamexiety has joined #dri-devel
<karolherbst>
it's kinda weird
mohamexiety has quit [Remote host closed the connection]
mohamexiety has joined #dri-devel
<karolherbst>
or rather.. I think lto kinda causes a lot of random symbols to be linked in and the linker just doesn't nuke unused things early enough
mohamexiety has quit [Remote host closed the connection]
mohamexiety has joined #dri-devel
samuelig has joined #dri-devel
kaiwenjon has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<dcbaker>
I actually expect GCC + rustc with lto enabled to not work, since GCC and LLVM have different formats for annotating LTO objects
Ryback_ has joined #dri-devel
<dcbaker>
One of these days I'll finish wiring up gcc-rs to Meson and I would expect that to work
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
<karolherbst>
mhhh
<karolherbst>
I'm still reluctant to gurantee any sort of support for gcc-rs
<karolherbst>
maybe in 5 years, once we don't constantly bump up the req rust version or so
vliaskov has joined #dri-devel
warpme has quit []
<dcbaker>
Yeah, I just meant if someone is dead set on LTO for gcc, that saying "well, there's gcc-rs, otherwise you can use clang"
<dcbaker>
please keep the pieces
<karolherbst>
yeah, fair
<karolherbst>
I wonder if the libasan problem is fundamentally the same, or are gcc and clang handling it similiar enough so that it should still all link fine?
<Company>
(Vulkan in general feels more unstable than GL. I'd describe it as solid code but not enough serious usage to weed out all the weird stuff.)
iyes has quit [Ping timeout: 480 seconds]
<alyssa>
robclark: for turnip?
<alyssa>
Company: i'm not sure "stable" applies to GL (-:
sudeepd has quit [Ping timeout: 480 seconds]
<Company>
GL is surprisingly solid for the size of the API
<Company>
but I was more talking about the kinds of issues that GTK got since we switched to Vulkan by default
sudeepd has joined #dri-devel
<Company>
the nvidia driver spins up all its suspended gpus on dlopen() of the driver for example, so vkCreateInstance() blocks for 5 seconds
<Company>
or Intel advertises YcbcrConversion but doesn't implement it
<Company>
stuff like that
glennk has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
zxrom has quit [Remote host closed the connection]
zxrom has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
pa- has quit [Remote host closed the connection]
pa has joined #dri-devel
<sghuge>
karolherbst: Okay, I think the same issue exist in llvm-18 as well. I can still repro the failure with llvm-18 :( Will try and see if I can get llvm-19
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
mohamexiety has quit [Read error: Connection reset by peer]
<karolherbst>
Company: vulkan not validating by default might also cause random issues I bet
<karolherbst>
but yeah.. that resuming GPUs issues is probably a huge blocker, because I doubt users want this lag when launching any app
<Company>
I don't think any of those issues are bad, they're just indications of developer focus
<Company>
someone just has to sit down and make the driver do the same thing that the EGL driver does
<karolherbst>
I'd consider the app only starting in 5 seconds to be a major blocker tbh
<Company>
or implement the YcbcrConversion/not advertise it
<Company>
yeah, it'd certainly be more critical if it was October already
<karolherbst>
yeah, fair
simon-perretta-img has quit [Ping timeout: 480 seconds]
<Company>
but it's also just the dual gpus that have a setup that has gpu suspend enabled and that uses the nvidia driver
<karolherbst>
every driver has it enabled afaik
<karolherbst>
thoug
<Company>
I didn't follow the whole discussion, I think it had something to do with what kernel module was used etc
<karolherbst>
maybe mesa is better at not accessing the suspended device in that case
<karolherbst>
normally the GPU gets resumed once you start accessing it via ioctls or other things
<Company>
I haven't heard complaints from AMD users
<Company>
but I have heard that nvidia's EGL-wayland had the same issue and they fixed it
<karolherbst>
ahh
<karolherbst>
probably just the way they init their drivers then
<Company>
yeah
<Company>
Vulkan use is heavily biased towards DXVK atm
<Company>
nobody runs a tiny GTK app with Vulkan, so all those features haven't seen much use
<Company>
well, DXVK and other Vulkan-targeting things, which are generally fullscreen apps that want the dgpu if there is one
<karolherbst>
that reminds me that running 32 bit games on my quadro with the nvidia driver at some point caused OOM situations, because the driver thought it's funny to pre allocate ~3GB of VM space
<karolherbst>
(quadro as in 48GB GPU)
<Sachiel>
Company: what's this about intel advertising ycbcr conversion but not implementing it? At least the cts tests for it are working fine, which I grant doesn't say much, but I'd expect "advertise but not implement" to fail them utterly
<Company>
the worst thing about drivers doing that is that people run their favorite top clone and then complain that every GTK4 app uses gigabytes of memory while GTK3 didn't
<Company>
Sachiel: no idea about the cts tests - it might require yuv dmabuf imports
dolphin` has joined #dri-devel
unerlige has quit [Read error: Connection reset by peer]
rsripada_ has quit [Read error: Connection reset by peer]
bolson has quit [Read error: Connection reset by peer]
lstrano has quit [Read error: Connection reset by peer]
dolphin has quit [Read error: Connection reset by peer]
dolphin` is now known as dolphin
bolson has joined #dri-devel
rsripada has joined #dri-devel
shankaru1 has quit [Read error: Connection reset by peer]