lkml.org 
[lkml]   [2006]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OpenGL-based framebuffer concepts
Date
On Tuesday 23 May 2006 16:53, Alan Cox wrote:
> On Maw, 2006-05-23 at 11:41 -0400, Kyle Moffett wrote:
> > So a modern GPU is essentially a proprietary CPU with an obscure
> > instruction set and lots of specialized texel hardware? Given the
> > total lack of documentation from either ATI or NVidia about such
> > cards I'd guess it's impossible for Linux to provide any kind of
> > reasonable 3d engine for that kind of environment, and it might be
> > better to target a design like the Open Graphics Project is working
> > to provide.
>
> Its typically a device you feed a series of fairly low level rendering
> commands to sometimes including instructions (eg shaders). DRI provides
> an interface that is chip dependant but typically looks like
>
>
> [User provided command buffer]
>
> [Kernel filtering/DMA interface]
>
> [Card command queue processing]
>
>
> All the higher level graphic work is done in the 3D client itself.

Exactly! Alans above explanation is exactly why I proposed merging DRM with
the framebuffer drivers. However, a day later and some new information
received, it would be better to change the framebuffer system to use DRM as a
backend where it's possible.

DRH
-
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: 2006-05-24 05:33    [W:0.175 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site