<tmlind>
freemangordon: looks good and works for me thanks
macros__ has joined #maemo-leste
<tmlind>
freemangordon: so i guess pretty much the only remaining weirdness is why stellarium renders at 7fps vs 11fps ish compared to the original blobs
<tmlind>
freemangordon: oh and the mesa EGL_EXT_image_dma_buf_import_modifiers issue
macros_ has quit [Ping timeout: 240 seconds]
<tmlind>
hmm maybe the objectcache stuff causes the performance difference?
<freemangordon>
tmlind: WDYM by "objectcache"?
<freemangordon>
pvr_dri is 100% the same as in the blobs
<tmlind>
weird, i wonder what the difference could be? the blobs also was crashing with glmark2 so something also fixed that somehow
<freemangordon>
tmlind: umm, no, blobs were not crashing, it was chromeos dri that was crashing
<tmlind>
oh ok
<freemangordon>
but blobs does not support xorg, so I wonder there do you get 11fps from, chromeos dri?
<tmlind>
yeah i'm pretty sure swapping some earlier dri makes stellarium much faster and glmark2 to crash
<tmlind>
yeah probably it was the chromeos dri then, not the old binary dri
<freemangordon>
yeah
<tmlind>
if it was the chromeos dri, then 87790e2b9ce7926f6cc492fce01ca9d2f5589107 adds the object cache stuff which could explain
<freemangordon>
is it possible to run stellarium on wayland?
<tmlind>
yeah that's what i use it for
<freemangordon>
with blobs that is
<freemangordon>
and see what fps we get there
<tmlind>
yeah that's what i was testing with over past few years
<freemangordon>
it could be some mesa change that lowered the fps
<tmlind>
something lowered the fps and fixed the glmark2 hang
<tmlind>
may have been two separate changes though
sunshavi has joined #maemo-leste
<freemangordon>
does 87790e2b9ce7926f6cc492fce01ca9d2f5589107 fixes fps?
<tmlind>
no, that still can't be done with wlroots, i've had that always disabled for wlroots
<tmlind>
so i'm pretty sure bakker's original mesa (with EXT_image_dma_buf_import_modifiers disabled) is faster but hangs with glmark2
<freemangordon>
yeah
<tmlind>
so the object cache seems like the biggest difference there to me
<freemangordon>
mhm
<freemangordon>
but, can you check the fps with blobs
<tmlind>
which blobs?
<tmlind>
the original ti blobs?
<tmlind>
i'll try disbling the object cache somehow
<freemangordon>
yes, original blobs
<freemangordon>
if they render with 7fps, then obviously that's all we can get
<tmlind>
hmm not sure i even remember what all hacks wlroots needs to use the original blobs..
<tmlind>
let's see if this works: git diff 87790e2b9ce7926f6cc492fce01ca9d2f5589107.. src/mesa/drivers/dri/pvr/pvrdrawable.c | patch -p1 -R
<tmlind>
only steps to go
<tmlind>
only 100 steps
<sicelo>
for original blobs, iirc we only needed 0001-render-Don-t-use-GL_EXT_unpack_subimage-when-not-ava.patch
<sicelo>
for wlroots, that is
<tmlind>
yeah maybe for wlroots-0.14
pere has joined #maemo-leste
<tmlind>
i'll test with mesa commit at 8206053e95d326d4833f70c65d26527b3a8f1607
<freemangordon>
this is chromeos I would say
elastic_dog has joined #maemo-leste
<tmlind>
yeah, that commit does stellarium at close to 13fps
<tmlind>
ok need to continue at some point later on, ttyl
enyc has quit [Ping timeout: 240 seconds]
<freemangordon>
Wizzup: did you forget about libsdl?
uvos has joined #maemo-leste
<uvos>
Wizzup: did you try kicking neverball again?
<Wizzup>
freemangordon: did not forget
<Wizzup>
uvos: see other channel
<Wizzup>
freemangordon: I've had to deal with some stuff, I'll do it today
<freemangordon>
ok
l_bratch has quit [Quit: Leaving]
l_bratch has joined #maemo-leste
enyc has joined #maemo-leste
pere has quit [Ping timeout: 272 seconds]
<freemangordon>
uvos: is it possible to turn display on *after* vtklock confirms it is shown?
<uvos>
freemangordon: if thats not how it works allready then you can by changing the module load order, but i cant recommend doing that willy nilly, it causes a lot of subtle bugs
<freemangordon>
ok
<freemangordon>
I am thinking of how to deal with vtklock still being drawn when display turns on
<uvos>
it signals mce its finished to early maybe
<freemangordon>
but maybe this is some gtk issue, or vtklock issue itself
<freemangordon>
hmm, ueah
<uvos>
and this some real issue
<freemangordon>
*yeah
<freemangordon>
will check it
<uvos>
so tklock.c waits untill it gets the finished signal via dbus
<uvos>
if thats before or after the when the display gets turned on depends on module load oder
<uvos>
but im pretty sure its before
<Wizzup>
could it be a window resize problem?
<Wizzup>
initially it has some default size and then resizes
<uvos>
right
<uvos>
yeah thats very possible
<uvos>
Wizzup: btw dose openlara show for you now?
<uvos>
in ham
<Wizzup>
yes
<Wizzup>
when I filter by typing 'lara' it did not show
<Wizzup>
I am not sure why, but I can see it in the games category
<uvos>
wierd
<uvos>
ok but thats unlikely to be the packages fault
<Wizzup>
depends on what it filters on
<Wizzup>
if I search for 'open' I can find it
<Wizzup>
but not for 'lara'
<uvos>
hmm
<uvos>
i would expect it to filter on the x-maemo-name thing
<uvos>
and/or the pacakge name
<uvos>
dose it find Lara?
<Wizzup>
checking
<Wizzup>
no
<Wizzup>
maybe it just matches the start of every word
<Wizzup>
looks like that's it
<uvos>
hm that could be improved
xmn has joined #maemo-leste
<Wizzup>
first I think want a separate category for debug symbols
<uvos>
just hide everything that maches dbgsym
<uvos>
its not like users that want to use this gui for pacakge management but cant use apt are going to have a need for debug symbols
<Wizzup>
agreed
xmn has quit [Ping timeout: 256 seconds]
macros_ has joined #maemo-leste
pere has joined #maemo-leste
xmn has joined #maemo-leste
<freemangordon>
yeah, sounds right (hide everything dbgsym)