Re: Improved memory detection for cgsix

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Thu, 3 Mar 2022 18:53:02 +0100
Romain Dolbeau <romain%dolbeau.org@localhost> wrote:

> 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.

Makes sense, doing it more fine grained is probably not worth the extra
code.

> > 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...

The cg6's reg property defines a 16MB range, with half of it used for
VRAM. IIRC an SBus slot can occupy up to 256MB of address space.
The xorg driver sets the drawing engine limits to 4096x4096, the docs
seem to imply the actual limit being more like 16K-1x16K-1.
So, if we try to stick to the likely hw limits then the practical limit
would be somewhere around 32MB, and even that would only be accessible
with the fb stride set to 2048.

> 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.

EXA more or less depends on being able to address VRAM by offset +
coordinates with arbitrary pitch, so off-screen pixmaps can be neatly
treated as simple memory ranges.
What it really likes to do is doing xrender operations entirely within
vram, which is why the suncg14 driver grew code to support things like
8bit off-screen pixmaps when running in 24bit. 
If your hw can't do that, off-screen memory is mostly a cache for
frequently used pixmaps.

have fun
Michael