Hi, On 25 January 2016 at 18:15, Smith, Gary K <gary.k.sm...@intel.com> wrote: > I really do not understand what the issue is here. It’s a hint provided by > the user to indicate that the current fb (which was allocated with the > appropriate aux buffer/compression fb modifiers) has been entirely resolved > (uncompressed) and hence can be used anywhere an uncompressed fb would > normally be required. > > Creating a fb that says that there is no aux buffer is entirely wrong in this > case as there is an aux buffer, it just happens to be in a particular known > state for this particular flip. > > If GBM doesn’t want to optimize its power usage when(if) it knows the buffer > is uncompressed, then it doesn’t have to set the property at all.
GBM cannot set the property, because GBM is not the element in charge of presenting the buffers. The property-based design precludes optimal use of current open-source userspace. The flipside here is a minor inconvenience (having to create multiple framebuffers) to closed userspace; last time this came up, when it was asked if this was actually a serious memory concern or not, there was no response. Cheers, Daniel > Thanks > Gary > > > > > -----Original Message----- > From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] > Sent: Monday, January 25, 2016 5:39 PM > To: Daniel Stone <dan...@fooishbar.org>; Daniel Vetter <dan...@ffwll.ch> > Cc: intel-gfx@lists.freedesktop.org; Thierry Reding > <thierry.red...@avionic-desi.gn.de>; Smith, Gary K <gary.k.sm...@intel.com> > Subject: Re: [Intel-gfx] [RFC] drm/i915: Render decompression support for > Gen9 and above > > 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 Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
