<Wizzup>
freemangordon: in OMP genre and playlist don't have the touch scroll it seems
<Wizzup>
wait
<Wizzup>
now it works
<Wizzup>
I guess some ts bug
xmn has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
few n900 news: i'm currently testing a Polarcell 1600mA (1572 real) on my n900, got 15 hours of music with audacious (thx to PA user mode), 35 hours idle with modem and cmtspeech On (24 hours with wifi)
<arno11>
sounds really good
<arno11>
and with new fmg DDX most ps1 games run @50-60 fps
<Wizzup>
:)
ceene has quit [Ping timeout: 264 seconds]
pere has joined #maemo-leste
k1r1t0 has quit [Quit: leaving]
arno11 has left #maemo-leste [#maemo-leste]
k1r1t0_N900 has joined #maemo-leste
k1r1t0_N900 has left #maemo-leste [#maemo-leste]
k1r1t0_N900 has joined #maemo-leste
inky has joined #maemo-leste
elastic_dog has quit [Ping timeout: 255 seconds]
<branon>
that's pretty impressive
fab_ has joined #maemo-leste
elastic_dog has joined #maemo-leste
<freemangordon>
ok, and gdb refuses to do stepi and nexti :(
<freemangordon>
what the?!?
k1r1t0_N900 has left #maemo-leste [#maemo-leste]
<dsc_>
ps1 games on the n900??
<dsc_>
thats cool
fab_ has quit [Read error: Connection reset by peer]
<sicelo>
freemangordon: re-gdb: talking to me? i didn't do stepi/nexti. instead, after the `select`, running the FD_ISSET line would always segfault. while stepping through the program, i realized that `fake` was set to -1 in my case, so the call looks like FD_ISSET(-1, &rfds)
<sicelo>
reading up on the problem, i almost ported the code to use `poll` instead of `select` ... i chose the easier path in this case (lazy?)
<Wizzup>
I think he was talking to himself
<sicelo>
ah :-)
arno11 has joined #maemo-leste
fab__ has joined #maemo-leste
<Wizzup>
dsc_: we have pcsx
slep has left #maemo-leste [#maemo-leste]
<freemangordon>
or rather, /me was talking to the world :)
<freemangordon>
HW compositing fails for ATLAS blits, whatever it is
<freemangordon>
and I cannot debug why
<freemangordon>
(have to step in the blob)
fab__ has quit [Read error: Connection reset by peer]
fab__ has joined #maemo-leste
fab__ has quit [Quit: fab__]
pere has quit [Ping timeout: 260 seconds]
arno11 has left #maemo-leste [#maemo-leste]
pagurus has joined #maemo-leste
<freemangordon>
ok, at least on d4 scrolling in abook is faster with SW compositing
<Wizzup>
huh
<freemangordon>
mhm
<freemangordon>
the same in settings
<freemangordon>
44 vs 48 fps
<Wizzup>
how is the cpu utilisation?
<freemangordon>
SW vs HW?
<freemangordon>
I would say the same
<freemangordon>
keep in mind not all compositing is HW accelerated
<freemangordon>
seems there is a bug in blobs that prevent compositing when src and dst have different bpp
<Wizzup>
freemangordon: yeah I was asking about cpu utilisation between sw and hw
<Wizzup>
seems like it shouldn't be the same if there are no bugs
<Wizzup>
understood in any case
<freemangordon>
well, the diff would be in range of 2-3%
<freemangordon>
the heavy ops are copying
<freemangordon>
which are already accelerated
<Wizzup>
ok
pere has joined #maemo-leste
pagurus has quit [Remote host closed the connection]
<freemangordon>
hmm, actually with HW cpu usage is higher
<freemangordon>
weird
<bencoh>
but is it "faster"?
<freemangordon>
no
<bencoh>
oh, nevermind, you said sw is faster
<freemangordon>
mhm
<bencoh>
something about upload textures to gpu maybe
<freemangordon>
not textures
<freemangordon>
those are already BOs
<bencoh>
ah
<freemangordon>
all the memory is omap_bo_new() etc
<freemangordon>
actually I would expect fallback path to be slower, as there I wait for GPU ops to complete before allowint CPU to render
<freemangordon>
and the shaders for HW compositting are 'borrowed' from blob that was released by TI, so I would expect those to be fast
<freemangordon>
about 2000LOC in vain :(
<Wizzup>
it might not be in vain
<Wizzup>
it might also be faster on n900 still
<freemangordon>
it is not
<Wizzup>
ok
<freemangordon>
I wonder what to do with that code
<Wizzup>
def. keep it around, I think there is a decent change we might get it to be faster
<Wizzup>
I'm kind of surprised that it's almost exactly as fast
<freemangordon>
keep in mind it has some renering issues
<freemangordon>
*rendering
<freemangordon>
like, transparency seems to be ignored
<freemangordon>
but ok, I'll ifdef the code
<Wizzup>
is it any different in 16 bit btw?
<freemangordon>
didn't try
<freemangordon>
16bpp is useless anyways,no?
<freemangordon>
though, there is some code to force alpha in 16 bits
<Wizzup>
yeah, I don't know if it will help a lot
<freemangordon>
ok, I'll push the code with HW compositing disabled
<freemangordon>
so if someone wants to check what's going on
<freemangordon>
despite this, I think I was able to squeeze few fps more, by tracking pixmaps ownership
joerg has quit [Ping timeout: 276 seconds]
<Wizzup>
great
<Wizzup>
would neon help somehow?
<Wizzup>
(maybe it is already)
<freemangordon>
maybe, but not in Xorg
<freemangordon>
afaik it already uses pixman
<freemangordon>
maybe we have some issue in GTK
<freemangordon>
because on n900 even in 16bpp scrolling in gtk apps is too slow
<Wizzup>
right
<freemangordon>
on n900 gears render with 20fps
<freemangordon>
even on 16bpp
<Wizzup>
but that comes from gpu right?
<freemangordon>
yes
<freemangordon>
however, those 20 fps are enough so scrolling in launcher to be nice
<freemangordon>
it is gtk apps that suffer from some issues
<freemangordon>
maybe NEON optimization I put there is not hit, dunno