Date: Thu, 20 Apr 2017 19:53:50 +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: r433902 - head Message-ID: <1855734.ja2yFjLJe3@workstation.reztek> In-Reply-To: <20170420170837.GA10533@FreeBSD.org> References: <201702111903.v1BJ3sMj021042@repo.freebsd.org> <20170420170837.GA10533@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 20 April 2017 17:08:37 Alexey Dokuchaev wrote: > On Sat, Feb 11, 2017 at 07:03:54PM +0000, Matthew Rezny wrote: > > New Revision: 433902 > > URL: https://svnweb.freebsd.org/changeset/ports/433902 > > > > Log: > > Add UPDATING entry for Xorg server 1.18.4 > > > > Modified: head/UPDATING > > ... > > +20170211: > > + AFFECTS: users of x11-server/xorg-server > > + AUTHOR: rezny@FreeBSD.org > > + > > + Xorg server has been updated to 1.18.4 and autodetection has changed. > > I've just had a chance to upgrade X.org/Mesa ports on my fresh -CURRENT > laptop, and noticed that X.org server indeed won't startup unless I load > radeonkms.ko module by hand. I understand that this entry specifically > > talks about it, but would like to clarify a few things if you don't mind: > > + The order in which drivers are now attempted is: > > + 1) vendor/model specific driver according to PCI IDs > > + 2) generic modesetting driver which requires a drm driver with KMS > > + 3) scfb, the generic framebuffer driver > > + 4) vesa (only if arch is x86) > > Can you recall what was the previous order? > Old Order: vendor specific according to PCI ID, fbdev, vesa Since fbdev is only for Linux framebuffer, and it's the #else after a specific case for Net/OpenBSD which use wsfb, I inserted scfb for us and made fbdev only for Linux. History note: scfb forked from wsfb which forked from fbdev. Modesetting was behind an #ifdef linux. I enabled it for us as well, though it could probably be changed to be enabled for all BSDs upstream. See x11-servers/xorg-server/files/patch-hw_xfree86_common_xf86AutoConfig.c > > + This should minimize the need for xorg.conf files. > > Didn't have one for a quite a few years now, didn't know it was still > needed. ;-) > > > + i.e. kld_list="i915kms.ko", to ensure correct functionality. Although > > + the vendor drivers may attempt to load the correct drm driver, which > > + does not always work, the modesetting driver assumes the required KMS > > Any ideas why it does not work now with AMD A8 APU (Aruba, NI)? I don't > mind loading it by hand or via kld_list, but still want to know what had > broken automatic loading in my case (as it worked fine before). > Do you have xf86-video-ati installed? That is what loads radeonkms.ko. You should only need to manually load it if using modesetting (ati is not installed). > > + driver is already loaded and will fail if there is none. The > > modesetting > > + driver is now recommended as an alternative to the Intel driver; the > > + performance is comparable and stability is better with modesetting. The > > + ATI driver continues to offer better performance than modesetting. > > Can you elaborate a bit on the last sentense (my context is solely AMD/ATI, > I don't own or care about Intel hardware). Thanks, > The modesetting driver is meant to be a generic DDX that uses the ksm drm interface without any vendor specifics. Think of it like scfb sitting on the framebuffer, except it sits on drm so it can do OpenGL and actually uses that exclusively for accelerated rendering (Glamor for 2D). That is nice to have in general and could be a good improvement for some Intel GPUs since UXA and SNA aren't exactly stable and Intel hasn't done a release in years. Radeon (ATI) has good EXA support for everything up through r600. Radeon r600 and up have no 2D hardware, so EXA on r600 uses 3D pipeline, and for radeonSI there is no EXA, instead Glamor is the default. Recently, Glamor was made default for r600 as well since the performance is generally on par with EXA, and Glamor is an option for all Radeons down through r300. So, the built-in modesetting DDX offers nothing over the ATI DDX since both can use Glamor for 2D, but ATI DDX does have advantages in the form of EXA support (better for older hardware) and better performance through hardware specific knowledge. Testing on a multi-monitor setup, under both KDE4's kwin and Enlightenment21, with a mixed load of video playback and various games both full-screen and windowed (including multiple simultaneous) revealed performance is similar in terms of framerate, sometimes generic modesetting slightly lagging, while ATI performs better visually with noticeably less tearing. TearFree doesn't completely work as advertised and does negatively impact performance, but even without there is little tearing overall, whereas with generic modesetting DDX there is persistent diagonal tearing plainly visible when doing something as simple as scrolling a maximized text editor or browser window. TearFree would probably perform better with DRI3 but I haven't tested on DRM-next myself. > ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1855734.ja2yFjLJe3>