View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005429 | Dwarf Fortress | Technical -- Rendering | public | 2012-02-24 06:07 | 2012-03-19 02:59 |
| Reporter | voodooattack | Assigned To | Baughn | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | SDL | OS | Windows 7 | OS Version | SP1 |
| Product Version | 0.34.02 | ||||
| Summary | 0005429: Memory leak in VBO renderer | ||||
| Description | I've found a memory leak in the VBO renderer for SDL, memory consumption steadily grows and never drops. Graph showing it in action: http://dl.dropbox.com/u/27714141/df_memory.png DF was merely showing the main menu at that point, memory usage increased by ~300kb per step in the graph. That amount increases and frame rate drops considerably in fortress mode, prior to the inevitable crash. | ||||
| Steps To Reproduce | Run in VBO mode, observe memory usage. | ||||
| Tags | No tags attached. | ||||
|
|
STANDARD/PARTIAL, FRAME_BUFFER, and ACCUM_BUFFER leak memory at a similar rate on my system. The leak rate doesn't seem to vary based on the window/grid size, though. 2D/2DSW/2DASYNC also leak memory, but much more slowly, only 4KB every few seconds when displaying the title screen. |
|
|
Indeed, I was just testing other modes, and can confirm Quietust's results. SHADER seems to be the worst though. |
|
|
Reminder sent to: Baughn Do it to it |
|
|
Just for the record, shader mode doesn't exist. |
|
|
Hmm, DF accepts the value in init.txt without a warning then. Never mind. |
|
|
It does, and defaults to 2D. Fixing (rewriting, more like) the init.txt parser is on my to-do list. |
|
|
I found and fixed several minor memory leaks, but nothing that would have a per-frame effect, or the effect described - the worst one would leak whenever you switch to fullscreen and back, the others mostly just leaked at program exit, which clutters up valgrind output but does nothing else. Leaving it running for ages on Linux shows no leak, either, and it seems like it should be relatively obvious. Is everyone who's seeing the leak on Windows? |
|
|
(Oh, and the leak you're seeing for 2D mode may not be a leak at all; the tile cache is built lazily, so having it increase slowly is pretty much normal, at least if you've got the FPS option on.) |
|
|
It might be a windows-only problem, I couldn't test on linux myself because my box is down. I guess finding the problem on windows would be harder, lack of valgrind and all. And yeah, I noticed that 2D's memory allocation is more like spikes, it drops back down after a while. |
|
|
I'm not seeing it in Windows, either. What GPU/driver do you have installed? |
|
|
I was seeing it on Windows 7 64-bit with an NVIDIA GPU (don't remember the driver version), but I'm not seeing it on Windows XP with NVIDIA 280.26 drivers. |
|
|
After installing the newest nvidia driver, I've noted that DF memory shoots up quite a bit at launch, but then holds still at ~100MB, 60MB more than at launch. That's not very nice behaviour from the drivers, but it's survivable. Would you like to confirm, so I can close this bug? |
|
|
I'm also using a NVIDIA card, not sure if that's relevant. And yeah, you can close it if you want, I'll try to test again with the next patch and report the results. If something goes awry I could either submit a new bug report or request this to be reopened. Thanks. :) |
|
|
I mean, can you verify that the "leak" eventually *stops*? |
|
|
No it doesn't. I've left it open at the title screen for 2 hours now and it went up from 40MB to 207MB, and is still (slowly but steadily) rising. I'll leave it open for a couple more hours and see how high it goes. |
|
|
Before I forget, here are my GPU specs: Operating System: Windows 7 Ultimate, 32-bit (Service Pack 1) DirectX version: 11.0 GPU processor: GeForce GT 240 Driver version: 285.62 DirectX support: 10.1 CUDA Cores: 96 Core clock: 550 MHz Shader clock: 1340 MHz Memory clock: 1700 MHz (3400 MHz data rate) Memory interface: 128-bit Total available graphics memory: 2815 MB Dedicated video memory: 1024 MB GDDR5 System video memory: 0 MB Shared system memory: 1791 MB Video BIOS version: 70.15.2D.00.70 IRQ: 18 Bus: PCI Express x16 Gen2 |
|
|
Same instance from before, still at the title screen, and here's where it's at: http://dl.dropbox.com/u/27714141/df_memory2.png 1GB of memory allocated. |
|
|
I wonder if it might happen only on 32-bit W7? It's definitely a problem in the graphics drivers, but it doesn't act out in the same way on the 64-bit version. I think. |
|
|
I honestly have no idea. When I experimented with [ARB_SYNC:YES] it got *much* worse though, there might be a clue there. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-02-24 06:07 | voodooattack | New Issue | |
| 2012-02-24 06:09 | Quietust | Note Added: 0020593 | |
| 2012-02-24 06:15 | Quietust | Note Edited: 0020593 | |
| 2012-02-24 06:20 | voodooattack | Note Added: 0020594 | |
| 2012-02-24 07:15 |
|
Status | new => assigned |
| 2012-02-24 07:15 |
|
Assigned To | => Baughn |
| 2012-02-24 07:20 |
|
Note Added: 0020600 | |
| 2012-02-24 12:35 | Baughn | Note Added: 0020617 | |
| 2012-02-24 13:20 | voodooattack | Note Added: 0020619 | |
| 2012-02-24 13:39 | Baughn | Note Added: 0020620 | |
| 2012-02-24 15:58 | Baughn | Note Added: 0020629 | |
| 2012-02-24 16:27 | Baughn | Note Added: 0020630 | |
| 2012-02-24 19:57 | voodooattack | Note Added: 0020635 | |
| 2012-02-25 08:21 | Baughn | Note Added: 0020658 | |
| 2012-02-25 08:51 | Quietust | Note Added: 0020659 | |
| 2012-02-25 09:45 | Baughn | Note Added: 0020661 | |
| 2012-02-25 10:43 | voodooattack | Note Added: 0020663 | |
| 2012-02-25 11:16 | Baughn | Note Added: 0020666 | |
| 2012-02-25 21:59 | voodooattack | Note Added: 0020696 | |
| 2012-02-25 22:08 | voodooattack | Note Added: 0020697 | |
| 2012-02-26 05:00 | voodooattack | Note Added: 0020705 | |
| 2012-03-08 16:14 | Baughn | Note Added: 0021281 | |
| 2012-03-19 02:59 | voodooattack | Note Added: 0021587 |
