Re: [Mesa-dev] [PATCH 1/7] egl/dri2: Check return value of __DRI2fence::create_fence()

2015-05-01 Thread Chad Versace 
On Fri 01 May 2015, Matt Turner wrote:
 On Fri, May 1, 2015 at 1:01 PM, Chad Versace chad.vers...@intel.com wrote:
  From: Chad Versace c...@kiwitree.net
 
 Different From: email address?

Oops. I forgot to configure my local .git/config after a fresh clone.
Thanks for catching that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=85203

--- Comment #12 from Michel Dänzer mic...@daenzer.net ---
(In reply to spam from comment #11)
 for me the system randomly hard freezes, too.
 
 i find these warnings in Xorg.log but nothing else:
 
 [  6064.296] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
 completion event has impossible msc 362422  target_msc 362423

Once again, it's unlikely that freezes are directly related to these messages,
which should be basically harmless. People experiencing freezes should file
separate reports about those.

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

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=85203

s...@abma.de changed:

   What|Removed |Added

 CC||s...@abma.de

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

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=85203

--- Comment #14 from s...@abma.de ---
ok, filled a new bug report: https://bugs.freedesktop.org/show_bug.cgi?id=90278

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

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=85203

--- Comment #13 from s...@abma.de ---
i can always reproduce the crash when running this tool:
https://github.com/abma/qvdpautest

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

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=85203

--- Comment #11 from s...@abma.de ---
for me the system randomly hard freezes, too.

i find these warnings in Xorg.log but nothing else:

[  6064.296] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 362422  target_msc 362423
[  6069.799] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 362751  target_msc 362752
[  6069.868] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 362754  target_msc 362755
[  6169.680] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 368733  target_msc 368734


i've a Radeon HD 5750.

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

[Mesa-dev] RFC Fast batch and relocation handling for i965

2015-05-01 Thread Chris Wilson 
Relocation processing is a significant overhead of heavy batches. The
kernel tries to make this as cheap as possible by avoiding as much work
as possible, but to be truly lazy requires userspace to construct its
batches and relocation trees in a convenient manner for processing.

Kristian made an attempt to enable libdrm_intel to supply its
execbuffers in this format,

http://lists.freedesktop.org/archives/intel-gfx/2015-January/058550.html

This is my batchmgr concept from that thread.
-Chris

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

[Mesa-dev] [PATCH 3/4] i965: Move pipecontrol workaround bo to brw_pipe_control

2015-05-01 Thread Chris Wilson 
With the exception of gen8, the sole user of the workaround bo are for
emitting pipe controls. More it out of the purview of the batchbuffer
and into the pipecontrol.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 src/mesa/drivers/dri/i965/brw_context.c   |  7 +
 src/mesa/drivers/dri/i965/brw_context.h   | 13 +
 src/mesa/drivers/dri/i965/brw_pipe_control.c  | 40 +++
 src/mesa/drivers/dri/i965/gen8_depth_state.c  |  2 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 
 src/mesa/drivers/dri/i965/intel_extensions.c  | 28 +--
 6 files changed, 64 insertions(+), 38 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 0f2f9ad..7be3f5c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -822,6 +822,12 @@ brwCreateContext(gl_api api,
   }
}
 
+   if (brw_init_pipe_control(brw, devinfo)) {
+  *dri_ctx_error = __DRI_CTX_ERROR_NO_MEMORY;
+  intelDestroyContext(driContextPriv);
+  return false;
+   }
+
brw_init_state(brw);
 
intelInitExtensions(ctx);
@@ -940,6 +946,7 @@ intelDestroyContext(__DRIcontext * driContextPriv)
if (ctx-swrast_context)
   _swrast_DestroyContext(brw-ctx);
 
+   brw_fini_pipe_control(brw);
intel_batchbuffer_free(brw);
 
drm_intel_bo_unreference(brw-throttle_batch[1]);
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 8269db0..54f0dee 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -867,8 +867,6 @@ struct intel_batchbuffer {
drm_intel_bo *bo;
/** Last BO submitted to the hardware.  Used for glFinish(). */
drm_intel_bo *last_bo;
-   /** BO for post-sync nonzero writes for gen6 workaround. */
-   drm_intel_bo *workaround_bo;
 
uint16_t emit, total;
uint16_t used, reserved_space;
@@ -880,8 +878,6 @@ struct intel_batchbuffer {
enum brw_gpu_ring ring;
bool needs_sol_reset;
 
-   uint8_t pipe_controls_since_last_cs_stall;
-
struct {
   uint16_t used;
   int reloc_count;
@@ -1017,6 +1013,10 @@ struct brw_context
 
drm_intel_context *hw_ctx;
 
+   /** BO for post-sync nonzero writes for gen6 workaround. */
+   drm_intel_bo *workaround_bo;
+   uint8_t pipe_controls_since_last_cs_stall;
+
/**
 * Set of drm_intel_bo * that have been rendered to within this batchbuffer
 * and would need flushing before being used from another cache domain that
@@ -1946,6 +1946,10 @@ gen6_upload_push_constants(struct brw_context *brw,
enum aub_state_struct_type type);
 
 /* brw_pipe_control.c */
+int brw_init_pipe_control(struct brw_context *brw,
+ const struct brw_device_info *info);
+void brw_fini_pipe_control(struct brw_context *brw);
+
 void brw_emit_pipe_control_flush(struct brw_context *brw, uint32_t flags);
 void brw_emit_pipe_control_write(struct brw_context *brw, uint32_t flags,
  drm_intel_bo *bo, uint32_t offset,
@@ -1956,7 +1960,6 @@ void brw_emit_depth_stall_flushes(struct brw_context 
*brw);
 void gen7_emit_vs_workaround_flush(struct brw_context *brw);
 void gen7_emit_cs_stall_flush(struct brw_context *brw);
 
-
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
index dfef436..37080bf 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -76,13 +76,13 @@ gen7_cs_stall_every_four_pipe_controls(struct brw_context 
*brw, uint32_t flags)
if (brw-gen == 7  !brw-is_haswell) {
   if (flags  PIPE_CONTROL_CS_STALL) {
  /* If we're doing a CS stall, reset the counter and carry on. */
- brw-batch.pipe_controls_since_last_cs_stall = 0;
+ brw-pipe_controls_since_last_cs_stall = 0;
  return 0;
   }
 
   /* If this is the fourth pipe control without a CS stall, do one now. */
-  if (++brw-batch.pipe_controls_since_last_cs_stall == 4) {
- brw-batch.pipe_controls_since_last_cs_stall = 0;
+  if (++brw-pipe_controls_since_last_cs_stall == 4) {
+ brw-pipe_controls_since_last_cs_stall = 0;
  return PIPE_CONTROL_CS_STALL;
   }
}
@@ -217,7 +217,7 @@ gen7_emit_vs_workaround_flush(struct brw_context *brw)
brw_emit_pipe_control_write(brw,
PIPE_CONTROL_WRITE_IMMEDIATE
| PIPE_CONTROL_DEPTH_STALL,
-   brw-batch.workaround_bo, 0,
+   brw-workaround_bo, 0,
0, 0);
 }
 
@@ -231,7 +231,7 @@ gen7_emit_cs_stall_flush(struct brw_context *brw)
brw_emit_pipe_control_write(brw,
PIPE_CONTROL_CS_STALL
|

[Mesa-dev] [PATCH 1/4] i965: Transplant PIPE_CONTROL routines to brw_pipe_control

2015-05-01 Thread Chris Wilson 
Start trimming the fat from intel_batchbuffer.c. First by moving the set
of routines for emitting PIPE_CONTROLS (along with the lore concerning
hardware workarounds) to a separate brw_pipe_control.c

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 src/mesa/drivers/dri/i965/Makefile.sources|   1 +
 src/mesa/drivers/dri/i965/brw_context.h   |  12 +
 src/mesa/drivers/dri/i965/brw_pipe_control.c  | 335 ++
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 304 ---
 src/mesa/drivers/dri/i965/intel_batchbuffer.h |  10 -
 5 files changed, 348 insertions(+), 314 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/brw_pipe_control.c

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index 6d4659f..a9f9129 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -82,6 +82,7 @@ i965_FILES = \
brw_object_purgeable.c \
brw_packed_float.c \
brw_performance_monitor.c \
+   brw_pipe_control.c \
brw_primitive_restart.c \
brw_program.c \
brw_program.h \
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index e2f26f5..7241816 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1945,6 +1945,18 @@ gen6_upload_push_constants(struct brw_context *brw,
struct brw_stage_state *stage_state,
enum aub_state_struct_type type);
 
+/* brw_pipe_control.c */
+void brw_emit_pipe_control_flush(struct brw_context *brw, uint32_t flags);
+void brw_emit_pipe_control_write(struct brw_context *brw, uint32_t flags,
+ drm_intel_bo *bo, uint32_t offset,
+ uint32_t imm_lower, uint32_t imm_upper);
+void intel_batchbuffer_emit_mi_flush(struct brw_context *brw);
+void intel_emit_post_sync_nonzero_flush(struct brw_context *brw);
+void intel_emit_depth_stall_flushes(struct brw_context *brw);
+void gen7_emit_vs_workaround_flush(struct brw_context *brw);
+void gen7_emit_cs_stall_flush(struct brw_context *brw);
+
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
new file mode 100644
index 000..c216f6d
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -0,0 +1,335 @@
+/**
+ *
+ * Copyright 2006 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include brw_context.h
+#include intel_batchbuffer.h
+#include intel_fbo.h
+#include intel_reg.h
+
+/**
+ * According to the latest documentation, any PIPE_CONTROL with the
+ * Command Streamer Stall bit set must also have another bit set,
+ * with five different options:
+ *
+ *  - Render Target Cache Flush
+ *  - Depth Cache Flush
+ *  - Stall at Pixel Scoreboard
+ *  - Post-Sync Operation
+ *  - Depth Stall
+ *
+ * I chose Stall at Pixel Scoreboard since we've used it effectively
+ * in the past, but the choice is fairly arbitrary.
+ */
+static void
+gen8_add_cs_stall_workaround_bits(uint32_t *flags)
+{
+   uint32_t wa_bits = PIPE_CONTROL_RENDER_TARGET_FLUSH |
+  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+  PIPE_CONTROL_WRITE_IMMEDIATE |
+  PIPE_CONTROL_WRITE_DEPTH_COUNT |
+  PIPE_CONTROL_WRITE_TIMESTAMP |
+  PIPE_CONTROL_STALL_AT_SCOREBOARD |
+  PIPE_CONTROL_DEPTH_STALL;
+
+   /* If we're doing a CS stall, and don't already have one of the
+* workaround bits set, add Stall at Pixel Scoreboard.
+*/
+   if ((*flags

Re: [Mesa-dev] [PATCH 11/13] nir/nir: Use a linked list instead of a has set for use/def sets

2015-05-01 Thread Jason Ekstrand 
On Apr 30, 2015 10:05 PM, Connor Abbott cwabbo...@gmail.com wrote:

typedef struct nir_src {
   union {
   +  nir_instr *parent_instr;
   +  struct nir_if *parent_if;
   +   };
   +
   +   struct list_head use_link;
 
  So I was thinking about this, and I realized that putting the list
  link here would mean that having SSA-only sources, like my experiments
  with making derefs instructions, would be a massive pain. Making a
  separate nir_ssa_src to put the use_link and parent_instr/parent_if in
  seems like a lot more churn, but would it be harder/even more churn to
  do it after this series rather than as a part of it? I don't think it
  necessitates re-doing everything or giving up entirely, but I thought
  it would be useful to note. I guess we could always use the full
  nir_src and then do an assert(is_ssa) in the validator.
 
  We could also put it in nir_reg_src and nir_ssa_src.  Since the list is
  embedded in a ssa value, we know what kind of source it is.  It would
mean
  that we would have to split up the iterators though. Not a big deal.
 

 The issue is that nir_ssa_src doesn't exist -- we directly embed the
 nir_ssa_def pointer in nir_src. So we would have to replace every
 occurrence of foo-src[0].ssa foo[0]-src[0].ssa.def and fixup all the
 function definitions, hence all the extra churn.

Right... Yeah, assertions sound better if that's what we want to do.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl: Remove skeleton implementation of EGL_MESA_screen_surface

2015-05-01 Thread Adam Jackson 
No backend wires this up to anything, and the extension spec has been
marked obsolete for 4+ years.

Signed-off-by: Adam Jackson a...@redhat.com
---
 include/EGL/eglmesaext.h  |  46 --
 src/egl/main/Makefile.sources |   4 -
 src/egl/main/eglapi.c | 278 
 src/egl/main/eglapi.h |  31 
 src/egl/main/eglconfig.c  |   4 -
 src/egl/main/eglcurrent.c |   8 -
 src/egl/main/egldisplay.h |   1 -
 src/egl/main/eglfallbacks.c   |  18 ---
 src/egl/main/eglmode.c| 357 --
 src/egl/main/eglmode.h|  88 ---
 src/egl/main/eglscreen.c  | 235 ---
 src/egl/main/eglscreen.h  | 117 --
 src/egl/main/eglsurface.c |  55 ---
 13 files changed, 1242 deletions(-)
 delete mode 100644 src/egl/main/eglmode.c
 delete mode 100644 src/egl/main/eglmode.h
 delete mode 100644 src/egl/main/eglscreen.c
 delete mode 100644 src/egl/main/eglscreen.h

diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index 595babd..d344e7c 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -34,52 +34,6 @@ extern C {
 
 #include EGL/eglplatform.h
 
-/* EGL_MESA_screen extension   PRELIMINARY  */
-#ifndef EGL_MESA_screen_surface
-#define EGL_MESA_screen_surface 1
-
-#define EGL_BAD_SCREEN_MESA0x4000
-#define EGL_BAD_MODE_MESA  0x4001
-#define EGL_SCREEN_COUNT_MESA  0x4002
-#define EGL_SCREEN_POSITION_MESA   0x4003
-#define EGL_SCREEN_POSITION_GRANULARITY_MESA   0x4004
-#define EGL_MODE_ID_MESA   0x4005
-#define EGL_REFRESH_RATE_MESA  0x4006
-#define EGL_OPTIMAL_MESA   0x4007
-#define EGL_INTERLACED_MESA0x4008
-#define EGL_SCREEN_BIT_MESA0x08
-
-typedef khronos_uint32_t EGLScreenMESA;
-typedef khronos_uint32_t EGLModeMESA;
-
-#ifdef EGL_EGLEXT_PROTOTYPES
-EGLAPI EGLBoolean EGLAPIENTRY eglChooseModeMESA(EGLDisplay dpy, EGLScreenMESA 
screen, const EGLint *attrib_list, EGLModeMESA *modes, EGLint modes_size, 
EGLint *num_modes);
-EGLAPI EGLBoolean EGLAPIENTRY eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA 
screen, EGLModeMESA *modes, EGLint modes_size, EGLint *num_modes);
-EGLAPI EGLBoolean EGLAPIENTRY eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA 
mode, EGLint attribute, EGLint *value);
-EGLAPI EGLBoolean EGLAPIENTRY eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA 
*screens, EGLint max_screens, EGLint *num_screens);
-EGLAPI EGLSurface EGLAPIENTRY eglCreateScreenSurfaceMESA(EGLDisplay dpy, 
EGLConfig config, const EGLint *attrib_list);
-EGLAPI EGLBoolean EGLAPIENTRY eglShowScreenSurfaceMESA(EGLDisplay dpy, EGLint 
screen, EGLSurface surface, EGLModeMESA mode);
-EGLAPI EGLBoolean EGLAPIENTRY eglScreenPositionMESA(EGLDisplay dpy, 
EGLScreenMESA screen, EGLint x, EGLint y);
-EGLAPI EGLBoolean EGLAPIENTRY eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA 
screen, EGLint attribute, EGLint *value);
-EGLAPI EGLBoolean EGLAPIENTRY eglQueryScreenSurfaceMESA(EGLDisplay dpy, 
EGLScreenMESA screen, EGLSurface *surface);
-EGLAPI EGLBoolean EGLAPIENTRY eglQueryScreenModeMESA(EGLDisplay dpy, 
EGLScreenMESA screen, EGLModeMESA *mode);
-EGLAPI const char * EGLAPIENTRY eglQueryModeStringMESA(EGLDisplay dpy, 
EGLModeMESA mode);
-#endif /* EGL_EGLEXT_PROTOTYPES */
-
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLCHOOSEMODEMESA) (EGLDisplay dpy, 
EGLScreenMESA screen, const EGLint *attrib_list, EGLModeMESA *modes, EGLint 
modes_size, EGLint *num_modes);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLGETMODESMESA) (EGLDisplay dpy, 
EGLScreenMESA screen, EGLModeMESA *modes, EGLint modes_size, EGLint *num_modes);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLGetModeATTRIBMESA) (EGLDisplay dpy, 
EGLModeMESA mode, EGLint attribute, EGLint *value);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLGETSCRREENSMESA) (EGLDisplay dpy, 
EGLScreenMESA *screens, EGLint max_screens, EGLint *num_screens);
-typedef EGLSurface (EGLAPIENTRYP PFNEGLCREATESCREENSURFACEMESA) (EGLDisplay 
dpy, EGLConfig config, const EGLint *attrib_list);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLSHOWSCREENSURFACEMESA) (EGLDisplay dpy, 
EGLint screen, EGLSurface surface, EGLModeMESA mode);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLSCREENPOSIITONMESA) (EGLDisplay dpy, 
EGLScreenMESA screen, EGLint x, EGLint y);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYSCREENMESA) (EGLDisplay dpy, 
EGLScreenMESA screen, EGLint attribute, EGLint *value);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYSCREENSURFACEMESA) (EGLDisplay 
dpy, EGLScreenMESA screen, EGLSurface *surface);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYSCREENMODEMESA) (EGLDisplay dpy, 
EGLScreenMESA screen, EGLModeMESA *mode);
-typedef const char * (EGLAPIENTRYP PFNEGLQUERYMODESTRINGMESA) (EGLDisplay dpy, 
EGLModeMESA mode);
-
-#endif /* EGL_MESA_screen_surface */
-
 #ifndef EGL_MESA_copy_context
 #define EGL_MESA_copy_context 1

Re: [Mesa-dev] [PATCH 5/6] i965/skl: Align compressed textures to four times the block size

2015-05-01 Thread Neil Roberts 
Sorry for the really long delay in replying! This patch is still needed
in order to fix a number of Piglit tests so it would be good to get it
landed.

Ben Widawsky b...@bwidawsk.net writes:

 Sorry for the delay, but I put this off initially because I wasn't
 sure which part of the docs this was addressing. I see that the
 Surface Horizontal Alignment field is now used for compressed formats.
 Assuming that's what this is referring to (if not, please correct
 me)...

Yes, that's right.

 The only thing that appears to be missing is the handling of the MCS
 case (must always be 16) which may or may not be relevant. AFAICT,
 it's a possible scenario.

The MCS buffer is only used when rendering right? I don't think it is
possible or would make sense to render to a compressed buffer. There is
already a section at the bottom of the function to handle the alignment
for uncompressed buffers when there is an MCS buffer. If it were
possible to use a compressed buffer with an MCS buffer then it would be
broken anyway even without this patch because it would just return the
block size which wouldn't be 16.

 Also, doesn't this make FXT1 have an alignment of 32?

Yes, but bear in mind that a row of 32 pixels only takes up 4 blocks so
that is only 64 bytes. I guess that is still quite a lot but if that's
what the hardware requires then that's what we have to do.

 if (_mesa_is_format_compressed(format))
 -  return 4;
 +  /* See comment above for the horizontal alignment */
 +  return brw-gen = 9 ? 16 : 4;

 This seems okay since the max height we support is 4.

What do you mean by the max height? I think previously this was just
hardcoding the block height to 4 so I am just bumping the alignment to
16 to represent 4 blocks.

 These hunks look okay to me. Any particular reason not to update
 brw_miptree_layout_texture_array as well? I am pretty certain we don't
 use ALL_SLICES_AT_EACH_LOD in Gen9 today, but presumably we could,
 right? /me shrugs

We actually can't use ALL_SLICES_AT_EACH_LOD on Gen9 (see the earlier
patches) but yes, brw_miptree_layout_texture_array needs to work for 2D
array textures. However I don't think anything needs changing there. The
only changes I made to brw_miptree_layout_2d were because it was
assuming that mt-align_w/h is always equal to the compressed block size
but with this patch that is no longer the case. I only changed the
places that wanted the block size so that they would use a separate
variable instead of conflating it with the alignment. I don't think
anything in brw_miptree_layout_texture_array needs to refer to the block
size so it should be ok.

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

[Mesa-dev] [PATCH 2/4] i915: Rename intel_emit* to reflect their new location in brw_pipe_control

2015-05-01 Thread Chris Wilson 
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp | 4 ++--
 src/mesa/drivers/dri/i965/brw_clear.c   | 4 ++--
 src/mesa/drivers/dri/i965/brw_context.h | 6 +++---
 src/mesa/drivers/dri/i965/brw_draw.c| 4 ++--
 src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 4 ++--
 src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c   | 8 
 src/mesa/drivers/dri/i965/brw_meta_updownsample.c   | 4 ++--
 src/mesa/drivers/dri/i965/brw_misc_state.c  | 2 +-
 src/mesa/drivers/dri/i965/brw_performance_monitor.c | 8 
 src/mesa/drivers/dri/i965/brw_pipe_control.c| 8 
 src/mesa/drivers/dri/i965/brw_state_upload.c| 4 ++--
 src/mesa/drivers/dri/i965/gen6_blorp.cpp| 6 +++---
 src/mesa/drivers/dri/i965/gen6_depth_state.c| 2 +-
 src/mesa/drivers/dri/i965/gen6_queryobj.c   | 6 +++---
 src/mesa/drivers/dri/i965/gen6_sol.c| 2 +-
 src/mesa/drivers/dri/i965/gen6_urb.c| 2 +-
 src/mesa/drivers/dri/i965/gen7_blorp.cpp| 4 ++--
 src/mesa/drivers/dri/i965/gen7_misc_state.c | 2 +-
 src/mesa/drivers/dri/i965/gen7_sol_state.c  | 4 ++--
 src/mesa/drivers/dri/i965/gen8_depth_state.c| 2 +-
 src/mesa/drivers/dri/i965/intel_blit.c  | 6 +++---
 src/mesa/drivers/dri/i965/intel_buffer_objects.c| 4 ++--
 src/mesa/drivers/dri/i965/intel_extensions.c| 6 +++---
 src/mesa/drivers/dri/i965/intel_fbo.c   | 2 +-
 src/mesa/drivers/dri/i965/intel_syncobj.c   | 2 +-
 25 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index b404869..2ccfae1 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -220,7 +220,7 @@ brw_blorp_exec(struct brw_context *brw, const 
brw_blorp_params *params)
 * data with different formats, which blorp does for stencil and depth
 * data.
 */
-   intel_batchbuffer_emit_mi_flush(brw);
+   brw_emit_mi_flush(brw);
 
 retry:
intel_batchbuffer_require_space(brw, estimated_max_batch_usage, 
RENDER_RING);
@@ -283,7 +283,7 @@ retry:
/* Flush the sampler cache so any texturing from the destination is
 * coherent.
 */
-   intel_batchbuffer_emit_mi_flush(brw);
+   brw_emit_mi_flush(brw);
 }
 
 brw_hiz_op_params::brw_hiz_op_params(struct intel_mipmap_tree *mt,
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 1231420..a6524aa 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -183,7 +183,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
 *  must be issued before the rectangle primitive used for the depth
 *  buffer clear operation.
 */
-   intel_batchbuffer_emit_mi_flush(brw);
+   brw_emit_mi_flush(brw);
 
if (fb-MaxNumLayers  0) {
   for (unsigned layer = 0; layer  depth_irb-layer_count; layer++) {
@@ -203,7 +203,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
*  by a PIPE_CONTROL command with DEPTH_STALL bit set and Then
*  followed by Depth FLUSH'
   */
-  intel_batchbuffer_emit_mi_flush(brw);
+  brw_emit_mi_flush(brw);
}
 
/* Now, the HiZ buffer contains data that needs to be resolved to the depth
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 7241816..8269db0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1950,9 +1950,9 @@ void brw_emit_pipe_control_flush(struct brw_context *brw, 
uint32_t flags);
 void brw_emit_pipe_control_write(struct brw_context *brw, uint32_t flags,
  drm_intel_bo *bo, uint32_t offset,
  uint32_t imm_lower, uint32_t imm_upper);
-void intel_batchbuffer_emit_mi_flush(struct brw_context *brw);
-void intel_emit_post_sync_nonzero_flush(struct brw_context *brw);
-void intel_emit_depth_stall_flushes(struct brw_context *brw);
+void brw_emit_mi_flush(struct brw_context *brw);
+void brw_emit_post_sync_nonzero_flush(struct brw_context *brw);
+void brw_emit_depth_stall_flushes(struct brw_context *brw);
 void gen7_emit_vs_workaround_flush(struct brw_context *brw);
 void gen7_emit_cs_stall_flush(struct brw_context *brw);
 
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 96e2369..ac8daaf 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -214,7 +214,7 @@ static void brw_emit_prim(struct brw_context *brw,
 * the besides the draw code.
 */
if (brw-always_flush_cache) {
-  intel_batchbuffer_emit_mi_flush(brw);
+  brw_emit_mi_flush(brw);
}
 
/* If indirect, emit a bunch of loads from the indirect BO. */
@@ -277,7 +277,7 @@ static void

[Mesa-dev] [PATCH] Fix possible memory leaks

2015-05-01 Thread Daniel Winzen 
Signed-off-by: Daniel Winzen d...@winzen4.de
---
 src/gallium/state_trackers/xa/xa_tracker.c | 4 +++-
 src/glx/apple/apple_glx_log.c  | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/xa/xa_tracker.c 
b/src/gallium/state_trackers/xa/xa_tracker.c
index 8901998..5b6c3f9 100644
--- a/src/gallium/state_trackers/xa/xa_tracker.c
+++ b/src/gallium/state_trackers/xa/xa_tracker.c
@@ -151,8 +151,10 @@ xa_tracker_create(int drm_fd)
 (void) loader_fd; /* silence unused var warning */
 #else
 loader_fd = dup(drm_fd);
-if (loader_fd == -1)
+if (loader_fd == -1) {
+free(xa);
 return NULL;
+}
 if (pipe_loader_drm_probe_fd(xa-dev, loader_fd, false))
xa-screen = pipe_loader_create_screen(xa-dev, PIPE_SEARCH_DIR);
 #endif
diff --git a/src/glx/apple/apple_glx_log.c b/src/glx/apple/apple_glx_log.c
index 5b9a865..a40b678 100644
--- a/src/glx/apple/apple_glx_log.c
+++ b/src/glx/apple/apple_glx_log.c
@@ -96,6 +96,7 @@ void _apple_glx_vlog(int level, const char *file, const char 
*function,
 fprintf(stderr, %-9s %24s:%-4d %s(%PRIu64): ,
 _asl_level_string(level), file, line, function, thread);
 vfprintf(stderr, fmt, args2);
+va_end(args2);
 }
 
 msg = asl_new(ASL_TYPE_MSG);
-- 
2.1.4

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

Re: [Mesa-dev] [PATCH 08/38] main: Refactor get_texture_for_framebuffer.

2015-05-01 Thread Fredrik Höglund 
On Wednesday 04 March 2015, Laura Ekstrand wrote:
 This moves a few blocks around so that the control flow is more obvious.  If
 the texture is 0, just return true at the beginning of the function.
 Likewise, if the texObj is NULL, return true at the beginning of the funciton
 as well.
 ---
  src/mesa/main/fbobject.c | 43 +--
  1 file changed, 21 insertions(+), 22 deletions(-)
 
 diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
 index 143c6b4..f86e1a0 100644
 --- a/src/mesa/main/fbobject.c
 +++ b/src/mesa/main/fbobject.c
 @@ -2437,17 +2437,34 @@ get_texture_for_framebuffer(struct gl_context *ctx,
  struct gl_texture_object **texObj)
  {
 GLenum maxLevelsTarget;
 +   GLboolean err = GL_TRUE;
  
 *texObj = NULL; /* This will get returned if texture = 0. */
  
 /* The textarget, level, and zoffset parameters are only validated if
  * texture is non-zero.
  */
 -   if (texture) {
 -  GLboolean err = GL_TRUE;
 +   if (!texture)
 +  return true;
 +
 +   *texObj = _mesa_lookup_texture(ctx, texture);
 +   if (!texObj) {

One more thing: this line is NULL-checking the wrong pointer.
It should be checking *texObj.

 +  /* Can't render to a non-existant texture object.
 +   *
 +   * The OpenGL 4.5 core spec (02.02.2015) in Section 9.2 Binding and
 +   * Managing Framebuffer Objects specifies a different error
 +   * depending upon the calling function (PDF pages 325-328).
 +   * *FramebufferTexture (where *layered = GL_TRUE) throws invalid
 +   * value, while the other commands throw invalid operation (where
 +   * *layered = GL_FALSE).
 +   */
 +  GLenum no_texobj_err = *layered ? GL_INVALID_VALUE :
 + GL_INVALID_OPERATION;
 +  _mesa_error(ctx, no_texobj_err,
 +  %s(non-generated texture %u), caller, texture);
 +  return false;
 +   }
  
 -  *texObj = _mesa_lookup_texture(ctx, texture);
 -  if (*texObj != NULL) {
   if (textarget == 0) {
  if (*layered) {
 /* We're being called by gl*FramebufferTexture() and textarget
 @@ -2496,23 +2513,6 @@ get_texture_for_framebuffer(struct gl_context *ctx,
  ? !_mesa_is_cube_face(textarget)
  : ((*texObj)-Target != textarget);
   }
 -  }
 -  else {
 - /* Can't render to a non-existant texture object.
 -  *
 -  * The OpenGL 4.5 core spec (02.02.2015) in Section 9.2 Binding and
 -  * Managing Framebuffer Objects specifies a different error
 -  * depending upon the calling function (PDF pages 325-328).
 -  * *FramebufferTexture (where *layered = GL_TRUE) throws invalid
 -  * value, while the other commands throw invalid operation (where
 -  * *layered = GL_FALSE).
 -  */
 - GLenum no_texobj_err = *layered ? GL_INVALID_VALUE :
 -GL_INVALID_OPERATION;
 - _mesa_error(ctx, no_texobj_err,
 - %s(non-generated texture %u), caller, texture);
 - return false;
 -  }
  
if (err) {
   _mesa_error(ctx, GL_INVALID_OPERATION,
 @@ -2546,7 +2546,6 @@ get_texture_for_framebuffer(struct gl_context *ctx,
   %s(invalid level %d), caller, level);
   return false;
}
 -   }
  
 return true;
  }
 

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

[Mesa-dev] [PATCH] egl/drm: Try to use CLOEXEC for drm fds

2015-05-01 Thread Derek Foreman 
These fds can propagate to child processes if we don't set CLOEXEC,
so make a best effort to do that.

Signed-off-by: Derek Foreman der...@osg.samsung.com
---
Noticed this when fixing up similar problems in weston - weston's
drm fd gets dup()ed here and loses CLOEXEC and ends up in every child
process the shell launches.

 src/egl/drivers/dri2/platform_drm.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 486b003..c326d6c 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -596,7 +596,11 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
struct dri2_egl_display *dri2_dpy;
struct gbm_device *gbm;
int fd = -1;
-   int i;
+   int i, flags = O_RDWR;
+
+#ifdef O_CLOEXEC
+   flags |= O_CLOEXEC;
+#endif
 
loader_set_logger(_eglLog);
 
@@ -611,9 +615,9 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
   char buf[64];
   int n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0);
   if (n != -1  n  sizeof(buf))
- fd = open(buf, O_RDWR);
+ fd = open(buf, flags);
   if (fd  0)
- fd = open(/dev/dri/card0, O_RDWR);
+ fd = open(/dev/dri/card0, flags);
   dri2_dpy-own_device = 1;
   gbm = gbm_create_device(fd);
   if (gbm == NULL)
@@ -639,6 +643,10 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
   }
}
 
+   flags = fcntl(dri2_dpy-fd, F_GETFD);
+   if (flags = 0  !(flags  FD_CLOEXEC))
+  fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+
dri2_dpy-fd = fd;
dri2_dpy-device_name = loader_get_device_name_for_fd(dri2_dpy-fd);
dri2_dpy-driver_name = strdup(dri2_dpy-gbm_dri-base.driver_name);
-- 
2.1.4

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

[Mesa-dev] [PATCH 3/7] i915/sync: Don't crash when deleting sync object

2015-05-01 Thread Chad Versace 
From: Chad Versace c...@kiwitree.net

Don't pass NULL to drm_intel_bo_unreference(). It doesn't like that.

Bug found by code inspection.
---
 src/mesa/drivers/dri/i915/intel_syncobj.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i915/intel_syncobj.c 
b/src/mesa/drivers/dri/i915/intel_syncobj.c
index d918cd7..92a246d 100644
--- a/src/mesa/drivers/dri/i915/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i915/intel_syncobj.c
@@ -60,7 +60,9 @@ intel_delete_sync_object(struct gl_context *ctx, struct 
gl_sync_object *s)
 {
struct intel_sync_object *sync = (struct intel_sync_object *)s;
 
-   drm_intel_bo_unreference(sync-bo);
+   if (sync-bo)
+  drm_intel_bo_unreference(sync-bo);
+
free(sync);
 }
 
-- 
2.4.0

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

[Mesa-dev] [PATCH 2/7] i965/sync: Don't crash when deleting sync object

2015-05-01 Thread Chad Versace 
From: Chad Versace c...@kiwitree.net

Don't pass NULL to drm_intel_bo_unreference(). It doesn't like that.

Bug found by code inspection.
---
 src/mesa/drivers/dri/i965/intel_syncobj.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c 
b/src/mesa/drivers/dri/i965/intel_syncobj.c
index e500fa0..3bc32df 100644
--- a/src/mesa/drivers/dri/i965/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i965/intel_syncobj.c
@@ -59,7 +59,9 @@ intel_delete_sync_object(struct gl_context *ctx, struct 
gl_sync_object *s)
 {
struct intel_sync_object *sync = (struct intel_sync_object *)s;
 
-   drm_intel_bo_unreference(sync-bo);
+   if (sync-bo)
+  drm_intel_bo_unreference(sync-bo);
+
free(sync);
 }
 
-- 
2.4.0

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

[Mesa-dev] [PATCH 1/7] egl/dri2: Check return value of __DRI2fence::create_fence()

2015-05-01 Thread Chad Versace 
From: Chad Versace c...@kiwitree.net

If it returns NULL, then return early with an error.

Cc: Marek Olšák marek.ol...@amd.com
---
 src/egl/drivers/dri2/egl_dri2.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 34d6bfe..c2a856f 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2232,6 +2232,13 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
switch (type) {
case EGL_SYNC_FENCE_KHR:
   dri2_sync-fence = dri2_dpy-fence-create_fence(dri2_ctx-dri_context);
+  if (!dri2_sync-fence) {
+ /* Why did it fail? DRI doesn't return an error code, so we emit
+  * a generic EGL error that doesn't communicate user error. */
+ _eglError(EGL_BAD_ALLOC, eglCreateSyncKHR);
+ free(dri2_sync);
+ return NULL;
+  }
   break;
 
case EGL_SYNC_CL_EVENT_KHR:
-- 
2.4.0

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

Re: [Mesa-dev] [PATCH 1/7] egl/dri2: Check return value of __DRI2fence::create_fence()

2015-05-01 Thread Matt Turner 
On Fri, May 1, 2015 at 1:01 PM, Chad Versace chad.vers...@intel.com wrote:
 From: Chad Versace c...@kiwitree.net

Different From: email address?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90275] Mesa 10.4.2 implementation error: Unexpected format PIPE_FORMAT_R8G8B8_UNORM in st_new_renderbuffer_fb

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=90275

bo hu b...@google.com changed:

   What|Removed |Added

 CC||b...@google.com

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

[Mesa-dev] [PATCH 6/7] i965/sync: Replace prefix 'intel_sync' - 'intel_gl_sync'

2015-05-01 Thread Chad Versace 
I'm about to implement DRI2_Fenc in intel_syncobj.c.  To prevent
madness, we need to prefix functions for GL_ARB_sync with 'gl' and
functions for DRI2_Fence with 'dri'. Otherwise, the file will become
a jumble of similiarly named functions.

For example:
old-name:  intel_client_wait_sync()
new-name:  intel_gl_client_wait_sync()
soon-to-come:  intel_dri_client_wait_sync()

I wrote this renaming commit separately from the commit that implements
DRI2_Fence because I wanted the latter diff to be reviewable.
---
 src/mesa/drivers/dri/i965/brw_context.h   |  7 -
 src/mesa/drivers/dri/i965/intel_syncobj.c | 52 ++-
 2 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index e2f26f5..9d8eb1a 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -849,13 +849,6 @@ struct brw_query_object {
bool flushed;
 };
 
-struct intel_sync_object {
-   struct gl_sync_object Base;
-
-   /** Batch associated with this sync object */
-   drm_intel_bo *bo;
-};
-
 enum brw_gpu_ring {
UNKNOWN_RING,
RENDER_RING,
diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c 
b/src/mesa/drivers/dri/i965/intel_syncobj.c
index a425b9e..dea6dba 100644
--- a/src/mesa/drivers/dri/i965/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i965/intel_syncobj.c
@@ -44,12 +44,19 @@
 #include intel_batchbuffer.h
 #include intel_reg.h
 
+struct intel_gl_sync_object {
+   struct gl_sync_object Base;
+
+   /** Batch associated with this sync object */
+   drm_intel_bo *bo;
+};
+
 static struct gl_sync_object *
-intel_new_sync_object(struct gl_context *ctx, GLuint id)
+intel_gl_new_sync_object(struct gl_context *ctx, GLuint id)
 {
-   struct intel_sync_object *sync;
+   struct intel_gl_sync_object *sync;
 
-   sync = calloc(1, sizeof(struct intel_sync_object));
+   sync = calloc(1, sizeof(*sync));
if (!sync)
   return NULL;
 
@@ -57,9 +64,9 @@ intel_new_sync_object(struct gl_context *ctx, GLuint id)
 }
 
 static void
-intel_delete_sync_object(struct gl_context *ctx, struct gl_sync_object *s)
+intel_gl_delete_sync_object(struct gl_context *ctx, struct gl_sync_object *s)
 {
-   struct intel_sync_object *sync = (struct intel_sync_object *)s;
+   struct intel_gl_sync_object *sync = (struct intel_gl_sync_object *)s;
 
if (sync-bo)
   drm_intel_bo_unreference(sync-bo);
@@ -68,11 +75,11 @@ intel_delete_sync_object(struct gl_context *ctx, struct 
gl_sync_object *s)
 }
 
 static void
-intel_fence_sync(struct gl_context *ctx, struct gl_sync_object *s,
-  GLenum condition, GLbitfield flags)
+intel_gl_fence_sync(struct gl_context *ctx, struct gl_sync_object *s,
+GLenum condition, GLbitfield flags)
 {
struct brw_context *brw = brw_context(ctx);
-   struct intel_sync_object *sync = (struct intel_sync_object *)s;
+   struct intel_gl_sync_object *sync = (struct intel_gl_sync_object *)s;
 
assert(condition == GL_SYNC_GPU_COMMANDS_COMPLETE);
intel_batchbuffer_emit_mi_flush(brw);
@@ -83,10 +90,11 @@ intel_fence_sync(struct gl_context *ctx, struct 
gl_sync_object *s,
intel_batchbuffer_flush(brw);
 }
 
-static void intel_client_wait_sync(struct gl_context *ctx, struct 
gl_sync_object *s,
-GLbitfield flags, GLuint64 timeout)
+static void
+intel_gl_client_wait_sync(struct gl_context *ctx, struct gl_sync_object *s,
+  GLbitfield flags, GLuint64 timeout)
 {
-   struct intel_sync_object *sync = (struct intel_sync_object *)s;
+   struct intel_gl_sync_object *sync = (struct intel_gl_sync_object *)s;
 
/* DRM_IOCTL_I915_GEM_WAIT uses a signed 64 bit timeout and returns
 * immediately for timeouts = 0.  The best we can do is to clamp the
@@ -108,14 +116,15 @@ static void intel_client_wait_sync(struct gl_context 
*ctx, struct gl_sync_object
  * any batchbuffers coming after this waitsync will naturally not occur until
  * the previous one is done.
  */
-static void intel_server_wait_sync(struct gl_context *ctx, struct 
gl_sync_object *s,
-GLbitfield flags, GLuint64 timeout)
+static void
+intel_gl_server_wait_sync(struct gl_context *ctx, struct gl_sync_object *s,
+  GLbitfield flags, GLuint64 timeout)
 {
 }
 
 static void intel_check_sync(struct gl_context *ctx, struct gl_sync_object *s)
 {
-   struct intel_sync_object *sync = (struct intel_sync_object *)s;
+   struct intel_gl_sync_object *sync = (struct intel_gl_sync_object *)s;
 
if (sync-bo  !drm_intel_bo_busy(sync-bo)) {
   drm_intel_bo_unreference(sync-bo);
@@ -124,12 +133,13 @@ static void intel_check_sync(struct gl_context *ctx, 
struct gl_sync_object *s)
}
 }
 
-void intel_init_syncobj_functions(struct dd_function_table *functions)
+void
+intel_init_syncobj_functions(struct dd_function_table *functions)
 {
-   functions-NewSyncObject =

[Mesa-dev] [PATCH 4/7] i965/sync: Return NULL when calloc fails

2015-05-01 Thread Chad Versace 
---
 src/mesa/drivers/dri/i965/intel_syncobj.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c 
b/src/mesa/drivers/dri/i965/intel_syncobj.c
index 3bc32df..a425b9e 100644
--- a/src/mesa/drivers/dri/i965/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i965/intel_syncobj.c
@@ -50,6 +50,8 @@ intel_new_sync_object(struct gl_context *ctx, GLuint id)
struct intel_sync_object *sync;
 
sync = calloc(1, sizeof(struct intel_sync_object));
+   if (!sync)
+  return NULL;
 
return sync-Base;
 }
-- 
2.4.0

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

[Mesa-dev] [PATCH 7/7] i965/sync: Implement DRI2_Fence extension

2015-05-01 Thread Chad Versace 
From: Chad Versace c...@kiwitree.net

This enables EGL_KHR_fence_sync and EGL_KHR_wait_sync.

Below is the difference in piglit results, before and after this patch.
No regressions and several tests improve from 'skip' to 'pass'. Out of
EGL_KHR_fence_sync tests, two of the multithreaded tests skip; all other
tests pass.

  cmdline: piglit run -p gbm -t sync tests/quick.py
  mesa: master@1ac7db0
  piglit: 4069bec
  hw: Ivybridge

| before after
  --+-
   pass | 3246
   fail |  0 0
  crash |  0 0
   skip | 3521
  total | 6767
---
 docs/relnotes/10.6.0.html |   4 +-
 src/mesa/drivers/dri/i965/intel_screen.c  |   2 +
 src/mesa/drivers/dri/i965/intel_screen.h  |   4 +
 src/mesa/drivers/dri/i965/intel_syncobj.c | 190 --
 4 files changed, 159 insertions(+), 41 deletions(-)

diff --git a/docs/relnotes/10.6.0.html b/docs/relnotes/10.6.0.html
index fbc4d5b..82001e1 100644
--- a/docs/relnotes/10.6.0.html
+++ b/docs/relnotes/10.6.0.html
@@ -59,8 +59,8 @@ Note: some of the new features are only available with 
certain drivers.
 liGL_ARB_uniform_buffer_object on freedreno/li
 liGL_EXT_draw_buffers2 on freedreno/li
 liGL_OES_EGL_sync on all drivers/li
-liEGL_KHR_fence_sync on freedreno, nv50, nvc0, r600, radeonsi/li
-liEGL_KHR_wait_sync on freedreno, nv50, nvc0, r600, radeonsi/li
+liEGL_KHR_fence_sync on i965, freedreno, nv50, nvc0, r600, radeonsi/li
+liEGL_KHR_wait_sync on i965, freedreno, nv50, nvc0, r600, radeonsi/li
 liEGL_KHR_cl_event2 on freedreno, nv50, nvc0, r600, radeonsi/li
 /ul
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 92e638f..2e7adfa 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -909,6 +909,7 @@ static const __DRIrobustnessExtension dri2Robustness = {
 
 static const __DRIextension *intelScreenExtensions[] = {
 intelTexBufferExtension.base,
+intelFenceExtension.base,
 intelFlushExtension.base,
 intelImageExtension.base,
 intelRendererQueryExtension.base,
@@ -918,6 +919,7 @@ static const __DRIextension *intelScreenExtensions[] = {
 
 static const __DRIextension *intelRobustScreenExtensions[] = {
 intelTexBufferExtension.base,
+intelFenceExtension.base,
 intelFlushExtension.base,
 intelImageExtension.base,
 intelRendererQueryExtension.base,
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
b/src/mesa/drivers/dri/i965/intel_screen.h
index f814ed0..e7a1490 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -30,6 +30,9 @@
 
 #include stdbool.h
 #include sys/time.h
+
+#include GL/internal/dri_interface.h
+
 #include dri_util.h
 #include intel_bufmgr.h
 #include brw_device_info.h
@@ -76,6 +79,7 @@ extern void intelDestroyContext(__DRIcontext * 
driContextPriv);
 extern GLboolean intelUnbindContext(__DRIcontext * driContextPriv);
 
 PUBLIC const __DRIextension **__driDriverGetExtensions_i965(void);
+extern const __DRI2fenceExtension intelFenceExtension;
 
 extern GLboolean
 intelMakeCurrent(__DRIcontext * driContextPriv,
diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c 
b/src/mesa/drivers/dri/i965/intel_syncobj.c
index dea6dba..952be92 100644
--- a/src/mesa/drivers/dri/i965/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i965/intel_syncobj.c
@@ -25,11 +25,11 @@
  *
  */
 
-/** @file intel_syncobj.c
+/**
+ * \file
+ * \brief Support for GL_ARB_sync and EGL_KHR_fence_sync.
  *
- * Support for ARB_sync
- *
- * ARB_sync is implemented by flushing the current batchbuffer and keeping a
+ * GL_ARB_sync is implemented by flushing the current batchbuffer and keeping a
  * reference on it.  We can then check for completion or wait for completion
  * using the normal buffer object mechanisms.  This does mean that if an
  * application is using many sync objects, it will emit small batchbuffers
@@ -44,13 +44,93 @@
 #include intel_batchbuffer.h
 #include intel_reg.h
 
+struct brw_fence {
+   /** The fence waits for completion of this batch. */
+   drm_intel_bo *batch_bo;
+
+   bool signalled;
+};
+
 struct intel_gl_sync_object {
struct gl_sync_object Base;
-
-   /** Batch associated with this sync object */
-   drm_intel_bo *bo;
+   struct brw_fence fence;
 };
 
+static void
+brw_fence_finish(struct brw_fence *fence)
+{
+   if (fence-batch_bo)
+  drm_intel_bo_unreference(fence-batch_bo);
+}
+
+static void
+brw_fence_insert(struct brw_context *brw, struct brw_fence *fence)
+{
+   assert(!fence-batch_bo);
+   assert(!fence-signalled);
+
+   intel_batchbuffer_emit_mi_flush(brw);
+   fence-batch_bo = brw-batch.bo;
+   drm_intel_bo_reference(fence-batch_bo);
+   intel_batchbuffer_flush(brw);
+}
+
+static bool
+brw_fence_has_completed(struct brw_fence *fence)
+{
+   if (fence-signalled)
+  return true;
+
+   if (fence-batch_bo  !drm_intel_bo_busy(fence-batch_bo)) {
+

[Mesa-dev] [PATCH 5/7] i915/sync: Return early when calloc fails

2015-05-01 Thread Chad Versace 
---
 src/mesa/drivers/dri/i915/intel_syncobj.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i915/intel_syncobj.c 
b/src/mesa/drivers/dri/i915/intel_syncobj.c
index 92a246d..92b5b63 100644
--- a/src/mesa/drivers/dri/i915/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i915/intel_syncobj.c
@@ -51,6 +51,8 @@ intel_new_sync_object(struct gl_context *ctx, GLuint id)
struct intel_sync_object *sync;
 
sync = calloc(1, sizeof(struct intel_sync_object));
+   if (!sync)
+  return NULL;
 
return sync-Base;
 }
-- 
2.4.0

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

[Mesa-dev] [PATCH 0/7] i965: Enable EGL_KHR_fence_sync

2015-05-01 Thread Chad Versace 
The first 6 patches are small cleanups. The real implementation is patch
7/7. Enabling EGL_KHR_fence_sync also gives us EGL_KHR_wait_sync for
free.

This series lives on the tag:
git://github.com/chadversary/mesa
i965-egl-khr-fence-sync-v01

Chad Versace (7):
  egl/dri2: Check return value of __DRI2fence::create_fence()
  i965/sync: Don't crash when deleting sync object
  i915/sync: Don't crash when deleting sync object
  i965/sync: Return NULL when calloc fails
  i915/sync: Return early when calloc fails
  i965/sync: Replace prefix 'intel_sync' - 'intel_gl_sync'
  i965/sync: Implement DRI2_Fence extension

 docs/relnotes/10.6.0.html |   4 +-
 src/egl/drivers/dri2/egl_dri2.c   |   7 +
 src/mesa/drivers/dri/i915/intel_syncobj.c |   6 +-
 src/mesa/drivers/dri/i965/brw_context.h   |   7 -
 src/mesa/drivers/dri/i965/intel_screen.c  |   2 +
 src/mesa/drivers/dri/i965/intel_screen.h  |   4 +
 src/mesa/drivers/dri/i965/intel_syncobj.c | 230 +++---
 7 files changed, 198 insertions(+), 62 deletions(-)

-- 
2.4.0

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

Re: [Mesa-dev] [PATCH 1/4] i965: Transplant PIPE_CONTROL routines to brw_pipe_control

2015-05-01 Thread Kenneth Graunke 
On Friday, May 01, 2015 03:53:40 PM Chris Wilson wrote:
 Start trimming the fat from intel_batchbuffer.c. First by moving the set
 of routines for emitting PIPE_CONTROLS (along with the lore concerning
 hardware workarounds) to a separate brw_pipe_control.c
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  src/mesa/drivers/dri/i965/Makefile.sources|   1 +
  src/mesa/drivers/dri/i965/brw_context.h   |  12 +
  src/mesa/drivers/dri/i965/brw_pipe_control.c  | 335 
 ++
  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 304 ---
  src/mesa/drivers/dri/i965/intel_batchbuffer.h |  10 -
  5 files changed, 348 insertions(+), 314 deletions(-)
  create mode 100644 src/mesa/drivers/dri/i965/brw_pipe_control.c
 
 diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
 b/src/mesa/drivers/dri/i965/Makefile.sources
 index 6d4659f..a9f9129 100644
 --- a/src/mesa/drivers/dri/i965/Makefile.sources
 +++ b/src/mesa/drivers/dri/i965/Makefile.sources
 @@ -82,6 +82,7 @@ i965_FILES = \
   brw_object_purgeable.c \
   brw_packed_float.c \
   brw_performance_monitor.c \
 + brw_pipe_control.c \
   brw_primitive_restart.c \
   brw_program.c \
   brw_program.h \
 diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
 b/src/mesa/drivers/dri/i965/brw_context.h
 index e2f26f5..7241816 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.h
 +++ b/src/mesa/drivers/dri/i965/brw_context.h
 @@ -1945,6 +1945,18 @@ gen6_upload_push_constants(struct brw_context *brw,
 struct brw_stage_state *stage_state,
 enum aub_state_struct_type type);
  
 +/* brw_pipe_control.c */
 +void brw_emit_pipe_control_flush(struct brw_context *brw, uint32_t flags);
 +void brw_emit_pipe_control_write(struct brw_context *brw, uint32_t flags,
 + drm_intel_bo *bo, uint32_t offset,
 + uint32_t imm_lower, uint32_t imm_upper);
 +void intel_batchbuffer_emit_mi_flush(struct brw_context *brw);
 +void intel_emit_post_sync_nonzero_flush(struct brw_context *brw);
 +void intel_emit_depth_stall_flushes(struct brw_context *brw);
 +void gen7_emit_vs_workaround_flush(struct brw_context *brw);
 +void gen7_emit_cs_stall_flush(struct brw_context *brw);
 +
 +
  #ifdef __cplusplus
  }
  #endif
 diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
 b/src/mesa/drivers/dri/i965/brw_pipe_control.c
 new file mode 100644
 index 000..c216f6d
 --- /dev/null
 +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
 @@ -0,0 +1,335 @@
 +/**
 + *
 + * Copyright 2006 VMware, Inc.
 + * All Rights Reserved.
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the
 + * Software), to deal in the Software without restriction, including
 + * without limitation the rights to use, copy, modify, merge, publish,
 + * distribute, sub license, and/or sell copies of the Software, and to
 + * permit persons to whom the Software is furnished to do so, subject to
 + * the following conditions:
 + *
 + * The above copyright notice and this permission notice (including the
 + * next paragraph) shall be included in all copies or substantial portions
 + * of the Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
 + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
 + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
 + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 + *
 + **/

I did a bit of archaeology, and all of the Tungsten Graphics code appears to
be long gone:

   gen8_add_cs_stall_workaround_bits - me (2014)
   gen7_cs_stall_every_four_pipe_controls - me (2014)
   brw_emit_pipe_control_flush - me (2013)
   brw_emit_pipe_control_write - me (2013)
   intel_emit_post_sync_nonzero_flush - Eric (2011)
   intel_emit_depth_stall_flushes - me (2011)
   gen7_emit_vs_workaround_flush - me (2012)
   gen7_emit_cs_stall_flush - Paul (2013)
   intel_batchbuffer_emit_mi_flush - Zhenyu (2010), Eric, and I

So I'd use this copyright instead (with more typical formatting):

/*
 * Copyright © 2010 Intel Corporation
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the Software),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 *

Re: [Mesa-dev] [PATCH 11/13] nir/nir: Use a linked list instead of a has set for use/def sets

2015-05-01 Thread Dylan Baker 
You have a typo in the subject line: s/has/hash


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

Re: [Mesa-dev] [PATCH 5/6] i965/skl: Align compressed textures to four times the block size

2015-05-01 Thread Ben Widawsky 
On Fri, May 01, 2015 at 04:54:36PM +0100, Neil Roberts wrote:
 Sorry for the really long delay in replying! This patch is still needed
 in order to fix a number of Piglit tests so it would be good to get it
 landed.
 
 Ben Widawsky b...@bwidawsk.net writes:
 
  Sorry for the delay, but I put this off initially because I wasn't
  sure which part of the docs this was addressing. I see that the
  Surface Horizontal Alignment field is now used for compressed formats.
  Assuming that's what this is referring to (if not, please correct
  me)...
 
 Yes, that's right.
 
  The only thing that appears to be missing is the handling of the MCS
  case (must always be 16) which may or may not be relevant. AFAICT,
  it's a possible scenario.
 
 The MCS buffer is only used when rendering right? I don't think it is
 possible or would make sense to render to a compressed buffer. There is
 already a section at the bottom of the function to handle the alignment
 for uncompressed buffers when there is an MCS buffer. If it were
 possible to use a compressed buffer with an MCS buffer then it would be
 broken anyway even without this patch because it would just return the
 block size which wouldn't be 16.
 
  Also, doesn't this make FXT1 have an alignment of 32?
 
 Yes, but bear in mind that a row of 32 pixels only takes up 4 blocks so
 that is only 64 bytes. I guess that is still quite a lot but if that's
 what the hardware requires then that's what we have to do.
 
  if (_mesa_is_format_compressed(format))
  -  return 4;
  +  /* See comment above for the horizontal alignment */
  +  return brw-gen = 9 ? 16 : 4;
 
  This seems okay since the max height we support is 4.
 
 What do you mean by the max height? I think previously this was just
 hardcoding the block height to 4 so I am just bumping the alignment to
 16 to represent 4 blocks.
 
  These hunks look okay to me. Any particular reason not to update
  brw_miptree_layout_texture_array as well? I am pretty certain we don't
  use ALL_SLICES_AT_EACH_LOD in Gen9 today, but presumably we could,
  right? /me shrugs
 
 We actually can't use ALL_SLICES_AT_EACH_LOD on Gen9 (see the earlier
 patches) but yes, brw_miptree_layout_texture_array needs to work for 2D
 array textures. However I don't think anything needs changing there. The
 only changes I made to brw_miptree_layout_2d were because it was
 assuming that mt-align_w/h is always equal to the compressed block size
 but with this patch that is no longer the case. I only changed the
 places that wanted the block size so that they would use a separate
 variable instead of conflating it with the alignment. I don't think
 anything in brw_miptree_layout_texture_array needs to refer to the block
 size so it should be ok.
 
 - Neil

Thanks for the explanations. lgtm
Reviewed-by: Ben Widawsky b...@bwidawsk.net
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] gl requirements of UBO size alignments?

2015-05-01 Thread Roland Scheidegger 
Hi,

this is sort of a revisit of a topic discussed here,
http://lists.freedesktop.org/archives/mesa-dev/2015-April/082199.html
but this time aimed squarely at GL itself.

Do uniform buffer objects need the size to be a multiple of
UNIFORM_BUFFER_OFFSET_ALIGNMENT or not?

The problem here is the state tables say this applies to both offset and
size of UBOs.
However, BindBufferRange does NOT need size to be aligned to it (and
from the ARB_ubo history, the language generating an error there was
removed at some point).

Plus, if the size of the UBO needs to be a multiple of the offset
alignment, this actually looks problematic (other than for never
generating an error): The spec says the workaround for implementations
which can't support any offsets for UBOs is to set a sufficently large
UNIFORM_BUFFER_OFFSET_ALIGNMENT value. This, in the end, would mean that
for such implementations always the maximum allowed UBO size would have
to be allocated (as there is no other such sufficiently large value),
which doesn't seem reasonable (?).

So, what's the answer there? I'm just trying to figure out if I need to
fix the piglit test (trivial...) or the driver (a bit more work...).

Roland

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

[Mesa-dev] [Bug 90275] Mesa 10.4.2 implementation error: Unexpected format PIPE_FORMAT_R8G8B8_UNORM in st_new_renderbuffer_fb

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=90275

Bug ID: 90275
   Summary: Mesa 10.4.2 implementation error: Unexpected format
PIPE_FORMAT_R8G8B8_UNORM in st_new_renderbuffer_fb
   Product: Mesa
   Version: 10.4
  Hardware: Other
OS: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: b...@google.com
QA Contact: mesa-dev@lists.freedesktop.org

When using OSMesa, we are having this error message: just wonder if this
PIPE_FORMAT_R8G8B8_UNORM is going to be supported?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90213] glDrawPixels with GL_COLOR_INDEX never returns.

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=90213

--- Comment #4 from Iago Toral ito...@igalia.com ---
(In reply to Jason Ekstrand from comment #3)
 (In reply to Iago Toral from comment #2)
  Hi Mark, Juha:
  
  Some special formats, like GL_COLOR_INDEX, MESA_FORMAT_YCBCR or
  byte-swapped scenarios need special handling before we can call
  _mesa_format_convert (see the implementation of texstore_rgba() in
  texstore.c for example).
  
  The problem in this case is that we are not doing that and it seems that the
  old _mesa_unpack_color_span_float that was used here before the format
  conversion overhaul did  handle at least GL_COLOR_INDEX (and byte-swapped
  scenarios too as far as I can see), so this is a regression.
  
  If the test was asserting before the overhaul that would explain that we did
  not catch it when we where in development, but it is a regression
  nonetheless.
  
  The solution is to add the same code we have in texstore.c to handle
  GL_COLOR_INDEX, which basically converts GL_COLOR_INDEX to GL_RGBA ubyte
  before calling _mesa_format_convert. We should probably also add the code we
  have there for byte-swapped formats. I think it could be useful to have a
  helper function for this so we don't have to replicate the code wherever we
  need to handle things like GL_COLOR_INDEX.
  
  Also, we should probably return something in
  _mesa_format_from_format_and_type even when we reach the assertion to make
  things less confusing in non-debug builds.
  
  Jason, what do you think?
 
 Seems reasonable to me

Great.

Juha, do you have plans to work on this? If not, I can give it a go next week.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
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] gallium/ttn: add missing SNE

2015-05-01 Thread Kenneth Graunke 
On Thursday, April 30, 2015 08:13:44 PM Rob Clark wrote:
 From: Rob Clark robcl...@freedesktop.org
 
 Signed-off-by: Rob Clark robcl...@freedesktop.org
 ---
  src/gallium/auxiliary/nir/tgsi_to_nir.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
 b/src/gallium/auxiliary/nir/tgsi_to_nir.c
 index 59aaf67..f1f7ef3 100644
 --- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
 +++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
 @@ -1286,6 +1286,7 @@ static const nir_op op_trans[TGSI_OPCODE_LAST] = {
 [TGSI_OPCODE_SEQ] = nir_op_seq,
 [TGSI_OPCODE_SGT] = 0,
 [TGSI_OPCODE_SIN] = nir_op_fsin,
 +   [TGSI_OPCODE_SNE] = nir_op_sne,
 [TGSI_OPCODE_SLE] = 0,
 [TGSI_OPCODE_TEX] = 0,
 [TGSI_OPCODE_TXD] = 0,
 

Reviewed-by: Kenneth Graunke kenn...@whitecape.org


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] egl/dri2: Check return value of __DRI2fence::create_fence()

2015-05-01 Thread Marek Olšák 
Reviewed-by: Marek Olšák marek.ol...@amd.com

Marek

On Fri, May 1, 2015 at 10:01 PM, Chad Versace chad.vers...@intel.com wrote:
 From: Chad Versace c...@kiwitree.net

 If it returns NULL, then return early with an error.

 Cc: Marek Olšák marek.ol...@amd.com
 ---
  src/egl/drivers/dri2/egl_dri2.c | 7 +++
  1 file changed, 7 insertions(+)

 diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
 index 34d6bfe..c2a856f 100644
 --- a/src/egl/drivers/dri2/egl_dri2.c
 +++ b/src/egl/drivers/dri2/egl_dri2.c
 @@ -2232,6 +2232,13 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
 switch (type) {
 case EGL_SYNC_FENCE_KHR:
dri2_sync-fence = 
 dri2_dpy-fence-create_fence(dri2_ctx-dri_context);
 +  if (!dri2_sync-fence) {
 + /* Why did it fail? DRI doesn't return an error code, so we emit
 +  * a generic EGL error that doesn't communicate user error. */
 + _eglError(EGL_BAD_ALLOC, eglCreateSyncKHR);
 + free(dri2_sync);
 + return NULL;
 +  }
break;

 case EGL_SYNC_CL_EVENT_KHR:
 --
 2.4.0

 ___
 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

[Mesa-dev] [Bug 89018] Civilization: Beyond Earth terrain section not rendered

2015-05-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=89018

Jérémy Viès jeremy.v...@gmail.com changed:

   What|Removed |Added

 CC||jeremy.v...@gmail.com

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