From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 11:42:05 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B890FDBC for ; Wed, 28 Aug 2013 11:42:05 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DE972078 for ; Wed, 28 Aug 2013 11:42:02 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 475B740003 for ; Wed, 28 Aug 2013 13:41:59 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 3CE4640004; Wed, 28 Aug 2013 13:41:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 86AE240003; Wed, 28 Aug 2013 13:41:57 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQ4mj263Wz8hVm; Wed, 28 Aug 2013 13:41:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id MUCbCg-zWb1O; Wed, 28 Aug 2013 13:41:47 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQ4mQ6NS8z8hVn; Wed, 28 Aug 2013 13:41:42 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cQ4mQ5pdKz9Ctj; Wed, 28 Aug 2013 13:41:42 +0200 (CEST) Message-ID: <521DE1F6.1030305@freebsd.org> Date: Wed, 28 Aug 2013 13:41:42 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Matthew Rezny Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> In-Reply-To: <201308280420.r7S4K1OM083764@freefall.freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:42:05 -0000 On 08/28/13 06:20, Matthew Rezny wrote: > The following reply was made to PR ports/156405; it has been noted by GNATS. > > From: Matthew Rezny > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware > rendering > Date: Wed, 28 Aug 2013 05:56:45 +0200 > > This is a very puzzling problem that really irks me. > > I had perfectly working R600 DRI on very similar hardware (HD4870) > as well as a laptop with similar video (HD4200), but some Xorg > update at least a year ago killed it. Why the regression without any > apparent attempt to fix? The last it worked properly was the point in > time when setting WITHOUT_NOVEAU allowed r600_dri.so to be compiled. > All worked perfect and the newer Xorg brings no new features from a > user point of view, only new problems. Our old xorg is blocking other ports from updating, so while it might not directly bring new features from your point of view, it is blocking new features in other areas. What versions of relevant software are you using? Do you have a xorg.log file to show us, so that we can see what's going on. > > I could almost understand if there was some actual problem with the > R600 DRI, but there isn't. Starting X results in the software > rasterizer, which makes KDE painfully slow . However, running certain > apps I get hardware rendering. i.e. OpenArena loads r600_dri.so instead > of swrast and the framerate in timedemo clearly slows hardware > rendering is in fact working. Why can a game get hardware rendering but > the rest of X can't? Once again, what version of libGL and libdri and drm ports are you using? Are your ports tree up to date? Are you using WITH_NEW_XORG or not? > > Considering how far off KMS support is, I would hope this issue would > have been addressed by now. From my viewpoint, it looks like some > stupid and likely trivial bug that causes Xorg to load swrast instead > of r600_dri, but I haven't the time nor patience to dig through the > mess that is Xorg to attempt to figure it out. Considering KMS for Ati/Radeon cards already hit the tree, I think it is safe to say we have been busy elsewhere. > > Considering the recent suggestion of flipping the WITH_NEW_XORG switch, > which itself is very ambiguous, I must re-iterate a previous > suggestion: Instead of having a single set of ports for Xorg, PLEASE > make some versioned ports for the older versions. This would allow the > "legacy" hardware (as in what I think most of us are actually using) to > continue to function in a useful fashion. Considering the precedent of > version-named ports (e.g. postgresql, mysql, bdb, etc), I cannot fathom > why this is not done for Xorg/DRI/Mesa. What is the problem with the name of the switch? It is fairly clear what it does in my opinion. The problem with versioned ports, apart from the fact that it probably would increase our workload even more, is that it is very hard to get a port to depend on different versions, with different shared libraries, functions, etc. etc. You also have to remember that xorg and mesa is a package, and mixing up versions in general won't work. And lastly, even if we would have versioned ports, binary packages still would have to depend on the default version (same for perl, databases and so on), so it wouldn't gain you very much anyway, since you would need to compile stuff from soruce to get a nondefault version. Then you might as well just select version in /etc/make.conf and then compile xorg to begin with. Regards! -- Niclas Zeising