End of year Xorg status rant

Matthew Macy mmacy at nextbsd.org
Sat Dec 31 23:41:56 UTC 2016


 > > I think we face a political problem, not so much a man-power-driven one 
 > I'm sure the Foundation and developers have been debating whether to drop desktop all together and only focus on server-side, which I would have no problem with and would just migrate to some other OS. The problem as you stated is that this half-assed approach is not working. Put simply, the choices are: 
 > A. Drop all Xorg related ports, kernel modules and move on or 
 > B. Seriously go after creating a decent (I don't need fantastic) desktop experience 
 >  
 > We all know what option A would mean for the future of FreeBSD, but not my call. 
 > If all else fails, I'm afraid I must agree with: 
 > > Time to change paradigm, time to change OS ... 

At this time, if you need either a) easy interoperability between ports and Fortran (I say easy because I know people doing it) or b) GPGPU compute, then yes you really have no choice. I myself run Ubuntu only because of CUDA and Nvidia. I've undertaken this work so that I can do GPGPU using Radeon Open Compute. Whether or not AMD will actually deliver, or if they do be able to successfully continue to support it the way Nvidia has is another question entirely. If at all possible I would like to do my AI/ML work on FreeBSD. But I'm well aware that predicating anything on the success of AMD is very speculative.

 At least on the kernel side - "politics" is a cop out for people who don't have the time/energy/ability to step up to the plate and do the work. Dragonfly and OpenBSD have proven this in spades. If lots of capable people showed up tomorrow to maintain the KMS drivers we could easily track Linux. Previously there was a very very deep *technical* problem in that the incremental amount of work required to update was insurmountable. Now that the diff with upstream has been reduced from 12,000-15,000+ lines below 300-400 lines the "activation energy" to update has been reduced by a factor of 5-10x. Nonetheless, it is still several days of work by someone knowledgeable to replay the DRM and driver updates and extend the linuxkpi as needed. To date I have only done it for i915 because the costs were partly offset and because I see dogfooding by developers as critical to the long term health of FreeBSD. It is not work I enjoy and I no longer have the time for what amounts to onerous charity work. I will continue to do it for drm/amdgpu, but i915 is too much extra work (at least two thirds of the time for updating to 4.9 was taken up by it). I have someone else lined up to do it provided his work situation permits. On the ports side, there is a sociopolitical component. There are people contributing patches that sit idly in Bugzilla indefinitely. The amount of work to remain current exceeds what Koop has the time and energy for. That is why I have predicated any future bug fixing of i915 on having a couple of  active contributors be sponsored for a ports bit. There *are* people at that level willing to do the work whose hands are tied by limited ports committer bandwidth. And I'm unwilling to make any further sacrifices to make KMS work if I have to maintain a separate ports repo myself that may or may not ever make it in to the main package builder repo.

TL;DR - Things are getting better. KMS needs continued extra help. It will never work as smoothly as Ubuntu.


 > Matthew: 
 > Thanks for the info. 
 > > .. the great work you've done as the major comitter to this project 
 > First off, personal thanks even if I don't benefit from it directly. 
 >  
 > > If you care about Radeon I would welcome contributions to its upkeep. 
 > > Unfortunately, the intersection set between people who care about 
 > > radeonkms and those attending to its upkeep is currently empty. 
 > I'll take a look, but I just don't have the coding experience/knowledge. I'd have to travel pretty far to get to the point where my contributions would be productive for either side :(( 
 

The offer stands. Once things were to reach  a "known good point" even without much technical skill an individual can help greatly by simply bisecting regressions. And really, one learns best by doing.

-M







More information about the freebsd-x11 mailing list