Re: [OT] Crazy idea: Design open-source graphics chip

[John Bradford]

Quote from Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>:
> On Thu, 29 Jan 2004, Timothy Miller wrote:
> > Ok, so, how about this idea:
> >
> > - Small Xilinx FPGA, 16M of RAM, and a DAC on a board.
> > - AGP 2X
> > - Up to 2048x2048 resolution at 8, 16, and 32 bpp.
> > - Acceleration ONLY for solid fills and bitblts on-screen.
> 
> Sounds OK to me.
> 
> > Given that so little is accelerated, there is no point in putting more
> > than the viewable framebuffer on the card, hense the 16 megs.  It would
> > probably actually HURT performance to cache pixmaps on the card.
> >
> >
> > Oh, there's one thing I forgot.  It would have to support VGA.  There is
> > a VGA core on opencores.org that we could use, but its logic area would
> > probably push up the FPGA cost so that the board was in the $100 range.
> >   Probably more.
> 
> Why support legacy VGA? It makes things more complex and expensive, and doesn't
> give us much, especially for a SoC.

It makes the card usable in a standard machine before the kernel has
booted.  I don't care about that at all from a technical viewpoint, as
there are better ways to deal with it, (re-write the system BIOS to
use the framebuffer for the BIOS configuration, for example), but I
can see that there may be a marketing reason for including VGA - more
people are likely to buy the card.  Whether this is significant
depends on the market we try to sell it in, and whether cost per unit
would be increased by the extra complexity, or decreased by the higher
volume of production possible if more units are going to be sold.

A cheap cludge would be an optional second GPU on the card just to do
the required VGA modes, with an analogue video pass-through.  That
would make the VGA cards more expensive than a single GPU which
incorporated VGA, but add almost nothing in cost or complexity terms
to the non-VGA cards.

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/