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
<hanetzer> anyone aware of what the wayland equivalent of glxinfo is?
<HdkR> eglinfo maybe?
<hanetzer> seems to be it
<Lyude> wflinfo
stikonas has quit [Remote host closed the connection]
<hanetzer> neverheard of that one
<hanetzer> oh, nifty. waffle
<hanetzer> should /usr/lib*/dri/panfrost_dri.so exist ?
<HdkR> `/usr/lib/aarch64-linux-gnu/dri/` probably
<hanetzer> that's something for debianish systems, yeah. but, that file should exist, if everthing is right?
<HdkR> Probably :D
<hanetzer> cool, since panfrost is landing in 19.1 I'm looking into adding it to the official mesa ebuild
<alyssa> hanetzer: Panfrost is specifically disabled in userspace since we're not ready for end-users yet. Conformance needs to be a bit better and a lot of work for stability and performance, IMO.
<alyssa> I don't want people using it (outside of special-purpose cases like LibreELEC) and then forever being disappointed by a temporary bugginess
<alyssa> d
<hanetzer> alyssa: hmm? howso?
<alyssa> hanetzer: What do you mean how so?
<hanetzer> 'specifically disabled in userspace'
<alyssa> Mesa does not build Panfrost by default, and that decision was intentional.
<alyssa> I'd rather distros not either ahead of upstream
<hanetzer> ah, so its not say a hardcoded bit of code but the build script, gotcha
vstehle has quit [Ping timeout: 246 seconds]
<hanetzer> hmm. would panfrost on x86/amd64 require kmsro?
<alyssa> hanetzer: ....Um
<alyssa> Target device :blink:
<hanetzer> yeah
<hanetzer> though it would be interesting, no?
<alyssa> That doesn't answer the question
<hanetzer> currently panfrost-capable devices are all arm/aarch64, right?
<alyssa> Yes.
<hanetzer> would be interesting to make a pci card with the rk3399 on it. I've often thought of playing with such an idea
<alyssa> "Do I need kmsro" should be the least of your worries right now
<hanetzer> probably true
<hanetzer> DRM_IOCTL_PANFROST_{CREATE,MMAP}_BO are failing for me :D
<alyssa> Over PCI?
<hanetzer> nah, just normal kevin chromebook
<hanetzer> weston and sway
bbrezillon has quit [Ping timeout: 245 seconds]
<HdkR> I guess I'll do a bit of Panfrost work while waiting for dinner to simmer
<HdkR> alyssa: Does Midgard have a ternary select op
<HdkR> Bifrost has a fun `float D = Src0 == 0.0 ? Src1 : Src2` inst
<HdkR> Comparison bit may or may not be able to be changed
<alyssa> HdkR: It does, that's "fcsel"
<alyssa> (Er, fcsel is "Src0 ? Src1 : src2", what you proposed is the same op just with the argument order switched :P)
<HdkR> :)
<alyssa> Though it's a binary-arg ISA, so src0 is shoved in some fixed magic register
<HdkR> Actually comparison value might be another arg. It's hardcoded to R60 atm
<alyssa> HdkR: Makes sense. Hardcoded to R63 (lolol) for us
<alyssa> Er wait no
<alyssa> It's r31.w, but I guess that'd be R127 for you
<alyssa> But registers r17-r31 are all fake anyway
bbrezillon has joined #panfrost
vstehle has joined #panfrost
tomeu has joined #panfrost
<tomeu> looks like my irc proxy went down tonight
<tomeu> alyssa: any progress on understanding why some tests start failing after fixing an uninitialized access?
<HdkR> :D
<hanetzer> huhu. odd. seems I have panfrost/weston running, but it frequently goes black :P
<urjaman> not odd at all
<hanetzer> like, everything is black except for the 'focused' application and a buffer of pixels around it
<urjaman> yes
<urjaman> that's the buffer_age extension being enabled but not actually working
<urjaman> (that has been talked about often enough here that i thought you'd know...)
<hanetzer> this is mesa-19.1_rc*; forget which. is git head better at this or?
<hanetzer> urjaman: I'm in a lotta channels doing a lotta different things, I lose track \o/
<urjaman> anyways sorry for the snark, my morning not the best
<hanetzer> doesn't seem snarky to me
<tomeu> hanetzer: bbrezillon is working on this, but will take quite some time
<urjaman> but yeah bbrezillon i think has been working on making the extension work, but not yet ... the workaround right now is to disable it
<hanetzer> and how does one disable said extension?
<urjaman> *shrug*
<urjaman> my implementation was grep mesa for disp->Extensions.EXT_buffer_age = EGL_TRUE; and comment out those lines :P
<tomeu> hanetzer: I think you just have to carry the four top commits in https://gitlab.freedesktop.org/tomeu/mesa/commits/hack_buffer_age
<urjaman> the thing that is annoying me more right now is mpv blanking the video whenever the HUD is visible
<hanetzer> 'egl,glx: query dri...' through 'panfrost: disable pipe_cap...' ?
<hanetzer> tomeu:^
<urjaman> i cant watch my series whilst continously skipping boring stuff :P
<hanetzer> this is honestly pretty cool :)
<hanetzer> early brokish dev drivers :)
<tomeu> hanetzer: yep
<tomeu> not 100% sure, I have just learned to live with the black screen :)
<urjaman> yeah i just instead play it all software (and mpv tells me to upgrade my graphics drivers :D) in X
<urjaman> like i tried it once and about 5 minutes in was like "nope, old way was better"
<urjaman> (honestly i find it annoying to be using the GPU as a video scaler on this hardware... the thing would have a completely fine video hardware pipeline without the GPU...)
<urjaman> the 2D hardware can scale and display YUV (or YV12 or whatever) planes (but mpv drm driver afaik doesnt use that, just an RGB scaled plane) and there's even a hardware video decoder to put the pixels in there (that is actually being worked on but anyways...)
<hanetzer> yeah. that and the rk3399's h264/hevc hw, that needs some love both in kernel and userspace
yann has quit [Read error: No route to host]
<tomeu> I think that work is progressing quite nicely
NeuroScr has quit [Quit: NeuroScr]
<hanetzer> for the rk3399 video codec hw?
stikonas has joined #panfrost
<tomeu> yep, and the request api
stikonas has quit [Remote host closed the connection]
BenG83 has joined #panfrost
<HdkR> Pushed some more Bifrost related compiler work. Mostly just playing with features, trying to figure out how derefs work and a few other bits
<HdkR> Also rebased since native_integers compiler option was removed
belgin has joined #panfrost
belgin has quit [Quit: Leaving]
raster has joined #panfrost
BenG83 has quit [Remote host closed the connection]
BenG83 has joined #panfrost
hopetech has joined #panfrost
hopetech has quit [Client Quit]
hopetech has joined #panfrost
kszaq has joined #panfrost
<kszaq> Does anybody here use Kodi on Panfrost? I am experiencing an issue with yuv2rgb shader used by it for software-decoded videos: it looks like only green component is shown. The shader used is here: https://github.com/xbmc/xbmc/blob/master/system/shaders/GLES/2.0/gles_yuv2rgb_basic.frag Curious thing is that when XBMC_COL_CONVERSION is defined, colors are completely fine (lines #L65-L67) - what would be the best way to debug it?
<HdkR> Probably best way to debug it would be to run it through the standalone compiler and try to see if there are any debug messages dumped out, then see if anything in the IR is wrong, then see if anything in the assembly isn't right :P
BenG83 has quit [Quit: Leaving]
<tomeu> also, you may be able to remove stuff from the shader so you isolate what is not working properly
<tomeu> there may be a INSTR_TYPE_MISMATCH fault of similar logged by the kernel, btw
<tomeu> which could may make it more obvious when things aren't working properly
<kszaq> OK, thank you for the pointers. I'm most confused why having additional 3 steps make it work fine. :D
<tomeu> yeah, it could be that some optimization stops happening when the extra steps are enabled
<tomeu> it will probably solve itself once
<tomeu> all deqp tests pass :p
Elpaulo has joined #panfrost
<kszaq> Since I don't know much about how it all works - that's what I hope for. :D
gtucker has joined #panfrost
<tomeu> alyssa: cwabbott: robher: just tried to use 64-bit descriptors on rk3288 with this trivial patch, and things are seriously borked: http://paste.debian.net/1082329/
<tomeu> get DATA_INVALID_FAULT on anything except the first job
<tomeu> and pandecode is also not happy at all
<tomeu> am I missing anything obvious to you?
<tomeu> ah, pandecode is grumpy in general on 32-bit
<cwabbott> tomeu: iirc nobody has tried to trace a T7xx 64-bit cmdstream, so just changing pointers to 64 bits isn't enough
<cwabbott> to turn on 64-bit pointers you'll have to get a setup where the blob uses 64-bit pointers and RE it yourself
<cwabbott> just changing the pointer size isn't enough, as there's probably some shuffling around that happened with the switch to 64-bit pointers that we marked as T8xx only due to lack of T7xx 64-bit traces
<cwabbott> the same would go for 32-bit traces on T8xx
<tomeu> ok, guess in terms of code, what you said T8xx means !is_t6xx
<cwabbott> yeah, that's right
<cwabbott> t7xx also has is_t6xx true since we've been using the 32-bit cmdstream mode which is very similar to t6xx
<cwabbott> *is_t6xx = truee
<tomeu> hmm, but is_t6xx is only used for setting three flags to different values
<tomeu> I don't see anything that changes struct definitions
<cwabbott> I haven't looked at mesa recently, but there definitely are struct changes
<cwabbott> it might still be handled via macros (alyssa would know)
<cwabbott> I mean, via #ifdef
<cwabbott> the goal was to switch everything over to runtime detection, but I don't know if that has happened yet
<tomeu> hmm, I think the only compile-time switches are __LP64__
<tomeu> guess I should first fix pandecode on 32bit though
<cwabbott> oh, that's probably what's switching between T6xx and T8xx
<cwabbott> some of the __LP64__ stuff is probably common between T7xx and T8xx, but other stuff is probably T8xx only
<cwabbott> since only T8xx has been tested with 64-bit pointers
<tomeu> ok, I see
<tomeu> afaics, pandecode has been broken on 32bit for a long time
<tomeu> kszaq: so you got panfrost working on armhf with a t8xx and with 64-bit pointers in the cmdstream with https://gitlab.freedesktop.org/mesa/mesa/merge_requests/650 ?
<tomeu> I'm trying to do the same thing but with a t760, and I get a bunch of null pointer references from the GPU side
<tomeu> which I guess points to wrong structure definitions
<cwabbott> tomeu: that MR works because you're still using t8xx + 64-bit pointers, which is a known configuration, even if cpu pointers are 32-bit
<cwabbott> it's just working around the fact that the t8xx + 32-bit pointer configuration isn't yet understood
<cwabbott> and nor is t7xx + 64-bit GPU pointer
<tomeu> I see
<tomeu> the latter would correspond to the Exynos 7420, looks like
<tomeu> or mediatek MT8735
<tomeu> none of them are supported in mainline
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #panfrost
<alyssa> tomeu: I haven't had a chance to look into much, insanely busy week (Well, more like a ton of Panfrost over the weekend, and then insanely busy Tuesday). Lot of patches to review, so... thank you no thank you ;P
<alyssa> tomeu: Also, wonderful to see we were officially mainlined!
<alyssa> urjaman: I have seen the wacky HUD bug in mpv, not sure what's behind it and hoping conformance work (maybe even bbrezillon's patches) would help
<alyssa> Kodi works fine here fwiw
<alyssa> kszaq: I've been using Kodi a fair bit on RK3399 (using, as in, a couple of hours of video played through it for non-Panfrost reasons ;P).. haven't seen issues with colour conversion, at least when using bilinear filtering.
raster has quit [Remote host closed the connection]
<alyssa> MIDGARD_MESA_DEBUG=shaders,msgs # setting that environment before starting Kodi will dump shader diagnostics... please send me and I'll take a peak
<alyssa> tomeu: What cwabbott said is correct
<alyssa> tomeu: Look at stuff conditional compiled via LP64 macro...
<alyssa> ....As cwabbot said, nvm
<alyssa> tomeu: Pandecode on 32-bit is definitely not happy, no :p
<alyssa> tomeu: First thing I notice is that if you're forcing 64b, then anywhere you say uintptr_t in mali-job it should be uint64_t
<TheCycoONE> typedef'd I hope -
BenG83 has joined #panfrost
chewitt has joined #panfrost
<chewitt> alyssa: the issue @kszaq is trying to figure out is related to netflix/amazon playback, which means video is software decoded
<chewitt> normal playback on rk3399 will be hardware decoded
<chewitt> if you go into settings > player > allow hardware acceleration - PRIME and disable hardware decoding it should force the same behaviour
stikonas has joined #panfrost
<alyssa> chewitt: Hrm, alright. I didn't realise RK3399 kodi did hw accel at all on mainline
<anarsoul> tomeu: alyssa: tllim from Pine64 is offering pine h64 boards for panfrost devs - it has mali t720 on it. Anyone interested?
pH5 has joined #panfrost
stikonas_ has joined #panfrost
stikonas has quit [Ping timeout: 246 seconds]
pH5 has quit [Ping timeout: 246 seconds]
pH5_ has joined #panfrost
<kszaq> tomeu: Yes, the MR was intended to run t8xx from armhf userspace or t6xx/7xx from aarch64 userspace. If you want to run t760 from armhf, you don't need it, right?
<kszaq> alyssa: Thanks, I'll see if I can understand anything from the Midgard debug. Like @chewitt said, to see the bug you need to turn off hw acceleration and play a video in HD resolution as for SD XBMC_COL_CONVERSION is defined and you won't see it.
stikonas_ has quit [Read error: Connection reset by peer]
stikonas_ has joined #panfrost
BenG83 has quit [Quit: Leaving]
_whitelogger has joined #panfrost
tlwoerner_ has joined #panfrost
jeez_ has joined #panfrost
<hanetzer> honestly I have t7xx/armhf and t8xx/aarch64, we need the reverse?
<hanetzer> and I know the t8xx/aarch64 can be ran in armhf mode (since stock chromeos on the kevin is in 32bit)
tlwoerner_ has quit [Read error: Connection reset by peer]
<hanetzer> so the only thing missing is t7xx for aarch64?
tlwoerner_ has joined #panfrost
tlwoerner_ has quit [Remote host closed the connection]
tlwoerner_ has joined #panfrost
tlwoerner_ has quit [Remote host closed the connection]
tlwoerner_ has joined #panfrost
tlwoerner_ has quit [Remote host closed the connection]
tlwoerner_ has joined #panfrost
tlwoerner_ has quit [Quit: Leaving]
<Lyude> oh yeah i forgot to tell yall
* Lyude is on the board of directors for X.Org now :)
<chewitt> congrats :)
<alyssa> Lyude: Hooray! :)
<Lyude> chewitt: thanks!
<HdkR> Lyude: Congrats. You'll do great on it :)
<Lyude> HdkR: thank you!
<Lyude> and thanks alyssa!
chewitt has quit [Remote host closed the connection]
jeez_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alyssa> ..Why won't wifi work on my dev machine anymore...?
mateo` has quit [Ping timeout: 246 seconds]
<HdkR> Wifi 6 came out, said you can't use the old stuff
<alyssa> This calls for a kernel rebuild :v
<HdkR> <Insert Spongebob 3 hours later meme>
<alyssa> Quite.
<alyssa> Anyways, I think I'll just track upstream now
<HdkR> One of these days I'll figure out a way to do cross-compiling or distcc that is actually worth it
<Lyude> nfs
<Lyude> that's what I do :)
<HdkR> well, I more mean that distcc is usually no where near the throughput I want and cross-compiling is usually wildly project specific, making quickly setting up cross-compiling for new things is a chore so I don't do it :P
<HdkR> sshfs for file sharing is easy enough to use :)
<Lyude> yeah, usually what I do is `dnf builddep -y whatever` on the machine I'm building for, then create a meson toolchain file that sets everything to use the rootfs of the test machine over nfs
<Lyude> then bam, suddenly cross compilation works
<Lyude> unless you're building llvm, because llvm-config is satan
<HdkR> oooh, You actually use the target machine's rootfs over the network
<HdkR> hmmm
<Lyude> yep!
<HdkR> Interesting idea
<Lyude> Setting up fscache helps as well
<HdkR> Does sshfs work with this? :P
<Lyude> no idea, but it probably hurts
<HdkR> hmmm
<HdkR> I may have to give it another go in the future. Especially if I start compiling on the N2 more
<HdkR> Moving away from my 64 thread CPU makes me sad now :P
mateo` has joined #panfrost
jeez_ has joined #panfrost
<HdkR> Lyude: Will your new position cut in to your panfrost time? :)
<Lyude> HdkR: i mean I haven't had any time in a while :\
<HdkR> That's why I am curious if it will devour even more :D
<Lyude> but that's mostly because I got myself very stressed out before trying to make time for panfrost and had to step back for a little bit
<Lyude> HdkR:no not really
<Lyude> actually I was going to say no if it would have
<Lyude> the thing is too I can use my work time for this so
<HdkR> woo