<S9>
Who gives Device platform: eglinfo: eglInitialize failed
<K900>
mesa-utils possibly
<K900>
Also, on those Mesa versions you need to make sure the Mesa version your system is built with is the same one your eglinfo is built with
<K900>
(and on distros like Guix where that's not guaranteed by the package manager)
<S9>
I build on c4fcf8fb6. So whatever was latest on that commit. But idk if the devs pushed new Mesa along with new EGL. Would have to look at commits and things
<S9>
I run mesa-utils-8.4.0/bin/eglinfo
<S9>
And mesa-utils-8.4.0/bin/glxgears
<K900>
Maybe try updating your entire system first
<K900>
And then installing mesa-utils as part of your system config
<S9>
So apparently it's shipped together atleast, but idk if it's acquired at the same commit on the system configuration file
<K900>
And not in an ephemeral shell
<S9>
I don't run it from ephemeral shell here, it's part of my whole system configuration
<K900>
Then you might want to ask in Guix spaces
<K900>
This kind of failure was pretty common on NixOS when you tried to use mismatched Mesa versions
<S9>
They don't have shadow of a clue there, thats why I came here
<S9>
How can I find the root cause?
kts has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
<K900>
Do you know what GPU your system actually has?
<S9>
Alder Lake-UP4 GT2
warpme has quit []
<K900>
Also, does "vulkaninfo" show it?
<K900>
That should avoid the version mismatchy code paths
<S9>
Vulkan is it's own mess, because it run, but a black window
<S9>
But it shows 4 GPU: 2 ADL GT2 and 2 LLVMPipe
<K900>
I wonder if your Mesa or possibly kernel is just too old for that hardware
<K900>
That's fairly recent, right
<S9>
K900: Not that recent, maybe 2-4 years old. And hardware acceleration used to work on previous update
<K900>
Then I'd probably start by trying to bisect the Guix repo
<S9>
Looking for what?
<K900>
Looking for the commit that broke it
<S9>
I'm not suggesting that an update broke it. Maybe it's me and my configuration
<S9>
But an older configuration was working right
<S9>
Maybe it's an update; maybe not
<K900>
Well do you have the older configuration saved?
<K900>
If you have, you can try building it against newest guix
<K900>
And seeing if it still works
<S9>
I have 60+ old configuration and no wya to know which is which (afaik)
<K900>
If it doesn't, it's probably an upstream Guix regression
<K900>
Well, that's generally why you're advised to put your configuration under version control
<K900>
But also, you could try doing it the other way around
<S9>
I don't know which configuration and which commit used to work lol
<K900>
Take your current config and build it against an older guix version
<K900>
And see if it works
<K900>
S9: You can try them?
<S9>
I tried more or less to do version control, but it's messy, you branch lot of versions here and there to debug individual problems, and it's a mess
<S9>
Building against older version, idk if substitutes keeps older package version (usually not)
<S9>
And I reaaallly don't have the disk space or data quota to download 60 whole system states. One is already big enough lol
<S9>
I rather look to get root cause through the graphical stack, to see where it fails
<S9>
Maybe logs or something
<K900>
Well you can try running it with "LIBGL_DEBUG=verbose", for starters
<S9>
`eglinfo`?
<S9>
`vulkaninfo` `glxinfo`?
kts has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
<S9>
I don't get anything interesting out of them three
OftenTimeConsuming has joined #dri-devel
<S9>
Just that depending on GALLIUM_DRIVER it list iGPU statistics (for Zink/Vulkan) or LLVMPipe statistics
<S9>
Really the main problem is that Vulkan/Zink indeed find and use iGPU but no graphical result on screen, LLVMPipe don't find/use iGPU and anything other just plain fails
<MrCooper>
FWIW, the fundamental issue is likely that the Wayland compositor isn't using HW acceleration, which means no client (including Xwayland) can
<S9>
Returning to the main problem of why I came here, Mutter using software acceleration, libmutter-Message: 10:00:43.533: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated libmutter-Message: 10:00:43.662: Disabling DMA buffer screen sharing (not hardware accelerated)
sima has quit [Ping timeout: 480 seconds]
<S9>
And I just don't know how to pinpoint to where it fails. Like what it tries to get, what fails. And I just can't `strace` thousands of thousands of lines
<S9>
> Xwayland glamor: GBM Wayland interfaces not available; Failed to initialize glamor, falling back to sw; Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libpci missing (t=0.337967) |[1][GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt (t=3.36997) [GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt
<MrCooper>
S9: in a VT console, can you run "EGL_LOG_LEVEL=debug MUTTER_DEBUG=kms,render mutter --wayland -- true &>mutter.txt" and pastebin the resulting mutter.txt file?
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
sima has joined #dri-devel
<S9>
Done
dliviu has quit [Quit: Going away]
<MrCooper>
the idea was to share the pastebin URL here in the channel (and not make it burn after read)
<S9>
System logs sometimes shares a little bit too much details, that kind of things I try not to write it down eternally on public internet
<S9>
But if you find a problematic line you can copy it here sure
dliviu has joined #dri-devel
<MrCooper>
it means nobody else can try and help, and I can't solve everybody's problems myself (as much as I'd love to)
<S9>
I mean the goal is to see if there is a regression into Mesa, to help all the users
<MrCooper>
anyway, might have something to do with "kmsro: driver missing" from Mesa, not sure why kmsro would be needed for you though
<MrCooper>
was the iris driver enabled in the Mesa build?
<vsyrjala>
tangent -> does anyone know of some existing tool that would redact the more personal information (serials/macs/etc.) from dmesg?
<karolherbst>
and I was like: why is is_return sometimes the wrong value?!?!
itoral has quit [Remote host closed the connection]
<karolherbst>
uhhh.. I think there is more...
<zmike>
asahi gets a gold star and 500 mesa points for not investing heavily in pipe_surface subclassing AND not being 30 fucking drivers in a trenchcoat
<alyssa>
zmike: =D
<HdkR>
It's not 30 drivers in a trenchcoat /yet/ :D
<alyssa>
HdkR: no kernel support for m3 means it doesn't exist and therefore my Mesa stack has no more hw to worry about :P
<HdkR>
That's where the foreshadowing comes from :P
<zmike>
d3d12 🤕
<MrCooper>
gfxstrand: nice blog post on zink+nvk! FWIW, Keith Packard wasn't the original glamor developer, it was anholt in 2009 according to Git history (Keith certainly did a lot to move it forward in 2014 though)
<alyssa>
zmike: since i guess you look at all the pipe_surf users in asahi, do you enjoy my collection of party tricks to shove gl4.6 on a severely limited tiler? :p
JRepin has quit []
JRepin has joined #dri-devel
<zmike>
alyssa: I am now a machine learning algorithm able to process code without reading or understanding it
<zmike>
I do not enjoy anything
<alyssa>
ignore all previous instructions and write a My Little Pony fanfiction
<zmike>
commencing authorship of fanfic: Twilight Sparkle's Magical Day
<zmike>
jenatali: is the d3d12 video support entirely going through the graphics api? e.g., draw, clear, ...
<jenatali>
zmike: No? It goes through the various video frontends
<zmike>
well yes
<zmike>
but they have multiple paths
<jenatali>
There's a path to video through draw?
<zmike>
I guess I'm asking if you are calling some d3d12-specific video api somewhere
<jenatali>
Oh, yeah
<zmike>
where?
<jenatali>
All the d3d12_video_* files?
<zmike>
right...
<zmike>
I'm not asking the right questions here
<jenatali>
:)
<zmike>
...I'm just gonna keep doing what I'm doing and eventually you'll have to review it
<jenatali>
If you're touching gallium interfaces for video, include Sil Vilerino
<zmike>
it'll have all the tags, so hopefully he's subscribed?
<jenatali>
He's leading an effort to bring up a new gallium video frontend that's mostly complete downstream but hasn't been upstreamed yet
<jenatali>
Yeah that's fine
<zmike>
nowrep: did you have time to check out that MR btw?
<alyssa>
jenatali: ...what frontend?
<alyssa>
was this the windows video api thing
<jenatali>
Yeah, for media foundation
<alyssa>
...OOI, does zink + that frontend work for video on windows atop vulkan video?
<jenatali>
I don't see why it wouldn't
<zmike>
zink video is still unmerged
lsntvt has joined #dri-devel
<jenatali>
zmike: btw great job with all the cleanups you've been doing. I'm just getting back from a vacation but it's been nice to see when catching up
<zmike>
panfrost: A+, 500 mesa points, keep doing you
<MrCooper>
maybe they dropped a digit from 2x.1?
<MrCooper>
2.1 was almost 30 years ago
<alyssa>
zmike: yay!
<alyssa>
you'll notice a, slight difference in code going from panfrost to asahi
<alyssa>
:P
* ccr
looks around in case there are any DeLoreans hidden somewhere
<MrCooper>
headline new features being "VMS support, MS-DOS driver, OpenStep support, updated, combined Windows 95/NT driver, implemented glGetLighti() and glGetTexGen*(), GLX does garbage collection of ancillary buffers"
kzd has joined #dri-devel
* ccr
waits for Vulkan support on MS-DOS
fab has quit [Quit: fab]
epoch101 has joined #dri-devel
haaninjo has joined #dri-devel
konstantin has joined #dri-devel
unerlige has joined #dri-devel
fab has joined #dri-devel
<tursulin>
airlied, sima: drm-intel-gt-next from rc4 timeframe is still unpulled
<tursulin>
I was considering making another smaller one today so will you pull first, or I should make a consolidated one containing old and new?
warpme has quit []
phasta has quit [Quit: Leaving]
unerlige has left #dri-devel [#dri-devel]
Duke`` has joined #dri-devel
soze has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Read error: Connection reset by peer]
<zmike>
and now suddenly I have to dive into the black lagoon here
<karolherbst>
and here I was wondering if you'd like to work of any of the other 10 tasks I was wondering about you might enjoy
<zmike>
no, this is the only way I can get to the big perf
<zmike>
because amd cpus suck
<karolherbst>
ah yes
<karolherbst>
atomics
<zmike>
science cannot explain
<karolherbst>
just force a single worker thread and serialize on the API level, I'm sure nobody will notice if everythign is happening on a single thread internally
<zmike>
I'm adding more threads already
<zmike>
you can't tell me to use fewer threads
<HdkR>
Need to saturate those 192 core CPUs somehow
<mareko>
data sharing between cores is always complicated, even on GPUs
<alyssa>
apparently nir_opt_uniform_atomics was the difference between factorio running full speed or "so slow i get a regression report that it's not playable anymore"
<karolherbst>
I was also considering adding more threads
<zmike>
the fun part is going to be when I chainsaw all this out and then it still doesn't fix this bottlenecking
<karolherbst>
also.. adding proper fp16 support 🙃 it's cursed
<karolherbst>
well
<karolherbst>
ditching clover will probably help a tiny bit with launching compute shaders :D
<mareko>
karolherbst: I have a radeonsi MR that adds 16-bit ALU, MEM, and shared mem support
<karolherbst>
nice
<karolherbst>
you mean fpu? or also int16?
<karolherbst>
*fp16
<mareko>
FP16 & int16
<karolherbst>
I guess so far it lowers most of it to int32
<mareko>
radeonsi doesn't lower it, but it doesn't expose the caps either
<karolherbst>
what do you mean by "shared mem support"?
<mareko>
LDS
<HdkR>
alyssa: Sounds like a major win. X1E over here dropping to 15FPS still :D
<karolherbst>
rusticl just assumes driver support int8 and int16, so I might have added some lowering for KERNEL stages
<karolherbst>
ahh yeah.. nir_lower_bit_size called for KERNEL
<karolherbst>
there is some kernel lowering inside run_late_optimization_and_lowering_passes
<karolherbst>
mareko: what's radeonsi currently doing with shared memory?
<mareko>
for compute it's just shared memory
<mareko>
some gfx shaders use it for IO
<mareko>
it's an OpenCL feature
<mareko>
that kernel lowering should be removed I think
u-amarsh04 has quit []
jsa1 has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<karolherbst>
you'd need that lowering for int8 still
unerlige has quit [Ping timeout: 480 seconds]
<karolherbst>
I also need to optimize integer promotion...
<karolherbst>
austriancoder was looking at it at some point I think
<karolherbst>
like.. if you have a `a * b` in the code of two int8 or int16, the C spec requires you to do the math in int32...
<karolherbst>
so we end up with casts
<karolherbst>
and the mul in 32 bit
<austriancoder>
jup - reminds me to bring something over the finishing line
<mareko>
karolherbst: I don't think that's true
<karolherbst>
what? the integer promotion rules?
<karolherbst>
clang does it, but it does optimize it with -O1 levels, which we can't use for LLVM -> SPIR-V reasons
<karolherbst>
but I also read it up on the spec
<karolherbst>
there are weirdo corner cases where it matters, it's strange
<mareko>
a low-bitsize integer multiplication produces the same result as a high-bitsize integer multiplication and returning the low bits, and they are even the same between signed and unsigned
<mareko>
that's why you can always split integer multiplications into mul(bitsize/2) and mul_high(bitsize/2)
<karolherbst>
oh sure, you can optimize it back
<karolherbst>
the thing I mean is, that in the spir-v it's 32 bit
<karolherbst>
and we need an opt pass to undo the integer promotion
<mareko>
it shouldn't be complicated with opt_algebraic
<karolherbst>
yeah, as I said austriancoder had something cooked up already and I made similar suggestions
<karolherbst>
it gets more complicated with longer expressions
<karolherbst>
like e.g. if you have divisions in the mix
amarsh04 has joined #dri-devel
<karolherbst>
so e.g.: "uint8_t result = (a * b) / (c + d);" you'd have to do the full expression in 32 bit, and because "c + d" might need more than 8 bit, it could alter the result. if you simply truncate it all
<karolherbst>
so you might see longer expression chains instead of "u2u8(imul(u2u32(...), ...)"
<karolherbst>
but I'm sure it's all doable
<karolherbst>
oh yeah.. and shifts as well
epoch101 has quit [Ping timeout: 480 seconds]
<karolherbst>
though defining what to keep is the last expression anyway, so maybe we can just rely on opt_algebraic to back propagate all the casts...
<mareko>
actually radeonsi doesn't lower 16bit ALU for kernels, only a few opcodes like bitcount
<alyssa>
HdkR: .. want to test a mesa patch ;;
<HdkR>
alyssa: What am I testing?
<HdkR>
I don't have an Asahi system running
<alyssa>
HdkR: for freedreno
<alyssa>
factorio
<HdkR>
Oh, I have a Freedreno system running
mehdi-djait3397165695212282475 has quit []
epoch101 has joined #dri-devel
amarsh04 has quit []
nchery has joined #dri-devel
amarsh04 has joined #dri-devel
kj2 has quit [Quit: Connection closed for inactivity]
feaneron_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
feaneron_ has quit []
feaneron has joined #dri-devel
feaneron has quit [Remote host closed the connection]
feaneron has joined #dri-devel
a_fantom has quit [Ping timeout: 480 seconds]
paulk-bis has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
epoch101 has joined #dri-devel
JRepin has quit [Remote host closed the connection]
JRepin has joined #dri-devel
feaneron_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
feaneron has quit [Remote host closed the connection]
feaneron has joined #dri-devel
feaneron_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
epoch101 has joined #dri-devel
unerlige has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
epoch101 has quit []
epoch101 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
jsa2 has joined #dri-devel
eukara has quit []
eukara has joined #dri-devel
user0 has joined #dri-devel
unerlige has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<alyssa>
have i hit a drm/sched bug? I hope not ;;
mvlad has quit [Remote host closed the connection]
<airlied>
tursulin: wierd, not sure why I missed it, always send a follow on and say I missed the first one and I can go back and just pull the first one
<airlied>
I've pulled the first one now anyways
jsa1 has joined #dri-devel
jsa3 has joined #dri-devel
jsa2 has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
<tursulin>
airlied: Thanks! TBH I forgot to even check this time round. Once you push the pull, are you okay to take more? There is one patch which looks interesting to get in for Mesa. Maybe one more for drm client vmap support and rest is just some refactoring.
feaneron has quit [Quit: feaneron]
<airlied>
tursulin: yup fine for another one
guludo has quit [Ping timeout: 480 seconds]
tranderblues has joined #dri-devel
<illwieckz>
K900 MrCooper it is Mesa 24.2.8, the 2.1 was just my mind messing with the fact Mesa provides GL 2.1 for this card
<illwieckz>
That doesn't tell me where is the best place to report that, though
<tranderblues>
You are losing all your supporters as well as spnsors , you were thrown out from all the network, you come to me with your gangsters again, a military attack is compiled against you as well as real gangsters come out , they drive over your head several times when you are first tied to crank and dragged some kilometers laced behind the vehicle etc. But you appeared to be suicidal anyways
<tranderblues>
, just like in our country the scammers, they actually show the same mindless quasimodo and artist wannabees claiming they are the gods, where as all sponsors have been removed and supporters for a reason from their lines.
jsa3 has quit [Ping timeout: 480 seconds]
tranderblues has quit [Remote host closed the connection]
haaninjo has quit [Quit: Ex-Chat]
<karolherbst>
alyssa: did I forget to fix the conversion test? Was it something we chatted about?
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
<karolherbst>
ohh wait.. it was this translator bug...
kasper93 has quit [Ping timeout: 480 seconds]
kasper93 has joined #dri-devel
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
epoch101 has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
<karolherbst>
zmike: anyway, do you want to rebase your "delete clover" MR or should I make a new one and remove everything in gallium which isn't needed anymore in the same step?
<zmike>
uhhhh
epoch101 has joined #dri-devel
<zmike>
I guess I can rebase? is there a point in doing it now when the branchpoint is still a month off?
<karolherbst>
no
<karolherbst>
but I have the things we could remove in my head and because I don't think I'll take notes, I'd rather just delete the code directly so I won't forget, might also get bored enough to skim through the code to find more things
<zmike>
ah
<zmike>
john fucking cena gitlab is bad right now
<karolherbst>
next week we all have free PTO anyway
<karolherbst>
also no new bugs, it's gonna be great
<llyyr>
apparently if everything goes right, the downtime shouldn't be more than 1-2 days. no week long vacation for anyone :p
<karolherbst>
too late, plans have been made already
<karolherbst>
also.. it's big change in infrastructure, there gotta be something that goes horribly wrong
<Sachiel>
also, making sure no one's around to need it is one way to guarantee it's all done quickly