<jannau>
Hej, I'm working on the drm/kms driver for the display processor on apple silicon machines. Apple splitted the driver between macOS and an embedded processor running firmware driving the actual display controller communicating over an RPC interface
<jannau>
one consequence of this design is that we do not have vblank interrupts. I would expect that it's in principle possible to route the interrupt to the AP but I don't know how and if it will interfere with the firmware code
<jannau>
page flips using the RPC interface are blocking and the driver sends flip_done/vblank events when they are done
junaid has quit [Ping timeout: 480 seconds]
<jannau>
with atomic clients this seems to work well enough. most legacy clients seem to work as well
<jannau>
there are however some cases where vblank interrupts are required. xfwm4 (xfce4 window manager) with compositing enabled is one broken case
darkbasic5 has joined #dri-devel
junaid has joined #dri-devel
darkbasic6 has joined #dri-devel
darkbasic6 has quit []
darkbasic5 has quit []
rasterman has joined #dri-devel
danvet has joined #dri-devel
darkbasic4 has joined #dri-devel
<darkbasic4>
Hi, Gentoo recently version bumped llvm/clang 15.0.4 to 15.0.5 (no other changes in packaging) and I can't compile mesa git master anymore since then: ../mesa-9999/meson.build:21:0: ERROR: Compiler clang-15 can not compile programs.
<darkbasic4>
Do you know what might be the problem?
junaid has quit [Ping timeout: 480 seconds]
<HdkR>
darkbasic4: Potentially clang-15 but lld-14?
<HdkR>
Should be some debug text somewhere where it attempted to test compiling and why it failed
<darkbasic4>
HdkR: nope lld-15.0.5
<darkbasic4>
Also if I try to compile Firefox or Chromium with clang it works fine
<darkbasic4>
And it did work fine for mesa with 15.0.4
sarnex has quit [Ping timeout: 480 seconds]
<HdkR>
Not sure then, would need to find that debug text that meson prints
<darkbasic4>
HdkR: where should I find further debug text? I've looked into all portage logs (/var/tmp/portage/media-libs/mesa-9999/temp) and I didn't find anything further messages
<darkbasic4>
Gentoo has weird slotting for llvm/clang, but that shouldn't be the problem because 15.0.4 used to work. Something in the 15.0.5 tarballs must have broke it, because that's the only change that happened
<darkbasic4>
This is an example of the slotting issues which is preventing karolherbst rusticl from being merged but shouldn't be correlated with this issue: https://bugs.gentoo.org/880615
<karolherbst>
ahh right.. I should look into this issue and how we can fix it sanely ...
<darkbasic4>
karolherbst: that would be awesome because I fixed all the previous issues and rusticl support is ready to be merged apart from that
<HdkR>
darkbasic4: build folder -> meson-logs/meson-log.txt should have some information
<jannau>
I've taken the display processor driver over from alyssa
<darkbasic4>
Oh maybe I know what the problem might be: sys-libs/libunwind might need to be recompiled. But if that's the case it's weird that portage didn't catch it
<darkbasic4>
That was indeed the issue, I will file a bug in Gentoo, thanks
junaid has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
pcercuei has joined #dri-devel
kts has quit [Quit: Leaving]
Haaninjo has joined #dri-devel
lygstate_ has joined #dri-devel
lygstate has quit [Read error: Connection reset by peer]
luckyxxl has quit [Quit: bye]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
dviola has quit [Read error: Connection reset by peer]
srslypascal is now known as Guest2022
srslypascal has joined #dri-devel
Guest2022 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
<alyssa>
Venemo: I have never written a kernel driver, that's my story and I'm sticking to it /s
<Venemo>
lol alyssa :)
OftenTimeConsuming has joined #dri-devel
vsyrjala_ has joined #dri-devel
vsyrjala has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
<alyssa>
Venemo: btw I was explaining the principles of SSA-based RA to someone last night
<alyssa>
and quoted you on "it sells lottery tickets" :-p
<Venemo>
haha, great
<Venemo>
well, every RA sells them don't they?
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold__ has joined #dri-devel
<alyssa>
some more than others ;p
yuq825 has left #dri-devel [#dri-devel]
* alyssa
just did a ubsan build
<alyssa>
scary results on mesa
Akari has joined #dri-devel
<karolherbst>
ehhhh :pain: so apparently executing `clang -print-resource-dir` at runtime is the only official way of getting clangs resource dir and my only question left is: are you kidding us?!?
junaid has quit [Ping timeout: 480 seconds]
underpantsgnome[m] has quit []
<karolherbst>
Maybe we should just embedded the headers files for all platforms *sigh*
<karolherbst>
I don't want to, but I guess we have to... :'(
junaid has joined #dri-devel
<alyssa>
oof
<karolherbst>
or you know.. mesa being an insane project as it is already, we should just start to write our own C parser....
Jeremy_Rand_Talos has joined #dri-devel
lygstate has joined #dri-devel
lygstate_ has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talos has quit []
rsjw has joined #dri-devel
junaid has quit [Read error: No route to host]
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
<jenatali>
karolherbst: The header isn't that large, I don't see the problem with embedding it
<jenatali>
But yeah it should probably just be a build option so it can be turned on for broken distros or keep it separate when you want
<jenatali>
As long as it defaults to embed for Windows :P
<karolherbst>
yeah....
<karolherbst>
it's just... uhhhh
<karolherbst>
why does it have to be like that...
<kisak>
I probably should ask if anybody knows of any 32 bit raytracing or opencl applications in the wild? I looks like if I get those turned on with 22.3.0 in my PPA, it'll not have i386 support except on Ubuntu 18.04.
kts has joined #dri-devel
junaid has joined #dri-devel
lemonzest has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
<darkbasic4>
karolherbst: I just noticed that opencl is grayed out when launching darktable using the .desktop file. I've launched it from the cmdline and unfortunately it displays black images with cl on. Somehow benchmarks are less broken because sometimes it works and sometimes it falls back on cpu, but not in the real world usage
<karolherbst>
yeah...
JohnnyonFlame has joined #dri-devel
<karolherbst>
though on main it should be better
<karolherbst>
unless you use radeonsi
<karolherbst>
there are a few bugs and I suspect I don't synchronize something correctly
<darkbasic4>
karolherbst: radeonsi
<karolherbst>
yeah.. then it's a bug somehwere
<darkbasic4>
karolherbst: btw I've just noticed that benchmark-generated images are black as well, even the ones where the kernel doesn't fail and there are no error messages
<karolherbst>
ohh.. that's good to know
<karolherbst>
but I suspect it's random? or is that deterministic?
<darkbasic4>
karolherbst: unfortunately it is deterministic: it never renders anything usable, always black
alanc has quit [Remote host closed the connection]
<karolherbst>
huh
<karolherbst>
should be easy to debug then
alanc has joined #dri-devel
<darkbasic4>
yeah that's the good part. I thought cl was working fine because the .desktop file sneakly disables it
<karolherbst>
I see
<karolherbst>
atm I am more or less focusing on getting basic radeonsi support merged though, so maybe best to file a bug and steps to reproduce it the easiest way
lygstate has quit [Read error: Connection reset by peer]
<karolherbst>
thanks!
heat has joined #dri-devel
pochu has quit [Quit: leaving]
bcheng has quit [Remote host closed the connection]
bcheng has joined #dri-devel
cphealy has quit [Quit: Leaving]
cphealy has joined #dri-devel
rsjw has quit [Ping timeout: 480 seconds]
rsjw has joined #dri-devel
<karolherbst>
jenatali: the only annoying part of embedding the headers is, that I have no idea how stable it is on clang upgrades... what if they change stuff in a way that older headers won't work with newer clang... or they fix bugs in it :/
<jenatali>
Could always statically link clang too lol
<karolherbst>
....
<karolherbst>
distributions will hate me
<jenatali>
Yeah I was kidding
<jenatali>
But yeah that base header is relatively stable afaik and you're not depending on the larger one anymore, right?
<karolherbst>
correct
<karolherbst>
but that doesn't stop people compiling against llvm-13 still
<karolherbst>
we use the base header for 14 or 15+ I think?|
<karolherbst>
uhhhh... why...
<karolherbst>
why does it have to be like that... I mean... couldn't they consider this use case?
<karolherbst>
why do we even have to deal with the resource path in the first place :(
junaid_ has joined #dri-devel
<karolherbst>
uhhh
<karolherbst>
jenatali: btw.. there is a bug in clc....
<karolherbst>
if you have multiple processes compiling with provided headers they might conflict
<karolherbst>
do we really have to maintain a temp directory?
<karolherbst>
system_temp_directory is /var/tmp of C:/TEMP
<karolherbst>
*or
<jenatali>
For the exact problem you're describing
<jenatali>
AddRemappedFile
<karolherbst>
no, I mean, why would it be virtual
<karolherbst>
ohh sure
<karolherbst>
but you still have that openclon12 directory
<jenatali>
To avoid conflicts and writing to the filesystem for no good reason?
<jenatali>
Yeah I think that was just to pick a path that nobody would use as an actual include path
<jenatali>
It can be anything
<karolherbst>
mhhh
<karolherbst>
so when I run the compiler tests in parallel I do have them failing sometimes
<jenatali>
I don't think that would be the problem
<karolherbst>
and it's because of sometihng happening in tmp, but that could also be the cts? dunno, never debugged that properly. I just blamed the CTS
tanty has quit []
<karolherbst>
mhh but yeah.. maybe I should take a deeper look and rule that out
<jenatali>
But yeah our compiler definitely doesn't touch the filesystem for user headers
<karolherbst>
okay
tanty has joined #dri-devel
junaid_ has quit [Remote host closed the connection]
<karolherbst>
jenatali: remember what the problem was with GetResourcesPath?
<jenatali>
I never tried to do anything at runtime
<jenatali>
We embedded our header at compile time from the start
<karolherbst>
I am wondering if I can just GetResourcesPath("clang", "") ...
Ahuj has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
gouchi has joined #dri-devel
junaid has quit [Remote host closed the connection]
Ahuj has quit [Ping timeout: 480 seconds]
rsjw has quit [Quit: rsjw]
dcz_ has quit [Ping timeout: 480 seconds]
Company has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
fab has joined #dri-devel
<alyssa>
so umm
<alyssa>
why does list_del not work properly inside list_for_each_entry_safe?!
<alyssa>
this code is a copypaste of panfrost and it works there
<dj-death>
do you delete the element you're iterating over? or another? ;)
<airlied>
yeah deleting the next element would be bad :-P
<alyssa>
dj-death: the one I'm iterating over
<dj-death>
odd
<alyssa>
if I switch to _rev instead of _safe it works
<alyssa>
having a big wtf moment here
<airlied>
some other thread hitting it?
<alyssa>
whole thing is inside a mutex
<airlied>
is the other side :-P
<alyssa>
?
<airlied>
the code adding things to he list
<alyssa>
oh
<alyssa>
also locked, same lock
<alyssa>
and now random other asserts are fired
<alyssa>
so i guess there's some deep memory unsafety happening
<alyssa>
i need rust c:
Duke`` has quit [Ping timeout: 480 seconds]
<alyssa>
oh f
<alyssa>
botched rebase
<alyssa>
delight
apinheiro has joined #dri-devel
Leopold__ has quit []
gouchi has quit [Remote host closed the connection]
<karolherbst>
always enable libasan or something :P
<dj-death>
you're going to have fun with embedded lists and asan ;)
<karolherbst>
why?
<dj-death>
unaligned memory accesses on empty lists
apinheiro has quit [Quit: Leaving]
tanty has quit []
fab has quit [Quit: fab]
anholt_ has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: couldn't get asan to work
<karolherbst>
:(
<karolherbst>
though that's on the m1, right?
<alyssa>
arm64/16KiB means whether given software works is a crapshoot
<alyssa>
yep
tanty has joined #dri-devel
<karolherbst>
yeah...
Haaninjo has quit [Quit: Ex-Chat]
YuGiOhJCJ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]