On 2018-07-17 09:59 AM, Christian König wrote: > Am 17.07.2018 um 09:46 schrieb Michel Dänzer: >> On 2018-07-17 09:33 AM, Christian König wrote: >>> Am 17.07.2018 um 09:26 schrieb Michel Dänzer: >>>> On 2018-07-17 08:50 AM, Christian König wrote: >>>>> Am 16.07.2018 um 18:05 schrieb Michel Dänzer: >>>>>> On 2018-07-13 08:47 PM, Marek Olšák wrote: >>>>>> [SNIP] >>>>>> Other opinions? >>>>> I understand the reason why Marek wants to do this, but I agree that >>>>> this is a little bit dangerous if used incorrectly. >>>>> >>>>> On the other hand I don't see any other way to sanely handle it >>>>> either. >>>> Sanely handle what exactly? :) I still haven't seen any description of >>>> an actual problem, other than "the handle is stored in the hash table". >>> Well the problem is that it's not "the handle" but rather "all handles" >>> which are now stored in the hash table. >>> >>> To begin with that is quite a bunch of wasted memory, not talking about >>> the extra CPU cycles. >> All that should be needed is one struct list_head per BO, 16 bytes on >> 64-bit. > > +malloc overhead and that for *every* BO the application/driver > allocated.
The struct list_head can be stored in struct amdgpu_bo, no additional malloc necessary. > The last time I looked we could easily have a few thousands of that > (but not in the same CS). > > So I would guess that the wasted memory can easily be in the lower kb > range, compared to adding just a flag that we never going to import the > handle again. I wouldn't call the memory "wasted", as it serves a clear purpose. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
