rz2k has quit [Read error: Connection reset by peer]
rsalveti_ has joined #arm-netbook
rsalveti has quit [Ping timeout: 248 seconds]
rsalveti_ is now known as rsalveti
valhalla has quit [Ping timeout: 252 seconds]
herdingcat has joined #arm-netbook
valhalla has joined #arm-netbook
dyoung is now known as dyoung-away
aholler has joined #arm-netbook
aholler_ has quit [Ping timeout: 248 seconds]
KoH_ has joined #arm-netbook
DEAT has quit [Read error: Connection reset by peer]
DEAT has joined #arm-netbook
KoH__ has quit [Ping timeout: 272 seconds]
cnxsoft has quit [Quit: cnxsoft]
gimli has joined #arm-netbook
Guest95108 is now known as fredy
fredy is now known as Guest43806
Guest43806 is now known as fredy
herdingcat has quit [Ping timeout: 240 seconds]
herdingcat has joined #arm-netbook
hramrach has quit [Remote host closed the connection]
bsdfox has quit [Read error: Connection reset by peer]
gimli has quit [Ping timeout: 248 seconds]
bsdfox has joined #arm-netbook
bsdfox has quit [Changing host]
bsdfox has joined #arm-netbook
Ershov has quit [Quit: Ershov]
hramrach has joined #arm-netbook
Ershov has joined #arm-netbook
eebrah has joined #arm-netbook
eebrah is now known as eebrah|away
tom_say has quit [Remote host closed the connection]
swivelgames has quit [Quit: Leaving]
eebrah|away is now known as eebrah
Quarx has joined #arm-netbook
Ershov has left #arm-netbook [#arm-netbook]
cnxsoft has joined #arm-netbook
Ershov has joined #arm-netbook
Ershov has left #arm-netbook [#arm-netbook]
herdingcat has quit [Ping timeout: 252 seconds]
herdingcat has joined #arm-netbook
pcat has quit [Ping timeout: 260 seconds]
rellla has joined #arm-netbook
Ershov has joined #arm-netbook
adibek has joined #arm-netbook
<adibek>
Does anyone make a10s_defconfig for linux-sunxi ?
<slapin>
does anyone have a10s?
<rm>
here?... or at all?
<sspiff>
slapin: you mean, does anyone have A10 based devices?
<rm>
A10s dammit
<rm>
not A10
<rm>
if you aren't aware there is even A10s (which is NOT A10)
<rm>
why do you bother trying to answer something
hg_5 has joined #arm-netbook
<sspiff>
rm: as you may notice, A10s looks a lot like the plural of A10, so I don't think the misunderstanding is that weird
<adibek>
I have mk802+ (cs102) with a10s and from 2 weeks i test images to boot linux and build images from linux-sunxi a u-boot but still dont have working linux
<rm>
it may or may not be weird, it is certainly not rare, so I am kind of tired seeing people make this mistake already :)
<adibek>
A10s is more like A13 but images from A13 does not boot
<sspiff>
rm: there are less agressive ways of communicating your frustration?
<andoma>
didn't hans to some work/research on getting linux running on a10s?
hg_5 has quit [Ping timeout: 255 seconds]
pcat has joined #arm-netbook
<adibek>
maybe Hahs getting linux running on a10s but there no even small instruction how to do this ?
hg_5 has joined #arm-netbook
wingrime has joined #arm-netbook
hg_5 has quit [Ping timeout: 246 seconds]
<mnemoc>
Adibek: the stage branches have the driver for the AXP used by A10S. as of defconfig, you can start from a13's or sun5i
<mnemoc>
but there is no a10s specific defconfig yet
rellla2 has joined #arm-netbook
<adibek>
i was try using sun5i but no efects , i must add serial console to my device for more detals
rellla has quit [Ping timeout: 240 seconds]
br- has joined #arm-netbook
XenGi_ has quit [Ping timeout: 252 seconds]
XenGi has joined #arm-netbook
hg_5 has joined #arm-netbook
mSquare has joined #arm-netbook
pcat has quit [Ping timeout: 256 seconds]
popolon has joined #arm-netbook
rellla2 is now known as rellla
<andoma>
Adibek: on my a10s stick i didn't manage to locate pads for soldering on a serial port
TestModule has joined #arm-netbook
<TestModule>
I got a weird error a second ago. u-boot: spl.c:261: undefined reference to `spl_display_print'
<TestModule>
Also throwing this: dram.c:30: undefined reference to `DRAMC_init'. I didn't see these errors before the pull i did
aesok has joined #arm-netbook
hg_5 has quit [Ping timeout: 240 seconds]
pcat has joined #arm-netbook
herdingcat has quit [Remote host closed the connection]
mac- has quit [Ping timeout: 272 seconds]
valhalla has quit [Read error: No route to host]
valhalla has joined #arm-netbook
cnxsoft has quit [Quit: cnxsoft]
Ershov has quit [Read error: Connection reset by peer]
<hramrach>
because they create threads behind the back of singlethreaded processes
<libv>
hramrach: also, readelf -d
<hramrach>
which don't initialize threading in X11, Gtk, ..
<libv>
hramrach: why would that be relevant?
<libv>
hramrach: only the mali lib uses threads
<libv>
hramrach: everything above job submission is singlethreaded
aesok has quit [Read error: Connection reset by peer]
<libv>
all state setup is single threaded, the application never should be aware of there being threads in the back, apart from some context switches eating cpu time
xymox has quit [Ping timeout: 248 seconds]
<hramrach>
the pthread library is initialized
<libv>
and?
<libv>
gdb will complain, sure
<hramrach>
the xcb and gtk/glib libraries do some voodoo to determine it is
<hramrach>
use a mutex to serialize
<hramrach>
that mutex does not exist
<hramrach>
crash
<libv>
that's an issue with xcb gtk/glib
<libv>
mali libs are threaded in way that should not matter for applications talking to it
<libv>
so blame xcb, gtk/glib
<hramrach>
hehehe
Ershov has left #arm-netbook [#arm-netbook]
<hramrach>
except look at the start of the log
<hramrach>
there is unknown request error
<hramrach>
unless that is some sort of corruption the egl lib *does* fiddle with X protocol behind the back of xcb lib
xymox has joined #arm-netbook
<libv>
hramrach: what are you doing to cause this?
TestModule has left #arm-netbook [#arm-netbook]
<hramrach>
es2_info
<adibek>
andoma: Can You upload the photo of your board ?
<hramrach>
on the old mali driveer if that matters
<libv>
where can i find that application?
<libv>
i will give it a whirl now on the framebuffer
<libv>
but my intention is to make the mali-libs test also work on X
<hramrach>
libv: to be precise I compiled mesa demos with the Mesa libgl and Mali libgles installed
<hramrach>
it won't work on framebuffer
<libv>
now there is your problem.
<hramrach>
that would be easy if I could import the es2_info code
<libv>
yes, but, this is why you have this issue now
<hramrach>
but that says (c) Tungsten graphics. All rights reserved
<libv>
it was a gamble worth taking
<libv>
but it did not work out
<hramrach>
so I use the test for fb and es2_info for X
<libv>
look, i explained a month ago that it is easy to port the test to X11
<hramrach>
it used to work before
<libv>
i will now go and do the work for that, which is mostly about setting up things so that they work with the mali libs under X
<libv>
then you too will have a working test under X
<libv>
yes, well, the mali libs have been threaded all the time, so that definitely is not the issue
<libv>
compiling es2_info in the mesa tree, and then hoping that they completely work against an opengles2 binary driver, that should make one feel slightly uncomfortable
<libv>
it should work, yes, but it clearly doesn't
<libv>
in this case
<hramrach>
yes, maybe the libX11 got upgraded to a newer, more broken version
<hramrach>
the test works fine, just crashes at the end
<hramrach>
it's not in Mesa tree
<hramrach>
it's in mesa demos
<libv>
but you built it against the mesa tree is what i understood
<hramrach>
it does what it should but libx11 shoots it down at the end
<hramrach>
or libxcb
<hramrach>
I suspect any non-trivial X program linking with the X libs in Debian using GLES will do the same
<libv>
maybe the version of the mali libs egl that you are using has a bug
<hramrach>
no, only the GL part
<hramrach>
not the GLES part
<libv>
that does not make sense.
<hramrach>
the demos refuse to build without libGL and Mali SDK does not provide one
<libv>
ah, hah
<libv>
hramrach: stop worrying, you are indeed doing it wrong.
<hramrach>
in fact the demos refuse to build against the Mali GLES because there are no .pc files
<hramrach>
been meaning to add them so the autocrap stuff works
<hramrach>
why?
<hramrach>
GLES is binary ABI
<hramrach>
the libs should be interchangeable
<libv>
yes, GL and GLES aren't
<hramrach>
in fact the Ubuntu es2_info libraries are biults against Mesa and used on Mali
<libv>
lucky
<hramrach>
I built against Mali but does not really make any difference
<hramrach>
*es2_info binaries
<libv>
maybe they built mesa right, and produced a gles library?
<hramrach>
yes, I have libGL just so autocrap detects it and moves on to libGLES
<hramrach>
it is irrelevant waht libGL I have. it's for libGL demos
<libv>
hramrach: in any case, i will get you your mali-libs test ported to X11
<hramrach>
yes, I could install that
<hramrach>
but that would not work on mali
<libv>
...
<hramrach>
well, perhaps it would load llvmpipe
<libv>
?
<hramrach>
??
<ssvb>
libv: maybe he is still talking about libGL?
<libv>
ssvb: even then it does not make sense :)
<andoma>
Adibek: it's already on the wiki
<hramrach>
how does it not make sense?
<hramrach>
the Mesa demos have programs for GL, programs for OpenVG, programs for GLES1, programs for GLES2
<hramrach>
to build them you need libGL
<hramrach>
the GL demos are not optional
muts has joined #arm-netbook
<hramrach>
autocrap ..
<ssvb>
hramrach: if they are pulling in unneeded libGL dependency, it's more like mesacrap than autocrap
<hramrach>
it's not unneeded
<hramrach>
the programs that link to it need it
<libv>
mesacrap indeed
<hramrach>
you just cannot skip building them
<libv>
no libGL, but only libGLES -> build only gles apps.
<libv>
ssvb is right
sspiff has quit [Read error: Connection reset by peer]
sspiff has joined #arm-netbook
sspiff has joined #arm-netbook
sspiff has quit [Changing host]
valhalla has quit [Ping timeout: 252 seconds]
valhalla has joined #arm-netbook
vinifm has quit [Ping timeout: 248 seconds]
arete74 has quit [Ping timeout: 264 seconds]
Quarx has quit []
Quarx has joined #arm-netbook
Quarx has quit [Client Quit]
Quarx has joined #arm-netbook
Quarx has quit [Client Quit]
Quarx has joined #arm-netbook
hipboi has joined #arm-netbook
prw has quit [Ping timeout: 245 seconds]
vinifm has joined #arm-netbook
<andoma>
libv: which kernel version (commit hash) are you using when you have working binary drivers for the framebuffer
<andoma>
i've been struggling quite a bit now and it's still no go
SouL_ has joined #arm-netbook
SouL_ has left #arm-netbook [#arm-netbook]
adibek has quit [Quit: Page closed]
jelly has joined #arm-netbook
datagutt has joined #arm-netbook
cnxsoft has joined #arm-netbook
dyoung is now known as dyoung-away
<libv>
andoma: sunxi 3.0
<andoma>
latest
<andoma>
?
<libv>
not the absolute very latest
<libv>
but late-ish
<andoma>
i tried a couple different kernel version .. also 3.4, none worked
<andoma>
it fails somewhere inside eglCreateContext() .. did some singlestepping and some kind of struct contains 0 in a word where the driver wants it to be 4, if not 4 it returns glError 3005
<andoma>
bytes per pixel perhaps? who knows
<andoma>
care to pastebin output from fbset -i or something
* slapin
got 2 nameless A13 tablets again, will try to identify what to make out of it
<libv>
andoma: what application are you running?
<andoma>
test from mali-libs
<libv>
under X11?
<andoma>
no
<libv>
hrm.
<libv>
let me give that a go in a minute, as i just cleared my todo list
<andoma>
no worries i'm not with the device now anyway as i'm dayjob as usual
<libv>
hramrach: this is not a bug that you should file against debian.
valhalla has quit [Ping timeout: 246 seconds]
* libv
just read the bug report against debians libx11
<libv>
andoma: you are using r3p0, right?
<andoma>
libv: yup
<andoma>
i am using my "own" rootfs though.. or actually more or less a standard buildroot compiled with pretty recent linaro toolchain (gcc 4.7)
XenGi is now known as XenGi_
<hramrach>
libv: since debian does nothave the most recent libs it's hard to file with upstream either
<libv>
hramrach: it's not a bug with either.
<libv>
hramrach: it's a bug with what you are doing on the mali library you are using, and i think it is a bug with what you are doing
<hramrach>
also comparing the output of the test program with X11 and framebuffer the only difference is that on framebuffer program reports surface size 480x480 while on X11 it reports surface creation error
<libv>
i really do suggest that you close this bug as to not bother the debian people needlessly
<hramrach>
running gnome-shell is a bug?
<hramrach>
you could say that but Debain packages it
valhalla has joined #arm-netbook
<libv>
hramrach: debian packages mali-libs?
<hramrach>
no
<libv>
then close the bug
<hramrach>
it packages GLES programs, however
<hramrach>
those should somehow work in the distro
<libv>
you know what, f this.
<libv>
i am putting you on ignore
<libv>
you seem to be totally void of logic.
ln2 has joined #arm-netbook
<ln2>
Let me know when I should send the Diablo III keys.
<ln2>
misstell. **
<hramrach>
libv: the logic is that GLES is an ABI and the library should be replaceable with any other
<hramrach>
maybe that logic is wrong
<hramrach>
but then the libraries we have are next to useless
vinifm has quit [Quit: Ex-Chat]
valhalla has quit [Ping timeout: 256 seconds]
<xenoxaos>
i would think libv would know what he's talking about....
<libv>
i am sure that i am not the only one seeing the broken logic, and that this is, at best, a bug against sunxi mali-libs and not against debian libx11.
revident has joined #arm-netbook
arete74 has joined #arm-netbook
<hramrach>
libv: are you saying that the mali libs are broken for using threads?
<hramrach>
they cannot initialize the X11 threading because the app must do it by X11 interface
<WarheadsSE>
techn_: sure can, can you put in a github issue for it?
arete74 has quit [Read error: Connection reset by peer]
arete74_ has joined #arm-netbook
GeorgeIoak has joined #arm-netbook
danlench has left #arm-netbook [#arm-netbook]
<GeorgeIoak>
ssvb: Does VLC/CedarX ONLY run fullscreen? That's all it has done for me (it scales any video to FS) and now of course I need to play a video on part of the screen
<hramrach>
are you using the framebuffer libraries or x11 libraries?
<ssvb>
GeorgeIoak: I have not tried VLC/CedarX
<hramrach>
on framebuffer the logic is that the application uses whole screen
<hramrach>
in X11 you can have windowed application
<GeorgeIoak>
hramrach: i compiled it last week and can't remember now, how could I check?
<hramrach>
but not sure vlc would work with CedarX in X11
<GeorgeIoak>
I don't remember having a choice of which libraries to use
<hramrach>
do you have an X server running?
<GeorgeIoak>
yes, wills version does work well but it is always fullscreen. yes X is running
<hramrach>
or perhaps does DISPLAY="" vlc
<hramrach>
work?
<GeorgeIoak>
i know you have to use these switched when running cvlc, --codec cedar --vout cedarfb
<GeorgeIoak>
brb
<hramrach>
does 'DISPLAY="" vlc' work?
<hramrach>
if it uses X it needs display
<Triffid_Hunter>
mplayer uses SDL for me if DISPLAY is empty, works but is chunky at best
<hramrach>
oh, cedarfb is probably direct framebuffer rendering
<hramrach>
that explains why the console is not visible but active
<hramrach>
GeorgeIoak: vlc simply draws over the whole screen without regard for anything else that might be on it
ZaEarl has joined #arm-netbook
<GeorgeIoak>
hmm, ok, that sucks for this application as it turns out, i thought you could write to a portion of the FB
<GeorgeIoak>
and yes mplayer is not great but it's close with the videos that i have that need to play
<GeorgeIoak>
has anyone tested which codec might perform better for the CPU, right now it takes ~65-75% on a MP4/h.264
ssvb has quit [Ping timeout: 276 seconds]
<jinzo>
I see someone quite close is selling his mele 1000 - how are they build wise?
ssvb has joined #arm-netbook
mSquare has quit [Quit: Leaving.]
<jinzo>
ssvb, I read your blog, quality stuff, keep em coming!
<GeorgeIoak>
ssvb: didn't know you had one, what's the link?
<Turl>
GeorgeIoak: with cedar, on performance governor?
cnxsoft has quit [Remote host closed the connection]
<GeorgeIoak>
Turl: you lost me, sorry
<GeorgeIoak>
crap, just found out i have to be on a conference call in 2 hours to discuss this. what's my best option to run a video on a web page, is there any codec that will perform better?
<GeorgeIoak>
right now the videos are m4v @ 704x396 and mplayer can barely keep up
<Turl>
GeorgeIoak: what cpu governor are you using?
<GeorgeIoak>
seems like i have to run performance
<GeorgeIoak>
of course running cpufreq-set -g performance works best but not sure if that's wise to leave for 24/7 kiosk
<Turl>
what I was saying was, if you're on cpu perf governor and using cedar, I think 60% cpu usage is a bit too much
<GeorgeIoak>
turl: yeah, i have that set in my rc.local
dyoung is now known as dyoung-away
<GeorgeIoak>
no, vlc/cedar is very low cpu but it only plays full screen and for this kiosk the videos need to be in a window
<GeorgeIoak>
i thought i was ok, until they sent me a sample of what they want to run last night
Avernos_ has joined #arm-netbook
<hramrach>
depending on the cedar interface you might be able to specify screen rectangle to output to
<GeorgeIoak>
i'm really surprised at how much CPU it takes to play a 704*396 video, i'm hoping that maybe a different codec will work? this one is AVC, High@L3.0
<GeorgeIoak>
hramrach: i tried passing the --width --height switch and it gets ignored
Avernos has quit [Ping timeout: 244 seconds]
<hramrach>
but at this point the output driver you picked based on the vlc guide is not made to do that
<GeorgeIoak>
I noticed in my FEX I have fb0_scaler_mode_enable = 0 and fb1_scaler_mode_enable = 0 but when I enabled them i saw an error in the log and vlc didn't play the video
<GeorgeIoak>
hramrach: meaning --vout cedarfb and it's writing to whole fb?
<Turl>
GeorgeIoak: high profile is not good if you want speed
<Turl>
GeorgeIoak: try baseline profile h264
<hramrach>
hmm, it does not seem there is an option to not draw fullscreen
<GeorgeIoak>
turl: thanks, you think h.264 is the best bet to reduce cpu?
<GeorgeIoak>
hramrach: that is what i found last night and once again my heart sank
<hramrach>
at least not with the interface the willswang cedar lib provides
<Turl>
if you have a decent neon decoder, it might be bearable
<Turl>
keep the resolution low too
<GeorgeIoak>
well i would have thought 704*396 was low?
Avernos_ has quit [Read error: Connection reset by peer]
<GeorgeIoak>
Turl: decent neon decoder, what's my options?
<hramrach>
I don't know what NEON decoders are available. All I found were pay-for and not easily obtainable
<hramrach>
but if you convert to, say, mpeg2 you should have reduced demand for CPU power
<GeorgeIoak>
by pay-for, how much are we talking about? i'm in a real bind here if i can't get this to work
Avernos has joined #arm-netbook
Avernos has quit [Changing host]
Avernos has joined #arm-netbook
<Turl>
the android vlc has neon decoding, I bet the desktop one does too
<hramrach>
cool
ln2 has quit [Quit: ln2]
<hramrach>
then just pick different output driver I guess
<hramrach>
or maybe just install vlc from distro
<GeorgeIoak>
i've never done anything in android though and i'm beginning to think i have should have started learning it 2 weeks ago
<GeorgeIoak>
hramrach: are you saying that the distro vlc is going to be better than mplayer?
<hramrach>
I have no idea
<hramrach>
I did not try playing any videos yet
pcat has quit [Ping timeout: 252 seconds]
<GeorgeIoak>
Turl: so i'm still confused if i have an option to try a different neon decoder
<GeorgeIoak>
hramrach: i never expected to be one of the few trying to get video playback :(
<GeorgeIoak>
strange, the only reference to ffmpeg on my system is in the libcedarx source tree. Chromium browser is installed and i thought it used ffmpeg?
<Turl>
it may, but it's an internal thing
<GeorgeIoak>
ok, i'll install ffmeg and see what happens. i do remember that on the vlc command line he had --fmeg demux but that didn't work well for me as well as someone else and removing that allowed the videos to play well
gimli has joined #arm-netbook
<hramrach>
GeorgeIoak: it's called libav-tools now
<hramrach>
and the corresponding libav* libraries are possibly used by vlc/mplayer/..
<GeorgeIoak>
hramrach: crap i just installed ffmpeg, i should install libav-tools instead?
<hramrach>
that should be the same thing
<GeorgeIoak>
ffmpeg --version said i should use libav-tools
<GeorgeIoak>
i don't want to break vlc/cedarx since at least for now it i an option, will this perhpas do that?
<hramrach>
it possibly uses ffmpeg for demuxing so you should keep the distro one alone
<hramrach>
but you can install libav someplace like /opt/libav and build mplayear and vlca agaist it and see how it works
<GeorgeIoak>
i installed then removed ffmpeg and vlc still works. are you saying not to install libav-tools?
<hramrach>
not sure you would get that very fast, though
<hramrach>
the distro libav-tools are harmless
<GeorgeIoak>
ok, i'll install them and try, is the player still called ffmpeg?
<hramrach>
but if you wanted to build a more recent libav with different (or at least known) CPU options it's better to put it someplace it does not get in the way of distro-installed programs
<hramrach>
it's called ffplay
<GeorgeIoak>
libavtools is already installed, i'll try ffplay
<hramrach>
it should provide about same peerformance as mplayer
<hramrach>
but no harm trying
<GeorgeIoak>
odd, it didn't play the video portion of a test mp4 i have that worked with vlc and i think mplayer
<GeorgeIoak>
mplayer plays it but chokes, that one is a 720P, i'll try the lower resolution one that they actually want to play
<GeorgeIoak>
avplay is maybe a little worse, i see CPU going over 90% just for avplay
<mnemoc>
expectable when not using cedarx
<GeorgeIoak>
hey mnemoc, maybe you've got some bright ideas. i have a conference call in less than 2 hours and need some kind of solution
<GeorgeIoak>
90% cpu for a 704x396 seems excessive
<mnemoc>
thought you said 720p
<mnemoc>
for 704x396.... not using neon maybe?
<hramrach>
it's a weak CPU. the VPU is there for a reason ;-)
<jelly>
720p would be like 310% cpu? :-)
<GeorgeIoak>
yes, all my initial tests were with 720P which works well with vlc/cedar but that only works full screen and last night i found out they want to run the video in a window
<hramrach>
it does not say if it uses neon or not, sadly
<GeorgeIoak>
720p with vlc/cedar runs less than 20% and is about 90% reliable
<hramrach>
should use by default if you build on neon-capable hardware
<mnemoc>
720p full screen with neon should work smoothly.... but burning all your cpu
<mnemoc>
in a window it's a different story
<GeorgeIoak>
the test app they sent me is html5 page with this 704x396 video playing in the middle of the screen with other content (menu choices)
<GeorgeIoak>
hramrach: do you have time to try and compile a version that we know uses neon?
rellla has quit [Remote host closed the connection]
<hramrach>
it will be quite useless for you if I compile it
<hramrach>
I build on the board so will take ages, and don't have the video to test, and I will have it linked with some random libraries I have
<GeorgeIoak>
do you think compiling on the board will take more than 1 hour?
<GeorgeIoak>
i've got extra boards here so i could copy my current SD card and set up another board to compile
<hramrach>
I did not try it so I cannot tell
<hramrach>
sure, might work
<GeorgeIoak>
what is your guys guess on this improving things?
<GeorgeIoak>
i need to be able to say something on the conference call
<hramrach>
dfastest is cross-compile but setting up the environment takes long
<GeorgeIoak>
i have a unbuntu VM setup that i use to compile kerne;s
<hramrach>
since the estimate is that it should run faster if you used neon it actually might
<hramrach>
yes, that's cool
<hramrach>
but you need wahtever libraries libav might use
<GeorgeIoak>
i still cannot get over why 704x396 takes almost all of the cpu, seems odd to me
<hramrach>
the armhf ones
<GeorgeIoak>
might be safer to just compile on the board?
pcat has joined #arm-netbook
<GeorgeIoak>
this site seems to have different profiles i could test now to see what impact each has on the cpu
<hramrach>
also the library you want to compile might be x264 if ffmpeg uses that
<GeorgeIoak>
are there any notes anywhere i can look at for compiling it so i know i get it right?
eebrah has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0.2/20130201065344]]
<hramrach>
hmm, x264 has no NEON options
<GeorgeIoak>
I've tried 4 different videos on this page and even the small one take 50-60% CPU????
<hramrach>
so the deal is possibly this: if you build ffmpeg without external x264 you get different codec
dyoung-away is now known as dyoung
<GeorgeIoak>
htamrach: different codec, which codec?
<hramrach>
the internal h264 codec of libav
<GeorgeIoak>
and do we know if the internal one uses or will use neon?
<hramrach>
we don't until it's tested
<hramrach>
libav has 'neon support' but may not acelerate everything
<GeorgeIoak>
and we don't know if the installed libav was compiled with neon support so i need to recompile and use whatever the "use neon" compile switch is?
sky770 has joined #arm-netbook
dyoung is now known as dyoung-away
<sky770>
Anyone saw lima's perf on quake 3?
<hramrach>
yes, that's it
* sky770
is excited as hell!
<hramrach>
1 person ;-)
<sky770>
Brilliant!
<hramrach>
but some here saw reports of the perf ;-)
<hramrach>
plus it only plays the demo
<libv>
sky770: if i had set up quake correctly, my lima driver would've had 75% of the binary drivers performance right off the bat
ln2 has joined #arm-netbook
<sky770>
Nw blobs can go suk em'selves
<libv>
that's how great the mali really is
<hramrach>
not all shaders compiled for all meshes
<sky770>
Yep
* sky770
hails libv n team *^_^*
<sky770>
Also..Congrats!
<sky770>
I really couldnt believe it when I first read abt it
<libv>
well, imagine my surprise when i had 30.5fps out of it first time round
<sky770>
You for sure are quite discrete :p
<sky770>
Yea..tht abt 5months ago?
<sky770>
@hramrach demo or noo demo..but ..
<hramrach>
yeah, looks good :)
<sky770>
you have any idea..hw big is this deal hramrach
<hramrach>
but what is needed to make use of the driver in some $random_app
<sky770>
^
<sky770>
/. Will be all over this soon :D
<hramrach>
yes, it's big
<hramrach>
but somewhat disappointed that now there is a demo the source is still not available :/
<sky770>
I suppose they were to hand it over to the community (crazy id s/w ppl :p)
<hramrach>
or is the code for runing the demo available already?
Avernos_ has joined #arm-netbook
<libv>
slashdot was all like "wtf, 2%, get out of here you lame gits."
* sky770
likes full releases :¦
Avernos has quit [Ping timeout: 248 seconds]
<libv>
sprinkle in a few "yo momma's"
Quarx has quit []
<libv>
engadget will once again ignore it
<libv>
because we have no money to pay them i guess.
<GeorgeIoak>
hramrach: any bright ideas for me?
<sky770>
Engadget..? I don't have the stats..but most ppl like us have abandoned or are rarely followimg it anymore
<hramrach>
no
<hramrach>
too little time for bright ideas
<GeorgeIoak>
crap, any ideas on who would be the best to get some ideas?
<Turl>
WarheadsSE: ping
<WarheadsSE>
Turl: pong
<Turl>
WarheadsSE: regarding earlier talk ^, is alarm ffmpeg/mplayer/etc built with neon support?
<WarheadsSE>
not by default, I think.
<WarheadsSE>
let me check the details, we hay have 2 packages (w v w/o)
<GeorgeIoak>
just got off of my conference call. they are asking me what video codec they should use to encode their videos. they'll send me tests but i need to give them some options
<traeak>
xiph foundation's codec?hehe
<techn_>
GeorgeIoak: Also.. ffmpeg/libav iterates quite quicly.. todays version could be fast enought to play your video fluidly
<techn_>
some of the linaro's packages are quite old.. like directfb
<GeorgeIoak>
techn: so maybe git the libav source and compile with --neon-enable?
rellla has joined #arm-netbook
<techn_>
I think that's worth of try
<techn_>
mnemoc: / WarheadsSE: or should we enable NFS boot on reference defconfig
<WarheadsSE>
i think thats also an option
<mnemoc>
techn_: should I hold from applying the edid parsing patch until hansg replies you?
<WarheadsSE>
but, seems like maybe it shouldnt be a defconfig though
eFfeM has joined #arm-netbook
<techn_>
mnemoc: I think you can apply that.. fix interlacing should be done in different patch :/
<techn_>
.. if it will be done
dyoung-away is now known as dyoung
soulskill has joined #arm-netbook
soulskill is now known as sky770_
sky770 has quit [Ping timeout: 260 seconds]
mdp has joined #arm-netbook
<GeorgeIoak>
could i run the webbrowser in 1 frambuffer and then try to run gstreamer or vlc on the other framebuffer which would be on top of the browser fb?
<techn_>
GeorgeIoak: you mean layers?
<GeorgeIoak>
techn:yes
<techn_>
yes you can use atleast two layers.. currently you must code that support by using /dev/disp interface
roric_ has joined #arm-netbook
<techn_>
but ssvb had xvideo driver on his backlog.. it would be same thing
<techn_>
so.. maybe you could cordinate that with ssvb :)
<GeorgeIoak>
is there a reason why vlc uses the full fb, could it be recompiled to display in a window size that is passed to it?
<andoma>
libv: ugh i found the issue. I didn't bother to bring along all the libGLES and libEGL symlinks to libMali.so to the target
<andoma>
the program links and executes just fine without it but it seems that some dlopen() or whatever inside libMali requires those to be around
<sky770_>
Later
sky770_ has quit [Quit: Bye]
<libv>
ah, i see :)
<libv>
andoma: good to know
<libv>
andoma: did you not use the makefile targets to install things?
<libv>
andoma: please do document this so that others do not run into this in future
<andoma>
no i cross compile everything
<andoma>
and copy stuff over manually
<libv>
andoma: in this case, those makefile targets are there to install things, and not to compile them :)
<andoma>
yeah, i know :) we'll i've got myself to blame
<andoma>
s/we'll/well/
<ibot>
andoma meant: yeah, i know :) well i've got myself to blame
<libv>
andoma: still, important lesson learned, one that is worth documenting
<techn_>
GeorgeIoak: where is vlc's source.. I could look
<GeorgeIoak>
techn: you mean ssvb's xvideo driver would do something similar?
<GeorgeIoak>
i was thinking if it was easiest to change the VLC/cedarx so it could run in a window and have it display on a FB on top of the other FB which is running X
<techn_>
GeorgeIoak: I think it will use layers.. but not sure.. ssvb, how did you plan to do it?
<GeorgeIoak>
i think that is one option and the other is to hope that a recompile of libav with neon will improve playback but it doesn't sound like neon will be enough
<GeorgeIoak>
at least we know vlc/cedar works well enough
<ssvb>
techn_: yes, XV should be using layers
<techn_>
GeorgeIoak: what eats cpu cycles, and cpu cycle free solution: audio(cedarx), video(cedarx), colorspace conversion(disp layer or gles2), image scaling(disp layer or gles2)
<ssvb>
techn_: but XV is a solution primarily for software video decoding, I don't know if there will be an easy way to integrate it with hw decoding on cedarx
<ssvb>
GeorgeIoak: have you tried profiling to see where exactly the time is spent?
<GeorgeIoak>
well vlc/cedarx workes well and always scales full screen. at least with my project i have control of the video coding and don't need to do any scaling
adibek has quit [Ping timeout: 245 seconds]
<GeorgeIoak>
ssvb: no, just checked cpu usage and it's almost the same cpu usage for all video sizes (within reason)
<GeorgeIoak>
ssvb: what do you use to profile?
<ssvb>
GeorgeIoak: perf
<GeorgeIoak>
is that in linux-tools?
<techn_>
GeorgeIoak: there is scaling done if your 400x200 video is played fullscreen and monitor resolution 1920x1080
<techn_>
no scaling would be 400x200 window
toxicpsion has joined #arm-netbook
<ssvb>
GeorgeIoak: yes, you can "apt-get install linux-tools" and then "perf record yourprogram" followed by "perf report"
<ssvb>
GeorgeIoak: or if perf is not found (like with my ubuntu/linaro chroot), then something like "perf_3.2.0-23 record ..." and "perf_3.2.0-23 report" may work
<GeorgeIoak>
techn_: yes, so my point was that right now the build of vlc/cedarx always scales and works so decoding and scaling. in my app the window and video size will be the same so no scaling should be needed
<GeorgeIoak>
ssvb: i'm on it
arete74_ has quit [Read error: Connection reset by peer]
<GeorgeIoak>
ssvb: a little strange. it installed perf but then says i need linux-tools-3.0.57 but that isn't found
datagutt has quit [Quit: kthxbai]
<GeorgeIoak>
perf is in /usr/bin but running it complains it can't find perf_3.0.57
<ssvb>
GeorgeIoak: just check if you also have perf_* something, in my case it was "perf_3.2.0-23"
<ssvb>
GeorgeIoak: it seemed to work
<GeorgeIoak>
yeah, you're right, perf_3.2.023 is what you need to run
<techn_>
GeorgeIoak: seems that vlc does scaling and colorspace conversion already with disp layers
<GeorgeIoak>
techn: but could it be changed to not scale
<techn_>
GeorgeIoak: but havent found yet logic that changes video window size
<ssvb>
GeorgeIoak: with the debugging symbols (apt-get install the relevant *-dbg packages) you can also see individual functions, it is important to verify that NEON is really used for software decoding
<ssvb>
GeorgeIoak: but if software decoding is not enough for your video resolutions, then tough luck and struggle with cedarx is ahead
<techn_>
mnemoc: stypid google adds some stuff to new members mails so it wont apply directly :(
<techn_>
stupid..
<techn_>
or is there way to apply those patches without hackery
<GeorgeIoak>
ssvb: uploading the perf -a report with chrom playing a small webm video
<GeorgeIoak>
should i run perf on the larger webm video or is the _armv6 what we need to fix?
<ssvb>
GeorgeIoak: and "apt-get install chromium-browser-dbg" should really help to see what is hiding inside of "29.38% chromium-browse chromium-browser [.] 0x7de282"
<GeorgeIoak>
ok, i'll do that now
<ssvb>
GeorgeIoak: armv6 means that the video decoder library is not using neon, it's a big performance problem
<hramrach>
not really if the code spends 3% in that
<ssvb>
GeorgeIoak: the offending library must be recompiled with neon enabled
<GeorgeIoak>
that explains why things suck so just need to find out how to fix that
<ssvb>
hramrach: have you seen how many "*_armv6" functions are there?
<hramrach>
even then no more than 10% time
<GeorgeIoak>
ok, i installed the dbg, i think i'll restart just to make sure chromium and everything is clean
<hramrach>
and optimizing them does not give you that much
<techn_>
hramrach: ffmpeg has more functionality accelerated when you use neon
<hramrach>
so say 30% speedup ~ 3% of total
<hramrach>
that might be another thing
<techn_>
you cant accelerate same things whith armv6
<mnemoc>
Alex1269: now it worked. thanks!
<GeorgeIoak>
ok, going to run it again, hopefully more info in this perf report
<libv>
crappity crap, either my mele is unable to properly use the ram at 480MHz, or i messed up installing uboot
* libv
digs out his serial cable
<GeorgeIoak>
when i run the report it says that i don't have symbols in /bin/dash
<libv>
good thing that i didn't try this before fosdem :)
<libv>
i have run into the exact same issue twice already over the last half a year
<Turl>
GeorgeIoak: have you considered android as an alternative?
<libv>
that's pretty bad :)
<Turl>
libv: you deleted your mmc node?
<libv>
no, i copied my own howto too directly
<GeorgeIoak>
i did but never worked in android but the time i've spent trying to get this working i could have learned. i need the lvds and touch to work too though
<libv>
and dded to /dec/mmcblkx
<Turl>
you dd'ed to ram? :p
<libv>
:)
<libv>
to devfs :)
<Turl>
libv: "zomgz this sdcard is fast!" ;)
<libv>
and i have done it before :)
<libv>
and i will do it again :)
<Turl>
yeah, that stuff happens
ln2 has joined #arm-netbook
<Turl>
GeorgeIoak: I was thinking of a simple web page with embedded html5 h264 video
<Turl>
it should work on android browser
focus_it has joined #arm-netbook
<GeorgeIoak>
me too, but it needs to be full screen so it looks like an app, not a computer/browser
<libv>
looking good, dmesg and q3a will tell whether 480MHz is stable
<GeorgeIoak>
i thought i could do that in *nix
<Turl>
GeorgeIoak: well, you could make an app with a huge web view and force it as launcher
<Turl>
libv: 480 on mali?
<Turl>
pff
<libv>
480MHz on ram
<focus_it>
Anyone got a datasheet for GT8UB256M16BP - the DDR3 chip in cubieboard?
<Turl>
libv: oh
<libv>
mali on allwinner does not clock there
ln2 has quit [Client Quit]
<Turl>
libv: yeah, that's why 'pfff' :P
<libv>
that extra third of performance would actually translate to q3a being a third faster :)
<GeorgeIoak>
how could i test touch and lvds for android, does it use the same script file? do you know if android has the touch libraries built-in already for sun4i-ts?
<Turl>
no idea if the built in android supports it or not
<Turl>
but for a quick proof of concept you should be fine
<GeorgeIoak>
let me boot up the stock android image and see how the browser reacts to that webm test page or do i need to flash a different android?
<Turl>
GeorgeIoak: not sure if it supports webm at all, use h264
<GeorgeIoak>
video format can easily be changed but right now no formats seem to work in *nix except for fs vlc/cedarx
<Turl>
you will need neon-able software on *nix if not using cedarx
<Turl>
otherwise you're pretty much guaranteed slow motion video
aesok has joined #arm-netbook
<GeorgeIoak>
OK, well a quick test on android for HTML5 video test pages works significantly better using the stock browser. i might have to pull the plug on *nix and re-invent the wheel which I'm not looking forward to
<libv>
heh, 480MHz puts us at 36.1, whereas 360MHz put us at 35.4 (at 720p)
<libv>
so yes, an improvement, but rather limited :)
<libv>
we are rather fragment shader bound :)
<libv>
it does seem stable though
<GeorgeIoak>
still would really like to get something going with neon to see how it performs or try to get vlc/cedarx to play videos in the same size as the content
<libv>
so i think i'll keep it
wingrime has quit [Ping timeout: 252 seconds]
popolon has joined #arm-netbook
<ssvb>
libv: something that typically runs at hundreds fps should see a bigger improvement from 480MHz RAM clock
<libv>
oh, yeah, definitely
<libv>
the spinning companion cube has a 30% boost in limare versus binary
<libv>
i will run that one now
<libv>
it is amazing how fragment shader heavy q3a is :)
<traeak>
cool or not cool?
revident has quit [Quit: Combustible lemons? Bah, I bring you weaponized asparagus!]
<GeorgeIoak>
Turl: I swallowed my pride and just fired off an email asking if the people creating the "content" had worked in Android. They're a big enough company that they may have which would leave me with "only" getting touch and LVDS working
<libv>
at 720p, this advantage for lima drops to just 19% :(
* libv
will now reboot with 480MHz again
<libv>
the egl version gain 7%
<libv>
the egl version gains 7% with the higher mem clock
<libv>
again, the pp is the biggest limit, it has it easier, but only a bit easier
<libv>
the limare test gains 5.6%
<libv>
17.6% advantage over opengl. our more aggressive scheduling is reducing the advantage of the extra memory bandwidth
<libv>
part of that may also be the uploading of the textures and the attributes
freakazoid0223 has joined #arm-netbook
<ZaEarl>
I should go to the Android Builders Summit.
<toxicpsion>
haven't been around enough to catch up on that one yet :P
<L84Supper>
"Full production should commence after Chinese New Year. We'll be sending out a press release along with more detail in the next couple of days."
<L84Supper>
"I finalized testing of the Chinese manufactured prepoduction units. Units are shipping next week to a few customers along with carrier boards."
popolon has quit [Quit: Quitte]
<hramrach>
it's sad the Olimex board with 2G ram seems stuck