End of year Xorg status rant

Sat Dec 31 11:05:15 UTC 2016

Am Fri, 30 Dec 2016 15:54:05 -0800
Matthew Macy <mmacy at 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20161231/70568429/attachment.sig>