Kenneth Graunke <kenn...@whitecape.org> writes: > On 11/06/2012 10:47 AM, Eric Anholt wrote: >> We were successfully freeing our compile data at context destroy, but until >> then we were allocating a new store every compile without freeing it.
>> /* Allocate the references to the uniforms that will end up in the
>> * prog_data associated with the compiled program, and which will be
>> freed
>> @@ -239,14 +226,14 @@ bool do_wm_prog(struct brw_context *brw,
>> /* The backend also sometimes adds params for texture size. */
>> param_count += 2 * BRW_MAX_TEX_UNIT;
>>
>> - c->prog_data.param = rzalloc_array(c, const float *, param_count);
>> - c->prog_data.pull_param = rzalloc_array(c, const float *,
>> param_count);
>> + c->prog_data.param = rzalloc_array(NULL, const float *, param_count);
>> + c->prog_data.pull_param = rzalloc_array(NULL, const float *,
>> param_count);
>> } else {
>> /* brw_wm_pass0.c will also add references to 0.0 and 1.0 which are
>> * uploaded as push parameters.
>> */
>> int param_count = (fp->program.Base.Parameters->NumParameters + 2) *
>> 4;
>> - c->prog_data.param = rzalloc_array(c, const float *, param_count);
>> + c->prog_data.param = rzalloc_array(NULL, const float *, param_count);
>> /* The old backend never does pull constants. */
>> c->prog_data.pull_param = NULL;
>> }
>
> This code mentions the old backend. It either needs to die or get
> relabeled.
>
> Otherwise, this looks fine to me. You really don't need to be using
> ralloc for any of this...it's just adding overhead. (Then again, I
> might file that in the 'meh' department...)
Yeah, I'd thought about swapping to calloc/free, then figured I'd
silently botch the size argument and be embarassed later (see also
5ac46da58893). Seriously, rzalloc_array() is a nice api.
pgpzzXNJ1HoQH.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
