Date: Tue, 13 Dec 2011 12:54:48 +0000 From: Matt Dawson <matt@chronos.org.uk> To: freebsd-amd64@freebsd.org Subject: Re: Video Card for FreeBSD 9.0 (RC2) AMD64 Message-ID: <201112131254.49175.matt@chronos.org.uk> In-Reply-To: <20111212192256.218280@gmx.com> References: <20111212192256.218280@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112131254.49175.matt>