Date: Tue, 11 Apr 2017 10:19:09 +0200 From: Matthew Rezny <rezny@freebsd.org> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r438198 - in head: graphics/dri graphics/libGL graphics/libGL/files graphics/libosmesa lang/clover Message-ID: <1795275.0xbZexPCl1@workstation.reztek> In-Reply-To: <20170411062709.GA36557@FreeBSD.org> References: <201704101914.v3AJEmNt097726@repo.freebsd.org> <20170411062709.GA36557@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1795275.0xbZexPCl1>