[lkml]   [2006]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: OpenGL-based framebuffer concepts
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.


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: 2006-05-23 16:34    [W:0.211 / U:4.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site