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

[Drew Hess]

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

pgpux3yIryQX7.pgp
Description: PGP signature