X11 Hardware Acceleration (EXA)

Test and fix the Kernel 4.14 features

Moderators: mdrjr, odroid

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Sat Apr 08, 2017 4:44 pm

memeka wrote:So we can all agree this issue is in the *binary* driver, NOT kernel.

Also, we're using the same binaries for Kernel 3.10 and under Kernel 3.10 this issue is NOT present.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Sun Apr 09, 2017 6:10 am

crashoverride wrote:FYI, I noticed the mouse cursor flashes when over dynamic content.

The following patch enables the hardware mouse cursor:
https://github.com/OtherCrashOverride/xf86-video-armsoc/commit/ab8678043b84b42b8bc0d0e6dbd5d7f874e22098
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Sun Apr 09, 2017 9:47 pm

crashoverride wrote:The following patch enables the hardware mouse cursor:
https://github.com/OtherCrashOverride/xf86-video-armsoc/commit/ab8678043b84b42b8bc0d0e6dbd5d7f874e22098

Nice one.. Thanks :)
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Mon Apr 10, 2017 12:29 am

crashoverride wrote:Of particular interest is that when playing a video with VLC, the colors are wrong over HDMI. Despite this, the colors displayed over a VNC session are correct. So the HDMI displays one thing at the same time that VNC (Vino server) displays another.

To help isolate the issue, I disabled the EXA acceleration and ran my dmabuf test program with Alpha=0 as noted in another thread. The color issue is still present even with software blitting. This should eliminate the EXA acceleration from the problem set (confirmed acceleration disabled by low 22 FPS).

I also re-confirmed that while the HDMI displays incorrect colors, VNC does not. This is strange because VNC draws from the same framebuffer as HDMI and the blit appears to be correct. This could mean its an issue with the Exynos Mixer and its interaction with "alpha" in the framebuffer.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Mon Apr 10, 2017 12:54 am

Based on the Exynos Mixer theory, I further modified the test program. Using a RGBA8888 surface, I set the shader to output zero (0) for alpha. This resulted in the same color issue as using RGBA8880. This supports the theory that its a Mixer issue. To reproduce:
https://github.com/OtherCrashOverride/m ... rt.cpp#L74
Change:
Code: Select all
  gl_FragColor = rgba;\n \

To:
Code: Select all
  gl_FragColor = vec4(rgba.rgb, 0);\n \


[edit]
The expected result is that the Mixer treats the X11 desktop as a RGBX surface. Alpha should be completely ignored.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Mon Apr 10, 2017 2:34 am

I have create a work-around for the alpha issue. This should allow VLC and any other program creating RGB24 GLES surface to display correctly:
https://github.com/OtherCrashOverride/linux-hardkernel/commit/f602b09e52343de5f4aeb98b5359c85175c572d4

Note that this patch does not address the missing RGB565 formats.

[edit]
For anyone testing this patch, please provide feedback. If it does not have side effects/issues then I will make a pull request for it.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Mon Apr 10, 2017 5:25 am

crashoverride wrote:To help isolate the issue, I disabled the EXA acceleration and ran my dmabuf test program with Alpha=0 as noted in another thread. The color issue is still present even with software blitting. This should eliminate the EXA acceleration from the problem set (confirmed acceleration disabled by low 22 FPS).

That was already known.
The issue was reported quite some time before you started your EXA acceleration and before G2D was activated.

crashoverride wrote:I have create a work-around for the alpha issue. This should allow VLC and any other program creating RGB24 GLES surface to display correctly:
https://github.com/OtherCrashOverride/linux-hardkernel/commit/f602b09e52343de5f4aeb98b5359c85175c572d4

Note that this patch does not address the missing RGB565 formats.

[edit]
For anyone testing this patch, please provide feedback. If it does not have side effects/issues then I will make a pull request for it.

Gonna try building a new Kernel with this patch and will report back, I'm especially interested in retroarch, as it always tries to make a RGB565 surface (but I'm not sure if it really does).
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Tue Apr 11, 2017 5:58 am

Tested your changes.. both hardware mouse and color fix seem to work ok.. although I can cause the system to crash the desktop under different circumstances.. sadly I don't know if this happened before as well.
I also had a vsync issue once, where retroarch was running in 30 instead of 60 FPS.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby odroid » Tue Apr 11, 2017 9:47 am

Yes. the VSYNC/FPS in full screen mode is different.
glmark2-es2 --fullscreen --annotate showed ~120fps on kernel 3.10
But it shows ~60fps on kernel 4.9
It seems to be a critical issue in kernel 4.9 why the great OGST can't use kernel 4.9 LTS yet. :(
User avatar
odroid
Site Admin
 
Posts: 24590
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Tue Apr 11, 2017 10:45 pm

odroid wrote:Yes. the VSYNC/FPS in full screen mode is different.
glmark2-es2 --fullscreen --annotate showed ~120fps on kernel 3.10
But it shows ~60fps on kernel 4.9

If you add odroid to the video group even on 3.10er Kernel you have 60 FPS.
My latest image uses exactly that and glmak2-es --fullscreen --annotate shows 59~60 FPS with Kernel 3.10..
odroid wrote:It seems to be a critical issue in kernel 4.9 why the great OGST can't use kernel 4.9 LTS yet. :(

Nope, that issn't an issue. The biggest issue up to now was, that the colors were completely messed up. You couldn't play any games if everything is just blue and red.
Also there was terrible tearing, much worse than on 3.10 Kernel.
With the latest patches from crashoverride it looks almost usable. Color is back to normal, but I'm not sure about the tearing just yet.
Also the ramdom crashes of the Desktop and the false vsync with 30 FPS need more investigation.
Aside from that it seems the Hardware info of the CPU still says "Samung Exynos (flattened device tree)" or something similar instead of "ODROID-XU3".
This breaks several scripts and hardware detections.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Wed Apr 12, 2017 12:47 am

odroid wrote:Yes. the VSYNC/FPS in full screen mode is different.
glmark2-es2 --fullscreen --annotate showed ~120fps on kernel 3.10
But it shows ~60fps on kernel 4.9

There is an old thread somewhere I commented on this. I recall that the old kernel 3.10+armsoc caused a "double flip". The actual flip is limited to vsync (60Hz), the double flip made it appear to be 120Hz.

The source of this behavior is that there are two (2) code paths in the armsoc driver. For normal windows, the contents are "blit" (copied) to the framebuffer. For the special case where a window is fullscreen, the actual framebuffer pointer is changed instead (zero-copy). A side effect of this is that the DRM driver waits for vsync before changing the framebuffer pointer (flip). This is the reason glmark2-es runs at 200+ fps in a window but only 60fps when fullscreen.

meveric wrote:The false vsync with 30 FPS need more investigation.

If a program and/or Mali driver calls FBIO_WAITFORVSYNC *and* the application is fullscreen, there is a race condition that will result in either 60fps or 30fps. This is because the DRM driver waits for vsync and the userspace program also waits for vsync. Depending on the interval between when the kernel does it and the userspace program does it, there may be two (2) waits.

The workaround for this issue appears to be to disable the "flip" in armsoc. This causes both window and fullscreen applications to use the same code path for display (copy). The G2D acceleration mitigates the impact of this operation as its now done in hardware. It does, however, still consume extra memory bandwidth.

The armsoc driver has an option to set "NoFlip" mode in xorg.conf. I could not get it to work, though. Therefore, I create a "vsync" branch in my github and forced the option:
https://github.com/OtherCrashOverride/xf86-video-armsoc/commit/b3c4d23b2dde6915bb9fbe7ad234c21909e78386
Code: Select all
$ cat /var/log/Xorg.0.log | grep "Flip"     
[164794.597] (II) ARMSOC(0): Buffer Flipping is Disabled


With the behavior now identical for window and fullscreen, it should be possible to delegate vsync control to Mali. Mali should be updated to call "drmWaitVBlank" dependent on the settings of "eglSwapInterval". Existing programs should be audited for use of FBIO_WAITFORVSYNC and any occurrences removed.

Until the Mali driver is updated, using the "NoFlip" option combined with FBIO_WAITFORVSYNC (with "odroid" user a member of "video" group) should produce the expected results.

[edit]
Armsoc with "NoFlip":
Code: Select all
$ glmark2-es2 --fullscreen
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1 v1.r14p0-01rel0.c2c829708a6ea349bc7a9dc1068c92e8
=======================================================
[build] use-vbo=false: FPS: 197 FrameTime: 5.076 ms
[build] use-vbo=true: FPS: 206 FrameTime: 4.854 ms
[texture] texture-filter=nearest: FPS: 228 FrameTime: 4.386 ms
[texture] texture-filter=linear: FPS: 222 FrameTime: 4.505 ms
[texture] texture-filter=mipmap: FPS: 222 FrameTime: 4.505 ms
[shading] shading=gouraud: FPS: 182 FrameTime: 5.495 ms
[shading] shading=blinn-phong-inf: FPS: 199 FrameTime: 5.025 ms
[shading] shading=phong: FPS: 109 FrameTime: 9.174 ms
[shading] shading=cel: FPS: 109 FrameTime: 9.174 ms
[bump] bump-render=high-poly: FPS: 168 FrameTime: 5.952 ms
[bump] bump-render=normals: FPS: 188 FrameTime: 5.319 ms
[bump] bump-render=height: FPS: 192 FrameTime: 5.208 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 155 FrameTime: 6.452 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 65 FrameTime: 15.385 ms
[pulsar] light=false:quads=5:texture=false: FPS: 207 FrameTime: 4.831 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 63 FrameTime: 15.873 ms
[desktop] effect=shadow:windows=4: FPS: 149 FrameTime: 6.711 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 35 FrameTime: 28.571 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 36 FrameTime: 27.778 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 35 FrameTime: 28.571 ms
[ideas] speed=duration: FPS: 133 FrameTime: 7.519 ms
[jellyfish] <default>: FPS: 146 FrameTime: 6.849 ms
[terrain] <default>: FPS: 19 FrameTime: 52.632 ms
[shadow] <default>: FPS: 104 FrameTime: 9.615 ms
[refract] <default>: FPS: 50 FrameTime: 20.000 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 224 FrameTime: 4.464 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 181 FrameTime: 5.525 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 196 FrameTime: 5.102 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 205 FrameTime: 4.878 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 159 FrameTime: 6.289 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 208 FrameTime: 4.808 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 207 FrameTime: 4.831 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 180 FrameTime: 5.556 ms
=======================================================
                                  glmark2 Score: 150
=======================================================
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Wed Apr 12, 2017 2:29 am

An example of an issue with the current Mali X11 driver:
During eglSwapBuffers, the following IOCTLs are called (viewed from strace):
Code: Select all
ioctl(10, FBIOGET_VSCREENINFO, 0xbef84360) = 0
ioctl(10, FBIOPAN_DISPLAY, 0xbef84360)  = -1 EBUSY (Device or resource busy)

If the FBIOPAN_DISPLAY were to succeed, it would result in visual corruption. There is no reason the Mali X11 driver should ever pan the display. This is the responsibility of the X server. Armsoc will never pan the display since it uses the DRM interface which can assign arbitrary buffers as the current framebuffer (no longer a single, contiguous buffer). All the FBIO* ioctls are no longer applicable because we do not use /dev/fb* on XU4. Access is now done with the DRM IOCTLs using /dev/dri/card0 and associated nodes.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Wed Apr 12, 2017 3:08 am

I added a vsync test to my "mali_test" repo. It demonstrates how to call drmWaitVBlank. It also shows that currently, we have tearing (using above "NoFlip").
https://github.com/OtherCrashOverride/mali_test/blob/master/test_vsync.cpp

In the future, drmWaitVBlank should never need to be called by a program. Instead, Mali should call this as needed based on the eglSwapInterval settings.

[edit]
Updated the code to call glFinish(). This corrects the tearing that was present.
(Note that eglSwapBuffers implies glFinish.)

[edit2]
The point of this is that Mali should incorporate the drmWaitVBlank code into eglSwapBuffers(). It should sync the GPU (glFinish) and then call drmWaitVBlank as many times as specified by eglSwapInterval. Finally, it should submit the buffer to the X11 DRI2.

[edit3]
and then call drmWaitVBlank as many times as specified by eglSwapInterval.

A better way to state it is that ".sequence =" should be set to the eglSwapInterval value when calling drmWaitVBlank. This value is number of vsync the DRM should block for.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby odroid » Wed Apr 19, 2017 10:18 am

Thank you for making the test program.
We will try it.
User avatar
odroid
Site Admin
 
Posts: 24590
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: X11 Hardware Acceleration (EXA)

Unread postby Brian.K » Wed Apr 19, 2017 3:46 pm

crashoverride wrote:I added a vsync test to my "mali_test" repo. It demonstrates how to call drmWaitVBlank. It also shows that currently, we have tearing (using above "NoFlip").
https://github.com/OtherCrashOverride/mali_test/blob/master/test_vsync.cpp

In the future, drmWaitVBlank should never need to be called by a program. Instead, Mali should call this as needed based on the eglSwapInterval settings.

[edit]
Updated the code to call glFinish(). This corrects the tearing that was present.
(Note that eglSwapBuffers implies glFinish.)

[edit2]
The point of this is that Mali should incorporate the drmWaitVBlank code into eglSwapBuffers(). It should sync the GPU (glFinish) and then call drmWaitVBlank as many times as specified by eglSwapInterval. Finally, it should submit the buffer to the X11 DRI2.

[edit3]
and then call drmWaitVBlank as many times as specified by eglSwapInterval.

A better way to state it is that ".sequence =" should be set to the eglSwapInterval value when calling drmWaitVBlank. This value is number of vsync the DRM should block for.

Thank you for the test program. I tried that program and glmark2-es2 with "NoFlip" option.
Code: Select all
odroid@odroid:~$ diff -u /etc/X11/xorg.conf.d/exynos.conf.orig /etc/X11/xorg.conf.d/exynos.conf
--- /etc/X11/xorg.conf.d/exynos.conf.orig       2017-04-19 02:53:01.745026232 +0000
+++ /etc/X11/xorg.conf.d/exynos.conf    2017-04-19 02:52:18.469867173 +0000
@@ -10,6 +10,7 @@
#      Option          "Fimg2DExaCopy"         "false"
#      Option          "Fimg2DExaComposite"    "false"
        Option          "SWcursorLCD"           "false"
+       Option          "NoFlip"                "true"
EndSection

Section "Screen"
odroid@odroid:~$ sudo /etc/init.d/lightdm restart                                                   
Restarting lightdm (via systemctl): lightdm.service.
odroid@odroid:~$ cat /var/log/Xorg.0.log | grep "Flip"   
[  1083.844] (**) ARMSOC(0): Option "NoFlip" "true"
[  1083.844] (II) ARMSOC(0): Buffer Flipping is Disabled


Code: Select all
odroid@odroid:~$ export DISPLAY=:0
odroid@odroid:~$ glmark2-es2 --fullscreen
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1 v1.r14p0-01rel0.c2c829708a6ea349bc7a9dc1068c92e8
=======================================================
[build] use-vbo=false: FPS: 143 FrameTime: 6.993 ms
[build] use-vbo=true: FPS: 177 FrameTime: 5.650 ms
[texture] texture-filter=nearest: FPS: 182 FrameTime: 5.495 ms
[texture] texture-filter=linear: FPS: 180 FrameTime: 5.556 ms
[texture] texture-filter=mipmap: FPS: 183 FrameTime: 5.464 ms
[shading] shading=gouraud: FPS: 165 FrameTime: 6.061 ms
[shading] shading=blinn-phong-inf: FPS: 164 FrameTime: 6.098 ms
[shading] shading=phong: FPS: 160 FrameTime: 6.250 ms
[shading] shading=cel: FPS: 158 FrameTime: 6.329 ms
[bump] bump-render=high-poly: FPS: 136 FrameTime: 7.353 ms
[bump] bump-render=normals: FPS: 179 FrameTime: 5.587 ms
[bump] bump-render=height: FPS: 179 FrameTime: 5.587 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 138 FrameTime: 7.246 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 56 FrameTime: 17.857 ms
[pulsar] light=false:quads=5:texture=false: FPS: 177 FrameTime: 5.650 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 58 FrameTime: 17.241 ms
[desktop] effect=shadow:windows=4: FPS: 117 FrameTime: 8.547 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 30 Fram
eTime: 33.333 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30
FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 32 Frame
Time: 31.250 ms
[ideas] speed=duration: FPS: 94 FrameTime: 10.638 ms
[jellyfish] <default>: FPS: 123 FrameTime: 8.130 ms
[terrain] <default>: FPS: 18 FrameTime: 55.556 ms
[shadow] <default>: FPS: 92 FrameTime: 10.870 ms
[refract] <default>: FPS: 47 FrameTime: 21.277 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 178 FrameTime: 5.618 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 152 FrameTime: 6.579 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 179 FrameTime: 5.587 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 148 FrameTime: 6.757 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 143 FrameTime: 6.993 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 158 FrameTime: 6.329 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 153 FrameTime: 6.536 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 148 FrameTime: 6.757 ms
=======================================================
                                  glmark2 Score: 129
=======================================================
odroid@odroid:~$ ./mali_test/test_vsync
X11Window: width=1920, height=1080
EGL: major=1, minor=4
EGL: Vendor=ARM
EGL: Version=1.4 Midgard-"r14p0-01rel0"
EGL: ClientAPIs=OpenGL_ES
EGL: Extensions=EGL_KHR_image_pixmap EGL_KHR_partial_update EGL_KHR_config_attribs EGL_KHR_image EGL_KHR_image_
base EGL_KHR_fence_sync EGL_KHR_wait_sync EGL_KHR_gl_colorspace EGL_KHR_get_all_proc_addresses EGL_IMG_context_
priority EGL_ARM_pixmap_multisample_discard EGL_KHR_gl_texture_2D_image EGL_KHR_gl_renderbuffer_image EGL_KHR_c
reate_context EGL_KHR_surfaceless_context EGL_KHR_gl_texture_cubemap_image EGL_EXT_create_context_robustness EG
L_KHR_cl_event2
EGL: ClientExtensions=EGL_EXT_client_extensions EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL
_KHR_platform_x11 EGL_EXT_platform_x11

X11Window: xwin = 58720258
FPS: 58
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60

There was not tearing issue.
User avatar
Brian.K
 
Posts: 245
Joined: Tue Sep 15, 2015 7:30 pm
Location: South Korea
languages_spoken: English, Korean
ODROIDs: XU4, C1+, C2

Re: X11 Hardware Acceleration (EXA)

Unread postby odroid » Wed Apr 19, 2017 4:06 pm

@meveric,
Can you please run the same test on your OGST image?
We really need to know what we have to fix for the Retroarch compatibility issue before releasing an official 4.9 LTS Kernel in early May.
User avatar
odroid
Site Admin
 
Posts: 24590
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Wed Apr 19, 2017 5:27 pm

odroid wrote:@meveric,
Can you please run the same test on your OGST image?
We really need to know what we have to fix for the Retroarch compatibility issue before releasing an official 4.9 LTS Kernel in early May.

I will do some more testing.
But please also fix the Hardware Identifier of the CPU cat /proc/cpuinfo | grep Hardware else there will be a lot of rewriting for scripts on different images.
I know that DietPi also uses this entry to identify the board, and so do my images (Debian Jessie and OGST).
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby odroid » Wed Apr 19, 2017 5:30 pm

Okay. We will fix it by early next week with u-boot stage identifier.
Please let me know the expected outputs for XU3 and XU4.
User avatar
odroid
Site Admin
 
Posts: 24590
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Wed Apr 19, 2017 5:40 pm

Under 3.10 it's currently just "ODROID-XU3" which is used for both XU3/XU4 not sure if it makes sense to have separate entries for both, since normally scripts normally apply for both (installation of xf86-video-armsoc, MFC firmware, etc. should be all the same for both, just not for other ODROIDs).
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Thu Apr 20, 2017 4:00 am

meveric wrote:But please also fix the Hardware Identifier of the CPU

A better solution may be to use:
Code: Select all
cat /proc/device-tree/model


This pulls the value from the device tree:
https://github.com/hardkernel/linux/blob/odroidxu4-4.9.y/arch/arm/boot/dts/exynos5422-odroidxu4.dts#L20
Code: Select all
   model = "Hardkernel Odroid XU4";


Since the device tree is board specific, this should also solve the problem of detecting XU3 vs XU4.
https://github.com/hardkernel/linux/blob/odroidxu4-4.9.y/arch/arm/boot/dts/exynos5422-odroidxu3.dts#L19
Code: Select all
   model = "Hardkernel Odroid XU3";
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Thu Apr 20, 2017 5:01 am

crashoverride wrote:
meveric wrote:But please also fix the Hardware Identifier of the CPU

A better solution may be to use:
Code: Select all
cat /proc/device-tree/model


This pulls the value from the device tree:
https://github.com/hardkernel/linux/blob/odroidxu4-4.9.y/arch/arm/boot/dts/exynos5422-odroidxu4.dts#L20
Code: Select all
   model = "Hardkernel Odroid XU4";


Since the device tree is board specific, this should also solve the problem of detecting XU3 vs XU4.
https://github.com/hardkernel/linux/blob/odroidxu4-4.9.y/arch/arm/boot/dts/exynos5422-odroidxu3.dts#L19
Code: Select all
   model = "Hardkernel Odroid XU3";


Hmm, but that would also require to rewrite the scripts that already exists and it doesn't work on all ODROIDs.
The older X,X2,U2/U3 don't necessarily use device trees.
Also the output on the same device is very different depending on the Kernel.
On Kernel 4.9 it might be "Hardkernel Odroid XU3" and "Hardkernel Odroid XU4"
But on Kerne 3.10 it's "Hardkernel odroid-xu3 board based on EXYNOS5422"
Writing filter for all these different cases is a pain in the A** ;)

And yes I could check for Kernel version first, and all that stuff.. but then we have cases in cases in cases.. while switching Hardware info back to ODROID-XU3 just means all scripts would still work, no changes necessary.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Thu Apr 20, 2017 5:44 am

meveric wrote:switching Hardware info back to ODROID-XU3 just means all scripts would still work, no changes necessary.

https://github.com/OtherCrashOverride/linux-hardkernel/commit/6c940932190e24e86df8abf05a97ed044da2c736
Code: Select all
odroid@odroidxu4:~$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 78.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 3

processor       : 1
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 78.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 3

processor       : 2
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 78.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 3

processor       : 3
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 78.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 3

processor       : 4
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 120.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc0f
CPU revision    : 3

processor       : 5
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 120.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc0f
CPU revision    : 3

processor       : 6
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 120.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc0f
CPU revision    : 3

processor       : 7
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 120.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc0f
CPU revision    : 3

Hardware        : ODROID-XU3
Revision        : 0100
Serial          : 0000000000000000
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Thu Apr 20, 2017 6:02 am

Thanks a lot, I can work with that :)
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby blu » Thu Apr 20, 2017 4:40 pm

crashoverride wrote:I added a vsync test to my "mali_test" repo. It demonstrates how to call drmWaitVBlank. It also shows that currently, we have tearing (using above "NoFlip").
https://github.com/OtherCrashOverride/mali_test/blob/master/test_vsync.cpp

In the future, drmWaitVBlank should never need to be called by a program. Instead, Mali should call this as needed based on the eglSwapInterval settings.

[edit]
Updated the code to call glFinish(). This corrects the tearing that was present.
(Note that eglSwapBuffers implies glFinish.)

eglSwapBuffers implies a glFlush
blu
 
Posts: 13
Joined: Wed Mar 08, 2017 11:30 pm
languages_spoken: english
ODROIDs: XU4 eMMC

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Thu Apr 20, 2017 5:34 pm

glFlush causes any pending commands to be sent for execution.
glFinish blocks until all pending command have been executed.

https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glFlush.xml
glFlush can return at any time.
It does not wait until the execution of all previously
issued GL commands is complete.


Before a buffer can be swapped, all rendering must be completed. This means glFinish is implied:
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glFinish.xhtml
glFinish does not return until the effects of all previously called GL commands are complete. Such effects include all changes to GL state, all changes to connection state, and all changes to the frame buffer contents.


[edit]
The example is intended to be a simplification of how a EGL driver would operate. A "real" EGL driver would not call glFinish. It would flush the command stream and insert fences. Once the fence is seen, the buffer can be swapped and a second fence would allow command processing to continue afterwards. This would allow the GL to continue issuing commands to the context while the swap is scheduled offering improved performance. Since its not possible to interact with Mali at this level from user-space, the simple glFinish() is used instead since it imparts the same behavior: rendering must be completed before a swap can occur.
Last edited by crashoverride on Thu Apr 20, 2017 5:52 pm, edited 1 time in total.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby blu » Thu Apr 20, 2017 5:47 pm

crashoverride wrote:glFlush causes any pending commands to be sent for execution.
glFinish blocks until all pending command have been executed.

Yep.

Before a buffer can be swapped, all rendering must be completed. This means glFinish is implied:

Nope.

Finishing rendering and blocking the client rendering thread are two orthogonal things. Which is precisely why eglSwapBuffers implies glFlush, and not glFinish.
blu
 
Posts: 13
Joined: Wed Mar 08, 2017 11:30 pm
languages_spoken: english
ODROIDs: XU4 eMMC

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Thu Apr 20, 2017 5:55 pm

blu wrote:Finishing rendering and blocking the client rendering thread are two orthogonal things.

See my edit above.

[edit]
I <3 edits!

[edit2]
Long term it would be awesome if we had the ultimate Mali driver that performed everything optimally. Since in the real world, this rarely happens over night, the focus is on replacing the legacy (hacks) FBIO_WAITFORVSYNC with drmWaitVBlank in user-space code. The only way either of these two methods works is with glFlush(). The example I posted only demonstrates the technique. It is hoped that it is an interim solution. After Mali has been updated with vsync support, the drmWaitVBlank can be removed from user-space code. At this point, future work on Mali can optimize the swaps. Until then, we have a transitional solution so that developers are not blocked.

It is not my goal to be "imprecise". Collaborating with different developers on different continents with different native languages necessitates that sometimes "simplicity" is prioritized over the pedantic.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby blu » Thu Apr 20, 2017 6:28 pm

crashoverride wrote:The example is intended to be a simplification of how a EGL driver would operate. A "real" EGL driver would not call glFinish. It would flush the command stream and insert fences. Once the fence is seen, the buffer can be swapped and a second fence would allow command processing to continue afterwards. This would allow the GL to continue issuing commands to the context while the swap is scheduled offering improved performance. Since its not possible to interact with Mali at this level from user-space, the simple glFinish() is used instead since it imparts the same behavior: rendering must be completed before a swap can occur.

I was merely commenting on the notion that eglSwapBuffers implies a glFinish - it does not. An EGL stack may choose to do whatever its authors deemed appropriate, but that does not mean the semantics of the API function implies everything an implementation does. As per Mali fence functionality - it definitely does expose fences client-side - check the extensions string dumps.
blu
 
Posts: 13
Joined: Wed Mar 08, 2017 11:30 pm
languages_spoken: english
ODROIDs: XU4 eMMC

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Thu Apr 20, 2017 6:42 pm

blu wrote:As per Mali fence functionality - it definitely does expose fences client-side - check the extensions string dumps.

I did not intend to imply a lack of fence support. Rather, I stated there is no way to interact with Mali (EGL/GL), DRM, and DRI2 at that level without being "in the driver". This statement should not prevent anyone from posting sample code demonstrating the technique should they feel up to the challenge.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby nicolasvila » Thu Apr 20, 2017 8:48 pm

Dear all.
HI, I'm a new on this forum I'm an Odroid XU4 user.

I was running Odrobian Jessie until recently, and decided to swich to ArchLinuxARM (as I'm Arch user on my Desktop PC)
I managed to install it properly and I have almost all the stuff I used to enjoy on Odrobian.... but still have a few issues, including one related to desktop acceleration and that's why I'm asking for help.

BEFORE (Odrobian Jessie):
    On my Debian (running MATE) there was no problem to launch any OpenGL-ES or OpenGL applications such as Stellarium or Celestia (thanks to glshim apparently)
    Kodi 16 was running smoothly
    I could enjoy MATE without any slowdown while dragging windows, etc.

NOW (ArchLinuxARM):
    Kodi 17 is running fine again
    Mate is working except, some "ghost" effects and slowdowns while dragging windows (maybe the armsoc driver is not as optimized as the older Odrobian one?)
    Stellarium complains as it tries to run using EGL profile

Do you think it is related to the armsoc driver?
Should I try using the Odrobian armsoc drivers? (by replacing the files)
Could we imagine a standard procedure to deploy the required files on any distribution?
Thanks.
nicolasvila
 
Posts: 4
Joined: Thu Aug 04, 2016 11:23 pm
Location: Toulouse, France
languages_spoken: french, english
ODROIDs: U3, XU4

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Thu Apr 20, 2017 9:11 pm

nicolasvila wrote:Do you think it is related to the armsoc driver?

The maintainers of Odrobian or ArchLinuxARM would be the ones to ask. I do not use either and only support the official Ubuntu image due to resource constraints.

nicolasvila wrote:Should I try using the Odrobian armsoc drivers? (by replacing the files)

Ensure you have a backup or other method to restore the original driver. I did release an experimental accelerated armsoc a long time ago, but due to IOMMU bugs in older kernels it could corrupt the system depending on kernel version. Its possible that Odrobian may have packaged that, but I do not know for certain.

nicolasvila wrote:Could we imagine a standard procedure to deploy the required files on any distribution?

Unlikely since each distro uses a different package manager (apt, yum, pacman, etc.).
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Thu Apr 20, 2017 11:06 pm

crashoverride wrote:
nicolasvila wrote:Should I try using the Odrobian armsoc drivers? (by replacing the files)

Ensure you have a backup or other method to restore the original driver. I did release an experimental accelerated armsoc a long time ago, but due to IOMMU bugs in older kernels it could corrupt the system depending on kernel version. Its possible that Odrobian may have packaged that, but I do not know for certain.

This won't work. armsoc is build against X-Server version, which is "unique" for each distro. Each time the X-Server changes, armsoc needs to be rebuild, which is normally each time you switch from one OS version to the next, or from one OS(e.g Debian) to another (e.g. Ubuntu/Arch/Fedora/etc.).
It's highly unlikely that Debian Jessie (which is several years old) uses the same X-Server version as ArchLinux (which is normally bleeding edge).
The binaries won't work, and you probably won't find any sources that XeoSal was using to rebuild it.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby nicolasvila » Fri Apr 21, 2017 3:07 am

Indeed, using the previous armsoc drivers does not work.
Xorg complains that the version of the driver does not match xorg version. So I gave up....

So I managed to compile and install your driver from the xu4 branch:
On ArchLinuxARM, the drm files are already present with the kernel and I just had to create a symlink:

Code: Select all
ln -s /usr/lib/modules/4.9.20-3-ARCH/build/include/uapi/drm /usr/include/uapi/drm


I've been able to enable G2D option from xorg.conf but I could only start a session using Openbox (performances were amazing, and very stable)

Mate startup failed and the screen remained blank (white in my case)
LXDE started but hanged when I clicked on the menu.
I need to investigate the different log files in order to figure out what's wrong
nicolasvila
 
Posts: 4
Joined: Thu Aug 04, 2016 11:23 pm
Location: Toulouse, France
languages_spoken: french, english
ODROIDs: U3, XU4

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Fri Apr 21, 2017 3:22 am

nicolasvila wrote:On ArchLinuxARM, the drm files are already present with the kernel and I just had to create a symlink:

viewtopic.php?f=146&t=26248#p182376
I should note that the libdrm code included is customized to correct errors and add required features. The libdrm supplied with Ubuntu or from upstream will not work.


[edit]
This applies to https://github.com/OtherCrashOverride/xf86-video-armsoc/blob/73f465226e09c7834e33aad17746f74ba5901bb0/src/exynos_fimg2d.c. There is a correlation between libdrm and the IOCTL interface used by the kernel and headers. Non 4.9.y kernels have not been tested and are not supported (by me). Others are certainly welcome to fork the armsoc driver and experiment.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby nicolasvila » Fri Apr 21, 2017 6:44 am

Thank you for your explanation. I just recompiled the armsoc driver like you suggested with the latest drm files from:
https://github.com/hardkernel/linux/tre ... e/uapi/drm
ArchLinuxARM stick with 4.9 kernel (not the mainline one)

Had no compilation problem, everything was OK, just like with the drm files bundled with the 4.9 ArchLinuxARM kernel (I'll make a diff with the XU4 4.9 branch)
The "crash" I mentioned earlier was apparently not caused by the drm files (not sure) but by a "missing" option in the xorg.conf.
It seems I HAVE to disable RENDER extension, even if doesn't care about it according to the logs (see below)

Code: Select all
Section "Device"
        Identifier      "Mali-Fbdev"
        Driver          "armsoc"
        Option          "fbdev"         "/dev/fb0"
        Option          "Debug"         "false"
        Option          "DPMS"          "false"

        Option          "DRI2"            "true"
        Option          "DRI2_PAGE_FLIP"  "false"
        Option          "DRI2_WAIT_VSYNC" "false"

        Option          "SwapbuffersWait" "true"
        Option          "AccelMethod" "G2D"
EndSection

Section "Screen"
        Identifier      "Default Screen"
        Device          "Mali-Fbdev"
        DefaultDepth    24
EndSection

Section "ServerLayout"
        Identifier      "Default Layout"
        Option          "BlankTime"     "0"
        Option          "StandbyTime"   "0"
        Option          "SuspendTime"   "0"
        Option          "OffTime"       "0"
EndSection

Section "DRI"
        Mode            0666
EndSection

Section "Extensions"
        Option      "Composite" "disable"
        Option      "RENDER"    "disable"
EndSection


Anyway... I tried to play with the different "Device" options but I didn't notice any change. Is there a list of available parameters ?
grep GL /var/log/Xorg.0.log|grep -v Modeline
Code: Select all
[  7206.910] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/armsoc_dri.so failed (/usr/lib/xorg/modules/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)
[  7206.910] (EE) AIGLX: reverting to software rendering
[  7207.287] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
[  7209.919] (II) IGLX: Loaded and initialized swrast
[  7209.919] (II) GLX: Initialized DRISWRAST GL provider for screen 0


Here are the ARMSOC lines from my /var/log/Xorg.0.log
Code: Select all
[  7205.531] (II) ARMSOC: Driver for ARM Mali compatible chipsets
[  7205.532] (II) ARMSOC(0): Creating default Display subsection in Screen section
[  7205.532] (**) ARMSOC(0): Depth 24, (--) framebuffer bpp 32
[  7205.532] (==) ARMSOC(0): RGB weight 888
[  7205.532] (==) ARMSOC(0): Using gamma correction (1.0, 1.0, 1.0)
[  7205.532] (==) ARMSOC(0): Default visual is TrueColor
[  7205.532] (II) ARMSOC(0): Chipset: Mali
[  7205.532] (**) ARMSOC(0): Option "Debug" "false"
[  7205.532] (II) ARMSOC(0): Buffer Flipping is Enabled
[  7205.532] (II) ARMSOC(0): umplock is Enabled
[  7205.532] (II) ARMSOC(0): Setting the video modes ...
[  7205.533] (II) ARMSOC(0): Adding all CRTCs
[  7205.533] (II) ARMSOC(0): Got CRTC: 0 (id: 27)
[  7205.571] (II) ARMSOC(0): Output HDMI-1 has no monitor section
[  7205.609] (II) ARMSOC(0): EDID for output HDMI-1
[  7205.609] (II) ARMSOC(0): Manufacturer: PHL  Model: 0  Serial#: 16843009
[  7205.609] (II) ARMSOC(0): Year: 2011  Week: 11
[  7205.609] (II) ARMSOC(0): EDID Version: 1.3
[  7205.609] (II) ARMSOC(0): Digital Display Input
[  7205.609] (II) ARMSOC(0): Max Image Size [cm]: horiz.: 64  vert.: 36
[  7205.609] (II) ARMSOC(0): Gamma: 2.20
[  7205.609] (II) ARMSOC(0): No DPMS capabilities specified
[  7205.609] (II) ARMSOC(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
[  7205.609] (II) ARMSOC(0): First detailed timing is preferred mode
[  7205.609] (II) ARMSOC(0): redX: 0.636 redY: 0.335   greenX: 0.291 greenY: 0.603
[  7205.609] (II) ARMSOC(0): blueX: 0.146 blueY: 0.061   whiteX: 0.279 whiteY: 0.292
[  7205.609] (II) ARMSOC(0): Supported established timings:
[  7205.609] (II) ARMSOC(0): 640x480@60Hz
[  7205.609] (II) ARMSOC(0): 800x600@60Hz
[  7205.609] (II) ARMSOC(0): 1024x768@60Hz
[  7205.609] (II) ARMSOC(0): Manufacturer's mask: 0
[  7205.609] (II) ARMSOC(0): Supported standard timings:
[  7205.609] (II) ARMSOC(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
[  7205.609] (II) ARMSOC(0): Supported detailed timing:
[  7205.609] (II) ARMSOC(0): clock: 148.5 MHz   Image Size:  640 x 360 mm
[  7205.609] (II) ARMSOC(0): h_active: 1920  h_sync: 2008  h_sync_end 2052 h_blank_end 2200 h_border: 0
[  7205.609] (II) ARMSOC(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 v_blanking: 1125 v_border: 0
[  7205.609] (II) ARMSOC(0): Supported detailed timing:
[  7205.609] (II) ARMSOC(0): clock: 84.8 MHz   Image Size:  640 x 360 mm
[  7205.609] (II) ARMSOC(0): h_active: 1360  h_sync: 1432  h_sync_end 1568 h_blank_end 1776 h_border: 0
[  7205.609] (II) ARMSOC(0): v_active: 768  v_sync: 771  v_sync_end 776 v_blanking: 798 v_border: 0
[  7205.609] (II) ARMSOC(0): Monitor name: PHILIPS FTV
[  7205.609] (II) ARMSOC(0): Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 175 MHz
[  7205.609] (II) ARMSOC(0): Supported detailed timing:
[  7205.609] (II) ARMSOC(0): clock: 148.5 MHz   Image Size:  640 x 360 mm
[  7205.610] (II) ARMSOC(0): h_active: 1920  h_sync: 2448  h_sync_end 2492 h_blank_end 2640 h_border: 0
[  7205.610] (II) ARMSOC(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 v_blanking: 1125 v_border: 0
[  7205.610] (II) ARMSOC(0): Supported detailed timing:
[  7205.610] (II) ARMSOC(0): clock: 74.2 MHz   Image Size:  640 x 360 mm
[  7205.610] (II) ARMSOC(0): h_active: 1920  h_sync: 2558  h_sync_end 2602 h_blank_end 2750 h_border: 0
[  7205.610] (II) ARMSOC(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 v_blanking: 1125 v_border: 0
[  7205.610] (II) ARMSOC(0): Supported detailed timing:
[  7205.610] (II) ARMSOC(0): clock: 74.2 MHz   Image Size:  640 x 360 mm
[  7205.610] (II) ARMSOC(0): h_active: 1920  h_sync: 2448  h_sync_end 2492 h_blank_end 2640 h_border: 0
[  7205.610] (II) ARMSOC(0): v_active: 540  v_sync: 542  v_sync_end 547 v_blanking: 562 v_border: 0
[  7205.610] (II) ARMSOC(0): Supported detailed timing:
[  7205.610] (II) ARMSOC(0): clock: 74.2 MHz   Image Size:  640 x 360 mm
[  7205.610] (II) ARMSOC(0): h_active: 1280  h_sync: 1720  h_sync_end 1760 h_blank_end 1980 h_border: 0
[  7205.610] (II) ARMSOC(0): v_active: 720  v_sync: 725  v_sync_end 730 v_blanking: 750 v_border: 0
[  7205.610] (II) ARMSOC(0): Number of EDID sections to follow: 1
[  7205.610] (II) ARMSOC(0): EDID (in hex):
[  7205.610] (II) ARMSOC(0):    00ffffffffffff00410c000001010101
[  7205.610] (II) ARMSOC(0):    0b150103804024780af9aba2554a9a25
[  7205.610] (II) ARMSOC(0):    0f474a21080081800101010101010101
[  7205.610] (II) ARMSOC(0):    010101010101023a801871382d40582c
[  7205.610] (II) ARMSOC(0):    450080682100001e1b2150a051001e30
[  7205.610] (II) ARMSOC(0):    48883500806821000018000000fc0050
[  7205.610] (II) ARMSOC(0):    48494c495053204654560a20000000fd
[  7205.610] (II) ARMSOC(0):    00384c1e5311000a20202020202001c7
[  7205.610] (II) ARMSOC(0):    020326714e9f10202122140513041102
[  7205.610] (II) ARMSOC(0):    15060126090703150750830100006703
[  7205.610] (II) ARMSOC(0):    0c003000b82d023a80d072382d40102c
[  7205.610] (II) ARMSOC(0):    458080682100001e011d803e73382d40
[  7205.610] (II) ARMSOC(0):    7e2c458080682100001e011d80d0721c
[  7205.610] (II) ARMSOC(0):    1620102c258080682100009e011d00bc
[  7205.610] (II) ARMSOC(0):    52d01e20b828554080682100001e0000
[  7205.611] (II) ARMSOC(0):    0000000000000000000000000000000c
[  7205.611] (II) ARMSOC(0): EDID vendor "PHL", prod id 0
[  7205.611] (II) ARMSOC(0): Using EDID range info for horizontal sync
[  7205.611] (II) ARMSOC(0): Using EDID range info for vertical refresh
[  7205.611] (--) ARMSOC(0): HDMI max TMDS frequency 225000KHz
[  7205.611] (II) ARMSOC(0): Printing probed modes for output HDMI-1
[  7205.612] (II) ARMSOC(0): Output HDMI-1 connected
[  7205.612] (II) ARMSOC(0): Using exact sizes for initial modes
[  7205.612] (II) ARMSOC(0): Output HDMI-1 using initial mode 1920x1080 +0+0
[  7205.612] (II) ARMSOC(0): Got KMS resources
[  7205.612] (**) ARMSOC(0): Display dimensions: (640, 360) mm
[  7205.612] (**) ARMSOC(0): DPI set to (76, 76)
[  7206.875] (II) ARMSOC(0): Soft EXA mode
[  7206.875] (II) ARMSOC(0): G2D Initialized.
[  7206.875] (II) ARMSOC(0): Setting swap chain size: 2
[  7206.875] (II) ARMSOC(0): [DRI2] Setup complete
[  7206.875] (II) ARMSOC(0): [DRI2]   DRI driver: armsoc
[  7206.875] (==) ARMSOC(0): Backing store disabled
[  7206.875] (==) ARMSOC(0): Silken mouse enabled
[  7206.875] (II) ARMSOC(0): HW cursor init()
[  7206.875] (II) ARMSOC(0): HW cursor initialized
[  7206.888] (II) ARMSOC(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[  7209.920] (II) ARMSOC(0): Setting screen physical size to 508 x 285
nicolasvila
 
Posts: 4
Joined: Thu Aug 04, 2016 11:23 pm
Location: Toulouse, France
languages_spoken: french, english
ODROIDs: U3, XU4

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Fri Apr 21, 2017 7:06 am

nicolasvila wrote:I tried to play with the different "Device" options but I didn't notice any change. Is there a list of available parameters ?

https://github.com/OtherCrashOverride/x ... #L114-L125
Code: Select all
/** Supported options. */
static const OptionInfoRec ARMSOCOptions[] = {
   { OPTION_DEBUG,      "Debug",      OPTV_BOOLEAN, {0}, FALSE },
   { OPTION_NO_FLIP,    "NoFlip",     OPTV_BOOLEAN, {0}, FALSE },
   { OPTION_CARD_NUM,   "DRICard",    OPTV_INTEGER, {0}, FALSE },
   { OPTION_BUSID,      "BusID",      OPTV_STRING,  {0}, FALSE },
   { OPTION_DRIVERNAME, "DriverName", OPTV_STRING,  {0}, FALSE },
   { OPTION_DRI_NUM_BUF, "DRI2MaxBuffers", OPTV_INTEGER, {-1}, FALSE },
   { OPTION_INIT_FROM_FBDEV, "InitFromFBDev", OPTV_STRING, {0}, FALSE },
   { OPTION_UMP_LOCK,   "UMP_LOCK",   OPTV_BOOLEAN, {0}, FALSE },
   { -1,                NULL,         OPTV_NONE,    {0}, FALSE }
};

Note that there is no "AccelMethod" option.
Code: Select all
Option          "AccelMethod" "G2D"


Unfortunately, I do not have the resources to diagnose issues on distros other than the official Ubuntu image (where everything works).
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby nicolasvila » Fri Apr 21, 2017 4:56 pm

Hi.
Thanks Crashoverride for the options parameters. I looked at the code too but is there a description?
I will give Ubuntu a try, just to compare the different behaviors.
I could maybe give a hand for the Debian & Arch support, as I'm a software developer too ;-)
I will check out with the 2 distros maintainers.

1) Odrobian seems outdated as I didn't see any packages for the upcoming version: Stretch. The version Jessie works perfectly and even standard GL application work out of the box (for example GL xscreensavers) I didn't find the sources of the drivers and the compilation options yet. That's my reference for now and I guess it's very close to what's available on Ubuntu.
2) Arch is something a little different and offers an interesting packaging mechanism, allowing compilation during install. On Arch xorg depends on a libglvnd (https://github.com/NVIDIA/libglvnd) package, a GL Vendor-Neutral Dispatch library which allows to dispatch calls to various API at runtime. Both GLX and EGL are supported, in any combination with OpenGL and OpenGL ES.

In any case, I well understood we have to take care of
* Xorg and Armsoc drivers coherence
* Mali drivers versions (1.4 Midgard-"r14p0-01rel0" on Arch, 1.4 Midgard-"r9p0-05rel0 on Odrobian)
* /usr/lib/libGL.so files versions (on Arch it's provided by libglvnd. On Odrobian there isn't libGL.so files but glshim is in the library path and allows to wrap GL API calls to OpenGL-ES)


I noticed the latest Mali drivers are r17p0-01rel0. Which Mali version is being used now on Ubuntu?

What's your recommended xorg.conf for the XU4 board?
nicolasvila
 
Posts: 4
Joined: Thu Aug 04, 2016 11:23 pm
Location: Toulouse, France
languages_spoken: french, english
ODROIDs: U3, XU4

Re: X11 Hardware Acceleration (EXA)

Unread postby crashoverride » Fri Apr 21, 2017 7:22 pm

nicolasvila wrote: I looked at the code too but is there a description?

Like most Linux things: "The source code is the documentation." :shock:

nicolasvila wrote:Which Mali version is being used now on Ubuntu?

r14p0

nicolasvila wrote:What's your recommended xorg.conf for the XU4 board?

No xorg.conf should be required unless you wish to set the "NoFlip" option as discussed a couple posts earlier in this thread.
crashoverride
 
Posts: 3075
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Mon Apr 24, 2017 2:40 pm

I did some testing, and was surprised to see the NoFlip option working so well with G2D acceleration.
And then it hit me. The reason why we're using r14p0 was that we always had vsync issues with the drivers for this we accepted a big loss in performance on the "buffer" test in glmaek2-es2 and all other programs that use it.

Since we now are able to disable buffer Flipping and still have decent performance (thanks to G2D) but still have no tearing (vsync?) I thought, why not going back to Mali r12p0 and see how it works...
And the results are very good :)

Code: Select all
odroid@gamestation-turbo:~$ glmark2-es2 --fullscreen --annotate
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1 v1.r12p0-04rel0.5824fa733530fc4698793c84be7a2a51
=======================================================
[build] use-vbo=false: FPS: 196 FrameTime: 5.102 ms
[build] use-vbo=true: FPS: 194 FrameTime: 5.155 ms
[texture] texture-filter=nearest: FPS: 212 FrameTime: 4.717 ms
[texture] texture-filter=linear: FPS: 212 FrameTime: 4.717 ms
[texture] texture-filter=mipmap: FPS: 212 FrameTime: 4.717 ms
[shading] shading=gouraud: FPS: 192 FrameTime: 5.208 ms
[shading] shading=blinn-phong-inf: FPS: 193 FrameTime: 5.181 ms
[shading] shading=phong: FPS: 130 FrameTime: 7.692 ms
[shading] shading=cel: FPS: 154 FrameTime: 6.494 ms
[bump] bump-render=high-poly: FPS: 166 FrameTime: 6.024 ms
[bump] bump-render=normals: FPS: 200 FrameTime: 5.000 ms
[bump] bump-render=height: FPS: 219 FrameTime: 4.566 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 162 FrameTime: 6.173 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 66 FrameTime: 15.152 ms
[pulsar] light=false:quads=5:texture=false: FPS: 197 FrameTime: 5.076 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 62 FrameTime: 16.129 ms
[desktop] effect=shadow:windows=4: FPS: 132 FrameTime: 7.576 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 82 FrameTime: 12.195 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 86 FrameTime: 11.628 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 96 FrameTime: 10.417 ms
[ideas] speed=duration: FPS: 120 FrameTime: 8.333 ms
[jellyfish] <default>: FPS: 138 FrameTime: 7.246 ms
[terrain] <default>: FPS: 19 FrameTime: 52.632 ms
[shadow] <default>: FPS: 103 FrameTime: 9.709 ms
[refract] <default>: FPS: 49 FrameTime: 20.408 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 184 FrameTime: 5.435 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 177 FrameTime: 5.650 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 168 FrameTime: 5.952 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 194 FrameTime: 5.155 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 154 FrameTime: 6.494 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 196 FrameTime: 5.102 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 196 FrameTime: 5.102 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 175 FrameTime: 5.714 ms
=======================================================
                                  glmark2 Score: 152
=======================================================

buffer tests are back to over 60 FPS

while vsync seems to work fine:
Code: Select all
odroid@gamestation-turbo:~$ ./test_vsync
X11Window: width=1920, height=1080
EGL: major=1, minor=4
EGL: Vendor=ARM
EGL: Version=1.4 Midgard-"r12p0-04rel0"
EGL: ClientAPIs=OpenGL_ES
EGL: Extensions= EGL_KHR_image_pixmap EGL_KHR_partial_update  EGL_KHR_config_attribs EGL_KHR_image EGL_KHR_image_base EGL_KHR_fence_sync EGL_KHR_wait_sync EGL_KHR_gl_colorspace EGL_KHR_get_all_proc_addresses EGL_IMG_context_priority EGL_ARM_pixmap_multisample_discard EGL_KHR_gl_texture_2D_image EGL_KHR_gl_renderbuffer_image EGL_KHR_create_context EGL_KHR_surfaceless_context EGL_KHR_gl_texture_cubemap_image EGL_EXT_create_context_robustness EGL_KHR_cl_event2
EGL: ClientExtensions= EGL_EXT_client_extensions EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_platform_x11 EGL_EXT_platform_x11

X11Window: xwin = 56623106
FPS: 58
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60


I'll do some more testing with retroarch later to see if there's any tearing or not :)
Edit:
on the first glance retroarch seems to work "ok-ish" most of the time it stars normally and tearing is not an issue, but at times it starts games with either 20 or 30 FPS rather than 60 FPS.. restarting helps, but still slightly annoying.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby Cartridge » Tue Apr 25, 2017 4:10 am

Would anyone be willing to show off g2d capabilites and more in a youtube video? I'm at work atm and havent started downloading yet to try all of it. Ive bout 4 hours to download an imge to then download some more to enable g2d and more libraries...
User avatar
Cartridge
 
Posts: 605
Joined: Fri Sep 27, 2013 9:06 pm
languages_spoken: english, french natively
ODROIDs: The Perfect ODROID-U2, ODROID-U3+, C1, XU3

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Tue Apr 25, 2017 5:27 am

there isn't much to see.. what isn't already in this thread.
Instead of 60-70 FPS in glmark2-es2 in window mode you now have up to 600 FPS.
The mouse cursor is no longer flickering when you are over multimedia content such as the glmark2-es2 window or chromium youtube.
tearing seems to be gone if you use NoFlip option and desktop feels snappier if you move a window around.
Aside from that there isn't much to "show off".
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby Cartridge » Tue Apr 25, 2017 7:43 am

Well theres many to windowed mode applications and games. At least to me. Come to think of it, the desktop is a big part of my life in computers lol I see it a lot xD
User avatar
Cartridge
 
Posts: 605
Joined: Fri Sep 27, 2013 9:06 pm
languages_spoken: english, french natively
ODROIDs: The Perfect ODROID-U2, ODROID-U3+, C1, XU3

Re: X11 Hardware Acceleration (EXA)

Unread postby moon.linux » Wed Apr 26, 2017 1:46 pm

It seen like the g3d bus is disable and not configured with respect to devfreq.
the opt binding for frequency scaling is also missing.

Code: Select all
                nocp_g3d_0: nocp@11A51000 {
                        compatible = "samsung,exynos5420-nocp";
                        reg = <0x11A51000 0x200>;
                        status = "disabled";
                };

                nocp_g3d_1: nocp@11A51400 {
                        compatible = "samsung,exynos5420-nocp";
                        reg = <0x11A51400 0x200>;
                        status = "disabled";
                };
moon.linux
 
Posts: 876
Joined: Thu Oct 02, 2014 11:42 pm
languages_spoken: english

Re: X11 Hardware Acceleration (EXA)

Unread postby MastaG » Fri Apr 28, 2017 4:43 pm

meveric wrote:I did some testing, and was surprised to see the NoFlip option working so well with G2D acceleration.
And then it hit me. The reason why we're using r14p0 was that we always had vsync issues with the drivers for this we accepted a big loss in performance on the "buffer" test in glmaek2-es2 and all other programs that use it.

Since we now are able to disable buffer Flipping and still have decent performance (thanks to G2D) but still have no tearing (vsync?) I thought, why not going back to Mali r12p0 and see how it works...
And the results are very good :)

Code: Select all
odroid@gamestation-turbo:~$ glmark2-es2 --fullscreen --annotate
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1 v1.r12p0-04rel0.5824fa733530fc4698793c84be7a2a51
=======================================================
[build] use-vbo=false: FPS: 196 FrameTime: 5.102 ms
[build] use-vbo=true: FPS: 194 FrameTime: 5.155 ms
[texture] texture-filter=nearest: FPS: 212 FrameTime: 4.717 ms
[texture] texture-filter=linear: FPS: 212 FrameTime: 4.717 ms
[texture] texture-filter=mipmap: FPS: 212 FrameTime: 4.717 ms
[shading] shading=gouraud: FPS: 192 FrameTime: 5.208 ms
[shading] shading=blinn-phong-inf: FPS: 193 FrameTime: 5.181 ms
[shading] shading=phong: FPS: 130 FrameTime: 7.692 ms
[shading] shading=cel: FPS: 154 FrameTime: 6.494 ms
[bump] bump-render=high-poly: FPS: 166 FrameTime: 6.024 ms
[bump] bump-render=normals: FPS: 200 FrameTime: 5.000 ms
[bump] bump-render=height: FPS: 219 FrameTime: 4.566 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 162 FrameTime: 6.173 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 66 FrameTime: 15.152 ms
[pulsar] light=false:quads=5:texture=false: FPS: 197 FrameTime: 5.076 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 62 FrameTime: 16.129 ms
[desktop] effect=shadow:windows=4: FPS: 132 FrameTime: 7.576 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 82 FrameTime: 12.195 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 86 FrameTime: 11.628 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 96 FrameTime: 10.417 ms
[ideas] speed=duration: FPS: 120 FrameTime: 8.333 ms
[jellyfish] <default>: FPS: 138 FrameTime: 7.246 ms
[terrain] <default>: FPS: 19 FrameTime: 52.632 ms
[shadow] <default>: FPS: 103 FrameTime: 9.709 ms
[refract] <default>: FPS: 49 FrameTime: 20.408 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 184 FrameTime: 5.435 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 177 FrameTime: 5.650 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 168 FrameTime: 5.952 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 194 FrameTime: 5.155 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 154 FrameTime: 6.494 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 196 FrameTime: 5.102 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 196 FrameTime: 5.102 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 175 FrameTime: 5.714 ms
=======================================================
                                  glmark2 Score: 152
=======================================================

buffer tests are back to over 60 FPS

while vsync seems to work fine:
Code: Select all
odroid@gamestation-turbo:~$ ./test_vsync
X11Window: width=1920, height=1080
EGL: major=1, minor=4
EGL: Vendor=ARM
EGL: Version=1.4 Midgard-"r12p0-04rel0"
EGL: ClientAPIs=OpenGL_ES
EGL: Extensions= EGL_KHR_image_pixmap EGL_KHR_partial_update  EGL_KHR_config_attribs EGL_KHR_image EGL_KHR_image_base EGL_KHR_fence_sync EGL_KHR_wait_sync EGL_KHR_gl_colorspace EGL_KHR_get_all_proc_addresses EGL_IMG_context_priority EGL_ARM_pixmap_multisample_discard EGL_KHR_gl_texture_2D_image EGL_KHR_gl_renderbuffer_image EGL_KHR_create_context EGL_KHR_surfaceless_context EGL_KHR_gl_texture_cubemap_image EGL_EXT_create_context_robustness EGL_KHR_cl_event2
EGL: ClientExtensions= EGL_EXT_client_extensions EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_platform_x11 EGL_EXT_platform_x11

X11Window: xwin = 56623106
FPS: 58
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60
FPS: 60


I'll do some more testing with retroarch later to see if there's any tearing or not :)
Edit:
on the first glance retroarch seems to work "ok-ish" most of the time it stars normally and tearing is not an issue, but at times it starts games with either 20 or 30 FPS rather than 60 FPS.. restarting helps, but still slightly annoying.


Hi meveric,

Did you run RetroArch on top of Xorg or straight from the console using the fbdev driver?
I was thinking of building another RecalBox image (which uses the fbdev driver) with the latest 4.9.y kernel, what version would you recommend? r12p?
MastaG
 
Posts: 159
Joined: Mon Aug 26, 2013 6:05 pm
languages_spoken: english

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Fri Apr 28, 2017 5:46 pm

MastaG wrote:Hi meveric,

Did you run RetroArch on top of Xorg or straight from the console using the fbdev driver?

xf86-video-armsoc is the framebuffer driver for X11 as far as I know only that one can currently use G2D acceleration.
There is a possibility to compile retroarch agains G2D as well, but I never followed that path.
MastaG wrote:I was thinking of building another RecalBox image (which uses the fbdev driver) with the latest 4.9.y kernel, what version would you recommend? r12p?

Since I don't use fbdev drivers I can't answer that question.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Re: X11 Hardware Acceleration (EXA)

Unread postby odroid » Tue May 02, 2017 7:25 pm

Today's update.

- armsoc DDX video driver based on crashoverride's git
- mali DDK driver based ARM's latest r17p0
- new kernel update 4.9.25-28

Update system with sudo apt update && sudo apt upgrade && sudo apt dist-upgrade
If your meta kernel package is kept back, manually update it with sudo apt install linux-image-xu3

glmark2-es2 rendering performance looks great.
Code: Select all
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1 v1.r17p0-01rel0.105a4ebe814535d8123c06e4f5178bb7
=======================================================
[build] use-vbo=false: FPS: 458 FrameTime: 2.183 ms
[build] use-vbo=true: FPS: 584 FrameTime: 1.712 ms
[texture] texture-filter=nearest: FPS: 597 FrameTime: 1.675 ms
[texture] texture-filter=linear: FPS: 599 FrameTime: 1.669 ms
[texture] texture-filter=mipmap: FPS: 568 FrameTime: 1.761 ms
[shading] shading=gouraud: FPS: 489 FrameTime: 2.045 ms
[shading] shading=blinn-phong-inf: FPS: 478 FrameTime: 2.092 ms
[shading] shading=phong: FPS: 464 FrameTime: 2.155 ms
[shading] shading=cel: FPS: 471 FrameTime: 2.123 ms
[bump] bump-render=high-poly: FPS: 324 FrameTime: 3.086 ms
[bump] bump-render=normals: FPS: 623 FrameTime: 1.605 ms
[bump] bump-render=height: FPS: 564 FrameTime: 1.773 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 490 FrameTime: 2.041 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 225 FrameTime: 4.444 ms
[pulsar] light=false:quads=5:texture=false: FPS: 641 FrameTime: 1.560 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 190 FrameTime: 5.263 ms
[desktop] effect=shadow:windows=4: FPS: 285 FrameTime: 3.509 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 40 FrameTime: 25.000 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 40 FrameTime: 25.000 ms
[ideas] speed=duration: FPS: 244 FrameTime: 4.098 ms
[jellyfish] <default>: FPS: 384 FrameTime: 2.604 ms
[terrain] <default>: FPS: 46 FrameTime: 21.739 ms
[shadow] <default>: FPS: 285 FrameTime: 3.509 ms
[refract] <default>: FPS: 89 FrameTime: 11.236 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 619 FrameTime: 1.616 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 504 FrameTime: 1.984 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 608 FrameTime: 1.645 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 567 FrameTime: 1.764 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 476 FrameTime: 2.101 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 577 FrameTime: 1.733 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 568 FrameTime: 1.761 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 490 FrameTime: 2.041 ms
=======================================================
                                  glmark2 Score: 412
=======================================================


If your score is much lower than mine, change the CPU governor to performance mode.
Check: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
If output is not "performance", type echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils and reboot.
User avatar
odroid
Site Admin
 
Posts: 24590
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: X11 Hardware Acceleration (EXA)

Unread postby meveric » Tue May 02, 2017 10:13 pm

seems the r17p0 drivers have the same speed issues as r14p0 at least when it comes to the [buffer] tests.
User avatar
meveric
 
Posts: 7708
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: ODROID-X2,ODROID-U2,ODROID-U3,ODROID-XU-Lite, ODROID-XU3, ODROID-XU3-Lite, ODROID-C1, ODROID-XU4, ODROID-C2

Previous

Return to Linux Kernel 4.14 Debugging Party

Who is online

Users browsing this forum: No registered users and 1 guest