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

From: Timothy Miller (miller_at_techsource.com)
Date: 10/21/04

  • Next message: Andrew Morton: "Re: Am I paranoid or is everyone out to break my kernel builds (Breakage in drivers/pcmcia)" 
    Date:	Thu, 21 Oct 2004 12:08:53 -0400
To: Stephen Wille Padnos <spadnos@sover.net>

    Stephen Wille Padnos wrote:
    > Jon Smirl wrote:
    >
    >> Another thought, TV out is important in the embedded market. Think
    >> about Tivo/MythTV/set top boxes.
    >>
    > OK - so the answer seems to be "if it does the right things, then it may
    > sell" It's hard to sell a card that doesn't do good 3D these days (re:
    > Matrox Parhelia). Speaking of the parhelia, I would look at that
    > feature set as a starting point. 10-bit color, multiscreen accelerated
    > 3D, dual DVI, gamma corrected glyph antialiasing, etc.

    I was thinking of pointing at the Permedia 2 or 3 as an example of the
    basic 3D feature set.

    >
    > So, let's try to figure out the right feature set. (that is what was
    > originally asked for, after all)
    >
    > Looking at 2D, I would definitely want to see: (some taken from other
    > emails on the subject)

    > alpha blending

    Easy enough.

    > antialiasing (related to alpha blending)

    Antialiasing implies oversampling or supersampling, unless you're
    thinking about something else. Sometimes, "antialiasing" is nothing
    more than a fuzzy texture. For instance, the way the X11 font server
    handles antialiased text... it just spits out a grayscale bitmap which
    can be used as texture.

    > bitblt
    > fast primitive drawing

    No problem.

    > accelerated offscreen operations

    It's funny that people mention that. Every DDX module I have ever
    produced has had sophistocated off-screen memory management so that
    pixmaps could be accelerated. I never even considered NOT supporting
    accelerated off-screen surfaces.

    There was one chip I had to support a number of years ago which didn't
    have separate registers for the base pointers to source and destination
    surfaces. That meant that you couldn't use "bitblt" to copy an image
    from off-screen to on-screen. What I ended up having to do was
    implement bitblt as a texture-mapping operation. (It wound up being
    slightly faster than the regular bitblt, even if the source and dest
    were the same surface.)

    Anyhow, in my world, accelerated off-screen surfaces are a given.

    > more than 8 bits/color channel

    For rendering or for display? A DVI transmitter won't do more than 8
    bits per channel, but it can be helpful to have more than 8 bits per
    channel for greater mathematical precision when compositing images.

    > video output - preferably with independent scale / refresh (ie, clone
    > the 100Hz 1600x1200 monitor on a 648x480 60 Hz NTSC monitor)
    > video decoding acceleration (possibly some encoding functions as well)

    While I have considered that for other products, I'm not sure I want to
    do through that trouble for a "low-end" card, unless you're happy with
    integer scaling, which isn't so bad.

    Most LCD monitors I encounter will scale, but I don't know what's the
    best thing to do about your example. I can see why you'd want to be
    able to squeeze your game display onto a TV, but I also wasn't thinking
    about supporting TV. Consider how much that would increase the parts cost.

    > bitmap scaling (think of font sizing and the like)
    > 2D rotation
    > possibly 2.5D rotation - ie, the perspective "twist" of a plane image
    > into 3D space (like Sun's Looking Glass environment)

    Those are all subsets of texture-mapping.

    >
    > I would think that a chip that has a lot of simple functions, but
    > requires the OS to put them together to actually do something, would be
    > great. This would be the UNIX mentality brought to hardware: lots of
    > small components that get strung together in ways their creator(s) never
    > imagined. If there can be a programmable side as well (other than
    > re-burning the FPGA), that would be great.

    You're right, and you're not. There are two reasons why modern 3D GPUs
    put the world mesh into the card framebuffer and do all the T&L in the
    GPU. One reason is that it's faster to do it in dedicated hardware.
    The other more pressing reason is that the host interface (PCI or AGP)
    puts a very low upper-bound on your triangle rendering rate.

    The number of parameters necessary to specify a single texture-mapped
    triangle are literally in the dozens. If you did only 32-bit fixed
    point (16.16) for coordinates, that's still a huge amount of information
    to move across the bus to instruct the chip to render a single triangle.
      And what if that triangle ends up amounting to a single pixel? Think
    about the waste!

    Instead, the un-transformed geometry is loaded into the card memory only
    once, and the GPU is instructed to render the scene based on the camera
    perspective and lighting information. Aside from the need to cache
    textures on-card, this is another reason for the need to have LOTS of
    graphics memory.

    >
    > I guess I would look at this as an opportunity to make a "visual
    > coprocessor", that also has the hardware necessary to output to a
    > monitor (preferably multiple monitors).

    I don't think that's realistic. We could do that, but it would have
    terrible performance.

    -
    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: Andrew Morton: "Re: Am I paranoid or is everyone out to break my kernel builds (Breakage in drivers/pcmcia)"

    Relevant Pages

    • Re: Triangle warping algorithm ?
      ... then to pass the array of pixels to the java rendering ... This will show you what is needed for triangle rendering. ... Giving vertices other values like texture coordinates is just ... For each pixel in the ...
      (comp.graphics.algorithms)
    • Re: Can Microsoft people answer my last post, please?
      ... Problem rendering a list of triangle ... and a mesh. ... chapter of a book to disable texture colores and alpha. ... State the basis of your problem, i.e. when rendering a triangle list ...
      (microsoft.public.win32.programmer.directx.graphics)
    • Re: A 3D mesh and texture.
      ... No one does one texture per polygon. ... rendering use some sort of directVolume Renderingtechnique. ... quality iso-surfaces by means of direct volume rendering and I'm aware ... interpolation has to be applied. ...
      (comp.graphics.api.opengl)
    • Re: Creating Circular Surface in DirectX
      ... rendering your surface by using a textured quad with alpha blending and a ... directly samples your rendered texture. ... draw it onto the screen via a 3D solid quad. ... be able to do the circular cut out yourself... ...
      (microsoft.public.win32.programmer.directx.graphics)
    • Re: Topmodel2 (BACK ON TOPIC)
      ... > most of the triangles are textured with green grass - OK. ... apply various attributes such as colour and texture. ... the triangle remains textured as ... > I then create a triangle with Edit and Join Selection. ...
      (comp.sys.acorn.misc)
    Loading