A new Linux handheld game console based on powerful ODROID-N2+

[JohnnyonFlame]

I managed to get it working, but GE2D seems to be outputting at 20fps.

A GE2D test program is available here. It was tested on N2, but may or may not require modifications for GOU.
https://github.com/OtherCrashOverride/ge2d-test

Thank you for the reply, however the application shows the same behavior as mine, whenever you rotate the display the framerate tanks.
I've pushed my initial implementation here: https://github.com/JohnnyonFlame/SDL-ge2d it makes usage of eglCreatePixmapSurface, "egl_create_pixmap_ID_mapping" libmali internals and ION/GE2D.

[JohnnyonFlame]

We've opened ODROID-Go Ultra sub-forum for further discussions.
viewforum.php?f=219

[crashoverride]

whenever you rotate the display the framerate tanks.

This is a known behavior of GE2D and the issue the test program was created to demonstrate.

I've pushed my initial implementation here: https://github.com/JohnnyonFlame/SDL-ge2d it makes usage of eglCreatePixmapSurface, "egl_create_pixmap_ID_mapping" libmali internals and ION/GE2D.

When a GPU buffer swap happens with a pixmap target, it implicitly flushes the command queue. This causes program execution to stall until the commands are complete. This is different from when the display is the target in that the driver is able to hide the latency by processing commands in the background.

This technique of latency hiding is necessary to achieve maximum frame rate. Three pixmap targets should be created. When a swap is called, the GPU swap is issued and execution is returned to the calling program with a different pixmap target. A separate thread then issues the GE2D rotation and presentation (wait for vsync) on the completed pixmap in the background.

[JohnnyonFlame]

whenever you rotate the display the framerate tanks.

This is a known behavior of GE2D and the issue the test program was created to demonstrate.

I've pushed my initial implementation here: https://github.com/JohnnyonFlame/SDL-ge2d it makes usage of eglCreatePixmapSurface, "egl_create_pixmap_ID_mapping" libmali internals and ION/GE2D.

When a GPU buffer swap happens with a pixmap target, it implicitly flushes the command queue. This causes program execution to stall until the commands are complete. This is different from when the display is the target in that the driver is able to hide the latency by processing commands in the background.

This technique of latency hiding is necessary to achieve maximum frame rate. Three pixmap targets should be created. When a swap is called, the GPU swap is issued and execution is returned to the calling program with a different pixmap target. A separate thread then issues the GE2D rotation and presentation (wait for vsync) on the completed pixmap in the background.

If I didn't miss any obvious cache configuration bits, then I guess GE2D rotation is just too much for 1080p display. At least there's enough headroom (with triplebuf, have yet to cleanup and push) to actually hit 60fps on the OGU resolutions...

[jutleys]

Is the board identical in dimensions compared to the OGS so would the OGS case be compatible?

[crashoverride]

I guess GE2D rotation is just too much for 1080p display

During the course of development, I used multiple strategies for rotation. For ease of implementation, its simpler to use the GPU for scaling/rotation. My method for this was to create a separate GLES context and use it solely with a purpose designed shader to scale/rotate. The buffers were shared across contexts with their DMABUF file descriptor.

In the interest of completeness, I should point out that it is not necessary to issue a swap when rendering off-screen. I use a fence object to signal completion of the command stream up to that point. When the fence is triggered, rendering is complete as if a swap was issued.
https://registry.khronos.org/EGL/sdk/do ... Sync.xhtml

[JohnnyonFlame]

I guess GE2D rotation is just too much for 1080p display

During the course of development, I used multiple strategies for rotation. For ease of implementation, its simpler to use the GPU for scaling/rotation. My method for this was to create a separate GLES context and use it solely with a purpose designed shader to scale/rotate. The buffers were shared across contexts with their DMABUF file descriptor.

In the interest of completeness, I should point out that it is not necessary to issue a swap when rendering off-screen. I use a fence object to signal completion of the command stream up to that point. When the fence is triggered, rendering is complete as if a swap was issued.
https://registry.khronos.org/EGL/sdk/do ... Sync.xhtml

I pushed my changes up to this point on Github. I had not considered using a different OpenGL context for display however.

Do you plan on making your implementation open any time soon? It would be very useful to cross-reference, since you're vastly more experienced with the hardware than I am.

[crashoverride]

Do you plan on making your implementation open any time soon?

An open source "libgou" (similar API to libgo2) is currently being considered. This approach would likely make it easier for developers to see how the pipeline is driven without all the extra "noise" that a larger code base would have.

[romadu]

We've opened the WiKi page with the following contents. We will eventually improve and add the contents.
- Charging
- eMMC OS image installation
- Temporary microSD booting instead of eMMC.
- Transferring ROM files
- Compiling kernel and uboot
- Customizing boot logo
- Calibration joystick
- Factory test mode
- Others
https://wiki.odroid.com/odroid_go_ultra/odroid_go_ultra

This thread is locked and please use this ODROID-Go Ultra specific sub-forum.
viewforum.php?f=219

[rooted]

We've started selling the ODROID-Go Ultra now.

ODROID-GO ULTRA Clear White : https://www.hardkernel.com/shop/odroid- ... ear-white/
ODROID-GO ULTRA Dim Gray : https://www.hardkernel.com/shop/odroid- ... -dim-gray/

[Andyyy]