It's software this time!

Should davesha skip the queue so he can work directly on the Pyra?

  • Yes

    Votes: 174 99.4%
  • No

    Votes: 1 0.6%

  • Total voters
    175
  • Poll closed .

Yogendra

Still Fresh
Joined
Aug 3, 2017
Messages
13
Age
71
While the hardware is finished and we're only waiting for the arrival of some stuff, we have awesome news regarding the Pyra lowlevel stuff!

3D in combination with TILER works now!


According to ptitSeb (who created the video), it runs a lot smoother in real life, but the camera had some weird shutter / framerate issues (which also explains the heavily flickering keyboard LEDs).

So, what happened?

davesha (a member here on the board who also preordered a Pyra) bought himself an OMAP5 uEVM Devboard to help out with the issues. Well, and you can see the result!
He fixed the stuff without owning a Pyra (with the help of aTc, zmatt and tmlind, you were replying to questions and helped out testing it on a Pyra on IRC as well)

And he's not yet done - he's currently working on optimizing even more.

This is pretty awesome news - it means that the software will be a lot more mature as we expected when delivery happens :D

Now, there's one thing: It would help if he had a Pyra to work on. It would make debugging, etc. a lot more easy for him - and it would help us to get a more mature software in faster time.
I've got a few retail units here already (without packaging, etc. though) and would love to send him his unit already - but he's a bit further down the queue.

I think it would be great if I let him SKIP the line - and finish his order right away (sending him packaging and the rest of the experience later on).
He already proved that he can help and I'm pretty sure it would bea good thing for all of us.

But I don't want to decide that myself. You supported the Pyra, you helped out and you're the ones still waiting for it! So here's a poll - please let me know if davesha should be allowed to skip the queue and become the first delivered preorder - or not.
Let him eat one right away. He’ll only make it better for us
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
512
Location
Oberhaching
The Goldelico Letux kernel issues list is probably the best one to work with. Unfortunately, the registration isn't working for me there, I get to the last step but the "Enable Your Account" button doesn't do anything...
Autonomous registration has been disabled because robots did find a way to register themselves and write spam issues with web-links (link-farm). Please contact me and let me know your account name and I can enable it manually.
 

Grench

Forum Addict!
Joined
Oct 3, 2008
Messages
6,504
Autonomous registration has been disabled because robots did find a way to register themselves and write spam issues with web-links (link-farm).
If there were rational laws in place, this behavior would be as illegal as someone walking into a shop (breaking and entering) and plastering the walls with paid advertising for other stores (vandalism). Sorry you have to pay the price for their misdeeds by having to take the time to manually authorize connections.
 

cerno

Still Fresh
Joined
Dec 5, 2017
Messages
12
Location
Brno
If there were rational laws in place, this behavior would be as illegal as someone walking into a shop (breaking and entering) and plastering the walls with paid advertising for other stores (vandalism). Sorry you have to pay the price for their misdeeds by having to take the time to manually authorize connections.
This behavior even is illegal, at least in my country, but nobody gives a s**t. Especially when the offending traffic comes from abroad, you're out of luck. The laws are useless, the government has different priorities: to use the police to extort the money from drivers who parked their cars 10 cm over the line, to bribe the electorate to ensure their reelection and to spy and stalk their own citizens and to collect megatons of data on them, all of them being forbidden by the GDPR.

20 years ago I wouldn't think normal humans would need their own intranet to protect from spam. :-(
 

Kippykip

BFG 9000
Joined
Sep 6, 2016
Messages
503
Age
22
Location
'STRAYA
Website
kippykip.com
While the hardware is finished and we're only waiting for the arrival of some stuff, we have awesome news regarding the Pyra lowlevel stuff!

3D in combination with TILER works now!


According to ptitSeb (who created the video), it runs a lot smoother in real life, but the camera had some weird shutter / framerate issues (which also explains the heavily flickering keyboard LEDs).

So, what happened?

davesha (a member here on the board who also preordered a Pyra) bought himself an OMAP5 uEVM Devboard to help out with the issues. Well, and you can see the result!
He fixed the stuff without owning a Pyra (with the help of aTc, zmatt and tmlind, you were replying to questions and helped out testing it on a Pyra on IRC as well)

And he's not yet done - he's currently working on optimizing even more.

This is pretty awesome news - it means that the software will be a lot more mature as we expected when delivery happens :D

Now, there's one thing: It would help if he had a Pyra to work on. It would make debugging, etc. a lot more easy for him - and it would help us to get a more mature software in faster time.
I've got a few retail units here already (without packaging, etc. though) and would love to send him his unit already - but he's a bit further down the queue.

I think it would be great if I let him SKIP the line - and finish his order right away (sending him packaging and the rest of the experience later on).
He already proved that he can help and I'm pretty sure it would bea good thing for all of us.

But I don't want to decide that myself. You supported the Pyra, you helped out and you're the ones still waiting for it! So here's a poll - please let me know if davesha should be allowed to skip the queue and become the first delivered preorder - or not.
Bruh when I initally saw that poor framerate I died a little inside...
But then I continued reading and... it's running that with full X86 emulation??? HOLY HECC OK NEVERMIND THAT'S ACTUALLY AMAZING
poggerfish.gif

BRUH
This gonna be epic, I haven't checked here in a while. From what I understand the hardware now is pretty much done?
poggers
 

daveshah

Very Active Member
Joined
Aug 17, 2008
Messages
132
Location
(Old) Hampshire, UK
Also, today @daveshah announced a patch to get the GC320 2D accelerator and for the DRI3WSEGL which apparently has something to do with running 3d graphics under X. They're mainly code from other people that he's found and tested and found to be good, so it's awsome that this is happening.
For anyone else following this, on the packages gitlab I also have WIP patches for TILER rotation support in the X11 driver and resize crash fixes in the DRI3 plugin.

The biggest remaining piece of the puzzle is the issue with etnaviv and swiotlb with 4GB RAM, which I can't debug on the uEVM (which only has 2GB). Some performance testing is also needed to make sure it doesn't add too much overhead compared to "raw" fullscreen 3D. Although it does add an extra blit going through X11, the GC320 means it takes minimal CPU time and it should be small fraction of memory bandwidth.

Also, many thanks to aTc for doing the Debian packaging and testing on a Pyra of this stuff!
 

Swordfish II

Very Active Member
Joined
May 20, 2015
Messages
980
For anyone else following this, on the packages gitlab I also have WIP patches for TILER rotation support in the X11 driver and resize crash fixes in the DRI3 plugin.

The biggest remaining piece of the puzzle is the issue with etnaviv and swiotlb with 4GB RAM, which I can't debug on the uEVM (which only has 2GB). Some performance testing is also needed to make sure it doesn't add too much overhead compared to "raw" fullscreen 3D. Although it does add an extra blit going through X11, the GC320 means it takes minimal CPU time and it should be small fraction of memory bandwidth.

Also, many thanks to aTc for doing the Debian packaging and testing on a Pyra of this stuff!
You are awesome
 

Failbert

Active Member
Joined
Apr 18, 2017
Messages
73
Age
29
All you contributors to the board design and the pre-release software deserve a hall of fame section (maybe on this site, maybe elsewhere) to "forever" (can't type it without parenthesis on the internet of today...) be remembered and have a nice addition to your porrtfolios.

If someone who invested time and skill into something that's both an freedom-centric indie endeavour AND an actual, non-vaporware (just 2monthsware) commercial product (in the age of failed or downright hoax kickstarters) isn't a good candidate to hire or subcontract for the next thing, then the thing must be boring.
 

daveshah

Very Active Member
Joined
Aug 17, 2008
Messages
132
Location
(Old) Hampshire, UK
Some benchmarks, because everyone loves benchmarks! This time glmark2, on the uEVM but with TILER enabled and using DRI3 and X11. The window size is the default 800x600.

First, the default configuration:
Code:
=======================================================
    glmark2 2020.04
=======================================================
    OpenGL Information
    GL_VENDOR:     Imagination Technologies
    GL_RENDERER:   PowerVR SGX 544MP
    GL_VERSION:    OpenGL ES 2.0 build 1.14@3699939 (MAIN)
=======================================================
[build] use-vbo=false: FPS: 135 FrameTime: 7.407 ms
[build] use-vbo=true: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=nearest: FPS: 172 FrameTime: 5.814 ms
[texture] texture-filter=linear: FPS: 172 FrameTime: 5.814 ms
[texture] texture-filter=mipmap: FPS: 173 FrameTime: 5.780 ms
[shading] shading=gouraud: FPS: 186 FrameTime: 5.376 ms
[shading] shading=blinn-phong-inf: FPS: 191 FrameTime: 5.236 ms
[shading] shading=phong: FPS: 167 FrameTime: 5.988 ms
[shading] shading=cel: FPS: 140 FrameTime: 7.143 ms
[bump] bump-render=high-poly: FPS: 123 FrameTime: 8.130 ms
[bump] bump-render=normals: FPS: 172 FrameTime: 5.814 ms
[bump] bump-render=height: FPS: 170 FrameTime: 5.882 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 137 FrameTime: 7.299 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 84 FrameTime: 11.905 ms
[pulsar] light=false:quads=5:texture=false: FPS: 178 FrameTime: 5.618 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: 100 FrameTime: 10.000 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 89 FrameTime: 11.236 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 90 FrameTime: 11.111 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: 127 FrameTime: 7.874 ms
[jellyfish] <default>: FPS: 118 FrameTime: 8.475 ms
[terrain] <default>: FPS: 2 FrameTime: 500.000 ms
[shadow] <default>: FPS: 85 FrameTime: 11.765 ms
[refract] <default>: FPS: 37 FrameTime: 27.027 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 180 FrameTime: 5.556 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 150 FrameTime: 6.667 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 181 FrameTime: 5.525 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 171 FrameTime: 5.848 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 170 FrameTime: 5.882 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 174 FrameTime: 5.747 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 148 FrameTime: 6.757 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 122 FrameTime: 8.197 ms
=======================================================
                                  glmark2 Score: 135
=======================================================

Then I noticed that the GPU clock was fixed at the default 425MHz. The maximum actually appears to be 532MHz, strictly speaking this also requires an increased operating point. Out of curiosity I tweaked the DPLL config to force the divider for 532MHz, although without increasing the operating point it is technically undervolted (seemed stable enough though). This does give some improvement to some of the benchmarks that are not bottlenecked by memory bandwidth or final blitting:
Code:
=======================================================
    glmark2 2020.04
=======================================================
    OpenGL Information
    GL_VENDOR:     Imagination Technologies
    GL_RENDERER:   PowerVR SGX 544MP
    GL_VERSION:    OpenGL ES 2.0 build 1.14@3699939 (MAIN)
=======================================================
[build] use-vbo=false: FPS: 138 FrameTime: 7.246 ms
[build] use-vbo=true: FPS: 171 FrameTime: 5.848 ms
[texture] texture-filter=nearest: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=linear: FPS: 173 FrameTime: 5.780 ms
[texture] texture-filter=mipmap: FPS: 174 FrameTime: 5.747 ms
[shading] shading=gouraud: FPS: 182 FrameTime: 5.495 ms
[shading] shading=blinn-phong-inf: FPS: 184 FrameTime: 5.435 ms
[shading] shading=phong: FPS: 185 FrameTime: 5.405 ms
[shading] shading=cel: FPS: 163 FrameTime: 6.135 ms
[bump] bump-render=high-poly: FPS: 139 FrameTime: 7.194 ms
[bump] bump-render=normals: FPS: 178 FrameTime: 5.618 ms
[bump] bump-render=height: FPS: 168 FrameTime: 5.952 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 156 FrameTime: 6.410 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 96 FrameTime: 10.417 ms
[pulsar] light=false:quads=5:texture=false: FPS: 186 FrameTime: 5.376 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 69 FrameTime: 14.493 ms
[desktop] effect=shadow:windows=4: FPS: 105 FrameTime: 9.524 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 91 FrameTime: 10.989 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 92 FrameTime: 10.870 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 98 FrameTime: 10.204 ms
[ideas] speed=duration: FPS: 133 FrameTime: 7.519 ms
[jellyfish] <default>: FPS: 139 FrameTime: 7.194 ms
[terrain] <default>: FPS: 2 FrameTime: 500.000 ms
[shadow] <default>: FPS: 90 FrameTime: 11.111 ms
[refract] <default>: FPS: 38 FrameTime: 26.316 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 185 FrameTime: 5.405 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 149 FrameTime: 6.711 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 186 FrameTime: 5.376 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 167 FrameTime: 5.988 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: 167 FrameTime: 5.988 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 193 FrameTime: 5.181 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 176 FrameTime: 5.682 ms
=======================================================
                                  glmark2 Score: 142 
=======================================================

The low score in the "terrain" benchmark seems to have been fixed in the 1.17 PowerVR blobs (currently PyraOS uses 1.14) according to their commit log, unfortunately these aren't quite working right with PyraOS yet so I can't test - first I had to LD_PRELOAD a new libm for them to not complain about the glibc version, but then there is a pthread segfault inside a Wayland library so I suspect they also are assuming that Wayland is running.
 
Top