Re: OpenGL-based framebuffer concepts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Maw, 2006-05-23 at 10:10 -0400, Kyle Moffett wrote:
> A GPU which does not support OpenGL at all would look virtually  

No GPU today "supports" OpenGL

> 2)  Client program sends OpenGL commands through kernel framebuffer  
> device.
> 3)  Kernel either passes the OpenGL commands to the GPU or if they  
> were trapped by the software renderer it passes them to that, which  
> can emulate them using more primitive operations.

You've no idea how a GPU works have you ?

The process generally goes something like this.

I build an OpenGL rendering context.
The supporting library JITs an engine which implements this rendering
context and pipeline. Only a JIT is really fast enough because there are
so many tests are otherwise involved.

Each poly is fired down the JIT engine which produces a mix of
	- AGP command streams
	- GPU bytecodes
	- Polygon breakdowns which go back into the engine
		(eg for clips the chip can't do)
	- Texture loads and swaps

The GPU view of the universe is far far from the OpenGL one. With the
possible exception of the big 3D Labs cards anyway.

Alan

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux