pipmak-users

[Pipmak-Users] Weird speed problem on laptop

[Urs H. <ur...@an...>]

Hi

I tried to run Pipmak on my Laptop (IBM Thinkpad X41) which has no
graphic acellerator. The CPU has a frequency of 1.5GHz.

After starting Pipmak, the framerate is very slow (about 10 seconds per
frame). But if I resize the window, I have to wait a few seconds and
then the framerate becomes high and one even could play the game. But
after about 20 seconds, the fun is over and the framerate falls back
and the game becomes unplayable.

This has nothing to do with the size of the window! I can even switch
into fullscreen after resizing the window and play the game with a
resolution of 1024x768!

Does anyone of you know what could cause this weird behaviour?

Greeting
Urs

[Pipmak-Users] Re: Weird speed problem on laptop

[Urs H. <ur...@an...>]

I have to provide more information:

I wrote:
> I tried to run Pipmak on my Laptop (IBM Thinkpad X41) which has no
> graphic acellerator. The CPU has a frequency of 1.5GHz.

I'm running Debian GNU/Linux. I use the xorg xserver. Because I don't
have a graphics acellerator, software rendernig is done through mesa.

[Pipmak-Users] Re: Weird speed problem on laptop

[Christian W. <cwa...@gm...>]

Urs Holzer wrote:
> After starting Pipmak, the framerate is very slow (about 10 seconds per
> frame). But if I resize the window, I have to wait a few seconds and
> then the framerate becomes high and one even could play the game. But
> after about 20 seconds, the fun is over and the framerate falls back
> and the game becomes unplayable.

No idea. Sounds like some OpenGL resource is being exhausted after a 
while, but what could it be? Does it also happen when you stay at one 
node without doing anything (i.e. no new textures or display lists are 
being uploaded to OpenGL)?

Can you run Pipmak through some performance analysis tool to see where 
the time is spent? I don't know if something like Shark 
(http://developer.apple.com/tools/sharkoptimize.html) exists for Linux. 
It records a callstack of the running application at a regular interval 
and can then analyze that data in various ways, including a 
callstack-vs-time graph.

Two other things you can try to improve rendering performance, tell me 
if these have any influence on the behavior you're seeing:
- Turn off interpolation (I key).
- Switch between power-of-two and rectangle textures, if your renderer 
supports both. By default, rectangle textures are used if supported 
(power-of-two textures are always available). Call the Lua function 
pipmak_internal.texrect() without arguments to query whether rectangle 
textures are on, and call it with true or false to try to turn them on 
or off. If not supported, turning them on will silently fail.

  -Christian

[Pipmak-Users] Re: Weird speed problem on laptop

[Urs H. <ur...@an...>]

Hi

Thanks for the help up to now.

I write my conclusions before the rest of this post:
I have the strange feeling that it has something to do with power
management, sleepstate of the processor and similar. But manipulating
the powermanagemant of my laptop I tried does not change anything. It
could also have to do with the kernel or the X-window system changing
the priority of pipmak. (The software renderer is built in into the x
window system. This causes the CPU usage for the Xorg-Task to be around
99.5%)

Christian Walther wrote:
> Urs Holzer wrote:
>> After starting Pipmak, the framerate is very slow (about 10 seconds
>> per frame). But if I resize the window, I have to wait a few seconds
>> and then the framerate becomes high and one even could play the game.
>> But after about 20 seconds, the fun is over and the framerate falls
>> back and the game becomes unplayable.
> 
> No idea. Sounds like some OpenGL resource is being exhausted after a
> while, but what could it be? Does it also happen when you stay at one
> node without doing anything (i.e. no new textures or display lists are
> being uploaded to OpenGL)?

After starting pipmak, something weird happens: The content of the
pipmak window starts with the startup node. It fades smoothly to a
completely black screen. Often, this stops before the whole window is
entirely black and the node is displayed normally again. 

So after this, the framerate is low. (From now on I will refer to the
very slow rendering "state" with "low framerate", and to the normal or
expected speed with "high framerate".) 

If the framerate is low, the following things do *not* change the
framerate to high:
- Hitting I: The framerate speeds up a little if I switch off
interpolation, as one expects. But the framerate does not change to
high.
- Going to another node: This does absolutely nothing to the framerate.
- 

The following actions change from low to high:
- Resizing the window.
- Using the console: Hitting N to show the Node number or hitting L to
enter a lua-command. Every time the console shows up, the framerate
changes to high.

And when does it change back from high to slow?
- A constant time after the change to high.
- Often it happens when the console disappears. (Whether the constant
time then is over, I don't know)

This was a full description of my observations so far.


> Can you run Pipmak through some performance analysis tool to see where
> the time is spent? I don't know if something like Shark
> (http://developer.apple.com/tools/sharkoptimize.html) exists for
> Linux. It records a callstack of the running application at a regular
> interval and can then analyze that data in various ways, including a
> callstack-vs-time graph.

Unfortunately, I don't know about such things. Though I heard of such
utilities. Recently, I read about a tool that logs all calls of to the
OpenGL library. I will perhaps follow this later.

> Two other things you can try to improve rendering performance, tell me
> if these have any influence on the behavior you're seeing:
> - Turn off interpolation (I key).

no

> - Switch between power-of-two and rectangle textures, if your renderer
> supports both. By default, rectangle textures are used if supported
> (power-of-two textures are always available). Call the Lua function
> pipmak_internal.texrect() without arguments to query whether rectangle
> textures are on, and call it with true or false to try to turn them on
> or off. If not supported, turning them on will silently fail.

Calling this function without arguments seems to do nothing. But calling
it with true or false works. At the beginning, texrect is on. It can be
switched of. Either way, it does not affect the framerate.


cu

[Pipmak-Users] Re: Weird speed problem on laptop

[Urs H. <ur...@an...>]

Hi

I wrote:
> I write my conclusions before the rest of this post:
> I have the strange feeling that it has something to do with power
> management, sleepstate of the processor and similar. But manipulating
> the powermanagemant of my laptop I tried does not change anything. It
> could also have to do with the kernel or the X-window system changing
> the priority of pipmak. (The software renderer is built in into the x
> window system. This causes the CPU usage for the Xorg-Task to be
> around 99.5%)

The kernel gives pipmak priorities 15 or 16. It seems that pipmak has
priority 15 while high framerate. But this value does not immediately
switch after changing the framerate. It takes some seconds!

I changed the nice value of pipmak. The nice value affects the priority.
I set the nice value to -8 which caused the kernel to give pipmak a
priority of about 7. This was the "best" priority of all running
applications! So, this framerate problem does not have to do with
application priorities given by the kernel.

cu

[Pipmak-Users] Re: Weird speed problem on laptop

[Christian W. <cwa...@gm...>]

Urs Holzer wrote:
> The following actions change from low to high:
> - Resizing the window.
> - Using the console: Hitting N to show the Node number or hitting L to
> enter a lua-command. Every time the console shows up, the framerate
> changes to high.

I guess the former is a special case of the latter, then, as resizing 
the window writes the new window size to the terminal. (You could test 
whether the effect of resizing the window goes away when you comment out 
the terminalPrintf() near "case SDL_VIDEORESIZE:" in main() in main.c.)

So, does that mean that you can keep it running at the high frame rate 
indefinitely (at least until you leave the current node) by doing 
something like

  pipmak.schedule(0, function() pipmak.print("*") return 8 end)

? (Not that this helps us around the problem, just as an experiment.)

>> pipmak_internal.texrect()
> Calling this function without arguments seems to do nothing.

Yes, that's the point. Calling it without arguments returns the current 
state without changing it. Calling it with an argument changes the state 
(and returns the previous state).

(I'm actually considering using such combined getter/setter functions 
also in the "official" (non-internal) Lua API in a (distant) future 
version. Do you find them confusing? Or did I just not explain it properly?)

  -Christian

[Pipmak-Users] Re: Weird speed problem on laptop

[Urs H. <ur...@an...>]

Hi Christian

Christian Walther wrote:
> Urs Holzer wrote:
>> The following actions change from low to high:
>> - Resizing the window.
>> - Using the console: Hitting N to show the Node number or hitting L
>> to enter a lua-command. Every time the console shows up, the
>> framerate changes to high.
> 
> I guess the former is a special case of the latter, then, as resizing
> the window writes the new window size to the terminal. (You could test
> whether the effect of resizing the window goes away when you comment
> out the terminalPrintf() near "case SDL_VIDEORESIZE:" in main() in
> main.c.)

I'm now sure that the framerate raises only when the terminal appears
and that it drops only when the terminal disappears. I will experiment
with the sourcecode later if I have enough time.
Do you do something special while displaying the terminal?

> So, does that mean that you can keep it running at the high frame rate
> indefinitely (at least until you leave the current node) by doing
> something like
> 
>   pipmak.schedule(0, function() pipmak.print("*") return 8 end)
> 
> ? (Not that this helps us around the problem, just as an experiment.)

This works!

>>> pipmak_internal.texrect()
>> Calling this function without arguments seems to do nothing.
> 
> Yes, that's the point. Calling it without arguments returns the
> current state without changing it. Calling it with an argument changes
> the state (and returns the previous state).
> 
> (I'm actually considering using such combined getter/setter functions
> also in the "official" (non-internal) Lua API in a (distant) future
> version. Do you find them confusing? Or did I just not explain it
> properly?)

Sorry, I'm an idiot. You explained it clearly enough. If it is called
without arguments, it will *return* the current state. And return
doesn't mean *print*. I thought, the return value will be printed. I
don't know why I thought this. (Perhaps because Perl returns the value
of the last statement in a function?) So, those getter/setter functions
are not confusing.