On Thursday 09 April 2009 14:03:20 Ian Romanick wrote: > 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? > > 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.
This isn't a problem for Gallium. As previously discussed the parts of the video pipeline that do appear as fixed-function in gpus would be exported to a gallium video interface. The default implementation of the interface would be using TGSI and Gallium interface (so 3D pipeline) but if particular hardware supported those features the driver could just implement the video interface using the fixed-function parts. z ------------------------------------------------------------------------------ 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
