Hello,
In my N64 graphics plugin (http://code.google.com/p/gles2n64/) the framebuffer becomes corrupt during peak loads. It doesn’t occur in the PowerVR Emulator, only on actual hardware. While I’m not rendering much geometry, it is written in a way that is stressful on the driver (the N64 had low level access, so it didn’t do much batching etc).
Here’s the symptoms:
- Non rendered tiles, typically in the bottom right corner, sometimes they’re completely black, other times they show the image from a few frames previous.
- Huge slowdown when it occurs. I get maybe 1/10 of the normal framerate.
- Sometimes after a few seconds everything gradually fixes itself and it returns to normal, other times the program crashes.
- Seems to coincide with high OGL driver utilisation, ie the balloons that are released when you start the first race in Mario Kart 64.
- 5% of the time everything just works, i get no corruption / slowdown.
You can see it occurring here: http://www.youtube.com/watch?v=BNHUvR-sKZE#t=3m40
and here: http://www.youtube.com/watch?v=BNHUvR-sKZE#t=4m20
These are the better cases, if necessary i can post some pictures of it occurring more severely.
Thanks
Hello,
The corrupted frames are showing a HW time-out problem, possibly caused by wrong data sent from the drivers to the HW. This could be related, as you mention, to a large amount of glDraw calls which might be exposing a bug in the drivers. This is going to be very difficult to investigate but we can have a look if you have binaries we can run on Beagle Board. Alternatively, it would be of great help if you are able to replicate this problem on a smaller application that mimics the N64 emulator behaviour as close as possible.
Best regards
Carlos.
Hmmm I was afraid it might be a driver issue.
I'm working on an Angstrom based platform.... Hopefully it will work on the beagle. I'm dynamically linking via -lSDL-1.2 -lpng12 -lz -lEGL -lIMGegl -lsrv_um. Here's a zip which contains the mupen64 binary and the plugins:
http://host-a.net/Adventus/Mupen64Plus.zip
To run just extract the zip to a folder then execute "mupen64plus" from the commandline with the 1st argument being the path to the rom you wish to load. A good rom to try is FZERO-X (USA), the first race in the demo sequence often shows the black blocks. Everything isn't totally stable in this release (in particular an assertion fails occasionally), The newer releases have fixed this issue however so i don't think they're related.
I did some crude benchmarking and found that Super Mario 64 has some scenes (ie the mario head) that average ~330 draw calls per frame, and in game about 220 per frame. F Zero-X sometimes has a peak around 280 when you start the race, then that drops to about 100 - 160. SM64 and F-Zero X have about the same average vertices per draw call (~18).
EDIT: I suspect it might have something to do with compiling shaders midframe, large shader compiles seem to coincide with desyncing. F Zero X compiles about 10 shaders before the first demo race.
Thanks,
Adventus2009-12-13 07:04:19
