Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267625AbUJVU7R (ORCPT ); Fri, 22 Oct 2004 16:59:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267566AbUJVUrc (ORCPT ); Fri, 22 Oct 2004 16:47:32 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:18885 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S267549AbUJVUoB (ORCPT ); Fri, 22 Oct 2004 16:44:01 -0400 Message-ID: <41797103.2070005@pobox.com> Date: Fri, 22 Oct 2004 16:43:47 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Miller CC: Alan Cox , Jon Smirl , Linux Kernel Mailing List Subject: Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? References: <4176E08B.2050706@techsource.com> <4177DF15.8010007@techsource.com> <4177E50F.9030702@sover.net> <200410220238.13071.jk-lkml@sci.fi> <41793C94.3050909@techsource.com> <417955D3.5020206@pobox.com> <41795DEA.8050309@techsource.com> <41796083.9060301@pobox.com> <417965E7.8010408@techsource.com> In-Reply-To: <417965E7.8010408@techsource.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3918 Lines: 105 Timothy Miller wrote: > > > Jeff Garzik wrote: > >> Timothy Miller wrote: >> > >> >>> At this moment, I'm taking a cue from the Linux driver ABI and >>> thinking that standardizing the interface would be more limiting than >>> helpful. >> >> >> >> No offense, but I strongly disagree :) >> >> Standardizing the hardware interface lowers the cost of doing an OS >> driver for every chip maker that implements the interface. The more >> chip makers that implement the interface, the greater the cost savings. >> >> Concrete examples: >> * IDE BMDMA interface on PCI. Practically every ATA chipset in >> production supports this interface. As a consequence, each individual >> ATA driver mainly involves setting chip-specific timings, and not much >> else. >> >> * tulip (ethernet MAC). Its ring and register designs were widely >> imitated across ethernet NICs; as a result, each ethernet driver is >> mainly a "paint by numbers" affair. >> >> * the new AHCI SATA interface, which Intel has on all its new >> motherboards, and SiS soon will as well (as will others, I hope). > > > Sure, but those standards had time to evolve to where they are. I don't > have that luxury in many respects. > >> >> >>> While it might be a pain to have to carry around multiple driver >>> versions, the fact that it's all open source kinda makes it easy to >>> make drastic changes without hurting anything. >> >> >> >> Ever-changing hardware and firmware interfaces are a huge pain. I've >> been writing and maintaining drivers for years... I feel this pain >> every day :) >> >> You want to design a hardware interface that allows you to upgrade and >> enhance your hardware over time, while keeping the changes to the >> hardware<->OS interface itself to a _bare minimum_. That's why I >> suggested the microcontroller+GPU approach. The microcontroller's >> firmware can be used to mask the transition between GPU revisions. >> >> Drivers live for many years, even decades, and long after the hardware >> they support has been EOL'd. It's in everybody's best interests to >> keep the changes to the drivers to a minimum. > > > Ok, let me say this: I will not change something I don't have to > change, but I'm not going to be held back (and hold everyone else back) > by some mistake I made in the past. > >> >>> Plus, I don't expect to get it perfect the first time. The first design >> >> >> >> Part of open source is open development. If you develop the hardware >> interface in public, actively soliciting feedback during development, >> you'll wind up with a much better interface. > > > Fair enough, although the problem of a competitor getting the jump on us > that way is yet to be addressed. If you start competing based on interface, then that gets us right back to where we are now: vendors so protective of their interface that they don't want to open source their drivers... and each chip requires its own separate OS driver, with its own separate engineering team and brainshare. A big bonus of my point #6 is that this is irrelevant -- if everyone is using the same, simple "do GL" interface, then you are competing on features/cost/time-to-market/etc., not interface. I thought Alan Cox's point was fairly relevant here: there are at least five(?) video chips out there with hardware docs available, but no engineers to write a complex 3D driver from scratch. If your company _leads the industry_ in creating a standardized interface, doesn't everybody benefit? Another advantage is that a simple "do GL" interface is much more "future-proof" interface, since it is a very high level interface. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/