Angus Dorbie (dorbie++at++sgi.com)
Wed, 29 Jul 1998 10:47:01 -0700
I've asked around and here are the answers to your questions.
** These should probably be put in the product FAQ. **
>
> - what is a LVDS ? What physical form does it take? (single coax?, etc.)
"LVDS is a Standard switching technology (EIA-644?) manufactured by TI
and National Semi. The connector is not standardized, though a standard
connector type is used. A 40-pin MDR connector by 3M is being used.
Cable
will either be twin-ax or shielded twisted pair."
The connector & cable stuff is subject to change.
You can still take analog of the final output on coax, you don't need
to worry about the lvds unless you need digital output, cabling for the
pipe interconnection is supplied with the option.
>
> - Is the alpha channel transferred as well?
No alpha is not supported.
>
> - Do all the pipes have to be on the same machine? (assuming a
> different,
> networked, software sync mechanism)
Yes, only single machine is supported.
>
> - How are drops handled? (in the above example, one pipe taking longer
> than 3/60 seconds to complete rendering pass)
> Is there a software sync (is the "sending to LVDS" triggered by a
> software call? Or by fixed scheduling in the DPLEX doughter boards?)
The sync uses the swapready HW, but there is also a degree of software
control at least at the glx level if not ultimately in Performer.
Drops are handled elegantly, it continues to send the current channel
out if the next one isn't done. At the next retrace, the now completed
sequential pipe image is sent eventually the right data propagates
through from the app to the draw processes. The obvious requirement
I'm sure most readers would want is to send the most recent data
skipping the dropped frame, unfortunately this has some nasty practical
implications.
1) If you left the skipped pipe rendering it wouldn't stand a hope of
ever making frame rate (because it has even less time to draw next
frame right) so you'd have to abort it when it missed the swap and
kick off it's next draw.
2) Aborting is a tricky thing for a draw process to do and the hairy
edge prior to swap might also be confusing.
3) Given that you must abort, you could have a horrible situation where
if several frames skip you have really stale information and no
prospect for anything new to display.
There certainly won't be any nonsense like the eye stepping backwards
because you switch to an older frame, and DPLEX system should help you
make frame all the time.
>
> - What is exactly meant by "tap one DG board for the final output"?
Take the video from one display generator on a single pipe, actually
the last one on the daisy chain.
> Does the pipe that is connect to the outputting DG do actual rendering?
Yes. There is no graphics hardware redundancy.
> Is the DPLEX hardware on it different?
No, every board has digital in and out and analog out. Only the last
board in the chain has a free digital out connector with all the video
frames. It also has an analog out for one channel ofcourse. If you don't
need digital video then a ring config is also supported where the same
analog is available from all pipes and there are no free digital out
connectors.
Note, that this frontpanel *replaces* whatever connectors you are
familiar with on an ONYX2 DG board so that 2 or 8 channel analog is not
possible from a single pipe while you have DPLEX installed. You still
have swapready & genlock.
>
> - Is the whole framebuffer transferred or just one DG output channel?
>
Only one channel is sent, the motivation is that if you
need > 1 channel you should actually split the pipes up.
To answer the question I think you are heading towards; although
this is a digital transfer, none of it is available to the graphics
rendering system, this is all digital video after rendering.
Cheers,Angus.
-- "Only the mediocre are always at their best." -- Jean GiraudouxFor advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:45 PDT