Currently there is a ton of noise if you try to helgrind mesa. This MR tries to reduce the noise, in particular by adding helgrind annotation for
simple_mtx_t. And also by cleaning up some of the debug env-var patterns that helgrind complains about.
Unfortunately on aarch64, helgrind seems unaware of some of the atomic instructions, so we still get some warnings like:
==449516== Possible data race during write of size 4 at 0xF703080 by thread #13 ==449516== Locks held: none ==449516== at 0xED40658: simple_mtx_unlock (simple_mtx.h:147) ==449516== by 0xED41333: fd_screen_unlock (freedreno_screen.h:147) ==449516== by 0xED42EAF: flush_resource (freedreno_resource.c:525) ==449516== by 0xED43103: fd_flush_resource (freedreno_resource.c:561) ==449516== by 0xE29A60B: dri2_allocate_textures (dri2.c:450) ==449516== by 0xE29F92F: dri_st_framebuffer_validate (dri_drawable.c:82) ==449516== by 0xE2B001B: st_framebuffer_validate (st_manager.c:223) ==449516== by 0xE2B1EBF: st_manager_validate_framebuffers (st_manager.c:1174) ==449516== by 0xE2E1D47: st_validate_state (st_atom.c:203) ==449516== by 0xE2EB263: st_Clear (st_cb_clear.c:442) ==449516== by 0xE77C9D7: clear (clear.c:221) ==449516== by 0xE77C9D7: _mesa_Clear (clear.c:242) ==449516== by 0xD79BE4F: shared_dispatch_stub_203 (glapi_mapi_tmp.h:21475) ==449516== ==449516== This conflicts with a previous read of size 4 by thread #8 ==449516== Locks held: 1, at address 0x1850C518 ==449516== at 0xEEFE5F0: __aarch64_ldadd4_acq_rel (in /home/robclark/src/mesa/debug/b/lib64/dri/msm_dri.so) ==449516== by 0xED3B0FF: simple_mtx_unlock (simple_mtx.h:142) ==449516== by 0xED3B7EB: fd_screen_unlock (freedreno_screen.h:147) ==449516== by 0xED3CCAF: lookup_gmem_state (freedreno_gmem.c:565) ==449516== by 0xED3D9C3: fd_gmem_render_tiles (freedreno_gmem.c:733) ==449516== by 0xEDEBB0B: batch_flush (freedreno_batch.c:355) ==449516== by 0xEDEBBB3: fd_batch_flush (freedreno_batch.c:384) ==449516== by 0xED3495F: bc_flush (freedreno_batch_cache.c:169) ==449516== Address 0xf703080 is 448 bytes inside a block of size 1,064 alloc'd ==449516== at 0x486A9C0: calloc (vg_replace_malloc.c:760) ==449516== by 0xED28733: fd_screen_create (freedreno_screen.c:871) ==449516== by 0xED266BB: fd_drm_screen_create (freedreno_drm_winsys.c:86) ==449516== by 0xE29713F: pipe_msm_create_screen (drm_helper.h:239) ==449516== by 0xEC97F5B: pipe_loader_drm_create_screen (pipe_loader_drm.c:264) ==449516== by 0xEC977FF: pipe_loader_create_screen (pipe_loader.c:156) ==449516== by 0xE29E24F: dri2_init_screen (dri2.c:2183) ==449516== by 0xEB4EAEF: driCreateNewScreen2 (dri_util.c:160) ==449516== by 0xC6FE56B: dri3_create_screen (dri3_glx.c:907) ==449516== by 0xC6E1A17: AllocAndFetchScreenConfigs (glxext.c:818) ==449516== by 0xC6E1ECF: __glXInitialize (glxext.c:949) ==449516== by 0xC6DA473: GetGLXPrivScreenConfig (glxcmds.c:173) ==449516== Block was alloc'd by thread #13
but this does not seem to be a problem on x86 (AFAICT)
update: also doesn't seem to be a problem with drd, which generally seems to do a better job than helgrind.