Am Dienstag, den 04.09.2018, 10:31 +0100 schrieb Emil Velikov:
> On 3 September 2018 at 20:52, Gert Wollny <gert.wol...@collabora.com>
> wrote:
> > Am Montag, den 03.09.2018, 14:42 +0100 schrieb Emil Velikov:
> > >
> > > struct virgl_hw_res **new_bo =
> > >
> > > > + new_nres * sizeof(struct
> > > > virgl_hw_buf*));
> > > > + if (!new_ptr) {
> > > > + fprintf(stderr,"failure to add relocation %d, %d\n",
> > > > cbuf->cres, new_nres);
> > > > return;
> > > > }
> > > > + cbuf->res_bo = new_ptr;
> > > > +
> > > > + new_ptr = REALLOC(cbuf->res_hlist, cbuf->nres *
> > > > sizeof(uint32_t),
> > >
> > > uint32_t *new_hlist =
> > >
> > > > + new_nres * sizeof(uint32_t));
> > > > + if (!new_ptr) {
> > > > + fprintf(stderr,"failure to add hlist relocation %d,
> > > > %d\n", cbuf->cres, cbuf->nres);
> > >
> > > FREE(new_bo);
> >
> > I don't think this is correct: as far as I understand how ralloc
> > works, then if the realloc succeeds, then the old cbuf->res_bo is
> > either invalidated, or points to the same area like new_bo. In both
> > cases free will free the memory where resource data is stored, and
> > later at cleanup this will lead to problems.
> >
>
> Ralloc is not used here, yet people could if they want to. Fwiw there
> are 0 instances of it in gallium/winsys.
Not sure what you want to tell me here, REALLOC vs realloc is about
60/40 in gallium/winsys, not using RALLOC makes the code look simpler
for virgl though,
Best,
Gert
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
