rohezal said:
I read it was 90 MB/s. But how thin is the bus? Even with 1 bit it should be 90/8 around 11 MB/s. A normal PCI 1.0 bus has 32 bit. Strange. But hey, now I know there the bottleneck is.
It's not a serial bus, it's parallel data/address over an asynchronous interface on the SoC's external memory interface. You can see from the schematics that the bus width is 16-bit, but transfers are obviously not one clock cycle. Some fixed number of waitstates on the CPU side are enforced, then the Glamo can further stall things using the nWAIT line when bus contention with its internal VRAM occurs. The contention shouldn't be that frequent, but apparently the nWAIT periods are frequent and long.
The 7.3MB/s number came from TheRasterman back in April 2008. I don't know how he got it, maybe by benchmarking. This amount would probably be aggregate over a long period of time because the actual number of clock cycles an access takes fluctuates.
Internally, the Glamo is probably performing operations synchronous with its clock. So, so long as it still works after the overclock it should be true that the internal waitstates due to contention would be lowered, and apparently it's also true that the external waitstate requirements were lowered. But I can't tell how much from your post, and I can't find any numbers. I do know the 7.3MB/s figure came before the update you're referring to, but I also worked with the Freerunner after that and performance was abysmal, so it couldn't be that substantial.
From what I can gather, the Glamo is really supposed to get data over a synchronous burst interface, but the SoC used can't natively interface it. The async interface was probably meant for accessing registers, not transferring data. If I had the datasheet I could say more. I think picking an accelerator chip that doesn't even have a datasheet available outside of NDA for an "open" device was a pretty bad move. Then when they did any kind of timing analysis or breadboarding against the chip and realized how horribly slow the configuration is they should have just thrown it out. I don't know what made them think the 2D acceleration provided was worth having such a slow framebuffer over, or maybe they were lured by the prospect of eventually having really primitive 3D (which they should have known was not forthcoming). The internal display controller on the SoC might be gimped too, but so long as it runs off of the same SDRAM the CPU writes to it should be much, much better.
rohezal said:
PAL televisions have "half frame". First frame: line 1,3,5,7,9,11 ... Second frame: line 2,4,6,8,10 ...
Is it possible to write just half frame to the glamo and save 50% of the bandwith? So we use only 2,2 MB/s and have around 60-70% of cpu time (Why is the glamo blocking the cpu anyway, !"$%&/()). Maybe we can update an outer 10 pixel boarder only every 4th or 6th frame because its in most games not very important and save a bit speed too. The sound issue is surely from the blocked cpu while the image is transfered. Hmm ok I see now some problems. Thank you guys
.
You have to ask yourself, is interlacing better than skipping/repeating frames? Interlacing was used on TVs because the screen refresh rate was necessary for the technology, and the display couldn't be repeated because it was transmitted a scanline at a time and not stored per-frame in a framebuffer. The industry has since viewed deinterlacing as a positive step to negate this process and progressive scan to generally be the better option. LCDs like the one on Freerunner are probably not at all well suited for it.
Another problem, one I've personally encountered on the device, is that if you only update part of the screen you can't perform double buffering. Without double buffering the only way to get a tear-free display is to upload the new frame entirely during the vertical blank period, which is often pretty small on LCDs, especially high resolution ones. So you'd be taking a heavily bandwidth limited interface and perform transfers at vsync (may not even have an exposed method on Freerunner's kernel), where now instead of having an entire frame to update you only have a fraction of it. This is of course assuming that the kernel can double buffer the Glamo, but that'd be pretty sad if it couldn't.
I want to try it
. Playing SNES on the phone would just rock. But maybe with sme real controller parts. Some eletro engeeners from my university are going to make one for me. In exchange I have to write C code for their micro controllers^^
Good luck with that then, let me know how it ends up working..
