Date: Thu, 29 Aug 2013 21:40:30 +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: <521FA3AE.1010900@freebsd.org> In-Reply-To: <20130829181649.0000788c@unknown> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown> <521E5CA0.6080206@freebsd.org> <20130829181649.0000788c@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-08-29 18:16, Matthew Rezny wrote: > On Wed, 28 Aug 2013 22:25:04 +0200 > Niclas Zeising <zeising@freebsd.org> wrote: > >> 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. >>>> >>> 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. >> >> 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. >> > Sorry, but it is actually you who misses the point. It matters not what > new features are in the updated software or what new features are in the > Xorg stack. If there is not a working driver then the Xorg stack is > useless and thus all the software that depends on it is also useless. > It can have a million new whizbang features but all that means nothing > if I can't run the Xorg stack due to missing/non-functional drivers. > Miss out on new features, or miss out on all of it, which is worse? > Answer should be obvious. It does work! It works for me, on two different hardware configurations, it works for the rest of the x11@ team, or it wouldn't have made it into the regular ports tree. It seem to work for mostly everyone else, since there's been very little traffic on the list lately regarding any issues with our X. I'm not denying that it doesn't work for you, but since you haven't provided any information I need, I can't help you currently. In the meantime, the rest of us moves along to newer versions, with new features and probably bugs. Some visible, some not visible, and a lot of features needed. > > Also, "upstream" does not support our platform so we must support ts > ourselves regardless what version it is. We had a version that worked > thanks to the effort of you and others. It's great to know that a newer > version is in the works, but until it's fully baked, don't take away > what we already had working. To throw it away away prematurely is not > only frustrating for those who were using it, but it also makes waste > of the past efforts. Upstream does support us. They generally accept our patches, if we send them along, and at least I have mostly been helped and advised when I've asked for it. They might not be able to test every corner case, and naturally they will move ahead to new APIs and ways of doing things, regardless of what we do. We do, however, have to show that we still use the software, or we will come to a time when it is impossible to get X to work on FreeBSD. >> WITH_NEW_XORG= 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. >> > At this moment in time I'm not even sure what WITH_NEW_XORG means in > terms of versions so I can't really guess at what it does and doesn't > work with. What I know is that radeon DRI does not work with or without > it when I last tested flipping the switch. The wisdom I remember > reading in the past in regards to the switch was that leaving it off > should be the version where DRI works, setting it on would get new Xorg > which breaks DRI for sure, unless WITH_KMS is also on, in which case > DRI works but only for Intel KMS. WITH_NEW_XORG gives the new FreeBSD xorg stack, as opposed to the legacy FreeBSD xorg stack, it is as simple as that. It works with intel KMS, it works with Radeon KMS (it still needs some small fixes in ports to get that to play really well, but we are working on that), and it works with the nVidia blob driver, and it works, at least for me, with Radeon without KMS. I assume it works with other hardware as well, since no one has complained. >> > I am going by what you said last month: > Niclas Zeising on Tue Jul 9 18:50:47 UTC 2013 > > "The reason we haven't updated to xserver 1.14.1 is partly that it is > untested, and also that some drivers, most notably the UMS version of > the ati driver, no longer works with this version. We are currently at > version 6.14.6 of the ATI driver, which is the last to not need KMS. > This will be updated some time after the ATI KMS work in the kernel is > completed, and possibly merged back. This means that this work is > probably a year or two (at least) away." This is referring to xserver 1.14.1, which does not work with the ATI UMS driver, meaning we can't import xserver 1.14.1 untill *all* supported versions of FreeBSD has the Radeon KMS kernel module, which is at least a couple of years away. It has nothing to do with the state of the Radeon KMS driver in FreeBSD 10.0. > > Maybe I misinterpreted that somehow so correct me if I read it wrong. > It is good to hear the VT switching issue is being worked on with > intent to have it resolved by 10.0. That is much more reassuring than > the last message I saw on the ML on the topic. > Raphael Kubo da Costa on Fri Jun 21 12:34:54 UTC 2013 > > "Niclas Zeising writes: >> while the VT switching issues are being worked on. > > Side question: is someone currently working on this? I assumed nobody > had picked up that part of the work and kib wasn't interested in it." Kib wasn't interested in this, and when this was mailed, more than two months ago, I was unsure if it was ok to discuss in public who was working on this, since no formal announcement had been made yet. Today, there is a git branch, somewhere. Have a look at https://wiki.freebsd.org/Newcons, allthough that page haven't been updated in quite some time, there is a link to the SVN repo were this work is being done. >> 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. > > We have always been at the mercy of upstream to some extent. Yes, they > have been doing KMS for a while. Yes, we need to do KMS too. That does > not mean we need to throw UMS support out the window. We need to keep > around the UMS support for the foreseeable future. When the day comes > that all hardware supported by UMS is supported by KMS, then and only > then can we safely throw away UMS support. As it is now, some hardware > is vesa only on Linux but still properly supported on FreeBSD using the > older Xorg. That is a good thing for us. This will never happen. Some legacy hardware will loose support. However, we need to move on, to support new hardware, and to support other software. There are parts of the ports tree where we can't update because of bugs in our legacy xorg, and these ports include new features we must have, in order to in turn be able to update other ports. We can't hold off these updates forever, just because some rarely used xorg driver needs the legacy xorg stack. And, as I said, last time I checked, almost all drivers compile with xorg 1.14, and the same goes for the drivers in the ports tree. I hardly think Linux and the freedesktop foundation throws out support for legacy hardware just because they can. It is more likely because no one is using said hardware, and is there to support it. X needs to move on, to get support for modern hardware, as well as support for new graphics features, and better graphics performance. As a comparison, do you think I can plug in my old 3dfx voodoo2 card and have windows 7 support it? Or even windows XP? How about my nVidia 440MX? Some legacy hardware will loose support, it is regrettable, but sometimes unavoidable. > >> 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? > > The reason to not use the official binary blobs is they don't support > everything. Last time I looked, the nvidia hardware support was divided > across no less than three, maybe even four driver versions. Only the > newest hardware is supported by the current driver which works with > current Xorg stack. All the previous driver versions for the "legacy" > hardware are considered "legacy" drivers and not maintained. They don't > work with current Xorg stack on either FreeBSD or Linux. I cannot speak > to the quality of the open drivers on Linux as I have not been using > them. The nvidia hardware I have is sitting in boxes that only need > text mode because there was no viable driver for any other use of it. > From reading the status of the nouveau project, they have a driver that > is at least better than vesa (2D accel and some 3D support) which > supports all nvidia hardware with the GeForce name (and maybe even some > TNT stuff but not the early Riva). That goes back further than any of > the nvidia legacy drivers iirc. Relying on vendor drivers leaves us at > their mercy, and when it's a closed driver there is no way for us to > fork it when "upstream" (vendor) drops support. Additionally, even when > it is still vendor supported, we can't fix bugs ourselves. Those > factors are part of why we are using an open source operating system in > the first place. I don't know exactly which nVidia driver supports which hardware, and which version of xorg, I don't maintain those drivers. Yes, we are at the mercy of upstream, as always, but in the case of nVidia at least, this collaboration has worked fine as far as I know. I don't know about the status of nouveau in Linux, but I know that on the ubuntu machines I maintain at uni we use the binary driverers. The same goes for all the department's CentOS installations, which makes me believe that this works better, or at least is less of a maintenance and administration burden, compared to using the nouveau driver. It is possible to port the nouveau kernel bits to FreeBSD, but so far no one has volunteered to do it, and in my opinion, there are other things that are more important to fix, such as updating the intel KMS driver to support new intel graphics hardware. For nouveau there is a working alternative, for intel and radeon graphics, there isn't. >> 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. > > Why unify? We should have one Xorg stack version that is frozen at the > point where UMS reached it's peak. That version can be patched up with > bug fixes as need be. The new KMS version is effectively a fork which > should have separate ports to allow it to move forward without breaking > the old UMS stack. Feel free to step in and maintain this mess, the rest of us probably lack the time and energy to do so. It is not as easy as it sounds to backport security and stability fixes, and the UMS stack lacks support for a lot of modern graphics hardware. You also still haven't solved the dependency issues. > >> 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. > > So I'm not the only one who can't remember what versions correspond to > the possible switch options... I gave you a list of the most important version differences. I can go on, the intel driver in the old xorg implementation is at 2.7.1, while in the new stack it is at 2.21.9, and in our development repo it is at 2.21.15. libGL and dri is at 7.6.1 and 8.0.4 respectively. And in the development repo it's at 9.1. libdrm is at 2.4.17 in the old stack, and 2.4.46 for the new one. > The reason that nouveau has not worked well on FreeBSD is that it > requires both KMS and gallium. The very early versions that worked with > UMS were only the start. With KMS arriving sooner on Linux, the nouveau > project decided early on to go KMS only. That makes sense for them. > When we have KMS and gallium support ironed out with Intel and ATI, > then it should be less difficult to bring in a current nouveau driver > for those that want to not use the official nvidia binary blob, either > on principle or because they have older hardware that is only supported > by legacy drivers which only work with a legacy Xorg stack. Yes, as stated before, it is possible to do this work, however, FreeBSD is mostly a volunteer effort, and so far no one has stepped up to do the work. > For ports, look at the gcc situation. Some have gcc=any, some have > gcc=4.2, some have gcc=4.4+, some have gcc=4.6+, etc. It's clearly > possible to say it doesn't matter, only an old version, or only > version at least as new as X.Y. It should be possible to do so for the > Xorg stack as well. The ports that make up the stack can be kept in sync > by having the old UMS stack ports pinned to the old version and new KMS > stack held together by new_version+. For X apps and libraries, anything > that needs old or new can specify it. Anything that does not say can be > assumed to be Xorg=any. This would not be exactly how it is now. This > would be manageable. As for the binary packages, I think it's solvable > by depending on the proper library version, but don't quote me on that. Patches welcome! > Perhaps I should have said the provided binary packages mean nothing > for me. You are forgetting all other users, however. >> > The lack of testing capacity is one more reason to carefully preserve > the UMS Xorg stack in a usable and easily obtainable state before we > go too much deeper into KMS territory. Except that we lack important hardware support with the UMS stack, so we can't stay there forever. Not to mention that this prevents us from updates in other areas. > > Of course a University, with it's IT staff dedicated to the task, can > manage to maintain a group of UNIX desktops/workstations with Linux and > *BSD just as they had done with the proprietary UNIX workstations of > the past. The little rant I put after the meat of my post was more about > home and small business users without the support staff dedicated to > such efforts. If it's hard for me to maintain my own personal systems, > it's nearly impossible for the non-technical users. How many years has > one of the major industry magazines run a "Is this the year of the > Linux desktop?" cover story? I've been seeing at least one a year for > no less than a decade. Each time there's a reason why THIS year will be > THE year as opposed to all the others. They always miss the mark. Some > businesses and governments have done Linux desktop projects and some > have worked, but also some have not and they've gone back to Windows. > For all those that went back, chances of them even giving Linux or > another "UNIX desktop" (OS X aside) a try in the feature are slim to > none. Once burned, twice shy. I manage my computers, no problem. Have you tried PC-BSD? They've used the KMS enabled X by default for some time, and I think it works there as well. I haven't tested myself though. > >> 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. >> > I think that we all understand this point. That is after all how we > ended up here. Frustrated by vendors dropping support for the platforms > we loved, or sabotaging the versions we enjoyed in an attempt to force > us onto their vision of the future, is the reason we end up using open > source software. If the original author drops it, so what? If it has > value, the users who care can choose to continue on with it to the > best of their abilities. Unfortunately for Xorg, the value is the apps > that run on it more-so than the Xorg stack itself. That combined with > the complexity limits the number of people willing to bury themselves in > maintaining it at any version. It is not my ideal, but I would happily > put 40+hours/week into it if doing so could keep food on my table, a > roof over my head, and the lights on (ok, I can forgo lights, I just > need the computers to stay on). A myriad of personal problems has meant > that I haven't been able to do so much for Xorg/Mesa as I'm struggling > enough to find sufficient paid work. If anyone wants to help change > that, I'll commit to doing more for the community. Right now I must > pick my battles carefully, meaning I can only put much time into > advancing those aspects of my computing life that I depend on to do any > paid work I can find, and that itself takes a back seat to simply > finding suitable work to do. > Most of us have a day job besides the 40 hrs/week we put into FreeBSD. I know people are getting payed to work on FreeBSD, but most of the work is still done by volunteers. I understand that not everyone can do this, but keep in mind that everone working on FreeBSD, regardless of which part, is doing their absolute best to make FreeBSD as good as humanly possible. Regard! -- Niclas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521FA3AE.1010900>