Re: Why run xserver on the OpenGL API?

"Kendall Bennett" <[email protected]>
Newsgroups gmane.comp.freedesktop.xserver
Organization SciTech Software, Inc.
Message-ID <3FC3A69B.27119.164815AA@localhost>
Keith Packard <[email protected]> wrote:

> Around 18 o'clock on Nov 25, "Kendall Bennett" wrote:
> 
> > Since I am sure we are not talking about building an X server based on
> > OpenGL that requires an existing OpenGL enabled X server to run, perhaps
> > you can clear this up?
> 
> Yeah, I'm not completely clear in my own mind how all of this is
> going to work, but certainly the bottom of the system is an
> X-independent OpenGL library sitting atop the raw hardware. 

Right. I am glad we are on the same page then. The good news (as I 
outlined in my previous post) is that we already have a completely X 
independent OpenGL library sitting atop the raw hardware right now on 
Linux. Software only, but it should be enough to kick start this project 
if you are interested.

> I would like to know how direct rendered 3D apps will get drawn
> into X windows; I'd like to think that the solution involves
> drawing to an off screen buffer and then telling the X server to
> swap buffers so that the Composite extension could get involved
> somehow. 

Yes, exactly! 

In fact that is exactly how I have designed it with SNAP. The SNAP 3D 
architecture is broke into two pieces. The first piece is a low level 
driver that handles all the probing, mode enumeration, mode sets, 
palette/gamma ramps etc, plus it contains a complete offscreen surface 
manager for allocating and managing draw buffers, depth buffers, 
textures, video surfaces etc etc. Layered on top of that is the 3D module 
(Mesa naturally ;-) that uses the buffer manager to manage all it's 
surfaces. Code that wants to draw to video memory allocates buffers with 
the buffer manager API and can either directly call the 2D SNAP functions 
or create an OpenGL rendering context for that buffer and draw to it. To 
display it on the screen, you can either BitBlt it to a visible buffer or 
if the buffer is part of a flip chain simply make the buffer visible for 
hardware page flipping. Here is the basic SNAP buffer version of glX: 

void      ChooseVisual(GA_buf *buf,GA_glVisual *visual);
ibool     CheckVisual(GA_buf *buf,GA_glVisual *visual);
GA_HGLRC  CreateContext(GA_buf *buf,GA_glVisual *visual,GA_HGLRC 
shareList);
void      DeleteContext(GA_HGLRC ctx);
ibool     MakeCurrent(GA_HGLRC ctx);
GA_HGLRC  GetCurrentContext(void);
void      SwapBuffers(GA_HGLRC ctx,N_int32 waitVRT);
void      SetPaletteData(GA_HGLRC ctx,GA_palette *pal,N_int32 num,N_int32 
index);
void      GetHalfTonePalette(GA_palette *pal,N_int32 num);
void *    GetProcAddress(const char *procName);

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.