Date: Wed, 28 Aug 2013 13:41:42 +0200 From: Niclas Zeising <zeising@freebsd.org> To: Matthew Rezny <mrezny@hexaneinc.com> Cc: freebsd-x11@FreeBSD.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <521DE1F6.1030305@freebsd.org> In-Reply-To: <201308280420.r7S4K1OM083764@freefall.freebsd.org> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mrezny@hexaneinc.com> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521DE1F6.1030305>