I thought we had concluded previously that this change was acceptable, which is why I'm surprised that it's come up yet again. The performance cost of creating two fb objects per buffer is irrelevant - it will be a one shot hit on buffer creation, and from that point forward it's just selecting which of the two fb's to use at any point in time. Given that I'm told that the memory cost kernel side per fb is small, the number isn't a big deal either. Hence, I'm not sure why you were expecting a performance analysis. The two things I object to are: 1) Having to tell the kernel that there is no aux buffer on an allocation that actually has an aux buffer in order to indicate that at this point in time the buffer is uncompressed. This is completely non intuitive from a caller perspective - especially as it's called an aux buffer, not a compression buffer. 2) Having to use a fb object to manage dynamic state. The fb for a particular buffer will change over the course of a frame. Any debug for a frame at entry to the HWC will have a different fb to the debug at frame exit which makes it hard to track. Thanks Gary -----Original Message----- From: Daniel Stone [mailto:daniel@xxxxxxxxxxxxx] Sent: Tuesday, March 22, 2016 1:37 PM To: Smith, Gary K <gary.k.smith@xxxxxxxxx> Cc: Kannan, Vandana <vandana.kannan@xxxxxxxxx>; intel-gfx <intel-gfx@xxxxxxxxxxxxxxxxxxxxx>; Daniel Vetter <daniel@xxxxxxxx> Subject: Re: [PATCH 2/2] drm/i915: Render decompression support for Gen9 and above On 22 March 2016 at 13:30, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > Exactly the same as the last time we discussed it I should add that I understand your previous objection that creating framebuffers on the fly is not performant enough, and you object to the effort of managing 100 rather than 50 framebuffers upfront (though honestly, if you get to 50 framebuffers you're already having to do some clever setup/management anyway). But in the last thread, Daniel Vetter asked for some performance numbers to bear out your objection that framebuffer creation is too costly, leading to getting it fixed if this is in fact the case (since other userspace relies on it being fast), but this performance analysis never arrived. I'd still be interested in seeing that. Cheers, Daniel --------------------------------------------------------------------- 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
