HeadCase
Posts: 45
Joined: Sat Sep 03, 2011 8:11 am

Possible memory leak in Anholt driver

Wed Mar 27, 2019 12:18 pm

Maybe James can pass this up to to Eric at some stage.

I have been testing the OpenGL driver on Pi using the love2d framework. This compiles to Raspbian and can be loaded from the repositories (although the previous version). The latest love2d 11.2 can be compiled from source fairly easily.

The performance of the OpenGL driver has been exceptionally good, such that replicating a desktop linux program on the Pi is identical to the x86 version, including frame rate of about 60fps. Love2d uses LuaJit, which performs very well on Pi.

Recently I found a case where the Pi version of love2d actually fails. This is not evident on any other system across various GPU types. The problem occurs when there are multiple screen draws and one of them involves a quad (which defines a rect in a texture). In this case, over several hundred frames, there seems to be a memory leak which eventually corrupts video ram and stops screen activity. It does not affect the system, as you can close the love2d app and eventually reboot.

To fix this problem, I found that moving all the texture draws to an off screen canvas and then only drawing that canvas to the screen in the frame draw resolves the problem. From that, I would guess that doing direct screen draws from multiple textures (including a quad) invokes different code, which exposes this bug. Love2d uses SDL2, and perhaps that is a factor, I do not know.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22150
Joined: Sat Jul 30, 2011 7:41 pm

Re: Possible memory leak in Anholt driver

Wed Mar 27, 2019 2:10 pm

Can you supply more details of the version of system you are running? OS version, mesa version etc. As much detail as possible.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

HeadCase
Posts: 45
Joined: Sat Sep 03, 2011 8:11 am

Re: Possible memory leak in Anholt driver

Fri Mar 29, 2019 12:10 am

The Pi 3B+ is using the latest Raspbian image updated to kernel 4.19.23-v7+ #1203 SMP

I did the kernel upgrade during bug testing and that did not seem to impact the outcome. The mesa version is the current one supported by the repositories - I did not attempt to rebuild the driver.

2.1 Mesa 13.0.6 is what is reported by glxinfo | grep "OpenGL version"

The love2d framework was initially 11.2 installed from .deb files supplied from the love2d guys. These were probably compiled on an x86 machine, so I downloaded their latest source and built it on the Pi 3. The problem persisted. The problem does not appear on any x86 linux machine with either nvidia or radeon GPU.


The love2d framework uses a love.draw() call which updates the screen at 60fps. There is no image buffer - you have to draw all elements in the draw call. So the draw call looks like

Code: Select all

love.draw()
    love.graphics.draw(Src_Img, 20,20)    -- a texture loaded from a .png file
    love.graphics.draw(Clip_Img, 840,20)  -- another texture loaded from a .png file

   bm16.draw()   -- a draw based on a quad pointing into a large 1024x1024 texture created from a bitmap

  love.graphics.print("Tick: "..bm16.tick, 1120,280)
  love.graphics.print("Frame: "..bm16.frame, 1010,280)   -- frame counter in top right of screen as proof of life
end
What I found was that any combination of the quad draw and a simple image draw caused the program to degrade over several hundred frames (variable) such that the frame counter stopped followed by degradation of the whole X window (not just in the application window) visible as corrupt blocks. Some of the blocks are solid colour, some are misplaced from somewhere else on the screen. Converting the video format in the config.lua file to full screen (t.window.borderless = false) did not fix the problem. Terminating the love program - (if k == 'escape' then love.event.quit() end ) stops the video corruption and X seems to show some signs of repairing the screen.

The time for the program to fail seems to be highly variable, but in general somewhere in the order of a few hundred to a thousand frames.
I tried all combinations of the draw calls, and the order was not a factor.
Eliminating the simple draws and just calling the quad based draw does not invoke the bug.
Multiple simple texture draws are not a problem, although I only tested up to three.
Text draws did not affect the outcome.

To prove that this problem was only evident in the love.draw() call that draws to the screen, I created an offscreen canvas of 1920x1080 and moved all the texture draws to that canvas, then in the love.draw() used that as the source for a single draw to the screen. This technique never exposes the bug, so that seems to point to the presumed video memory leak only being activated when composing the image to send to X.

I hope that helps. There doesn't seem to be anything more to test without a deep understanding of the driver code. The love2d source is available at bitbucket https://bitbucket.org/rude/love for details of how their draw system works.

User avatar
Gavinmc42
Posts: 2896
Joined: Wed Aug 28, 2013 3:31 am

Re: Possible memory leak in Anholt driver

Fri Mar 29, 2019 12:55 am

Mesa 13? Very old, there was quite a few VC4 bugs fixes and 19 is now out.

I have been using 18.3 in Gentoo64 and it is much better, but there was some more changes to VC4 from 18.3 to 19 if I read the commit correctly.

Not sure if Raspbian next is using the updated mesa?
Or if Love3D will compile in Gentoo64.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Return to “Graphics programming”