performance work

Neil Graham Lerc at
Wed Dec 31 08:48:55 EST 2008

On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote:
> > I'm curious as to why reads from video memory are so slow,  On standard
> > video cards it's slow because there is quite a division between the CPU
> > and the video memory,  but on the geode isn't the video memory shared in
> > the same SDRAM as Main memory. 
> It is, in that they share the same physical RAM chips, but they are 
> controlled by different entities - one is managed by the system memory 
> controller and the other is handled by the GPU.   At start up time, the 
> memory is carved up by the firmware, and after the top of system RAM is 
> established, video and system memory behave for all intents and purposes 
> like separate components.  Put simply, there is no way to directly 
> address video memory from the system memory.  Access to the video memory 
> has to happen via PCI cycles, and for obvious reasons the active video 
> region has the cache disabled, accounting for relatively slow readback.

That makes my brain melt, you can't address it even though it's on the
same chip!?!  Even as far back as the PCjr the deal was that sharing
video memory cost some performance due to taking turns with cycles but
it gave some back with easy access to the memory for all.   Has the
geode cunningly managed to provide a system that combines all the
disadvantages of separate memory with all the disadvantages of shared?

One wonders what would happen if you wired some lines to the chips so
that the memory appeared in two places,  would you get access to the ram
(with the usual 'you pays your money, you takes your chances' caveats
about coherency)

I'm not a hardware person, but that all just seems odd.

> That said, the read from memory performance is still worse  then you
> might expect - I never really got a good answer from
> the silicon guys as to why. 
being hit with the full sdram latency every access maybe?

Is it feasible to try with caches enabled and require the software to
flush as needed.

More information about the Devel mailing list