On 01/19/2016 02:28 AM, Daniel Stone wrote: >>>> >> > We aren't just talking about a few fbs here, we already see more than >>>> >> > 100 fbs active during complex situations. Potentially doubling this >>>> >> > number is surely a significant increase in memory usage, both from the >>>> >> > management side in userspace and the kernel side. >> > >> > 8kb kernel memory for the additional 2 copies of drm_framebuffer structs >> > for 100 buffers. That's about as much as the minimal overhead for just 1 >> > underlying gem object (counting the sg table, vma, gtt pte tracking, gem >> > object and shmem backing node and pagecache entries). 2 integers in userspace. >> > >> > Do you have some data to show that overhead? > I agree with this view as well, and it does seem to be the way chosen > for generic userspace on other drivers. > > For context, the way ChromeOS and Wayland compositors (Weston, Mutter, > Enlightenment) work is that a userspace library called GBM is > distributed as part of EGL, which is the native EGL platform/winsys > for rendering on KMS. The major difference with GBM, however, is that > it does _not_ do presentation: presentation is explicitly controlled > by the compositor itself. > > In order to use this new property, we would have to add API to EGL/GBM > to extract a list of property names to set, which wouldn't really make > for great API. It'd be much cleaner for these users to stick with FB > modifiers, especially as they destroy and recreate the FB objects > (something we've not seen have any performance impact) for every flip > anyway. From my side, I'd be much happier using generically-applicable > FB modifiers, than continuing along the property explosion. > > The other sticking point is that if I go from flipping GPU buffers > with render compression enabled to software buffers, from userspace > that means I then need to explicitly go unset the render decompression > flag before I can display software buffers, else the flips just get > rejected; something which isn't the case with FB modifiers. One more > thing to go wrong ... Just for background, we ended up with a property for this attribute due to a request from the only userland folks we had at the time (our hwcomposer team). They felt it would be simpler to use a property in this specific case, though they already do have a number of fb objects to deal with. Really I can make an argument either way for how well each matches hardware behavior, so figured we'd just go with a property due to someone expressing a preference. This has probably already been changed in an updated patch (still catching up on mail), but I thought I'd at least chime in on the thinking on this from way back (around a year ago now I think). Cc'ing Gary in case he has further comment. Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
