cheb
Lesser Nub
Cakes 3
Posts: 127
|
|
« 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 , going to port a sample code from C and see if the method works. P.S. Real Jedi do not use SDL, nope .
|
|
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
fromhell
|
|
« 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 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
|
|
« 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 3
Posts: 127
|
|
« Reply #2 on: April 17, 2017, 12:33:43 AM » |
|
sudo raspi-config, "Driver and kernel not present on your system, please update" Ugh Will research into it later. and they even have the mature pak on the repo 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
|
|
« 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 3
Posts: 127
|
|
« Reply #4 on: April 19, 2017, 04:46:40 AM » |
|
..meanwhile, 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?
|
|
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
pelya
Member
Cakes 6
Posts: 399
|
|
« 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 3
Posts: 127
|
|
« Reply #6 on: April 19, 2017, 03:02:42 PM » |
|
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. So, judging by that and by headers provided (one folder for GLES, one for GLES2), I think that YES, it does. I did not understand shaders at that point of time, I do not understand them that well... , but... so much potential!
|
|
« Last Edit: April 19, 2017, 03:05:30 PM by cheb »
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
fromhell
|
|
« 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/22The 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 3
Posts: 127
|
|
« 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! 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) 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 3
Posts: 127
|
|
« Reply #9 on: April 20, 2017, 12:47:14 AM » |
|
tearing apart a bit of the SDL backend used in the engine Or worse, making a custom build of SDL itself 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 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: 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
|
|
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
fromhell
|
|
« 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 3
Posts: 127
|
|
« 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 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 {$ifdef cpuarm} {$packrecords 4}// analog of #pragma pack(4) {$endif} to my main header and replaced all packed record ... // the same effect as #pragma pack(1) has on structs with {$ifndef cpuarm}packed{$endif} record - lo and behold, it *worked* So, these female dogs (the GLES libraries) are messing with fpu flags or their ARM equivalent, making unaligned float operations throw AVs Why oh god why
|
|
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
pelya
Member
Cakes 6
Posts: 399
|
|
« Reply #12 on: April 22, 2017, 07:05:36 AM » |
|
Mysterious crashes that should never happen
Welcome to the embedded development
|
|
|
Logged
|
|
|
|
cheb
Lesser Nub
Cakes 3
Posts: 127
|
|
« Reply #13 on: June 11, 2017, 11:31:11 PM » |
|
IT LIVES! Who da badass? Cheb da badass! LOL, the hardware surface overlaps the mouse pointer as well. Oops, you can only make it show on screenshots by using a physical camera. Frak, some shit driver spams console with "glGetError 0x500" slowing it to a crawl 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 ? ) Eeeeeeee
|
|
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
cheb
Lesser Nub
Cakes 3
Posts: 127
|
|
« 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 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 3
Posts: 127
|
|
« 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! My thanks to the dudes who figured it out!
|
|
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
fromhell
|
|
« 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 3
Posts: 127
|
|
« 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
|
|
|
Logged
|
Imma lazy dreamer. I achieved nothing.
|
|
|
cheb
Lesser Nub
Cakes 3
Posts: 127
|
|
« 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). * 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! 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: [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 3
Posts: 127
|
|
« 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? ). 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.
|
|
|
|
fromhell
|
|
« 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
|
|
|
|