Status of Intel Broadwell GPU Support??
theron.tarigo at gmail.com
Wed Mar 22 18:23:40 UTC 2017
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 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?
>>> I followed the instructions here:
>>> 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
>>> 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.
>> 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 :)
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
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.
More information about the freebsd-x11