From: Timothy Miller <miller@techsource.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
Date: Wed, 20 Oct 2004 18:02:51 -0400 [thread overview]
Message-ID: <4176E08B.2050706@techsource.com> (raw)
I've brought this up the following subject before on LKML, but it wasn't
really resolved, and also, management at my company (Tech Source) has
only now started to warm up to my idea.
To begin with, I'm an ASIC/FPGA designer, as well as software developer.
My own projects here include X11 drivers (DDX modules) for OpenWindows
and XFree86, as well as the bulk of a graphics ASIC which we use in our
air traffic control systems. The point: we have a lot of experience
with graphics hardware and system software.
In short, what I have been proposing to my superiors is the development
of a graphics card specifically for open source systems. This means
full disclosure on all register interfaces so that no one has to deal
with anything closed source (BIOS included). The goal here is to
produce a graphics card which is a Free Software geek's dream in terms
of openness. If Tech Source (me being its avatar) can develop a
relationship with the Linux (and BSD) community, users and developers
can get a product that they want without being locked out by hardware
vendors that feel they have to protect every last little bit of IP
relating to their products. The EXPRESS PURPOSE of this product is to
be free-software-friendly.
I can produce more detail later, but first, some characteristics and
advantages of what I'm proposing:
- x86 BIOS/OpenBoot/OpenFirmware code under BSD and GPL license
- kernel drivers under BSD and GPL license
- X11 module under MIT license
- flashable PROM so that boot code can be added for more platforms
- usable as the console on any platform that can take a PCI, AGP, or
PCI-Express card
- downloadable schematic for the circuit board
- FPGA-based graphics engine so it's reprogrammable
- instructions on how to reprogram the FPGA, so it's hackable
- if we discontinue a product, we may release the Verilog code for the FPGA
- Since this is designed to be open-source-friendly, we want to play by
the rules of the open-source community.
- Tech Source would actively participate in the development and
maintenance of our own drivers.
- We will actually pay attention to problems and concerns raised by
users and developers.
- We won't be control-freaks.
The desired effects, for developers, of these characteristics would include:
- The card "just works" with Linux because, maybe, the drivers would go
into main-line
- The drivers are not a debugging/tainting nightmare, since they are
open source
- The drivers are easy to work on, since you don't ever have to guess
about anything.
- The drivers are easy to debug because
(a) we document everything, and
(b) we'll talk to you.
- People will think it's cool and want to hack it.
The desired effect for end users:
- It just works.
- It's not a liability for system stability.
The reason this idea came up is because I, as a user of Linux, am often
frustrated by the lack of open-source support for graphics cards which
are not "pre-owned". Sure, SOME companies release specs so that we can
develop open source drivers, but those cards tend to be prohibitively
expensive, slower than their cheaper counterparts from ATI or nVidia,
and they STILL don't document the internals of the BIOS so that the card
can be ported to a non-x86 system. Furthermore, since all these vendors
focus exclusively on Windows, they don't give much help to open source
developers who may produce drivers which work but which are sub-optimal
in performance or stability. (Here, I have to make the obligatory CYA
statement that there is nothing wrong with their business models -- it's
just unfortunate for Linux users.)
By contrast, what _I_ want to produce would be supportable by both Tech
Source (mostly me), and also by anyone else who wants to hack it. I
would be one of the primary designers of the chip, so I would know it
inside and out. I would also be the primary driver developer, with the
help of others on LKML. So, I would be here to help, but hopefully, the
documentation would be clear enough (and the drivers I write, complete
enough) so that no one gets stuck having to guess or reverse-engineer
anything.
There are, however, some caveats. Tech Source is not willing to foot a
lot of development capital for this project. That means we can't spend
an excessive amount of time on developing a fully virtex shading
programmable 3D engine, and my superiors are not willing, as yet, to
give me sufficient funding to produce an ASIC. What this means is that
the design has to be small and simple and focus primarily on 2D
performance so that it can fit into an FPGA.
A 2D rendering engine is easy to parallelize, so although we can't clock
the FPGA design as fast as an ASIC design, we can easily saturate a
128-bit DDR memory bus at, say, 200Mhz. A 3D rendering engine, on the
other hand, is a beast, and our performance will be less than stellar
(although certainly better than doing it all with the host CPU). (If
there IS sufficient demand, we would LOVE to produce a
performance-competitive 3D chip, but keep in mind that that would be a
huge and expensive development effort, and would result in an expensive
product.)
The advantage of having this in an FPGA is that we can add features and
fix bugs as necessary, and provide a flash utility for everyone to use
to upgrade. You run the utility, cycle power, and you're set. This
way, if some kernel developer who is concerned about latency decides
that having an interrupt signal occur on some event that we don't
already cover, we can add the feature and supply a new bitfile in
relatively short order. You wouldn't have to buy a new card to upgrade.
All of this, however, is a pipe-dream if it's not cost effective for
Tech Source. I have to make a very strong case to the CEO. I think
everyone at this company is excited about the IDEA of developing this
product. But we have no clue what the market is like. It's not worth
it to us to develop this if only a handful of kernel hackers are going
to buy it. We're guessing that some workstation and server vendors who
deal in Linux would like to resell this sort of product, because if our
drivers are in the mainline Linux kernel, it'll "just work". On the
other hand, maybe they're all perfectly happy with the graphics
controllers that come built into many Intel motherboards and have "good
enough" support.
The very fact that no other company has openly considered going to the
level of openness that I'm proposing might suggest that what I'm
proposing is completely out of touch with reality, because it just can't
be profitable.
So, here are some questions to answer:
(1) Would the sales volumes of this product be enough to make it worth
producing (ie. profitable)?
(2) How much would you be willing to pay for it?
(3) How do you feel about the choice of neglecting 3D performance as a
priority? How important is 3D performance? In what cases is it not?
(4) How much extra would you be willing to pay for excellent 3D performance?
(5) What's most important to you, performance, price, or stability?
Feel free to insert your own questions and answers here. Remember, I'm
an engineer. My understanding of business is dilettantish at best.
I haven't worked out a complete design spec for this product. The
reason is that what we think people want and what people REALLY want may
not be congruent. If you have a good idea for a piece of graphics
hardware which you think would be beneficial to the free software
community (and worth it for a company to produce), then Tech Source, as
a graphics company, might be willing to sell it.
Oh, and before you flame me, YES, I AM doing market research for Tech
Source here, but NO, I am not doing it at THEIR request. They told me
that if I wanted to do this, I would have to make a case for it, and
that's what I'm trying to do. This is MY idea, and I would personally
love to have a product like what I'm describing. I would also
personally very much enjoy WORKING on such a project, because then I
wouldn't have to do more boring stuff. There's a lot of selfishness
here on my part. But it's selfishess that I hope everyone else will
benefit from.
next reply other threads:[~2004-10-20 21:56 UTC|newest]
Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 22:02 Timothy Miller [this message]
2004-10-20 22:17 ` HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? Andre Eisenbach
2004-10-21 1:31 ` Jon Valvatne
2004-10-21 16:09 ` Timothy Miller
2004-10-24 19:47 ` Pavel Machek
2004-10-20 22:19 ` HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? [u] Martin Schlemmer [c]
2004-10-24 8:24 ` Tonnerre
2004-10-24 14:26 ` Martin Schlemmer [c]
2004-10-20 22:26 ` HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? David Lang
2004-10-21 14:46 ` Timothy Miller
2004-10-21 17:25 ` David Lang
2004-10-21 18:15 ` Timothy Miller
2004-10-21 18:32 ` Antonio Vargas
2004-10-22 9:53 ` Raphael Jacquot
2004-10-24 9:03 ` Tonnerre
2004-10-25 1:33 ` Stephen Wille Padnos
2004-10-25 1:48 ` Stephen Wille Padnos
2004-10-25 2:29 ` Gene Heskett
2004-10-22 10:16 ` Christian Leber
2004-10-22 17:31 ` Timothy Miller
2004-10-21 19:30 ` Kendall Bennett
2004-10-22 17:05 ` Tobias Diedrich
2004-10-22 17:12 ` Timothy Miller
2004-10-26 2:36 ` Dave Airlie
2004-10-26 3:55 ` Jon Smirl
2004-10-20 22:28 ` Jim Nelson
2004-10-21 14:51 ` Timothy Miller
2004-10-21 22:03 ` Jim Nelson
2004-10-20 22:29 ` Kasper Sandberg
2004-10-21 14:53 ` Timothy Miller
2004-10-21 15:06 ` Simon Braunschmidt
2004-10-21 18:00 ` Timothy Miller
2004-10-20 23:10 ` Alan Cox
2004-10-21 15:10 ` Timothy Miller
2004-10-21 15:25 ` Jon Smirl
2004-10-21 18:03 ` Timothy Miller
2004-10-21 15:32 ` Alan Cox
2004-10-21 19:30 ` Kendall Bennett
2004-10-22 17:15 ` Timothy Miller
2004-10-21 1:08 ` Jon Smirl
2004-10-21 1:11 ` Jon Smirl
2004-10-21 2:00 ` Stephen Wille Padnos
2004-10-21 16:08 ` Timothy Miller
2004-10-21 16:34 ` Stephen Wille Padnos
2004-10-21 23:38 ` Jan Knutar
2004-10-22 4:30 ` Jan Rychter
2004-10-22 17:00 ` Timothy Miller
2004-10-22 17:00 ` Chris Friesen
2004-10-22 18:47 ` Jeff Garzik
2004-10-22 19:22 ` Timothy Miller
2004-10-22 19:33 ` Jeff Garzik
2004-10-22 19:56 ` Timothy Miller
2004-10-22 20:43 ` Jeff Garzik
2004-10-22 20:27 ` Alan Cox
2004-10-23 17:20 ` Francois Romieu
2004-10-23 21:17 ` Alan Cox
2004-10-24 0:06 ` Francois Romieu
2004-10-22 20:51 ` Jeff Garzik
2004-10-22 19:32 ` Roland Dreier
2004-10-24 10:40 ` Helge Hafting
2004-10-25 15:39 ` Timothy Miller
2004-10-21 21:57 ` J.A. Magallon
2004-10-22 9:48 ` Raphael Jacquot
2004-10-21 20:23 ` "Fernando O. Korndörfer"
2004-10-22 9:02 ` Raphael Jacquot
2004-10-21 15:13 ` Timothy Miller
2004-10-21 15:36 ` Shaun Kruger
2004-10-21 18:05 ` Timothy Miller
2004-10-21 19:30 ` Kendall Bennett
2004-10-22 8:49 ` Adrian Cox
2004-10-22 20:10 ` Geert Uytterhoeven
2004-10-23 13:17 ` Adrian Cox
2004-10-22 20:10 ` Geert Uytterhoeven
2004-10-22 22:07 ` Timothy Miller
2004-10-24 10:45 ` Helge Hafting
2004-10-25 15:47 ` Timothy Miller
2004-10-28 9:07 ` Helge Hafting
2004-10-29 16:00 ` Timothy Miller
2004-10-21 1:48 ` HARDWARE:Graphics Cards or TOE? Nuno Silva
2004-10-26 20:50 ` Timothy Miller
2004-10-21 2:29 ` HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? Kurt Wall
2004-10-21 16:10 ` Timothy Miller
2004-10-21 16:22 ` Pascal Patry
2004-10-21 12:20 ` Adrian Bunk
2004-10-21 13:14 ` Simon Braunschmidt
2004-10-21 17:34 ` Jurriaan
2004-10-21 16:26 ` Timothy Miller
2004-10-21 17:42 ` Alan Cox
2004-10-21 19:09 ` Timothy Miller
2004-10-21 17:53 ` Tobias Diedrich
2004-10-21 23:02 ` Florian Schmidt
2004-10-24 1:04 ` Lee Revell
2004-10-22 1:08 ` Rene Herman
2004-10-23 5:40 ` Kevin Puetz
2004-10-23 17:02 ` Rene Herman
2004-10-23 22:19 ` Lee Revell
2004-10-24 11:10 ` Rene Herman
2004-10-22 10:57 ` Helge Hafting
2004-10-22 19:47 ` Giuseppe Bilotta
2004-10-22 20:15 ` Giuseppe Bilotta
2004-10-25 15:29 ` Tonnerre
2004-10-25 15:53 ` Timothy Miller
2004-10-25 16:32 ` Giuliano Pochini
2004-10-28 9:37 ` Helge Hafting
2004-10-28 11:40 ` Geert Uytterhoeven
2004-10-28 12:21 ` David Greaves
2004-10-29 16:04 ` Timothy Miller
2004-10-22 22:27 ` Clemens Schwaighofer
2004-10-23 14:36 ` Markus Törnqvist
2004-10-24 8:18 ` Tonnerre
2004-10-25 11:54 ` Stuart Longland
2004-10-25 16:38 ` Lars Roland
2004-10-25 17:08 ` Timothy Miller
2004-10-26 21:02 ` Helge Hafting
2004-10-26 21:38 ` Timothy Miller
2004-10-25 22:52 ` Tonnerre
-- strict thread matches above, loose matches on Subject: below --
2004-10-20 23:48 Timothy Miller
2004-10-21 0:30 ` J.A. Magallon
2004-10-21 0:47 ` Timothy Miller
2004-10-22 20:09 ` Geert Uytterhoeven
2004-10-21 1:25 ` Zan Lynx
2004-10-21 15:52 ` Timothy Miller
2004-10-21 4:48 Albert Cahalan
2004-10-21 16:19 ` Timothy Miller
2004-10-21 15:54 John Ripley
2004-10-21 18:09 ` Timothy Miller
2004-10-21 21:32 ` Baruch Even
2004-10-25 23:30 ` Werner Almesberger
2004-10-21 17:08 Greg Buchholz
2004-10-22 2:18 ` Tim Connors
2004-10-21 17:44 John Ripley
2004-10-21 18:26 ` Timothy Miller
2004-10-21 21:36 ` Greg Buchholz
2004-10-21 22:40 ` Timothy Miller
2004-10-21 23:25 ` Jon Smirl
2004-10-21 23:40 ` Greg Buchholz
2004-10-22 16:48 ` Timothy Miller
2004-10-22 16:50 ` Chris Friesen
2004-10-22 17:41 ` Timothy Miller
2004-10-25 23:10 ` Tonnerre
2004-10-26 0:32 ` Werner Almesberger
2004-10-22 15:59 ` Troy Benjegerdes
2004-10-22 3:47 Roy Butler
2004-10-22 17:04 ` Timothy Miller
2004-10-24 18:17 ` Mail Lists
2004-10-25 12:17 ` Bernd Eckenfels
2004-10-22 10:31 John Ripley
2004-10-22 12:58 ` Moritz Muehlenhoff
2004-10-22 17:33 ` Timothy Miller
2004-10-22 17:15 Stephen Lewis
2004-10-23 4:45 ` Gene Heskett
2004-10-23 7:06 ` Stephen Lewis
2004-10-23 19:06 Bodo Eggert
2004-10-25 1:44 ` Stephen Wille Padnos
2004-10-25 8:23 ` Vojtech Pavlik
[not found] <6.1.2.0.1.20041026082223.0231edd8@mail.javagear.com>
2004-10-26 15:44 ` Timothy Miller
2004-10-26 16:35 ` Jesper Juhl
2004-10-26 16:57 ` Jeff Garzik
2004-10-26 21:14 ` Helge Hafting
2004-10-26 21:41 ` Timothy Miller
2004-11-17 14:35 Sid Boyce
2004-11-17 14:46 ` Chris Wedgwood
2004-11-23 13:47 ` Karel Kulhavy
2004-11-23 22:48 ` Timothy Miller
2004-11-24 1:22 ` Sid Boyce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4176E08B.2050706@techsource.com \
--to=miller@techsource.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).