<tleydxdy>
for gpu soft reset, would the application know it did bad? like with vulkan robustness or something similar
<DemiMarie>
karolherbst: any plans to purge LLVM from Mesa?
<DemiMarie>
mareko: what would it take for NIR to generate CPU SIMD instructions directly?
<karolherbst>
sadly.. no
<karolherbst>
it would be a lot of work with no real pay off besides dropping LLVM
<karolherbst>
I don't think people here want to add various CPU archs and deal with that nonsense inside mesa just to support llvmpipe
<karolherbst>
also having a _real_ C parser is also something nobody wants to do
<karolherbst>
C alone is a mess, but then you got the macro language on top
<karolherbst>
and then somebody would also have to manage the OpenCL C stuff with all the builtins and everything
<karolherbst>
just boils down to more work
<DemiMarie>
karolherbst: Ask Walter Bright about how hard it was to write a C parser for the D compiler. To be fair, he was the only person to have ever written a Standard C++ compiler solo IIRC.
<karolherbst>
I'm sure it's easy to write one that kinda works, I'm sure it's near impossible to write a compliant one
<DemiMarie>
karolherbst: Walter Bright had the advantage that he already maintains a C compiler.
<karolherbst>
well.. we don't :)
<karolherbst>
anyway, I think C is the simple part
<karolherbst>
the preprocessor is the one worrying me
<karolherbst>
and CL does have weirdo additions for that
<DemiMarie>
karolherbst: is calling `/usr/bin/cpp` an option?
<karolherbst>
so you can include files, but instead of looking in a filesystem you have this runtime map and stuff
<karolherbst>
sadly, no
<karolherbst>
because CL C is different
<karolherbst>
the semantics are more or less the same, just that you can provide "header" files as CL program objects with a header name and you have to replace that stuff at runtime
<karolherbst>
it's pretty wild actually
<DemiMarie>
I know of D and Haskell implementations of the C preprocessor
<karolherbst>
the question is: do they actually compile every valid source file
<DemiMarie>
A Rust one for rusticl would likely be ~5,000 SLoC (about the size of the D one)
<karolherbst>
and do it correctly
<DemiMarie>
The D one can handle libc headers IIRC
<karolherbst>
yeah, that's a 5k loc we'd have to maintain
<DemiMarie>
what if there was a Rust crate that implemented the C preprocessor?
<karolherbst>
mhhh
<DemiMarie>
(to be clear: I am NOT offering to implement one!)
<karolherbst>
then we'd also have to recreate the spirv-llvm translator part
<karolherbst>
or rather parsing CL C and output spir-v
<DemiMarie>
that said, I am more interested in the AMD backend
<karolherbst>
yeah...
<DemiMarie>
which (IIUC) is a PITA
<karolherbst>
I think nobody is interested in actually doing the work required to ditch llvm
<DemiMarie>
are there plans to ditch LLVM for the AMD backend?
<karolherbst>
for ACO?
<karolherbst>
that's up to the radeonsi driver
<DemiMarie>
no idea what Mesa internal code names are
<karolherbst>
but I think there are some looking into this
<DemiMarie>
What would the advantages be?
<karolherbst>
no llvm
<cwabbott>
there's ongoing work to be able to use ACO instead of LLVM in radeonsi, but it's going to be a long effort
<karolherbst>
yeah, and the people working on it alreayd hate me for wanting real function call support in that as well :P
<karolherbst>
still need to find a poor sould doing that for intels compiler for me 🙃
<mareko>
ACO doesn't support CDNA
<cwabbott>
a number of driver-specific details were implemented via driver callbacks in the NIR-to-LLVM translation pass and they need to be transitioned one-by-one to NIR passes
<karolherbst>
well.. lucky that I don't care much about CDNA either
<karolherbst>
or does radeonsi care about CDNA?
<mareko>
yes
<karolherbst>
mhhh
<mareko>
it's just for VAAPI and OpenMAX
<karolherbst>
sounds like there is still a lot of work ahead then :)
<karolherbst>
ahh
<mareko>
CDNA can't do any graphics, but it has video hw and can do postprocessing via compute
<mareko>
the video gallium frontends support compute-only chips with video hw
<mareko>
rusticl should work on it too
<airlied>
is there much aco needs to support cdna?
<airlied>
I thought it was pretty much the same compute cores
<airlied>
maybe an instruction or two extra
<karolherbst>
mareko: in theory yes, but I've experienced some bugs with the compute only blitter/copy... I have to look into it but setting COMPUTE_ONLY triggered some weirdo bugs in that area
<karolherbst>
but given that images with clover+radeonsi never really worked that's also not really surprising
<airlied>
you don't get blit if you have compute only
<airlied>
or you have to use a compute based blit path
<karolherbst>
yeah and I think the compute based on isn't entirely working alright
<karolherbst>
I'd have to check again
andremorishita has quit []
elongbug has joined #dri-devel
<mareko>
the compute blit only works to the extent required by VAAPI and OpenMAX
<airlied>
yeah so CL probably has larger expectations around that
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<mareko>
resource_copy_region should work, blit isn't used by vaapi/openmax
<mareko>
I think I have a full compute blit implementation locally (only scaling and filtering is missing AFAIK)
<mareko>
(missing in the main branch I mean)
aravind has joined #dri-devel
a-865 has joined #dri-devel
bluetail has joined #dri-devel
bmodem has joined #dri-devel
zzoon has joined #dri-devel
<zzoon[m]>
airlied: I've updated the MR for hevc decoding.. that makes it work on gen12(alderlake)
<zzoon[m]>
btw there are some failures of cts on gen12.. even if h264 decoding..
bmodem1 has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<airlied>
zzoon[m]: would be good to get some ideas of where cts is failing, but it could also be CTS bugs
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
<kode54>
neat
<kode54>
latest drm-xe-next kernel doesn't bring up my displays
<kode54>
I've already reported it
Zopolis4_ has joined #dri-devel
danvet has joined #dri-devel
junaid has joined #dri-devel
itoral has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<tarceri>
Welp I just spent 4 hours rechecking my code and looking for bugs. All because of one little feq instead of ieq
<tarceri>
Can someone hit reset on today please
bmodem has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
tzimmermann has joined #dri-devel
junaid has quit [Remote host closed the connection]
aravind has joined #dri-devel
frieder has joined #dri-devel
Danct12 is now known as Guest12206
Danct12 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
sgruszka_ has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
yuq825 has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
clem_ has quit [Remote host closed the connection]
clem_ has joined #dri-devel
jkrzyszt has joined #dri-devel
thellstrom has joined #dri-devel
bgs has joined #dri-devel
fab has quit [Quit: fab]
dcz has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
<airlied>
thellstrom: seems to be a regression with drm/ttm: Reduce the number of used allocation orders for TTM pages
<karolherbst>
mareko: anyway, atm I'm not using the blit callback at all and I think the problems were around resource_copy_region, but I'm not 100% sure on that. I used to had wrappers for blit, but never used them. Anyway, CL doesn't really have blit operations, just some image <-> buffer copy functions and atm quite some of it is implemented in software only anyway
<karolherbst>
but I do want to revive COMPUTE_ONLY because that will be the trigger to enable SVM and/or use compute contexts to allow longer running kernels and stuff on some drivers
sgruszka has joined #dri-devel
JohnnyonFlame has joined #dri-devel
apinheiro has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
penguin42 has joined #dri-devel
pundir has quit [Quit: Connection closed for inactivity]
jkrzyszt has joined #dri-devel
junaid has joined #dri-devel
garrison has quit [Read error: Connection reset by peer]
garrison has joined #dri-devel
uajain has joined #dri-devel
junaid has quit [Remote host closed the connection]
<uajain>
hello, I wanted to know if there's a correct way to flush the DRM request/queue, committed using drmModeAtomicCommit () with DRM_MODE_PAGE_FLIP_EVENT passed in
<emersion>
there's no queue, no buffering, it's a direct IOCTL
<uajain>
Ok. What I'm noticing is that a request (say T) is committed successfully for disabling the display pipeline - but _after_ that a request with DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK is calling the page_flip_event handler
<uajain>
that request is T-1
<uajain>
What I don't understand is - if the pipeline is disabled successfully, how come I am noticing a page flip event being generated afterwards
<uajain>
when there's no queuing etc.
<emersion>
page flip events happen asynchronously, when the page-flip happens
<emersion>
well
<emersion>
you could say that there is a queue of 1 slot
<uajain>
Correct.
<emersion>
user-space does drmModeAtomicCommit(), that programs the hw, and after vblank kernel sends the event
<uajain>
ok, so I really have to see if I disable the pipeline - what happens to a vblank event.
<uajain>
My goal is to cancel that page_flip event entirely - when I disable the pipeline itself
<MrCooper>
atomic KMS API offers no way to cancel anything yet
<uajain>
indeed, because I haven't found a way yet - after reading drm documentation and many IOCTLs description
aravind has quit [Ping timeout: 480 seconds]
<uajain>
so I guess the only way I have forwards to handle the stop/disable state in userspace and early return; in the page flip handler
<MrCooper>
karolherbst: GCC 13 in F38 generates a -Wdangling-reference warning about src/gallium/frontends/clover/spirv/invocation.cpp:link_program()::&bsec , does that look legit?
bmodem1 has joined #dri-devel
<uajain>
We got similar in libcamera as well with GCC 13 but turned out to be false positive
<MrCooper>
thanks, looks like it won't be fixed though sadly; is there any workaround?
<karolherbst>
yeah.. it does look kinda dodgy to warn about it
<karolherbst>
disabling that buggy warning then?
<MrCooper>
GCC bug report above says it's not fixable in the compiler, but the false positive rate is low
<karolherbst>
I don't agree with the reasoning, maybe we have to keep commenting on the bug saying it is widespread?
<karolherbst>
heh
<karolherbst>
famous last words
<MrCooper>
k, I'll disable it for now, thanks
<karolherbst>
according to what is the false positives rate low? nobody filing bugs because nobody uses it?
<MrCooper>
("disable" as in "make it not fatal in CI")
<karolherbst>
right
itoral has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
pendingchaos_ is now known as pendingchaos
vliaskov has quit [Read error: Connection reset by peer]
Danct12 has quit [Quit: WeeChat 3.8]
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<zmike>
tarceri: we've all been there
yuq825 has left #dri-devel [#dri-devel]
Guest12206 has quit []
Danct12 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
aravind has joined #dri-devel
Company has joined #dri-devel
stuarts has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
stuarts has quit [Remote host closed the connection]
fab has quit [Quit: fab]
stuarts has joined #dri-devel
gouchi has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
gouchi has quit [Quit: Quitte]
<gfxstrand>
dcbaker: How're you coming with meson crate support?
stuarts has quit [Remote host closed the connection]
<gfxstrand>
dcbaker: I just updated my syn dep yesterday and it was a PITA because I had to re-meson 3 repos. :-/
fab has joined #dri-devel
macromorgan has joined #dri-devel
Zopolis4_ has quit []
heat_ has joined #dri-devel
<dcbaker>
gfxstrand: things are moving forward. One of the gstreamer guys is in the same position and has been fixing a lot of bugs and adding features we need
<gfxstrand>
Ok
kzd has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
<karolherbst>
dcbaker: so I also digged deeper into that isystem bug, and it appears when you use a dependency with `include_type : 'system'` it adds those isystem arguments. Bindgen doesn't filter those out, but normal C targets do... So now that's kinda an annoying situation
aravind has joined #dri-devel
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
<dcbaker>
Hmmmmm. Okay, that is annoying. Of course isystem is just annoying because people aren’t using it for what it’s for but for it’s side effects…
<karolherbst>
but yeah.. I think we have to assume that isystem args are passed to bindgen and it kinda has to deal with it in a way without breaking random stuff :(
<karolherbst>
it's just sad that I need this to fix actual bugs :(
<anholt>
hakzsam: any chance you could look into the radv + pipeline cache fix regression?
<hakzsam>
sure
<anholt>
thanks!
frieder has quit [Remote host closed the connection]
stuarts has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
jessica_248 is now known as jessica_24
<dcbaker>
karolherbst: of course. That isn't actually what -isystem is for, that's just a side effect of -isystem. I'm 50% of the way to writing patches for clang and gcc to add -iexternal which works just like -I except it surpresses warnings. Let me see what I can do about that today
<karolherbst>
mhh, so it would require patched gcc/clang?
<dcbaker>
I mean, the problem here is that people don't actually want what -isystem is meant for, which is pushing include paths later in the resolution order
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<dcbaker>
they just don't want warnings from the headers of external projects
<karolherbst>
right...
<dcbaker>
but we need to handle this correctly with bindgen
Jeremy_Rand_Talos_ has joined #dri-devel
<dcbaker>
and by this I mean -isystem
<karolherbst>
right...
<karolherbst>
the issue is just that there is an -isystem/usr/include and it messes up everything. For normal compilers it's all filtered out depending on what the compiler says is the default include path and stuff
<karolherbst>
tried to mimic it but kinda got painful real quick
<dcbaker>
yeah... I mean ideally we'd just re-use the code that already exists for clang
sgruszka has quit [Ping timeout: 480 seconds]
<karolherbst>
mhhh right..
<dcbaker>
I'm just not sure how painful that is going to be
<karolherbst>
very probably
<karolherbst>
I looked into it, but I stopped at "we have to make sure the clang _we_ ask is the same clang bindgen uses"
<dcbaker>
yeah.... which has interesting interactions with cross compiling
<dcbaker>
since bindgen will always be run from the build machine, but the rust target might be built for a different host machine
<karolherbst>
mhhh
<karolherbst>
right
<karolherbst>
anyway.. the bug I'm trying to solve and where I need this is, that I want to do this "check the build-id from where that symbol came from" and for that I need bindings to LLVM :( I could of course hardcode a mangled symbol name, but....
aravind has quit [Ping timeout: 480 seconds]
bluebugs has quit [Read error: Connection reset by peer]
<dcbaker>
yeah.... We need to fix this anyway
<dcbaker>
also.... we have a dependency.as_system() but not an inverse function...
<dcbaker>
as a workaround maybe we could do something like dep_llvm_includes = dependency('llvm', ...); dep_llvm = dep_llvm_includes.as_system()
<karolherbst>
yeah.. though I don't think it makes sense to overwrite this? dunno.. There is probably a reason why the dependency is marked as system
<karolherbst>
but it just shouldn't add isystem for paths which would get filtered later on anyway?
<karolherbst>
mhhh
<dcbaker>
yeah
<dcbaker>
wait...
<dcbaker>
I thought we did filter /usr/lib/include already in the llvm dependency handler... Is llvm coming from cmake or llvm-config?
<karolherbst>
uhm.... no idea
<karolherbst>
`dependency('llvm', ....)'
<karolherbst>
whatever that ends up doing I guess
<eric_engestrom>
dcbaker: if/when you send that -iexternal upstream, please drop me a link; I'd be interested in following along :)
<MrCooper>
dcbaker: FWIW, -isystem does generate warnings, they just don't result in errors with -Werror; I'd want that to be the same with -iexternal
stuarts has quit [Remote host closed the connection]
smiles_1111 has quit [Ping timeout: 480 seconds]
pochu has quit [Quit: leaving]
bmodem1 has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
djbw has joined #dri-devel
<karolherbst>
dcbaker: I suspect it uses cmake as meson searched for cmake right before reporting the llvm dep
<karolherbst>
but yeah.. there is an -isystem /usr/include arg coming from it
<dcbaker>
That might be the issue. I think the llvm-config path will strip that, but the cmake path doesn't seem to.... I can fix that
<karolherbst>
cool!
<karolherbst>
would be cool to get it done for 1.2 so I only need to bump the version once for the bugs I have :3
lemonzest has joined #dri-devel
sarnex has quit [Remote host closed the connection]
sarnex has joined #dri-devel
guru_ has joined #dri-devel
oneforall2 has quit [Read error: Connection reset by peer]
sarnex_ has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
elongbug has quit [Read error: Connection reset by peer]
<HdkR>
TL;DR? They switching to something better than ML?
gnuiyl has quit [Remote host closed the connection]
<dcbaker>
karolherbst: the more I think about it, the more I think that we should just always drop default include dirs when converting to a system include, it's not even really an LLVM problem, it's really just a "/usr/bin/include" should always be dropped when the dependency is a system type
<karolherbst>
yeah.. probably
khfeng has quit [Ping timeout: 480 seconds]
<dcbaker>
which is going to be an enormous amount of work... back to the LLVM cmake aproach
paulk has joined #dri-devel
stuarts has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
bgs has quit [Remote host closed the connection]
fab has quit [Quit: fab]
<alyssa>
robclark: on asahi, --use-gl=egl only works for me if I also pass --in-process-gpu, otherwise it bugs out with "GPU process exited unexpectedly: exit_code=5" and falls back to software
<alyssa>
is this familiar?
<robclark>
alyssa: ok, I'm going to guess you are talking about chrome/ium? Try disabling gpu sandbox?
dcz has quit [Ping timeout: 480 seconds]
<alyssa>
happens regardless of no sandbox
<alyssa>
and yeah I meant chromium, whoops thought I specified, heh
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
<alyssa>
i.e. neither --disable-gpu-sandbox nor --no-sandbox make a difference, but --in-process-gpu does "fix" it
<alyssa>
I don't particularly care personally, but was wondering whether this was known snafu for gles + desktop linux
<robclark>
I don't think I've tried to specifically use gles on desktop linux, tbh
<alyssa>
yeah, incredibly valid.
<robclark>
gpu sandbox tends to be the problem over and over again because it needs to know certain driver specific paths to let punch thru the sandbox
<alyssa>
nod.
<alyssa>
only reason it was interesting was EXT_ms_rtt testing ;)
<zf>
is it possible for more than one process to use RADV_THREAD_TRACE at a time?
<zf>
I'm guessing probably not...
Duke`` has quit [Ping timeout: 480 seconds]
<alyssa>
ngl the seemore demo is really growing on me
<alyssa>
like a talking plant
<HdkR>
I used to really like Intel's old Order Independent Transparency demo
<HdkR>
Luckily that feature really took off.
Zopolis4_ has joined #dri-devel
ngcortes has joined #dri-devel
ngcortes_ has joined #dri-devel
sarnex_ has quit []
sarnex has joined #dri-devel
ngcortes__ has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
ngcortes_ has quit [Ping timeout: 480 seconds]
ngcortes__ has quit [Ping timeout: 480 seconds]
ngcortes_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
ngcortes__ has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes_ has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
pcercuei_ has quit []
ngcortes_ has joined #dri-devel
apinheiro has quit [Remote host closed the connection]