Re: [Intel-gfx] HDMI monitor hot remove handling

2011-11-13 Thread Zhenyu Wang 
On 2011.11.11 16:50:41 +0800, Wu Fengguang wrote:
I still think you should do those in hot_plug(), to call detect() for 
current
status, write eld and set specific audio enable/disable bit for all 
audio stuff.
Just my sense, you may send RFC patch for other's comment. 
 
  yeah, mode_set() will only be in normal mode setting path and taking current
  monitor's audio capability, but not on hot removal path. And if connector's 
  DPMS off,
  does audio need to care? I think no, as user might still like to hear 
  sound, right? ;)
  
  So looks currently nobody cares for hot removal, you need to set that by
  yourself somewhere.
 
 Zhenyu, according to your comments, here is the patch, tested OK on
 HDMI :)  DP not tested yet.

Well, I don't think I suggested a new hook for hot removal. ;)

You know that hot_plug() hook is intel encoder thing, which is the place
I think you can do audio config stuff. 

 
 This notifies the audio driver of the HDMI/DP monitor hot removal
 event.
 
 - clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
 - clear ELD Valid bit
 
 Signed-off-by: Wu Fengguang fengguang...@intel.com
 ---
  drivers/gpu/drm/drm_crtc_helper.c |4 
  drivers/gpu/drm/i915/intel_dp.c   |   19 +++
  drivers/gpu/drm/i915/intel_drv.h  |4 
  drivers/gpu/drm/i915/intel_hdmi.c |   17 +
  include/drm/drm_crtc.h|1 +
  5 files changed, 45 insertions(+)
 
 --- linux.orig/drivers/gpu/drm/i915/intel_dp.c2011-11-11 
 16:42:58.0 +0800
 +++ linux/drivers/gpu/drm/i915/intel_dp.c 2011-11-11 16:42:59.0 
 +0800
 @@ -1984,6 +1984,24 @@ intel_dp_detect(struct drm_connector *co
   return connector_status_connected;
  }
  
 +static void intel_dp_hot_remove(struct drm_connector *connector)
 +{
 + struct intel_dp *intel_dp = intel_attached_dp(connector);
 + struct drm_device *dev = intel_dp-base.base.dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct drm_crtc *crtc = intel_dp-base.base.crtc;
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 +
 + intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
 + I915_WRITE(intel_dp-output_reg, intel_dp-DP);
 + POSTING_READ(intel_dp-output_reg);
 + intel_wait_for_vblank(dev, intel_crtc-pipe);
 +
 + connector-eld[0] = 0;
 + if (dev_priv-display.write_eld)
 + dev_priv-display.write_eld(connector, crtc);
 +}
 +
  static int intel_dp_get_modes(struct drm_connector *connector)
  {
   struct intel_dp *intel_dp = intel_attached_dp(connector);
 @@ -2143,6 +2161,7 @@ static const struct drm_connector_funcs 
   .detect = intel_dp_detect,
   .fill_modes = drm_helper_probe_single_connector_modes,
   .set_property = intel_dp_set_property,
 + .hot_remove = intel_dp_hot_remove,
   .destroy = intel_dp_destroy,
  };
  
 --- linux.orig/drivers/gpu/drm/i915/intel_drv.h   2011-11-11 
 16:42:58.0 +0800
 +++ linux/drivers/gpu/drm/i915/intel_drv.h2011-11-11 16:42:59.0 
 +0800
 @@ -382,6 +382,10 @@ extern void intel_fb_restore_mode(struct
  extern void intel_init_clock_gating(struct drm_device *dev);
  extern void intel_write_eld(struct drm_encoder *encoder,
   struct drm_display_mode *mode);
 +extern void intel_hotplug_status(struct drm_device *dev,
 +   struct drm_connector *connector,
 +   struct drm_crtc *crtc,
 +   enum drm_connector_status status);
  extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
  
  #endif /* __INTEL_DRV_H__ */
 --- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c  2011-11-11 
 16:42:58.0 +0800
 +++ linux/drivers/gpu/drm/i915/intel_hdmi.c   2011-11-11 16:42:59.0 
 +0800
 @@ -352,6 +352,22 @@ intel_hdmi_detect(struct drm_connector *
   return status;
  }
  
 +static void intel_hdmi_hot_remove(struct drm_connector *connector)
 +{
 + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 + struct drm_i915_private *dev_priv = connector-dev-dev_private;
 + u32 temp;
 +
 + temp = I915_READ(intel_hdmi-sdvox_reg);
 + I915_WRITE(intel_hdmi-sdvox_reg, temp  ~SDVO_AUDIO_ENABLE);
 + POSTING_READ(intel_hdmi-sdvox_reg);
 +
 + connector-eld[0] = 0;
 + if (dev_priv-display.write_eld)
 + dev_priv-display.write_eld(connector,
 + intel_hdmi-base.base.crtc);
 +}
 +
  static int intel_hdmi_get_modes(struct drm_connector *connector)
  {
   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 @@ -461,6 +477,7 @@ static const struct drm_connector_funcs 
   .detect = intel_hdmi_detect,
   .fill_modes = drm_helper_probe_single_connector_modes,
   .set_property = intel_hdmi_set_property,
 + .hot_remove = intel_hdmi_hot_remove,
   .destroy = intel_hdmi_destroy,
  };
  
 --- linux.orig/drivers/gpu/drm/drm_crtc_helper.c  2011-11-11

Re: [Intel-gfx] HDMI monitor hot remove handling

2011-11-13 Thread Wu Fengguang 
On Mon, Nov 14, 2011 at 10:05:05AM +0800, Zhenyu Wang wrote:
 On 2011.11.11 16:50:41 +0800, Wu Fengguang wrote:
 I still think you should do those in hot_plug(), to call detect() for 
 current
 status, write eld and set specific audio enable/disable bit for all 
 audio stuff.
 Just my sense, you may send RFC patch for other's comment. 
  
   yeah, mode_set() will only be in normal mode setting path and taking 
   current
   monitor's audio capability, but not on hot removal path. And if 
   connector's DPMS off,
   does audio need to care? I think no, as user might still like to hear 
   sound, right? ;)
   
   So looks currently nobody cares for hot removal, you need to set that by
   yourself somewhere.
  
  Zhenyu, according to your comments, here is the patch, tested OK on
  HDMI :)  DP not tested yet.
 
 Well, I don't think I suggested a new hook for hot removal. ;)

Yes, sorry.

 You know that hot_plug() hook is intel encoder thing, which is the place
 I think you can do audio config stuff. 

The problem is, -hot_plug() is called at the very beginning, before
-detect() is called. If doing the hot remove notifications in
-hot_plug(), the patch will add an _extra_ loop to call into
-detect().

Why not insert the functionalities somewhere after -detect() is
called and we already know it's a hot removal event?  That avoids
adding duplicate -detect() calls.

Thanks,
Fengguang

  
  This notifies the audio driver of the HDMI/DP monitor hot removal
  event.
  
  - clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
  - clear ELD Valid bit
  
  Signed-off-by: Wu Fengguang fengguang...@intel.com
  ---
   drivers/gpu/drm/drm_crtc_helper.c |4 
   drivers/gpu/drm/i915/intel_dp.c   |   19 +++
   drivers/gpu/drm/i915/intel_drv.h  |4 
   drivers/gpu/drm/i915/intel_hdmi.c |   17 +
   include/drm/drm_crtc.h|1 +
   5 files changed, 45 insertions(+)
  
  --- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-11 
  16:42:58.0 +0800
  +++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-11 16:42:59.0 
  +0800
  @@ -1984,6 +1984,24 @@ intel_dp_detect(struct drm_connector *co
  return connector_status_connected;
   }
   
  +static void intel_dp_hot_remove(struct drm_connector *connector)
  +{
  +   struct intel_dp *intel_dp = intel_attached_dp(connector);
  +   struct drm_device *dev = intel_dp-base.base.dev;
  +   struct drm_i915_private *dev_priv = dev-dev_private;
  +   struct drm_crtc *crtc = intel_dp-base.base.crtc;
  +   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
  +
  +   intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
  +   I915_WRITE(intel_dp-output_reg, intel_dp-DP);
  +   POSTING_READ(intel_dp-output_reg);
  +   intel_wait_for_vblank(dev, intel_crtc-pipe);
  +
  +   connector-eld[0] = 0;
  +   if (dev_priv-display.write_eld)
  +   dev_priv-display.write_eld(connector, crtc);
  +}
  +
   static int intel_dp_get_modes(struct drm_connector *connector)
   {
  struct intel_dp *intel_dp = intel_attached_dp(connector);
  @@ -2143,6 +2161,7 @@ static const struct drm_connector_funcs 
  .detect = intel_dp_detect,
  .fill_modes = drm_helper_probe_single_connector_modes,
  .set_property = intel_dp_set_property,
  +   .hot_remove = intel_dp_hot_remove,
  .destroy = intel_dp_destroy,
   };
   
  --- linux.orig/drivers/gpu/drm/i915/intel_drv.h 2011-11-11 
  16:42:58.0 +0800
  +++ linux/drivers/gpu/drm/i915/intel_drv.h  2011-11-11 16:42:59.0 
  +0800
  @@ -382,6 +382,10 @@ extern void intel_fb_restore_mode(struct
   extern void intel_init_clock_gating(struct drm_device *dev);
   extern void intel_write_eld(struct drm_encoder *encoder,
  struct drm_display_mode *mode);
  +extern void intel_hotplug_status(struct drm_device *dev,
  + struct drm_connector *connector,
  + struct drm_crtc *crtc,
  + enum drm_connector_status status);
   extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
   
   #endif /* __INTEL_DRV_H__ */
  --- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-11-11 
  16:42:58.0 +0800
  +++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2011-11-11 16:42:59.0 
  +0800
  @@ -352,6 +352,22 @@ intel_hdmi_detect(struct drm_connector *
  return status;
   }
   
  +static void intel_hdmi_hot_remove(struct drm_connector *connector)
  +{
  +   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
  +   struct drm_i915_private *dev_priv = connector-dev-dev_private;
  +   u32 temp;
  +
  +   temp = I915_READ(intel_hdmi-sdvox_reg);
  +   I915_WRITE(intel_hdmi-sdvox_reg, temp  ~SDVO_AUDIO_ENABLE);
  +   POSTING_READ(intel_hdmi-sdvox_reg);
  +
  +   connector-eld[0] = 0;
  +   if (dev_priv-display.write_eld)
  +   dev_priv-display.write_eld(connector,
  +   intel_hdmi-base.base.crtc);
  +}
  +
   static int

Re: [Intel-gfx] [PATCH 3/3] glamor: Route fillspans and polyfillrects to glamor.

2011-11-13 Thread Zhigang Gong 
 -Original Message-
 From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
 Sent: Friday, November 11, 2011 9:55 PM
 To: Zhigang Gong; intel-gfx@lists.freedesktop.org
 Subject: RE: [Intel-gfx] [PATCH 3/3] glamor: Route fillspans and
polyfillrects
 to glamor.
 
 On Fri, 11 Nov 2011 18:48:57 +0800, Zhigang Gong
 zhigang.g...@linux.intel.com wrote:
   -Original Message-
   From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
   Sent: Friday, November 11, 2011 5:08 PM
   To: Zhigang Gong; intel-gfx@lists.freedesktop.org
   Subject: Re: [Intel-gfx] [PATCH 3/3] glamor: Route fillspans and
  polyfillrects
   to glamor.
  
   On Fri, 11 Nov 2011 16:31:21 +0800, Zhigang Gong
   zhigang.g...@linux.intel.com wrote:
If GLAMOR is enabled, we route UXA's fillspans and polyfillrects
to glamor by default. And if glamor fail to accelerate it, UXA
continue to handle it.
  
   How is serialisation handled between the UXA and glamor acceleration
   routines? Don't you need to flush the UXA batch (if the pixmap is
   active) before handing over to glamor and similarly flush the glamor
   pixmap after failure?
  Thanks for pointing this issue out. This is something I want to be
  discussed here.
 
  There are three types of access to the pixmap:
  1. UXA batch command buffer.
  2. Glamor through OpenGL
  3. CPU access mapped BO buffer.
 
  My understanding is that the leading two types has the queue
 mechanism
  and need to be handled carefully. In general, we can treat glamor 's
  access as another batch buffer. Then in the place where current intel
  driver need to flush UXA batch buffer, we also need to flush the GL
  operations there. Right?
 
  And besides above places we need to flush glamor, we also need to
  flush UXA batch buffer before call into glamor and also need to flush
  glamor after the glamor rendering function really touch the pixmap.
 
 Right, we want to consider it as another form of pixmap migration, just
 instead of between different regions of memory we are migrating
 between different queues. We could envision using fences to coordinate
 rendering between the different batches, but that is likely to be overkill
 and not possible with most Intel hardware.

Understand, so we can't expect to solve this overhead problem that way. 
IMO, as eventually, glamor will take over all the rendering functions,
if glamor is enabled. This heavy flushing may be get eliminated then.  

Anyway, currently, I still need to work out another patch to handle all the 
needed flushing OPs. Will submit it to review soon.

- Zhigang

 -Chris
 
 --
 Chris Wilson, Intel Open Source Technology Centre

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.

2011-11-13 Thread Zhigang Gong 


 -Original Message-
 From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
 Sent: Friday, November 11, 2011 9:13 PM
 To: Zhigang Gong; intel-gfx@lists.freedesktop.org
 Subject: RE: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.
 
 On Fri, 11 Nov 2011 18:52:11 +0800, Zhigang Gong
 zhigang.g...@linux.intel.com wrote:
 
 
   -Original Message-
   From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
   Sent: Friday, November 11, 2011 5:12 PM
   To: Zhigang Gong; intel-gfx@lists.freedesktop.org
   Subject: Re: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.
  
   On Fri, 11 Nov 2011 16:31:20 +0800, Zhigang Gong
   zhigang.g...@linux.intel.com wrote:
@@ -965,6 +969,9 @@ void
   intel_uxa_block_handler(intel_screen_private *intel)
 * framebuffer until significantly later.
 */
intel_flush_rendering(intel);
+#ifdef GLAMOR
+   intel_glamor_block_handler(intel);
+#endif
 }
  
   I suspect this is the wrong way around as we are not flushing the
   render cache of glamor's rendering to the scanout until the next block
 handler.
  I don't understand here. Would you please explain more detail? Thanks.
 
 Whenever we render, the data ends up in the Render Cache and needs to
 be flushed out to memory before it is coherent with the CPU or in this
 case the Display Engine (i.e. scanout).
 
 intel_flush_rendering() does two tasks. The first is to submit any pending
 batch, and the second is to flush the Render Cache so that the
 modifications land on the scanout in a timely manner. It is probably best
if
 those two tasks were separated so that we do:
 
   intel_uxa_block_handler(intel); // flush the UXA batch
   intel_glamor_block_handler(intel); // flush the GL batch
   intel_flush_rendering(intel); // flush the RenderCache to scanout
 
 However, you can simply rearrange the code and achieve it with the
 existing functions:
 
   intel_glamor_block_handler(intel); // mark the front bo as dirty as
 needbe
   intel_flush_rendering(intel); // flush UXA batch along with RenderCache
Thanks for the explanation here. But I still don't think the original code
is wrong
regard to this cache flushing issue. Here is my analysis:
intel_glamor_block_handler calls to glFlush(), and glFlush is similar with
the 
intel_flush_rendering, it calls intel_flush to flush the batch buffers and
then
call intel_flush_frontbuffer to flush the frontbuffer which flushes the scan
out
buffer. So when the screen pixmap is accessed by glamor, and after we call
intel_glamor_block_handler, the Display Engine should see the correct data

Right?

- Zhigang

 
 -Chris
 
 --
 Chris Wilson, Intel Open Source Technology Centre

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Glamor update

2011-11-13 Thread Zhigang Gong 
 -Original Message-
 From: Jamey Sharp [mailto:ja...@minilop.net]
 Sent: Saturday, November 12, 2011 5:47 AM
 To: Zhigang Gong
 Cc: xorg-de...@lists.x.org; intel-gfx@lists.freedesktop.org
 Subject: Re: Glamor update
 
 Hello!
 
 On Fri, Nov 11, 2011 at 04:42:32PM +0800, Zhigang Gong wrote:
  During the last discussion about glamor’s plan in this list, we got a
  conclusion that to extract glamor from xorg and build a separate
  glamor library to be used by any possible DDX driver. And Eric
  suggested I can incrementally merge glamor into Intel video driver.
  Now here is the update.
 
  The separate glamor library is at :
  git://people.freedesktop.org/~gongzg/glamor，it provides two
 interfaces:
 
  1.   glamor : Rendering library. All the rendering functions are
  implemented in this package.
 
  2.   glamor-egl : EGL support library. This package provides
 functions
  to create and initialize OpenGL/EGL context.
 
  There are a little bit more details to introduce glamor in the README file.
 
  The Intel video driver to merge glamor is at
  git://people.freedesktop.org/~gongzg/xf86-video-intel’s “glamor”
 branch.
 
  I just started the merging stage. Only finished 3 patches to enable
  glamor in UXA code path. Currently, only migrate fillspans and
  polyfillrect to glamor. Will continue to migrate the rest functions.
 
 I've looked over all the source in your glamor repo, and your patches to
 the Intel driver. This work looks very promising! I'm eager to see more
 progress.
 
 I don't speak for the Intel graphics team or anything, but I noticed a couple
 minor things you might clean up. In the glamor: turn on glamor.
 commit, there's a patch hunk that just adds an empty ifdef:
 
 -
 +#ifdef GLAMOR
 +#endif
Fixed.
 
 You might want to remove that. Also, the call to
 intel_glamor_create_textured_pixmap in intel_uxa_create_pixmap is
 inconsistently indented; it should just be tabs, looks like.
Fixed.
I will submit the new version patch again latter. Thanks for your carefully 
reviewing.

 
 Any chance you'll add some of the Xephyr/glamor functionality to
 xf86-video-nested, too? I think that should be easier to test and hack on.

Currently, we don't have enough bandwidth to do that. If anyone in the 
community want to do that, I'd be happy to provide help. 

 
 Jamey

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.

2011-11-13 Thread Zhigang Gong 
Thanks for the review. Fixed that empty #ifdef block, missed one line code
there to free glamor screen.

 

 

From: eugeni.dodo...@gmail.com [mailto:eugeni.dodo...@gmail.com] On Behalf
Of Eugeni Dodonov
Sent: Friday, November 11, 2011 8:59 PM
To: Zhigang Gong
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.

 

 

On Fri, Nov 11, 2011 at 06:31, Zhigang Gong zhigang.g...@linux.intel.com
wrote:

@@ -1109,7 +1127,8 @@ static void I830FreeScreen(int scrnIndex, int flags)
 {
   ScrnInfoPtr scrn = xf86Screens[scrnIndex];
   intel_screen_private *intel = intel_get_screen_private(scrn);
-
+#ifdef GLAMOR
+#endif





Empty #ifdef block?

-- 
Eugeni Dodonov http://eugeni.dodonov.net/ 


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/3] glamor: Initial commit to introduce glamor acceleration.

2011-11-13 Thread Zhigang Gong 
Added one configuration option --enable-glamor to control
whether use glamor. Added one new file intel_glamor.c to
wrap glamor egl API for intel driver's usage.
This commit doesn't really change the driver's control path.
It just adds necessary files for glamor and change some
configuration.

Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
 configure.ac   |   17 +++
 src/Makefile.am|5 ++
 src/intel_glamor.c |  130 
 src/intel_glamor.h |   45 ++
 4 files changed, 197 insertions(+), 0 deletions(-)
 create mode 100644 src/intel_glamor.c
 create mode 100644 src/intel_glamor.h

diff --git a/configure.ac b/configure.ac
index fccab56..dc01c46 100644
--- a/configure.ac
+++ b/configure.ac
@@ -126,6 +126,15 @@ AC_ARG_ENABLE(sna,
  [SNA=$enableval],
  [SNA=no])
 AM_CONDITIONAL(SNA, test x$SNA != xno)
+
+AC_ARG_ENABLE(glamor,
+ AS_HELP_STRING([--enable-glamor],
+[Enable glamor, a new GL-based acceleration 
[default=no]]),
+ [GLAMOR=$enableval],
+ [GLAMOR=no])
+
+AM_CONDITIONAL(GLAMOR, test x$GLAMOR != xno)
+
 AC_MSG_CHECKING([whether to include SNA support])
 
 required_xorg_xserver_version=1.6
@@ -137,6 +146,14 @@ if test x$SNA != xno; then
 fi
 AC_MSG_RESULT([$SNA])
 
+if test x$GLAMOR != xno; then
+   PKG_CHECK_MODULES(LIBGLAMOR, [glamor])
+   PKG_CHECK_MODULES(LIBGLAMOR_EGL, [glamor-egl])
+   AC_DEFINE(GLAMOR, 1, [Enable glamor acceleration])
+fi
+
+AC_MSG_CHECKING([whether to include GLAMOR support])
+AC_MSG_RESULT([$GLAMOR])
 
 AC_ARG_ENABLE(vmap,
  AS_HELP_STRING([--enable-vmap],
diff --git a/src/Makefile.am b/src/Makefile.am
index cd1bb36..1a29390 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -40,6 +40,10 @@ SUBDIRS += sna
 intel_drv_la_LIBADD += sna/libsna.la
 endif
 
+if GLAMOR
+GLAMOR_SOURCE = intel_glamor.c
+endif
+
 NULL:=#
 
 intel_drv_la_SOURCES = \
@@ -70,6 +74,7 @@ intel_drv_la_SOURCES = \
 i965_3d.c \
 i965_video.c \
 i965_render.c \
+$(GLAMOR_SOURCE) \
 $(NULL)
 
 if DRI
diff --git a/src/intel_glamor.c b/src/intel_glamor.c
new file mode 100644
index 000..cadfc71
--- /dev/null
+++ b/src/intel_glamor.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright © 2011 Intel Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy,
+ * modify, merge, publish, distribute, sublicense, and/or sell copies
+ * of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including
+ * the next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Zhigang Gong zhigang.g...@linux.intel.com
+ *
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
+#include unistd.h
+#include fcntl.h
+#include sys/ioctl.h
+#include errno.h
+#include xf86drm.h
+
+#define GLAMOR_FOR_XORG  1
+
+#include glamor.h
+#include intel.h
+#include intel_glamor.h
+
+Bool
+intel_glamor_create_screen_resources(ScreenPtr screen)
+{
+   ScrnInfoPtr scrn = xf86Screens[screen-myNum];
+   intel_screen_private *intel = intel_get_screen_private(scrn);
+
+   if (!glamor_glyphs_init(screen))
+   return FALSE;
+   if (!glamor_egl_create_textured_screen(screen,
+  intel-front_buffer-handle,
+  intel-front_pitch))
+   return FALSE;
+   return TRUE;
+}
+
+Bool
+intel_glamor_pre_init(ScrnInfoPtr scrn)
+{
+   intel_screen_private *intel;
+   intel = intel_get_screen_private(scrn);
+   return glamor_egl_init(scrn, intel-drmSubFD);
+}
+
+Bool
+intel_glamor_create_textured_pixmap(PixmapPtr pixmap)
+{
+   struct intel_pixmap *priv;
+   priv = intel_get_pixmap_private(pixmap);
+   return glamor_egl_create_textured_pixmap(pixmap, priv-bo-handle,
+priv-stride);
+}
+
+void
+intel_glamor_destroy_pixmap(PixmapPtr pixmap)
+{
+   glamor_egl_destroy_textured_pixmap(pixmap);
+}
+
+Bool

[Intel-gfx] [PATCH v2 2/3] glamor: turn on glamor.

2011-11-13 Thread Zhigang Gong 
Add glamor's initialization to the uxa's control path.
At preInit stage, it creates and initialize EGL display
context for glamor. At the screenInit stage, it initialize
glamor's internal data structures and shaders.

And this commit enables textured pixmap also. Each pixmap
which has a valid BO can get a cooresponding texture.

After this commit. It's ready to do rendering through
glamor's rendering functions.

Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
 src/intel_driver.c |   26 +-
 src/intel_uxa.c|   25 +++--
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/src/intel_driver.c b/src/intel_driver.c
index 24696da..63f83e7 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -75,6 +75,10 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
 #include i915_drm.h
 #include xf86drmMode.h
 
+#ifdef GLAMOR
+#include intel_glamor.h
+#endif
+
 /* *INDENT-OFF* */
 /*
  * Note: ColorKey is provided for compatibility with the i810 driver.
@@ -712,6 +716,20 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags)
return FALSE;
}
 
+#ifdef GLAMOR
+/* Load glamor module */
+if (!xf86LoadSubModule(scrn, glamor_egl)) {
+PreInitCleanup(scrn);
+return FALSE;
+}
+
+if (!intel_glamor_pre_init(scrn)) {
+   xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+  Failed to pre init glamor display.\n);
+   return FALSE;
+}
+#endif
+
/* Load the dri2 module if requested. */
if (intel-directRenderingType != DRI_DISABLED)
xf86LoadSubModule(scrn, dri2);
@@ -1109,7 +1127,9 @@ static void I830FreeScreen(int scrnIndex, int flags)
 {
ScrnInfoPtr scrn = xf86Screens[scrnIndex];
intel_screen_private *intel = intel_get_screen_private(scrn);
-
+#ifdef GLAMOR
+   intel_glamor_free_screen(scrnIndex, flags);
+#endif
if (intel) {
intel_mode_fini(intel);
intel_close_drm_master(intel);
@@ -1189,6 +1209,10 @@ static Bool I830CloseScreen(int scrnIndex, ScreenPtr 
screen)
 
DeleteCallback(FlushCallback, intel_flush_callback, scrn);
 
+#ifdef GLAMOR
+   intel_glamor_close_screen(screen);
+#endif
+
if (intel-uxa_driver) {
uxa_driver_fini(screen);
free(intel-uxa_driver);
diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index 8c6f754..3bbe531 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -40,6 +40,10 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #include string.h
 #include errno.h
 
+#ifdef GLAMOR
+#include intel_glamor.h
+#endif
+
 static const int I830CopyROP[16] = {
ROP_0,  /* GXclear */
ROP_DSa,/* GXand */
@@ -964,6 +968,9 @@ void intel_uxa_block_handler(intel_screen_private *intel)
 * and beyond rendering results may not hit the
 * framebuffer until significantly later.
 */
+#ifdef GLAMOR
+   intel_glamor_block_handler(intel);
+#endif
intel_flush_rendering(intel);
 }
 
@@ -1095,6 +1102,10 @@ intel_uxa_create_pixmap(ScreenPtr screen, int w, int h, 
int depth,
list_init(priv-batch);
list_init(priv-flush);
intel_set_pixmap_private(pixmap, priv);
+#ifdef GLAMOR
+   priv-pinned = 1;
+   intel_glamor_create_textured_pixmap(pixmap);
+#endif
}
 
return pixmap;
@@ -1102,8 +1113,12 @@ intel_uxa_create_pixmap(ScreenPtr screen, int w, int h, 
int depth,
 
 static Bool intel_uxa_destroy_pixmap(PixmapPtr pixmap)
 {
-   if (pixmap-refcnt == 1)
+   if (pixmap-refcnt == 1) {
+#ifdef GLAMOR
+   intel_glamor_destroy_pixmap(pixmap);
+#endif
intel_set_pixmap_bo(pixmap, NULL);
+   }
fbDestroyPixmap(pixmap);
return TRUE;
 }
@@ -1134,6 +1149,10 @@ Bool intel_uxa_create_screen_resources(ScreenPtr screen)
scrn-displayWidth = intel-front_pitch / intel-cpp;
}
 
+#ifdef GLAMOR
+   if (!intel_glamor_create_screen_resources(screen))
+   return FALSE;
+#endif
return TRUE;
 }
 
@@ -1295,6 +1314,8 @@ Bool intel_uxa_init(ScreenPtr screen)
 
uxa_set_fallback_debug(screen, intel-fallback_debug);
uxa_set_force_fallback(screen, intel-force_fallback);
-
+#ifdef GLAMOR
+   intel_glamor_init(screen);
+#endif
return TRUE;
 }
-- 
1.7.4.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/3] glamor: Route fillspans and polyfillrects to glamor.

2011-11-13 Thread Zhigang Gong 
If GLAMOR is enabled, we route UXA's fillspans and
polyfillrects to glamor by default. And if glamor
fail to accelerate it, UXA continue to handle it.

Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
 uxa/uxa-accel.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c
index 516834f..18fa63b 100644
--- a/uxa/uxa-accel.c
+++ b/uxa/uxa-accel.c
@@ -27,7 +27,6 @@
  *Michel Dänzer mic...@tungstengraphics.com
  *
  */
-
 #ifdef HAVE_DIX_CONFIG_H
 #include dix-config.h
 #endif
@@ -37,6 +36,10 @@
 #include uxa.h
 #include mipict.h
 
+#ifdef GLAMOR
+#include glamor.h
+#endif
+
 static void
 uxa_fill_spans(DrawablePtr pDrawable, GCPtr pGC, int n,
   DDXPointPtr ppt, int *pwidth, int fSorted)
@@ -49,6 +52,10 @@ uxa_fill_spans(DrawablePtr pDrawable, GCPtr pGC, int n,
int nbox;
int x1, x2, y;
int off_x, off_y;
+#ifdef GLAMOR
+   if (glamor_fill_spans_nf(pDrawable, pGC, n, ppt, pwidth, fSorted))
+   return;
+#endif
 
if (uxa_screen-swappedOut || uxa_screen-force_fallback)
goto fallback;
@@ -673,6 +680,10 @@ uxa_poly_fill_rect(DrawablePtr pDrawable,
int n;
RegionPtr pReg = RECTS_TO_REGION(pScreen, nrect, prect, CT_UNSORTED);
 
+#ifdef GLAMOR
+   if (glamor_poly_fill_rect_nf(pDrawable, pGC, nrect, prect))
+   return;
+#endif
/* Compute intersection of rects and clip region */
REGION_TRANSLATE(pScreen, pReg, pDrawable-x, pDrawable-y);
REGION_INTERSECT(pScreen, pReg, pClip, pReg);
-- 
1.7.4.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.16.902

2011-11-13 Thread tino . keitel+xorg 
On Sun, Nov 13, 2011 at 11:27:29 +, Chris Wilson wrote:
 This is the second release candidate in preparation for the upcoming
 2.17.0 release. We will appreciate any feedback we can get from

Hi,

this does not show up in
git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel yet.

Is this the correct repository?

Regards,
Tino
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx