[Intel-gfx] [RFC] drm/i915: Render decompression support for Gen9 and above

[Jesse Barnes]

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