buzzmarshall has quit [Quit: Konversation terminated!]
jfsimon1981 has joined #beagle
Shadyman has quit [Quit: Leaving.]
Archana has joined #beagle
set_ has quit [Ping timeout: 246 seconds]
florian has joined #beagle
Midjak has joined #beagle
buzzmarshall has joined #beagle
akaWolf has quit [Ping timeout: 248 seconds]
akaWolf has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981_b has joined #beagle
jfsimon1981 has quit [Read error: Connection reset by peer]
Archana has quit [Remote host closed the connection]
CrazyEddy has quit [Ping timeout: 256 seconds]
CrazyEddy has joined #beagle
florian has quit [Quit: Ex-Chat]
<jfsimon1981_b>
zmatt, where does the bi-quad filter code come from which you pasted bin ?
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Shadyman has joined #beagle
m-atoms has joined #beagle
m-atoms has quit [Ping timeout: 246 seconds]
m-atoms has joined #beagle
lucascastro has quit [Ping timeout: 240 seconds]
vvn has quit [Quit: WeeChat 3.5]
m-atoms has quit [Ping timeout: 256 seconds]
m-atoms has joined #beagle
<zmatt>
jfsimon1981_b: ehh, I just wrote it for the occasion? like, I'm not sure what you mean, the biquad filter itself is literally just a single expression (y0 = b0 x0 + b1 x1 + b2 x2 - a1 y1 - a2 y2)
<zmatt>
more symmetrically, a biquad solves the equation a0 y0 + a1 y1 + a2 y2 = b0 x0 + b1 x1 + b2 x2 for y0 (the current output sample)
<zmatt>
the point of that doc was just to show how trivial a biquad is, and to give the actual coefficients for the biquads used by the load cell mattb0ne uses (based on the documentation of that load cell)
<jfsimon1981_b>
where was the code you pasted from, is this an open source project or one of yours ?
<jfsimon1981_b>
Seems interesting
<zmatt>
20:17 <@zmatt> jfsimon1981_b: ehh, I just wrote it for the occasion
<jfsimon1981_b>
This peace of C code ?
<jfsimon1981_b>
including coeficients so on ...
<zmatt>
20:55 <@zmatt> the point of that doc was just to show how trivial a biquad is, and to give the actual coefficients for the biquads used by the load cell mattb0ne uses (based on the documentation of that load cell)
<zmatt>
I computed the coefficients from the filter specs (2nd order butterworth with given cutoff frequencies, with a 1200 Hz sample rate)
<jfsimon1981_b>
ok
<zmatt>
it's not meant to be interesting code, it's trivial code written very verbosely for illustration purposes
<jfsimon1981_b>
maybe or you, I have more difficulties in C than C++
<jfsimon1981_b>
though you're right now i get a closer look
<jfsimon1981_b>
By any chance do you know how we can accelerate 2D on the beagleboard black ? I understood the SGX530 if for 3D accele only
<jfsimon1981_b>
Though i understood QT applications can use it somehow, i'm unsure about this
<zmatt>
accelerate 2d in what way?
<jfsimon1981_b>
For instance when displaying a videos with mplayer, or animating sprites with SFML, this loads the cpu quite a lot
<jfsimon1981_b>
and can't get smooth in full res.
<jfsimon1981_b>
I'll have to investigate this topic. I might have future projects related to graphic things with the BB
<zmatt>
reduce resolution or use more efficient code
<jfsimon1981_b>
At the moment had to lower resolution so things work well.
<jfsimon1981_b>
But I had 3D code running with opengles a while ago, that was much better
<zmatt>
video decoding is generally very cpu-heavy... some devices have hardware acceleration for decoding and/or encoding video using specific codecs, the AM335x does not
<zmatt>
you're describing very very different things
<jfsimon1981_b>
I think that's about openglES, unlike opengl, which most applications can use for 2D stuff. Not ES.
<zmatt>
video decoding performance will depends on how well-tuned the code is to the Cortex-A8 + NEON
<jfsimon1981_b>
I mean drawing, that's slow and apparently draws the cpu a lot
<jfsimon1981_b>
i think
<zmatt>
if "animating sprites" is slow then the code is probably just shit
<jfsimon1981_b>
oh
<zmatt>
since there's not really much to compute there, it's just copy-pasting bits
<jfsimon1981_b>
Well maybe, i used SFML, compiled on the beagle and used it straight away
<jfsimon1981_b>
have to check what's Neon
<zmatt>
then SFML is probably just very cpu-heavy, and no form of acceleration will help with that
<zmatt>
or maybe they're just doing something that happens to cause a huge negative performance impact
<jfsimon1981_b>
indeed it loads the cpu
<jfsimon1981_b>
drawing takes time
<zmatt>
I mean, obviously it does, but... I meant more like overhead than actual drawing
<zmatt>
but who knows, I don't know what it does or why it might be slow
<zmatt>
like, "drawing" is too vague a term anyway
<jfsimon1981_b>
i mean a lot of time, full screen full res it can be about 10 fps or so, maybe less
<zmatt>
doing what?
<jfsimon1981_b>
the draw function
<zmatt>
doing what?
<jfsimon1981_b>
that updates a full screen with a new image for example,
<jfsimon1981_b>
drawing
<jfsimon1981_b>
draw function
<zmatt>
again, "drawing" is very non-specific, what do you mean by that?
<jfsimon1981_b>
you draw the background, move a sprite, then draw it, draw all shapes, then display them, every loop
<zmatt>
don't repeat the same vagueness, clarify what you mean. obviously the performance of "drawing" onto screen is entirely dependent on what kind of drawing operations you're doing and how they are implemented
<zmatt>
also, what's your screen resolution?
<jfsimon1981_b>
It's just a textures box
<jfsimon1981_b>
i tried full res so 1280x80
<jfsimon1981_b>
i tried full res so 1280x800
<jfsimon1981_b>
that did'nt work well, as i mentionned it just loaded too much the cpu. On a computer, sfml goes through the graphic cardfor doing all 2D stuff (obviously), but not on the bb
<zmatt>
I'm not sure how the graphics card would help much for drawing... I guess for scaling with anti-aliasing, or transparency?
<zmatt>
what API does it use?
<jfsimon1981_b>
Just drawing pixels which goes from VRAM to the back buffer, that's pretty fast
<zmatt>
I guess the GPU could in theory blit pixels faster than the CPU, dunno by how much...
<zmatt>
anyway, I can't really offer much insight into the performance of a library I don't know performing unspecified operations
<jfsimon1981_b>
it's just moving sprites and wraing them, like running a counter
<zmatt>
for blitting the main bottleneck will be RAM, and how it's being accessed.... e.g. if code makes the mistake of reading from a framebuffer (which is uncached) then performance will immediately tank
<zmatt>
yes I know, and literally just told you 4 minutes ago
m-atoms has joined #beagle
<zmatt>
it'll use a software-implementation of OpenGL
<jfsimon1981_b>
ah
<jfsimon1981_b>
yes i see
<jfsimon1981_b>
maybe i'll have to check how to compile it differently or try a new library to get better performances
<zmatt>
the GPU driver supports OpenGL ES and OpenGL ES 2, and does not support X11 (only Wayland or running applications directly on the framebuffer)
<zmatt>
it looks to me like SFML has a hard dependency on OpenGL
<jfsimon1981_b>
indeed it seems unlogical to have poor perf, with a 1Ghz proc that's plenty
<jfsimon1981_b>
yep i think it has to go through it, though i can check further
zjason` has quit [Read error: Connection reset by peer]
<jfsimon1981_b>
they have a support forum, i'll post on it
zjason`` has joined #beagle
<zmatt>
it's not that fast, and clock frequency isn't the only performance indicator
<jfsimon1981_b>
too bad i love sfml, it's so simple to use
<zmatt>
the AM335x is not designed for heavy graphics, it's designed for industrial applications
<zmatt>
I think the main reason they included a (very basic) 3d gpu is because they apparently wanted to support Android for touchscreen interfaces, which apparently requires a gpu
<jfsimon1981_b>
I had 4 digits of 64x40 to animate that means draw them all and draw a 200x100 texture, each frame, and that got much too slow that it flickered at about 10~15 fps, so the cpu's not at fault, i think that 's the soft implementaton of GL, you raised it that probably why.
<jfsimon1981_b>
Not asking a lot with this simple animation.
<jfsimon1981_b>
Ah
<zmatt>
yes and no, you're not asking a lot but the way it's done probably asking a lot
<jfsimon1981_b>
anyway
<zmatt>
so you're also using X11 here?
<jfsimon1981_b>
i think so yes
<jfsimon1981_b>
what do you mean
<jfsimon1981_b>
I run though (forgot it)
<zmatt>
I guess it's a stupid question since SFML depends on it
<jfsimon1981_b>
LXDE was too heavy, I moved to XFCE
<jfsimon1981_b>
yes i run X, i installed the lightweight manager
<zmatt>
flickering is a problem there because the fbdev video driver can't do double-buffering and the modesetting video driver apparently causes the lcdc kernel driver to crash for some reason
<jfsimon1981_b>
what's fbdev2
<jfsimon1981_b>
there are both
<zmatt>
?
<jfsimon1981_b>
i was playing with mplayer and it proposed fbdev and fbdev2
<jfsimon1981_b>
though only the 2nd works
<zmatt>
must be some mplayer-specific thing
<jfsimon1981_b>
yes i'm animating a counted with 4 digits and playing fun stuff videos, so i had to work with a video player and a graphic lib
<zmatt>
documentation just says it's an "alternative implementation" ... with no explanation of why mplayer has two different fbdev video output implementations or when you might want to use which
<zmatt>
sounds like the beaglebone is not a great match to your application
<jfsimon1981_b>
maybe
<jfsimon1981_b>
but i'd like to get those things work with OpenGL ES, that's way to go
<zmatt>
ES or ES 2 ? (they're _very_ different APIs)
<zmatt>
I don't see how either of those would help you here though
<jfsimon1981_b>
the only difficulty is then to program the graphic stuff. Working with gles is more complex than just animating with sfml 2d.
<jfsimon1981_b>
Gles probably to begin with
<jfsimon1981_b>
i saw discussions about players using the SGX card, on raspberry
<zmatt>
honestly unless you're doing 3d rendering I'm not how it would help
<jfsimon1981_b>
i think there can be special purpose players optimized for this hardware, did'nt investigate yet
<zmatt>
I definitely don't see how it would help with video
<jfsimon1981_b>
no for animating stuff
<jfsimon1981_b>
well if you look straight it's almost 2d
<zmatt>
yes I know you *can* use opengl for 2d, but I'm not sure it would actually be faster here
<jfsimon1981_b>
I animated aircraft's instruments on a beagle with gles years ago and that worked well, though it's all done in 3d with gles, really this looks flat and therefore it's kind of 2d
<jfsimon1981_b>
that's what i need nowadays as well,
m-atoms has quit [Ping timeout: 248 seconds]
m-atoms has joined #beagle
<zmatt>
I mean, you do you I guess, but that doesn't sound particularly simple and is almost certainly also not very efficient... basic 2d stuff may very well be faster on the cpu (when the code doesn't suck) than the gpu when taking into account all the overhead involved with talking to the gpu.... but i'll depend on the details I guess
<jfsimon1981_b>
that's right
<jfsimon1981_b>
i meant it's really fun to me working with opengles and eventually going a bit artistic, also it would unload the cpu
<jfsimon1981_b>
i'm maybe lost indeed, but i need a good library for 2d stuff which i have'nt found yet
<jfsimon1981_b>
i had sfml but i'll probably loose it for something else, for the emnbedded due to this GL issue. I don't think it can be turned around, i think sfml is kind overlay for opengl
<zmatt>
yes my impression is also that it's entirely built around opengl
<jfsimon1981_b>
i'm trying to remember a few ones, maybe just try qt anyway
<jfsimon1981_b>
if that can work for bb
<jfsimon1981_b>
yes it's entirely built upon it i think
<jfsimon1981_b>
also the fact SGX is a UK company and i like them, but there are other ways quite sure, that will perform good
m-atoms has quit [Ping timeout: 256 seconds]
vagrantc has joined #beagle
<jfsimon1981_b>
i'll give a try on Qt, i find it too complex though
<zmatt>
qt5 can definitely run directly on the framebuffer... there's also directfb (or rather, directfb2) and things that use it
<jfsimon1981_b>
but maybe because i did'nt get into it much
<jfsimon1981_b>
yes that's what i see
<jfsimon1981_b>
though it surely need x server to be running
<zmatt>
no
<jfsimon1981_b>
ah
<jfsimon1981_b>
interesting
<zmatt>
like, the whole point of directfb is that it's for using directly on the fb... hence the name :P
<jfsimon1981_b>
ok
<jfsimon1981_b>
that's simpler than i though
<jfsimon1981_b>
i'll get on that pretty soon
<zmatt>
and it has a drm/kms backend, so you're not stuck with the old linux fbdev backend
<zmatt>
hence double-buffering will also be supported
<jfsimon1981_b>
ok
<zmatt>
(so no flickering)
<jfsimon1981_b>
yes i had that issue too
<jfsimon1981_b>
i kind of dealt with it but it's not good code and solutions i found at the moment.
<zmatt>
not sure where one is supposed to find its documentation though :P the directfb2 page just appears to be a long readme
<jfsimon1981_b>
fbdev has'nt a backbuffer right
<zmatt>
yeah the old fbdev interface supports neither double-buffering nor changing the video mode (resolution / framerate)
<zmatt>
(on the am335x anyway)
<jfsimon1981_b>
all right
<zmatt>
basically, when the video output is enabled the kernel will pick a video mode and then create a single framebuffer for use by fbdev, and it'll display that framebuffer by default if no application is using drm
<jfsimon1981_b>
ok
<zmatt>
while with drm framebuffers are explicitly allocated by userspace, and you can then perform a "page flip" which changes the active framebuffer (either immediately, which may cause tearing, or on the next vsync to avoid tearing)
<jfsimon1981_b>
i'll implement the qt5 application see how that goes, eventually play a bit with the drivers the
<zmatt>
with recent versions of qt5 the "linuxfb" platform plugin also supports drm/kms, but I don't remember if it'll use it by default or if this requires explicit config
<jfsimon1981_b>
ok
<jfsimon1981_b>
do you use qt5
<zmatt>
I haven't done any GUI stuff on the bbb for many many years, but back then we used qt5 yes.... my job was just to get it working though, I didn't do any actual qt5 programming
<jfsimon1981_b>
ok
<jfsimon1981_b>
do you remind we discussed the pwm stuff back few weeks, that's this same project ; it's for Prowein in Germany
<zmatt>
I don't remember no
<zmatt>
I talk about many things with many people :P
<jfsimon1981_b>
they collect corks in wood hand held bags, and that hardware is detecting them, counting and animating a small panel 10 inch, with the count number and fancy video
<jfsimon1981_b>
that's this whole project though i got involved in doing a bit more, like power supply, Ui so on