Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

From: Jeff Garzik (jgarzik_at_pobox.com)
Date: 10/22/04

  • Next message: Deepak Saxena: "Re: [PATCH BK][ARM] Various ARM updates for 2.6.9" 
    Date:	Fri, 22 Oct 2004 14:47:47 -0400
To: Timothy Miller <miller@techsource.com>

    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
    driver.

    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Deepak Saxena: "Re: [PATCH BK][ARM] Various ARM updates for 2.6.9"

    Relevant Pages

    • Re: Linux, X, ld, gcc, linking, shared libraries and stuff
      ... >> because, originally, video cards / system RAM could NOT afford to have ... > GL actually "copies" everything, but it's done by the graphics card, so ... > anyway if it's not hardware accelerated. ... installed the proper driver, then it zooms around the screen... ...
      (alt.lang.asm)
    • Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
      ... > 3) Your main bottlenecks are video RAM bandwidth to/from the GPU, ... it may be easier for the first rev of your chip to do all ... > I feel my own personal design for video hardware interface is better ... > should be presented to the OS driver. ...
      (Linux-Kernel)
    • Re: Can i8042prt.sys crashes be avoided?
      ... it sounds like malfunctioning hardware to me. ... most laptops have an Fn+key ... If the i8042 chip did not overheat then I have ... > Is there really no way for the driver to command the chip to reset itself? ...
      (microsoft.public.development.device.drivers)
    • Re: Windows XP Randomly Suddenly Shutdown, nothing to do with power
      ... When other hardware starts being accessed (ie when ATI video ... Curious is that boot halts when accessing ATI driver. ...
      (alt.os.windows-xp)
    • Re: analog video capture
      ... We have now confirmed that you do indeed have analog capable hardware, ... We might learn a bit more about your capture hardware, ... Immediately below the "Video input source:" dialog, ... if your video capture device uses Windows Driver Models drivers. ...
      (microsoft.public.windowsxp.moviemaker)