Date: Sat, 31 Dec 2016 12:04:59 +0100 From: "O. Hartmann" <ohartmann@walstatt.org> To: Matthew Macy <mmacy@nextbsd.org> Cc: "Beeblebrox" <zaphod@berentweb.com>, "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org> Subject: Re: End of year Xorg status rant Message-ID: <20161231120453.13adf858@thor.walstatt.dynvpn.de> In-Reply-To: <15952279f17.e0be0d8c34357.732964216134709731@nextbsd.org> References: <20161230163653.54909631@rsbsd.rsb> <15952279f17.e0be0d8c34357.732964216134709731@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Am Fri, 30 Dec 2016 15:54:05 -0800 Matthew Macy <mmacy@nextbsd.org> schrieb: > > Thanks for reading, merry Solstice and a happy New Year to all of you. > > > > > > SYSTEM: > > * FreeBSD 11.0-STABLE #0 4370756a792(stable/11): Fri Dec 30 09:48:35 +03 2016 > > * All ports installed through poudrire built packages. > > * GPU: RS880 [Radeon HD 4250] > > * Possibly relevant Xorg.log output: > > (WW) Falling back to old probe method for fbdev > > (II) Loading /usr/local/lib/xorg/modules/libfbdevhw.so > > (EE) LoadModule: Module fbdevhw does not have a fbdevhwModuleData data object. > > (II) UnloadModule: "fbdevhw" > > (EE) Failed to load module "fbdevhw" (invalid module, 0) > > (WW) Falling back to old probe method for vesa > > (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support > > > > > > -- > > FreeBSD_amd64_11-Stable_RadeonKMS > > Please CC my email when responding, mail from list is not delivered. > > > I've just updated drm-next (drm/i915/amdgpu/radeon) to linux 4.9. The amdgpu driver > works well enough that I can now dogfood, but is not quite to the point where I would > recommend it to others. The radeon driver experiences sufficiently little churn that I > can trivially update it whenever I update drm and amdgpu. However, I have only very > lightly tested radeon many months ago, and I personally have no interest in hardware > older than the SI that amdgpu now supports. 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. > > -M This is in a separate source tree, isn't it? Despite the great work you've done as the major comitter to this project, for end users or those interesdted in FreeBSD as a system platform the situation with GPU support is a mess. The progress on Linux is tremendous - on new high performance GPUs as well as on embedded MIPS or ARM/ARM64 systems. The GPU problem isn't a "viewing issue only" - it has also great impact on how useful FreeBSD - or in general the platform of concern - is for a scientific GPGPU usage. I remember a time, that was the pre FBSD 5 era, when FreeBSD had a stand in the scientific/numerical community. That is history now. Another issue of how to loose potential clients on FBSD is in governmental and scientific areas the fact, that we need to purchase hardware "out of the here and now" for the next couple of years - in worse cases up to five. Selection must be made carefully. So no one is going to obtain old, outdated but supported hardware. And almost all of our desktop systems has been used for numerical stuff. I can not speak for computer centers, where they select and use the OS on other objectives than "we" do when we have the reign over our decissions. I think we face a political problem, not so much a man-power-driven one. nVidia provides a BLOB, this BLOB works well even with the most recent hardware of theirs, but it lacks in support for OpenCL and their own CUDA acceleration framework. I never understood why. I asked nVidia - and they told me, that there is no request from the community ... so far. That is a claim and I can not hold something against it, since it seems obvious that I'm, with some other single people, are the only one compared to millions of others - de facto Null so to speak. And AMD? Well, 2006 or 2008 the company claimed to support the opensource community better than before, but that left in history to be a insubstancial claim. Their hardware might be a great deal even for GPGPU purposes with OpenCL, but this is Linux only as far as I can tell. I have no idea how to solve the problem. Maybe a tighter communication with the vendors? I doubt that there were any serious interactions from the core in the past. There is still the rumour about core team members very reluctant to change kernel code towards a Linux-style API in some portions to support a faster transition of the Linux-well suported opensource drivers to FreeBSD. I can not confirm this, but is has been published on one of the FBSD lists. I'm not into kernel development, so I do not know the strange personalities behind such decissions or the reasoning (it might be that there were security/design objections which would FreeBSD make vulnerable, I don't know). Isn't it a henn-egg problem with the driver question? No driver support means no use of the OS means no customers buying a specific GPU/hardware type means no market means no ambition to provide/develop drivers? Time to change paradigm, time to change OS ... oh -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWGeQ2wAKCRDS528fyFhY lKfIAf9B8EofUIPzLf1QnD5e10ZgxQzVw87rj0MpdFm1mwYH1IfP+4e5bOHLviYC i4NQgbw7H/uskSB1YxShF4k5ekD1Af4n8D7wkV2B98FMzLFmdh3bfCDfhIP7XcOR p/CVMuQNj6air62j+GeJ160jw6bks9vE0yChG5W3goqDudfBkuZV =gray -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161231120453.13adf858>