Hyperion Entertainment Message Boards

Hallo devs,

I´ve got a few questions regarding future (RAM, GFx Card RAM) enhancements to the kernel (i think) and would be grateful if someone who knows could answer them or at least point me to the persons/institutions that can.
 
Thanks in advance
 
Please also correct anything if i´m wrong
 
Base question:
Is AmigaOS4 limited to 2 GB RAM overall?
So that even if we´ve got 2GB on a gfx Card it wouldn´t be possible to integrate the whole of this gfx card ram because AmigaOS4 could only use/work with 2 GB max?
Or is gfx Card memory something completely different to the System and "could" be used?
 
 
Regarding System RAM:
 
As far as i understand it the System RAM is limited to 2 GB in total (displayed and usable) in WB/OS.
 
It was communicated some time ago that this barrier is planned to be breached by some (porgramming) trick and usage of some "enhanced" ram flag (or whatever - some enlightement needed here)
 
So, usage of this "beyond 2 GB RAM" (I´ll call it Shadow mem, because i like the sound of it) would be able to fix a lot of problems we(i) are(am) having.
 
1st Q: Is this still being worked on? (An ETA would be nice, thank you)
 
2nd Q: Are there plans to recompile memory hungry OS parts to take advantage of this Shadow mem to reduce normal RAM usage and give it back to other apps? (I´m thinking of things like HDD caches/buffers f.e.)
 
3rd Q: Are there any code examples somewhere of what has to be done to make use of the new Shadow mem in our apps?
           If yes, where could one find those?
           If not, when will they (estimated) be available?
 
4th Q: How much work would be involved adapting apps to use the new Shadow mem? Could it be achieved with a simple "new" compiler flag?
 
5th Q: Will there be visual (OS/WB) feedback to let the user know how much Shadow mem is in use/still available?
 
6th Q: Given a hypothetical Setup with an X1000 and 4 GB RAM, how much of the (right now) closed-out 2 GB Shadow mem could effectively be used? Are the whole 2 GB possible? If not, why not and how much?
 
7th Q: Would some sort of "roll-over" emergency (Shadow nem) - SWAP be possible?
          e.g. Let´s say my System RAM gets filled up to 1.5 GB and instead of freezing or telling me that more RAM is not available it could silently swap everything else out to the Shadow mem...that would efectively make all other questions obsolete actually...and no one would have to worry about rewriting their apps.
 
 
Regarding GFX-Card RAM:
 
If i understand it correctly right now the 256 MB (max) memory gets mapped into the System Memory, which is why there is a loss of approx. 300-400MB of System mem which in turn cannot be used and (reproducable) freeze the System if used anyway.
 
1st Q: Will it be possible to use more than 256 MB gfx mem on gfx cards that feature more? (1 GB to 3 GB are what most cards offer today)
If not, why not? (Is the gfx memory limited to a max of  2 GB aswell)? If yes, when (estimated) will this be available to end users?
 
2nd Q: Will it be possible to map this Ram to the Shadow mem instead of the normal System ram to not fill it up?
 
3rd Q: Would it be possible to "Mount" not used (but available) gfx Card Memory to the System in some sort of ram disk? Like a non-resistant Cache drive?


That would be all for now

oh, and please don't answer with a simple yes or not but elaborate a bit.

Thanks for your attention

I wish I could answer all your questions. Problem is that things are changing as we speak, so almost any answer you get now may become wrong a little way down the track.

Your Q1:
Yes, it is still being developed. As it stands, there is still a limitation of 4 GB overall (minus a bit for hardware registers), since we are only using a 32-bit address space. Don't forget the address space limitation. No process (including the kernel and drivers) can access more than 4 GB until we go to a 64-bit API, which means a new OS. Different processes can access different parts of the 4 GB memory maximum, but the current API means that they must all see different parts of it (privately) and the same parts (publicly). You can't have two processes accessing memory at (what they see as) address range A, while it is actually mapped to ranges B and C for the two processes. AmigaOS can't pass pointers and messages between processes unless they both refer to the same physical addresses. This fundamental problem is not likely to change.

Your Q2:
Yes there are plans to move some system memory requirements to "Shadow" RAM, and we have experimented with some things already. As you suggest, we would like it to be used for things like buffers and caches. However, as it currently stands, the shadow RAM can only be used as "MEMF_PRIVATE", so can't be used for I/O. This prevents it being used for buffers or caches, so they have to be copied into MEMF_SHARED for I/O.

I'll leave it to the experts in each niche to answer your other questions. Perhaps Hans could answer your questions about gfx mem.

Your 'shadow mem' seems like Extended Memory Objects to me.

Search the OS wiki for Extended Memeory and you should find a bare bones example.

Thanks alot both of you.

Anyone else?
I'd really like to get an answer to the gfx ram restrictions

It would be good to know, but answers from Hyperion on future features?! #NDA #notime #yourenotabetatester
If it wasn't for the dedicated indie devs doing their best to answer questions, then there would be scant informed discussion about AmigaOS at all.

Anyone up to answer the questions about gfx card ram restrictions, please?