03:59 <evx256> hello again! hopefully haven't outworn my welcome :) so in testing various gles3.0 and prior to that vulkan apps, I realized that I can no longer run gles3.0 apps that previously ran without issue. I thought this might have been a regression since, the mesa taht shipped on the factory image of pinephonepro, mesa 21.3.4-1, so I checked out this branch, built it, and it appears to segfault in same place as:

03:59 <evx256> https://gitlab.freedesktop.org/mesa/mesa/-/issues/6032

04:01 <evx256> however, and more worrisome, i tried to re-run these apps on that factory image (i just remove the sd card with a different manjaro with the newer mesa), and they too no longer work and segfault in the gallium driver. so now, and you'll have to forgive my ignorance on these matters, i'm wondering is it possible there's some global state in the gpu that got messed up when testing the newer mesa, that is now persisting across reb

04:01 <evx256> booted os's?

04:03 <evx256> like i have screenshots of these apps running, i double checked the mesa on the factory image when i boot is equal to the mesa in the factory image on the downloads page, but now they all segfault and cannot present; so... i'm running out of explanations how this could be possible, other than some persistent state in the gpu hardware somehow? that doesn't seem possible to me, but i also couldn't say one way or the other :)

04:13 <HdkR> Stuff could have changed around the app and mesa. Especially with AFBC scanout shenanigans

04:14 <evx256> could you elaborate a bit on what you mean? :)

04:17 <evx256> so just to be clear, i built (and ran) the shadow and cube and triangle examples from here: https://github.com/gfx-rs/wgpu/ successfully when running against gles3.0; i have screenshots of them running. so then i installed an os on an sdcard, booted that, played with it for a while, attempted to try out vulkan, then bla bla, more stuff, then noticed the apps no longer run, so i removed sd card, as i said, re-ran them, and no lo

04:17 <evx256> run. i can't understand how this would be possible unless i updated either the app or the system (neither is true, afaik), _or_ there's some kind of state inside the gpu hardware that is persisting across boots and os's, which as i said, i don't know enough whether that could be true.

04:18 <HdkR> Did the kernel change on you? You're interacting with DRM here which is seemingly providing an AFBC framebuffer to scan out to. Previously you might not have hit that.

04:19 <HdkR> Or it is mixing AFBC and tiled, hard to know for sure

04:19 <evx256> that is a good question; afaik, when the apps ran, i had done `pacman -Syyu` _before_ i ran them, played with them a bit; got bored, and installed another os on another sd card and hadn't touched this (it's on emmc built into the pinephone). it is possible i did `pacman -Syyu` _after_ i ran them, i'm not sure of good way to know this.

04:21 <HdkR> You may have also been playing with `PAN_MESA_DEBUG=linear`

04:22 <evx256> i definitely didn't pass that flag; are you saying that this could cause some persistable effect to the t860 gpu that is observable through reboots and os's though?

04:22 <HdkR> nope

04:22 <HdkR> But it would make the assert go away

04:22 <evx256> the assert in the issue you mean?

04:30 <HdkR> yea

04:33 <evx256> good to know! do note that i did compile the asserts out when simply compiling in release, (which is what the shipped gallium driver is built with), and it segfaults, but maybe that environment variable alters some control logic? i will try it out :)

04:35 <HdkR> Yes, that environment variable does control some logic around this

04:38 <evx256> yea still getting segfaults; i was told in the wgpu channel it is probably related to the surface i'm asking for (Bgra8UnormSrgb)

04:38 <HdkR> Very likely

04:40 <evx256> it's still kind of troubling to me all this worked before... like suddenly the gallium driver for t860 and mali has issues with srgb surface, but before, what sounds like it must have been a kernel update i forgot about, now it has major problems with it? something is fishy...

04:40 <HdkR> kernel update or WM/DE could cause it

04:43 <HdkR> Depending on what is asking for that particular scan out buffer format :)

04:46 <evx256> ok easy enough to test this theory then, i can just change the surface request

04:50 <evx256> also what does that environment variable you suggested do exactly?

04:51 <HdkR> Forces some tiled resources to be linear

05:21 <evx256> ok running with a non-gamma correct surface also segfaults

05:23 <HdkR> well it looks like the fault is in a different location than the assert

05:31 <evx256> so i guess the part i'm finding confusing a bit here is it isn't clear to me how/why a kernel update would segfault the mesa code where it does; are the pointers it's trying to delete in the linkedlist volatile resources? (i.e., being deleted by the kernel/whatever underneath it)

05:41 <HdkR> Also have to understand that I'm making wild guesses to try and help :)

05:48 <evx256> i dig it, and appreciate it :)

08:11 <Didgy> Testing from IRC

11:08 <robmur01> hmm, looks like my LXDM might be dying on "assert(ctx->blend_src1 < ctx->temp_count);" in RA

11:09 <robmur01> I think I shall not be attempting to debug that :)

13:19 <alyssa> robmur01: mumble.

13:19 <robmur01> "Register allocation? On an unsupported GPU? At this time of year? Entirely localised to my living room?"

13:43 <alyssa> ah yes the time of year

13:44 <alyssa> it's TOO COLD to write compilers that's my excuse

13:56 <HdkR> Just need to build compilers more frequently then

13:56 <HdkR> Warm you up quite fast

13:57 <macc24> 4 watts of arm heating power

14:00 <alyssa> hmm

22:10 <alyssa> Yikes I have too many open MRs to deal with

22:11 <alyssa> I should strongly consider not opening more ;V

22:14 <steev> open more, let future you deal with it

22:18 <anarsoul> future you won't appreciate that

22:18 <anarsoul> :)

22:18 <alyssa> future me and I are not on the best terms

22:20 <macc24> get a time machine and send the patches to review for past you :)

22:22 <steev> that's a future you problem

22:25 <anarsoul> darn you, past me!

22:26 <alyssa> thanks for volunteering for patch review duty

22:28 <steev> i mean... i can look at them, and say... yep, looks like code

22:29 <anarsoul> looks like code, works like code, let's treat it like code!

22:29 <steev> merged in my tree without conflict. lgtm+1

22:46 <alyssa> 2 files changed, 46 insertions(+), 3 deletions(-)

22:46 <alyssa> i'm not really doing well at this "fewer patches" thing

22:58 <jekstrand> alyssa: Or you can be like me and just replace all the code with different code

22:58 <jekstrand> - 2849

22:58 <jekstrand> MR

23:00 <alyssa> jekstrand: oof

23:00 <alyssa> jekstrand: My new "jekstrand job theory" is that you left Intel as soon as you finished the raytracing patches so you wouldn't have to upstream them

23:00 <alyssa> :-p

23:00 <jekstrand> alyssa: I should have. Instead, I made the mistake of hanging around for another year to try and save i915.

23:01 <alyssa> what happened to i915

23:03 <jekstrand> Oh, it's generally a disaster and the whole team doesn't know how to do open-source anymore.

23:03 <anarsoul> :(

23:03 <jekstrand> Not "whole team". There's a few that still do and still care.

23:04 <jekstrand> But, yeah...

23:04 <jekstrand> And the code-base is an over-grown misarchitected pile

23:04 <anarsoul> I kind of hoped to get discrete Intel GPU one day...

23:04 <anarsoul> with decent open-source driver

23:06 <jekstrand> I think we'll get there. There's still some good people there.

23:06 <HdkR> Guess we'll just need Mali dGPU :>

23:06 <anarsoul> HdkR: no, thanks

23:09 <jekstrand> But, yeah, I don't like kernel development (too much rebooting and no GDB) and was pretty burned out.

23:10 <alyssa> HdkR: Okay but have you considered Vivante dGPU

23:10 <anarsoul> jekstrand: can't you just pass GPU to a VM?

23:10 <jekstrand> :P

23:10 <anarsoul> alyssa: what about adreno? :P

23:10 <jekstrand> alyssa: Are you trying to give me indigestion.

23:10 <jekstrand> ?

23:11 <HdkR> alyssa: that would be the most sad dGPU, like an MX150

23:11 <anarsoul> oh wait, we already have radeon :)

23:11 <alyssa> if we only we had a freadeon driver for it...

23:11 <anarsoul> I wonder if modern AMD GPUs have anything in common with adreno :)

23:12 <jekstrand> And then there's discrete PowerVR

23:12 <jekstrand> https://wccftech.com/chinese-gpu-maker-innosilicon-unveils-fantasy-one-chip-for-discrete-graphics-cards-up-to-32-gb-gddr6x-memory-dual-gpu-solutions-5-tflops/

23:14 <alyssa> is it normal to spend every day for years thinking about how much you want to do a thing X and then still not do it

23:14 <HdkR> I wish I could write this code correctly

23:39 <HdkR> From what I can tell, it's now years later and it still isn't correct

23:39 <HdkR> darned