lkml.org 
[lkml]   [2004]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
Timothy Miller wrote:

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

I'm thinking more like microcode. The functional blocks on the chip
would be capable of being "rewired" by the OS, depending on the
applications being run. All of the functions would still operate out of
card-local memory.

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

Yep - reminds me of the days with the old SGI Iris, which did OpenGL
processing directly on the card, with the display list local to the
GPU(s) (1280x1024@100 bit depth -24 bit color, 24-bit Z, another 48 bits
for double-buffering, and 2 bits of overlay + 2 more underlay - those
were the days :)

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

Sorry - I wasn't thinking in terms of an 8087 - more like a dedicated
processor for image related functions - like a DSP card. A display list
based coprocessor would certainly be better than anything that has to
repeatedly transfer commands over a slow bus.

- Steve

-
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/

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