Dave Airlie wrote:
>> At least for TTM this is part of a larger problem where you can hit
>> problems both when the pinned page quota is hit, and when
>> you can't fit an object in the aperture.
>>
>> The other problem is the one you mention. Since we're dealing with
>> multiple clients and only
> > The problem remains how to avoid this situation completely. I guess the
> > drm driver can reserve a global "safe" aperture size, and communicate
> > that to the 3D client, but the current TTM drivers don't deal with this
> > situation.
> > My first idea would probably be your first alterna
> At least for TTM this is part of a larger problem where you can hit
> problems both when the pinned page quota is hit, and when
> you can't fit an object in the aperture.
>
> The other problem is the one you mention. Since we're dealing with
> multiple clients and only evict one buffer at a t
Dave Airlie wrote:
> Hi Eric,
>
> others: This may be a larger problem (I'd be interested in how TTM solves
> this also).
>
> So I've hit a problem with the fake bufmgr and the size of the objects
> referenced by a batchbuffer being bigger than the current aperture. So
> when we have a batchbuff
>
> Hi Eric,
>
> others: This may be a larger problem (I'd be interested in how TTM solves
> this also).
>
> So I've hit a problem with the fake bufmgr and the size of the objects
> referenced by a batchbuffer being bigger than the current aperture. So
> when we have a batchbuffer and we are
Hi Eric,
others: This may be a larger problem (I'd be interested in how TTM solves
this also).
So I've hit a problem with the fake bufmgr and the size of the objects
referenced by a batchbuffer being bigger than the current aperture. So
when we have a batchbuffer and we are emitting a number
