[Intel-gfx] FreeBSD i915 driver update

[K. Macy]

On Wed, May 18, 2016 at 1:11 AM, Daniel Vetter <daniel at 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