Date: Wed, 28 Aug 2013 22:25:04 +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: <521E5CA0.6080206@freebsd.org> In-Reply-To: <20130828171520.00004b3e@unknown> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EPSWDGHSUMXNHEICCFBM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/28/13 17:15, Matthew Rezny wrote: > On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising > <zeising@freebsd.org> wrote: >> On 08/28/13 06:20, Matthew Rezny wrote: >> 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. >>=20 > What I meant was no user noticeable features in Xorg stack itself. I=20 > understand some other software running on Xorg might like a newer=20 > version, but from a user perspective the older versions of that=20 > software with working hardware rendering are more usable and useful=20 > than newer versions stuck on software rendering. Any new features > are nothing more than theoretical if there is no practical way of > running them. You are missing the point. Some software needs updated xorg stack, because of lacking features or bugs in our current xorg. If we can't update those packages, we are missing out on features there, and that might in turn stop other updates. Besides that, our current xorg is lacking support upstream, meaning security isses might go undetected, or we need to backport patches, which takes time and effort. >=20 >> What versions of relevant software are you using? Do you have a=20 >> xorg.log file to show us, so that we can see what's going on. >>=20 > 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=20 > TurionII/HD4200 laptop is running Windows7 as I gave up on using=20 > FreeBSD on it months ago. When it had working R600 DRI then it was=20 > 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=20 > unacceptably short lived away from a power outlet. Without a list of software, logs and other relevant information it is impossible to help you and debug this issue. It is not very hard to get a list of installed ports and packages, a dmesg output and a log from xor= g. As a side note, cooling issues can probably cause all sorts of issues that doesn't seem related at first, so that might be a place to start. >>=20 >>> 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? >>=20 >> Once again, what version of libGL and libdri and drm ports are you=20 >> using? Are your ports tree up to date? Are you using >> WITH_NEW_XORG or not? >>=20 > See above about version numbers. Port tree was up to date on the=20 > 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). WITH_NEW_XORG=3D is usable for other hardware configurations as well, and= with the addition of the radeon KMS driver, it should work fine even with radeon hardware. It might need some polish in the ports department to get optimal performance, but we are working to get that into the tree in time for 10.0. >>=20 >>> Considering how far off KMS support is, I would hope this issue=20 >>> 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. >>=20 >> Considering KMS for Ati/Radeon cards already hit the tree, I think >> it is safe to say we have been busy elsewhere. >>=20 > 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 doubt it is 1-2 years away, where did you see that mail? Of course there will be some bugs, as always, but it has been in the works for some time, and it has been tested and deemed ready for a release (10.0, which is due in a couple of months). With regards to VT switching, I can understand that it is an issue, but it is something that's actively being worked on, and the plan is to have it resolved before 10.0 as well, so FreeBSD is really making progress in the graphics and desktop department. >=20 > 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=20 > 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. The problem is that we are in the hands of upstream development. Linux has had KMS for quite some time, so it is natural that xorg is starting to chop of support for UMS. And we need to get on that train, or get left in the dust. The FreeBSD x11@ team is stretched for resources as is, so we need to focus on what is important. And newcons isn't far in the distance, it is happening. With regards to nVidia, why should we not use the official binary blobs? They work (last time I heard) and are supported upstream. I doubt we'll ever see any KMS driver for nVidia graphics cards as long as we have this support. We are not Linus, giving the finger to all vendors who want to support our operating system, just because they might use a different license than the core OS uses. How far along is the linux KMS work for nVidia hardware? Lastly, last time I checked most drivers compiled fine with the new xorg distribution, and even with xserver 1.14 which is in experimental testing. Unfortunately we (the x11@ team) can't test every conceivable combination of hardware, so there might be some issues. On the other hand, there have been few complains about video hardware and drivers not working, so either noone is using those drivers, or they work ok. >>=20 >>> Considering the recent suggestion of flipping the WITH_NEW_XORG=20 >>> 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. >>=20 >> What is the problem with the name of the switch? It is fairly >> clear what it does in my opinion. >>=20 > The problem with the switch is that it is relative. Someone who may=20 > 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=20 > 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. This is why we're slowly working towards getting one unified version of xorg again, but it takes time, both because we need to port software, and because the FreeBSD kernel and core system needs to "catch up" in terms of new hardware support. Currently there are two distributions, the old one, which is xserver 1.7.7, libGL 7.6.1 (if I'm not mistaken) and old versions of the intel driver that doesn't support any modern intel GPUs, and so on. And then there is the new distributions, which needs a modern FreeBSD with support for intel KMS if you have a intel GPU, xserver 1.12, mesa 8.0 and so on. I understand that it can be troublesome moving between versions. We are doing our best to make it work, but sometimes issues occur, especially when moving backwards, since that means ports versions going backwards. The WITHOUT_NOUVEAU option was removed some time ago, since NOUVEAU never really worked well on FreeBSD, as I've come to understand it. >=20 >> 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. >>=20 > 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. Well then, how do you solve it if you have an application foo, that wants libGL and xorg-server? Which version should it depend on, libGL A.B or libGL X.Y? How do you solve that, especially for a binary package? You can't, not with our current package manager at least. If you install the package foo, you'll get the default versions of libGL and xorg-server, otherwise you'll have to compile yourself anyway. It is exactly the same now. >=20 >> And lastly, even if we would have versioned ports, binary packages=20 >> still would have to depend on the default version (same for perl,=20 >> 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. >>=20 > 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=20 > 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. Binary packages are of no interest for you, maybe, but you are forgetting the bigger picture. It has to work as well, and all this has to work for everyone, with different versions of FreeBSD, different hardware, and different requirements. Can you maybe see now why it is actually a quite time-consuming effort to maintain this. Versioned ports would only give us even more to support, with little gain. If you set WITH_NEW_XORG, you get the new xorg distribution, comprising a set of N ports, with specific versions. If you don't set it, you get another set of M ports with specific versions, those sets might overlap, but not everywhere. You can't, however, pick different versions of different ports, they have to work together. And you can't install them side-by-side. While it might be possible to version the ports, I doubt it. This discussion has happened before, and I have still not seen any progress. You still can choose which distribution you want, by setting *one* option= =2E Besides, if we on top of different versions here, start adding different versions of other ports, you can soon follow that the dependency related issues will explode. >=20 > It is my opinion that the primary factor holding back the "Linux=20 > desktop" (and by extension use of FreeBSD as a desktop OS) is the=20 > 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. xfree86/xorg is a complicated beast, that's why we're working on porting it and making it as easy to use as possible. I've been using FreeBSD on my both my laptop and desktop for quite some time, without any major hassles. I even run our testing versions, to start ironing out issues and bugs before the rest of the community sees our requests for further testing. As stated before, we do our best to test this, but the sheer variety of hardware out there makes it impossible to cover all corners. I have friends that use some free operating system or another without any hassle with X, and I sysadmin several Linux boxes with desktop environments in the computer club at the university I attend. Not to mention that the university also uses linux, so saying that the "UNIX desktop" is a no-go is clearly wrong. Remember also that FreeBSD, and the ports collection, including all relevant software for this discussion (except the nVidia drivers) are open source. Feel free to help out, experiment and send patches, that's how we in the x11@ team ended up here. And while it doesn't seem like much, some of us spend in excess of 40hrs/week some weeks, to make all this work. Regards! --=20 Niclas Zeising FreeBSD ports and doc commiter Member of the FreeBSD x11@ team Happy FreeBSD user ------enig2EPSWDGHSUMXNHEICCFBM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBCgAGBQJSHly0AAoJELuNS1e7i1VR6mAP/1SwKlv8Oa4gfaTY1prJkI3R qjGWtN0evJFnpoYsVelOrFKz2cY8gMOnlpcGgCaNzw8CIzi2Nd/X2WJ7CT1Vq6Az eQAyS5hzRdvRK1jBhXXJkU9R86vD4gVxdd66ZTqPfIqnCk3KIHudnyw9sUm0O4Uo QkAS2XcE5vZPa6aOFIw68g2B4qaRRU7KjAjHqxxARnaNllrFTIqPRZl6Pkoo+K0E C9zwiVTClqyWOEHlazRi4N0D0ZB3rGIfEex5m7UVP6PpGloPKl13fnieK6D6xIiq sn4kUe/GDouXsf2e2tMMVllmrgnAKdzSgLvhccqgahZgVVxxk9xDJ4hg4aCwvHtU PzOBUekP3RFXBP0TghdCx6AVdEl9b05074OmzXRSC1K38Q6SPJz/LxrwWNE8C2sY MuyezYbRb4kK7FMDRckgniWULZ8fEkhJZaLi68Mt5Xzi0Owjo75jMGS4HU9boRtr GH28eo65yqZGucya2ZxSnD4v7KcCA4Ec7At03HuVQd2ik7xJqmKLgxgaTHBwfX1V 12L5dPNqnjRZljYa3z5ikQQjjyeb3Y6uVIGkYab302XyLoHcuLnBHHdpfuQro5QB hxWkhFFD/2U7Mw4r9h1Ep14XKsGT6IA9EcdE1x1/ilOzcFPE0MnL3j7sQ/eaiIxq ToP7gu8yrESBq1VCDHa3 =ihxB -----END PGP SIGNATURE----- ------enig2EPSWDGHSUMXNHEICCFBM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521E5CA0.6080206>