[Mesa-dev] [Bug 75061] bug in clearing color buffer

2014-02-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=75061

--- Comment #10 from Maxim  ---
Any progress?

-- 
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: add missing DebugMessageControl types

2014-02-23 Thread Timothy Arceri 
To make reviewing easier here is the relevant piece of the spec

"Tokens accepted or provided by the  parameters of
DebugMessageControl and DEBUGPROC, and the  parameter of
GetDebugMessageLog:

DEBUG_TYPE_PUSH_GROUP0x8269  
DEBUG_TYPE_POP_GROUP 0x826A"

On Wed, 2014-02-19 at 21:43 +1100, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri 
> ---
>  src/mesa/main/errors.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> index 5f4eac6..c00c796 100644
> --- a/src/mesa/main/errors.c
> +++ b/src/mesa/main/errors.c
> @@ -575,6 +575,11 @@ validate_params(struct gl_context *ctx, unsigned caller,
>/* this value is only valid for GL_KHR_debug functions */
>if (caller == CONTROL || caller == INSERT)
>   break;
> +   case GL_DEBUG_TYPE_PUSH_GROUP:
> +   case GL_DEBUG_TYPE_POP_GROUP:
> +  /* this value is only valid for GL_KHR_debug */
> +  if (caller == CONTROL)
> + break;
> case GL_DONT_CARE:
>if (caller == CONTROL || caller == CONTROL_ARB)
>   break;


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

Re: [Mesa-dev] [PATCH 07/25] dri/nouveau: add GLX_MESA_query_renderer support

2014-02-23 Thread Emil Velikov 
On 23/02/14 07:24, Pekka Paalanen wrote:
> On Sat, 22 Feb 2014 03:03:57 +
> Emil Velikov  wrote:
> 
>> v2: nv04-2x cards support upto opengl 1.3.
>> v3: Include correct headers.
>>
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/mesa/drivers/dri/nouveau/nouveau_screen.c | 83 
>> ++-
>>  1 file changed, 82 insertions(+), 1 deletion(-)
> ...
> 
> I still think there is something funny here:
> 
>> +static int
>> +nouveau_query_renderer_integer(__DRIscreen *psp, int param,
>> +   unsigned int *value)
>> +{
>> +   const struct nouveau_screen *const screen =
>> +  (struct nouveau_screen *) psp->driverPrivate;
>> +
>> +   switch (param) {
>> +   case __DRI2_RENDERER_VENDOR_ID:
>> +  value[0] = 0x10de;
>> +  return 0;
>> +   case __DRI2_RENDERER_DEVICE_ID: {
>> +  struct drm_nouveau_getparam gp;
>> +  int *chip_id = 0, ret;
> 
> chip_id is set to NULL.
> 
>> +
>> +  memset(&gp, 0, sizeof(gp));
>> +  gp.param = NOUVEAU_GETPARAM_PCI_DEVICE;
>> +  gp.value = (unsigned long) chip_id;
> 
> gp.value is now 0 (NULL).
> 
>> +
>> +  ret = drmCommandWriteRead(psp->fd, DRM_NOUVEAU_GETPARAM, &gp, 
>> sizeof(gp));
>> +  if (ret) {
>> + nouveau_error("Error retrieving NOUVEAU_GETPARAM_PCI_DEVICE.\n");
>> + *chip_id = -1;
> 
> Dereferencing NULL.
> 
>> +  }
>> +  value[0] = *chip_id;
> 
> Dereferencing NULL.
> 
> Am I missing something? You didn't mention anything about this when
> Ilia pointed it out.
> 
After Ilia pointed out my messy handling in this hunk and the
abstraction violation I've decided to go with nouveau_getparam(), thus
why I did not bring up again this flawed piece of code.

Thanks you for having a look, and pardon for the pain this may have caused.

-Emil
> 
> Thanks,
> pq
> 
>> +  return 0;
>> +   }

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

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

2014-02-23 Thread Emil Velikov 
On 22/02/14 21:46, Roland Scheidegger wrote:
> 
> 
> - Original Message -
>> From: "Emil Velikov" 
>> To: "Roland Scheidegger" , mesa-dev@lists.freedesktop.org
>> Cc: "emil l velikov" 
>> Sent: Saturday, February 22, 2014 2:02:08 PM
>> Subject: Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version 
>> pipe-caps
>>
>> On 22/02/14 12:02, Roland Scheidegger wrote:
>>> Am 22.02.2014 04:04, schrieb Emil Velikov:
 According to the GLX_MESA_query_renderer spec each driver should
 be able to report the version of each GL api they support before
 creating a context.

 Currently both classic mesa and gallium evaluate the version post
 context creation and while the classic drivers set the max_gl*version
 according to their capabilities, gallium uses fixed values which
 are not the best approach due to driver differences.

 Add pipe-caps so that each driver can provide their individual
 capabilites.

 Signed-off-by: Emil Velikov 
 ---
  src/gallium/docs/source/screen.rst   | 8 +++-
  src/gallium/include/pipe/p_defines.h | 6 +-
  2 files changed, 12 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/docs/source/screen.rst
 b/src/gallium/docs/source/screen.rst
 index bd553f4..7b72133 100644
 --- a/src/gallium/docs/source/screen.rst
 +++ b/src/gallium/docs/source/screen.rst
 @@ -169,7 +169,7 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
 -* ''PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
 +* ``PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE.
  * ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
different sizes for fb color/zs attachments. This controls whether
 @@ -182,6 +182,12 @@ The integer capabilities:
vertex components output by a single invocation of a geometry shader.
This is the product of the number of attribute components per vertex
and
the number of output vertices.
 +* ``PIPE_CAP_MAX_GL_CORE_VERSION``: The maximum OpenGL (Core profile)
 version
 +  supported.
 +* ``PIPE_CAP_MAX_GL_COMPAT_VERSION``: The maximum OpenGL (Compatibility
 profile)
 +  version supported.
 +* ``PIPE_CAP_MAX_GL_ES1_VERSION``: The maximum OpenGL ES1 version
 supported.
 +* ``PIPE_CAP_MAX_GL_ES2_VERSION``: The maximum OpenGL ES2 version
 supported.
  
  
  .. _pipe_capf:
 diff --git a/src/gallium/include/pipe/p_defines.h
 b/src/gallium/include/pipe/p_defines.h
 index 83815cd..5c27f9c 100644
 --- a/src/gallium/include/pipe/p_defines.h
 +++ b/src/gallium/include/pipe/p_defines.h
 @@ -522,7 +522,11 @@ enum pipe_cap {
 PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
 PIPE_CAP_TGSI_VS_LAYER = 87,
 PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES = 88,
 -   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89
 +   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89,
 +   PIPE_CAP_MAX_GL_CORE_VERSION = 90,
 +   PIPE_CAP_MAX_GL_COMPAT_VERSION = 91,
 +   PIPE_CAP_MAX_GL_ES1_VERSION = 92,
 +   PIPE_CAP_MAX_GL_ES2_VERSION = 93,
  };
  
  #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)

>>>
>>> Hmm do you really need all these different cap bits? Generally, the
>>> difference between ES/CORE/COMPAT contexts isn't hw related at all, and
>>> thus not really (gallium) driver related. So, obviously, every driver
>>> can do ES11 for instance, it should be impossible to write a gallium
>>> driver which can't. Similarly, I don't think core/compat needs a
>>> different query neither, though I guess ES2 version being separate might
>>> make sense.
>>>
>> If you can think of a way to retrieve the gl* version that a driver
>> support without ever having a gl_context I would love to hear how we can
>> do that. GLX_MESA_query_renderer requires from the driver to state the
>> version of each api it supports prior of context creation.
>>
>> Honestly I felt a bit bad about adding all those caps, but this is the
>> least evasive way of handling it. I will drop the ES1 cap would love to
>> nuke the rest as well :-)
> 
> 
> I think you could easily derive compat and core version from some "gl driver
> version" instead of having two (the driver knows nothing about core or compat
> contexts, after all). ES might be different (at least with OES 4.0).
> But technically, you shouldn't even need any version queries as you could 
> derive
> this from all the other cap bits I think (much the same way as st_extensions.c
> figures out what extensions are supported, plus mesa's compute_version then 
> does).
> None of that cap query stuff (including querying for msaa formats and the 
> like)
> requires

[Mesa-dev] [PATCH] targets/opencl: resolve undefined symbols at link time

2014-02-23 Thread Emil Velikov 
Current automake build does not try to resolve undefined
symbols thus we could end up with a broken library.

Signed-off-by: Emil Velikov 
---
 src/gallium/targets/opencl/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index 8eec405..91ec067 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -4,6 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la
 
 lib@OPENCL_LIBNAME@_la_LDFLAGS = \
$(LLVM_LDFLAGS) \
+   -no-undefined \
-version-number 1:0
 
 lib@OPENCL_LIBNAME@_la_LIBADD = \
-- 
1.9.0

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

Re: [Mesa-dev] [Intel-gfx] [PATCH] i965: Use default contexts when possible.

2014-02-23 Thread Ben Widawsky 
On Thu, Jan 02, 2014 at 07:50:35PM -1000, Ben Widawsky wrote:
> Will full PPGTT support it can be assumed that every file descriptor
> gets its own hardware context. As such, there is no need to allocate
> anew context in order to use the features provided by hardware contexts.
> Eliminating this extra context allocation saves both physical memory
> (currently PPGTT pages are pinned forever), GGTT space on IVB, and HSW,
> as well as the associated startup cost of allocating the second context
> - which can include an eviction in pathological cases.
> 
> Unfortunately, this requires a libdrm version bump as it requires a new
> interface.
> 
> NOTE: I am uncertain if the share context idea is valid. Needs mesa
> eyes.
> 
> Cc: Kenneth Graunke 
> Signed-off-by: Ben Widawsky 

Hi Ken/whomever. Everything but the actual exposing of the full PPGTT
param from this series has been merged. If you can give me a pointer on
what needs doing here in mesa, I'll try again now that full PPGTT is
available in dinq.

Thanks.

> ---
>  configure.ac| 2 +-
>  src/mesa/drivers/dri/i965/brw_context.c | 9 -
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f75325d..a0ae0b3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -29,7 +29,7 @@ AC_SUBST([OSMESA_VERSION])
>  dnl Versions for external dependencies
>  LIBDRM_REQUIRED=2.4.24
>  LIBDRM_RADEON_REQUIRED=2.4.50
> -LIBDRM_INTEL_REQUIRED=2.4.49
> +LIBDRM_INTEL_REQUIRED=2.4.51
>  LIBDRM_NVVIEUX_REQUIRED=2.4.33
>  LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
>  LIBDRM_FREEDRENO_REQUIRED=2.4.39
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 78c06fc..f5a66e1 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -674,7 +674,14 @@ brwCreateContext(gl_api api,
>  
> intel_fbo_init(brw);
>  
> -   if (brw->gen >= 6) {
> +   /* We assume that the hw_ctx is the first created for the file descriptor 
> if
> +* this is not a share context. If that assumption turns false then we'll
> +* end up having hw_ctx for two contexts using the same actual context.
> +*/
> +   if (!shareCtx)
> +  brw->hw_ctx = drm_intel_gem_default_context_get(brw->bufmgr);
> +
> +   if (!brw->hw_ctx && brw->gen >= 6) {
>/* Create a new hardware context.  Using a hardware context means that
> * our GPU state will be saved/restored on context switch, allowing us
> * to assume that the GPU is in the same state we left it in.
> -- 
> 1.8.5.2
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] targets/opencl: resolve undefined symbols at link time

2014-02-23 Thread Francisco Jerez 
Emil Velikov  writes:

> Current automake build does not try to resolve undefined
> symbols thus we could end up with a broken library.
>
> Signed-off-by: Emil Velikov 

Looks good to me,
Reviewed-by: Francisco Jerez 

> ---
>  src/gallium/targets/opencl/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/targets/opencl/Makefile.am 
> b/src/gallium/targets/opencl/Makefile.am
> index 8eec405..91ec067 100644
> --- a/src/gallium/targets/opencl/Makefile.am
> +++ b/src/gallium/targets/opencl/Makefile.am
> @@ -4,6 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la
>  
>  lib@OPENCL_LIBNAME@_la_LDFLAGS = \
>   $(LLVM_LDFLAGS) \
> + -no-undefined \
>   -version-number 1:0
>  
>  lib@OPENCL_LIBNAME@_la_LIBADD = \
> -- 
> 1.9.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgpCWvpAJcPFZ.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] i965: Don't forget to subtract mt->first_level in minify calls.

2014-02-23 Thread Eric Anholt 
Kenneth Graunke  writes:

> This fixes fbo-clear-formats GL_ARB_depth_texture on Ironlake, which
> regressed since commit f128bcc7c293013f4b44e4b661638333de0077c2
> ("i965: Drop mt->levels[].width/height.")  intel_miptree_copy_slice was
> calling minify(.., 7) on a 2x2 texture with mt->first_level == 7.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75292
> Signed-off-by: Kenneth Graunke 
> Cc: Eric Anholt 

Yuck, forgot about firstlevel -- not sure I'd have done the change if
I'd thought about it, but since you've written the patch let's go with
it.  Hopefully some day we can figure out how to kill firstlevel.

Reviewed-by: Eric Anholt 


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

[Mesa-dev] [PATCH] pipe-loader: wrap pipe_loader_sw_probe_xlib within HAVE_PIPE_LOADER_XLIB

2014-02-23 Thread Emil Velikov 
The above function implies using the the xlib winsys, which
has additional library dependencies that should not be forced.

Make the software xlib pipe loader optional thus avoid all
the dependency hell. A user that wishes to use the particular
pipe-loader would need to set the following within configure.ac.

 enable_gallium_xlib_loader=yes

v2:
 - Wrap sw/xlib/xlib_sw_winsys.h to handle compilation on systems
lacking X11 headers. Spotted by Christian Prochaska.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75356
Signed-off-by: Emil Velikov 
---
 configure.ac   | 7 +++
 src/gallium/auxiliary/pipe-loader/Makefile.am  | 4 
 src/gallium/auxiliary/pipe-loader/pipe_loader.h| 4 ++--
 src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 5 -
 src/gallium/targets/gbm/Makefile.am| 7 +++
 src/gallium/targets/opencl/Makefile.am | 7 +++
 src/gallium/targets/xa/Makefile.am | 7 +++
 src/gallium/tests/trivial/Makefile.am  | 7 +++
 8 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 08aed4e..d42803c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1887,6 +1887,12 @@ AM_CONDITIONAL(NEED_GALLIUM_LLVMPIPE_DRIVER, test 
"x$HAVE_GALLIUM_I915" = xyes -
 if test "x$enable_gallium_loader" = xyes; then
 GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/null"
 
+if test "x$enable_gallium_xlib_loader" = xyes; then
+GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib"
+NEED_WINSYS_XLIB="yes"
+GALLIUM_PIPE_LOADER_DEFINES="$GALLIUM_PIPE_LOADER_DEFINES 
-DHAVE_PIPE_LOADER_XLIB"
+fi
+
 if test "x$enable_gallium_drm_loader" = xyes; then
 GALLIUM_PIPE_LOADER_DEFINES="$GALLIUM_PIPE_LOADER_DEFINES 
-DHAVE_PIPE_LOADER_DRM"
 PKG_CHECK_MODULES([GALLIUM_PIPE_LOADER_XCB], [xcb xcb-dri2],
@@ -1905,6 +1911,7 @@ if test "x$enable_gallium_loader" = xyes; then
 AC_SUBST([GALLIUM_PIPE_LOADER_CLIENT_DEFINES])
 AC_SUBST([GALLIUM_PIPE_LOADER_CLIENT_LIBS])
 fi
+AM_CONDITIONAL(NEED_PIPE_LOADER_XLIB, test "x$enable_gallium_xlib_loader" = 
xyes)
 
 AM_CONDITIONAL(HAVE_I915_DRI, test x$HAVE_I915_DRI = xyes)
 AM_CONDITIONAL(HAVE_I965_DRI, test x$HAVE_I965_DRI = xyes)
diff --git a/src/gallium/auxiliary/pipe-loader/Makefile.am 
b/src/gallium/auxiliary/pipe-loader/Makefile.am
index 232fe40..ccdbea5 100644
--- a/src/gallium/auxiliary/pipe-loader/Makefile.am
+++ b/src/gallium/auxiliary/pipe-loader/Makefile.am
@@ -8,10 +8,6 @@ AM_CPPFLAGS = $(DEFINES) \
-I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/gallium/winsys
 
-if NEED_WINSYS_XLIB
-AM_CPPFLAGS += -DHAVE_WINSYS_XLIB
-endif
-
 noinst_LTLIBRARIES =
 
 if HAVE_LOADER_GALLIUM
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index 125086d..a5e49fc 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -35,7 +35,7 @@
 
 #include "pipe/p_compiler.h"
 
-#ifdef HAVE_WINSYS_XLIB
+#ifdef HAVE_PIPE_LOADER_XLIB
 #include 
 #endif
 
@@ -105,7 +105,7 @@ pipe_loader_create_screen(struct pipe_loader_device *dev,
 void
 pipe_loader_release(struct pipe_loader_device **devs, int ndev);
 
-#ifdef HAVE_WINSYS_XLIB
+#ifdef HAVE_PIPE_LOADER_XLIB
 
 /**
  * Initialize Xlib for an associated display.
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index ece687b..35ec37f 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -31,7 +31,10 @@
 #include "util/u_dl.h"
 #include "sw/dri/dri_sw_winsys.h"
 #include "sw/null/null_sw_winsys.h"
+#ifdef HAVE_PIPE_LOADER_XLIB
+/* Explicitly wrap the header to ease build without X11 headers */
 #include "sw/xlib/xlib_sw_winsys.h"
+#endif
 #include "target-helpers/inline_sw_helper.h"
 #include "state_tracker/drisw_api.h"
 
@@ -49,7 +52,7 @@ static struct sw_winsys *(*backends[])() = {
null_sw_create
 };
 
-#ifdef HAVE_WINSYS_XLIB
+#ifdef HAVE_PIPE_LOADER_XLIB
 bool
 pipe_loader_sw_probe_xlib(struct pipe_loader_device **devs, Display *display)
 {
diff --git a/src/gallium/targets/gbm/Makefile.am 
b/src/gallium/targets/gbm/Makefile.am
index c0dcd8c..ecbb9ad 100644
--- a/src/gallium/targets/gbm/Makefile.am
+++ b/src/gallium/targets/gbm/Makefile.am
@@ -50,6 +50,13 @@ gbm_gallium_drm_la_LIBADD = \
$(LIBDRM_LIBS) \
-lm
 
+if NEED_PIPE_LOADER_XLIB
+gbm_gallium_drm_la_LIBADD += \
+   $(top_builddir)/src/gallium/winsys/sw/xlib/libws_xlib.la \
+   -lX11 -lXext -lXfixes \
+   $(LIBDRM_LIBS)
+endif
+
 gbm_gallium_drm_la_LDFLAGS = -no-undefined -avoid-version -module
 
 # FIXME: this shouldn't be needed
diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index 8eec405..e82889e 100644
--- a/src/gallium/targets/opencl/Mak

Re: [Mesa-dev] [RFC 08/27] i965/fs: Configure w-tiled stencil surfaces as y-tiled on gen6/7

2014-02-23 Thread Pohjolainen, Topi 
On Sat, Feb 22, 2014 at 03:48:40PM +0200, Pohjolainen, Topi wrote:
> On Sat, Feb 22, 2014 at 11:05:34AM +0200, Topi Pohjolainen wrote:
> > Signed-off-by: Topi Pohjolainen 
> > ---
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 28 
> > ++--
> >  1 file changed, 26 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > index 6f23cec..2e841d9 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -194,12 +194,36 @@ const struct intel_mipmap_tree *
> >  brw_get_texture_surface(const struct gl_texture_object *tex_obj,
> >  struct brw_wm_surface *surface)
> >  {
> > -   const struct intel_texture_object *intel_tex = 
> > intel_texture_object(tex_obj);
> > +   const struct intel_texture_object *intel_tex =
> > +  (const struct intel_texture_object *)tex_obj;
> 
> This actually belongs to patch number 6, I merged it to the wrong patch when I
> fixed compiler warning on intel_texture_object() needing non-constant pointer.
> 
> > const struct gl_texture_image *first = 
> > tex_obj->Image[0][tex_obj->BaseLevel];
> > const struct intel_mipmap_tree *mt = intel_tex->mt;
> >  
> > if (tex_obj->StencilSampling && first->_BaseFormat == GL_DEPTH_STENCIL) 
> > {
> > -  assert(!"Stencil indexing shouldn't be enabled yet");
> > +  const unsigned level = tex_obj->BaseLevel - mt->first_level;
> > +
> > +  mt = mt->stencil_mt;
> > +
> > +  /* Stencil is really W-tiled but as the hardware does not support
> > +   * sampling from it, it needs to be treated as Y-tiled with adjusted
> > +   * dimensions instead. Y-tiles are twice as wide and half as high as 
> > W.
> > +   * Also one needs to take into account that both tilings consist of
> > +   * 8x4 subtiles.
> > +   */
> > +  const unsigned x_align = 8, y_align = 4;
> > +
> > +  surface->tiling = I915_TILING_Y;
> > +  surface->width = ALIGN(minify(mt->physical_width0, level), x_align) 
> > * 2;
> > +  surface->height = ALIGN(minify(mt->physical_height0, level), 
> > y_align) / 2;
> > +  surface->pitch = 2 * mt->region->pitch;
> > +  surface->min_lod = 0;
> > +  surface->mip_count = 0;
> > +  surface->depth = 1;

And this needs to be "surface->depth = mt->logical_depth0;". I'm currently
working on piglit tests for layered stencil.

> > +
> > +  /* Texture surfaces are always resolved to the layer zero. */
> > +  surface->page_offset = intel_miptree_get_tile_offsets(
> > +mt, level, 0, true,
> > +&surface->tile_x, &surface->tile_y);
> > } else {
> >surface->tiling = mt->region->tiling;
> >surface->width = mt->logical_width0;
> > -- 
> > 1.8.3.1
> > 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Avoid dependency hints on math opcodes

2014-02-23 Thread Jordan Justen 
On Wed, Feb 12, 2014 at 9:25 PM, Ian Romanick  wrote:
> On 02/12/2014 06:59 PM, Matt Turner wrote:
>> On Wed, Feb 12, 2014 at 4:24 PM,   wrote:
>>> From: Mike Stroyan 
>>>
>>>   Putting NoDDClr and NoDDChk dependency control on instruction
>>> sequences that include math opcodes can cause corruption of channels.
>>> Treat math opcodes like send opcodes and suppress dependency hinting.
>>>
>>> Signed-off-by: Mike Stroyan 
>>> Tested-by: Tony Bertapelli 
>>> ---
>>>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
>>> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>>> index dd23ed4..1c42ca8 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>>> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>>> @@ -717,6 +717,14 @@ vec4_visitor::opt_set_dependency_control()
>>>  continue;
>>>   }
>>>
>>> + /* Dependency control does not work well over math instructions.
>>> +  */
>>> + if (inst->is_math()) {
>>> +memset(last_grf_write, 0, sizeof(last_grf_write));
>>> +memset(last_mrf_write, 0, sizeof(last_mrf_write));
>>> +continue;
>>> + }
>>> +
>>>   /* Now, see if we can do dependency control for this instruction
>>>* against a previous one writing to its destination.
>>>*/
>>> --
>>> 1.8.3.2
>>
>> I can't find any mention of this in the PRMs. Do we have a bug report
>> or something that this fixes?
>
> We have some code involving a lot of inversesqrt calls that I haven't
> quite turned into a shader_runner test yet... I also wonder if this
> could be related to the Dota2 too-much-specular bug, but I haven't tried
> that out yet either.

It didn't seem to help this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=74700

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

Re: [Mesa-dev] [PATCH 21/25] gallium/r300/r600/radeonsi: handle query_renderer caps

2014-02-23 Thread Michel Dänzer 
On Sam, 2014-02-22 at 03:04 +, Emil Velikov wrote:
> 
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 4e6478c..adbc981 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -341,6 +341,18 @@ static int si_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>   return 11;
>   case PIPE_CAP_MAX_GL_ES2_VERSION:
>   return 30;
> +
> + case PIPE_CAP_VENDOR_ID:
> + return 0x1002;
> + case PIPE_CAP_DEVICE_ID:
> + return sscreen->b.info.pci_id;
> + case PIPE_CAP_ACCELERATED:
> + return 1;
> + case PIPE_CAP_VIDEO_MEMORY:
> + /* XXX: Do we want to return vram_size or gart_size ? */
> + return sscreen->b.info.vram_size >> 20;

VRAM makes more sense to me. If you wanted to consider GTT as well,
you'd need to combine it with VRAM somehow, rather than just reporting
its size instead of VRAM.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

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

[Mesa-dev] [PATCH 4/4] glsl: Delete LRP_TO_ARITH lowering pass flag.

2014-02-23 Thread Kenneth Graunke 
Tt's kind of a trap---calling do_common_optimization() after
lower_instructions() may cause opt_algebraic() to reintroduce
ir_triop_lrp expressions that were lowered, effectively defeating the
point.  Because of this, nobody uses it.

Cc: "10.1" 
Signed-off-by: Kenneth Graunke 
---
 src/glsl/ir_optimization.h  |  5 ++---
 src/glsl/lower_instructions.cpp | 10 --
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index 055d655..1777b84 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -36,9 +36,8 @@
 #define LOG_TO_LOG20x10
 #define MOD_TO_FRACT   0x20
 #define INT_DIV_TO_MUL_RCP 0x40
-#define LRP_TO_ARITH   0x80
-#define BITFIELD_INSERT_TO_BFM_BFI 0x100
-#define LDEXP_TO_ARITH 0x200
+#define BITFIELD_INSERT_TO_BFM_BFI 0x80
+#define LDEXP_TO_ARITH 0x100
 
 /**
  * \see class lower_packing_builtins_visitor
diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
index 44a6e80..9c5e7b3 100644
--- a/src/glsl/lower_instructions.cpp
+++ b/src/glsl/lower_instructions.cpp
@@ -38,7 +38,6 @@
  * - LOG_TO_LOG2
  * - MOD_TO_FRACT
  * - LDEXP_TO_ARITH
- * - LRP_TO_ARITH
  * - BITFIELD_INSERT_TO_BFM_BFI
  *
  * SUB_TO_ADD_NEG:
@@ -87,10 +86,6 @@
  * -
  * Converts ir_binop_ldexp to arithmetic and bit operations.
  *
- * LRP_TO_ARITH:
- * -
- * Converts ir_triop_lrp to (op0 * (1.0f - op2)) + (op1 * op2).
- *
  * BITFIELD_INSERT_TO_BFM_BFI:
  * ---
  * Breaks ir_quadop_bitfield_insert into ir_binop_bfm (bitfield mask) and
@@ -499,11 +494,6 @@ lower_instructions_visitor::visit_leave(ir_expression *ir)
 pow_to_exp2(ir);
   break;
 
-   case ir_triop_lrp:
-  if (lowering(LRP_TO_ARITH))
-lrp_to_arith(ir);
-  break;
-
case ir_quadop_bitfield_insert:
   if (lowering(BITFIELD_INSERT_TO_BFM_BFI))
  bitfield_insert_to_bfm_bfi(ir);
-- 
1.9.0

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

[Mesa-dev] [PATCH 3/4] i965: Stop lowering ir_triop_lrp.

2014-02-23 Thread Kenneth Graunke 
Both the vector and scalar backends now support it natively, so there's
no point in lowering it.

Cc: "10.1" 
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_shader.cpp | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 643c140..36b3ae9 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -145,7 +145,6 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
   const int bitfield_insert = brw->gen >= 7
   ? BITFIELD_INSERT_TO_BFM_BFI
   : 0;
-  const int lrp_to_arith = brw->gen < 6 ? LRP_TO_ARITH : 0;
   lower_instructions(shader->base.ir,
 MOD_TO_FRACT |
 DIV_TO_MUL_RCP |
@@ -153,7 +152,6 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
 EXP_TO_EXP2 |
 LOG_TO_LOG2 |
  bitfield_insert |
- lrp_to_arith |
  LDEXP_TO_ARITH);
 
   /* Pre-gen6 HW can only nest if-statements 16 deep.  Beyond this,
-- 
1.9.0

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

[Mesa-dev] [PATCH 1/4] i965/vec4: Add a brw->gen >= 6 assertion in three-source emitters.

2014-02-23 Thread Kenneth Graunke 
Three source instructions didn't exist until Gen6.  vec4_generator has
assertions to catch this, but catching it in the visitor provides a
nicer backtrace.

Cc: "10.1" 
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index a2f7922..95e0064 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -128,6 +128,7 @@ vec4_visitor::emit(enum opcode opcode)
vec4_instruction *  \
vec4_visitor::op(dst_reg dst, src_reg src0, src_reg src1, src_reg src2)\
{   \
+  assert(brw->gen >= 6);   \
   return new(mem_ctx) vec4_instruction(this, BRW_OPCODE_##op, dst, \
   src0, src1, src2);   \
}
-- 
1.9.0

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

[Mesa-dev] [PATCH 2/4] i965/vec4: Handle ir_triop_lrp on Gen4-5 as well.

2014-02-23 Thread Kenneth Graunke 
When the vec4 backend encountered an ir_triop_lrp, it always emitted an
actual LRP instruction, which only exists on Gen6+.  Gen4-5 used
lower_instructions() to decompose ir_triop_lrp at the IR level.

Since commit 8d37e9915a3b21 ("glsl: Optimize open-coded lrp into lrp."),
we've had an bug where lower_instructions translates ir_triop_lrp into
arithmetic, but opt_algebraic reassembles it back into a lrp.

To avoid this ordering concern, just handle ir_triop_lrp in the backend.
The FS backend already does this, so we may as well do likewise.

Cc: "10.1" 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75253
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_vec4.h   |  3 +++
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 36 +-
 2 files changed, 32 insertions(+), 7 deletions(-)

This patch fixes a regression from 10.0 to 10.1, and really needs to be
cherry-picked before the final 10.1.0 release.

Technically, it's the only one that needs to be cherry-picked, but I figured
I may as well CC the whole series and leave it up to the stable maintainers.

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 6bd8b80..fb5c0a6 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -506,6 +506,9 @@ public:
 
void emit_minmax(uint32_t condmod, dst_reg dst, src_reg src0, src_reg src1);
 
+   void emit_lrp(const dst_reg &dst,
+ const src_reg &x, const src_reg &y, const src_reg &a);
+
void emit_block_move(dst_reg *dst, src_reg *src,
const struct glsl_type *type, uint32_t predicate);
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 95e0064..d4f1899 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1132,6 +1132,34 @@ vec4_visitor::emit_minmax(uint32_t conditionalmod, 
dst_reg dst,
}
 }
 
+void
+vec4_visitor::emit_lrp(const dst_reg &dst,
+   const src_reg &x, const src_reg &y, const src_reg &a)
+{
+   if (brw->gen >= 6) {
+  /* Note that the instruction's argument order is reversed from GLSL
+   * and the IR.
+   */
+  emit(LRP(dst,
+   fix_3src_operand(a), fix_3src_operand(y), fix_3src_operand(x)));
+   } else {
+  /* Earlier generations don't support three source operations, so we
+   * need to emit x*(1-a) + y*a.
+   */
+  dst_reg y_times_a   = dst_reg(this, glsl_type::vec4_type);
+  dst_reg one_minus_a = dst_reg(this, glsl_type::vec4_type);
+  dst_reg x_times_one_minus_a = dst_reg(this, glsl_type::vec4_type);
+  y_times_a.writemask   = dst.writemask;
+  one_minus_a.writemask = dst.writemask;
+  x_times_one_minus_a.writemask = dst.writemask;
+
+  emit(MUL(y_times_a, y, a));
+  emit(ADD(one_minus_a, negate(a), src_reg(1.0f)));
+  emit(MUL(x_times_one_minus_a, x, src_reg(one_minus_a)));
+  emit(ADD(dst, src_reg(x_times_one_minus_a), src_reg(y_times_a)));
+   }
+}
+
 static bool
 is_16bit_constant(ir_rvalue *rvalue)
 {
@@ -1628,13 +1656,7 @@ vec4_visitor::visit(ir_expression *ir)
   break;
 
case ir_triop_lrp:
-  op[0] = fix_3src_operand(op[0]);
-  op[1] = fix_3src_operand(op[1]);
-  op[2] = fix_3src_operand(op[2]);
-  /* Note that the instruction's argument order is reversed from GLSL
-   * and the IR.
-   */
-  emit(LRP(result_dst, op[2], op[1], op[0]));
+  emit_lrp(result_dst, op[0], op[1], op[2]);
   break;
 
case ir_triop_csel:
-- 
1.9.0

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

Re: [Mesa-dev] [PATCH 19/25] gallium/i915: handle query_renderer caps

2014-02-23 Thread Stéphane Marchesin 
On Sat, Feb 22, 2014 at 5:22 AM, Emil Velikov wrote:

> On 22/02/14 03:33, Stéphane Marchesin wrote:
> > On Fri, Feb 21, 2014 at 7:04 PM, Emil Velikov  >wrote:
> >
> >> Implementation is a verbatim copy from the classic driver.
> >>
> >> This introduces a driver dependency on libdrm-intel, as the winsys does
> not
> >> cache the aperture size of the device.
> >>
> >
> > Usually if you have to add calls into libdrm, you add them to the winsys,
> > and then add a new entry point to the winsys which you call... If you
> want
> > I can do it.
> >
> > I've been ensuring that the only place calling into libdrm was the winsys
> > so far. Whether or not we remove the sw winsys, I think it's a healthy
> > thing to do.
> >
> Agreed, keeping OS/platform specifics within the winsys is the way to do
> it.
>
> Should I store the device aperture size within i915_winsys or is there a
> more suitable place for it ? The current implementation is essentially a
> vtable for the drm/sw callbacks.
>

I would probably just add a function to the winsys to get the aperture
size. Basically copy-paste that big chunk of code from case
PIPE_CAP_VIDEO_MEMORY into int iws->aperture_size(struct i915_winsys *iws);

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

Re: [Mesa-dev] [PATCH] i965: Don't try to use the hardware blitter for multisampled miptrees.

2014-02-23 Thread Kenneth Graunke 
On 02/21/2014 08:20 PM, Paul Berry wrote:
> On 21 February 2014 19:15, Kenneth Graunke  > wrote:
> 
> The blitter is completely ignorant of MSAA buffer layouts, so any
> attempt to use BLT paths with MSAA buffers is likely to break
> spectacularly.
> 
> In most cases, BLORP handles MSAA blits, so we never hit this bug.
> Until recently, it also wasn't worth fixing, since Meta couldn't handle
> MSAA either, so there was nothing to fall back to.  But now there is.
> 
> +143 piglit tests on Broadwell (which doesn't have BLORP support).
> Surprisingly, three also start failing.  No changes on Ivybridge.
> 
> 
> That actually doesn't surprise me too much.  Since color buffers use an
> array-like sample layout (sample N in the Nth layer), trying to use the
> blitter on a multisampled buffer just gets you sample 0 from each pixel.
>  Which for some tests is good enough to pass (even though the blit is
> actually doing the wrong thing).  So it's possible that a few of these
> tests that were passing by luck with the blitter don't yet have proper
> Meta support :)

That makes a lot of sense.  For UMS buffers, it got sample 0, which was
enough to fool a few not-very-picky tests.  But it still wrongly ignored
samples >= 1.  And it would probably break horribly for IMS buffers.

I can definitely believe the meta code needs more baking. :)

> Signed-off-by: Kenneth Graunke  >
> ---
>  src/mesa/drivers/dri/i965/intel_blit.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
> b/src/mesa/drivers/dri/i965/intel_blit.c
> index df85dc9..cedb230 100644
> --- a/src/mesa/drivers/dri/i965/intel_blit.c
> +++ b/src/mesa/drivers/dri/i965/intel_blit.c
> @@ -165,6 +165,10 @@ intel_miptree_blit(struct brw_context *brw,
> mesa_format src_format =
> _mesa_get_srgb_format_linear(src_mt->format);
> mesa_format dst_format =
> _mesa_get_srgb_format_linear(dst_mt->format);
> 
> +   /* The blitter doesn't understand multisampling at all. */
> +   if (src_mt->num_samples > 0 || dst_mt->num_samples > 0)
> +  return false;
> +
> 
> 
> You might consider moving this check up to the top of the function,
> since it doesn't depend on src_format or dst_format.  But it's not a big
> deal.  Either way, the patch is:
> 
> Reviewed-by: Paul Berry  >

Done.  Thanks a ton for the review, Paul!

--Ken



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] glsl: Delete LRP_TO_ARITH lowering pass flag.

2014-02-23 Thread Matt Turner 
Series is

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

[Mesa-dev] [PATCH 1/2] mesa: Add core API support for GL_ARB_stencil_texturing (from 4.3).

2014-02-23 Thread Kenneth Graunke 
While the GL_ARB_stencil_texturing extension does not allow the creation
of stencil textures, it does allow shaders to sample stencil values
stored in packed depth/stencil textures.

Specifically, applications can call glTexParameter* with a pname of
GL_DEPTH_STENCIL_TEXTURE_MODE and value of either GL_DEPTH_COMPONENT or
GL_STENCIL_INDEX to select which component they wish to sample.  The
default value is GL_DEPTH_COMPONENT (for traditional depth sampling).

Shaders should use an unsigned integer sampler (presumably usampler2D)
to access stencil data.  Otherwise, results are undefined.  Using shadow
samplers with GL_STENCIL_INDEX selected also is undefined behavior.

This patch creates a new gl_texture_object field, StencilSampling, to
indicate that stencil should be sampled rather than depth.  (I chose to
use a boolean since I figured it would be more convenient for drivers.)
It also introduces the [Get]TexParameter code to get and set the value,
and of course the extension plumbing.

Signed-off-by: Kenneth Graunke 
---
 docs/GL3.txt|  2 +-
 src/mapi/glapi/gen/GL4x.xml |  2 +-
 src/mesa/main/extensions.c  |  1 +
 src/mesa/main/mtypes.h  |  2 ++
 src/mesa/main/texobj.c  |  2 ++
 src/mesa/main/texparam.c| 28 
 6 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 542ee28..33910ec 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -158,7 +158,7 @@ GL 4.3:
   GL_ARB_robust_buffer_access_behavior not started
   GL_ARB_shader_image_size not started
   GL_ARB_shader_storage_buffer_object  not started
-  GL_ARB_stencil_texturing not started
+  GL_ARB_stencil_texturing API exists, no drivers
   GL_ARB_texture_buffer_range  DONE (nv50, nvc0, i965, 
r600, radeonsi)
   GL_ARB_texture_query_levels  DONE (i965)
   GL_ARB_texture_storage_multisample   DONE (all drivers that 
support GL_ARB_texture_multisample)
diff --git a/src/mapi/glapi/gen/GL4x.xml b/src/mapi/glapi/gen/GL4x.xml
index 6706278..8efef0b 100644
--- a/src/mapi/glapi/gen/GL4x.xml
+++ b/src/mapi/glapi/gen/GL4x.xml
@@ -15,7 +15,7 @@
 
 
 
-
+  
 
 
 
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 2611db8..8712564 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -137,6 +137,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_shading_language_packing",
o(ARB_shading_language_packing),GL, 2011 },
{ "GL_ARB_shading_language_420pack",
o(ARB_shading_language_420pack),GL, 2011 },
{ "GL_ARB_shadow",  o(ARB_shadow),  
GLL,2001 },
+   { "GL_ARB_stencil_texturing",   o(ARB_stencil_texturing),   
GL, 2012 },
{ "GL_ARB_sync",o(ARB_sync),
GL, 2003 },
{ "GL_ARB_texture_border_clamp",
o(ARB_texture_border_clamp),GLL,2000 },
{ "GL_ARB_texture_buffer_object",   
o(ARB_texture_buffer_object),   GLC,2008 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index fbbca55..6da3eb6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1199,6 +1199,7 @@ struct gl_texture_object
struct gl_sampler_object Sampler;
 
GLenum DepthMode;   /**< GL_ARB_depth_texture */
+   bool StencilSampling;   /**< Should we sample stencil instead of depth? 
*/
 
GLfloat Priority;   /**< in [0,1] */
GLint BaseLevel;/**< min mipmap level, OpenGL 1.2 */
@@ -3509,6 +3510,7 @@ struct gl_extensions
GLboolean ARB_shading_language_packing;
GLboolean ARB_shading_language_420pack;
GLboolean ARB_shadow;
+   GLboolean ARB_stencil_texturing;
GLboolean ARB_sync;
GLboolean ARB_texture_border_clamp;
GLboolean ARB_texture_buffer_object;
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 6adc0ae..9ab539f 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -148,6 +148,7 @@ _mesa_initialize_texture_object( struct gl_context *ctx,
obj->Sampler.CompareMode = GL_NONE; /* ARB_shadow */
obj->Sampler.CompareFunc = GL_LEQUAL;   /* ARB_shadow */
obj->DepthMode = ctx->API == API_OPENGL_CORE ? GL_RED : GL_LUMINANCE;
+   obj->StencilSampling = false;
obj->Sampler.CubeMapSeamless = GL_FALSE;
obj->Swizzle[0] = GL_RED;
obj->Swizzle[1] = GL_GREEN;
@@ -280,6 +281,7 @@ _mesa_copy_texture_object( struct gl_texture_object *dest,
dest->Sampler.CompareFunc = src->Sampler.CompareFunc;
dest->Sampler.CubeMapSeamless = src->Sampler.CubeMapSeamless;
dest->DepthMode = src->Dept

[Mesa-dev] [PATCH 2/2] i965: Implement ARB_stencil_texturing on Gen8+.

2014-02-23 Thread Kenneth Graunke 
On earlier hardware, we had to implement math in the shader to translate
Y-tiled or untiled coordinates to W-tiled coordinates (which is what
BLORP does today in order to texture from stencil buffers).

On Broadwell, we can simply state that it's W-tiled in SURFACE_STATE,
and adjust the pitch.  This is much easier.

In the surface state code, I chose to handle the "should we sample depth
or stencil?" question separately from the setup for sampling from
stencil.  This should make it work with the BindRenderbufferTexImage
hook as well, and hopefully be reusable for GL_ARB_texture_stencil8
someday.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_defines.h |  1 +
 src/mesa/drivers/dri/i965/brw_surface_formats.c |  2 +-
 src/mesa/drivers/dri/i965/gen8_surface_state.c  | 17 ++---
 src/mesa/drivers/dri/i965/intel_extensions.c|  4 
 4 files changed, 20 insertions(+), 4 deletions(-)

Passes my Piglit test (which Topi reviewed and I already pushed).

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 01d3cb6..8a4879b 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -264,6 +264,7 @@
 #define GEN8_SURFACE_HALIGN_8   (2 << 14)
 #define GEN8_SURFACE_HALIGN_16  (3 << 14)
 #define GEN8_SURFACE_TILING_NONE(0 << 12)
+#define GEN8_SURFACE_TILING_W   (1 << 12)
 #define GEN8_SURFACE_TILING_X   (2 << 12)
 #define GEN8_SURFACE_TILING_Y   (3 << 12)
 #define BRW_SURFACE_RC_READ_WRITE  (1 << 8)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 9acece5..0c95e86 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -363,7 +363,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
   [MESA_FORMAT_Z24_UNORM_X8_UINT] = 0,
   [MESA_FORMAT_X8Z24_UNORM] = 0,
   [MESA_FORMAT_Z_UNORM32] = 0,
-  [MESA_FORMAT_S_UINT8] = 0,
+  [MESA_FORMAT_S_UINT8] = BRW_SURFACEFORMAT_R8_UINT,
 
   [MESA_FORMAT_BGR_SRGB8] = 0,
   [MESA_FORMAT_A8B8G8R8_SRGB] = 0,
diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c 
b/src/mesa/drivers/dri/i965/gen8_surface_state.c
index 594e531..27af6ad 100644
--- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
@@ -139,6 +139,18 @@ gen8_update_texture_surface(struct gl_context *ctx,
   return;
}
 
+   if (tObj->StencilSampling && firstImage->_BaseFormat == GL_DEPTH_STENCIL)
+  mt = mt->stencil_mt;
+
+   unsigned tiling_mode, pitch;
+   if (mt->format == MESA_FORMAT_S_UINT8) {
+  tiling_mode = GEN8_SURFACE_TILING_W;
+  pitch = 2 * mt->region->pitch;
+   } else {
+  tiling_mode = surface_tiling_mode(mt->region->tiling);
+  pitch = mt->region->pitch;
+   }
+
uint32_t tex_format = translate_tex_format(brw,
   mt->format,
   sampler->sRGBDecode);
@@ -150,7 +162,7 @@ gen8_update_texture_surface(struct gl_context *ctx,
  tex_format << BRW_SURFACE_FORMAT_SHIFT |
  vertical_alignment(mt) |
  horizontal_alignment(mt) |
- surface_tiling_mode(mt->region->tiling);
+ tiling_mode;
 
if (tObj->Target == GL_TEXTURE_CUBE_MAP ||
tObj->Target == GL_TEXTURE_CUBE_MAP_ARRAY) {
@@ -165,8 +177,7 @@ gen8_update_texture_surface(struct gl_context *ctx,
surf[2] = SET_FIELD(mt->logical_width0 - 1, GEN7_SURFACE_WIDTH) |
  SET_FIELD(mt->logical_height0 - 1, GEN7_SURFACE_HEIGHT);
 
-   surf[3] = SET_FIELD(mt->logical_depth0 - 1, BRW_SURFACE_DEPTH) |
- (mt->region->pitch - 1);
+   surf[3] = SET_FIELD(mt->logical_depth0 - 1, BRW_SURFACE_DEPTH) | (pitch - 
1);
 
surf[4] = gen7_surface_msaa_bits(mt->num_samples, mt->msaa_layout);
 
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index ef9aa55..5094c2b 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -303,6 +303,10 @@ intelInitExtensions(struct gl_context *ctx)
  ctx->Extensions.ARB_compute_shader = true;
}
 
+   if (brw->gen >= 8) {
+  ctx->Extensions.ARB_stencil_texturing = true;
+   }
+
if (brw->gen == 5 || can_write_oacontrol(brw))
   ctx->Extensions.AMD_performance_monitor = true;
 
-- 
1.8.4.2

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

Re: [Mesa-dev] [PATCH 2/2] i965: Implement ARB_stencil_texturing on Gen8+.

2014-02-23 Thread Matt Turner 
On Sun, Feb 23, 2014 at 9:59 PM, Kenneth Graunke  wrote:
> On earlier hardware, we had to implement math in the shader to translate
> Y-tiled or untiled coordinates to W-tiled coordinates (which is what
> BLORP does today in order to texture from stencil buffers).
>
> On Broadwell, we can simply state that it's W-tiled in SURFACE_STATE,
> and adjust the pitch.  This is much easier.
>
> In the surface state code, I chose to handle the "should we sample depth
> or stencil?" question separately from the setup for sampling from
> stencil.  This should make it work with the BindRenderbufferTexImage
> hook as well, and hopefully be reusable for GL_ARB_texture_stencil8
> someday.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_defines.h |  1 +
>  src/mesa/drivers/dri/i965/brw_surface_formats.c |  2 +-
>  src/mesa/drivers/dri/i965/gen8_surface_state.c  | 17 ++---
>  src/mesa/drivers/dri/i965/intel_extensions.c|  4 
>  4 files changed, 20 insertions(+), 4 deletions(-)
>
> Passes my Piglit test (which Topi reviewed and I already pushed).
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 01d3cb6..8a4879b 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -264,6 +264,7 @@
>  #define GEN8_SURFACE_HALIGN_8   (2 << 14)
>  #define GEN8_SURFACE_HALIGN_16  (3 << 14)
>  #define GEN8_SURFACE_TILING_NONE(0 << 12)
> +#define GEN8_SURFACE_TILING_W   (1 << 12)
>  #define GEN8_SURFACE_TILING_X   (2 << 12)
>  #define GEN8_SURFACE_TILING_Y   (3 << 12)
>  #define BRW_SURFACE_RC_READ_WRITE  (1 << 8)
> diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
> b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> index 9acece5..0c95e86 100644
> --- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
> +++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> @@ -363,7 +363,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
>[MESA_FORMAT_Z24_UNORM_X8_UINT] = 0,
>[MESA_FORMAT_X8Z24_UNORM] = 0,
>[MESA_FORMAT_Z_UNORM32] = 0,
> -  [MESA_FORMAT_S_UINT8] = 0,
> +  [MESA_FORMAT_S_UINT8] = BRW_SURFACEFORMAT_R8_UINT,
>
>[MESA_FORMAT_BGR_SRGB8] = 0,
>[MESA_FORMAT_A8B8G8R8_SRGB] = 0,
> diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c 
> b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> index 594e531..27af6ad 100644
> --- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> @@ -139,6 +139,18 @@ gen8_update_texture_surface(struct gl_context *ctx,
>return;
> }
>
> +   if (tObj->StencilSampling && firstImage->_BaseFormat == GL_DEPTH_STENCIL)
> +  mt = mt->stencil_mt;
> +
> +   unsigned tiling_mode, pitch;
> +   if (mt->format == MESA_FORMAT_S_UINT8) {
> +  tiling_mode = GEN8_SURFACE_TILING_W;
> +  pitch = 2 * mt->region->pitch;

Why do we multiply by two?

You updated GL3.txt in the last patch. Need to update it here too?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] mesa: Add core API support for GL_ARB_stencil_texturing (from 4.3).

2014-02-23 Thread Matt Turner 
Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75061] bug in clearing color buffer

2014-02-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=75061

Michel Dänzer  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|Other   |Drivers/Gallium/r600

--- Comment #11 from Michel Dänzer  ---
AFAICT the problem is that both threads access the same struct r600_resource
concurrently. It might be relatively easy to avoid the crashes by updating the
buf member atomically in r600_init_resource() instead of setting it to NULL
first in r600_invalidate_buffer(), but I suspect there could be more subtle
issues with other members, in particular valid_buffer_range.

Marek, any thoughts on how to solve this?

-- 
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