svn commit: r438198 - in head: graphics/dri graphics/libGL graphics/libGL/files graphics/libosmesa lang/clover

[Matthew Rezny]

On Tuesday 11 April 2017 06:27:09 Alexey Dokuchaev wrote:
> On Mon, Apr 10, 2017 at 07:14:48PM +0000, Matthew Rezny wrote:
> > New Revision: 438198
> > URL: https://svnweb.freebsd.org/changeset/ports/438198
> > 
> > Log:
> >   Update Mesa to 17.0.3
> 
> Cool, thanks!
> 
> > -OPTIONS_DEFINE=	TEXTURE
> > +OPTIONS_DEFINE=	TEXTURE VAAPI VDPAU
> 
> So VDPAU is back?
> 
VDPAU option is back. Sorry, I forgot to mention VDPAU and VAAPI in the commit 
message as my focus was on documenting the DRI3 change. VDPAU is not supported 
by the 3.8 era drm drivers in kernel. It is supported by DRM-next and 
DragonFly. I believe the situation with VAAPI is the same. So, these options 
are for those users at the moment as stated in pkg-help. As I write this, it 
occurs to me that nvidia-drivers also may support VDPAU.

> > @@ -1,13 +1,15 @@
> > -The GALLIUM option enables gallium (llvm) backed drivers such as for
> > example -the r600 and radeonsi driver.
> > +VAAPI and VDPAU options enable building Gallium based VA-API and VDPAU
> > +drivers to decode video on the GPU via libva and libvdpau, respectively.
> > +Gallium based VAAPI and VDPAU drivers are only available for Radeon GPUs.
> > 
> > -The VDPAU option enables VDPAU drivers to decode video on the GPU via the
> > -VDPAU library.
> > +Both GPU decode options require newer drm drivers than are currently
> > present +in a released FreeBSD kernel. These are options for DRM-next and
> > DragonFly.
> I'm still confused, would it work against up-to-date -CURRENT or I still
> need to patch the kernel parts?
> 
That is something I am not completely clear on either since I am not directly 
working on the DRM-next parts. As far as I know, the effort to integrate the 
needed changes in LinuxKPI is still in progress, so I  believe it is still 
necessary to use the kernel from FreeBSDDesktop repo in order to use the more 
up to date drm drivers. My primary concern in regards to DRM-next is making 
the FreeBSD ports tree work well enough with their kernel/drivers such that 
use of the FreeBSDDesktop ports tree is not strictly necessary, thus ensuring 
ports are ready when the DRM-next work lands in CURRENT.

> ./danfe