FreeBSD i915 driver update

FreeBSD i915 driver update

[Scott Long]

Hello intel-gfx,

I'd like to offer a heads-up on the ongoing work in the FreeBSD project
to update to a contemporary version of the i915 driver.

For context, some background information on the earlier approaches we've
taken to import the i915 driver in FreeBSD. In the past, developers often
reworked the imported driver to conform to FreeBSD coding and even style
conventions. Needless to say, this divergence from the upstream driver
caused an ever-increasing maintenance burden, and proved to be a large
impediment to updating the driver.

In May 2012 we updated to migrate to the KMS driver and bring compat up
to SandyBridge / IvyBridge hardware. We remained on this version for
several years.

In March 2016 Jean-Sébastien Pédron updated to the i915 driver from
Linux 3.8.13, bringing in initial support for Haswell GPUs. A lot of
effort went into reducing gratuituous differences versus the upstream
driver, but the delta to the Linux verison is still significant. This
is what we have in FreeBSD HEAD right now, and represents about 17KLOC
of diffs against Linux. FreeBSD HEAD source reference:
https://svnweb.freebsd.org/base/head/sys/dev/drm2/i915/

Jean-Sébastien and other developers have been discussing a new approach
for post-3.8.13 updates. Instead of maintaining a large set of changes,
the plan is to keep the driver as close as possible to the upstream Linux
version, and use straightforward shims to adapt to interfaces provided by
FreeBSD where possible.

We took an initial step on that path with an update to the Linux 3.9
driver, and have reduced the diffs to about 9KLOC.
https://github.com/freebsd/freebsd-base-graphics/tree/drm-next-3.9

Current work in progress is targeting an update to Linux 4.6, and the
driver currently attaches and basic functionality works (e.g., xterms
and glxgears).  A demonstration screen shot is at
https://plus.google.com/114029301710423058970/posts/485LyZegC9B
The delta to Linux is about 4KLOC right now.
https://github.com/iotamudelta/freebsd-base-graphics/tree/drm-next-4.6

The diffs against the upstream linux code have roughly halfed with
each porting effort.  The focus is on creating a linux KPI compatiblity
layer for FreeBSD that will allow the DRM and KMS drivers to work with
minimal changes.  The goal is to get it under 1KLOC and to the point
where its feasible to follow the upstream development on a 
change-by-change basis.  Our ultimate goal is to align closely with
the Linux graphics development community and collaborate with Intel,
ATI, and others on keeping FreeBSD up to date in their product
development efforts.

The Linux KPI module code and DRM modules will be put into the FreeBSD
ports tree to make them more modular and sharable between different
branches and forks of FreeBSD.  We're hoping to get a BETA level
release into the ports tree in time for the FreeBSD 11.0 launch this
summer.  However, the effort is still very much ALPHA quality right
now and will stay in github as it matures.

Even though the code is still ALPHA, we're looking for any feedback
on the approach we're taking, as well as any reports of successes
and failures on a variety of hardware.  Feel free to follow up on
this mailing list, or to join the freebsd-x11 mailing list on
freebsd.org.  We're also doing a bi-weekly community conference call
to discuss this and other topics in graphics on FreeBSD, and we
welcome others to join the discussion.  As we continue the progress
on getting the code fleshed out and matured, we expect that we'll
collaborate on this list and in the IRC channel.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

FreeBSD i915 driver update

[Scott Long]

Hello intel-gfx,

I'd like to offer a heads-up on the ongoing work in the FreeBSD project
to update to a contemporary version of the i915 driver.

For context, some background information on the earlier approaches we've
taken to import the i915 driver in FreeBSD. In the past, developers often
reworked the imported driver to conform to FreeBSD coding and even style
conventions. Needless to say, this divergence from the upstream driver
caused an ever-increasing maintenance burden, and proved to be a large
impediment to updating the driver.

In May 2012 we updated to migrate to the KMS driver and bring compat up
to SandyBridge / IvyBridge hardware. We remained on this version for
several years.

In March 2016 Jean-Sébastien Pédron updated to the i915 driver from
Linux 3.8.13, bringing in initial support for Haswell GPUs. A lot of
effort went into reducing gratuituous differences versus the upstream
driver, but the delta to the Linux verison is still significant. This
is what we have in FreeBSD HEAD right now, and represents about 17KLOC
of diffs against Linux. FreeBSD HEAD source reference:
https://svnweb.freebsd.org/base/head/sys/dev/drm2/i915/

Jean-Sébastien and other developers have been discussing a new approach
for post-3.8.13 updates. Instead of maintaining a large set of changes,
the plan is to keep the driver as close as possible to the upstream Linux
version, and use straightforward shims to adapt to interfaces provided by
FreeBSD where possible.

We took an initial step on that path with an update to the Linux 3.9
driver, and have reduced the diffs to about 9KLOC.
https://github.com/freebsd/freebsd-base-graphics/tree/drm-next-3.9

Current work in progress is targeting an update to Linux 4.6, and the
driver currently attaches and basic functionality works (e.g., xterms
and glxgears).  A demonstration screen shot is at
https://plus.google.com/114029301710423058970/posts/485LyZegC9B
The delta to Linux is about 4KLOC right now.
https://github.com/iotamudelta/freebsd-base-graphics/tree/drm-next-4.6

The diffs against the upstream linux code have roughly halfed with
each porting effort.  The focus is on creating a linux KPI compatiblity
layer for FreeBSD that will allow the DRM and KMS drivers to work with
minimal changes.  The goal is to get it under 1KLOC and to the point
where its feasible to follow the upstream development on a 
change-by-change basis.  Our ultimate goal is to align closely with
the Linux graphics development community and collaborate with Intel,
ATI, and others on keeping FreeBSD up to date in their product
development efforts.

The Linux KPI module code and DRM modules will be put into the FreeBSD
ports tree to make them more modular and sharable between different
branches and forks of FreeBSD.  We're hoping to get a BETA level
release into the ports tree in time for the FreeBSD 11.0 launch this
summer.  However, the effort is still very much ALPHA quality right
now and will stay in github as it matures.

Even though the code is still ALPHA, we're looking for any feedback
on the approach we're taking, as well as any reports of successes
and failures on a variety of hardware.  Feel free to follow up on
this mailing list, or to join the freebsd-x11 mailing list on
freebsd.org.  We're also doing a bi-weekly community conference call
to discuss this and other topics in graphics on FreeBSD, and we
welcome others to join the discussion.  As we continue the progress
on getting the code fleshed out and matured, we expect that we'll
collaborate on this list and in the IRC channel.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[Jani Nikula]

On Fri, 13 May 2016, Scott Long <scottl@netflix.com> wrote:
> Jean-Sébastien and other developers have been discussing a new approach
> for post-3.8.13 updates. Instead of maintaining a large set of changes,
> the plan is to keep the driver as close as possible to the upstream Linux
> version, and use straightforward shims to adapt to interfaces provided by
> FreeBSD where possible.

FWIW, I think this is likely the only viable option.

The i915 driver is a fast moving target, and I have witnessed the
struggles of full time paid developers backporting and forward porting
drm and i915 features from Linux kernel version to another. It is not a
trivial task. Last I checked, the Linux driver backports project has
also given up backporting latest drm drivers to stable kernel versions.

I don't have any FreeBSD experience and I don't know what kind of team
of developers you have, but it is my educated guess that you'll have
plenty of more productive things to do than trying to maintain a
significant amount of delta with upstream while also trying to stay
up-to-date.

> Our ultimate goal is to align closely with the Linux graphics
> development community and collaborate with Intel, ATI, and others on
> keeping FreeBSD up to date in their product development efforts.

The focus and priority of the i915 driver is obviously Linux, but I
don't see us rejecting patches that help FreeBSD if the patches
generally make sense and don't interfere with the main priority.

Good luck with your efforts!


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[K. Macy]

> I don't have any FreeBSD experience and I don't know what kind of team
> of developers you have, but it is my educated guess that you'll have
> plenty of more productive things to do than trying to maintain a
> significant amount of delta with upstream while also trying to stay
> up-to-date.

I agree 100%. FreeBSD's DRM support has lagged further and further
behind every year. Linux 3.8 was releases 39 months ago, but support
for it just went in to FreeBSD in March of this year. By working on
the linuxkpi side of things I was able to get the 4.6-rc5 i915 up and
running with at least glxgears working in under three weeks. It's
really hard to argue for making the driver "native" any more.

>> Our ultimate goal is to align closely with the Linux graphics
>> development community and collaborate with Intel, ATI, and others on
>> keeping FreeBSD up to date in their product development efforts.
>
> The focus and priority of the i915 driver is obviously Linux, but I
> don't see us rejecting patches that help FreeBSD if the patches
> generally make sense and don't interfere with the main priority.

That would be much appreciated. I have the diff with upstream down to
~450 lines, so there likely isn't a whole lot that needs to change.
However, there may be small things that are easier to do in the driver
than in the linuxkpi.

Thanks in advance.

-M
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[Scott Long]

> On May 13, 2016, at 1:34 AM, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> 
> On Fri, 13 May 2016, Scott Long <scottl@netflix.com> wrote:
>> Jean-Sébastien and other developers have been discussing a new approach
>> for post-3.8.13 updates. Instead of maintaining a large set of changes,
>> the plan is to keep the driver as close as possible to the upstream Linux
>> version, and use straightforward shims to adapt to interfaces provided by
>> FreeBSD where possible.
> 
> FWIW, I think this is likely the only viable option.
> 
> The i915 driver is a fast moving target, and I have witnessed the
> struggles of full time paid developers backporting and forward porting
> drm and i915 features from Linux kernel version to another. It is not a
> trivial task. Last I checked, the Linux driver backports project has
> also given up backporting latest drm drivers to stable kernel versions.
> 
> I don't have any FreeBSD experience and I don't know what kind of team
> of developers you have, but it is my educated guess that you'll have
> plenty of more productive things to do than trying to maintain a
> significant amount of delta with upstream while also trying to stay
> up-to-date.
> 
>> Our ultimate goal is to align closely with the Linux graphics
>> development community and collaborate with Intel, ATI, and others on
>> keeping FreeBSD up to date in their product development efforts.
> 
> The focus and priority of the i915 driver is obviously Linux, but I
> don't see us rejecting patches that help FreeBSD if the patches
> generally make sense and don't interfere with the main priority.
> 
> Good luck with your efforts!

Hi Jani,

Thanks for the encouraging words.  The amazing work of Matt
and Jean-Sebastian is proving the wisdom of keeping the diffs
small and focusing on the kernel interfaces.  As they work on
completing the code and bringing it to maturity, we’ll be looking
for ways to unobtrusively organize any necessary deltas and post
patches here for review.  With FreeBSD being prepared for
release in only a few months, there’s a good chance that it could
be the first platform to support Gen9 hardware in a stock, non-
experimental configuration.  Stay tuned!

Thanks,
Scott

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[Jani Nikula]

On Thu, 12 May 2016, Scott Long <scottl@netflix.com> wrote:
> I'd like to offer a heads-up on the ongoing work in the FreeBSD project
> to update to a contemporary version of the i915 driver.

I inadvertently let this through the moderation while Scott had reposted
as subscriber. Please ignore this one and keep the conversation in the
other thread [1]. Sorry for the noise.

BR,
Jani.

[1] http://mid.gmane.org/946F24C0-6419-4C15-ACAB-0CD6E247D082@netflix.com


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[Ed Maste]

On 13 May 2016 at 03:34, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> I don't have any FreeBSD experience and I don't know what kind of team
> of developers you have, but it is my educated guess that you'll have
> plenty of more productive things to do than trying to maintain a
> significant amount of delta with upstream while also trying to stay
> up-to-date.

There are certainly lots of other things we can do with our time :-)

That said, I see another advantage of the new approach here. In the
past at any given time we had somewhere between nobody and one or two
brave souls working on the driver in FreeBSD. That work required an
understanding of the hardware, FreeBSD and Linux interfaces, and
context of the previous modifications to the driver.

Now we have a much larger team of folks contributing, and the work can
more easily be distributed.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[Jani Nikula]

On Fri, 13 May 2016, "K. Macy" <kmacy@freebsd.org> wrote:
> That would be much appreciated. I have the diff with upstream down to
> ~450 lines, so there likely isn't a whole lot that needs to change.
> However, there may be small things that are easier to do in the driver
> than in the linuxkpi.

Incidentally, there's some related discussion going on in dri-devel [1],
perhaps you'd like to chime in?

BR,
Jani.

[1] http://thread.gmane.org/gmane.comp.video.dri.devel/153947


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[K. Macy]

[-- Attachment #1.1: Type: text/plain, Size: 1155 bytes --]

On Tuesday, May 17, 2016, Jani Nikula <jani.nikula@linux.intel.com> wrote:

> On Fri, 13 May 2016, "K. Macy" <kmacy@freebsd.org <javascript:;>> wrote:
> > That would be much appreciated. I have the diff with upstream down to
> > ~450 lines, so there likely isn't a whole lot that needs to change.
> > However, there may be small things that are easier to do in the driver
> > than in the linuxkpi.
>
> Incidentally, there's some related discussion going on in dri-devel [1],
> perhaps you'd like to chime in?
>
> BR,
> Jani.
>
> [1] http://thread.gmane.org/gmane.comp.video.dri.devel/153947
>
>
>
 Thanks. Will do in the morning. I plan on keeping drm, i915, et al. as
ports  - graphics moves faster than FreeBSD releases. Thus, it should be
easier to do sane things with the headers without being tied to kernel
source layout.

I know it's old hat to you all, but I'm happy to report that the 4.6 i915
driver works on FreeBSD on skylake with at least basic 3D hw acceleration.
When one is coming from being 39 months behind to the latest driver, little
things like that are exciting.

Cheers.

-M

--
> Jani Nikula, Intel Open Source Technology Center
>

[-- Attachment #1.2: Type: text/html, Size: 1836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[Daniel Vetter]

On Fri, May 13, 2016 at 10:34:59AM +0300, Jani Nikula wrote:
> On Fri, 13 May 2016, Scott Long <scottl@netflix.com> wrote:
> > Jean-Sébastien and other developers have been discussing a new approach
> > for post-3.8.13 updates. Instead of maintaining a large set of changes,
> > the plan is to keep the driver as close as possible to the upstream Linux
> > version, and use straightforward shims to adapt to interfaces provided by
> > FreeBSD where possible.
> 
> FWIW, I think this is likely the only viable option.
> 
> The i915 driver is a fast moving target, and I have witnessed the
> struggles of full time paid developers backporting and forward porting
> drm and i915 features from Linux kernel version to another. It is not a
> trivial task. Last I checked, the Linux driver backports project has
> also given up backporting latest drm drivers to stable kernel versions.
> 
> I don't have any FreeBSD experience and I don't know what kind of team
> of developers you have, but it is my educated guess that you'll have
> plenty of more productive things to do than trying to maintain a
> significant amount of delta with upstream while also trying to stay
> up-to-date.
> 
> > Our ultimate goal is to align closely with the Linux graphics
> > development community and collaborate with Intel, ATI, and others on
> > keeping FreeBSD up to date in their product development efforts.
> 
> The focus and priority of the i915 driver is obviously Linux, but I
> don't see us rejecting patches that help FreeBSD if the patches
> generally make sense and don't interfere with the main priority.

What I don't really like is the old approach of trying to abstract away
differences between Linux and *BSD in drmP.h with some screaming macros.
Given the imbalance of manpower between Linux and *BSD I think the best
(and probably only really) approach is to have linux compat types and
wrapper functions for everything. Which seems to be the new plan.

If there's stuff needed above&beyond that I think we need to look at in on
a case-by-case basis and figure out what makes sense. For me the crucial
bit isn't so much whether we need to make changes in upstream linux or
not, but whether there's a benefit for usptream too. If bug reports and
bugfixes flow back to linux, then I'm all for it. If it's a one-way street
then frankly I don't care ;-)

> Good luck with your efforts!

Yeah, would be great to have *BSD tracking upstream closely again, wish
you the best with that!

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[K. Macy]

> What I don't really like is the old approach of trying to abstract away
> differences between Linux and *BSD in drmP.h with some screaming macros.
> Given the imbalance of manpower between Linux and *BSD I think the best
> (and probably only really) approach is to have linux compat types and
> wrapper functions for everything. Which seems to be the new plan.

Correct.

> If there's stuff needed above&beyond that I think we need to look at in on
> a case-by-case basis and figure out what makes sense. For me the crucial
> bit isn't so much whether we need to make changes in upstream linux or
> not, but whether there's a benefit for usptream too. If bug reports and
> bugfixes flow back to linux, then I'm all for it. If it's a one-way street
> then frankly I don't care ;-)

I apologize for a being a bit slow to parse your statements. What is
upstream and what is downstream? If upstream is Linux and downstream
Linux users then I actually do have some areas I'd like engage on like
figuring out if userptr as it stands couldn't provide a better failure
mode. However, I'd like to think that upstream is Intel and downstream
is Intel customers and that the predominant focus on Linux is an
artifact of cost / benefit. If the latter is the case then any changes
that don't interfere with your primary focus but still support your
broader customer base should be considered desirable.

Either way, now that we're in sync with upstream I do hope that we can
contribute to general driver discussions to the extent that our
limited resources permit.


>> Good luck with your efforts!
>
> Yeah, would be great to have *BSD tracking upstream closely again, wish
> you the best with that!


Thanks.

-M
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[randyf]

On Tue, 17 May 2016, Daniel Vetter wrote:

>>> Our ultimate goal is to align closely with the Linux graphics
>>> development community and collaborate with Intel, ATI, and others on
>>> keeping FreeBSD up to date in their product development efforts.
>>
>> The focus and priority of the i915 driver is obviously Linux, but I
>> don't see us rejecting patches that help FreeBSD if the patches
>> generally make sense and don't interfere with the main priority.
>
> What I don't really like is the old approach of trying to abstract away
> differences between Linux and *BSD in drmP.h with some screaming macros.
> Given the imbalance of manpower between Linux and *BSD I think the best
> (and probably only really) approach is to have linux compat types and
> wrapper functions for everything. Which seems to be the new plan.
>
> If there's stuff needed above&beyond that I think we need to look at in on
> a case-by-case basis and figure out what makes sense. For me the crucial
> bit isn't so much whether we need to make changes in upstream linux or
> not, but whether there's a benefit for usptream too. If bug reports and
> bugfixes flow back to linux, then I'm all for it. If it's a one-way street
> then frankly I don't care ;-)
>

   FWIW, this is the approach I have taken with Solaris.  It's probably 
only a 90-95% solution at this time, but that's a hellavalot less work 
than it previously was (though requiring one hellavalot of initial work 
:^P ).


   Cheers!

 	---- Randy
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[Daniel Vetter]

On Tue, May 17, 2016 at 08:09:27AM -0700, K. Macy wrote:
> > What I don't really like is the old approach of trying to abstract away
> > differences between Linux and *BSD in drmP.h with some screaming macros.
> > Given the imbalance of manpower between Linux and *BSD I think the best
> > (and probably only really) approach is to have linux compat types and
> > wrapper functions for everything. Which seems to be the new plan.
> 
> Correct.
> 
> > If there's stuff needed above&beyond that I think we need to look at in on
> > a case-by-case basis and figure out what makes sense. For me the crucial
> > bit isn't so much whether we need to make changes in upstream linux or
> > not, but whether there's a benefit for usptream too. If bug reports and
> > bugfixes flow back to linux, then I'm all for it. If it's a one-way street
> > then frankly I don't care ;-)
> 
> I apologize for a being a bit slow to parse your statements. What is
> upstream and what is downstream? If upstream is Linux and downstream
> Linux users then I actually do have some areas I'd like engage on like
> figuring out if userptr as it stands couldn't provide a better failure
> mode. However, I'd like to think that upstream is Intel and downstream
> is Intel customers and that the predominant focus on Linux is an
> artifact of cost / benefit. If the latter is the case then any changes
> that don't interfere with your primary focus but still support your
> broader customer base should be considered desirable.
> 
> Either way, now that we're in sync with upstream I do hope that we can
> contribute to general driver discussions to the extent that our
> limited resources permit.

I meant downstream/upstream wrt *BSD ports, i.e.

upstream = the i915 linux driver
downstream = your port in *BSD

If you think of the Intel/customer relation, everything we do here in the
community is pretty much just best effort, done by developers and
maintainers because it's the right thing to do. I think intel as a company
doesn't care one bit about *BSD from a business perspective at all.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FreeBSD i915 driver update

[K. Macy]

On Wed, May 18, 2016 at 1:11 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, May 17, 2016 at 08:09:27AM -0700, K. Macy wrote:
>> > What I don't really like is the old approach of trying to abstract away
>> > differences between Linux and *BSD in drmP.h with some screaming macros.
>> > Given the imbalance of manpower between Linux and *BSD I think the best
>> > (and probably only really) approach is to have linux compat types and
>> > wrapper functions for everything. Which seems to be the new plan.
>>
>> Correct.
>>
>> > If there's stuff needed above&beyond that I think we need to look at in on
>> > a case-by-case basis and figure out what makes sense. For me the crucial
>> > bit isn't so much whether we need to make changes in upstream linux or
>> > not, but whether there's a benefit for usptream too. If bug reports and
>> > bugfixes flow back to linux, then I'm all for it. If it's a one-way street
>> > then frankly I don't care ;-)
>>
>> I apologize for a being a bit slow to parse your statements. What is
>> upstream and what is downstream? If upstream is Linux and downstream
>> Linux users then I actually do have some areas I'd like engage on like
>> figuring out if userptr as it stands couldn't provide a better failure
>> mode. However, I'd like to think that upstream is Intel and downstream
>> is Intel customers and that the predominant focus on Linux is an
>> artifact of cost / benefit. If the latter is the case then any changes
>> that don't interfere with your primary focus but still support your
>> broader customer base should be considered desirable.
>>
>> Either way, now that we're in sync with upstream I do hope that we can
>> contribute to general driver discussions to the extent that our
>> limited resources permit.
>
> I meant downstream/upstream wrt *BSD ports, i.e.
>
> upstream = the i915 linux driver
> downstream = your port in *BSD
>
> If you think of the Intel/customer relation, everything we do here in the
> community is pretty much just best effort, done by developers and
> maintainers because it's the right thing to do. I think intel as a company
> doesn't care one bit about *BSD from a business perspective at all.

Your .sig says Intel Corporation but your e-mail is not @intel.com.
Are you doing this work purely in your free time?

No of course Intel doesn't care about graphics on BSD. Of course it's
self-perpetuating though. It's a bit akin to one high end ethernet
card manufacturer that the supply chain management at a client of mine
always claims is going out of business, when in fact it's more a
matter of the NIC vendor not playing the games that GSCM staffing does
to maximize their KPIs. The end result is though, said NIC vendor is
in fact more likely to go out business. As hardware support for an OS
diminishes past a certain point it becomes impossible to eat one's own
dogfood and the OS inevitably withers. FreeBSD's wounds are mostly
self-inflicted - I'm just pointing out that there is cause and effect.

And it's not entirely true that Intel as a whole has no interest in
BSD. A single company using FreeBSD accounts for ~40% of all of the
downstream internet traffic from fixed access sources in North
America. Intel tries to cultivate their business. Of course there are
a handful of instances where Intel product managers have thought they
could promise "out of the box support" without actually lining up the
resources to make that happen. (However, Intel even does that
internally one look no further than the sad history of Larrabee and
Intel applications research engineers being managed out to cover up
the project's failings)  It's a delicate balance finding the level of
support that makes sense financially while actually being honest about
expectations management. I hope I don't sound critical, in contrast to
times in the past they actually seem to be doing a good job right now.

In any event. I see it as the Linuxkpi's job to make driver code from
Linux "just work". So this whole who cares about what is largely
academic. I did this DRM update personally because I wanted ROCm as
Nvidia refuses to enable CUDA on FreeBSD. i915 matters to me in so far
as I see up to date support as critical to enabling developers to get
back to eating their own dogfood.

Cheers.

-M
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx