[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
I've thought about this a bit already, and had some chip designers 
correct my thoughts on a few things. Here are my comments, in no
particular order:

1) I agree it probably wouldn't be cost effective without selling to
OEMs in volume

2) AGP/PCI-Express is practically required, if you want OEM sales, IMO

3) Your main bottlenecks are video RAM bandwidth to/from the GPU,
PCI/AGP bus bandwidth, and system RAM bandwidth.

4) I am a bit dubious that FPGA will perform at a useful clock speed.

5) Key question: generic GPU or not?

From what I've read in ARS Technica and other tech sites, ATI and
NVIDIA chips are moving towards a more generic, programmable CPU model.
Presumably on current (or future?) chips, you will push bytecoded
shaders direct to your video card. Essentially some future GPUs will be
highly specialized, yet generic, CPUs with their own ISA.

On the other hand, if you only support a small number of graphics
operations, it may be easier for the first rev of your chip to do all
the 2D operations in silicon.

6) My preference: generic OpenGL programming interface.

I feel my own personal design for video hardware interface is better
than ATI or NVIDIA: present to the OS driver a generic, open, public
OpenGL interface, that very rarely (if ever) changes. This must be a
simple interface: only a few key operations, such as "transfer {display
list | shader | texture | ...} data to card" or "execute display list"
should be presented to the OS driver.

The interface should have a standard "fall back to software rendering"
response message, for minimalist hardware.

If your hardware presents a standard GL interface to OS driver,

a) there is a high potential industry standardization, if it's done right

b) reduce complexity in the OS driver.

c) stop the "driver rat race". After the OS driver is initially
written, the only maintenance costs are keeping up to date with the
latest OpenGL standards. You have very low cross-hardware support
costs, because all the hardware presents the same interface to the OS

d) makes it possible to add value to your hardware without changing the
OS driver

e) makes it possible for multiple video chip vendors to compete, without
worrying about OS driver issues, or Linux support issues.

f) this isn't a terribly new idea :) But it's a good one, IMHO.

g) even on minimalist 2D-only hardware, you can implement this interface

7) two-chip solution

One thing I have pondered, with regards to #6: what about implementing
a multi-core solution? One core to handle the graphics operations and
control the video, and one core a much more generic microcontroller that
runs ucLinux, and handles the GL "slow path" stuff. The advantage of
this approach is

a) 100% of 2D and 3D GL is "done in hardware". The portions of GL that
are not handled by the GPU core are handled by the microcontroller core,
which is running a generic firmware.

b) Since a microcontroller is included, you can upgrade the firmware
quite easily to support new OpenGL features.

c) you don't necessarily have to follow my design of one purpose built
GPU core, and one generic microcontroller core. If your FPGA is big
enough, you can have plenty of execution engines (that's the beauty of
hardware, it's inherently parallel).

But OTOH, maybe a multi-core solution will add too much latency into the
picture, I dunno.

8) I don't find an open source video BIOS terribly exciting. Yes, I do
think it should be open source, but the interest is largely theoretical.
A video BIOS only does a couple things... implements VESA/etc. BIOS
calls, and initializes the hardware based on characteristics specific to
the video board (i.e. OEM not GPU details, such as video RAM setup and
clocking, which video inputs are actually implemented on the board,
...). I don't see there being a big programmer or developer interest

Such a video BIOS would probably have to be BSD-licensed, since the
video BIOS code may wind up being #included into an OEM's system BIOS.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.166 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site