search for: sampler_state_delete

...amplers[s][i] = nv50_tsc_entry(hwcso[i]); if (old) nv50_screen_tsc_unlock(nv50->screen, old); } In the above hunk we get the old/current tsc, drop in on the floor and assign the new one in it's place. Does where does the ST keep track of the old one in order to nuke it via sampler_state_delete, or is it already deleted by the time we get here ? -Emil > -ilia > >> >> -Emil >> >>> Tested-by: Christian Ruppert <idl0r at qasl.de> >>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> >>> Cc: "10.2 10.3" <mesa-...

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 >

...so[i]); > if (old) > nv50_screen_tsc_unlock(nv50->screen, old); > } > > In the above hunk we get the old/current tsc, drop in on the floor and assign > the new one in it's place. Does where does the ST keep track of the old one in > order to nuke it via sampler_state_delete, or is it already deleted by the > time we get here ? It's the st's job to do this. It creates the samplers, and it deletes them. Binding is merely setting which samplers map to which slots. -ilia