hello,

Le 14/03/2015 10:14, Csaba Láng a écrit :

Hi Cyrille,

I guess nohow. Raspberry uses openGL ES, while the minimal dependence to GEM is openGL.

i've read somewhere that raspberry pi 2 are openGL compatible. (i'm not talking about the RPi 1)

anyhow, the error as nothing to do with openL

cheers c

Look around on the internet. I was drilling into this topic as well, but could not find a decent solution.

Cheers:

Popesz

On Sat, Mar 14, 2015 at 9:37 AM, Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> wrote:

hello,

i've receive a raspberry pi 2.
Gem is not installable via apt-get, so i'm trying to compile it.

i get the source from https://github.com/umlaeute/__Gem <https://github.com/umlaeute/Gem>

the compilation procedure fail on the 1st step :


pi@raspberrypi ~/Gem $ ./autogen.sh
PATH: /usr/local/sbin:/usr/local/__bin:/usr/sbin:/usr/bin:/sbin:/__bin:/usr/local/games:/usr/__games
AUTORECONF: /usr/bin/autoreconf
AUTOHEADER: /usr/bin/autoheader
AUTOMAKE  : /usr/bin/automake
ACLOCAL   : /usr/bin/aclocal
LIBTOOL   : /usr/bin/libtool
LIBTOOLIZE: /usr/bin/libtoolize
AUTOCONF  : /usr/bin/autoconf
running autoreconf
autoreconf: Entering directory `.'
autoreconf: configure.ac <http://configure.ac>: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac <http://configure.ac>: tracing
autoreconf: configure.ac <http://configure.ac>: adding subdirectory extra to autoreconf
autoreconf: Entering directory `extra'
autoreconf: running: aclocal --force -I ../m4
autoreconf: configure.ac <http://configure.ac>: adding subdirectory pix_artoolkit to autoreconf
autoreconf: Entering directory `pix_artoolkit'
autoreconf: running: aclocal --force -I ../../m4
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in `../../m4'.
libtoolize: copying file `../../m4/libtool.m4'
libtoolize: copying file `../../m4/ltoptions.m4'
libtoolize: copying file `../../m4/ltsugar.m4'
libtoolize: copying file `../../m4/ltversion.m4'
libtoolize: copying file `../../m4/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac <http://configure.ac> and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
autoreconf: running: /usr/bin/autoconf --force
configure:15277: error: possibly undefined macro: AC_LIB_APPENDTOVAR
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
HOST-OS    : <unknown>
HOST-KERNEL: Linux raspberrypi 3.18.9-v7+ #767 SMP PREEMPT Sat Mar 7 21:52:35 GMT 2015 armv7l GNU/Linux
HOST-#CPU  : 4


did anyone know how to solve this problem?

thanks and cheers
c

_________________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 14/03/15 20:28, Cyrille Henry wrote:

hello,

Le 14/03/2015 10:14, Csaba Láng a écrit :

...

Hi Cyrille,

I guess nohow. Raspberry uses openGL ES, while the minimal dependence to GEM is openGL.

i've read somewhere that raspberry pi 2 are openGL compatible. (i'm not talking about the RPi 1)

RPi 2 have a very similar chip, just with 4 cores instead of 1, same old issues and advantages. Apparently there is some support beyond Es, but not enough to run gem and as not at all documented.

If you are experimenting with an RPi 2 then with audio the load balancing by switching cores will add considerable latency (X-runs at latencies the RPi 1 handles fine). This is probably due to cache invalidation on a core switch, and the time required to fetch everything again if the switch occurs at an inopportune moment re buffers and deadlines. For low latency audio you will need to use linux cpu affinity to always put the main pd process on a specific core, this can also be achieved by the no-sleep flag in pd which sets pd to use busy-waiting (I believe) so run continuously and fully occupy one core. There may be advantages to either technique, no point sleeping a process if it owns the core exclusively, but running 100% may also lead to heating issues and a need to run at lower clock speeds... depending I guess on how the no-sleep is implemented.

This could prove useful if you are ready to manually split your processing between separate pd patches and script the launching to achieve the cpu affinity required. cpusets could help more, making a core (or three) dedicated exclusively to a pd process each while the remaining core(s) run anything else.

Some have said there may be heating issues without load balancing, but the devices are cheap so a shortened life probably isn't an issue, other heat problems could arise ... maybe slow down the clock speed or add a decent heat sink to the chip if you are playing with this option.

Simon

Disappointing but good on you for trying it out... hopefully an open accessible openGL capable embedded platform soon...?

On Sun, Mar 15, 2015 at 8:47 PM, Cyrille Henry ch@chnry.net wrote:

Le 15/03/2015 04:11, Simon Wise a écrit :

Apparently there is some support beyond Es, but not enough to run gem

...

and as not at all documented.

i was to much optimistic and did not double check the informations i found announcing openGL support. thanks for the clarification. cheers

c

...

If you are experimenting with an RPi 2 then with audio the load balancing by switching cores will add considerable latency (X-runs at latencies the RPi 1 handles fine). This is probably due to cache invalidation on a core switch, and the time required to fetch everything again if the switch occurs at an inopportune moment re buffers and deadlines. For low latency audio you will need to use linux cpu affinity to always put the main pd process on a specific core, this can also be achieved by the no-sleep flag in pd which sets pd to use busy-waiting (I believe) so run continuously and fully occupy one core. There may be advantages to either technique, no point sleeping a process if it owns the core exclusively, but running 100% may also lead to heating issues and a need to run at lower clock speeds... depending I guess on how the no-sleep is implemented.

This could prove useful if you are ready to manually split your processing between separate pd patches and script the launching to achieve the cpu affinity required. cpusets could help more, making a core (or three) dedicated exclusively to a pd process each while the remaining core(s) run anything else.

Some have said there may be heating issues without load balancing, but the devices are cheap so a shortened life probably isn't an issue, other heat problems could arise ... maybe slow down the clock speed or add a decent heat sink to the chip if you are playing with this option.

Simon

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

you may also be interested in Nvidia Jetson Dev Kit [1] which support OpenGL 4.4

[1] : https://developer.nvidia.com/jetson-tk1

-- do it yourself http://antoine.villeret.free.fr

2015-03-16 12:26 GMT+01:00 Simon Wise simonzwise@gmail.com:

On 16/03/15 12:09, Richie Cyngler wrote:

...

Disappointing but good on you for trying it out... hopefully an open accessible openGL capable embedded platform soon...?

openGL has moved a very long way since gem and similar were written, so has the gpu architecture that it is communicating with ... embedded platforms are looking to support quite a different approaches, and compatibility with old approaches isn't on their agenda at all.

But the small, cheap intel based platforms are easily up to running most older stuff within a more traditional architecture ... they are what you should be looking at to run pd/gem.

Simon

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list