On Wed, Jul 27, 2016 at 1:37 AM, Eric Anholt wrote:
> Rob Clark writes:
>
>> On Tue, Jul 26, 2016 at 7:11 PM, Eric Anholt wrote:
>>> Rob Clark writes:
>>>
On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt wrote:
> Overflow memory handling is tricky: While it's still referenced by the
>
Rob Clark writes:
> On Tue, Jul 26, 2016 at 7:11 PM, Eric Anholt wrote:
>> Rob Clark writes:
>>
>>> On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt wrote:
Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed. When we
On Tue, Jul 26, 2016 at 7:11 PM, Eric Anholt wrote:
> Rob Clark writes:
>
>> On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt wrote:
>>> Overflow memory handling is tricky: While it's still referenced by the
>>> BPO registers, we want to keep it from being freed. When we are
>>> putting a new set o
On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt wrote:
> Overflow memory handling is tricky: While it's still referenced by the
> BPO registers, we want to keep it from being freed. When we are
> putting a new set of overflow memory in the registers, we need to
> assign the old one to the last rende
Rob Clark writes:
> On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt wrote:
>> Overflow memory handling is tricky: While it's still referenced by the
>> BPO registers, we want to keep it from being freed. When we are
>> putting a new set of overflow memory in the registers, we need to
>> assign the
Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed. When we are
putting a new set of overflow memory in the registers, we need to
assign the old one to the last rendering job using it.
We were looking at "what's currently runn
