On Mon, Jun 6, 2011 at 12:52 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 05.06.2011 06:31, schrieb Younes Manton: >> 2011/6/4 Jose Fonseca <jfons...@vmware.com>: >>> At very least there are ovious things that need to be fixed: >>> >>> - get_param / is_format_supported should not be duplicated from screen. >> >> This is also deliberate. Params and surface formats may depend on the >> codec/profile/dimensions of the video stream the context was created >> to decode. There is not always enough info available in pipe_screen >> alone to determine if a particular cap or surface is supported. The >> current implementation largely wraps pipe_screen because again it's >> using the 3D pipeline and we don't have to deal with funny decoding >> hardware constraints. > > I'm not sure if that's the right answer though, couldn't you just as > well require a driver to handle all dimensions etc. for a given codec? > If necessary should just use the shader stages (or cpu...) instead?
That implies that every driver wanting to do HW decoding will also have to implement 3D decoding. But anyhow, it's really not a question of falling back. HW decoders will have different caps based on which codec they're decoding (and sometimes based on how many streams) and there needs to be a way for a state tracker to get that info. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
