On 03.01.2012 17:03, Maarten Lankhorst wrote:
Hi Christian,
2012/1/2 Christian König<deathsim...@vodafone.de>:
Hi Maarten,
first of all: Happy new Year and sorry for the late reply, have been on
vacation for the last week.
On 29.12.2011 16:41, Maarten Lankhorst wrote:
Hey Christian,
Op 26-12-11 14:00, Christian König schreef:
Based on patches from Maarten Lankhorst<m.b.lankho...@gmail.com>
Signed-off-by: Christian König<deathsim...@vodafone.de>
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index de79a9b..f7ee522 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -410,7 +410,8 @@ struct pipe_context {
enum
pipe_video_profile profile,
enum
pipe_video_entrypoint entrypoint,
enum
pipe_video_chroma_format chroma_format,
- unsigned width,
unsigned height, unsigned max_references );
+ unsigned width,
unsigned height, unsigned max_references,
+ bool
expect_chunked_decode);
I really don't like this part, isn't it implied from entrypoint>=
PIPE_VIDEO_ENTRYPOINT_IDCT?
Not necessarily, I'm still trying to give this interface a more general look
and feel.
So for the current use case it can be deduced from the fact that XvMC only
supports entry-points IDCT and MC, while VDPAU only supports bitstream, but
that doesn't necessary have to be always the case.
Even if this is true, it seems like this is a limitation that only
applies to the shader based decoder. The nouveau pmpeg xvmc
implementation in mesa doesn't need it at all.
Not really, for UVD I have pretty much the same problem (but for
different reasons). Also I don't really see a problem in having driver
specific bits in the interface as long as it doesn't cause problems for
other drivers.
Christian.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
