https://bugs.freedesktop.org/show_bug.cgi?id=101467
Andrés Gómez García changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=101467
--- Comment #7 from Bruce Cherniak ---
Available in 17.1.5 with commit 5c91fcfa.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=101467
--- Comment #6 from Bruce Cherniak ---
Fixed in master by commit 32c1a54b. cc'd for inclusion in 17.1 stable.
This patch limits the number of items on the fence work queue (the
deferred deletion list) by submitting a
https://bugs.freedesktop.org/show_bug.cgi?id=101467
Bruce Cherniak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=101467
--- Comment #4 from Eero Tamminen ---
If application is freeing the resources, but driver memory usage still grows
unbounded due to deferred deletion, I'm not sure what else it could be
described than leak...
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=101467
Bruce Cherniak changed:
What|Removed |Added
Resolution|--- |NOTABUG
https://bugs.freedesktop.org/show_bug.cgi?id=101467
--- Comment #2 from Bruce Cherniak ---
For the curious, this is the same result as allowing llvmpipe to build larger
scenes by setting the defines LP_SCENE_MAX_SIZE and LP_SCENE_MAX_RESOURCE_SIZE
to *large* values.
https://bugs.freedesktop.org/show_bug.cgi?id=101467
--- Comment #1 from Bruce Cherniak ---
Well, technically the swr driver isn't "leaking" memory, it's just deferring
deletion of the underlying storage until a sync point.
Because the loop is simply:
for
https://bugs.freedesktop.org/show_bug.cgi?id=101467
Bug ID: 101467
Summary: swr driver leaks memory (texture management)
Product: Mesa
Version: 17.1
Hardware: Other
OS: All
Status: NEW
Severity: normal