Port-sparc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Improved memory detection for cgsix



On Sat 26. Feb 2022 at 23:25, foo bar <tokenalt%gmail.com@localhost> wrote:
On Sat, Feb 26, 2022 at 8:47 PM Michael <macallan%netbsd.org@localhost> wrote:
>
> Hello,
>
> On Sat, 26 Feb 2022 16:48:07 -0800
> foo bar <tokenalt%gmail.com@localhost> wrote:
>
> > So recently I got my hands on a GX+ (501-2039) and when I tried it out
> > on netbsd I noticed that it only detected 1M or vram instead of the 4M
> > the card has. Looking through the source code I found this.
> >
> > src/sys/dev/sbus/cgsix_sbus.c: line 175
> >
> >     sc->sc_ramsize = prom_getpropint(node, "fbmapped", 1024 * 1024);
> >
> > However when I looked at the attributes of the GX+ I saw it didn't
> > even define an fbmapped at all, but it does have a vmsize = 4. Then I
> > checked a GX (501-1996) and it also does not have fbmapped but it does
> > have vmsize = 1. Finally I check a TGX+ clone w/ 2M of vram and it
> > does have fbmapped = 2M and it also has vmsize = 2. Based on this
> > limited sample size I believe the fbmapped attribute was added in the
> > TGX line. Attached below is a patch to check both attributes which
> > correctly detects the memory size on the cards I have.
> >
> > After that I ran into a second problem in that the xserver would only
> > map 2M of ram. Looking at the code I found the xdriver doesn't detect
> > the memory size at all it just blindly tries to map memory til it
> > succeeds. I wasn't sure how to add memory detection to the driver so I
> > just raised the max amount it would try to 4M, patch below.
> >
> > With these changes my GX+ is now properly detected as shown here.
> >
> > [     1.000003] cgsix0 at sbus0 slot 1 offset 0x0 level 9:
> > SUNW,501-1717, 1152 x 900, rev 7
> > [     1.000003] cgsix0: attached to /dev/fb0
> > [     1.000003] cgsix0: framebuffer size: 4 MB
> >
> > [   305.720] (II) SUNCG6(0): mapped 4096 KB video RAM
> > ...
> > [   305.916] (II) EXA(0): Offscreen pixmap area of 3156480 bytes
>
> This isn't going to work, unfortunately, and here's why.
> The 4MB CG6 all have two independent 2MB framebuffers, for double
> buffering, which can not be combined into one big framebuffer.
> That's why fbmapped never shows more than 2MB, even on 4MB boards.
> There are bits which control what you access through the framebuffer
> mapping - you can direct reads to either buffer, and writes can go to
> either or both at the same time.
> If you try to map more than 2MB framebuffer you'll either hit unmapped
> space or a repeat of the buffer after 2MB.
> Same goes for the drawing engine.
> The cg6 in the sparcstation LX is a special case - it's got 1MB
> soldered in but you can add another 1MB as a VRAM module. This thing
> can be used as either 2x 1MB with double buffering, or as a single 2MB.
> Unfortunately we don't have that option with 4MB boards, those are
> always double buffered.
>
> I'd love to be proven wrong on this though.
> I have a bunch of different cg6 here, at least a few of them are plus
> variants. I'll do some experiments.
> I'd suggest to write a program that maps the space, scribbles into it
> beyond 2MB and checks where that scribbling actually ends up.

I can cite an historical document that says it is possible at least on
the tgx+. Sun's "TurboGXplus Accelerator Features" from 1993. On page
11 it talks about off screen memory and says the memory can be mapped
either as two 2MB frame buffers or one 4MB frame buffer and the
maximum amount of off screen memory is 3.25MB when running at 1024x768
single bufferd.

This is about the only source I can find for the document tho, it
doesn't seem to be anywhere else that I can find.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.3716&rep=rep1&type=pdf

Hi,

for the TGX+ I can say for certain that it does support single buffered mode.  The firmware/fcode checks if (width * height *2) <= vmsize (4mb) and if so enables double buffering and sets the dblbuf property accordingly.  This is interesting since no resolution requiring more than 2mb was officially supported.  The chipset does support acceleration for resolutions with widths of 2048 at least, maybe higher (if anyone has a copy of the TurboGX Reference Card 800-5112 I would love to check.)

I run my tgx+ at 1920x1200 which requires more than 2mb (and a little bit if work.) If anyone wants to do the same, you can do this by editing nvramrc.  Romain has some code to make that easier here: https://github.com/rdolbeau/SunTurboGX .  If you don’t mind making hardware changes, you can also replace the eeprom and use a modified firmware which you can find here: https://github.com/1k5/tgx-plus-vesa-mod (sorry, not well documented.)

I don’t have a GX+ so I can’t say how double buffering works there, but my GX (501-1672) does set vmsize and dblbuf even though dblbuf is always 0.

@foo bar: Is there any way I can talk you into sending me the firmware for the GX+ as well as for the 2mb TGX+ clone?  I would love to have a look at them.  I can talk you through the process of extracting fcode/firmware.

Cheers,
Malte



Home | Main Index | Thread Index | Old Index