Paul Guyot wrote:
> If you just do this with more than 32 KB, you're in big trouble.
> Otherwise, it's just like buffering to what you call the C++ heap.
>
> You don't need to actually put the VBO into a soup, but you need to
> call ClearVBOCache() say every 32 1K page changed.
>
> Cf:
> http://newyork.unna.org/unna/apple/documentation/developer/QAs-2.x/html/vboreset.htm
>
> It's only when this function is called that the VBO data is actually
> written to the store.
Thanks for the information!
The problem seems to be that the Newton OS holds the dirty pages of a
VBO in memory (system heap) until it is being committed via
ClearVBOCache or EntryChangeXmit and that these dirty pages eat into the
available system heap. If other applications now also demand more memory
from the system heap until there is no more memory available, the Newton
resets. Sounds reasonable.
I also figure that the same would happen if I allocate system heap
memory through other means, so I take the warning in the Q&As as "The
whole VBO stuff might look like NewtonScript only, but it can give you
trouble on the system side" as opposed to pure NS stuff which (with some
exceptions like comms) can be dealt with in low memory situations as it
does not affect the system heap to that extent.
Anyway, I think the 32k figure is a bit conservative for MP2100s which
have about 3MB system heap available after restart... my approach of
using non-committed VBOs would use about 180k of system heap. Let's see
how far we get with this, if people observe resetting Newtons, then it's
time for optimizations. The core decoder doesn't need that much memory,
it's just the playback part...
> If something goes wrong, what tells you that all the references to
> your NS buffer will be removed? I can't see the difference.
I don't know enough about the GC implementation in the Newton but I
would imagine that if I have one NS object that references one VBO and
then the NS object can be GC'ed, the memory taken by the VBO can also be
reclaimed.
If I however have one NS object (say an integer) that translates to a
pointer to a memory region allocated on the system heap and then the NS
object is GC'ed, the GC does not know that this object actually points
to memory on the system heap which still needs to be deallocated.
> Not really. I bet the Voyager chipset uses DMA (well, sort of since
> it's he who accesses the DRAM, the CPU only accesses the ROM and the
> Voyager chipset).
I think it would be nice to tell Voyager "play this memory region and
give me an interrupt when done" to avoid doing too much on the
NewtonScript side like dealing with protoSoundChannel. This could be
more efficient...
>>A different way to do all this would be to implement a codec (actually,
>>only the -dec part might be feasible), but I'm not sure if we have the
>>complete tool set for that.
>>
>
> Oh, all you need is an hex editor ;)
... which I have ;) hmmm perhaps a disassembler would also help.
Eckhart
--
-- eck_at_40hz.org -- www.40hz.org --
--
This is the Newtontalk mailinglist - http://www.newtontalk.net
To unsubscribe or manage: visit the above link or
mailto:newtontalk-request_at_newtontalk.net?Subject=unsubscribe
This archive was generated by hypermail 2.1.2 : Sat Dec 01 2001 - 20:04:10 EST