Status of Intel Broadwell GPU Support??

[Theron]

On 03/22/17 13:58, Pete Wright wrote:
>
>
> On 03/22/17 10:20, Theron wrote:
>> On 03/22/17 08:50, Bob Willcox wrote:
>>> On Wed, Mar 22, 2017 at 09:02:27AM +0000, Thomas Mueller wrote:
>>>>> Hooray!! My system is up and running the 
>>>>> FreeBSDDesktop/freebsd-base-graphics version!
>>>>> The download, build, & install was mostly uneventful. Thanks again 
>>>>> for your help!
>>>>> Bob
>>>>> Bob Willcox
>>>> Did you use freebsd-base-graphics for buildworld and buildkernel, 
>>>> or did you use the normal /usr/src for buildworld and 
>>>> freebsd-base-graphics for the kernel?
>>>>
>>>>
>>>> Tom
>>>>
>>> I followed the instructions here:
>>>
>>> https://github.com/FreeBSDDesktop/freebsd-base-graphics
>>>
>>> and used freebsd-base-graphics for both buildword and buildkernel. 
>>> I'm not too
>>> clear on just what that means for any future updates, though. I have 
>>> been
>>> hoping for the past year or more that the patches/changes included in
>>> freebsd-base-graphics would get integrated into the base. I really 
>>> don't know
>>> if that's happened or planned to be done. Been kinda frustrating.
>>>
>>> Bob
>>>
>>
>> I think the problem with upstreaming is that 
>> FreeBSDDesktop/freebsd-base-graphics uses elements of the Linux 
>> source tree organization, namely the drivers/gpu and 
>> Documentation/gpu directories, which do not fit in the normal FreeBSD 
>> source tree.  As far as I can tell the FreeBSDDesktop team did this 
>> to minimize differences between Linux and FreeBSD gpu sources.  Maybe 
>> these directories should be put elsewhere and just the makefiles 
>> modified to resolve the differences?  Or have the source consist of 
>> the files with unmodified Linux paths along side a patch file 
>> correcting the differences, similarly to ports? Given that most 
>> technical issues are out of the way and that there is a high user 
>> demand for this support, it seems to be time for the developers to 
>> revisit this issue.
>
> I don't want to speak for mmacy@ or others, but my understanding was 
> to first implement a linux KPI layer for FreeBSD that is up to date 
> with the current linux kernel code.  this should allow for easier 
> integration of the DRM bits from linux onto FreeBSD, and help get 
> other drivers and that are linux specific working.
>
> I believe currently work is happening right now to get the lkpi code 
> from drm-next integrated into upstream CURRENT, and some folks are 
> working on creating a drm port/pkg for intel i915 graphics as well as 
> for amd GPU's.  This plan should help avoid some of the nastiness you 
> mention, while also keeping GPL'd that is required to get all the bits 
> working correctly out of the base system.
>
> at least that is my understanding - i'm sure someone will chime in if 
> i'm off base/confused though :)
>
> -pete
>
You must be right about linuxkpi being the real issue.  I did an 
experiment locally where I deleted sys/dev/drm which is a symlink to 
drivers/gpu/drm, moved drivers/gpu/drm to sys/dev/drm, and deleted 
drivers/gpu entirely.  The kernel still builds with no issue, so the 
only remaining reason for drivers/gpu is diff compatibility with Linux 
source.

How would these drivers work as ports?  Would this work like 
x11/nvidia-driver?  Of course there must be others but Nvidia and 
Virtualbox are the ports I have encountered which provide kernel modules.

Theron