On Wed, Nov 26, 2014 at 10:59 AM, Matt Turner <matts...@gmail.com> wrote:
> On Wed, Nov 26, 2014 at 10:56 AM, Jason Ekstrand <ja...@jlekstrand.net> > wrote: > > On Wed, Nov 26, 2014 at 10:39 AM, Matt Turner <matts...@gmail.com> > wrote: > >> > >> The i965 backends pass something out of 'screen', which is allocated > >> per-process, making using this as a ralloc context not thread-safe. > >> > >> All callers ra_alloc_interference_graph() already ralloc_free() its > >> return value. > >> --- > >> src/util/register_allocate.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c > >> index 6cf7ce7..1cfd66f 100644 > >> --- a/src/util/register_allocate.c > >> +++ b/src/util/register_allocate.c > >> @@ -374,7 +374,7 @@ ra_alloc_interference_graph(struct ra_regs *regs, > >> unsigned int count) > >> struct ra_graph *g; > >> unsigned int i; > >> > >> - g = rzalloc(regs, struct ra_graph); > >> + g = rzalloc(NULL, struct ra_graph); > > > > > > Why not make ra_alloc_interference_graph take a ralloc context? > > I mean, I could, but why? All callers of ra_alloc_interference_graph() > ralloc_free its result themselves. > Sure. It doesn't much matter. It just gives us the option. I don't care much either way. This one is Reviewed-by: Jason Ekstrand <jason.ekstr...@intel.com>
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
