[Intel-gfx] [PATCH igt 2/2] kms_frontbuffer_tracking: standardize the used FB sizes
daniel at ffwll.ch
Thu Dec 10 01:04:12 PST 2015
On Mon, Dec 07, 2015 at 02:04:51PM +0000, Zanoni, Paulo R wrote:
> Em Sex, 2015-12-04 às 16:28 +0100, Daniel Vetter escreveu:
> > On Wed, Dec 02, 2015 at 10:47:01AM -0200, Paulo Zanoni wrote:
> > > We want to make sure that both tiled and untiled buffers have the
> > > same
> > > size for the same width/height/format. This will allow better
> > > control
> > > over the failure paths exercised by our tests: when we try to flip
> > > from tiled to untiled, we'll be sure that we won't execute the
> > > error
> > > path that checks for buffer sizes.
> > >
> > > v2: Use the new igt_calc_fb_size() instead of implementing our own
> > > size calculation (Daniel).
> > >
> > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> > > ---
> > > tests/kms_frontbuffer_tracking.c | 51 ++++++++++++++++++++++++++
> > > --------------
> > > 1 file changed, 34 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/tests/kms_frontbuffer_tracking.c
> > > b/tests/kms_frontbuffer_tracking.c
> > > index 81703ec..3db95d2 100644
> > > --- a/tests/kms_frontbuffer_tracking.c
> > > +++ b/tests/kms_frontbuffer_tracking.c
> > > @@ -479,10 +479,28 @@ static bool init_modeset_cached_params(void)
> > > return true;
> > > }
> > >
> > > +static int format_get_bpp(uint32_t format)
> > Ah, missed one: igt_drm_format_to_bpp please, and if it doesn't cover
> > them all we
> > need to fix that asap.
> I'm not sure if this is a good idea. Not every DRM format has a
> matching cairo format, and it seems the whole igt_fb code is built
> based on this assumption. On a quick look, it really seems that both
> kms_render.c and kms_atomic.c will break if I add ARGB2101010 with a
> matching CAIRO_INVALID (since they call igt_get_all_formats() and use
> I know, you can question the use of ARGB2101010 by
> kms_frontbuffer_tracking (we don't use it anymore, the format is there
> as an artifact of an older attempt when I initially added support for
> multiple formats), but that doesn't solve the bigger problem that we
> can't easily expand igt_drm_format_to_bpp().
Hm, if you don't need it maybe push these patches without the new format
and use the existing library function for now?
> If you still insist, the big plan should be to make sure that both
> igt_fb and the libs can properly handle the cases where a DRM format
> doesn't have a matching cairo format, but I don't want to block my
> current tasks on this. So I'd vote to merge my patches as-is for now.
> What do you think?
igt_get_all_cairo_formats which skips on CAIRO_INVALID, roll it out in
existing users, extend what we have here?
Shouldn't be too much work, and we need this kind of stuff anyway.
Software Engineer, Intel Corporation
More information about the Intel-gfx