<emersion>
hikiko: i'm not too happy about the uint64_t cast
<emersion>
but the rest LGTM
<hikiko>
emersion, what else could we do to avoid it?
<hikiko>
I am not sure if it's a good idea to patch the int-ll64.h
<hikiko>
is it?
apinheiro has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
shashank_sharma has joined #dri-devel
<pq>
hikiko, at least I'm still confused about where does passing a __u64 to PRIu64 exactly cause compiler warnings, which platform, libc, and compiler exactly? I see a lot of hypotheses in the MR discussions, but no clear "the warning ... I get on ..." which should also be in the commit message.
shashank_sharma has quit [Read error: Connection reset by peer]
<emersion>
pq: on Linux + glibc it seems
i-garrison has quit []
<pq>
then that should be clearly stated :-)
<emersion>
glibc says uint64_t is `long long unsigned`, but kernel uAPI headers say it's `long unsigned`
<emersion>
or the other way around
<hikiko>
the other way around :)
<pq>
That's the theory. There really should be literally quoted examples of the error messages.
<pq>
and details on which platform, libc and compiler this happens on
i-garrison has joined #dri-devel
<pq>
now that I try it myself, I see the warnings
<hikiko>
ok, pq I will build it on Linux/BSD and paste the warnings plus the differences between the systems
shashanks has quit [Ping timeout: 480 seconds]
<hikiko>
on BSD the definition is matching libc's as far as I remember
<hikiko>
the problem was linux specific
<hikiko>
but I'll try to update the MR later
<pq>
It's hard for me to see any other solution than the explicit '(uint64_t)' cast.
<emersion>
well, update either glibc or linux uapi headers to make them agree
<pq>
is that even possible?
<hikiko>
glibc is a bad idea I think because then all other unix based systems will have to update their headers too
<emersion>
every user-space program will run into the mismatch, not just libdrm
<pq>
I bet that is just going to provoke a different set of warnings on software that used to not have them.
<emersion>
the problem only happens on 64-bit systems, where both `long long` and `long` are 64-bit types
<emersion>
well, feel free to merge
<hikiko>
thank you, can I add your R-b's too emersion and maybe pq?
<pq>
I didn't review it.
<hikiko>
ok :)
<pq>
it just looked like a bizarre problem to have, but reality is strange it seems
<emersion>
you can add my R-b on all changes except the casts
<hikiko>
ok!
<hikiko>
but still merge the casts right?
<hikiko>
thank you both!
<emersion>
well, i don't know what the libdrm rules are anymore
<emersion>
it seems people just merge their own stuff without review
<hikiko>
well, then I will add a comment in the code explaining the cast before merging so that if people later disagree or Linux headers change we can revert them
lumag_ has joined #dri-devel
lumag_ has quit []
<hikiko>
and split it in 2 commits
thellstrom has quit [Ping timeout: 480 seconds]
<emersion>
ideally 3
<hikiko>
ok!
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
rkanwal has joined #dri-devel
sadlerap has quit [Read error: Connection reset by peer]
shashanks has joined #dri-devel
shashank_sharma has joined #dri-devel
shashank_s has joined #dri-devel
shashank_sharma has quit [Read error: Connection reset by peer]
shashank_s has quit [Read error: Connection reset by peer]
shashank_s has joined #dri-devel
mi6x3m has joined #dri-devel
<mi6x3m>
hey, how important is the C++ RTTI for mesa?
<mi6x3m>
does it increase performance or stability?
<karolherbst>
mi6x3m: sadly it's required by nouveau
<karolherbst>
as we use typeof
<karolherbst>
ehh typeid or something
shashanks has quit [Ping timeout: 480 seconds]
<karolherbst>
yep typeid and only in one place
shashanks has joined #dri-devel
<karolherbst>
gtest also seems to make use of rtti
<mi6x3m>
ok, no issue, i was just asking because of llvm
<karolherbst>
yeah.......
<karolherbst>
not sure if we need llvm with rtti, but..
<karolherbst>
I suspect we do
<karolherbst>
"isa" requires rtti, no?
<mi6x3m>
i guess it's needed because of the error message
<mi6x3m>
anyhow, swrast automatically uses llvm when it's available, no?
<karolherbst>
we have two swrast drivers
<pinchartl>
dynamic_cast can also require rtti (not sure how widespread dynamic_cast usage is in mesa)
<karolherbst>
one slow onw, not using llvm and another one being faster and using llvm
<mi6x3m>
how do i select the llvm one in gallium_drivers?
<karolherbst>
pinchartl: clover uses it
<karolherbst>
mi6x3m: by compiling with llvm turned on
<mi6x3m>
right, what i supposed :)
<mi6x3m>
thanks!
<karolherbst>
anyway.. nouveau can live without rtti, as typeid is only used in a assertion
<karolherbst>
clover on the other hand...
<pq>
Does RTTI also spread through C++ linking? If you link two object files with C++ linkage, don't they both need to agree on whether RTTI exists or not?
<karolherbst>
probably
devilhorns has joined #dri-devel
jeeeun84 has joined #dri-devel
slattann has quit [Quit: Leaving.]
AndrewR has quit [Ping timeout: 480 seconds]
itoral has quit []
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
lsd|2 has joined #dri-devel
lsd|2 has left #dri-devel [#dri-devel]
mi6x3m has quit [Quit: Leaving]
kchibisov_ has quit [Read error: Connection reset by peer]
kchibisov has joined #dri-devel
mi6x3m has joined #dri-devel
<mi6x3m>
hey, what is the gallium draw module?
<mi6x3m>
description : 'Whether to use LLVM for the Gallium draw module, if LLVM is included.'
AndrewR has joined #dri-devel
Danct12 has quit [Quit: Leaving]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
mi6x3m has quit [Quit: Leaving]
apinheiro has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
mbrost has joined #dri-devel
dllud has quit []
dllud has joined #dri-devel
pcercuei has quit [Quit: brb]
aravind has quit [Ping timeout: 480 seconds]
<hikiko>
emersion, and pq after a second thought I think we can't do anything about the linux kernel. I checked and __u64 isn't part of the C standard so everyone can define it at will, so we can't ask the Linux kernel dev to change the ull to something more convenient unfortunately. I merged it like that and added this last thought to the MR discussion.
<pq>
ok, thanks
mclasen has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
Haaninjo has joined #dri-devel
pcercuei has joined #dri-devel
mmenzyns has quit []
mmenzyns has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
technopoirot has quit [Ping timeout: 480 seconds]
technopoirot has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
dEQP + shader-db is really good actually :'o
mbrost_ has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
stuart has joined #dri-devel
<alyssa>
er, dEQP + drm-shim, having a slow morning
pcercuei has joined #dri-devel
mbrost_ has joined #dri-devel
pcercuei has quit [Quit: brb]
shashank_sharma has joined #dri-devel
<danvet>
melissawen, did you see the vkms configfs patches?
pcercuei has joined #dri-devel
<melissawen>
danvet, I saw when they arrived... but I still couldn't stop to review
shashanks has quit [Ping timeout: 480 seconds]
shashank_s has quit [Ping timeout: 480 seconds]
devilhorns has quit [Remote host closed the connection]
mbrost_ has quit [Ping timeout: 480 seconds]
shashank_sharma has quit [Ping timeout: 480 seconds]
<jenatali>
mi6x3m: FWIW there's also a way to build with LLVM turned on but select the slow one if you want. We use it to build once for our GL and CL stacks, but avoid pulling in LLVM into the GL binary (since Windows requires static linking with LLVM and that makes it biiiig)
<jenatali>
pq: I'm ~90% sure that the MSVC ABI doesn't, but for the Itanium ABI it does
<jenatali>
mi6x3m: Oh didn't read back far enough - that option you found is the one I'm talking about. The draw module is the component that interprets/JITs shaders, either for GL API needs on hardware, or because you're using software
frieder has quit [Remote host closed the connection]
<javierm>
danvet, tzimmermann: I believe Andrzej is right and found yet another fb_info lifetime bug, this time in drm_fb_helper.c
kushal_ has joined #dri-devel
<javierm>
danvet, tzimmermann: have the temptation to make fb_info use kref
kushal_ has quit []
<mattst88>
has anyone packaged the amber branch yet? tjaalton maybe?
<mattst88>
wondering what I need to do with some libraries it produces like libgbm.so, libglapi.so, etc
<tjaalton>
mattst88: yep, the deb only ships libEGL_amber, libGLX_amber and the dri drivers
<mattst88>
tjaalton: okay, so do you build with -Dgbm=enabled but then delete libgbm.so?
<tjaalton>
mattst88: looks like gbm disabled
<mattst88>
interesting, okay. I ask because some of the EGL paths are dependent on gbm being enabled
<mattst88>
e.g. EGL_KHR_platform_gbm
heat has joined #dri-devel
gouchi has joined #dri-devel
<tzimmermann>
javierm, the whole block near line 630 looks suspect to me
mbrost_ has joined #dri-devel
technopo1rot has joined #dri-devel
technopoirot has quit [Ping timeout: 480 seconds]
gouchi has quit [Quit: Quitte]
soreau has quit [Remote host closed the connection]
dlromw^ has quit [Remote host closed the connection]
slattann has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
agd5f_ has joined #dri-devel
<karolherbst>
dcbaker: I am currently wondering what's the best way of integrating clippy into meson. It's a bit of a drop in replacement for rustc, but they say it shouldn't be used as such
<dcbaker>
Right now we support it as a drop in replacement for rustc
<karolherbst>
ohh.. how can I switch over btw?
<dcbaker>
You can just set RUSTC=clippy-driver and go (I think it’s the driver)
jkrzyszt has quit [Ping timeout: 480 seconds]
<karolherbst>
do I have to reconfigure/throw away build?
<dcbaker>
Yes, unfortunately
<dcbaker>
We really don’t have any other way to deal with the compiler changing :/
stuart has joined #dri-devel
<karolherbst>
mhh, I think we might need special rust targets
dllud has quit [Read error: Connection reset by peer]
<karolherbst>
maybe even for rustfmt as well
<karolherbst>
but.. for clippy we might want to compile rust project normally with rustc and then add a clippy target which uses compiled rust libs and just runs clippy-driver instead?
<karolherbst>
dunno
<dcbaker>
Yeah, adding rustfmt has been on my list, we support clang-format and clang-tidy targets already
<karolherbst>
cool
stuarts has joined #dri-devel
<dcbaker>
That might be a better way to handle clippy, I’d have too look at what all it entails
agd5f has quit [Ping timeout: 480 seconds]
<karolherbst>
but yeah.. I think for clippy we might want to duplicate targets so that compiled binaries don't end up being produced from clippy? dunno
<karolherbst>
I don't know what issues it can cause if we use binaries from clippy
shashanks has joined #dri-devel
stuarts has quit []
stuarts has joined #dri-devel
dllud has joined #dri-devel
nchery has joined #dri-devel
adjtm has joined #dri-devel
stuart has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
slattann has quit []
stuarts has quit [Remote host closed the connection]
<zmike>
dcbaker: gonna do a few more backports
<dcbaker>
zmike: sounds good
<zmike>
think I even managed it without breaking the branch this time
Danct12 has joined #dri-devel
alanc has quit [Remote host closed the connection]
<danvet>
javierm, yeah I guess I get a price for looking for the right kind of bug and still being blind :-)
apinheiro has joined #dri-devel
mbrost has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
mclasen has quit []
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
stuart has joined #dri-devel
<karolherbst>
oh no.. clippy hates me for doing Err(..)? :D
<karolherbst>
guess I'll change it then
<imirkin>
clippy?
<imirkin>
"Can you I help you with error handling today?" -- that clippy?
<karolherbst>
:D kind of
rkanwal has quit [Quit: rkanwal]
<karolherbst>
no, it's the thing for rust which complains about your shitty code
rkanwal has joined #dri-devel
<imirkin>
ah heh
<karolherbst>
so it points us things you shouldn't do :)
<karolherbst>
*out
mbrost has quit [Ping timeout: 480 seconds]
<Lyude>
mh, trying to restore the atomic state on system resume was such a bad idea :(
mbrost has joined #dri-devel
<javierm>
danvet: well, you can't beat me at that since I missed that added a use-after-free in efifb after trying to fix one...
<javierm>
felt like an idiot after that, but at least learned that I should wait at least a week before pushing fixes to give time to the bots to stress the patches
danvet has quit [Ping timeout: 480 seconds]
stuarts has joined #dri-devel
technopo1rot has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
adjtm has quit [Quit: Leaving]
icecream95 has joined #dri-devel
mbrost has joined #dri-devel
apinheiro has quit [Quit: Leaving]
ahajda has joined #dri-devel
<karolherbst>
airlied: on that MR, at first I was like: 🤔🤔 now I am like: 🔥🔥 burn it
AndrewR has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
iive has quit []
Duke`` has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
pcercuei has quit [Quit: dodo]
mbrost has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]