Date: Sun, 01 Jan 2017 12:38:06 -0800 From: Matthew Macy <mmacy@nextbsd.org> To: "Beeblebrox" <zaphod@berentweb.com> Cc: =?UTF-8?Q?=22Fernando_Herrero_Carr=C3=B3n=22?= <elferdo@gmail.com>, "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org> Subject: Re: End of year Xorg status rant Message-ID: <1595bc0e7fd.104bb7c2f73595.7799477205099344822@nextbsd.org> In-Reply-To: <20170101183653.2c85698a@rsbsd.rsb> References: <20161230163653.54909631@rsbsd.rsb> <15952279f17.e0be0d8c34357.732964216134709731@nextbsd.org> <20161231120453.13adf858@thor.walstatt.dynvpn.de> <20161231145143.18e6ac99@rsbsd.rsb> <CAMwkeZz%2BJA2Lzjs9=MYVvYrU61XbLnfdYbwqAwXL3oBPWdw9kQ@mail.gmail.com> <20170101183653.2c85698a@rsbsd.rsb>
next in thread | previous in thread | raw e-mail | index | archive | help
---- On Sun, 01 Jan 2017 07:36:53 -0800 Beeblebrox via freebsd-x11 <freebsd-x11@freebsd.org> wrote ---- > Interesting discussion; thank you for all comments. > I have several questions: > > * Is TrueOS/PC-BSD ahead of FreeBSD on the Desktop? If so, why? The answer is probably "depends on the card", but again, is it ahead of FreeBsd for certain cards and why? If it's because they have integrated Matt's work, why has FreeBSD not opted to do so? That question goes to the heart of the challenges that lie with the FreeBSD developer model. When speaking to Krste Asanovic of RISC-V, an old colleague of sorts, about the reasons that FreeBSD has not fared as well as Linux over the decades, the point that resonated the most (or perhaps the only one that resonated) was the challenge of absorbing outside contributions. I've gone on at length in the past about the scalability issues of siloed committers vs lieutenants. In a nutshell, it is not a committer's responsibility to marshal in new work. There is much more of a "stick" for breaking / changing code with an import than there is a "carrot" for adding new functionality. At its core, it's a cultural issue. I don't know that it's fixable. When / if FreeBSD moves to git it will be *technically* easier to pull in contributions, but the liability and lack of incentive to do so will remain. > * Does the problem have anything to do with the Kernel Compat Layer for Linux (https://wiki.freebsd.org/linux-kernel)? I'm asking to understand the extent of the issue. Yes and no. In order for my "enhanced" linuxkpi to work a number of (small) changes to the core kernel need to be made. Getting those in without a commit bit simply takes time. I did have to make changes to the VM subsystem, but there is a new KPI that I can take advantage of. I have a patch to the linuxkpi to use the new "pg_populate", but the drivers don't yet work with said change. There is some GPL code that was imported out of expediency. However, "base" can remain legally "pure" by maintaining the extended linuxkpi, or at least the problematic bits, as a port (this has been my intention all along). Upstream drivers move faster than FreeBSD releases, by keeping linuxkpi/drm/{i915, radeon, amdgpu} we can release updates as soon as they come out for Linux. If someone feels strongly about keeping the linuxkpi BSD "pure", he can contribute by rewriting the pieces in question. > * Other than that, perhaps we could try and slice this problem in the short term from another angle: > Which GPU cards work (and are expected to work with new hardware) as of now? If anything, this discussion shows that the Graphics Wiki page (https://wiki.freebsd.org/Graphics) is inadequate for GPU selection. Perhaps it could be updated to a parametrised format showing functions by column each GPU card supports (rather than simply works"/"does not work"). It's pretty simple: if you need a discrete graphics card *today* you should buy Nvidia. If you want 95% stable integrated graphics you go with 11 on Haswell or earlier (it still panics on some WebGL code). If you can live with 80-85% you can use Broadwell or Skylake now with TrueOS or my repo. In a week or so when I announce drm-next with 4.9 you'll also have Kaby Lake support. I have made a commitment to myself to dogfood with AMD and not get lulled in to using Nvidia on FreeBSD. However, unless you've got an extremely high pain threshold like jmd (running amdgpu on his A12) or you have the chops to debug and hack the linuxkpi, it's not something I recommend. Over the last few weeks amdgpu has gone from insta-panic on startx to running fully accelerated with mesa 13 and stable for an hour or two. I'm optimistic that this will improve and will post to the list when I think it warrants wider use. > For example, as an immediate solution to my problem I would prefer (as I assume most others would) to purchase a new card that is confirmed to be working on multiple parameters rather than slog through a "hopefully soon" scenario for the next couple of years (I'm not on a laptop, btw). > > I'm still willing to contribute, but above solution would at least reduce frustration and increase my productivity. New systems would also benefit by selecting decent cards and reducing noise to the developers/list. I think the categories are straightforward. -M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1595bc0e7fd.104bb7c2f73595.7799477205099344822>