Chad Versace <chad.vers...@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.pohjolai...@intel.com> wrote:
>>> On Tue, May 28, 2013 at 01:33:18PM -0700, Eric Anholt wrote:
>>>> Topi Pohjolainen <topi.pohjolai...@intel.com> writes:
>>>>
>>>>> Signed-off-by: Topi Pohjolainen <topi.pohjolai...@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.
pgp7vHWRQ4nrr.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
