On Fri, Jul 29, 2011 at 8:15 PM, Maarten Lankhorst <m.b.lankho...@gmail.com> wrote: > On 07/30/2011 01:57 AM, Younes Manton wrote: >> On Fri, Jul 29, 2011 at 7:45 PM, Maarten Lankhorst >> <m.b.lankho...@gmail.com> wrote: >>> On 07/30/2011 01:05 AM, Younes Manton wrote: >>>> On Fri, Jul 29, 2011 at 6:46 PM, Maarten Lankhorst >>>> <m.b.lankho...@gmail.com> wrote: >>>>>> 2nd patch isn't needed. You shouldn't call vl_video_buffer_create_ex, >>>>>> you should override the create_buffer hook yourself and do what you >>>>>> want. I'll push the 1st one later. >>>>> What create_buffer hook do you mean? If you mean >>>>> pipe_video_decoder->create_buffer, it creates a pipe_video_decode_buffer, >>>>> I need to create a pipe_video_buffer. >>>> pipe_context->create_video_buffer >>> My current nouveau_video_buffer_create calls vl_video_buffer_create_ex >>> with an extra flag set to indicate I want a linear resource. If no capable >>> hardware is found normal resources are used instead. Since I added a >>> fallback to g3dvl, it made sense to me that I just added an extra flag >>> during creation instead of copy pasting the video buffer implementation. >>> >>> The only thing different between vl_video_buffer and >>> nouveau_video_buffer_create is that the latter sets >>> NOUVEAU_RESOURCE_FLAG_LINEAR, rest can be identical. >> Yeah, I realize that, but look at what struct vl_video_buffer has >> under the covers, there's a bunch of state related to shader-based >> decoding. You don't need any of that, what's the point of creating it? >> Besides, if/when pipe_video_decode_buffer goes away even more >> shader-specific stuff will end up in vl_video_buffer to bridge the >> gap. Simply define your own VPE-specific pipe_video_buffer that 1) >> checks that the requested format is NV12, 2) creates 1 luma resource >> and 1 chroma resource. For nv50 you can pass the linear flag, for nv40 >> it will also have to pass the linear flag, for nv30 it will need more >> specialized version to deal with the fact that nv30 doesnt even >> support linear or regular non-POT textures. > The problem is that I don't know whether create_buffer is called > for vdpau or xvmc. If it was just xvmc I'd agree with you, but > create_video_buffer can be called for vdpau too. I can't > guarantee that the kernel and the graphics card support PMPEG > decoding either, in which case I do want to fall back to g3dvl. > > pipe_video_buffer should just contain the minimum, > and all vl_mpeg_ related state should be split off from it. > > ~Maarten >
pipe_video_buffer already contains the minimum, it's just an interface. However vl_video_buffer_create_ex creates a *vl_video_buffer* specific to its needs, which is why it makes little sense to use for a HW decoder. The problem of which what to do with that hook when you have more than one decoder is separate from that. The create_video_buffer hook should be part of pipe_video_decoder, not pipe_context, for exactly this sort of reason. It used to be like that previously and is something I'll likely be moving back to deal with this. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
