openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] Introduction and CTL/ICC question


From: Drew Hess
Subject: Re: [Openexr-devel] Introduction and CTL/ICC question
Date: Fri, 11 Mar 2005 16:09:19 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)

The 3 separate lookups are definitely a bottleneck (and the penalty is
proportional to the size of the texture, I suppose due to reduced
locality in the texture cache).

The lattice lookup encoded as a 3D texture is faster, even for
reasonably large 3D texture sizes (I went all the way up to 64x64x64
in my testing).  This is true of both the fixed-point 3D textures on
NV3x and 16-bit FP 3D textures on NV4x.

By the way, there's a good chapter in the new "GPU Gems 2" book on
using the GPU for color transformations by a guy at Sony Imageworks
(don't have the book handy, sorry I can't remember the name).  I
recommend it to anyone who's interested in this sort of thing.


d


Lars Borg <address@hidden> writes:

> At 10:44 AM -0800 3/9/05, Drew Hess wrote:
>>It depends on what you mean by "reasonable performance," but on an
>>NV30-class GPU, you can get ~20fps playback on HD-resolution 16-bit FP
>>RGBA frames using 3 full 1x65536 LUTs; that is, one LUT for each color
>>channel (R, G, B) that can transform any 16-bit half value to any
>>other 16-bit half value.
>
> That's about 40 Mpixels/sec.
> Using 65k LUTs may be suboptimal as you may become memory bound.
>
> We have seen >>100 Mpixels/sec with GeForce 6800 GT with many types of
> ICC profiles and float data, and we think it can go faster. This case
> was GPU bound, not memory bound.
>
> I don't know how NV30 compares with 6800.
>
> Lars Borg
> Adobe Systems

Attachment: pgpHZBGnWpzSu.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]