On 2018-07-16 08:51 PM, Marek Olšák wrote: > On Mon, Jul 16, 2018 at 12:05 PM, Michel Dänzer <michel at daenzer.net> wrote: >> On 2018-07-13 08:47 PM, Marek Olšák wrote: >>> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer <michel at daenzer.net> wrote: >> >>>> I'd rather add the handle to the hash table in amdgpu_bo_alloc, >>>> amdgpu_create_bo_from_user_mem and amdgpu_bo_import instead of in >>>> amdgpu_bo_export, making amdgpu_bo_export(bo, amdgpu_bo_handle_type_kms, >>>> ...) essentially free. In the unlikely (since allocating a BO from the >>>> kernel is expensive) case that the hash table shows up on profiles, we >>>> can optimize it. >>> >>> The hash table isn't very good for high BO counts. The time complexity >>> of a lookup is O(n). >> >> A lookup is only needed in amdgpu_bo_import. amdgpu_bo_alloc and >> amdgpu_create_bo_from_user_mem can just add the handle to the hash >> bucket directly. >> >> Do you know of, or can you imagine, any workload where amdgpu_bo_import >> is called often enough for this to be a concern? > > Fullscreen DRI2 or DRI3 re-imports buffers every frame. DRI3 doesn't. The X server only imports each DRI3 buffer once, after that it's referred to via the pixmap XID. With DRI2 page flipping (ignoring that basically nobody's using that anymore with radeonsi :), it's always the same set of buffers, so the lookup can be made fast as discussed in the sub-thread with Christian. (Also, DRI2 can only use page flipping with sync-to-vblank enabled, so this happens on the order of hundreds of times per second max) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
