-----Original Message-----
From: Pauli Nieminen [mailto:pauli.niemi...@linux.intel.com]
Sent: Monday, June 04, 2012 9:11 PM
To: Zhao, Halley
Cc: Eric Anholt; mesa-dev@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.z...@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:e...@anholt.net]
Sent: Saturday, June 02, 2012 5:33 AM
To: Zhao, Halley; mesa-dev@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.z...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
