Re: [Mesa-dev] [RFC, PATCH] Fix 24bpp software rendering, take 2
This patch add the support for 24bpp in the dri/swrast implementation. Signed-off-by: Marc Pignat marc at pignat.org --- Hi all! Here is a fix for https://bugs.freedesktop.org/show_bug.cgi?id=23525 This time it has been tested under kvm/qemu using: * cirrus emulation (truecolor 24 bits with 24 bpp) * vga (truecolor 24 bits with 32 bpp) I know this is a workaround, but I think we don't need to spend too much time for this unusual (24 bpp) mode. Best regards Marc diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c index 07d4955..a57b327 100644 --- a/src/glx/drisw_glx.c +++ b/src/glx/drisw_glx.c @@ -100,6 +100,13 @@ XCreateDrawable(struct drisw_drawable * pdp, 32, /* bitmap_pad */ 0); /* bytes_per_line */ + /** + * swrast does not handle 24-bit depth with 24 bpp, so let X do the + * the conversion for us. + */ + if (pdp-ximage-bits_per_pixel == 24) + pdp-ximage-bits_per_pixel = 32; + return True; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: Use correct internal target
Commit 1a339b6c(st/mesa: prefer native texture formats when possible)
introduced two new arguments to the st_choose_format() functions.
This patch fixes the order and passes the correct internal_target
rather than GL_NONE
NOTE: This is a candidate for the 7.11 branch
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/mesa/state_tracker/st_cb_drawpixels.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index c730975..d61d7ac 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1400,14 +1400,14 @@ st_CopyPixels(struct gl_context *ctx, GLint srcx, GLint
srcy,
/* srcFormat can't be used as a texture format */
if (type == GL_DEPTH) {
texFormat = st_choose_format(screen, GL_DEPTH_COMPONENT,
- st-internal_target, GL_NONE, GL_NONE,
+ GL_NONE, GL_NONE, st-internal_target,
sample_count, PIPE_BIND_DEPTH_STENCIL);
assert(texFormat != PIPE_FORMAT_NONE);
}
else {
/* default color format */
texFormat = st_choose_format(screen, GL_RGBA,
- st-internal_target, GL_NONE, GL_NONE,
+ GL_NONE, GL_NONE, st-internal_target,
sample_count, PIPE_BIND_SAMPLER_VIEW);
assert(texFormat != PIPE_FORMAT_NONE);
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st-api: Rework how drawables are invalidated v2
The api and the state tracker manager code as well as the state tracker code
assumed that only a single context could be bound to a drawable. That is not
a valid assumption, since multiple contexts can bind to the same drawable.
Fix this by making it the state tracker's responsibility to update all
contexts binding to a drawable
Note that the state trackers themselves don't use atomic stamps on
frame-buffers. Multiple context rendering to the same drawable should
be protected by the application.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/include/state_tracker/st_api.h | 25 +
.../state_trackers/dri/common/dri_drawable.c |1 +
src/gallium/state_trackers/dri/drm/dri2.c |4 +-
src/gallium/state_trackers/dri/sw/drisw.c |5 +-
src/gallium/state_trackers/egl/common/egl_g3d.c| 13 +--
.../state_trackers/egl/common/egl_g3d_api.c|7 --
src/gallium/state_trackers/egl/common/egl_g3d_st.c |2 +
src/gallium/state_trackers/vega/vg_context.h |5 +-
src/gallium/state_trackers/vega/vg_manager.c | 48 +-
src/gallium/state_trackers/wgl/stw_context.c |6 +-
src/gallium/state_trackers/wgl/stw_st.c|2 +
src/mesa/state_tracker/st_cb_viewport.c| 15 ++-
src/mesa/state_tracker/st_context.h|6 +-
src/mesa/state_tracker/st_manager.c| 98 +++
14 files changed, 121 insertions(+), 116 deletions(-)
diff --git a/src/gallium/include/state_tracker/st_api.h
b/src/gallium/include/state_tracker/st_api.h
index 04fc7c6..f7cc243 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -253,6 +253,12 @@ struct st_context_attribs
struct st_framebuffer_iface
{
/**
+* Atomic stamp which changes when framebuffers need to be updated.
+*/
+
+ int32_t stamp;
+
+ /**
* Available for the state tracker manager to use.
*/
void *st_manager_private;
@@ -315,25 +321,6 @@ struct st_context_iface
void (*destroy)(struct st_context_iface *stctxi);
/**
-* Invalidate the current textures that was taken from a framebuffer.
-*
-* The state tracker manager calls this function to let the rendering
-* context know that it should update the textures it got from
-* st_framebuffer_iface::validate. It should do so at the latest time
possible.
-* Possible right before sending triangles to the pipe context.
-*
-* For certain platforms this function might be called from a thread other
-* than the thread that the context is currently bound in, and must
-* therefore be thread safe. But it is the state tracker manager's
-* responsibility to make sure that the framebuffer is bound to the context
-* and the API context is current for the duration of this call.
-*
-* Thus reducing the sync primitive needed to a single atomic flag.
-*/
- void (*notify_invalid_framebuffer)(struct st_context_iface *stctxi,
- struct st_framebuffer_iface *stfbi);
-
- /**
* Flush all drawing from context to the pipe also flushes the pipe.
*/
void (*flush)(struct st_context_iface *stctxi, unsigned flags,
diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index 28a33ac..7b8de31 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -136,6 +136,7 @@ dri_create_buffer(__DRIscreen * sPriv,
drawable-sPriv = sPriv;
drawable-dPriv = dPriv;
dPriv-driverPrivate = (void *)drawable;
+ p_atomic_set(drawable-base.stamp, 1);
return GL_TRUE;
fail:
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index e471e8e..2b6abc3 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -52,13 +52,11 @@ static void
dri2_invalidate_drawable(__DRIdrawable *dPriv)
{
struct dri_drawable *drawable = dri_drawable(dPriv);
- struct dri_context *ctx = drawable-context;
dri2InvalidateDrawable(dPriv);
drawable-dPriv-lastStamp = *drawable-dPriv-pStamp;
- if (ctx)
- ctx-st-notify_invalid_framebuffer(ctx-st, drawable-base);
+ p_atomic_inc(drawable-base.stamp);
}
static const __DRI2flushExtension dri2FlushExtension = {
diff --git a/src/gallium/state_trackers/dri/sw/drisw.c
b/src/gallium/state_trackers/dri/sw/drisw.c
index ac11f7c..a1879a8 100644
--- a/src/gallium/state_trackers/dri/sw/drisw.c
+++ b/src/gallium/state_trackers/dri/sw/drisw.c
@@ -103,14 +103,11 @@ drisw_present_texture(__DRIdrawable *dPriv,
static INLINE void
drisw_invalidate_drawable(__DRIdrawable *dPriv)
{
- struct dri_context *ctx = dri_get_current(dPriv-driScreenPriv);
struct dri_drawable *drawable = dri_drawable(dPriv);
drawable-texture_stamp =
Re: [Mesa-dev] [PATCH] st-api: Rework how drawables are invalidated v2
- Original Message - Note that the state trackers themselves don't use atomic stamps on frame-buffers. Multiple context rendering to the same drawable should be protected by the application. I known that contexts must not be used by two threads simultaneously, but I don't recall ever reading similar constraint for drawables. Is this written anywhere? Neither glXMakeCurrent man page nor wglMakeCurrent reference page [1] mentions such constraint. Of course, rendering from two contexts to the same drawable will usually be effective only when the context flushes. But AFAICS, the application should not need any additional lbocking. Unfortunately, I can't find such mesa demo: xdemos/corender and xdemos/multictx are close but not quite. A multictx_mt version would be necessary. Jose [1] http://msdn.microsoft.com/en-us/library/dd374387(v=vs.85).aspx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] getenv4d-with-error: New test for a bug in glGetProgramEnvParameter4dARB().
2011/6/29 Eric Anholt e...@anholt.net:
---
tests/all.tests | 4 +
tests/spec/CMakeLists.txt | 1 +
tests/spec/arb_vertex_program/CMakeLists.gl.txt | 16
tests/spec/arb_vertex_program/CMakeLists.txt | 1 +
.../spec/arb_vertex_program/getenv4d-with-error.c | 88
5 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 tests/spec/arb_vertex_program/CMakeLists.gl.txt
create mode 100644 tests/spec/arb_vertex_program/CMakeLists.txt
create mode 100644 tests/spec/arb_vertex_program/getenv4d-with-error.c
diff --git a/tests/all.tests b/tests/all.tests
index 86987d9..8a319be 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -892,6 +892,10 @@ spec['ARB_vertex_buffer_object'] =
arb_vertex_buffer_object
arb_vertex_buffer_object['elements-negative-offset'] =
PlainExecTest(['arb_vertex_buffer_object-elements-negative-offset', '-auto'])
arb_vertex_buffer_object['mixed-immediate-and-vbo'] =
PlainExecTest(['arb_vertex_buffer_object-mixed-immediate-and-vbo', '-auto'])
+arb_vertex_program = Group()
+spec['ARB_vertex_program'] = arb_vertex_program
+arb_vertex_program['getenv4d-with-error'] =
PlainExecTest(['arb_vertex_program-getenv4d-with-error', '-auto'])
+
ext_framebuffer_object = Group()
spec['EXT_framebuffer_object'] = ext_framebuffer_object
add_fbo_stencil_tests(ext_framebuffer_object, 'GL_STENCIL_INDEX1')
diff --git a/tests/spec/CMakeLists.txt b/tests/spec/CMakeLists.txt
index efcc660..52dfcf4 100644
--- a/tests/spec/CMakeLists.txt
+++ b/tests/spec/CMakeLists.txt
@@ -15,3 +15,4 @@ add_subdirectory (nv_conditional_render)
add_subdirectory (nv_texture_barrier)
add_subdirectory (arb_draw_elements_base_vertex)
add_subdirectory (arb_vertex_buffer_object)
+add_subdirectory (arb_vertex_program)
diff --git a/tests/spec/arb_vertex_program/CMakeLists.gl.txt
b/tests/spec/arb_vertex_program/CMakeLists.gl.txt
new file mode 100644
index 000..f71badd
--- /dev/null
+++ b/tests/spec/arb_vertex_program/CMakeLists.gl.txt
@@ -0,0 +1,16 @@
+include_directories(
+ ${OPENGL_INCLUDE_PATH}
+ ${GLUT_INCLUDE_DIR}
+ ${piglit_SOURCE_DIR}/tests/util
+)
+
+link_libraries (
+ piglitutil
+ ${OPENGL_gl_LIBRARY}
+ ${OPENGL_glu_LIBRARY}
+ ${GLUT_glut_LIBRARY}
+)
+
+add_executable (arb_vertex_program-getenv4d-with-error getenv4d-with-error.c)
+
+# vim: ft=cmake:
diff --git a/tests/spec/arb_vertex_program/CMakeLists.txt
b/tests/spec/arb_vertex_program/CMakeLists.txt
new file mode 100644
index 000..144a306
--- /dev/null
+++ b/tests/spec/arb_vertex_program/CMakeLists.txt
@@ -0,0 +1 @@
+piglit_include_target_api()
diff --git a/tests/spec/arb_vertex_program/getenv4d-with-error.c
b/tests/spec/arb_vertex_program/getenv4d-with-error.c
new file mode 100644
index 000..3e77a7f
--- /dev/null
+++ b/tests/spec/arb_vertex_program/getenv4d-with-error.c
@@ -0,0 +1,88 @@
+/*
+ * Copyright © 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS 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.
+ */
+
+/** @file getenv4d-with-error.c
+ *
+ * Tests for a bug in Mesa where glGetProgramEnvParameter4dARB would
+ * fail to update the result if there was an existing GL error in the
+ * context.
+ */
+
+#include piglit-util.h
+
+int piglit_width = 64, piglit_height = 64;
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE | GLUT_ALPHA;
+
+void
+piglit_init(int argc, char **argv)
+{
+ bool pass = true;
+ double test_data[4] = { 0.1, 0.2, 0.3, 0.4 };
+ double result_data[4];
+ float epsilon = .1;
+
+ piglit_require_extension(GL_ARB_vertex_program);
+
+ glProgramEnvParameter4dARB(GL_VERTEX_PROGRAM_ARB, 0,
+ test_data[0],
+ test_data[1],
+
Re: [Mesa-dev] [PATCH 2/2] Gallium:draw:aaline and aapoint: Don't free the tokens.
Stephane, It doens't look right to me: we did allocate these (with the tgsi_alloc_tokens() call above); and the driver should not delete them (the driver will make a copy of the tokens if it needs them, and should not hold on to the incoming tokens. If there's a double free, then I suspect the problem is elsewhere, not the draw module. Jose - Original Message - We didn't allocate them, and the driver will try to free them at the end of the pipeline stage, so leave them alone. --- src/gallium/auxiliary/draw/draw_pipe_aaline.c |1 - src/gallium/auxiliary/draw/draw_pipe_aapoint.c |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c b/src/gallium/auxiliary/draw/draw_pipe_aaline.c index 458f85d..83b19ef 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c +++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c @@ -385,7 +385,6 @@ generate_aaline_fs(struct aaline_stage *aaline) goto fail; aaline-fs-generic_attrib = transform.maxGeneric + 1; - FREE((void *)aaline_fs.tokens); return TRUE; fail: diff --git a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c index 9265c37..9e40687 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c +++ b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c @@ -531,7 +531,6 @@ generate_aapoint_fs(struct aapoint_stage *aapoint) goto fail; aapoint-fs-generic_attrib = transform.maxGeneric + 1; - FREE((void *)aapoint_fs.tokens); return TRUE; fail: -- 1.7.5.3.367.ga9930 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): i915g: Improve SIN/COS a bit.
Module: Mesa Branch: master Commit: 062a1e291fdc0ef69b6677f8ae0e3471047e281d URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=062a1e291fdc0ef69b6677f8ae0e3471047e281d Author: Stéphane Marchesin marcheu at chromium.org Date: Tue Jun 28 00:53:01 2011 -0700 i915g: Improve SIN/COS a bit. --- src/gallium/drivers/i915/i915_fpc_translate.c | 40 1 files changed, 20 insertions(+), 20 deletions(-) This adds some more uses of M_PI to i915_fpc_translate.c, before the definition of M_PI it makes for the benefit of math.h which don't define M_PI. See [1]. Attached is a patch which fixes this by moving the definition of M_PI. I'm not sure why this file and the few others which do this, don't include compiler.h for the definition M_PI there... [1] http://tinderbox.freedesktop.org/builds/2011-06-28-0002/logs/libGL/#build From 135e6608f9f5e1afb631049846769de739684e44 Mon Sep 17 00:00:00 2001 From: Jon TURNEY jon.tur...@dronecode.org.uk Date: Wed, 29 Jun 2011 12:43:11 +0100 Subject: [PATCH] i915g: Move definition of M_PI in i915_fpc_translate.c Move defintion of M_PI (for the benefit of math.h which do not define it), to before the first use of it Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- src/gallium/drivers/i915/i915_fpc_translate.c |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/i915/i915_fpc_translate.c b/src/gallium/drivers/i915/i915_fpc_translate.c index ab09d56..93fe453 100644 --- a/src/gallium/drivers/i915/i915_fpc_translate.c +++ b/src/gallium/drivers/i915/i915_fpc_translate.c @@ -41,6 +41,9 @@ #include draw/draw_vertex.h +#ifndef M_PI +#define M_PI 3.14159265358979323846 +#endif /** * Simple pass-through fragment shader to use when we don't have @@ -442,11 +445,6 @@ emit_simple_arith_swap2(struct i915_fp_compile *p, emit_simple_arith(p, inst2, opcode, numArgs, fs); } - -#ifndef M_PI -#define M_PI 3.14159265358979323846 -#endif - /* * Translate TGSI instruction to i915 instruction. * -- 1.7.5.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st-api: Rework how drawables are invalidated
Jon, Thanks for pointing this out. I apparently missed at least one case. I'll fix ASAP. /Thomas On 06/29/2011 02:20 PM, Jon TURNEY wrote: On 28/06/2011 13:19, Thomas Hellstrom wrote: The api and the state tracker manager code as well as the state tracker code assumed that only a single context could be bound to a drawable. That is not a valid assumption, since multiple contexts can bind to the same drawable. Fix this by making it the state tracker's responsibility to update all contexts binding to a drawable. Signed-off-by: Thomas Hellstromthellst...@vmware.com --- src/gallium/include/state_tracker/st_api.h | 26 ++- .../state_trackers/dri/common/dri_drawable.c |3 + src/gallium/state_trackers/dri/drm/dri2.c |4 +- src/gallium/state_trackers/dri/sw/drisw.c |4 +- src/gallium/state_trackers/egl/common/egl_g3d.c| 12 +-- .../state_trackers/egl/common/egl_g3d_api.c|7 -- src/gallium/state_trackers/egl/common/egl_g3d_st.c |8 ++ src/gallium/state_trackers/vega/vg_context.h |4 +- src/gallium/state_trackers/vega/vg_manager.c | 40 -- src/gallium/state_trackers/wgl/stw_context.c |6 +- src/gallium/state_trackers/wgl/stw_st.c|3 + src/mesa/state_tracker/st_cb_viewport.c| 15 +++- src/mesa/state_tracker/st_context.h|5 +- src/mesa/state_tracker/st_manager.c| 85 +++- 14 files changed, 109 insertions(+), 113 deletions(-) It looks like state_trackers/glx/xlib (built when ./configured --with-driver=xlib) hasn't been updated for this change: make[5]: Entering directory `/opt/wip/mesa-cygwin-dri-driver/mesa/src/gallium/state_trackers/glx/xlib' ccache gcc -c -I. -I../../../../../src/gallium/include -I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers -I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa -I/opt/wip/jhbuild/install/include -g -O0 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208 -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS xm_api.c -o xm_api.o xm_api.c: In function ‘xmesa_notify_invalid_buffer’: xm_api.c:1119:16: error: ‘struct st_context_iface’ has no member named ‘notify_invalid_framebuffer’ make[5]: *** [xm_api.o] Error 1 make[5]: Leaving directory `/opt/wip/mesa-cygwin-dri-driver/mesa/src/gallium/state_trackers/glx/xlib' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): i915g: Improve SIN/COS a bit.
On Wed, Jun 29, 2011 at 5:49 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Module: Mesa Branch: master Commit: 062a1e291fdc0ef69b6677f8ae0e3471047e281d URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=062a1e291fdc0ef69b6677f8ae0e3471047e281d Author: Stéphane Marchesin marcheu at chromium.org Date: Tue Jun 28 00:53:01 2011 -0700 i915g: Improve SIN/COS a bit. --- src/gallium/drivers/i915/i915_fpc_translate.c | 40 1 files changed, 20 insertions(+), 20 deletions(-) This adds some more uses of M_PI to i915_fpc_translate.c, before the definition of M_PI it makes for the benefit of math.h which don't define M_PI. See [1]. Attached is a patch which fixes this by moving the definition of M_PI. Reviewed-by: Brian Paul bri...@vmware.com I'm not sure why this file and the few others which do this, don't include compiler.h for the definition M_PI there... We can't include Mesa's compiler.h in any of the gallium sources. We should probably define M_PI in one of the gallium utility headers. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix overwriting gl_format with pipe_format since 9d380f48
On Mon, Jun 27, 2011 at 9:03 AM, Andre Maasikas amaasi...@gmail.com wrote: fixes assert later on in texcompress2/r600g Pushed. Thanks! -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38776] New: Account request for Vadim Girlin
https://bugs.freedesktop.org/show_bug.cgi?id=38776 Summary: Account request for Vadim Girlin Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: pt...@yandex.ru Created an attachment (id=48554) -- (https://bugs.freedesktop.org/attachment.cgi?id=48554) ssh key I'm requesting account with mesa commit access. Real name: Vadim Girlin Email: vadimgirlin at gmail.com Preferred account name: vadimg -- 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 38776] Account request for Vadim Girlin
https://bugs.freedesktop.org/show_bug.cgi?id=38776 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Product|Mesa|freedesktop.org Component|Other |New Accounts AssignedTo|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org --- Comment #2 from Alex Deucher ag...@yahoo.com 2011-06-29 08:14:37 PDT --- Vadim has produced a lot of good patches for r600g. Please give him access to mesa. -- 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 3/3] mesa: Remove extra NULL Check on glFeedbackBuffer().
On Tue, 28 Jun 2011 21:20:14 -0600, Brian Paul brian.e.p...@gmail.com wrote:
On Tue, Jun 28, 2011 at 5:49 PM, Eric Anholt e...@anholt.net wrote:
This error result doesn't appear in the GL 2.1 or 3.2 compatibility
specs, and triggers an unexpected GL error in Intel's oglconform when
it tries to reset the feedback state after usage so that the diff the
state at error time vs. context init time code doesn't generate
spurious diffs. The unexpected GL error then translates into testcase
failure.
---
src/mesa/main/feedback.c | 5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/feedback.c b/src/mesa/main/feedback.c
index fcb089f..f4862f5 100644
--- a/src/mesa/main/feedback.c
+++ b/src/mesa/main/feedback.c
@@ -64,11 +64,6 @@ _mesa_FeedbackBuffer( GLsizei size, GLenum type, GLfloat
*buffer )
_mesa_error( ctx, GL_INVALID_VALUE, glFeedbackBuffer(size0) );
return;
}
- if (!buffer) {
- _mesa_error( ctx, GL_INVALID_VALUE, glFeedbackBuffer(buffer==NULL)
);
- ctx-Feedback.BufferSize = 0;
- return;
- }
switch (type) {
case GL_2D:
You're removing the null ptr check which set the buffer size to zero.
What if someone passes buffer=NULL but size 0? I hope we don't
crash now if we didn't crash before. Though, I doubt that'd ever
happen in practice.
I'm sure we would, and I'd just chalk it up to application bugs like so
many other entrypoints with a pointer==NULL. I guess we can just limit
the check to size != NULL if you'd like.
pgplYink4BNAa.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] dri2proto 2.6
Chad Versace (1): Add attachment token DRI2BufferHiz Jesse Barnes (2): Revert dri2proto: make DRI2 swap event match GLX spec dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec git tag: dri2proto-2.6 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.6.tar.bz2 MD5: 2eb74959684f47c862081099059a11ab dri2proto-2.6.tar.bz2 SHA1: ba65fc53376fd6e6b41bf6ef1e2ea1ba4b12ca96 dri2proto-2.6.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.6.tar.gz MD5: 873142af5db695537cfe05e01d13541f dri2proto-2.6.tar.gz SHA1: ebce24ebc3c9674d40a9b100a4520e735670a23c dri2proto-2.6.tar.gz ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] Gallium:draw:aaline and aapoint: Don't free the tokens.
2011/6/29 Jose Fonseca jfons...@vmware.com: Stephane, It doens't look right to me: we did allocate these (with the tgsi_alloc_tokens() call above); and the driver should not delete them (the driver will make a copy of the tokens if it needs them, and should not hold on to the incoming tokens. If there's a double free, then I suspect the problem is elsewhere, not the draw module. Hmm, I'll investigate more. There is definitely a double-free of some kind on those. Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] glsl: Create AST structs corresponding to new productions in grammar
On 06/28/2011 10:47 PM, Kenneth Graunke wrote: On 06/28/2011 02:48 PM, Dan McCabe wrote: Previously we added productions for: switch_body case_label_list case_statement case_statement_list Now add AST structs corresponding to those productions. Both 1/3 and 3/3 look good. You might actually want to squash them...they're so similar. I'd order them like this: [PATCH 1/4] glsl: Add productions to GLSL grammar for switch statements [PATCH 2/4] glsl: Create AST structures for switch statements [PATCH 3/4] glsl: Reference data structure ctors in grammar [PATCH 4/4] glsl: Generate IR for switch statements My reasoning for ordering them the way I did is that 1/5 was the least amount of code the **COULD** be added. 2/5 included the discovery that the naive approach to the grammar doesn't work and that you needed something more complex. 3/5 then adds the support for the realistic variant of the grammar. I tried to grow the complexity organically and order them with the intent that if you nothing about the code (as was the case for me when I started this work), you would gradually learn all that was needed to make it work in a logical progression. But your suggested re-ordering makes sense if you already know the code base. When 4/5 and 5/5 get reviewed, I will revisit the issue. It's not a big deal to me either way. cheers, danm ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: Optimize new fs state setup
Perversely, do this by eliminating the comparison between stored and
current fs state. On ipers, a perf trace showed try_update_scene_state
using 31% of a CPU, and 98% of that was in 'repz cmpsb', ie, the memcmp.
Taking that out takes try_update_scene_state down to 6.5% of the
profile; more importantly, ipers goes from 10 to 14fps and gears goes
from 790 to 830fps.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_setup.c | 61 ++-
1 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index cbe06e5..9118db5 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -839,42 +839,35 @@ try_update_scene_state( struct lp_setup_context *setup )
setup-dirty |= LP_SETUP_NEW_FS;
}
-
if (setup-dirty LP_SETUP_NEW_FS) {
- if (!setup-fs.stored ||
- memcmp(setup-fs.stored,
- setup-fs.current,
- sizeof setup-fs.current) != 0)
- {
- struct lp_rast_state *stored;
- uint i;
-
- /* The fs state that's been stored in the scene is different from
- * the new, current state. So allocate a new lp_rast_state object
- * and append it to the bin's setup data buffer.
- */
- stored = (struct lp_rast_state *) lp_scene_alloc(scene, sizeof
*stored);
- if (!stored) {
-assert(!new_scene);
-return FALSE;
- }
+ struct lp_rast_state *stored;
+ uint i;
+
+ /* The fs state that's been stored in the scene is different from
+ * the new, current state. So allocate a new lp_rast_state object
+ * and append it to the bin's setup data buffer.
+ */
+ stored = (struct lp_rast_state *) lp_scene_alloc(scene, sizeof *stored);
+ if (!stored) {
+ assert(!new_scene);
+ return FALSE;
+ }
- memcpy(stored,
-setup-fs.current,
-sizeof setup-fs.current);
- setup-fs.stored = stored;
-
- /* The scene now references the textures in the rasterization
- * state record. Note that now.
- */
- for (i = 0; i Elements(setup-fs.current_tex); i++) {
-if (setup-fs.current_tex[i]) {
- if (!lp_scene_add_resource_reference(scene,
-setup-fs.current_tex[i],
-new_scene)) {
- assert(!new_scene);
- return FALSE;
- }
+ memcpy(stored,
+ setup-fs.current,
+ sizeof setup-fs.current);
+ setup-fs.stored = stored;
+
+ /* The scene now references the textures in the rasterization
+ * state record. Note that now.
+ */
+ for (i = 0; i Elements(setup-fs.current_tex); i++) {
+ if (setup-fs.current_tex[i]) {
+if (!lp_scene_add_resource_reference(scene,
+ setup-fs.current_tex[i],
+ new_scene)) {
+ assert(!new_scene);
+ return FALSE;
}
}
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: Don't skip glGetProgramEnvParam4dvARB if there was already an error.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/28/2011 04:49 PM, Eric Anholt wrote:
Fixes a bug caught by oglconform, and now piglit
ARB_vertex_program/getenv4d-with-error. The wrapping of an existing
GL function made it so that we couldn't distinguish an error in
looking up our arguments from an existing error. Instead, make a
helper function to choose the param, and use it from multiple callers.
---
src/mesa/main/arbprogram.c | 119 ---
1 files changed, 55 insertions(+), 64 deletions(-)
diff --git a/src/mesa/main/arbprogram.c b/src/mesa/main/arbprogram.c
index 26d7819..cbc1455 100644
--- a/src/mesa/main/arbprogram.c
+++ b/src/mesa/main/arbprogram.c
@@ -269,6 +269,33 @@ _mesa_IsProgramARB(GLuint id)
return GL_FALSE;
}
+static GLboolean
+get_env_param_pointer(struct gl_context *ctx, const char *func,
+ GLenum target, GLuint index, GLfloat **param)
+{
+ if (target == GL_FRAGMENT_PROGRAM_ARB
+ctx-Extensions.ARB_fragment_program) {
+ if (index = ctx-Const.FragmentProgram.MaxEnvParams) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(index), func);
+ return GL_FALSE;
+ }
+ *param = ctx-FragmentProgram.Parameters[index];
+ return GL_TRUE;
+ }
+ else if (target == GL_VERTEX_PROGRAM_ARB
+ (ctx-Extensions.ARB_vertex_program ||
+ ctx-Extensions.NV_vertex_program)) {
+ if (index = ctx-Const.VertexProgram.MaxEnvParams) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(index), func);
+ return GL_FALSE;
+ }
+ *param = ctx-VertexProgram.Parameters[index];
+ return GL_TRUE;
+ } else {
+ _mesa_error(ctx, GL_INVALID_ENUM, %s(target), func);
+ return GL_FALSE;
+ }
+}
void GLAPIENTRY
_mesa_ProgramStringARB(GLenum target, GLenum format, GLsizei len,
@@ -383,31 +410,19 @@ void GLAPIENTRY
_mesa_ProgramEnvParameter4fARB(GLenum target, GLuint index,
GLfloat x, GLfloat y, GLfloat z, GLfloat w)
{
+ GLfloat *param;
+
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END(ctx);
FLUSH_VERTICES(ctx, _NEW_PROGRAM_CONSTANTS);
- if (target == GL_FRAGMENT_PROGRAM_ARB
-ctx-Extensions.ARB_fragment_program) {
- if (index = ctx-Const.FragmentProgram.MaxEnvParams) {
- _mesa_error(ctx, GL_INVALID_VALUE, glProgramEnvParameter(index));
- return;
- }
- ASSIGN_4V(ctx-FragmentProgram.Parameters[index], x, y, z, w);
- }
- else if (target == GL_VERTEX_PROGRAM_ARB /* == GL_VERTEX_PROGRAM_NV */
-(ctx-Extensions.ARB_vertex_program ||
ctx-Extensions.NV_vertex_program)) {
- if (index = ctx-Const.VertexProgram.MaxEnvParams) {
- _mesa_error(ctx, GL_INVALID_VALUE, glProgramEnvParameter(index));
- return;
- }
- ASSIGN_4V(ctx-VertexProgram.Parameters[index], x, y, z, w);
- }
- else {
- _mesa_error(ctx, GL_INVALID_ENUM, glProgramEnvParameter(target));
+ if (!get_env_param_pointer(ctx, glProgramEnvParameter,
+ target, index, param)) {
return;
}
+
+ ASSIGN_4V(param, x, y, z, w);
Could this be:
if (get_env_param_pointer(ctx, glProgramEnvParameter,
target, index, param)) {
ASSIGN_4V(param, x, y, z, w);
}
}
@@ -422,33 +437,19 @@ void GLAPIENTRY
_mesa_ProgramEnvParameter4fvARB(GLenum target, GLuint index,
const GLfloat *params)
{
+ GLfloat *param;
+
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END(ctx);
FLUSH_VERTICES(ctx, _NEW_PROGRAM_CONSTANTS);
- if (target == GL_FRAGMENT_PROGRAM_ARB
-ctx-Extensions.ARB_fragment_program) {
- if (index = ctx-Const.FragmentProgram.MaxEnvParams) {
- _mesa_error(ctx, GL_INVALID_VALUE,
glProgramEnvParameter4fv(index));
- return;
- }
- memcpy(ctx-FragmentProgram.Parameters[index], params,
- 4 * sizeof(GLfloat));
- }
- else if (target == GL_VERTEX_PROGRAM_ARB /* == GL_VERTEX_PROGRAM_NV */
-(ctx-Extensions.ARB_vertex_program ||
ctx-Extensions.NV_vertex_program)) {
- if (index = ctx-Const.VertexProgram.MaxEnvParams) {
- _mesa_error(ctx, GL_INVALID_VALUE,
glProgramEnvParameter4fv(index));
- return;
- }
- memcpy(ctx-VertexProgram.Parameters[index], params,
- 4 * sizeof(GLfloat));
- }
- else {
- _mesa_error(ctx, GL_INVALID_ENUM, glProgramEnvParameter4fv(target));
+ if (!get_env_param_pointer(ctx, glProgramEnvParameter4fv,
+ target, index, param)) {
return;
}
+
+ memcpy(param, params, 4 * sizeof(GLfloat));
}
@@ -496,15 +497,17 @@ _mesa_GetProgramEnvParameterdvARB(GLenum target, GLuint
index,
GLdouble *params)
{
GET_CURRENT_CONTEXT(ctx);
-
Re: [Mesa-dev] [PATCH 1/2] getenv4d-with-error: New test for a bug in glGetProgramEnvParameter4dARB().
On Wed, 29 Jun 2011 11:56:29 +0200, Gustaw Smolarczyk wielkie...@gmail.com
wrote:
2011/6/29 Eric Anholt e...@anholt.net:
+ if (fabs(test_data[0] - result_data[0]) epsilon ||
+ fabs(test_data[1] - result_data[1]) epsilon ||
+ fabs(test_data[2] - result_data[2]) epsilon ||
+ fabs(test_data[3] - result_data[3]) epsilon) {
+ fprintf(stderr, ProgramEnvParamter4dvARB failed:\n);
+ fprintf(stderr, Expected: (%f %f %f %f)\n,
+ test_data[0],
+ test_data[1],
+ test_data[2],
+ test_data[3]);
+ fprintf(stderr, Expected: (%f %f %f %f)\n,
Shouldn't here be something different than Expected? Maybe Found?
Same in the other patch.
Thanks! Fixed.
pgpkm2ubkkaSv.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] DRI2/GLX: use new swap event types
Use the new swap event type so we get valid SBC values.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Jeremy Huddleston jerem...@apple.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
configure.ac |4 ++--
src/glx/dri2.c |4 ++--
src/glx/glxext.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index acf9f06..7eee611 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,8 +22,8 @@ LIBDRM_REQUIRED=2.4.24
LIBDRM_RADEON_REQUIRED=2.4.24
LIBDRM_INTEL_REQUIRED=2.4.24
LIBDRM_NOUVEAU_REQUIRED=0.6
-DRI2PROTO_REQUIRED=2.1
-GLPROTO_REQUIRED=1.4.11
+DRI2PROTO_REQUIRED=2.6
+GLPROTO_REQUIRED=1.4.14
LIBDRM_XORG_REQUIRED=2.4.24
LIBKMS_XORG_REQUIRED=1.0.0
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index adfd3d1..8654a37 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -97,7 +97,7 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
case DRI2_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
- xDRI2BufferSwapComplete *awire = (xDRI2BufferSwapComplete *)wire;
+ xDRI2BufferSwapComplete2 *awire = (xDRI2BufferSwapComplete2 *)wire;
/* Ignore swap events if we're not looking for them */
aevent-type = dri2GetSwapEventType(dpy, awire-drawable);
@@ -124,7 +124,7 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
}
aevent-ust = ((CARD64)awire-ust_hi 32) | awire-ust_lo;
aevent-msc = ((CARD64)awire-msc_hi 32) | awire-msc_lo;
- aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
+ aevent-sbc = awire-sbc;
return True;
}
#endif
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index 73c3327..40a06a8 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -133,12 +133,12 @@ __glXWireToEvent(Display *dpy, XEvent *event, xEvent
*wire)
case GLX_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
- xGLXBufferSwapComplete *awire = (xGLXBufferSwapComplete *)wire;
+ xGLXBufferSwapComplete2 *awire = (xGLXBufferSwapComplete2 *)wire;
aevent-event_type = awire-event_type;
aevent-drawable = awire-drawable;
aevent-ust = ((CARD64)awire-ust_hi 32) | awire-ust_lo;
aevent-msc = ((CARD64)awire-msc_hi 32) | awire-msc_lo;
- aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
+ aevent-sbc = awire-sbc;
return True;
}
default:
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Optimize new fs state setup
On Wed, 2011-06-29 at 13:19 -0400, Adam Jackson wrote:
Perversely, do this by eliminating the comparison between stored and
current fs state. On ipers, a perf trace showed try_update_scene_state
using 31% of a CPU, and 98% of that was in 'repz cmpsb', ie, the memcmp.
Taking that out takes try_update_scene_state down to 6.5% of the
profile; more importantly, ipers goes from 10 to 14fps and gears goes
from 790 to 830fps.
Some of the motivation for that memcpy is about keeping the memory usage
of the binned scene from exploding and forcing unnecessary flushes on
more complex apps.
I wonder if there is a way to improve the dirty flag handling to avoid
ending up in that memcpy so often?
Note that freeglut is probably dominating your gears numbers by trying
to reinitialize your SpaceBall device (I don't have one either) on every
swapbuffers.
http://lists.freedesktop.org/archives/mesa-dev/2011-February/005599.html
Keith
Signed-off-by: Adam Jackson a...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_setup.c | 61
++-
1 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index cbe06e5..9118db5 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -839,42 +839,35 @@ try_update_scene_state( struct lp_setup_context *setup )
setup-dirty |= LP_SETUP_NEW_FS;
}
-
if (setup-dirty LP_SETUP_NEW_FS) {
- if (!setup-fs.stored ||
- memcmp(setup-fs.stored,
- setup-fs.current,
- sizeof setup-fs.current) != 0)
- {
- struct lp_rast_state *stored;
- uint i;
-
- /* The fs state that's been stored in the scene is different from
- * the new, current state. So allocate a new lp_rast_state object
- * and append it to the bin's setup data buffer.
- */
- stored = (struct lp_rast_state *) lp_scene_alloc(scene, sizeof
*stored);
- if (!stored) {
-assert(!new_scene);
-return FALSE;
- }
+ struct lp_rast_state *stored;
+ uint i;
+
+ /* The fs state that's been stored in the scene is different from
+ * the new, current state. So allocate a new lp_rast_state object
+ * and append it to the bin's setup data buffer.
+ */
+ stored = (struct lp_rast_state *) lp_scene_alloc(scene, sizeof
*stored);
+ if (!stored) {
+ assert(!new_scene);
+ return FALSE;
+ }
- memcpy(stored,
-setup-fs.current,
-sizeof setup-fs.current);
- setup-fs.stored = stored;
-
- /* The scene now references the textures in the rasterization
- * state record. Note that now.
- */
- for (i = 0; i Elements(setup-fs.current_tex); i++) {
-if (setup-fs.current_tex[i]) {
- if (!lp_scene_add_resource_reference(scene,
-setup-fs.current_tex[i],
-new_scene)) {
- assert(!new_scene);
- return FALSE;
- }
+ memcpy(stored,
+ setup-fs.current,
+ sizeof setup-fs.current);
+ setup-fs.stored = stored;
+
+ /* The scene now references the textures in the rasterization
+ * state record. Note that now.
+ */
+ for (i = 0; i Elements(setup-fs.current_tex); i++) {
+ if (setup-fs.current_tex[i]) {
+if (!lp_scene_add_resource_reference(scene,
+ setup-fs.current_tex[i],
+ new_scene)) {
+ assert(!new_scene);
+ return FALSE;
}
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Optimize new fs state setup
Ohh that's interesting, you'd think the comparison shouldn't be that
expensive (though I guess in ipers case the comparison is never true).
memcmp is quite extensively used everywhere. Maybe we could replace that
with something faster (since we only ever care if the blocks are the
same but not care about the lexographic ordering and always compare
whole structs, should compare dwords instead of bytes for a 4 time
speedup)? Or isn't that the reason cmpsb instead of cmpsd is used?
Also I guess it would help if the values which are more likely to be
unequal are first in the struct (if we can tell that).
Of course though if it's unlikely to be the same as the compared value
anyway not comparing at all still might be a win (here).
Roland
Am 29.06.2011 19:19, schrieb Adam Jackson:
Perversely, do this by eliminating the comparison between stored and
current fs state. On ipers, a perf trace showed try_update_scene_state
using 31% of a CPU, and 98% of that was in 'repz cmpsb', ie, the memcmp.
Taking that out takes try_update_scene_state down to 6.5% of the
profile; more importantly, ipers goes from 10 to 14fps and gears goes
from 790 to 830fps.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_setup.c | 61
++-
1 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index cbe06e5..9118db5 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -839,42 +839,35 @@ try_update_scene_state( struct lp_setup_context *setup )
setup-dirty |= LP_SETUP_NEW_FS;
}
-
if (setup-dirty LP_SETUP_NEW_FS) {
- if (!setup-fs.stored ||
- memcmp(setup-fs.stored,
- setup-fs.current,
- sizeof setup-fs.current) != 0)
- {
- struct lp_rast_state *stored;
- uint i;
-
- /* The fs state that's been stored in the scene is different from
- * the new, current state. So allocate a new lp_rast_state object
- * and append it to the bin's setup data buffer.
- */
- stored = (struct lp_rast_state *) lp_scene_alloc(scene, sizeof
*stored);
- if (!stored) {
-assert(!new_scene);
-return FALSE;
- }
+ struct lp_rast_state *stored;
+ uint i;
+
+ /* The fs state that's been stored in the scene is different from
+ * the new, current state. So allocate a new lp_rast_state object
+ * and append it to the bin's setup data buffer.
+ */
+ stored = (struct lp_rast_state *) lp_scene_alloc(scene, sizeof
*stored);
+ if (!stored) {
+ assert(!new_scene);
+ return FALSE;
+ }
- memcpy(stored,
-setup-fs.current,
-sizeof setup-fs.current);
- setup-fs.stored = stored;
-
- /* The scene now references the textures in the rasterization
- * state record. Note that now.
- */
- for (i = 0; i Elements(setup-fs.current_tex); i++) {
-if (setup-fs.current_tex[i]) {
- if (!lp_scene_add_resource_reference(scene,
-setup-fs.current_tex[i],
-new_scene)) {
- assert(!new_scene);
- return FALSE;
- }
+ memcpy(stored,
+ setup-fs.current,
+ sizeof setup-fs.current);
+ setup-fs.stored = stored;
+
+ /* The scene now references the textures in the rasterization
+ * state record. Note that now.
+ */
+ for (i = 0; i Elements(setup-fs.current_tex); i++) {
+ if (setup-fs.current_tex[i]) {
+if (!lp_scene_add_resource_reference(scene,
+ setup-fs.current_tex[i],
+ new_scene)) {
+ assert(!new_scene);
+ return FALSE;
}
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] glsl: Generate IR for switch statements
On 06/28/2011 02:48 PM, Dan McCabe wrote:
Up until now modifying the GLSL compiler has been pretty straightforward.
This is where things get interesting. But still pretty straightforward.
Dan,
This patch looks good! I found a few small issues...nothing major. I
think one more round and it should be ready to go. Comments inline.
Switch statements can be thought of a series of if/then/else statements.
Case labels are compared with the value of a test expression and the case
statements are executed if the comparison is true.
There are a couple of aspects of switch statements that complicate this simple
view of the world. The primary one is that cases can fall through sequentially
to subsequent case, unless a break statement is encountered, in which case,
the switch statement exits completely.
But break handling is further complicated by the fact that a break statement
can impact the exit of a loop. Thus, we need to coordinate break processing
between switch statements and loop statements.
The code generated by a switch statement maintains three temporary state
variables:
int test_value;
bool is_fallthru;
bool is_break;
test_value is initialized to the value of the test expression at the head of
the switch statement. This is the value that case labels are compared against.
is_fallthru is used to sequentially fall through to subsequent cases and is
initialized to false. When a case label matches the test expression, this
state variable is set to true. It will also be forced to false if a break
statement has been encountered. This forcing to false on break MUST be
after every case test. In practice, we defer that forcing to immediately after
the last case comparison prior to executing a case statement, but that is
an optimization.
is_break is used to indicate that a break statement has been executed and is
initialized to false. When a break statement is encountered, it is set to
true.
This state variable is then used to conditionally force is_fallthru to to
false
to prevent subsequent case statements from executing.
Code generation for break statements depends on whether the break statement is
inside a switch statement or inside a loop statement. If it inside a loop
statement is inside a break statement, the same code as before gets generated.
But if a switch statement is inside a loop statement, code is emitted to set
the is_break state to true.
Just as ASTs for loop statements are managed in a stack-like
manner to handle nesting, we also add a bool to capture the innermost switch
or loop condition. Note that we still need to maintain a loop AST stack to
properly handle for-loop code generation on a continue statement. Technically,
we don't (yet) need a switch AST stack, but I am using one for orthogonality
with loop statements, in anticipation of future use. Note that a simple
boolean stack would have sufficed.
We will illustrate a switch statement with its analogous conditional code that
a switch statement corresponds to by examining an example.
Consider the following switch statement:
switch (42) {
case 0:
case 1:
gl_FragColor = vec4(1.0, 2.0, 3.0, 4.0);
case 2:
case 3:
gl_FragColor = vec4(4.0, 3.0, 2.0, 1.0);
break;
case 4:
default:
gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);
}
Note that case 0 and case 1 fall through to cases 2 and 3 if they occur.
Note that case 4 and the default case must be reached explicitly, since cases
2 and 3 break at the end of their case.
Finally, note that case 4 and the default case don't break but simply fall
through to the end of the switch.
For this code, the equivalent code can be expressed as:
int test_val = 42; // capture value of test expression
bool is_fallthru = false; // prevent initial fall through
bool is_break = false; // capture the execution of a break stmt
is_fallthru |= (test_val == 0); // enable fallthru on case 0
is_fallthru |= (test_val == 1); // enable fallthru on case 1
is_fallthru = !is_break; // inhibit fallthru on previous break
if (is_fallthru) {
gl_FragColor = vec4(1.0, 2.0, 3.0, 4.0);
}
is_fallthru |= (test_val == 2); // enable fallthru on case 2
is_fallthru |= (test_val == 3); // enable fallthru on case 3
is_fallthru = !is_break; // inhibit fallthru on previous break
if (is_fallthru) {
gl_FragColor = vec4(4.0, 3.0, 2.0, 1.0);
is_break = true; // inhibit all subsequent fallthru for break
}
is_fallthru |= (test_val == 4); // enable fallthru on case 4
is_fallthru = true; // enable fallthru for default case
is_fallthru = !is_break; // inhibit fallthru on previous break
if (is_fallthru) {
gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);
}
The code generate for
Re: [Mesa-dev] [PATCH 4/5] glsl: Reference data structure ctors in grammar
On 06/28/2011 02:48 PM, Dan McCabe wrote: We now tie the grammar to the ctors of the ASTs they reference. This requires that we actually have definitions of the ctors. In addition, we also need to define print and hir methods for the AST classes. The Print methods are pretty simple to flesh out. However, at this stage of the development, we simply stub out the hir methods and flesh them out later. Also, since actual class instances get returned by the productions in the grammar, we also need to designate the type of the productions that reference those instances. --- src/glsl/ast_to_hir.cpp | 54 + src/glsl/glsl_parser.yy | 55 +++-- src/glsl/glsl_parser_extras.cpp | 100 +++ 3 files changed, 193 insertions(+), 16 deletions(-) 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] How to submit a patch?
On Wed, Jun 29, 2011 at 10:34 AM, Micael kam1k...@gmail.com wrote: Hi I'm new here, and I'm looking for a way to submit a patch that I have created that fixes an index out of bounds issue. I already attached the patch to the bug report in question (https://bugs.freedesktop.org/show_bug.cgi?id=34495). Is that enough? Please send the patch to this list for review. Thanks! Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] glsl: Generate IR for switch statements
Right back at ya', comments in-line, in response to your in-line comments.
Thanks for the good feedback and review.
cheers, danm
On 06/29/2011 12:53 PM, Kenneth Graunke wrote:
On 06/28/2011 02:48 PM, Dan McCabe wrote:
Up until now modifying the GLSL compiler has been pretty straightforward.
This is where things get interesting. But still pretty straightforward.
Dan,
This patch looks good! I found a few small issues...nothing major. I
think one more round and it should be ready to go. Comments inline.
Switch statements can be thought of a series of if/then/else statements.
Case labels are compared with the value of a test expression and the case
statements are executed if the comparison is true.
There are a couple of aspects of switch statements that complicate this simple
view of the world. The primary one is that cases can fall through sequentially
to subsequent case, unless a break statement is encountered, in which case,
the switch statement exits completely.
But break handling is further complicated by the fact that a break statement
can impact the exit of a loop. Thus, we need to coordinate break processing
between switch statements and loop statements.
The code generated by a switch statement maintains three temporary state
variables:
int test_value;
bool is_fallthru;
bool is_break;
test_value is initialized to the value of the test expression at the head of
the switch statement. This is the value that case labels are compared against.
is_fallthru is used to sequentially fall through to subsequent cases and is
initialized to false. When a case label matches the test expression, this
state variable is set to true. It will also be forced to false if a break
statement has been encountered. This forcing to false on break MUST be
after every case test. In practice, we defer that forcing to immediately after
the last case comparison prior to executing a case statement, but that is
an optimization.
is_break is used to indicate that a break statement has been executed and is
initialized to false. When a break statement is encountered, it is set to true.
This state variable is then used to conditionally force is_fallthru to to false
to prevent subsequent case statements from executing.
Code generation for break statements depends on whether the break statement is
inside a switch statement or inside a loop statement. If it inside a loop
statement is inside a break statement, the same code as before gets generated.
But if a switch statement is inside a loop statement, code is emitted to set
the is_break state to true.
Just as ASTs for loop statements are managed in a stack-like
manner to handle nesting, we also add a bool to capture the innermost switch
or loop condition. Note that we still need to maintain a loop AST stack to
properly handle for-loop code generation on a continue statement. Technically,
we don't (yet) need a switch AST stack, but I am using one for orthogonality
with loop statements, in anticipation of future use. Note that a simple
boolean stack would have sufficed.
We will illustrate a switch statement with its analogous conditional code that
a switch statement corresponds to by examining an example.
Consider the following switch statement:
switch (42) {
case 0:
case 1:
gl_FragColor = vec4(1.0, 2.0, 3.0, 4.0);
case 2:
case 3:
gl_FragColor = vec4(4.0, 3.0, 2.0, 1.0);
break;
case 4:
default:
gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);
}
Note that case 0 and case 1 fall through to cases 2 and 3 if they occur.
Note that case 4 and the default case must be reached explicitly, since cases
2 and 3 break at the end of their case.
Finally, note that case 4 and the default case don't break but simply fall
through to the end of the switch.
For this code, the equivalent code can be expressed as:
int test_val = 42; // capture value of test expression
bool is_fallthru = false; // prevent initial fall through
bool is_break = false; // capture the execution of a break stmt
is_fallthru |= (test_val == 0); // enable fallthru on case 0
is_fallthru |= (test_val == 1); // enable fallthru on case 1
is_fallthru= !is_break; // inhibit fallthru on previous break
if (is_fallthru) {
gl_FragColor = vec4(1.0, 2.0, 3.0, 4.0);
}
is_fallthru |= (test_val == 2); // enable fallthru on case 2
is_fallthru |= (test_val == 3); // enable fallthru on case 3
is_fallthru= !is_break; // inhibit fallthru on previous break
if (is_fallthru) {
gl_FragColor = vec4(4.0, 3.0, 2.0, 1.0);
is_break = true; // inhibit all subsequent fallthru for break
}
is_fallthru |= (test_val == 4); // enable fallthru on case 4
is_fallthru = true; // enable fallthru for default case
is_fallthru= !is_break; // inhibit
[Mesa-dev] [PATCH 3/5] intel: Remove now trivial intel_renderbuffer_set_{hiz_, }region().
Note that as a result of this cleanup a bug in
intel_process_dri2_buffer_no_separate_stencil() beomes quite apparent.
---
src/mesa/drivers/dri/intel/intel_context.c | 40
src/mesa/drivers/dri/intel/intel_fbo.c | 19 -
src/mesa/drivers/dri/intel/intel_fbo.h | 12
3 files changed, 17 insertions(+), 54 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 547d81b..91f6c6d 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -1112,7 +1112,6 @@ intel_query_dri2_buffers_no_separate_stencil(struct
intel_context *intel,
*
* \see intel_update_renderbuffers()
* \see intel_region_alloc_for_handle()
- * \see intel_renderbuffer_set_region()
*/
static void
intel_process_dri2_buffer_no_separate_stencil(struct intel_context *intel,
@@ -1124,7 +1123,6 @@ intel_process_dri2_buffer_no_separate_stencil(struct
intel_context *intel,
assert(!intel-must_use_separate_stencil);
struct gl_framebuffer *fb = drawable-driverPrivate;
- struct intel_region *region = NULL;
struct intel_renderbuffer *depth_rb = NULL;
if (!rb)
@@ -1151,20 +1149,18 @@ intel_process_dri2_buffer_no_separate_stencil(struct
intel_context *intel,
if (unlikely(INTEL_DEBUG DEBUG_DRI)) {
fprintf(stderr, (reusing depth buffer as stencil)\n);
}
- intel_region_reference(region, depth_rb-region);
+ intel_region_reference(rb-region, depth_rb-region);
} else {
- region = intel_region_alloc_for_handle(intel-intelScreen,
-buffer-cpp,
-drawable-w,
-drawable-h,
-buffer-pitch / buffer-cpp,
-buffer-name,
-buffer_name);
+ intel_region_release(rb-region);
+ rb-region = intel_region_alloc_for_handle(intel-intelScreen,
+buffer-cpp,
+drawable-w,
+drawable-h,
+buffer-pitch / buffer-cpp,
+buffer-name,
+buffer_name);
}
- intel_renderbuffer_set_region(intel, rb, region);
- intel_region_release(region);
-
if (buffer-attachment == __DRI_BUFFER_DEPTH_STENCIL) {
struct intel_renderbuffer *stencil_rb =
intel_get_renderbuffer(fb, BUFFER_STENCIL);
@@ -1175,7 +1171,8 @@ intel_process_dri2_buffer_no_separate_stencil(struct
intel_context *intel,
if (stencil_rb-region stencil_rb-region-name == buffer-name)
return;
- intel_renderbuffer_set_region(intel, stencil_rb, region);
+ /* XXX: Surely this is incorrect. */
+ intel_region_reference(stencil_rb-region, NULL);
}
}
@@ -1300,7 +1297,6 @@ intel_query_dri2_buffers_with_separate_stencil(struct
intel_context *intel,
*
* \see intel_update_renderbuffers()
* \see intel_region_alloc_for_handle()
- * \see intel_renderbuffer_set_region()
* \see enum intel_dri2_has_hiz
*/
static void
@@ -1360,9 +1356,9 @@ intel_process_dri2_buffer_with_separate_stencil(struct
intel_context *intel,
buffer_name);
if (buffer-attachment == __DRI_BUFFER_HIZ) {
- intel_renderbuffer_set_hiz_region(intel, rb, region);
+ intel_region_reference(rb-hiz_region, region);
} else {
- intel_renderbuffer_set_region(intel, rb, region);
+ intel_region_reference(rb-region, region);
}
intel_region_release(region);
@@ -1511,12 +1507,10 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
/ depth_stencil_buffer-cpp,
depth_stencil_buffer-name,
dri2 depth / stencil buffer);
-intel_renderbuffer_set_region(intel,
- intel_get_renderbuffer(fb, BUFFER_DEPTH),
- region);
-intel_renderbuffer_set_region(intel,
- intel_get_renderbuffer(fb,
BUFFER_STENCIL),
- region);
+intel_region_reference(intel_get_renderbuffer(fb,
BUFFER_DEPTH)-region,
+ region);
+intel_region_reference(intel_get_renderbuffer(fb,
BUFFER_STENCIL)-region,
+ region);
intel_region_release(region);
}
}
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index ee656ed..1246002 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++
[Mesa-dev] [PATCH 4/5] intel: Remove gratuitous context checks in intel_delete_renderbuffer().
Even if we don't have a current context, if we're freeing the rb we
should free its region (and BO). The renderbuffer unreference checks
appear to be just cargo-cult from the region unreference code.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30217
---
src/mesa/drivers/dri/intel/intel_fbo.c | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 1246002..1669af2 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -70,24 +70,15 @@ intel_new_framebuffer(struct gl_context * ctx, GLuint name)
static void
intel_delete_renderbuffer(struct gl_renderbuffer *rb)
{
- GET_CURRENT_CONTEXT(ctx);
- struct intel_context *intel = intel_context(ctx);
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
ASSERT(irb);
- if (intel irb-region) {
- intel_region_release(irb-region);
- }
- if (intel irb-hiz_region) {
- intel_region_release(irb-hiz_region);
- }
- if (intel irb-wrapped_depth) {
- _mesa_reference_renderbuffer(irb-wrapped_depth, NULL);
- }
- if (intel irb-wrapped_stencil) {
- _mesa_reference_renderbuffer(irb-wrapped_stencil, NULL);
- }
+ intel_region_release(irb-region);
+ intel_region_release(irb-hiz_region);
+
+ _mesa_reference_renderbuffer(irb-wrapped_depth, NULL);
+ _mesa_reference_renderbuffer(irb-wrapped_stencil, NULL);
free(irb);
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] intel: Allow intel_region_reference() with *dst != NULL.
This should help us avoid leaking regions in region reference code by
making the API more predictable.
---
src/mesa/drivers/dri/intel/intel_regions.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_regions.c
b/src/mesa/drivers/dri/intel/intel_regions.c
index a4da1ce..6cf37c4 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.c
+++ b/src/mesa/drivers/dri/intel/intel_regions.c
@@ -264,11 +264,13 @@ intel_region_alloc_for_handle(struct intel_screen *screen,
void
intel_region_reference(struct intel_region **dst, struct intel_region *src)
{
- if (src)
- _DBG(%s %p %d\n, __FUNCTION__, src, src-refcount);
+ _DBG(%s: %p(%d) - %p(%d)\n, __FUNCTION__,
+ *dst, *dst ? (*dst)-refcount : 0, src, src ? src-refcount : 0);
+
+ if (src != *dst) {
+ if (*dst)
+intel_region_release(dst);
- assert(*dst == NULL);
- if (src) {
src-refcount++;
*dst = src;
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] intel: Rely on intel_region_reference()'s support of *dst != NULL.
---
src/mesa/drivers/dri/i915/i830_vtbl.c |2 --
src/mesa/drivers/dri/i915/i915_vtbl.c |2 --
src/mesa/drivers/dri/intel/intel_fbo.c| 13 -
src/mesa/drivers/dri/intel/intel_screen.c |1 -
4 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 584df82..7775e71 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -618,11 +618,9 @@ i830_set_draw_region(struct intel_context *intel,
uint32_t draw_x, draw_y;
if (state-draw_region != color_regions[0]) {
- intel_region_release(state-draw_region);
intel_region_reference(state-draw_region, color_regions[0]);
}
if (state-depth_region != depth_region) {
- intel_region_release(state-depth_region);
intel_region_reference(state-depth_region, depth_region);
}
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index 9721a1c..cd7d108 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -570,11 +570,9 @@ i915_set_draw_region(struct intel_context *intel,
uint32_t draw_x, draw_y, draw_offset;
if (state-draw_region != color_regions[0]) {
- intel_region_release(state-draw_region);
intel_region_reference(state-draw_region, color_regions[0]);
}
if (state-depth_region != depth_region) {
- intel_region_release(state-depth_region);
intel_region_reference(state-depth_region, depth_region);
}
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 90c3909..ee656ed 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -277,8 +277,6 @@ intel_image_target_renderbuffer_storage(struct gl_context
*ctx,
return;
irb = intel_renderbuffer(rb);
- if (irb-region)
- intel_region_release(irb-region);
intel_region_reference(irb-region, image-region);
rb-InternalFormat = image-internal_format;
@@ -351,12 +349,7 @@ intel_renderbuffer_set_region(struct intel_context *intel,
struct intel_renderbuffer *rb,
struct intel_region *region)
{
- struct intel_region *old;
-
- old = rb-region;
- rb-region = NULL;
intel_region_reference(rb-region, region);
- intel_region_release(old);
}
@@ -365,10 +358,7 @@ intel_renderbuffer_set_hiz_region(struct intel_context
*intel,
struct intel_renderbuffer *rb,
struct intel_region *region)
{
- struct intel_region *old = rb-hiz_region;
- rb-hiz_region = NULL;
intel_region_reference(rb-hiz_region, region);
- intel_region_release(old);
}
@@ -572,7 +562,6 @@ intel_update_tex_wrapper_regions(struct intel_context
*intel,
/* Point the renderbuffer's region to the texture's region. */
if (irb-region != intel_image-mt-region) {
- intel_region_release(irb-region);
intel_region_reference(irb-region, intel_image-mt-region);
}
@@ -592,7 +581,6 @@ intel_update_tex_wrapper_regions(struct intel_context
*intel,
/* Point the renderbuffer's hiz region to the texture's hiz region. */
if (irb-hiz_region != intel_image-mt-hiz_region) {
- intel_region_release(irb-hiz_region);
intel_region_reference(irb-hiz_region, intel_image-mt-hiz_region);
}
@@ -770,7 +758,6 @@ intel_render_texture(struct gl_context * ctx,
intel_image-mt = new_mt;
intel_renderbuffer_set_draw_offset(irb, intel_image, att-Zoffset);
- intel_region_release(irb-region);
intel_region_reference(irb-region, intel_image-mt-region);
}
#endif
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 2a3a601..bd8d574 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -291,7 +291,6 @@ intel_dup_image(__DRIimage *orig_image, void *loaderPrivate)
if (image == NULL)
return NULL;
- image-region = NULL;
intel_region_reference(image-region, orig_image-region);
if (image-region == NULL) {
FREE(image);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] i915: Fix leak of ViewportMatrix data on context destroy.
From: John jpsinthe...@verizon.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30217 --- src/mesa/drivers/dri/intel/intel_context.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index 91f6c6d..eef2c58 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -922,6 +922,8 @@ intelDestroyContext(__DRIcontext * driContextPriv) /* free the Mesa context */ _mesa_free_context_data(intel-ctx); + _math_matrix_dtr(intel-ViewportMatrix); + FREE(intel); driContextPriv-driverPrivate = NULL; } -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Optimize new fs state setup
Actually I ran some numbers here and tried out a optimized struct compare:
original ipers: 12.1 fps
ajax patch: 15.5 fps
optimized struct compare: 16.8 fps
This is the function I used for that (just enabled in that lp_setup
function):
static INLINE int util_cmp_struct(const void *src1, const void *src2,
unsigned count)
{
/* hmm pointer casting is evil */
const uint32_t *src1_ptr = (uint32_t *)src1;
const uint32_t *src2_ptr = (uint32_t *)src2;
unsigned i;
assert(count % 4 == 0);
for (i = 0; i count/4; i++) {
if (*src1_ptr != *src2_ptr) {
return 1;
}
src1_ptr++;
src2_ptr++;
}
return 0;
}
(And no this doesn't use repz cmpsd here.)
So, unless I made some mistake, memcmp is just dead slow (*), most of
the slowness probably coming from the bytewise comparison (and
apparently I was wrong in assuming the comparison there might never be
the same for ipers).
Of course, the optimized struct compare relies on structs really being
dword aligned (I think this is always the case), and additionally it
relies on the struct size being a whole multiple of dwords - likely
struct needs padding to ensure that (at least I don't think this is
always guaranteed for all structs).
But since memcmp is used extensively (cso for one) maybe some
optimization along these lines might be worth it (though of course for
small structs the win isn't going to be as big - and can't beat the repz
cmps in code size...).
Roland
(*) I actually found some references some implementations might be
better they don't just use repz cmpsb but they split this up in parts
which do dword (or qword even - well for really large structs could use
sse2) comparisons for the parts where it's possible and only byte
comparisons for the remaining bytes (and if the compiler does that it
probably would know the size at compile time here hence could leave out
much of the code). Of course memcmp requires that the return value isn't
just a true or false value, hence there's more code needed once an
unequal dword is found, though the compiler could optimize that away too
in case it's not needed. Much the same as memcpy is optimized usually
really, so blame gcc :-).
Am 29.06.2011 20:33, schrieb Roland Scheidegger:
Ohh that's interesting, you'd think the comparison shouldn't be that
expensive (though I guess in ipers case the comparison is never true).
memcmp is quite extensively used everywhere. Maybe we could replace that
with something faster (since we only ever care if the blocks are the
same but not care about the lexographic ordering and always compare
whole structs, should compare dwords instead of bytes for a 4 time
speedup)? Or isn't that the reason cmpsb instead of cmpsd is used?
Also I guess it would help if the values which are more likely to be
unequal are first in the struct (if we can tell that).
Of course though if it's unlikely to be the same as the compared value
anyway not comparing at all still might be a win (here).
Roland
Am 29.06.2011 19:19, schrieb Adam Jackson:
Perversely, do this by eliminating the comparison between stored and
current fs state. On ipers, a perf trace showed try_update_scene_state
using 31% of a CPU, and 98% of that was in 'repz cmpsb', ie, the memcmp.
Taking that out takes try_update_scene_state down to 6.5% of the
profile; more importantly, ipers goes from 10 to 14fps and gears goes
from 790 to 830fps.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_setup.c | 61
++-
1 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index cbe06e5..9118db5 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -839,42 +839,35 @@ try_update_scene_state( struct lp_setup_context *setup
)
setup-dirty |= LP_SETUP_NEW_FS;
}
-
if (setup-dirty LP_SETUP_NEW_FS) {
- if (!setup-fs.stored ||
- memcmp(setup-fs.stored,
- setup-fs.current,
- sizeof setup-fs.current) != 0)
- {
- struct lp_rast_state *stored;
- uint i;
-
- /* The fs state that's been stored in the scene is different from
- * the new, current state. So allocate a new lp_rast_state object
- * and append it to the bin's setup data buffer.
- */
- stored = (struct lp_rast_state *) lp_scene_alloc(scene, sizeof
*stored);
- if (!stored) {
-assert(!new_scene);
-return FALSE;
- }
+ struct lp_rast_state *stored;
+ uint i;
+
+ /* The fs state that's been stored in the scene is different from
+ * the new, current state. So allocate a new lp_rast_state object
+ * and append it to the bin's setup data buffer.
+ */
+ stored = (struct lp_rast_state *) lp_scene_alloc(scene,
Re: [Mesa-dev] [PATCH 4/9] i965: Implement new ir_unop_u2i and ir_unop_i2u opcodes.
On Wed, 15 Jun 2011 00:49:33 -0700, Kenneth Graunke kenn...@whitecape.org wrote: No MOV is necessary since signed/unsigned integers share the same bit-representation; it's simply a question of interpretation. In particular, the fs_reg::imm union shouldn't need updating. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- .../dri/i965/brw_fs_channel_expressions.cpp|2 ++ src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |6 ++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp b/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp index 7f3f528..46677a6 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp @@ -191,6 +191,8 @@ ir_channel_expressions_visitor::visit_leave(ir_assignment *ir) case ir_unop_log: case ir_unop_exp2: case ir_unop_log2: + case ir_unop_i2u: + case ir_unop_u2i: case ir_unop_f2i: case ir_unop_i2f: case ir_unop_f2b: diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index b485787..3c415b2 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -349,6 +349,12 @@ fs_visitor::visit(ir_expression *ir) emit_math(FS_OPCODE_RSQ, this-result, op[0]); break; + case ir_unop_i2u: + this-result.type = BRW_REGISTER_TYPE_UD; + break; + case ir_unop_u2i: + this-result.type = BRW_REGISTER_TYPE_D; + break; Comparing these opcodes to ir_unop_neg, I think you mean: op[0].type = WHATEVER; this-result = op[0]; sounds like we don't have any execution tests for these new opcodes? pgpcXhOwA8IWC.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How to submit a patch?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/29/2011 07:34 AM, Micael wrote: I'm new here, and I'm looking for a way to submit a patch that I have created that fixes an index out of bounds issue. I already attached the patch to the bug report in question (https://bugs.freedesktop.org/show_bug.cgi?id=34495). Is that enough? The preferred way is to send the patch to the mailing list using git-send-email. Sending the patch as an attachment makes it impractical for most people to respond to the patch with comments in line. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4LuO0ACgkQX1gOwKyEAw/j6ACffFXO0l7VXUn/w9os5FeXbMt0 iOIAnRKcTj0J6S6tNGNQuMvxwE1chf5O =84Fq -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Optimize new fs state setup
I didn't even look at that was just curious why the memcmp (which is
used a lot in other places) is slow. However, none of the other memcmp
seem to show up prominently (cso functions are quite low in profiles,
_mesa_search_program_cache uses memcmp too but it's not that high
neither). So I guess those functions either aren't called that often or
the sizes they compare are small.
So should maybe just file a gcc bug for memcmp and look at that
particular llvmpipe issue again :-).
Roland
Am 30.06.2011 01:16, schrieb Corbin Simpson:
Okay, so maybe I'm failing to recognize the exact situation here, but
wouldn't it be possible to mark the FS state with a serial number and
just compare those? Or are these FS states not CSO-cached?
~ C.
On Wed, Jun 29, 2011 at 3:44 PM, Roland Scheidegger srol...@vmware.com
wrote:
Actually I ran some numbers here and tried out a optimized struct compare:
original ipers: 12.1 fps
ajax patch: 15.5 fps
optimized struct compare: 16.8 fps
This is the function I used for that (just enabled in that lp_setup
function):
static INLINE int util_cmp_struct(const void *src1, const void *src2,
unsigned count)
{
/* hmm pointer casting is evil */
const uint32_t *src1_ptr = (uint32_t *)src1;
const uint32_t *src2_ptr = (uint32_t *)src2;
unsigned i;
assert(count % 4 == 0);
for (i = 0; i count/4; i++) {
if (*src1_ptr != *src2_ptr) {
return 1;
}
src1_ptr++;
src2_ptr++;
}
return 0;
}
(And no this doesn't use repz cmpsd here.)
So, unless I made some mistake, memcmp is just dead slow (*), most of
the slowness probably coming from the bytewise comparison (and
apparently I was wrong in assuming the comparison there might never be
the same for ipers).
Of course, the optimized struct compare relies on structs really being
dword aligned (I think this is always the case), and additionally it
relies on the struct size being a whole multiple of dwords - likely
struct needs padding to ensure that (at least I don't think this is
always guaranteed for all structs).
But since memcmp is used extensively (cso for one) maybe some
optimization along these lines might be worth it (though of course for
small structs the win isn't going to be as big - and can't beat the repz
cmps in code size...).
Roland
(*) I actually found some references some implementations might be
better they don't just use repz cmpsb but they split this up in parts
which do dword (or qword even - well for really large structs could use
sse2) comparisons for the parts where it's possible and only byte
comparisons for the remaining bytes (and if the compiler does that it
probably would know the size at compile time here hence could leave out
much of the code). Of course memcmp requires that the return value isn't
just a true or false value, hence there's more code needed once an
unequal dword is found, though the compiler could optimize that away too
in case it's not needed. Much the same as memcpy is optimized usually
really, so blame gcc :-).
Am 29.06.2011 20:33, schrieb Roland Scheidegger:
Ohh that's interesting, you'd think the comparison shouldn't be that
expensive (though I guess in ipers case the comparison is never true).
memcmp is quite extensively used everywhere. Maybe we could replace that
with something faster (since we only ever care if the blocks are the
same but not care about the lexographic ordering and always compare
whole structs, should compare dwords instead of bytes for a 4 time
speedup)? Or isn't that the reason cmpsb instead of cmpsd is used?
Also I guess it would help if the values which are more likely to be
unequal are first in the struct (if we can tell that).
Of course though if it's unlikely to be the same as the compared value
anyway not comparing at all still might be a win (here).
Roland
Am 29.06.2011 19:19, schrieb Adam Jackson:
Perversely, do this by eliminating the comparison between stored and
current fs state. On ipers, a perf trace showed try_update_scene_state
using 31% of a CPU, and 98% of that was in 'repz cmpsb', ie, the memcmp.
Taking that out takes try_update_scene_state down to 6.5% of the
profile; more importantly, ipers goes from 10 to 14fps and gears goes
from 790 to 830fps.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_setup.c | 61
++-
1 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index cbe06e5..9118db5 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -839,42 +839,35 @@ try_update_scene_state( struct lp_setup_context
*setup )
setup-dirty |= LP_SETUP_NEW_FS;
}
-
if (setup-dirty LP_SETUP_NEW_FS) {
- if (!setup-fs.stored ||
- memcmp(setup-fs.stored,
- setup-fs.current,
- sizeof
[Mesa-dev] [PATCH] i965/fs: Fix message register allocation in FB writes.
Commit 6750226e6d915742ebf96bae2cfcdd287b85db35 bumped the base MRF to
m2 instead of m0, but failed to adjust inst-mlen, which was being set
to the highest MRF. Subtracting the base MRF solves the issue.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 9091014..cbe5cf4 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1791,7 +1791,8 @@ fs_visitor::emit_fb_writes()
{
this-current_annotation = FB write header;
GLboolean header_present = GL_TRUE;
- int nr = 2;
+ int base_mrf = 2;
+ int nr = base_mrf;
int reg_width = c-dispatch_width / 8;
if (intel-gen = 6
@@ -1870,8 +1871,8 @@ fs_visitor::emit_fb_writes()
fs_inst *inst = emit(FS_OPCODE_FB_WRITE);
inst-target = target;
- inst-base_mrf = 2;
- inst-mlen = nr;
+ inst-base_mrf = base_mrf;
+ inst-mlen = nr - base_mrf;
if (target == c-key.nr_color_regions - 1)
inst-eot = true;
inst-header_present = header_present;
@@ -1888,8 +1889,8 @@ fs_visitor::emit_fb_writes()
}
fs_inst *inst = emit(FS_OPCODE_FB_WRITE);
- inst-base_mrf = 2;
- inst-mlen = nr;
+ inst-base_mrf = base_mrf;
+ inst-mlen = nr - base_mrf;
inst-eot = true;
inst-header_present = header_present;
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38789] New: [bisected] Hacks cubestorm, noof and pipes from XScreenSaver stopped displaying anything
https://bugs.freedesktop.org/show_bug.cgi?id=38789 Summary: [bisected] Hacks cubestorm, noof and pipes from XScreenSaver stopped displaying anything Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: jlp.b...@gmail.com Today I noticed that instead of my screensaver only black color was shown. The screensaver was a hack noof from XScreenSaver. I bisected the commits and the one causing the problem was: ac8fdbc1c723afb19eeaba5457ba78d0bf33b8d4 st-api: Rework how drawables are invalidated v3. I also went through all the OpenGL XScreeenSaver hacks and noticed that 3 of them are affected by the same problem: cubestorm, noof and pipes. The hardware I'm using is AMD Radeon HD 5750 with r600g driver. -- 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] llvmpipe: Optimize new fs state setup
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame and loses to glibc's
memcmp (including call overhead, no knowledge about alignment etc.) even
when comparing only very few bytes (and loses BIG time for lots of bytes
to compare). Oops. Well at least if the strings are the same (I'd guess
if the first byte is different it's hard to beat the gcc builtin...).
So this is really a gcc bug. The bug is quite old though with no fix in
sight apparently so might need to think about some workaround (but just
not doing the comparison doesn't look like the right idea, since
apparently it would be faster with the comparison if gcc's memcmp got
fixed).
Roland
Am 30.06.2011 01:47, schrieb Roland Scheidegger:
I didn't even look at that was just curious why the memcmp (which is
used a lot in other places) is slow. However, none of the other memcmp
seem to show up prominently (cso functions are quite low in profiles,
_mesa_search_program_cache uses memcmp too but it's not that high
neither). So I guess those functions either aren't called that often or
the sizes they compare are small.
So should maybe just file a gcc bug for memcmp and look at that
particular llvmpipe issue again :-).
Roland
Am 30.06.2011 01:16, schrieb Corbin Simpson:
Okay, so maybe I'm failing to recognize the exact situation here, but
wouldn't it be possible to mark the FS state with a serial number and
just compare those? Or are these FS states not CSO-cached?
~ C.
On Wed, Jun 29, 2011 at 3:44 PM, Roland Scheidegger srol...@vmware.com
wrote:
Actually I ran some numbers here and tried out a optimized struct compare:
original ipers: 12.1 fps
ajax patch: 15.5 fps
optimized struct compare: 16.8 fps
This is the function I used for that (just enabled in that lp_setup
function):
static INLINE int util_cmp_struct(const void *src1, const void *src2,
unsigned count)
{
/* hmm pointer casting is evil */
const uint32_t *src1_ptr = (uint32_t *)src1;
const uint32_t *src2_ptr = (uint32_t *)src2;
unsigned i;
assert(count % 4 == 0);
for (i = 0; i count/4; i++) {
if (*src1_ptr != *src2_ptr) {
return 1;
}
src1_ptr++;
src2_ptr++;
}
return 0;
}
(And no this doesn't use repz cmpsd here.)
So, unless I made some mistake, memcmp is just dead slow (*), most of
the slowness probably coming from the bytewise comparison (and
apparently I was wrong in assuming the comparison there might never be
the same for ipers).
Of course, the optimized struct compare relies on structs really being
dword aligned (I think this is always the case), and additionally it
relies on the struct size being a whole multiple of dwords - likely
struct needs padding to ensure that (at least I don't think this is
always guaranteed for all structs).
But since memcmp is used extensively (cso for one) maybe some
optimization along these lines might be worth it (though of course for
small structs the win isn't going to be as big - and can't beat the repz
cmps in code size...).
Roland
(*) I actually found some references some implementations might be
better they don't just use repz cmpsb but they split this up in parts
which do dword (or qword even - well for really large structs could use
sse2) comparisons for the parts where it's possible and only byte
comparisons for the remaining bytes (and if the compiler does that it
probably would know the size at compile time here hence could leave out
much of the code). Of course memcmp requires that the return value isn't
just a true or false value, hence there's more code needed once an
unequal dword is found, though the compiler could optimize that away too
in case it's not needed. Much the same as memcpy is optimized usually
really, so blame gcc :-).
Am 29.06.2011 20:33, schrieb Roland Scheidegger:
Ohh that's interesting, you'd think the comparison shouldn't be that
expensive (though I guess in ipers case the comparison is never true).
memcmp is quite extensively used everywhere. Maybe we could replace that
with something faster (since we only ever care if the blocks are the
same but not care about the lexographic ordering and always compare
whole structs, should compare dwords instead of bytes for a 4 time
speedup)? Or isn't that the reason cmpsb instead of cmpsd is used?
Also I guess it would help if the values which are more likely to be
unequal are first in the struct (if we can tell that).
Of course though if it's unlikely to be the same as the compared value
anyway not comparing at all still might be a win (here).
Roland
Am 29.06.2011 19:19, schrieb Adam Jackson:
Perversely, do this by eliminating the comparison between stored and
current fs state. On ipers, a perf trace showed try_update_scene_state
using 31% of a CPU, and 98% of that was in 'repz cmpsb', ie, the memcmp.
Taking that out takes try_update_scene_state down to 6.5% of the
Re: [Mesa-dev] [PATCH-RFC] autoconf: add --enable-{dri,glx,osmesa}
On Sun, Jun 26, 2011 at 10:39 PM, Chia-I Wu olva...@gmail.com wrote:
From: Chia-I Wu o...@lunarg.com
The idea is that DRI driver, libGL and libOSMesa are libraries that can
be independently enabled, yet --with-driver does not allow us to easily
do that, if not impossible. This also matches what
--enable-{egl,xorg,d3d1x} do for the respective libraries.
There are two libGL providers: Xlib-based and DRI-based. They cannot
coexist. To be able to choose between them, --enable-xlib-glx is also
added.
With this commit, --with-driver=dri can be replaced by
$ ./configure --enable-dri --enable-glx --disable-osmesa
--with-driver=xlib can be replaced by
$ ./configure --disable-dri --enable-glx --enable-osmesa \
--enable-xlib-glx
and --with-driver=osmesa can be replaced by
$ ./configure --disable-dri --disable-glx --enable-osmesa
Some combinations that cannot be supported with --with-driver will
produce errors at the moment. But in the future, we would like to
support, for example,
$ ./configure --enable-dri --disable-glx --enable-egl
(build libEGL and DRI drivers, but not libGL)
Note that this commit still keeps --with-driver for transitional
purpose.
If there is no objection, I'd like to make the change later this week.
---
configure.ac | 301
++
1 files changed, 177 insertions(+), 124 deletions(-)
diff --git a/configure.ac b/configure.ac
index c36b2f6..5489c3f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -532,6 +532,28 @@ AC_ARG_ENABLE([openvg],
[enable support for OpenVG API @:@default=no@:@])],
[enable_openvg=$enableval],
[enable_openvg=no])
+
+AC_ARG_ENABLE([dri],
+ [AS_HELP_STRING([--enable-dri],
+ [enable DRI modules @:@default=auto@:@])],
+ [enable_dri=$enableval],
+ [enable_dri=auto])
+AC_ARG_ENABLE([glx],
+ [AS_HELP_STRING([--enable-glx],
+ [enable GLX library @:@default=auto@:@])],
+ [enable_glx=$enableval],
+ [enable_glx=auto])
+AC_ARG_ENABLE([osmesa],
+ [AS_HELP_STRING([--enable-osmesa],
+ [enable OSMesa library @:@default=auto@:@])],
+ [enable_osmesa=$enableval],
+ [enable_osmesa=auto])
+AC_ARG_ENABLE([egl],
+ [AS_HELP_STRING([--disable-egl],
+ [disable EGL library @:@default=enabled@:@])],
+ [enable_egl=$enableval],
+ [enable_egl=yes])
+
AC_ARG_ENABLE([xorg],
[AS_HELP_STRING([--enable-xorg],
[enable support for X.Org DDX API @:@default=no@:@])],
@@ -542,16 +564,17 @@ AC_ARG_ENABLE([d3d1x],
[enable support for Direct3D 10 11 low-level API
@:@default=no@:@])],
[enable_d3d1x=$enableval],
[enable_d3d1x=no])
-AC_ARG_ENABLE([egl],
- [AS_HELP_STRING([--disable-egl],
- [disable EGL library @:@default=enabled@:@])],
- [enable_egl=$enableval],
- [enable_egl=yes])
AC_ARG_ENABLE([gbm],
[AS_HELP_STRING([--enable-gbm],
[enable gbm library @:@default=auto@:@])],
[enable_gbm=$enableval],
[enable_gbm=auto])
+
+AC_ARG_ENABLE([xlib_glx],
+ [AS_HELP_STRING([--enable-xlib-glx],
+ [make GLX library Xlib-based instead of DRI-based
@:@default=disable@:@])],
+ [enable_xlib_glx=$enableval],
+ [enable_xlib_glx=auto])
AC_ARG_ENABLE([gallium_egl],
[AS_HELP_STRING([--enable-gallium-egl],
[enable optional EGL state tracker (not required
@@ -637,24 +660,66 @@ if test x$enable_opengl = xno; then
fi
AC_ARG_WITH([driver],
- [AS_HELP_STRING([--with-driver=DRIVER],
- [driver for Mesa: xlib,dri,osmesa @:@default=dri when available, or
xlib@:@])],
+ [AS_HELP_STRING([--with-driver=DRIVER], [DEPRECATED])],
[mesa_driver=$withval],
- [mesa_driver=$default_driver])
+ [mesa_driver=auto])
dnl Check for valid option
case x$mesa_driver in
-xxlib|xdri|xosmesa)
- if test x$enable_opengl = xno; then
- AC_MSG_ERROR([Driver '$mesa_driver' requires OpenGL enabled])
+xxlib|xdri|xosmesa|xno)
+ if test x$enable_dri != xauto -o \
+ x$enable_glx != xauto -o \
+ x$enable_osmesa != xauto -o \
+ x$enable_xlib_glx != xauto; then
+ AC_MSG_ERROR([--with-driver=$mesa_driver is deprecated])
fi
;;
-xno)
+xauto)
+ mesa_driver=$default_driver
;;
*)
AC_MSG_ERROR([Driver '$mesa_driver' is not a valid option])
;;
esac
+# map $mesa_driver to APIs
+if test x$enable_dri = xauto; then
+ case x$mesa_driver in
+ xdri) enable_dri=yes ;;
+ *) enable_dri=no ;;
+ esac
+fi
+
+if test x$enable_glx = xauto; then
+ case x$mesa_driver in
+ xdri|xxlib) enable_glx=yes ;;
+ *) enable_glx=no ;;
+ esac
+fi
+
+if test x$enable_osmesa = xauto; then
+ case x$mesa_driver in
+ xxlib|xosmesa) enable_osmesa=yes ;;
+ *) enable_osmesa=no ;;
+ esac
+fi
+
+if test x$enable_xlib_glx = xauto; then
+ case x$mesa_driver in
+
