Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

Video Format Object (VFO) Files

From Higher Intellect Vintage Wiki
Revision as of 20:59, 30 July 2019 by Callahan (talk | contribs) (Added subheadings, limitations, strikethrough abandoned text)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Video format objects are microcode images loaded into SGI graphics display hardware to generated the timing signals required to produce display images at specific resolutions and refresh rates. Vfo's are generated using SGI's Video Format Compiler (VFC) and end-user prepared video format source (vfs) files. VFC is not installed by default with IRIX, so you must install it separately if you wish to create custom video format files.

System Compatibility

Video format object microcode is not binary compatible between different hardware types. Although vfc is independently re-targetable to a number of different hardware types, video format objects that were compiled to run with one hardware architecture will not necessarily run on another. For example, video format objects created for Infinite RealityTM will not work properly on Impact. As another example, a vfo file created for an Octane SI graphics card will not work with an Octane 2 V8. However, a file created for an Indigo2 Solid Impact will also work with an Octane Solid Impact (but not/not 2RSS cards such as the SSI/SSE/MXI/EMXI). VPro .vfo files are interchangeable.

Block Sync Templates, Video Format Source Files, and EDID

Generally speaking, video format objects (vfos) can be created using one of two methods:

  1. By use of a block sync template - because no user-defined format source file is needed, this method is quick and easy to use. Because it the lacks specific monitor, resolution and format timing details that can be included in a source file, it produces the most generically targeted microcode.
  2. By creating a video format source (vfs) file - video format source files offer the ability to tailor the microcode for specific resolutions, refresh rates and even monitors.

Most modern monitors automatically transmit Enhanced Display Identification Data (EDID) data that defines the monitor's detailed preferred video format, including all data needed to create a custom .vfs file. This data can be extracted using widely available Linux/Unix tools such as get_edid/parse_edid or directly from display drivers on many Windows systems. There is also a large repository of monitor-specific EDID data at this github page). This github page has an template that easily generates a custom .vfs file using monitor-specific EDID. If EDID is not available (for example, on older monitors), specific format values might also be obtained from the (monitor) manufacturer.

If neither of those methods is available, then there are a number of display modeline generators that offer all of the timing values needed to complete a video source file. Generated modelines won't necessarily contain the same values as provided by the manufacturer or EDID information for a particular monitor, but should still provide microcode that is reasonably well targeted to specific resolutions and refresh rates.

SGI included a number of video format source code files with the installation of the Video Format Compiler. The comments section of those source files indicate most were intended for use with some of CRT monitors marketed by SGI. This includes all of the wide-format for which source files are available. As a result some of the SGI vfo microcode provided for wide-screen displays does not always produce a stable displays when used with more recent LCD monitors.

Modern LCDs and Reduced Blanking

Modern LCD monitors that don't work well with the CRT-targeted vfo-microcode supplied by SGI may see improvement if used with a format that includes reduced blanking. Reduced blanking lowers display format overhead needed to allow CRT screen redraws, overhead that doesn't benefit and may adversely affect LCD monitors. Any LCD monitor new enough to take advantage of reduced blanking may benefit when using a custom .vfo/.sdb file.

Reduced blanking can also allow much greater resolution and refresh rates on systems with relatively low pixel clock restrictions, such as IMPACT boards. Using reduced blanking, even low end IMPACT systems have been proven to support resolutions of 1920x1200 at ~60 FPS.

Compiling a Custom .vfo/.sdb file

Creating and using a custom vfo file for an SGI computer is a multi-step process.

  1. Build a plain text input file, customarily with the .vfs extension, using the EDID for the monitor in question.
  2. Compile the .vfs file using the vfc command and the appropriate pre-compiler options. Some hardware, such as IMPACT graphics on Octane and Indigo2 systems, require long pre-compiler option strings.
  3. Name the output file appropriately. VPro systems use the .vfo extension, while IMPACT systems use the .sdb extension.
  4. Place the file in the appropriate subfolder of /usr/gfx/ucode/, such as /usr/gfx/ucode/ODSY/vof/ (for VPRO) or /usr/gfx/ucode/MGRAS/vof/2RSS for Max Impact Indigo2 and Octane systems, as well as Octane SSI/SSE systems. This will enable selecting the new resolution using the GUI Display Options tool.

VFC Command and Precompiler Options

Using VFC to create a custom .sdb file for IMPACT graphics requires setting many pre-compiler options. An example VFC command is:

vfc -a ascii=vfsname.info -c board=/usr/gfx/ucode/vfc/rules/mgras.def,chip=/usr/gfx/ucode/vfc/rules/mgras_vc3.def -p "-DRSSCOUNT=2" -p "-DDB32=1" -p "-DINTERLACED=0" -p "-DSTEREO_FMT=0" -p "-DOPTIONS=0" -p "-DZBUF=1" -p "-DVERT_SERRATION=0" -o vfsname.sdb vfsname.vfs

A breakdown of the VFC and precompiler options for a MGRAS system:

  • "-a ascii=vfsname.info": Writes a summary with key resolution and frame data to the file vfsname.info
  • "-c board ...,chip ...":specifies the appropriate files for IMPACT/MGRAS graphics.
  • "-p": Specifies a command passed to the pre-compiler
  • "-DRSSCOUNT=2": Specifies the number of raster engines. Octane SSI/SSE/MXI/EMXI and Indigo2 Max Impact have two raster engines. Other Impact boards have one (Octane SI/SE and Indigo2 Solid and High Impact)
  • "-DDB32": Set to 1 to enable large double buffered visuals
  • "-DINTERLACED=0": Non-interlaced
  • "-DSTEREO_FMT=0": Not stereo (e.g. not for use with 3D glasses)
  • "-DOPTIONS=0": There are three "options" (0,1,2) that change how the pre-compiler computes blanking periods and possibly other things. If you understand what this does exactly, please update this wiki. Options 0 and 2 seem to work well with reduced blanking LCD files, while option 1 often does not.
  • "-DZBUF=1": Enable Z-buffered visuals
  • "-DVERT_SERRATION=0": A serrated vertical sync pulse may be required for some interlaced modes
  • "-o vfsname.sdb": Name of output
  • "vfsname.vfs": Input

Using VFC to create a .vfo file for VPro systems is more straightforward. An example command for VPro/ODYSSEY boards is:

vfc -a ascii=vfsname.info -c chip=/usr/gfx/ucode/vfc/rules/VPro_Chip.def,board=/usr/gfx/ucode/vfc/rules/VPro_Board.def -o vfsname.vfo vfsname.vfs

A breakdown of the VFC options for a VPro system:

  • "-a ascii=vfsname.info": Writes a summary with key resolution and frame data to the file vfsname.info
  • "-c board ...,chip ...":specifies the appropriate files for VPro graphics. Note this is case-sensitive!
  • "-o vfsname.sdb": Name of output
  • "vfsname.vfs": Input

Limitations and Workarounds

All systems:

  1. When using a pixel-based (in contrast to a time-based) .vfs input, the total blank lines (HorizontalTotal-HorizontalDisplay) must be divisible by 8.

IMPACT:

  1. Pixel clock cannot exceed 160MHz.
  2. Framebuffer usage (total active pixels*bits per pixel) cannot exceed 13.5MB (1RSS) or 27MB (2RSS).
  3. Some users have noted visual artifacts on IMPACT systems with modern LCDs using high resolutions (such as 1920x1080) and the monitor's native EDID resolution. These artifacts have been reduced or eliminated by incrementally increasing the blanking in the custom .vfs file.

VPro:

  1. Vertical display lines cannot exceed 2048.
  2. V6/V8 cards cannot have a pixel clock between 109MHz and 193MHz. See V6/V8 Pixel Clock Issues.
  3. DCD-equipped VPros require dual channel display modes ([email protected]) with a horizontal resolution that is a multiple of 64.

SGI O2:

  1. O2 graphics have a limitation of 2160 TotalPixelsPerLine. VFO microcode generated from a reduced blanking modeline will typically lower the TotalPixelsPerLine value. As an example, a CVT-generated modeline for [email protected] without a reduction in blanking results in 2240 TotalPixelsPerLine, which would generate a VFC error rather than usable microcode.

Example VFO Files

NOT Attached are a number of video format object (vfo) files sorted by target resolution. The intended graphics hardware platform within each listed resolution can be identified by the file prefix. Currently all include reduced blanking, indicated by the letters "rb" following the refresh rate (e.g. V10-V12_1920x1200_60rb.vfo). The reduced blanking modelines used were generated with the IRIX port of CVT graciously provided by rooprob.

Please note that the attached vfo files may not work with every monitor. Some monitors many not support reduced blanking or may require a source file specifically tailored from EDID data or a manufacturer provided modeline. I'll consider creating those (or resolutions not currently included) on a case-by-case basis, just post a request in this thread.

[email protected] with reduced blanking:

 # 1280x1024 @ 60.00 Hz Reduced Blank (CVT)
 #   field rate 59.96 Hz; hsync: 63.19 kHz; pclk: 91.00 MHz
 Modeline "1280x1024_60.00_rb"  91.00  1280 1328 1360 1440  1024 1027 1034 1054  +HSync -Vsync

File comment: Reduced blanking lowered the pixel clock from 109.81KHz, which would be unusable on a V6 or V8, to 91.23KHz, which would work with a V6 or V8, even if set in 16 bytes/pixel mode.

 V6-V8_1280x1024_60rb.vfo [8.14 KiB] 


[email protected] with reduced blanking:

 # 1440x900 @ 60.00 Hz Reduced Blank (CVT)
 #   field rate 59.90 Hz; hsync: 55.47 kHz; pclk: 88.75 MHz
 Modeline "1440x900_60.00_rb"  88.75  1440 1488 1520 1600  900 903 909 926  +HSync -Vsync
 V6-V8_1440x900_60rb.vfo [8.23 KiB] 
 O2_1440x900_60rb.vfo [12.14 KiB] 


[email protected] with reduced blanking:

 # 1440x900 @ 60.00 Hz Reduced Blank (CVT)
 #   field rate 59.90 Hz; hsync: 55.47 kHz; pclk: 88.75 MHz
 Modeline "1440x900_60.00_rb"  88.75  1440 1488 1520 1600  900 903 909 926  +HSync -Vsync
 V6-V8_1600x900_60rb.vfo [8.27 KiB] 
 O2_1600x900_60rb.vfo [12.14 KiB] 


[email protected] with reduced blanking:

 # 1680x1050 @ 60.00 Hz Reduced Blank (CVT)
 #   field rate 59.88 Hz; hsync: 64.67 kHz; pclk: 119.00 MHz
 Modeline "1680x1050_60.00_rb"  119.00  1680 1728 1760 1840  1050 1053 1059 1080  +HSync -Vsync


 V10-V12_1680x1050_60rb.vfo [8.51 KiB] 
 O2_1680x1050_60rb.vfo [12.14 KiB] 


[b][email protected] with reduced blanking:

 # 1600x1200 @ 60.00 Hz Reduced Blank (CVT)
 #   field rate 59.92 Hz; hsync: 74.01 kHz; pclk: 130.25 MHz
 Modeline "1600x1200_60.00_rb"  130.25  1600 1648 1680 1760  1200 1203 1207 1235  +HSync -Vsync

 V10-V12_1600x1200_60rb.vfo [8.27 KiB] 
 O2_1600x1200_60rb.vfo [12.14 KiB] 
 IR_1600x1200_60rb.vfo [17.58 KiB] 


[email protected] with reduced blanking:

 # 1920x1080 @ 60.00 Hz Reduced Blank (CVT)
 #   field rate 59.93 Hz; hsync: 66.59 kHz; pclk: 138.50 MHz
 Modeline "1920x1080_60.00_rb"  138.50  1920 1968 2000 2080  1080 1083 1088 1111  +HSync -Vsync
 V10-V12_1920x1080_60rb.vfo [8.38 KiB] 


 IR_1920x1080_60rb.vfo [17.58 KiB] 


[email protected] with reduced blanking:

 # 1920x1200 @ 60.00 Hz Reduced Blank (CVT)
 #   field rate 59.95 Hz; hsync: 74.04 kHz; pclk: 154.00 MHz
 Modeline "1920x1200_60.00_rb"  154.00  1920 1968 2000 2080  1200 1203 1209 1235  +HSync -Vsync


 V8-V10-V12_1920x1200_60rb.vfo [8.38 KiB] 
 IR_1920x1200_60rb.vfo [17.58 KiB] 

See also