On Nov 30, 2004, at 8:32 PM, Glenn Anderson wrote:
I am finding the opposite, decompressing 1920x1080 Photo JPEG
QuickTime movies to a 32bit ARGB GWorld/texture is slightly faster
than to a '2vuy' GWorld/texture on a single 1.8GHz 1st gen G5 with
an FX 6800 GT.
How can YUV->RGB possibly be faster than no conversion at all?
Internally the Photo JPEG codec has to do a 4:2:0 to 4:2:2 conversion
for '2vuy' (or 'yuvs'). If you use ARGB it does a 4:2:0 to RGB
conversion, so you just get a different conversion, rather than
having no conversion in the YCbCr case. The only significant
difference is that twice as much data is involved for the ARGB case,
but it would appear the extra overhead of that on a G5 is less
significant than the overhead on the GPU of doing a YCbCr to RGB
conversion. On this particular hardware configuration, ARGB is using
slightly more CPU time, but the frame rate is slightly better with
ARGB for some reason.
Even if you get the GPU to do an overlay the pixels have to come
back to the CPU side prior to texturing.
That is true for both ARGB and YCbCr pixels, on OS X anyway. On OS 9
systems that support AGP Fast Writes and VRAM GWorlds I get way
better performance, but that is a different story.
Apple's Photo-Jpeg does have a 'lossless' mode that could be RGB,
but I don't recall what color-space it uses. If you are using that,
and it is RGB, then it will be faster to use ARGB. I don't think
I've ever run across 'lossless' Jpeg though, so outside that
specific case YUV will be much, much faster.
I am using medium quality Photo JPEG, which is 4:2:0. In 'lossless'
quality the Photo JPEG codec apparently uses 4:4:4 sampling, but that
typically results in much much higher data rates which are not so
useable.
I suspect you will find the problem was the 32bit GWorld you were
using was allocated by QuickDraw or QuickTime, so did not have a
baseAddr aligned to 32 bytes and/or rowBytes that is a multiple of
32 bytes
I allocate my own buffer, and that buffer is also used in processing
by the CPU. I've never seen ARGB pixel formats perform better than
YUV for video sources.
Typically YCbCr is slightly faster, but nothing like 400%.
glPixelStorei(GL_UNPACK_CLIENT_STORAGE, GL_TRUE) and
glTexParameteri(GL_TEXTURE_RECTANGLE_EXT,
GL_TEXTURE_STORAGE_HINT_APPLE, GL_STORAGE_CACHED_APPLE) gives the
best performance.
Yes, but there is a caveat with client_storage. If you do process
the pixels after the QT decompression and before texturing, then
client_storage can become a problem. QT and GL aren't synchronized
in any way so it's quite possible and even very likely that
artifacts will occur with client_storage enabled.
I am using a transfer codec which allocates the source GWorld (the
one QuickTime is drawing in to and my code is texturing from), and
alternates it between two buffers in the LockBits call.
If you are not using client_storage, you may be seeing significantly
better performance with YCbCr due to the extra memory copy involved
only being half the size.
Glenn.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
