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
stikonas_ has quit [Read error: Connection reset by peer]
stikonas__ has joined #panfrost
stikonas__ has quit [Ping timeout: 258 seconds]
stikonas__ has joined #panfrost
vstehle has quit [Ping timeout: 248 seconds]
stikonas__ has quit [Remote host closed the connection]
brads has quit [Ping timeout: 250 seconds]
milloni has quit [Ping timeout: 248 seconds]
milloni has joined #panfrost
chewitt has quit [Quit: Zzz..]
jernej__ has joined #panfrost
jernej__ has quit [Quit: Konversation terminated!]
vstehle has joined #panfrost
jernej has joined #panfrost
chewitt has joined #panfrost
pH5 has joined #panfrost
<tomeu> shadeslayer: is everything clear now?
brads has joined #panfrost
endrift has quit [Ping timeout: 246 seconds]
endrift has joined #panfrost
<cwabbott> alyssa: you know, there is a frag coord as sysval option that you could set instead
<cwabbott> it's some PIPE_CAP
<cwabbott> we've converted things to sysvals as we saw fit to avoid having to look over all the varyings in the beginning
stikonas_ has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
raster has joined #panfrost
<tomeu> alyssa: lots of regressions crept into master
<tomeu> I'm making CI runs as I revert stuff, to find out what introduced them
<tomeu> doesn't seem to be a single cuplrit
<tomeu> alyssa: guess we have two options if we want to keep the CI useful: fix the regressions or update the expectations
<tomeu> we're talking about 300 failed tests
chewitt has quit [Quit: Zzz..]
<urjaman> that sounds like a lot of tests
<tomeu> there were a lot of changes :)
chewitt has joined #panfrost
raster has quit [Remote host closed the connection]
raster has joined #panfrost
<shadeslayer[m]> > shadeslayer: is everything clear now?
<shadeslayer[m]> Nope, didn't manage to figure it out tbh
<shadeslayer[m]> tomeu: ^^
<tomeu> shadeslayer[m]: where have you seen panfrost_drm_job_submit ?
<tomeu> alyssa: you can see where regressions were introduced in this branch: https://gitlab.freedesktop.org/tomeu/mesa/commits/master
<tomeu> I stopped adding reverts once arm64 was green
<tomeu> heh, that's panfrost_drm_submit_job
<tomeu> panfrost_drm_submit_job calls a single SUBMIT ioctl
<shadeslayer[m]> Uh, right >.<
<tomeu> panfrost_drm_submit_vs_fs_job submits two kernel submit jobs: one with a chain of draw calls, and another with a "fragment" job
<tomeu> which on mali terms means a job whose job is to get the draw results into a framebuffer
<tomeu> if there's no draws (for example there's only a clear), then only the latter is submitted
<tomeu> iiuic, a panfrost_job corresponds to what is submitted in panfrost_drm_submit_vs_fs_job: a chain of draw calls plus a fragment job
<tomeu> draws pile up in a single panfrost_job until there's a flush
<tomeu> at which point panfrost_drm_submit_vs_fs_job gets called and panfrost_invalidate_frame prepares the state machine for a new frame
<tomeu> shadeslayer[m]: did that help? :)
<shadeslayer[m]> I see, that does make everything clear :)
<tomeu> \o/
<shadeslayer[m]> I was simply missing that last part about what panfrost_job did
<shadeslayer[m]> That nicely connects everything up
belgin has joined #panfrost
belgin has quit [Quit: Leaving]
afaerber has joined #panfrost
<shadeslayer[m]> tomeu: http://sprunge.us/fCm5JQ
<tomeu> shadeslayer[m]: I think that's the idea, but besides moving code from panfrost_context.c to panfrost_job.c, I think we need to move state as well
<tomeu> so ctx->draw_count as well
<tomeu> panfrost_invalidate_frame(ctx) could be moved to the job as well
<tomeu> alyssa: is that what you had in mind?
<tomeu> shadeslayer[m]: but of course, better make this refactoring gradually :)
<shadeslayer[m]> tomeu: oh, so we need to move any state associated with jobs into panfrost_job and call those from panfrost_context?
<tomeu> shadeslayer[m]: and access fields within panfrost_job only through functions, ideally
<tomeu> shadeslayer[m]: but do it bit by bit, or you will end up with something so entangled you won't be able to pull it off :)
<shadeslayer[m]> <tomeu "shadeslayer: but do it bit by bi"> Yeah, just trying to understand the big picture first :)
belgin has joined #panfrost
<shadeslayer[m]> "/* Generates a set value job. It's unclear what exactly this does, why it's
<shadeslayer[m]> * necessary, and when to call it. */"
<shadeslayer[m]> yup
<tomeu> hehe
jolan has quit [Quit: leaving]
<cwabbott> :q
belgin has quit [Quit: Leaving]
<shadeslayer[m]> panfrost_emit_for_draw .... q.q
<alyssa> cwabbott: Yeah, in my WIP stuff I switched to using that. It doesn't solve the issue of "reciprocating the interpolated 1/w" being wrong compared to "interpolating w". Hence VS changes
<alyssa> tomeu: You know me, broken CI is an opportunity to cause mischief :grin:
<alyssa> I'll fix the regressions if you give me a list to go through
<alyssa> tomeu: Pretty much (re jobs)
<alyssa> shadeslayer[m]: emit_for_draw shouldn't be in panfrost_job
<alyssa> panfrost_job.c is for bookkeeping
<alyssa> emit_for_draw is actually programming the hw state
<shadeslayer[m]> alyssa: oh yeah, I'm just crying after looking at the line count for that function
<shadeslayer[m]> it just goes on forever
<alyssa> shadeslayer[m]: Patches welcome (TM)
<alyssa> :P
<shadeslayer[m]> alyssa: tomeu http://sprunge.us/045z17?diff is what I'm working on
<tomeu> alyssa: the list is at the bottom of https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/338453
<shadeslayer[m]> I want to get a initial implementation of panfrost_job_submit going, then move more state into panfrost_job
<tomeu> but not all tests were broken by the same commit
<tomeu> alyssa: in my master branch you can get a sense of which commits broke which tests: https://gitlab.freedesktop.org/tomeu/mesa/commits/master
<tomeu> shadeslayer[m]: I think that's a good way of starting
<alyssa> tomeu: Oy vey.
<tomeu> not sure if it was mischief or carnage :p
<alyssa> Ouch
<alyssa> tomeu: Okay, looking through the regressions, a -lot- of them are from me breaking cubemaps. Which is expected kinda :P
<alyssa> The other stuff are probably honest-to-goodness bugs
<tomeu> alyssa: ok, if we want to regress because it's better in the longer run, guess we can just add tests to the expected failures
<alyssa> tomeu: Nonnonno
<alyssa> My #1 priority will be fixing hthnose
<alyssa> It's okay to break master; it's not okay to leave it broken
<tomeu> cool
<shadeslayer[m]> panfrost_clear needs to move into panfrost_job_clear I presume?
<shadeslayer[m]> oh and should frame invalidation happen in pan_context or pan_job?
<shadeslayer[m]> since it seems to work on a context, and not a job, but jobs are supposed to invalidate a frame on flush
<tomeu> frame invalidate is mostly there because the job state isn't in panfrost_job yet
<tomeu> basically, frame_invalidate resets the stuff in context that should be in panfrost_job instead
<shadeslayer[m]> I see, but it should move into panfrost_job when I start moving state into panfrost_job
<tomeu> once that state is in panfrost_job, frame_invalidate will stop being needed
<shadeslayer[m]> ahhh
<alyssa> :+1:
<HdkR> :+10:
<shadeslayer[m]> https://gitlab.freedesktop.org/shadeslayer/mesa/tree/refactor/panfrost_job < gonna start pushing things there
<cwabbott> alyssa: it shouldn't be hard to emulate by emitting an invert, but there's now a nir pass that handles inverting w too
<alyssa> cwabbott: Right, but the invert has to happen in the vertex shader
<alyssa> By the fragment shader, we've already gone through lerp'ing and lost information, no?
<alyssa> Wait
<alyssa> perspective-correct interp != lerp ummmm
<alyssa> tomeu: Just pushed two commit s (to your repo so CI picks it up). Should fix a few hundred regressions or so
<tomeu> hehe
<tomeu> just a few hundred...
<alyssa> D'oh
<alyssa> Aside: I have a ton of work from last weekend pushed to my personal mesa but not prettied up for the list
jolan has joined #panfrost
<alyssa> Should probably do that before I totally forget
* alyssa cherrypicks the top one
* tomeu starts to feel the speed
<alyssa> Awful, awful, awful bug
<alyssa> For abs(int), the blob emits:
<alyssa> iabs [src], #0
<alyssa> Second-arg of a one-arg instruction is ignored, so memory corruption meant we emitted
<alyssa> iabs [src], #[junk]
<alyssa> Turns out there's no iabs instruction.... that's iabsdiff
<HdkR> alyssa: but junk is ignored so it is fine? :P
<HdkR> Oh, iabsdiff is a two arg instruction then?
<alyssa> HdkR: See list
<shadeslayer[m]> alyssa: tomeu does this look like I'm going down the right path https://gitlab.freedesktop.org/shadeslayer/mesa/commits/refactor/panfrost_job
<alyssa> :eyes:
<alyssa> shadeslayer[m]: Yes, conceptually :)
<alyssa> shadeslayer[m]: If this were on the list, patches 1/3 would have my R-b
<alyssa> Patch #2 is a little problematic
<alyssa> It's functionally correct, but... the counts are conceptually -part of panfrost_job-
<alyssa> If we're refactoring this, better go the full 9 yards: remove the counts from panfrost_context and only maintain them in the job
<alyssa> Then instead of resetting counters, you just free the job and the counters poof automagically
<shadeslayer[m]> aha
<shadeslayer[m]> I can work on that next and maybe squash the two together :)
<shadeslayer[m]> iterative work ftw
<alyssa> Yup
<shadeslayer[m]> I'm currently refactoring job clearing and trying to fix a stupid compile error :/
<shadeslayer[m]> "error: old-style parameter declarations in prototyped function definition"
<Lyude> shadeslayer[m]: sounds like you did something like `static void foo();` instead of `static void foo(void);`
<shadeslayer[m]> I don't see it tbh
<Lyude> shadeslayer[m]: mind pushing your work to a git repo somewhere so I can take a look
<shadeslayer[m]> must be in panfrost_job_clear
<shadeslayer[m]> sure
* Lyude looks
raster has quit [Remote host closed the connection]
<Lyude> shadeslayer[m]: add a ; after panfrost_job_clear()
<Lyude> the dec in pan_job.h
<shadeslayer[m]> facepalm
<shadeslayer[m]> Lyude: thanks
<Lyude> shadeslayer[m]:np, thank clang - it ended up giving a far more helpful error message than gcc, which just barfed out enough unrelated errors to fill up my terminal's scrollback
stikonas_ has joined #panfrost
<shadeslayer[m]> time to switch
<shadeslayer[m]> ush
<Lyude> heh, up to you, I usually just use gcc myself but my vim config uses llvm for code diagnostics/autocompletion
<HdkR> YouCompleteMe is pretty good, using clang stuff as well :D
<Lyude> oh hey another ycmd user!
<Lyude> yeah I even use it with the linux kernel nowadays (which recently added a super useful script to generate a compile_commands.json from kbuild)
<HdkR> Nie
<HdkR> nice
<HdkR> My only complaint with it is that it ends up being a bit slow with large files
<Lyude> it might be, but since switching to neovim I haven't really had to deal with performance issues for a while now :p
<Lyude> I remember it being slow before I made the switch though
<HdkR> hm. Maybe I should give that a look
<Lyude> also if it helps, there's also a nice gtk client for it that's available on fedora's copr as well https://github.com/daa84/neovim-gtk
<HdkR> Nicer than QT but that doesn't help when I'm using ssh :P
<HdkR> Whoa
<HdkR> That's hecka quicker
<HdkR> and my vimrc copied over almost perfectly
<Lyude> yeah! neovim is ♥
<HdkR> Hm, colour scheme seems to prefer the bright system colours rather than "regular" Will need to change that
<shadeslayer[m]> I'm poking about how to set it up in vscode :)
<shadeslayer[m]> tomeu: alyssa should vertex_jobs and tiler_jobs move out of pan_context too?
<alyssa> Ummm
<alyssa> shadeslayer[m]: Those should not even exist, now that jobs are linked on-demand
<alyssa> You should just have a pointer in pan_job for the first job and the last job and everything else is done implciitly since the actual hardware is a linked list of mali_jobs (see next_job_64 field)
stikonas_ has quit [Quit: Konversation terminated!]
stikonas has joined #panfrost
TheKit has quit [Ping timeout: 258 seconds]
TheKit has joined #panfrost
<alyssa> Just fixed 400+ tests by deleting a few lines of code and nothing else. That's a good day.
<HdkR> :D
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #panfrost
raster has joined #panfrost
pH5 has quit [Quit: bye]
hlmjr has quit [Quit: Konversation terminated!]
herbmilleriw has joined #panfrost
afaerber has quit [Quit: Leaving]
<Lyude> alyssa: oh neat! so it sounds like most of your focus is going to be on getting midgard to run gnome-shell if I'm understanding this correctly
<Lyude> (also congrats!)
<alyssa> Lyude: That's the medium term objective
<Lyude> is there a short term one?
<alyssa> The focus is on fixing dEQP tests and stuff, but from a mgmt perspective, the deliverable is (we hope) G-s running by the end of the summer
<Lyude> Ahhhh
<alyssa> Since... shiny
<alyssa> Though tbh weston is pretty shiny
<Lyude> yeah weston is nice
* alyssa is using Weston+Panfrost+Rk3399 as her daily driver
<anarsoul> why not sway?
<alyssa> Eyecandy..
<bnieuwen2uizen> so, are you actively mapping out the features needed for gnome shell?
<alyssa> We will be a little longer down the line; the hope is that improving conformance will make that easier to work out
<HdkR> <3 the mention
<bnieuwen2uizen> my experience from bringing up a vulkan driver was that a typical app uses a bunch of things not properly tested by CTS.
<bnieuwen2uizen> At some point fixing some CTS tests gives you an adrenaline kick but gets you no closer to running that app
<bnieuwen2uizen> so mapping out features gives you direction in which parts of the CTS you really want to focus on, after which you end up doing some app debugging
<alyssa> Good to note, thank you!
<bnieuwen2uizen> (of course, feel free to ignore this. It is all anecdotal and I haven't had the time to bring up another driver and see to which extent this advice helps :P)
stikonas_ has joined #panfrost
stikonas has quit [Ping timeout: 246 seconds]
<bnieuwen2uizen> btw is the kernel stuff in scope or are you still doing this on top of the proprietary kernel driver?
<bnieuwen2uizen> (or did you switch already and I missed that?)
<alyssa> bnieuwen2uizen: What proprietary kernel driver? :)
<alyssa> bnieuwen2uizen: We were merged in 5.2
<bnieuwen2uizen> \o/
<alyssa> I don't do any kernel myself, butyeah
<bnieuwen2uizen> congrats :)
<alyssa> tomeu: and robher get the credit <3
<shadeslayer[m]> <alyssa "shadeslayer: Those should not ev"> awesome, guess it's time to clean up some code :)
<alyssa> shadeslayer[m]: Have a blast :)
<shadeslayer[m]> hah
<shadeslayer[m]> currently having a blast being lost in Paris, but guess it's as good as time a any to fix this code
<anarsoul> :)
<alyssa> Yupyup
<shadeslayer[m]> now working on moving draw_count into panfrost_job http://sprunge.us/IrFrH6
<shadeslayer[m]> but I think this is trickier, I presume we want to update the draw_count via a panfrost_job function?
<shadeslayer[m]> and not just go draw_count++ ?
<shadeslayer[m]> <anarsoul "alyssa: https://www.phoronix.com"> People already asking for Valhall support in the comments q.q
<HdkR> I'll start working on it as soon as ARM hands over ISA documentation
<shadeslayer[m]> haha
<HdkR> (Theoretically we can reuse significant amounts of the bifrost compiler)
chewitt has quit [Quit: Adios!]
<alyssa> Theoretically.
<alyssa> We'll find out!
<HdkR> ISA documentation would get us a long way though
<anarsoul> HdkR: don't stop poking robher until he gives up and hands out ISA docs :D
<HdkR> I'm not rude enough for that
LinguinePenguiny has joined #panfrost
raster has quit [Remote host closed the connection]
<shadeslayer[m]> tomeu alyssa : when you have a spare moment, it'd be nice to get initial comments on https://gitlab.freedesktop.org/shadeslayer/mesa/commits/refactor/panfrost_job