Le jeu. 3 mars 2022 à 18:28, Michael <
macallan%netbsd.org@localhost> 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