Re: the basic idea of my codec

----- Original Message -----
From: "Johan Hanson" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Thursday, June 20, 2002 9:01 PM
Subject: Re: [tarkin-dev] the basic idea of my codec


> Maciek Urbañski wrote:
> >
> > ...but computers are getting faster, and there is large enough amount of
> > MMX/MMX2/SSE/SSE2/AltiVEC-wizards around to make it faster. And
computers
> > will be faster and faster, and the standard sohuld stand for a long
time.
> > ;-)
>
> I have had what I think is an important idea.
>
> What if we could write a player where *all* transforms are performed
> on the graphics card?
> Some people on this list are working on MC using textured polygons,
> but what if also the IDWT could be implemented as "pixel shaders"
> that are supported by the latest cards from NVidia, ATI (and soon
> also from Permedia and Matrox).
>
> These devices have several limitations of course, such as having
> only a single destination pixel at once. The devices are designed
> to work with 2D buffers.

The major limatation of those devices is lack of coditional jumps. It's hard
to perform any adaptive coding whe you can't adapt...
Maybe the nev GPU from 3DLabs... they claim it's fully programable...
But really... why ? why do it on the GPU not CPU ?


> I am interested in how your inverse red-black transform would look like.
> Is it possible to merge the two inverse transforms into one pass?

Look-up the paper The Red-Black Wavelet Transform and the Lifting Scheme,
Geert Uytterhoeven
and Adhemar Bultheel.


> Can it be written as a routine with a single destination write?

Yes, it could.


> Despite their shortcomings, GPUs also have certain features for free
> that should be exploited if possible:
>  - A read from a buffer can linearly interpolate two/four input
>    samples at once. (in 1D and 2D respectively)
>    This is called texture filtering.
>  - GPU:s are often vector-processors, like MMX/SSE/3DNow/Altivec/...
>    meaning that we transform all three color channels (Y,Cr,Cb) at once.

I'm not very fond of an idea... I think (almost sure) it's impossible do do
entire decoding process in GPU. I can't imagine decoding a Huffam on those
machines, and arithetic coders/range coders are far more complex... But I
might be wrong.


> If the inverse transform uses a 2D kernel with no holes between
> kernel elements (which would be the case if both inverse transforms were
> merged into one), then we could use texture filtering to speed it up.
> A 2D IDWT would also need less passes on a GPU than if a 1D IDWT was
> used.


It's next to impossible. You'll lose adaptivity, the kernel would be huge.
And anyway - you can divide the image into separate red and black blocks
(sort of de-interlave process) and you find that kernel matrix has no
"holes".

> Oh. Well, don't think about what I wrote... That could consume too much
> of your mind.. ;-)

If I fail because of you... revenge ! ;-)



--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.