Pages: [1]
  Print  
Author Topic: Existential questions about OA on raspberry Pi 2 (and 3)  (Read 6660 times)
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« on: April 16, 2017, 12:00:11 pm »

So, I tried OA on my rPi 2. Installed it from Raspbian repository, got *software* rendering at 1 frame per second @ 640x480.

And then I got mightily confused: yes, OA can be built for Raspbian, and can obviously start. BUT did anyone ever made a port using hardware acceleration?

While rPi 2 *does* have hardware acceleration (Minecraft Pi is the only way to prove it, runs at passable FPS @ 1920x1080), the hardware video drivers from Broadcom do *not* support OpenGL, only GLES 2. Meaning you'll never get hardware acceleration and glBegin working together.

Does OA even have a GLES-only port?
Or can SDL emulate immediate mode functions on GLES as I described in that other thread?

I am currently trying to make my engine start up on Pi. What I learned so far (and wasn't that painful) is that that's no ordinary GLES2 either.
First, loading the DLLs by name gives you mesa ones that do not work. To get hardware acceleration you have to use ones tucked away @ /opt/vc/lib
Second, the normal initialization method doesn't work either. You have to load a crapload of proprietary API functions from libbcm_host.so and then dance through hoops to create a hardware surface overlayed on top of normal screen (a bit like some video players did @ WinXP, creating a hardware surface in YUV format or stuff because CPUs were too slow to convert on the fly)
Weeell, and that required converting a shitload of headers to Pascal. Which was tedious.
Now I am intimidated  Sad, going to port a sample code from C and see if the method works.

P.S. Real Jedi do not use SDL, nope  Cool.
Logged

Imma lazy dreamer. I achieved nothing.
fromhell
Administrator
GET A LIFE!
**********

Cakes 32
Posts: 14490



WWW
« Reply #1 on: April 16, 2017, 03:28:22 pm »

The GLES ports won't fix the performance issue either.

sudo raspi-config, advanced, enable GL.   OA should then run at a stunning 10-30fps -  the kind of performance that makes someone want to reboot the project  topsy

Yes I wish there was a better way.. and it's a little hilarous having OA in the raspbian repo, i mean that's the default OS for a schoolkid-targeted computer and they even have the mature pak on the repo  Huh
« Last Edit: April 16, 2017, 03:34:22 pm by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #2 on: April 17, 2017, 12:33:43 am »

Quote
sudo raspi-config,
"Driver and kernel not present on your system, please update"
Ugh Lips Sealed
Will research into it later.

Quote
and they even have the mature pak on the repo
Cheesy

Quote
OA should then run at a stunning 10-30fps
Then that "driver" is *crap*.
Minecraft Pi runs smoothly (and I mean deathmatch-worthy smoothly) even if I enlarge its window to be almost fullscreen (which is fullHD). And it does have *lots* of polygons (being Minecraft and all).

I am currently researching furter and I see many, ahem, "implementations" where eglSwapBuffers() is emulated by using glReadPixels, then converting that shit into a X bitmap, then pasting that bitmap into to an X window.
Logged

Imma lazy dreamer. I achieved nothing.
fromhell
Administrator
GET A LIFE!
**********

Cakes 32
Posts: 14490



WWW
« Reply #3 on: April 17, 2017, 10:05:15 pm »

You might be onto something

FWIW you can't VNC Minecraft Pi and Retroarch through but you can vnc the gl games through the GL desktop drivers (which Minecraft Pi and Retroarch doesn't work in)..


I think supporting Pi properly would mean tearing apart a bit of the SDL backend used in the engine
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #4 on: April 19, 2017, 04:46:40 am »

..meanwhile,
Quote

The classic twitch shooter from industry pioneer id Software, Quake III Arena is heavily tied to the CPU performance of the Pi. The standard ‘timedemo’ was run at 1280×1024, high geometric, maximum texture detail, 32-bit texture quality, and trilinear filtering to obtain these results.
Where did they get this?  Sad
Logged

Imma lazy dreamer. I achieved nothing.
pelya
Member


Cakes 6
Posts: 395


WWW
« Reply #5 on: April 19, 2017, 12:46:53 pm »

There is a GLES1 port of OpenArena, namely, Android version. Does RasPI support GLES1?
I've tried to make GLES2 renderer some time ago, failed miserably of course, because I did not understand shaders at that point of time, and it's too much work all in all, but it at least compiles with GLES2 headers.

@fromhell since we're talking about renderers, here's a silly video of Quake 1 renderer with 360° FOV, hope it's not old news.
Logged
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #6 on: April 19, 2017, 03:02:42 pm »

Quote
Does RasPI support GLES1?
When I forgot to pass
EGLint contextAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE, EGL_NONE };
to eglCreateContext(), I got GLES 1.1 and the following attempt to compile GLSL crashed. punched

So, judging by that and by headers provided (one folder for GLES, one for GLES2), I think that YES, it does.

Quote
I did not understand shaders at that point of time,
I do not understand them that well...  shifty, but... so much potential! Kiss
« Last Edit: April 19, 2017, 03:05:30 pm by cheb » Logged

Imma lazy dreamer. I achieved nothing.
fromhell
Administrator
GET A LIFE!
**********

Cakes 32
Posts: 14490



WWW
« Reply #7 on: April 19, 2017, 11:17:17 pm »

I was able to compile and try out a GLES Q3 port made for the Pi once (a fairly outdated one) and the performance isn't anywhere better than running with the gl desktop driver sadly. On top of that, it still ran in software rendering on the legacy (default) desktop driver

See also this bug:
https://github.com/OpenArena/engine/issues/22

@fromhell since we're talking about renderers, here's a silly video of Quake 1 renderer with 360° FOV, hope it's not old news.
The concept's been explored before with Fisheye Quake way back in 1999
« Last Edit: April 19, 2017, 11:19:51 pm by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #8 on: April 20, 2017, 12:18:57 am »

For now, the vital quirk (at least in Raspbian) is that you *have* to load DLLs *specifically* from /opt/vc/lib , otherwise you get software. If SDL can be told "load DLLs from that path" then it's doable.
If not...  Blam!  punched Say hello to software rendering.

There is a reason I made my engine configurable, down to (OS model + bitness), which DLLs and from which paths to load (sometimes with a list of variants to try until one works - as with OpenAL and Microsoft xinput)  Lips Sealed

Quote
and the performance isn't anywhere better
Which Pi ?
2 has vastly better performance than the first models
And 3 has so much performance it makes CPU radiator obligatory
« Last Edit: April 20, 2017, 12:23:43 am by cheb » Logged

Imma lazy dreamer. I achieved nothing.
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #9 on: April 20, 2017, 12:47:14 am »

Quote
tearing apart a bit of the SDL backend used in the engine
Or worse, making a custom build of SDL itself Sad

So, I delved deeper.

Foul hackery abound. You have to shadow your X11 window with a hardware accelerated window managed by kernel drivers directly. And update its position when the X window moves Sad So far I was only able to get a sheer white rectangle overlapping all windows of the display (including my focused X window), but at least that foul window trickery works.

There is one EGL function that takes native window as an argument:

EGLAPI EGLSurface EGLAPIENTRY eglCreateWindowSurface(EGLDisplay dpy, EGLConfig config,              EGLNativeWindowType win,  const EGLint *attrib_list);
             
normally it's an opaque handle with user program needing no knowledge of its actual implementation:

typedef struct android_native_window_t* EGLNativeWindowType;

Even more pronounced in Pascal:

var eglCreateWindowSurface : function(dpy:EGLDisplay; config:EGLConfig; win:EGLNativeWindowType; attrib_list: pEGLint):EGLSurface; cdecl = nil;

type EGLNativeWindowType = TWindow;

type TWindow = TXID;

type TXID = culong;

type {$if defined(cpu64) and not(defined(win64) and defined(cpux86_64))}culong = qword;{$else}culong = cardinal;{$endif}

But!
The hack is to feed the innocent function a concooted fake.

After porting from dozens of disjointed C examples it comes to this:
Code:
type
  DISPMANX_ELEMENT_HANDLE_T = uint32_t;
  EGL_DISPMANX_WINDOW_T = record
    element: DISPMANX_ELEMENT_HANDLE_T;
    width, height: cint;
  end;
...
  f_nativewindow: EGL_DISPMANX_WINDOW_T; //a class field, actually
...
  f_nativewindow.element:= dx_dispman_element; //Broadcom yog-sothothery
  f_nativewindow.width:= myrect.width;
  f_nativewindow.height:= myrect.height;
...
  eSurface:= eglCreateWindowSurface(eDisplay, eConfig, ptruint(@f_nativewindow), nil);


Try making SDL jump through *that* loop Sad
Logged

Imma lazy dreamer. I achieved nothing.
fromhell
Administrator
GET A LIFE!
**********

Cakes 32
Posts: 14490



WWW
« Reply #10 on: April 20, 2017, 02:18:05 pm »

For now, the vital quirk (at least in Raspbian) is that you *have* to load DLLs *specifically* from /opt/vc/lib , otherwise you get software. If SDL can be told "load DLLs from that path" then it's doable.
SDL does have a function for loading OpenGL from somewhere else, it's just not implemented (the evil "unified sdl" commit regressed this feature)
See also this bug:
https://github.com/OpenArena/engine/issues/14
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #11 on: April 22, 2017, 06:02:35 am »

More of "Cheb's adventures in the land of ARM coding".

I had *wonderful* time investigating mysterious AVs at float division of two int32_t 's
This drank oh so much of my blood  grouch
Until I had a hunch to print out the actual adresses of the struct members.
These were 76B952D6h, 76B952B6h.
Aha, I thought.
I then added
Code:
{$ifdef cpuarm}
  {$packrecords 4}// analog of #pragma pack(4)
{$endif}
to my main header and replaced all
Code:
packed record ... // the same effect as #pragma pack(1) has on structs
with
Code:
{$ifndef cpuarm}packed{$endif} record
- lo and behold, it *worked* Embarrassed

So, these female dogs (the GLES libraries) are messing with fpu flags or their ARM equivalent, making unaligned float operations throw AVs  Lips Sealed
Why oh god why  grouch
Logged

Imma lazy dreamer. I achieved nothing.
pelya
Member


Cakes 6
Posts: 395


WWW
« Reply #12 on: April 22, 2017, 07:05:36 am »

Mysterious crashes that should never happen

Welcome to the embedded development  Cheesy
Logged
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #13 on: June 11, 2017, 11:31:11 pm »

IT LIVES!  Tongue



Who da badass? Cheb da badass!  Cool

LOL, the hardware surface overlaps the mouse pointer as well.  Cheesy
Oops, you can only make it show on screenshots by using a physical camera. Huh
Frak, some shit driver spams console with "glGetError 0x500" slowing it to a crawl  mad Cannot see the actual FPS.

P.S. Everything I posted before holds true, it started working as soon as I managed to tame GLES2 in general using ANGLE on Windows (who coulda thought the w component of the position should not be set to 0 ?  Embarrassed )

Eeeeeeee  Kiss Smiley  Cool
Logged

Imma lazy dreamer. I achieved nothing.
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #14 on: June 14, 2017, 12:09:16 pm »

A bit of useful lore:

when creating that surface, thou shall not pass null as the alpha descriptor.

you should
Code:
VC_DISPMANX_ALPHA_T         dispman_alpha;
dispman_alpha.flags = DISPMANX_FLAGS_ALPHA_FIXED_ALL_PIXELS;
dispman_alpha.opacity = 0xFF;
dispman_alpha.mask = NULL;
dispman_element = vc_dispmanx_element_add( dispman_update, dispman_display,
0/*layer*/, &dst_rect, 0/*src*/, &src_rect, DISPMANX_PROTECTION_NONE,
&dispman_alpha, (DISPMANX_CLAMP_T *)NULL, (DISPMANX_TRANSFORM_T)0 );

Should you fail to do that - and the driver will start using any alpha you write to BLEND your surface with underlying windows. No matter which blending mode you use, the alpha will end in the framebuffer and make it partly transparent. In my case I got mouse pointer and moving windows visible through halos around the letters of my text (rendered by using bitmap font against solid background).

MinecraftPi has this shit happening to its menu bar and crosshair.
You may think big deal, my X11 window is black anyway, but then your alphaed areas get blended with black, ruining your image if these areas were white.
Logged

Imma lazy dreamer. I achieved nothing.
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #15 on: June 17, 2017, 02:33:28 am »

One more bit of useful lore:
The hardware surface supports hardware scaling! It's 100% free!

I ran into glitches at window sizes approaching fullHD, like garbled memory flickering, so I limited the surface I use to 1380x768 - which looked ugly, part of the window blank. Now I can simply stretch it.

Undocumented, bro!  mad My thanks to the dudes who figured it out! Cool
Logged

Imma lazy dreamer. I achieved nothing.
fromhell
Administrator
GET A LIFE!
**********

Cakes 32
Posts: 14490



WWW
« Reply #16 on: September 09, 2017, 09:46:24 pm »

How's it working after Stretch?
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #17 on: September 22, 2017, 11:24:52 am »

Uhh... I just heard of it from you...?

Will report later, when I install and test it. Seems like time to unpack my RPi3 finally came Cheesy
Logged

Imma lazy dreamer. I achieved nothing.
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #18 on: September 23, 2017, 10:07:04 am »

* Assembled RPi3 in a nice transparent case gluing a tiny fan to the HDMI connector so that the CPU is always fresh, connected to 5V pins of that 40 pin connector that resembles IDE connectors of old.
* Installed Stretch.
* Installed Lazarus.
* Found they upgraded Free Pascal from the fossilized 2.6.4 to 3.0.0. Cussed up a storm (the road to hell is paved with dev team efforts to streamline string processing and improve Delphi compatibility -- the worst Unicode migration I ever saw). mad
* Spent fun half hour trying to figure why assembling fails, then trying various command line options until one worked. With RPi2 & Jessie & fpc 2.6.4 the working combination was -O3 -CaEABIHF -CpARMV7 -CfVFPV3 . With RPi3 & Stretch & fpc 3.0.0 it's -O3 -CaEABIHF -CpARMV7R . AFAIK, you have to find one that matches the pre-compiled RTL. Why oh why haven't I let this to "default"
* Spent two fun hours trying to build and adapting my sources to 3.0's changed string handling.

Tl:DR: It works!  punched
They renamed the DLLs to libbrcmGLESv2.so and libbrcmEGL.so and specifying the path is not necessary anymore. Other than that? Everything is the same (as that Russian saying goes, "the same eggs but side-on"). Even MinecraftPi shows the same effect when I try moving other windows over its window (the 3d viewport stays on top but some areas are see-through).

I resolved the duplicity by changing my INI section to this:
Code:
[ostRaspbian]
try-program-dir-first=1
GLES_path_0=/opt/vc/lib/
EGL_dll_0=libEGL.so
EGL_dll_1=libbrcmEGL.so
GLES_dll_0=libGLESv2.so
GLES_dll_1=libbrcmGLESv2.so
« Last Edit: September 23, 2017, 10:10:35 am by cheb » Logged

Imma lazy dreamer. I achieved nothing.
cheb
Lesser Nub


Cakes 2
Posts: 120



WWW
« Reply #19 on: September 28, 2017, 02:49:07 am »

I just counted all the places where glBegin is used in OA.
There are only 16 instances in the entire sources and half of them are for rendering textured quads.

So it should be - in theory - quite simple to port OA to GLES (either 1.0 or 2.0) if not that SDL problem you mentioned before.

I found a great way to write and debug GLES2 compliant render on Windows by leeching the required DLLs from Firefox (Google's implementation which is a wrapper for DirectX 9). Then, after ironing out all bugs in the friendly environment of a beefy machine that compiles fast, you only have to build once on the target platform.

For example, it takes 12 seconds to build my project on my laptop and about 5 minutes on RPi 3 (cross-compilation? Is that edible?  Kiss ).
If you think that's suspiciously slow for Pascal, you're right. Most of that time is devoured by my custom lineinfo extractor, strip and upx. Plus the job is done twice, one regular executable and one debugging with assertions and range checks on.
Logged

Imma lazy dreamer. I achieved nothing.
pelya
Member


Cakes 6
Posts: 395


WWW
« Reply #20 on: September 29, 2017, 02:31:29 pm »

If you wamt GLES1 pprt of OA, take a look at Android version, it compiles for PC with GLES libs: https://sourceforge.net/projects/libsdl-android/files/OpenArena/
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 32
Posts: 14490



WWW
« Reply #21 on: October 01, 2017, 05:04:38 am »

I've tried that one and unfortunately VC4's GLES1 driver is pretty useless as far as I could test
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Pages: [1]
  Print  
 
Jump to: