On Wed, Sep 09, 2015 at 10:04:23AM -0700, Jesse Barnes wrote: > [Adding Rob & Thierry] > > On 09/09/2015 09:36 AM, Smith, Gary K wrote: > > I don't understand why this is an issue. Surely the fb is to describe > > static state about the buffer, not dynamic state. The fb should be > > created with the compressed modifier. The compressed property is just > > a hint to the kernel that the buffer has been completely resolved, > > hence currently it can be treated as an uncompressed fb (and the aux > > buffer can be ignored). This is dynamic state that may well change > > very regularly over the lifetime of the buffer. There's fb modifier at all in this patch set, not just a static modifier to be able to check the compression data fits plus a "ignore compression" runtime knob. > > It's still a compressed fb, it contains a aux buffer and had to be > > created with the compressed fb modifier. However, once the userspace > > has fully resolved the buffer, the aux buffer can be ignored and the > > compressed fb can be used in any situation where an uncompressed fb > > would normally be required. This is dynamic state that may well change > > very regularly over the lifetime of the buffer. > > > > I could allocate two fbs always, and use the appropriate one. We > > already do this in order to indicate whether a RGBA buffer currently > > needs to be considered as opaque (RGBX) or blended. Experience has > > shown that it makes it very complex to debug when the fb keeps on > > changing its value. However, because we now have 4 different states > > (Blended/Opaque and Compressed or Resolved), we will now end up with > > up to 4 fbs per buffer. > > > > 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? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
