Re: GLX in bad state

I replied to Gavriel's letter before reading Ove's, so there is a repeat 
of some of the answers.

I am aware of the very bad video memory allocation scheme in WineX and the 
negative impact it has on performance.  I have also devised a much better 
video memory allocation scheme.  I have informed you of this on 3 Sep 
2003.  I have also supplied you subsequently with sufficient information so
that you would not need to guess what the problem is.  You have this 
information available.

The problems do not end there, unfortunately.  Even with these problems fixed
WineX is producing under 5 fps.  It should be over 20 fps and perhaps even 30
fps.  Let us not become fixated with this easily solvable problem.  I am
looking beyond that.

My video card has 64 MB of memory and 2 active textures.  I would like to 
see results for different systems.  I believe this will provide a lot of 
insight.

It is imperative that my patch be included in the CVS to allow the C4 
demo to run.  This patch would off-coarse not be necessary once pixel shaders
are introduced.  In the meantime it will prevent an annoying crash on 
Operation Flashpoint.

On Sun, 4 Apr 2004, Ove Kaaven wrote:

> Oh, almost forgot to mention: Each pbuffer comes with its own Zbuffer,
> so the actual VRAM spent here is the double (2.4 MB). That is, over 1 MB
> is wasted here, and there's not much to be done about that with the
> current API. For the record, ARB_render_texture would not help with this
> waste; with it, we'd still have a separate zbuffer per pbuffer/texture
> combo, so something else is needed to fix the VRAM waste completely.

  Issue 11 of the ARB_render_texture spec is as follows:

  11. When the color buffer is released from the texture (back to the 
      pbuffer) should the contents be preserved?
 
      No, this may prove difficult to implement on some architectures.

The color buffer remains intact upon release.  So why is the answer no?
There could be two reasons:
a.  The contents of the color buffer were copied to the texture memory, 
    and thus negating the usefulness of this extension.
b.  The depth/stencil buffer was used for something else in the interim, 
    i.e the depth/stencil buffer is shared.

I vote for b.  Hardware vendors eager to maximize performance will have 
noticed that they can share the depth/stencil buffer.  In addition, the 
actual pbuffer may be shared by several textures with ARB_render_texture.
The conclusion is that renderable textures have a hold on video memory 
only when they are bound to a pbuffer.  I believe you have misinterpreted 
the spec.

Nadav Frum
----------