00:22 <Lyude> gah, so close

00:23 <Lyude> now at the stage of getting bismuth/rk3399 to not hang on kernel boot

01:12 <alyssa> hanetzer: See robher's kernel tree

01:33 <hanetzer> alyssa: hmm? where it at?

01:35 <alyssa> gitlab.fd.o/robher/linux-panfrost panfrost-5.0 branch or something

01:45 <hanetzer> page not found

01:45 <hanetzer> specifically, g.fd.o/robher

01:47 <hanetzer> ah robh

04:58 <alyssa> I just hacked up a version of the overlay to talk to old kbase

04:58 <alyssa> Why? Not to support old kbase, of course... to use old panwrap1

04:59 <alyssa> It's a bit of gamble, but I'm hoping from the wrap it'll be obvious where we regressed and then poof, t6xx will come back

04:59 <alyssa> More importantly, I have a new set of music I'm obsessed with, so I have plenty of tunes to keep me motivated ;)

05:09 <memeka> thanks alyssa

05:31 <HdkR> alyssa: I have a wrapped output on t6xx if you want it :P

06:44 <memeka> I’ll stick to cheering :)

06:46 <alyssa> I just pushed a branch to my personal fork which draws some triangles on a modern panfrost on 32-bit/t6xxish

06:47 <alyssa> Bunch of regressions to fix still, and then a ton of cleanup (I'm just trying to make forward progress, I'll deal with writing a proper patch once I have something more or less working)

06:54 <tomeu> o/

06:54 <tomeu> alyssa: congrats on movement having moved to upstream, that's a pretty big milestone

06:55 <tomeu> I'm fine with both MRs and ML

12:37 <tomeu> robher: btw, got this backtraces whenever I called the GEM_NEW ioctl: http://paste.debian.net/1066924/

12:37 <tomeu> tomorrow I may be able to debug it further

15:32 <robher> tomeu: Did you pick up my updated branch?

15:33 <tomeu> robher: I'm at:

15:33 <tomeu> 6e572ac0cc80 (HEAD -> panfrost, robher/panfrost-5.0-rc4) drm/panfrost: add initial MMU implementation

15:51 <alyssa> tomeu: ^_^

15:52 <alyssa> MLs are more convenient for me right now, since I do a fair bit of development from a TTY (since desktops + browsers require marginally working gfx drivers ;) ) . I can send off patches from the cmdline and do review from mutt; I can't do that with gitlab.

15:57 <daniels> alyssa: git push to a branch, then use https://github.com/lighttiger2505/lab to create a new MR

15:58 <alyssa> daniels: ...and in one message my objections disappear :) Thank you!

16:00 <daniels> there are quite a few CLI clients available, or hey, you can even roll your own with the python/ruby/... gitlab modules, or curl if you're super bored :P

16:00 <daniels> np!

16:01 <alyssa> daniels: I feel like my time might be betting spent on APIs like OpenGL than GitLab ;)

16:02 <daniels> alyssa: heh, if you look at the '100 MRs' thread on mesa-dev@ as well, most of my posts in there are providing small shell/python snippets to do GitLab Things

16:03 <alyssa> Gotcha

16:03 <alyssa> daniels: Any clients that aren't, um, written in Go? :P

16:03 <alyssa> <--- prejudiced

16:04 <alyssa> Oh, or nodejs, that's worse ;P

16:04 <daniels> yeah there are a ton

16:05 <alyssa> Native C or Python would be preferences ;P

16:05 <alyssa> <--- Prejudiced

16:05 <daniels> https://python-gitlab.readthedocs.io/en/stable/ is in python, but I don't know whether or not it supports creating MRs (it certainly should, since the API you get through the Python module does)

16:06 <alyssa> :+1:

16:11 <daniels> https://about.gitlab.com/partners/#cli-clients has more options than you might want btw

17:08 <robher> tomeu: My first guess is something related to the size of the buffer being larger than 2MB. I'll have to debug it tomorrow with my test program (which I need to push out too).