[Nouveau] [Mesa-stable] [PATCH 2/2] nv50: zero out unbound samplers

[Emil Velikov]

On 31/08/14 01:13, Ilia Mirkin wrote:
> On Sat, Aug 30, 2014 at 8:09 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 31/08/14 00:34, Ilia Mirkin wrote:
>>> On Sat, Aug 30, 2014 at 7:30 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> 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 ?
>>>
>>> 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 *old = nv50->samplers[s][i];
>>
>>       nv50->samplers[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 ?
> 
> 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.
> 
It seemed to me that the driver was doing some of the "heavy lifting", so I
was a bit confused. Thanks for the clarification.

-Emil

>   -ilia
>