search for: sampler_state_cr

...on't try to read them again later. >>> >> Would it be worth doing a similar thing with the unlocked samplers below the >> nr mark ? It seems to me that we might be leaking nv50->samplers[s][i], or >> perhaps I'm missing something ? > > Can you elaborate? sampler_state_create/delete deal with allocation > and deallocation. samplers starts out as NULL. I'm just making sure > that a subsequent call with a larger number of samplers doesn't try to > unlock potentially-deleted samplers. > for (i = 0; i < nr; ++i) { struct nv50_tsc_entry...

On 30/08/14 23:02, Ilia Mirkin wrote: > Samplers are only defined up to num_samplers, so set all samplers above > nr to NULL so that we don't try to read them again later. > Would it be worth doing a similar thing with the unlocked samplers below the nr mark ? It seems to me that we might be leaking nv50->samplers[s][i], or perhaps I'm missing something ? -Emil >

...t; nr to NULL so that we don't try to read them again later. >> > Would it be worth doing a similar thing with the unlocked samplers below the > nr mark ? It seems to me that we might be leaking nv50->samplers[s][i], or > perhaps I'm missing something ? Can you elaborate? sampler_state_create/delete deal with allocation and deallocation. samplers starts out as NULL. I'm just making sure that a subsequent call with a larger number of samplers doesn't try to unlock potentially-deleted samplers. -ilia > > -Emil > >> Tested-by: Christian Ruppert <idl0r at q...

...em again later. >>>> >>> Would it be worth doing a similar thing with the unlocked samplers below the >>> nr mark ? It seems to me that we might be leaking nv50->samplers[s][i], or >>> perhaps I'm missing something ? >> >> Can you elaborate? sampler_state_create/delete deal with allocation >> and deallocation. samplers starts out as NULL. I'm just making sure >> that a subsequent call with a larger number of samplers doesn't try to >> unlock potentially-deleted samplers. >> > > for (i = 0; i < nr; ++i) { >...