The Graphics Synthesizer (GS) drivers

[frno7]

The Graphics Synthesizer (GS) frame buffer device driver drivers/video/fbdev/ps2fb.c currently operates in

1. text console mode, via the fbcon driver and its tiled API. It turned out to be a rather good fit. The GS has 4 MiB of local frame buffer video memory that is not directly accessible by the kernel due to its hardware design. No main memory is allocated for the frame buffer, which is a significant saving given that the PlayStation 2 is limited to 32 MiB of total main memory, and mmap is disabled.

   The maximum practical resolution 1920×1080p at 16 bits per pixel is 4147200 bytes, which leaves 47104 bytes for a tiled font, which at 8×8 pixels and at a minimum of a 4 bits indexed texture palette is at most 1464 characters. The indexed palette makes it easy to switch colors. struct fb_tile_ops such as fb_tileblit, fb_fillrect and fb_copyarea are accelerated by GS hardware that is very fast for the kernel via simple DMA (GIF) GS commands. The GS has two CRT merge circuits made for picture-in-picture that are used to accelerate YWRAP in hardware, which is particularly effective for console text scrolling.

   Console text operations are synchronous and therefore work properly in interrupt contexts, with kernel panics, etc. This is essential for debuggability (see also Enable the R5900 breakpoint hardware #27). Various optimisation techniques, such as buffering, can possibly be even faster, but one might want to implement that as a user space console driver via some kind of /dev/gs interface (as explained below) that can do zero-copying of GS commands, etc.

   See also Improve early printk using the Graphics Synthesizer #9 for early printk during booting.

It’s possible to implement a

2. virtual frame buffer mode, similar to the PlayStation 3 in that the whole visible main memory frame buffer is regularly copied to the GS via DMA at vertical blank intervals. This enables mmap, which is required for frame buffer compatibility, but it is otherwise very inefficient and slow. A complete copy of the whole frame buffer is allocated in main memory and GS hardware acceleration is turned off.

An interesting variant,

3. a specific Graphics Synthesizer device driver, is not yet implemented. The GS hardware is essentially a serial device that accepts a series of commands via DMA. A /dev/gs device driver could provide direct access to the GS hardware, which would be very efficient and enable most of the GS features to applications. The main drawback is that this kind of device driver is specific to the GS.

Support the Direct Rendering Manager subsystem?

[frno7]

@sp193, I'm attempting to document the privileged Graphics Synthesizer (GS) registers, and a few bit fields remain unclear. Would you be able to fill in some details?

Specifically, the SMODE1 register has many unknown fields marked with FIXME below. Its CMOD field has some kind of standard (VESA/HDTV) mode apart from PAL and NTSC. Is there a better name than gs_cmod_standard?

The field sizes for SRFSH RFSH and SYNCH1 HS are unknown. The HSEQ and HSVS fields of SYNCH1 are unknown too.

Are more fields symbolical (to be represented with enums) rather than numerical? This is somewhat important because symbols are used whenever appropriate to read/write registers with sysfs. For example, inspecting the PMODE register shows symbols for its fields MMOD, AMOD and SLBG, which is much more helpful than their numerical representations:

# cat /sys/devices/platform/gs/registers/pmode
en1 1
en2 0
crtmd 1
mmod circuit1
amod circuit1
slbg circuit2
alp 0

One or several bit fields can be written simultaneously, so even simple shell scripts can set any conceivable video mode configuration. For example, the SLBG field can be changed with:

# echo "slbg bgcolor" >/sys/devices/platform/gs/registers/pmode

These privileged GS registers and bit fields are at the moment partly unclear:

enum gs_smode1_cmod {
	gs_cmod_standard,	/* FIXME: Better name than standard? */
	/* Reserved */
	gs_cmod_ntsc = 2,	/* NTSC broadcast */
	gs_cmod_pal		/* PAL broadcast */
};

enum gs_smode1_gcont {
	gs_gcont_rgbyc,
	gs_gcont_ycrcb
};

struct gs_smode1 {
	u64 rc : 3;		/* PLL reference divider */
	u64 lc : 7;		/* PLL loop divider */
	u64 t1248 : 2;		/* PLL output divider */
	u64 slck : 1;		/* FIXME */
	u64 cmod : 2;		/* Display mode (PAL, NTSC, VESA, etc.) */
	u64 ex : 1;		/* FIXME */
	u64 prst : 1;		/* PLL reset */
	u64 sint : 1;		/* PLL (phase-locked loop) */
	u64 xpck : 1;		/* FIXME */
	u64 pck2 : 2;		/* FIXME */
	u64 spml : 4;		/* FIXME */
	u64 gcont : 1;		/* Select RGBYC or YCrCb */
	u64 phs : 1;		/* HSync output */
	u64 pvs : 1;		/* VSync output */
	u64 pehs : 1;		/* FIXME */
	u64 pevs : 1;		/* FIXME */
	u64 clksel : 2;		/* FIXME */
	u64 nvck : 1;		/* FIXME */
	u64 slck2 : 1;		/* FIXME */
	u64 vcksel : 2;		/* FIXME */
	u64 vhp : 1;		/* FIXME */
	u64 : 27;
};

struct gs_srfsh {
	u64 rfsh : 4;		/* DRAM refresh FIXME: Number of bits? */
	u64 : 60;
};

struct gs_synch1 {
	u64 hfp : 11;		/* Horizontal front porch */
	u64 hbp : 11;		/* Horizontal back porch */
	u64 hseq : 10;		/* FIXME */
	u64 hsvs : 11;		/* FIXME */
	u64 hs : 21;		/* FIXME: Number of bits? */
};

[sp193]

You should refer to the Sony documentation for the meanings behind the documented registers like PMODE.

Those undocumented registers like SMODE1 were just undocumented. The most official information you can find, is from the official PS2Linux. But they only mentioned the field names.
Everything else you might find on the Internet, were likely derived through experimentation. Other than PS2Linux, everything else went through the EE kernel to get video modes set up.

If you worked with analog video signals, some things like HBP might make sense - it requires domain knowledge that I do not have.

On a side note, setting up a video mode for PS2s requires the DVE to be configured. This device was totally replaced with the SCPH-75000 and later, and was always different on the T10000. On the PC CARD consoles, the access to the DVE required slightly different initialization. In all cases, the register interfaces are undocumented.
You may find some code from dve_reg.S of OPL, as I updated the original version from Kernelloader to support models up to the SCPH-70000.

[frno7]

Thanks! Yes, PMODE is covered by the documentation; it only served as an example in using symbolic text fields with sysfs. I'm happy about how that turned out, since it's so easy and flexible to inspect and configure whatever video mode one may wish for, including all specifics (such as overlays and picture-in-picture) that the Graphics Synthesizer can do, without any ioctls. I think it will be great for applications.

I have gathered as much as I can about SMODE1, SRFSH and SYNCH1. I have also implemented conversion functions from the standard kernel video mode timings notation. For example, the standard Linux frame buffer mode for 1920×1080 at 50 Hz progressive moved 13 px to the right to is

mode "1920x1080-50"
    # D: 148.500 MHz, H: 56.250 kHz, V: 50.000 Hz
    geometry 1920 1080 1920 1080 16
    timings 6734 148 484 36 4 88 5
    bcast true
    rgba 5/0,5/5,5/10,1/15
endmode

One can adjust these standard Linux frame buffer notation timings quite freely to adjust screen margins, refresh rates, etc. and the GS registers are recomputed accordingly.

You may find some code from dve_reg.S of OPL, as I updated the original version from Kernelloader to support models up to the SCPH-70000.

Thanks! What does the abbreviation DVE stand for? Are the DVE registers in dve_reg.S needed if the GS is reset? The Linux GS driver does not yet reset the GS, as it currently relies on the GS already being setup at boot. The GIF is reset, though.