An almost naked Pyra


levi said:
Ah, that's good to know. So the extra registers and 64-bit instruction decode transistors are left completely unpowered while the processor is in 32-bit mode? Neat!
Click to expand...

That is probably true too but what I meant is that in 64-bit mode there are forms for integer instructions that only operate on the low 32-bit part of registers. So for example, "add w0, w0, w1" is the 32-bit form and "add x0, x0, x1" is the 64-bit form. With the 32-bit forms the processor can gate off a lot of the unneeded computation and data transfer paths. With the exception of pointers, most integer work is going to tend to be 32-bit even in 64-bit mode so it's easy to take advantage of this. The base register in load/store instructions is always 64-bit, but an offset register can be 32-bit.
 
EvilDragon said:
Yep, seen it! Will try to test ASAP :)
Click to expand...

Just an update on this, worth doing publicly.

notaz ran a build of DraStic that he was able to get working on his OMAP5 EVM. The one I sent you earlier is no good, so if you want to do a temperature or stability test you'll need this new one from notaz (Lordus can probably build something that will work too)

It uses /dev/fb0, but unfortunately the OMAP drivers only allow allocating one screen's worth and don't allow the pan function, so there's no double buffering (ie, tearing). I doubt this will work on Pyra, so we'll eventually need to find something else for baseline support. I don't know what the performance overhead will be.

Here is performance for New Super Mario Bros in the world 2 map with high-resolution rendering:

Code: 
Full run time:  14.25ms per frame
Video 2D run time:  3.06ms per frame
Video 3D run time:  7.87ms per frame
Video Geometry run time:  1.06ms per frame
Screen Update run time:  0.00ms per frame
Audio run time:  0.00ms per frame

This is with both CPUs running at 1.5GHz. The emulator is configured to use two threads. The second thread is used for half of the 2D work (one of the screens) and half of the 3D work (every other 16 lines of the screen). Screen update was disabled for this test, although with the fbdev solution it probably didn't add a lot. This is just around the edge for consistent 100% speed performance w/o frameskip (needs < 16.67ms full run time), assuming that the screen update code that's eventually used doesn't add too much to that.

During runtime, about 160% CPU time is used. About 93% is used on core #0 and about 67% on core #1. So, both cores are not used 100%. notaz reports that temperature rises to 82C on the UEVM's sensor. This is of course with the heat sink on. It'll be interesting to see what temperature climbs to on Pyra, and whether or not this will be sustainable.

The scene tested has close to the highest 3D runtime in my Pandora test set, and has the highest overall time. So it should be representative of a fairly heavy load for DS emulation, although there are exceptions that will be much heavier.
 
@Exophase, @notaz Is that good performance? Was this tried without an Xorg session? I know the modesetting driver bogs everything down without working 3D drivers, aTc's OS image uses fbturbo currently for better performance.

I wish my devboard was still working...
 
Concerning /dev/fb0. I suppose the best solution would be to use DRM instead.
 
Exophase said:
Just an update on this, worth doing publicly.

notaz ran a build of DraStic that he was able to get working on his OMAP5 EVM. The one I sent you earlier is no good, so if you want to do a temperature or stability test you'll need this new one from notaz (Lordus can probably build something that will work too)

It uses /dev/fb0, but unfortunately the OMAP drivers only allow allocating one screen's worth and don't allow the pan function, so there's no double buffering (ie, tearing). I doubt this will work on Pyra, so we'll eventually need to find something else for baseline support. I don't know what the performance overhead will be.

Here is performance for New Super Mario Bros in the world 2 map with high-resolution rendering:

Code: 
Full run time:  14.25ms per frame
Video 2D run time:  3.06ms per frame
Video 3D run time:  7.87ms per frame
Video Geometry run time:  1.06ms per frame
Screen Update run time:  0.00ms per frame
Audio run time:  0.00ms per frame

This is with both CPUs running at 1.5GHz. The emulator is configured to use two threads. The second thread is used for half of the 2D work (one of the screens) and half of the 3D work (every other 16 lines of the screen). Screen update was disabled for this test, although with the fbdev solution it probably didn't add a lot. This is just around the edge for consistent 100% speed performance w/o frameskip (needs < 16.67ms full run time), assuming that the screen update code that's eventually used doesn't add too much to that.

During runtime, about 160% CPU time is used. About 93% is used on core #0 and about 67% on core #1. So, both cores are not used 100%. notaz reports that temperature rises to 82C on the UEVM's sensor. This is of course with the heat sink on. It'll be interesting to see what temperature climbs to on Pyra, and whether or not this will be sustainable.

The scene tested has close to the highest 3D runtime in my Pandora test set, and has the highest overall time. So it should be representative of a fairly heavy load for DS emulation, although there are exceptions that will be much heavier.
Click to expand...

82C is really high! Would the performances and the temperature would be better with working 3D drivers?
 
Samsung was able to put a heatpipe in their newest Galaxy S7 Smartphones (Exynos 8 SoC), I'm sure the Pyra has more room inside than an average densed smart phone. Just an idea if there is really need for serious cooling. ;)
But if you can put an beefy Octa Core 64 Bit CPU in an small SmartPhone without melting the device, I'm sure that the compared slower OMAP5 doesn't need such an intense cooling. Except it is a really bad Chip design or whatever Ti did there.
 
Last edited:
TrashyMG said:
@Exophase, @notaz Is that good performance? Was this tried without an Xorg session? I know the modesetting driver bogs everything down without working 3D drivers, aTc's OS image uses fbturbo currently for better performance.

I wish my devboard was still working...
Click to expand...

I don't know but I asked notaz to check top and make sure nothing was taking a meaningful amount of CPU time.

Lordus also offered scores from an Odroid XU3 with an Exynos 5410, where execution was pegged to two A15 cores clocked at 1.5GHz. It scored a bit better, I don't have the exact number but AFAIK it was about 5%. I asked for a perf number from notaz and it looks like the function that writes back to the fbdev mapped buffer was using a lot more CPU time than I expected it should. So it's possible that fbdev driver performed the mmap in a suboptimal way, like not enabling write buffering. On the other hand, the difference could be due to things like different memory latencies between the two SoCs.

Plume said:
Concerning /dev/fb0. I suppose the best solution would be to use DRM instead.
Click to expand...

We really want to use OpenGL ES because it makes it easy to have arbitrary scaling, shaders, overlays, etc. But the drivers aren't ready.

For the next best thing I was hoping for at least something that's comparable to the fbdev DSS driver on Pandora, where you have at least two layers and one of them scaleable (but hopefully better than this). I have no idea how to use DRM but I'll try to learn about that.

Faust said:
82C is really high! Would the performances and the temperature would be better with working 3D drivers?
Click to expand...

Unfortunately, using OpenGL ES would probably make the CPU load worse because it has to upload the screen to a texture. Ideally the remaining time on the second core would suck that up so there wouldn't be a huge performance hit, but it might already be using too much CPU...

TrashyMG said:
The heatsink is also really shitty.
Click to expand...

Let's hope Pyra's solution is better then. Looking forward to getting some test data back when things are working.
 
Exophase said:
TrashyMG said:
@Exophase, @notaz Is that good performance? Was this tried without an Xorg session? I know the modesetting driver bogs everything down without working 3D drivers, aTc's OS image uses fbturbo currently for better performance.
Click to expand...
I don't know but I asked notaz to check top and make sure nothing was taking a meaningful amount of CPU time.
Click to expand...
The system was mostly idle before starting the test, Xorg was not even running, the overheads should be minimal.
 
Exophase said:
Let's hope Pyra's solution is better then. Looking forward to getting some test data back when things are working.
Click to expand...
I believe anything is better than what was provided on the devboard, but still pretty concerning.

notaz said:
he system was mostly idle before starting the test, Xorg was not even running, the overheads should be minimal.
Click to expand...
As I don't know what framerate the Pandora typically runs Drastic at, I prob shouldn't be that concerned. I just felt that it should be a bit better seeing what I could manage on the devboard when I was playing with it.
 
TrashyMG said:
As I don't know what framerate the Pandora typically runs Drastic at, I prob shouldn't be that concerned. I just felt that it should be a bit better seeing what I could manage on the devboard when I was playing with it.
Click to expand...

Just want to reiterate, the posted test was with high resolution rendering enabled. This isn't even available as an option on Pandora.

High resolution rendering roughly triples the time of the 3D score and doubles the time of the 2D score. So the normal rendering score would probably be closer to 10ms. I could ask if notaz (or ED) wants to test this too.

I do have a high resolution result for this test on Pandora (GHz model @ 1GHz) from last April:

Code: 
Full run time:  49.21ms per frame
Video 2D run time:  7.05ms per frame
Video 3D run time:  32.43ms per frame
Video Geometry run time:  2.69ms per frame
Screen Update run time:  0.49ms per frame
Audio run time:  0.78ms per frame

So 3.45x slower than Pyra.

Accounting for a dual core bonus of ~60% and a clock bonus of 50% that results in about 44% better perf/MHz. I suspect that the heavily hand-optimized NEON code I did has less of a per-MHz advantage going from Cortex-A8 to A15 than typical code would. Games w/o high resolution rendering could show a bigger gap because the A15 would probably do better with the dynarec stuff. Naturally, everyone should take all of this with some serious salt.
 
I'm no mechanical engineer or thermal analyst but some new heat pipe solution sounds like an awfully tall order for a device like Pyra. Expensive and difficult to design, and maybe at risk of tripping over patents.

Besides that, is there any place to really add anything? The SoC is sandwiched between the two PCBs, the only place to really remove heat is into the main PCB through the ground plane. That should hopefully distribute it to a lot of surface area across the PCB so it could be a pretty good solution. Only other thing I can think of to help more would be to tie the ground plane to some additional heatsink on the other side but I doubt there's room for that.
 
It's a product solution sold by and patented by Fujitsu, since it's only a 1mm thick ribbon like product, there's a chance it can be used in the Pyra (actually the reason I mentioned it - because it's thin)
Fujitsu have an email on their page to contact about info on it. Wouldn't hurt finding out more info. If it's to expensive, not viable, not yet available to the general market etc etc, you will soon find out, won't find out without asking though


11-1c_tcm100-1559499.jpg
11-1e_tcm100-1559501.jpg
 
Last edited:
Yeah, it really can't hurt to ask. But if it's not needed, then no point asking anyway.
 
vcoleiro1 said:
It's a product solution sold by and patented by Fujitsu, since it's only a 1mm thick ribbon like product, there's a chance it can be used in the Pyra (actually the reason I mentioned it - because it's thin)
Click to expand...

Oh I had no idea, thanks.

Unfortunately I don't really see how anything remotely like this could work in Pyra. Someone else correct me if I'm not seeing this right, but AFAIK if you stuck it between the OMAP and main PCB (and 1mm is actually quite a lot of added height) it'd hit the daughter board connectors or, if it came out the other way, various components on the main board. It's packed really tight in there.
 
You must log in or register to reply here.

Similar threads

EvilDragon
Some PCBs, holidays, a new case revision and a theme
6 7 8
Replies
153
Views
30K
Tenka
Tenka
EvilDragon
Silent progress
7 8 9
Replies
168
Views
31K
chewdiggy
chewdiggy
EvilDragon
Nothing to show, but a lot happened.
7 8 9
Replies
168
Views
27K
levi
levi
EvilDragon
Updates in all areas
6 7 8
Replies
141
Views
33K
DrHAX
DrHAX
EvilDragon
Greetings from Greece and Bavaria
2 3
Replies
40
Views
12K
rygD
rygD
Back
Top