logs archiveBotHelp.net / Freenode / #3dsdev / 2015 / September / 20 / 1
endrift
bluh
I think I messed something up
framerate varies ~1 - 2 fps based on which screen it's running on
aliaspider
that's weird
both vsync signals happen almost at the same time right ? although if you are profiling fps, vsync wouldn't be in effect anyway
endrift
I think it's because in one case I'm taking the time to clear both screens (the fps counter is always on the bottom screen)
but that is a LOT of difference
aliaspider
ah
you can speed it up if you use queued gpu commands, and wait only when you are about to send the new commands, not when you finished sending the current ones
endrift
no I don't think that's the problem here
idk I'll look at it
yuriks
endrift: "1-2 fps" from what original framerate?
I can see an extra clear making that difference
endrift
in this game, it's ~58fps on bottom screen, ~56 on top
it has to be the extra clear doing it
yuriks
that's a 0.6ms difference
yeah, I'd pin it on the clear
#fpsisaterribleperformancemeasure
endrift
but like
there should be a way to optimize that so the GPU is busy while the CPU is busy
instead of waiting on the GPU and idling the CPU
aliaspider
there is , I just told you :P
you send commands and go do your things
endrift
aliaspider: I saw that you know, I've tried it before today
it's...hmm
aliaspider
when you want to send the next frame o the gpu
that is when you sync
endrift
look I know how this sh*t works okay
aliaspider
you don't even wait for the buffer swap
what ?
ok sorry
I was just trying to help
endrift
I've just been really stressed lately so I have maybe not been looking at it the right way
when I get stressed I shotgun debug instead of taking a step back
and that doesn't ever help
so why are there PSC0 and PSC1
can you run two fills at the same time?
yuriks
endrift: if you find out, let me know, lol
this is what I originally did the interrupt patch for
you can run two fills at the same time
I assumed PSC0 was for the first fill, PSC1 for the second
but apparently not?
doesn't seem like PSC1 is ever reported, at any rate
endrift
it's totally not the fill that's doing it
it's probably the display transfer
yuriks
oh, yeah, that's probably even slower, hmm
try putting the fps counter on the same screen always? *shrug*
endrift
ok I managed to significantly narrow the gap
the gap is still there though unfortunately
https://github.com/mgba-emu/mgba/commit/465dc2b40048e70380ed26a7451d208f4e643d6c really poorly written changelog, idc
ergh...nevermind
suddenly terrible tearing
aliaspider
swapbuffer needs to be called directly after starting the transfer
the final display transfer I mean
that detail did make go crazy before, it seems the gsp will only swap after a transfer
« prev