On Mon, Oct 12, 2009 at 11:58 AM, José Fonseca wrote:
> Younes,
>
> I've finally took a good look to your changes. Again, I don't know
> enough about video to comment on the details, so comments below focus
> more on shape than the content.
>
> Overall the interfaces look sane to me. The point I'
On Sun, 2009-09-20 at 19:22 -0700, Younes Manton wrote:
> On Mon, Jan 19, 2009 at 9:39 AM, Younes Manton wrote:
> > I've been taking a look at VDPAU and how to support it on cards with
> > and without hardware support and I have some thoughts. The VDPAU API
> > lets the client pass off the entire
Great!
probably libXvMCg3dvl.so can load device dependent xvmc driver dynamics
according to current device, for example, libnouveau_dri.so and
libradeon_dri.so.
btw, the context and screen are related to DRI, I am changing them to DRI2
in order to use gallium 3d functions.
Cooper
On Mon, Sep 21, 2
On Tue, Jan 20, 2009 at 4:07 AM, Xavier Bestel wrote:
> Sorry to get in the way, but if at some point in the pipe everything can
> be done in hardware or shaders, maybe drivers should expose what they
> can accelerate to let the app handle the rest (some smart frameworks
> like gstreamer could tak
On Mon, Jan 19, 2009 at 23:25, Younes Manton wrote:
> On Mon, Jan 19, 2009 at 4:08 PM, Corbin Simpson
> 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
On Mon, 2009-01-19 at 17:25 -0500, Younes Manton wrote:
> > - 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 tak
On Mon, Jan 19, 2009 at 4:08 PM, Corbin Simpson
wrote:
> Well, it occurs to me that almost all video decoding's done in a
> pipeline, and we don't want to do any steps in software between hardware
> steps. It also occurs to me that there's a big disconnect between the
> actual video format, and th
Keith Whitwell wrote:
> On Mon, 2009-01-19 at 05:39 -0800, Younes Manton wrote:
>> I've been taking a look at VDPAU and how to support it on cards with
>> and without hardware support and I have some thoughts. The VDPAU API
>> lets the client pass off the entire video bitstream and takes care of
>>
On Mon, 2009-01-19 at 05:39 -0800, Younes Manton wrote:
> I've been taking a look at VDPAU and how to support it on cards with
> and without hardware support and I have some thoughts. The VDPAU API
> lets the client pass off the entire video bitstream and takes care of
> the rest of the decoding pi
I've been taking a look at VDPAU and how to support it on cards with
and without hardware support and I have some thoughts. The VDPAU API
lets the client pass off the entire video bitstream and takes care of
the rest of the decoding pipeline. This is fine if you have hardware
that can handle that,
10 matches
Mail list logo
