[Mesa-dev] [PATCH] mesa: fix a leak in _mesa_delete_texture_image()
Valgrind complains about a definitely lost block allocated in intelNewTextureImage(). This leak was apparently created by 6e0f9001fe3fb191c2928bd09aa9e9d05ddf4ea9, mesa: move gl_texture_image::Data, RowStride, ImageOffsets to swrast, as it removes the free() from _mesa_delete_texture_image(). Put the free() back, fixes a Valgrind error. Signed-off-by: Pekka Paalanen ppaala...@gmail.com Cc: Brian Paul bri...@vmware.com --- src/mesa/main/teximage.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index 8a002b6..6318cb1 100644 --- a/src/mesa/main/teximage.c +++ b/src/mesa/main/teximage.c @@ -604,6 +604,7 @@ _mesa_delete_texture_image(struct gl_context *ctx, */ ASSERT(ctx-Driver.FreeTextureImageBuffer); ctx-Driver.FreeTextureImageBuffer( ctx, texImage ); + free(texImage); } -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Fix memory leak on error path.
Fixes Coverity resource leak defect.
Signed-off-by: Vinson Lee v...@vmware.com
---
src/mesa/program/prog_parameter_layout.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/prog_parameter_layout.c
b/src/mesa/program/prog_parameter_layout.c
index 28fca3b..e4f2db3 100644
--- a/src/mesa/program/prog_parameter_layout.c
+++ b/src/mesa/program/prog_parameter_layout.c
@@ -138,6 +138,7 @@ _mesa_layout_parameters(struct asm_parser_state *state)
inst-SrcReg[i].Symbol-param_binding_length);
if (new_begin 0) {
+ _mesa_free_parameter_list(layout);
return GL_FALSE;
}
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: Fix memory leak in out-of-memory path.
Fixes Coverity resource leak defect.
Signed-off-by: Vinson Lee v...@vmware.com
---
src/mesa/state_tracker/st_atom_pixeltransfer.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index afca609..fb1e409 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -266,6 +266,7 @@ get_pixel_transfer_program(struct gl_context *ctx, const
struct state_key *key)
if (!fp-Base.Instructions) {
_mesa_error(ctx, GL_OUT_OF_MEMORY,
generating pixel transfer program);
+ _mesa_free_parameter_list(params);
return NULL;
}
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43879] (xorg-server 1.11.2-2, xf86-video-ati 6.14.3-1 or git, qt 4.7.4) black pixels instead of transparency from PNGs
https://bugs.freedesktop.org/show_bug.cgi?id=43879 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added AssignedTo|xorg-driver-...@lists.x.org |mesa-dev@lists.freedesktop. ||org QAContact|xorg-t...@lists.x.org | Product|xorg|Mesa Component|Driver/Radeon |Mesa core --- Comment #2 from Michel Dänzer mic...@daenzer.net 2011-12-16 07:24:36 PST --- AFAICT from looking at it in apitrace, the game itself seems at least partly to blame: * It doesn't pass GLX_ALPHA_SIZE with a non-0 value to glXChooseFBConfig, so it can't rely on the FBConfig having an alpha channel. * It passes GLX_BIND_TO_TEXTURE_RGB_EXT (instead of GLX_BIND_TO_TEXTURE_RGBA_EXT) to glXChooseFBConfig and passes GLX_TEXTURE_FORMAT_RGB_EXT (instead of GLX_TEXTURE_FORMAT_RGBA_EXT) for GLX_TEXTURE_FORMAT_EXT to glXCreatePixmap, so it can't rely on that the FBConfig can be bound to a texture with an alpha channel. That said, I tried overriding these values in gdb, but the problem was still there, so there could be a Mesa issue as well. Anyway, it doesn't seem to happen with LIBGL_ALWAYS_INDIRECT=1 but does happen with llvmpipe, so reassigning to Mesa core for now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix a leak in _mesa_delete_texture_image()
On 12/16/2011 07:17 AM, Pekka Paalanen wrote: Valgrind complains about a definitely lost block allocated in intelNewTextureImage(). This leak was apparently created by 6e0f9001fe3fb191c2928bd09aa9e9d05ddf4ea9, mesa: move gl_texture_image::Data, RowStride, ImageOffsets to swrast, as it removes the free() from _mesa_delete_texture_image(). Put the free() back, fixes a Valgrind error. Signed-off-by: Pekka Paalanenppaala...@gmail.com Cc: Brian Paulbri...@vmware.com --- src/mesa/main/teximage.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index 8a002b6..6318cb1 100644 --- a/src/mesa/main/teximage.c +++ b/src/mesa/main/teximage.c @@ -604,6 +604,7 @@ _mesa_delete_texture_image(struct gl_context *ctx, */ ASSERT(ctx-Driver.FreeTextureImageBuffer); ctx-Driver.FreeTextureImageBuffer( ctx, texImage ); + free(texImage); } Reviewed-by: Brian Paul bri...@vmware.com Can you commit this? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix memory leak on error path.
On 12/16/2011 07:45 AM, Vinson Lee wrote:
Fixes Coverity resource leak defect.
Signed-off-by: Vinson Leev...@vmware.com
---
src/mesa/program/prog_parameter_layout.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/prog_parameter_layout.c
b/src/mesa/program/prog_parameter_layout.c
index 28fca3b..e4f2db3 100644
--- a/src/mesa/program/prog_parameter_layout.c
+++ b/src/mesa/program/prog_parameter_layout.c
@@ -138,6 +138,7 @@ _mesa_layout_parameters(struct asm_parser_state *state)
inst-SrcReg[i].Symbol-param_binding_length);
if (new_begin 0) {
+ _mesa_free_parameter_list(layout);
return GL_FALSE;
}
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: Fix memory leak in out-of-memory path.
On 12/16/2011 07:46 AM, Vinson Lee wrote:
Fixes Coverity resource leak defect.
Signed-off-by: Vinson Leev...@vmware.com
---
src/mesa/state_tracker/st_atom_pixeltransfer.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index afca609..fb1e409 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -266,6 +266,7 @@ get_pixel_transfer_program(struct gl_context *ctx, const
struct state_key *key)
if (!fp-Base.Instructions) {
_mesa_error(ctx, GL_OUT_OF_MEMORY,
generating pixel transfer program);
+ _mesa_free_parameter_list(params);
return NULL;
}
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: Fix build with llvm-3.1svn.
On 12/12/2011 07:01 PM, Vinson Lee wrote:
llvm-3.1svn r145714 moved global variables into a new TargetOptions
class. TargetMachine constructor now needs a TargetOptions object as
well.
Signed-off-by: Vinson Leev...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 14 +-
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp |2 ++
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
index 62825a2..a50a51d 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
@@ -250,7 +250,19 @@ lp_disassemble(const void* func)
return;
}
-#if HAVE_LLVM= 0x0300
+#if HAVE_LLVM= 0x0301
+ TargetOptions options;
+#if defined(DEBUG)
+ options.JITEmitDebugInfo = true;
+#endif
+#if defined(PIPE_ARCH_X86)
+ options.StackAlignmentOverride = 4;
+#endif
+#if defined(DEBUG) || defined(PROFILE)
+ options.NoFramePointerElim = true;
+#endif
+ TargetMachine *TM = T-createTargetMachine(Triple, sys::getHostCPUName(),
, options);
+#elif HAVE_LLVM == 0x0300
TargetMachine *TM = T-createTargetMachine(Triple, sys::getHostCPUName(),
);
#else
TargetMachine *TM = T-createTargetMachine(Triple, );
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 41a..fe7616b 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -69,6 +69,7 @@
lp_register_oprofile_jit_event_listener(LLVMExecutionEngineRef EE)
extern C void
lp_set_target_options(void)
{
+#if HAVE_LLVM= 0x0300
#if defined(DEBUG)
#if HAVE_LLVM= 0x0207
llvm::JITEmitDebugInfo = true;
@@ -102,6 +103,7 @@ lp_set_target_options(void)
#if 0
llvm::UnsafeFPMath = true;
#endif
+#endif /* HAVE_LLVM= 0x0300 */
#if HAVE_LLVM 0x0209
/*
I haven't looked at LLVM 3.1-svn yet, but this seems OK to me.
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43879] (xorg-server 1.11.2-2, xf86-video-ati 6.14.3-1 or git, qt 4.7.4) black pixels instead of transparency from PNGs
https://bugs.freedesktop.org/show_bug.cgi?id=43879 --- Comment #3 from Iwan Gabovitch qubo...@gmail.com 2011-12-16 07:57:09 UTC --- What the.. I can not reproduce the display bug any more after replacing catalyst with xf86-video-ati again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43879] (xorg-server 1.11.2-2, xf86-video-ati 6.14.3-1 or git, qt 4.7.4) black pixels instead of transparency from PNGs
https://bugs.freedesktop.org/show_bug.cgi?id=43879 --- Comment #4 from Iwan Gabovitch qubo...@gmail.com 2011-12-16 08:01:57 PST --- Here are some logs though: http://qubodup.net/hw/catalyst_Xorg.0.log http://qubodup.net/hw/catalyst_dmesg.txt http://qubodup.net/hw/catalyst_glxinfo.txt http://qubodup.net/hw/catalyst_lspci.txt http://qubodup.net/hw/radeon_Xorg.0.log http://qubodup.net/hw/radeon_dmesg.txt http://qubodup.net/hw/radeon_glxinfo.txt http://qubodup.net/hw/radeon_lspci.txt 01:00.0 VGA compatible controller: ATI Technologies Inc Juniper [Radeon HD 5700 Series/6750] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Implement bounds checking for transform feedback output.
On 15 December 2011 15:20, Kenneth Graunke kenn...@whitecape.org wrote:
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
src/mesa/drivers/dri/i965/brw_context.h |3 ++
src/mesa/drivers/dri/i965/brw_gs_emit.c | 10
src/mesa/drivers/dri/i965/gen6_sol.c| 38
+++
4 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 7d360b0..fd60853 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -117,6 +117,7 @@ static void brwInitDriverFunctions( struct
dd_function_table *functions )
brw_init_queryobj_functions(functions);
functions-PrepareExecBegin = brwPrepareExecBegin;
+ functions-BeginTransformFeedback = brw_begin_transform_feedback;
functions-EndTransformFeedback = brw_end_transform_feedback;
}
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 8e52488..20623d4 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1073,6 +1073,9 @@ brw_fprog_uses_noperspective(const struct
gl_fragment_program *fprog);
/* gen6_sol.c */
void
+brw_begin_transform_feedback(struct gl_context *ctx,
+struct gl_transform_feedback_object *obj);
+void
brw_end_transform_feedback(struct gl_context *ctx,
struct gl_transform_feedback_object *obj);
diff --git a/src/mesa/drivers/dri/i965/brw_gs_emit.c
b/src/mesa/drivers/dri/i965/brw_gs_emit.c
index 72d4eca..5dd3734 100644
--- a/src/mesa/drivers/dri/i965/brw_gs_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_gs_emit.c
@@ -352,6 +352,15 @@ gen6_sol_program(struct brw_gs_compile *c, struct
brw_gs_prog_key *key,
*/
brw_MOV(p, get_element_ud(c-reg.header, 5),
get_element_ud(c-reg.SVBI, 0));
+
+ /* Make sure that the buffers have enough room for all the
vertices. */
+ brw_ADD(p, get_element_ud(c-reg.temp, 0),
+get_element_ud(c-reg.SVBI, 0), brw_imm_ud(num_verts));
+ brw_CMP(p, vec1(brw_null_reg()), BRW_CONDITIONAL_L,
+get_element_ud(c-reg.temp, 0),
+get_element_ud(c-reg.SVBI, 4));
+ brw_IF(p, BRW_EXECUTE_1);
+
/* For each vertex, generate code to output each varying using the
* appropriate binding table entry.
*/
@@ -392,6 +401,7 @@ gen6_sol_program(struct brw_gs_compile *c, struct
brw_gs_prog_key *key,
get_element_ud(c-reg.header, 5), brw_imm_ud(1));
}
}
+ brw_ENDIF(p);
/* Now, reinitialize the header register from R0 to restore the
parts of
* the register that we overwrote while streaming out transform
feedback
diff --git a/src/mesa/drivers/dri/i965/gen6_sol.c
b/src/mesa/drivers/dri/i965/gen6_sol.c
index b11bce2..56d4a6a 100644
--- a/src/mesa/drivers/dri/i965/gen6_sol.c
+++ b/src/mesa/drivers/dri/i965/gen6_sol.c
@@ -26,6 +26,7 @@
* Code to initialize the binding table entries used by transform feedback.
*/
+#include main/macros.h
#include brw_context.h
#include intel_buffer_objects.h
#include intel_batchbuffer.h
@@ -101,6 +102,43 @@ const struct brw_tracked_state gen6_sol_surface = {
};
void
+brw_begin_transform_feedback(struct gl_context *ctx,
+struct gl_transform_feedback_object *obj)
+{
+ struct intel_context *intel = intel_context(ctx);
+ const struct gl_shader_program *vs_prog =
+ ctx-Shader.CurrentVertexProgram;
+ const struct gl_transform_feedback_info *linked_xfb_info =
+ vs_prog-LinkedTransformFeedback;
+ struct gl_transform_feedback_object *xfb_obj =
+ ctx-TransformFeedback.CurrentObject;
+
+ unsigned max_index = 0x;
+
+ /* Compute the maximum number of vertices that we can write without
+* overflowing any of the buffers currently being used for feedback.
+*/
+ for (int i = 0; i MAX_FEEDBACK_ATTRIBS; ++i) {
Minor nit: MAX_FEEDBACK_ATTRIBS (32) is the correct bound for generic Mesa
code, but in i965, we only support 4 buffers, so this loop bound should
probably be BRW_MAX_SOL_BUFFERS.
+ unsigned stride = linked_xfb_info-BufferStride[i];
+
+ /* Skip any inactive buffers, which have a stride of 0. */
+ if (stride == 0)
+continue;
+
+ unsigned max_for_this_buffer = xfb_obj-Size[i] / (4 * stride);
+ max_index = MIN2(max_index, max_for_this_buffer);
+ }
+
+ /* Initialize the SVBI 0 register to zero and set the maximum index. */
+ BEGIN_BATCH(4);
+ OUT_BATCH(_3DSTATE_GS_SVB_INDEX 16 | (4 - 2));
+ OUT_BATCH(0); /* SVBI 0 */
+ OUT_BATCH(0);
+ OUT_BATCH(max_index);
+ ADVANCE_BATCH();
+}
+
+void
brw_end_transform_feedback(struct gl_context *ctx,
Re: [Mesa-dev] vertex array regression
Brian,
On Thursday, December 15, 2011 22:36:24 you wrote:
I found the problem. It's this chunk in vbo_context.c:
[...]
For fixed function, the point is to simply place the per-vertex
material attributes in the generic attribute arrays. There are 12
such material attributes. So there's four slots left over.
Yep, and these map with the old scheme to often used attributes like the
vertex position.
Thanks to your hints I believe that I found the underlying problem:
If you look at the resulting bitmasks for the enabled vertex program inputs in
isosurf by commenting out the printf in _mesa_set_varying_vp_inputs you will
see surprising results with the old numbering. The current checked in
numbering looks much more plausible.
It turns out that this wrong varying_vp_inputs mask sets the _NEW_ARRAY bit
through _mesa_set_varying_vp_inputs. That in turn cares for some (by now in my
debug session untracked) state updates. This helps in the end for isosurf.
If the varying_vp_inputs mask looks plausible the _NEW_ARRAY bit is not set
and isosurf fails.
This also explaines that only draw paths going through vbo_exec_array.c are
affected, since the imm variants in vbo_exec_{safe,draw} always set the
_NEW_ARRAY bit on any draw.
So for me this change
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index a6e41e9..a2851c4 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -446,7 +446,7 @@ recalculate_input_bindings(struct gl_context *ctx)
* to revalidate vertex arrays. Not marking the state as dirty also
* improves performance (quite significantly in some apps).
*/
- if (!ctx-VertexProgram._MaintainTnlProgram)
+ /* if (!ctx-VertexProgram._MaintainTnlProgram) */
ctx-NewState |= _NEW_ARRAY;
break;
makes isosurf work reliable.
I will prepare a patch for that.
Greetings
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: make update_fbo_texture() non-static
On 12/15/2011 04:46 PM, Brian Paul wrote:
Nice refactor. For the series,
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
We'll call this from the mipmap generation code.
---
src/mesa/main/teximage.c | 11 ++-
src/mesa/main/teximage.h |4
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 8a002b6..eccc0fd 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2205,9 +2205,10 @@ check_rtt_cb(GLuint key, void *data, void *userData)
* in size or format since that effects FBO completeness.
* Any FBOs rendering into the texture must be re-validated.
*/
-static void
-update_fbo_texture(struct gl_context *ctx, struct gl_texture_object *texObj,
- GLuint face, GLuint level)
+void
+_mesa_update_fbo_texture(struct gl_context *ctx,
+ struct gl_texture_object *texObj,
+ GLuint face, GLuint level)
{
/* Only check this texture if it's been marked as RenderToTexture */
if (texObj-_RenderToTexture) {
@@ -2502,7 +2503,7 @@ teximage(struct gl_context *ctx, GLuint dims,
check_gen_mipmap(ctx, target, texObj, level);
- update_fbo_texture(ctx, texObj, face, level);
+ _mesa_update_fbo_texture(ctx, texObj, face, level);
/* state update */
texObj-_Complete = GL_FALSE;
@@ -2844,7 +2845,7 @@ copyteximage(struct gl_context *ctx, GLuint dims,
check_gen_mipmap(ctx, target, texObj, level);
-update_fbo_texture(ctx, texObj, face, level);
+_mesa_update_fbo_texture(ctx, texObj, face, level);
/* state update */
texObj-_Complete = GL_FALSE;
diff --git a/src/mesa/main/teximage.h b/src/mesa/main/teximage.h
index 9cc7d5a..d756646 100644
--- a/src/mesa/main/teximage.h
+++ b/src/mesa/main/teximage.h
@@ -80,6 +80,10 @@ _mesa_choose_texture_format(struct gl_context *ctx,
GLenum target, GLint level,
GLenum internalFormat, GLenum format, GLenum
type);
+extern void
+_mesa_update_fbo_texture(struct gl_context *ctx,
+ struct gl_texture_object *texObj,
+ GLuint face, GLuint level);
extern void
_mesa_clear_texture_image(struct gl_context *ctx,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] linker: fix strdup memory leak
On 12/14/2011 11:26 PM, Pekka Paalanen wrote: string_to_uint_map::put() already does a strdup() for the key argument, so we leak the memory allocated by strdup() in link_uniforms.cpp. Remove the extra strdup(), fixes a few Valgrind detected leaks. Have you run piglit on this? I seem to recall adding the extra strdup for a reason. The hash table keeps a copy of the key pointer passed to it, and the underlying object may be deleted before the hash table is deleted. This can happen if the back-end optimizes some uniforms away after the linker has generated the list of active uniforms. I'm pretty sure there were one or two test cases that hit this on i965. Signed-off-by: Pekka Paalanenppaala...@gmail.com --- src/glsl/link_uniforms.cpp |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp index c7de480..f6094d7 100644 --- a/src/glsl/link_uniforms.cpp +++ b/src/glsl/link_uniforms.cpp @@ -174,8 +174,7 @@ private: if (this-map-get(id, name)) return; - char *key = strdup(name); - this-map-put(this-num_active_uniforms, key); + this-map-put(this-num_active_uniforms, name); /* Each leaf uniform occupies one entry in the list of active * uniforms. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: free gl_uniform_storage::name
On 12/14/2011 11:26 PM, Pekka Paalanen wrote:
parcel_out_uniform_storage::visit_field() assigns a strdup()'d string
into gl_uniform_storage::name, but it is never freed.
Free gl_uniform_storage::name, fixes some Valgrind reported memory
leaks.
Signed-off-by: Pekka Paalanenppaala...@gmail.com
---
src/mesa/main/shaderobj.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 454007f..2275430 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -39,6 +39,7 @@
#include program/prog_parameter.h
#include program/hash_table.h
#include ralloc.h
+#include ../glsl/ir_uniform.h
/**/
/*** Shader object functions***/
@@ -276,6 +277,9 @@ _mesa_clear_shader_program_data(struct gl_context *ctx,
struct gl_shader_program *shProg)
{
if (shProg-UniformStorage) {
+ unsigned i;
+ for (i = 0; i shProg-NumUserUniformStorage; ++i)
+ free(shProg-UniformStorage[i].name);
ralloc_free(shProg-UniformStorage);
This only plugs one of the leaks. If you write a test case that relinks
a program, the ralloc_free(UniformStorage) at the top of
link_assign_uniform_locations will also leak.
Since the rest of the uniform data is already tracked using ralloc, a
better solution is to replace the strdup with ralloc_strdup. Looking in
link_uniforms, it seems the names are allocated (via
count_uniform_size::process) before the UniformStorage is allocated (via
rzalloc_array on line 336). I believe the right answer is:
- Add a 'void *mem_ctx' to the count_uniform_size constructor, and
store it in the object.
- Use the mem_ctx in the ralloc_strdup call that will replace the
existing strdup call.
- Pass prog to the count_uniform_size constructor as the mem_ctx.
- At the very end of link_assign_uniform_locations, loop over each
entry in UniformStorage and ralloc_reparent the name field to be owned
by UniformStorage. This will prevent transient leaks if a program is
relinked (due to the ralloc_free at the top of
link_assign_uniform_locations).
shProg-NumUserUniformStorage = 0;
shProg-UniformStorage = NULL;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43896] New: Mesa assembly breaks Super Meat Boy, Shank
https://bugs.freedesktop.org/show_bug.cgi?id=43896 Bug #: 43896 Summary: Mesa assembly breaks Super Meat Boy, Shank Classification: Unclassified Product: Mesa Version: 7.11 Platform: Other URL: http://www.humblebundle.com/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: s...@whiz.se The games Super Meat Boy and Shank from The Humble Indie Bundle does not work correctly when the assembler optimizations in Mesa is used. Super Meat Boy will either give an error MojoShader compile failed or segfault. Shank runs, but does not render correctly or, using git master, will segfault on start. All of these problems go away if Mesa is compiled with the --disable-asm flag. Both the error message from the game and the backtraces from the segfaults point to the games themselves so I'm not sure if this is Mesa exposing a bug in the games or the other way around. I did however notice that Fedora explicitly makes use of the flag to turn the assembly off with this comment i do not have words for how much the assembly dispatch code infuriates me. A bug report for the games is filed here: https://bugzilla.icculus.org/show_bug.cgi?id=5315 System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.3 -- xserver: 1.11.2.902 -- mesa: -- drm: 2.4.29 -- kernel: 3.1.5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] i965: Add separate stencil/HiZ setup for MESA_FORMAT_Z32_FLOAT_X24S8.
On 12/15/2011 08:43 PM, Eric Anholt wrote:
This is a little more unusual than the separate MESA_FORMAT_S8_Z24
support, because in addition to storing the real stencil data in a
MESA_FORMAT_S8 miptree, we also make the Z miptree be
MESA_FORMAT_Z32_FLOAT instead of the requested format.
Reviewed-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_misc_state.c |2 +-
src/mesa/drivers/dri/i965/brw_vtbl.c |2 +
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 31 +--
3 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 8a6a694..ad49c8f 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -216,7 +216,7 @@ brw_depthbuffer_format(struct brw_context *brw)
if (!drb)
return BRW_DEPTHFORMAT_D32_FLOAT;
- switch (drb-Base.Format) {
+ switch (drb-mt-format) {
case MESA_FORMAT_Z16:
return BRW_DEPTHFORMAT_D16_UNORM;
case MESA_FORMAT_Z32_FLOAT:
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index bc76ec2..d348806 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -202,6 +202,8 @@ static bool brw_is_hiz_depth_format(struct intel_context
*intel,
return false;
switch (format) {
+ case MESA_FORMAT_Z32_FLOAT:
+ case MESA_FORMAT_Z32_FLOAT_X24S8:
case MESA_FORMAT_X8_Z24:
case MESA_FORMAT_S8_Z24:
return true;
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 0d49fec..e0f9632 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -89,9 +89,6 @@ intel_miptree_create_internal(struct intel_context *intel,
mt-compressed = compress_byte ? 1 : 0;
mt-refcount = 1;
- intel_get_texture_alignment_unit(intel, format,
- mt-align_w,mt-align_h);
-
if (target == GL_TEXTURE_CUBE_MAP) {
assert(depth0 == 1);
mt-depth0 = 6;
@@ -109,16 +106,6 @@ intel_miptree_create_internal(struct intel_context *intel,
mt-cpp = 2;
}
-#ifdef I915
- (void) intel;
- if (intel-is_945)
- i945_miptree_layout(mt);
- else
- i915_miptree_layout(mt);
-#else
- brw_miptree_layout(intel, mt);
-#endif
-
if (_mesa_is_depthstencil_format(_mesa_get_format_base_format(format))
(intel-must_use_separate_stencil ||
(intel-has_separate_stencil
@@ -142,12 +129,28 @@ intel_miptree_create_internal(struct intel_context *intel,
*/
if (mt-format == MESA_FORMAT_S8_Z24) {
mt-format = MESA_FORMAT_X8_Z24;
+ } else if (mt-format == MESA_FORMAT_Z32_FLOAT_X24S8) {
+mt-format = MESA_FORMAT_Z32_FLOAT;
+mt-cpp = 4;
} else {
-_mesa_problem(Unknown format %s in separate stencil\n,
+_mesa_problem(NULL, Unknown format %s in separate stencil mt\n,
_mesa_get_format_name(mt-format));
}
}
+ intel_get_texture_alignment_unit(intel, mt-format,
+ mt-align_w,mt-align_h);
+
+#ifdef I915
+ (void) intel;
+ if (intel-is_945)
+ i945_miptree_layout(mt);
+ else
+ i915_miptree_layout(mt);
+#else
+ brw_miptree_layout(intel, mt);
+#endif
+
Did this patch get at least some touch testing on i915? None of the
functions that (now) get called first should have any dependency on on
*_miptree_layout on i915, but still.
return mt;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Implement bounds checking for transform feedback output.
On 12/16/2011 10:44 AM, Paul Berry wrote:
On 16 December 2011 10:04, Paul Berry stereotype...@gmail.com
mailto:stereotype...@gmail.com wrote:
On 15 December 2011 15:20, Kenneth Graunke kenn...@whitecape.org
mailto:kenn...@whitecape.org wrote:
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
mailto:kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
src/mesa/drivers/dri/i965/brw_context.h |3 ++
src/mesa/drivers/dri/i965/brw_gs_emit.c | 10
src/mesa/drivers/dri/i965/gen6_sol.c| 38
+++
4 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 7d360b0..fd60853 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -117,6 +117,7 @@ static void brwInitDriverFunctions( struct
dd_function_table *functions )
brw_init_queryobj_functions(functions);
functions-PrepareExecBegin = brwPrepareExecBegin;
+ functions-BeginTransformFeedback =
brw_begin_transform_feedback;
functions-EndTransformFeedback = brw_end_transform_feedback;
}
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 8e52488..20623d4 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1073,6 +1073,9 @@ brw_fprog_uses_noperspective(const struct
gl_fragment_program *fprog);
/* gen6_sol.c */
void
+brw_begin_transform_feedback(struct gl_context *ctx,
+struct gl_transform_feedback_object
*obj);
+void
brw_end_transform_feedback(struct gl_context *ctx,
struct gl_transform_feedback_object
*obj);
diff --git a/src/mesa/drivers/dri/i965/brw_gs_emit.c
b/src/mesa/drivers/dri/i965/brw_gs_emit.c
index 72d4eca..5dd3734 100644
--- a/src/mesa/drivers/dri/i965/brw_gs_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_gs_emit.c
@@ -352,6 +352,15 @@ gen6_sol_program(struct brw_gs_compile *c,
struct brw_gs_prog_key *key,
*/
brw_MOV(p, get_element_ud(c-reg.header, 5),
get_element_ud(c-reg.SVBI, 0));
+
+ /* Make sure that the buffers have enough room for all
the vertices. */
+ brw_ADD(p, get_element_ud(c-reg.temp, 0),
+get_element_ud(c-reg.SVBI, 0),
brw_imm_ud(num_verts));
+ brw_CMP(p, vec1(brw_null_reg()), BRW_CONDITIONAL_L,
+get_element_ud(c-reg.temp, 0),
+get_element_ud(c-reg.SVBI, 4));
+ brw_IF(p, BRW_EXECUTE_1);
+
Whoops, one other correction. There's an off-by-one error--this should
be BRW_CONDITIONAL_LE.
For example, let's say we're outputting triangles, the transform
feedback buffer is large enough to hold 6 vertices, and we've output 3
vertices already. In that case num_verts is 3, SVBI.0 is 3, and SVBI.4
is 6. The above logic compares SVBI.0 + num_verts SVBI.4 (6 6), so
it concludes that there isn't room for the second triangle. It should
be computing SVBI.0 + num_verts = SVBI.4 (6 = 6), because there is
just barely room for the second triangle.
Do we have piglit test cases for these edge conditions? If we don't, we
need them. :)
/* For each vertex, generate code to output each varying
using the
* appropriate binding table entry.
*/
@@ -392,6 +401,7 @@ gen6_sol_program(struct brw_gs_compile *c,
struct brw_gs_prog_key *key,
get_element_ud(c-reg.header, 5),
brw_imm_ud(1));
}
}
+ brw_ENDIF(p);
/* Now, reinitialize the header register from R0 to
restore the parts of
* the register that we overwrote while streaming out
transform feedback
diff --git a/src/mesa/drivers/dri/i965/gen6_sol.c
b/src/mesa/drivers/dri/i965/gen6_sol.c
index b11bce2..56d4a6a 100644
--- a/src/mesa/drivers/dri/i965/gen6_sol.c
+++ b/src/mesa/drivers/dri/i965/gen6_sol.c
@@ -26,6 +26,7 @@
* Code to initialize the binding table entries used by
transform feedback.
*/
+#include main/macros.h
#include brw_context.h
#include intel_buffer_objects.h
#include intel_batchbuffer.h
@@ -101,6 +102,43 @@ const struct brw_tracked_state
gen6_sol_surface = {
};
void
[Mesa-dev] [Bug 43896] Mesa assembly breaks Super Meat Boy, Shank
https://bugs.freedesktop.org/show_bug.cgi?id=43896 mercutio22 mnemon...@posthocergopropterhoc.net changed: What|Removed |Added CC||mnemonico@posthocergopropte ||rhoc.net -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Set _NEW_ARRAY flag on rebind in any case.
Hi, attached is a change that fixes a problem with the isosurf mesa demo. Please review. Mathias From ce63927e24df800ab6c89554ae9b2096cd79122a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@web.de Date: Fri, 16 Dec 2011 20:16:52 +0100 Subject: [PATCH] mesa: Set _NEW_ARRAY flag on rebind in any case. Remove the special case, not seting the _NEW_ARRAY flag for !ctx-VertexProgram._MaintainTnlProgram in vbo_exec_array.c::recalculate_input_bindings. This fixes a problem with isosurf that was exposed by the recent array object changes. Signed-off-by: Mathias Froehlich mathias.froehl...@web.de --- src/mesa/vbo/vbo_exec_array.c | 12 +--- 1 files changed, 1 insertions(+), 11 deletions(-) diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c index a6e41e9..133ea0a 100644 --- a/src/mesa/vbo/vbo_exec_array.c +++ b/src/mesa/vbo/vbo_exec_array.c @@ -440,14 +440,6 @@ recalculate_input_bindings(struct gl_context *ctx) inputs[VERT_ATTRIB_GENERIC(i)] = vbo-generic_currval[i]; const_inputs |= VERT_BIT_GENERIC(i); } - - /* There is no need to make _NEW_ARRAY dirty here for the TnL program, - * because it already takes care of invalidating the state necessary - * to revalidate vertex arrays. Not marking the state as dirty also - * improves performance (quite significantly in some apps). - */ - if (!ctx-VertexProgram._MaintainTnlProgram) - ctx-NewState |= _NEW_ARRAY; break; case VP_NV: @@ -474,8 +466,6 @@ recalculate_input_bindings(struct gl_context *ctx) inputs[VERT_ATTRIB_GENERIC(i)] = vbo-generic_currval[i]; const_inputs |= VERT_BIT_GENERIC(i); } - - ctx-NewState |= _NEW_ARRAY; break; case VP_ARB: @@ -514,10 +504,10 @@ recalculate_input_bindings(struct gl_context *ctx) } inputs[VERT_ATTRIB_GENERIC0] = inputs[0]; - ctx-NewState |= _NEW_ARRAY; break; } + ctx-NewState |= _NEW_ARRAY; _mesa_set_varying_vp_inputs( ctx, VERT_BIT_ALL (~const_inputs) ); } -- 1.7.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] R600g LLVM shader backend
On Thu, 2011-12-15 at 10:41 -0800, Jose Fonseca wrote: - Original Message - On Mon, 2011-12-12 at 07:05 -0800, Jose Fonseca wrote: - Original Message - Hi, I have just pushed a branch containing an LLVM shader backend for r600g to my personal git repo: http://cgit.freedesktop.org/~tstellar/mesa/ r600g-llvm-shader Hi Tom, This is pretty cool stuff. The fact that you have a similar passing rate to the existing compiler makes it quite remarkable. I was aware of several closed/open-source projects to develop GPU backends for LLVM, and LunarG made a middle end, but this is the first working OpenGL stack based on a LLVM GPU backend that I'm aware. There are three main components to this branch: 1. A TGSI-LLVM converter (commit ec9bb644cf7dde055c6c3ee5b8890a2d367337e5) The goal of this converter is to give all gallium drivers a convenient way to convert from TGSI to LLVM. The interface is still evolving, and I'm interested in getting some feedback for it. The interface looks a good start, but I'd like it to be even more overridable. I don't even think there's anything GPU specific there -- I also had some plans to do TGSI translation in llvmpipe in two stages: first TGSI - high-level LLVM IR w/ custom gallivm/tgsi intrinsics - low-level LLVM IR w/ x86 SIMD instrinsincs, to allow optimizations and other decisions to happen at a higher level, before starting to emit lower-level code. What else would you like to see overridable? I'd like that all LLVM - TGSI translators (your new one, llvmpipe's TGSI - aos, llvmpipe's TGSI - SOA) shared a common hierarchy, so all the things they do different needs to be pluggable / overridable. But I'd need to look in more detail to give a precise list. Ok, this makes sense. I think the important things to have be plugable are load and stores to special register files (i.e everything besides TGSI_FILE_TEMPORARY) and also the conversion of each TGSI_OPCODE to llvm IR. I think it might be nice to map TGSI opcodes to C functions rather than intrinsic strings. What do you mean by C functions? What I meant was instead of passing an intrinsic to the TGSI - LLVM converter as a char * and saying convert TGSI_OPCODE_* to this intrinsic, we should pass function pointers, that get called for each TGSI_OPCODE_* conversion. So I'd like us to have a flexible hierarchy of TGSI translators that can be shared for GPU/CPUs alike. BTW, I'd prefer that all reusable Gallium+LLVM code (be it meant for GPU or CPU) lives in src/gallium/auxiliary/gallivm , as it make code maintenance and build integration simpler. So tgsi_llvm.c should be moved into gallivm. Also, beware that the ability to build core gallium/mesa without LLVM must be preserved. (Having particular drivers to have hard dependencies on LLVM is of course at discretion of drivers developers though.) 2. Changes to gallivm so that code can be shared between it and the TGSI-LLVM converter. These changes are attached, please review. I'll review them separately. Been busy days. Still no time to go through them in detail... Also, maybe it would make sense to have amdil backend distributed separately from mesa, as it looks like a component that has other consumers beyond mesa/gallium/r600g, right? Eventually, the AMDIL backend will be distributed as a part of llvm [1], but we still have a lot of work to do to make that happen. The r600g backend is basically a subclass of the AMDIL backend, so if the AMDIL backend is in LLVM the r600g backend would probably have to be too. I think it must be possible to have LLVM backends / passes out of the tree. Anyway, it is a detail. Why is the result code worse: due to limitations in the assembler, in the AMDIL LLVM backend, or in LLVM itself? I guess it's due to limitations in the assembler. When the code is translated from TGSI, the vector instructions fit much better into the VLIW architecture, so the lack of a proper assembler is not as noticeable, but the r600g LLVM backend assumes non-VLIW hardware, which makes the lack of a good assembler really noticeable. I see. What are the state trackers that you envision this will use? (e.g., Are you targeting clover? do you hope this will be the default compiler backend for Mesa? Or is Mesa/Gallium just a way to test AMDIL backend?) For r600g we are targeting clover, but future chip generations will use LLVM for all state trackers. That sounds great! I'm also interested in your general opinion on using LLVM for GPU. The thing that was most difficult for me to model with LLVM was preloading values (e.g. shader inputs) into registers. I had to try a few different ways of implementing this before I got it
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 16.12.2011 19:27, Ian Romanick wrote: On 12/13/2011 05:08 PM, Christoph Bumiller wrote: On 12/14/2011 12:58 AM, Ian Romanick wrote: On 12/13/2011 01:25 PM, Jose Fonseca wrote: - Original Message - On 12/13/2011 03:09 PM, Jose Fonseca wrote: - Original Message - On 12/13/2011 12:26 PM, Bryan Cain wrote: On 12/13/2011 02:11 PM, Jose Fonseca wrote: - Original Message - This is an updated version of the patch set I sent to the list a few hours ago. There is now a TGSI property called TGSI_PROPERTY_NUM_CLIP_DISTANCES that drivers can use to determine how many of the 8 available clip distances are actually used by a shader. Can't the info in TGSI_PROPERTY_NUM_CLIP_DISTANCES be easily derived from the shader, and queried through src/gallium/auxiliary/tgsi/tgsi_scan.h ? No. The clip distances can be indirectly addressed (there are up to 2 of them in vec4 form for a total of 8 floats), which makes it impossible to determine which ones are used by analyzing the shader. The description is almost complete. :) The issue is that the shader may declare out float gl_ClipDistance[4]; the use non-constant addressing of the array. The compiler knows that gl_ClipDistance has at most 4 elements, but post-hoc analysis would not be able to determine that. Often the fixed-function hardware (see below) needs to know which clip distance values are actually written. But don't all the clip distances written by the shader need to be declared? E.g.: DCL OUT[0], CLIPDIST[0] DCL OUT[1], CLIPDIST[1] DCL OUT[2], CLIPDIST[2] DCL OUT[3], CLIPDIST[3] therefore a trivial analysis of the declarations convey that? No. Clip distance is an array of up to 8 floats in GLSL, but it's represented in the hardware as 2 vec4s. You can tell by analyzing the declarations whether there are more than 4 clip distances in use, but not which components the shader writes to. TGSI_PROPERTY_NUM_CLIP_DISTANCES is the number of components in use, not the number of full vectors. Lets imagine out float gl_ClipDistance[6]; Each a clip distance is a scalar float. Either all hardware represents the 8 clip distances as two 4 vectors, and we do: DCL OUT[0].xywz, CLIPDIST[0] DCL OUT[1].xy, CLIPDIST[1] using the full range of struct tgsi_declaration::UsageMask [1] or we represent them as as scalars: DCL OUT[0].x, CLIPDIST[0] DCL OUT[1].x, CLIPDIST[1] DCL OUT[2].x, CLIPDIST[2] DCL OUT[3].x, CLIPDIST[3] DCL OUT[4].x, CLIPDIST[4] DCL OUT[5].x, CLIPDIST[5] If indirect addressing is allowed as I read bore, then maybe the later is better. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. GeForce8+ = scalar architecture, no vectors, addresses are byte based, can access individual components just fine. Something like: gl_ClipDistance[i - 12] = some_value; DCL OUT[0].xyzw, POSITION DCL OUT[1-8].x, CLIPDIST[0-7] MOV OUT1[ADDR[0].x - 12].x, TEMP[0]. * ** * - tgsi_dimension.Index specifying the base address by referencing a declaration ** - tgsi_src_register.Index is the only way I see to make this work nicely on all hardware. (This is also needed if OUT[i] and OUT[i + 1] cannot be assigned to contiguous hardware resources because of semantic.) For constrained hardware the driver can build the clunky c := ADDR[0].x % 4 i := ADDR[0].x / 4 IF [c == 0] MOV OUT[i].x, TEMP[0]. ELSE IF [c == 1] MOV OUT[i].y, TEMP[0]. ELSE IF [c == 2] MOV OUT[i].z, TEMP[0]. ELSE MOV OUT[i].w, TEMP[0]. ENDIF itself. Doing it at that low-level has a number of significant drawbacks. The worst is that it's long after any high-level optimizations can be done on the code. It also means that it has to be reimplemented in every driver that needs. This really belongs at a higher level in the code. Note that lowering pass that already exists changes the accesses to 'float gl_ClipDistance[8]' to 'vec4 gl_ClipDistanceMESA[2]'. Is there a compelling reason to not do the same at the lower level? Of course, we can add a CAP/option to let the driver choose whether it wants a TGSI array or some pass at a higher level to lower the assignment. I'd just like TGSI to be extended to be able to express what's *actually* going on so I can produce my simple: shl $r0, constbuf0[0], 2 store out[$r0+0x270], $r1 (0x270-0x28c are fixed locations for clip distances) for gl_ClipDistance[uniform int i] = some_value; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/13] Big pile of client-side GLX fixes
This series of fixes is a direct result of the GLX_EXT_import_context recently committed to piglit. These are all bugs discovered while working on GLX_ARB_create_context and friends. As soon as this series lands, the GLX_ARB_create_context patches will go out. I've already posted a set of GLX_ARB_create_context tests to the piglit list for review. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/13] glx: Don't segfault if xcb_glx_is_direct_reply returns NULL
From: Ian Romanick ian.d.roman...@intel.com NOTE: This is a candidate for the 7.11 branch. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/glx/glxcmds.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c index c8ec9c2..c29bc1c 100644 --- a/src/glx/glxcmds.c +++ b/src/glx/glxcmds.c @@ -594,7 +594,7 @@ __glXIsDirect(Display * dpy, GLXContextID contextID) (c, contextID), NULL); - const Bool is_direct = reply-is_direct ? True : False; + const Bool is_direct = (reply != NULL reply-is_direct) ? True : False; free(reply); return is_direct; -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/13] glx: Don't create a shared context if the other context isn't the same kind
From: Ian Romanick ian.d.roman...@intel.com
Each of the DRI, DRI2, and DRISW backends contain code like the
following in their create-context routine:
if (shareList) {
pcp_shared = (struct dri2_context *) shareList;
shared = pcp_shared-driContext;
}
This assumes that the glx_context *shareList is actually the correct
derived type. However, if shareList was created as an
indirect-rendering context, it will not be the expected type. As a
result, shared will contain garbage. This garbage will be passed to
the driver, and the driver will probably segfault. This can be
observed with the following GLX code:
ctx0 = glXCreateContext(dpy, visinfo, NULL, False);
ctx1 = glXCreateContext(dpy, visinfo, ctx0, True);
Create-context is the only case where this occurs. All other cases
where a context is passed to the backend, it is the 'this' pointer
(i.e., we got to the backend by call something from ctx-vtable).
To work around this, check that the shareList-vtable-destroy method
is the same as the destroy method of the expected type. We could also
check that shareList-vtable matches the vtable or by adding a tag
to glx_context to identify the derived type.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/dri2_glx.c |7 +++
src/glx/dri_glx.c |7 +++
src/glx/drisw_glx.c |7 +++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 553869a..f929fdd 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -185,6 +185,13 @@ dri2_create_context(struct glx_screen *base,
__DRIcontext *shared = NULL;
if (shareList) {
+ /* If the shareList context is not a DRI2 context, we cannot possibly
+ * create a DRI2 context that shares it.
+ */
+ if (shareList-vtable-destroy != dri2_destroy_context) {
+return NULL;
+ }
+
pcp_shared = (struct dri2_context *) shareList;
shared = pcp_shared-driContext;
}
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index 666423a..9365224 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -587,6 +587,13 @@ dri_create_context(struct glx_screen *base,
return NULL;
if (shareList) {
+ /* If the shareList context is not a DRI context, we cannot possibly
+ * create a DRI context that shares it.
+ */
+ if (shareList-vtable-destroy != dri_destroy_context) {
+return NULL;
+ }
+
pcp_shared = (struct dri_context *) shareList;
shared = pcp_shared-driContext;
}
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index fbc6be2..f988eeb 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -382,6 +382,13 @@ drisw_create_context(struct glx_screen *base,
return NULL;
if (shareList) {
+ /* If the shareList context is not a DRISW context, we cannot possibly
+ * create a DRISW context that shares it.
+ */
+ if (shareList-vtable-destroy != drisw_destroy_context) {
+return NULL;
+ }
+
pcp_shared = (struct drisw_context *) shareList;
shared = pcp_shared-driContext;
}
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/13] glx: Fix handling of property list received from the server in glXImportContextEXT
From: Ian Romanick ian.d.roman...@intel.com
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c | 39 +++
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index c29bc1c..345b6dc 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1411,14 +1411,19 @@ _X_EXPORT GLXContext
glXImportContextEXT(Display *dpy, GLXContextID contextID)
{
struct glx_display *priv = __glXInitialize(dpy);
- struct glx_screen *psc;
+ struct glx_screen *psc = NULL;
xGLXQueryContextReply reply;
CARD8 opcode;
struct glx_context *ctx;
int propList[__GLX_MAX_CONTEXT_PROPS * 2], *pProp, nPropListBytes;
+ int numProps;
int i, renderType;
XID share;
struct glx_config *mode;
+ uint32_t fbconfigID = 0;
+ uint32_t visualID = 0;
+ uint32_t screen;
+ Bool got_screen = False;
if (contextID == None || __glXIsDirect(dpy, contextID))
return NULL;
@@ -1463,35 +1468,45 @@ glXImportContextEXT(Display *dpy, GLXContextID
contextID)
UnlockDisplay(dpy);
SyncHandle();
- /* Look up screen first so we can look up visuals/fbconfigs later */
- psc = NULL;
- for (i = 0, pProp = propList; i reply.n; i++, pProp += 2)
- if (pProp[0] == GLX_SCREEN)
-psc = GetGLXScreenConfigs(dpy, pProp[1]);
- if (psc == NULL)
- return NULL;
-
+ numProps = nPropListBytes / (2 * sizeof(propList[0]));
share = None;
mode = NULL;
renderType = 0;
pProp = propList;
- for (i = 0, pProp = propList; i reply.n; i++, pProp += 2)
+ for (i = 0, pProp = propList; i numProps; i++, pProp += 2)
switch (pProp[0]) {
+ case GLX_SCREEN:
+screen = pProp[1];
+got_screen = True;
+break;
case GLX_SHARE_CONTEXT_EXT:
share = pProp[1];
break;
case GLX_VISUAL_ID_EXT:
-mode = glx_config_find_visual(psc-visuals, pProp[1]);
+visualID = pProp[1];
break;
case GLX_FBCONFIG_ID:
-mode = glx_config_find_fbconfig(psc-configs, pProp[1]);
+fbconfigID = pProp[1];
break;
case GLX_RENDER_TYPE:
renderType = pProp[1];
break;
}
+ if (!got_screen)
+ return NULL;
+
+ psc = GetGLXScreenConfigs(dpy, screen);
+ if (psc == NULL)
+ return NULL;
+
+ if (fbconfigID != 0) {
+ mode = glx_config_find_fbconfig(psc-configs, fbconfigID);
+ } else if (visualID != 0) {
+ mode = glx_config_find_visual(psc-visuals, visualID);
+ }
+
if (mode == NULL)
return NULL;
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/13] glx: Don't segfault if glXGetContextIDEXT is pased a NULL context
From: Ian Romanick ian.d.roman...@intel.com
Fixes the piglit test glx-get-context-id.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 345b6dc..c799b36 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1559,7 +1559,7 @@ _X_EXPORT GLXContextID glXGetContextIDEXT(const
GLXContext ctx_user)
{
struct glx_context *ctx = (struct glx_context *) ctx_user;
- return ctx-xid;
+ return (ctx == NULL) ? None : ctx-xid;
}
_X_EXPORT
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/13] glx: Send DestroyContext protocol at the correct times
From: Ian Romanick ian.d.roman...@intel.com
Send the DestroyContext protocol immediately when glXDestroyContext is
called, and never call it when glXFreeContextEXT is called. In both
cases, either destroy the client-side structures or, if the context is
current, set xid to None so that the client-side structures will be
destroyed later.
I believe this restores the behavior of the original SGI code. See
src/glx/x11 around commit 5df82c8. The spec doesn't say anything
about glXDestroyContext not really destroying imported contexts (it
acts like glXFreeContextEXT instead), but that's what the original
code did. Note that glXFreeContextEXT on a non-imported context does
not destroy it either.
Fixes the piglit test glx-free-context.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/dri2_glx.c |3 ---
src/glx/dri_glx.c |3 ---
src/glx/drisw_glx.c|3 ---
src/glx/glxclient.h|3 ---
src/glx/glxcmds.c | 42 +++---
src/glx/indirect_glx.c |3 ---
6 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index f929fdd..a9bcebf 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -120,9 +120,6 @@ dri2_destroy_context(struct glx_context *context)
driReleaseDrawables(pcp-base);
- if (context-xid)
- glx_send_destroy_context(psc-base.dpy, context-xid);
-
if (context-extensions)
XFree((char *) context-extensions);
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index 9365224..3c14ef0 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -516,9 +516,6 @@ dri_destroy_context(struct glx_context * context)
driReleaseDrawables(pcp-base);
- if (context-xid)
- glx_send_destroy_context(psc-base.dpy, context-xid);
-
if (context-extensions)
XFree((char *) context-extensions);
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index f988eeb..1585524 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -253,9 +253,6 @@ drisw_destroy_context(struct glx_context *context)
driReleaseDrawables(pcp-base);
- if (context-xid)
- glx_send_destroy_context(psc-base.dpy, context-xid);
-
if (context-extensions)
XFree((char *) context-extensions);
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index f915426..109206f 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -227,9 +227,6 @@ struct glx_context_vtable {
void * (*get_proc_address)(const char *symbol);
};
-extern void
-glx_send_destroy_context(Display *dpy, XID xid);
-
/**
* GLX state that needs to be kept on the client. One of these records
* exist for each context that has been made current by this client.
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index c799b36..e4d0b12 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -381,7 +381,7 @@ glXCreateContext(Display * dpy, XVisualInfo * vis,
X_GLXCreateContext, renderType, vis-screen);
}
-_X_HIDDEN void
+static void
glx_send_destroy_context(Display *dpy, XID xid)
{
CARD8 opcode = __glXSetupForCommand(dpy);
@@ -405,25 +405,24 @@ glXDestroyContext(Display * dpy, GLXContext ctx)
{
struct glx_context *gc = (struct glx_context *) ctx;
- if (!gc)
+ if (gc == NULL || gc-xid == None)
return;
__glXLock();
+ if (!gc-imported)
+ glx_send_destroy_context(dpy, gc-xid);
+
if (gc-currentDpy) {
/* This context is bound to some thread. According to the man page,
* we should not actually delete the context until it's unbound.
* Note that we set gc-xid = None above. In MakeContextCurrent()
* we check for that and delete the context there.
*/
- if (!gc-imported)
-glx_send_destroy_context(dpy, gc-xid);
gc-xid = None;
- __glXUnlock();
- return;
+ } else {
+ gc-vtable-destroy(gc);
}
__glXUnlock();
-
- gc-vtable-destroy(gc);
}
/*
@@ -1562,9 +1561,30 @@ _X_EXPORT GLXContextID glXGetContextIDEXT(const
GLXContext ctx_user)
return (ctx == NULL) ? None : ctx-xid;
}
-_X_EXPORT
-GLX_ALIAS_VOID(glXFreeContextEXT, (Display *dpy, GLXContext ctx), (dpy, ctx),
- glXDestroyContext);
+_X_EXPORT void
+glXFreeContextEXT(Display *dpy, GLXContext ctx)
+{
+ struct glx_context *gc = (struct glx_context *) ctx;
+
+ if (gc == NULL || gc-xid == None)
+ return;
+
+ /* The GLX_EXT_import_context spec says:
+*
+* glXFreeContext does not free the server-side context information or
+* the XID associated with the server-side context.
+*
+* Don't send any protocol. Just destroy the client-side tracking of the
+* context. Also, only release the context structure if it's not current.
+*/
+ __glXLock();
+ if (gc-currentDpy) {
+ gc-xid = None;
+ } else {
+ gc-vtable-destroy(gc);
+ }
+ __glXUnlock();
+}
[Mesa-dev] [PATCH 06/13] glx: Make __glXSendError available in non-Apple builds
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Jeremy Huddleston jerem...@apple.com
---
src/glx/Makefile |1 +
src/glx/apple/Makefile|2 +-
src/glx/apple/glx_error.c | 67 -
src/glx/apple/glx_error.h | 33 --
src/glx/glx_error.c | 67 +
src/glx/glx_error.h | 33 ++
6 files changed, 102 insertions(+), 101 deletions(-)
delete mode 100644 src/glx/apple/glx_error.c
delete mode 100644 src/glx/apple/glx_error.h
create mode 100644 src/glx/glx_error.c
create mode 100644 src/glx/glx_error.h
diff --git a/src/glx/Makefile b/src/glx/Makefile
index dd96973..183ffb1 100644
--- a/src/glx/Makefile
+++ b/src/glx/Makefile
@@ -15,6 +15,7 @@ SOURCES = \
glxconfig.c \
glxcmds.c \
glxcurrent.c \
+ glx_error.c \
glxext.c \
glxextensions.c \
indirect_glx.c \
diff --git a/src/glx/apple/Makefile b/src/glx/apple/Makefile
index 6868d28..66e6658 100644
--- a/src/glx/apple/Makefile
+++ b/src/glx/apple/Makefile
@@ -39,7 +39,7 @@ SOURCES = \
../compsize.c \
../glxconfig.c \
glx_empty.c \
- glx_error.c \
+ ../glx_error.c \
../glx_pbuffer.c \
../glx_query.c \
../glxcmds.c \
diff --git a/src/glx/apple/glx_error.c b/src/glx/apple/glx_error.c
deleted file mode 100644
index d44a80c..000
--- a/src/glx/apple/glx_error.c
+++ /dev/null
@@ -1,67 +0,0 @@
-/*
- Copyright (c) 2009 Apple 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 following conditions:
-
- The above copyright notice and this permission notice 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
- NONINFRINGEMENT. IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT
- HOLDER(S) 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.
-
- Except as contained in this notice, the name(s) of the above
- copyright holders shall not be used in advertising or otherwise to
- promote the sale, use or other dealings in this Software without
- prior written authorization.
-*/
-#include stdbool.h
-#include assert.h
-#include X11/Xlibint.h
-#include X11/extensions/extutil.h
-#include X11/extensions/Xext.h
-#include glxclient.h
-#include glx_error.h
-
-void
-__glXSendError(Display * dpy, int errorCode, unsigned long resourceID,
- unsigned long minorCode, bool coreX11error)
-{
- struct glx_display *glx_dpy = __glXInitialize(dpy);
- struct glx_context *gc = __glXGetCurrentContext();
- xError error;
-
- assert(glx_dpy);
- assert(gc);
-
- LockDisplay(dpy);
-
- error.type = X_Error;
-
- if (coreX11error) {
- error.errorCode = errorCode;
- }
- else {
- error.errorCode = glx_dpy-codes-first_error + errorCode;
- }
-
- error.sequenceNumber = dpy-request;
- error.resourceID = resourceID;
- error.minorCode = minorCode;
- error.majorCode = gc ? gc-majorOpcode : 0;
-
- _XError(dpy, error);
-
- UnlockDisplay(dpy);
-}
diff --git a/src/glx/apple/glx_error.h b/src/glx/apple/glx_error.h
deleted file mode 100644
index 6ba2f85..000
--- a/src/glx/apple/glx_error.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- Copyright (c) 2009 Apple 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 following conditions:
-
- The above copyright notice and this permission notice 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
- NONINFRINGEMENT. IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT
- HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- WHETHER IN AN ACTION OF CONTRACT, TORT OR
[Mesa-dev] [PATCH 07/13] glx: Make parameter types for __glXSendError match protocol types
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Jeremy Huddleston jerem...@apple.com
---
src/glx/glx_error.c |4 ++--
src/glx/glx_error.h |6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/glx/glx_error.c b/src/glx/glx_error.c
index d44a80c..0855c35 100644
--- a/src/glx/glx_error.c
+++ b/src/glx/glx_error.c
@@ -35,8 +35,8 @@
#include glx_error.h
void
-__glXSendError(Display * dpy, int errorCode, unsigned long resourceID,
- unsigned long minorCode, bool coreX11error)
+__glXSendError(Display * dpy, int_fast8_t errorCode, uint_fast32_t resourceID,
+ uint_fast16_t minorCode, bool coreX11error)
{
struct glx_display *glx_dpy = __glXInitialize(dpy);
struct glx_context *gc = __glXGetCurrentContext();
diff --git a/src/glx/glx_error.h b/src/glx/glx_error.h
index 6ba2f85..19be38b 100644
--- a/src/glx/glx_error.h
+++ b/src/glx/glx_error.h
@@ -27,7 +27,9 @@
prior written authorization.
*/
#include stdbool.h
+#include stdint.h
#include X11/Xlib.h
-void __glXSendError(Display * dpy, int errorCode, unsigned long resourceID,
-unsigned long minorCode, bool coreX11error);
+void __glXSendError(Display * dpy, int_fast8_t errorCode,
+ uint_fast32_t resourceID, uint_fast16_t minorCode,
+ bool coreX11error);
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/13] glx: Generate BadContext when None is passed to glXImportContextEXT
From: Ian Romanick ian.d.roman...@intel.com
Fixes the piglit test glx-import-context-single-process
NOTE: This is a candidate for the 7.11 branch, but it also requires
the previous patch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index e4d0b12..51a76fa 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -37,12 +37,12 @@
#include glapi.h
#include glxextensions.h
#include indirect.h
+#include glx_error.h
#ifdef GLX_DIRECT_RENDERING
#ifdef GLX_USE_APPLEGL
#include apple_glx_context.h
#include apple_glx.h
-#include glx_error.h
#else
#include sys/time.h
#ifdef XF86VIDMODE
@@ -1424,7 +1424,23 @@ glXImportContextEXT(Display *dpy, GLXContextID contextID)
uint32_t screen;
Bool got_screen = False;
- if (contextID == None || __glXIsDirect(dpy, contextID))
+ /* The GLX_EXT_import_context spec says:
+*
+* If contextID does not refer to a valid context, then a BadContext
+* error is generated; if contextID refers to direct rendering
+* context then no error is generated but glXImportContextEXT returns
+* NULL.
+*
+* If contextID is None, generate BadContext on the client-side. Other
+* sorts of invalid contexts will be detected by the server in the
+* __glXIsDirect call.
+*/
+ if (contextID == None) {
+ __glXSendError(dpy, GLXBadContext, contextID, X_GLXIsDirect, false);
+ return NULL;
+ }
+
+ if (__glXIsDirect(dpy, contextID))
return NULL;
opcode = __glXSetupForCommand(dpy);
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/13] glx: Initialize share_xid in CreateContext
From: Ian Romanick ian.d.roman...@intel.com Previously the share_xid was only set in the glXImportContextEXT path, and it was left set to None in all of the other create-context paths. Fixes the piglit test glx-query-context-info-ext. NOTE: This is a candidate for the 7.11 branch. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/glx/glxcmds.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c index 51a76fa..8a1b941 100644 --- a/src/glx/glxcmds.c +++ b/src/glx/glxcmds.c @@ -344,6 +344,7 @@ CreateContext(Display *dpy, int generic_id, struct glx_config *config, UnlockDisplay(dpy); SyncHandle(); + gc-share_xid = shareList ? shareList-xid : None; gc-imported = GL_FALSE; gc-renderType = renderType; -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/13] glx: Explicitly reject servers that only support GLX 1.0
From: Ian Romanick ian.d.roman...@intel.com
__glXInitialize calls AllocAndFetchScreenConfigs.
AllocAndFetchScreenConfigs unconditionally sends a glXQuerySeverString
request to the server. This request is only supported with GLX 1.1 or
later, so we were already implicitly incompatible with GLX 1.0
servers. How many more similar bugs lurk in the code that nobody has
noticed in years?
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxext.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index 8254544..baa2489 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -836,9 +836,12 @@ __glXInitialize(Display * dpy)
dpyPriv-serverGLXvendor = 0x0;
dpyPriv-serverGLXversion = 0x0;
- /* See if the versions are compatible */
+ /* See if the versions are compatible. This GLX implementation does not
+* work with servers that only support GLX 1.0.
+*/
if (!QueryVersion(dpy, dpyPriv-majorOpcode,
-dpyPriv-majorVersion, dpyPriv-minorVersion)) {
+dpyPriv-majorVersion, dpyPriv-minorVersion)
+ || (dpyPriv-majorVersion == 1 dpyPriv-minorVersion 1)) {
Xfree(dpyPriv);
_XUnlockMutex(_Xglobal_lock);
return NULL;
@@ -884,8 +887,7 @@ __glXInitialize(Display * dpy)
return NULL;
}
- if (dpyPriv-majorVersion == 1 dpyPriv-minorVersion = 1)
- __glXClientInfo(dpy, dpyPriv-majorOpcode);
+ __glXClientInfo(dpy, dpyPriv-majorOpcode);
/* Grab the lock again and add the dispay private, unless somebody
* beat us to initializing on this display in the meantime. */
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/13] glx: Remove some extensions that are not, and never will be, supported
From: Ian Romanick ian.d.roman...@intel.com
There are a few unsupported extensions (e.g., the ATI and NV float
extensions) that are still in the list. There is some small chance
that these may be supported some day.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxextensions.c | 11 ---
src/glx/glxextensions.h |9 -
2 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index 0d2888c..de1bce2 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -73,7 +73,6 @@ struct extension_info
static const struct extension_info known_glx_extensions[] = {
{ GLX(ARB_get_proc_address),VER(1,4), Y, N, Y, N },
{ GLX(ARB_multisample), VER(1,4), Y, Y, N, N },
- { GLX(ARB_render_texture), VER(0,0), N, N, N, N },
{ GLX(ATI_pixel_format_float), VER(0,0), N, N, N, N },
#ifdef GLX_USE_APPLEGL
{ GLX(EXT_import_context), VER(0,0), N, N, N, N },
@@ -85,40 +84,30 @@ static const struct extension_info known_glx_extensions[] =
{
{ GLX(EXT_visual_rating), VER(0,0), Y, Y, N, N },
{ GLX(EXT_framebuffer_sRGB),VER(0,0), Y, Y, N, N },
#ifdef GLX_USE_APPLEGL
- { GLX(MESA_agp_offset), VER(0,0), N, N, N, N }, /* Deprecated */
{ GLX(MESA_copy_sub_buffer),VER(0,0), N, N, N, N },
#else
- { GLX(MESA_agp_offset), VER(0,0), N, N, N, Y }, /* Deprecated */
{ GLX(MESA_copy_sub_buffer),VER(0,0), Y, N, N, N },
#endif
{ GLX(MESA_multithread_makecurrent),VER(0,0), Y, N, Y, N },
- { GLX(MESA_pixmap_colormap),VER(0,0), N, N, N, N }, /* Deprecated */
- { GLX(MESA_release_buffers),VER(0,0), N, N, N, N }, /* Deprecated */
#ifdef GLX_USE_APPLEGL
{ GLX(MESA_swap_control), VER(0,0), N, N, N, N },
#else
{ GLX(MESA_swap_control), VER(0,0), Y, N, N, Y },
#endif
{ GLX(NV_float_buffer), VER(0,0), N, N, N, N },
- { GLX(NV_render_depth_texture), VER(0,0), N, N, N, N },
- { GLX(NV_render_texture_rectangle), VER(0,0), N, N, N, N },
#ifdef GLX_USE_APPLEGL
- { GLX(NV_vertex_array_range), VER(0,0), N, N, N, N }, /* Deprecated */
{ GLX(OML_swap_method), VER(0,0), N, N, N, N },
{ GLX(OML_sync_control),VER(0,0), N, N, N, N },
{ GLX(SGI_make_current_read), VER(1,3), N, N, N, N },
{ GLX(SGI_swap_control),VER(0,0), N, N, N, N },
{ GLX(SGI_video_sync), VER(0,0), N, N, N, N },
#else
- { GLX(NV_vertex_array_range), VER(0,0), N, N, N, Y }, /* Deprecated */
{ GLX(OML_swap_method), VER(0,0), Y, Y, N, N },
{ GLX(OML_sync_control),VER(0,0), Y, N, N, Y },
{ GLX(SGI_make_current_read), VER(1,3), Y, N, N, N },
{ GLX(SGI_swap_control),VER(0,0), Y, N, N, N },
{ GLX(SGI_video_sync), VER(0,0), Y, N, N, Y },
#endif
- { GLX(SGIS_blended_overlay),VER(0,0), N, N, N, N },
- { GLX(SGIS_color_range),VER(0,0), N, N, N, N },
#ifdef GLX_USE_APPLEGL
{ GLX(SGIS_multisample),VER(0,0), N, N, N, N },
#else
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index 4fa7a61..fe0e12f 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -35,31 +35,22 @@ enum
{
ARB_get_proc_address_bit = 0,
ARB_multisample_bit,
- ARB_render_texture_bit,
ATI_pixel_format_float_bit,
EXT_visual_info_bit,
EXT_visual_rating_bit,
EXT_import_context_bit,
EXT_framebuffer_sRGB_bit,
- MESA_agp_offset_bit,
MESA_copy_sub_buffer_bit,
MESA_depth_float_bit,
MESA_multithread_makecurrent_bit,
- MESA_pixmap_colormap_bit,
- MESA_release_buffers_bit,
MESA_swap_control_bit,
MESA_swap_frame_usage_bit,
NV_float_buffer_bit,
- NV_render_depth_texture_bit,
- NV_render_texture_rectangle_bit,
- NV_vertex_array_range_bit,
OML_swap_method_bit,
OML_sync_control_bit,
SGI_make_current_read_bit,
SGI_swap_control_bit,
SGI_video_sync_bit,
- SGIS_blended_overlay_bit,
- SGIS_color_range_bit,
SGIS_multisample_bit,
SGIX_fbconfig_bit,
SGIX_pbuffer_bit,
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/13] glx: GLX 1.4 does not require GLX_INTEL_swap_event
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxextensions.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index de1bce2..0558aab 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -128,7 +128,7 @@ static const struct extension_info known_glx_extensions[] =
{
{ GLX(SGIX_visual_select_group),VER(0,0), Y, Y, N, N },
{ GLX(EXT_texture_from_pixmap), VER(0,0), Y, N, N, N },
#endif
- { GLX(INTEL_swap_event),VER(1,4), Y, N, N, N },
+ { GLX(INTEL_swap_event),VER(0,0), Y, N, N, N },
{ NULL }
};
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/13] glx: Remove GLX_USE_APPLEGL cruft in extension string handling
From: Ian Romanick ian.d.roman...@intel.com
All of the extensions require that both libGL and either the server or
the direct rendering driver (or both) enable the extension before it's
advertised. It seems safe to assume that none of the other components
on OS X will enable these extensions, so all the #ifdef blocks here
just clutter the code.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Jeremy Huddleston jerem...@apple.com
---
src/glx/glxextensions.c | 38 ++
1 files changed, 2 insertions(+), 36 deletions(-)
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index 0558aab..819fffc 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -74,60 +74,26 @@ static const struct extension_info known_glx_extensions[] =
{
{ GLX(ARB_get_proc_address),VER(1,4), Y, N, Y, N },
{ GLX(ARB_multisample), VER(1,4), Y, Y, N, N },
{ GLX(ATI_pixel_format_float), VER(0,0), N, N, N, N },
-#ifdef GLX_USE_APPLEGL
- { GLX(EXT_import_context), VER(0,0), N, N, N, N },
- { GLX(EXT_visual_info), VER(0,0), N, N, N, N },
-#else
{ GLX(EXT_import_context), VER(0,0), Y, Y, N, N },
{ GLX(EXT_visual_info), VER(0,0), Y, Y, N, N },
-#endif
{ GLX(EXT_visual_rating), VER(0,0), Y, Y, N, N },
{ GLX(EXT_framebuffer_sRGB),VER(0,0), Y, Y, N, N },
-#ifdef GLX_USE_APPLEGL
- { GLX(MESA_copy_sub_buffer),VER(0,0), N, N, N, N },
-#else
{ GLX(MESA_copy_sub_buffer),VER(0,0), Y, N, N, N },
-#endif
{ GLX(MESA_multithread_makecurrent),VER(0,0), Y, N, Y, N },
-#ifdef GLX_USE_APPLEGL
- { GLX(MESA_swap_control), VER(0,0), N, N, N, N },
-#else
{ GLX(MESA_swap_control), VER(0,0), Y, N, N, Y },
-#endif
{ GLX(NV_float_buffer), VER(0,0), N, N, N, N },
-#ifdef GLX_USE_APPLEGL
- { GLX(OML_swap_method), VER(0,0), N, N, N, N },
- { GLX(OML_sync_control),VER(0,0), N, N, N, N },
- { GLX(SGI_make_current_read), VER(1,3), N, N, N, N },
- { GLX(SGI_swap_control),VER(0,0), N, N, N, N },
- { GLX(SGI_video_sync), VER(0,0), N, N, N, N },
-#else
{ GLX(OML_swap_method), VER(0,0), Y, Y, N, N },
{ GLX(OML_sync_control),VER(0,0), Y, N, N, Y },
{ GLX(SGI_make_current_read), VER(1,3), Y, N, N, N },
{ GLX(SGI_swap_control),VER(0,0), Y, N, N, N },
{ GLX(SGI_video_sync), VER(0,0), Y, N, N, Y },
-#endif
-#ifdef GLX_USE_APPLEGL
- { GLX(SGIS_multisample),VER(0,0), N, N, N, N },
-#else
{ GLX(SGIS_multisample),VER(0,0), Y, Y, N, N },
-#endif
{ GLX(SGIX_fbconfig), VER(1,3), Y, Y, N, N },
-#ifdef GLX_USE_APPLEGL
- { GLX(SGIX_pbuffer),VER(1,3), N, N, N, N },
-#else
{ GLX(SGIX_pbuffer),VER(1,3), Y, Y, N, N },
-#endif
{ GLX(SGIX_swap_barrier), VER(0,0), N, N, N, N },
{ GLX(SGIX_swap_group), VER(0,0), N, N, N, N },
-#ifdef GLX_USE_APPLEGL
- { GLX(SGIX_visual_select_group),VER(0,0), N, N, N, N },
- { GLX(EXT_texture_from_pixmap), VER(0,0), N, N, N, N },
-#else
{ GLX(SGIX_visual_select_group),VER(0,0), Y, Y, N, N },
{ GLX(EXT_texture_from_pixmap), VER(0,0), Y, N, N, N },
-#endif
{ GLX(INTEL_swap_event),VER(0,0), Y, N, N, N },
{ NULL }
};
@@ -608,7 +574,7 @@ __glXCalculateUsableExtensions(struct glx_screen * psc,
* support for GLX 1.3, enable support for the extensions that can be
* emulated as well.
*/
-
+#ifndef GLX_USE_APPLEGL
if (minor_version = 3) {
SET_BIT(server_support, EXT_visual_info_bit);
SET_BIT(server_support, EXT_visual_rating_bit);
@@ -624,7 +590,7 @@ __glXCalculateUsableExtensions(struct glx_screen * psc,
SET_BIT(server_support, EXT_import_context_bit);
}
-
+#endif
/* An extension is supported if the client-side (i.e., libGL) supports
* it and the server supports it. In this case that means that either
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43896] Mesa assembly breaks Super Meat Boy, Shank
https://bugs.freedesktop.org/show_bug.cgi?id=43896 David sidic...@gmail.com changed: What|Removed |Added CC||sidic...@gmail.com -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] Big pile of client-side GLX fixes
On 12/16/11 2:55 PM, Ian Romanick wrote: This series of fixes is a direct result of the GLX_EXT_import_context recently committed to piglit. These are all bugs discovered while working on GLX_ARB_create_context and friends. As soon as this series lands, the GLX_ARB_create_context patches will go out. I've already posted a set of GLX_ARB_create_context tests to the piglit list for review. Series looks good. I got a chuckle out of the GLX 1.0 thing, I'm completely unsurprised that nobody's recently run Mesa against an OpenGL that didn't support texturing. Just how old of an SGI machine would you have to find, anyway. Reviewed-by: Adam Jackson a...@redhat.com - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Implement bounds checking for transform feedback output.
On 16 December 2011 11:09, Ian Romanick i...@freedesktop.org wrote: On 12/16/2011 10:44 AM, Paul Berry wrote: On 16 December 2011 10:04, Paul Berry stereotype...@gmail.com mailto:stereotype441@gmail.**com stereotype...@gmail.com wrote: On 15 December 2011 15:20, Kenneth Graunke kenn...@whitecape.org mailto:kenn...@whitecape.org** wrote: Signed-off-by: Kenneth Graunke kenn...@whitecape.org mailto:kenn...@whitecape.org** --- src/mesa/drivers/dri/i965/brw_**context.c |1 + src/mesa/drivers/dri/i965/brw_**context.h |3 ++ src/mesa/drivers/dri/i965/brw_**gs_emit.c | 10 src/mesa/drivers/dri/i965/**gen6_sol.c| 38 ++**+ 4 files changed, 52 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/**brw_context.c b/src/mesa/drivers/dri/i965/**brw_context.c index 7d360b0..fd60853 100644 --- a/src/mesa/drivers/dri/i965/**brw_context.c +++ b/src/mesa/drivers/dri/i965/**brw_context.c @@ -117,6 +117,7 @@ static void brwInitDriverFunctions( struct dd_function_table *functions ) brw_init_queryobj_functions(**functions); functions-PrepareExecBegin = brwPrepareExecBegin; + functions-**BeginTransformFeedback = brw_begin_transform_feedback; functions-**EndTransformFeedback = brw_end_transform_feedback; } diff --git a/src/mesa/drivers/dri/i965/**brw_context.h b/src/mesa/drivers/dri/i965/**brw_context.h index 8e52488..20623d4 100644 --- a/src/mesa/drivers/dri/i965/**brw_context.h +++ b/src/mesa/drivers/dri/i965/**brw_context.h @@ -1073,6 +1073,9 @@ brw_fprog_uses_noperspective(**const struct gl_fragment_program *fprog); /* gen6_sol.c */ void +brw_begin_transform_feedback(**struct gl_context *ctx, +struct gl_transform_feedback_object *obj); +void brw_end_transform_feedback(**struct gl_context *ctx, struct gl_transform_feedback_object *obj); diff --git a/src/mesa/drivers/dri/i965/**brw_gs_emit.c b/src/mesa/drivers/dri/i965/**brw_gs_emit.c index 72d4eca..5dd3734 100644 --- a/src/mesa/drivers/dri/i965/**brw_gs_emit.c +++ b/src/mesa/drivers/dri/i965/**brw_gs_emit.c @@ -352,6 +352,15 @@ gen6_sol_program(struct brw_gs_compile *c, struct brw_gs_prog_key *key, */ brw_MOV(p, get_element_ud(c-reg.header, 5), get_element_ud(c-reg.SVBI, 0)); + + /* Make sure that the buffers have enough room for all the vertices. */ + brw_ADD(p, get_element_ud(c-reg.temp, 0), +get_element_ud(c-reg.SVBI, 0), brw_imm_ud(num_verts)); + brw_CMP(p, vec1(brw_null_reg()), BRW_CONDITIONAL_L, +get_element_ud(c-reg.temp, 0), +get_element_ud(c-reg.SVBI, 4)); + brw_IF(p, BRW_EXECUTE_1); + Whoops, one other correction. There's an off-by-one error--this should be BRW_CONDITIONAL_LE. For example, let's say we're outputting triangles, the transform feedback buffer is large enough to hold 6 vertices, and we've output 3 vertices already. In that case num_verts is 3, SVBI.0 is 3, and SVBI.4 is 6. The above logic compares SVBI.0 + num_verts SVBI.4 (6 6), so it concludes that there isn't room for the second triangle. It should be computing SVBI.0 + num_verts = SVBI.4 (6 = 6), because there is just barely room for the second triangle. Do we have piglit test cases for these edge conditions? If we don't, we need them. :) This one was caught by piglit tests that I'm hoping to send to the list today. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] Big pile of client-side GLX fixes
On 12/16/2011 12:51 PM, Adam Jackson wrote: On 12/16/11 2:55 PM, Ian Romanick wrote: This series of fixes is a direct result of the GLX_EXT_import_context recently committed to piglit. These are all bugs discovered while working on GLX_ARB_create_context and friends. As soon as this series lands, the GLX_ARB_create_context patches will go out. I've already posted a set of GLX_ARB_create_context tests to the piglit list for review. Series looks good. I got a chuckle out of the GLX 1.0 thing, I'm completely unsurprised that nobody's recently run Mesa against an OpenGL that didn't support texturing. Just how old of an SGI machine would you have to find, anyway. Dunno.. what did they ship in 1992? It looks like GLX 1.2 even was required to support OpenGL 1.1, and OpenGL 1.1 was released in July 1992. Reviewed-by: Adam Jackson a...@redhat.com - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] Big pile of client-side GLX fixes
On 12/16/11 4:28 PM, Ian Romanick wrote: On 12/16/2011 12:51 PM, Adam Jackson wrote: Series looks good. I got a chuckle out of the GLX 1.0 thing, I'm completely unsurprised that nobody's recently run Mesa against an OpenGL that didn't support texturing. Just how old of an SGI machine would you have to find, anyway. Dunno.. what did they ship in 1992? It looks like GLX 1.2 even was required to support OpenGL 1.1, and OpenGL 1.1 was released in July 1992. Crimson Reality Engine was 1993 (if not a bit earlier), and that could texture. So I suspect the only OpenGL 1.0 implementations were in specific point releases of IRIX that people would rapidly have upgraded past; therefore, that literally all copies of those binaries have disappeared from the earth. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Remove unnecessary FLUSH_VERTICES in bind_buffer_range
It isn't necessary to call FLUSH_VERTICES from bind_buffer_range,
because transform feedback buffers are not allowed to be changed when
transform feedback is active.
Thanks to Marek Olšák for pointing out this bug.
---
src/mesa/main/transformfeedback.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index 824f66a..3305613 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -404,7 +404,11 @@ bind_buffer_range(struct gl_context *ctx, GLuint index,
{
struct gl_transform_feedback_object *obj =
ctx-TransformFeedback.CurrentObject;
- FLUSH_VERTICES(ctx, _NEW_TRANSFORM_FEEDBACK);
+
+ /* Note: no need to FLUSH_VERTICES or flag _NEW_TRANSFORM_FEEDBACK, because
+* transform feedback buffers can't be changed while transform feedback is
+* active.
+*/
/* The general binding point */
_mesa_reference_buffer_object(ctx,
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gbm: Introduce a new API gbm_bo_create_from_name.
On 12/15/2011 01:58 AM, zhigang.g...@linux.intel.com wrote:
From: Zhigang Gongzhigang.g...@linux.intel.com
Glamor need a function to create a texture from a
BO allocated by using libdrm directly in DDX layer.
EGL image extension API eglCreateImageKHR does support
this function, but that extension only support one
colore format - ARGB32 which is not sufficent for
us. I discussed this in the mail list and KRH suggest
me to extent GBM to support more color formats should
be better. I took his advice and decide to use gbm
bo to create image. Now before extent the color formats,
I have to add a new API to the create a gbo from a
name. This commit is for that purpose.
Signed-off-by: Zhigang Gongzhigang.g...@linux.intel.com
This patch should be split in two:
- Pull code out of gbm_dri_bo_create into the new function
gbm_dri_match_format.
- Add the new bo_create_from_name interfaces interface.
This allows the gbm_dri_match_format patch and the follow-on patch
(gbm/dri: Added more color formats.) to be committed while discussion
about bo_create_from_name continues.
---
src/gbm/backends/dri/gbm_dri.c | 87 ++--
src/gbm/main/gbm.c | 14 ++
src/gbm/main/gbm.h |6 +++
src/gbm/main/gbmint.h |4 ++
4 files changed, 98 insertions(+), 13 deletions(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 9de8cb6..d78cf5f 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -284,6 +284,22 @@ gbm_dri_bo_create_from_egl_image(struct gbm_device *gbm,
returnbo-base.base;
}
+static int
+gbm_dri_match_format(enum gbm_bo_format format, int *dri_format)
+{
+ switch (format) {
+ case GBM_BO_FORMAT_XRGB:
+ *dri_format = __DRI_IMAGE_FORMAT_XRGB;
+ break;
+ case GBM_BO_FORMAT_ARGB:
+ *dri_format = __DRI_IMAGE_FORMAT_ARGB;
+ break;
+ default:
+ return -1;
+ }
+ return 0;
+}
+
static struct gbm_bo *
gbm_dri_bo_create(struct gbm_device *gbm,
uint32_t width, uint32_t height,
@@ -296,23 +312,15 @@ gbm_dri_bo_create(struct gbm_device *gbm,
bo = calloc(1, sizeof *bo);
if (bo == NULL)
- return NULL;
+ goto fail;
bo-base.base.gbm = gbm;
bo-base.base.width = width;
bo-base.base.height = height;
- switch (format) {
- case GBM_BO_FORMAT_XRGB:
- dri_format = __DRI_IMAGE_FORMAT_XRGB;
- break;
- case GBM_BO_FORMAT_ARGB:
- dri_format = __DRI_IMAGE_FORMAT_ARGB;
- break;
- default:
- return NULL;
- }
-
+ if (gbm_dri_match_format(format,dri_format) != 0)
+ goto fail;
+
if (usage GBM_BO_USE_SCANOUT)
dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (usage GBM_BO_USE_CURSOR_64X64)
@@ -323,8 +331,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
width, height,
dri_format, dri_use,
bo);
+
Spurious whitespace change.
if (bo-image == NULL)
- return NULL;
+ goto fail;
dri-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_HANDLE,
bo-base.base.handle.s32);
@@ -332,8 +341,59 @@ gbm_dri_bo_create(struct gbm_device *gbm,
(int *)bo-base.base.pitch);
returnbo-base.base;
+
+fail:
+
+ if (bo)
+ free(bo);
There is no reason to check whether the pointer is NULL before calling free.
+ return NULL;
}
+static struct gbm_bo *
+gbm_dri_bo_create_from_name(struct gbm_device *gbm,
+uint32_t width, uint32_t height,
+enum gbm_bo_format format, int name,
+int pitch)
+{
+ struct gbm_dri_device *dri = gbm_dri_device(gbm);
+ struct gbm_dri_bo *bo;
+ int dri_format;
+
+ bo = calloc(1, sizeof *bo);
+ if (bo == NULL)
+ goto fail;
+
+ bo-base.base.gbm = gbm;
+ bo-base.base.width = width;
+ bo-base.base.height = height;
+
+ if (gbm_dri_match_format(format,dri_format) != 0)
+ goto fail;
+
+ bo-image =
+ dri-image-createImageFromName(dri-screen,
+ width, height,
+ dri_format, name, pitch,
+ bo);
+ if (bo-image == NULL)
+ goto fail;
+
+ dri-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_HANDLE,
+bo-base.base.handle.s32);
+ dri-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_STRIDE,
+ (int *)bo-base.base.pitch);
+
+ returnbo-base.base;
+
+fail:
+
+ if (bo)
+ free(bo);
Same comment as above.
+ return NULL;
+
+}
+
+
static void
dri_destroy(struct gbm_device *gbm)
{
@@ -358,6 +418,7 @@ dri_device_create(int fd)
dri-base.base.fd = fd;
dri-base.base.bo_create = gbm_dri_bo_create;
dri-base.base.bo_create_from_egl_image = gbm_dri_bo_create_from_egl_image;
+
Re: [Mesa-dev] [PATCH 00/13] Big pile of client-side GLX fixes
On 12/16/2011 02:02 PM, Adam Jackson wrote: On 12/16/11 4:28 PM, Ian Romanick wrote: On 12/16/2011 12:51 PM, Adam Jackson wrote: Series looks good. I got a chuckle out of the GLX 1.0 thing, I'm completely unsurprised that nobody's recently run Mesa against an OpenGL that didn't support texturing. Just how old of an SGI machine would you have to find, anyway. Dunno.. what did they ship in 1992? It looks like GLX 1.2 even was required to support OpenGL 1.1, and OpenGL 1.1 was released in July 1992. Crimson Reality Engine was 1993 (if not a bit earlier), and that could texture. So I suspect the only OpenGL 1.0 implementations were in specific point releases of IRIX that people would rapidly have upgraded OpenGL 1.0 had texturing. It just didn't have texture objects. If you wanted more than one texture you had to use display lists. glNewList(tex0, GL_COMPILE); glTexImage2D(GL_TEXTURE_2D, ...); glTexParameteri(GL_TEXTURE_2D, ...); glEndList(); ... glCallList(tex0); That's just as good as encapsulating state in an object, right? :) That's why OpenGL 1.1 came out so quickly after 1.0. past; therefore, that literally all copies of those binaries have disappeared from the earth. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] egl: add EGL_NV_post_sub_buffer
On 12/14/2011 01:21 PM, Ian Romanick wrote: On 12/14/2011 12:24 PM, Fredrik Höglund wrote: diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index 9484b83..d03a24d 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -144,6 +144,15 @@ typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESA) (EGLDisplay dpy, con typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESA) (EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); #endif +#ifndef EGL_NV_post_sub_buffer +#define EGL_NV_post_sub_buffer 1 +#define EGL_POST_SUB_BUFFER_SUPPORTED_NV 0x30BE +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLBoolean EGLAPIENTRY eglPostSubBufferNV(EGLDisplay dpy, EGLSurface surface, EGLint x, EGLint y, EGLint width, EGLint height); +#endif /* EGL_EGLEXT_PROTOTYPES */ +typedef EGLBoolean (EGLAPIENTRYP PFNEGLPOSTSUBBUFFERNVPROC) (EGLDisplay dpy, EGLSurface surface, EGLint x, EGLint y, EGLint width, EGLint height); +#endif + #ifndef EGL_WL_bind_wayland_display #define EGL_WL_bind_wayland_display 1 I think we may be treating this file incorrectly. It's my understanding that eglext.h comes from Khronos, and we don't get to modify it. Our current eglext.h is based on version 7 (current version is 10), and it has diverged quite a bit. I want to ping folks at Khronos and figure out how we're supposed to deal with this file. After some discussion with the EGL group in Khronos, here is what I have learned. - Specific implementations are allowed to modify eglext.h, but it's not really recommended. - Instead, implementations are recommended to ship, and I'm not kidding, eglMYPLATFORMext.h, where MYPLATFORM is some name like mesa or android, or whatever. - One suggestion is to have a eglMYPLATFORMext.h and have eglext.h include that. I think I'm in favor of the later option. This isolates our changes to a separate file, and it prevents applications from having to directly include eglmesaext.h (or whatever). This also allows us to get new versions of the official eglext.h with less risk of dropping something. I also think that any and all Mesa and Wayland extensions should get propagated to the official eglext.h as soon as possible. It looks like a few of them (e.g., EGL_MESA_drm_image) already are. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] Big pile of client-side GLX fixes
On Fri, Dec 16, 2011 at 02:11:43PM -0800, Ian Romanick wrote: | OpenGL 1.0 had texturing. It just didn't have texture objects. If | you wanted more than one texture you had to use display lists. | ... | That's why OpenGL 1.1 came out so quickly after 1.0. There were machines from a couple of workstation vendors that didn't support texturing, and if I remember correctly the same was true for a few of the PC vendors that were involved at the beginning. Some of the earliest arguments about subsetting revolved around that issue; people wanted to ship OpenGL on machines without hardware texturing and without software fallback. Texture objects came about when everyone realized that some textures needed to be mutable (via CopyTexture, etc.) but display lists were explicitly designed to be immutable. As Ian said, that was right on the heels of 1.0. Allen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] egl: add EGL_NV_post_sub_buffer
On 12/14/2011 11:16 PM, Chia-I Wu wrote:
On Thu, Dec 15, 2011 at 5:21 AM, Ian Romanicki...@freedesktop.org wrote:
On 12/14/2011 12:24 PM, Fredrik Höglund wrote:
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 3cb1a5b..ff15476 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -951,6 +951,9 @@ eglGetProcAddress(const char *procname)
#ifdef EGL_ANDROID_swap_rectangle
{ eglSetSwapRectangleANDROID, (_EGLProc)
eglSetSwapRectangleANDROID },
#endif
+#ifdef EGL_NV_post_sub_buffer
It seems weird that we define this in our own header file, then check to see
if it's defined. I understand that the new code is just following the
pattern of the existing code. Perhaps Kristian or Chia-I can shed some
light on this convention.
The convention was established before I started working on EGL. I
agree with you that those checks are unnecessary (and ugly..). I will
remove them in a separate patch, if no one objects.
I would support that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/13] glx: Fix handling of property list received from the server in glXImportContextEXT
On Fri, 16 Dec 2011 11:55:40 -0800, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com NOTE: This is a candidate for the 7.11 branch. I couldn't work out what was actually being fixed here, unless it's fbconfigid should take precedence over visualid. pgpS4nKMaVVBB.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 08/13] glx: Generate BadContext when None is passed to glXImportContextEXT
On Fri, 16 Dec 2011 11:55:45 -0800, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Fixes the piglit test glx-import-context-single-process NOTE: This is a candidate for the 7.11 branch, but it also requires the previous patch. I would have thought the server should be returning BadContext here -- it looks like it tries to in some cases of not finding the context, which it seems like should be the case for None. pgpbbtng3H1Bx.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 00/13] Big pile of client-side GLX fixes
On Fri, 16 Dec 2011 11:55:37 -0800, Ian Romanick i...@freedesktop.org wrote: This series of fixes is a direct result of the GLX_EXT_import_context recently committed to piglit. These are all bugs discovered while working on GLX_ARB_create_context and friends. As soon as this series lands, the GLX_ARB_create_context patches will go out. I've already posted a set of GLX_ARB_create_context tests to the piglit list for review. Uncommented patches are Reviewed-by: Eric Anholt e...@anholt.net pgpigTokQ2pU5.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] libvdpau_r600.so not found
I've been trying to test out vdpau w/o success.
It turns out that libvdpau_r600.so is in /usr/lib64/vdpau/, whereas
everything looks for it in the standard ld path (ie, /usr/lib64).
With »ln -s vdpau/libvdpau_r600.so /usr/lib64/« it seems to work.
Is mesa wrong to install the libs to ${libdir}/vdpau, or is libvdpau
and the apps wrong to look for them in ${libdir}?
(Everything was compiled locally; most of the fdo stuff from git master.)
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43896] Mesa assembly breaks Super Meat Boy, Shank
https://bugs.freedesktop.org/show_bug.cgi?id=43896 imamdxl8...@gmail.com changed: What|Removed |Added CC||imamdxl8...@gmail.com -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] More on lib paths
And while I'm asking about library paths, I compiled mesa with gallium planning on using r600g, but everything looks for r600_dri.so; never for r600g_dri.so. I had to add a symlink. Is there an env I should set to prefer r600g over r600? I didn't find one looking through the src. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libvdpau_r600.so not found
On Fri, Dec 16, 2011 at 7:01 PM, James Cloos cl...@jhcloos.com wrote:
I've been trying to test out vdpau w/o success.
It turns out that libvdpau_r600.so is in /usr/lib64/vdpau/, whereas
everything looks for it in the standard ld path (ie, /usr/lib64).
With »ln -s vdpau/libvdpau_r600.so /usr/lib64/« it seems to work.
Is mesa wrong to install the libs to ${libdir}/vdpau, or is libvdpau
and the apps wrong to look for them in ${libdir}?
(Everything was compiled locally; most of the fdo stuff from git master.)
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Mesa is probably wrong. You can specify it with ./configure
--with-vdpau-libdir= of course, but I can't think of a good reason to
have the default be not in the usually searched paths.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] More on lib paths
On Fri, Dec 16, 2011 at 7:20 PM, James Cloos cl...@jhcloos.com wrote: And while I'm asking about library paths, I compiled mesa with gallium planning on using r600g, but everything looks for r600_dri.so; never for r600g_dri.so. I had to add a symlink. Is there an env I should set to prefer r600g over r600? I didn't find one looking through the src. Both the r600 classic and the r600 gallium drivers produce the same 3D driver: r600_dri.so. There is no r600g_dri.so. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libvdpau_r600.so not found
On Fri, Dec 16, 2011 at 7:38 PM, James Jones jajo...@nvidia.com wrote:
On 12/16/11 4:27 PM, Younes Manton wrote:
On Fri, Dec 16, 2011 at 7:01 PM, James Clooscl...@jhcloos.com wrote:
I've been trying to test out vdpau w/o success.
It turns out that libvdpau_r600.so is in /usr/lib64/vdpau/, whereas
everything looks for it in the standard ld path (ie, /usr/lib64).
With »ln -s vdpau/libvdpau_r600.so /usr/lib64/« it seems to work.
Is mesa wrong to install the libs to ${libdir}/vdpau, or is libvdpau
and the apps wrong to look for them in ${libdir}?
(Everything was compiled locally; most of the fdo stuff from git master.)
-JimC
--
James Clooscl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Mesa is probably wrong. You can specify it with ./configure
--with-vdpau-libdir= of course, but I can't think of a good reason to
have the default be not in the usually searched paths.
The correct dir is LIBDIR/vdpau. From here:
http://cgit.freedesktop.org/~aplattner/libvdpau/tree/configure.ac:72
Do you have an older libvdpau.so?
We had a long debate over this internally and decided it was better to have
the backends in a non-searchpath directory. I believe the idea was to
discourage directly linking to them, and to roughly follow the lead of
OpenCL in this area, but my memory is getting foggy. Before we made the
switch, old NVIDIA builds of libvdpau.so looked in LIBDIR and installed
libvdpau_nvidia.so there as well.
Thanks,
-James
nvpublic
Makes sense, thanks. By 'usually searched paths' what I was actually
had in mind was 'wherever libvdpau.so searches for it'; though I too
thought it was still LIBDIR since I'm running one of the older
drivers that has it there and I never actually install Mesa.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Remove unnecessary FLUSH_VERTICES in bind_buffer_range
Reviewed-by: Marek Olšák mar...@gmail.com
Thanks!
Marek
On Fri, Dec 16, 2011 at 11:06 PM, Paul Berry stereotype...@gmail.com wrote:
It isn't necessary to call FLUSH_VERTICES from bind_buffer_range,
because transform feedback buffers are not allowed to be changed when
transform feedback is active.
Thanks to Marek Olšák for pointing out this bug.
---
src/mesa/main/transformfeedback.c | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index 824f66a..3305613 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -404,7 +404,11 @@ bind_buffer_range(struct gl_context *ctx, GLuint index,
{
struct gl_transform_feedback_object *obj =
ctx-TransformFeedback.CurrentObject;
- FLUSH_VERTICES(ctx, _NEW_TRANSFORM_FEEDBACK);
+
+ /* Note: no need to FLUSH_VERTICES or flag _NEW_TRANSFORM_FEEDBACK,
because
+ * transform feedback buffers can't be changed while transform feedback is
+ * active.
+ */
/* The general binding point */
_mesa_reference_buffer_object(ctx,
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/13] glx: Fix handling of property list received from the server in glXImportContextEXT
On 12/16/2011 03:33 PM, Eric Anholt wrote: On Fri, 16 Dec 2011 11:55:40 -0800, Ian Romanicki...@freedesktop.org wrote: From: Ian Romanickian.d.roman...@intel.com NOTE: This is a candidate for the 7.11 branch. I couldn't work out what was actually being fixed here, unless it's fbconfigid should take precedence over visualid. Crap. I thought I wrote a credible commit message for that patch, but it looks like the text never got from my brain to the commit message. The problem is that the number of reply bytes read is clamped to sizeof(propList), but the loop that processes the properties tries to examine all of them. If the server sends 47,000 properties, we only read 3 but process all 47,000. It now occurs to me that the __GLX_MAX_CONTEXT_PROPS define in glxproto.h is rubbish. The server should send 4 properties: screen, fbconfig ID (or visual ID), share context ID, and render type. Ugh. I'll re-spin this patch with a better commit message, and I'll change int propList[__GLX_MAX_CONTEXT_PROPS * 2], *pProp, nPropListBytes; to /* This GLX implementation knows about 5 different properties, so * allow the server to send us one of each. */ int propList[5 * 2], *pProp, nPropListBytes; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/13] glx: Generate BadContext when None is passed to glXImportContextEXT
On 12/16/2011 03:45 PM, Eric Anholt wrote: On Fri, 16 Dec 2011 11:55:45 -0800, Ian Romanicki...@freedesktop.org wrote: From: Ian Romanickian.d.roman...@intel.com Fixes the piglit test glx-import-context-single-process NOTE: This is a candidate for the 7.11 branch, but it also requires the previous patch. I would have thought the server should be returning BadContext here -- it looks like it tries to in some cases of not finding the context, which it seems like should be the case for None. This was one of the first patches that I wrote, and I think this was from before my discovery that XCB doesn't propagate protocol errors to the application. I bet the server is generating BadContext, but the implementation of __glXIsDirect doesn't propagate that error from XCB to the application. I'll rework the patch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/8] i965 gen6: Initial implementation of transform feedback.
On 12/13/2011 03:35 PM, Paul Berry wrote:
[snip]
+static void
+brw_update_sol_surface(struct brw_context *brw, drm_intel_bo *bo,
+ uint32_t *out_offset, unsigned num_vector_components,
+ unsigned stride_dwords, unsigned offset_dwords,
+ uint32_t buffer_size_minus_1)
+{
+ uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 6 * 4, 32,
+out_offset);
+ uint32_t width = buffer_size_minus_1 0x7f;
+ uint32_t height = (buffer_size_minus_1 0xfff80) 7;
+ uint32_t depth = (buffer_size_minus_1 0x7f0) 20;
+ uint32_t pitch_minus_1 = 4*stride_dwords - 1;
+ uint32_t surface_format;
+ uint32_t offset_bytes = 4 * offset_dwords;
+ switch (num_vector_components) {
+ case 1:
+ surface_format = BRW_SURFACEFORMAT_R32_FLOAT;
+ break;
+ case 2:
+ surface_format = BRW_SURFACEFORMAT_R32G32_FLOAT;
+ break;
+ case 3:
+ surface_format = BRW_SURFACEFORMAT_R32G32B32_FLOAT;
+ break;
+ case 4:
+ surface_format = BRW_SURFACEFORMAT_R32G32B32A32_FLOAT;
+ break;
+ default:
+ assert (!Invalid vector size for transform feedback output);
+ surface_format = BRW_SURFACEFORMAT_R32_FLOAT;
+ break;
+ }
Is it possible to have integer transform feedback outputs? If so, we'd
need to adjust this. But we can do that later (if at all).
Looks good, Paul.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965 gen6: Implement rasterizer discard.
On 12/14/2011 11:59 AM, Paul Berry wrote: This patch enables rasterizer discard functionality (a part of transform feedback) in Gen6, by generating an alternate GS program when rasterizer discard is active. Instead of forwarding vertices down the pipeline, the alternate GS program uses a URB Write message to deallocate the URB entry that was allocated by FF sync and terminate the thread. Note: parts of the Sandy Bridge PRM seem to imply that we could do this more efficiently, by clearing the GEN6_GS_RENDERING_ENABLE bit, and not allocating a URB entry at all. However, it's not clear how we are supposed to terminate the thread if we do that. Volume 2 part 1, section 4.5.4, says GS threads must terminate by sending a URB_WRITE message with the EOT and Complete bits set., and my experiments so far confirm that. --- This patch needs to be applied on top of the series [PATCH 0/8] i965 gen6: Initial implementation of transform feedback., which is still under review on the mailing list. Assuming the dirty bit gets sorted out, Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
