[PATCH 0/6] Etnaviv cmdbuf suballocator

Christian Gmeiner christian.gmeiner at gmail.com
Wed Feb 1 14:23:45 UTC 2017


2017-01-30 12:52 GMT+01:00 Christian Gmeiner <christian.gmeiner at gmail.com>:
> Hi Lucas,
>
> 2017-01-30 12:48 GMT+01:00 Lucas Stach <l.stach at pengutronix.de>:
>> Am Mittwoch, den 18.01.2017, 12:25 +0100 schrieb Lucas Stach:
>>> Hi all,
>>>
>>> the following patches introduce a cmduf suballocator in the Etnaviv
>>> kernel driver, which has the following benefits:
>>>
>>> 1. Allocating and freeing a CMA buffer for each user command submission
>>>    is taking a big toll on the CPU, as CMA is not exactly low overhead.
>>>    By suballocating a single buffer we avoid all this overhead.
>>>
>>> 2. Less TLB flushes on MMUv2. Each time a new buffer gets mapped into
>>>    the GPU address space on MMUv2 the TLBs need to be flushed. Mapping
>>>    the suballocated area once allows to skip the TLB flushes (at least
>>>    as long as userspace re-uses existing buffers).
>>>
>>> 3. No workarounds for GC3000 required anymore. The FE TLB flush on
>>>    GC3000 doesn't work reliably, which required us to map the cmdbufs
>>>    into the GPU address space at specific positions, which also isn't
>>>    guaranteed to work if the address space is already crowded. Having
>>>    a single static area for the cmdbufs side-steps the erratum completely.
>>>
>>> If I can get reviews and/or enough testing, I would like to include this
>>> code in kernel 4.11.
>>
>> If this helps in testing this change, I have pushed my queue out into my
>> public git repo at:
>>
>> https://git.pengutronix.de/git/lst/linux drm-etnaviv-next
>>
>> The branch is based on v4.10-rc1, but is trivial to rebase onto
>> something more recent.
>>
>
> Will have a look at it later the day.
>

I really like the idea of a suballocator - nice work!

Series is Reviewed-by: Christian Gmeiner <christian.gmeiner at gmail.com>

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner


More information about the dri-devel mailing list