alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - Transientification is terminating. Memory reductions in progress.
<alyssa> HdkR: Once either freedreno or v3d go Vulkan (and are successful), I'l jump on the bandwagon
<HdkR> :D
<alyssa> Inb4 HdkR starts porting freedreno to Vulkan
<HdkR> I mean, I have a few Freedreno supporting boards
<HdkR> and I do love Adreno from what I learned tinkering with Freedreno :P
<HdkR> Wonder if I ever pushed my Adreno LLVM code
<alyssa> Oy
<alyssa> HdkR: We need you on Bifrost, don't get distracted! :p
<HdkR> Ah, I never pushed it. That code is long gone now
<Lyude> alyssa: don't worry, I'm on bf too :). and bf should be a lot easier to work on in my spare time since I don't need to get hw or anything else reay for it for the time being, just open my laptop and write mesa code
<alyssa> Hooray!
<alyssa> Lyude: Personally I'll stick to gf, but you do you
<alyssa> ....I mean Midgard
<Lyude> still want to help out with the kernel stuff wherever I can as well
<alyssa> ;)
<HdkR> Bifrost needs to get off the ground sooner rather than later and I feel like a huge bottleneck D:
<alyssa> I feel like a bottleneck for Midgard
<Lyude> i think all of the peole working on bf right now are bottlenecks because none of us are being paid to do it full time :p
<Lyude> alyssa: lol no
<Lyude> that's just completely false
<alyssa> Kind of my own fault for blowing 4 days on an art project
<alyssa> ;P
* alyssa plugs self, again
<HdkR> rest is important
<alyssa> There's a realtime d e m o
memeka has joined #panfrost
<memeka> hi ... i have upgraded to more recent kbase (i was using pretty old one, r21p0 before), and now I get a kernel crash either when using arm binary, or panfrost:
<memeka> any ideas about this issue? looks like some changes in PM
stikonas has quit [Remote host closed the connection]
<Lyude> alyssa: lemme know when you've pushed so I can go "woo"
<alyssa> Lyude: Have mesa rebuilds in the middle since I'm paranoid about bisectability at this point ;p
<Lyude> that's a good think to be paranoid about :)
<Lyude> *thing
<alyssa> It's pushed
<alyssa> Lyude: ^^
<HdkR> Woo!
<HdkR> memeka: Looks like a pm failure in kbase
<memeka> HdkR: yes :)
<HdkR> Which would be the same regardless of userspace there
<memeka> HdkR: as of r21p0, it was working ok, in r24 it's not
<memeka> trying to get to the root of it :)
<HdkR> Diff what they changed in the PM bits :P
<memeka> HdkR: yeah there were many iterations :)
<memeka> and "imprecise external abort" is the worst error to have :))
<Lyude> alyssa: hooray!
<Lyude> i'm on a bus now, so I'll release my "woo" at home
<alyssa> :+1:
<alyssa> ....and Phoronix is joining the celebration :)
<HdkR> yay
<alyssa> So for my plans for dev for the near future:
<alyssa> - Refactor non-DRM stuff a little more so Panfrost can be built without those files (but legacy support can be dropped in out-of-tree)
<alyssa> - Upstream the rest of the cmdstream driver (minus non-DRM stuff -- still stub at this point)
<alyssa> - Get us working off upstream from there (except for the overlay)
<alyssa> I'm thinking just a nondrm folder which can be dropped in
<alyssa> Hopefully, the above should be speedy
<alyssa> tomeu: robher: etc: ^^ This means, don't touch userspace for a little while longer unless you want to sort out merge yourself
<alyssa> panfrost/mesa is going deprecated ("You do seem to move the code every few months" "I promise mesa/mesa is the last ;P")
<alyssa> After that, we'll move dev over to the actual mesa-dev list, or mesa gitlab MRs (not sure which -- if people have thoughts here, I'm open to it)
<HdkR> panfrost/mesa is deprecated once all the bits are upstreamed right?
<robher> alyssa: NP, I'm digging into the MMU code ATM.
<alyssa> HdkR: Ya
<alyssa> robher: Bon apetit :)
<HdkR> Typical workflow then, nothing crazy
<alyssa> (If people do have thoughts on mailing list vs MR, do tell. I'm split myself)
<HdkR> Personally I prefer the MR workflow
<HdkR> but that is because I was raised that way
<HdkR> :P
<alyssa> I was too but
<alyssa> There's something... nostalgic.. about mailing lists
<alyssa> Kinda like how I'm nostalgic about the NES even though I wasn't alive then
<alyssa> :p
<memeka> HdkR: there's nothing changed in the PM code :(
<memeka> there are changes in the memory allocation stuff tho` :(
<memeka> hmm found the issue ... it was not getting the clock :(
<alyssa> Gotcha
<alyssa> I hate getting clocked myself, but you do you I guess :)
<memeka> alyssa: of_clk_get(kbdev->dev->of_node, 0) replaced clk_get(kbdev->dev, "clk_mali")
<memeka> problem is on my platoform: clocks = <&clock CLK_FOUT_VPLL>, <&clock CLK_DOUT_ACLK_G3D>, <&clock CLK_G3D>;
<memeka> last one is clk_mali :)
<alyssa> <--- Doesn't touch the kernel
<memeka> and they kept regulator using "clk_get" :)
<memeka> alyssa: now at least I can get a nice crash with panfrost :D
<memeka> alyssa: btw, weird issue: using LD_LIBRARY_PATH, i get "unknown symbol" -> doesn't load the "" etc files from panfrost
<memeka> if I do LD_PRELOAD for them then is ok tho`
<memeka> any ideas?
<memeka> "failed to set mode: Unknown error 524" :D there we go
<memeka> mali 11800000.mali: error detected from slot 0, job status 0x00000040 (JOB_CONFIG_FAULT)
<HdkR> memeka: XU4?
<memeka> mali 11800000.mali: t6xx: GPU fault 0x40 from job slot 0
<memeka> HdkR: yes
<HdkR> Yea
<HdkR> Midgard 1st gen is broken atm
<memeka> i can get egl strings w/o errors :)
<HdkR> Job submission is the issue
<HdkR> I have like five XU4q devices upstairs, I just haven't wanted to try messing with it since i'm busy with Bifrost :P
<memeka> HdkR: :(
<memeka> there are more XU4 users than bifrost users :P
<memeka> here we go, traces!!!
<HdkR> Fun, jump to zero
<memeka> :)
<HdkR> ` helper->vtbl->set_stencil(prsc, stencil);`
<HdkR> That particular issue is because stencil isn't set up
<HdkR> Unrelated to the other crash
<memeka> if (!stencil) return NULL above
<HdkR> wrong check
<HdkR> helper-vtl->set_stencil is null
<HdkR> It would get set in panfrost_resource.c
<HdkR> and it is currently commented out :)
<memeka> :D
<memeka> ../src/gallium/state_trackers/dri/dri2.c:698: dri2_allocate_textures: Assertion `*zsbuf' failed.
<memeka> screen->base.screen->resource_create
<HdkR> Which makes sense if it is attempting a stencil buffer
<memeka> hmmm
<memeka> [drm:exynos_plane_atomic_check] *ERROR* unsupported pixel format modifier
<memeka> bo format: 875713112
<memeka> any idea how to check what format that is?
<memeka> 42RX
<memeka> XR24 :)
<memeka> formats: XR12 AR12 XR15 AR15 RG16 XR24 AR24
<memeka> :(
<memeka> plane supports it :(
<Lyude> i need to setup my exynos machine too
<memeka> ok done
<memeka> fixed that thanks to rtp
<memeka> i can run now kmscube!
<memeka> no errors running it, but mali 11800000.mali: error detected from slot 0, job status 0x00000040 (JOB_CONFIG_FAULT), and black screen
<HdkR> Yep, job submision issue like I said :P
<memeka> this is the log:
<memeka> HdkR: so, job submission you say ... anyone dusts off his XU4? :)
<memeka> I have kernel with kbase ready, get it on any rootfs image and just compile panfrost :)
<Lyude> i've only got an xu3 unfortunately
<memeka> Lyude: sure
<memeka> works on that too :)
<Lyude> I don't believe it will since the xu3 has a 6xx series gpu and I don't think we've gotten support for 6xx fixed yet
<Lyude> (does the xu4 have a 6xx gpu as well?)
<alyssa> Lyude: The above is talking about 6xx
<memeka> Lyude: yes, xu3 and xu4 is the same soc, just different form factor and slightly different dtb
<memeka> Lyude: so dust if off :)
<HdkR> Lyude: XU3/XU4 run the same SoC
<Lyude> oh alright
<HdkR> technically the XU2 was the same SoC as well
<HdkR> 5420 versus 5422
<Lyude> If I've got time tomorrow I'll look-im probably not going to be up for much longer
<HdkR> Working on a bit more NIR->MIR stuff atm
<alyssa> Command stream code sent off to mesa-dev
<alyssa> Message body is too big: 215383 bytes with a limit of 128 KB
<alyssa> I am Good at Patch
<HdkR> MR wouldn't have that issue :)
<alyssa> HdkR: MR would have other issues to dump 6k lines :p
<anarsoul> split it?
<HdkR> Added some more NIR->MIR direct conversion ops tonight. About all I could do for now
<HdkR> Work is draining
<alyssa> :)
<alyssa> anarsoul: Doesn't matter, just need to wait for a list admin :shrug:
yann has quit [Ping timeout: 250 seconds]
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #panfrost
<Ashy> oh wow, pinebook pro looks awesome and I just saw the phoronix article too
<Ashy> nice!
<HdkR> Looks like a great device for Midgard development
<HdkR> :)
ph5 has quit [Quit: bye]
ph5 has joined #panfrost
belgin has joined #panfrost
<memeka> HdkR: Xu4 is great too it needs just developers
<memeka> :)
<HdkR> It is a good device yes
<rtp> memeka: hi. fwiw, I hope to time next week to play with panfrost on my peach pit
<memeka> rtp: did we end up in the same place?
<memeka> Job submission error?
<HdkR> memeka: If you use panwrap to capture a job submission from the blob on the device then compare it to the jobs that panfrost emits then you could see what is failing :P
<rtp> memeka: I dont remember but I think it was something else
<rtp> HdkR: actually, that's my plan for next time I'll work on panfrost :)
<HdkR> nice
<memeka> rtp: try my patch too I think you had data transfer issues
<memeka> So I hope I got pass that
<rtp> not sure I'll use it but I'll probably take parts. I've a bunch of things in a one big patch so I cant use yours without regressing. for instance, I've some changes to make panwrap work when fcntl(F_DUPFD*) is used
<rtp> maybe I should submit theses panwrap changes to make things easier :)
yann has joined #panfrost
<memeka> rtp: all your casting shenanigans were not needed on my system
<davidlt> Ashy, HdkR, yeah, the Pinebook Pro feel much better than Pinebook
<davidlt> I got more close ups on PCBs incl. WiFi chip
<HdkR> woo
<rtp> memeka: I tried various tricks to get things working and casting is one of them. The changes are mostly "test" changes so they may disappear once things are working
<davidlt> HdkR, it's for WiFi + BT
<davidlt> any questions on Pinebook Pro?
<davidlt> for 199 USD it's a nice solutions for mobile dev board / backup laptop with a proper USB-C (data, charging and audio) [you can also use barrel plug to charge].
<davidlt> I don't think they will be making much of the profit here
<davidlt> you can also attach NMVe (all 4 lanes), which is great if you want to avoid slow-IO like uSD, eMMC
<davidlt> IPS screen with 1080p with slim borders
<davidlt> keyboard is nice for such price also (no flex in the middle, enough key travel and also pressing on the key corner registers key nicely)
belgin has quit [Quit: leaving]
<HdkR> ah interesting, a BCM derived wifi device
cwabbott has quit [Remote host closed the connection]
cwabbott has joined #panfrost
<HdkR> Didn't realize SDIO could handle 802.11ac at 1x1 speeds
<memeka> HdkR: don't think it can do fully, but close
belgin has joined #panfrost
belgin has quit [Client Quit]
yann has quit [Ping timeout: 250 seconds]
afaerber has joined #panfrost
tgall_foo has quit [Remote host closed the connection]
tgall_foo has joined #panfrost
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 -]
MoeIcenowy has joined #panfrost
afaerber has quit [Quit: Leaving]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
jernej has joined #panfrost
BenG83 has joined #panfrost
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
jernej has joined #panfrost
<krh> alyssa: it's not just that compilers are slow at bit fields, it's also that bitfields doesn't have the right semantics for this
<krh> sometimes you want overlapping bitfields
<krh> the compiler also masks off the values written to the bitfields so as to not overflow into neighbor fields, which you typically don't want (extra code for something that shouldn't happen)
<krh> so you want to assert on overflow in debug build and do nothing in release builds
stikonas has joined #panfrost
BenG83 has quit [Quit: Leaving]
ph5 has quit [Quit: bye]
ph5 has joined #panfrost
WeaselSoup has quit [Read error: Connection reset by peer]
WeaselSoup has joined #panfrost
yann has joined #panfrost
AreaScout_ has quit [Remote host closed the connection]
<Ashy> davidlt: how does the keyboard compare to a thinkpad, dell xps or the older macbooks?
<davidlt> Ashy, definitely not that quality :)
<Ashy> well, i consider the dell xps keyboards to be fairly low quality with thinkpads being the best
rellla has quit [Ping timeout: 264 seconds]
<davidlt> I don't remember how dell xps feels like
<Lyude> xps is alright
<Lyude> imho ThinkPad's back at it again winning with the keyboards, Dell's still kinda OK, HP is <3 but they still have hell's arrow keys (making the Up and Down keys longer doesn't help HP!)
<Lyude> (i have all of these laptops like right next to me, so :)
<Ashy> yeah my t450 has the nicest laptop keyboard i've ever used, followed by my macbook air 2012 which was my daily driver for 4 years and is still reliable, and trailing very far behind is the xsp13 that work provided me which comparatively has an awful keyboard
<Ashy> that also quite often double triggers keypresses
<Ashy> the previous year xps15 had the same issue too
<alyssa> krh: Mm, I guess
<HdkR> I had some issues with the dell keyboard as well. It isn't too amazing but at least the keys have a consistent feel to them
<memeka> Don’t really like the dells
<HdkR> I had one for work
<memeka> Had a thinkpad 15 years ago, solid keyboard
<Lyude> unfortunately the keyboards have changed a lot since then
<Lyude> Some would say for the better, some would disagree
<memeka> Then MacBooks and liked the keyboards
<memeka> Until the new super slim ones
<ente> seems like the same is true for any development, some people like it, some people don't, the ones who don't are conservative ;P
<memeka> Not enough travel :(
<ente> I agree, and every other laptop maker copied the keyboard from apple :(
<memeka> Don’t consider myself conservative for liking a bit of travel feel :)
<Lyude> my razer blade stealth types like a 2016 mbp
<Lyude> which I'm surprisingly ok with
<memeka> I don’t really like the mechanical long travel ones either
<memeka> The clicking is fun but gets annoying after some time
<HdkR> Sadly this year's keyboards on the razer's aren't good D:
<HdkR> razers*
<Lyude> it has forced my hands to learn to use between 0% and 100% of force instead of just mashing the keys as hard as possible
<Lyude> HdkR: aw
<ente> honestly, me neither, but I like a lot of things about 80s computers more than 2019's computers
<Lyude> tbh though the hell that is TB firmware is probably going to get me to avoid razer laptops in the future unless they start actually updating their firmware
<HdkR> I just love how I can't use quick charge off the TB port </s>
<Lyude> i warned u!!!
<HdkR> Luckily I can swap the charger over to it and use the other type-c port in that instance
<Lyude> like, this laptop works with my one Caldigit dock that I literally had to ask for a specific hardware revision of because it was the only one they sent me that worked with my laptop
<Lyude> newer anything docks just keep power cycling if I plug them in because of the outdated TB controller firmware
<HdkR> heh. TB is just such a great thing
<alyssa> TB?
<Lyude> alyssa: thunderbolt
<HdkR> Thunderbolt
<alyssa> Ah
* Lyude wins
<HdkR> I presume the one laptop that shipped AMD + Thunderbolt didn't do any better?
<Lyude> HdkR: I mean, the main problem has to do with the manufacturer's willingness to actually update the TB controller firmware in a timely manner more then anything else
<HdkR> Yea :/
<Lyude> which is why I don't ever hit issues like this on any of the dell/lenovo/hp machines I've got since most of them have fwupd support at this point
<HdkR> That's good at least
<Lyude> honestly, of all of the issues you would have hoped intel learned from, you'd think that one of those lessons would have been "putting OEMs in charge of firmware updates is 100% a terrible idea in all cases and scenarios forever"
<HdkR> Maybe it'll improve once we're on like seventh generation controllers
<alyssa> Friends don't let friends run blobs
<memeka> alyssa: yeah wish i would not run one too :P i just need a job submission fix :P
<memeka> "i need my fix!"
<memeka> :))