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.

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

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:

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;

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

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:

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:

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.

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.

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.

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.

You're welcome. Problem solving can be gratifying - if you actually solve anything. We 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:

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:

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.