There are a lot of ARMv7L copatible chips around, runing Linux.

The point I interested in, you can place an ARM based fanles boad nearly everywhere
and the hardware has anought power to run this game fluid.  
And at all, S2 is! the best Settlers game there ever was.

Facing two problems on the PI:
The GPU's aren't well supported by the OS and the propietary firmware not well documented.
The RTTR build doesn't support ARM chips and the GPU's as well. Even if, EGL/GLES is not openGL,
the lib's are shaped to fit with graphic harware.

I playing compiling with RPI 3b and BPI M1, both in ARMv7L mode, using this:

Code:

  

Code:

Code:

# compiling 1-2 hours on one core (you only have 1GB RAM)
at all you will end up using a resolution 800x600 with 2-7 FPS on native X11 and up to 24 FPS with SDL-ovelay, if your CPU is that powerfull.
as you may recogniced, at this point all openGL stuff is emulated by the CPU, no GPU acceleration!
if you have an "optimiced" FBturbo installed, it can break the graphic output and the use of SIMD(NEON)


#links I find usefull:
/opt/vc/src/hello_pi
https://github.com/peepo/openGL-RPi-tutorial
https://pandorawiki.org/GLES
https://stackoverflow.com/questions/28375338/cube-using-single-gl-triangle-strip
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/CJAJIIGG.html
www.khronos.org/vulkan


Kind regards,
a ethusiast, not a programmer!

PS: My mind is a open wound. Don't even try to be sweet! I see this thread as my work-in-progress playground.

---

A basic intelligence, called my own.
A sea of knowledge, called the World-Wide-Web.
So you must be the luck I still miss.

How I found you? Searching for __LUCK__!

Code:

Hack around the clock is tricky, tricky-tricky!
https://github.com/Leuchtefix75

glBegin is at an end, so replace it:
You define the vertex array outside and than tell the graphic API how to tread
it.
we are at 2D(x,y), typ is GL_INT, n Byte ofset per vertice, our array
could be modifed to 3D(x,y,z) seting the deep z=0

Code:

On RPI you may think to implement the firmware like this...

Code:

...but than you realize your fail and want to return. But it fails again? Clean
you build-cache would do the trick!

Code:

how to use unmodified systems-cursor

Code:

To stop that hoping bunny, if the building quality is already visible
and half transparent...
My eyes like it that way!

Code:

some modifications to the game defaults

Code:

If you want to 'make install' to a directory, as portable version

Code:

Code:

Code:

---

Hi,

please send as a Pull-Request on github, so we can discuss your changes further.

---
mfg
Flo

---

And now for something completely different, ba-ba ba-ba, PIXMAN!

First: If you have a openGL driver that realy uses your GPU,
you don't need a software rastericer like PIXMAN. But it's nice to lear from building it.
You may have a look at http://pixman.org/ for a short explanation and aditional links.

Code:

1 GIT the first best
2 it has made a directory... cd in to it
3 make a subfolder for the build process
4 cd to it
5 start the automated environment configuration... you have to --disable-arm-iwmmxt
6 MAKE in userspace
7 replace the installed version by your own build
8 reboot you system... if it fails, use a copy of your OS, or try 'make uninstall'


OK, system start's, But what's the benefit?
Using the SIMD is like using an aditional core, specialized for 'pixel manipulation'.
If you don't use CAIRO or the X server, your system is probably not compatible with PIXMAN.

note:
.ko are kernel modules(drivers), the OS core
.so are The Other Ones, or an other Holiday

---

...next step: GALLIUM Driver
Since 2015, the RPI Foundation stoped selling media codecs, thanks to
"nasty"
EU law, so 2016
Broadcom opened the VC4 specification, which led to a working openGL kernel-
modul/graphic-driver:

https://www.golem.de/news/raspberry-pi-bastelrechner-bekommt-pixel-desktop-
1609-123537.html

Code:

Note:
When the dtoverlay=vc4-kms-v3d overlay is loaded you get cma=256M@256 added
to the kernel command line for free.
Memory allocated to the old graphics driver(gpu_mem) is wasted.
Contiguous-Memory-Allocator(if no MMU) provides virtual allocation.
The access to the real allocated memory gets solved by DMA transfer,
but can cause frame-errors if not available in time.

==== or the deprecated BCM_HOST stuff ====

Code:

Code:

void TerrainRenderer::DrawWays(const PreparedRoads& sorted_roads) const
# I stare at it with full force, so it must explain itself to me! Don't you
think?

Code:

how to implement ARM_NEON, if it's supported by the compiler

Code:

Note:
EGL is the windowing part to GLES(3D) and openVG(2D)
https://www.tutorialspoint.com/cplusplus/cpp_this_pointer.htm

---

And now for something completely different!

Yes, two years have past since I used BANANA-PI with a GUI.
Between there ran an IPFIRE(the successor of IPCOP) on it.
Have spend the day to prepare on my RPI an SD-card  with ARCH-LINUX for BANANA-PI.

Code:

ROOT rights needed
install: GCC-ARM-NONE-EABI, BSDTAR, SWIG, U-BOOT-TOOLS
GPARTED to make a new partitiontable on your /dev/sdX (X for where SD card is)
and formate one primary partition as EXT4
at host system create a dir as mount-point and mount the formated partition to transfer the
operating system image

Code:

Create a file with the following boot script
boot.cmd

Code:

Code:

To build the U-Boot bootloader:

Code:

IF you were patient, but the first start won't bring a display, you can try the reset- or power-
switch, or make a power-reset

Preset accounts are: root/root, alarm/alarm
You can change the password by passwd alarm for example

OK, now I have a headles(no GUI) disk-image ...with MESA(X11)? OK, will take the Ubuntu image, or

Code:

Will patch it with:
https://developer.arm.com/products/software/mali-drivers/utgard-kernel
...which depends on the UMP User-Space driver! Trying to build the UMP can get a mess and in
mainline it's defined as deprecated.
May find a ready to install UMP driver with a how-to?
https://gist.github.com/kashimAstro/2708a2e420900249e7ae8bc44ff3a875
https://groups.google.com/forum/#!topic/linux-sunxi/R3nOsbF37yA
https://github.com/yuq/mesa-lima

I think this is still a treasure of the Web without 3D acceleration:
ArchLinux_For_BananaPi_v1412_eldajani.img.tar.xz
https://docs.google.com/uc?id=0BxWqJEu810QVVmgweHBSQ3FSdWs&export=download

http://kivypie.mitako.eu/kivy-faq.html

If Linux gets slow on high RAM usage/load, it could be due

Code:

Note: battery connectors for bananapi M1 (BAT1 for RTC, + is USB side, - SD card side)
https://www.symcon.de/forum/threads/28021-BananaPi

---

How to replace deprecated openGL QUADS?

The only point it's hard to replace it in function, if there is a dynamic QUARD stripe like in:

Code:

an example for a replacement:
./src/ogl/glArchivItem_Bitmap_Player.cpp
./src/ogl/glSmartBitmap.cpp

Code:

...or working with indices for reuse of vertices
./src/Window.cpp

Code:

I would realy appreciate if all direct grafhic API(openGL) access would be done in the .SO file, even more in one source file,
to maintain the stuff and S25MAIN only access abstractions.

---

I don't mind replacing all deprecated OpenGL stuff. In fact I actually want to switch to custom shaders as IMO we don't need to support those damn old PCs that don't support shaders.

What I would need is something to flag all deprecated usages or stuff that would not work in OpenGLES. Is there a flag/switch/tool to do that at least on linux?

---
Github: https://github.com/Flamefire

---

It's not quit deprecated, it's just not implemented.
Probably there are tools like plugins, so you can set a switch for a dedicated environment with a dedicated version.

But let explain the motivation!
If I'm right, the openGL KMS driver for RPI seams to be symbolic linked and has some issues with pointers causing allocation errors.
But it supports all the GL stuff from the sourcecode. So on RPI it is at playable speed, but can crash on maps over 96x96.

With the default MESA openGL driver the game is compileable everywhere. But if the game runs at 3FPS you wont play it.
So on non RPI it is still interesting to use the GLESv2 libs. Another issue is the EGL context in a X11 environment.

I like this example, even I don't realy get it. Maybe it can help you too?
https://github.com/peepo/openGL-RPi-tutorial

ARMv7l and GLESv2... we get closer!

---

I know. The point is: OpenGLES is basically an OpenGL without the deprecated stuff (like Quad-drawing). The whole fixed-function-pipeline is deprecated and the shader-based stuff might even be faster and now better supported.

So thats why I want some tool to show all deprecated stuff of OGL

---
Github: https://github.com/Flamefire

---

Was für ein Veränkespiel!
Nagut, beschmutzen wir die mir auserkorene Spielwiese, die ich im wesentlichen als Gedankenstütze für meine S25 Forschungen nutze.

Da ich den Sourcecode nur modifiziere und eigentlich überhaupt nichts mit Programmierung, geschweige Programmiersprachen zu tun habe,
bin ich mit meinem Wissen gerade so weit, wie ich es hier erfasse.

Gut, ich verstehe was du gern hättest, aber weiß das ich dafür nicht unbedingt der geeignete Ansprechpartner bin.
Am zielführendsten dürfte es wohl sein, sich ein System(HW +SW) zu schaffen und dann zu beginnen zu debuggen.
Sicher gibt es auch für x86_64 basierende Systeme eine GLESv2 Umgebung zum Installieren?
Oder man verwendet einfach nur mal die Header ohne die Libs und schaut was nicht mehr definiert ist?
Ansonsten entspann dich und schau wie es sich entwickelt.

Man kann natürlich auch mit dem Bisherigen brechen und die Routinen völlig neu schreiben, mit einem neuen Konzept.
Z.B. könnten auch nicht-openGL Videomodule gebaut werden, wie für Vulkan, was für MALI multi-core interessant wäre.
Es bedeutet ja nicht das du das alles selbst machen mußt, nur die Möglichkeit in Form von Schnittstellen schaffen, mehr nicht.

Für den Moment hack ich einfach in meinen Gegebenheiten und versuche es mit GLESv2 gangbar zu machen, da der Rest soweit funktioniert.
Ich denke das mein Fork da genau das richtige Mittel ist, um es überall runterladen zu können und weiter zu bearbeiten.
Das Game zu bauen ist für mich ein Spiel bei dem ich nicht verlieren kann, solange ich ein Backup habe.

Für den Anfang wäre es erstmal wichtig in eurem GIT:
- das LUA Problem scheint behoben zu sein, Haken dran
- FATAL_ERROR "Unknown processor arch" darf nicht für native-compiling gelten
- -DRTTR_ENABLE_OPTIMIZATIONS=OFF als Default,
  oder nochmal einen Filter vor FORCE_ADD_FLAGS setzen:
  IF(("${PLATFORM_ARCH}" STREQUAL "x86_64") OR ("${PLATFORM_ARCH}" STREQUAL "i386"))
- Hinweis: openGL driver besorgen, z.B. unter Linux über MESA, um das Game überhaupt erstmal laufen zu sehen

...
  Man kann sich wohl statt dem auch GLES2-MESA besorgen und dann mit den proprietären Binaries ersetzen?

---

Das Processor arch und die flags werde ich noch machen. Das dauert aber etwas, da ich das gleich richtig machen will.

Ich hoffe ja, dass wir bald C++11 und SDL2 bekommen. Das dürfte auch OpenGLES einfacher machen.

---
Github: https://github.com/Flamefire

---

Wenn du weißt wie "gleich richtig" geht? Ich bin immer noch am These aufstellen und gegenprüfen.

Aber -march=armv7-a und compiler arm-none-eabi sollte schon mal einen cross-build ermöglichen.
NONE bedeutet wohl nicht für einen Speziellen CPU-Chip und -EABI steht für bare-matel, während nur -ABI ein OS voraussetzt.  
openGL kann ja für den Build erstmal bleiben und sollte sogar auf dem RPI mit KMS driver spielfähig sein.
Bei GLES wird man wohl, außer das er GLESv2 benutzen soll, standard openGL disablen,
als auch den Pfad für die Lib's und die Pfade für die Header explizit angeben müssen.
Ich steck nur nicht so weit in Linux, um die Systemkonfiguration gleich anzupassen.

SDL2 kann wohl GLESv2 benutzen, was nicht bedeutet das es das mitbringt, sondern das du immer noch die GLES Header und die Lib's brauchst, um etwas zu compilieren?
Und dann siehst du was geht und was nicht.

Das mistige sind immer die leicht geänderten Namen für letztendlich die gleichen Werte.
Und ich seh bei dem Includen in einer bestimmten Reihenfolge, bzw. beim Kaskadieren von Headern nicht recht durch.
Wann mach ich besser einen extra Header für Header, wann bind ich sie direkt im C/C++-file ein?

Da du mich nun schon mal in meinem Streben aufhälst, wie kann ich eigentlich den FPS-counter auf die linke Ecke bringen und die anderen counter verschwinden lassen?

note:
https://wiki.libsdl.org/MigrationGuide

---

__APPLE__ geht schon etwas in die richtige Richtung, bis auf das wirklich APPLE spezifische.

Ich spiel mit MESA_GLES2 in oglIncludes.h bisschen rum.

Code:

Versuche PFNGL* auszuklammern und _ARB/ARB durch "" zu ersetzen.

How to get This to that?

Code:

Code:

Note:
SDL2 & ES2
https://gist.github.com/SuperV1234/5c5ad838fe5fe1bf54f9

SDL using ANGLE, which simulates ES2 using Direct3D 9
https://discourse.libsdl.org/t/opengl-es2-support-on-windows/20177

noch mehr openGL demos
http://voidptr.io/blog/2016/04/28/ldEngine-Part-1.html

https://open.gl/drawing

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawArrays.xhtml

Cheat: winter

Code:

Code:

I like the funny pictures ...
https://en.wikipedia.org/wiki/Mesa_(computer_graphics)

---

I started working on that too. First step to support this would be using a newer OpenGL version and the Core profile. But we have to decide, what to support at the minimum. OpenGL 2.x is required for shaders, OpenGL 3.x to disallow glBegin & friends completely and have some more goodies.

See https://github.com/Return-To-The-Roots/s25client/pull/848

---
Github: https://github.com/Flamefire

---

https://www.raspberrypi.org/documentation/configuration/config-txt/

VC4 runs well with parameters
# cmdline.txt: cma=128M
config.txt:
hdmi_force_hotplug=1
gpu_mem=32 #16MB is the minimum but causes problems
avoid_warnings=2
dtoverlay=vc4-kms-v3d,cma-224
#dtoverlay=vc4-fkms-v3d,cma-128
...
and without xorg.conf
gpu_mem -native frame Buffer, no more used if KMS gets activated at boot
CMA -needed for kms driver, uses the MMU to transfer memory blocks by DMA
looks like a good idea to let some space of the first 256MB for CPU (memory-split / not GPU_MEM or CMA )
RAM issues can appear if 4/5 of RAM is used, because of memory fragmentation (google MMU REALLOC)

the RPI KMS driver is basiclly a MESA and so a openGL driver, Wayland uses MESA as backend
so there probably never be a /usr/lib/arm-linux-gnueabihf/dri/vc4_drv_video.so

Code:

glad/CMakeLists.txt

Code:

https://github.com/Dav1dde/glad

build mesa your own

Code:

usually you got 2.4.74 and libdrm >= 2.4.75 is required

Code:

https://linux-sunxi.org/Mali400#Utgard

hint for crosscopiling:
The following are valid -mcpu values with --target=aarch64-arm-none-eabi:
cortex-a53
cortex-a57
The following are valid -mcpu values with --target=armv8a-arm-none-eabi:
cortex-a53
cortex-a57
The following are valid -mcpu values with --target=armv7a-arm-none-eabi:
cortex-a5
cortex-a7
cortex-a8
cortex-a9
cortex-a12
cortex-a15
cortex-a17

unknown type name 'Display'
/usr/include/EGL/eglplatform.h

Code:

autoconf
autoreconf -i

Code:

"If you created any destroy many hundreds/thousands of lists many thousand times, the function may fail at some point, since there is a guarantee that all generated identifiers are contiguous. This is the same symptom as with heap fragmentation -- memory allocation can fail even though there is plenty of memory left."

https://www.reddit.com/r/C_Programming/comments/45wf43/getting_keyboard_input_on_linux/
https://www.microcontrollertips.com/using-input-devices-on-embedded-linux-usb-mouse-on-intel-edison/
https://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html
https://stackoverflow.com/questions/20943322/accessing-keys-from-linux-input-device


====some more half-wisdom====
ARMv7 is specifyed to have a MMU.

The GPU uses its MMU for memory copy.
The GPU can also access the CPU-RAM by it, even if it is an external graphic card.
The interesting point is to do no memory copy if both share the same RAM, zero-copy.
Therefore it has to be clear who of both "processors" allocates and free the buffer and how to avoid multiple access to it at the same time?
Another point is, if CPU and GPU(MMU) do different endianes, the memory address must be translated.
UMP handle these two points, so zero-copy is supported. But UMP is marked as deprecated, even if all MALI devices will still use it, also in future.
CMA might use the MMU. But it looks more like it only uses DMA.
However, there would be no need of a fixed graphic memory, if both processors can utilize the whole RAM and one memory driver for all.

In openGL you create or load something in client/userspace and let it copy by GL-command to GPU-API space, so no further processing by CPU would be possible.
And then you erase what you created.

If there is no fixed Framebuffer, means every application gets its own render buffer and the GPU filter it by layer-number/deep-buffer in realtime,
you don't move were an application window in the frame buffer is drawn, you move the place it is visible without the lag of drawing.
That is close to no work for the CPU.
If video playback has its own layer, you use two or more render buffer and zero-copy is enabled,
you just have to tell the GPU which one is visible for that layer, and meanwhile another one gets drawn/rendered.

WAYLAND is on that way.
But its X11 wrapper is very slow and most applications still depend on X11.

---

https://reddit.com/r/raspberry_pi/comments/ailmgj/raspberry_piopenclgpu_vc4cl_videocore_iv_opencl/

Just came here to link this interesting development regarding Raspberry Pi GPU. Don’t know if it really helps or not (GL vs.
CL?) but I really hope to be able to play this awesome game on Pi some day :)

---

Back To The Roots, Back To Reality!

it's an old... sourcecode
CMakeLists.txt

Code:

external/libsiedler2/CMakeLists.txt #if TEST is enabled

Code:

my OS is RASPBIAN(NOOBS3.0/ARMv7) on a RPi3

Code:

GLAD is to provide an dedicated GL environment... old sourcecode, old GL

Code:

I don't care for crap of others!
cmake/Modules/ConstrainedOption.cmake

Code:

What is it for? For INTEL? I don't have, I don't care!

Code:

don't know why LUA is still an issue
cmake-qt-gui

Code:

/home/pi/s25client/CMakeLists.txt

Code:

and the lovely old message ... maybe, one day

Code:

GLES don't work. But we can

Code:

to use EGL

just to know...

Code:

maps over 100 still crashes by memory issues
lower maps work, but slightly unstable and at that risk
setting mfpu=neon to make higher maps start

Code:

but memory access issue appear on quit after all on quit? who cares
...
Upgrade to Raspbian Buster: no UNALIGNED_ACCESS, no error? or the new compiler?... all maps playable and stable now


...some hackage

Code:

Trace/Breakpoint (Received a SIGTRAP)
=> RTTR_Assert_Enabled = 0

---

...you need something to get something more!

http://www.codesourcery.com
ulimit -s 32768

http://linuxfromscratch.org/lfs/view/development/chapter06/gcc.html

Code:

dpkg-buildpackage -G -us -ui -uc

https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/

Code:

dont want to maintain a thing, just want to have, but...
https://www.debian.org/doc/manuals/maint-guide/
or short version
https://ubuntuforums.org/showthread.php?t=910717

https://developer.arm.com/tools-and-software/open-source-software/developer-
tools/gnu-
toolchain/gnu-a/downloads

https://www.boost.org/users/download/

https://cmake.org/download/

https://solarianprogrammer.com/2017/12/08/raspberry-pi-raspbian-install-gcc-compile-
cpp-17-
programs/

https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to-prepare-debian-packages/
=====
wget http://ftp.snt.utwente.nl/pub/software/gnu/binutils/binutils-2.29.tar.xz                                                              
wget ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-7.2.0/gcc-7.2.0.tar.xz                                                            
wget http://ftp.gnu.org/gnu/glibc/glibc-2.26.tar.xz                  
tar xvf binutils-2.29.tar.xz      
tar xvf gcc-7.2.0.tar.xz          
cd binutils-2.29                  
./configure --target=armv7l-unknown-linux-gnueabihf --disable-multilib
make                          
sudo make install                  
cd ..                              
scp drone:headers.tar.gz .        
cd /usr/local/armv7l-unknown-linux-gnueabihf                          
sudo tar xzvf $OLDPWD/headers.tar.gz                                  
cd -                              
cd gcc-7.2.0                      
./contrib/download_prerequisites  
mkd ../gcc-build                  
../gcc-7.2.0/configure --enable-languages=c,c++,lto --enable-shared --enable-
threads=posix --
with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --
enable-
clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --
enable-linker-
build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-
style=gnu --
enable-gnu-indirect-function --disable-multilib --disable-werror --enable-
checking=release --
target=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a --with-float=hard --with-
fpu=vfpv3-d16                              
make all-gcc                  
sudo make install-gcc              
cd ..                              
tar xvf glibc-2.26.tar.xz          
mkd glibc-build                    
../glibc-2.26/configure --prefix=/usr/local/armv7l-unknown-linux-gnueabihf --
build=$MACHTYPE --
host=armv7l-unknown-linux-gnueabihf --target=armv7l-unknown-linux-gnueabihf --with-
headers=/usr/local/armv7l-unknown-linux-gnueabihf/include --disable-multilib
libc_cv_forced_unwind=yes
make # This fails, but it does succeed buildling the parts we need now.                                                                
sudo make install-bootstrap-headers=yes install-headers                                                                                    
sudo install csu/crt1.o csu/crti.o csu/crtn.o /usr/local/armv7l-unknown-linux-
gnueabihf/lib/                                                
sudo touch /usr/local/armv7l-unknown-linux-gnueabihf/include/gnu/stubs.h                                                                    
sudo /usr/local/bin/armv7l-unknown-linux-gnueabihf-gcc -nostdlib -nostartfiles -
shared -x c
/dev/null -o /usr/local/armv7l-unknown-linux-gnueabihf/lib/libc.so                                                                                                                          
cd ../gcc-build                                                                                                                            
make all-target-libgcc                                                                                                                  
sudo make install-target-libgcc                                                                                                            
cd ../glibc-build                                                                                                                          
make                                                                                                                                    
sudo make install                                                                                                                          
cd ../gcc-build                                                                                                                            
make                                                                                                                                    
sudo make install
====

SDL2 + DRM needs LIBGDM-dev!

new strategy: build a toolchain, build boost, build cmake, build game
I would prefer to do the last!

if fail...
make distclean

DEB Debian packaging
build-essential
devscripts
debhelper

export LD_LIBRARY_PATH="$LOCAL/lib"
export PKG_CONFIG_PATH="$LOCAL/lib/pkgconfig:$LOCAL/share/pkgconfig"
export CFLAGS="-I/usr/include/arm-linux-gnueabihf"     # for the C compiler
export CXXFLAGS="-I/usr/include/arm-linux-gnueabihf/sys"   # for the C++ compiler
export LDFLAGS="-L$LOCAL/lib"        # for the linker

I have no idea, but it sounds like something to care for

Code:

dEQP failures on llvmpipe
GALLIVM_DEBUG=no_rho_approx,no_bilinear,no_quad_lod

VALKYRIE(GUI for Valgrind)
VALGRIND utilize MEMCHECK and mockup MALLOC by vg_replace_malloc.c to produce a more
detailed
output
And keep in mind: MALLOC don't produce the ERROR, it detects it!

Doubly/double linked list example

Code:

just to have fun
https://forum.unity.com/threads/why-wasnt-timeline-named-compositor.536102/

https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
RPI3b(bcm2835) has 2 MMU's(Memory Management Unit - block/frame wise RAM access by DMA)
...MMU for CPU<=>RAM
...SMMU(IOMMU) for IO<=>RAM

activating the GL(Full KMS) by raspi-config allocates 256MB CMA(Contiguous memory allocation)
CMA is designed for system without MMU, so reallocation may be not possible

I wonder what's the differnce of the deprecated UMP(Universal Memory Provider) which is still needed for MALI drivers on Banana PI?
export CFLAGS="-mcpu=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits"
--with-arch=armv6 --with-fpu=vfp --with-float=hard

https://www.andreasch.com/2018/05/08/rpi3-kernel-aarch64/

Code:

Code:

"Vomiting is not Projectile" bug

---

I did it... no, I don't... but was so close!

stdarg.h file not found ?
=======================

prerequirements:
libmpc-dev bison
-


1)download the source
wget XYZ-1.2.tar.xz

2)unpack it
tar xvf XYZ-1.2.tar.xz

3)step into the subfolder
cd XYZ_1.2

dh_make -f ../XYZ-1.2.tar.xz =>i=>Y=>y

4) do a subfolder in there
mkdir debian

5) some simple text only files into this subfolter
dch -i --create

changelog
compat
control
copyright
rules

6) do or change some entries (if you offer you work to others, you should be
serious)
#changelog
XYZ (1.2.3) unstable; urgency=medium

  * Initial release.

#compat => debhelper-Kompatibilitätsstufe
9

#control
Source: XYZ  
Maintainer: pi <pi@raspberrypi>
Build-Depends:
Standards-Version: 1.2.3
Section: utils

Package: XYZ  
Priority: extra  
Architecture: any
Depends:  
Description: XYZ 1.2.3
Just prints "Hi", it's very useful.

#copyright
Copyright 2019, GNU GENERAL PUBLIC LICENSE

#rules
#!/usr/bin/make -f  
%:  
    dh $@

7) from the source path build this pice of deb
debuild -us -uc

8) step out the souce folder, and there it should be, ready to install to your
system
XYZ-1.2.3_armhf.deb
XYZ-dbgsym_1.2.3_armhf.deb

==========================

cat >>~/.bashrc <<EOF
DEBEMAIL="person@company.tld"
DEBFULLNAME="Testy McTester"
export DEBEMAIL DEBFULLNAME
EOF
. ~/.bashrc

==========================
# http://www.linuxfromscratch.org/blfs/view/cvs/general/gcc.html
#Recommended:  Tcl, Expect and DejaGnu
wget https://ftpmirror.gnu.org/gcc/gcc-9.1.0/gcc-9.1.0.tar.gz
tar xf gcc-9.1.0.tar.gz
cd gcc-9.1.0
contrib/download_prerequisites

auto-apt run ./configure DFLAGS="-O3 -march=native""
make
sudo checkinstall
...or...
dpkg-buildpackage -b
--------------------------
sudo apt-get install --reinstall build-essential
sudo apt-get install --reinstall gcc
sudo dpkg-reconfigure build-essential
sudo dpkg-reconfigure gcc

==========================
git clone https://github.com/giuliomoro/checkinstall
cd checkinstall
make install
==========================
#https://cmake.org/download/
#download the sourcecode file
tar xvf cmake-3.14.4.tar.gz
cd cmake-3.14.4
mkdir cmake-3.14.4
cd cmake-3.14.4
auto-apt run ../bootstrap   --qt-gui #depends on qtbase5-dev
make
sudo checkinstall
# install the *.DEB from filemanager or package-manager
cmd# cmake-gui

---

I did it by Raspbian/buster.
It was still marked as unstable... but as stable now
And as usual, a distribution upgrade can break some serious parts. Backup before!

SYNAPTIC is still a nice tool for DEBIAN package management
If using SYNAPTIC for the first time, you should disable

Code:

Code:

https://phoenixnap.com/kb/how-to-upgrade-debian-9-stretch-to-debian-10-buster

Code:

...package source is selected, prepare your system...

Code:

Now you can update packages as you need, one by one (LIBC6 is the best first step)
or upgrade the whole installation

Code:

However, now you can install/upgrade the build tools needed for actual S25.

#Der Download wird als root und nicht Sandbox-geschützt durchgeführt
sudo rm -f /var/cache/apt/archives/partial/*
sudo chown _apt:root /var/cache/apt/archives/partial/

Zurückgehaltene Pakete - broken packages

Code:

if still getting same error then try

Code:

after removing package update your system and restart once.

Note:
firefox60+ -Video streaming is broken
so...

Code:

or use an older Version!
you can copy the .DEB file to /var/cache/apt/archives and then install it from your package-manager

Code:

...but this version needs pulseaudio!
firefox dependencies are all close to a must-be
sudo apt-cache depends firefox-esr
...
https://packages.debian.org/sid/armhf/firefox

pulseaudio -serious issues with ALSA backend -looks like a political issue, like both want to get, what the other already is
-the audio device you want to use in Pulseaudio must not be selected as default in the PI-mixer(ALSA)

---

compiling with GLES2.0 -> undefined reference to:

Code:

OES is the "vendor"-code for the OpenGL ES working group
ARB -code for desktop-OpenGL

The basic idea is:
-you define an array in CPU-RAM, give the graphix API the poiter(start address of the
array) and the size of the array
-the API/GPU read it by DMA into GPU-RAM and use it as described
-the target should be to avoid to much of this copy action and reuse what the GPU-RAM
already has... but to poiter this out is exctly the problem


Note: generating GLAD use GLES2.0 version 3.1 (GLES3/GL31.h)
but at all GLES2.0 has no fixed shader, so your program provides the source code for a shader and a texture compiler,
which are compiled and uploaded to GPU at runtime.
It's close to SIMD, if it not already share the same registers.

---

Code:

still looking for a good example of std::thread or boost::thread


Spatial Tutorial - General Matrix Multiply (GeMM) like SIMD(MMX/SSE/NEON)/openCL/GLM
https://champyen.blogspot.com/2018/12/spatial-tutorial-general-matrix.html

https://en.wikibooks.org/wiki/GLSL_Programming/Vector_and_Matrix_Operations

---