[Mesa-dev] [PATCH 1/1] glsl: warning: pragma `invariant(all)' not supported in GLSL ES 1.00

2012-07-06 Thread Oliver McFadden
The OpenGL(R) ES Shading Language
Version 1.00 Revision 17 (12 May, 2009)

> 4.6.1 The Invariant Qualifier
> ... To force all output variables to be invariant, use the pragma
> #pragma STDGL invariant(all)

Signed-off-by: Oliver McFadden 
---
 src/glsl/glsl_parser.yy |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 5ca8740..8d27ef2 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -297,7 +297,7 @@ pragma_statement:
| PRAGMA_OPTIMIZE_OFF EOL
| PRAGMA_INVARIANT_ALL EOL
{
-  if (state->language_version < 120) {
+  if (state->language_version < 120 && !state->Const.GLSL_100ES) {
  _mesa_glsl_warning(& @1, state,
 "pragma `invariant(all)' not supported in %s",
 state->version_string);
-- 
1.7.8

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 51782] New: mesa-8.0.3: fails to compile against uclibc

2012-07-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=51782

 Bug #: 51782
   Summary: mesa-8.0.3: fails to compile against uclibc
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: bluen...@gentoo.org


Created attachment 63883
  --> https://bugs.freedesktop.org/attachment.cgi?id=63883
Fix compile time errors against uclibc

mesa is mostly okay with uclibc instead of glibc, but 8.0.3 does miss a few
checks that fall back on glibc-ism and cause compile time failures.  The
following patch fixes this issue.

This was hit in Gentoo on amd64, but would affect all uclibc systems on all
arches.  Downstream bug is at

   https://bugs.gentoo.org/show_bug.cgi?id=425042


The attached patch fixes the issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Require current libxcb.

2012-07-06 Thread Ian Romanick

On 07/05/2012 03:08 PM, Eric Anholt wrote:

Without that, people with buggy apps that looked at just the server
string for GLX_ARB_create_context would call this function that just
threw an error when you tried to make a context.  Google shows plenty
of complaints about this.


Oh yeah.  I never went back and did this.  I thought the main problem 
was various Unigen demos that only looked at the client string.  Either way,


Reviewed-by: Ian Romanick 


---
  configure.ac  |   21 +
  src/glx/clientinfo.c  |7 +--
  src/glx/create_context.c  |   14 --
  src/glx/glxextensions.c   |9 -
  src/glx/tests/Makefile.am |3 ---
  5 files changed, 2 insertions(+), 52 deletions(-)

diff --git a/configure.ac b/configure.ac
index 46265a2..a76515b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1030,29 +1030,12 @@ xyesno)
  GL_PC_CFLAGS="$X11_INCLUDES"

  # XCB can only be used from pkg-config
-PKG_CHECK_MODULES([XCB],[x11-xcb xcb-glx])
+PKG_CHECK_MODULES([XCB],[x11-xcb xcb-glx>= 1.8.1])
  GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV x11-xcb xcb-glx"
  X11_INCLUDES="$X11_INCLUDES $XCB_CFLAGS"
  GL_LIB_DEPS="$GL_LIB_DEPS $XCB_LIBS"
  fi

-# Check to see if the xcb-glx library is new enough to support
-# GLX_ARB_create_context.  This bit of hackery is necessary until XCB 1.8
-# is released.
-save_CPPFLAGS="$CPPFLAGS"
-save_LDFLAGS="$LDFLAGS"
-CPPFLAGS="$CPPFLAGS $X11_INCLUDES"
-LDFLAGS="$LDFLAGS $GL_LIB_DEPS"
-AC_CHECK_LIB(xcb-glx, xcb_glx_create_context_attribs_arb_checked,
-[HAVE_XCB_GLX_CREATE_CONTEXT=yes],
-[HAVE_XCB_GLX_CREATE_CONTEXT=no])
-CPPFLAGS="$save_CPPFLAGS"
-LDFLAGS="$save_LDFLAGS"
-
-if test x$HAVE_XCB_GLX_CREATE_CONTEXT = xyes; then
-X11_INCLUDES="$X11_INCLUDES -DHAVE_XCB_GLX_CREATE_CONTEXT"
-fi
-
  # need DRM libs, -lpthread, etc.
  GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm -lpthread $DLOPEN_LIBS"
  GL_PC_LIB_PRIV="-lm -lpthread $DLOPEN_LIBS"
@@ -1061,8 +1044,6 @@ esac

  # This is outside the case (above) so that it is invoked even for non-GLX
  # builds.
-AM_CONDITIONAL(HAVE_XCB_GLX_CREATE_CONTEXT,
-test x$HAVE_XCB_GLX_CREATE_CONTEXT = xyes)
  AM_CONDITIONAL(HAVE_XF86VIDMODE, test "x$HAVE_XF86VIDMODE" = xyes)

  GLESv1_CM_LIB_DEPS="$LIBDRM_LIBS -lm -lpthread $DLOPEN_LIBS"
diff --git a/src/glx/clientinfo.c b/src/glx/clientinfo.c
index 97d43ce..429e9a3 100644
--- a/src/glx/clientinfo.c
+++ b/src/glx/clientinfo.c
@@ -39,7 +39,6 @@ __glX_send_client_info(struct glx_display *glx_dpy)
 Bool any_screen_has_ARB_create_context = False;
 Bool any_screen_has_ARB_create_context_profile = False;
 unsigned i;
-#ifdef HAVE_XCB_GLX_CREATE_CONTEXT
 static const uint32_t gl_versions[] = {
1, 4,
 };
@@ -48,7 +47,6 @@ __glX_send_client_info(struct glx_display *glx_dpy)
 };
 static const char glx_extensions[] =
"GLX_ARB_create_context GLX_ARB_create_context_profile";
-#endif

 /* There are three possible flavors of the client info structure that the
  * client could send to the server.  The version sent depends on the
@@ -125,7 +123,6 @@ __glX_send_client_info(struct glx_display *glx_dpy)
  * THE ORDER IS IMPORTANT.  We want to send the most recent version of the
  * protocol that the server can support.
  */
-#ifdef HAVE_XCB_GLX_CREATE_CONTEXT
 if (glx_dpy->majorVersion == 1&&  glx_dpy->minorVersion == 4
 &&  any_screen_has_ARB_create_context_profile) {
xcb_glx_set_client_info_2arb(c,
@@ -148,9 +145,7 @@ __glX_send_client_info(struct glx_display *glx_dpy)
  gl_versions,
  gl_extension_string,
  glx_extensions);
-   } else
-#endif
-   {
+   } else {
xcb_glx_client_info(c,
  GLX_MAJOR_VERSION, GLX_MINOR_VERSION,
  gl_extension_length,
diff --git a/src/glx/create_context.c b/src/glx/create_context.c
index a1a55b3..a755e83 100644
--- a/src/glx/create_context.c
+++ b/src/glx/create_context.c
@@ -99,7 +99,6 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig config,
  * the protocol error and handle it.  Part of handling the error is freeing
  * the possibly non-NULL value returned by this function.
  */
-#ifdef HAVE_XCB_GLX_CREATE_CONTEXT
 cookie =
xcb_glx_create_context_attribs_arb_checked(c,
 gc->xid,
@@ -111,19 +110,6 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig 
config,
 (const uint32_t *)
 attrib_list);
 err = xcb_request_check(c, cookie);
-#else
-   /* This is a hugely ugly hack to make things compile on systems that lack
-* the proper XCB version.
-*/
-   memset(&cookie, 0, sizeof(cookie));
-
- 

Re: [Mesa-dev] [PATCH 1/8] __DRIimage: version 5, add new formats and createSubImage

2012-07-06 Thread Eric Anholt
Kristian Høgsberg  writes:

> The additions in version 5 enables creating EGLImages for different planes
> of a YUV buffer.  createImageFromName is still used to create the containing
> __DRIimage, and createSubImage can then be used no that __DRIimage to create
> __DRIimages that correspond to the y, u, and v planes (__DRI_IMAGE_FORMAT_R8)
> or the uv planes (__DRI_IMAGE_FORMAT_RG88) for formats such as NV12 where
> the u and v components are interleaved.  Packed formats such as YUYV etc
> doesn't require any special treatment, we just sample those as a regular
> ARGB texture.

This patch series is making more sense to me than the last few yuv
patchsets I've seen.

> Signed-off-by: Kristian Høgsberg 
> ---
>  include/GL/internal/dri_interface.h |   16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index e37917e..5dfe15b 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -907,6 +907,10 @@ struct __DRIdri2ExtensionRec {
>  #define __DRI_IMAGE_FORMAT_ARGB 0x1003
>  #define __DRI_IMAGE_FORMAT_ABGR 0x1004
>  #define __DRI_IMAGE_FORMAT_XBGR 0x1005
> +#define __DRI_IMAGE_FORMAT_R8   0x1006 /* Since version 5 */
> +#define __DRI_IMAGE_FORMAT_RG88 0x1007
> +#define __DRI_IMAGE_FORMAT_YUV420   0x1008
> +#define __DRI_IMAGE_FORMAT_NV12 0x1009

Could we get just a couple notes on the yuv420/nv12 formats here?  Also,
can one of these end up as an OES_EGL_image that someone might try to
bind as a texture?  What should happen, if so?  (If it's possible, the
MESA_FORMAT_NONE in the next patch would result in a bunch of
_mesa_problem()s and failure)

>  #define __DRI_IMAGE_USE_SHARE0x0001
>  #define __DRI_IMAGE_USE_SCANOUT  0x0002
> @@ -963,6 +967,18 @@ struct __DRIimageExtensionRec {
>  * \since 4
>  */
> int (*write)(__DRIimage *image, const void *buf, size_t count);
> +
> +   /**
> +* Create an image out of a sub-region of a parent image.  This
> +* entry point lets us create individual __DRIimages for different
> +* planes in a planar buffer (typically yuv), for example.
> +*
> +* \since 5
> +*/
> +__DRIimage *(*createSubImage)(__DRIimage *image,
> +  int width, int height, int format,
> +  int offset, int pitch,
> +  void *loaderPrivate);
>  };

Some notes about lifetime would be good here.  In the implementation you
have, the subimage gets separated from the parent, so changing the
storage of the parent (if that's a thing that's possible -- I don't
understand egl image lifetimes) wouldn't be tracked in the child.  You
could free the parent safely, as well.

If the subimage can get bound as a render target, it won't be reliably
synchronized with texturing from another subimage that overlaps it, and
that seems like something to be noted.

Are there supposed to be any restrictions on the layout of
width/height/offset/pitch related to the parent?  For tiled buffers,
there would be.  Is this totally driver-dependent?


pgpjzxXijG5EL.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/8] intel: Add offset field to miptree

2012-07-06 Thread Eric Anholt
Kristian Høgsberg  writes:

> This lets us specify an offset into the bo where the miptree starts,
> which will let us set up a texture for a single plane in a planar buffer.

While I've not some questions about the other patches, this one is:

Reviewed-by: Eric Anholt 


pgpiMU3R6GicJ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/8] intel: Implement __DRIimage::createSubImage and bump supported version to 5

2012-07-06 Thread Eric Anholt
Kristian Høgsberg  writes:
> +static __DRIimage *
> +intel_create_sub_image(__DRIimage *parent,
> +   int width, int height, int dri_format,
> +   int offset, int pitch, void *loaderPrivate)
> +{
> +__DRIimage *image;
> +
> +image = intel_allocate_image(dri_format, loaderPrivate);
> +
> +image->region = calloc(sizeof(*image->region), 1);
> +if (image->region == NULL) {
> +   FREE(image);
> +   return NULL;
> +}
> +
> +image->region->cpp = _mesa_get_format_bytes(image->format);
> +image->region->width = width;
> +image->region->height = height;
> +image->region->pitch = pitch;
> +image->region->refcount = 1;
> +image->region->bo = parent->region->bo;
> +drm_intel_bo_reference(image->region->bo);
> +image->region->tiling = parent->region->tiling;
> +image->offset = offset;
> +
> +return image;
> +}

I would be a lot more comfortable if there was some validation that
offset + height * pitch was within the buffer object referenced, at
least.  There's also (offset % tile_width) != 0 possibility, but at
least it wouldn't involve rendering outside the BO afaik.

image->region->screen isn't set, so if intel_query_image() is callable
on it, it would segfault.  Seems like that ought to be fixed.


pgpkcUXRFrxXA.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/1] glsl: warning: pragma `invariant(all)' not supported in GLSL ES 1.00

2012-07-06 Thread Eric Anholt
Oliver McFadden  writes:

> The OpenGL(R) ES Shading Language
> Version 1.00 Revision 17 (12 May, 2009)
>
>> 4.6.1 The Invariant Qualifier
>> ... To force all output variables to be invariant, use the pragma
>> #pragma STDGL invariant(all)
>
> Signed-off-by: Oliver McFadden 

Could we get a piglit test for this?  Should be easy.

Reviewed-by: Eric Anholt 


pgpRUW76XU3qW.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 0/8] i965/msaa: Implement CMS MSAA layout for Gen7.

2012-07-06 Thread Paul Berry
This patch series adds support for the "Compressed Multisample
Surface" layout, which should speed up multisample rendering on Gen7
by decreasing memory bandwidth requirements.

Patches 1-2 do preparatory refactoring, including creating a function
to determine which MSAA layout should be used based on chipset
capabilities.  Initially CMS layout is not switched on, so these
patches should not produce any functional change.

Patch 3 adds code to create the MCS buffer (an auxiliary buffer the
hardware uses to keep track of the state of compression when CMS is in
use).  Patches 4-5 ensure that the state of the MCS buffer is properly
communicated to the hardware when CMS is in use.  Patches 6-7 update
blorp to properly account for the CMS layout when doing blits.  These
patches should not produce any functional change either, since CMS
layout is still switched off.

Finally, patch 8 switches on CMS layout for hardware/format
combinations that support it (Gen7 supports it on all formats except
signed integer).

No piglit regressions on Gen6 or Gen7.

[PATCH 1/8] i965/msaa: Move {rt,tex}_interleaved into blorp program key.
[PATCH 2/8] i965/msaa: Add an enum to describe MSAA layout.
[PATCH 3/8] i965/msaa: Allocate MCS buffer when CMS MSAA is in use.
[PATCH 4/8] i965/msaa: Add CMS MSAA settings to brw_structs.h.
[PATCH 5/8] i965/msaa: Set SURFACE_STATE properly when CMS MSAA is in use.
[PATCH 6/8] i965/msaa: Add CMS-related sampler messages to brw_defines.h
[PATCH 7/8] i965/msaa: Add CMS support to blorp.
[PATCH 8/8] i965/msaa: Enable CMS layout on Gen7 for the formats that support 
it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/8] i965/msaa: Move {rt, tex}_interleaved into blorp program key.

2012-07-06 Thread Paul Berry
On Gen6, MSAA buffers always use an interleaved layout and non-MSAA
buffers always use a non-interleaved layout, so it is not strictly
necessary to keep track of the layout of the texture and render target
surfaces in the blorp program key.  However, it is cleaner to do so,
since (a) it makes the blorp compiler less dependent on implicit
knowledge about how the GPU pipeline is configured, and (b) it paves
the way for implementing compressed multisampled surfaces in Gen7.

This patch won't cause any redundant compiles, because the layout of
the texture and render target surfaces depends on other parameters
that are already in the blorp program key.
---
 src/mesa/drivers/dri/i965/brw_blorp.h|   12 ++
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp |   30 +
 2 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h 
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 4c74c91..4259d9c 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -192,6 +192,12 @@ struct brw_blorp_blit_prog_key
 */
unsigned tex_samples;
 
+   /* If tex_samples > 0, whether or not the GPU pipeline will be configured
+* to read from it as though it were an interleaved MSAA layout.  False if
+* tex_samples == 0.
+*/
+   bool tex_interleaved;
+
/* Actual number of samples per pixel in the source image. */
unsigned src_samples;
 
@@ -205,6 +211,12 @@ struct brw_blorp_blit_prog_key
 */
unsigned rt_samples;
 
+   /* If rt_samples > 0, whether or not the GPU pipeline will be configured
+* to write to it as though it were an interleaved MSAA layout.  False if
+* rt_samples == 0.
+*/
+   bool rt_interleaved;
+
/* Actual number of samples per pixel in the destination image. */
unsigned dst_samples;
 
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 0bed768..0467607 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -510,14 +510,6 @@ const GLuint *
 brw_blorp_blit_program::compile(struct brw_context *brw,
 GLuint *program_size)
 {
-   /* Since blorp uses color textures and render targets to do all its work
-* (even when blitting stencil and depth data), we always have to configure
-* the Gen7 GPU to use sliced layout on Gen7.  On Gen6, the MSAA layout is
-* always interleaved.
-*/
-   const bool rt_interleaved = key->rt_samples > 0 && brw->intel.gen == 6;
-   const bool tex_interleaved = key->tex_samples > 0 && brw->intel.gen == 6;
-
/* Sanity checks */
if (key->dst_tiled_w && key->rt_samples > 0) {
   /* If the destination image is W tiled and multisampled, then the thread
@@ -537,7 +529,7 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
*/
   assert(!key->src_tiled_w);
   assert(key->tex_samples == key->src_samples);
-  assert(tex_interleaved == key->src_interleaved);
+  assert(key->tex_interleaved == key->src_interleaved);
   assert(key->tex_samples > 0);
}
 
@@ -549,7 +541,7 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
}
 
/* Interleaved only makes sense on MSAA surfaces */
-   if (tex_interleaved) assert(key->tex_samples > 0);
+   if (key->tex_interleaved) assert(key->tex_samples > 0);
if (key->src_interleaved) assert(key->src_samples > 0);
if (key->dst_interleaved) assert(key->dst_samples > 0);
 
@@ -579,8 +571,8 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
 */
if (rt_tiled_w != key->dst_tiled_w ||
key->rt_samples != key->dst_samples ||
-   rt_interleaved != key->dst_interleaved) {
-  encode_msaa(key->rt_samples, rt_interleaved);
+   key->rt_interleaved != key->dst_interleaved) {
+  encode_msaa(key->rt_samples, key->rt_interleaved);
   /* Now (X, Y, S) = detile(rt_tiling, offset) */
   translate_tiling(rt_tiled_w, key->dst_tiled_w);
   /* Now (X, Y, S) = detile(dst_tiling, offset) */
@@ -634,12 +626,12 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
*/
   if (tex_tiled_w != key->src_tiled_w ||
   key->tex_samples != key->src_samples ||
-  tex_interleaved != key->src_interleaved) {
+  key->tex_interleaved != key->src_interleaved) {
  encode_msaa(key->src_samples, key->src_interleaved);
  /* Now (X, Y, S) = detile(src_tiling, offset) */
  translate_tiling(key->src_tiled_w, tex_tiled_w);
  /* Now (X, Y, S) = detile(tex_tiling, offset) */
- decode_msaa(key->tex_samples, tex_interleaved);
+ decode_msaa(key->tex_samples, key->tex_interleaved);
   }
 
   /* Now (X, Y, S) = decode_msaa(tex_samples, detile(tex_tiling, offset)).
@@ -1332,6 +1324,16 @@ brw_blorp_blit_params::brw_blorp_blit_params(struct 
brw_context *brw,
wm_prog_key.tex_samples = src.num_sample

[Mesa-dev] [PATCH 2/8] i965/msaa: Add an enum to describe MSAA layout.

2012-07-06 Thread Paul Berry
>From the Ivy Bridge PRM, Vol 1 Part 1, p112:

There are three types of multisampled surface layouts designated
as follows:
  - IMS Interleaved Multisampled Surface
  - CMS Compressed Mulitsampled Surface
  - UMS Uncompressed Multisampled Surface

Previously, the i965 driver only used IMS and UMS formats, and
distinguished beetween them using the boolean
intel_mipmap_tree::msaa_is_interleaved.  To facilitate adding support
for the CMS format, this patch replaces that boolean (and other
booleans derived from it) with an enum
INTEL_MSAA_LAYOUT_{IMS,CMS,UMS}.  It also updates the terminology used
in comments throughout the driver to match the IMS/CMS/UMS terminology
used in the PRM.  CMS layout is not yet used.

The enum has a fourth possible value, INTEL_MSAA_LAYOUT_NONE, which is
used for non-multisampled surfaces.
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp   |1 +
 src/mesa/drivers/dri/i965/brw_blorp.h |   32 ++--
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp  |  190 ++---
 src/mesa/drivers/dri/i965/brw_tex_layout.c|   10 +-
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c  |2 +-
 src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |4 +-
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c|   68 
 src/mesa/drivers/dri/intel/intel_mipmap_tree.h|   48 +-
 src/mesa/drivers/dri/intel/intel_tex_image.c  |2 +-
 src/mesa/drivers/dri/intel/intel_tex_validate.c   |2 +-
 10 files changed, 229 insertions(+), 130 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index afb4530..9017e4d 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -61,6 +61,7 @@ brw_blorp_surface_info::set(struct brw_context *brw,
this->num_samples = mt->num_samples;
this->array_spacing_lod0 = mt->array_spacing_lod0;
this->map_stencil_as_y_tiled = false;
+   this->msaa_layout = mt->msaa_layout;
 
switch (mt->format) {
case MESA_FORMAT_S8:
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h 
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 4259d9c..053eef7 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -97,6 +97,12 @@ void set(struct brw_context *brw,
 * surface.  Should correspond to one of the BRW_SURFACEFORMAT_* enums.
 */
uint32_t brw_surfaceformat;
+
+   /**
+* For MSAA surfaces, MSAA layout that should be used when setting up the
+* surface state for this surface.
+*/
+   intel_msaa_layout msaa_layout;
 };
 
 
@@ -192,38 +198,30 @@ struct brw_blorp_blit_prog_key
 */
unsigned tex_samples;
 
-   /* If tex_samples > 0, whether or not the GPU pipeline will be configured
-* to read from it as though it were an interleaved MSAA layout.  False if
-* tex_samples == 0.
+   /* MSAA layout that has been configured in the surface state for texturing
+* from.
 */
-   bool tex_interleaved;
+   intel_msaa_layout tex_layout;
 
/* Actual number of samples per pixel in the source image. */
unsigned src_samples;
 
-   /* If src_samples > 0, whether or not the source image uses an interleaved
-* MSAA layout.  False if src_samples == 0.
-*/
-   bool src_interleaved;
+   /* Actual MSAA layout used by the source image. */
+   intel_msaa_layout src_layout;
 
/* Number of samples per pixel that have been configured in the render
 * target.
 */
unsigned rt_samples;
 
-   /* If rt_samples > 0, whether or not the GPU pipeline will be configured
-* to write to it as though it were an interleaved MSAA layout.  False if
-* rt_samples == 0.
-*/
-   bool rt_interleaved;
+   /* MSAA layout that has been configured in the render target. */
+   intel_msaa_layout rt_layout;
 
/* Actual number of samples per pixel in the destination image. */
unsigned dst_samples;
 
-   /* If dst_samples > 0, whether or not the destination image uses an
-* interleaved MSAA layout.  False if dst_samples == 0.
-*/
-   bool dst_interleaved;
+   /* Actual MSAA layout used by the destination image. */
+   intel_msaa_layout dst_layout;
 
/* True if the source image is W tiled.  If true, the surface state for the
 * source image must be configured as Y tiled, and tex_samples must be 0.
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 0467607..ea98a66 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -288,22 +288,22 @@ enum sampler_message_arg
  *   offset = tile(tiling_format, encode_msaa(num_samples, layout, X, Y, S))
  *   (X, Y, S) = decode_msaa(num_samples, layout, detile(tiling_format, 
offset))
  *
- * For a single-sampled surface, or for a multisampled surface that stores
- * each sample in a different array slice, encode_msaa() and decode_msaa are
- * the identity function:
+ * F

[Mesa-dev] [PATCH 3/8] i965/msaa: Allocate MCS buffer when CMS MSAA is in use.

2012-07-06 Thread Paul Berry
To implement Gen7's CMS MSAA layout, we need an extra buffer, the MCS
(Multisample Control Surface) buffer.  This patch introduces code for
allocating and deallocating the buffer, and storing a pointer to it in
the intel_mipmap_tree struct.

No functional change, since the CMS layout is not enabled yet.
---
 src/mesa/drivers/dri/intel/intel_fbo.c |9 +
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c |   45 
 src/mesa/drivers/dri/intel/intel_mipmap_tree.h |   14 +++
 3 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c 
b/src/mesa/drivers/dri/intel/intel_fbo.c
index a801bb7..6530b99 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -282,6 +282,15 @@ intel_alloc_renderbuffer_storage(struct gl_context * ctx, 
struct gl_renderbuffer
   }
}
 
+   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_CMS) {
+  bool ok = intel_miptree_alloc_mcs(intel, irb->mt, rb->NumSamples);
+  if (!ok) {
+ intel_miptree_release(&irb->mt->hiz_mt);
+ intel_miptree_release(&irb->mt);
+ return false;
+  }
+   }
+
return true;
 }
 
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index f97668a..84fc477 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -406,6 +406,7 @@ intel_miptree_release(struct intel_mipmap_tree **mt)
   intel_region_release(&((*mt)->region));
   intel_miptree_release(&(*mt)->stencil_mt);
   intel_miptree_release(&(*mt)->hiz_mt);
+  intel_miptree_release(&(*mt)->mcs_mt);
   intel_resolve_map_clear(&(*mt)->hiz_map);
 
   for (i = 0; i < MAX_TEXTURE_LEVELS; i++) {
@@ -637,6 +638,50 @@ intel_miptree_copy_teximage(struct intel_context *intel,
 }
 
 bool
+intel_miptree_alloc_mcs(struct intel_context *intel,
+struct intel_mipmap_tree *mt,
+GLuint num_samples)
+{
+   assert(mt->mcs_mt == NULL);
+   assert(intel->gen >= 7); /* MCS only used on Gen7+ */
+   assert(num_samples == 4); /* TODO: support 8x MSAA */
+
+   /* From the Ivy Bridge PRM, Vol4 Part1 p76, "MCS Base Address":
+*
+* "The MCS surface must be stored as Tile Y."
+*
+* We set msaa_format to INTEL_MSAA_LAYOUT_CMS to force
+* intel_miptree_create() to use Y tiling.  msaa_format is otherwise
+* ignored for the MCS miptree.
+*/
+   mt->mcs_mt = intel_miptree_create(intel,
+ mt->target,
+ MESA_FORMAT_A8,
+ mt->first_level,
+ mt->last_level,
+ mt->width0,
+ mt->height0,
+ mt->depth0,
+ true,
+ 0 /* num_samples */,
+ INTEL_MSAA_LAYOUT_CMS);
+
+   /* From the Ivy Bridge PRM, Vol 2 Part 1 p326:
+*
+* When MCS buffer is enabled and bound to MSRT, it is required that it
+* is cleared prior to any rendering.
+*
+* Since we don't use the MCS buffer for any purpose other than rendering,
+* it makes sense to just clear it immediately upon allocation.
+*/
+   void *data = intel_region_map(intel, mt->mcs_mt->region, 0);
+   memset(data, 0, mt->mcs_mt->region->bo->size);
+   intel_region_unmap(intel, mt->mcs_mt->region);
+
+   return mt->mcs_mt;
+}
+
+bool
 intel_miptree_alloc_hiz(struct intel_context *intel,
struct intel_mipmap_tree *mt,
 GLuint num_samples)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index e0ed4fe..f8245a6 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -272,6 +272,15 @@ struct intel_mipmap_tree
 */
struct intel_mipmap_tree *stencil_mt;
 
+   /**
+* \brief MCS miptree for multisampled textures.
+*
+* This miptree contains the "multisample control surface", which stores
+* the necessary information to implement compressed MSAA on Gen7+
+* (INTEL_MSAA_FORMAT_CMS).
+*/
+   struct intel_mipmap_tree *mcs_mt;
+
/* These are also refcounted:
 */
GLuint refcount;
@@ -384,6 +393,11 @@ intel_miptree_s8z24_gather(struct intel_context *intel,
uint32_t level,
uint32_t layer);
 
+bool
+intel_miptree_alloc_mcs(struct intel_context *intel,
+struct intel_mipmap_tree *mt,
+GLuint num_samples);
+
 /**
  * \name Miptree HiZ functions
  * \{
-- 
1.7.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http:

[Mesa-dev] [PATCH 4/8] i965/msaa: Add CMS MSAA settings to brw_structs.h.

2012-07-06 Thread Paul Berry
Previously the DWORD used to control the CMS MSAA layout was just a
pad value, because we didn't use it.
---
 src/mesa/drivers/dri/i965/brw_structs.h |   22 --
 1 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_structs.h 
b/src/mesa/drivers/dri/i965/brw_structs.h
index 41c88d0..67bfb98 100644
--- a/src/mesa/drivers/dri/i965/brw_structs.h
+++ b/src/mesa/drivers/dri/i965/brw_structs.h
@@ -854,8 +854,26 @@ struct gen7_surface_state
   GLuint x_offset:7;
} ss5;
 
-   struct {
-  GLuint pad; /* Multisample Control Surface stuff */
+   union {
+  GLuint raw_data;
+  struct {
+ GLuint y_offset_for_uv_plane:14;
+ GLuint pad1:2;
+ GLuint x_offset_for_uv_plane:14;
+ GLuint pad0:2;
+  } planar; /** Interpretation when Surface Format == PLANAR */
+  struct {
+ GLuint mcs_enable:1;
+ GLuint append_counter_enable:1;
+ GLuint pad:4;
+ GLuint append_counter_address:26;
+  } mcs_disabled; /** Interpretation when mcs_enable == 0 */
+  struct {
+ GLuint mcs_enable:1;
+ GLuint pad:2;
+ GLuint mcs_surface_pitch:9;
+ GLuint mcs_base_address:20;
+  } mcs_enabled; /** Interpretation when mcs_enable == 1 */
} ss6;
 
struct {
-- 
1.7.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 5/8] i965/msaa: Set SURFACE_STATE properly when CMS MSAA is in use.

2012-07-06 Thread Paul Berry
When a buffer using Gen7's CMS MSAA layout is bound to a texture or a
render target, the SURFACE_STATE structure needs to point to the MCS
buffer and to indicate its pitch.  This patch updates the functions
that emit SURFACE_STATE to handle CMS layout properly.
---
 src/mesa/drivers/dri/i965/brw_state.h |5 ++
 src/mesa/drivers/dri/i965/gen7_blorp.cpp  |4 ++
 src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |   45 +
 3 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
b/src/mesa/drivers/dri/i965/brw_state.h
index 31853ea..1c70db2 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -201,6 +201,11 @@ GLuint translate_tex_format(gl_format mesa_format,
 void gen7_set_surface_tiling(struct gen7_surface_state *surf, uint32_t tiling);
 void gen7_set_surface_num_multisamples(struct gen7_surface_state *surf,
unsigned num_samples);
+void gen7_set_surface_mcs_info(struct brw_context *brw,
+   struct gen7_surface_state *surf,
+   uint32_t surf_offset,
+   const struct intel_mipmap_tree *mcs_mt,
+   bool is_render_target);
 void gen7_check_surface_setup(struct gen7_surface_state *surf,
   bool is_render_target);
 void gen7_init_vtable_surface_functions(struct brw_context *brw);
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp 
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index ec63120..f087dbd 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -181,6 +181,10 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
surf->ss3.pitch = pitch_bytes - 1;
 
gen7_set_surface_num_multisamples(surf, surface->num_samples);
+   if (surface->msaa_layout == INTEL_MSAA_LAYOUT_CMS) {
+  gen7_set_surface_mcs_info(brw, surf, wm_surf_offset,
+surface->mt->mcs_mt, is_render_target);
+   }
 
if (intel->is_haswell) {
   surf->ss7.shader_chanel_select_r = HSW_SCS_RED;
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index 6510421..56b8c3d 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -69,6 +69,46 @@ gen7_set_surface_num_multisamples(struct gen7_surface_state 
*surf,
 
 
 void
+gen7_set_surface_mcs_info(struct brw_context *brw,
+  struct gen7_surface_state *surf,
+  uint32_t surf_offset,
+  const struct intel_mipmap_tree *mcs_mt,
+  bool is_render_target)
+{
+   /* From the Ivy Bridge PRM, Vol4 Part1 p76, "MCS Base Address":
+*
+* "The MCS surface must be stored as Tile Y."
+*/
+   assert(mcs_mt->region->tiling == I915_TILING_Y);
+
+   /* Compute the pitch in units of tiles.  To do this we need to divide the
+* pitch in bytes by 128, since a single Y-tile is 128 bytes wide.
+*/
+   unsigned pitch_bytes = mcs_mt->region->pitch * mcs_mt->cpp;
+   unsigned pitch_tiles = pitch_bytes / 128;
+
+   /* The upper 20 bits of surface state DWORD 6 are the upper 20 bits of the
+* GPU address of the MCS buffer; the lower 12 bits contain other control
+* information.  Since buffer addresses are always on 4k boundaries (and
+* thus have their lower 12 bits zero), we can use an ordinary reloc to do
+* the necessary address translation.
+*/
+   assert ((mcs_mt->region->bo->offset & 0xfff) == 0);
+   surf->ss6.mcs_enabled.mcs_enable = 1;
+   surf->ss6.mcs_enabled.mcs_surface_pitch = pitch_tiles - 1;
+   surf->ss6.mcs_enabled.mcs_base_address = mcs_mt->region->bo->offset >> 12;
+   drm_intel_bo_emit_reloc(brw->intel.batch.bo,
+   surf_offset +
+   offsetof(struct gen7_surface_state, ss6),
+   mcs_mt->region->bo,
+   surf->ss6.raw_data - mcs_mt->region->bo->offset,
+   is_render_target ? I915_GEM_DOMAIN_RENDER
+   : I915_GEM_DOMAIN_SAMPLER,
+   is_render_target ? I915_GEM_DOMAIN_RENDER : 0);
+}
+
+
+void
 gen7_check_surface_setup(struct gen7_surface_state *surf,
  bool is_render_target)
 {
@@ -451,6 +491,11 @@ gen7_update_renderbuffer_surface(struct brw_context *brw,
 
gen7_set_surface_num_multisamples(surf, irb->mt->num_samples);
 
+   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_CMS) {
+  gen7_set_surface_mcs_info(brw, surf, brw->wm.surf_offset[unit],
+irb->mt->mcs_mt, true /* is_render_target */);
+   }
+
if (intel->is_haswell) {
   surf->ss7.shader_chanel_select_r = HSW_SCS_RED;
   surf->ss7.shader_chanel_select_g 

[Mesa-dev] [PATCH 6/8] i965/msaa: Add CMS-related sampler messages to brw_defines.h.

2012-07-06 Thread Paul Berry
---
 src/mesa/drivers/dri/i965/brw_defines.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 3234b0e..73ade0a 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -838,6 +838,8 @@ enum brw_message_target {
 #define GEN5_SAMPLER_MESSAGE_SAMPLE_LOD_COMPARE  6
 #define GEN5_SAMPLER_MESSAGE_SAMPLE_LD   7
 #define GEN5_SAMPLER_MESSAGE_SAMPLE_RESINFO  10
+#define GEN7_SAMPLER_MESSAGE_SAMPLE_LD_MCS   29
+#define GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DMS   30
 #define GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DSS   31
 
 /* for GEN5 only */
-- 
1.7.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 7/8] i965/msaa: Add CMS support to blorp.

2012-07-06 Thread Paul Berry
This patch updates the blorp engine to properly handle the case where
the surface being textured from uses Gen7's CMS MSAA layout.  The
following changes were necessary:

- Before reading color values from the surface, we need to read from
  the MCS buffer using the ld_mcs sampler message.  This is done by
  the mcs_fetch() function, and the result is stored in the mcs_data
  register.  This only needs to be done once per pixel, since the MCS
  value is shared between all samples belonging to a pixel.

- When reading color values from the surface, we need to use the
  ld2dms sampler message instead of the ld2dss message, and we need to
  provide the value read from the MCS buffer as an argument.
---
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp |   45 -
 1 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index ea98a66..6954733 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -273,6 +273,7 @@ enum sampler_message_arg
SAMPLER_MESSAGE_ARG_U_INT,
SAMPLER_MESSAGE_ARG_V_INT,
SAMPLER_MESSAGE_ARG_SI_INT,
+   SAMPLER_MESSAGE_ARG_MCS_INT,
SAMPLER_MESSAGE_ARG_ZERO_INT,
 };
 
@@ -427,6 +428,7 @@ private:
void manual_blend();
void sample(struct brw_reg dst);
void texel_fetch(struct brw_reg dst);
+   void mcs_fetch();
void expand_to_32_bits(struct brw_reg src, struct brw_reg dst);
void texture_lookup(struct brw_reg dst, GLuint msg_type,
const sampler_message_arg *args, int num_args);
@@ -461,6 +463,13 @@ private:
 */
struct brw_reg texture_data;
 
+   /* Auxiliary storage for the contents of the MCS surface.
+*
+* Since the sampler always returns 8 registers worth of data, this is 8
+* registers wide, even though we only use the first 2 registers of it.
+*/
+   struct brw_reg mcs_data;
+
/* X coordinates.  We have two of them so that we can perform coordinate
 * transformations easily.
 */
@@ -645,6 +654,8 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
* the texturing unit, will cause data to be read from the correct
* memory location.  So we can fetch the texel now.
*/
+  if (key->tex_layout == INTEL_MSAA_LAYOUT_CMS)
+ mcs_fetch();
   texel_fetch(result);
}
 
@@ -686,6 +697,8 @@ brw_blorp_blit_program::alloc_regs()
reg += BRW_BLORP_NUM_PUSH_CONST_REGS;
this->result = vec16(brw_vec8_grf(reg, 0)); reg += 8;
this->texture_data = vec16(brw_vec8_grf(reg, 0)); reg += 8;
+   this->mcs_data =
+  retype(brw_vec8_grf(reg, 0), BRW_REGISTER_TYPE_UD); reg += 8;
for (int i = 0; i < 2; ++i) {
   this->x_coords[i]
  = vec16(retype(brw_vec8_grf(reg++, 0), BRW_REGISTER_TYPE_UW));
@@ -1054,6 +1067,9 @@ brw_blorp_blit_program::manual_blend()
/* TODO: support num_samples != 4 */
const int num_samples = 4;
 
+   if (key->tex_layout == INTEL_MSAA_LAYOUT_CMS)
+  mcs_fetch();
+
/* Gather sample 0 data first */
s_is_zero = true;
texel_fetch(result);
@@ -1118,6 +1134,12 @@ brw_blorp_blit_program::texel_fetch(struct brw_reg dst)
   SAMPLER_MESSAGE_ARG_U_INT,
   SAMPLER_MESSAGE_ARG_V_INT
};
+   static const sampler_message_arg gen7_ld2dms_args[4] = {
+  SAMPLER_MESSAGE_ARG_SI_INT,
+  SAMPLER_MESSAGE_ARG_MCS_INT,
+  SAMPLER_MESSAGE_ARG_U_INT,
+  SAMPLER_MESSAGE_ARG_V_INT
+   };
 
switch (brw->intel.gen) {
case 6:
@@ -1126,8 +1148,13 @@ brw_blorp_blit_program::texel_fetch(struct brw_reg dst)
   break;
case 7:
   if (key->tex_samples > 0) {
- texture_lookup(dst, GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DSS,
-gen7_ld2dss_args, ARRAY_SIZE(gen7_ld2dss_args));
+ if (key->tex_layout == INTEL_MSAA_LAYOUT_CMS) {
+texture_lookup(dst, GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DMS,
+   gen7_ld2dms_args, ARRAY_SIZE(gen7_ld2dms_args));
+ } else {
+texture_lookup(dst, GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DSS,
+   gen7_ld2dss_args, ARRAY_SIZE(gen7_ld2dss_args));
+ }
   } else {
  assert(s_is_zero);
  texture_lookup(dst, GEN5_SAMPLER_MESSAGE_SAMPLE_LD, gen7_ld_args,
@@ -1141,6 +1168,17 @@ brw_blorp_blit_program::texel_fetch(struct brw_reg dst)
 }
 
 void
+brw_blorp_blit_program::mcs_fetch()
+{
+   static const sampler_message_arg gen7_ld_mcs_args[2] = {
+  SAMPLER_MESSAGE_ARG_U_INT,
+  SAMPLER_MESSAGE_ARG_V_INT
+   };
+   texture_lookup(vec16(mcs_data), GEN7_SAMPLER_MESSAGE_SAMPLE_LD_MCS,
+  gen7_ld_mcs_args, ARRAY_SIZE(gen7_ld_mcs_args));
+}
+
+void
 brw_blorp_blit_program::expand_to_32_bits(struct brw_reg src,
   struct brw_reg dst)
 {
@@ -1183,6 +1221,9 @@ brw_blorp_blit_program::texture_lookup(struct brw_reg dst,
  else
  

[Mesa-dev] [PATCH 8/8] i965/msaa: Enable CMS layout on Gen7 for the formats that support it.

2012-07-06 Thread Paul Berry
---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c |   19 ++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 84fc477..4f77a65 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -292,7 +292,24 @@ compute_msaa_layout(struct intel_context *intel, gl_format 
format)
case GL_DEPTH_STENCIL:
   return INTEL_MSAA_LAYOUT_IMS;
default:
-  return INTEL_MSAA_LAYOUT_UMS;
+  /* From the Ivy Bridge PRM, Vol4 Part1 p77 ("MCS Enable"):
+   *
+   *   This field must be set to 0 for all SINT MSRTs when all RT channels
+   *   are not written
+   *
+   * In practice this means that we have to disable MCS for all signed
+   * integer MSAA buffers.  The alternative, to disable MCS only when one
+   * of the render target channels is disabled, is impractical because it
+   * would require converting between CMS and UMS MSAA layouts on the fly,
+   * which is expensive.
+   */
+  if (_mesa_get_format_datatype(format) == GL_INT) {
+ /* TODO: is this workaround needed for future chipsets? */
+ assert(intel->gen == 7);
+ return INTEL_MSAA_LAYOUT_UMS;
+  } else {
+ return INTEL_MSAA_LAYOUT_CMS;
+  }
}
 }
 
-- 
1.7.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] r600g: improve flushed depth texture handling v2

2012-07-06 Thread Marek Olšák
On Wed, Jun 27, 2012 at 1:34 AM, Vadim Girlin  wrote:
> Use r600_resource_texture::flished_depth_texture for GPU access, and
> allocate it in the VRAM. For transfers we'll allocate untiled texture in the
> GTT and store it in the r600_transfer::staging.
>
> Improves performance when flushed depth texture is frequently used by the
> GPU (about 30% for Lightsmark).
>
> Signed-off-by: Vadim Girlin 
> ---
>
> Fixes fbo-clear-formats, fbo-generatemipmap-formats, no regressions on
> evergreen

Hi,

is there any reason this patch hasn't been committed yet?

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/8] __DRIimage: version 5, add new formats and createSubImage

2012-07-06 Thread Kristian Høgsberg
On Fri, Jul 06, 2012 at 02:10:57PM -0700, Eric Anholt wrote:
> Kristian Høgsberg  writes:
> 
> > The additions in version 5 enables creating EGLImages for different planes
> > of a YUV buffer.  createImageFromName is still used to create the containing
> > __DRIimage, and createSubImage can then be used no that __DRIimage to create
> > __DRIimages that correspond to the y, u, and v planes 
> > (__DRI_IMAGE_FORMAT_R8)
> > or the uv planes (__DRI_IMAGE_FORMAT_RG88) for formats such as NV12 where
> > the u and v components are interleaved.  Packed formats such as YUYV etc
> > doesn't require any special treatment, we just sample those as a regular
> > ARGB texture.
> 
> This patch series is making more sense to me than the last few yuv
> patchsets I've seen.

Thanks for the feedback.  I wanted to mention that while it would be a
lot easier to use different bo's for the different planes, we can't do
that.  The decoder takes a base address for the destination buffer and
then offsets relative to that to identify the various planes.  So it
has to be all within the same bo and the patch series has to touch the
miptree setup.

Also, after I sent out the series I started working on YUYV support
(which is what the SNB+ sprites take), and the sub-image feature turns
out to be useful there as well.  We can create an RG88 texture for
sampling the Y-component and then an RGBA texture for sampling the
U and V channels, which means that we can texture from a YUYV buffer
with bilinear filtering.

> > Signed-off-by: Kristian Høgsberg 
> > ---
> >  include/GL/internal/dri_interface.h |   16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/include/GL/internal/dri_interface.h 
> > b/include/GL/internal/dri_interface.h
> > index e37917e..5dfe15b 100644
> > --- a/include/GL/internal/dri_interface.h
> > +++ b/include/GL/internal/dri_interface.h
> > @@ -907,6 +907,10 @@ struct __DRIdri2ExtensionRec {
> >  #define __DRI_IMAGE_FORMAT_ARGB 0x1003
> >  #define __DRI_IMAGE_FORMAT_ABGR 0x1004
> >  #define __DRI_IMAGE_FORMAT_XBGR 0x1005
> > +#define __DRI_IMAGE_FORMAT_R8   0x1006 /* Since version 5 */
> > +#define __DRI_IMAGE_FORMAT_RG88 0x1007
> > +#define __DRI_IMAGE_FORMAT_YUV420   0x1008
> > +#define __DRI_IMAGE_FORMAT_NV12 0x1009
> 
> Could we get just a couple notes on the yuv420/nv12 formats here?  Also,
> can one of these end up as an OES_EGL_image that someone might try to
> bind as a texture?  What should happen, if so?  (If it's possible, the
> MESA_FORMAT_NONE in the next patch would result in a bunch of
> _mesa_problem()s and failure)

The __DRIimage we create with either of the YUV formats is never
exposed as an EGLImage.  We hold on to it in the wl_buffer object and
use it to create subimages of one of the types that we can actually
texture from and those get exposed as EGLImages.  I had
__DRI_IMAGE_FORMAT_NONE instead of the YUV formats, I think that may
be clearer.

> >  #define __DRI_IMAGE_USE_SHARE  0x0001
> >  #define __DRI_IMAGE_USE_SCANOUT0x0002
> > @@ -963,6 +967,18 @@ struct __DRIimageExtensionRec {
> >  * \since 4
> >  */
> > int (*write)(__DRIimage *image, const void *buf, size_t count);
> > +
> > +   /**
> > +* Create an image out of a sub-region of a parent image.  This
> > +* entry point lets us create individual __DRIimages for different
> > +* planes in a planar buffer (typically yuv), for example.
> > +*
> > +* \since 5
> > +*/
> > +__DRIimage *(*createSubImage)(__DRIimage *image,
> > +  int width, int height, int format,
> > +  int offset, int pitch,
> > +  void *loaderPrivate);
> >  };
> 
> Some notes about lifetime would be good here.  In the implementation you
> have, the subimage gets separated from the parent, so changing the
> storage of the parent (if that's a thing that's possible -- I don't
> understand egl image lifetimes) wouldn't be tracked in the child.  You
> could free the parent safely, as well.

The lifetime rules are pretty simple; each subimage is an independent
__DRIimage and its lifetime is not tied to the that of the parent.
I'll put that in the docs.
 
> If the subimage can get bound as a render target, it won't be reliably
> synchronized with texturing from another subimage that overlaps it, and
> that seems like something to be noted.

I didn't intend for the subimages to end up as render targets, but
there's nothing in the API that prevents that.  I guess the semantics
I have in mind are much like the image_external restrictions, where
you can't write to the EGLImage in any way (no glTexImage2D or
glTexSubImage2D, no binding as rendertarget, no rendering to the image
in OpenVG etc).  I can add language to the wayland GLES2 extension
that exposes the subimages to say that any such usage will result in
undefined behavior.

> Are there supposed 

Re: [Mesa-dev] [PATCH 3/8] intel: Add offset field to miptree

2012-07-06 Thread Kristian Høgsberg
On Fri, Jul 06, 2012 at 02:11:44PM -0700, Eric Anholt wrote:
> Kristian Høgsberg  writes:
> 
> > This lets us specify an offset into the bo where the miptree starts,
> > which will let us set up a texture for a single plane in a planar buffer.
> 
> While I've not some questions about the other patches, this one is:
> 
> Reviewed-by: Eric Anholt 

Thanks.  By the way, I expect this feature will be useful for the
external_image implementation too, where we'll need to set up textures
inside a bo as well.

Kristian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/8] intel: Implement __DRIimage::createSubImage and bump supported version to 5

2012-07-06 Thread Kristian Høgsberg
On Fri, Jul 06, 2012 at 02:16:23PM -0700, Eric Anholt wrote:
> Kristian Høgsberg  writes:
> > +static __DRIimage *
> > +intel_create_sub_image(__DRIimage *parent,
> > +   int width, int height, int dri_format,
> > +   int offset, int pitch, void *loaderPrivate)
> > +{
> > +__DRIimage *image;
> > +
> > +image = intel_allocate_image(dri_format, loaderPrivate);
> > +
> > +image->region = calloc(sizeof(*image->region), 1);
> > +if (image->region == NULL) {
> > +   FREE(image);
> > +   return NULL;
> > +}
> > +
> > +image->region->cpp = _mesa_get_format_bytes(image->format);
> > +image->region->width = width;
> > +image->region->height = height;
> > +image->region->pitch = pitch;
> > +image->region->refcount = 1;
> > +image->region->bo = parent->region->bo;
> > +drm_intel_bo_reference(image->region->bo);
> > +image->region->tiling = parent->region->tiling;
> > +image->offset = offset;
> > +
> > +return image;
> > +}
> 
> I would be a lot more comfortable if there was some validation that
> offset + height * pitch was within the buffer object referenced, at
> least.

That's a good point.  We should probably validate that for
intel_region_alloc_for_handle() too (that is, that height * pitch <=
bo-size).

> There's also (offset % tile_width) != 0 possibility, but at
> least it wouldn't involve rendering outside the BO afaik.

Yeah, maybe just _mesa_warning for that one?  Getting a corrupted
output is immediately noticable and easier to track down than just
returning NULL and getting a black texture.
 
> image->region->screen isn't set, so if intel_query_image() is callable
> on it, it would segfault.  Seems like that ought to be fixed.

Ah yes, will add.

Kristian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev