On Mon, Jan 19, 2009 at 23:25, Younes Manton <youne...@gmail.com> wrote:
> On Mon, Jan 19, 2009 at 4:08 PM, Corbin Simpson
> <mostawesomed...@gmail.com> wrote:
>> - Drivers have one hook for taking in video frames, maybe in a context,
>> maybe in a video_context.
>> - Drivers are responsible for all steps of decoding frames, but are free
>> to use methods in Util or Video or whatever auxiliary module we decide
>> to put them in. Things like, say, video_do_idct() or video_do_huffman()
>> might be possible.
>> - Drivers probably shouldn't mix'n'match hardware and software steps,
>> although this is a driver preference, e.g.
>>
>> video_do_foo();
>> nouveau_do_bar();
>> video_do_baz();
>>
>> I would guess that the migration setup would take longer than just doing
>> video_do_bar() instead, but that's just my opinion. I'm sure that not
>> all chipsets are quite like that.
>
> I doubt this will be a problem, I can't think of any reason to fall
> back to software for a stage if the preceding stage was handled in
> hardware or shaders. There may be such an oddball case, but yeah no
> point in mixing hardware, software, and shaders if we have to read
> back from the GPU.
Yeah, there is no existing hardware that would require such a
combination. Actually, from what I can see, the existing fixed pipe
hardware for video decoding that exists today falls within one of
these categories :
- no fixed pipe acceleration at all -> sw CA{BAC,VLC} + shader iDCT +
shader MC + shader CSC
- fixed pipe MC -> sw CA{BAC,VLC} + shader iDCT + fixed MC + shader CSC
- fixed pipe iDCT + MC -> sw CA{BAC,VLC} + fixed iDCT + fixed MC + shader CSC
- fixed pipe CA{BAC,VLC} + iDCT + MC -> fixed CA{BAC,VLC} + fixed iDCT
+ fixed MC + shader CSC
So basically we only need sw CA{BAC,VLC}, all other software stages
can be avoided (and incidently that's the philosophy of gallium).
There is also no way we're going to be able to do efficient
CA{BAC,VLC} using shaders today, and I don't see that happening soon.
>
>> - I think that once a frame's decompressed, we can use the normal
>> methods for putting the frame to a buffer, although I'm sure that people
>> are going to reply and tell me why that's not a good idea. :3
>>
>> So from this perspective, support for new formats needs to be explicitly
>> added per-driver. PIPE_FORMAT_MPEG2, PIPE_FORMAT_THEORA,
>> PIPE_FORMAT_XVID, PIPE_FORMAT_H264, etc.
>
> There are also profile variations to consider, but yeah that's the jist of it.
>
Yes indeed, we discussed this on irc already, and you know I'm afraid
that the number of combinations for fixed pipe stuff could explode
(the 4 combinations * the number of formats). The problem is that this
will have to be duplicated in each driver. Not sure if there's a way
out of this though, and also maybe it doesn't matter because we won't
support too many formats...
Stephane
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
