ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
kzd has quit [Quit: kzd]
sarnex has joined #dri-devel
guru_ has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
sarnex has quit [Ping timeout: 480 seconds]
Danct12 has quit [Read error: Connection reset by peer]
oneforall2 has joined #dri-devel
luben has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
vliaskov has quit []
kzd has joined #dri-devel
Danct12 has joined #dri-devel
<ndufresne>
Company: rk3399 based board could be worth it, Intel 8K too
<Company>
ndufresne: I'm asking because mclasen has a branch going that does passthrough to the compositor, but to test how well it actually works and if it's worth it, we'd need an actual setup that benefits
<Company>
and neither mutter nor desktop hardware really care if you passthrough
<ndufresne>
What does it mean "they don't care?"
<Company>
your demo does run at 60fps with no noticeable CPU usage
<Company>
no matter if you passthrough or accidentally fallback to software rendering
<ndufresne>
With Weston or wlroot based compositor, HW layers will be used automatically, meaning you can go from codec to display without using the GPU
<ndufresne>
Try 4K60 fps ?
sarnex has joined #dri-devel
<ndufresne>
No GPU means the GPU can go to lower power state, and you get longer playback on battery, cooler system -> quieter experience
<ndufresne>
Well, that is for arm system, of course on PC your codec is in GPU
<Company>
if it actually is
<Company>
my codec is in vp9dec atm
<Company>
89% cpu usage for a 4k video
<Company>
mplayer takes 45%, mpv 60%
<ndufresne>
Ah, so you are looking at dmanuf passthrough for software decode
rcf has quit [Quit: WeeChat 3.8]
<ndufresne>
Skipping GPU is one thing that comes to mind, but also avoiding forcing your compositor into Texture2D can help, the cpu load in such context should be the sum of app + compositor
<Company>
ndufresne: I'm looking at something that makes it visually obvious that passthrough doesn't work
<Company>
ndufresne: I want to see when it breaks
djbw has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
yyds has joined #dri-devel
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
yuq825 has joined #dri-devel
ginnie_zhou has joined #dri-devel
Daanct12 has joined #dri-devel
kts has joined #dri-devel
ginnie_zhou_ has joined #dri-devel
ginnie_zhou has quit []
agd5f_ has joined #dri-devel
JohnnyonFlame has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
tristianc6704 has quit []
tristianc6704 has joined #dri-devel
flynnjiang has joined #dri-devel
flynnjiang has quit [Read error: Connection reset by peer]
flynnjiang has joined #dri-devel
nchery has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
djbw has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
rcf has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
luben has quit [Remote host closed the connection]
kts has joined #dri-devel
luben has joined #dri-devel
luben_ has joined #dri-devel
luben_ has quit []
kts has quit [Ping timeout: 480 seconds]
luben has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
alpalcone has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
aravind has joined #dri-devel
djbw has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Duke`` has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
tzimmermann has joined #dri-devel
sima has joined #dri-devel
aravind has joined #dri-devel
glennk has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
oneforall2 has quit [resistance.oftc.net weber.oftc.net]
Aura has quit [resistance.oftc.net weber.oftc.net]
alanc has quit [resistance.oftc.net weber.oftc.net]
anujp has quit [resistance.oftc.net weber.oftc.net]
macromorgan has quit [resistance.oftc.net weber.oftc.net]
Shibe has quit [resistance.oftc.net weber.oftc.net]
soreau has quit [resistance.oftc.net weber.oftc.net]
greenjustin has quit [resistance.oftc.net weber.oftc.net]
cborah1 has quit [resistance.oftc.net weber.oftc.net]
Kayden has quit [resistance.oftc.net weber.oftc.net]
JTL has quit [resistance.oftc.net weber.oftc.net]
jolan has quit [resistance.oftc.net weber.oftc.net]
rauji___ has quit [resistance.oftc.net weber.oftc.net]
linyaa has quit [resistance.oftc.net weber.oftc.net]
andrey-konovalov has quit [resistance.oftc.net weber.oftc.net]
exit70 has quit [resistance.oftc.net weber.oftc.net]
nchery has quit [resistance.oftc.net weber.oftc.net]
ginnie_zhou_ has quit [resistance.oftc.net weber.oftc.net]
agd5f has quit [resistance.oftc.net weber.oftc.net]
linusw has quit [resistance.oftc.net weber.oftc.net]
cheako has quit [resistance.oftc.net weber.oftc.net]
naseer7 has quit [resistance.oftc.net weber.oftc.net]
sh_zam has quit [resistance.oftc.net weber.oftc.net]
mattrope has quit [resistance.oftc.net weber.oftc.net]
rsripada has quit [resistance.oftc.net weber.oftc.net]
aswar002 has quit [resistance.oftc.net weber.oftc.net]
Sachiel has quit [resistance.oftc.net weber.oftc.net]
kem has quit [resistance.oftc.net weber.oftc.net]
Lyude has quit [resistance.oftc.net weber.oftc.net]
cyrozap has quit [resistance.oftc.net weber.oftc.net]
sauce has quit [resistance.oftc.net weber.oftc.net]
steve--w has quit [resistance.oftc.net weber.oftc.net]
mchehab_ has quit [resistance.oftc.net weber.oftc.net]
rcn-ee___ has quit [resistance.oftc.net weber.oftc.net]
mdnavare has quit [resistance.oftc.net weber.oftc.net]
hfink has quit [resistance.oftc.net weber.oftc.net]
steev has quit [resistance.oftc.net weber.oftc.net]
dri-logger has quit [resistance.oftc.net weber.oftc.net]
krh has quit [resistance.oftc.net weber.oftc.net]
ogabbay has quit [resistance.oftc.net weber.oftc.net]
vignesh has quit [resistance.oftc.net weber.oftc.net]
benettig has quit [resistance.oftc.net weber.oftc.net]
ernstp has quit [resistance.oftc.net weber.oftc.net]
tfiga has quit [resistance.oftc.net weber.oftc.net]
SanchayanMaity has quit [resistance.oftc.net weber.oftc.net]
kathleen_ has quit [resistance.oftc.net weber.oftc.net]
vgpu-arthur has quit [resistance.oftc.net weber.oftc.net]
ddavenport_ has quit [resistance.oftc.net weber.oftc.net]
pundir has quit [resistance.oftc.net weber.oftc.net]
norris has quit [resistance.oftc.net weber.oftc.net]
jhugo has quit [resistance.oftc.net weber.oftc.net]
appusony____ has quit [resistance.oftc.net weber.oftc.net]
naseer__ has quit [resistance.oftc.net weber.oftc.net]
NishanthMenon has quit [resistance.oftc.net weber.oftc.net]
angular_mike______ has quit [resistance.oftc.net weber.oftc.net]
tchar has quit [resistance.oftc.net weber.oftc.net]
hwentlan_ has quit [resistance.oftc.net weber.oftc.net]
haasn has quit [resistance.oftc.net weber.oftc.net]
_alice has quit [resistance.oftc.net weber.oftc.net]
lvrp16 has quit [resistance.oftc.net weber.oftc.net]
jluthra has quit [resistance.oftc.net weber.oftc.net]
pendingchaos has quit [resistance.oftc.net weber.oftc.net]
seanpaul has quit [resistance.oftc.net weber.oftc.net]
sskras has quit [resistance.oftc.net weber.oftc.net]
jstultz has quit [resistance.oftc.net weber.oftc.net]
vaishali has quit [resistance.oftc.net weber.oftc.net]
cwabbott has quit [resistance.oftc.net weber.oftc.net]
melissawen has quit [resistance.oftc.net weber.oftc.net]
demarchi has quit [resistance.oftc.net weber.oftc.net]
siqueira has quit [resistance.oftc.net weber.oftc.net]
radii_ has quit [resistance.oftc.net weber.oftc.net]
swivel has quit [resistance.oftc.net weber.oftc.net]
robink has quit [resistance.oftc.net weber.oftc.net]
codingkoopa32 has quit [resistance.oftc.net weber.oftc.net]
smaeul has quit [resistance.oftc.net weber.oftc.net]
rossy has quit [resistance.oftc.net weber.oftc.net]
SolarAquarion has quit [resistance.oftc.net weber.oftc.net]
kisak has quit [resistance.oftc.net weber.oftc.net]
graphitemaster has quit [resistance.oftc.net weber.oftc.net]
narmstrong has quit [resistance.oftc.net weber.oftc.net]
rcombs has quit [resistance.oftc.net weber.oftc.net]
rodrigovivi has quit [resistance.oftc.net weber.oftc.net]
rib has quit [resistance.oftc.net weber.oftc.net]
zzag has quit [resistance.oftc.net weber.oftc.net]
markco has quit [resistance.oftc.net weber.oftc.net]
zx2c4 has quit [resistance.oftc.net weber.oftc.net]
tfiga_ is now known as tfiga
steev_ is now known as steev
NishanthMenon_ is now known as NishanthMenon
appusony____ has joined #dri-devel
melissawen has joined #dri-devel
cyrozap has joined #dri-devel
sauce has joined #dri-devel
rib has joined #dri-devel
andrey-konovalov has joined #dri-devel
ogabbay has joined #dri-devel
narmstrong has joined #dri-devel
linusw has joined #dri-devel
soreau has joined #dri-devel
benettig has joined #dri-devel
nchery has joined #dri-devel
tchar has joined #dri-devel
sh_zam has joined #dri-devel
haasn has joined #dri-devel
agd5f has joined #dri-devel
rodrigovivi has joined #dri-devel
vignesh has joined #dri-devel
rcn-ee___ has joined #dri-devel
pendingchaos has joined #dri-devel
anujp has joined #dri-devel
Kayden has joined #dri-devel
norris has joined #dri-devel
kathleen_ has joined #dri-devel
naseer__ has joined #dri-devel
rsripada has joined #dri-devel
dri-logger has joined #dri-devel
markco has joined #dri-devel
hansg has joined #dri-devel
mvlad has joined #dri-devel
xantoz has joined #dri-devel
sarahwalker has joined #dri-devel
cwabbott_ has quit []
cwabbott has joined #dri-devel
cmichael has joined #dri-devel
SolarAquarion has joined #dri-devel
Ahuj has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
jluthra_ has quit []
jluthra_ has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
jluthra_ has quit []
vliaskov has joined #dri-devel
jluthra has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
pundir_ is now known as pundir
ced117 has joined #dri-devel
Aura has joined #dri-devel
rsripada has quit [Server closed connection]
rsripada has joined #dri-devel
naseer__ has quit [Server closed connection]
naseer__ has joined #dri-devel
harrryhan has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
dri-logger has quit [Server closed connection]
dri-logg1r has joined #dri-devel
pcercuei has joined #dri-devel
harrryhan has joined #dri-devel
norris has quit [Server closed connection]
norris has joined #dri-devel
Kayden has quit [Server closed connection]
Kayden has joined #dri-devel
kathleen_ has quit [Server closed connection]
kathleen_ has joined #dri-devel
pendingchaos has quit [Server closed connection]
pendingchaos has joined #dri-devel
rodrigovivi has quit [Server closed connection]
rodrigovivi has joined #dri-devel
agd5f has quit [Server closed connection]
agd5f has joined #dri-devel
haasn has quit [Server closed connection]
haasn has joined #dri-devel
vignesh has quit [Server closed connection]
vignesh has joined #dri-devel
tchar has quit [Server closed connection]
tchar has joined #dri-devel
anujp has quit [Server closed connection]
anujp has joined #dri-devel
Aura has quit [Ping timeout: 480 seconds]
hansg has quit [Ping timeout: 480 seconds]
Aura has joined #dri-devel
benettig has quit [Server closed connection]
benettig has joined #dri-devel
hansg has joined #dri-devel
rcn-ee___ has quit [Server closed connection]
rcn-ee___ has joined #dri-devel
linusw has quit [Server closed connection]
linusw has joined #dri-devel
agd5f_ has joined #dri-devel
hansg has quit [Quit: Leaving]
ogabbay has quit [Server closed connection]
ogabbay has joined #dri-devel
habernir has joined #dri-devel
narmstrong has quit [Server closed connection]
narmstrong has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
rib has quit [Server closed connection]
rib has joined #dri-devel
habernir has quit []
habernir has joined #dri-devel
soreau has quit [Server closed connection]
soreau has joined #dri-devel
habernir has quit []
habernir has joined #dri-devel
Tele42 is now known as kisak
<javierm>
tzimmermann: the patch makes sense to me. Do you think that's worth to add a Fixes: commit c76f0f7cb546 ("drm: Begin an API for in-kernel clients") ?
sh_zam has quit [Server closed connection]
sh_zam has joined #dri-devel
<tzimmermann>
javierm, thanks for looking. i'd not bother about the fixes tag. the dependency handling now works correctly as the fbdev helpers depend on the driver module. maybe this wasn't the case in earlier releases
<tzimmermann>
and i only found that issue because i915 tests for unloading the driver module. no other driver seems to bother
nchery has quit [Server closed connection]
nchery has joined #dri-devel
<tzimmermann>
javierm, could you please send an ack to the list?
<habernir>
anyone know what happen to mesa version 23.2.2?
<habernir>
or everything is ok with dylan baker
<habernir>
?
andrey-konovalov has quit [Server closed connection]
<javierm>
tzimmermann: done
<tzimmermann>
javierm, thank you
andrey-konovalov has joined #dri-devel
<tzimmermann>
javierm, there's something else to ask you. that work on fbdev init helpers and macros is comming to an end. i only have various patches left that implement this and that. shall i post them in one big series?
cyrozap has quit [Server closed connection]
cyrozap has joined #dri-devel
sauce has quit [Server closed connection]
sauce has joined #dri-devel
appusony____ has quit [Server closed connection]
appusony____ has joined #dri-devel
<javierm>
tzimmermann: sure, that works for me. I'll probably won't have time to do any review until Friday though
<tzimmermann>
no worries :)
yyds_ has quit [Remote host closed the connection]
melissawen has quit [Server closed connection]
melissawen has joined #dri-devel
markco has quit [Server closed connection]
markco has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.1.1]
gio has quit []
cmichael has quit [Server closed connection]
cmichael has joined #dri-devel
SolarAquarion has quit [Server closed connection]
SolarAquarion has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
Elen has joined #dri-devel
harrryhan has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
Elen has quit []
i509vcb has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
yuq825 has quit [Remote host closed the connection]
habernir has quit [Quit: Leaving]
yyds has joined #dri-devel
harrryhan has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
jhugo_ is now known as jhugo
yyds has quit [Remote host closed the connection]
harryhanYuhao_ has joined #dri-devel
Company has joined #dri-devel
harrryhan has quit [Ping timeout: 480 seconds]
<gfxstrand>
dcbaker: FYI: My goal for this week is to land NAK.
<gfxstrand>
dcbaker: I'm working on figuring out how to hack around the 32-bit problems. I'm experimenting with marking things native in the wraps I pull in (they're only used for proc macro build deps) but still having issues where it can't find built-in creates like core::
ginnie_zhou__ has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
cphealy has joined #dri-devel
Haaninjo has joined #dri-devel
heat_ has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
macslayer has joined #dri-devel
harryhanYuhao_ has quit []
harrryhan has joined #dri-devel
greenjustin_ is now known as greenjustin
pekkari has joined #dri-devel
gio has joined #dri-devel
macromorgan_ has quit []
aravind has joined #dri-devel
macromorgan has joined #dri-devel
kzd has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
<bl4ckb0ne>
is there something specific to do to get the MESA prefix for an EGL ext beside producing the impl?
<emersion>
need to reserve in khronos
<emersion>
and merge the API there as well I think
simon-perretta-img has joined #dri-devel
hfink_ has quit []
hfink has joined #dri-devel
caef^ has quit [Ping timeout: 480 seconds]
Mangix has quit [Ping timeout: 480 seconds]
macromorgan has quit [Quit: Leaving]
macromorgan has joined #dri-devel
lyudess has quit []
Lyude has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
pekkari has joined #dri-devel
pekkari has quit []
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
Ahuj has quit [Ping timeout: 480 seconds]
cmichael has quit []
<gfxstrand>
Anyone feeling brave and want to review a nir_lower_io MR?
<gfxstrand>
I don't strictly need it for NAK but I do need some of it to pass CTS.
<gfxstrand>
I also suspsect other drivers will want it as well. AMD, maybe?
Sachiel_ is now known as Sachiel
greenjustin has quit [Quit: Leaving]
greenjustin has joined #dri-devel
dogukan has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<dcbaker>
gfxstrand: sweet! the can't find core thing is interesting, same branch or a different one? I'll see if I can poke at it a bit and help
harrryhan has quit [Remote host closed the connection]
<gfxstrand>
dcbaker: Let me dig around. IDK that it's in a branch yet.
lynxeye has quit [Quit: Leaving.]
cef has quit [Ping timeout: 480 seconds]
jstultz_ has quit []
jstultz has joined #dri-devel
harrryhan has joined #dri-devel
alanc-away has quit []
alanc has joined #dri-devel
peelz has joined #dri-devel
notpeelz has quit [Ping timeout: 480 seconds]
peelz is now known as Guest5454
<gfxstrand>
dcbaker: nak/native-wrap in my gitlab
harrryhan has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
mdnavare_ has quit []
mdnavare_ has joined #dri-devel
heat has joined #dri-devel
mdnavare_ has quit []
mdnavare_ has joined #dri-devel
tobiasjakobi has joined #dri-devel
vliaskov has joined #dri-devel
smaeul_ has quit []
smaeul has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
vliaskov_ has joined #dri-devel
<airlied>
gfxstrand: btw is it wednesday, pinging about the llvm17 blocker :-)
<gfxstrand>
airlied: Right. Thanks.
<gfxstrand>
I'll take a look at that while dcbaker is poking at meson
<tango_>
hello all, I'm getting a kernel NULL pointer dereference on a thinkpad P15v gen3 amd when I enable both the mesa Clover ICD and the amd rocm (5.7.0) one. no issues if both rocm and rusticl are enabled, or with clover and rusticl. the fault seems to be specifically on clover+rocm. should I file this against mesa, rocm or both?
<tango_>
it's not a showstopper for me because clover can't actually use the gpu anyway for compute, but I thought it might be useful to know that there is this issue
<gfxstrand>
IDK that I particularly trust either driver but I guess file something against clover for now.
<gfxstrand>
Can't promise how quickly someone will look into it but we may as well have it written down.
<gfxstrand>
airlied: I'm gonna have to install LLVM 17 aren't I?...
flom84 has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit []
<airlied>
gfxstrand: not sure if you can easily grab bits from f39
<gfxstrand>
Is it in f39 or rawhide?
<gfxstrand>
I'm going to try pulling from rawhide
<airlied>
or use an f39 vm
<airlied>
pretty sure f39 has it
flom84 has quit []
JTL1 has quit []
vliaskov has joined #dri-devel
vliaskov_ has quit [Read error: No route to host]
JTL has joined #dri-devel
<gfxstrand>
airlied: Nah, highest I can get from either is an llvm16 package.
<gfxstrand>
Looks like there's a copr
Aura has quit [Ping timeout: 480 seconds]
<airlied>
llvm in f39 should be 17
<airlied>
llvm16 is the compat package
jeeeun8413519 has quit []
<gfxstrand>
Oh...
<gfxstrand>
Why do they not just all have versions?!? *sigh*
<gfxstrand>
Okay, let's install from f39 and hope it doesn't break
jeeeun8413519 has joined #dri-devel
<gfxstrand>
Yikes! It wants to update glibc... That's not gonna be good.
<gfxstrand>
Maybe I should just update to f39 beta today?
<daniels>
it mostly works these days
<gfxstrand>
Yeah, I'm usually not too worried about Fedora betas
<gfxstrand>
I'm slightly more worried about installing a glibc from fedora N+1 without doing an actual upgrade. (-:
rasterman has quit [Quit: Gettin' stinky!]
vliaskov_ has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
<airlied>
gfxstrand: I did the glibc update yesterday on my f38 and it seems fine
<airlied>
and I did it just for vulkan-loader :-P
vliaskov has quit [Ping timeout: 480 seconds]
dogukan has quit [Remote host closed the connection]
<Company>
can confirm that F39 works fine
<Company>
I updated a week or 2 ago and haven't had any issues
<gfxstrand>
DemiMarie: The word "kernel" gets overloaded and I didn't know if he they were talking about kernel kernel or a GPU kernel. (-:
<gfxstrand>
Why, CL, why?!? *sigh*
<karolherbst>
yo
<karolherbst>
whatever the problem is, I agree
<gfxstrand>
crab_fire.jpg
<alyssa>
if both NAK and CL extravaganza land this week
<alyssa>
that will be deserving of crab_fire.jpg
<karolherbst>
mesa v2
<gfxstrand>
lol
<DemiMarie>
gfxstrand: from my PoV, a NULL pointer dereference in a GPU kernel is no big deal, while a Linux kernel NULL pointer dereference could indicate something more serious (like exploitable kernel memory corruption that happened to first cause a NULL pointer dereference).
<DemiMarie>
So my assumption was that this was the more serious kind.
* DemiMarie
wonders if Mesa should have LLVM as a git submodule
<karolherbst>
no
<jenatali>
No
<karolherbst>
worst case we just fail to compile with llvm-17 and newer and make everybody elses life miserable
<alyssa>
i should maybe do my day job.
<Sachiel>
nah
<Sachiel>
it's almost friday, not worth starting now
<alyssa>
very true
<karolherbst>
I had the last two days of and worked on zink on nvidia stuff, maybe I just stop working this week :D
<jenatali>
Since when is Wednesday "almost Friday"?
<alyssa>
jenatali: since 12:01pm
<jenatali>
:P
<alyssa>
unless you take fridays off
<alyssa>
then Tuesday night
<gfxstrand>
It is after noon. Therefore, it rounds up to friday.
<alyssa>
yes
<gfxstrand>
Otherwise, it would have been still mostly monday
<alyssa>
yep
ced117 has quit [Ping timeout: 480 seconds]
harrryhan has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<gfxstrand>
I knew making paths handle casts was going to bite us...
<jenatali>
Hm?
<gfxstrand>
Oh, looking at these LLVM fails and we're failing because of the way that nir_deref_path just silently ignores trivial casts.
<jenatali>
:(
<airlied>
gfxstrand: so we should push my fix and ignore the biting for longer :-P
<gfxstrand>
airlied: Annoyingly, I may be coming to that conclusion. :P
<alyssa>
chomp
<gfxstrand>
airlied: Well, not quite. Need to make one tweak to your patch.
<karolherbst>
maybe I should test with llvm-17.. :D
<karolherbst>
but I also wanted to look into the native spirv backend stuff...
<alyssa>
chomp
<jenatali>
gfxstrand: I'm looking at VK_LUNARG_direct_driver_loading, and its implications on vk_icdGetInstanceProcAddr, which starts to allow getting the vk_icd* functions instead of exports from the .so/.dll with loader interface v7. Given that there's like 3 entrypoints, I think it's not worth trying to do a codegen solution to share among the drivers. Thoughts?
ced117 has joined #dri-devel
crabbedhaloablut has quit []
<jenatali>
Since they're not in the VK .xml API definitions...
<gfxstrand>
jenatali: Hrm...
<gfxstrand>
jenatali: I think at the very least we need to be able to return *something* from *GetInstanceProcAddr
<jenatali>
Right now, each driver implements their own vk_icdGetInstanceProcAddr as a wrapper around the common version
<jenatali>
For loader iface v7, that is now allowed/suggested to start returning success for ICD entrypoints in addition to API instance entrypoints
<jenatali>
But those entrypoints aren't in the XML since they're not part of the API, just part of the ICD/loader interface
<jenatali>
So, my question is should I write a little bit of code in dzn to support iface v7, or should I try to do something fancy so we can get a one-liner (or few-liner) in any driver that wants iface v7
heat has quit [Read error: Connection reset by peer]
<gfxstrand>
So I think the only fancy thing we would need to do is to add 2-3 special cases to the common get_instance_proc_addr impl.
<gfxstrand>
IDK that we need codegen for it
<gfxstrand>
We can just have a couple strcmp or something
<jenatali>
Except each driver has their own implemention of the ICD entrypoints too
<jenatali>
Manually written out instead of codegen'd
<gfxstrand>
Those *should* just be one-line wrappers to make sure they get exposed as symbols.
heat has joined #dri-devel
<gfxstrand>
If they're doing anything functional in there, that's sketchy
<jenatali>
Well, the version negotiation one is a one-liner impl instead of wrapper, but yeah
<gfxstrand>
Hrm... I see what you mean, I think.
<gfxstrand>
Well, maybe not?
<jenatali>
And enumerating devices, the helper is optional
<gfxstrand>
Right, the version negotiation one is the one that I wonder about
ced117 has quit [Ping timeout: 480 seconds]
<gfxstrand>
Though, honestly, does anyone have a good reason to do their own thing there?
<gfxstrand>
I kinda think no
<jenatali>
Yeah probably not
mvlad has quit [Remote host closed the connection]
<gfxstrand>
Ugh... This is all very annoying
<jenatali>
Yeah. The nice thing is that it means I don't need to add vk_icdEnumerateAdapterPhysicalDevices to lavapipe's .def file
<gfxstrand>
So the one thing that does need to be unique per-driver is driver_GetInstanceProcAddr() because that has to point at the instance entrypoint table.
<jenatali>
Right
<gfxstrand>
And maybe vk_icdGetInstanceProcAddr() because it needs to call that
<gfxstrand>
But that's just a one-liner
<gfxstrand>
We can special-case "vk_icdGetInstanceProcAddr()" inside of instance_proc_addr to point to the driver one. That's easy enough.
<gfxstrand>
jenatali: So I think the answer to your broad quesiton of "should we fix this" is yes. The details are a mess but, yes, we should fix it.
<jenatali>
Cool
<jenatali>
Looks like pvr and nvk still report ICD iface v4, the rest of the tree is v5
<jenatali>
That should really just be de-duped
<gfxstrand>
Yup
ced117 has joined #dri-devel
<jenatali>
Ok, so I'll de-dupe that and vk_icdGetPhysicalDeviceProcAddr, neither of those should be unique
<gfxstrand>
yup
mbrost has joined #dri-devel
<gfxstrand>
NVK doesn't have a good reason. Just that I didn't want to think about v5 yet.
<gfxstrand>
I guarantee PVR doesn't have a good reason. :-P
<jenatali>
Great. I definitely started that discussion without thinking it all the way through (still in the process of ramping back up after 12 weeks not thinking about code)
<jenatali>
And then I'll figure out what to do with vk_icdEnumerateAdapterPhysicalDevices, which is the whole reason I care right now
<gfxstrand>
Yeah, that one's annoying.
<gfxstrand>
Silly windows...
<jenatali>
Yeah. But hey, with v7 at least it doesn't need to be exported from the DLL anymore, which means I don't need to have different .def files for lvp and dzn
<gfxstrand>
airlied: Want to look at the LLVM 17 MR. I just beefed the patch up a bit.
<gfxstrand>
Oh, and let me add a fixes tag
<jenatali>
I still need to do something to prevent lvp from exposing that function though but at least I can do it in code instead of at build time
ced117 has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<gfxstrand>
airlied: I mostly just made it not throw away alignment informaiton. No idea if that will ever matter for anything (probably not) but wanted to be sure.
<airlied>
gfxstrand: looks good to me
<jenatali>
Ugh. Venus
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Aura has joined #dri-devel
<gfxstrand>
alyssa: CLC stuff looks pretty good. I left some comments but they're all cosmetic.
<gfxstrand>
Delightfully cursed is how I think I'd describe that MR. :joy:
ced117 has joined #dri-devel
<jenatali>
Good description
djbw has quit [Read error: Connection reset by peer]
<gfxstrand>
I just want it for all of NIR. :D
mbrost has quit [Ping timeout: 480 seconds]
<gfxstrand>
Okay, now back to seeing if I can get NAK to build 32-bit
mbrost has joined #dri-devel
<gfxstrand>
Ooh, nice! I can drop my DivCeil impl from NAK and use the thing in Rust 1.73
<gfxstrand>
Looks like NAK is going to require 1.73
Mangix has joined #dri-devel
<alyssa>
gfxstrand: thanks!
<alyssa>
gfxstrand: thanks!
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<karolherbst>
gfxstrand: ohhh.. that stuff lands in 1.73? cool
<gfxstrand>
Yeah, and it's badly needed.
<alyssa>
gfxstrand: Addressed the cosmetic things, want to give one last look or shall I assign to karol?
<alyssa>
("Don't you mean Marge?" "o:)")
<alyssa>
:P
<alyssa>
karolherbst: ;P
<karolherbst>
do it
<karolherbst>
I can bounce it back if you want
luben has joined #dri-devel
<alyssa>
>:)
<gfxstrand>
alyssa: There we go. Gave you an RB
<alyssa>
blahaj_grinning.jpg
<alyssa>
+ /* TODO: Can we recover parameter names? */
<alyssa>
do either of you know?
<gfxstrand>
Can we? Yeah, probably. Is it worth the effort? Probably not.
<alyssa>
mood
Haaninjo has quit [Quit: Ex-Chat]
<gfxstrand>
And if we do then we have to deal with the case where some jerk writes my_helper(arg0, arg2, arg1) just to mess with us
<alyssa>
The use case is if you use an IDE (or youcompleteme or whatever) and it'll pop up the function signature, even if the func is defined in autogenerated .h
<alyssa>
(currently I need to open the original .cl to get the names when calling from .c)
<karolherbst>
alyssa: declare those functions in a header file or something, on the GPU side they evaluate to the function call, on the CPU side they just wrap around the nir_build_call thing
<karolherbst>
but yeah...
<karolherbst>
more work or something
Mangix has joined #dri-devel
<alyssa>
karolherbst: not needing to type .h manually is a feature heh
<gfxstrand>
I'm tempted to use it NVK just for query copies
<gfxstrand>
dcbaker: It appears that the rust_args from my cross file aren't making their way through.
<alyssa>
gfxstrand: >:)
<karolherbst>
so we replace all of nir_builder now or what :P
<gfxstrand>
Maybe not all
<gfxstrand>
One of the as-yet unsolved problems is calling NIR intrinsics but I've got a half a plan for that.
<jenatali>
I'll say that making clc a core requirement of nir will make the barrier to entry on Windows incredibly high
<gfxstrand>
Oh?
<gfxstrand>
I mean, yeah, LLVM sucks.
<karolherbst>
gfxstrand: I actually wonder how painful that would be... but in the end we can just have some internal header with all the intrinsics and resolve it inside vtn
<jenatali>
Windows doesn't have distros that produce libraries you can link against. You have to compile it yourself
<gfxstrand>
We have a wrap...
<alyssa>
jenatali: ...what about clon12
<jenatali>
Do we?
<jenatali>
alyssa: Yes, the barrier to setting up a build for that is enormous
<gfxstrand>
Oh, I thought we did.
<alyssa>
jenatali: Oof.
<gfxstrand>
I guess not
<karolherbst>
llvm build system moment right there
<jenatali>
Obviously it's not my call at the end of the day, just wanted to say it'd be painful for me
<gfxstrand>
Yeah, I think it would be painful in any non-Linux, TBH.
<gfxstrand>
And I'm a little worried about stuff like the LLVM17 issue we just had
<karolherbst>
just download llvm.dll
<Sachiel>
what's this about?
<karolherbst>
yeah...
<gfxstrand>
It would be one thing if we were baking in SPIR-V and could just invoke a recent enough verion of clang.
<karolherbst>
LLVM is a pain
<karolherbst>
but look
<karolherbst>
we already know the answer
rppt has joined #dri-devel
<gfxstrand>
A lot of the SPIR-V bloat is because we have to -O0 it but with recent LLVM we *should* be able to build to SPIR-V with -O3
<karolherbst>
the question is
<karolherbst>
who is gonna write that code
<jenatali>
Yeah if the process for producing the SPIR-V was to invoke prebuilt tools via the build system, I'm all for that. But right now it requires linking custom code against LLVM libs, and that's really bad on Windows
<jenatali>
You can download clang.exe, but there's no clang.lib
<karolherbst>
pain
<karolherbst>
guess we have to write a CL C parser for mesa then...
<alyssa>
jenatali: I think the real sol'n will be to switch to llvm's spirv backend
<gfxstrand>
I think the first step here is to play with the new SPIR-V back-end in LLVM
<gfxstrand>
jinkx!
<gfxstrand>
jinx
<karolherbst>
but yeah..
<karolherbst>
that already helps a lot
<alyssa>
and then be able to do clang.exe at buildtime instead of linking.
<jenatali>
Yeah, removing that translator dep will definitely help
mbrost has quit [Ping timeout: 480 seconds]
<i509vcb>
I thought all the rage these days was rust -> spriv with llvm
<alyssa>
crab_angel.jpg
<gfxstrand>
But yeah, if we can just invoke clang with -march=spirv64, that'll help a lot
<i509vcb>
NAK does make that agxv in rust idea quite tempting assuming it doesn't result in hell...
Duke`` has quit [Ping timeout: 480 seconds]
harrryhan has quit [Quit: Leaving]
harrryhan has joined #dri-devel
<karolherbst>
who does want to look into native spirv backend stuff though? Or should I just plan that for myself for like... next week or something
<alyssa>
thx for volunteering
<alyssa>
;)
<karolherbst>
yeah, np
<karolherbst>
I think I already kinda said I'd do it
<jenatali>
karolherbst: I'm interested, but won't have time for a little while
<karolherbst>
the curse of our times
heat_ has joined #dri-devel
<karolherbst>
*time
<karolherbst>
but I also want to get rusticl conformant on vulkan sooo....
heat has quit [Read error: Connection reset by peer]
<airlied>
I'd just stick to rusticl conformance, the spirv backend is likely going to be a bit of a timesink
<karolherbst>
yeah, same
<karolherbst>
but also nvidia is bothering me
<gfxstrand>
IDK... The translator bugs are also a timesink
<airlied>
you think the backend is going to be better? :-)
<karolherbst>
and not sure if I get away with anv + radv as the impls :D
<karolherbst>
if I look at the bugs intels SyCL impls has....
<airlied>
karolherbst: I'd back anv and radv as separate implementations :-P but I could see why khronos might not
<karolherbst>
then uhhh
<karolherbst>
it's worse
frankbinns has quit [Remote host closed the connection]
<karolherbst>
airlied: yeah... same
<karolherbst>
hence I've asked
<karolherbst>
but I have a complete run on radv, so there is that
<gfxstrand>
Long-term the back-end will definitely be better.
frankbinns has joined #dri-devel
<gfxstrand>
IDK if it's better right now.
<karolherbst>
yeah..
<karolherbst>
we might want to wait until llvm-18 anyway
<airlied>
getting nvidia bugs fixed will be probably a bit of a blocker though
<karolherbst>
yeah.....
<gfxstrand>
According to various folks, it's passing CTS on top of the Intel proprietary driver.
<karolherbst>
I mean...
<karolherbst>
yes
<karolherbst>
but they also eat invalid spir-v
<karolherbst>
I've filed a lot of bugs
<karolherbst>
and the SyCL spir-vs they generate trip over vtn a lot, because it's invalid
<karolherbst>
like..
<jenatali>
Yeah I've seen that too
<karolherbst>
builtins in CrossWorkgroup ...
<karolherbst>
and other random nonsense
<gfxstrand>
Ugh... I'm running into meson --edition bugs, I think.
<jenatali>
+128 −733, nice
<karolherbst>
anyway.. I'll probably look into it if nobody else does
<karolherbst>
I think it's easy to flip over
<karolherbst>
and the CTS will tell me what burns
<karolherbst>
could have it as an env var for testing for now
<gfxstrand>
Yeah, I think that's the first step
<gfxstrand>
Have an ENV var or some other easy switch and then folks can help figure out the bugs
<karolherbst>
yep
<karolherbst>
the issue is.. some clang versions invoke the llvm-spirv binary instead
<gfxstrand>
I did nicely tell the people working on it that if it doesn't pass SPIR-V validation, I don't really care that the Intel driver is happy.
<karolherbst>
so I also have to figure that part out
<karolherbst>
gfxstrand: yeah...
<karolherbst>
I mean
<karolherbst>
in rusticl I don't verify internal spir-vs because....
<karolherbst>
_but_
<karolherbst>
my runs with offline compiled spir-vs have like 2 fails more
<karolherbst>
and I do validate all external spir-v
<karolherbst>
and I know for a reason that intels' CL impl doesn't
<karolherbst>
not sure how many of those are upstream llvm bugs
jeeeun8413519 has quit []
<jenatali>
gfxstrand: Are you still the person to ask for Vulkan runtime reviews?
<jenatali>
If so, !25998 pretty please :)
Guest5454 has quit [Read error: Connection reset by peer]
peelz has joined #dri-devel
peelz is now known as Guest5483
<gfxstrand>
dcbaker: I have a theory as to why it's not working. Meson isn't passing rust_std through from parent project to subproject.
<gfxstrand>
Which is fine right up until you do a cross build at which point something somewhere along the line zeros out rust_std
Guest5483 has quit [Read error: Connection reset by peer]
notpeelz has joined #dri-devel
<gfxstrand>
dcbaker: Hrm... I think the real problem is that --edition really shouldn't be per-machine
notpeelz has quit [Read error: Connection reset by peer]
notpeelz has joined #dri-devel
<gfxstrand>
dcbaker: Yeah, that's the problem.
<gfxstrand>
Well, rust_std is generally handled wrong
<gfxstrand>
rust_std should be per-crate and generally not per-machine
<gfxstrand>
dcbaker: I can hack around it sort-of with --native-file except that I want 2021 for NAK and proc-macro2 wants 2018 and breaks with 2021
sima has quit [Ping timeout: 480 seconds]
peelz- has joined #dri-devel
notpeelz has quit [Ping timeout: 480 seconds]
<dcbaker>
gfxstrand: sigh. Yeah, we have always basically assumed that things would be backwards compatible or that you would never cross a breaking boundary (ie, c++98 vs c++11). I think you can work around this issue by adding `override_options : ["rust_std=2018"]` to the library call that creates the proc-macro itself
<gfxstrand>
dcbaker: The problem is that rust_std and c++_std are not at all the same thing
<gfxstrand>
Rust editions are DESIGNED to allow linking across editions.
<gfxstrand>
C++ editions much less so
<dcbaker>
Really C++ is kinda special in that it doesn't necessarily allow linking across standards. C and Fortran do
<gfxstrand>
But, yeah, if meson is trying to handle rust_std like it's handling c++_std, then one or both are going to be broken.
<dcbaker>
But C++ is like rust in that things probably don't compile with the wrong version
<dcbaker>
it's really that it's treating everything like C, where everything is always 100% forward compatibile
<dcbaker>
s/it's/meson
<gfxstrand>
So it's all wrong! :joy:
<dcbaker>
and it's a known issue that I've been arguing we should fix for a long time :/
<dcbaker>
I think Xavier has done some work to try to make that happen
<gfxstrand>
Is there a chat where I can get both you and Xavier?
<gfxstrand>
Should I just join #meson?
<gfxstrand>
Please don't say the answer is Matrix
<dcbaker>
We have a bridged channel between matrix and oftc
<mattst88>
#mesonbuild :)
<dcbaker>
I can't remember if it's #meson or #mesonbuild:matrix.org
<dcbaker>
but yes, Xavier and I are both there, and so are a couple of other people interested in Meson + Rust
<gfxstrand>
Okay, I'll bother both of you there more tomorrow
<gfxstrand>
I have enough hacks piled up to know where the bugs are at this point.
<dcbaker>
sounds good
<gfxstrand>
dcbaker: The other bug I'm hitting is that meson is trying to link in my proc macro because it's a dependency.
<gfxstrand>
But that blows up because it's x86_64 and the lib I'm building is x86_64
<gfxstrand>
*lib I'm building is i686
<dcbaker>
That is a known issue. I can't remember if anyone volunteered to look at it.
<dcbaker>
along with about a million other corners of dependency
<dcbaker>
If no one else is I can look at taht
<gfxstrand>
dcbaker: The question I'm asking myself is what should I wait to be fixed before I land NAK.
<gfxstrand>
I'm tempted to just land it and say "Sorry, cross builds broken with NVK. It'll get fixed one day."
<gfxstrand>
I really don't like that but we're getting to the point where NAK being in a branch is getting painful.
<dcbaker>
Xavier and I have been talking about pushing for a short 1.4 cycle that focuses on getting a lot of Rust stuff squared away. Having NAK landed but not supported for cross building might be helpful in lighting that fire ;)
<dcbaker>
for Meson that is
<gfxstrand>
So does that mean you'll ACK the MR and I can burn it all down?
harrryhan has quit [Quit: Leaving]
<dcbaker>
sure, ack :)
<dcbaker>
I did have a couple of patches on your last version... let me see if those are still relavent
<gfxstrand>
Sure
<gfxstrand>
Also feel free to tell me to re-order stuff for less breakage
<gfxstrand>
Some of it might be a bit painful but I'm happy to try
pcercuei has quit [Quit: dodo]
<dcbaker>
I personally hate re-ordering of big giant piles of newness, and grumble when others ask me to do that, so I will not
<gfxstrand>
dcbaker: I'm going to look at a couple more things tomorrow and then we'll merge it, I think.
<gfxstrand>
dcbaker: Well, the thing that really sucks is that meson doesn't take kindly to updating wraps
<gfxstrand>
And I do that mid-branch, I think.
<gfxstrand>
I'll try to rebase that out tomorrow
<dcbaker>
I think you can do `import('rust')` without the `unstable-` bit since you have >= 1.3 required; I think for the same reason you can do `rust_abi : 'c'` instead of `rust_crate_type`
<dcbaker>
I think otherwise everything looks fine to me, and I'm of the "start having good commit hygiene after we merge giant features" camp
<gfxstrand>
Yeah, I just don't want to cause massive bisect pain
<gfxstrand>
Then again, no one who isn't building NVK will ever see that so maybe meh?
<gfxstrand>
Yeah, looks like I already dealt with that.
<gfxstrand>
Oh, great... the python wheel package doesn't build on f39
<daniels>
gfxstrand: I had that earlier but it resolved itself with an update - if the python dep is version-locked, try updating
<gfxstrand>
daniels: I'm using the shell script in mesa. Do we need to bump the versions in there?
<daniels>
gfxstrand: if you mean ci_run_n_monitor.sh, iirc you need to nuke .gitlab-ci/bin/venv/
<gfxstrand>
I don't have a .gitlab-ci/bin/venv
<daniels>
fun. tree up to date?
<gfxstrand>
yeah
<gfxstrand>
Oh, .venv
<daniels>
yeah, sorry
<gfxstrand>
Looks like ruamel.yaml.clib has an update which fixes it but aiohttp doesn't
<gfxstrand>
This should at least alleviate a few surprises for Fedora users. :)
<gfxstrand>
Or anyone else who gets a surprise Python 3.12 update
<DavidHeidelberg>
gfxstrand: thank you for that, if you want to merge it, go ahead :)
<gfxstrand>
Already assigned
<DavidHeidelberg>
perfecto! muy bien!
<gfxstrand>
Ugh... Merging NAK is going to mean updating meson in the build containers....
<airlied>
life choices :-P
<gfxstrand>
I think this is a problem for tomorrow's me.
<airlied>
does it just matter if nvk/nak is enabled?
<airlied>
or will everyone suddenly need meson 1.3
<gfxstrand>
Oh, you're getting NAK the moment you ask for NVK
<gfxstrand>
But only NVK people will
<gfxstrand>
But CI builds everything so....
<bnieuwenhuizen>
just don't build NVK in CI
<airlied>
ah cool should scare distros away from packaging it ifor a while :-P
<daniels>
gfxstrand: happy to talk you through it tomorrow then
<gfxstrand>
I kinda half-remember
<gfxstrand>
Trying to find meson versions now
iive has quit [Quit: They came for me...]
<daniels>
atm it's installed from debian stable, so you'd have to remove those from the debian package lists in .gitlab-ci/container/*.sh and add the pip call like in the fedora one
<gfxstrand>
We're already doing that
<daniels>
righto
<daniels>
in that case, just adjust the relevant versions and bump the image tags in .gitlab-ci/image-tags.yaml
<gfxstrand>
The real question is whether or not pip will be happy with the meson version I requested
<airlied>
I do wonder how to get the rust deps without wraps, I've installed a bunch of packagse but they don't seem to be picked up
<gfxstrand>
Xavier has meson PRs for that
<gfxstrand>
They even mostly work if you pull all the right branches together
<airlied>
ah meson needs more work, okay I'll suck up wraps for now