<sima>
jfalempe, in other places we just looked at oops_in_progress to figure out whether the console printing is from panic context
<sima>
not perfect, but at least in the past good enough
<sima>
so maybe use that instead of your panic_cpu check?
<jfalempe>
sima: ok, yes oops_in_progress is a function disguised, so that should work.
<sima>
well we already use it all over the place in the drm fbdev code, so that one is available to modules for sure
leizhou has joined #dri-devel
<jfalempe>
I'm just checking where this flag is set, but I will use that, thanks.
MrCooper has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
<jfalempe>
sima: The only drawback is that we will lose the "not fatal" oops in fbcon if the drm driver supports drm_panic. But you can still retrieve it dmesg, because the system is still running.
<jfalempe>
I will send a patch shortly to unblock the build.
leizhou has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #dri-devel
warpme has joined #dri-devel
fab has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
cascardo_ is now known as cascardo
fab has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
smpl has joined #dri-devel
leizhou has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
vliaskov_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
leizhou has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
mripard has joined #dri-devel
<sima>
jfalempe, yeah it's not perfect unfortunately
Company has quit [Quit: Leaving]
guludo has joined #dri-devel
aravind has joined #dri-devel
leizhou has joined #dri-devel
leizhou has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
leizhou has joined #dri-devel
frieder has joined #dri-devel
MrCooper_ has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #dri-devel
itoral has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
MrCooper_ has joined #dri-devel
MrCooper_ is now known as MrCooper
frieder has quit [Ping timeout: 480 seconds]
warpme has quit []
recurser_ has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
recurser has joined #dri-devel
<zmike>
eric_engestrom / dcbaker: maybe you have some idea on this: is it possible to have a static (internal) library which exports symbols for subsequent mesa linking but then have those symbols not exposed in the final .so link?
<ishitatsuyuki>
no, you can't, ELF symbols are global by nature
<ishitatsuyuki>
visibility and / or linker scripts are more of extensions
<ishitatsuyuki>
and they only apply to shared libraries
<ishitatsuyuki>
renaming the symbols with a prefix might work if the code is fully vendored
<zmike>
the symbols are from a static library in src/gallium/frontends/dri and the user is a shared library inside mesa
alih has quit []
kts has joined #dri-devel
<ifreund>
Can I synthetically trigger a GPU reset somehow in order to test the ability of my program to recover from it?
<ishitatsuyuki>
zmike: do you just need the symbol to be not exported from the shared library? or does the symbols conflict with another definition within the same shared library?
<zmike>
the former
<ishitatsuyuki>
you can use hidden visibility, or linker script specifying a whitelist of symbols to export
<zmike>
right now I'm declaring them with attribute(weak) as a temporary workaround
<zmike>
hidden doesn't seem to work
<zmike>
well, no change in visibility works
<zmike>
I think because it's a static library
<ishitatsuyuki>
hidden should work, static library is just bundle of .o files
<zmike>
well
<ishitatsuyuki>
if you readelf -Ws file_from_static_lib.o does it show STV_HIDDEN?
<zmike>
681: 0000000000000000 32 FUNC GLOBAL HIDDEN 349 driGetAPIMask
<karolherbst>
maybe there are still fails, but some sub-tests are now passing?
<ishitatsuyuki>
zmike, is my understanding right that libfinal_product.so links libglx.a and libdri.a?
<DavidHeidelberg>
not improvements, that's good, the "Fail"
<karolherbst>
ahh
<DavidHeidelberg>
karolherbst: UI(Fail) means it was crashing before
<karolherbst>
ahh
<zmike>
ishitatsuyuki: no, libglx is the final product that links libgallium_dri
<DavidHeidelberg>
so it got a bit better, but other tests went from Pass -> Fail
<karolherbst>
I see
<karolherbst>
might need to bisect it if it's a stable fail
<zmike>
ishitatsuyuki: err actually libgallium_dri is a .so
<zmike>
so probably this is the issue
<DavidHeidelberg>
it's I had two runs, sadly my clear_buffer MR brings one more fail, which I need to figure out
<karolherbst>
DavidHeidelberg: I suspect some changes in the compiler
<zmike>
because it's a .a -> .so -> .so
<zmike>
not .a -> .so directly
<ishitatsuyuki>
right
<zmike>
so I think there's no solution here until I flatten it
<DavidHeidelberg>
karolherbst: I'm just reporting now, I came to the Korea today, -x hours of sleep, so my best effort is now to tell :P I'll try to finish the clear_buffers so it can get in sooner and gets proper testing....
<ishitatsuyuki>
yes, if you export glx symbols from libgallium_dri it will be available to every module in the process
<zmike>
yeah
<zmike>
so I'm just gonna keep doing a hacky workaround for now
jfalempe has quit [Quit: jfalempe]
<ishitatsuyuki>
feel free to ping / ask on MR if you need a better solution for upstreaming
<zmike>
I think (hope) it'll be okay since I'm gonna keep hacking away at it until it gets to a non-hacky final state before the next release
<zmike>
but yeah, thanks
recurser___ has joined #dri-devel
jfalempe has joined #dri-devel
recurser has quit [Ping timeout: 480 seconds]
OftenTimeConsuming is now known as Guest958
OftenTimeConsuming has joined #dri-devel
Guest958 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
heat is now known as Guest959
Guest959 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
davispuh has joined #dri-devel
Duke`` has joined #dri-devel
warpme has quit []
Company has quit [Quit: Leaving]
leizhou has quit [Remote host closed the connection]
leizhou has joined #dri-devel
warpme has joined #dri-devel
warpme has quit []
asrivats has joined #dri-devel
anujp has quit [Remote host closed the connection]
mripard has quit [Quit: mripard]
<gfxstrand>
eric_engestrom, dcbaker: Any further thoughts on getting !30275 to build? Updating to meson 1.4.2 did nothing and it builds fine with clang locally
<dcbaker>
gfxstrand: I was looking at it.
<gfxstrand>
cool
<dcbaker>
Here's what I'm thinking: clang doesn't like -pthread in the link line in a bunch of cases, it considers that dead code (Meson runs into this on macOS especially), so I'm thinking that debian has a bad combination of turning this flag on, and one of their dependencies putting -pthread in it's cflags (probably zlib or zstd, based on the command line)
<dcbaker>
I'm wondering if we just want to set -Wno-... on that argument and move on. Because I can't reproduce locally either
<gfxstrand>
I can certainly try
<gfxstrand>
And the thing is, it does depend on something that uses pthreads
<gfxstrand>
Just the rust code doesn't need it (kinda)
Company has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<dcbaker>
Yeah, it might be worth my time to see if Meson can just filter -pthread from rustc link args...
<dcbaker>
I forsee this being an ongoing issue...
<gfxstrand>
dcbaker: While you're filtering Rust things, I ran into an issue with using idep_mesautil where it somehow ended up with some sources in it (from perfetto, maybe?) Those made rust choke.
<gfxstrand>
IDK that just filtering sources is necessarily the right call but it's a pretty nasty corner to hit especially if those sources come from a wrap
<dcbaker>
I think we can fix that without Meson changes
<gfxstrand>
yes
<dcbaker>
You should be able to do idep_mesautil.partial_dependency(compile_args : true, includes : true, link_args : true, links : true), to drop any sources that are included in idep_mesautil.
<dcbaker>
But that will also drop headers....
<dcbaker>
Might need Meson patches still
<dcbaker>
sigh
<dcbaker>
Never let anyone tell you build systems aren't hard, lol
kts has quit [Quit: Konversation terminated!]
a_Tom has joined #dri-devel
kts has joined #dri-devel
fab has joined #dri-devel
jfalempe has quit [Quit: jfalempe]
jfalempe has joined #dri-devel
asrivats has quit [Ping timeout: 480 seconds]
jfalempe has quit []
jfalempe has joined #dri-devel
<jimc>
help diagnose job #61356474 ? python-test falls over with:
<jimc>
00:07
<jimc>
[01:06] ERROR: unknown-section: ret code: 1
<jimc>
$ cd bin/ci
LeviYun has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
jfalempe has quit [Quit: jfalempe]
rasterman has quit [Quit: Gettin' stinky!]
lynxeye has quit [Quit: Leaving.]
<gfxstrand>
dcbaker: Oh, that should work. I don't need includes in Rust. I just need them in the bindgen call
<dcbaker>
gfxstrand: just be aware that there is a long standing bug that external dependencies mix includes and compile_args into compile_args, so if you have anything found via a `dependency()` call, you need `compile_args : true` to get the includes
<dcbaker>
I've written patches a few times for this, but never quite get it all working
Mangix has quit [Ping timeout: 480 seconds]
asrivats has joined #dri-devel
alih has joined #dri-devel
<gfxstrand>
dcbaker: Sweet! All I need are link_with and links so that works a treat
<dcbaker>
yay!
<gfxstrand>
dcbaker: If I'm going to add -Wnounused-command-line-arguments, where should I do that?
<gfxstrand>
In rust_args?
<dcbaker>
That's where I'd start. If that doesn't work then link_arguments
kts has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
guru_ has quit [Ping timeout: 480 seconds]
recurser has joined #dri-devel
LeviYun has joined #dri-devel
recurser___ has quit [Ping timeout: 480 seconds]
leizhou has quit [Remote host closed the connection]
<gfxstrand>
dcbaker: Looks like I've got it. -Clink-arg=-Wno-unused-command-line-arguments
<dcbaker>
gfxstrand: since we went to symlinks that make sense to me.
<dcbaker>
gfxstrand: that makes me think we're not handling `link_arguments` in rust targets...
<gfxstrand>
dcbaker: Yeah, putting it in link_args did nothing
<gfxstrand>
Unless link_arguments and link_args are different (but that would be nutty)
<dcbaker>
no, it's probably called link_args and I'm writing the wrong thing
<dcbaker>
too many plates in the air, each with their own opinion on what we should abbreviate, lol
<dcbaker>
I would not be surprised if rust targets ignore link args, I'll have to look at that
<gfxstrand>
Yup
<karolherbst>
DavidHeidelberg: oh btw, please tell me once you are officially ready to drop clover support, because then I'm gonna clean up quite a lot
guludo has quit [Quit: WeeChat 4.3.3]
guludo has joined #dri-devel
coldfeet has joined #dri-devel
riteo has quit [Remote host closed the connection]
Kayden has quit [Quit: -> JF]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
KitsuWhooa has joined #dri-devel
Mangix has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
krychu has joined #dri-devel
KitsuWhooa has quit [Quit: Unable to handle kernel NULL pointer dereference at null]
leizhou has joined #dri-devel
KitsuWhooa has joined #dri-devel
illwieckz has joined #dri-devel
<Lyude>
Does anyone know whether or not /all/ KMS drivers capable of performing non-blocking modesets would be using drm_atomic_helper_wait_for_flip_done()? Or are there usecases for such a driver possibly using drm_atomic_helper_wait_for_vblanks()?
riteo has joined #dri-devel
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
probablymoony has joined #dri-devel
moony has quit [Read error: No route to host]
mvlad has quit [Remote host closed the connection]
riteo has quit [Remote host closed the connection]
riteo has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
guludo has quit [Remote host closed the connection]
guludo has joined #dri-devel
iive has joined #dri-devel
janneg is now known as jannau
mbrost has joined #dri-devel
chamlis has quit [Ping timeout: 480 seconds]
chamlis has joined #dri-devel
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
kzd has quit [Read error: Connection reset by peer]
agd5f_ has joined #dri-devel
kzd has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<Sachiel>
gfxstrand: opinion on how to handle VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT in mesa? It's a trivial if in vtn, but we'd have to pass the flag to vk_pipeline_hash_shader_stage(). Or we can keep not passing pipeline creation flags in there and have a pass after that does s/ViewIndex/DeviceIndex/ that every driver has to call
a_Tom has quit [Remote host closed the connection]
krei-se- has joined #dri-devel
krei-se has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
recurser has quit []
recurser has joined #dri-devel
nerdopolis has joined #dri-devel
jfalempe has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
recurser has quit [Remote host closed the connection]
recurser has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Read error: Connection reset by peer]
recurser has quit []
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
i509vcb has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
leizhou has quit [Remote host closed the connection]
vliaskov_ has quit [Read error: Connection reset by peer]