Skip to content
GitLab
Switch branch/tag
  1. 01 Aug, 2020 5 commits
  3. 30 Jul, 2020 3 commits
    • Frank Binns's avatar
      egl/dri2: only take a dri2_dpy reference when binding a new context/surfaces · a6cb316f
      Frank Binns authored and Eric Engestrom's avatar Eric Engestrom committed 
      This effectively reverts part of 2907faee, which changed dri2_make_current() to
always take a dri2_dpy reference regardless of whether or not a new context or
surface(s) were being bound. This led to a reference count imbalance as there
was no corresponding code added to drop a reference on the dri2_dpy. As a
consequence, any application that called eglInitialize() on a default/native
display after having called eglTerminate() would always get back the old
dri2_dpy, inheriting its previous state.

As the reference count is there to prevent the dri2_dpy from being destroyed
between eglTerminate() and eglInitialize() calls when a context is still bound,
a reference should only be taken when a successful call to
dri2_dpy->core->bindContext() has been made. Fix the issue by restoring the old
reference counting behaviour.

Fixes: 4e8f95f6 ("egl_dri2: Always unbind old contexts")
Fixes: 2907faee

 ("egl/dri2: try to bind old context if bindContext failed")
Signed-off-by: Frank Binns's avatarFrank Binns <frank.binns@imgtec.com>
Reviewed-by: Luigi Santivetti's avatarLuigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
Tested-by: default avatarNicolas Cortes <nicolas.g.cortes@intel.com>
Closes: #3328
Part-of: <!6105>
(cherry picked from commit d0e32e5f)
      a6cb316f
    • Kenneth Graunke's avatar
      iris: Delete shader variants when deleting the API-facing shader · 2e2a315d
      Kenneth Graunke authored and Eric Engestrom's avatar Eric Engestrom committed 
      We were space-leaking iris_compiled_shader objects, leaving them around
basically forever - long after the associated iris_uncompiled_shader was
deleted.  Perhaps even more importantly, this left the BO containing the
assembly referenced, meaning those were never reclaimed either.  For
long running applications, this can leak quite a bit of memory.

Now, when freeing iris_uncompiled_shader, we hunt down any associated
iris_compiled_shader objects and pitch those (and their BO) as well.

One issue is that the shader variants can still be bound, because we
haven't done a draw that updates the compiled shaders yet.  This can
cause issues because state changes want to look at the old program to
know what to flag dirty.  It's a bit tricky to get right, so instead
we defer variant deletion until the shaders are properly unbound, by
stashing them on a "dead" list and tidying that each time we try and
delete some shader variants.

This ensures long running programs delete their shaders eventually.

Fixes: ed4ffb97

 ("iris: rework program cache interface")
Reviewed-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
Part-of: <!6075>
(cherry picked from commit 128cbcd3)
      2e2a315d
    • Eric Engestrom's avatar
      .pick_status.json: Update to c77a414e · 158babb8
      Eric Engestrom authored
      158babb8
  5. 29 Jul, 2020 10 commits
  7. 24 Jul, 2020 5 commits
  9. 22 Jul, 2020 17 commits