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 (bigly_number_of_textures) {
      allocate_texture()
      draw_something()
      delete_texture()
   }
   read_pixels()

There is nothing forcing synchronization until the read_pixels.  So, at the end of the loop, there are 5000 free() queued up, that all get flushed on the read_pixels.  This accounts for ~20GB of allocated system memory.

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.

This suggests that when/if the oom-killer kicks in is more dependent on the amount of system memory than indicative of a memory leak.

I'm going to close this as "not a bug", since we're technically not leaking memory.

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

OK.  I have a small patch that lowers the overall memory usage for streaming-texture-leak without affecting our targeted applications.

For those running on smaller memory (16GB?) systems, this will prevent oom-killer.

Thus far, we have not seen any real world applications that exhibit behavior similar to the streaming-texture-leak test; as any form of pipeline flush will trigger the defer queue and properly free any retained allocations.  But, this addresses those as well.  

I'll submit the patch for review shortly.

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 sync fence when the queue size
exceeds a threshold.  This initiates deferred deletion of all resources
on the list and decreases the total amount of memory held waiting for
"deferred deletion".

Available in 17.1.5 with commit 5c91fcfa.

(In reply to Bruce Cherniak from comment #7)
> Available in 17.1.5 with commit 5c91fcfa.

Thanks Bruce, I should actually have noted that myself.

I suppose we can close, then ...