SGI: Hardware

VFO: Video Format Object Files
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. Video format object (vfo) microcode is typically generated using SGI's Video Format Compiler (VFC) and end-user prepared video format source (vfs) files.

As mentioned in the vfc man page , vfo files are hardware specific:

The vfc man page wrote: 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 Reality will not work properly on Impact.

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

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

• 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. Monitor specific format values can be obtained from the (monitor) manufacturer, or in the case of some more recent displays, extracted from the monitor firmware in with EDID reader/decoder software (EDID information or manufacturer provided modelines can sometimes be found with a web search). 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 includes 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 written specifically for use with some of the 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.

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 . Reduced blanking is primarily intended for use with DVI-connected LCD monitors, but any LCD monitor new enough to take advantage of reduced blanking *may* also benefit when connected via the VGA port.

Graphics hardware errata:

• The first generation of Octane VPro graphics boards, the V6 and the V8, can not generate display resolutions that have a pixel clock between 109MHz and 193MHz. This limits the ability of the V6 and V8 to use a number of common display resolutions, a situation that can be at least partially over come with the use of reduced blanking. As an example, a CVT-generated 1600x900@60Hz modeline without reduced blanking would have a Pixel Clock of 118.25MHz, which falls in the unusable 109-193MHz Pixel Clock range

  Code: Select all

  Modeline "1600x900_60.00" *118.25* 1600 1688 1856 2112 900 903 908 935 -HSync +Vsync
  while a modeline with reduced blanking would have a Pixel Clock of only 97.75MHz, which could be used by V6 or V8 graphics boards.

  Code: Select all

  Modeline "1600x900_60.00rb" *97.75* 1600 1648 1680 1760 900 903 908 926 +HSync -Vsync

• VPro graphics have a maximum screen height of 2048 pixels. Exceeding that amount will generate a VFC error:

  Code: Select all

  Screen height is greater than 2048.000000 pixels. Decrease ActiveLinesPerFrame

• DCD-equipped VPros require dual channel display modes (2@) with a horizontal resolution that is a multiple of 64. 1440x900 and 1680x1050 are relatively a common wide-screen formats with horizontal resolutions that aren't multiples of 64; attempting to compile dual channel microcode in either format will generate the following error message:

  Code: Select all

  DualHead Formats must have a screen boundary at a multiple of 64.  Make ActivePixelsPerLine a multiple of 64.

• 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 1680x1050@60Hz without a reduction in blanking results in 2240 TotalPixelsPerLine, which would generate a VFC error rather than usable microcode;

  Code: Select all

  Modeline "1680x1050_60.00" 146.25 1680 1704 1960 *2240* 1050 1053 1059 1089 -HSync +Vsync
  while a CVT modeline with reduced blanking would have only 1840 TotalPixelsPerLine

  Code: Select all

  Modeline "1680x1050_60.00rb"  119.00  1680 1728 1760 *1840*  1050 1053 1059 1080  +HSync -Vsync
  which would successfully generate O2-usable microcode.

If anyone would like advice or assistance with creating custom microcode display files, just post a request in this thread.

Wiki'ed with attribution back to this thread:
VFO topic.

R.

I've never successfully gotten 1440x900 to work on my Octane V6. I tried the attached file and it works for the most part except when you scroll a window or do something graphic intensive. Here is what it looks like http://www.youtube.com/watch?v=XoTCPfyx1KI

astouffer wrote: I've never successfully gotten 1440x900 to work on my Octane V6.

What monitor are you using?

My suggestion would be to use EDID info to make a vfo customized for your monitor. Second best would be a web search for the specific model name/number of monitor model info and the words modeline and or EDID to see if someone else has posted that info. If you can get a modeline for your monitor I'll try making you a custom vfo (or if you'd like to try yourself, there's a defacto VFC how-to in this thread ).

astouffer wrote: Here is what it looks like http://www.youtube.com/watch?v=XoTCPfyx1KI

Next time I fire up something other than an IRIX box I'll take a look.

recondas wrote: Next time I fire up something other than an IRIX box I'll take a look.

There's a youtube downloader in /nekoware. I haven't used it for a long time but worked okay in the past. Irix Mplayer will then play the vid, no need for no steenkin' peecee crap

Since you seem to be becoming the current vfc go-to guy, have you tried any double your pleasure dcd formats yet ?

hamei wrote: Since you seem to be becoming the current vfc go-to guy, have you tried any double your pleasure dcd formats yet ?

Unfortunately, it looks like the crew at SGI responsible for developing VFC got spirited away by digital gypsies/corporate raiders before they had the chance to leave even the slightest bread-crumb trail as to how those parts of VFC worked. The absolute lack of documentation on how to use the VPro DCD definition file (VPro_DCD.def) has been the show-stopper for every other mention of VPro-DCD.def I can find on-line. That seems to leave the compiled-by-SGI 2@ dual-channel video format microcode objects as the best resource for hints on what's involved.

It is possible to extract some background information on the composition of VFC micro-code objects using Stuart Levy's "vfoinfo" script . For instance, vfoinfo run in "quick" mode returns: or (since I'm guessing you're particularly interested in 2@1920x1200 formats): Doing the same thing with vfoinfo in verbose mode returns a couple hundred lines of potentially useful format parameters (due to length these are just the first few lines): If we're lucky there'll be enough info there to figure out how to reverse engineer VPRo_DCD.def and/or create a working DCD microcode source file.

recondas wrote: What monitor are you using?

My suggestion would be to use EDID info to make a vfo customized for your monitor. Second best would be a web search for the specific model name/number of monitor model info and the words modeline and or EDID to see if someone else has posted that info. If you can get a modeline for your monitor I'll try making you a custom vfo (or if you'd like to try yourself, there's a defacto VFC how-to in this thread ).

The monitor in question is a Gateway FPD1975W. Thanks for the offer but I tried doing a custom vfo with the EDID numbers and got a similar clock frequency to the one you posted. Its a problem with the V6. I ended up buying a 4:3 ratio Sony LCD for a good price on ebay. Heres an mpeg video of what 1440x900 looks like http://www.bittermen.net:808/VID00086.mpg

astouffer wrote: The monitor in question is a Gateway FPD1975W. Thanks for the offer but I tried doing a custom vfo with the EDID numbers and got a similar clock frequency to the one you posted. Its a problem with the V6. I ended up buying a 4:3 ratio Sony LCD for a good price on ebay. Heres an mpeg video of what 1440x900 looks like http://www.bittermen.net:808/VID00086.mpg

The vfo I posted above uses reduced blanking, the modeline I used was: As was briefly touched upon in the same post, reduced blanking was primarily intended for DVI-attached LCD monitors. A CVT generated modeline without reduced blanking has a 106.5Mhz pixel clock, which would still fall outside the 109-193MHz pixel clock black hole for your V6: If you think a format without reduced blanking is worth a shot, there's a copy attached.

That last vfo produces artifacts on the screen constantly. What makes me wonder about this bug is how the modes with the 89Mhz clock still act buggy. 89Mhz should be safe but its not. Has anyone else done 1440x900 on a V6 or is it just me?

Attached are all the 1440x900 modes I've tried but without success. All were compiled by me except for the Acer monitor. Please feel free to use/edit or pass them along.

recondas wrote:

Code: Select all

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo     1920x600_29 ("1920 x 1200 @ 60Hz Odyssey Dual Channel for SGI Flat Panel")

or (since I'm guessing you're particularly interested in 2@1920x1200 formats):

Code: Select all

# ./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60_ds.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60_ds.vfo   1920x600_30 ("1920 x 1200 @ 60Hz Skew Mode for Odyssey Dual Channel Display board")

.

Hmmm. Interesting. What I'm more interested in to start out will be two outputs of 1920 x 2400 @ 33.72 hz refresh tho ..... luckily, my monitor will work down at 13 hz so too-low a refresh should not be a problem.

Apparently a dcd output for dual 1920 x 1200 @ 60 is really two 1920 x 600 @ 30 each ? Understanding the exact workings of the dcd might be in order ...

hamei wrote: What I'm more interested in to start out will be two outputs of 1920 x 2400 @ 33.72 hz refresh tho ..... luckily, my monitor will work down at 13 hz so too-low a refresh should not be a problem. Apparently a dcd output for dual 1920 x 1200 @ 60 is really two 1920 x 600 @ 30 each ? Understanding the exact workings of the dcd might be in order ...

In that case it might be a good thing if the DCD does use 1920x600. Regardless of refresh rate the maximum screen height for a VPro graphics is 2048 pixels.

recondas wrote:

hamei wrote: Since you seem to be becoming the current vfc go-to guy, have you tried any double your pleasure dcd formats yet ?

Unfortunately, it looks like the crew at SGI responsible for developing VFC got spirited away by digital gypsies/corporate raiders before they had the chance to leave even the slightest bread-crumb trail as to how those parts of VFC worked. The absolute lack of documentation on how to use the VPro DCD definition file (VPro_DCD.def) has been the show-stopper for every other mention of VPro-DCD.def I can find on-line. That seems to leave the compiled-by-SGI 2@ dual-channel video format microcode objects as the best resource for hints on what's involved.

UPDATE: After some serious head-scratching/banging/ache I managed to figure out the secret incantations needed to compile 2@ VFC microcode for DCD-equipped VPro boards. Since hamei asked, the format I tested was the 1920x1200_33.72 he mentioned.

The output of a VFC analysis of the [email protected] is quoted below:

recondas wrote: In that case it might be a good thing if the DCD does use 1920x600. Regardless of refresh rate the maximum screen height for a VPro graphics is 2048 pixels.

Ka rap. Are you sure ? I know I've seen photos of a Fuel running a T221.

The T221 is a little compllicated due to bandwidth.

With one dvi connection you can run anywhere from 1920 x 1200 at 48 hz (monitor will automatically downscale from 60 hz input, but internally it's always running 48 hz which is FINE, the 1600 sw would run at 50 hz and you couldn't tell it wasn't a crt at 83 hz) to 3840 x 2400 at 13hz (which also looks fine but the mouse lags a little and videos are pretty jerky.)

Two dvi connections can do two stripes of 1920 x 2400 @ 33 hz (which should be fine, movies refresh at what, 25 hz or so ?) or possibly 41 hz. This would seem to be ideal except you say the dcd cannot create resolutions higher than X_x_2048 ? Ka ka ka rap I wonder if Compositor can turn it sideways then rotate the screen back to the true position ?

Four dvi inputs can do four 1920 x 1200 tiles or four 960 x 2400 stripes at 48 hz refresh. Bit that's a project for the distant future ...

recondas wrote: UPDATE: After some serious head-scratching/banging/ache I managed to figure out the secret incantations needed to compile 2@ VFC microcode for DCD-equipped VPro boards. Since hamei asked, the format I tested was the 1920x1200_33.72 he mentioned.

First, thank you.

Second, you've gone where few men have gone before. Looking through all the threads here and googling like heck has not turned up anyone outside SGI who's been successful at creating dualling dcd formats. Woo-hoo

But third, try try again. 1920 x 1200 won't work on a T221. It wants 2400 in Y. Just for fun, I'm wondering if 2400 x 1920 is possible ? I'm not sure what SGI did - certainly hope it isn't strictly a single connection at 13 hz . But I have seen photos of the Fuel running a T221. So they did something ....

Grazie grazie tho, you've increased the pool of SGI knowledge in a signifcant area. The abilitiy to create more dcd formats will be a useful useful thing.

hamei wrote: Two dvi connections can do two stripes of 1920 x 2400 @ 33 hz (which should be fine, movies refresh at what, 25 hz or so ?) or possibly 41 hz. This would seem to be ideal except you say the dcd cannot create resolutions higher than X_x_2048 ? Ka ka ka rap

Exceeding a height of 2048 results generates an error message: which in turn leads to: Looks like your lucky day tho (or maybe unlucky after we try a few), when the DCD definition file is included VFC ignores its own advice and creates a format anyway.

hamei wrote: Four dvi inputs can do four 1920 x 1200 tiles or four 960 x 2400 stripes at 48 hz refresh. Bit that's a project for the distant future ...

That was schleusel's take on how a VPro/T221 should be configured (start here and read down a few posts): viewtopic.php?f=3&t=16719068&p=7284690&#p7284690

hamei wrote: First, thank you.

You're welcome. Problem solving can be gratifying - if you actually solve anything. We'll see how this goes.

hamei wrote: Second, you've gone where few men have gone before. Looking through all the threads here and googling like heck has not turned up anyone outside SGI who's been successful at creating dualling dcd formats. Woo-hoo

The solution was too obvious - once I found it. Logged five pages of trial-n-error/cause-n-effect notes before I had my doh! epiphany.

hamei wrote: But third, try try again. 1920 x 1200 won't work on a T221. It wants 2400 in Y. Just for fun, I'm wondering if 2400 x 1920 is possible ?

As...you...wish.....

Figuring out how to get VFC to include the DCD definition file was the first part of the puzzle. The second part will be providing the data needed by the DCD definition file. I used vfoinfo to explore all of the SGI-provided VPro 2@ fromats. In each case it appears SGI built the 2@ formats at half the target refresh rate, and half the target Y resolution:

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1024x768_60.vfo
/usr/gfx/ucode/ODSY/vof/2@1024x768_60.vfo 1024x384_29 ("1024 x 768 @ 60Hz for Odyssey Dual Channel Display")

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1280x1024_60.vfo
/usr/gfx/ucode/ODSY/vof/2@1280x1024_60.vfo 1280x512_29 ("1280 x 1024 @ 60Hz Dual Channel for Odyssey")

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo 1920x600_29 ("1920 x 1200 @ 60Hz Odyssey Dual Channel for SGI Flat Panel")

I followed that lead and created a 2@1920x2400_20uvf format. The 20Hz refresh rate comes from the T221 modeline SGI provides for the Onyx4 UltimateVision (look in section for "1/2 screen 3840x2400"): http://techpubs.sgi.com/library/tpl/cgi ... 137-PARENT I chose 20Hz to keep the pixel clock as low as possible - even at that the pixel clock needed for two displays at 1920x2400 may be be too high unless that situation is helped by the DCD circuitry. In the same thread linked above schleusel mentions the (single?) DVI port on a V12 tops out at 165Mhz. The combined pixel clock of the attached 2@ format is 197.777MHz (for both DVI ports on the DCD).

vfoinfo for the resulting format follows that of the SGI-generated 2@ formats:

./vfoinfo -q 2@1920x2400_20uvf.vfo
2@1920x2400_20uvf.vfo 1920x1200_10 ("2@1920x2400_20uvf")

- we'll have to see what effect, if any, ignoring the screen height error has on the compiled format.

Attached are a couple dual-channel 2@ vfo files (with reduced blanking) for DCD-equipped VPro boards.

This one is 2@1280x1024 because I happen to have two 1280x1024 LCD monitors for testing (two SGI F180s - which have worked flawlessly with the format since I created it this morning).
And this one is 2@1920x1080_60rb because there have been some previous requests for a dual-channel 1920x1080 VPro format. I don't have any 1920x1080 capable monitors, so it hasn't had a trial run yet. If you try it some feedback would be appreciated.


If you have a DCD-equipped VPro and would like a dual-channel vfo created in a different resolution just post a request. VFC requires the horizontal resolution of dual-channel displays be multiples of 64, so some formats (like 2@1440x900 or 2@1680x1050) would be problematic in dual-channel mode.