<pq>
thanks, so I should have bothered to sudo to root so I can 'modinfo drm'
Surkow|laptop has joined #dri-devel
xexaxo has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<danvet>
yeah if build system would somehow pull these in automatically it would be nice
<pq>
btw. how do you see the modparam help if the thing is a built-in and not a module?
Duke`` has joined #dri-devel
gpoo has joined #dri-devel
<danvet>
pq, I think you don't
<danvet>
which is also why the build system can't easily pull these all out
rsalvaterra_ has joined #dri-devel
<danvet>
pq, maybe it's there as the .modinfo elf section in the decompressed image
* danvet
not sure
rsalvaterra has quit [Ping timeout: 480 seconds]
<pq>
right
itoral has quit [Remote host closed the connection]
yoslin_ has joined #dri-devel
yoslin has quit [Ping timeout: 480 seconds]
yoslin_ has quit []
yoslin has joined #dri-devel
vivijim has joined #dri-devel
sdutt has joined #dri-devel
rsalvaterra_ has quit []
rsalvaterra has joined #dri-devel
<karolherbst>
the hell... do we have no single distribution where I can install arch foreign packages and where debugging with gdb is not a giant pita?
<karolherbst>
:(
<HdkR>
What's an Arch foreign package in this context?
<MrCooper>
non-x86_64
<karolherbst>
MrCooper: that's not what I meant
<karolherbst>
I meant different from the host
<karolherbst>
not just non x86 :)
<HdkR>
Yea, Arch isn't multi-arch aware. So this is why I'm curious :P
<karolherbst>
HdkR: so I have this container, where I use the binaries of the actual host arch to cross compile
<karolherbst>
but
<karolherbst>
this also requires me to install foreign arch packages for deps and stuff
<karolherbst>
so I have this debian with x86 and s390x binaries/libs and so on
<karolherbst>
and this works great
<karolherbst>
but now I want to debug with gdb-multiarch
<MrCooper>
HdkR: doubt it's anything to do with Arch the distro, "arch foreign" as in "foreign architecture"
<HdkR>
ooooh
<karolherbst>
and... because apt is so stupid I don't get magically the source files added to debugging, because apparently apt source is the only way to get the sources and this just extracts stuff insde the current dir
<karolherbst>
and because I am lazy and might have to dig into a couple of libs I am not looking forward to mess with gdb and substituions and that crap
<karolherbst>
in fedora that's simple.. I install the debug stuff and it's there in gdb
<karolherbst>
but fedora can't do this foreign arch stuff
<HdkR>
ah source packages. I usually get to the point of getting the dbg packages and if I can't resolve by then, custom compile the world :/
<karolherbst>
yeah well
<karolherbst>
I am digging into llvmpipe on s390x :)
<karolherbst>
and I kind of don't want to compile llvm against s390x
<karolherbst>
I mean.. seriously.. that stuff should be simple, no?
<HdkR>
I don't trust any distro to do things outside of the norm. So many heck up multi-arch, asking for multi-arch debug capability? Madness
<karolherbst>
:D
<karolherbst>
well
<karolherbst>
even on a normal debian install you don't get debug sources.. so
<karolherbst>
....
<karolherbst>
or maybe I am missing something
<MrCooper>
this is indeed an area where Debian could learn from Fedora
<karolherbst>
MrCooper: they even say so on the wiki :D
<HdkR>
I won't say Debian does it correctly either :P
<karolherbst>
I mean.. I could also just use a s390x fedora container, but then the compiler runs through qemu :/
<MrCooper>
debuginfod could help in theory, but I suspect there may be no servers for s390x
<karolherbst>
yeah....
<karolherbst>
I tried that of course
<karolherbst>
but maybe I messed something up
<MrCooper>
maybe you could set up a debuginfod server for s390x :)
<karolherbst>
...
<pq>
karolherbst, I suppose you have not yet needed to add a handful of source search paths in gdb just to be able to see Mesa sources alone, not to speak of any other projects? :-)
<karolherbst>
pq: I didn't
<karolherbst>
in fedora that just works out of the box :)
<pq>
I have, I think it was on Ubuntu
<karolherbst>
biggest reason to not use ubuntu for native development :)
<pq>
because different pieces of Mesa were built with a different "root" dir, so they need different source search paths...
<karolherbst>
...
<karolherbst>
maybe I ditch the idea of using a debian container alltogether :D
<pq>
tbh, I don't know if that was due to Ubuntu, Debian or Mesa itself.
<karolherbst>
all I can say I never needed that on fedora
illwieckz has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe I could create a fedora s390x chroot, compile against that and run that stuff via systemd-nspawn or so...
<karolherbst>
but that also sounds like pain
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
illwieckz has joined #dri-devel
mattrope has joined #dri-devel
cef is now known as Guest895
Guest895 has quit [Ping timeout: 480 seconds]
cef has joined #dri-devel
phomes has quit [Quit: Page closed]
rsalvaterra_ has joined #dri-devel
xcube has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
cef is now known as Guest897
cef has joined #dri-devel
Guest897 has quit [Ping timeout: 480 seconds]
rsalvaterra_ has quit []
rsalvaterra has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
pochu has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
tobiasjakobi has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
xcube has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
ngcortes has joined #dri-devel
NiksDev2 has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
nchery has joined #dri-devel
frieder has quit [Remote host closed the connection]
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
pekkari has joined #dri-devel
pekkari has quit []
tzimmermann has quit [Quit: Leaving]
Sumera[m] has quit []
Erandir has quit [Read error: Connection reset by peer]
Sumera[m] has joined #dri-devel
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
silver has joined #dri-devel
Erandir has joined #dri-devel
xcube has joined #dri-devel
xexaxo has quit [Ping timeout: 480 seconds]
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
Kayden has quit [Quit: -> lunch -> vast empty wasteland]
mlankhorst has joined #dri-devel
lynxeye has quit []
ngcortes has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
jcline has quit [Remote host closed the connection]
jcline has joined #dri-devel
Kayden has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
<anholt>
apparently NIR currently won't optimize use of vec4 ssa1.x, ssa1.y, undef, ssa1.w into just ssa1.
<karolherbst>
mhhh
<karolherbst>
anholt: maybe we want to treat "undef" als always matching in opt_algebraic?
<anholt>
I don't think opt_algebraic is related
<karolherbst>
ohh
<karolherbst>
copy_prop
<karolherbst>
or something
<anholt>
yeah, copyprop would be the place.
<anholt>
possibly some risk in that then ssa1.z is used when it wasn't before.
<karolherbst>
mhh
<karolherbst>
anholt: well.. one could check if the value is used, but it could also some RA implications
pcercuei has quit [Quit: dodo]
cbaylis has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
Does anyone mind if disassembler/assembler for a new architecture live in Mesa, in advance of the compiler being brought up?
<alyssa>
(Otherwise I'll stick it on a separate GitLab repo)
<anholt>
Assuming it's a future mesa-supportable GPU, I'm in favor of in-tree over eventual code dump.
<cbaylis>
If you call isatty() on a drm device, glibc does ioctl(fd, TCGETS, ...) and the DRM subsystem apparently doesn't notice that this is not a DRM ioctl and something random happens. I have a patch https://pastebin.com/0b6jfZUP I'm very out of date with kernel development, so I haven't worked out how to test it yet, but does it look sensible?
<alyssa>
anholt: 👍 will prepare the merge request then
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
and yes, very much intended to support in panfrost+panvk, but holding off on doing much more than r/e until there's hardware other than android phones..