Re: [Openexr-devel] OpenEXR image sequence files...

[E. Scott Larsen]

Interesting.  I believe it though - graphics drivers do apparently odd 
things sometimes.

These stages aren't the bottleneck in our app so we've just done this 
since it made sense to us and we haven't timed it or made efforts to 
optimize it.  Looks like you've investigated it and done a fine job, so 
I'd go with your results.

//Scott

Drew Hess wrote:
> Yeah, I'm doing that.  It doesn't seem to make a lot of difference in
> my application, but maybe I'm missing something.  I have two PDR
> textures, one of which I'm copying to from a list of in-memory OpenEXR
> images, the other which is being used by OpenGL for the current frame.
>
> But from everything I understand, and I've talked to a few Nvidia
> developers and architects about this, you don't get any benefit from
> downloading one texture while you're rendering the other out of
> texture memory; in fact, this significantly reduces performance.  It's
> almost as if there's a mutex around the texture memory ports such that
> you can either be downloading across AGP, or doing texture lookups
> From a pixel shader, but not both.
>
> So, from a pipeline standpoint, the process looks like this:
>
>   fill-tex1   download-tex1  render-frame1
>               fill-tex2                     download-tex2  render-tex2
>                                             fill-tex3
>
> and your framerate is limited by t(download-tex + render-frame).  It
> would really be nice to reduce this to something on the order of
> t(max(download-tex,render-frame))
>
>
> d
>
>
> "E. Scott Larsen" <address@hidden> writes:
>
>
> > You can make two textures and render from one while the other is being
> > filled in, then swap when the latter is ready.  This has worked well for
> > us in a multithreaded scenario (one thread rendering and one thread
> > reading the next image and filling the spare texture with it).
> >
> > //Scott
> >
> > On Thu, 4 Nov 2004, Drew Hess wrote:
> >
> >
> > > There's been some interest in this, but nothing is being actively
> > > developed, as far as I know.  At SIGGRAPH 2003 I had a few people
> > > approach me after the OpenEXR sketch asking about using OpenEXR for
> > > video, but nothing came of it.
> > >
> > > We'd certainly be interested in hearing ideas.  The major issue for us
> > > is that it takes about 400MB/s to stream uncompressed HD-res RGBA
> > > 16-bit OpenEXR images, and that's not very practical for an artist's
> > > desktop machine.  Then again, it's not a Herculean effort, either,
> > > just takes a stack of maybe 10-12 7200rpm IDE drives; so for other
> > > markets, like digital cinema, maybe it's not such a big deal.
> > >
> > > BTW, you probably want the alpha channel for padding reasons, even
> > > though it costs you another 100MB/s; otherwise, either your app or the
> > > OpenGL driver has to reformat the data as RGBA before sending it to a
> > > 16-bit FP pixel shader, since that's the only native 16-bit FP format
> > > that current video cards support.
> > >
> > > I dunno, maybe if you have a 2nd processor you can be doing that one
> > > frame ahead and save on some disk bandwidth while still maintaining
> > > the frame rate to the video card, but it'd be challenging, esp. since
> > > video cards aren't typically able to render while you're downloading
> > > the next texture/frame.  With a fast Pentium 4 or Athlon 64 and an
> > > NV40, I can get about 40fps on HD-res OpenEXR image sequences, but
> > > downloading a texture to the card and rendering it is basically a
> > > serial process -- you can't overlap it.
> > >
> > > d
> > >
> > >
> > >
> > > "David Kuo" <address@hidden> writes:
> > >
> > >
> > > > New to the list.
> > > >
> > > >
> > > >
> > > > Don't think this has been discussed before, but is there any effort
> > > > underway to extend OpenEXR to image sequences?
> > > >
> > > >
> > > >
> > > > I am working on displaying real-time HDR video sequences, and would
> > > > rather not invent yet another file format.
> > > >
> > > >
> > > >
> > > > David
> > > >
> > > > _______________________________________________
> > > > Openexr-devel mailing list
> > > > address@hidden
> > > > http://lists.nongnu.org/mailman/listinfo/openexr-devel
> >
> > >