Date: Fri, 30 Aug 2013 18:53:08 +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: <20130830185308.00003809@unknown> In-Reply-To: <521FA3AE.1010900@freebsd.org> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown> <521E5CA0.6080206@freebsd.org> <20130829181649.0000788c@unknown> <521FA3AE.1010900@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Aug 2013 21:40:30 +0200 Niclas Zeising <zeising@freebsd.org> wrote: > 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. > If it works, then why did you suspend this PR with the statement "This is a known issue and will not be fixed until the ATI KMS work is integrated into FreeBSD."? If it is not an issue, then why is it that I have seen numerous ML posts in the past couple years asking how to make DRI work on R600 class hardware? I have seen 2-3 people report it works but at least a dozen state that it doesn't work for them. If you know some magic trick to enable DRI in Xorg (not just in a couple games, but for KWin and apps) then please share it. > > > 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. > Accepting patches is not the same as supporting us. Upstream is essentially Linux. Even if Xorg and Mesa are not directly part of Linux, they now rely on the DRM drivers in Linux and design decisions are very Linux centric. i.e. dropping HAL and using udev for handling input devices, where HAL was a portable standalone but udev is a non-portable part of Linux. The BSDs and OpenSolaris are essentially left out in the cold to use what they can of the resulting code. We will always be behind on versions as we must port what we can and either ignore or replace the pieces that are too Linux specific. > >> 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. > The switch, as named, implies it is more for testing than use. "Give me something newer than default" is what that name says. It's exact meaning, in terms of versions and what features it enables/breaks, has changed over time. It would be more logical to change the name as the meaning changes. At least then it would be more obvious when there is a change in the effect. For example, it could currently be called WITH_XORG_KMS_SUPPORT, which of course requires WITH_KMS. >> > > 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. > OK, so that timeline was not for Radeon KMS support becoming usable, but for that support to exist in all branches that are supported by ports, which basically means 10-RELEASE, backport to 9, and wait for 8 to expire. Do you have any insight into when we might reasonable expect the Radeon KMS support to graduate from testing to general use? In time for 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. > I realize it's been some months since that statement, but I had not seen any statement on the status since that time. I am aware of multiple projects intended to replace SC. Newscons is one which had appeared to be stalled for some time but I had heard some mumblings about it recently enough to figure it was coming back to life slowly. There was also the KGI based console that looked usable around the same time Newcons started, but it too seemed to stall without going into the tree. I understand that sometimes there are private projects, but my feeling is that it is best to make as much public as possible. Publicly sharing information about upcoming and ongoing projects not only alleviates the need for some questions, but allows better planning and can enable people who want to same thing to possibly work together rather than needlessly duplicate efforts in private. > >> 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. > I know that this, support of all hardware with KMS, will never happen. I intended that to be interpreted as a need to maintain a UMS supporting Xorg stack indefinitely. Surely not every library and app can be used in their most recent form on the older stack, but at least the things that have been working with it can be kept for use by those who are satisfied with them. I have not tried my Voodoo2 in Windows 7 as that OS brings no benefit for the box which hosts that card, but it certainly works in Windows XP. I do not know about the 440MX as that's a cut down card, but my 4600Ti works at least up through XP. Windows 7 botched the audio path so badly that Windows XP remains the best OS for Win32 games that don't require DX11 (DX10 is possible on XP with a little hacking). Vendors dropping support don't mean the hardware isn't still used. Creative ate Aureal before the W2K drivers were even fully finished, but my Vortex2 works in XP, and thanks to community driver efforts it even supports A3D and hardware accelerated DS3D. Supporting hardware that is no longer vendor supported is one area where open source operating systems have previously and should continue to surpass closed operating systems. A good number of my SCSI cards don't have support for NT6+ and some (adaptec) don't even have any support for 64bit XP, but they all work great in FreeBSD and Linux. Sometimes old hardware is in use because it's not possible to upgrade (AGP video cards) and sometimes it's in use because it simply still works well enough there is no compelling reason to replace it. e.g. my file server has the PCIe slots full of network and SAS cards, so to avoid using the onboard intel video, I put my trusty MilleniumII in an otherwise useless PCI slot. Silly as that may sound to some, the integrated video consumes 3% of system memory bandwidth for a text mode console in idle state (surely much more for graphical modes) so using a graphics cards with dedicated hardware and memory reduces contention for system resources and improves performance on the tasks the box is intended for. > > >> 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. > That is the current state. The vendor's drivers are currently better performing for modern hardware and still a better experience for some older hardware. The much older hardware is stuck with either vesa or nouveau for a modern Xorg stack, but that is not the hardware you have. The importance of nouveau on FreeBSD is minimal now for the reasons we both covered, but that will change in time as more of the current cards go to legacy driver support by the vendor and the legacy drivers fall further behind in Xorg support while nouveau continues to improve. > >> 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. > First step is to separate the UMS and KMS stacks more cleanly, which I have said I would like to do when I am able to do so. Resolving dependencies will get easier with that done. Maintenance after that point is mainly keeping it buildable and collecting the bugfixes from our community. Upstream won't have much to backport in my opinion. > > > >> 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! > In due time. This would be part of phase 2 (improving dependency handling). There might even be a better way, but this is what seems practical and logical at the moment. > > Perhaps I should have said the provided binary packages mean nothing > > for me. > > You are forgetting all other users, however. > It would be interesting to know what portion of the user base actually uses the provided binary packages. I know a few reasons to do so. One is for speeds of installation. Another is to be able to point to the project as the vendor when documenting compliance in certain industries. That aside, the real point is I don't mind compiling from ports to get the options I want and the version I want. Right now, anyone wanting KMS needs to do that. If the default changes, then anyone not wanting KMS has to do that. If the Xorg stack ports split, binary packages for both could be available. That would be an improvement from the current state for users of binary packages. The issue would then only be the binary packages for apps that depend on Xorg stack, which is not unsolvable but something I personally am not motivated to do anything about. > >> > > 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. > Difference of perspective. If new hardware isn't supported, I hold off on buying it. If the hardware I have looses support, then something that was working becomes "broken" and that is a regression in functionality. > > > 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. > I tried PC-BSD on several occasions. I am not a fan of PBI, but they have made using ports with it easier than it used to be. The last time I tried PC-BSD, it was the version handed out at EuroBSDcon last year and it initially came up in vesa mode on my laptop. The ati/radeon driver (which was autodetected as the best option) would not work at all as it was apparently too new and I just got errors about not being able to invoke KMS mode. The radeonhd driver was also given as an option but did not have working DRI. I managed to get DRI working by patching and recompiling the driver. I found a bugfix for the particular chipset in my laptop sitting to rot in some repo at suse IIRC. The fix was committed to their repo, but the last official release of the radeonhd driver was prior to the commit, and without an official release that fix never got carried over from Linux. I dropped a link on IRC at the time but I did not check to see if anyone committed the patch to the radeonhd driver on FreeBSD. I also had problems with getting acceptable sound support since PC-BSD has everything going through PulseAudio, which is another whole bucket of worms. I played with it for a few weeks before deciding PC-BSD is still not for me. > > >> 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. > I thank those who manage to work their day job and still donate their time to the project. I envy those whose day job is to work for the this or any similar open project. Most of the jobs I've had are unrelated, so all my efforts are on my own time as is the case for most everyone else. Recently, it's been hard to find jobs that can even pay the bills, forget directly supporting an open project or even leaving time on the side to do so. I was half joking/half serious in my comments, in that I don't expect it to come true, but if anyone wanted to throw money at this problem I'd happily tackle it on a faster timeline than what I foresee myself being able to do while living in the current state. > Regard!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130830185308.00003809>