Re: [PATCH v12 00/13] Support blob memory and venus on qemu

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> On 6/5/24 17:47, Alex Bennée wrote:
> ....
>> I'm guessing some sort of resource leak, if I run vkcube-wayland in the
>> guest it complains about being stuck on a fence with the iterator going
>> up. However on the host I see:
>> 
<snip>
>> 
>> The backtrace (and the 18G size of the core file!) indicates a leak:
>
> The unmap debug-assert tells that BO wasn't mapped because mapping
> failed, likely due to OOM. You won't hit this abort with a release build
> of libvirglrenderer.

AFAIK I should be building a release build (or at least I hope that is
what the wrapper I posted does):

  Message-Id: <20240605133527.529950-1-alex.bennee@linaro.org>
  Date: Wed,  5 Jun 2024 14:35:27 +0100
  Subject: [RFC PATCH] subprojects: add a wrapper for libvirglrenderer
  From: =?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>

Maybe I need to explicitly set builtype=release in the default options?

> The leak likely happens due to unsignalled fence.
>
> Please try to run vkcube with disabled fence-feedback feature:
>
>  # VN_PERF_NO_FENCE_FEEDBACK=1 vkcube-wayland
>
> It fixes hang for me. We had problems with combination of this Venus
> optimization feature + Intel ANV driver for a long time and hoped that
> it's fixed by now, apparently the issue was only masked.

That doesn't help, still causes the crash:

  virtio_gpu_fence_ctrl fence 0xdfd, type 0x204                                 
        
  virtio_gpu_fence_ctrl fence 0xdfe, type 0x207                            
  virtio_gpu_fence_ctrl fence 0xdff, type 0x207                        
  virtio_gpu_fence_ctrl fence 0xe00, type 0x207                              
  virtio_gpu_fence_ctrl fence 0xe01, type 0x207                       
  virtio_gpu_fence_ctrl fence 0xe02, type 0x207                                
  virtio_gpu_fence_ctrl fence 0xe03, type 0x207                  
  virtio_gpu_fence_resp fence 0xdfd                                             
        
  virtio_gpu_fence_resp fence 0xdfe                                             
        
  virtio_gpu_fence_resp fence 0xdff                                             
        
  virtio_gpu_fence_resp fence 0xe00                                             
        
  virtio_gpu_fence_resp fence 0xe01                                             
        
  virtio_gpu_fence_resp fence 0xe02                                             
        
  virtio_gpu_fence_resp fence 0xe03                                             
        
  stats: vq req  100,   7 -- 3D   25 (19560)                                    
        
  vrend_renderer_resource_unmap: invalid bits 0x83                              
  virgl_renderer_resource_unmap: unexpected ret = -22, pipe:0x555559e5d0c0 
fd_type:0

  Thread 1 "qemu-system-aar" received signal SIGABRT, Aborted.                  
                                                                                
               
  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
  44      ./nptl/pthread_kill.c: No such file or directory.                     
     

Which I think means VREND_STORAGE_GL_MEMOBJ | VREND_STORAGE_GL_TEXTURE |
VREND_STORAGE_GUEST_MEMORY

(I note the sense of has_bits is meant to be mask, bit but I don't think
that makes any difference)

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro