Let him eat one right away. He’ll only make it better for usWhile 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
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.
It's software this time!
- Thread starter EvilDragon
- Start date
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
I don't think eating a Pyra is a good idea. 
directive0
Very Active Member
Seems like a good idea to me.
hns
Well-Known Member
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.
daveshah
Well-Known Member
Thanks for activating my account, I have now updated that issue list in a few places with that I am currently working on.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
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.
ClockworkCoder
Chaotic Neutral
Unless he was the one that voted "no"!
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. :-(
ok. then when all the critical kernel bugs are squashed, its release day right?
Kippykip
BFG 9000
Bruh when I initally saw that poor framerate I died a little inside...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
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.
But then I continued reading and... it's running that with full X86 emulation??? HOLY HECC OK NEVERMIND THAT'S ACTUALLY AMAZING
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
levi
Still fresh, damnit!
daveshah
Well-Known Member
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
Advanced Member
- Joined
- May 20, 2015
- Messages
- 1,175
You are awesome
Failbert
Active Member
- Joined
- Apr 18, 2017
- Messages
- 77
- Age
- 33
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.
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
Well-Known Member
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:
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:
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.
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.
Pretty cool, I wonder how much different there will be whit the actual Pyra ..
dit you already got a shipping mail from Evildragon ?
Whit best regards, Matthias
dit you already got a shipping mail from Evildragon ?
Whit best regards, Matthias
GizmoTheGreen
Active Member
is pyra x11 only or does it work with wayland..?
daveshah
Well-Known Member
It should be pretty similar, the only differences would be the slightly different resolution and possibly thermal.
No shipping email yet.
At the moment only X11 is working reliably. I have tried Wayland a bit with the new 1.17 drivers as it doesn't seem to work with the 1.14 drivers and it does run well (and can do its own accelerated rotation so doesn't need any TILER patches). Once the issues with the 1.17 drivers are ironed out, then Wayland is definitely going to be an option on the Pyra.
No shipping email yet.
Post automatically merged:
At the moment only X11 is working reliably. I have tried Wayland a bit with the new 1.17 drivers as it doesn't seem to work with the 1.14 drivers and it does run well (and can do its own accelerated rotation so doesn't need any TILER patches). Once the issues with the 1.17 drivers are ironed out, then Wayland is definitely going to be an option on the Pyra.
