From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 13 12:54:54 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41EE11065677 for ; Tue, 13 Dec 2011 12:54:54 +0000 (UTC) (envelope-from matt@chronos.org.uk) Received: from chronos.org.uk (chronos-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:12b::2]) by mx1.freebsd.org (Postfix) with ESMTP id ACCEB8FC08 for ; Tue, 13 Dec 2011 12:54:53 +0000 (UTC) Received: from workstation1.localnet (workstation1.local.chronos.org.uk [IPv6:2001:470:1f09:12b::20]) (authenticated bits=0) by chronos.org.uk (8.14.5/8.14.5) with ESMTP id pBDCsnHK012109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Dec 2011 12:54:49 GMT (envelope-from matt@chronos.org.uk) X-DKIM: OpenDKIM Filter v2.4.1 chronos.org.uk pBDCsnHK012109 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=chronos.org.uk; s=mail; t=1323780889; bh=vLTznzmzvmRLUaq2woPjbEZuRuZGpzgKAW0aa6Ecb5k=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=ETcl4oPpW4Q79mQ+rZhailIUNlBvlSJ9r0+g0cgUK2o34eXY4ygMLC3n0Rki4b0C2 c0XyLHPCJkzPs8mycNA1EKFB7ICOEK2PsAZkXtE25Y+uQlORy2uD6naFCy8pNpIinN HHIzXjmz3NFAatd03HBrjauAon73Zm8jpMy9pyCQ= From: Matt Dawson To: freebsd-amd64@freebsd.org Date: Tue, 13 Dec 2011 12:54:48 +0000 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.7.3; amd64; ; ) References: <20111212192256.218280@gmx.com> In-Reply-To: <20111212192256.218280@gmx.com> X-Face: -a*{KS?gYyH>pt=1?H+(>B2Z'>b6WxX:^O@+VaMV>l\tOh@[x`#&AHSdl`m<-EEhk=1%t9iRthI|; ~8)mN@qxJ}x5l:zhDO( =?utf-8?q?=2Eas=0A?= NeO!\oL7huHfsoF'I5,0G+Yo[G-G"FG,l`QJ$IgwH/[\a]vRH^'=`; cY+*_{Or` MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112131254.49175.matt@chronos.org.uk> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (chronos.org.uk [IPv6:2001:470:1f09:12b::1]); Tue, 13 Dec 2011 12:54:49 +0000 (GMT) X-Virus-Scanned: clamav-milter 0.97.3 at central.local.chronos.org.uk X-Virus-Status: Clean X-Spam-Status: No, score=-100.4 required=3.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RP_MATCHES_RCVD, SPF_PASS,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on central.local.chronos.org.uk Subject: Re: Video Card for FreeBSD 9.0 (RC2) AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 12:54:54 -0000 On Monday 12 Dec 2011 19:22:55 Dieter BSD wrote: > Full support requires full documentation or full > reverse-engineering. nVidia is openly hostile towards FLOSS, I > don't expect any documentation from them in the forseeable future. > AMD/ATI is working on documenting their chips, but seems to be > concentrating on features for games, and never getting around to > UVD (video decode) or GPGPU, etc. The only fully documented card > I know of is the Open Graphics Project's OGP-D1, which is a PCI-X > FPGA development card. It has linux drivers, but I suspect it > doesn't have support in BSD. Just a quick comment on this: One of the reasons I choose FreeBSD over $OTHER_OS is that a lot of us are remarkably free of political encumbrance when we're trying to get things working, ergo the nVidia binary blob and the support from nVidia on the forums is generally accepted as a best-effort endeavour. When you're sitting in the living room setting up and HTPC with SWMBO looking on and making clicking noises and muttering things like "the XBox can already do this stuff" because of your dislike of decisions being imposed by large corporations, the ability to cd /usr/ports/x11/nvidia-driver && make config && make && make install to get something that Just Works [TM] rather than trying to get around other people's political views can be the difference between violent rejection and passive acceptance. There are reasons why nVidia cannot release specifications, particularly on their PureVideo technology, which happen to be the same reasons AMD can't release theirs: They don't fully own those technologies. As it stands, I'm resigned to trading off full freedom of code for functionality. The important part, the interface between the kernel and the blob, is fully open in that you can see what passes between the two and ensure there's nothing freedom and privacy threatening going on. Idealism is all well and good, but general acceptance in the real world requires a certain amount of compromise. There's another example right in our kernel: The Highpoint RocketRAID (hptrr(4)) driver has a closed binary component. It's right there in the man page for all to see. -- Matt Dawson MTD15-RIPE matt@chronos.org.uk