[Mesa-dev] [v6 2/9] intel: do not create renderbuffers out of planar images

[Eric Anholt]

Chad Versace <chad.versace at linux.intel.com> writes:

> On 05/30/2013 01:20 AM, Daniel Vetter wrote:
>> On Thu, May 30, 2013 at 9:49 AM, Pohjolainen, Topi
>> <topi.pohjolainen at intel.com> wrote:
>>> On Tue, May 28, 2013 at 01:33:18PM -0700, Eric Anholt wrote:
>>>> Topi Pohjolainen <topi.pohjolainen at intel.com> writes:
>>>>
>>>>> Signed-off-by: Topi Pohjolainen <topi.pohjolainen at intel.com>
>>>>> ---
>>>>>   src/mesa/drivers/dri/intel/intel_fbo.c | 4 ++++
>>>>>   1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c
>>>>> index 69f8629..7ccbaa8 100644
>>>>> --- a/src/mesa/drivers/dri/intel/intel_fbo.c
>>>>> +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
>>>>> @@ -280,6 +280,10 @@ intel_image_target_renderbuffer_storage(struct gl_context *ctx,
>>>>>      if (image == NULL)
>>>>>         return;
>>>>>
>>>>> +   /* Planar buffers are not supported as render targets. */
>>>>> +   if (image->planar_format && image->planar_format->nplanes > 1)
>>>>> +      return;
>>>>> +
>>>>>      /* __DRIimage is opaque to the core so it has to be checked here */
>>>>>      switch (image->format) {
>>>>>      case MESA_FORMAT_RGBA8888_REV:
>>>>
>>>> OK, this answers one question I had about what our support was going to
>>>> be.  But what about glEGLImageTargetTexture2DOES()?
>>>>
>>>> Are we only going to support planar textures with image_external?  My
>>>> thought is "yes".  How about on HSW with the YUV sampler support?  Are
>>>> we going to relayout the data in the incoming fds to a copy that can
>>>> support sampling from them, or are we going to reject incoming fds that
>>>> don't fit the required layout?  And if we decide to reject anything, are
>>>> we going to reject it at the or the dmabuf_import stage or the
>>>> image_external stage?
>>>
>>> I was also thinking that planar would be supported only by image_external, and I
>>> hadn't even thought about HSW yet.
>
> I think the same formats supported in image_external should also be supported
> by dma_buf_import. This would allow us to write Piglit tests for any supported
> image_external format.
>
> If the set of supported dma_buf_import formats is a subset of the image_external
> formats, then how do you propose we write tests (Piglit or non-Piglit) for the
> extra image_external formats?
>
> To avoid any implementation weirdness, though, I think we should prevent
> creation of 2D texture targets (GL_TEXTURE_2D) from dma_buf images, and
> permit only creation of external textures (GL_TEXTURE_EXTERNAL).

External unfortunately requires that you rewrite your shaders, which is
ridiculous, but I don't see any way to make GL_OES_EGL_image really
useful what with:

   "As a result of this referencing operation, all of the pixel
    data in the <buffer> used as the EGLImage source resource (i.e., the
    <buffer> parameter passed to the CreateImageOES command that returned
    <image>) will become undefined."

So, while I *hate* the external spec, I don't really see much point in
supporting dmabufs with GL_OES_EGL_image any more, given that it allows
the driver to just throw out the data that was in the image before.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130603/e27df8b4/attachment.pgp>