Xgl server

[Brian Paul]

David Reveman wrote:
> 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.

Eventually, a render-to-texture extension, like 
GL_EXT_framebuffer-object would alleviate that, right?


> 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.

Right.


> 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.

Sounds like you've got a handle on it.

-Brian