Date: Wed, 28 Aug 2013 17:15:20 +0200 From: Matthew Rezny <mrezny@hexaneinc.com> To: Niclas Zeising <zeising@freebsd.org> Cc: freebsd-x11@FreeBSD.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130828171520.00004b3e@unknown> In-Reply-To: <521DE1F6.1030305@freebsd.org> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising <zeising@freebsd.org> wrote: > 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 I meant was no user noticeable features in Xorg stack itself. I understand some other software running on Xorg might like a newer version, but from a user perspective the older versions of that software with working hardware rendering are more usable and useful than newer versions stuck on software rendering. Any new features are nothing more than theoretical if there is no practical way of running them. > 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. > Unfortunately, not at the moment. Relevant versions of Xorg/Mesa stuff is too tangled a mess to possibly remember off the top of my head. I can't provide an Xorg.log until I replace some hardware. The desktop 890FX/PhenomII/HD4870 is having instability problems due to VRM cooling issues on the motherboard. While diagnosing the problem, I pulled all the hard drives except one which has Windows7, primarily to prevent creeping data corruption on the FreeBSD drives. When I get the motherboard replaced, then I can follow up on this properly. The TurionII/HD4200 laptop is running Windows7 as I gave up on using FreeBSD on it months ago. When it had working R600 DRI then it was quite usable under FreeBSD with the only caveat being the lack of GPU power control meant battery life was a little short. Without functional hardware rendering, not only was it frustratingly slow, but the increased CPU load impacted battery life to the point it was unacceptably short lived away from a power outlet. > > > 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? > See above about version numbers. Port tree was up to date on the desktop. I've been running 9-STABLE with ports updated monthly. I was not using the WITH_NEW_XORG recently as my understanding was that should only be turned on (at that point in time) for Intel KMS testers (not sure if can really call any of them users given the current state). > > > 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. > I recognize it is in the tree. In fact, its landing in the tree is what provoked me to respond to this PR at the this time. However, I just saw a statement somewhere on wiki or ML that it would not be ready for real use for another 1-2 years. From the announcement of it coming into -CURRENT, I get the impression it is really not usable beyond testing. Lacking a working console after Xorg loads is a total show stopper in my opinion (and why I can't call the Intel KMS stuff anything more than testing a year after it went in tree). Sure the serial console works, but that is only practical for testing, not daily use as a desktop. Forget use on a laptop as I haven't seen a serial port on one of those in a LONG time, not to mention the impractically of carrying some other device to be the console for my laptop, already a device that is massively inferior to a desktop in every way other than portability. I do not intend to come across as unappreciative of the KMS work, but I'm being realistic. I understand the motives for choosing the ordering for KMS development. First came Intel due to the large number of laptops with integrated Intel graphics that didn't even have UMS support. Next comes ATI/AMD that needs to migrate from UMS to KMS for support of newer hardware. Last shall be Nvidia since there is a vendor supported binary driver that is sufficiently usable for most with that hardware. Anything else but the current "Big 3" will be left to rot since Xorg/Mesa are dropping/have dropped UMS support entirely without regard to the vast amount of hardware that is still in use and working perfectly well on older versions of the stack. The overall approach makes logical sense, but the problem is this gap in which UMS support is rapidly decaying before KMS support has graduated from it's testing status. Prior to the KMS mess, Radeon r100-r700 was the best supported GPU hardware under FreeBSD using open drivers and I'm surely not alone in having used that to guide hardware buying decisions over the last several years. The UMS support needs to be maintained in a better state until KMS is truly ready to supercede it, meaning not only have OpenGL actually work beyond trivial demos, but more importantly a console that works at all times. Even once we have newcons running atop DRM drivers, I still see immense value in having a method to switch back to text mode with the traditional console. Being able to reliably see a panic and get into the debugger without relying on serial ports pretty much requires a text mode fallback. That combined with how far in the distance newcons is means it should be a priority to devise a solution to get back to text mode now. > > > 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 the switch is that it is relative. Someone who may have had to flip it on at one point in time will later have to turn it off to retain the same working Xorg version. If they update ports without flipping the switch at the right time, getting back to working can be a nightmare. Further, the single switch only supports two version sets existing at any point in time. In the past, when there was both WITH_NEW_XORG and WITHOUT_NOVEUA switches, there were three possible version combinations controlled by two switches. That is in fact the last time anything worked for me (both set ON). In theory, after WITHOUT_NOVEUA went away, I should have been able to flip WITH_NEW_XORG to OFF and retained the same working configuration, but in reality that was not the case. It did not matter if the switch was ON or OFF, neither version would load the r600_dri.so when starting Xorg. I reported the problem on IRC and was told that was strange and shouldn't happen, but now we have a PR (the one I'm responding to) that says it is essentially expected behavior for the UMS driver that won't be addressed. > 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. > I know they are a package that need to have versions kept in sync. That is exactly why I advocate versioned ports. Having versioned ports would make it easier to keep those in sync as the ports could depend on the correct version and updating one would trigger others to the updated. Currently, when the switch is flipped, all the right ports need to be rebuilt in just the right order and it doesn't always work. Sometimes it in necessary to unistall them all and then rebuild everything to get Xorg to even start. I have seen numerous others on IRC and the ML facing the same problem. I tried freezing portions of my ports tree and selectively going back in time, and while that worked briefly, it became an unmaintainable mess over time and I gave up on it, resulting in spending progressively more time in Windows on my desktop (even before the hardware problems) just to get anything done. FreeBSD still runs all my server hardware with text consoles quite nicely. > 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. > In that case, at least there would be binary packages of each version rather than only for the default version. Binary packages are meaningless to me. I have to build everything from source to get working OPTIONS combination anyway. At least with versions I could be sure I'm building what I think I am/what I know I need. Using versioned ports would not only allow me to retain the known working versions, but would make it more clear what other software has to be frozen at a particular version to continue using it. Without that, it is rather unclear what are the exact repercussions of staying on older Xorg stacks. I see things like the databases and Python/Perl as great examples of what benefits versioned ports bring. People relying on older versions of those ports can do so with confidence while newer versions become available to those that need them. At the same time, those relying on older versions can move forward to new versions in testing environments, rework their software as needed, and eventually migrate to a newer version with confidence. Without versioned ports, updating the ports tree is a game of Russian roulette. When it comes to the Xorg stack, it feels like there is only one chamber without a bullet. It is my opinion that the primary factor holding back the "Linux desktop" (and by extension use of FreeBSD as a desktop OS) is the complexity and mess of Xfree86/Xorg. For more than a decade now, I've periodically tried both for desktop use and always found that the disaster that is X keeps me from being able to use it as such for more than a brief stint here and there. For a long time I used OS X as my desktop and regarded FreeBSD as a server OS, but with what Apple has done in the past few years OS X is as bad if not worse than Windows. As a former OS/2 user that sees Windows 2000 as the peak of Windows usability, and OS X 10.5 as the peak of Mac OS usability, I find myself so desperate for a usable desktop OS that I almost bought an Amiga X1000. Fortunately, MorphOS released 3.2 with PowerMac G5 support just in time to allow me to give that a spin on my old Mac without dropping significant coin on new hardware. Still, I'd like to see the non-Mac "UNIX desktop" eventually reach a state where it can be practically used as an everyday desktop OS. With it being so difficult for a highly technical (programmer) user to do so, it is obviously impossible for any "normal" user to do so. No surprise I see people frustrated with Windows installing one of the "easy" Linux distros, and then after a couple months at most, giving up and either going back to Windows or buying a Mac. I can only hope that Wayland is magically better, but the realist/pessimist portion of me fears that it will be too Linux centric, a nightmare to port, and still have no stable ABI. Lack of stable ABI in Linux is the secondary factor that prevents any real success outside the server space where admins can dedicate their lives to chasing updates and/or backporting bug fixes and required features. At least FreeBSD has a sensible way of versioning the ABI that allows it to be much more sane and really excel in that exact same space since it requires less effort to maintain production systems and can even be a better Linux than Linux in terms of running older Linux binaries on current OS versions. > Regards! Best Regards, Matthew "the desktop OS homeless" (OS/2 desktop user since Warp 3, until IBM abandoned it and the new owner renamed it, prompting a change of desktop OS to NT5 aka Win2k, until SP4 sabotaged the network stack prompting a downgrade to XP which was quickly followed by a migration to Mac OS X, satisfied until Apple killed compatibility and stability with 10.6 and then turned it into "desktop iOS" with 10.7, prompting complete abandonment of yet another platform and finding myself homeless when FreeBSD only fulfilled the role for a few months before the Xorg stack fell apart)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130828171520.00004b3e>