Page MenuHome

blenderplayer painfully slow in recent builds
Closed, ResolvedPublic


System Information
OS: Ubuntu 13.04 (64 bit)
Graphics: ATI Mobility Radeon HD 5430

Blender Version
Broken: Blender 2.69 e9e08a1 (from buildbot)
Broken: Blender 2.69 48b9680 (own build)
Worked: Blender 2.69 6d8f76c (from buildbot)

Short description of error

Older versions of blenderplayer worked fairly well with my game (15-25fps), now they are very slow indeed (1.1fps).

Exact steps for others to reproduce the error

Start a game that contains a fairly complicated scene. Details for the one I'm testing with are listed below - but this is by no means a minimal test case.

  1. Download S. Cargo - Note: this game is currently in beta; please don't publicise widely.
  2. Unzip it, and change to the new directory.
  3. Ignore the packaged cargo executable, and instead run blenderplayer assets/Outdoors.blend. Notice that the frame rate is much slower in recent versions.

Although e9e08a1 is the earliest version I've tried so far that has the bug, I'm pretty sure this is not a bug in the LOD code. Here is a screenshot of a profiler that I ran while running the game:

This profile was taken after the game had finished loading, and yet a great deal of time was spent loading images. I think this is not the case in 6d8f76c (which doesn't have the bug) - although I still need to build that version with debug symbols to be sure.

Event Timeline

Alex Fraser (z0r) added a project: Game Engine.
Alex Fraser (z0r) set Type to Bug.
Alex Fraser (z0r) created this task.
Alex Fraser (z0r) raised the priority of this task from to Needs Triage by Developer.

Seeing as the __libc_start_main is such a low percentage, I guessing your game is GPU bound. This means we have to find what changed for the GPU.

Yep - my suspicion is that all images (textures) are being re-loaded on every frame and transferred to the GPU.

It seems this was caused by the image cache rewrite on the 13th of December: ce893552c359d11cfa93709f239a3c93f4cdb244

git bisect start
# bad: [e9e08a1d12594eab0e341049fc252ff8578e9333] Game Engine: Level of detail support and tools
git bisect bad e9e08a1d12594eab0e341049fc252ff8578e9333
# good: [6d8f76cfabd96bf3865f924f8afdcb13ae78beb4] Minor addition for completeness (unlikely to happen), make sure new sculpt struct has at least dyntopo subdivision turned on.
git bisect good 6d8f76cfabd96bf3865f924f8afdcb13ae78beb4
# good: [afffa9bc39d54eec505c9397d56a2c8275d81e08] RNA: Add assert to ensure the idprop is correct size on array get/set
git bisect good afffa9bc39d54eec505c9397d56a2c8275d81e08
# bad: [1bebdc9ad0b6174a9aee243ad37fcc20db23791c] Fix T37264: cycles CPU render had limited number of float images, bumped to 1024.
git bisect bad 1bebdc9ad0b6174a9aee243ad37fcc20db23791c
# good: [9e30783585642643968c8f15415240371b4e8be1] Interface / PointCache: Remove name fields here as well, not needed anymore due to direct rename in uiList.
git bisect good 9e30783585642643968c8f15415240371b4e8be1
# bad: [f372758257e268d4c1278aceeb243c1aa83ad695] Interface / Modifiers: Don't show cage placeholder in modifier header, if the current modifier does not support it or the cage is disabled (like Subsurf 0).
git bisect bad f372758257e268d4c1278aceeb243c1aa83ad695
# bad: [c456cd94b23af53b53ac13219ea488ed6e7eb5c2] Curve Handle Recalculate (Ctrl+N)
git bisect bad c456cd94b23af53b53ac13219ea488ed6e7eb5c2
# bad: [ce893552c359d11cfa93709f239a3c93f4cdb244] Image cache rewrite to using generic movie cache
git bisect bad ce893552c359d11cfa93709f239a3c93f4cdb244
# good: [7eab49f8d923ed3992dff1236e30a62f2d70f460] Interface / Particles: Fix bad alignment in Rotation panel, sub layout missed the flag.
git bisect good 7eab49f8d923ed3992dff1236e30a62f2d70f460

Segey, any thoughts on this bug?

To be clear: this bug only happens in blenderplayer; not when running the game in blender.

..ah, I see this has a change in do_versions! I'll re-save all my asset files. Maybe that's it.

..ah, I see this has a change in do_versions! I'll re-save all my asset files. Maybe that's it.

That wasn't it :) I re-saved everything with 58ae499 and the bug is still present.

I don't see what could be causing the extra GPU load, unless cache misses are triggering texture uploads somehow. That would lead me to suspect something isn't being properly initialized in the BGE, but I don't see any new initialization code. Hopefully Sergey can shed some light on this.

This is due to images needed for the level doesn't fit into the cache limit. Easy fix would be to disable cache limitor whe BGE is running, but maybe i'll think something smarter today.

P.S. Noticed some more issues with the cache rewrite, working on all this now.

Sergey Sharybin (sergey) triaged this task as Confirmed, Medium priority.Dec 22 2013, 8:32 AM

Solved for now by disabling cache limiter. This brings up old behavior, but would be cool to discuss better cache policies here.

Thank you, Sergey! I'm happy to have a discussion about cache policies.

Do we event need to keep images in the cache? Once they're in the GPU memory, that should be enough, right? They could be discarded from the cache at that point - with video textures being a special case (maybe they don't even use the cache now).

So, now I just need to wait for the buildbot maintainers to come back from holiday to make my release. That's a pretty good position to be in. Thanks!

@Alex Fraser (z0r), the thing is, it seems image is not always in GPU memory. And even if so, with current design we can not have image in GPU and not in CPU memory. Not as if it's not possible to support, but that's rateher huge project..

Change in image cache mechanism was mainly caused by image sequences never frees the memory. For example, if you'll open log image sequence, set it up as a 3D viepwort background and start playback you'll run out of memory sooner or later. With new cache mechanism old image frames will be dropped from memory.

Not sure whether it was ever a problem in GE? As in, with old cache (when images were never removed from the memory) were there any out-of-memory issues or so?