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

[Michel Dänzer]

On 2019-04-15 12:57 p.m., Lucas Stach wrote:
> 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.

I don't mean "expectation" as in that of any particular application. I
mean that because the caller cannot yet express that it only wants to
sample from / render to the image, dri2_create_image_common must assume
that the image will be used for both.


> 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.

kmscube could never work using existing API on hardware which can't
render to R8, so "break" doesn't really fit.

Conversely, is it possible for the caller to find out that the image
can't be used for rendering, so that e.g. an attempt to use it for a
GL(ES) FBO would be correctly marked as incomplete? If not, this change
may break other applications which worked before, e.g. glamor.


> 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.

One possibility might be adding new "sample only" flags / API where needed.


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer