alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
_whitelogger has joined #panfrost
vstehle has quit [Ping timeout: 244 seconds]
yann has quit [Ping timeout: 272 seconds]
megi has quit [Ping timeout: 245 seconds]
_whitelogger has joined #panfrost
vstehle has joined #panfrost
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 245 seconds]
_whitelogger has joined #panfrost
guillaume_g has joined #panfrost
wens has joined #panfrost
davidlt_ is now known as davidlt
EmilKarlson has joined #panfrost
rellla has quit [Quit: see you later]
<EmilKarlson> am I on #panfrost now?
<EmilKarlson> yes, I can see the user list
<HdkR> This is the Panfrost channel yes.
<tomeu> hi! o/
<EmilKarlson> hi
<tomeu> EmilKarlson: PAN_MESA_DEBUG=trace prints to either stdout or stderr
<tomeu> so it should be in the X log file
<EmilKarlson> thanks
<EmilKarlson> I am bad at env right now and the errors stopped
<EmilKarlson> lightdm gets PAN_MESA_DEBUG=trace, but it's stripped on Xorg, probably has to do with env reset on new session or seat or something
<EmilKarlson> Xorg only has PATH and PWD
<EmilKarlson> maybe I should figure out how startx works again
<tomeu> yeah, startx may be best
pH5 has joined #panfrost
yann has joined #panfrost
rellla has joined #panfrost
megi has joined #panfrost
yann has quit [Ping timeout: 258 seconds]
adjtm has quit [Ping timeout: 268 seconds]
yann has joined #panfrost
raster has joined #panfrost
adjtm has joined #panfrost
<EmilKarlson> I seem to get this message and on screen corruption while moving mouse over scroll bar on claws-mail
<EmilKarlson> only Xorg is running with glamor, rest of the stuff is LIBGL_ALWAYS_SOFTWARE=1
raster has quit [Remote host closed the connection]
raster has joined #panfrost
<EmilKarlson> and debian buster
<tomeu> were you able to get a trace?
<EmilKarlson> not yet, will try later
_whitelogger has joined #panfrost
<tomeu> alyssa: gave deqp-gles3 a try, but it hits an assertion when trying to generate the test case list
<tomeu> apparently a program fails to link due to
<tomeu> " "Transform feedback can't capture varyings belonging "
<tomeu> "to different vertex streams in a single buffer. "
<tomeu> "Varying %s writes to buffer from stream %u, other "
<tomeu> "varyings in the same buffer write from stream %u.",
<tomeu> "
<tomeu> guess that's not the actual problem, as the program is:
<tomeu> #version 100 attribute vec4 pos; uniform float scale; void main () { gl_Position = vec4(scale * pos.xy, pos.zw); }
<tomeu> #version 100 void main () { gl_FragColor = vec4(1.0, 0.0, 1.0, 1.0); }
chewitt has joined #panfrost
<tomeu> alyssa: ignore that, I was passing MIDGARD_MESA_DEBUG=deqp instead of PAN_MESA_DEBUG=deqp :(
<EmilKarlson> https://pastebin.com/4UmxmRH6 this is a different one, marked as TODO
<alyssa> tomeu: Ok
<tomeu> EmilKarlson: the TODO there refers to the lack of reason decoding
<tomeu> not to that particular failure
<tomeu> EmilKarlson: a trace could tell us where that other problem is :)
<EmilKarlson> yup, apparently startx removes all environment
<tomeu> maybe run X directly?
<EmilKarlson> the funny thing is, I see the env in my session, but not on Xorg
<EmilKarlson> oh right, Xorg is suid
<EmilKarlson> but that should not clear all environment though, I guess
<tomeu> what about: sudo PAN_MESA_DEBUG=trace X
<alyssa> EmilKarlson: Clearing env for suid is reasonable, the env is an attack vector and for a suid binary that means local privilege escalation (getting root)
<alyssa> ("Why do you know so much about vulnerabilities/exploitation...?")
<EmilKarlson> yes, but IIRC only parts of the env are cleaned by default
<EmilKarlson> like LD_PRELOAD
<EmilKarlson> which I guess is the easiest one
<EmilKarlson> what is the string that I'll need to find in mesa trace?
<tomeu> EmilKarlson: maybe just share it with us
<tomeu> along with the fault messages in dmesg
<EmilKarlson> heh, too large for pastebin
<EmilKarlson> it'll take a while
<EmilKarlson> only 144M
<EmilKarlson> in general I am not sure I got the matching kernel messages, so I might want to precheck
<tomeu> maybe upload it somewhere?
<EmilKarlson> sched_jobs are ta least not found
<EmilKarlson> if that's not useful, I can try to capture it again
<EmilKarlson> I'll need to run X as root, that's the only way I got it working, other might be to remove suid and add some user permissions, but I am not sure how that works, or does it work at all
<tomeu> .exception_status = 30258 (source ID: 0x3 access: 0x2 exception: 0x58),
<tomeu> .fault_pointer = 0x4101800,
<tomeu> seems to be some problem wuth the polygon list
<tomeu> .polygon_list = memory_4100000 + 0,
<tomeu> .polygon_list_body = memory_4100000 + 6144,
<tomeu> polygon_list_body is 0x4101800
<tomeu> alyssa: any ideas?
<tomeu> EmilKarlson: what hw?
chewitt has quit [Ping timeout: 258 seconds]
<tomeu> alyssa: looks like we have some work to do before we can reliably run deqp-gles3: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/449811
<EmilKarlson> rk3399/Kvein
<EmilKarlson> Kevin
<alyssa> tomeu: What's the issue per se?
<alyssa> It doesn't need to be reliable right now; it's not for CI.
<tomeu> alyssa: crashes and a hang
<alyssa> ....Yes, the hang is an issue
* alyssa is just hoping for a list of tests that fail/crash/hang/etc
<tomeu> and the crashes slow things quite a bit
<tomeu> we should invest a bit more on the CI so the hangs are probably reported, but it would be probably faster to just fix them :)
<alyssa> access=0x2 is write or read?
<alyssa> but yes, source ID=0x3 is the polygon list unit thing
<tomeu> alyssa: oh, we know that?
<alyssa> tomeu: Yeah, see the replay.c file in kbase ;)
<tomeu> awesome, we should improve the error messages
<alyssa> tomeu: Uh, 0x3 is the *only* one we know ;)
guillaume_g has quit [Quit: Konversation terminated!]
<alyssa> EmilKarlson: I've been staring at your trace, waiting for an epiphany ;)
<tomeu> ah, pity
<alyssa> tomeu: My hunch is that the size is too small, so a bug in the size computation we're doing
<EmilKarlson> as I said, I don't guarantee the kernel messages and the trace matches, as I tried quite a few times
<alyssa> EmilKarlson: The fault info is in the trace itself as well as the kernel ;)
<alyssa> tomeu: One test could be adding a lot more space to the header_size and then setting the total_size to 0
<EmilKarlson> also the hw may be tangled up, if you are not certain there is sufficient reset between runs
<EmilKarlson> not sure, what state the gpu itself stores
<tomeu> I think that should be fine
<EmilKarlson> I'll try to streamline the process in the future, if you think reports like this are useful
<tomeu> alyssa: something like this? http://paste.debian.net/1093194/
<tomeu> EmilKarlson: would you be able to test with patches such as that one?
megi has quit [Ping timeout: 246 seconds]
<EmilKarlson> I can probably manage, will take a second, so better not wait for it
* tomeu is about to start his weekend
<EmilKarlson> next week is fine
<EmilKarlson> have a nice weekend
<tomeu> thanks, you too! o/
<EmilKarlson> alyssa: are you btw. at the point where you are actively using Panfrost on Kevin?
<EmilKarlson> or rather passively, as in it's stable enough not to hinder work
<alyssa> EmilKarlson: At work (so 40h/wk), I've been using Panfrost full-time since the end of May :)
<alyssa> Off workhours I use a different Kevin with no GPU accel since I don't want the temptation to overwork myself ;)
<EmilKarlson> makes sense
<alyssa> EmilKarlson: (Case in point -- at the end of May, I stopped caring and started bringing my Panfrost-Kevin to class. It was fine, until all of a sudden we had to do something online and I had to recompile mesa due to patching a bug.)
<alyssa> ;P
<alyssa> Needless to say, things have stabilized a lot since then
<alyssa> Uy, my pipelineing register stuff is wacked
jcureton has joined #panfrost
<jcureton> robher: regarding "drm/panfrost: Add support for GPU heap allocations" on dri-devel, i'm currently working with a physical (not FPGA) platform that has a T720 with a single shared interrupt line
<EmilKarlson> alyssa: cool, the progress indeed has exceeded my expectations
<alyssa> EmilKarlson: Thank you!
<alyssa> Wait, where did my writeout optimization patch go
<alyssa> I swear I wrote that maybe a week ago
<alyssa> Am I.. am I hallucinating?
<alyssa> Do I write code in my sleep?
<daniels> that would explain a lot tbf :P
<alyssa> daniels: Rude :p
<alyssa> daniels: Found it thanks to git log --all --grep
<alyssa> ....Granted that doesn't prove I was awake when I wrote it
<robher> jcureton: okay, it may be easier to support than I said. We just need all the handlers to set IRQF_ONESHOT.
<daniels> alyssa: you are familiar with git reflog, right?
<jcureton> robher: okay! i'll try to find time today or early next week to clone that series and try it out
<alyssa> daniels: Only vaguely
raster has quit [Remote host closed the connection]
<alyssa> Argh, blend shaders are so broken
<alyssa> How that code worked before is a mystery
adjtm has quit [Ping timeout: 245 seconds]
* alyssa made writeout more aggressivr
* alyssa just landed the opts from the past few days (minus the aggressive writeout which is still in CI)
<alyssa> But why stop here? :)
megi has joined #panfrost
adjtm has joined #panfrost
afaerber has joined #panfrost
yann has quit [Ping timeout: 244 seconds]
pH5 has quit [Quit: bye]
<cyrozap> Do I write code in my sleep?
<cyrozap> oops, bad paste :P
<cyrozap> <alyssa> Do I write code in my sleep?
<cyrozap> Sometimes I look at code I wrote months/years previously and have _absolutely no recollection_ of _ever_ writing it.
<cyrozap> Same for IRC messages--sometimes I grep through my logs since a particular conversation seems familiar, and it frequently turns out that yes, I _did_ have _the entire exact same conversation_ before.
<cyrozap> Or I'll just be looking through my logs to remind myself of something, and I see words that claim to have been written by me, and sound like something I wrote, but I can't ever remember writing them.
<cyrozap> It's really eerie.
<alyssa> cyrozap: Memory is a strange thing
<alyssa> I can remember specific dates of memorable-but-largely-inconsequential events in my life
<alyssa> I have no idea what I had for lunch yesterday.
<alyssa> Leftover noodles maybe?
* alyssa remembers now.. maybe..
<alyssa> But I can remember random hex sequences from REing :p
<cyrozap> Consciousness in general is a strange thing ;)
<cyrozap> But yeah big mood on the "random hex sequences" thing
<cyrozap> Especially MMIO register addresses and bits
<cyrozap> Going back to a project after 6 months and seeing some bytes/addresses/packet captures, "oh yeah I remember how this all works"
<cyrozap> Reading code I didn't comment in enough: "...what the hell is this?"
<wens> ok, chromium gpu rasterization with panfrost fails with: emit_alu:995: Unhandled ALU op fddx
<wens> this is on veyron speedy, running mesa @ 95732cc9ef3
<alyssa> wens: Yeah, derivatives aren't implemented yet
<alyssa> Though I'm not sure why it thinks they are
<anarsoul> aren't they part of GLES3?
yann has joined #panfrost
<Lyude> ._., love how the moment I go to try to figure out the scpi issue on my T820 it just mysteriously goes away
<Lyude> alyssa: ^ should definitely have the system up and running this weekend, all that's left is just applying chewitt's patches for panfrost and that shouldn't take more then a couple minutes, but I'll probably have to do it this afternoon or tommorrow
<alyssa> Lyude: chewitt: Alright, thank you for the update :)
<alyssa> anarsoul: Yes, 3.0
<alyssa> (IIRC)
<alyssa> Copyprop with swizzles.. totes not over my head T_T
<alyssa> instructions in affected programs: 672 -> 574 (-14.58%)
<alyssa> This seems suspicious for something not even intended as an opt :/
<alyssa> But I'm not complaining
stikonas has joined #panfrost
davidlt has quit [Ping timeout: 244 seconds]
<robher> jcureton: I've updated my panfrost/heap-noexec branch which should work for shared irqs. Any testing would be appreciated.
stikonas has quit [Remote host closed the connection]