[Mesa-dev] [PATCH 2/6] mesa intel driver:
Ian Romanick
idr at freedesktop.org
Tue Jun 5 22:12:46 CEST 2012
On 06/05/2012 12:55 AM, Zhao, Halley wrote:
> Thanks Paul, Thanks Ian as well for the comments on it.
> I will update internal_format to GL_YCBCR_MESA.
> (I didn't notice glext.h before, but gl2.h only)
>
> As to the error in intel_image_target_texture_2d(), it isn't caused by wrong internal format, but hw limitation since we don't support packed YUV as texture.
Yes and no. The hardware natively supports the 422 subsampling, but
GEN4 and later do not support the color space conversion. For
GL_YCBCR_MESA textures extra instructions are added after the texture
lookup to perform the conversion.
>> -----Original Message-----
>> From: Pauli Nieminen [mailto:pauli.nieminen at linux.intel.com]
>> Sent: Monday, June 04, 2012 9:11 PM
>> To: Zhao, Halley
>> Cc: Eric Anholt; mesa-dev at lists.freedesktop.org; Barnes, Jesse
>> Subject: Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
>>
>> On Mon, Jun 04, 2012 at 10:00:47AM +0000, Zhao, Halley wrote:
>>> Thanks for careful review.
>>>
>>> 1. My mistake for the XXXXs, we can remove it.
>>> There is MESA_FORMAT_YCBCR_REV for UYVY, so
>> MESA_FORMAT_YCBCR is exactly for YUYV format.
>>> GL_LUMINANCE should be ok since YUYV is an luminance format.
>>
>> internal_format should be GL_YCBCR_MESA that is supposed to be working
>> texture format with GL.
>>
>>> 2. as to intel_image_target_texture_2d(), an error is added for YUYV region.
>>> Updated patch see below.
>>>
>>
>> Could it be because of wrong internal format?
>>
>>> 3. A test case is added to demonstrate the usage:
>> http://lists.freedesktop.org/archives/mesa-dev/2012-June/022487.html
>>> As to the case when hw overlay is not available, it is considered in
>> following way:
>>> 3.1) when client connect to wayland-server, it gets which formats are
>> supported from server in drm_handle_format(). Client sends YUYV buffer to
>> server only when the server supports it.
>>> Client can convert a YUYV/NV12 buffer to XRGB format through libva:
>> http://lists.freedesktop.org/archives/libva/2012-May/000845.html
>> (YUYV<-->NV12/YV12 are supported)
>>> 3.2) if Weston want to support YUYV internally, it can depend on libva's
>> color conversion or some special shader to do it.
>>>
>>> From 5356270a25a300bbe7e0d36a79b031d2fb108a88 Mon Sep 17 00:00:00
>> 2001
>>> From: Zhao halley<halley.zhao at intel.com>
>>> Date: Fri, 25 May 2012 11:36:48 +0800
>>> Subject: [PATCH 2/7] mesa intel driver:
>>>
>>> add YUYV format for dri image
>>> YUYV image doesn't use for texture
>>> ---
>>> src/mesa/drivers/dri/intel/intel_screen.c | 5 +++++
>>> src/mesa/drivers/dri/intel/intel_tex_image.c | 6 ++++++
>>> 2 files changed, 11 insertions(+), 0 deletions(-) mode change 100644
>>> => 100755 src/mesa/drivers/dri/intel/intel_screen.c
>>> mode change 100644 => 100755
>>> src/mesa/drivers/dri/intel/intel_tex_image.c
>>>
>>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>>> b/src/mesa/drivers/dri/intel/intel_screen.c
>>> old mode 100644
>>> new mode 100755
>>> index 458178f..b8d44ba
>>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>>> @@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen
>> *screen,
>>> image->internal_format = GL_RGB;
>>> image->data_type = GL_UNSIGNED_BYTE;
>>> break;
>>> + case __DRI_IMAGE_FORMAT_YUYV:
>>> + image->format = MESA_FORMAT_YCBCR;
>>> + image->internal_format = GL_LUMINANCE;
>>> + image->data_type = GL_UNSIGNED_BYTE;
>>> + break;
>>> default:
>>> free(image);
>>> return NULL;
>>> diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
>>> b/src/mesa/drivers/dri/intel/intel_tex_image.c
>>> old mode 100644
>>> new mode 100755
>>> index 094d3cd..8b94cb1
>>> --- a/src/mesa/drivers/dri/intel/intel_tex_image.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
>>> @@ -388,6 +388,12 @@ intel_image_target_texture_2d(struct gl_context
>> *ctx, GLenum target,
>>> if (image == NULL)
>>> return;
>>>
>>> + if (image->format == MESA_FORMAT_YCBCR) {
>>> + _mesa_error(&intel->ctx,
>>> + GL_INVALID_OPERATION, "glEGLImageTargetTexture2DOES,
>> attach YUYV region to texture is not supported");
>>> + return;
>>> + }
>>> +
>>> intel_set_texture_image_region(ctx, texImage, image->region,
>>> target, image->internal_format, image->format); }
>>> --
>>> 1.7.5.4
>>>
>>>> -----Original Message-----
>>>> From: Eric Anholt [mailto:eric at anholt.net]
>>>> Sent: Saturday, June 02, 2012 5:33 AM
>>>> To: Zhao, Halley; mesa-dev at lists.freedesktop.org
>>>> Cc: Barnes, Jesse; Zhao, Halley
>>>> Subject: Re: [PATCH 2/6] mesa intel driver:
>>>>
>>>> On Thu, 31 May 2012 17:23:59 +0800, Zhao halley
>>>> <halley.zhao at intel.com>
>>>> wrote:
>>>>> add YUYV format for dri image
>>>>> YUYV image doesn't use for texture
>>>>> ---
>>>>> src/mesa/drivers/dri/intel/intel_screen.c | 5 +++++
>>>>> src/mesa/drivers/dri/intel/intel_tex_image.c | 3 +++
>>>>> 2 files changed, 8 insertions(+), 0 deletions(-) mode change
>>>>> 100644 => 100755 src/mesa/drivers/dri/intel/intel_screen.c
>>>>> mode change 100644 => 100755
>>>>> src/mesa/drivers/dri/intel/intel_tex_image.c
>>>>>
>>>>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> b/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> old mode 100644
>>>>> new mode 100755
>>>>> index 458178f..5ff2e49
>>>>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> @@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen
>>>> *screen,
>>>>> image->internal_format = GL_RGB;
>>>>> image->data_type = GL_UNSIGNED_BYTE;
>>>>> break;
>>>>> + case __DRI_IMAGE_FORMAT_YUYV:
>>>>> + image->format = MESA_FORMAT_YCBCR; // XXXX no
>> detailed
>>>> YUV format in mesa yet
>>>>> + image->internal_format = GL_LUMINANCE; // XXXX no detailed
>>>> YUV format in gles2 yet
>>>>> + image->data_type = GL_UNSIGNED_BYTE;
>>>>> + break;
>>>>> default:
>>>>> free(image);
>>>>> return NULL;
>>>>
>>>> I don't like seeing these XXXs added that suggest that this commit isn't
>> ready.
>>>>
>>>>> diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
>>>>> b/src/mesa/drivers/dri/intel/intel_tex_image.c old mode 100644 new
>>>>> mode 100755 index 094d3cd..e5c3bdc ---
>>>>> a/src/mesa/drivers/dri/intel/intel_tex_image.c +++
>>>>> b/src/mesa/drivers/dri/intel/intel_tex_image.c @@ -388,6 +388,9 @@
>>>>> intel_image_target_texture_2d(struct gl_context *ctx, GLenum
>>>>> target, if (image == NULL) return;
>>>>>
>>>>> + if (image->format == MESA_FORMAT_YCBCR)
>>>>> + return;
>>>>> +
>>>>> intel_set_texture_image_region(ctx, texImage, image->region,
>>>>> target, image->internal_format,
>> image->format); }
>>>>
>>>> So, you don't actually attach the region to the texture? If you
>>>> don't support rendering from the format as a texture, why is this not
>> throwing an error?
>>>>
>>>> I don't understand yet how this series really gets used. As far as
>>>> I understand, wayland likes to use the image directly as an overlay
>>>> if possible, but sometimes it can't. At that point, it needs to be
>>>> able to do GL rendering using that image as a source, right? So,
>>>> how is the compositor supposed to handle the format in that case, if it can't
>> texture from it?
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list