Re: DPLEX questions [was: Re: Pipes]

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Fri, 31 Jul 1998 11:25:34 -0700

Moshe Nissim wrote:
>
> Thanks for the thorough and quick reply.
>
> > 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.
>
> So it's kind of analogous to a double-buffer operation on a single pipe
> --
> the front buffer continues to be sent until the drawing to the back
> buffer is finished?

Yep, I suppose so.

>
> >
> > 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.
> .
> .
> > Only one channel is sent, the motivation is that if you
> > need > 1 channel you should actually split the pipes up.
>
> So, only one channel, which is also the *only* channel. What is that
> channel?
> The whole framebuffer at the pipes rate in some digital LVDS format?

It's a video channel, which may or may not be your whole framebuffer.

> And what video format (.vfo) is output from the final DPLEX board?

It's programmable, you load a vfo. There is a bandwidth limit on
the dplex interconnect but 1280x1024++at++60 is supported.

> Can you slave a GVO channel to it?

I don't think so.

>
> > 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.
> >
>
> Yes, it would have been nice to dedicate one pipe to 2d post-rendering
> stuff like distortion and blurring...

You can do the equivalent, each pipe renders then distorts, it's a
symmetric
solution to the same problem and the performance is exactltly
equivalent.

The other approach was not practical.

>
> It would have been nicer to have alpha supported as well. This makes it
> less useable for my application...

Agreed.

>
> Well, can't please everybody all of the time, can you?
>

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 


For 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

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:46 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.