<dcbaker>
imirkin: yes. You asked me to do that already and i forgot :(
<imirkin>
dcbaker: ok. let's just nuke it then and see what falls out
<imirkin>
i always hated that build check anyways
<dcbaker>
Nuking the check is problematic
mripard has quit [Read error: Connection reset by peer]
bbrezillon has quit [Read error: Connection reset by peer]
<dcbaker>
C++ with and without rtti had a different abi, iirc
<dcbaker>
So linking between them is undefined behavior
<dcbaker>
curro knows all of those rules better than i do though
<imirkin>
dcbaker: between any two libraries?
<imirkin>
then we're just totally screwed no?
<imirkin>
since some libs may be built with rtti and not others
<imirkin>
this isn't like there's rtti at the ABI level
<imirkin>
and why would nouveau be singled out
<imirkin>
i.e. i don't think the "different ABI" thing is quite as dire as you suggest
mripard has joined #dri-devel
<dcbaker>
It's been a long time obviously, but i seen to remember mixing rtti and non-rtti is one of those "works in many cases, fails mysteriously on occasion". If be happy to reduce the error to a warning if that makes things easier
<dcbaker>
*I'd be
<imirkin>
but what does nouveau have to do with it?
<imirkin>
just because there's a slight rtti use, doesn't change all that ABI stuff magically
<imirkin>
should start warning if mesa is built with rtti and llvm without (/ vice versa) in that case
<imirkin>
i.e. i'm inclined to remove it.
<imirkin>
trying to super-confirm what happens to typeid if no rtti
lemonzest has joined #dri-devel
Eickmeyer[m] has joined #dri-devel
Eickmeyer[m] has quit [Remote host closed the connection]
<imirkin>
oh. hm...
pntaylor has joined #dri-devel
pntaylor has quit [Remote host closed the connection]
<imirkin>
it might not compile at all. that's a problem :)
<dcbaker>
So, according to the c++ standard no-rtti is undefined behavior. It generally works too link rtti and non-rtti work gcc and clang as long as you don't have virtual functions, call typeid or make a dynamic_cast. So i guess building without rtti is itself a "you get to keep the pieces" situation
<imirkin>
dcbaker: how do i easy force-enable -fno-rtti?
<dcbaker>
I guess given that I'm fine with deleting the check
<imirkin>
i tried "cpp_args += '-fno-rtti'" at the top of novueau's meson.build
<imirkin>
but didn't seem to work
<dcbaker>
Regent meson has a -Db_rtti=false
<dcbaker>
I think
<dcbaker>
Or i guess just add it with -Dcpp_flags=
<dcbaker>
Sorry, I'm on my phone
<imirkin>
no worries
<imirkin>
i put it in top-level meson.build, seems to work
<imirkin>
fwiw nouveau *does* use typeid (in an assert)
<dcbaker>
Yeah, that variable gets processed at the bottom of the main meson.build file iirc
<imirkin>
ahh ok
<dcbaker>
Right, and i ran into that i think
<dcbaker>
Which is why I added that check
<imirkin>
i'll try to work it out. thanks.
<dcbaker>
I guess we could pass rtti as a define as well to wrap that assert in #if HAS_RTTI
<dcbaker>
Np
<imirkin>
i'm just going to make the ifdef take __cpp_rtti into account
<imirkin>
that way it compiles either way
<imirkin>
apparently C++98 requires it
<imirkin>
(and gcc does it)
blue__penquin has joined #dri-devel
slowz has joined #dri-devel
slowz has quit [Remote host closed the connection]
libv has joined #dri-devel
libv__ has quit [Ping timeout: 480 seconds]
rpcope1 has joined #dri-devel
rpcope1 has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
evgeny[m|gr] has joined #dri-devel
evgeny[m|gr] has quit [Remote host closed the connection]
craftyguy_ has joined #dri-devel
craftyguy is now known as Guest1015
craftyguy_ is now known as craftyguy
Guest1015 has quit [Ping timeout: 480 seconds]
bcarvalho has joined #dri-devel
miaoski has joined #dri-devel
miaoski has quit [Remote host closed the connection]
rasterman has joined #dri-devel
blue__penquin has quit []
bcarvalho has quit [Read error: Connection reset by peer]
blue__penquin has joined #dri-devel
jonbryan has joined #dri-devel
jonbryan has quit [Remote host closed the connection]
gouchi has joined #dri-devel
pekkari has joined #dri-devel
hdhog-t has joined #dri-devel
neonking has joined #dri-devel
hdhog-t has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-06 08:16:56)]
danvet has joined #dri-devel
ogabbay___ has joined #dri-devel
Daanct12 has joined #dri-devel
ogabbay___ has quit []
ogabbay has joined #dri-devel
xp4ns3 has quit []
Danct12 has quit [Ping timeout: 480 seconds]
tbr has joined #dri-devel
tbr has quit [Remote host closed the connection]
SOO7 has joined #dri-devel
SOO7 has quit [Remote host closed the connection]
SquidDev has joined #dri-devel
SquidDev has quit [Remote host closed the connection]
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
holdsworth has joined #dri-devel
holdsworth has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-06 09:21:32)]
<imirkin>
ok. maybe just add it to the flakes list?
<zmike>
ab on that 👍
<imirkin>
although the multi-context thing might imply some sort of actual problem
<imirkin>
e.g. doing something in the screen you're not supposed to
<imirkin>
or not handling the context switch properly, etc
<zmike>
I don't think so or I'd see it locally
<imirkin>
well, it'd be a timing issue. maybe check with valgrind if you have a setup handy?
<imirkin>
er, i guess valgrind wouldn't necessarily detect that =/
<imirkin>
TSAN or whatever, but that's a bigger deal.
<zmike>
I can look again next week, but I checked this all recently when I saw it
<imirkin>
ah ok
<imirkin>
if you already looked into it, i'm sure it's nothing trivial then
<imirkin>
i'll send a change to add to flakes list in a bit
<zmike>
the txf timeouts are more annoying
<zmike>
and happen more frequently by far
<imirkin>
=/
<imirkin>
surprising txf would be so slow. texturing in general is pretty slow with llvmpipe, but i would have imagined txf would be the exception to that =/
<zmike>
they're big textures
<airlied>
valgrind --tool=helgrind might be better
<airlied>
found my glx-multithread-texture crash the other day :-P
<zmike>
that mostly just spams billions of false positives for tc
<airlied>
not that tc would ever do anything wrong :-P
<zmike>
no, not even once
<imirkin>
huh. noticed this just now ... there is no ext to enable image2DMS in GLES
GloriousEggroll has quit [Read error: Connection reset by peer]
GloriousEggroll has joined #dri-devel
<airlied>
imirkin: probably sane not to want it :-P
macromorgan has joined #dri-devel
macromorgan_ has quit [Read error: Connection reset by peer]
hadack_ has quit []
cphealy_ has quit []
cphealy has joined #dri-devel
karolherbst has joined #dri-devel
rasterman has quit []
ngcortes has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
reductum has quit []
reductum has joined #dri-devel
reductum has quit []
reductum has joined #dri-devel
gouchi has quit [Remote host closed the connection]
macromorgan_ has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
nsneck_ has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
MrFixIt has joined #dri-devel
MrFixIt has quit [Remote host closed the connection]
jhobbel[m|gr] has joined #dri-devel
jhobbel[m|gr] has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
macromorgan_ has quit [Read error: Connection reset by peer]
macromorgan_ has joined #dri-devel
macromorgan has quit [Remote host closed the connection]