The Pyra from a Developer’s Eye

neo

In our previous feature of the Gamescom, you have seen what has been disclosed during the show a couple of days ago, as well as what was going on in the backroom. As you know PtitSeb and Notaz (two of the most active porter/coders on the Pandora) were there and actively trying stuff on the Pyra. So, what do they think of what they played with so far?

First, the setup available in the backroom included a devboard using a SGX driver for 3D scenes, and a LCD screen (BOE) attached to it (one of the candidate screens). There was no rotation chip to be used, so all trial was done in “portrait mode”. Sometimes it was however needed to boot on a normal HDMI screen in order to test things in a proper way.

07

The good thing is that the screen does not seem to have much of a ghosting issue like on the Pandora, and remains readable even in portrait mode. It seems to be more colorful and have more maximum brightness than Pandora’s screen.

08

Now on to the performance of the board itself. Overall Notaz thought the devboard gives a nice boost for all major tasks, as it is to be expected. During the different days on the show, Notaz was apparently doing the most of the work, connecting to the devboard via SSH when PtitSeb was having fun with it. But that did not prevent PtitSeb from trying a number of things as well.

PtitSeb mentioned that compilations on the devboard were significantly faster:

PtitSeb: While I was there, I compiled Jedi Knight II and Arx Libertatis [an open source recreation of Arx Fatalis’ engine] and the difference is obvious (while I can’t measure it) even though I was using only one core (Notaz was using the other one).

Notaz was thinking very much the same thing:

Notaz: Compilation is a lot faster, 2 cores and large cache make a huge difference. This means cross-compilation on PC is no longer needed, just compile everything on the device (yes PtitSeb is already does that on his Pandora, but for me it’s too slow). At the show, I’ve compiled the kernel and all the emulators directly on the board, some of which even while PtitSeb was compiling his stuff (he used one core and I used the other while connected over ssh from a Pandora).

As you know, Reicast (the Dreamcast Emulator) was running apparently very well on the development board. On the Pandora 1Ghz, Reicast’s bottleneck in performance is coming from the CPU. On the devboard it was obviously not an issue anymore.

PtitSeb: Initially Reicast was too fast. When we added an OSS (audio) driver, the speed was then limited to 100%. On the Pandora I only used OSS, it’s quite simple to code, and the current Alsa code was glitchy, so I did not use it since then. Reicast manages its own emulation speed using sound. Sonic Adventure or Skies of Arcadia were running at full speed, without any glitch. It’s quite obvious by now that the Sega Dreamcast fans will have the machine of their dreams with the Pyra!

Notaz had compiled Mupen (N64 Emulator) before PtitSeb had even arrived at the show, using the Rice GLES2 drivers that he knows well since he has recently optimized them.

mupen

When PtitSeb arrived, they started compiling the GLES1.1 version as well, just to see if a lower usage of GPU made any difference in performance. The results were however disappointing:

PtitSeb: There was no miracle, the driver seems to show its limitations at this stage. With or without frameskip, it was slow (or running at very low FPS) – there were no glitches but we couldn’t get the speed out of it. We tested with the Dynarec or the interpreter and there was no change in the framerate. There’s probably more work needed on the GPU drivers. When I arrived, Reicast could not run more than 1 minute without crashing, but when Notaz found another git source, and updated the build, Reicast worked in a stable way after that. However there was no change for Mupen…

For Jedi Knight II, there were some issues with the original files of the game, PtitSeb could not connect properly to his portable hard drive at first.

jediknight2

But then it went through in the end, while things did not go as smoothly as expected:

PtitSeb: Jedi Knight II could be compiled. It launched, and I got the main menu. Then it crashes when lauching the game’s intro. I did not have time to debug this issue. I do not know where the problem is coming from.

Arx Libertatis was another game PtitSeb managed to compile during the show.

PtitSeb: on the Pandora this game is limited by the CPU, so on the devboard it runs better. There’s not glitch and it runs more smoothly. With drivers improvements it could be even smoother, probably. But we compared between the Pandora and the devboard, and everyone (Notaz, ED and IngoReis) thought it was running better on the Pyra devboard.

On the GPU side, it seems that the devboard is still constrained because of the drivers.

PtitSeb: The state of the GPU is not all that great right now. Drivers are still unstable, and the context creation is a little more convoluted than on the Pandora. It’s not easy to measure how good the results are at this stage. It’s hard to have a final opinion, but I think the drivers are too immature right now. I could not notice the superiority of the new SGX of the devboard compared to the Pandora (I could have compiled my benchmark tool but I did not have time).

Notaz has his doubts about the driver too:

Notaz: The driver is a continuation of the one on Pandora (the latest version) so it can’t be said it’s immature… Still there could easily be something wrong with it. There could also easily be some integration issues or simple misconfiguration somewhere, like the clocks set wrong or similar. TI calls it “1.9 DDK post-beta engineering drop”, so maybe there’ll be another “drop”, or maybe not, who knows, at least for OMAP3 we had many driver releases.

cortex15

Some of the performance issues may be linked to the A15 in itself:

Notaz: Framebuffer access is very slow as Cortex-A15 doesn’t support write-through caching (Cortex-A8 does), which means you need to be more careful with direct framebuffer access. Some of my emulators will have to be changed to work around that (this is not related to 3D/SGX, it about programs using direct fb access, like PCSX ReARMed).

PtitSeb also checked about the claims that the chip could overheat, since there was a recent discussion about that on the boards.

PtitSeb: While I was running Arx Libertatis, I checked the temperature with a laser termometer (a pretty cool toy!) and it was less than 45 C while the coffee was at about 70 C. I don’t think it’s going to be an issue.

All these observations show that the development still has a long way to go to bring the same level of performance as what we currently enjoy on the Pandora. It may be that some emulators do not run as well at first, for a number of reasons, while there should be some workarounds.

I will be back soon again with a long article about the Pyra’s development, overall design, and what’s left to do in software and hardware until launch.

Leave a Reply

3 Comments on "The Pyra from a Developer’s Eye"

avatar
  Subscribe  
newest oldest most voted
Notify of
rohezal
Guest

Thank you for this nice article. Since the omap5 will be used in cars etc, I think they will fix the driver. A navigation system must randomly crash 😉

Adrian Browne
Guest

Good article. Concise.
I sure am looking forward to a Pyra.

Sepulep
Guest

any observations on raw floating point performance??