Re: Improved memory detection for cgsix

Le jeu. 3 mars 2022 à 18:28, Michael <[email protected]> a écrit :
> Maybe fbmapped is supposed to be the amount mapped by OBP?

It is, looking at a disassembled PROM (two; 501-2325 & 501-2253).
But that could simply be because the 'map' function and the attributes use
the same constant...

> But if
> that's the case, why would they map more than the visible screen?

The amount mapped (/frame) is hardwired as a constant, to 1 MiB (501-2325
TGX) and 2 Mib (501-2253 TGX+). That constant is also used to define
'fbmapped'.
The total size (/vmsize) is also defined as a constant, to 1 and 4
respectively.

My guess is, it's easier to do it that way in the PROM, as it will be the
'main' use case: regular TGX were most likely to run at 1152x900, and TGX+
to be at 1152x900 or 1280x1024 and using double-buffering.
And while the PROM doesn't use VRAM beyond the visible screen, X11 (or
SunView, NeWS, OpenWindows, ...) could likely use it the same way EXA does.
And the second buffer needs to be the same size and alignment as the
primary one, in all likelihood.

> As for X11, the driver will likely use up off-screen memory pretty
> quick (...)

Thanks for the explanations.
Makes me wonder what the upper useful bound would be - I've limited my own
version of the cg6 to 4 or 8 MiB, but I have 256 MiB available on my
board...

I'm guessing it works the same way for all framebuffers, so extra space
beyond the FB would be useful for a hypothetical custom 24-bits accelerated
SBus framebuffer? 256 MiB could actually be useful for that use case.

Cordially,

-- 
Romain Dolbeau