alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
* urjaman found a screenshot:
<Lyude> i had a triple monitor cube
<Lyude> man i miss the days of compiz
<Lyude> it was literally one of the reasons I tried ubuntu all those years ago
<HdkR> Lyude: I won't be able to pester you about random NV crap anymore :P
<HdkR> (Or the other way around I guess)
<Lyude> HdkR: did you get a new job?
<HdkR> Last day is tomorrow
<Lyude> oooooh! cool-where are you planning on working next?
<HdkR> Contracting work doing fun open source things :D
<Lyude> oh cool!
<HdkR> I mean, if NV wants to tap a known quantified resource in the future for Nouveau things. Easy pick for someone who knows too much :P
<HdkR> Also randomly, fiber HDMI cables are cool
<alyssa----> HdkR: Congrats!
<HdkR> woop woop
<alyssa----> ITE: Alyssa fails to debug mipmaps for the third day in the row
<HdkR> Sounds like typical mipmap problems
<HdkR> :D
<alyssa----> Certainly progres
jolan has quit [Quit: leaving]
jolan has joined #panfrost
TheKit has quit [Ping timeout: 246 seconds]
TheKit has joined #panfrost
jstultz has quit [Ping timeout: 250 seconds]
ric96 has quit [Ping timeout: 240 seconds]
austriancoder has quit [Ping timeout: 250 seconds]
jstultz has joined #panfrost
ric96 has joined #panfrost
austriancoder has joined #panfrost
_whitelogger has joined #panfrost
adjtm_ has joined #panfrost
adjtm has quit [Read error: Connection reset by peer]
chewitt has quit [Ping timeout: 245 seconds]
chewitt has joined #panfrost
belgin has joined #panfrost
belgin has quit [Quit: Leaving]
<bbrezillon> robher, tomeu: anyone plans to use the pfdev->scheduled_jobs field, or is it a leftover of a previous scheduler implem?
<tomeu> bbrezillon: I don't see any use for it, right now
<bbrezillon> for the perfcnt stuff, I'd need to have access to the last queued job so I can compare the perfcnt context/setup of this last queued job to the new job to queue
<bbrezillon> if it's different, we need to add a fence to make sure we have dumped HW counter values before the next job starts
<bbrezillon> tomeu: yep, so the question is, is there any plan to use it, in which case I could access the last queued job from this list
<bbrezillon> if not, I think I'll just add a last_queued_job pointer to panfrost_device and update it everytime a new job is queued
<tomeu> bbrezillon: have you already checked if you can access that info from drm-sched?
<bbrezillon> tomeu: I looked at it
<tomeu> ok, last_queued_job sounds good to me
<bbrezillon> problem is, IIUC, we have X schedulers (X being the number of job slots) and one rq per scheduler
<bbrezillon> so retrieving the last queued job is not an easy task
<bbrezillon> I could probably iterate over all jobs and find the one with the biggest seqid
<bbrezillon> but that's far easier to have a pointer in panfrost_device
<tomeu> yep
embed-3d has quit [Ping timeout: 250 seconds]
<tomeu> alyssa----: does it make any sense that ctx->pipe_framebuffer.cbufs[0] is a tiled buffer?
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
<narmstrong> tomeu: I managed to get panfrost work with your reset code
<narmstrong> the first job fails, then a reset makes it work ok
stikonas has joined #panfrost
<tomeu> narmstrong: are you testing with igt?
<narmstrong> tomeu: not yet
<narmstrong> only kmscube
<narmstrong> tomeu: which igt branch should I use ?
<tomeu> wonder why is kmscube failing
<tomeu> haven't seen any faults with it here
<narmstrong> only the first job fails with : [ 183.893793] panfrost d00c0000.gpu: js fault, js=0, status=DATA_INVALID_FAULT, head=0x2400b00, tail=0x2400b00
<narmstrong> [ 184.417501] panfrost d00c0000.gpu: gpu sched timeout, js=0, status=0x58, head=0x2400b00, tail=0x2400b00, sched_job=00000000e55ebb77
<narmstrong> then it works fine
<narmstrong> maybe the first GPU reset should come after another init
<narmstrong> on mali_kbase, it resets a lof of stuff before running the first job
<narmstrong> i will try igt
<tomeu> but, why do you get faults when running kmscube?
<narmstrong> If I knew...
<tomeu> ok, would be cool to run kmscube with mali_kbase under pantrace
<tomeu> actually no, guess a register dump could be more useful
<tomeu> but in any case, I'm not sure there's much point in debugging this issue atm
<tomeu> all this will change when we implement pm runtime
<narmstrong> well, since your `46ddf17cfc4edfdc5da019f4479ac37244873313` fixed the subsequent jobs
<tomeu> someone observed that mali_kbase resets the GPU before each job, but I wonder if they just saw runtime PM in action
<tomeu> that will power down cores and when waking up, reset and power cores up again
<narmstrong> I need to enable POWER_OFF_ONLY on mali_kbase, so the gpu is reset at each job
<narmstrong> but seems they have the same issue on the new SoCs with bifrost, but seems they fixed so they can omit POWER_OFF_ONLY
<narmstrong> I need to check the hacks done on mali_kbase, but my eyes bleeds when I look at this...
<tomeu> well, guess it could be worse if, on top of resetting the gpu between jobs, you had to replay jobs randomly
<narmstrong> resetting the GPU before each hw_submit doesn fix the first fault...
narmstrong has quit [Ping timeout: 252 seconds]
narmstrong has joined #panfrost
cwabbott has quit [Ping timeout: 246 seconds]
stikonas has quit [Remote host closed the connection]
cwabbott has joined #panfrost
BenG83 has joined #panfrost
<tomeu> narmstrong: this doesn't happen with kbase, right?
<narmstrong> No
<narmstrong> I will do tracing to diff the registers writes between kbase and drm
<tomeu> awesome, thanks
<narmstrong> interesting, whan running the testgles2 from SDL2, the crash happens when I kill the test, not before...
<narmstrong> [ 140.952568] panfrost d00c0000.gpu: mmu irq status=1
<narmstrong> [ 140.952639] Reason: TODO
<narmstrong> [ 140.952639] decoded fault status: SLAVE FAULT
<narmstrong> [ 140.952639] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
<narmstrong> [ 140.952639] panfrost d00c0000.gpu: Unhandled Page fault in AS0 at VA 0x0000000004040200
<narmstrong> [ 140.952639] access type 0x2: READ
<narmstrong> [ 140.952639] raw fault status: 0x50002C3
<narmstrong> [ 140.952639] source id 0x500
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #panfrost
<narmstrong> not for today Quake3Arena [ 2377.222740] panfrost d00c0000.gpu: js fault, js=0, status=INSTR_INVALID_PC, head=0x24a2000, tail=0x24a2000
<narmstrong> (using a GLES port)
<narmstrong> funny, 1/4 of the screen is correcly rendered, the rest is the menu frame
<tomeu> ah, first problem I see in the compiler
<narmstrong> I maybe went a little bit too far by running q3 :-p
<tomeu> narmstrong: TRANSLATION_FAULT_LEVEL3 makes me think that a buffer was unmapped while the GPU was trying to access it
<narmstrong> tomeu: for the first one, i thing the job stop wasn't handled correctly from mesa
<tomeu> ah, guess the kernel should be stopping all of a client's jobs when the client closes the fd
<tomeu> I don't think that's implemented
<tomeu> one more for the TODO :)
<daniels> or at least holding a ref from job -> resources
<alyssa----> tomeu: ctx->pipe_framebuffer.cbufs[0] is ok to be AFBC or linear, it can't be tiled
<alyssa----> Since we can't render into tiled
<narmstrong> tomeu: is tests/panfrost_submit suposed to work ? I get Bad address for each tests
afaerber has joined #panfrost
pH5 has quit [Quit: bye]
cwabbott_ has joined #panfrost
cwabbott has quit [Ping timeout: 252 seconds]
cwabbott_ is now known as cwabbott
pH5 has joined #panfrost
afaerber has quit [Remote host closed the connection]
<urjaman> "your cover letter has style problems" thx checkpatch :D
jernej has quit [Remote host closed the connection]
jernej has joined #panfrost
<alyssa----> What do people think about elementaryOS?
<Lyude> it's alright
<Lyude> but i've never actually used it, I get good vibes from the elementary libraries though
<HdkR> Back in Linux like a sane individual
<anarsoul|2> alyssa----: they're using gnome as their base
<alyssa----> anarsoul|2: And...?
<anarsoul|2> alyssa----: it's somewhat sluggish if you compare it to KDE. I wouldn't recommend it for arm-based systems
<Lyude> HdkR: :D
<Lyude> anarsoul|2: i've heard that it's more sluggish for kde then years and I've honestly always had the opposite experience
<Lyude> granted I haven't tried kde since moving to gnome-shell on wayland because i'm not really interested in != wayland right now (not sure how far KDE's progress with wayland has managed to get yet)
<anarsoul|2> Lyude: well, OK. Just FYI: KDE runs fine even on underpowered Pinebook with no GL at all
<alyssa----> anarsoul|2: Er, Pantheon is diverged very far from GNOME at this point
<Lyude> anarsoul|2: ahhh, yeah you've got me there :p
<Lyude> things have probably changed a lot since I last used it
<alyssa----> anarsoul|2: They're not using JavaScript everywhere, for starters
<anarsoul|2> alyssa----: are they still using it in wM?
<anarsoul|2> s/wM/WM
<alyssa----> anarsoul|2: Vala
* alyssa---- apologises for linking to a m*dium post
<anarsoul|2> sounds convincing, I may take a look
<anarsoul|2> vala is nice
<alyssa----> I'm not pro-eOS or anything, I'm honestly trying to make an informed opinion on it, hence asking here since people here tend to be opinionated :p
<anarsoul|2> but not very popular :)
<anarsoul|2> alyssa----: well, I'm not pro-gnome or pro-kde, I just use whatever works best on my hardware
<anarsoul|2> I'd been using gnome for almost 6 years till I switched back to KDE last year
<anarsoul|2> unfortunately gnome became unusable on my x230
NeuroScr has quit [Ping timeout: 255 seconds]
NeuroScr has joined #panfrost