On Wed, May 18, 2016 at 1:11 AM, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
