Re: GLX in bad state

Any Transgamers willing to post their results please do so.  The patch I 
posted here is simply a stub and so does not affect any game negatively.  
Hopefully, Transgaming will include this patch in the next release of 
WineX so that less able users will be able to participate.

This discussion is yielding results.  I should emphasize that I do not own the
C4 game and I am unlikely to purchase it in future.  I believe it is relevant
in quantifying performance and should give an idea as to the level of
performance to be expected in games with similar visual effects.

See comments.

On Sat, 3 Apr 2004, Gavriel State wrote:

> Nadav Frum wrote:
> > As far as your dismissal of this topic is concerned, you are wrong.I 
> > have managed to produce just under 5 fps just by introducing a more efficient
> > video memory allocation scheme.It is not perfect but it does prove my point.
> 
> My dismissal is not of the topic in general, but of the conclusion that
> ARB_render_texture is the solution.
> 
> In fact, your own video memory allocation scheme performance improvement disproves
> your earlier conclusion that ARB_render_texture is needed.If performance can
> be improved without ARB_render_texture, then the lack of such an extension
> cannot be the cause of the problem.

My video allocation scheme adds complexity to the code.  Code complexity uses
CPU cycles.  In DirectX one simply issues a SetRenderTarget command.  With
ARB_render_texture we can get close to this type of scheme.

The fact that the effect of transferring large amounts of video data does 
not slow down the current WineX implementation is not good news.  It means 
that WineX is slow enough for the video card to go to sleep.

> > It is possible that there are other factors besides the absence of
> > ARB_render_texture that are slowing the game down.
> 
> Yes, I agree.We can do a number of things to speed this up without requiring
> a new GL extension.

The original Wine was probably programmed in the spirit of get-it-to-work 
rather than get-it-to-work-fast.  This should not be the case with WineX. 
If an extension makes things faster and better it is an important step in
making things generally faster.  I do not understand why you believe
translating WGL extensions into GLX is unnessesary.  

Do not forget that extensions of this type are considered very important 
by many parties in the industry.  ARB currently has the Super Buffers 
working group to sort out future issues relating to buffers.

> >>That's only if it renders to every texture, which is very unlikely.Most games
> >>that do this kind of thing render to 2-3 textures, no more.
> >
> >
> > Let us see.There are several shadow casting objects:  choppers, numerous 
> > jeeps, plenty of vegetation and buildings, etc.For reflections there is 
> > the ship, the chopper and the general scenery.It is more than 2-3.  
> > There are also the textures used to bypass the 2 active texture limit on my
> > card. All in all, around 70.
> >
> > When you start drawing shadows, every visible object will require one.
> > Most games have more than 2-3 visible objects.Some shadows can be 
> > aggregated.
> 
> Ok, rather than surmising based on an assumption of how they do their shadows,
> I ran the demo with -debugmsg +x11drv,-ddraw,+timestamp, and came up with these
> results:
> 
> In a typical frame from the opening intro, there are a total of22 UpdateTexture
> operations, on 8 different textures.The sizes of these textures are as follows:
> 
> 128 x 128
> 256 x 256
> 128 x 128
> 512 x 256
> 128 x 128
> 128 x 128
> 128 x 128
> 256 x 256
> 
> At 32 bpp, this amounts to about 1.2 Megs of RAM.Thus, neither the data transfer,
> nor the memory requirements should be onerous.

32 bpp for color + 32 bpp for depth/stencil.
What are your system specs and your fps?  Which frame?  There is no 
opening intro.  You run the benchmark and you see a 10 minute cut-scene.

> >>The problem is somewhere else.
> >
> > Where?
> 
> Well, I noticed a couple of interesting things.One is that we are frequently
> deleting and then recreating pbuffers while we render.I'm not quite sure why
> this is exactly, but it is definitely affecting performance significantly.While
> in some cases, creating the pbuffer was quick (1 ms), frequently it took as
> long as 50 ms.I even saw one time when it took over 200 ms.

> In the above frame, we were deleting and reallocating 7 pbuffers.In total,
> allocating the pbuffers alone amounted to 339 ms, close to half the frame
> time.
> 
> So, what we need to figure out is:
> 
> (a) Why are we destroying pbuffers for textures that we've rendered to
>    in the past and then recreating them?
> 

#define CACHESIZE 64 - in glx_private.h, i.e. 70+ renderable textures.

> and
> 
> (b) Why does it sometimes take a really long time to allocate a pbuffer?
> 
> It was interesting to note that the long time required to allocate the pbuffer
> seemed to always be associated with the larger pbuffers (256x256 and up), and
> that the 128x128 pbuffer allocations were small.

The bigger the block the longer it takes to find a big enough gap.

> One possible answer to (b) is memory fragmentation in the video card RAM,
> combined with bad allocation algorithms in the driver.There's not much
> we can do about that, other than to try to use memory in such a way as not
> to aggravate the problem.

The driver simply does not defragment itself.  I believe that the OpenGL 
implementation and the DirectDraw implementation have a lot of common 
code.  The driver is not the first thing I would blame.

> As for (a), Ove will have to answer that one.We do have a bunch of code
> around to reuse render targets - perhaps it needs to reuse the pbuffers as
> well.Or perhaps this app is just hitting us in a way that we don't expect - it
> does seem to also require a bunch of copy_aux calls, which may be due to the
> way the app is locking the textures.That may be the cause of further
> performance losses.

You guessed right.  I do reuse the pbuffers.

> > The discussion I am attempting to start is simply to identify problems.
> > When the problems have been identified perhaps somebody will agree to
> > address them.
> 
> That's a great goal, and you've clearly identified that this app is slower
> than itcould be, and that something related to rendering to textures is
> related to the problem.

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