[PATCH v2 0/3] ast, mgag200: Map console BO while it's being displayed
tzimmermann at suse.de
Fri Sep 6 08:10:28 UTC 2019
Am 05.09.19 um 11:29 schrieb Gerd Hoffmann:
> On Thu, Sep 05, 2019 at 10:19:40AM +0200, Thomas Zimmermann wrote:
>> Am 05.09.19 um 09:56 schrieb Daniel Vetter:
>>> On Thu, Sep 5, 2019 at 9:01 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>>>>> - imo we should fix this by using the io_mapping stuff, that avoids
>>>>> the overhead of repeated pat checks for map/unmap.
>>>> Another idea: IIRC ttm has a move_notify callback. So we could simply
>>>> keep mappings active even when the refcount goes down to zero. Then do
>>>> the actual unmap either in the move_notify or in the destroy callback.
>>> Yeah that should be a really clean solution, and only needs changes in
>>> the vram helpers. Which is nice, more common code!
>> But the console's BO is special wrt to mapping. Putting special code for
>> console handling into vram helpers doesn't seem right.
> I have no special handling in mind. I think we can simply do that for
> all gem objects, no matter whenever they are created by fbcon or
> userspace (wayland/xorg/whatever). vmap will create a mapping (or
> increase the reference count). vunmap decreases the reference count,
> when it goes down to zero unpin it but keep the mapping. The actual
> unmap happens when ttm wants move the object from VRAM to SYSTEM due to
> VRAM being full. In case vram has room for all our objects we simply
> never unmap.
That's pretty cool. Thanks for clarifying. I think it's the solution I
was looking for.
> hope this clarifies,
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the dri-devel