Xgl server

[David Reveman]

On Fri, 2004-11-05 at 11:11 -0700, Brian Paul wrote:
> David Reveman wrote:
> > I've been doing some work to get an X server running on top of
> > OpenGL/glitz and I've got something that works pretty well now. I stuck
> > the code into the "xserver" tree and './configure --enable-xglserver'
> > should compile the common xgl code along with an Xglx server that can
> > run on top of an existing X server with GLX.
> > 
> > With a good OpenGL driver and some luck, you should be able to run most
> > applications on it. However, you should know that the Xglx server is
> > really simple, there's no real cursor and compared to the Xnest server,
> > Xglx must always run on top of all other windows as the back buffer is
> > used for pixmap memory.
> > 
> > There's a screenshot from running a complete gnome desktop on top of
> > Xglx here:
> > http://www.cs.umu.se/~c99drn/pics/xgl-shot.png
> > I was actually running Xglx on top of software mesa when I took that
> > screenshot. That's of course quite slow, but not completely unusable. :)
> > 
> > A lot of operations are accelerated, some operations can be accelerated
> > better, some operations are not accelerated but can be accelerated and
> > some operations can never be accelerated.
> > 
> > Here's a list of things that I think most importantly need some work:
> > 
> > * Get the fb layer to operate on pixel data with scan-line order
> > bottom-to-top. This will make software fall-backs A LOT faster. As
> > keithp told me, all we really need to do is to use negative strides and
> > I'll give that a try within in a few days, hopefully that will work just
> > fine.
> 
> Why do you need bottom-to-top raster order?  I assume it has something 
> to do with OpenGL's conventions.

I'm glad you asked. Normally when using OpenGL you would just load all
texture data as it's stored by application and if this happens to be in
top-to-bottom raster order you would just take care of that when
assigning texture coordinates or when setting the texture matrix.

With glitz, in general, and especially with Xgl, a lot of copying from
framebuffer/pbuffers to textures is done. If textures contain pixel data
stored in top-to-bottom order this cannot (as far as I know) be done
efficiently and it's a lot more important that this framebuffer/pbuffer
to texture copy is efficient than the user memory to texture copy.

This is why glitz stores texture data in bottom-to-top raster order. If
someone knows a better way around this problem please let me know.

> 
> 
> > * Replace or improve the current xgl offscreen memory manager, it wastes
> > huge amounts of memory right now.
> > * Improve xrender text performance.
> > * Accelerate bitmap text. Performance of applications2 that use bitmap
> > text is terrible right now. :(
> > 
> > The following things could also needs some work. They are probably not
> > as important but they would be interesting and fun to get working:
> > 
> > * Hook up glitz's convolution filters. This should be really easy, all
> > we need is a software fall-back.
> > * GLX and accelerated indirect rendering.
> > * Add Xagl and Xwgl servers.
> > * Add a miniglx or mesa-solo server.
> > 
> > Have fun playing with it. If you find any bugs (and you will), please
> > let me know.
> 
> Nice job!

thanks :)
 
-David