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