<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
 
<article>

<!-- Title information -->
<title> Information for SiS Users
<author> Xavier Ducoin (<it>xavier@rd.lectra.fr</it>)
<date> June 25 1999

<!-- Table of contents -->
<toc>

<sect> Introduction <p>

This driver was primarily written for the SiS86c201.  It also works
on the 202 , 205 and 5597/5598 chips. Support for 6326, 530 and 620
has been added since.
Some support for SiS86c215 and 225 was added as well. This support consists
simply in 
identify it as 205, so probably 86c215 won't work with acceleration 
(is a cheap 205 without some features).

The driver supports many advanced features.  These include:
<itemize>
  <item>Linear Addressing
  <item>8/15/16/24 bits per pixel
  <item>Fully programmable clocks are supported
  <item>H/W cursor support
  <item>BitBLT acceleration of many operations
  <item>XAA support (XFree86 Acceleration Architecture)
</itemize>

<sect> Supported chips <p>

<descrip>
<tag>SiS 86c201</tag>
	(External hardware clock)
<tag>SiS 86c202, SiS 86c2x5, SiS 5597/5598, SiS 6326, SiS 530, SiS 620</tag>
	(Internal clock synthesizer)
</descrip>

Color expansion is not supported by the engine in 16M-color graphic mode.

<sect> XF86Config Options <p>

The following options are of particular interest for the SiS driver. Each of
them must be specified in the `svga' driver section of the XF86Config file,
within the Screen subsections of the depths to which they are applicable
(you can enable options for all depths by specifying them in the Device
section).

<descrip>
<tag>Option "set_mclk"</tag>
        This option lets you to modify the memory clocking of your card.
        (only for 5597 and 6326) Modifying the memory timings can destroy the 
	device, but usually the only ill effects of overclocking is to 
	have some noise an drawing errors, but BE CAREFUL. Usually a little 
	increment can improve the drawing speed, and allows also higher dotclocks. 
	The server reports default memclock on starting messages, so take it
	as a base. Units are in MHZ.
<tag>Option "dac_speed"</tag>
        This option lets you to modify the maximum allowed dotclock (only for
	5597 and 6326).	Without it, the server makes a conservative guess 
	based on memory clock, speed and number of banks. If your monitor 
	supports higher dotclocks and you know that your card can do it, give a 
	try. If the speed is too high for your configuration (but not for your
	monitor), the effects can vary from some noise on screen to a black 
	screen. Don't use speeds greater than 135 Mhz, (175 for 6326), even 
	if your monitor supports the dot-clock. 
<tag>Option "noaccel"</tag>
	By default the XAA (XFree86 Acceleration Architecture) is used.
	This option will disable the use of the XAA and will enable the old
	BitBlt acceleration operations. (see below).
<tag>Option "hw_clocks"</tag>
	On chips 86c202 and later, the default is to use the programmable
	clock for all clocks. It is possible to use the fixed clocks
	supported by the chip instead of using this option (manufacturer
	dependent).
<tag>Option "sw_cursor", "hw_cursor"</tag>
	The default is for using the hardware cursor.
<tag>Option "no_linear"</tag>
	By default linear addressing is used on all chips.
	However this might be broken in some implementations. It is
	possible to turn the linear addressing off with this option.
	Note that H/W acceleration and 16/24bpp are only supported with
	linear addressing.
<tag>Option "no_bitblt"</tag>
	This option will disable the use of all the BitBLT engine.
	It is useful for problems related to acceleration problems.
	In general this will result in a reduced performance.
<tag>Option "no_imageblt"</tag>                                              
	It is useful for problems related to image writing, and possible                 
	stipple acceleration problems. In general this will result in a reduced          
        performance.                                                                     
<tag>Option "ext_eng_queue"</tag>
	5597/8 and 6326 have the option to extend the engine command queue on
	VRAM. With extended queue length, the driver only checks queue status 
	on some color-expansion commands. This gives some performance improvement, 
	but is possible to lose some commands, corrupting screen output. As the 
	size of extended command queue is 16-32K, the probability is very low, but
	exists. The performance gain observed is around 8-10%. Currently, using
	this option with xaa_benchmark freezes the acceleration engine, causing 
	weird image display.
<tag>Option "pci_burst_on"</tag>
        This set a bit on some registers. Although documented, the utility of 
	this option is unknown for me. I can't see any difference on stability 
	or performance.
<tag>Option "fast_vram"</tag>
        Enables 1 cycle memory access. Try it. Increased memory bandwidth reduces
	the possibility of glitches and noise on high resolution modes. 
<tag>Option "fifo_moderate","fifo_conservative","fifo_aggressive"</tag>
        These options modify the arbitration thresholds on CRT FIFO. Fifo_aggressive
	gives more time to CPU for accessing the VRAM. Fifo_conservative reduces 
	the possibility of noise caused when the CRT tries to read memory when 
	it is used by CPU, but reduces performance. The default is between 
	aggressive and moderate (more aggressive than moderate).
	 

</descrip>


<sect> Modelines <p>

When constructing a modeline for use with the Sis
driver you'll need to consider several points:
<itemize>
  <item>H/W Acceleration.  The H/W cursor, and fill operations
	currently allocate memory of the video ram for there own use.
	If this is not available these functions will automatically be
	disabled. Also, ext_eng_queue allocate 32k of Vram. 
  <item>Dot Clock. SiS documents the following video modes to work with 
        6326. The max dot clock allowable for your 6326 based board depends 
	also on the memory installed on it. Option fast_vram can be needed 
	for high dot clocks to work. Of course, the memory installed must
	allow 1 cycle R/W. The server tries to avoid problems with high 
	dotclocks, limiting the maximum based on estimated memory bandwidth.
	Overriding the limits with dac_speed and modelines can damage the 
	card if you exceed the card limits. Values between driver guess and
	chipset limits are acceptable, but can cause bad image quality, noise 
	or no image displayed. 
   <itemize>
        <item>SiS recommended video modes for 6326: 
        <item>   640x480  : 4, 8, 15, 16, 24 bpp at 85Hz Non-interlaced
        <item>   800x600  : 4, 8, 15, 16, 24 bpp at 85Hz Non-interlaced 
        <item>  1024x768  : 4, 8, 15, 16, 24 bpp at 85Hz Non-interlaced
        <item> 1280x1024  : 4, 8, 15, 16, 24 bpp at 75Hz Non-interlaced
        <item> 1600x1200  : 4, 8  bpp at 65Hz Non-interlaced
   </itemize>	 
</itemize>

<sect> Troubleshooting <p>

The generic VGA driver doesn't work with 6326, so XF86Setup can't be used
for this card. Please use xf86config instead.

With intensive generation there is a snow phenomenon on the screen.
Can't remove it even if I used the fifo low/high water mark dumped
from W95. 

The latter point is changed. Now we use calculated values for the fifo
settings, and this appears to be stable until the bandwidth required for CRT
is near the memory bandwidth (dotclock*depth/8 near Mclk*32 or Mclk*64 ). 
In that case, you could try to use fifo_moderate, fifo_conservative or a lower
dotclock.

Some video modes with high dot-clocks don't work at all, resulting on black 
screen. We are tracing now this problem. Lowering dotclock in that case could 
solve the problem. 

<verb>
Updated June 25, 1999 by Dirk Hohndel, covering changes for 530 and 620.
Updated October 12, 1998 by Juanjo Santamarta, covering changes for 5597 and 6326.
Updated November 6, 1998 by Juanjo Santamarta, covering changes for 5597, 86c2x5 and 6326.
</verb>

<verb>
$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.3.2.7 1999/06/25 08:57:14 hohndel Exp $
</verb>
</article>
