On Wed, Aug 1, 2018 at 1:52 PM, Christian König <christian.koenig at amd.com> wrote: > Am 01.08.2018 um 19:39 schrieb Marek Olšák: >> >> On Wed, Aug 1, 2018 at 2:32 AM, Christian König >> <christian.koenig at amd.com> wrote: >>> >>> Am 01.08.2018 um 00:07 schrieb Marek Olšák: >>>> >>>> Can this be implemented as a wrapper on top of libdrm? So that the >>>> tree (or hash table) isn't created for UMDs that don't need it. >>> >>> >>> No, the problem is that an application gets a CPU pointer from one API >>> and >>> tries to import that pointer into another one. >>> >>> In other words we need to implement this independent of the UMD who >>> mapped >>> the BO. >> >> Yeah, it could be an optional feature of libdrm, and other components >> should be able to disable it to remove the overhead. > > > The overhead is negligible, the real problem is the memory footprint. > > A brief look at the hash implementation in libdrm showed that this is > actually really inefficient. > > I think we have the choice of implementing a r/b tree to map the CPU pointer > addresses or implement a quadratic tree to map the handles. > > The later is easy to do and would also allow to get rid of the hash table as > well. We can also use the hash table from mesa/src/util. I don't think the overhead would be negligible. It would be a log(n) insertion in bo_map and a log(n) deletion in bo_unmap. If you did bo_map+bo_unmap 10000 times, would it be negligible? Marek
