[Mesa-dev] [Bug 65173] segfault in _mesa_get_format_datatype and _mesa_get_color_read_type when state dumping with glretrace
https://bugs.freedesktop.org/show_bug.cgi?id=65173
--- Comment #11 from José Fonseca jfons...@vmware.com ---
(In reply to comment #10)
What does nVidia proprietary driver return for
IMPLEMENTATION_COLOR_READ_{FORMAT,TYPE} on that call? That is, what is the
output of
glretrace -D 137078 wine-preloader.137078.trim.trace | grep
IMPLEMENTATION_COLOR_READ
Nothing, the part of the state dump where mesa version crashes looks like
this (I've put stderr part in stderr tags):
GL_MAX_VERTEX_UNIFORM_COMPONENTS: 4096,
GL_MAX_VARYING_COMPONENTS: 60,
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS: 32,
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS: 96,
GL_SHADING_LANGUAGE_VERSION: 3.30 NVIDIA via Cg compiler,
GL_CURRENT_PROGRAM: 18 stderr137078: glDebugOutputCallback: High
severity API error 1282, GL_INVALID_OPERATION error generated. Invalid query
on incomplete or unselected read framebuffer
137078: glDebugOutputCallback: High severity API error 1282,
GL_INVALID_OPERATION error generated. Invalid query on incomplete or
unselected read framebuffer/stderr
,
GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS: 32,
GL_TEXTURE_BUFFER: 0,
Thanks for checking. It seems it nvidia driver emits a GL_INVALID_OPERATION
error. We could do the same.
BTW, I did read the relevant specs for this query, but they don't really
describe what happens in this situation.
--
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] ilo: Ensure array 'shaders' in fully initialized.
Fixes Uninitialized pointer read defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/ilo/ilo_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo_state.c
b/src/gallium/drivers/ilo/ilo_state.c
index 33da429..f071292 100644
--- a/src/gallium/drivers/ilo/ilo_state.c
+++ b/src/gallium/drivers/ilo/ilo_state.c
@@ -83,7 +83,7 @@ finalize_shader_states(struct ilo_context *ilo)
.deps = 0,
},
};
- struct ilo_shader *shaders[PIPE_SHADER_TYPES];
+ struct ilo_shader *shaders[PIPE_SHADER_TYPES] = { 0 };
int num_shaders = 0, i;
for (i = 0; i PIPE_SHADER_TYPES; i++) {
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ilo: Ensure array 'shaders' in fully initialized.
On Fri, May 31, 2013 at 2:59 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes Uninitialized pointer read defect reported by Coverity.
This looks like a false alarm, as shaders are not read when
num_shaders is zero. Does the report give more details?
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/ilo/ilo_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo_state.c
b/src/gallium/drivers/ilo/ilo_state.c
index 33da429..f071292 100644
--- a/src/gallium/drivers/ilo/ilo_state.c
+++ b/src/gallium/drivers/ilo/ilo_state.c
@@ -83,7 +83,7 @@ finalize_shader_states(struct ilo_context *ilo)
.deps = 0,
},
};
- struct ilo_shader *shaders[PIPE_SHADER_TYPES];
+ struct ilo_shader *shaders[PIPE_SHADER_TYPES] = { 0 };
int num_shaders = 0, i;
for (i = 0; i PIPE_SHADER_TYPES; i++) {
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ilo: Ensure array 'shaders' in fully initialized.
On Fri, May 31, 2013 at 12:35 AM, Chia-I Wu olva...@gmail.com wrote:
On Fri, May 31, 2013 at 2:59 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes Uninitialized pointer read defect reported by Coverity.
This looks like a false alarm, as shaders are not read when
num_shaders is zero. Does the report give more details?
1. var_decl: Declaring variable shaders without initializer.
86 struct ilo_shader *shaders[PIPE_SHADER_TYPES];
87 int num_shaders = 0, i;
88
2. Condition i 4, taking true branch
5. Condition i 4, taking true branch
8. Condition i 4, taking false branch
89 for (i = 0; i PIPE_SHADER_TYPES; i++) {
90 /* no state bound */
3. Condition !sh[i].state, taking true branch
6. Condition !sh[i].state, taking true branch
91 if (!sh[i].state)
4. Continuing loop
7. Continuing loop
92 continue;
93
94 /* switch variant if the shader or the states it depends on changed */
95 if (ilo-dirty (sh[i].dirty | sh[i].deps)) {
96 struct ilo_shader_variant variant;
97
98 ilo_shader_variant_init(variant, sh[i].state-info, ilo);
99 ilo_shader_state_use_variant(sh[i].state, variant);
100 }
101
102 shaders[num_shaders++] = sh[i].state-shader;
103 }
104
Uninitialized pointer read (UNINIT)
9. uninit_use_in_call: Using uninitialized element of array
shaders when calling ilo_shader_cache_set(struct ilo_shader_cache
*, struct ilo_shader **, int).
105 ilo_shader_cache_set(ilo-shader_cache, shaders, num_shaders);
/src/gallium/drivers/ilo/ilo_shader.c
556ilo_shader_cache_set(struct ilo_shader_cache *shc,
557 struct ilo_shader **shaders,
558 int num_shaders)
559{
560 int new_cur, i;
561
562 /* calculate the space needed */
563 new_cur = shc-cur;
1. Condition i num_shaders, taking true branch
564 for (i = 0; i num_shaders; i++) {
2. read_parm: Reading a parameter value.
565 if (shaders[i]-cache_seqno != shc-seqno)
566 new_cur = align(new_cur, 64) + shaders[i]-kernel_size;
567 }
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/ilo/ilo_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo_state.c
b/src/gallium/drivers/ilo/ilo_state.c
index 33da429..f071292 100644
--- a/src/gallium/drivers/ilo/ilo_state.c
+++ b/src/gallium/drivers/ilo/ilo_state.c
@@ -83,7 +83,7 @@ finalize_shader_states(struct ilo_context *ilo)
.deps = 0,
},
};
- struct ilo_shader *shaders[PIPE_SHADER_TYPES];
+ struct ilo_shader *shaders[PIPE_SHADER_TYPES] = { 0 };
int num_shaders = 0, i;
for (i = 0; i PIPE_SHADER_TYPES; i++) {
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ilo: Ensure array 'shaders' in fully initialized.
On Fri, May 31, 2013 at 3:48 PM, Vinson Lee v...@freedesktop.org wrote:
On Fri, May 31, 2013 at 12:35 AM, Chia-I Wu olva...@gmail.com wrote:
On Fri, May 31, 2013 at 2:59 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes Uninitialized pointer read defect reported by Coverity.
This looks like a false alarm, as shaders are not read when
num_shaders is zero. Does the report give more details?
I am not sure how to follow the report... I eye-checked the code, and
I failed to spot any uninitialized pointer read. Do you have an
example that the code would read past what it should?
1. var_decl: Declaring variable shaders without initializer.
86 struct ilo_shader *shaders[PIPE_SHADER_TYPES];
87 int num_shaders = 0, i;
88
2. Condition i 4, taking true branch
5. Condition i 4, taking true branch
8. Condition i 4, taking false branch
89 for (i = 0; i PIPE_SHADER_TYPES; i++) {
90 /* no state bound */
3. Condition !sh[i].state, taking true branch
6. Condition !sh[i].state, taking true branch
91 if (!sh[i].state)
4. Continuing loop
7. Continuing loop
92 continue;
93
94 /* switch variant if the shader or the states it depends on changed
*/
95 if (ilo-dirty (sh[i].dirty | sh[i].deps)) {
96 struct ilo_shader_variant variant;
97
98 ilo_shader_variant_init(variant, sh[i].state-info, ilo);
99 ilo_shader_state_use_variant(sh[i].state, variant);
100 }
101
102 shaders[num_shaders++] = sh[i].state-shader;
103 }
104
Uninitialized pointer read (UNINIT)
9. uninit_use_in_call: Using uninitialized element of array
shaders when calling ilo_shader_cache_set(struct ilo_shader_cache
*, struct ilo_shader **, int).
105 ilo_shader_cache_set(ilo-shader_cache, shaders, num_shaders);
/src/gallium/drivers/ilo/ilo_shader.c
556ilo_shader_cache_set(struct ilo_shader_cache *shc,
557 struct ilo_shader **shaders,
558 int num_shaders)
559{
560 int new_cur, i;
561
562 /* calculate the space needed */
563 new_cur = shc-cur;
1. Condition i num_shaders, taking true branch
564 for (i = 0; i num_shaders; i++) {
2. read_parm: Reading a parameter value.
565 if (shaders[i]-cache_seqno != shc-seqno)
566 new_cur = align(new_cur, 64) + shaders[i]-kernel_size;
567 }
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/ilo/ilo_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo_state.c
b/src/gallium/drivers/ilo/ilo_state.c
index 33da429..f071292 100644
--- a/src/gallium/drivers/ilo/ilo_state.c
+++ b/src/gallium/drivers/ilo/ilo_state.c
@@ -83,7 +83,7 @@ finalize_shader_states(struct ilo_context *ilo)
.deps = 0,
},
};
- struct ilo_shader *shaders[PIPE_SHADER_TYPES];
+ struct ilo_shader *shaders[PIPE_SHADER_TYPES] = { 0 };
int num_shaders = 0, i;
for (i = 0; i PIPE_SHADER_TYPES; i++) {
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
o...@lunarg.com
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 60518] glDrawElements segfault when compiled into display list
https://bugs.freedesktop.org/show_bug.cgi?id=60518
--- Comment #8 from cor...@gmx.net ---
(In reply to comment #7)
I suspect the problem are these lines in setup_glsl_generate_mipmap():
_mesa_BindAttribLocation(mipmap-ShaderProg, 0, position);
_mesa_BindAttribLocation(mipmap-ShaderProg, 1, texcoords);
_mesa_EnableVertexAttribArray(0);
_mesa_EnableVertexAttribArray(1);
Which can be executed without this line being called:
_mesa_BindVertexArray(mipmap-ArrayObj);
This patch might fix this.
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ca5f5a1..7da08e8 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3397,6 +3397,8 @@ setup_glsl_generate_mipmap(struct gl_context *ctx,
sizeof(struct vertex), OFFSET(x));
_mesa_VertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE,
sizeof(struct vertex), OFFSET(tex));
+ } else {
+ _mesa_BindVertexArray(mipmap-ArrayObj);
}
/* Generate a fragment shader program appropriate for the texture target
*/
Yep, no segfaults with this patch. Tested with mesa git, i965. Thanks, for
looking into this, José.
--
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] glapi: Add some missing static_dispatch=false annotations to es_EXT.xml
FYI here is the full build log of the failing build. https://buildd.debian.org/status/fetch.php?pkg=mesaarch=powerpcver=9.1.3-1stamp=1369778584 Andreas. 2013/5/30 Andreas Boll andreas.boll@gmail.com This fixes the following build errors on powerpc: CC glapi_dispatch.lo In file included from glapi_dispatch.c:90:0: ../../../../../src/mapi/glapi/glapitemp.h:1640:1: error: no previous prototype for 'glReadBufferNV' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:4198:1: error: no previous prototype for 'glDrawBuffersNV' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6377:1: error: no previous prototype for 'glFlushMappedBufferRangeEXT' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6389:1: error: no previous prototype for 'glMapBufferRangeEXT' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6401:1: error: no previous prototype for 'glBindVertexArrayOES' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6413:1: error: no previous prototype for 'glDeleteVertexArraysOES' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6433:1: error: no previous prototype for 'glGenVertexArraysOES' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6445:1: error: no previous prototype for 'glIsVertexArrayOES' [-Werror=missing-prototypes] NOTE: This is a candidate for the 9.0 and 9.1 branches. Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com --- src/mapi/glapi/gen/es_EXT.xml | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml index ff378ac..f412333 100644 --- a/src/mapi/glapi/gen/es_EXT.xml +++ b/src/mapi/glapi/gen/es_EXT.xml @@ -689,22 +689,25 @@ !-- 71. GL_OES_vertex_array_object -- category name=GL_OES_vertex_array_object number=71 -function name=BindVertexArrayOES alias=BindVertexArray es2=2.0 +function name=BindVertexArrayOES alias=BindVertexArray + static_dispatch=false es2=2.0 param name=array type=GLuint/ /function function name=DeleteVertexArraysOES alias=DeleteVertexArrays - es2=2.0 + static_dispatch=false es2=2.0 param name=n type=GLsizei/ param name=arrays type=const GLuint * count=n/ /function -function name=GenVertexArraysOES alias=GenVertexArrays es2=2.0 +function name=GenVertexArraysOES alias=GenVertexArrays + static_dispatch=false es2=2.0 param name=n type=GLsizei/ param name=arrays type=GLuint * output=true count=n/ /function -function name=IsVertexArrayOES alias=IsVertexArray es2=2.0 +function name=IsVertexArrayOES alias=IsVertexArray + static_dispatch=false es2=2.0 param name=array type=GLuint/ return type=GLboolean/ /function @@ -779,7 +782,8 @@ size name=Get mode=get/ /enum -function name=DrawBuffersNV alias=DrawBuffers es2=2.0 +function name=DrawBuffersNV alias=DrawBuffers + static_dispatch=false es2=2.0 param name=n type=GLsizei counter=true/ param name=bufs type=const GLenum * count=n/ /function @@ -787,7 +791,8 @@ !-- 93. GL_NV_read_buffer -- category name=GL_NV_read_buffer -function name=ReadBufferNV alias=ReadBuffer es2=2.0 +function name=ReadBufferNV alias=ReadBuffer + static_dispatch=false es2=2.0 param name=mode type=GLenum/ /function /category @@ -815,8 +820,8 @@ enum name=MAP_FLUSH_EXPLICIT_BIT_EXT value=0x0010/ enum name=MAP_UNSYNCHRONIZED_BIT_EXT value=0x0020/ -function name=MapBufferRangeEXT alias=MapBufferRange es1=1.0 - es2=2.0 +function name=MapBufferRangeEXT alias=MapBufferRange + static_dispatch=false es1=1.0 es2=2.0 param name=target type=GLenum/ param name=offset type=GLintptr/ param name=size type=GLsizeiptr/ @@ -825,7 +830,7 @@ /function function name=FlushMappedBufferRangeEXT alias=FlushMappedBufferRange - es1=1.0 es2=2.0 + static_dispatch=false es1=1.0 es2=2.0 param name=target type=GLenum/ param name=offset type=GLintptr/ param name=length type=GLsizeiptr/ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g/sb: improve math optimizations
This patch adds support for some math optimizations that are generally
considered unsafe, that's why they are currently disabled for compute
shaders.
GL requirements are less strict, so they are enabled for
for GL shaders by default. In case of any issues with
applications that rely on higher precision than guaranteed by GL,
'sbsafemath' option in R600_DEBUG allows to disable them.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
There are no regressions on evergreen with piglit tests or any
other apps that I tested, with and without llvm backend.
(Issue with Unigine Heaven that I mentioned on #dri-devel
yesterday was in fact caused by my own well-hidden bug, now it's fixed).
Improvements for real apps probably won't be very noticeable in many cases,
but this still might help some apps, e.g. this improves shader2 test
of the fill benchmark in mesa demos.
src/gallium/drivers/r600/r600_isa.h | 19 +-
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/r600/r600_pipe.h | 1 +
src/gallium/drivers/r600/sb/sb_bc.h | 1 +
src/gallium/drivers/r600/sb/sb_bc_parser.cpp | 2 +
src/gallium/drivers/r600/sb/sb_context.cpp | 1 +
src/gallium/drivers/r600/sb/sb_core.cpp | 1 +
src/gallium/drivers/r600/sb/sb_expr.cpp | 444 ---
src/gallium/drivers/r600/sb/sb_expr.h| 4 +
src/gallium/drivers/r600/sb/sb_shader.cpp| 2 +-
src/gallium/drivers/r600/sb/sb_shader.h | 2 +
11 files changed, 431 insertions(+), 47 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_isa.h
b/src/gallium/drivers/r600/r600_isa.h
index 89d..c6bb869 100644
--- a/src/gallium/drivers/r600/r600_isa.h
+++ b/src/gallium/drivers/r600/r600_isa.h
@@ -84,7 +84,8 @@ enum alu_op_flags
* includes MULADDs (considering the MUL part on src0 and src1 only) */
AF_M_COMM = (1 23),
- /* associative operation ((a op b) op c) == (a op (b op c)) */
+ /* associative operation ((a op b) op c) == (a op (b op c)),
+* includes MULADDs (considering the MUL part on src0 and src1 only) */
AF_M_ASSOC = (1 24),
AF_PRED_PUSH = (1 25),
@@ -373,11 +374,11 @@ static const struct alu_op_info alu_op_table[] = {
{SAD_ACCUM_HI_UINT, 3, { -1, 0x0F },{ 0,
0, AF_V, AF_V}, AF_UINT_DST },
{MULADD_UINT24, 3, { -1, 0x10 },{ 0,
0, AF_V, AF_V}, AF_UINT_DST | AF_24 },
{LDS_IDX_OP,3, { -1, 0x11 },{ 0,
0, AF_V, AF_V}, 0 },
- {MULADD,3, { 0x10, 0x14 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM },
- {MULADD_M2, 3, { 0x11, 0x15 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM },
- {MULADD_M4, 3, { 0x12, 0x16 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM },
- {MULADD_D2, 3, { 0x13, 0x17 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM },
- {MULADD_IEEE, 3, { 0x14, 0x18 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM | AF_IEEE },
+ {MULADD,3, { 0x10, 0x14 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM | AF_M_ASSOC },
+ {MULADD_M2, 3, { 0x11, 0x15 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM | AF_M_ASSOC },
+ {MULADD_M4, 3, { 0x12, 0x16 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM | AF_M_ASSOC },
+ {MULADD_D2, 3, { 0x13, 0x17 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM | AF_M_ASSOC },
+ {MULADD_IEEE, 3, { 0x14, 0x18 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_M_COMM | AF_M_ASSOC | AF_IEEE },
{CNDE, 3, { 0x18, 0x19 },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_CMOV | AF_CC_E },
{CNDGT, 3, { 0x19, 0x1A },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_CMOV | AF_CC_GT },
{CNDGE, 3, { 0x1A, 0x1B },{ AF_VS,
AF_VS, AF_VS, AF_VS}, AF_CMOV | AF_CC_GE },
@@ -397,9 +398,9 @@ static const struct alu_op_info alu_op_table[] = {
{MUL_LIT_M2,3, { 0x0D, -1 },{ AF_VS,
AF_VS, 0, 0}, 0 },
{MUL_LIT_M4,3, { 0x0E, -1 },{ AF_VS,
AF_VS, 0, 0}, 0 },
{MUL_LIT_D2,3, { 0x0F, -1 },{ AF_VS,
AF_VS, 0, 0}, 0 },
- {MULADD_IEEE_M2,3, { 0x15, -1 },{ AF_VS,
AF_VS, 0, 0}, AF_IEEE },
- {MULADD_IEEE_M4,3, { 0x16, -1 },{ AF_VS,
AF_VS, 0, 0}, AF_IEEE },
- {MULADD_IEEE_D2,3, { 0x17, -1 },{ AF_VS,
AF_VS, 0, 0}, AF_IEEE },
+ {MULADD_IEEE_M2,3, { 0x15, -1 },{ AF_VS,
AF_VS, 0, 0}, AF_M_COMM | AF_M_ASSOC | AF_IEEE },
+ {MULADD_IEEE_M4,3, {
Re: [Mesa-dev] [PATCH] glapi: Add some missing static_dispatch=false annotations to es_EXT.xml
The change looks OK to me. Reviewed-by: Brian Paul bri...@vmware.com On 05/31/2013 04:29 AM, Andreas Boll wrote: FYI here is the full build log of the failing build. https://buildd.debian.org/status/fetch.php?pkg=mesaarch=powerpcver=9.1.3-1stamp=1369778584 Andreas. 2013/5/30 Andreas Boll andreas.boll@gmail.com mailto:andreas.boll@gmail.com This fixes the following build errors on powerpc: CC glapi_dispatch.lo In file included from glapi_dispatch.c:90:0: ../../../../../src/mapi/glapi/glapitemp.h:1640:1: error: no previous prototype for 'glReadBufferNV' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:4198:1: error: no previous prototype for 'glDrawBuffersNV' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6377:1: error: no previous prototype for 'glFlushMappedBufferRangeEXT' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6389:1: error: no previous prototype for 'glMapBufferRangeEXT' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6401:1: error: no previous prototype for 'glBindVertexArrayOES' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6413:1: error: no previous prototype for 'glDeleteVertexArraysOES' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6433:1: error: no previous prototype for 'glGenVertexArraysOES' [-Werror=missing-prototypes] ../../../../../src/mapi/glapi/glapitemp.h:6445:1: error: no previous prototype for 'glIsVertexArrayOES' [-Werror=missing-prototypes] NOTE: This is a candidate for the 9.0 and 9.1 branches. Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com mailto:maarten.lankho...@canonical.com --- src/mapi/glapi/gen/es_EXT.xml | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml index ff378ac..f412333 100644 --- a/src/mapi/glapi/gen/es_EXT.xml +++ b/src/mapi/glapi/gen/es_EXT.xml @@ -689,22 +689,25 @@ !-- 71. GL_OES_vertex_array_object -- category name=GL_OES_vertex_array_object number=71 -function name=BindVertexArrayOES alias=BindVertexArray es2=2.0 +function name=BindVertexArrayOES alias=BindVertexArray + static_dispatch=false es2=2.0 param name=array type=GLuint/ /function function name=DeleteVertexArraysOES alias=DeleteVertexArrays - es2=2.0 + static_dispatch=false es2=2.0 param name=n type=GLsizei/ param name=arrays type=const GLuint * count=n/ /function -function name=GenVertexArraysOES alias=GenVertexArrays es2=2.0 +function name=GenVertexArraysOES alias=GenVertexArrays + static_dispatch=false es2=2.0 param name=n type=GLsizei/ param name=arrays type=GLuint * output=true count=n/ /function -function name=IsVertexArrayOES alias=IsVertexArray es2=2.0 +function name=IsVertexArrayOES alias=IsVertexArray + static_dispatch=false es2=2.0 param name=array type=GLuint/ return type=GLboolean/ /function @@ -779,7 +782,8 @@ size name=Get mode=get/ /enum -function name=DrawBuffersNV alias=DrawBuffers es2=2.0 +function name=DrawBuffersNV alias=DrawBuffers + static_dispatch=false es2=2.0 param name=n type=GLsizei counter=true/ param name=bufs type=const GLenum * count=n/ /function @@ -787,7 +791,8 @@ !-- 93. GL_NV_read_buffer -- category name=GL_NV_read_buffer -function name=ReadBufferNV alias=ReadBuffer es2=2.0 +function name=ReadBufferNV alias=ReadBuffer + static_dispatch=false es2=2.0 param name=mode type=GLenum/ /function /category @@ -815,8 +820,8 @@ enum name=MAP_FLUSH_EXPLICIT_BIT_EXT value=0x0010/ enum name=MAP_UNSYNCHRONIZED_BIT_EXT value=0x0020/ -function name=MapBufferRangeEXT alias=MapBufferRange es1=1.0 - es2=2.0 +function name=MapBufferRangeEXT alias=MapBufferRange + static_dispatch=false es1=1.0 es2=2.0 param name=target type=GLenum/ param name=offset type=GLintptr/ param name=size type=GLsizeiptr/ @@ -825,7 +830,7 @@ /function function name=FlushMappedBufferRangeEXT alias=FlushMappedBufferRange - es1=1.0 es2=2.0 + static_dispatch=false es1=1.0 es2=2.0 param name=target type=GLenum/ param name=offset type=GLintptr/
[Mesa-dev] [Bug 60518] glDrawElements segfault when compiled into display list
https://bugs.freedesktop.org/show_bug.cgi?id=60518 --- Comment #9 from Brian Paul bri...@vmware.com --- Jose, I think it would be more symmetric with the peer setup_ff_generate_mipmap() function if we just enabled the vertex arrays when we create the vertex array object. So, how about this patch: diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index ca5f5a1..1ab603a 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -3397,6 +3397,8 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, sizeof(struct vertex), OFFSET(x)); _mesa_VertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(struct vertex), OFFSET(tex)); + _mesa_EnableVertexAttribArray(0); + _mesa_EnableVertexAttribArray(1); } /* Generate a fragment shader program appropriate for the texture target */ @@ -3468,8 +3470,6 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, _mesa_DeleteObjectARB(vs); _mesa_BindAttribLocation(mipmap-ShaderProg, 0, position); _mesa_BindAttribLocation(mipmap-ShaderProg, 1, texcoords); - _mesa_EnableVertexAttribArray(0); - _mesa_EnableVertexAttribArray(1); link_program_with_debug(ctx, mipmap-ShaderProg); sampler-shader_prog = mipmap-ShaderProg; ralloc_free(mem_ctx); Can you test that approach, core13? -- 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 65173] segfault in _mesa_get_format_datatype and _mesa_get_color_read_type when state dumping with glretrace
https://bugs.freedesktop.org/show_bug.cgi?id=65173 --- Comment #12 from Brian Paul bri...@vmware.com --- Created attachment 80099 -- https://bugs.freedesktop.org/attachment.cgi?id=80099action=edit patch which generates GL_INVALID_ENUM How about this patch? It generates GL_INVALID_OPERATION if there's no color read buffer. It also cleans up both functions in general. -- 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] Bugs in fbo-sys-blit (problems with fake front and missing invalidates)
On 29 May 2013 14:19, Ville Syrjälä syrj...@sci.fi wrote: On Wed, May 29, 2013 at 01:39:00PM -0700, Paul Berry wrote: I started this discussion with just some of the Intel folks, and Eric suggested I bring it to the mesa-dev list. The short version is: in my efforts to implement fast color clears on Intel hardware, I've uncovered some problems with the fbo-sys-blit piglit test, which I've traced to 3 bugs. I could use some help with bug (2) below, which I suspect is a bug in the X server. -- Forwarded message (footnotes added) -- First of all, a brief summary of what fbo-sys-blit's piglit_display() does: a. Clear the back buffer to green. b. Copy the back buffer to the front buffer using a blit. c. Clear the back buffer to red. d. Read the contents of the front buffer to verify that it's green. I've found three bugs: snip Did you try this [1] patch from Chris? I had a similar patch in a private tree way back when, but for some reason I decided that it's not necessary, and hence didn't send it out. I can't actually recall why I came to that conclusion, nor can I think of a good reason now either. But it's been quite a while since I poked at any dri2 or composite stuff so I may be out of practice. [1] http://patchwork.freedesktop.org/patch/12111/ Thanks for the suggestion. Ultimately, this didn't turn out to fix the problem, but it gave a helpful starting point for me and Eric to debug yesterday. Here's what we found: - Something (we're not sure exactly what) is causing the DRI2Drawable's serialNumber to change when the window gets mapped and compositing is in use. This is not terribly surprising, since serial numbers change under a lot of circumstances. - As a result of x server commit 3209b094 (which fixed https://bugs.freedesktop.org/show_bug.cgi?id=28365), a serial number change causes all of the drawable's buffers to be reallocated. - However, whatever caused the serialNumber to change didn't cause an invalidate message to be sent to the client, so Mesa doesn't find out that it needs to request buffers before it starts rendering the frame. We believe that commit 3209b094 is causing the server to overzealously reallocate buffers, and that we need to revert it and find a less broad fix for https://bugs.freedesktop.org/show_bug.cgi?id=28365 (if it still exists--a lot of other fixes got made in the meantime which might have addressed the true cause of the bug). Eric is going to work on doing that while I pursue the remaining issues from my original email. Note: in the process of debugging we discovered another scenario that can cause fake front buffering to be lost: if, while the fake front buffer is dirty, Mesa makes a request for just the back buffer, the X server will throw away the fake front buffer. I'll make a piglit test and a fix for this. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 60518] glDrawElements segfault when compiled into display list
https://bugs.freedesktop.org/show_bug.cgi?id=60518 --- Comment #10 from cor...@gmx.net --- (In reply to comment #9) Jose, I think it would be more symmetric with the peer setup_ff_generate_mipmap() function if we just enabled the vertex arrays when we create the vertex array object. So, how about this patch: diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index ca5f5a1..1ab603a 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -3397,6 +3397,8 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, sizeof(struct vertex), OFFSET(x)); _mesa_VertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(struct vertex), OFFSET(tex)); + _mesa_EnableVertexAttribArray(0); + _mesa_EnableVertexAttribArray(1); } /* Generate a fragment shader program appropriate for the texture target */ @@ -3468,8 +3470,6 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, _mesa_DeleteObjectARB(vs); _mesa_BindAttribLocation(mipmap-ShaderProg, 0, position); _mesa_BindAttribLocation(mipmap-ShaderProg, 1, texcoords); - _mesa_EnableVertexAttribArray(0); - _mesa_EnableVertexAttribArray(1); link_program_with_debug(ctx, mipmap-ShaderProg); sampler-shader_prog = mipmap-ShaderProg; ralloc_free(mem_ctx); Can you test that approach, core13? This one works too, no segfaults. -- 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] meta: move vertex array enables for mipmap generation
Before, on the second call to GenerateMipmap were enabling two vertex arrays for the current vertex array object, rather than the private generate-mipmap vertex array object. This caused things to blow up elsewhere. This patch moves the array enables into the block where the generate-mipmap vertex array object is created, as we do in the setup_ff_generate_mipmap() function. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60518 NOTE: This is a candidate for the stable branches. Tested-by: cor...@gmx.net --- src/mesa/drivers/common/meta.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index ca5f5a1..1ab603a 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -3397,6 +3397,8 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, sizeof(struct vertex), OFFSET(x)); _mesa_VertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(struct vertex), OFFSET(tex)); + _mesa_EnableVertexAttribArray(0); + _mesa_EnableVertexAttribArray(1); } /* Generate a fragment shader program appropriate for the texture target */ @@ -3468,8 +3470,6 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, _mesa_DeleteObjectARB(vs); _mesa_BindAttribLocation(mipmap-ShaderProg, 0, position); _mesa_BindAttribLocation(mipmap-ShaderProg, 1, texcoords); - _mesa_EnableVertexAttribArray(0); - _mesa_EnableVertexAttribArray(1); link_program_with_debug(ctx, mipmap-ShaderProg); sampler-shader_prog = mipmap-ShaderProg; ralloc_free(mem_ctx); -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Security fixes applied in mesa trunk
Two security fixes were applied recently (CVE-2013-1993), it would be nice to see a new mesa stable release with these fixes applied. Thanks. -- Laurent Carlier ArchLinux Trusted User http://www.archlinux.org signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] and a random apitrace/gallium question..
On Fri, May 31, 2013 at 10:18 AM, José Fonseca jose.r.fons...@gmail.com wrote: I'd support such change. Be it through GL_GREMEDY_string_marker, or ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB, ...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would be necessary to pass these annotations to the drivers. This discussion would be more appropriate in Mesa-dev mailing list though. I could probably handle the gallium bits to let the driver intercept the messages. For quicker results, you could modify your gallium driver to force flushing on every draw, and dump the commands to stderr, and run glretrace with -v option. I do this all the time: enabling logging at all levels (state tracker, trace driver, etc), and see how they correlate. well, with the way tiling works on adreno, that isn't so straightforward to do, at least not without changing the results. That is why I started wondering about a way to get apitrace-retrace to insert some debug markers into cmdstream ;-) BR, -R Jose On Fri, May 31, 2013 at 3:03 PM, Rob Clark robdcl...@gmail.com wrote: Is there a way to get apitrace retrace to emit gl call #'s for draw calls in some way that the gallium driver could intercept (ie. GL_GREMEDY_string_marker)? This way when I'm capturing cmdstream from a retrace, I could do something like emit a CP_NOP w/ payload that has the marker to more easily find the spots in the cmdstream which match up to draw calls in the trace.. BR, -R ___ apitrace mailing list apitr...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/apitrace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meta: move vertex array enables for mipmap generation
Yeah, that looks even better than my fix. Jose - Original Message - Before, on the second call to GenerateMipmap were enabling two vertex arrays for the current vertex array object, rather than the private generate-mipmap vertex array object. This caused things to blow up elsewhere. This patch moves the array enables into the block where the generate-mipmap vertex array object is created, as we do in the setup_ff_generate_mipmap() function. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60518 NOTE: This is a candidate for the stable branches. Tested-by: cor...@gmx.net --- src/mesa/drivers/common/meta.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index ca5f5a1..1ab603a 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -3397,6 +3397,8 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, sizeof(struct vertex), OFFSET(x)); _mesa_VertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(struct vertex), OFFSET(tex)); + _mesa_EnableVertexAttribArray(0); + _mesa_EnableVertexAttribArray(1); } /* Generate a fragment shader program appropriate for the texture target */ @@ -3468,8 +3470,6 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, _mesa_DeleteObjectARB(vs); _mesa_BindAttribLocation(mipmap-ShaderProg, 0, position); _mesa_BindAttribLocation(mipmap-ShaderProg, 1, texcoords); - _mesa_EnableVertexAttribArray(0); - _mesa_EnableVertexAttribArray(1); link_program_with_debug(ctx, mipmap-ShaderProg); sampler-shader_prog = mipmap-ShaderProg; ralloc_free(mem_ctx); -- 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 65173] segfault in _mesa_get_format_datatype and _mesa_get_color_read_type when state dumping with glretrace
https://bugs.freedesktop.org/show_bug.cgi?id=65173 --- Comment #13 from José Fonseca jfons...@vmware.com --- (In reply to comment #12) How about this patch? It generates GL_INVALID_OPERATION if there's no color read buffer. It also cleans up both functions in general. Patch looks good to me! -- 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] llvmpipe: reduce alignment requirement for 1d resources from 4x4 to 4x1
From: Roland Scheidegger srol...@vmware.com
For rendering to buffers, we cannot have any y alignment.
So make sure that tile clear commands only clear up to the fb width/height,
not more (do this for all resources actually as clearing more seems
pointless for other resources too). For the jit fs function, skip execution
of the lower half of the fragment shader for the 4x4 stamp completely,
for depth/stencil only load/store the values from the first row
(replace other row with undef).
For the blend function, also only load half the values from fs output, drop
the second row after untwiddling (fix up some issues there due to inconsistent
usage of block_width/block_height/block_size, num_fs and fs type length).
Also reduce 1d and 1d array alignment too, because they can be handled the
same as buffers so don't need to waste memory.
---
src/gallium/auxiliary/gallivm/lp_bld_conv.c | 90 +++
src/gallium/auxiliary/gallivm/lp_bld_pack.c |6 +-
src/gallium/drivers/llvmpipe/lp_bld_depth.c | 19 ++-
src/gallium/drivers/llvmpipe/lp_bld_depth.h |2 +
src/gallium/drivers/llvmpipe/lp_rast.c |8 +-
src/gallium/drivers/llvmpipe/lp_scene.c |2 -
src/gallium/drivers/llvmpipe/lp_scene.h |4 -
src/gallium/drivers/llvmpipe/lp_state_fs.c | 228 +++
src/gallium/drivers/llvmpipe/lp_state_fs.h |1 +
src/gallium/drivers/llvmpipe/lp_texture.c | 24 ++-
src/gallium/drivers/llvmpipe/lp_texture.h | 21 +++
11 files changed, 281 insertions(+), 124 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_conv.c
b/src/gallium/auxiliary/gallivm/lp_bld_conv.c
index eb2d096..f11361a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_conv.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_conv.c
@@ -530,24 +530,22 @@ int lp_build_conv_auto(struct gallivm_state *gallivm,
dst_type-width== 8)
{
/* Special case 4x4f -- 1x16ub */
- if (src_type.length == 4 util_cpu_caps.has_sse2)
+ if (src_type.length == 4
+ util_cpu_caps.has_sse2)
{
- assert((num_srcs % 4) == 0);
-
- num_dsts = num_srcs / 4;
- dst_type-length = 16;
+ num_dsts = (num_srcs + 3) / 4;
+ dst_type-length = num_srcs * 4 = 16 ? 16 : num_srcs * 4;
lp_build_conv(gallivm, src_type, *dst_type, src, num_srcs, dst,
num_dsts);
return num_dsts;
}
/* Special case 2x8f -- 1x16ub */
- if (src_type.length == 8 util_cpu_caps.has_avx)
+ if (src_type.length == 8
+ util_cpu_caps.has_avx)
{
- assert((num_srcs % 2) == 0);
-
- num_dsts = num_srcs / 2;
- dst_type-length = 16;
+ num_dsts = (num_srcs + 1) / 2;
+ dst_type-length = num_srcs * 8 = 16 ? 16 : num_srcs * 8;
lp_build_conv(gallivm, src_type, *dst_type, src, num_srcs, dst,
num_dsts);
return num_dsts;
@@ -602,7 +600,7 @@ lp_build_conv(struct gallivm_state *gallivm,
num_tmps = num_srcs;
- /* Special case 4x4f -- 1x16ub
+ /* Special case 4x4f -- 1x16ub, 2x4f - 1x8ub, 1x4f - 1x4ub
*/
if (src_type.floating == 1
src_type.fixed== 0
@@ -616,20 +614,23 @@ lp_build_conv(struct gallivm_state *gallivm,
dst_type.sign == 0
dst_type.norm == 1
dst_type.width== 8
- dst_type.length == 16
- 4 * num_dsts == num_srcs
+ ((dst_type.length == 16 4 * num_dsts == num_srcs) ||
+(num_dsts == 1 dst_type.length * num_srcs == 16 num_srcs != 3))
util_cpu_caps.has_sse2)
{
struct lp_build_context bld;
- struct lp_type int16_type = dst_type;
- struct lp_type int32_type = dst_type;
+ struct lp_type int16_type, int32_type;
+ struct lp_type dst_type_ext = dst_type;
LLVMValueRef const_255f;
unsigned i, j;
lp_build_context_init(bld, gallivm, src_type);
+ dst_type_ext.length = 16;
+ int16_type = int32_type = dst_type_ext;
+
int16_type.width *= 2;
int16_type.length /= 2;
int16_type.sign = 1;
@@ -643,21 +644,34 @@ lp_build_conv(struct gallivm_state *gallivm,
for (i = 0; i num_dsts; ++i, src += 4) {
LLVMValueRef lo, hi;
- for (j = 0; j 4; ++j) {
+ for (j = 0; j dst_type.length / 4; ++j) {
tmp[j] = LLVMBuildFMul(builder, src[j], const_255f, );
tmp[j] = lp_build_iround(bld, tmp[j]);
}
+ if (num_srcs == 1) {
+tmp[1] = tmp[0];
+ }
+
/* relying on clamping behavior of sse2 intrinsics here */
lo = lp_build_pack2(gallivm, int32_type, int16_type, tmp[0], tmp[1]);
- hi = lp_build_pack2(gallivm, int32_type, int16_type, tmp[2], tmp[3]);
- dst[i] = lp_build_pack2(gallivm, int16_type, dst_type, lo, hi);
+
+ if (num_srcs 4) {
+hi = lo;
+ }
+ else {
+hi = lp_build_pack2(gallivm, int32_type, int16_type, tmp[2],
Re: [Mesa-dev] [PATCH] meta: move vertex array enables for mipmap generation
On 05/31/2013 08:18 AM, Brian Paul wrote: Before, on the second call to GenerateMipmap were enabling two vertex arrays for the current vertex array object, rather than the private generate-mipmap vertex array object. This caused things to blow up elsewhere. This patch moves the array enables into the block where the generate-mipmap vertex array object is created, as we do in the setup_ff_generate_mipmap() function. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60518 NOTE: This is a candidate for the stable branches. Tested-by: cor...@gmx.net Reviewed-by: Ian Romanick ian.d.roman...@intel.com --- src/mesa/drivers/common/meta.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index ca5f5a1..1ab603a 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -3397,6 +3397,8 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, sizeof(struct vertex), OFFSET(x)); _mesa_VertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(struct vertex), OFFSET(tex)); + _mesa_EnableVertexAttribArray(0); + _mesa_EnableVertexAttribArray(1); } /* Generate a fragment shader program appropriate for the texture target */ @@ -3468,8 +3470,6 @@ setup_glsl_generate_mipmap(struct gl_context *ctx, _mesa_DeleteObjectARB(vs); _mesa_BindAttribLocation(mipmap-ShaderProg, 0, position); _mesa_BindAttribLocation(mipmap-ShaderProg, 1, texcoords); - _mesa_EnableVertexAttribArray(0); - _mesa_EnableVertexAttribArray(1); link_program_with_debug(ctx, mipmap-ShaderProg); sampler-shader_prog = mipmap-ShaderProg; ralloc_free(mem_ctx); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Security fixes applied in mesa trunk
On 05/31/2013 08:46 AM, Laurent Carlier wrote: Two security fixes were applied recently (CVE-2013-1993), it would be nice to see a new mesa stable release with these fixes applied. There's another about to land. I'm expecting there will be 9.1.4 next week. I'll pick the commits that have landed over to the 9.1 branch in just a few minutes. Thanks. ___ 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] llvmpipe: fix bogus assertions for buffer surfaces
From: Roland Scheidegger srol...@vmware.com
One of the assertion made no sense for buffer rendertargets
(due to the union), so drop it. (The same assertion is present already in
the path for texture surfaces later.).
---
src/gallium/drivers/llvmpipe/lp_texture.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index a02ddbc..b959e82 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -485,7 +485,6 @@ llvmpipe_create_surface(struct pipe_context *pipe,
{
struct pipe_surface *ps;
- assert(surf_tmpl-u.tex.level = pt-last_level);
if (!(pt-bind (PIPE_BIND_DEPTH_STENCIL | PIPE_BIND_RENDER_TARGET)))
debug_printf(Illegal surface creation without bind flag\n);
@@ -513,7 +512,8 @@ llvmpipe_create_surface(struct pipe_context *pipe,
ps-u.buf.first_element = surf_tmpl-u.buf.first_element;
ps-u.buf.last_element = surf_tmpl-u.buf.last_element;
assert(ps-u.buf.first_element = ps-u.buf.last_element);
- assert(ps-u.buf.last_element ps-width);
+ assert(util_format_get_blocksize(surf_tmpl-format) *
+ps-u.buf.last_element pt-width0);
}
}
return ps;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl: Make a local variable to avoid restating this array lookup.
---
src/glsl/link_uniforms.cpp | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index ad63668..54d54cf 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -640,7 +640,9 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
*/
count_uniform_size uniform_size(prog-UniformHash);
for (unsigned i = 0; i MESA_SHADER_TYPES; i++) {
- if (prog-_LinkedShaders[i] == NULL)
+ struct gl_shader *sh = prog-_LinkedShaders[i];
+
+ if (sh == NULL)
continue;
/* Uniforms that lack an initializer in the shader code have an initial
@@ -655,13 +657,13 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
memset(prog-_LinkedShaders[i]-SamplerUnits, 0,
sizeof(prog-_LinkedShaders[i]-SamplerUnits));
- link_update_uniform_buffer_variables(prog-_LinkedShaders[i]);
+ link_update_uniform_buffer_variables(sh);
/* Reset various per-shader target counts.
*/
uniform_size.start_shader();
- foreach_list(node, prog-_LinkedShaders[i]-ir) {
+ foreach_list(node, sh-ir) {
ir_variable *const var = ((ir_instruction *) node)-as_variable();
if ((var == NULL) || (var-mode != ir_var_uniform))
@@ -678,9 +680,8 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
uniform_size.process(var);
}
- prog-_LinkedShaders[i]-num_samplers = uniform_size.num_shader_samplers;
- prog-_LinkedShaders[i]-num_uniform_components =
-uniform_size.num_shader_uniform_components;
+ sh-num_samplers = uniform_size.num_shader_samplers;
+ sh-num_uniform_components = uniform_size.num_shader_uniform_components;
}
const unsigned num_user_uniforms = uniform_size.num_active_uniforms;
--
1.8.3.rc0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: Fix uniform buffer object counting.
We were counting uniforms located in UBOs against the default uniform
block limit, while not doing any counting against the specific combined
limit.
Note that I couldn't quite find justification for the way I did this, but
I think it's the only sensible thing: The spec talks about components, so
each float in a std140 block would count as 1 component and a vec4
would count as 4, though they occupy the same amount of space. Since GPU
limits on uniform buffer loads are surely going to be about the size of
the blocks, I just counted them that way.
Fixes link failures in piglit
arb_uniform_buffer_object/maxuniformblocksize when ported to geometry
shaders on Paul's GS branch, since in that case the max block size is
bigger than the default uniform block component limit.
---
src/glsl/link_uniforms.cpp | 12 +++-
src/glsl/linker.cpp| 25 +++--
src/mesa/main/mtypes.h | 10 +-
3 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index 54d54cf..c4f86c8 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -170,6 +170,7 @@ public:
void process(ir_variable *var)
{
+ this-is_ubo_var = var-is_in_uniform_block();
if (var-is_interface_instance())
program_resource_visitor::process(var-interface_type,
var-interface_type-name);
@@ -197,6 +198,8 @@ public:
*/
unsigned num_shader_uniform_components;
+ bool is_ubo_var;
+
private:
virtual void visit_field(const glsl_type *type, const char *name,
bool row_major)
@@ -222,7 +225,8 @@ private:
* Note that samplers do not count against this limit because they
* don't use any storage on current hardware.
*/
-this-num_shader_uniform_components += values;
+if (!is_ubo_var)
+ this-num_shader_uniform_components += values;
}
/* If the uniform is already in the map, there's nothing more to do.
@@ -682,6 +686,12 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
sh-num_samplers = uniform_size.num_shader_samplers;
sh-num_uniform_components = uniform_size.num_shader_uniform_components;
+
+ sh-num_combined_uniform_components = sh-num_uniform_components;
+ for (unsigned i = 0; i sh-NumUniformBlocks; i++) {
+sh-num_combined_uniform_components +=
+ sh-UniformBlocks[i].UniformBufferSize / 4;
+ }
}
const unsigned num_user_uniforms = uniform_size.num_active_uniforms;
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 982fe46..cd8d680 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1523,12 +1523,18 @@ check_resources(struct gl_context *ctx, struct
gl_shader_program *prog)
ctx-Const.GeometryProgram.MaxTextureImageUnits
};
- const unsigned max_uniform_components[MESA_SHADER_TYPES] = {
+ const unsigned max_default_uniform_components[MESA_SHADER_TYPES] = {
ctx-Const.VertexProgram.MaxUniformComponents,
ctx-Const.FragmentProgram.MaxUniformComponents,
ctx-Const.GeometryProgram.MaxUniformComponents
};
+ const unsigned max_combined_uniform_components[MESA_SHADER_TYPES] = {
+ ctx-Const.VertexProgram.MaxCombinedUniformComponents,
+ ctx-Const.FragmentProgram.MaxCombinedUniformComponents,
+ ctx-Const.GeometryProgram.MaxCombinedUniformComponents
+ };
+
const unsigned max_uniform_blocks[MESA_SHADER_TYPES] = {
ctx-Const.VertexProgram.MaxUniformBlocks,
ctx-Const.FragmentProgram.MaxUniformBlocks,
@@ -1546,7 +1552,22 @@ check_resources(struct gl_context *ctx, struct
gl_shader_program *prog)
shader_names[i]);
}
- if (sh-num_uniform_components max_uniform_components[i]) {
+ if (sh-num_uniform_components max_default_uniform_components[i]) {
+ if (ctx-Const.GLSLSkipStrictMaxUniformLimitCheck) {
+linker_warning(prog, Too many %s shader default uniform block
+ components, but the driver will try to optimize
+ them out; this is non-portable out-of-spec
+ behavior\n,
+ shader_names[i]);
+ } else {
+linker_error(prog, Too many %s shader default uniform block
+components,
+ shader_names[i]);
+ }
+ }
+
+ if (sh-num_combined_uniform_components
+ max_combined_uniform_components[i]) {
if (ctx-Const.GLSLSkipStrictMaxUniformLimitCheck) {
linker_warning(prog, Too many %s shader uniform components,
but the driver will try to optimize them out;
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 186f8a0..d982391 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2141,13 +2141,21 @@
[Mesa-dev] [PATCH] intel: flush fake front buffer if server is about to destroy it.
Fixes piglit test spec/!OpenGL 1.0/gl-1.0-front-invalidate-back
---
This patch depends on [PATCH 2/2] intel: flush fake front buffer more
robustly., which was sent to mesa-dev yesterday and is still awaiting
review.
src/mesa/drivers/dri/intel/intel_context.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 0afd417..4508e49 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -1079,6 +1079,15 @@ intel_query_dri2_buffers(struct intel_context *intel,
attachments[i++] = __DRI_BUFFER_FRONT_LEFT;
attachments[i++] = intel_bits_per_pixel(front_rb);
+ } else if (front_rb intel-front_buffer_dirty) {
+ /* We have pending front buffer rendering, but we aren't querying for a
+ * front buffer. If the front buffer we have is a fake front buffer,
+ * the X server is going to throw it away when it processes the query.
+ * So before doing the query, make sure all the pending drawing has
+ * landed in the real front buffer.
+ */
+ intel_flush(intel-ctx);
+ intel_flush_front(intel-ctx);
}
if (back_rb) {
--
1.8.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: add support for layered rendering
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as well.
(Note that what GL knows as gl_Layer variable d3d10 is naming
RENDER_TARGET_ARRAY_INDEX)
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/include/pipe/p_defines.h |3 ++-
src/gallium/include/pipe/p_shader_tokens.h |3 ++-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 683080c..b74b237 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -168,6 +168,8 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
+* ``PIPE_CAP_LAYERED_RENDERING``: Whether rendering to multiple layers is
+ supported using layer selection by the TGSI_SEMANTIC_LAYER shader variable.
.. _pipe_capf:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8af1a84..c359a9e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -508,7 +508,8 @@ enum pipe_cap {
PIPE_CAP_QUERY_PIPELINE_STATISTICS = 81,
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK = 82,
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
- PIPE_CAP_MAX_VIEWPORTS = 84
+ PIPE_CAP_MAX_VIEWPORTS = 84,
+ PIPE_CAP_MULTIPLE_LAYERS = 85
};
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index b33cf1d..c984d50 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -165,7 +165,8 @@ struct tgsi_declaration_interp
#define TGSI_SEMANTIC_TEXCOORD 19 /** texture or sprite coordinates */
#define TGSI_SEMANTIC_PCOORD 20 /** point sprite coordinate */
#define TGSI_SEMANTIC_VIEWPORT_INDEX 21 /** viewport index */
-#define TGSI_SEMANTIC_COUNT 22 /** number of semantic values */
+#define TGSI_SEMANTIC_LAYER 22 /** layer (rendertarget index) */
+#define TGSI_SEMANTIC_COUNT 23 /** number of semantic values */
struct tgsi_declaration_semantic
{
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Do we support front buffer rendering with EGL? Do we want to?
After my recent work on front buffer rendering I decided to try a piglit
run with PIGLIT_PLATFORM=x11_egl to see whether front buffer rendering
works with EGL. It doesn't, and I tracked the problem down to this
function, from src/egl/drivers/dri2/platform_x11.c:
static void
dri2_flush_front_buffer(__DRIdrawable * driDrawable, void *loaderPrivate)
{
(void) driDrawable;
/* FIXME: Does EGL support front buffer rendering at all? */
#if 0
struct dri2_egl_surface *dri2_surf = loaderPrivate;
dri2WaitGL(dri2_surf);
#else
(void) loaderPrivate;
#endif
}
Since this function is a nop, rendering to the fake front buffer doesn't
get properly flushed to the real front buffer, so the following piglit
tests fail (at least with the Intel backend):
- spec/!OpenGL 1.1/drawbuffer-modes
- spec/EXT_framebuffer_blit/fbo-sys-blit
- spec/EXT_framebuffer_blit/fbo-sys-sub-blit
Note: to see this failure reliably, you need to patch Mesa and the X server
to address the bugs mentioned in
http://lists.freedesktop.org/archives/mesa-dev/2013-May/039985.html.
I'm trying to decide whether or not this is a problem. The EGL 1.4 spec
leaves some wiggle room about whether front buffer rendering is allowed, to
accommodate window systems that don't permit front buffer rendering.
However, since X11 supports front buffer rendering, it seems to me that
Mesa-EGL-X11 ought to support it.
Also, some of us have pipe dreams of a future where Linux desktop apps
transition over to using EGL instead of GLX. It seems like supporting
front buffer rendering via EGL would help encourage that.
Thoughts?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Fix glColorPointer(GL_FIXED)
When a gl_client_array is created with glColorPointer,
gl_client_array::Normalized is true. This caused the translation from the
gl_client_array's type to a BRW_SURFACEFORMAT to assertion fail.
Fixes the spinning cube's color in Android 4.2's ApiDemos.apk,
Graphics OpenGL ES.
Fixes assertion failure in mesa-demos/src/egl/opengles1/tri_x11 on Haswell
and Ivybridge:
brw_draw_upload.c:287: get_surface_type: Assertion `0' failed.
No Piglit regressions on Haswell.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42182
Issue: AXIA-2954
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index d2451f9..2ded14b 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -263,6 +263,14 @@ get_surface_type(struct intel_context *intel,
else {
return ubyte_types_norm[size];
}
+ case GL_FIXED:
+ if (intel-gen = 8 || intel-is_haswell)
+return fixed_point_types[size];
+
+ /* This produces GL_FIXED inputs as values between INT32_MIN and
+ * INT32_MAX, which will be scaled down by 1/65536 by the VS.
+ */
+ return int_types_scale[size];
/* See GL_ARB_vertex_type_2_10_10_10_rev.
* W/A: Pre-Haswell, the hardware doesn't really support the formats we'd
* like to use here, so upload everything as UINT and fix
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add support for layered rendering
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as well.
(Note that what GL knows as gl_Layer variable d3d10 is naming
RENDER_TARGET_ARRAY_INDEX)
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/include/pipe/p_defines.h |3 ++-
src/gallium/include/pipe/p_shader_tokens.h |3 ++-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 683080c..b74b237 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -168,6 +168,8 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
+* ``PIPE_CAP_LAYERED_RENDERING``: Whether rendering to multiple layers is
+ supported using layer selection by the TGSI_SEMANTIC_LAYER shader variable.
.. _pipe_capf:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8af1a84..c359a9e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -508,7 +508,8 @@ enum pipe_cap {
PIPE_CAP_QUERY_PIPELINE_STATISTICS = 81,
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK = 82,
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
- PIPE_CAP_MAX_VIEWPORTS = 84
+ PIPE_CAP_MAX_VIEWPORTS = 84,
+ PIPE_CAP_MULTIPLE_LAYERS = 85
};
Actually I don't think is a good name, PIPE_CAP_LAYERED_RENDERING might
be better?
I'm open to just about any suggestion though :-).
Roland
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index b33cf1d..c984d50 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -165,7 +165,8 @@ struct tgsi_declaration_interp
#define TGSI_SEMANTIC_TEXCOORD 19 /** texture or sprite coordinates */
#define TGSI_SEMANTIC_PCOORD 20 /** point sprite coordinate */
#define TGSI_SEMANTIC_VIEWPORT_INDEX 21 /** viewport index */
-#define TGSI_SEMANTIC_COUNT 22 /** number of semantic values */
+#define TGSI_SEMANTIC_LAYER 22 /** layer (rendertarget index) */
+#define TGSI_SEMANTIC_COUNT 23 /** number of semantic values */
struct tgsi_declaration_semantic
{
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add support for layered rendering
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as well.
(Note that what GL knows as gl_Layer variable d3d10 is naming
RENDER_TARGET_ARRAY_INDEX)
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/include/pipe/p_defines.h |3 ++-
src/gallium/include/pipe/p_shader_tokens.h |3 ++-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 683080c..b74b237 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -168,6 +168,8 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
+* ``PIPE_CAP_LAYERED_RENDERING``: Whether rendering to multiple layers is
+ supported using layer selection by the TGSI_SEMANTIC_LAYER shader
variable.
.. _pipe_capf:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8af1a84..c359a9e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -508,7 +508,8 @@ enum pipe_cap {
PIPE_CAP_QUERY_PIPELINE_STATISTICS = 81,
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK = 82,
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
- PIPE_CAP_MAX_VIEWPORTS = 84
+ PIPE_CAP_MAX_VIEWPORTS = 84,
+ PIPE_CAP_MULTIPLE_LAYERS = 85
};
Actually I don't think is a good name, PIPE_CAP_LAYERED_RENDERING might
be better?
I'm open to just about any suggestion though :-).
FWIW, I prefer PIPE_CAP_LAYERED_RENDERING as well. Other colors:
PIPE_CAP_RENDER_TARGET_INDEX
PIPE_CAP_RENDER_TARGET_ARRAY_INDEX
PIPE_CAP_RENDER_TARGET_LAYERS
Alex
Roland
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index b33cf1d..c984d50 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -165,7 +165,8 @@ struct tgsi_declaration_interp
#define TGSI_SEMANTIC_TEXCOORD 19 /** texture or sprite coordinates */
#define TGSI_SEMANTIC_PCOORD 20 /** point sprite coordinate */
#define TGSI_SEMANTIC_VIEWPORT_INDEX 21 /** viewport index */
-#define TGSI_SEMANTIC_COUNT 22 /** number of semantic values */
+#define TGSI_SEMANTIC_LAYER 22 /** layer (rendertarget index) */
+#define TGSI_SEMANTIC_COUNT 23 /** number of semantic values */
struct tgsi_declaration_semantic
{
___
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] gallium: add support for layered rendering
On 01.06.2013 01:02, Alex Deucher wrote:
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as well.
(Note that what GL knows as gl_Layer variable d3d10 is naming
RENDER_TARGET_ARRAY_INDEX)
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/include/pipe/p_defines.h |3 ++-
src/gallium/include/pipe/p_shader_tokens.h |3 ++-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 683080c..b74b237 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -168,6 +168,8 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
+* ``PIPE_CAP_LAYERED_RENDERING``: Whether rendering to multiple layers is
+ supported using layer selection by the TGSI_SEMANTIC_LAYER shader
variable.
.. _pipe_capf:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8af1a84..c359a9e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -508,7 +508,8 @@ enum pipe_cap {
PIPE_CAP_QUERY_PIPELINE_STATISTICS = 81,
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK = 82,
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
- PIPE_CAP_MAX_VIEWPORTS = 84
+ PIPE_CAP_MAX_VIEWPORTS = 84,
+ PIPE_CAP_MULTIPLE_LAYERS = 85
};
Actually I don't think is a good name, PIPE_CAP_LAYERED_RENDERING might
be better?
I'm open to just about any suggestion though :-).
FWIW, I prefer PIPE_CAP_LAYERED_RENDERING as well. Other colors:
PIPE_CAP_RENDER_TARGET_INDEX
PIPE_CAP_RENDER_TARGET_ARRAY_INDEX
PIPE_CAP_RENDER_TARGET_LAYERS
Or PIPE_CAP_GS_LAYER_SELECTION to make it clear that the driver doesn't
support GL_AMD_vertex_shader_layer ?
Alex
Roland
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index b33cf1d..c984d50 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -165,7 +165,8 @@ struct tgsi_declaration_interp
#define TGSI_SEMANTIC_TEXCOORD 19 /** texture or sprite coordinates */
#define TGSI_SEMANTIC_PCOORD 20 /** point sprite coordinate */
#define TGSI_SEMANTIC_VIEWPORT_INDEX 21 /** viewport index */
-#define TGSI_SEMANTIC_COUNT 22 /** number of semantic values */
+#define TGSI_SEMANTIC_LAYER 22 /** layer (rendertarget index) */
+#define TGSI_SEMANTIC_COUNT 23 /** number of semantic values */
struct tgsi_declaration_semantic
{
___
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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 65224] New: piglit arb_uniform_buffer_object-maxuniformblocksize fs regression
https://bugs.freedesktop.org/show_bug.cgi?id=65224
Priority: medium
Bug ID: 65224
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit arb_uniform_buffer_object-maxuniformblocksize
fs regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Mesa core
Product: Mesa
mesa: 869c5d438f137b2c6b9aec1dddc00bfa64f36621 (master)
piglit arb_uniform_buffer_object-maxuniformblocksize fs regressed on softpipe
and llvmpipe.
$ ./bin/arb_uniform_buffer_object-maxuniformblocksize fs -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
Max uniform block size: 65536
Testing FS with uniform block vec4 v[4096]
Failed to link: error: Too many fragment shader uniform components
Failed to link with uniform block vec4 v[4096]
PIGLIT: {'result': 'fail' }
614ee25077b7ffafeb87b22563d01856824fb4bc is the first bad commit
commit 614ee25077b7ffafeb87b22563d01856824fb4bc
Author: Marek Olšák mar...@gmail.com
Date: Thu May 2 02:38:43 2013 +0200
st/mesa: initialize all program constants and UBO limits
Also simplify UBO support checking.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Brian Paul bri...@vmware.com
:04 04 43469d74b142c9f8cc68e07142a952dd73c6298d
bd3bffda50371f7e9f646dda596077eb828ec3be 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] gallivm: fix out-of-bounds access with mirror_clamp_to_edge address mode
From: Roland Scheidegger srol...@vmware.com
Surprising this bug survived so long, we were missing a clamp (in the
linear filtering version).
(Valgrind complained a lot about invalid reads with piglit texwrap,
I've also seen spurios failures in this test which might have
happened due to this. Valgrind probably didn't complain before the
alignment reduction in llvmpipe to 4x4 since the test is using tiny
textures so the reads were still always well within allocated area.)
While here, also do an effective clamp (after half subtraction)
of [0,length-0.5] instead of [0, length-1] which saves an instruction
(the filtering weight could be different due to this, but only if
both texels point to the same max texel so it doesn't matter).
(Both changes are borrowed from PIPE_TEX_CLAMP_TO_EDGE case.)
Note: This is a candidate for the stable branches.
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index 7ac0029..e0a59d0 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -436,7 +436,6 @@ lp_build_sample_wrap_linear(struct lp_build_sample_context
*bld,
case PIPE_TEX_WRAP_MIRROR_CLAMP_TO_EDGE:
{
- LLVMValueRef min, max;
struct lp_build_context abs_coord_bld = bld-coord_bld;
abs_coord_bld.type.sign = FALSE;
@@ -450,16 +449,18 @@ lp_build_sample_wrap_linear(struct
lp_build_sample_context *bld,
}
coord = lp_build_abs(coord_bld, coord);
- /* clamp to [0.5, length - 0.5] */
- min = half;
- max = lp_build_sub(coord_bld, length_f, min);
- coord = lp_build_clamp(coord_bld, coord, min, max);
-
+ /* clamp to length max */
+ coord = lp_build_min(coord_bld, coord, length_f);
+ /* subtract 0.5 */
coord = lp_build_sub(coord_bld, coord, half);
+ /* clamp to [0, length - 0.5] */
+ coord = lp_build_max(coord_bld, coord, coord_bld-zero);
/* convert to int, compute lerp weight */
lp_build_ifloor_fract(abs_coord_bld, coord, coord0, weight);
coord1 = lp_build_add(int_coord_bld, coord0, int_coord_bld-one);
+ /* coord1 = min(coord1, length-1) */
+ coord1 = lp_build_min(int_coord_bld, coord1, length_minus_one);
}
break;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add support for layered rendering
Am 01.06.2013 01:22, schrieb Christoph Bumiller:
On 01.06.2013 01:02, Alex Deucher wrote:
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as well.
(Note that what GL knows as gl_Layer variable d3d10 is naming
RENDER_TARGET_ARRAY_INDEX)
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/include/pipe/p_defines.h |3 ++-
src/gallium/include/pipe/p_shader_tokens.h |3 ++-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 683080c..b74b237 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -168,6 +168,8 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
+* ``PIPE_CAP_LAYERED_RENDERING``: Whether rendering to multiple layers is
+ supported using layer selection by the TGSI_SEMANTIC_LAYER shader
variable.
.. _pipe_capf:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8af1a84..c359a9e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -508,7 +508,8 @@ enum pipe_cap {
PIPE_CAP_QUERY_PIPELINE_STATISTICS = 81,
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK = 82,
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
- PIPE_CAP_MAX_VIEWPORTS = 84
+ PIPE_CAP_MAX_VIEWPORTS = 84,
+ PIPE_CAP_MULTIPLE_LAYERS = 85
};
Actually I don't think is a good name, PIPE_CAP_LAYERED_RENDERING might
be better?
I'm open to just about any suggestion though :-).
FWIW, I prefer PIPE_CAP_LAYERED_RENDERING as well. Other colors:
PIPE_CAP_RENDER_TARGET_INDEX
PIPE_CAP_RENDER_TARGET_ARRAY_INDEX
PIPE_CAP_RENDER_TARGET_LAYERS
Or PIPE_CAP_GS_LAYER_SELECTION to make it clear that the driver doesn't
support GL_AMD_vertex_shader_layer ?
Actually now that you mention GS I think we could probably get rid of
the cap bit entirely and just depend on the PIPE_SHADER_GEOMETRY query
to expose this, as it's pretty much tied to it anyway?
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 65225] New: [softpipe] piglit interpolation-none-gl_BackColor-flat-fixed regression
https://bugs.freedesktop.org/show_bug.cgi?id=65225
Priority: medium
Bug ID: 65225
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit
interpolation-none-gl_BackColor-flat-fixed regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Mesa core
Product: Mesa
mesa: 869c5d438f137b2c6b9aec1dddc00bfa64f36621 (master)
$ ./bin/shader_runner
generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_BackColor-flat-fixed.shader_test
-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
Probe at (159,45)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
Probe at (192,38)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
Probe at (216,33)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
Probe at (166,83)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
Probe at (196,71)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
Probe at (136,136)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
Probe at (173,115)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
Probe at (145,166)
Expected: 0.00 0.00 1.00 1.00
Observed: 1.00 1.00 0.00 0.572549
PIGLIT: {'result': 'fail' }
4b5595b38b3884531624fab6def7c604e92d0914 is the first bad commit
commit 4b5595b38b3884531624fab6def7c604e92d0914
Author: Zack Rusin za...@vmware.com
Date: Fri May 24 16:39:59 2013 -0400
draw: fixup draw_find_shader_output
draw_find_shader_output like most of the code in draw used to
depend on position always being at output slot 0. which meant
that any other attribute being at 0 could signify an error.
unfortunately position can be at any of the output slots, thus
other attributes can occupy slot 0 and we need to mark the ones
which were not found by something else. This commit changes
draw_find_shader_output so that it returns -1 if it can't
find the given attribute and adjust the code that depended
on it returning 0 whenever it correctly found an attrib.
Signed-off-by: Zack Rusin za...@vmware.com
Reviewed-by: José Fonsecajfons...@vmware.com
Reviewed-by: Brian Paul bri...@vmware.com
Reviewed-by: Roland Scheidegger srol...@vmware.com
:04 04 677fc576c96383eabe6210f6a82e19592b7b59cf
220034f286f44d7e00165cfba49f5204ee1b1589 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] [Bug 65226] New: [llvmpipe] st_mesa_to_tgsi.c:1133:st_translate_mesa_program: Assertion `program-NumAddressRegs == 1' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=65226 Priority: medium Bug ID: 65226 Keywords: have-backtrace, regression CC: mar...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: [llvmpipe] st_mesa_to_tgsi.c:1133:st_translate_mesa_program: Assertion `program-NumAddressRegs == 1' failed. Severity: critical Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: 869c5d438f137b2c6b9aec1dddc00bfa64f36621 (master) Run piglit vp-address-02 on llvmpipe. $ ./bin/vp-address-02 -auto src/mesa/state_tracker/st_mesa_to_tgsi.c:1133:st_translate_mesa_program: Assertion `program-NumAddressRegs == 1' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x7f86655b6ba6 in _debug_assert_fail (expr=0x7f8666104f9f program-NumAddressRegs == 1, file=0x7f8666104aa8 src/mesa/state_tracker/st_mesa_to_tgsi.c, line=1133, function=0x7f8666105040 st_translate_mesa_program) at src/gallium/auxiliary/util/u_debug.c:278 #1 0x7f86654c5ccf in st_translate_mesa_program (ctx=0x16baac0, procType=1, ureg=0x1802160, program=0x17f1b40, numInputs=2, inputMapping=0x1801ef8, inputSemanticName=0x0, inputSemanticIndex=0x0, interpMode=0x0, numOutputs=2, outputMapping=0x1802000, outputSemanticName=0x18020dc , outputSemanticIndex=0x1802113 , passthrough_edgeflags=0 '\000', clamp_color=0 '\000') at src/mesa/state_tracker/st_mesa_to_tgsi.c:1133 #2 0x7f86653d32c2 in st_translate_vertex_program (st=0x1710520, stvp=0x17f1b40, key=0x7fff83643f50) at src/mesa/state_tracker/st_program.c:355 #3 0x7f86653d3482 in st_get_vp_variant (st=0x1710520, stvp=0x17f1b40, key=0x7fff83643f50) at src/mesa/state_tracker/st_program.c:426 #4 0x7f8665499bbb in update_vp (st=0x1710520) at src/mesa/state_tracker/st_atom_shader.c:152 #5 0x7f866549443e in st_validate_state (st=0x1710520) at src/mesa/state_tracker/st_atom.c:201 #6 0x7f86654a0a9d in st_Clear (ctx=0x16baac0, mask=2) at src/mesa/state_tracker/st_cb_clear.c:395 #7 0x7f866540a55e in _mesa_Clear (mask=16384) at src/mesa/main/clear.c:203 #8 0x7f8668024fb3 in stub_glClear (mask=16384) at piglit/tests/util/generated_dispatch.c:1798 #9 0x00401114 in piglit_display () at piglit/tests/shaders/vp-address-02.c:95 #10 0x7f8668021060 in display () at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:60 #11 0x7f86677ce137 in fghRedrawWindow (window=0x1647090) at freeglut_main.c:210 #12 fghcbDisplayWindow (window=0x1647090, enumerator=0x7fff836441b0) at freeglut_main.c:227 #13 0x7f86677d1889 in fgEnumWindows (enumCallback=0x7f86677ce0d0 fghcbDisplayWindow, enumerator=0x7fff836441b0) at freeglut_structure.c:394 #14 0x7f86677ce5fa in fghDisplayAll () at freeglut_main.c:249 #15 glutMainLoopEvent () at freeglut_main.c:1450 #16 0x7f86677cef05 in glutMainLoop () at freeglut_main.c:1498 #17 0x7f8668021295 in run_test (gl_fw=0x7f86682fdf40, argc=1, argv=0x7fff83644578) at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:142 #18 0x7f866801f37e in piglit_gl_test_run (argc=1, argv=0x7fff83644578, config=0x7fff83644460) at piglit/tests/util/piglit-framework-gl.c:127 #19 0x004010de in main (argc=2, argv=0x7fff83644578) at piglit/tests/shaders/vp-address-02.c:63 (gdb) frame 1 #1 0x7f86654c5ccf in st_translate_mesa_program (ctx=0x16baac0, procType=1, ureg=0x1802160, program=0x17f1b40, numInputs=2, inputMapping=0x1801ef8, inputSemanticName=0x0, inputSemanticIndex=0x0, interpMode=0x0, numOutputs=2, outputMapping=0x1802000, outputSemanticName=0x18020dc , outputSemanticIndex=0x1802113 , passthrough_edgeflags=0 '\000', clamp_color=0 '\000') at src/mesa/state_tracker/st_mesa_to_tgsi.c:1133 1133 debug_assert( program-NumAddressRegs == 1 ); (gdb) print program-NumAddressRegs $1 = 2 614ee25077b7ffafeb87b22563d01856824fb4bc is the first bad commit commit 614ee25077b7ffafeb87b22563d01856824fb4bc Author: Marek Olšák mar...@gmail.com Date: Thu May 2 02:38:43 2013 +0200 st/mesa: initialize all program constants and UBO limits Also simplify UBO support checking. NOTE: This is a candidate for the 9.1 branch. Reviewed-by: Brian Paul bri...@vmware.com :04 04 43469d74b142c9f8cc68e07142a952dd73c6298d bd3bffda50371f7e9f646dda596077eb828ec3be 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
Re: [Mesa-dev] [PATCH] gallium: add support for layered rendering
On Sat, Jun 1, 2013 at 2:42 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 01.06.2013 01:22, schrieb Christoph Bumiller:
On 01.06.2013 01:02, Alex Deucher wrote:
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as well.
(Note that what GL knows as gl_Layer variable d3d10 is naming
RENDER_TARGET_ARRAY_INDEX)
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/include/pipe/p_defines.h |3 ++-
src/gallium/include/pipe/p_shader_tokens.h |3 ++-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 683080c..b74b237 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -168,6 +168,8 @@ The integer capabilities:
since they are linked) a driver can support. Returning 0 is equivalent
to returning 1 because every driver has to support at least a single
viewport/scissor combination.
+* ``PIPE_CAP_LAYERED_RENDERING``: Whether rendering to multiple layers is
+ supported using layer selection by the TGSI_SEMANTIC_LAYER shader
variable.
.. _pipe_capf:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8af1a84..c359a9e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -508,7 +508,8 @@ enum pipe_cap {
PIPE_CAP_QUERY_PIPELINE_STATISTICS = 81,
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK = 82,
PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE = 83,
- PIPE_CAP_MAX_VIEWPORTS = 84
+ PIPE_CAP_MAX_VIEWPORTS = 84,
+ PIPE_CAP_MULTIPLE_LAYERS = 85
};
Actually I don't think is a good name, PIPE_CAP_LAYERED_RENDERING might
be better?
I'm open to just about any suggestion though :-).
FWIW, I prefer PIPE_CAP_LAYERED_RENDERING as well. Other colors:
PIPE_CAP_RENDER_TARGET_INDEX
PIPE_CAP_RENDER_TARGET_ARRAY_INDEX
PIPE_CAP_RENDER_TARGET_LAYERS
Or PIPE_CAP_GS_LAYER_SELECTION to make it clear that the driver doesn't
support GL_AMD_vertex_shader_layer ?
Actually now that you mention GS I think we could probably get rid of
the cap bit entirely and just depend on the PIPE_SHADER_GEOMETRY query
to expose this, as it's pretty much tied to it anyway?
Yes, the geometry shader query is sufficient.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
