Gfx: Potential leak on Metal backend related to acquiring command buffer.

Created on 22 Aug 2019 · 4Comments · Source: gfx-rs/gfx

GFX version:
0.3.0 with PR
OS:
macOS Mojave 10.14.6 (18G87)
GPU:
Happens on both:
NVIDIA GeForce GT 750M 2 GB
Intel Iris Pro 1536 MB

I noticed a slow growing leak but couldn't reproduce it until I let the program run for 40 minutes straight with a couple of quads in the foreground. It grew for ~46mb to ~117mb but the one allocation I noticed the most was ~63mb. That being said Instruments does not indicate it as a leak so feel free to close it if it's not considered a leak.

The biggest one (~63mb) was under impl<B: Backend, C> CommandPool<B, C>

    /// Allocates a new primary command buffer from the pool.
    pub fn acquire_command_buffer<S: Shot>(&mut self) -> CommandBuffer<B, C, S> {
        let buffer = self.raw.allocate_one(RawLevel::Primary); // (`~63mb`)
        unsafe { CommandBuffer::new(buffer) }
    }

One level deeper.

fn allocate_one(&mut self, level: com::RawLevel) -> CommandBuffer {
        //TODO: fail with OOM if we allocate more actual command buffers
        // than our mega-queue supports.
        let inner = Arc::new(RefCell::new(CommandBufferInner {  //(`~63mb`)
            sink: None,
            level,
            backup_journal: None,
            #[cfg(feature = "dispatch")]
            backup_capacity: None,
            retained_buffers: Vec::new(),
            retained_textures: Vec::new(),
            active_visibility_queries: Vec::new(),
            events: Vec::new(),
            host_events: Vec::new(),
        }));
        self.allocated.push(Arc::clone(&inner)); //(~2.4mb)

I got a large trace to share, but unable to upload at this time.

Metal request OSX bug medium

Source