On 31/08/14 01:13, Ilia Mirkin wrote:
> On Sat, Aug 30, 2014 at 8:09 PM, Emil Velikov <emil.l.veli...@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.veli...@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
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
