Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual
On Fri, Aug 12, 2011 at 3:59 PM, Chia-I Wu olva...@gmail.com wrote:
On Fri, Aug 12, 2011 at 3:30 AM, Brian Paul bri...@vmware.com wrote:
On 08/11/2011 11:09 AM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/04/2011 06:29 AM, Brian Paul wrote:
On 08/04/2011 06:31 AM, Benjamin Franzke wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588
egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and
WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to
GL_BACK.
If a pixmap surface is created egl_dri2 will use a single buffer config,
so MakeCurrent has to adjust DrawBuffer[0] to the current drawable.
---
src/mesa/drivers/dri/intel/intel_context.c | 6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index fe8be08..0eeffc0 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
readFb = driReadPriv-driverPrivate;
driContextPriv-dri2.draw_stamp = driDrawPriv-dri2.stamp - 1;
driContextPriv-dri2.read_stamp = driReadPriv-dri2.stamp - 1;
+
+ if (fb-Visual.doubleBufferMode) {
+ intel-ctx.Color.DrawBuffer[0] = GL_BACK;
+ } else {
+ intel-ctx.Color.DrawBuffer[0] = GL_FRONT;
+ }
}
intel_prepare_render(intel);
This doesn't seem right to me. We shouldn't be changing context state
like that during a make-current() call.
During context initialization we call _mesa_init_color() where we set
ctx-Color.DrawBuffer[0] to either GL_BACK or GL_FRONT depending on the
visual's double-buffer flag. You might investigate why that's not doing
the job.
This entire approach is wrong, and it will break GLX. Page 28 (page 34
of the PDF) of the GLX 1.4 spec says (emphasis mine):
No error will be generated if the value of GL DRAW BUFFER in ctx
indicates a color buffer that is not supported by draw. In this
case, *all rendering will behave as if GL DRAW BUFFER was set to
NONE.* Also, no error will be generated if the value of GL READ
BUFFER in ctx does not correspond to a valid color buffer. Instead,
when an operation that reads from the color buffer is executed
(e.g., glReadPixels or glCopyPixels), the pixel values used will be
undefined until GL READ BUFFER is set to a color buffer that is
valid in read. Operations that query the value of GL READ BUFFER or
GL DRAW BUFFER (i.e., glGet, glPushAttrib) use the value set last
in the context, independent of whether it is a valid buffer in read
or draw.
Page 217 of the GL 3.3 spec says:
For the default framebuffer, in the initial state the draw buffer
for fragment color zero is BACK if there is a back buffer; FRONT
if there is no back buffer; and NONE if no default framebuffer is
associated with the context.
This seems a little ambiguous and perhaps in conflict with the GLX text.
I think the right answer is that the context draw buffer (and read
buffer) setting is initialized based on the drawable the first time the
context is bound. It seems like just changing _mesa_init_color to use
the double-buffer setting from the drawable (instead of the context)
should be sufficient.
Yeah, this is all a bit tricky.
Suppose the context is initially in a double-buffered state and we're
drawing to the back buffer. Then we bind the context to a single-buffered
window. We need to make sure we don't try to render to the non-existant
back buffer. There may be a few places in Mesa where we're not prepared for
that.
Anyway, from what I've gathered we should _not_ change the value of
GL_DRAW_BUFFER in this situation either.
I'm putting together a couple piglit GLX tests to exercise this. I
don't plan to send them to the piglit list until I can test them on a
non-Mesa driver. Since I'm still at SIGGRAPH, that won't be until next
week.
I also started on a piglit test for this bug got sidetracked. NVIDIA's
driver seems to do the following:
1. create double-buffered ctx and window, and make current.
2. query GL_DRAW_BUFFER returns GL_BACK
3. create single-buffered window and bind to the context.
4. query GL_DRAW_BUFFER still returns GL_BACK
5. drawing to the single-buffered window has no effect.
I did a little experiments today. It seems NVIDIA does not have the
concept of single-buffered or double-buffered contexts, but
single-buffered or double-buffered drawables. In GLX spec,
GLX_DOUBLEBUFFER seems to only apply for drawables too. This is what
I did
1. create a single-buffered drawable
2. create a context with a GLX_DOUBLEBUFFER visual
3. make the context and drawable current
4. query GL_DRAW_BUFFER returns GL_FRONT
This could conflict with section 4.2.1 of GL spec
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
Am Donnerstag, den 11.08.2011, 12:04 -0400 schrieb Younes Manton: It's been brought to my attention that the source this is based on is GPL'd, which means it needs to go before 7.12 is released since it's incompatible with Mesa's MIT license. That is actually not so problematic as it sounds in the first place, since parts of Mesa is already licensed under the LGPL, but it starts to be a problem when somebody tries to link a for example BSD licensed binary with the resulting VDPAU implementation (since it is the only implementation wich is using this code at the moment). I googled a bit before including this code and came around with the following mail conversation (http://www.mail-archive.com/license-discuss@opensource.org/msg01164.html): - The Free Software Foundation skirted the issue with its repackaging of the X rendering capability into libxmi. They licensed the new library under GPL, but the original source files borrowed from X remain under MIT terms (even though those files have most likely been modified to embed them in a GPL library). It's the modification that's the key. The FSF own the modifications, and the copyright on those is GPL. MIT own the pre-modified code. To the extent that the latter can be separated from the former, it can be distributed under MIT terms. To the extent that they're inseparable, both licenses must be satisfied - possible, since they aren't contradictory. The FSF did that? So that means that you can mix GPL code with other code and distribute both under the their respective licences? What effect does this have on that GPL distribution clause? Exactly. But the effect is that you must satisfy *both* licenses. Now the MIT license makes no real restrictions on other works its combined into, but the GPL does. The problem comes when the GPL demands that you give certain permissions (the permission to modify and distribute sources) on any derived work, and this may conflict with one of the other licenses applicable on a work - but doesn't in the MIT case. In particular, the GPL says that you must make available the source of the whole work. Now this is an additional restriction on top the the MIT one, but it's not in conflict with the MIT one - it doesn't ask you to do anything you aren't allowed to do. I already considered a configure option which makes this code to be not included, but in the long term it just should go away. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: initial multi-threaded span rendering
On Fri, 2011-08-12 at 07:48 +0200, Andreas Fänger wrote: OSMesa for gallium would be really helpful. Are there plans to implement some sort of antialising (GL_POLYGON_SMOOTH, fsaa) in softpipe/llvmpipe? MLAA works with softpipe and llvmpipe: http://candgsoc.host56.com/ -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
2011/8/12 Christian König deathsim...@vodafone.de: Am Donnerstag, den 11.08.2011, 12:04 -0400 schrieb Younes Manton: It's been brought to my attention that the source this is based on is GPL'd, which means it needs to go before 7.12 is released since it's incompatible with Mesa's MIT license. That is actually not so problematic as it sounds in the first place, since parts of Mesa is already licensed under the LGPL, but it starts to be a problem when somebody tries to link a for example BSD licensed binary with the resulting VDPAU implementation (since it is the only implementation wich is using this code at the moment). I googled a bit before including this code and came around with the following mail conversation (http://www.mail-archive.com/license-discuss@opensource.org/msg01164.html): - The Free Software Foundation skirted the issue with its repackaging of the X rendering capability into libxmi. They licensed the new library under GPL, but the original source files borrowed from X remain under MIT terms (even though those files have most likely been modified to embed them in a GPL library). It's the modification that's the key. The FSF own the modifications, and the copyright on those is GPL. MIT own the pre-modified code. To the extent that the latter can be separated from the former, it can be distributed under MIT terms. To the extent that they're inseparable, both licenses must be satisfied - possible, since they aren't contradictory. The FSF did that? So that means that you can mix GPL code with other code and distribute both under the their respective licences? What effect does this have on that GPL distribution clause? Exactly. But the effect is that you must satisfy *both* licenses. Now the MIT license makes no real restrictions on other works its combined into, but the GPL does. The problem comes when the GPL demands that you give certain permissions (the permission to modify and distribute sources) on any derived work, and this may conflict with one of the other licenses applicable on a work - but doesn't in the MIT case. In particular, the GPL says that you must make available the source of the whole work. Now this is an additional restriction on top the the MIT one, but it's not in conflict with the MIT one - it doesn't ask you to do anything you aren't allowed to do. I already considered a configure option which makes this code to be not included, but in the long term it just should go away. Christian. Sorry, by incompatible I didn't mean that you couldn't use them together, but that one is more restrictive than the other. Like the discussion you quoted states, if you combine MIT and GPL you have to satisfy both of them, which means you have to satisfy the GPL. I personally don't care that much, but unfortunately with the way gallium is built it affects more than just VDPAU. Every driver in lib/gallium includes that code, including swrast_dri (softpipe), r600_dri, etc, and libGL loads those drivers. If you build with the swrast config instead of DRI I believe galllium libGL statically links with softpipe, so basically my understanding is that anyone linking with gallium libGL (both swrast and DRI configs) has to satisfy the GPL now. Maybe someone else who is more familiar with these sorts of things can comment and confirm that this is accurate and whether or not it's a problem. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Patch] Destroy context in egl_dri2 and egl_glx driver when apps call eglDestroyContext
Hi, this patch calls corresponding destroyContext in egl_dri2 and egl_glx
driver.
Any comment?
Cooper
---
src/egl/drivers/dri2/egl_dri2.c | 17 +
src/egl/drivers/glx/egl_glx.c | 18 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c
b/src/egl/drivers/dri2/egl_dri2.c
index 9a37ea4..2d947cd 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -726,6 +726,22 @@ dri2_create_context(_EGLDriver *drv, _EGLDisplay *disp,
_EGLConfig *conf,
}
/**
+ * Called via eglDestroyContext(), drv-API.DestroyContext().
+ */
+static EGLBoolean
+dri2_destroy_context(_EGLDriver *drv, _EGLDisplay *disp, _EGLContext *ctx)
+{
+ struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
+ struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+
+ _eglPutContext(ctx);
+ dri2_dpy-core-destroyContext(dri2_ctx-dri_context);
+ free(dri2_ctx);
+
+ return EGL_TRUE;
+}
+
+/**
* Called via eglMakeCurrent(), drv-API.MakeCurrent().
*/
static EGLBoolean
@@ -1348,6 +1364,7 @@ _EGL_MAIN(const char *args)
dri2_drv-base.API.Initialize = dri2_initialize;
dri2_drv-base.API.Terminate = dri2_terminate;
dri2_drv-base.API.CreateContext = dri2_create_context;
+ dri2_drv-base.API.DestroyContext = dri2_destroy_context;
dri2_drv-base.API.MakeCurrent = dri2_make_current;
dri2_drv-base.API.GetProcAddress = dri2_get_proc_address;
dri2_drv-base.API.WaitClient = dri2_wait_client;
diff --git a/src/egl/drivers/glx/egl_glx.c b/src/egl/drivers/glx/egl_glx.c
index 7cf8f4d..b21a3d7 100644
--- a/src/egl/drivers/glx/egl_glx.c
+++ b/src/egl/drivers/glx/egl_glx.c
@@ -713,6 +713,23 @@ GLX_eglCreateContext(_EGLDriver *drv, _EGLDisplay
*disp, _EGLConfig *conf,
return GLX_ctx-Base;
}
+/**
+ * Called via eglDestroyContext(), drv-API.DestroyContext().
+ */
+static EGLBoolean
+GLX_eglDestroyContext(_EGLDriver *drv, _EGLDisplay *disp, _EGLContext *ctx)
+{
+ struct GLX_egl_driver *GLX_drv = GLX_egl_driver(drv);
+ struct GLX_egl_context *GLX_ctx = GLX_egl_context(ctx);
+
+ _eglPutContext(ctx);
+ assert(GLX_ctx);
+ GLX_drv-glXDestroyContext(disp, ctx);
+
+ free(GLX_ctx);
+
+ return EGL_TRUE;
+}
/**
* Destroy a surface. The display is allowed to be uninitialized.
@@ -1142,6 +1159,7 @@ _EGL_MAIN(const char *args)
GLX_drv-Base.API.Initialize = GLX_eglInitialize;
GLX_drv-Base.API.Terminate = GLX_eglTerminate;
GLX_drv-Base.API.CreateContext = GLX_eglCreateContext;
+ GLX_drv-Base.API.DestroyContext = GLX_eglDestroyContext;
GLX_drv-Base.API.MakeCurrent = GLX_eglMakeCurrent;
GLX_drv-Base.API.CreateWindowSurface = GLX_eglCreateWindowSurface;
GLX_drv-Base.API.CreatePixmapSurface = GLX_eglCreatePixmapSurface;
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Fix type error when lowering integer divisions
This patch fixes a bug when lowering an integer division:
x/y
to a multiplication by a reciprocal:
int(float(x)*reciprocal(float(y)))
If x was a a plain int and y was an ivecN, the lowering pass
incorrectly assigned the type of the product to be float, when in fact
it should be vecN. This caused mesa to abort with an IR validation
error.
Fixes piglit tests {fs,vs}-op-div-int-ivec{2,3,4}.
---
src/glsl/lower_instructions.cpp |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
index 806f863..23aa19b 100644
--- a/src/glsl/lower_instructions.cpp
+++ b/src/glsl/lower_instructions.cpp
@@ -166,6 +166,10 @@ lower_instructions_visitor::div_to_mul_rcp(ir_expression
*ir)
else
op0 = new(ir) ir_expression(ir_unop_u2f, vec_type, ir-operands[0],
NULL);
+ vec_type = glsl_type::get_instance(GLSL_TYPE_FLOAT,
+ir-type-vector_elements,
+ir-type-matrix_columns);
+
op0 = new(ir) ir_expression(ir_binop_mul, vec_type, op0, op1);
if (ir-operands[1]-type-base_type == GLSL_TYPE_INT) {
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
Am Freitag, den 12.08.2011, 10:49 -0400 schrieb Younes Manton: Sorry, by incompatible I didn't mean that you couldn't use them together, but that one is more restrictive than the other. Like the discussion you quoted states, if you combine MIT and GPL you have to satisfy both of them, which means you have to satisfy the GPL. I personally don't care that much, but unfortunately with the way gallium is built it affects more than just VDPAU. Every driver in lib/gallium includes that code, including swrast_dri (softpipe), r600_dri, etc, and libGL loads those drivers. If you build with the swrast config instead of DRI I believe galllium libGL statically links with softpipe, so basically my understanding is that anyone linking with gallium libGL (both swrast and DRI configs) has to satisfy the GPL now. A crap, your right. I've forgotten that GPL has even a problem when code is just linked in, compared to being used. Maybe someone else who is more familiar with these sorts of things can comment and confirm that this is accurate and whether or not it's a problem. I already asked around in my AMD team, and the general answer was: Oh fuck I've no idea, please don't give me a headache. I could asked around a bit more, but I don't think we get a definitive answer before xmas. As a short term solution we could compile that code conditionally, and only enable it when the VDPAU state tracker is enabled. But as the long term solution the code just needs a rewrite, beside having a license problem, it is just not very optimal. The original code is something like a decade old, and is using a whole bunch of quirks which are not useful by today’s standards (not including the sign in mv tables for example). ffmpegs/libavs implementation for example is something like halve the size and even faster, but uses more memory for table lookups. But that code is also dual licensed under the GPL/LGPL. Using LGPL code instead could also be a solution, because very important parts of Mesa (the GLSL parser for example) is already licensed under that, but I'm also not an expert with that also. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
Hey, On 08/12/2011 07:42 PM, Christian König wrote: Am Freitag, den 12.08.2011, 10:49 -0400 schrieb Younes Manton: Sorry, by incompatible I didn't mean that you couldn't use them together, but that one is more restrictive than the other. Like the discussion you quoted states, if you combine MIT and GPL you have to satisfy both of them, which means you have to satisfy the GPL. I personally don't care that much, but unfortunately with the way gallium is built it affects more than just VDPAU. Every driver in lib/gallium includes that code, including swrast_dri (softpipe), r600_dri, etc, and libGL loads those drivers. If you build with the swrast config instead of DRI I believe galllium libGL statically links with softpipe, so basically my understanding is that anyone linking with gallium libGL (both swrast and DRI configs) has to satisfy the GPL now. A crap, your right. I've forgotten that GPL has even a problem when code is just linked in, compared to being used. Maybe someone else who is more familiar with these sorts of things can comment and confirm that this is accurate and whether or not it's a problem. I already asked around in my AMD team, and the general answer was: Oh fuck I've no idea, please don't give me a headache. I could asked around a bit more, but I don't think we get a definitive answer before xmas. As a short term solution we could compile that code conditionally, and only enable it when the VDPAU state tracker is enabled. But as the long term solution the code just needs a rewrite, beside having a license problem, it is just not very optimal. The original code is something like a decade old, and is using a whole bunch of quirks which are not useful by today’s standards (not including the sign in mv tables for example). ffmpegs/libavs implementation for example is something like halve the size and even faster, but uses more memory for table lookups. But that code is also dual licensed under the GPL/LGPL. Using LGPL code instead could also be a solution, because very important parts of Mesa (the GLSL parser for example) is already licensed under that, but I'm also not an expert with that also. gstreamer might have a LGPL version, but if we use LGPL, we probably want to move that code to vdpau/g3dvl instead of it being linked in with everything.. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Implementing varying packing
This optimisation pass will look for and pack together float,
vec2, vec3 varyings in fragment shaders and transform the vertex
shader accordingly. It might improve performance depending on
the hardware.
---
src/glsl/Makefile |1 +
src/glsl/linker.cpp|3 +
src/glsl/pack_varyings.cpp | 491
3 files changed, 495 insertions(+), 0 deletions(-)
create mode 100644 src/glsl/pack_varyings.cpp
diff --git a/src/glsl/Makefile b/src/glsl/Makefile
index e2d29bd..8ce06bd 100644
--- a/src/glsl/Makefile
+++ b/src/glsl/Makefile
@@ -84,6 +84,7 @@ CXX_SOURCES = \
opt_structure_splitting.cpp \
opt_swizzle_swizzle.cpp \
opt_tree_grafting.cpp \
+ pack_varyings.cpp \
s_expression.cpp
LIBS = \
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 255edc6..97b25ff 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1404,6 +1404,7 @@ demote_shader_inputs_and_outputs(gl_shader *sh, enum
ir_variable_mode mode)
}
}
+extern void pack_varyings(gl_shader* vs,gl_shader* fs);
void
assign_varying_locations(struct gl_shader_program *prog,
@@ -1413,6 +1414,8 @@ assign_varying_locations(struct gl_shader_program *prog,
unsigned output_index = VERT_RESULT_VAR0;
unsigned input_index = FRAG_ATTRIB_VAR0;
+ pack_varyings(producer,consumer);
+
/* Operate in a total of three passes.
*
* 1. Assign locations for any matching inputs and outputs.
diff --git a/src/glsl/pack_varyings.cpp b/src/glsl/pack_varyings.cpp
new file mode 100644
index 000..caf41aa
--- /dev/null
+++ b/src/glsl/pack_varyings.cpp
@@ -0,0 +1,491 @@
+/*
+ * Copyright © 2011 Intel Corporation
+ * Copyright © 2011 Vincent Lejeune
+ *
+ * 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 pack_varyings.cpp
+ *
+ * Try to find packeable varyings and pack them.
+ * Currently the code only concerns varying float, vec2 and vec3.
+ *
+ * This is a 2 passes code :
+ * - In a first pass, all varyings from shaders are collected. A packing
+ * strategy is then build looking only at the amount of each type of varyings
+ * (float, vec2, vec3) ; in particular the number of occurence of each varyings
+ * is ignored as it is assumed that swizzle is mostly performance free. This
+ * strategy is stored as a hash_table of packing_remap structures. If a shader
+ * object is reused by several program, storing this strategy might avoid
+ * unnecessary recomputations ; this is not done yet.
+ * - In a second pass, the packing variables are declared in the shaders and
the
+ * packed variables are removed. Instructions are then parsed and each
occurence
+ * of packed variables is replaced by corresponding packing variable swizzled.
+ */
+
+#include main/core.h
+#include glsl_symbol_table.h
+#include ir.h
+#include program.h
+#include program/hash_table.h
+#include linker.h
+#include ir_rvalue_visitor.h
+#include ir_optimization.h
+#include list.h
+
+extern C {
+#include main/shaderobj.h
+}
+
+/*
+ * Boxed List definition
+ * Such a list holds pointer instead of exec_node ; in addition they can
contain
+ * item stored in another list (exec_node can belong to a unique exec_list).
+ * This container is needed to store ir_variable* in the first pass without
+ * removing them from instruction flow.
+ *
+ */
+
+// BOXED LIST BEGIN
+
+class box : public exec_node
+{
+public:
+ void* content;
+ box(void* c):content(c)
+ {
+
+ }
+};
+
+class boxed_exec_list : public exec_list
+{
+public:
+ void push_tail(void *n)
+ {
+ box* b = new (this) box(n);
+ exec_list::push_tail(b);
+ }
+
+ void push_head(void *n)
+ {
+ box* b = new (this) box(n);
+ exec_list::push_head(b);
+ }
+
+ static void* operator new(size_t size, void *ctx)
+ {
+ void *node;
+
+ node = ralloc_size(ctx, size);
+ assert(node != NULL);
+
+ return node;
+
Re: [Mesa-dev] [PATCH] Implementing varying packing
-Original Message- Subject: [Mesa-dev] [PATCH] Implementing varying packing This optimisation pass will look for and pack together float, vec2, vec3 varyings in fragment shaders and transform the vertex shader accordingly. It might improve performance depending on the hardware. --- src/glsl/Makefile |1 + src/glsl/linker.cpp|3 + src/glsl/pack_varyings.cpp | 491 3 files changed, 495 insertions(+), 0 deletions(-) create mode 100644 src/glsl/pack_varyings.cpp diff --git a/src/glsl/Makefile b/src/glsl/Makefile index e2d29bd..8ce06bd 100644 --- a/src/glsl/Makefile +++ b/src/glsl/Makefile @@ -84,6 +84,7 @@ CXX_SOURCES = \ opt_structure_splitting.cpp \ opt_swizzle_swizzle.cpp \ opt_tree_grafting.cpp \ + pack_varyings.cpp \ s_expression.cpp LIBS = \ Please add the equivalent change to src/glsl/SConscript. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
2011/8/12 Christian König deathsim...@vodafone.de: Am Freitag, den 12.08.2011, 10:49 -0400 schrieb Younes Manton: Sorry, by incompatible I didn't mean that you couldn't use them together, but that one is more restrictive than the other. Like the discussion you quoted states, if you combine MIT and GPL you have to satisfy both of them, which means you have to satisfy the GPL. I personally don't care that much, but unfortunately with the way gallium is built it affects more than just VDPAU. Every driver in lib/gallium includes that code, including swrast_dri (softpipe), r600_dri, etc, and libGL loads those drivers. If you build with the swrast config instead of DRI I believe galllium libGL statically links with softpipe, so basically my understanding is that anyone linking with gallium libGL (both swrast and DRI configs) has to satisfy the GPL now. A crap, your right. I've forgotten that GPL has even a problem when code is just linked in, compared to being used. Maybe someone else who is more familiar with these sorts of things can comment and confirm that this is accurate and whether or not it's a problem. I already asked around in my AMD team, and the general answer was: Oh fuck I've no idea, please don't give me a headache. I could asked around a bit more, but I don't think we get a definitive answer before xmas. As a short term solution we could compile that code conditionally, and only enable it when the VDPAU state tracker is enabled. But as the long term solution the code just needs a rewrite, beside having a license problem, it is just not very optimal. The original code is something like a decade old, and is using a whole bunch of quirks which are not useful by today’s standards (not including the sign in mv tables for example). ffmpegs/libavs implementation for example is something like halve the size and even faster, but uses more memory for table lookups. But that code is also dual licensed under the GPL/LGPL. Using LGPL code instead could also be a solution, because very important parts of Mesa (the GLSL parser for example) is already licensed under that, but I'm also not an expert with that also. Even though the GLSL parser is licensed under LGPL (because Bison is), there is a special exception that we may license it under whatever licence we want if we don't make software that does exactly what Bison does. So the whole GLSL compiler is actually licensed under the MIT license. There was one LGPL dependency (talloc), but Intel has paid special attention to get rid of that. My recollection is nobody wanted LGPL or GPL code in Mesa. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
Why not ask the original author to relicense? 2011/8/12 Marek Olšák mar...@gmail.com 2011/8/12 Christian König deathsim...@vodafone.de: Am Freitag, den 12.08.2011, 10:49 -0400 schrieb Younes Manton: Sorry, by incompatible I didn't mean that you couldn't use them together, but that one is more restrictive than the other. Like the discussion you quoted states, if you combine MIT and GPL you have to satisfy both of them, which means you have to satisfy the GPL. I personally don't care that much, but unfortunately with the way gallium is built it affects more than just VDPAU. Every driver in lib/gallium includes that code, including swrast_dri (softpipe), r600_dri, etc, and libGL loads those drivers. If you build with the swrast config instead of DRI I believe galllium libGL statically links with softpipe, so basically my understanding is that anyone linking with gallium libGL (both swrast and DRI configs) has to satisfy the GPL now. A crap, your right. I've forgotten that GPL has even a problem when code is just linked in, compared to being used. Maybe someone else who is more familiar with these sorts of things can comment and confirm that this is accurate and whether or not it's a problem. I already asked around in my AMD team, and the general answer was: Oh fuck I've no idea, please don't give me a headache. I could asked around a bit more, but I don't think we get a definitive answer before xmas. As a short term solution we could compile that code conditionally, and only enable it when the VDPAU state tracker is enabled. But as the long term solution the code just needs a rewrite, beside having a license problem, it is just not very optimal. The original code is something like a decade old, and is using a whole bunch of quirks which are not useful by today’s standards (not including the sign in mv tables for example). ffmpegs/libavs implementation for example is something like halve the size and even faster, but uses more memory for table lookups. But that code is also dual licensed under the GPL/LGPL. Using LGPL code instead could also be a solution, because very important parts of Mesa (the GLSL parser for example) is already licensed under that, but I'm also not an expert with that also. Even though the GLSL parser is licensed under LGPL (because Bison is), there is a special exception that we may license it under whatever licence we want if we don't make software that does exactly what Bison does. So the whole GLSL compiler is actually licensed under the MIT license. There was one LGPL dependency (talloc), but Intel has paid special attention to get rid of that. My recollection is nobody wanted LGPL or GPL code in Mesa. Marek ___ 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
