[Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Lucas Stach]

Hi Michel,

Am Montag, den 15.04.2019, 12:04 +0200 schrieb Michel Dänzer:
> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
> > Unconditionally requesting both bindings can lead to premature
> > failure to create a valid image.
> > 
> > > > Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
> > ---
> >  src/gallium/state_trackers/dri/dri2.c | 13 +++++++++++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c
> > index efb43c0d7973..510b7f8d04a7 100644
> > --- a/src/gallium/state_trackers/dri/dri2.c
> > +++ b/src/gallium/state_trackers/dri/dri2.c
> > @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
> >  {
> >     const struct dri2_format_mapping *map = dri2_get_mapping_by_format(format);
> >     struct dri_screen *screen = dri_screen(_screen);
> > +   struct pipe_screen *pscreen = screen->base.screen;
> >     __DRIimage *img;
> >     struct pipe_resource templ;
> > -   unsigned tex_usage;
> > +   unsigned tex_usage = 0;
> >  
> >     if (!map)
> >        return NULL;
> >  
> > -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> > +   if (pscreen->is_format_supported(pscreen, map->pipe_format, screen->target,
> > +                                    0, 0, PIPE_BIND_RENDER_TARGET))
> > +      tex_usage |= PIPE_BIND_RENDER_TARGET;
> > +   if (pscreen->is_format_supported(pscreen, map->pipe_format, screen->target,
> > +                                    0, 0, PIPE_BIND_SAMPLER_VIEW))
> > +      tex_usage |= PIPE_BIND_SAMPLER_VIEW;
> > +
> > +   if (!tex_usage)
> > +      return NULL;
> >  
> >     if (use & __DRI_IMAGE_USE_SCANOUT)
> >        tex_usage |= PIPE_BIND_SCANOUT;
> > 
> 
> Since there are no __DRI_IMAGE_USE_* flags for rendering & sampling, the
> expectation does seem to be that both are supported. What happens if an
> image is created for a format which only supports sampling, then the
> caller attempts rendering to it?

While I agree that the missing flags is a problem, I don't think the
expectation that createImage must create something which is both render
and sampler compatible holds anymore.

kmscube for example does create a R8 buffer via gbm_bo_create that is
only used to create a texture. As this is going through the createImage
path it will fail on drivers that only support texturing from R8, like
etnaviv, which is definitely not what the application expects. There is
quite a bit of API abuse involved in this example, but I'm not sure if
the right way to deal with this is break the application.

Also are other ways to come up with a DRI image that is only sampler
compatible, like the create_image_from_fd paths. While we may be able
to fix the gbm case, as we have the flags available there, we can't do
this as easily for the import paths, as there are no usage flags
available at the EGL API level.

Regards,
Lucas