[Mesa-dev] [RFC] egl/dri2: Add Mir platform backend

[christopher . halse . rogers]

From: Christopher James Halse Rogers 

A first pass at a Mir platform for EGL.

This is RFC mainly because I hope to shortly make Mir's API less painfully
pointless-callback-based. There's no point in committing this as-is, but
it's hopefully still useful to review.

---
 configure.ac|   5 +-
 src/egl/drivers/dri2/Makefile.am|   6 +
 src/egl/drivers/dri2/egl_dri2.c |   6 +
 src/egl/drivers/dri2/egl_dri2.h |  19 +-
 src/egl/drivers/dri2/platform_mir.c | 344 
 src/egl/main/Makefile.am|   6 +
 src/egl/main/egldisplay.c   |  12 +-
 src/egl/main/egldisplay.h   |   1 +
 8 files changed, 395 insertions(+), 4 deletions(-)
 create mode 100644 src/egl/drivers/dri2/platform_mir.c

diff --git a/configure.ac b/configure.ac
index 7852595..6f35e9e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1559,7 +1559,9 @@ for plat in $egl_platforms; do
 
android|gdi)
;;
-
+mir)
+PKG_CHECK_MODULES([MIR], [mirclient])
+;;
*)
AC_MSG_ERROR([EGL platform '$plat' does not exist])
;;
@@ -1587,6 +1589,7 @@ AM_CONDITIONAL(HAVE_EGL_PLATFORM_WAYLAND, echo 
"$egl_platforms" | grep 'wayland'
 AM_CONDITIONAL(HAVE_EGL_PLATFORM_DRM, echo "$egl_platforms" | grep 'drm' 
>/dev/null 2>&1)
 AM_CONDITIONAL(HAVE_EGL_PLATFORM_FBDEV, echo "$egl_platforms" | grep 'fbdev' 
>/dev/null 2>&1)
 AM_CONDITIONAL(HAVE_EGL_PLATFORM_NULL, echo "$egl_platforms" | grep 'null' 
>/dev/null 2>&1)
+AM_CONDITIONAL(HAVE_EGL_PLATFORM_MIR, echo "$egl_platforms" | grep 'mir' 
>/dev/null 2>&1)
 
 AM_CONDITIONAL(HAVE_EGL_DRIVER_DRI2, test "x$HAVE_EGL_DRIVER_DRI2" != "x")
 AM_CONDITIONAL(HAVE_EGL_DRIVER_GLX, test "x$HAVE_EGL_DRIVER_GLX" != "x")
diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am
index 45f7dfa..dfb0c05 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -62,3 +62,9 @@ if HAVE_EGL_PLATFORM_DRM
 libegl_dri2_la_SOURCES += platform_drm.c
 AM_CFLAGS += -DHAVE_DRM_PLATFORM
 endif
+
+if HAVE_EGL_PLATFORM_MIR
+libegl_dri2_la_SOURCES += platform_mir.c
+AM_CFLAGS += -DHAVE_MIR_PLATFORM
+AM_CFLAGS += $(MIR_CFLAGS)
+endif
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index b774919..ddd0314 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -599,6 +599,12 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
  return EGL_TRUE;
   return dri2_initialize_wayland(drv, disp);
 #endif
+#ifdef HAVE_MIR_PLATFORM
+   case _EGL_PLATFORM_MIR:
+  if (disp->Options.TestOnly)
+ return EGL_TRUE;
+  return dri2_initialize_mir(drv, disp);
+#endif
 #endif
 #ifdef HAVE_ANDROID_PLATFORM
case _EGL_PLATFORM_ANDROID:
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 84ea2a6..d82b9f8 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -65,6 +65,10 @@
 
 #endif /* HAVE_ANDROID_PLATFORM */
 
+#ifdef HAVE_MIR_PLATFORM
+#include 
+#endif
+
 #include "eglconfig.h"
 #include "eglcontext.h"
 #include "egldisplay.h"
@@ -134,6 +138,10 @@ struct dri2_egl_display
int  formats;
 #endif
 
+#ifdef HAVE_MIR_PLATFORM
+   MirConnection*mir_conn;
+#endif
+
int (*authenticate) (_EGLDisplay *disp, uint32_t id);
 };
 
@@ -182,7 +190,9 @@ struct dri2_egl_surface
struct gbm_dri_surface *gbm_surf;
 #endif
 
-#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
+#if defined(HAVE_WAYLAND_PLATFORM) \
+   || defined(HAVE_DRM_PLATFORM) \
+   || defined(HAVE_MIR_PLATFORM)
__DRIbuffer   *dri_buffers[__DRI_BUFFER_COUNT];
struct {
 #ifdef HAVE_WAYLAND_PLATFORM
@@ -204,6 +214,10 @@ struct dri2_egl_surface
/* EGL-owned buffers */
__DRIbuffer   *local_buffers[__DRI_BUFFER_COUNT];
 #endif
+
+#ifdef HAVE_MIR_PLATFORM
+   MirSurface*mir_surf;
+#endif
 };
 
 
@@ -265,6 +279,9 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp);
 EGLBoolean
 dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *disp);
 
+EGLBoolean
+dri2_initialize_mir(_EGLDriver *drv, _EGLDisplay *disp);
+
 char *
 dri2_get_driver_for_fd(int fd);
 char *
diff --git a/src/egl/drivers/dri2/platform_mir.c 
b/src/egl/drivers/dri2/platform_mir.c
new file mode 100644
index 000..965a1df
--- /dev/null
+++ b/src/egl/drivers/dri2/platform_mir.c
@@ -0,0 +1,344 @@
+/*
+ * Copyright © 2012 Canonical, Inc
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the follow

Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines

[Carl Worth]

Jose Fonseca  writes:
> I see.  But one can use apitrace through LD_LIBRARY_PATH instead of
> LD_PRELOAD. Steam is not the first app to have issues with LD_PRELOAD.

I spend some time looking at this issue today.

First, things aren't as bad as I had first thought. I had
misunderstood the original report thinking that the Steam overlay made
it so that no Steam games could be traced. But in fact, it's easy to
trace a Steam game with "apitrace trace"—the only trick is to ensure
that LD_PRELOAD does not include gamoverlayrenderer.so.

But, yes, there's definitely a failure if one actually does want to
trace the operation of the overlay itself.

And switching from LD_PRELOAD to LD_LIBRARY_PATH for apitrace didn't
fix things in my experiments. Regardless of the mechanism for invoking
apitrace, I found the same behavior: If both apitrace and
gameoverlayrenderer are loaded then the game will segfault. The crash
is from infinite mutual recursion as the two wrappers continue to call
into each others functions.

I don't think it should be too hard to get this to work, (though it
may require a source change to the Steam overlay). I'll do some more
experiments tomorrow and see if I can't make a concrete recommendation
to be able to give to Valve as a bug report.

And, obviously, if there's something we can do to make apitrace more
robust here, I'll submit that change as well.

-Carl

-- 
carl.d.wo...@intel.com


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

[Mesa-dev] [Bug 61828] [softpipe] tgsi/tgsi_exec.c:1936:exec_tex: Assertion `modifier != 1' failed.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61828

--- Comment #1 from Roland Scheidegger  ---
Whoa I thought noone ever defined TXP for array textures. But it turns out I
was wrong since apparently GL_MESA_texture_array supports array textures even
with fixed function hence TXP. Sick. (The spec does not actually seem to define
if the array coord should be projected or not, but I guess from previous
softpipe behavior not. I don't think any real hw actually implements this
correctly however.)
Well I will just kill those assertions again. I am quite sure we can't really
handle that correctly everywhere however anyway (for instance the glsl-to-tgsi
code lowering texture opcodes with lod and projection would do the projective
divide itself on all coords but then again probably noone cares).

-- 
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 61828] New: [softpipe] tgsi/tgsi_exec.c:1936:exec_tex: Assertion `modifier != 1' failed.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61828

  Priority: medium
Bug ID: 61828
  Keywords: have-backtrace, regression
CC: srol...@vmware.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [softpipe] tgsi/tgsi_exec.c:1936:exec_tex: Assertion
`modifier != 1' failed.
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: e21460b4d515a7ea41e2694c89b5d94b0bd84d54 (master)

Run piglit array-texture test on softpipe.

$ ./bin/array-texture -auto
Mesa warning: failed to remap glClampColorARB
Mesa warning: failed to remap glTexBufferARB
Mesa warning: failed to remap glFramebufferTextureARB
Mesa warning: failed to remap glVertexAttribDivisorARB
Mesa warning: failed to remap glProgramParameteriARB
tgsi/tgsi_exec.c:1936:exec_tex: Assertion `modifier != 1' failed.
Trace/breakpoint trap (core dumped)

(gdb) bt
#0  0x7f28bca0d722 in _debug_assert_fail (expr=0x7f28bcc2b24e "modifier !=
1", file=0x7f28bcc2afc4 "tgsi/tgsi_exec.c", line=1936, function=0x7f28bcc2b93d
"exec_tex")
at util/u_debug.c:278
#1  0x7f28bc9ee42c in exec_tex (mach=0x7f28b29e3010, inst=0x28ab2d0,
modifier=1, sampler=1) at tgsi/tgsi_exec.c:1936
#2  0x7f28bc9f55c1 in exec_instruction (mach=0x7f28b29e3010,
inst=0x28ab2d0, pc=0x733b9298) at tgsi/tgsi_exec.c:3862
#3  0x7f28bc9f7b0f in tgsi_exec_machine_run (mach=0x7f28b29e3010) at
tgsi/tgsi_exec.c:4484
#4  0x7f28bcabe8d6 in exec_run (var=0x28aac90, machine=0x7f28b29e3010,
quad=0x2501710) at sp_fs_exec.c:129
#5  0x7f28bcac6ca8 in shade_quad (qs=0x24355f0, quad=0x2501710) at
sp_quad_fs.c:78
#6  0x7f28bcac6e5c in shade_quads (qs=0x24355f0, quads=0x2503b90, nr=1) at
sp_quad_fs.c:131
#7  0x7f28bcad0237 in flush_spans (setup=0x2501690) at sp_setup.c:250
#8  0x7f28bcad161b in subtriangle (setup=0x2501690, eleft=0x25016e8,
eright=0x25016b8, lines=100) at sp_setup.c:759
#9  0x7f28bcad18d3 in sp_setup_tri (setup=0x2501690, v0=0x2674f10,
v1=0x2674f30, v2=0x2674ef0) at sp_setup.c:848
#10 0x7f28bcac2428 in sp_vbuf_draw_arrays (vbr=0x2501600, start=0, nr=4) at
sp_prim_vbuf.c:577
#11 0x7f28bc9be148 in draw_pt_emit_linear (emit=0x24fe3f0,
vert_info=0x733b9660, prim_info=0x733b9710) at draw/draw_pt_emit.c:255
#12 0x7f28bc9c0888 in emit (emit=0x24fe3f0, vert_info=0x733b9660,
prim_info=0x733b9710) at draw/draw_pt_fetch_shade_pipeline.c:187
#13 0x7f28bc9c0c03 in fetch_pipeline_generic (middle=0x24fe2b0,
fetch_info=0x0, prim_info=0x733b9710) at
draw/draw_pt_fetch_shade_pipeline.c:306
#14 0x7f28bc9c0d31 in fetch_pipeline_linear_run (middle=0x24fe2b0, start=0,
count=4, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline.c:364
#15 0x7f28bc9c861f in vsplit_segment_simple_linear (vsplit=0x24fb680,
flags=0, istart=0, icount=4) at draw/draw_pt_vsplit_tmp.h:235
#16 0x7f28bc9c8924 in vsplit_run_linear (frontend=0x24fb680, start=0,
count=4) at draw/draw_split_tmp.h:61
#17 0x7f28bc9bcaf1 in draw_pt_arrays (draw=0x24f1170, prim=9, start=0,
count=4) at draw/draw_pt.c:148
#18 0x7f28bc9bd75a in draw_vbo (draw=0x24f1170, info=0x733b9950) at
draw/draw_pt.c:539
#19 0x7f28bcac08a4 in softpipe_draw_vbo (pipe=0x2436020,
info=0x733b9950) at sp_draw_arrays.c:109
#20 0x7f28bc9a6f2d in cso_draw_vbo (cso=0x2585b60, info=0x733b9950) at
cso_cache/cso_context.c:1347
#21 0x7f28bc8bbe90 in st_draw_vbo (ctx=0x25253f0, prims=0x2570bac,
nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3,
tfb_vertcount=0x0)
at ../../src/mesa/state_tracker/st_draw.c:287
#22 0x7f28bc87d79b in vbo_exec_vtx_flush (exec=0x2570318, keepUnmapped=1
'\001') at ../../src/mesa/vbo/vbo_exec_draw.c:400
#23 0x7f28bc876966 in vbo_exec_FlushVertices_internal (exec=0x2570318,
unmap=1 '\001') at ../../src/mesa/vbo/vbo_exec_api.c:556
#24 0x7f28bc878ebe in vbo_exec_FlushVertices (ctx=0x25253f0, flags=1) at
../../src/mesa/vbo/vbo_exec_api.c:1256
#25 0x7f28bc7fa510 in _mesa_ReadnPixelsARB (x=50, y=150, width=1, height=1,
format=6407, type=5126, bufSize=2147483647, pixels=0x733b9b70)
at ../../src/mesa/main/readpix.c:735
#26 0x7f28bc7faac5 in _mesa_ReadPixels (x=50, y=150, width=1, height=1,
format=6407, type=5126, pixels=0x733b9b70) at
../../src/mesa/main/readpix.c:869
#27 0x7f28c0462cd8 in piglit_probe_pixel_rgb (x=50, y=150,
expected=0x6030a0) at piglit/tests/util/piglit-util-gl.c:414
#28 0x00401861 in test_2d_array_texture (tex=1) at
piglit/tests/texturing/array-texture.c:196
#29 0x00401c6d in piglit_display () at
piglit/tests/texturing/array-texture.c:299
#30 0x7f28c03fd418 in display () at
piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:60
#31 0x7f28bfdb2137 in fghR

[Mesa-dev] [Bug 61827] New: [softpipe] piglit fbo-clear-formats GL_ARB_depth_buffer_float stencil regression

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61827

  Priority: medium
Bug ID: 61827
  Keywords: regression
CC: anuj.pho...@gmail.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [softpipe] piglit fbo-clear-formats
GL_ARB_depth_buffer_float stencil regression
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: e21460b4d515a7ea41e2694c89b5d94b0bd84d54 (master)

$ ./bin/fbo-clear-formats  GL_ARB_depth_buffer_float stencil -auto
Mesa warning: failed to remap glClampColorARB
Mesa warning: failed to remap glTexBufferARB
Mesa warning: failed to remap glFramebufferTextureARB
Mesa warning: failed to remap glVertexAttribDivisorARB
Mesa warning: failed to remap glProgramParameteriARB
Using test set: GL_ARB_depth_buffer_float
Testing GL_DEPTH_COMPONENT32F - no stencil.
Testing GL_DEPTH32F_STENCIL8
Mesa: User error: GL_INVALID_OPERATION in glBlitFramebuffer(stencil attachment
depth format mismatch)
fbo-clear-formats: piglit/tests/fbo/fbo-clear-formats.c:332:
draw_stencil_mipmap: Assertion `piglit_dispatch_glGetError() == 0' failed.
Aborted (core dumped)

(gdb) bt
#0  0x7fcaf932a425 in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7fcaf932db8b in __GI_abort () at abort.c:91
#2  0x7fcaf93230ee in __assert_fail_base (fmt=,
assertion=0x4061f8 "piglit_dispatch_glGetError() == 0", 
file=0x4061b8 "piglit/tests/fbo/fbo-clear-formats.c", line=,
function=) at assert.c:94
#3  0x7fcaf9323192 in __GI___assert_fail (assertion=0x4061f8
"piglit_dispatch_glGetError() == 0", 
file=0x4061b8 "piglit/tests/fbo/fbo-clear-formats.c", line=332,
function=0x406280 "draw_stencil_mipmap") at assert.c:103
#4  0x00402ce9 in draw_stencil_mipmap (x=1, y=1, dim=256, tex=1,
level=0) at piglit/tests/fbo/fbo-clear-formats.c:332
#5  0x004035c9 in test_format (format=0x404ed8) at
piglit/tests/fbo/fbo-clear-formats.c:535
#6  0x00401f92 in fbo_formats_display (test_format=0x40346d
) at piglit/tests/fbo/fbo-formats.h:641
#7  0x004036d4 in piglit_display () at
piglit/tests/fbo/fbo-clear-formats.c:563
#8  0x7fcaf991c418 in display () at
piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:60
#9  0x7fcaf90ce137 in fghRedrawWindow (window=0x21a7e60) at
freeglut_main.c:210
#10 fghcbDisplayWindow (window=0x21a7e60, enumerator=0x7fff69b020d0) at
freeglut_main.c:227
#11 0x7fcaf90d1889 in fgEnumWindows (enumCallback=0x7fcaf90ce0d0
, enumerator=0x7fff69b020d0) at freeglut_structure.c:394
#12 0x7fcaf90ce5fa in fghDisplayAll () at freeglut_main.c:249
#13 glutMainLoopEvent () at freeglut_main.c:1450
#14 0x7fcaf90cef05 in glutMainLoop () at freeglut_main.c:1498
#15 0x7fcaf991c5f0 in run_test (gl_fw=0x7fcaf9befbc0, argc=3,
argv=0x7fff69b02498)
at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:127
#16 0x7fcaf991a736 in piglit_gl_test_run (argc=3, argv=0x7fff69b02498,
config=0x7fff69b02380) at piglit/tests/util/piglit-framework-gl.c:127
#17 0x004020c0 in main (argc=4, argv=0x7fff69b02498) at
piglit/tests/fbo/fbo-clear-formats.c:49
(gdb) frame 4
#4  0x00402ce9 in draw_stencil_mipmap (x=1, y=1, dim=256, tex=1,
level=0) at piglit/tests/fbo/fbo-clear-formats.c:332
332assert(glGetError() == 0);

252573ae0fe6c928885f005cf6e77200b45601fb is the first bad commit
commit 252573ae0fe6c928885f005cf6e77200b45601fb
Author: Anuj Phogat 
Date:   Mon Jan 7 15:55:31 2013 -0800

mesa: Fix GL error generation in glBlitFramebuffer()

V2:
If mask has GL_STENCIL_BUFFER_BIT set, the depth formats for
readRenderBuffer and drawRenderBuffer must match unless one of the two
buffers doesn't have depth, in which case it's not blitted, so the
format check should be ignored.  Same comment goes for stencil formats
in depth renderbuffers if mask has GL_DEPTH_BUFFER_BIT set.

v3 (Kayden): Refactor code to be a bit more readable.

Signed-off-by: Anuj Phogat 
Signed-off-by: Kenneth Graunke 
Reviewed-by: Kenneth Graunke 
Reviewed-by: Ian Romanick 

:04 04 56dc8f187d114e82f922ff7b0dcf6800a1eb174c
0891bad034833aa6624fa0caf7a6cf2818ddfc59 Msrc
bisect run success

-- 
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] st/mesa: translate ir offset parameters for non-TXF opcodes.

[sroland]

From: Roland Scheidegger 

Otherwise the state tracker will crash if the texture instructions
have offsets.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8e3e3b8..2928eef 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2714,16 +2714,28 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
switch (ir->op) {
case ir_tex:
   opcode = (is_cube_array && ir->shadow_comparitor) ? TGSI_OPCODE_TEX2 : 
TGSI_OPCODE_TEX; 
+  if (ir->offset) {
+ ir->offset->accept(this);
+ offset = this->result;
+  }
   break;
case ir_txb:
   opcode = is_cube_array ? TGSI_OPCODE_TXB2 : TGSI_OPCODE_TXB;
   ir->lod_info.bias->accept(this);
   lod_info = this->result;
+  if (ir->offset) {
+ ir->offset->accept(this);
+ offset = this->result;
+  }
   break;
case ir_txl:
   opcode = is_cube_array ? TGSI_OPCODE_TXL2 : TGSI_OPCODE_TXL;
   ir->lod_info.lod->accept(this);
   lod_info = this->result;
+  if (ir->offset) {
+ ir->offset->accept(this);
+ offset = this->result;
+  }
   break;
case ir_txd:
   opcode = TGSI_OPCODE_TXD;
@@ -2731,6 +2743,10 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
   dx = this->result;
   ir->lod_info.grad.dPdy->accept(this);
   dy = this->result;
+  if (ir->offset) {
+ ir->offset->accept(this);
+ offset = this->result;
+  }
   break;
case ir_txs:
   opcode = TGSI_OPCODE_TXQ;
@@ -2742,8 +2758,8 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
   ir->lod_info.lod->accept(this);
   lod_info = this->result;
   if (ir->offset) {
-ir->offset->accept(this);
-offset = this->result;
+ ir->offset->accept(this);
+ offset = this->result;
   }
   break;
}
-- 
1.7.9.5

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

[Mesa-dev] [Bug 61821] New: src/mesa/drivers/dri/common/xmlpool.h:96:29: fatal error: xmlpool/options.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61821

  Priority: medium
Bug ID: 61821
  Keywords: regression
CC: consume.no...@gmail.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: src/mesa/drivers/dri/common/xmlpool.h:96:29: fatal
error: xmlpool/options.h
  Severity: blocker
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: Other
   Product: Mesa

mesa: e21460b4d515a7ea41e2694c89b5d94b0bd84d54

$ ./autogen.sh --with-dri-drivers= --with-gallium-drivers=swrast
[...]
$ make
[...]
Making all in drm
make[5]: Entering directory `src/gallium/state_trackers/dri/drm'
  CC dri_screen.lo
In file included from dri_screen.c:33:0:
src/mesa/drivers/dri/common/xmlpool.h:96:29: fatal error: xmlpool/options.h: No
such file or directory
compilation terminated.

998d975e38db7478781130b42a4fb68d6b181055 is the first bad commit
commit 998d975e38db7478781130b42a4fb68d6b181055
Author: Daniel Martin 
Date:   Thu Feb 28 19:39:06 2013 +0100

Fix build of swrast only without libdrm

Reviewed-by: Matt Turner 
Signed-off-by: Daniel Martin 

:100644 100644 5f95a78d26f241557754adaeffe73d3e3d3a88bb
785259554bbb833bc6d03c50414b8262bc553341 M$
bisect run success

-- 
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 1/2] i965: Fix off-by-one in query object result gathering.

[Eric Anholt]

Kenneth Graunke  writes:

> If we've written N pairs of values to the buffer, then last_index = N,
> but the values are 0 .. N-1.  Thus, we need to use <, not <=.
>
> This worked anyway because we fill the buffer with zeroes, so we just
> added an extra (0 - 0) to our results.

This series is:

Reviewed-by: Eric Anholt 


pgpuqQ809jrcW.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 2/3] llvmpipe: add some scene limit sanity check assertions

[Roland Scheidegger]

Am 04.03.2013 23:04, schrieb Brian Paul:
> Note: This is a candidate for the stable branches.
> ---
>  src/gallium/drivers/llvmpipe/lp_scene.c |   20 
>  1 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c 
> b/src/gallium/drivers/llvmpipe/lp_scene.c
> index fec2f74..8056906 100644
> --- a/src/gallium/drivers/llvmpipe/lp_scene.c
> +++ b/src/gallium/drivers/llvmpipe/lp_scene.c
> @@ -64,6 +64,26 @@ lp_scene_create( struct pipe_context *pipe )
>  
> pipe_mutex_init(scene->mutex);
>  
> +   /* Do some scene limit sanity checks here */
> +   {
> +  unsigned maxBins = TILES_X * TILES_Y;
> +  unsigned maxCommandBytes = sizeof(struct cmd_block) * maxBins;
> +  unsigned maxCommandPlusData = maxCommandBytes + DATA_BLOCK_SIZE;
> +  /* We'll need at least one command block per bin.  Make sure that's
> +   * less than the max allowed scene size.
> +   */
> +  assert(maxCommandBytes < LP_SCENE_MAX_SIZE);
> +  /* We'll also need space for at least one other data block */
> +  assert(maxCommandPlusData <= LP_SCENE_MAX_SIZE);
> +
> +  /* Ideally, the size of a cmd_block object will be a power of two
> +   * in order to avoid wasting space when we allocation them from
allocation->allocate

> +   * data blocks (which are power of two also).
> +   */
> +  assert(sizeof(struct cmd_block) ==
> + util_next_power_of_two(sizeof(struct cmd_block)));
> +   }
I guess that's ok though the waste is not THAT big otherwise (especially
not with the smaller blocks now).

I guess doing STATIC_ASSERT with sizeof() wouldn't be portable? (Of
course it wouldn't work for the last assert.)

> return scene;
>  }
>  
> 

Series looks good to me otherwise though we probably need to improve
that in the future.

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

Re: [Mesa-dev] multisample clears

[Dave Airlie]

On Mon, Mar 4, 2013 at 11:47 PM, Marek Olšák  wrote:
> On Mon, Mar 4, 2013 at 4:54 AM, Dave Airlie  wrote:
>> I've been playing with softpipe msaa on and off, but I hit a problem
>> with the clears and am just wondering if the state tracker should be
>> doing something like this.
>>
>> Or maybe only if any bound buffer has nr_samples > 1, or fallback to
>> the non-quad draw method.
>>
>> I can't see how else the driver could distinguish a multisample clear.
>>
>> The other problem I have and not figuring out is if rendering to a
>> buffer with multisample off, then turning it on is meant to be
>> meaningful, if you have to clear
>> the buffer in between, then with this fixed it should be cool.
>>
>> Dave.
>>
>> From e1ee59d87ba42d8a58be640ee1fd2b952414f45e Mon Sep 17 00:00:00 2001
>> From: Dave Airlie 
>> Date: Mon, 4 Mar 2013 13:39:17 +1000
>> Subject: [PATCH] st/mesa: enable multisample in clear quad code
>>
>> Not sure if this is correct at all
>
> For clears, blits, and the like, multisampling doesn't have to be
> enabled, which means pixel values are stored in all samples regardless
> of sample positions.
>
> Multisampling can be problematic if the rendered quad doesn't cover
> whole pixels (floating-point precision may play a role, not sure), so
> it's better not to enable it.
>

Yeah I thought about it a bit more and I think you are right, I was
being premature in my optimisation,
in that if I had a multisample buffer with say 4 samples and I was
rendering non-multisampled into it
I was only using one sample and storing how many I'd used. However I
should just replicate samples
at this point and look towards optimising it later if possible.

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

Re: [Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.

[Anuj Phogat]

On Mon, Mar 4, 2013 at 11:41 AM, Ian Romanick  wrote:
> On 03/04/2013 11:38 AM, Matt Turner wrote:
>>
>> Reported-by: Marek Olšák 
>
>
> Do our ETC2 piglit tests run in this mode?  It would be good to see this
> change actually fix a bug by making a failing test pass. :)
>
ETC2 tests currently runs only on gles3.  Need to add
config.supports_gl_compat_version = 30; to enable them on GL contexts.

>> ---
>>   src/mesa/main/teximage.c |2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>> index 0dcf88a..e5260d1 100644
>> --- a/src/mesa/main/teximage.c
>> +++ b/src/mesa/main/teximage.c
>> @@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint
>> internalFormat )
>> }
>>  }
>>
>> -   if (_mesa_is_gles3(ctx)) {
>> +   if (_mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility) {
>> switch (internalFormat) {
>> case GL_COMPRESSED_RGB8_ETC2:
>> case GL_COMPRESSED_SRGB8_ETC2:
>>
>
> ___
> 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] [PATCH 2/2] i965: Don't fill buffer with zeroes.

[Kenneth Graunke]

This was only necessary because our bounds checking was off by one, and
thus we read an extra pair of values.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index b634a10..430a3b1 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -510,12 +510,6 @@ ensure_bo_has_space(struct gl_context *ctx, struct 
brw_query_object *query)
   }
 
   query->bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1);
-
-  /* Fill the buffer with zeroes.  This is probably superfluous. */
-  drm_intel_bo_map(query->bo, true);
-  memset((char *) query->bo->virtual, 0, 4096);
-  drm_intel_bo_unmap(query->bo);
-
   query->last_index = 0;
}
 }
-- 
1.8.1.5

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

[Mesa-dev] [PATCH 1/2] i965: Fix off-by-one in query object result gathering.

[Kenneth Graunke]

If we've written N pairs of values to the buffer, then last_index = N,
but the values are 0 .. N-1.  Thus, we need to use <, not <=.

This worked anyway because we fill the buffer with zeroes, so we just
added an extra (0 - 0) to our results.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 0065513..b634a10 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -208,7 +208,7 @@ brw_queryobj_get_results(struct gl_context *ctx,
* run out of space in the query's BO and allocated a new one.  If so,
* this function was already called to accumulate the results so far.
*/
-  for (i = 0; i <= query->last_index; i++) {
+  for (i = 0; i < query->last_index; i++) {
 query->Base.Result += results[i * 2 + 1] - results[i * 2];
   }
   break;
@@ -218,7 +218,7 @@ brw_queryobj_get_results(struct gl_context *ctx,
   /* If the starting and ending PS_DEPTH_COUNT from any of the batches
* differ, then some fragments passed the depth test.
*/
-  for (i = 0; i <= query->last_index; i++) {
+  for (i = 0; i < query->last_index; i++) {
 if (results[i * 2 + 1] != results[i * 2]) {
 query->Base.Result = GL_TRUE;
 break;
-- 
1.8.1.5

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

[Mesa-dev] [PATCH 3/3] llvmpipe: remove unused cmd_block_list struct

[Brian Paul]

---
 src/gallium/drivers/llvmpipe/lp_scene.h |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_scene.h 
b/src/gallium/drivers/llvmpipe/lp_scene.h
index 801829d..1d0cd0e 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.h
+++ b/src/gallium/drivers/llvmpipe/lp_scene.h
@@ -81,10 +81,6 @@ struct cmd_block {
struct cmd_block *next;
 };
 
-struct cmd_block_list {
-   struct cmd_block *head;
-   struct cmd_block *tail;
-};
 
 struct data_block {
ubyte data[DATA_BLOCK_SIZE];
-- 
1.7.3.4

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

[Mesa-dev] [PATCH 1/3] llvmpipe: tweak CMD_BLOCK_MAX and LP_SCENE_MAX_SIZE

[Brian Paul]

We advertise a max texture/surfaces size of 8K x 8K but the old values
for these limits didn't actually allow us to handle that surface size.

For 8K x 8K we'll have 16384 bins.  Each bin needs at least one cmd_block
object which was 2192 bytes in size.  Since 16384 * 2192 exceeded
LP_SCENE_MAX_SIZE we'd silently fail in lp_scene_new_data_block() and not
draw the complete scene.

By reducing CMD_BLOCK_MAX to 29 we get nice 512-byte cmd_blocks.  And
by increasing LP_SCENE_MAX_SIZE to 9 MB we can allocate enough command
blocks for 8K x 8K, plus a few regular data blocks.

Fixes the (improved) piglit fbo-maxsize test.

Note: This is a candidate for the stable branches.
---
 src/gallium/drivers/llvmpipe/lp_scene.h |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_scene.h 
b/src/gallium/drivers/llvmpipe/lp_scene.h
index b1db61b..801829d 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.h
+++ b/src/gallium/drivers/llvmpipe/lp_scene.h
@@ -49,12 +49,18 @@ struct lp_rast_state;
 #define TILES_Y (LP_MAX_HEIGHT / TILE_SIZE)
 
 
-#define CMD_BLOCK_MAX 128
+/* Commands per command block (ideally so sizeof(cmd_block) is a power of
+ * two in size.)
+ */
+#define CMD_BLOCK_MAX 29
+
+/* Bytes per data block.
+ */
 #define DATA_BLOCK_SIZE (64 * 1024)
 
 /* Scene temporary storage is clamped to this size:
  */
-#define LP_SCENE_MAX_SIZE (4*1024*1024)
+#define LP_SCENE_MAX_SIZE (9*1024*1024)
 
 /* The maximum amount of texture storage referenced by a scene is
  * clamped ot this size:
-- 
1.7.3.4

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

[Mesa-dev] [PATCH 2/3] llvmpipe: add some scene limit sanity check assertions

[Brian Paul]

Note: This is a candidate for the stable branches.
---
 src/gallium/drivers/llvmpipe/lp_scene.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c 
b/src/gallium/drivers/llvmpipe/lp_scene.c
index fec2f74..8056906 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.c
+++ b/src/gallium/drivers/llvmpipe/lp_scene.c
@@ -64,6 +64,26 @@ lp_scene_create( struct pipe_context *pipe )
 
pipe_mutex_init(scene->mutex);
 
+   /* Do some scene limit sanity checks here */
+   {
+  unsigned maxBins = TILES_X * TILES_Y;
+  unsigned maxCommandBytes = sizeof(struct cmd_block) * maxBins;
+  unsigned maxCommandPlusData = maxCommandBytes + DATA_BLOCK_SIZE;
+  /* We'll need at least one command block per bin.  Make sure that's
+   * less than the max allowed scene size.
+   */
+  assert(maxCommandBytes < LP_SCENE_MAX_SIZE);
+  /* We'll also need space for at least one other data block */
+  assert(maxCommandPlusData <= LP_SCENE_MAX_SIZE);
+
+  /* Ideally, the size of a cmd_block object will be a power of two
+   * in order to avoid wasting space when we allocation them from
+   * data blocks (which are power of two also).
+   */
+  assert(sizeof(struct cmd_block) ==
+ util_next_power_of_two(sizeof(struct cmd_block)));
+   }
+
return scene;
 }
 
-- 
1.7.3.4

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

Re: [Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.

[Anuj Phogat]

On Mon, Mar 4, 2013 at 11:38 AM, Matt Turner  wrote:
> Reported-by: Marek Olšák 
> ---
>  src/mesa/main/teximage.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 0dcf88a..e5260d1 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint 
> internalFormat )
>}
> }
>
> -   if (_mesa_is_gles3(ctx)) {
> +   if (_mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility) {
Similar change is required in compressed_texture_error_check() as well.

>switch (internalFormat) {
>case GL_COMPRESSED_RGB8_ETC2:
>case GL_COMPRESSED_SRGB8_ETC2:
> --
> 1.7.8.6
>
> ___
> 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] [PATCH] mesa: don't allocate a texture if width or height is 0 in CopyTexImage

[Marek Olšák]

---
 src/mesa/main/teximage.c |   22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..a7b88d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3494,19 +3494,21 @@ copyteximage(struct gl_context *ctx, GLuint dims,
  _mesa_init_teximage_fields(ctx, texImage, width, height, 1,
 border, internalFormat, texFormat);
 
- /* Allocate texture memory (no pixel data yet) */
- ctx->Driver.AllocTextureImageBuffer(ctx, texImage);
+ if (width && height) {
+/* Allocate texture memory (no pixel data yet) */
+ctx->Driver.AllocTextureImageBuffer(ctx, texImage);
 
- if (_mesa_clip_copytexsubimage(ctx, &dstX, &dstY, &srcX, &srcY,
-&width, &height)) {
-struct gl_renderbuffer *srcRb =
-   get_copy_tex_image_source(ctx, texImage->TexFormat);
+if (_mesa_clip_copytexsubimage(ctx, &dstX, &dstY, &srcX, &srcY,
+   &width, &height)) {
+   struct gl_renderbuffer *srcRb =
+  get_copy_tex_image_source(ctx, texImage->TexFormat);
 
-ctx->Driver.CopyTexSubImage(ctx, dims, texImage, dstX, dstY, dstZ,
-srcRb, srcX, srcY, width, height);
- }
+   ctx->Driver.CopyTexSubImage(ctx, dims, texImage, dstX, dstY, 
dstZ,
+   srcRb, srcX, srcY, width, height);
+}
 
- check_gen_mipmap(ctx, target, texObj, level);
+check_gen_mipmap(ctx, target, texObj, level);
+ }
 
  _mesa_update_fbo_texture(ctx, texObj, face, level);
 
-- 
1.7.10.4

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

Re: [Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.

[Ian Romanick]

On 03/04/2013 11:38 AM, Matt Turner wrote:

Reported-by: Marek Olšák 


Do our ETC2 piglit tests run in this mode?  It would be good to see this 
change actually fix a bug by making a failing test pass. :)



---
  src/mesa/main/teximage.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..e5260d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint 
internalFormat )
}
 }

-   if (_mesa_is_gles3(ctx)) {
+   if (_mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility) {
switch (internalFormat) {
case GL_COMPRESSED_RGB8_ETC2:
case GL_COMPRESSED_SRGB8_ETC2:



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

[Mesa-dev] [PATCH] mesa: Allow ETC2/EAC formats with ARB_ES3_compatibility.

[Matt Turner]

Reported-by: Marek Olšák 
---
 src/mesa/main/teximage.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..e5260d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -520,7 +520,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint 
internalFormat )
   }
}
 
-   if (_mesa_is_gles3(ctx)) {
+   if (_mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility) {
   switch (internalFormat) {
   case GL_COMPRESSED_RGB8_ETC2:
   case GL_COMPRESSED_SRGB8_ETC2:
-- 
1.7.8.6

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

Re: [Mesa-dev] [PATCH 1/2] configure.ac: Don't check for X11 unconditionally.

[Matt Turner]

On Mon, Mar 4, 2013 at 11:14 AM, Brian Paul  wrote:
> On 03/04/2013 11:31 AM, Matt Turner wrote:
>>
>> X11 is already checked conditionally below.
>>
>> Fixes OSMesa-only configurations to not require X11.
>> ---
>>   configure.ac |8 
>>   1 files changed, 0 insertions(+), 8 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 7852595..1b13d06 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -832,20 +832,12 @@ if test "x$enable_dri" = xyes; then
>>   fi
>>   fi
>>
>> -dnl Find out if X is available.
>> -PKG_CHECK_MODULES([X11], [x11], [no_x=no], [no_x=yes])
>> -
>>   dnl Try to tell the user that the --x-* options are only used when
>>   dnl pkg-config is not available. This must be right after AC_PATH_XTRA.
>>   m4_divert_once([HELP_BEGIN],
>>   [These options are only used when the X libraries cannot be found by the
>>   pkg-config utility.])
>>
>> -dnl We need X for xlib and dri, so bomb now if it's not found
>> -if test "x$enable_glx" = xyes -a "x$no_x" = xyes; then
>> -AC_MSG_ERROR([X11 development libraries needed for GLX])
>> -fi
>> -
>>   dnl Direct rendering or just indirect rendering
>>   case "$host_os" in
>>   gnu*)
>
>
> The series LGMT.  Thanks, Matt!
>
> Candidates for the stable branches?

Sure.

> Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH 1/2] configure.ac: Don't check for X11 unconditionally.

[Brian Paul]

On 03/04/2013 11:31 AM, Matt Turner wrote:

X11 is already checked conditionally below.

Fixes OSMesa-only configurations to not require X11.
---
  configure.ac |8 
  1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7852595..1b13d06 100644
--- a/configure.ac
+++ b/configure.ac
@@ -832,20 +832,12 @@ if test "x$enable_dri" = xyes; then
  fi
  fi

-dnl Find out if X is available.
-PKG_CHECK_MODULES([X11], [x11], [no_x=no], [no_x=yes])
-
  dnl Try to tell the user that the --x-* options are only used when
  dnl pkg-config is not available. This must be right after AC_PATH_XTRA.
  m4_divert_once([HELP_BEGIN],
  [These options are only used when the X libraries cannot be found by the
  pkg-config utility.])

-dnl We need X for xlib and dri, so bomb now if it's not found
-if test "x$enable_glx" = xyes -a "x$no_x" = xyes; then
-AC_MSG_ERROR([X11 development libraries needed for GLX])
-fi
-
  dnl Direct rendering or just indirect rendering
  case "$host_os" in
  gnu*)


The series LGMT.  Thanks, Matt!

Candidates for the stable branches?

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

Re: [Mesa-dev] [PATCH] r600g/radeonsi: unreference previous fence in flush

[Jerome Glisse]

On Mon, Mar 4, 2013 at 2:05 PM, Michel Dänzer  wrote:
> On Mon, 2013-03-04 at 13:17 -0500, j.gli...@gmail.com wrote:
>> From: Jerome Glisse 
>>
>> Some code calling the flush function gave a fence pointer that point
>> to an old fence and should be unreference to avoid leaking fence.
>>
>> Candidate for 9.1
>>
>> Signed-off-by: Jerome Glisse 
>> ---
>>  src/gallium/drivers/r600/r600_pipe.c | 8 +---
>>  src/gallium/drivers/radeonsi/radeonsi_pipe.c | 9 ++---
>>  2 files changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_pipe.c 
>> b/src/gallium/drivers/r600/r600_pipe.c
>> index 78002ae..4bcfc67 100644
>> --- a/src/gallium/drivers/r600/r600_pipe.c
>> +++ b/src/gallium/drivers/r600/r600_pipe.c
>> @@ -145,12 +145,14 @@ static void r600_flush_from_st(struct pipe_context 
>> *ctx,
>>  enum pipe_flush_flags flags)
>>  {
>>   struct r600_context *rctx = (struct r600_context *)ctx;
>> - struct r600_fence **rfence = (struct r600_fence**)fence;
>> + struct r600_fence *rfence;
>>   unsigned fflags;
>>
>>   fflags = flags & PIPE_FLUSH_END_OF_FRAME ? RADEON_FLUSH_END_OF_FRAME : 
>> 0;
>> - if (rfence) {
>> - *rfence = r600_create_fence(rctx);
>> + if (fence) {
>> + rfence = r600_create_fence(rctx);
>> + ctx->screen->fence_reference(ctx->screen, fence,
>> + (struct pipe_fence_handle 
>> *)rfence);
>
> This change increases the reference count of the returned fence from 1
> to 2. I don't think that's correct, but if it is, the change should be
> amended with an explanation why.
>

No i have uncommited change in my tree. I will probably resend with
the xa patchset.

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

Re: [Mesa-dev] [PATCH] r600g/radeonsi: unreference previous fence in flush

[Michel Dänzer]

On Mon, 2013-03-04 at 13:17 -0500, j.gli...@gmail.com wrote: 
> From: Jerome Glisse 
> 
> Some code calling the flush function gave a fence pointer that point
> to an old fence and should be unreference to avoid leaking fence.
> 
> Candidate for 9.1
> 
> Signed-off-by: Jerome Glisse 
> ---
>  src/gallium/drivers/r600/r600_pipe.c | 8 +---
>  src/gallium/drivers/radeonsi/radeonsi_pipe.c | 9 ++---
>  2 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_pipe.c 
> b/src/gallium/drivers/r600/r600_pipe.c
> index 78002ae..4bcfc67 100644
> --- a/src/gallium/drivers/r600/r600_pipe.c
> +++ b/src/gallium/drivers/r600/r600_pipe.c
> @@ -145,12 +145,14 @@ static void r600_flush_from_st(struct pipe_context *ctx,
>  enum pipe_flush_flags flags)
>  {
>   struct r600_context *rctx = (struct r600_context *)ctx;
> - struct r600_fence **rfence = (struct r600_fence**)fence;
> + struct r600_fence *rfence;
>   unsigned fflags;
>  
>   fflags = flags & PIPE_FLUSH_END_OF_FRAME ? RADEON_FLUSH_END_OF_FRAME : 
> 0;
> - if (rfence) {
> - *rfence = r600_create_fence(rctx);
> + if (fence) {
> + rfence = r600_create_fence(rctx);
> + ctx->screen->fence_reference(ctx->screen, fence,
> + (struct pipe_fence_handle 
> *)rfence);

This change increases the reference count of the returned fence from 1
to 2. I don't think that's correct, but if it is, the change should be
amended with an explanation why.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Fix build of swrast only without libdrm

[Matt Turner]

On Thu, Feb 28, 2013 at 10:39 AM, Daniel Martin  wrote:
>
> Signed-off-by: Daniel Martin 
> ---
> There's a small logic error preventing mesa to be build with swrast only
> and not having libdrm.
>
> v2: "|| test" replaced by "-a"
>
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 5f95a78..7852595 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1095,7 +1095,7 @@ if test "x$enable_dri" = xyes; then
>  fi
>
>  # if we are building any dri driver other than swrast or using the dri 
> state tracker ...
> -if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" 
> = xyes; then
> +if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast -a "x$enable_dri" = 
> xyes; then
>  # ... libdrm is required
>  if test "x$have_libdrm" != xyes; then
>  AC_MSG_ERROR([DRI drivers requires libdrm >= $LIBDRM_REQUIRED])
> --
> 1.8.1.4

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

[Mesa-dev] [PATCH 2/2] configure.ac: Remove stale comment about --x-* arguments.

[Matt Turner]

Should have been removed with e273ed37.
---
 configure.ac |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1b13d06..ea56a04 100644
--- a/configure.ac
+++ b/configure.ac
@@ -832,12 +832,6 @@ if test "x$enable_dri" = xyes; then
 fi
 fi
 
-dnl Try to tell the user that the --x-* options are only used when
-dnl pkg-config is not available. This must be right after AC_PATH_XTRA.
-m4_divert_once([HELP_BEGIN],
-[These options are only used when the X libraries cannot be found by the
-pkg-config utility.])
-
 dnl Direct rendering or just indirect rendering
 case "$host_os" in
 gnu*)
-- 
1.7.8.6

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

[Mesa-dev] [PATCH 1/2] configure.ac: Don't check for X11 unconditionally.

[Matt Turner]

X11 is already checked conditionally below.

Fixes OSMesa-only configurations to not require X11.
---
 configure.ac |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7852595..1b13d06 100644
--- a/configure.ac
+++ b/configure.ac
@@ -832,20 +832,12 @@ if test "x$enable_dri" = xyes; then
 fi
 fi
 
-dnl Find out if X is available.
-PKG_CHECK_MODULES([X11], [x11], [no_x=no], [no_x=yes])
-
 dnl Try to tell the user that the --x-* options are only used when
 dnl pkg-config is not available. This must be right after AC_PATH_XTRA.
 m4_divert_once([HELP_BEGIN],
 [These options are only used when the X libraries cannot be found by the
 pkg-config utility.])
 
-dnl We need X for xlib and dri, so bomb now if it's not found
-if test "x$enable_glx" = xyes -a "x$no_x" = xyes; then
-AC_MSG_ERROR([X11 development libraries needed for GLX])
-fi
-
 dnl Direct rendering or just indirect rendering
 case "$host_os" in
 gnu*)
-- 
1.7.8.6

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

[Mesa-dev] [PATCH] r600g/radeonsi: unreference previous fence in flush

[j . glisse]

From: Jerome Glisse 

Some code calling the flush function gave a fence pointer that point
to an old fence and should be unreference to avoid leaking fence.

Candidate for 9.1

Signed-off-by: Jerome Glisse 
---
 src/gallium/drivers/r600/r600_pipe.c | 8 +---
 src/gallium/drivers/radeonsi/radeonsi_pipe.c | 9 ++---
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index 78002ae..4bcfc67 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -145,12 +145,14 @@ static void r600_flush_from_st(struct pipe_context *ctx,
   enum pipe_flush_flags flags)
 {
struct r600_context *rctx = (struct r600_context *)ctx;
-   struct r600_fence **rfence = (struct r600_fence**)fence;
+   struct r600_fence *rfence;
unsigned fflags;
 
fflags = flags & PIPE_FLUSH_END_OF_FRAME ? RADEON_FLUSH_END_OF_FRAME : 
0;
-   if (rfence) {
-   *rfence = r600_create_fence(rctx);
+   if (fence) {
+   rfence = r600_create_fence(rctx);
+   ctx->screen->fence_reference(ctx->screen, fence,
+   (struct pipe_fence_handle 
*)rfence);
}
/* flush gfx & dma ring, order does not matter as only one can be live 
*/
if (rctx->rings.dma.cs) {
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c 
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index acf3e2d..3272fe2 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
@@ -135,12 +135,15 @@ void radeonsi_flush(struct pipe_context *ctx, struct 
pipe_fence_handle **fence,
unsigned flags)
 {
struct r600_context *rctx = (struct r600_context *)ctx;
-   struct r600_fence **rfence = (struct r600_fence**)fence;
+   struct r600_fence *rfence;
struct pipe_query *render_cond = NULL;
unsigned render_cond_mode = 0;
 
-   if (rfence)
-   *rfence = r600_create_fence(rctx);
+   if (fence) {
+   rfence = r600_create_fence(rctx);
+   ctx->screen->fence_reference(ctx->screen, fence,
+   (struct pipe_fence_handle 
*)rfence);
+   }
 
/* Disable render condition. */
if (rctx->current_render_cond) {
-- 
1.7.11.7

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

[Mesa-dev] [Bug 61761] glPolygonOffsetEXT, OFFSET_BIAS incorrectly set to a huge number

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61761

--- Comment #4 from Blaž Hrastnik  ---
Yeah, it seems to be some obscurely ancient extension. The only reason I "used"
it is because I took over the work on OpenGL bindings for ruby, and the library
is over 6 years old, so some tests test really old pieces of OpenGL
(https://github.com/archSeer/opengl/blob/master/test/test_gl_ext_ext.rb#L29),
which is why I was able to report the past few bugs. More to come!

-- 
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 61761] glPolygonOffsetEXT, OFFSET_BIAS incorrectly set to a huge number

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61761

--- Comment #3 from Roland Scheidegger  ---
I guess if nvidia doesn't advertize it (and by the looks of it they never did)
it should be safe to remove (and amd doesn't seem to advertize it neither in
their closed-source drivers). After all PolygonOffset became core in OpenGL
1.1, so you'd be looking at OpenGL 1.0 apps potentially using it. Some of the
mesa demos actually can use it, though all of them will use the ordinary
PolygonOffset by default.

-- 
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 61761] glPolygonOffsetEXT, OFFSET_BIAS incorrectly set to a huge number

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61761

--- Comment #2 from Brian Paul  ---
I wonder if we should just drop the GL_EXT_polygon_offset extension.  I see
that NVIDIA doesn't advertise it.

-- 
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 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61764

--- Comment #4 from Blaž Hrastnik  ---
Ah yes, I have found that bit later in the documentation. Thank you for
clarification!

-- 
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 1/4] gallium: add get_sample_position interface

[Brian Paul]

On 03/03/2013 01:27 PM, Dave Airlie wrote:

From: Dave Airlie

This is to be used to implement glGet GL_SAMPLE_POSITION.

Signed-off-by: Dave Airlie
---
  src/gallium/include/pipe/p_context.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/gallium/include/pipe/p_context.h 
b/src/gallium/include/pipe/p_context.h
index 7ed946e..4ffee20 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -520,6 +520,10 @@ struct pipe_context {
 const uint *block_layout, const uint *grid_layout,
 uint32_t pc, const void *input);
 /*@}*/
+   void (*get_sample_position)(struct pipe_context *context,
+   int max_samples,
+   unsigned sample_index,
+   float *out_value);
  };


Should max_samples be unsigned?

-Brian

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

Re: [Mesa-dev] [PATCH 2/4] st/mesa: add support for get sample position

[Brian Paul]

Just minor formatting nits below.

On 03/03/2013 01:27 PM, Dave Airlie wrote:

From: Dave Airlie

This just calls into the gallium interface.

Signed-off-by: Dave Airlie
---
  src/mesa/sources.mak|  1 +
  src/mesa/state_tracker/st_cb_msaa.c | 52 +
  src/mesa/state_tracker/st_cb_msaa.h | 39 
  src/mesa/state_tracker/st_context.c |  2 ++
  4 files changed, 94 insertions(+)
  create mode 100644 src/mesa/state_tracker/st_cb_msaa.c
  create mode 100644 src/mesa/state_tracker/st_cb_msaa.h

diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 178ceb2..7498d96 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -224,6 +224,7 @@ STATETRACKER_FILES = \
$(SRCDIR)state_tracker/st_cb_eglimage.c \
$(SRCDIR)state_tracker/st_cb_fbo.c \
$(SRCDIR)state_tracker/st_cb_feedback.c \
+   $(SRCDIR)state_tracker/st_cb_msaa.c \
$(SRCDIR)state_tracker/st_cb_program.c \
$(SRCDIR)state_tracker/st_cb_queryobj.c \
$(SRCDIR)state_tracker/st_cb_rasterpos.c \
diff --git a/src/mesa/state_tracker/st_cb_msaa.c 
b/src/mesa/state_tracker/st_cb_msaa.c
new file mode 100644
index 000..688d6a3
--- /dev/null
+++ b/src/mesa/state_tracker/st_cb_msaa.c
@@ -0,0 +1,52 @@
+/**
+ *
+ * Copyright 2013 Red Hat
+ * 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 THE AUTHORS 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 "main/mfeatures.h"
+#include "main/bufferobj.h"
+#include "main/imports.h"
+
+#include "state_tracker/st_cb_msaa.h"
+#include "state_tracker/st_context.h"
+#include "state_tracker/st_cb_fbo.h"
+
+#include "pipe/p_context.h"


Put a blank line or two after the #include line.



+static void st_GetSamplePosition(struct gl_context *ctx,
+ struct gl_framebuffer *fb,
+ GLuint index,
+ GLfloat *outValue)


Put 'static void' on its own line.



+{
+   struct st_context *st = st_context(ctx);
+   struct st_renderbuffer *strb;
+
+   if (st->pipe->get_sample_position)
+  st->pipe->get_sample_position(st->pipe, fb->Visual.samples, index, 
outValue);
+}
+
+void st_init_msaa_functions(struct dd_function_table *functions)


'void' on its own line.



+{
+   functions->GetSamplePosition = st_GetSamplePosition;
+}
diff --git a/src/mesa/state_tracker/st_cb_msaa.h 
b/src/mesa/state_tracker/st_cb_msaa.h
new file mode 100644
index 000..ba4c06f
--- /dev/null
+++ b/src/mesa/state_tracker/st_cb_msaa.h
@@ -0,0 +1,39 @@
+/**
+ *
+ * Copyright 2013 Red Hat
+ * 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 THE AUTHORS 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

[Mesa-dev] [Bug 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61764

--- Comment #3 from Roland Scheidegger  ---
(In reply to comment #2)
> I'd still argue that this is a bug. If the extensions were removed, their
> implementation should be fully removed (as in, these functions, especially
> the EXT/ARB versions of them should be removed), instead of leaving some
> sort of a buggy shell, which can still be called (or at least can be tried
> to be called). So I'd just fully remove these, so there'd be no confusion.

No this is not correct. The problem is there never was a separate ARB_imaging
extension, this is (rather was) part of core but optionally supported. As such
there's language in the spec which says you have to return invalid_enum for
invalid operands and invalid_operation for unsupported functions belonging to
this imaging subset.

-- 
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] [RFC] OES_external_image for i965

[Kristian Høgsberg]

On Mon, Mar 4, 2013 at 10:11 AM, Pohjolainen, Topi
 wrote:
> On Mon, Mar 04, 2013 at 09:56:34AM -0500, Kristian H?gsberg wrote:
>> On Mon, Mar 4, 2013 at 4:55 AM, Pohjolainen, Topi
>>  wrote:
>> > On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote:
>> >> On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi
>> >>  wrote:
>> >> > On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote:
>> >> >> Hi Topi,
>> >> >>
>> >> >> > The second more or less questionable part is the support for 
>> >> >> > creating YUV
>> >> >> > buffers. In order to test for YUV sampling one needs a way of 
>> >> >> > providing them
>> >> >> > for the EGL stack. Here I chose to augment the dri driver backing 
>> >> >> > gbm as I
>> >> >> > couldn't come up with anything better. It may be helpful to take a 
>> >> >> > look at the
>> >> >> > corresponding piglit test case and framework support I've written 
>> >> >> > for it.
>> >> >>
>> >> >> You might want to take a look at the EGL_EXT_image_dma_buf_import[i] 
>> >> >> which has been written
>> >> >> specifically for this purpose. Though this does assume you have a 
>> >> >> driver which supports exporting a
>> >> >> YUV buffer it has allocated with dma_buf, such as a v4l2 driver or 
>> >> >> even ion on Android.
>> >> >>
>> >> >
>> >> > It certainly looks good addressing not only the individual plane setup 
>> >> > but
>> >> > allowing one to control also the conversion coefficients and subsampling
>> >> > position.
>> >> > Coming from piglit testing point of view, do you have any ideas where to
>> >> > allocate the buffers from? I guess people wouldn't be too happy seeing 
>> >> > v4l2 tied
>> >> > into piglit, for example.
>> >>
>> >> SInce you're already using intel specific ioctls to mmap the buffers,
>> >> I'd suggest you just go all the way and allocate using intel specific
>> >> ioctls (like my simple-yuv.c example).  I don't really see any other
>> >> approach, but it's not pretty...
>> >>
>> >
>> > I used gbm buffer objects in order to match the logic later in
>> > 'dri2_drm_create_image_khr()' which expects the buffer to be of the type
>> > 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm 
>> > buffer
>> > objects instead would require new target, I guess?
>>
>> Right... I'd use the extension Tom suggests:
>>
>> http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>>
>> which is mostly implemented by this patch:
>>
>> http://lists.freedesktop.org/archives/mesa-dev/2013-February/035429.html
>>
>> with just the EGL extension bits missing.  That way, you're also not
>> dependent on any specific window system.  As it is your test has to
>> run under gbm, using the dmabuf import extension it can run under any
>> window system.
>
> Just to clarify that I understood correctly. The actual creation of the buffer
> (and dma_buf exporting) would still be via hardware specific ioctls (in 
> intel's
> case GEM)? Your and Tom's material address only the importing side, or did I
> miss something?

Yes, that's correct.  You'll need intel create and export to fd
functions, but you are already mapping the bo using intel specific
ioctls.  So I think it's cleaner to just have a chipset specific
function to create the bo and return an fd, stride etc, and from there
on it's generic code where you feed it into the dma_buf_import
function.

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

[Mesa-dev] [Bug 61395] glEdgeFlag can't be set to false

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61395

Brian Paul  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Brian Paul  ---
Thanks for the reminder.  I just pushed it.
Commit b1390c7992c457f230cb5a7a64803b194de316e0

-- 
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 1/5] r600g: unify vgt states

[Jerome Glisse]

On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák  wrote:
> The states were split because we thought it caused a hardlock. Now we know
> the hardlock was caused by something else and has since been fixed.

For the serie:
Reviewed-by: Jerome Glisse 

> ---
>  src/gallium/drivers/r600/evergreen_state.c   |3 +--
>  src/gallium/drivers/r600/r600_hw_context.c   |1 -
>  src/gallium/drivers/r600/r600_pipe.h |6 --
>  src/gallium/drivers/r600/r600_state.c|3 +--
>  src/gallium/drivers/r600/r600_state_common.c |   22 +++---
>  5 files changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index 205bbc5..244989d 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -2615,8 +2615,7 @@ void evergreen_init_state_functions(struct r600_context 
> *rctx)
> r600_init_atom(rctx, 
> &rctx->samplers[PIPE_SHADER_GEOMETRY].views.atom, id++, 
> evergreen_emit_gs_sampler_views, 0);
> r600_init_atom(rctx, 
> &rctx->samplers[PIPE_SHADER_FRAGMENT].views.atom, id++, 
> evergreen_emit_ps_sampler_views, 0);
>
> -   r600_init_atom(rctx, &rctx->vgt_state.atom, id++, 
> r600_emit_vgt_state, 6);
> -   r600_init_atom(rctx, &rctx->vgt2_state.atom, id++, 
> r600_emit_vgt2_state, 3);
> +   r600_init_atom(rctx, &rctx->vgt_state.atom, id++, 
> r600_emit_vgt_state, 7);
>
> if (rctx->chip_class == EVERGREEN) {
> r600_init_atom(rctx, &rctx->sample_mask.atom, id++, 
> evergreen_emit_sample_mask, 3);
> diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
> b/src/gallium/drivers/r600/r600_hw_context.c
> index 91af6b8..b78b004 100644
> --- a/src/gallium/drivers/r600/r600_hw_context.c
> +++ b/src/gallium/drivers/r600/r600_hw_context.c
> @@ -827,7 +827,6 @@ void r600_begin_new_cs(struct r600_context *ctx)
> ctx->framebuffer.atom.dirty = true;
> ctx->poly_offset_state.atom.dirty = true;
> ctx->vgt_state.atom.dirty = true;
> -   ctx->vgt2_state.atom.dirty = true;
> ctx->sample_mask.atom.dirty = true;
> ctx->scissor.atom.dirty = true;
> ctx->config_state.atom.dirty = true;
> diff --git a/src/gallium/drivers/r600/r600_pipe.h 
> b/src/gallium/drivers/r600/r600_pipe.h
> index 570a284..4cfade1 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -127,10 +127,6 @@ struct r600_vgt_state {
> struct r600_atom atom;
> uint32_t vgt_multi_prim_ib_reset_en;
> uint32_t vgt_multi_prim_ib_reset_indx;
> -};
> -
> -struct r600_vgt2_state {
> -   struct r600_atom atom;
> uint32_t vgt_indx_offset;
>  };
>
> @@ -506,7 +502,6 @@ struct r600_context {
> struct r600_config_stateconfig_state;
> struct r600_stencil_ref_state   stencil_ref;
> struct r600_vgt_state   vgt_state;
> -   struct r600_vgt2_state  vgt2_state;
> struct r600_viewport_state  viewport;
> /* Shaders and shader resources. */
> struct r600_cso_state   vertex_fetch_shader;
> @@ -733,7 +728,6 @@ void r600_emit_cso_state(struct r600_context *rctx, 
> struct r600_atom *atom);
>  void r600_emit_alphatest_state(struct r600_context *rctx, struct r600_atom 
> *atom);
>  void r600_emit_blend_color(struct r600_context *rctx, struct r600_atom 
> *atom);
>  void r600_emit_vgt_state(struct r600_context *rctx, struct r600_atom *atom);
> -void r600_emit_vgt2_state(struct r600_context *rctx, struct r600_atom *atom);
>  void r600_emit_clip_misc_state(struct r600_context *rctx, struct r600_atom 
> *atom);
>  void r600_emit_stencil_ref(struct r600_context *rctx, struct r600_atom 
> *atom);
>  void r600_emit_viewport_state(struct r600_context *rctx, struct r600_atom 
> *atom);
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index bbff6bd..fd3b14e 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2312,8 +2312,7 @@ void r600_init_state_functions(struct r600_context 
> *rctx)
> r600_init_atom(rctx, 
> &rctx->samplers[PIPE_SHADER_FRAGMENT].views.atom, id++, 
> r600_emit_ps_sampler_views, 0);
> r600_init_atom(rctx, &rctx->vertex_buffer_state.atom, id++, 
> r600_emit_vertex_buffers, 0);
>
> -   r600_init_atom(rctx, &rctx->vgt_state.atom, id++, 
> r600_emit_vgt_state, 6);
> -   r600_init_atom(rctx, &rctx->vgt2_state.atom, id++, 
> r600_emit_vgt2_state, 3);
> +   r600_init_atom(rctx, &rctx->vgt_state.atom, id++, 
> r600_emit_vgt_state, 7);
>
> r600_init_atom(rctx, &rctx->seamless_cube_map.atom, id++, 
> r600_emit_seamless_cube_map, 3);
> r600_init_atom(rctx, &rctx->sample_mask.atom, id++, 
> r600_emit_sample_mask, 3);
> diff --git a/src/gallium/drivers/r600/r600_state_common.c 
> b/src/gallium/drivers/r600/r600_state_comm

Re: [Mesa-dev] [PATCH 1/6] r600g: inline r600_pipe_shader function

[Jerome Glisse]

On Sun, Mar 3, 2013 at 8:39 AM, Marek Olšák  wrote:
> also change names of other functions, so that they make sense

For the serie:
Reviewed-by: Jerome Glisse 

> ---
>  src/gallium/drivers/r600/evergreen_state.c   |4 +-
>  src/gallium/drivers/r600/r600_pipe.h |8 +--
>  src/gallium/drivers/r600/r600_shader.c   |   89 
> --
>  src/gallium/drivers/r600/r600_state.c|4 +-
>  src/gallium/drivers/r600/r600_state_common.c |4 +-
>  5 files changed, 51 insertions(+), 58 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index 97f91df..5c7cd40 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3311,7 +3311,7 @@ void evergreen_init_atom_start_cs(struct r600_context 
> *rctx)
> eg_store_loop_const(cb, R_03A200_SQ_LOOP_CONST_0 + (32 * 4), 
> 0x01000FFF);
>  }
>
> -void evergreen_pipe_shader_ps(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader)
> +void evergreen_update_ps_state(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader)
>  {
> struct r600_context *rctx = (struct r600_context *)ctx;
> struct r600_pipe_state *rstate = &shader->rstate;
> @@ -3460,7 +3460,7 @@ void evergreen_pipe_shader_ps(struct pipe_context *ctx, 
> struct r600_pipe_shader
> shader->flatshade = rctx->rasterizer->flatshade;
>  }
>
> -void evergreen_pipe_shader_vs(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader)
> +void evergreen_update_vs_state(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader)
>  {
> struct r600_context *rctx = (struct r600_context *)ctx;
> struct r600_pipe_state *rstate = &shader->rstate;
> diff --git a/src/gallium/drivers/r600/r600_pipe.h 
> b/src/gallium/drivers/r600/r600_pipe.h
> index 3eb2968..28c7de3 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -626,8 +626,8 @@ void cayman_init_common_regs(struct r600_command_buffer 
> *cb,
>
>  void evergreen_init_state_functions(struct r600_context *rctx);
>  void evergreen_init_atom_start_cs(struct r600_context *rctx);
> -void evergreen_pipe_shader_ps(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader);
> -void evergreen_pipe_shader_vs(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader);
> +void evergreen_update_ps_state(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader);
> +void evergreen_update_vs_state(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader);
>  void *evergreen_create_db_flush_dsa(struct r600_context *rctx);
>  void *evergreen_create_resolve_blend(struct r600_context *rctx);
>  void *evergreen_create_decompress_blend(struct r600_context *rctx);
> @@ -701,8 +701,8 @@ r600_create_sampler_view_custom(struct pipe_context *ctx,
> unsigned width_first_level, unsigned 
> height_first_level);
>  void r600_init_state_functions(struct r600_context *rctx);
>  void r600_init_atom_start_cs(struct r600_context *rctx);
> -void r600_pipe_shader_ps(struct pipe_context *ctx, struct r600_pipe_shader 
> *shader);
> -void r600_pipe_shader_vs(struct pipe_context *ctx, struct r600_pipe_shader 
> *shader);
> +void r600_update_ps_state(struct pipe_context *ctx, struct r600_pipe_shader 
> *shader);
> +void r600_update_vs_state(struct pipe_context *ctx, struct r600_pipe_shader 
> *shader);
>  void *r600_create_db_flush_dsa(struct r600_context *rctx);
>  void *r600_create_resolve_blend(struct r600_context *rctx);
>  void *r700_create_resolve_blend(struct r600_context *rctx);
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index 949191a..7ecab7b 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -58,52 +58,6 @@ issued in the w slot as well.
>  The compiler must issue the source argument to slots z, y, and x
>  */
>
> -static int r600_pipe_shader(struct pipe_context *ctx, struct 
> r600_pipe_shader *shader)
> -{
> -   struct r600_context *rctx = (struct r600_context *)ctx;
> -   struct r600_shader *rshader = &shader->shader;
> -   uint32_t *ptr;
> -   int i;
> -
> -   /* copy new shader */
> -   if (shader->bo == NULL) {
> -   shader->bo = (struct r600_resource*)
> -   pipe_buffer_create(ctx->screen, PIPE_BIND_CUSTOM, 
> PIPE_USAGE_IMMUTABLE, rshader->bc.ndw * 4);
> -   if (shader->bo == NULL) {
> -   return -ENOMEM;
> -   }
> -   ptr = r600_buffer_mmap_sync_with_rings(rctx, shader->bo, 
> PIPE_TRANSFER_WRITE);
> -   if (R600_BIG_ENDIAN) {
> -   for (i = 0; i < rshader->bc.ndw; ++i) {
> -   ptr[i] = bswap_32(rshader->bc.bytecode[i]);
> -   }
> -   } else {
> -   

Re: [Mesa-dev] [PATCH] r600g: allocate FMASK right after the texture, so that it's aligned with it

[Jerome Glisse]

On Sun, Mar 3, 2013 at 9:13 AM, Marek Olšák  wrote:
> This avoids the kernel CS checker errors with MSAA textures.

Reviewed-by: Jerome Glisse 

> ---
>  src/gallium/drivers/r600/r600_texture.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_texture.c 
> b/src/gallium/drivers/r600/r600_texture.c
> index 484045e..4825592 100644
> --- a/src/gallium/drivers/r600/r600_texture.c
> +++ b/src/gallium/drivers/r600/r600_texture.c
> @@ -435,8 +435,8 @@ r600_texture_create_object(struct pipe_screen *screen,
> }
>
> if (base->nr_samples > 1 && !rtex->is_depth && !buf) {
> -   r600_texture_allocate_cmask(rscreen, rtex);
> r600_texture_allocate_fmask(rscreen, rtex);
> +   r600_texture_allocate_cmask(rscreen, rtex);
> }
>
> if (!rtex->is_depth && base->nr_samples > 1 &&
> --
> 1.7.10.4
>
> ___
> 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] [RFC] OES_external_image for i965

[Pohjolainen, Topi]

On Mon, Mar 04, 2013 at 09:56:34AM -0500, Kristian H?gsberg wrote:
> On Mon, Mar 4, 2013 at 4:55 AM, Pohjolainen, Topi
>  wrote:
> > On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote:
> >> On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi
> >>  wrote:
> >> > On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote:
> >> >> Hi Topi,
> >> >>
> >> >> > The second more or less questionable part is the support for creating 
> >> >> > YUV
> >> >> > buffers. In order to test for YUV sampling one needs a way of 
> >> >> > providing them
> >> >> > for the EGL stack. Here I chose to augment the dri driver backing gbm 
> >> >> > as I
> >> >> > couldn't come up with anything better. It may be helpful to take a 
> >> >> > look at the
> >> >> > corresponding piglit test case and framework support I've written for 
> >> >> > it.
> >> >>
> >> >> You might want to take a look at the EGL_EXT_image_dma_buf_import[i] 
> >> >> which has been written
> >> >> specifically for this purpose. Though this does assume you have a 
> >> >> driver which supports exporting a
> >> >> YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even 
> >> >> ion on Android.
> >> >>
> >> >
> >> > It certainly looks good addressing not only the individual plane setup 
> >> > but
> >> > allowing one to control also the conversion coefficients and subsampling
> >> > position.
> >> > Coming from piglit testing point of view, do you have any ideas where to
> >> > allocate the buffers from? I guess people wouldn't be too happy seeing 
> >> > v4l2 tied
> >> > into piglit, for example.
> >>
> >> SInce you're already using intel specific ioctls to mmap the buffers,
> >> I'd suggest you just go all the way and allocate using intel specific
> >> ioctls (like my simple-yuv.c example).  I don't really see any other
> >> approach, but it's not pretty...
> >>
> >
> > I used gbm buffer objects in order to match the logic later in
> > 'dri2_drm_create_image_khr()' which expects the buffer to be of the type
> > 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm 
> > buffer
> > objects instead would require new target, I guess?
> 
> Right... I'd use the extension Tom suggests:
> 
> http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> 
> which is mostly implemented by this patch:
> 
> http://lists.freedesktop.org/archives/mesa-dev/2013-February/035429.html
> 
> with just the EGL extension bits missing.  That way, you're also not
> dependent on any specific window system.  As it is your test has to
> run under gbm, using the dmabuf import extension it can run under any
> window system.

Just to clarify that I understood correctly. The actual creation of the buffer
(and dma_buf exporting) would still be via hardware specific ioctls (in intel's
case GEM)? Your and Tom's material address only the importing side, or did I
miss something?

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

Re: [Mesa-dev] [RFC] OES_external_image for i965

[Kristian Høgsberg]

On Mon, Mar 4, 2013 at 4:55 AM, Pohjolainen, Topi
 wrote:
> On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote:
>> On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi
>>  wrote:
>> > On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote:
>> >> Hi Topi,
>> >>
>> >> > The second more or less questionable part is the support for creating 
>> >> > YUV
>> >> > buffers. In order to test for YUV sampling one needs a way of providing 
>> >> > them
>> >> > for the EGL stack. Here I chose to augment the dri driver backing gbm 
>> >> > as I
>> >> > couldn't come up with anything better. It may be helpful to take a look 
>> >> > at the
>> >> > corresponding piglit test case and framework support I've written for 
>> >> > it.
>> >>
>> >> You might want to take a look at the EGL_EXT_image_dma_buf_import[i] 
>> >> which has been written
>> >> specifically for this purpose. Though this does assume you have a driver 
>> >> which supports exporting a
>> >> YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even 
>> >> ion on Android.
>> >>
>> >
>> > It certainly looks good addressing not only the individual plane setup but
>> > allowing one to control also the conversion coefficients and subsampling
>> > position.
>> > Coming from piglit testing point of view, do you have any ideas where to
>> > allocate the buffers from? I guess people wouldn't be too happy seeing 
>> > v4l2 tied
>> > into piglit, for example.
>>
>> SInce you're already using intel specific ioctls to mmap the buffers,
>> I'd suggest you just go all the way and allocate using intel specific
>> ioctls (like my simple-yuv.c example).  I don't really see any other
>> approach, but it's not pretty...
>>
>
> I used gbm buffer objects in order to match the logic later in
> 'dri2_drm_create_image_khr()' which expects the buffer to be of the type
> 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm buffer
> objects instead would require new target, I guess?

Right... I'd use the extension Tom suggests:

http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt

which is mostly implemented by this patch:

http://lists.freedesktop.org/archives/mesa-dev/2013-February/035429.html

with just the EGL extension bits missing.  That way, you're also not
dependent on any specific window system.  As it is your test has to
run under gbm, using the dmabuf import extension it can run under any
window system.

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

Re: [Mesa-dev] [PATCH 2/6] r600g: cleanup #include recursion between r600_pipe.h and evergreen_compute.h

[Tom Stellard]

On Fri, Mar 01, 2013 at 05:55:31PM +0100, Marek Olšák wrote:

Patches 2-4 are:

Reviewed-by: Tom Stellard 

Thanks for working on this, it is a nice improvement.

-Tom

> ---
>  src/gallium/drivers/r600/compute_memory_pool.c|1 +
>  src/gallium/drivers/r600/evergreen_compute.h  |2 +-
>  src/gallium/drivers/r600/evergreen_compute_internal.c |1 +
>  src/gallium/drivers/r600/r600_pipe.c  |1 +
>  src/gallium/drivers/r600/r600_pipe.h  |1 -
>  src/gallium/drivers/r600/r600_resource.c  |1 +
>  src/gallium/drivers/r600/r600_texture.c   |1 +
>  7 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
> b/src/gallium/drivers/r600/compute_memory_pool.c
> index 5b1cb1b..8896909 100644
> --- a/src/gallium/drivers/r600/compute_memory_pool.c
> +++ b/src/gallium/drivers/r600/compute_memory_pool.c
> @@ -39,6 +39,7 @@
>  #include "r600_pipe.h"
>  #include "r600_formats.h"
>  #include "compute_memory_pool.h"
> +#include "evergreen_compute.h"
>  #include "evergreen_compute_internal.h"
>  #include 
>  
> diff --git a/src/gallium/drivers/r600/evergreen_compute.h 
> b/src/gallium/drivers/r600/evergreen_compute.h
> index e68ebd8..db57520 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.h
> +++ b/src/gallium/drivers/r600/evergreen_compute.h
> @@ -32,7 +32,7 @@
>  struct r600_atom;
>  struct evergreen_compute_resource;
>  
> -void *evergreen_create_compute_state(struct pipe_context *ctx, const const 
> struct pipe_compute_state *cso);
> +void *evergreen_create_compute_state(struct pipe_context *ctx, const struct 
> pipe_compute_state *cso);
>  void evergreen_delete_compute_state(struct pipe_context *ctx, void *state);
>  void evergreen_compute_upload_input(struct pipe_context *context, const uint 
> *block_layout, const uint *grid_layout, const void *input);
>  void evergreen_init_atom_start_compute_cs(struct r600_context *rctx);
> diff --git a/src/gallium/drivers/r600/evergreen_compute_internal.c 
> b/src/gallium/drivers/r600/evergreen_compute_internal.c
> index 2e8e9da..60bb3bf 100644
> --- a/src/gallium/drivers/r600/evergreen_compute_internal.c
> +++ b/src/gallium/drivers/r600/evergreen_compute_internal.c
> @@ -42,6 +42,7 @@
>  #include "r600_pipe.h"
>  #include "r600_formats.h"
>  #include "evergreend.h"
> +#include "evergreen_compute.h"
>  #include "evergreen_compute_internal.h"
>  #include "r600_hw_context_priv.h"
>  
> diff --git a/src/gallium/drivers/r600/r600_pipe.c 
> b/src/gallium/drivers/r600/r600_pipe.c
> index e81856c..05bb755 100644
> --- a/src/gallium/drivers/r600/r600_pipe.c
> +++ b/src/gallium/drivers/r600/r600_pipe.c
> @@ -23,6 +23,7 @@
>  #include "r600_pipe.h"
>  #include "r600_public.h"
>  #include "r600_isa.h"
> +#include "evergreen_compute.h"
>  #include "r600d.h"
>  
>  #include 
> diff --git a/src/gallium/drivers/r600/r600_pipe.h 
> b/src/gallium/drivers/r600/r600_pipe.h
> index cb52083..c178285 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -33,7 +33,6 @@
>  #include "r600_llvm.h"
>  #include "r600_public.h"
>  #include "r600_resource.h"
> -#include "evergreen_compute.h"
>  
>  #define R600_NUM_ATOMS 38
>  
> diff --git a/src/gallium/drivers/r600/r600_resource.c 
> b/src/gallium/drivers/r600/r600_resource.c
> index 5e637f6..5962f8a 100644
> --- a/src/gallium/drivers/r600/r600_resource.c
> +++ b/src/gallium/drivers/r600/r600_resource.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include "r600_pipe.h"
> +#include "evergreen_compute.h"
>  
>  static struct pipe_resource *r600_resource_create(struct pipe_screen *screen,
>   const struct pipe_resource 
> *templ)
> diff --git a/src/gallium/drivers/r600/r600_texture.c 
> b/src/gallium/drivers/r600/r600_texture.c
> index aefc40f..1c071cb 100644
> --- a/src/gallium/drivers/r600/r600_texture.c
> +++ b/src/gallium/drivers/r600/r600_texture.c
> @@ -25,6 +25,7 @@
>   *  Corbin Simpson
>   */
>  #include "r600_formats.h"
> +#include "evergreen_compute.h"
>  #include "r600d.h"
>  
>  #include 
> -- 
> 1.7.10.4
> 
> ___
> 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 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61764

--- Comment #2 from Blaž Hrastnik  ---
I'd still argue that this is a bug. If the extensions were removed, their
implementation should be fully removed (as in, these functions, especially the
EXT/ARB versions of them should be removed), instead of leaving some sort of a
buggy shell, which can still be called (or at least can be tried to be called).
So I'd just fully remove these, so there'd be no confusion.

-- 
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 60121] build - libvdpau_softpipe fails at runtime.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60121

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Andy Furniss  ---
fixed by e29124717eae4f8d329bb6a9707b802c0ff4bdd9

-- 
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 3/4] st/mesa: add support for ARB_texture_multisample

[Marek Olšák]

On Sun, Mar 3, 2013 at 9:27 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This adds support to the mesa state tracker for ARB_texture_multisample.
>
> hardware doesn't seem to use a different texture instructions, so
> I don't think we need to create one for TGSI at this time.
>
> Thanks to Marek for fixes to sample number picking.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/state_tracker/st_atom_framebuffer.c |  1 +
>  src/mesa/state_tracker/st_atom_msaa.c|  2 ++
>  src/mesa/state_tracker/st_cb_bitmap.c|  4 +--
>  src/mesa/state_tracker/st_cb_drawpixels.c|  2 +-
>  src/mesa/state_tracker/st_cb_fbo.c   |  2 +-
>  src/mesa/state_tracker/st_cb_texture.c   | 41 
> 
>  src/mesa/state_tracker/st_extensions.c   |  7 +
>  src/mesa/state_tracker/st_gen_mipmap.c   |  1 +
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 17 ++--
>  src/mesa/state_tracker/st_mesa_to_tgsi.c |  2 ++
>  src/mesa/state_tracker/st_texture.c  |  8 +-
>  src/mesa/state_tracker/st_texture.h  |  1 +
>  12 files changed, 74 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c 
> b/src/mesa/state_tracker/st_atom_framebuffer.c
> index 3df8691..c752640 100644
> --- a/src/mesa/state_tracker/st_atom_framebuffer.c
> +++ b/src/mesa/state_tracker/st_atom_framebuffer.c
> @@ -59,6 +59,7 @@ update_renderbuffer_surface(struct st_context *st,
> enum pipe_format format = st->ctx->Color.sRGBEnabled ? resource->format : 
> util_format_linear(resource->format);
>
> if (!strb->surface ||
> +   strb->surface->texture->nr_samples != strb->Base.NumSamples ||
> strb->surface->format != format ||
> strb->surface->texture != resource ||
> strb->surface->width != rtt_width ||
> diff --git a/src/mesa/state_tracker/st_atom_msaa.c 
> b/src/mesa/state_tracker/st_atom_msaa.c
> index 9baa4fc..b749a17 100644
> --- a/src/mesa/state_tracker/st_atom_msaa.c
> +++ b/src/mesa/state_tracker/st_atom_msaa.c
> @@ -63,6 +63,8 @@ static void update_sample_mask( struct st_context *st )
>  sample_mask = ~sample_mask;
>}
>/* TODO merge with app-supplied sample mask */
> +  if (st->ctx->Multisample.SampleMask)
> + sample_mask = st->ctx->Multisample.SampleMaskValue;
> }
>
> /* mask off unused bits or don't care? */
> diff --git a/src/mesa/state_tracker/st_cb_bitmap.c 
> b/src/mesa/state_tracker/st_cb_bitmap.c
> index 36fffe9..d7a95e2 100644
> --- a/src/mesa/state_tracker/st_cb_bitmap.c
> +++ b/src/mesa/state_tracker/st_cb_bitmap.c
> @@ -299,7 +299,7 @@ make_bitmap_texture(struct gl_context *ctx, GLsizei 
> width, GLsizei height,
>  * Create texture to hold bitmap pattern.
>  */
> pt = st_texture_create(st, st->internal_target, st->bitmap.tex_format,
> -  0, width, height, 1, 1,
> +  0, width, height, 1, 1, 0,
>PIPE_BIND_SAMPLER_VIEW);
> if (!pt) {
>_mesa_unmap_pbo_source(ctx, unpack);
> @@ -568,7 +568,7 @@ reset_cache(struct st_context *st)
> cache->texture = st_texture_create(st, PIPE_TEXTURE_2D,
>st->bitmap.tex_format, 0,
>BITMAP_CACHE_WIDTH, 
> BITMAP_CACHE_HEIGHT,
> -  1, 1,
> +  1, 1, 0,
>   PIPE_BIND_SAMPLER_VIEW);
>  }
>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
> b/src/mesa/state_tracker/st_cb_drawpixels.c
> index e282bf9..e609eb5 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -463,7 +463,7 @@ alloc_texture(struct st_context *st, GLsizei width, 
> GLsizei height,
> struct pipe_resource *pt;
>
> pt = st_texture_create(st, st->internal_target, texFormat, 0,
> -  width, height, 1, 1, PIPE_BIND_SAMPLER_VIEW);
> +  width, height, 1, 1, 0, PIPE_BIND_SAMPLER_VIEW);
>
> return pt;
>  }
> diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
> b/src/mesa/state_tracker/st_cb_fbo.c
> index 72bc960..cf3e27f 100644
> --- a/src/mesa/state_tracker/st_cb_fbo.c
> +++ b/src/mesa/state_tracker/st_cb_fbo.c
> @@ -430,7 +430,7 @@ st_render_texture(struct gl_context *ctx,
> strb->rtt_level = att->TextureLevel;
> strb->rtt_face = att->CubeMapFace;
> strb->rtt_slice = att->Zoffset;
> -
> +   rb->NumSamples = texImage->NumSamples;
> rb->Width = texImage->Width2;
> rb->Height = texImage->Height2;
> rb->_BaseFormat = texImage->_BaseFormat;
> diff --git a/src/mesa/state_tracker/st_cb_texture.c 
> b/src/mesa/state_tracker/st_cb_texture.c
> index c922a31..385bac6 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -78,6 +78,8 @@ gl_target_to_pipe(GLenum target)
> case GL_TEXTURE_2D

[Mesa-dev] [PATCH 2/2] intel: Support depth-15 Visuals

[Chris Wilson]

Note: This is a candidate for the stable branches.
Signed-off-by: Chris Wilson 
---
 src/mesa/drivers/dri/intel/intel_screen.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index d223a0b..5beea37 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -789,8 +789,10 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
 
_mesa_initialize_window_framebuffer(fb, mesaVis);
 
-   if (mesaVis->redBits == 5)
+   if (mesaVis->greenBits == 6)
   rgbFormat = MESA_FORMAT_RGB565;
+   else if (mesaVis->greenBits == 5)
+  rgbFormat = MESA_FORMAT_ARGB1555;
else if (mesaVis->sRGBCapable)
   rgbFormat = MESA_FORMAT_SARGB8;
else if (mesaVis->alphaBits == 0)
@@ -1023,6 +1025,7 @@ static __DRIconfig**
 intel_screen_make_configs(__DRIscreen *dri_screen)
 {
static const gl_format formats[] = {
+  MESA_FORMAT_ARGB1555,
   MESA_FORMAT_RGB565,
   MESA_FORMAT_ARGB
};
@@ -1051,7 +1054,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
   depth_bits[0] = 0;
   stencil_bits[0] = 0;
 
-  if (formats[i] == MESA_FORMAT_RGB565) {
+  if (formats[i] == MESA_FORMAT_ARGB1555 ||
+ formats[i] == MESA_FORMAT_RGB565) {
  depth_bits[1] = 16;
  stencil_bits[1] = 0;
  if (screen->gen >= 6) {
@@ -1080,7 +1084,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
for (int i = 0; i < ARRAY_SIZE(formats); i++) {
   __DRIconfig **new_configs;
 
-  if (formats[i] == MESA_FORMAT_RGB565) {
+  if (formats[i] == MESA_FORMAT_ARGB1555 ||
+ formats[i] == MESA_FORMAT_RGB565) {
  depth_bits[0] = 16;
  stencil_bits[0] = 0;
   } else {
@@ -1120,7 +1125,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
   depth_bits[0] = 0;
   stencil_bits[0] = 0;
 
-  if (formats[i] == MESA_FORMAT_RGB565) {
+  if (formats[i] == MESA_FORMAT_ARGB1555 ||
+ formats[i] == MESA_FORMAT_RGB565) {
  depth_bits[1] = 16;
  stencil_bits[1] = 0;
   } else {
-- 
1.7.10.4

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

[Mesa-dev] [PATCH 1/2] dri: Support depth-15 Visuals

[Chris Wilson]

Note: This is a candidate for the stable branches.
Signed-off-by: Chris Wilson 
---
 src/mesa/drivers/dri/common/utils.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/common/utils.c 
b/src/mesa/drivers/dri/common/utils.c
index ac0773b..41cab13 100644
--- a/src/mesa/drivers/dri/common/utils.c
+++ b/src/mesa/drivers/dri/common/utils.c
@@ -189,6 +189,8 @@ driCreateConfigs(gl_format format,
   { 0x00FF, 0xFF00, 0x00FF, 0x },
   /* MESA_FORMAT_ARGB */
   { 0x00FF, 0xFF00, 0x00FF, 0xFF00 },
+  /* MESA_FORMAT_ARGB1555 */
+  { 0x7c00, 0x03E0, 0x001F, 0x8000 },
};
 
const uint32_t * masks;
@@ -204,6 +206,9 @@ driCreateConfigs(gl_format format,
bool is_srgb;
 
switch (format) {
+   case MESA_FORMAT_ARGB1555:
+  masks = masks_table[3];
+  break;
case MESA_FORMAT_RGB565:
   masks = masks_table[0];
   break;
-- 
1.7.10.4

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

Re: [Mesa-dev] multisample clears

[Marek Olšák]

On Mon, Mar 4, 2013 at 4:54 AM, Dave Airlie  wrote:
> I've been playing with softpipe msaa on and off, but I hit a problem
> with the clears and am just wondering if the state tracker should be
> doing something like this.
>
> Or maybe only if any bound buffer has nr_samples > 1, or fallback to
> the non-quad draw method.
>
> I can't see how else the driver could distinguish a multisample clear.
>
> The other problem I have and not figuring out is if rendering to a
> buffer with multisample off, then turning it on is meant to be
> meaningful, if you have to clear
> the buffer in between, then with this fixed it should be cool.
>
> Dave.
>
> From e1ee59d87ba42d8a58be640ee1fd2b952414f45e Mon Sep 17 00:00:00 2001
> From: Dave Airlie 
> Date: Mon, 4 Mar 2013 13:39:17 +1000
> Subject: [PATCH] st/mesa: enable multisample in clear quad code
>
> Not sure if this is correct at all

For clears, blits, and the like, multisampling doesn't have to be
enabled, which means pixel values are stored in all samples regardless
of sample positions.

Multisampling can be problematic if the rendered quad doesn't cover
whole pixels (floating-point precision may play a role, not sure), so
it's better not to enable it.

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

Re: [Mesa-dev] [PATCH 4/4] r600g: add support for remaining bits for multisample texture

[Marek Olšák]

The sample positions can be found in r600_emit_msaa_state,
evergreen_emit_msaa_state, and cayman_emit_msaa_state, though
extracting them from the arrays might not be so straightforward.

Marek

On Sun, Mar 3, 2013 at 9:27 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> get sample position is most definitely wrong, need to find out what
> sample positions the hardware uses.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/r600/r600_shader.c   |  1 +
>  src/gallium/drivers/r600/r600_state_common.c | 35 
> 
>  2 files changed, 36 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index 8642463..5fd3f83 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -4705,6 +4705,7 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
> tex.src_sel_z = tex.src_sel_y;
> }
> } else if (inst->Texture.Texture == TGSI_TEXTURE_2D_ARRAY ||
> +  inst->Texture.Texture == TGSI_TEXTURE_2D_ARRAY_MSAA ||
>inst->Texture.Texture == TGSI_TEXTURE_SHADOW2D_ARRAY ||
>((inst->Texture.Texture == TGSI_TEXTURE_CUBE_ARRAY ||
> inst->Texture.Texture == TGSI_TEXTURE_SHADOWCUBE_ARRAY) &&
> diff --git a/src/gallium/drivers/r600/r600_state_common.c 
> b/src/gallium/drivers/r600/r600_state_common.c
> index 22ac846..8c8b665 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -1748,6 +1748,39 @@ bool sampler_state_needs_border_color(const struct 
> pipe_sampler_state *state)
> wrap_mode_uses_border_color(state->wrap_r, linear_filter));
>  }
>
> +static void r600_get_sample_position(struct pipe_context *ctx,
> +int max_sample,
> +unsigned sample_index,
> +float *out_value)
> +{
> +   switch (max_sample) {
> +   case 1:
> +   default:
> +   out_value[0] = out_value[1] = 0.5;
> +   break;
> +   case 4:
> +   switch (sample_index) {
> +   case 0:
> +   out_value[0] = 0.25;
> +   out_value[1] = 0.25;
> +   break;
> +   case 1:
> +   out_value[0] = 0.25;
> +   out_value[1] = 0.75;
> +   break;
> +   case 2:
> +   out_value[0] = 0.75;
> +   out_value[1] = 0.25;
> +   break;
> +   case 3:
> +   out_value[0] = 0.75;
> +   out_value[1] = 0.75;
> +   break;
> +   }
> +   break;
> +   }
> +}
> +
>  /* keep this at the end of this file, please */
>  void r600_init_common_state_functions(struct r600_context *rctx)
>  {
> @@ -1785,6 +1818,8 @@ void r600_init_common_state_functions(struct 
> r600_context *rctx)
> rctx->context.stream_output_target_destroy = r600_so_target_destroy;
> rctx->context.set_stream_output_targets = r600_set_streamout_targets;
> rctx->context.draw_vbo = r600_draw_vbo;
> +
> +   rctx->context.get_sample_position = r600_get_sample_position;
>  }
>
>  #if R600_TRACE_CS
> --
> 1.8.1.2
>
> ___
> 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] u_blitter: don't create illegal shaders for 1D/3D/RECT/CUBE MSAA

[Marek Olšák]

The conditional should be "if (i > 1 && .."; with that fixed, this is:

Reviewed-by: Marek Olšák 

Marek

On Mon, Mar 4, 2013 at 9:02 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> I hit an assert playing with softpipe and texture MSAA today, makes me think
> we might need something like this to stop creating illegal shaders.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/util/u_blitter.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_blitter.c 
> b/src/gallium/auxiliary/util/u_blitter.c
> index e37be4e..ceaa9d0 100644
> --- a/src/gallium/auxiliary/util/u_blitter.c
> +++ b/src/gallium/auxiliary/util/u_blitter.c
> @@ -924,6 +924,11 @@ void util_blitter_cache_all_shaders(struct 
> blitter_context *blitter)
>   (target == PIPE_TEXTURE_CUBE_ARRAY))
>  continue;
>
> +if (max_samples > 1 &&
> +(target != PIPE_TEXTURE_2D &&
> + target != PIPE_TEXTURE_2D_ARRAY))
> +   continue;
> +
>   blitter_get_fs_texfetch_col(ctx, target, i);
>   blitter_get_fs_texfetch_depth(ctx, target, i);
>   if (ctx->has_stencil_export) {
> --
> 1.8.1.4
>
> ___
> 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 2/2] st/mesa: add switch case for ir_txf_ms to silence warning

[Marek Olšák]

On Mon, Mar 4, 2013 at 11:53 AM, Roland Scheidegger  wrote:
> Am 02.03.2013 04:26, schrieb Dave Airlie:
>> On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger  
>> wrote:
>>> Am 02.03.2013 01:36, schrieb Brian Paul:
 ---
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
 b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
 index 8e3e3b8..c41b583 100644
 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
 +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
 @@ -2746,6 +2746,9 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
offset = this->result;
}
break;
 +   case ir_txf_ms:
 +  assert(!"Unexpected ir_txf_ms opcode");
 +  break;
 }

 if (ir->projector) {

>>>
>>> Series looks good to me. I guess we need a new opcode like
>>> (TGSI_OPCODE_TXF_MS?), unless we switch everything over and only use the
>>> new sample style opcodes which already have that (SAMPLE_I_MS) :-).
>>
>> I'm not really sure we do, from what I can see TXF is sufficent since
>> LOD is bogus with MS textures so you can reuse the slot. r600 hw at
>> least only has one LD instruction from what I can see.
> Hmm yes but it doesn't sound like a very clean solution, to reuse the
> opcode for something a bit different. Though granted since with the
> combined texture/sampler state you always know the target (unlike with
> the sample_i opcodes) it should be always possible to distinguish
> txf-with-lod from txf-with-sample so it might indeed be ok.

There is no need to look at the texture or sampler state. TGSI texture
instructions specify their own texture target (TGSI_TEXTURE_*). For
example:

TXF OUT[0], IN[0], 2D_MSAA

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

[Mesa-dev] [Bug 61761] glPolygonOffsetEXT, OFFSET_BIAS incorrectly set to a huge number

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61761

--- Comment #1 from Roland Scheidegger  ---
Looks like when using PolygonOffsetEXT() mesa will multiply the bias value by
_DepthMaxF to set offset units (hence the same as calling PolygonOffset(). But
the get will just return offset units instead of bias instead.
I guess to really support that correctly we'd need to store bias separately.
After all _DepthMaxF of the bound draw buffer could change.
I don't know though if anyone is interested in that or we should just drop
it...

-- 
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 61764] invalid enum in glEnable, glConvolutionFilter, glSeparableFilter, glColorTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61764

Roland Scheidegger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #1 from Roland Scheidegger  ---
Mesa does not (or rather, no longer, it did at some point) support the clunky
and legacy ARB_imaging subset. Therefore, trying to use functions or enumerants
requiring that extension will indeed generate errors.

-- 
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 1/4] gallium: add get_sample_position interface

[Roland Scheidegger]

Am 03.03.2013 21:27, schrieb Dave Airlie:
> From: Dave Airlie 
> 
> This is to be used to implement glGet GL_SAMPLE_POSITION.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/include/pipe/p_context.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/gallium/include/pipe/p_context.h 
> b/src/gallium/include/pipe/p_context.h
> index 7ed946e..4ffee20 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -520,6 +520,10 @@ struct pipe_context {
> const uint *block_layout, const uint *grid_layout,
> uint32_t pc, const void *input);
> /*@}*/
> +   void (*get_sample_position)(struct pipe_context *context,
> +   int max_samples,
> +   unsigned sample_index,
> +   float *out_value);
>  };
> 
It looks like GL wants that function to depend on the currently bound
visual, and this is format-indepedent (which seems to be more sane
indeed). I think though "max_samples" should be "num_samples" or
something similar. Also some doc would be nice.
Otherwise LGTM.

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

Re: [Mesa-dev] multisample clears

[Roland Scheidegger]

Am 04.03.2013 04:54, schrieb Dave Airlie:
> I've been playing with softpipe msaa on and off, but I hit a problem
> with the clears and am just wondering if the state tracker should be
> doing something like this.
> 
> Or maybe only if any bound buffer has nr_samples > 1, or fallback to
> the non-quad draw method.
> 
> I can't see how else the driver could distinguish a multisample clear.
> 
> The other problem I have and not figuring out is if rendering to a
> buffer with multisample off, then turning it on is meant to be
> meaningful, if you have to clear
> the buffer in between, then with this fixed it should be cool.
> 
> Dave.
> 
> From e1ee59d87ba42d8a58be640ee1fd2b952414f45e Mon Sep 17 00:00:00 2001
> From: Dave Airlie 
> Date: Mon, 4 Mar 2013 13:39:17 +1000
> Subject: [PATCH] st/mesa: enable multisample in clear quad code
> 
> Not sure if this is correct at all
> ---
>  src/mesa/state_tracker/st_cb_clear.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/state_tracker/st_cb_clear.c
> b/src/mesa/state_tracker/st_cb_clear.c
> index 4aa0bc1..649d7bd 100644
> --- a/src/mesa/state_tracker/st_cb_clear.c
> +++ b/src/mesa/state_tracker/st_cb_clear.c
> @@ -282,7 +282,14 @@ clear_with_quad(struct gl_context *ctx,
> cso_set_vertex_elements(st->cso_context, 2, st->velems_util_draw);
> cso_set_stream_outputs(st->cso_context, 0, NULL, 0);
> cso_set_sample_mask(st->cso_context, ~0);
> -   cso_set_rasterizer(st->cso_context, &st->clear.raster);
> +
> +   {
> +  struct pipe_rasterizer_state rs = st->clear.raster;
> +
> +  if (st->ctx->Multisample.Enabled)
> + rs.multisample = 1;
> +  cso_set_rasterizer(st->cso_context, &rs);
> +   }
> 
> /* viewport state: viewport matching window dims */
> {
> 

Hmm I don't think this should be necessary (but it should be ok), since
it is perfectly legal to do non-multisampled rendering into a
multisampled buffer. The semantics of this are somewhat loose (you are
for instance allowed to perform depth test against a "centermost" sample
or do the test depth against individual samples, but in any case
rasterization will only have produced one depth value, and that depth
value is written to all samples if the depth test passes (but don't ask
me when the depth test is considered "passed" when you test against each
sample but still only can write the same value for all samples, I guess
it's easier to simply pick one sample)). Likewise all color samples are
set to the same value.
So as far as I can tell a clear should work with the same result,
regardless if you have multisampling enabled or not.
So yes it is indeed somewhat meaningful to render to a multisampled
buffer with multisampling off and on (though I'm quite sure some hw and
drivers don't quite support it correctly, it is probably not something
apps would do).

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

Re: [Mesa-dev] [PATCH 2/2] st/mesa: add switch case for ir_txf_ms to silence warning

[Roland Scheidegger]

Am 02.03.2013 04:26, schrieb Dave Airlie:
> On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger  
> wrote:
>> Am 02.03.2013 01:36, schrieb Brian Paul:
>>> ---
>>>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
>>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
>>> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> index 8e3e3b8..c41b583 100644
>>> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> @@ -2746,6 +2746,9 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
>>>offset = this->result;
>>>}
>>>break;
>>> +   case ir_txf_ms:
>>> +  assert(!"Unexpected ir_txf_ms opcode");
>>> +  break;
>>> }
>>>
>>> if (ir->projector) {
>>>
>>
>> Series looks good to me. I guess we need a new opcode like
>> (TGSI_OPCODE_TXF_MS?), unless we switch everything over and only use the
>> new sample style opcodes which already have that (SAMPLE_I_MS) :-).
> 
> I'm not really sure we do, from what I can see TXF is sufficent since
> LOD is bogus with MS textures so you can reuse the slot. r600 hw at
> least only has one LD instruction from what I can see.
Hmm yes but it doesn't sound like a very clean solution, to reuse the
opcode for something a bit different. Though granted since with the
combined texture/sampler state you always know the target (unlike with
the sample_i opcodes) it should be always possible to distinguish
txf-with-lod from txf-with-sample so it might indeed be ok.

Roland


> 
> I've already done a good bit of the state tracker for this, I just
> need to get a driver I can run it on :-)
> (gallium-texture-multisample branch in my repo)
> 
> Dave
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] OES_external_image for i965

[Pohjolainen, Topi]

On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote:
> On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi
>  wrote:
> > On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote:
> >> Hi Topi,
> >>
> >> > The second more or less questionable part is the support for creating YUV
> >> > buffers. In order to test for YUV sampling one needs a way of providing 
> >> > them
> >> > for the EGL stack. Here I chose to augment the dri driver backing gbm as 
> >> > I
> >> > couldn't come up with anything better. It may be helpful to take a look 
> >> > at the
> >> > corresponding piglit test case and framework support I've written for it.
> >>
> >> You might want to take a look at the EGL_EXT_image_dma_buf_import[i] which 
> >> has been written
> >> specifically for this purpose. Though this does assume you have a driver 
> >> which supports exporting a
> >> YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even 
> >> ion on Android.
> >>
> >
> > It certainly looks good addressing not only the individual plane setup but
> > allowing one to control also the conversion coefficients and subsampling
> > position.
> > Coming from piglit testing point of view, do you have any ideas where to
> > allocate the buffers from? I guess people wouldn't be too happy seeing v4l2 
> > tied
> > into piglit, for example.
> 
> SInce you're already using intel specific ioctls to mmap the buffers,
> I'd suggest you just go all the way and allocate using intel specific
> ioctls (like my simple-yuv.c example).  I don't really see any other
> approach, but it's not pretty...
> 

I used gbm buffer objects in order to match the logic later in
'dri2_drm_create_image_khr()' which expects the buffer to be of the type
'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm buffer
objects instead would require new target, I guess?

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

[Mesa-dev] [PATCH] u_blitter: don't create illegal shaders for 1D/3D/RECT/CUBE MSAA

[Dave Airlie]

From: Dave Airlie 

I hit an assert playing with softpipe and texture MSAA today, makes me think
we might need something like this to stop creating illegal shaders.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/util/u_blitter.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_blitter.c 
b/src/gallium/auxiliary/util/u_blitter.c
index e37be4e..ceaa9d0 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -924,6 +924,11 @@ void util_blitter_cache_all_shaders(struct blitter_context 
*blitter)
  (target == PIPE_TEXTURE_CUBE_ARRAY))
 continue;
 
+if (max_samples > 1 &&
+(target != PIPE_TEXTURE_2D &&
+ target != PIPE_TEXTURE_2D_ARRAY))
+   continue;
+
  blitter_get_fs_texfetch_col(ctx, target, i);
  blitter_get_fs_texfetch_depth(ctx, target, i);
  if (ctx->has_stencil_export) {
-- 
1.8.1.4

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