On Thu, Apr 9, 2009 at 20:03, Ian Romanick <i...@freedesktop.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephane Marchesin wrote: > >> That's my point: video codecs move too fast to be put into silicon, >> and require too many resources to implement. So we should use shaders >> and lay everything onto an API that takes care of the hardware >> details. > > This is one case where I agree with keithp about fixed-function > hardware. You can always make a fixed-function video decoder that uses > orders of magnitude less power than a programmable decoder. How many > movies do you want to be able to watch on that long flight from LA to > Sydney?
It depends, lets say my movie is H264 and I have an i945. Since that card can't do H264 decoding as fixed pipe and since the driver has no shader-based H264, I end up using the CPU and actually a lot more battery. It's actually way worse than fixed hardware. I end up running out of battery in the taxi to the airport. On the other hand, had I used a shader-based video decoding library, I could at least accelerate most of the decoding. That would probably let me watch movies at least until I land in Hong kong (where I catch the connecting flight). Really H264 (or any codec for that matter) is not the end of the tunnel. Hey, no fixed pipe hardware implements the full H264 spec today. What's going to happen when newer videos start using the full range of capabilities? Yes, fallback to CPU rendering again. Or corrupt video. > > As a fairly extreme example, the CPU in the iPod can decode MP3. > However, doing it on the CPU, even that power efficient CPU, uses more > that 5x the power of doing on the dedicated MP3 decode hardware. I > don't know that the difference is as extreme for video decode hardware, > but even 2x would pretty significant. > > I guess the point is that fixed-function decode hardware won't > disappear, at least not on mobile devices, any time soon. > Yeah, the answer for those is pretty simple IMO: we just don't support these. And we can handle the rest with g3dvl. Stephane ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
