Re: GLX in bad state

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.

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

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

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

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.

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.

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.

> 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 it could be, and that something related to rendering to textures is
related to the problem.

Take care,
  -Gav

-- 
Gavriel State
Co-CEO & CTO
TransGaming Technologies Inc.
[email protected]
http://www.transgaming.com

Let the games begin!