Mailinglist Archive: radeonhd (93 mails)
| < Previous | Next > |
Re: [radeonhd] Yo (ho ho and a bottle of rum)
- From: Matthias Hopf <mhopf@xxxxxxx>
- Date: Tue, 2 Feb 2010 13:43:44 +0100
- Message-id: <20100202124344.GA18665@xxxxxxx>
On Feb 02, 10 20:37:22 +1300, Michael Cree wrote:
Actually, integer arithmetics has only been added *after* floating point
was already defined and working :-)
Guess so. Anything that requires an inherent serial workflow (Huffman
etc.) is truly bad to parallelize, especially in a SIMD array like GPUs.
Matthias
--
Matthias Hopf <mhopf@xxxxxxx> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@xxxxxxxxx
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
On 26/01/10 11:50, Christian König wrote:
IDCT and MC should be pretty easy, IDCT are just a bunch of cos and mulYeah, on the surface it's straightforward, but often CPU implementations of
operations, and MC scripted blitter operations.
the DCT for JPEG/MPEG trade off precision for efficiency by using fixed
point or even integer arithmetic. With hardware implementation it might be
nice to aim for precision to maintain best quality assuming sufficient
speedup? I'm not familiar with shaders; do they provide floating point?
Actually, integer arithmetics has only been added *after* floating point
was already defined and working :-)
The real tricky part isVLD? What's that? I'm guessing - variable length decoding?
VLD, i have no clue how this works.
Guess so. Anything that requires an inherent serial workflow (Huffman
etc.) is truly bad to parallelize, especially in a SIMD array like GPUs.
Matthias
--
Matthias Hopf <mhopf@xxxxxxx> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@xxxxxxxxx
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
| < Previous | Next > |