public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Rinat Ibragimov" <ibragimovrinat@mail.ru>
To: "Eric Anholt" <eric@anholt.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)
Date: Tue, 27 Aug 2013 11:29:00 +0400	[thread overview]
Message-ID: <1377588540.132340590@f368.i.mail.ru> (raw)
In-Reply-To: <87haecdol2.fsf@eliezer.anholt.net>


Понедельник, 26 августа 2013, 16:22 -07:00 от Eric Anholt <eric@anholt.net>:
> Rinat Ibragimov <ibragimovrinat@mail.ru> writes:
> 
> > Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric@anholt.net>:
> >> Ибрагимов Ринат <ibragimovrinat@mail.ru> writes:
> >> 
> >> > libvdpau uses second DRI driver name to determine which VDPAU driver
> >> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> >> > with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> >> > I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
> >> > it would be convenient to have this driver selection working without manual
> >> > driver selection.
> >> 
> >> If it's a generic driver, why would it need a "i965" string passed over
> >> the DRI2 protocol to find it?
> >
> > It doesn't actually. It's just to simplify distribution package management.
> > If one names driver libvdpau_nvidia.so.1, it will break VDPAU on
> > nVidia equipped machines. With this patch one can name it
> > libvdpau_i965.so.1 and driver will be loaded on intel equipped
> > machines only.
> >
> >> 
> >> One of the things I'm planning on doing is removing use of the
> >> protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
> >> it has built, and it knows how to detect those devices (in the EGL
> >> code), so why would we pay attention to what the X Server thinks our
> >> driver's name is?  Seems like vdpau could probably do the same.
> >> 
> >
> > VDPAU uses entry point library (libvdpau) which loads backend drivers.
> > libvdpau uses second DRI2 driver name amongst other methods to determine
> > which driver to load. It can not rely on Mesa's internal knowledge, because
> > it must work with proprietary nVidia driver too.
> 
> Right, I meant "couldn't libvdpau have a method to determine which
> driver to load based on looking at your hardware, like how Mesa's EGL
> does?", since only libvdpau is likely to know how pieces of hardware map
> to driver binaries.
> 

VDPAU drivers have separate code from libvdpau, while Mesa have drivers
inside it (if I get it right). I can't figure out how libvdpau beeing separate
can determine mapping between hardware and driver to load. The only way
is to ask[1] DRI2.


[1] http://cgit.freedesktop.org/~aplattner/libvdpau/tree/src/vdpau_wrapper.c#n104
---
Rinat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2013-08-27  7:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-16 10:31 [PATCH] Add second DRI driver name (DRI2DriverVDPAU) Ибрагимов Ринат
2013-08-19 15:54 ` Rinat Ibragimov
2013-08-26  7:36 ` Rinat Ibragimov
2013-08-26 20:40 ` Eric Anholt
2013-08-26 21:22   ` Rinat Ibragimov
2013-08-26 23:22     ` Eric Anholt
2013-08-27  7:29       ` Rinat Ibragimov [this message]
2013-08-28 23:26         ` Eric Anholt
2013-08-29  7:49           ` Rinat Ibragimov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1377588540.132340590@f368.i.mail.ru \
    --to=ibragimovrinat@mail.ru \
    --cc=eric@anholt.net \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox