public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Miller <miller@techsource.com>
To: Helge Hafting <helgehaf@aitel.hist.no>
Cc: John Bradford <john@grabjohn.com>,
	chakkerz@optusnet.com.au,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [OT] Crazy idea:  Design open-source graphics chip
Date: Fri, 30 Jan 2004 12:02:06 -0500	[thread overview]
Message-ID: <401A8E0E.6090004@techsource.com> (raw)
In-Reply-To: <401A33CA.4050104@aitel.hist.no>


NOTE:  My guilt meter for being so far off topic is starting to peg. 
Let's either find a better open forum to discuss this or just take it 
off list.

The only reason I haven't taken it completely off list so far is because 
SOME aspects of this discussion may be relevant to Free Software in 
general.  It is the Linux mentality that spurred this idea and Linux 
users who would be the target market.  But now we're just arguing 
trivialities.

So, the obligatory on-topic comment is simple:  Any Linux-targeted 
graphics chip has to be quite sophistocated and cost-competitive to some 
extent in order for the idea to have any merit whatsoever.  Core Linux 
users on this list are the most qualified to dictate what they would use 
it for.

Unfortunately, the comments I have gotten so far lead me to solutions 
that already exist.



Helge Hafting wrote:

>>
> I run X on an unaccelerated framebuffer (1280x1024 16bit color) every day.

This is you.  How many other people would be happy with this?


> 
> So a good 2D card is trivial - a video signal generator and memory on an 
> AGP bus.

I wouldn't call it 'good', but you're essentially correct.  Mind you, 
you can get the latest S3 chip for $30 or less.  That's well documented, 
a lot faster than a dumb framebuffer, and has VGA built in.

Once you get below a certain level of performance in this open-source 
design, it's no longer worth doing because there are so many low-end 
alternatives that blow it away.

> Let the host processor do software rendering.  Cheap, and I believe this is
> the sort of thing embedded uses might go for when they want to display 
> mostly
> static stuff. (Web-based info kiosk and similiar).

Not cheap.  You can get cheaper with what's already out there!

Let me put it this way:  To make it cheaper than what's out there, 
someone would have to do a run of _millions_ of some minimalist chip 
that sold for like $1.  You could have a graphics card for $5.  THAT 
would make it worth it.  But we would never get the volumes necessary 
for that!

> Add a BIOS rom and you can even see what happens during boot on a pc.

A BIOS ROM doesn't help you if you don't have a VGA core, and a VGA core 
is not a trivial piece of logic.

I like Macs, Suns, and other UNIX workstations because they don't rely 
on this antiquated piece of logic to act as a console.  The chip I 
designed doesn't do VGA, but that doesn't stop it from working nicely as 
a console in a Sun.

> 
> The next step up is 2D acceleration, which is easy enough by sticking a
> generic microprocessor there. Maybe an inexpensive celeron/duron.

<sigh>  Think about the logic area required for that.  For BASIC 2D 
acceleration, the amount of logic required for elementary operations is 
miniscule compared to the logic required for even the simplest of CPU 
cores.  And the dedicated logic would be faster!

> 
> Then there's 3D, and enough of it to play quake.  The first quakes ran
> fine with software rendering and processors that were slow by today's
> standards.  Todays cheap processors are faster - I wonder if putting 2-4 
> of them on the card might be enough. They'd be able to access the memory 
> directly,
> not limited to slow AGP/PCI speeds.  And they'd be able to divide the work
> between them, rendering separate parts of the screen.

My knowledge of 3D graphics is limited to linear algebra and mostly pure 
theory, but I do have SOME clue as to what existing 3D engines are like. 
    The issue of general purpose CPU's versus GPU's has been discussed 
on the web at nauseum, and for what they do, modern GPU's are an order 
of magnitude faster than CPU's at what they do.  And they're less expensive!


> 
> Why bother with 8-bit?

There are reasons.  We can go into them off-list.


> 
> 
> Why VGA?  When you have a _driver_ , you don't need compatibility at all.

BOOT CONSOLE.  You cannot get a boot console on a PC without a VGA core. 
  Once the kernel takes over, you're right, but until then...


> 
> 
> Another reason to drop VGA then - money.


As soon as PC BIOS's don't require it, we can drop it.


  reply	other threads:[~2004-01-30 16:58 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-28 17:34 [OT] Crazy idea: Design open-source graphics chip Timothy Miller
2004-01-29  1:11 ` Christian Unger
2004-01-29 15:59   ` Stephen Smoogen
2004-01-29 16:07     ` Maciej Soltysiak
2004-01-29 16:21     ` John Bradford
2004-01-29 16:13   ` Timothy Miller
2004-01-29 16:29     ` John Bradford
2004-01-29 16:52       ` Timothy Miller
2004-01-29 17:18         ` John Bradford
2004-01-29 17:47           ` Timothy Miller
2004-01-29 18:55             ` John Bradford
2004-01-29 19:11               ` Timothy Miller
2004-01-29 21:36                 ` John Bradford
2004-01-29 21:36                   ` Timothy Miller
2004-01-30 10:36                 ` Helge Hafting
2004-01-30 17:02                   ` Timothy Miller [this message]
2004-01-30 17:20                     ` Maciej W. Rozycki
2004-01-30 17:40                       ` Timothy Miller
2004-01-30 18:11                         ` Maciej W. Rozycki
2004-01-30 18:21                           ` Timothy Miller
2004-01-30 19:09                             ` Maciej W. Rozycki
2004-01-30 21:09                         ` Helge Hafting
2004-01-30 21:23                           ` Timothy Miller
2004-01-31 17:32                             ` John Bradford
2004-01-31 18:39                             ` Roland Dreier
2004-01-30 17:23                     ` Måns Rullgård
2004-01-30 17:44                       ` Timothy Miller
2004-01-30 19:01                     ` John Bradford
2004-01-30 21:19                     ` Helge Hafting
2004-02-01 10:36                 ` Geert Uytterhoeven
2004-02-01 11:06                   ` John Bradford
2004-02-01 11:46                     ` Måns Rullgård
2004-02-01 22:41                   ` Christian Unger
2004-02-02 17:13                   ` Timothy Miller
2004-02-02 17:11                     ` Geert Uytterhoeven
2004-01-30 16:54               ` Jesse Pollard
2004-02-01 10:35         ` Geert Uytterhoeven
2004-02-02 17:03           ` Timothy Miller
2004-01-29 16:30     ` Richard B. Johnson
2004-01-29 16:58       ` Timothy Miller
2004-01-29 18:08         ` Frank Gevaerts
2004-01-30 22:35           ` Esben Stien
2004-01-29 18:06     ` Torrey Hoffman
2004-01-29 18:58       ` Timothy Miller
2004-01-31 18:41     ` Pavel Machek
2004-01-31 18:15 ` Tomas Zvala
  -- strict thread matches above, loose matches on Subject: below --
2004-02-01 14:58 DaMouse Networks
2004-02-02 17:16 ` Timothy Miller
2004-02-02 17:37   ` DaMouse Networks
2004-02-02 18:45     ` Timothy Miller
2004-02-02 19:43       ` DaMouse Networks

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=401A8E0E.6090004@techsource.com \
    --to=miller@techsource.com \
    --cc=chakkerz@optusnet.com.au \
    --cc=helgehaf@aitel.hist.no \
    --cc=john@grabjohn.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