[Mesa-dev] [PATCH] r600g: Implemented the y component write for the LOG opcode.
From: Tilman Sauerbeck
This makes the 'vp1-LOG test' piglit test work.
Signed-off-by: Tilman Sauerbeck
---
src/gallium/drivers/r600/r600_shader.c | 95 ++--
1 files changed, 90 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 129c95e..c188355 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2044,7 +2044,6 @@ static int tgsi_exp(struct r600_shader_ctx *ctx)
static int tgsi_log(struct r600_shader_ctx *ctx)
{
struct tgsi_full_instruction *inst =
&ctx->parse.FullToken.FullInstruction;
- struct r600_bc_alu_src r600_src[3];
struct r600_bc_alu alu;
int r;
@@ -2089,13 +2088,99 @@ static int tgsi_log(struct r600_shader_ctx *ctx)
return r;
}
- /* result.y = FIXME; */
+ /* result.y = src.x / (2 ^ floor(log2(src.x))); */
if ((inst->Dst[0].Register.WriteMask >> 1) & 1) {
memset(&alu, 0, sizeof(struct r600_bc_alu));
- alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_MOV);
- alu.src[0].sel = V_SQ_ALU_SRC_1;
- alu.src[0].chan = 0;
+ alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_LOG_IEEE);
+ r = tgsi_src(ctx, &inst->Src[0], &alu.src[0]);
+ if (r)
+ return r;
+
+ alu.src[0].chan = tgsi_chan(&inst->Src[0], 0);
+
+ alu.dst.sel = ctx->temp_reg;
+ alu.dst.chan = 1;
+ alu.dst.write = 1;
+ alu.last = 1;
+
+ r = r600_bc_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+
+ r = r600_bc_add_literal(ctx->bc, ctx->value);
+ if (r)
+ return r;
+
+ memset(&alu, 0, sizeof(struct r600_bc_alu));
+
+ alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_FLOOR);
+ alu.src[0].sel = ctx->temp_reg;
+ alu.src[0].chan = 1;
+
+ alu.dst.sel = ctx->temp_reg;
+ alu.dst.chan = 1;
+ alu.dst.write = 1;
+ alu.last = 1;
+
+ r = r600_bc_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+
+ r = r600_bc_add_literal(ctx->bc, ctx->value);
+ if (r)
+ return r;
+
+ memset(&alu, 0, sizeof(struct r600_bc_alu));
+
+ alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_EXP_IEEE);
+ alu.src[0].sel = ctx->temp_reg;
+ alu.src[0].chan = 1;
+
+ alu.dst.sel = ctx->temp_reg;
+ alu.dst.chan = 1;
+ alu.dst.write = 1;
+ alu.last = 1;
+
+ r = r600_bc_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+
+ r = r600_bc_add_literal(ctx->bc, ctx->value);
+ if (r)
+ return r;
+
+ memset(&alu, 0, sizeof(struct r600_bc_alu));
+
+ alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_RECIP_IEEE);
+ alu.src[0].sel = ctx->temp_reg;
+ alu.src[0].chan = 1;
+
+ alu.dst.sel = ctx->temp_reg;
+ alu.dst.chan = 1;
+ alu.dst.write = 1;
+ alu.last = 1;
+
+ r = r600_bc_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+
+ r = r600_bc_add_literal(ctx->bc, ctx->value);
+ if (r)
+ return r;
+
+ memset(&alu, 0, sizeof(struct r600_bc_alu));
+
+ alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_MUL);
+
+ r = tgsi_src(ctx, &inst->Src[0], &alu.src[0]);
+ if (r)
+ return r;
+
+ alu.src[0].chan = tgsi_chan(&inst->Src[0], 0);
+
+ alu.src[1].sel = ctx->temp_reg;
+ alu.src[1].chan = 1;
alu.dst.sel = ctx->temp_reg;
alu.dst.chan = 1;
--
1.7.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Support GLSL ES in the standalone compiler
Hi Kenneth,
This patch series add GLSL ES support to the standalone compiler.
The first patch makes the standalone compiler to pass a dummy context to
_mesa_glsl_parse_state. The second patch adds a new option, --glsl-es, to
enable GLSL ES mode.
--
o...@lunarg.com
From b36c0eefd7b1ae96eabf72dc537d69d389abe1d0 Mon Sep 17 00:00:00 2001
From: Chia-I Wu
Date: Wed, 8 Sep 2010 18:48:12 +0800
Subject: [PATCH 1/2] glsl: Require a context in _mesa_glsl_parse_state.
Create a dummy context in the standalone compiler and pass it to
_mesa_glsl_parse_state.
---
src/glsl/glsl_parser_extras.cpp | 77 +++
src/glsl/main.cpp | 47 +---
2 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index d6ad8cb..3dbec5d 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -57,63 +57,28 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct
__GLcontextRec *ctx,
this->es_shader = false;
this->ARB_texture_rectangle_enable = true;
- if (ctx != NULL) {
- /* OpenGL ES 2.0 has different defaults from desktop GL. */
- if (ctx->API == API_OPENGLES2) {
-this->language_version = 100;
-this->es_shader = true;
-this->ARB_texture_rectangle_enable = false;
- }
-
- this->extensions = &ctx->Extensions;
-
- this->Const.MaxLights = ctx->Const.MaxLights;
- this->Const.MaxClipPlanes = ctx->Const.MaxClipPlanes;
- this->Const.MaxTextureUnits = ctx->Const.MaxTextureUnits;
- this->Const.MaxTextureCoords = ctx->Const.MaxTextureCoordUnits;
- this->Const.MaxVertexAttribs = ctx->Const.VertexProgram.MaxAttribs;
- this->Const.MaxVertexUniformComponents =
ctx->Const.VertexProgram.MaxUniformComponents;
- this->Const.MaxVaryingFloats = ctx->Const.MaxVarying * 4;
- this->Const.MaxVertexTextureImageUnits =
ctx->Const.MaxVertexTextureImageUnits;
- this->Const.MaxCombinedTextureImageUnits =
ctx->Const.MaxCombinedTextureImageUnits;
- this->Const.MaxTextureImageUnits = ctx->Const.MaxTextureImageUnits;
- this->Const.MaxFragmentUniformComponents =
ctx->Const.FragmentProgram.MaxUniformComponents;
-
- this->Const.MaxDrawBuffers = ctx->Const.MaxDrawBuffers;
- } else {
- /* If there is no GL context (standalone compiler), fill in constants
- * with the minimum required values.
- */
- static struct gl_extensions null_extensions;
-
- memset(&null_extensions, 0, sizeof(null_extensions));
- null_extensions.ARB_draw_buffers = GL_TRUE;
- null_extensions.ARB_fragment_coord_conventions = GL_TRUE;
- null_extensions.EXT_texture_array = GL_TRUE;
- null_extensions.NV_texture_rectangle = GL_TRUE;
-
- this->extensions = &null_extensions;
-
- /* 1.10 minimums. */
- this->Const.MaxLights = 8;
- this->Const.MaxClipPlanes = 8;
- this->Const.MaxTextureUnits = 2;
-
- /* More than the 1.10 minimum to appease parser tests taken from
- * apps that (hopefully) already checked the number of coords.
- */
- this->Const.MaxTextureCoords = 4;
-
- this->Const.MaxVertexAttribs = 16;
- this->Const.MaxVertexUniformComponents = 512;
- this->Const.MaxVaryingFloats = 32;
- this->Const.MaxVertexTextureImageUnits = 0;
- this->Const.MaxCombinedTextureImageUnits = 2;
- this->Const.MaxTextureImageUnits = 2;
- this->Const.MaxFragmentUniformComponents = 64;
-
- this->Const.MaxDrawBuffers = 2;
+ /* OpenGL ES 2.0 has different defaults from desktop GL. */
+ if (ctx->API == API_OPENGLES2) {
+ this->language_version = 100;
+ this->es_shader = true;
+ this->ARB_texture_rectangle_enable = false;
}
+
+ this->extensions = &ctx->Extensions;
+
+ this->Const.MaxLights = ctx->Const.MaxLights;
+ this->Const.MaxClipPlanes = ctx->Const.MaxClipPlanes;
+ this->Const.MaxTextureUnits = ctx->Const.MaxTextureUnits;
+ this->Const.MaxTextureCoords = ctx->Const.MaxTextureCoordUnits;
+ this->Const.MaxVertexAttribs = ctx->Const.VertexProgram.MaxAttribs;
+ this->Const.MaxVertexUniformComponents =
ctx->Const.VertexProgram.MaxUniformComponents;
+ this->Const.MaxVaryingFloats = ctx->Const.MaxVarying * 4;
+ this->Const.MaxVertexTextureImageUnits =
ctx->Const.MaxVertexTextureImageUnits;
+ this->Const.MaxCombinedTextureImageUnits =
ctx->Const.MaxCombinedTextureImageUnits;
+ this->Const.MaxTextureImageUnits = ctx->Const.MaxTextureImageUnits;
+ this->Const.MaxFragmentUniformComponents =
ctx->Const.FragmentProgram.MaxUniformComponents;
+
+ this->Const.MaxDrawBuffers = ctx->Const.MaxDrawBuffers;
}
const char *
diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
index 2323a20..982562c 100644
--- a/src/glsl/main.cpp
+++ b/src/glsl/main.cpp
@@ -59,6 +59,41 @@ _mesa_new_shader(GLcontext *ctx, GLuint name, GLenum type)
return shader;
}
+static void
+initiali
Re: [Mesa-dev] [PATCH] glsl: Support GLSL ES in the standalone compiler
On Wednesday 08 September 2010 04:00:09 Chia-I Wu wrote: > Hi Kenneth, > > This patch series add GLSL ES support to the standalone compiler. > > The first patch makes the standalone compiler to pass a dummy context to > _mesa_glsl_parse_state. The second patch adds a new option, --glsl-es, to > enable GLSL ES mode. I like these. The first definitely makes the code cleaner, and the second should be quite useful. I've pushed them to master. Thanks! --Kenneth ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New interesting closed-source OpenGL/GLSL test
On Wed, 2010-09-08 at 03:07 +0200, Luca Barbieri wrote: > For anyone who doesn't know it yet, there is a new closed-source > OpenGL game for Linux called Amnesia, with the very interesting > property that the developers offer a test program that renders several > complex GLSL-based effects one at a time. I filed an initial bug report about the game and test a while back: https://bugs.freedesktop.org/show_bug.cgi?id=29420 -- 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
[Mesa-dev] [Bug 30075] Possible glXDestroyContext glXMakeContextCurrent inconsistency
https://bugs.freedesktop.org/show_bug.cgi?id=30075 Kristian Høgsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Kristian Høgsberg 2010-09-08 07:20:55 PDT --- The request to destroy the server side context is always sent immediately. If the context is current on the server side, it's up to the server to hold on to in until it's no longer current. The garbage collection is gone in master. -- 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] GL_NV_texture_env_combine4, Mesa and TNT2
randrianas...@gmail.com writes:
> Very hackish patch series for nv0x hardware, please take look and comment on
> changes, blame me for errors etc.
>
> Francisco, might be nouveau list is better for this stuff?
It's fine either way, do it as you prefer.
> From 9bf16a26361ab4a44b6568deae30c523488cde1b Mon Sep 17 00:00:00 2001
> From: Andrew Randrianasulu
> Date: Mon, 6 Sep 2010 18:17:48 +0400
> Subject: [PATCH 1/6] nv0x: use multitexturing engine for A8 textures, fixes
> teapot demo broken
> probably since we started to use _mesa_meta_Bitmap
>
Can you please split your commit messages? It goes way over the 80
column limit.
> ---
> src/mesa/drivers/dri/nouveau/nv04_context.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c
> b/src/mesa/drivers/dri/nouveau/nv04_context.c
> index 6834f7c..af46ce2 100644
> --- a/src/mesa/drivers/dri/nouveau/nv04_context.c
> +++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
> @@ -38,6 +38,7 @@ nv04_context_engine(GLcontext *ctx)
> struct nouveau_hw_state *hw = &to_nouveau_context(ctx)->hw;
> struct nouveau_grobj *fahrenheit;
>
> +
This is useless whitespace.
> if (ctx->Texture.Unit[0].EnvMode == GL_COMBINE ||
> ctx->Texture.Unit[0].EnvMode == GL_BLEND ||
> ctx->Texture.Unit[0].EnvMode == GL_ADD ||
> @@ -46,6 +47,13 @@ nv04_context_engine(GLcontext *ctx)
> fahrenheit = hw->eng3dm;
> else
> fahrenheit = hw->eng3d;
> +
Same here.
> + if (ctx->Texture.Unit[0]._ReallyEnabled) {
> + struct gl_texture_object *t = ctx->Texture.Unit[0]._Current;
> + struct gl_texture_image *ti = t->Image[0][t->BaseLevel];
Inconsistent indentation here.
> + if (ti->_BaseFormat == GL_ALPHA)
> + fahrenheit = hw->eng3dm;
This is the right thing to do, but we need to check for GL_LUMINANCE
too.
> + }
>
> if (fahrenheit != nctx->eng3d) {
> nctx->eng3d = fahrenheit;
> --
> 1.7.0.2
> From 8ca9fd5db720af498fcaf1365db19fbd2be57b57 Mon Sep 17 00:00:00 2001
> From: Andrew Randrianasulu
> Date: Mon, 6 Sep 2010 18:26:05 +0400
> Subject: [PATCH 2/6] nv0x: add workaround for TNT2 and small sifm copies,
> shuts up errors but texenv demo still NOT fixed.
>
> ---
> src/mesa/drivers/dri/nouveau/nv04_surface.c | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nv04_surface.c
> b/src/mesa/drivers/dri/nouveau/nv04_surface.c
> index e3febf7..48078f9 100644
> --- a/src/mesa/drivers/dri/nouveau/nv04_surface.c
> +++ b/src/mesa/drivers/dri/nouveau/nv04_surface.c
> @@ -410,10 +410,19 @@ nv04_surface_copy(GLcontext *ctx,
> nv04_surface_copy_m2mf(ctx, dst, src, dx, dy, sx, sy, w, h);
> return;
> }
> +
> + /* TNT2 seems to be upset if we use sifm with small region,
> + add workaround */
> + int sifm_allowed = 0;
> + if (context_chipset(ctx) < 0x10) {
> + if (w > 8 && h > 8)
> + sifm_allowed = 1;
> + } else { sifm_allowed = 1; }
> +
It's probably not about size, but about alignment, and most likely we
can keep using accelerated copies fixing the provided coordinates.
>
> /* Swizzle using sifm+swzsurf. */
> if (src->layout == LINEAR && dst->layout == SWIZZLED &&
> - dst->cpp != 1 && !(dst->offset & 63)) {
> + dst->cpp != 1 && !(dst->offset & 63) && (sifm_allowed == 1)) {
> nv04_surface_copy_swizzle(ctx, dst, src, dx, dy, sx, sy, w, h);
> return;
> }
> --
> 1.7.0.2
>
> From c183d547ec41466e902248c856c7291dfac33726 Mon Sep 17 00:00:00 2001
> From: Andrew Randrianasulu
> Date: Tue, 7 Sep 2010 19:00:31 +0400
> Subject: [PATCH 3/6] nouveau: Trivially move GL_ARB_texture_env_dot3 and
> GL_ARB_texture_env_combine
> from common extension list into nv10 and nv20 specific extension lists, so
> they will not show up on nv0x.
>
> ---
> src/mesa/drivers/dri/nouveau/nouveau_context.c |2 --
> src/mesa/drivers/dri/nouveau/nv10_context.c|2 ++
> src/mesa/drivers/dri/nouveau/nv20_context.c|2 ++
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c
> b/src/mesa/drivers/dri/nouveau/nouveau_context.c
> index f481161..e9e7bbf 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
> @@ -50,8 +50,6 @@
> static const struct dri_extension nouveau_extensions[] = {
> { "GL_ARB_multitexture",NULL },
> { "GL_ARB_texture_env_add", NULL },
> - { "GL_ARB_texture_env_combine", NULL },
> - { "GL_ARB_texture_env_dot3",NULL },
> { "GL_ARB_texture_mirrored_repeat", NULL },
> { "GL_EXT_fog_coord", GL_EXT_fog_coord_functions },
> { "GL_EXT_framebuffer_blit",NULL },
> diff --git
Re: [Mesa-dev] [PATCH 1/3] glsl: add ir_partial_visitor
On Tue, 07 Sep 2010 13:08:37 -0700, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Luca Barbieri wrote: > > Well, the alternative is to copy&paste this into ir_lower_jumps and > > other similar passes. > > > > I added a new class instead of changing ir_visitor so that subclasses > > that need to examine all leaves will get a compile error if not > > updated when new leaves are introduced. This is debatable though, > > since you need to add the function to ir_visitor anyway. > > The problem with the default navigation is that code breaks in > mysterious ways when new node types are added. We've encountered this a > couple times with the hierarchical visitor. If the visitor base class > is pure virtual, the compiler will tell you all the places that need to > be updated when a new node type is added. The cases where we've had > this problem with the hierarchical visitor have been a bitch to debug. > The extra bit of cut-and-paste seems like a small price to pay. The only value I've seen from the pure virtual methods is that you don't mis-type them (which is a problem I've had with the HV, since the signatures don't all match). People would still regularly cut-and-paste the wrong junk in to make the compile succeed. pgpTKFCPeKi3O.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri wrote: > It would be great if Intel switched to the i915g and i965g Gallium > drivers, since everyone else is concentrating their attention on > Gallium, since it's much easier and better to write drivers for it. I keep hearing this, and a bunch of people have been trying to build the equivalent gallium hardware drivers to various core drivers for a long time. So, can we get some details on a success story? What driver is now more correct/faster than it was before? By how much? How much of that was hardware enabling you did on the gallium side only? pgpoJaGzvZp6B.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
> I keep hearing this, and a bunch of people have been trying to build the > equivalent gallium hardware drivers to various core drivers for a long > time. So, can we get some details on a success story? What driver is > now more correct/faster than it was before? By how much? How much of > that was hardware enabling you did on the gallium side only? I think Corbin Simpson and Marek Olsak could be the best people to comment on this, since they mostly wrote the r300g driver, which seems now to be the preferred driver, instead of the older r300 classic DRI driver. Dave Airlie extensively contributed both to the r300 DRI driver and to r600 Gallium drivers, and possibly others are in a similar position. Keith Whitwell wrote the current Gallium i965 driver, and as far as I know stopped work on it due to other commitments. Personally I never worked on classic drivers, so I can't really give a thorough comparison. The general advantages of Gallium are, as I see it, are: - Ability to write the driver in a more maintainable "object-oriented" fashion, where you just provide code to create hardware-specific objects from general self-contained descriptions and then bind them to the pipeline - Rich set of auxiliary code, much more modern than the Mesa code (kind of like your GLSL compiler vs the old one). Among others, this includes the draw module that by default executes vertex and geometry shaders with LLVM. - Ability to get support for APIs other than OpenGL (e.g. the DDX interface, OpenVG, with work on Cairo, OpenCL, video APIs) mostly for free, and much more efficiently and cleanly than if they were layered on top of OpenGL, which may require custom interfaces anyway - Sharing the code to support all the legacy features and weird corner cases of OpenGL and not exposing the driver to them ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Wed, 8 Sep 2010 18:57:46 +0200, Luca Barbieri wrote:
> S I'd been wanting to do this. Only, I was thinking that instead of
> > adding an ir_binop_all_equal and ir_binop_any_equal, those would just be
> > expressed as not(any(nequal())) and any(equal()). And I say that as
> > probably one of the few that has a backend that wants to recognize
> > all_equal. What do you think?
>
> I think it makes sense: by the way, ir_to_mesa emits the current
> nequal, or my new any_nequal, exactly as it does emit any(equal()).
>
> Of course, what ir_to_mesa does is not really optimal, because it
> should use predicates/condition codes, which are however badly
> supported everywhere.
>
> In general if(any(nequal(a, b))) should become, in pseudo-code,
> assuming a vector predicate register,
>
> SNE_update_pred NONE, a, b
> IFC pred.xyzw:
>
> and certainly not anything using DP4 for optimal performance on
> hardware that has predicates like nv30/nv40.
>
> Modern/scalar hardware would probably prefer that representation too,
> since unlike DP4 it can be readily scalarized.
As far as scalar hardware, right now in the 965 FS backend for:
if (any(lessThan(args, vec4(3.0
gl_FragColor = vec4(0.0, 1.0, 0.0, 0.0);
else
gl_FragColor = vec4(1.0, 0.0, 0.0, 0.0);
I'm getting:
(expression bool || (swiz w (expression bool < (swiz w (var_ref
a...@0x8753010) )(constant float (3.00)) ) )(expression bool || (swiz z
(expression bool < (swiz z (var_ref a...@0x8753010) )(constant float
(3.00)) ) )(expression bool || (expression bool < (swiz x (var_ref
a...@0x8753010) )(constant float (3.00)) ) (swiz y (expression bool < (swiz
y (var_ref a...@0x8753010) )(constant float (3.00)) ) )) ) )
mov(8) g19<1>F g3.3<0,1,0>F{ align1 };
mov(8) g20<1>F 3F { align1 };
cmp.l(8)g21<1>D g19<8,8,1>F g20<8,8,1>F { align1 };
and(8) g21<1>D g21<8,8,1>D 1D { align1 };
mov(8) g22<1>D g24<8,8,1>D { align1 };
mov(8) g23<1>F g3.2<0,1,0>F{ align1 };
mov(8) g24<1>F 3F { align1 };
cmp.l(8)g25<1>D g23<8,8,1>F g24<8,8,1>F { align1 };
and(8) g25<1>D g25<8,8,1>D 1D { align1 };
mov(8) g26<1>D g27<8,8,1>D { align1 };
mov(8) g27<1>F g3<0,1,0>F { align1 };
mov(8) g28<1>F 3F { align1 };
cmp.l(8)g29<1>D g27<8,8,1>F g28<8,8,1>F { align1 };
and(8) g29<1>D g29<8,8,1>D 1D { align1 };
mov(8) g30<1>F g3.1<0,1,0>F{ align1 };
mov(8) g31<1>F 3F { align1 };
cmp.l(8)g32<1>D g30<8,8,1>F g31<8,8,1>F { align1 };
and(8) g32<1>D g32<8,8,1>D 1D { align1 };
mov(8) g33<1>D g33<8,8,1>D { align1 };
or(8) g34<1>D g29<8,8,1>D g33<8,8,1>D { align1 };
or(8) g35<1>D g26<8,8,1>D g34<8,8,1>D { align1 };
or(8) g36<1>D g22<8,8,1>D g35<8,8,1>D { align1 };
mov.ne(8) nullg36<8,8,1>D { align1 };
(+f0) if(8) ip 18D { align1 switch
};
[...]
So the current implementation of if(any()) is looking pretty OK ("or or
or mov.ne if"), though there's a register dependency that could be
eliminated with a bit of juggling, and we could move the cond update up
to the last or. Also, not sure whether to make bools be 0,1 immediately
at cmp time, or to do that at b2f/b2i time. (ignoring gratuitous moves
in that code that will get eliminated later, and obviously register
allocation isn't done.)
If you're working on a driver for a scalar chip, you might want to pull
brw_fs_channel_expressions and brw_fs_vector_splitting up and get them
used -- it should make sensible codegen a lot easier for them.
Hmm, that dependency thing might be nice in general. Take the
or(or(or(a,b),c),d) and make or(or(a,b), or(c,d)) when you've got an
associating operator (probably make sure component counts are equal, or
the type changes can be painful).
pgpxVVfsXPGn5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
> If you're working on a driver for a scalar chip, you might want to pull > brw_fs_channel_expressions and brw_fs_vector_splitting up and get them > used -- it should make sensible codegen a lot easier for them. Current drivers for scalar hardware take Mesa IR/TGSI input and not GLSL IR. Using GLSL IR might be interesting, but how do you plan to support assembly programs? Will a converter from Mesa IR to GLSL IR be used for that? Having two hardware backends, one for GLSL IR, and one for Mesa IR/TGSI doesn't seem to be a feasible long-term solution, and dropping assembly program support also isn't (e.g. Doom 3 will stop working). Also, would converting GLSL IR to LLVM and writing an hardware LLVM backend be a better idea? That gives an instruction matcher, scalarizer and register allocator for free, plus optionally middle-end optimizations. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Wednesday 08 September 2010 11:40:24 Luca Barbieri wrote: > > If you're working on a driver for a scalar chip, you might want to pull > > brw_fs_channel_expressions and brw_fs_vector_splitting up and get them > > used -- it should make sensible codegen a lot easier for them. > > Current drivers for scalar hardware take Mesa IR/TGSI input and not GLSL > IR. > > Using GLSL IR might be interesting, but how do you plan to support > assembly programs? > Will a converter from Mesa IR to GLSL IR be used for that? We intend to change the front-end for ARB fp/vp to generate GLSL IR directly. Then it would be compiled via whatever backend path your driver prefers. Since we also intend to write direct GLSL IR->915 and GLSL IR->965 backends, this would mean that Intel drivers won't use Mesa IR at all. Ideally, Mesa IR should go away eventually - if someone writes a GLSL IR->TGSI converter, none of the Gallium drivers would need it... > Having two hardware backends, one for GLSL IR, and one for Mesa > IR/TGSI doesn't seem to be a feasible long-term solution, and dropping > assembly program support also isn't (e.g. Doom 3 will stop working). > > Also, would converting GLSL IR to LLVM and writing an hardware LLVM > backend be a better idea? > That gives an instruction matcher, scalarizer and register allocator > for free, plus optionally middle-end optimizations. > ___ > 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 (shader-work): glsl: teach loop analysis that array dereferences are bounds on the index
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
>> Clever. :)
>>
>> Technically speaking only the access to the array has undefined
>> behavior, and that undefined behavior does not include program
>> termination.
>
> No, my interpretation is correct, because ARB_robustness contains the
> following text:
> <<
> ... Undefined behavior results from indexing an array with a
> non-constant expression that's greater than or equal to the array's
> size or less than 0. If robust buffer access is enabled via the
> OpenGL API, such indexing must not result in abnormal program
> termination. The results are still undefined, but implementations
> are encouraged to produce zero values for such accesses. Only
> one-dimensional arrays may be declared. ...
>
> Hence, abnormal program termination and undefined results are both
> allowed in the normal (non-robustness) case, and thus it's obvious
> that loop termination is OK too.
>
>> I'm a bit nervous / suspicious that there may be some app
>> out there that relies on the loop running too many times.
>
> However, at least the nVidia Cg compiler seems to refuse to unroll
> this, so caution may indeed be advisable.
I think some of the danger lies in constructs like:
for (int i = 0; i < limit; i++)
if (i < gl_TexCoord.length())
do_something_with(gl_TexCoord[i]);
else
do_something_else();
We need a bunch more tests.
>> I wonder if
>> there should be a flag to disable this particular optimization.
> Yes, so that we can support ARB_robustness.
> We'll probably want an environment variable to force ARB_robustness on
> even if the user did not ask for it.
>
>>> +loop_analysis::visit_leave(ir_dereference_array *ir)
>>> +{
>>> + /* If we're not somewhere inside a loop, there's nothing to do.
>>> +*/
>>> + if (this->state.is_empty())
>>> + return visit_continue_with_parent;
>> I fixed this bug in loop_analysis::visit(ir_dereference_variable *)
>> earlier today. See commit 956f049f.
>
> Thanks.
>
> Are the other places in the file that return visit_continue_with_parent
> correct?
I don't think so.
>> How about:
>>
>> assert(ir->array_index->type->is_integer());
>> ir_constant *const max_index_c =
>> (ir->array_index->type->base_type == GLSL_TYPE_UINT)
>>? new(ir) ir_constant((unsigned)max_index)
>>: new(ir) ir_constant((int)max_index);
>> ir_constant *const zero_c =
>> ir_constant::zero(ir, ir->array_index->type);
>
> Yes, much better.
>
>>> + bound_if = new (ir) ir_if(new(ir) ir_expression(ir_binop_greater,
>>> ir->array_index->type, ir->array_index, max_index_c));
>> Shouldn't this be ir_binop_gequal?
>
> No, max_index is array_length - 1.
>
> Not sure whether it's better to set it to array_length and use gequal instead.
It probably doesn't matter one way or the other. A comment would help
the next person not think it was a bug, though.
>>> + bound_if->self_link();
>> This is weird. Why not insert the new instructions at the top of the
>> loop?
>
> Well, if I actually insert them, then they will end up in the
> resulting Mesa IR code, which is a pessimization.
>
>> It seems like it would be better just store the minimum and
>> maximum "allowed" value for the variable in its entry in loop_variable.
>
> I tried this at first, but it is much more complex, and also doesn't allow
> to automagically support array[2 * i + 1], array[int(f)], and so on.
>
> Instead with this approach, as the general code gains such support, it
> will automatically apply to array bounds too.
I'm a bit nervous about having IR floating around that is expected to be
kept but is not in the instruction stream. My main concern is that a
round of talloc clean up will destroy these objects before they're
intended to be destroyed. What is the intended lifetime of these
instructions? It appears that it's the same as the loop_state object
(or the loop_variable_state objects). If that's the case, one of those
should probably be used as the memory context instead of ir.
The way that these are flagged as being different is also strange.
>> This ought to simplify the follow-on patches as well. I think the key
>> observation is that this trick only works on variable identified as loop
>> induction variables.
>
> I don't understand what you mean here.
I think I was looking at some of the patches out of order. Never mind.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyH3PMACgkQX1gOwKyEAw+UMwCgkpZmd6zc8eVfdCyq35CYQuvP
AVcAoIiCWB0hQUcjpQjmDZU+8XDsc/rk
=yIw6
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Barbieri wrote: >> If you're working on a driver for a scalar chip, you might want to pull >> brw_fs_channel_expressions and brw_fs_vector_splitting up and get them >> used -- it should make sensible codegen a lot easier for them. > > Current drivers for scalar hardware take Mesa IR/TGSI input and not GLSL IR. > > Using GLSL IR might be interesting, but how do you plan to support > assembly programs? > Will a converter from Mesa IR to GLSL IR be used for that? Yes. Post-7.9 we have: 1. Run directly from GLSL IR for software (where "directly" almost certainly involves LLVM). 2. Compile assembly shaders to GLSL IR (possibly via Mesa IR -> GLSL IR translation). This will allow support of other NV assembly extensions for free on more advanced GLSL hardware. This will give better support for applications that use Cg. The GLSL backend for Cg generates some ugly, ugly code. 3. Add full support for GLSL 1.30. 4. Geometry shader support. 5. Gut prog_execute and fixed-function *software* TNL. I suspect that #1 and #2 will happen in parallel (I know Ken wants to work on the converter) so that we can have a single backend in the i965 driver. #5 depends on #1 and #2 being complete and accepted. I'm not sure about the ordering of #3 relative to the others, and #4 depends on it. We really want GLSL 1.30 and geometry shaders by the end of the year. We'll see if it happens. > Having two hardware backends, one for GLSL IR, and one for Mesa > IR/TGSI doesn't seem to be a feasible long-term solution, and dropping > assembly program support also isn't (e.g. Doom 3 will stop working). > > Also, would converting GLSL IR to LLVM and writing an hardware LLVM > backend be a better idea? > That gives an instruction matcher, scalarizer and register allocator > for free, plus optionally middle-end optimizations. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyH3sUACgkQX1gOwKyEAw/adACghnChPV5L95ArCPUO4q83VIqX PAoAnA/L01WMlqh3hpcy69+Hq4IjcYlN =V7Qt -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GL_NV_texture_env_combine4, Mesa and TNT2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Francisco Jerez wrote:
> randrianas...@gmail.com writes:
>
>> Very hackish patch series for nv0x hardware, please take look and comment on
>> changes, blame me for errors etc.
>>
>> Francisco, might be nouveau list is better for this stuff?
>
> It's fine either way, do it as you prefer.
Patches to core Mesa should go to mesa-dev for review.
>> From 3accecebe12d34e74feae8149615c379bea54915 Mon Sep 17 00:00:00 2001
>> From: Andrew Randrianasulu
>> Date: Wed, 8 Sep 2010 15:27:24 +0400
>> Subject: [PATCH 5/6] mesa: hack support for EXT_texture_env_combine in
>> texenv.c, avoid gl errors if only this extension enabled in driver
>>
>> ---
>> src/mesa/main/texenv.c |6 --
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/main/texenv.c b/src/mesa/main/texenv.c
>> index 4442fb8..d8402da 100644
>> --- a/src/mesa/main/texenv.c
>> +++ b/src/mesa/main/texenv.c
>> @@ -320,7 +320,8 @@ set_combiner_operand(GLcontext *ctx,
>>alpha = GL_FALSE;
>>break;
>> case GL_OPERAND2_RGB:
>> - if (ctx->Extensions.ARB_texture_env_combine) {
>> + if (ctx->Extensions.ARB_texture_env_combine ||
>> +ctx->Extensions.EXT_texture_env_combine) {
>> term = 2;
>> alpha = GL_FALSE;
>>}
>> @@ -348,7 +349,8 @@ set_combiner_operand(GLcontext *ctx,
>>alpha = GL_TRUE;
>>break;
>> case GL_OPERAND2_ALPHA:
>> - if (ctx->Extensions.ARB_texture_env_combine) {
>> + if (ctx->Extensions.ARB_texture_env_combine ||
>> +ctx->Extensions.EXT_texture_env_combine) {
>> term = 2;
>> alpha = GL_TRUE;
>>}
>> --
>> 1.7.0.2
>>
>
> That's incorrect, it makes mesa pass through illegal combinations like:
>> glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_ONE_MINUS_SRC_COLOR);
I have a pair patches that will fix this. I'm trying to track down an
unrelated regression that occurred last night first.
>> From 6e3cbb059b96032bd1a800b802e15f0c72e291fd Mon Sep 17 00:00:00 2001
>> From: Andrew Randrianasulu
>> Date: Wed, 8 Sep 2010 15:29:11 +0400
>> Subject: [PATCH 6/6] nv0x: avoid assertion, just hack, we need properly
>> enable multitexturing engine for advanced texenv modes and/or emulated
>> textures, may be by dirtying context on texenv changes?
>>
>> ---
>> src/mesa/drivers/dri/nouveau/nv04_state_raster.c | 10 --
>> 1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
>> b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
>> index c191571..a2544fb 100644
>> --- a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
>> +++ b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
>> @@ -307,11 +307,17 @@ nv04_emit_blend(GLcontext *ctx, int emit)
>> else
>> blend |= NV04_TEXTURED_TRIANGLE_BLEND_SHADE_MODE_FLAT;
>>
>> +
>> +
>> /* Texture environment. */
>> -if (ctx->Texture._EnabledUnits)
>> +if (ctx->Texture._EnabledUnits) {
>> +if ((ctx->Texture.Unit[0].EnvMode == GL_REPLACE) ||
>> +ctx->Texture.Unit[0].EnvMode == GL_MODULATE ||
>> +ctx->Texture.Unit[0].EnvMode == GL_DECAL) {
>> blend |= get_texenv_mode(ctx->Texture.Unit[0].EnvMode);
>> -else
>> +} else { blend |= get_texenv_mode(GL_MODULATE); }
>> blend |= get_texenv_mode(GL_MODULATE);
>> +}
> What exactly are you trying to workaround here?
This looks like spurious punctuation changes that deviate from any
coding standards that I've ever seen in Mesa or DRI drivers.
>>
>> /* Secondary color */
>> if (NEED_SECONDARY_COLOR(ctx))
>> --
>> 1.7.0.2
>
>> From 8d361fd58f6c5543f398aeb2a8eaff596bf721d8 Mon Sep 17 00:00:00 2001
>> From: Andrew Randrianasulu
>> Date: Wed, 8 Sep 2010 06:50:04 +0400
>> Subject: [PATCH 4/6] nouveau: Add GL_EXT_texture_env_combine and
>> GL_NV_texture_env_combine4 into common extension list, currently fail piglit
>> tests, need more testing!
>>
>> ---
>> src/mesa/drivers/dri/nouveau/nouveau_context.c |2 ++
>> src/mesa/drivers/dri/nouveau/nv04_state_frag.c | 10 +-
>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c
>> b/src/mesa/drivers/dri/nouveau/nouveau_context.c
>> index e9e7bbf..0b735df 100644
>> --- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
>> +++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
>> @@ -56,8 +56,10 @@ static const struct dri_extension nouveau_extensions[] = {
>> { "GL_EXT_framebuffer_object", GL_EXT_framebuffer_object_functions },
>> { "GL_EXT_secondary_color", GL_EXT_secondary_color_functions },
>> { "GL_EXT_stencil_wrap",NULL },
>> +{ "GL_EXT_texture_env_combine", NULL },
>> { "GL_EXT_texture_lod_
Re: [Mesa-dev] Mesa (shader-work): glsl: teach loop analysis that array dereferences are bounds on the index
> I think some of the danger lies in constructs like:
>
> for (int i = 0; i < limit; i++)
> if (i < gl_TexCoord.length())
> do_something_with(gl_TexCoord[i]);
> else
> do_something_else();
Yes, you are right.
What we should logically do is apply this optimization, but only if
the dereference is guaranteed to be executed.
A simple method seems to be to check that it is not inside an if, and
is not preceded by any code with continue or break.
Presumably the induction variable code needs to check this too, since
otherwise this infinite loop would be broken too:
for (int i = 0;; i++)
{
do_something();
if(i >= 2)
continue;
if(i >= 3)
break;
}
> What is the intended lifetime of these
> instructions? It appears that it's the same as the loop_state object
> (or the loop_variable_state objects). If that's the case, one of those
> should probably be used as the memory context instead of ir.
Right.
Is the way talloc is used and works documented anywhere?
In particular, calling placement new with any part of the IR is always
equivalent, right?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
> We intend to change the front-end for ARB fp/vp to generate GLSL IR directly. Nice. It's probably a good idea to extend GLSL IR to represent things like LOG and LIT directly and have optional lowering passes for them, so that DX9 hardware with native instructions for them can still easily generate them without complex matching. > Then it would be compiled via whatever backend path your driver prefers. > Since we also intend to write direct GLSL IR->915 and GLSL IR->965 backends, > this would mean that Intel drivers won't use Mesa IR at all. Ideally, Mesa IR > should go away eventually There are non-Intel DRI drivers using Mesa IR though: r200, r300 and r600. While r300 and r600 seem likely to be eventually dropped in favor of the gallium drivers, r200 will likely stay. So it looks like that either r200 needs to be converted to use TGSI instead of Mesa IR, or vertex program support dropped on r200. Also, you will need to rewrite the fixed function program generator to generate GLSL IR. That said, it seems a very good idea, especially because Mesa IR is mostly equivalent to TGSI, and would need a truly major update anyway to be able to represent modern assembly languages like NV_gpu_shader5 and AMD IL. > - if someone writes a GLSL IR->TGSI converter, none > of the Gallium drivers would need it... Gallium could probably add GLSL IR as a shader input format, and eventually drop TGSI in favor of it, since most drivers don't really like it. However a GLSL IR->TGSI pass (which is relatively easy to write by just refactoring ir_to_mesa.cpp) will still be needed for a while, since a lot of code depends on TGSI. BTW, it would be nice to support GL_EXT_separate_shader_objects soon, since hardware drivers and Gallium will tend to work in that mode anyway. Later (or soon in a driver-initiated fashion), a further transition to LLVM could be advisable, but this is easy and GLSL IR is still going to be great as a frontend IR, because as you can see in the glsl2-llvm branch, converting it to LLVM IR is easy and can work quite well. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GL_NV_texture_env_combine4, Mesa and TNT2
Ian Romanick writes: > [...] > > At some point it may be worth adding a dri-conf option to enable fake > ARB_texture_env_combine support. There are a few apps that check for > that but not for the EXT. I'd swear that NV drivers used to support the > ARB extension on TNT2 hardware. They did some hack that let them do > some cases of GL_SUBTRACT using the combine4 hardware. I may just be > misremembering, though. > Yup, we can hack up GL_SUBTRACT support as long as the user leaves the constant color untouched, not sure it's worth the work though, nvidia doesn't seem to claim ARB support in this old extension list I had laying around [1]. Maybe it was someone else? >>> diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_frag.c >>> b/src/mesa/drivers/dri/nouveau/nv04_state_frag.c >>> index d7c86d4..d95ac97 100644 >>> --- a/src/mesa/drivers/dri/nouveau/nv04_state_frag.c >>> +++ b/src/mesa/drivers/dri/nouveau/nv04_state_frag.c >>> @@ -89,13 +89,13 @@ get_input_source(struct combiner_state *rc, int source) >>> case GL_TEXTURE1: >>> return COMBINER_SOURCE(TEXTURE1); >>> >>> - case GL_CONSTANT: >>> + case GL_CONSTANT_EXT: >>> return COMBINER_SOURCE(CONSTANT); >>> >>> - case GL_PRIMARY_COLOR: >>> + case GL_PRIMARY_COLOR_EXT: >>> return COMBINER_SOURCE(PRIMARY_COLOR); >>> >>> - case GL_PREVIOUS: >>> + case GL_PREVIOUS_EXT: >>> return rc->unit ? COMBINER_SOURCE(PREVIOUS) : >>> COMBINER_SOURCE(PRIMARY_COLOR); >>> >>> @@ -202,7 +202,7 @@ setup_combiner(struct combiner_state *rc) >>> UNSIGNED_OP(rc); >>> break; >>> >>> - case GL_INTERPOLATE: >>> + case GL_INTERPOLATE_EXT: >>> INPUT_ARG(rc, 0, 0, 0); >>> INPUT_ARG(rc, 1, 2, 0); >>> INPUT_ARG(rc, 2, 1, 0); >>> @@ -210,7 +210,7 @@ setup_combiner(struct combiner_state *rc) >>> UNSIGNED_OP(rc); >>> break; >>> >>> - case GL_ADD_SIGNED: >>> + case GL_ADD_SIGNED_EXT: >>> INPUT_ARG(rc, 0, 0, 0); >>> INPUT_SRC(rc, 1, ZERO, INVERT); >>> INPUT_ARG(rc, 2, 1, 0); >> >> That's pointless, the _EXT definitions match the core ones, they're just >> uglier. > > Agreed. The convention in Mesa has been: > > - Use the most recent names available for enums. > > - Don't change the enums used unless there is good reason. > > This particular patch fails both. [1] http://annarchy.freedesktop.org/~currojerez/glxinfo-nvidia-nv05.txt pgpOQI2qe8HvU.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r300 presubtract v2
On Tue, 2010-09-07 at 22:23 -0700, Tom Stellard wrote: > Hi, > > I have just pushed a branching adding support for presubtract sources to > my personal repo. The branch contains peephole optimizations for all the > presubtract operations except for 1 - 2 * src0. I've tested this branch > on an RV370 and an RV515 and both match the piglit results from master. > > The branch name is presub-rebase-v2 and you can check it out from here: > git://anongit.freedesktop.org/~tstellar/mesa > > The changes in the branch touch almost every part of the compiler, so > I'll wait a few days to push this to give people a chance to comment. > I haven't done a lot of performance testing on this branch yet, so I'm > not sure what the performance impact will be. I'm hoping at the very > least this will help fix some of the "too many instructions" bugs. This seems to have regressed the game Shadowgrounds, I'm mostly just getting a black screen. (It's working on master). Should be reproducable with the demo: http://demofiles.linuxgamepublishing.com/shadowgrounds/ -- 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] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
> 2. Compile assembly shaders to GLSL IR (possibly via Mesa IR -> GLSL IR > translation). This will allow support of other NV assembly extensions > for free on more advanced GLSL hardware. This will give better support > for applications that use Cg. The GLSL backend for Cg generates some > ugly, ugly code. How about doing the work to support Cg directly instead of that of supporting the assembly extensions? (which may actually be easier) nVidia for instance has a compiler that supports both Cg and GLSL. As far as I know, only nVidia's own demos require the assembly extensions, and everything else just use ARB_vp/fp or GLSL since that's the only way to run on non-nVidia hardware. Also, while NV_fragment_program_option/2 and NV_vertex_program1-3 match nVidia GeForce FX/6/7 hardware closely, NV_gpu_program4/5 don't even have that advantage, since the later nVidia hardware is scalar and not at all like those extensions. That said, the idea of using a complex language like GLSL as the API interface is one of the usual bad design decisions of OpenGL (since, for instance, it essentially guarantees incompatibilities, and forces everyone implementing it do a lot of unnecessary work), and it would be much better if OpenGL just specified a binary bytecode format (like, say, Direct3D 11), but unfortunately this is what the current situation is. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Thu, Sep 9, 2010 at 3:28 AM, Eric Anholt wrote: > On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri > wrote: > >> It would be great if Intel switched to the i915g and i965g Gallium >> drivers, since everyone else is concentrating their attention on >> Gallium, since it's much easier and better to write drivers for it. > > I keep hearing this, and a bunch of people have been trying to build the > equivalent gallium hardware drivers to various core drivers for a long > time. So, can we get some details on a success story? What driver is > now more correct/faster than it was before? By how much? How much of > that was hardware enabling you did on the gallium side only? r300g is a lot more successful than r300 classic, support for things like texture tiling and hyper-z were a lot easier to add to the gallium driver. These were very difficult to add to classic. The thing is you miight enjoy fixing upside down FBO ordering for the 10th time, I personally would rather not know, and that goes for every other corner case in the GL spec that is abstracted away from the driver. Having to not distinguish between and FBO and a rendering buffer, having to not look at visual bits vs renderbuffer bits etc. Texture transfers, and accelerated readpixels for free, I could go on. The only upfront pain I really find with gallium is the winsys/pipe split, I find it mostly unnecessary for writing drivers on Linux and have no need to use those drivers on other non Linux OSes. Really it would be worthwhile taking the i915g driver and fixing it as an exercise so you get llvm draw for free instead of NIHing llvm draw. I'm also disappointed that i915g and i965g never materialised in a useful form, I'm still tempted to write i965g myself, and maybe after r600g is finished I can find some time to bring it up. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Trouble building gallium x11/softpipe
Hi, I'm working with the Khronos Group to implement several EGL extensions in gallium3d. Up until now, I've been working with a mesa codebase that I grabbed way back in April. I'm now trying to migrate to the latest version of mesa (and "rebase" daily) so that I can send my changes to you folk for review. However, it seems my old ways of building no longer work. Specifically, I used to do: ./autogen.sh --with-state-trackers=egl,es,vega --enable-gallium-swrast make export LD_LIBRARY_PATH=$MESA_ROOT/lib export EGL_DRIVER=$MESA_ROOT/lib/egl_x11_swrast.so When I try that today, egl_x11_swrast.so does not get built, and (not surprisingly) EGL initialization fails. Any hints? Are the build instructions documented somewhere? This trial-and-error approach is getting tiresome ;) Thanks so much for your help! If you can get me through this I'll have some exciting patches for you guys! -Greg Prisament, Lychee Software ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Barbieri wrote: >> We intend to change the front-end for ARB fp/vp to generate GLSL IR directly. > Nice. > It's probably a good idea to extend GLSL IR to represent things like > LOG and LIT directly and have optional lowering passes for them, so > that DX9 hardware with native instructions for them can still easily > generate them without complex matching. I know several generations of hardware have a real LIT instruction, but did anyone ever do a real LOG instruction? In any case, it should be easy enough to generate that instruction from: (expression float log2 (expression float abs (...)) The other difference of LOG vs LG2 is the precision. This is a case where ES-style precision qualifiers would help. Hmm... >> Then it would be compiled via whatever backend path your driver prefers. >> Since we also intend to write direct GLSL IR->915 and GLSL IR->965 backends, >> this would mean that Intel drivers won't use Mesa IR at all. Ideally, Mesa >> IR >> should go away eventually > > There are non-Intel DRI drivers using Mesa IR though: r200, r300 and r600. > While r300 and r600 seem likely to be eventually dropped in favor of > the gallium drivers, r200 will likely stay. > So it looks like that either r200 needs to be converted to use TGSI > instead of Mesa IR, or vertex program support dropped on r200. Going directly from GLSL IR to r200 assembly shouldn't be too difficult. I think I still have a Radeon 8500 around to do it on. Once we've done i965 and i915 (fragment shaders), we should have a solid set of "best practices" for doing this. Converting anything else should be easy after that. > Also, you will need to rewrite the fixed function program generator to > generate GLSL IR. > > That said, it seems a very good idea, especially because Mesa IR is > mostly equivalent to TGSI, and would need a truly major update anyway > to be able to represent modern assembly languages like NV_gpu_shader5 > and AMD IL. > >> - if someone writes a GLSL IR->TGSI converter, none >> of the Gallium drivers would need it... > > Gallium could probably add GLSL IR as a shader input format, and > eventually drop TGSI in favor of it, since most drivers don't really > like it. > However a GLSL IR->TGSI pass (which is relatively easy to write by > just refactoring ir_to_mesa.cpp) will still be needed for a while, > since a lot of code depends on TGSI. Right. This is the sort of incremental approach that we had in mind. Rewriting things piece by piece, learning as you go, is just good software engineering. > BTW, it would be nice to support GL_EXT_separate_shader_objects soon, > since hardware drivers and Gallium will tend to work in that mode > anyway. We probably won't do the EXT version. It has some warts that make it ugly to both app developers and driver developers. Since the ARB version is part of OpenGL 4.1, it will get implemented eventually. > Later (or soon in a driver-initiated fashion), a further transition to > LLVM could be advisable, but this is easy and GLSL IR is still going > to be great as a frontend IR, because as you can see in the glsl2-llvm > branch, converting it to LLVM IR is easy and can work quite well. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyIAwIACgkQX1gOwKyEAw+CUgCfcBQccgI6zwW/vOnwr9BVLf7F T7YAn0fUOMYza3MumSafjEBaCjeCtSeW =DkzB -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: > On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri > wrote: > >> It would be great if Intel switched to the i915g and i965g Gallium >> drivers, since everyone else is concentrating their attention on >> Gallium, since it's much easier and better to write drivers for it. > > I keep hearing this, and a bunch of people have been trying to build the > equivalent gallium hardware drivers to various core drivers for a long > time. So, can we get some details on a success story? What driver is > now more correct/faster than it was before? By how much? How much of > that was hardware enabling you did on the gallium side only? And never mind that you can't make a conformant OpenGL driver with Gallium due to the impossibility of software fallbacks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyIBIAACgkQX1gOwKyEAw8+wACfZCjPtxA5FQOGcqVcshvsorxB 4zsAn2LnfZ8rAqKbeySoQd7rqHArksmV =24zb -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Barbieri wrote: > That said, the idea of using a complex language like GLSL as the API > interface is one of the usual bad design decisions of OpenGL (since, > for instance, it essentially guarantees incompatibilities, and forces > everyone implementing it do a lot of unnecessary work), and it would > be much better if OpenGL just specified a binary bytecode format > (like, say, Direct3D 11), but unfortunately this is what the current > situation is. The mistakes of D3D again rear their ugly head. Every D3D driver has to attempt to reverse engineer the assembly code that it is given to do real optimization. It make the driver (and the driver writer) do orders of magnitude more work. The only people that it helps are people like S3 or XGI that don't have a budget to hire a full driver team. For everyone else it just plain sucks. The incompatibilities are largely because we have *no* conformance tests for anything past OpenGL 1.2. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyIBe8ACgkQX1gOwKyEAw99HQCcCwHptAw3kB42otxGzKJqp2ky 5tIAoJpUWqu/tYV2YFtRaVUGdjrYkPBI =WCid -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Thu, Sep 9, 2010 at 7:47 AM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eric Anholt wrote: >> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri >> wrote: >> >>> It would be great if Intel switched to the i915g and i965g Gallium >>> drivers, since everyone else is concentrating their attention on >>> Gallium, since it's much easier and better to write drivers for it. >> >> I keep hearing this, and a bunch of people have been trying to build the >> equivalent gallium hardware drivers to various core drivers for a long >> time. So, can we get some details on a success story? What driver is >> now more correct/faster than it was before? By how much? How much of >> that was hardware enabling you did on the gallium side only? > > And never mind that you can't make a conformant OpenGL driver with > Gallium due to the impossibility of software fallbacks. You mean there is a useful GL conformance test suite to know? I don't think conformant and GL actually happens anymore, nowadays it seems to be a lot more about de-facto. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
> And never mind that you can't make a conformant OpenGL driver with > Gallium due to the impossibility of software fallbacks. Well, you could use the failover module to use softpipe for fallbacks, but no one does, for the following reasons: 1. Modern hardware doesn't need any software fallbacks, and at most you need to "emulate" things with ad-hoc shaders (possibly compute shaders) 2. Software fallbacks are mostly useless because a terribly slow implementation is not significantly more useful than a broken uone ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Wed, 8 Sep 2010 20:40:24 +0200, Luca Barbieri wrote: > > If you're working on a driver for a scalar chip, you might want to pull > > brw_fs_channel_expressions and brw_fs_vector_splitting up and get them > > used -- it should make sensible codegen a lot easier for them. > > Current drivers for scalar hardware take Mesa IR/TGSI input and not GLSL IR. Yes, but depending on your Mesa IR -> HW codegen, seeing scalar expressions that have had algebraic optimizations done on them might be a big win. Looking at some examples on 965, it's about break-even right now without fixing up the codegen (but we need to fix up the codegen anyway). > Using GLSL IR might be interesting, but how do you plan to support > assembly programs? > Will a converter from Mesa IR to GLSL IR be used for that? That's part of the plan. > Having two hardware backends, one for GLSL IR, and one for Mesa > IR/TGSI doesn't seem to be a feasible long-term solution, and dropping > assembly program support also isn't (e.g. Doom 3 will stop working). We've already got 2 Mesa IR backends for the fragment shader in 965, sadly: the non-flow-control FS that does something like value numbering to get dead code elimination and copy propagation, and the GLSL one that still doesn't support function calls and has absolutely ridiculous register allocation. So for us, going from 2 to 2 looks OK, and if we can go from 2 to 1 I can despair about the state of the driver a little less. > Also, would converting GLSL IR to LLVM and writing an hardware LLVM > backend be a better idea? > That gives an instruction matcher, scalarizer and register allocator > for free, plus optionally middle-end optimizations. Structured flow control is the issue. What's the solution for getting that back out of LLVM? pgpnSJf5pwcs4.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Thu, Sep 9, 2010 at 12:22 AM, Luca Barbieri wrote: >> And never mind that you can't make a conformant OpenGL driver with >> Gallium due to the impossibility of software fallbacks. > > Well, you could use the failover module to use softpipe for fallbacks, > but no one does, for the following reasons: > 1. Modern hardware doesn't need any software fallbacks, and at most > you need to "emulate" things with ad-hoc shaders (possibly compute > shaders) > 2. Software fallbacks are mostly useless because a terribly slow > implementation is not significantly more useful than a broken uone That being said the draw module handles all those fun special cases of triangles, lines and quads already so its only when the rasterizer and fragment shader can't handle things that we just do best effort. Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Trouble building gallium x11/softpipe
With some debugging I've figured out that setting EGL_DRIVERS_PATH to
$MESA_ROOT/lib/egl fixes my problem. I'm back in business! ('til I hit the
next roadblock at least). Sorry for the spam.
Cheers,
-Greg Prisament, Lychee Software
On Wed, Sep 8, 2010 at 2:31 PM, Gregory Prisament
wrote:
> Hi,
>
> I'm working with the Khronos Group to implement several EGL extensions in
> gallium3d. Up until now, I've been working with a mesa codebase that I
> grabbed way back in April. I'm now trying to migrate to the latest version
> of mesa (and "rebase" daily) so that I can send my changes to you folk for
> review.
>
> However, it seems my old ways of building no longer work.
>
> Specifically, I used to do:
>
> ./autogen.sh --with-state-trackers=egl,es,vega --enable-gallium-swrast
> make
> export LD_LIBRARY_PATH=$MESA_ROOT/lib
> export EGL_DRIVER=$MESA_ROOT/lib/egl_x11_swrast.so
>
>
> When I try that today, egl_x11_swrast.so does not get built, and (not
> surprisingly) EGL initialization fails.
>
> Any hints? Are the build instructions documented somewhere? This
> trial-and-error approach is getting tiresome ;)
>
> Thanks so much for your help! If you can get me through this I'll have
> some exciting patches for you guys!
> -Greg Prisament, Lychee Software
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
> Structured flow control is the issue. What's the solution for getting > that back out of LLVM? Well, my idea is the following. First, break any self loop edges, then do an SCC decomposition of the CFG, and output the DAG of the SCCs in topological order. SCCs that have size 1 are basic blocks, so just emit them. SCCs that have size >1 become loops. Choose the basic block with the most in-edges from outside the SCC, and make that the loop header. Now, make all the edges from outside to inside the SCC, and those from inside to the header, pass through a new basic block after setting an appropriate flag, which is used by this new basic block to dispatch them to their "old destinations", thus making all in-edges go to this single node, making the CFG reducible. Then, do a similar thing with the out-edges, so that there is a single "after" node for the loop. After that, recurse on the graph formed by the SCC minus the original header, plus the in-edge dispatch node with becomes part of the loop This will give you a CFG which is composed only of loops and conditional forward gotos. Now, process each loop body, which is an acyclic graph after collapsing nested loops. Every time a node has two successors, that's an "if". On each branch, you put those basic blocks that are dominated by the branch out-edge. Now, if these blocks have out-edges to a single node, that's the "endif", and you just recursively process the branches. Otherwise, "cut" those edges by introducing a new dispatch node with a flag. A further issues are switch statements. These can be treated as successive ifs, but the way they are split affects the conciseness of the result. The idea here is to split the graph in biconnected components, and see if any articulation point splits some of the switch cases from the others. If so, you generate an if to separate those cases, and recurse. Post-dominators might also work for this, but it seems biconnected components are required to handle multiple exits due to breaks and returns properly After all this, you rerun all LLVM optimization passes with all parts that could destroy this structure disabled. Then, you convert it to GLSL IR or whatever you want. I have code that does this and seems to work on the tests I did, but it's not yet in a state where it would be mergeable in LLVM upstream. In particular, it's hard to get nice clean code, and avoid quadratic algorithms. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Wed, Sep 8, 2010 at 11:47 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eric Anholt wrote: >> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri >> wrote: >> >>> It would be great if Intel switched to the i915g and i965g Gallium >>> drivers, since everyone else is concentrating their attention on >>> Gallium, since it's much easier and better to write drivers for it. >> >> I keep hearing this, and a bunch of people have been trying to build the >> equivalent gallium hardware drivers to various core drivers for a long >> time. So, can we get some details on a success story? What driver is >> now more correct/faster than it was before? By how much? How much of >> that was hardware enabling you did on the gallium side only? > > And never mind that you can't make a conformant OpenGL driver with > Gallium due to the impossibility of software fallbacks. Hmm thinking more about it doing a proper software fallback for the rasterizer and fragment shader would mostly be trivial. What you would need to write for each driver is file that grabs all the cso:s states and plugs that into the helper object. Doing that is trivial since all state is in cso:s. Grabbing all the needed texture data from the hw textures would all be handled from the helper, since which textures to use is already given via the cso:s, but doing it would be trivial, as we can already run the software rasterizers on top of regular hardware driver (see src/gallium/winsys/sw/wrapper). And it might even be worth it since now we actually have a fast software rasterizer (for things more complex then glxgears and tunnel). Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
> The only people that it helps are people like > S3 or XGI that don't have a budget to hire a full driver team. For > everyone else it just plain sucks. This is the case for all Mesa/Gallium drivers, if you define "full driver team" by the standards of ATI and nVidia Windows driver teams. Hence, something that helps in that case is very much welcome. I'm not sure however how reading some binary bytecode could be more difficult than writing a full lexer+parser+IR definition, and surely incredibly reduces the existance of corner cases. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29279] Define precision of float variables in the es2gears fragment shader
https://bugs.freedesktop.org/show_bug.cgi?id=29279 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Ian Romanick 2010-09-08 17:28:36 PDT --- commit 231bc96e02d3be029d2a47eb9b30ea47d679bfc3 Author: Ian Romanick Date: Wed Sep 8 17:22:16 2010 -0700 Define default precision in es2gears fragment shader This is required by GLSL ES. -- 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] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Wed, 8 Sep 2010 20:25:15 +0200, Luca Barbieri wrote: > > I keep hearing this, and a bunch of people have been trying to build the > > equivalent gallium hardware drivers to various core drivers for a long > > time. So, can we get some details on a success story? What driver is > > now more correct/faster than it was before? By how much? How much of > > that was hardware enabling you did on the gallium side only? > > I think Corbin Simpson and Marek Olsak could be the best people to > comment on this, since they mostly wrote the r300g driver, which seems > now to be the preferred driver, instead of the older r300 classic DRI > driver. > > Dave Airlie extensively contributed both to the r300 DRI driver and to > r600 Gallium drivers, and possibly others are in a similar position. > > Keith Whitwell wrote the current Gallium i965 driver, and as far as I > know stopped work on it due to other commitments. > > Personally I never worked on classic drivers, so I can't really give a > thorough comparison. > > The general advantages of Gallium are, as I see it, are: > - Ability to write the driver in a more maintainable "object-oriented" > fashion, where you just provide code to create hardware-specific > objects from general self-contained descriptions and then bind them to > the pipeline So you're taking the GL state from Mesa's structures, munging it into intermediate structures, then presenting me with intermediate objects? The biggest thing I've found for CPU-side performance on 965 was that you want to avoid some sort of intermediate state step for everything but shader compile. I've seriously thought about going back to the 915-style immediate mode state updates for 965 -- anecdotal evidence From other groups says that this is *immense* win. > - Rich set of auxiliary code, much more modern than the Mesa code > (kind of like your GLSL compiler vs the old one). Among others, this > includes the draw module that by default executes vertex and geometry > shaders with LLVM. There are two things I find attractive about gallium, you nailed one of them: 1) LLVM backends for software 2) Not having to write texture upload/download/blit/etc. code, just the layout. Now, the layout's the part that we screw up the most, and you have to do it either way. But the layout, at least as Intel does it, makes upload/download/copy tough, so not doing that part in the driver somehow would be nice (2.5kloc or so that's been copied around a few times). However, the fact that when I ask about performance nobody says "OMG the texture upload/download/copy/etc. support in gallium is so great and is way faster than anybody managed in classic because it catches all the corner cases" makes me really scared about it. I always wished that instead of gallium we had just got a reworked implementation of texture handling in Mesa. > - Ability to get support for APIs other than OpenGL (e.g. the DDX > interface, OpenVG, with work on Cairo, These 3 only seem interesting to me once you've abstracted the hardware abstraction layer that you have to implement anyway, so that you want to talk to gallium to avoid the overhead of the abstraction layer -> abstraction layer translation. Having written cairo on OpenGL and a partial implementation of X on OpenGL, if you can assume GLSL then OpenGL is a good interface for talking to the hardware. If you can't assume shaders, well, gallium isn't an option anyway. I do not want to write assembly for cairo's gradients or new blend operators or whatever. If your hardware abstraction layer doesn't give me a decent language to talk to in 2010, it sounds like failure. > OpenCL, video APIs) mostly for These two, on 965, want to use the media engine, so I don't see significant sharing to be had between a gallium OpenGL driver and a gallium media driver. You'd share the batchbuffer code, maybe the buffer object handling, texture layout functions for inter-API interaction, what else? Batchbuffers we've wanted to put into libdrm for years but never got around to it, and if we've got multiple things layouting textures, then we'd probably throw that into the shared lib instead of duping it, too. And, as far as video APIs, open-source codec guys tell me they want OpenCL or please go away. Intel codec accel guys just write assembly by hand like real men (wtf?) and stuff it in vaapi. Neither of these sound like video APIs on gallium to me. (though please don't interpret this as me pushing vaapi. The lack of a shipping gstreamer plugin for vaapi pretty much summarizes vaapi's relevance to me.) > - Sharing the code to support all the legacy features and weird corner > cases of OpenGL and not exposing the driver to them This is definitely something good, and meta.c's been mostly working for that in classic Mesa. If we cleaned up renderbuffer handling so the window system FB vs FBOs weren't magic, then I'd be happy. pgp9oXGdt1eZO.pgp Description: PGP signature
Re: [Mesa-dev] New interesting closed-source OpenGL/GLSL test
On Wed, 8 Sep 2010 03:07:50 +0200, Luca Barbieri wrote: > For anyone who doesn't know it yet, there is a new closed-source > OpenGL game for Linux called Amnesia, with the very interesting > property that the developers offer a test program that renders several > complex GLSL-based effects one at a time. > > Unfortunately, it's pretty broken right now (on softpipe), and thus > could be a great test to get to work, since it's much easier to figure > out what's happening than in full games/demos. > > It can be found at: > http://frictionalgames.com/forum/thread-3656.html > > Reference images at: > http://unbirthgame.com/files/feat_test_images_round2.jpg > > The test appears to use several advanced techniques like bloom, > deferred rendering, SSAO, water rendering, and several lighting and > fog models. Very cool, I'll be playing with this! pgpOYUcvD6BHe.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: teach loop analysis that array dereferences are bounds on the index
On Wed, 8 Sep 2010 21:30:56 +0200, Luca Barbieri wrote: > > Right. > Is the way talloc is used and works documented anywhere? > In particular, calling placement new with any part of the IR is always > equivalent, right? I need to put some stuff in the readme about this. Actually, instead of typing you a message, I put some stuff in the readme about this. pgpQDEwkoJaqD.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: teach loop analysis that array dereferences are bounds on the index
Thanks! But, does this mean that if I allocate using new(existing_ir) ir_foo() or opposed to new(talloc_parent(existing_ir)) ir_foo() then this new object will always remain alive as long as existing_ir is alive, even if it's no longer referenced? If so, why would anyone do that, which seems to occur frequently in the codebase? And why is an hierarchical ownership model useful at all, instead of just doing a "mark-and-sweep" plus copying phase after all optimizations, or maybe after a given pass if the allocated memory grows too much? Also, how about just keeping the context in a thread-local variable and using it automatically, possibly in a global way with a gc root registration mechanism? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Thu, Sep 9, 2010 at 2:35 AM, Eric Anholt wrote: > On Wed, 8 Sep 2010 20:25:15 +0200, Luca Barbieri > wrote: >> > I keep hearing this, and a bunch of people have been trying to build the >> > equivalent gallium hardware drivers to various core drivers for a long >> > time. So, can we get some details on a success story? What driver is >> > now more correct/faster than it was before? By how much? How much of >> > that was hardware enabling you did on the gallium side only? >> >> I think Corbin Simpson and Marek Olsak could be the best people to >> comment on this, since they mostly wrote the r300g driver, which seems >> now to be the preferred driver, instead of the older r300 classic DRI >> driver. >> >> Dave Airlie extensively contributed both to the r300 DRI driver and to >> r600 Gallium drivers, and possibly others are in a similar position. >> >> Keith Whitwell wrote the current Gallium i965 driver, and as far as I >> know stopped work on it due to other commitments. >> >> Personally I never worked on classic drivers, so I can't really give a >> thorough comparison. >> >> The general advantages of Gallium are, as I see it, are: >> - Ability to write the driver in a more maintainable "object-oriented" >> fashion, where you just provide code to create hardware-specific >> objects from general self-contained descriptions and then bind them to >> the pipeline > > So you're taking the GL state from Mesa's structures, munging it into > intermediate structures, then presenting me with intermediate objects? > The biggest thing I've found for CPU-side performance on 965 was that > you want to avoid some sort of intermediate state step for everything > but shader compile. I've seriously thought about going back to the > 915-style immediate mode state updates for 965 -- anecdotal evidence > From other groups says that this is *immense* win. >From my profiling on i915 the mesa/gallium state functions never show up, this include the hashmap state cache that is in between the gl state tracker and the driver. Then again that might be drowned out by the sw vertex shader. Corbin tells me on IRC that the same applies for r300g and the hotspots are preparing and emitting HW state, with no hotspot within mesa or gallium, Corbin can you comment please? At least it shows that the cso hashmap and state tracker doesn't cost much and moving to it was a big win. >> - Rich set of auxiliary code, much more modern than the Mesa code >> (kind of like your GLSL compiler vs the old one). Among others, this >> includes the draw module that by default executes vertex and geometry >> shaders with LLVM. > > There are two things I find attractive about gallium, you nailed one of > them: > > 1) LLVM backends for software > 2) Not having to write texture upload/download/blit/etc. code, just the > layout. > > Now, the layout's the part that we screw up the most, and you have to do > it either way. But the layout, at least as Intel does it, makes > upload/download/copy tough, so not doing that part in the driver somehow > would be nice (2.5kloc or so that's been copied around a few times). > However, the fact that when I ask about performance nobody says "OMG the > texture upload/download/copy/etc. support in gallium is so great and is > way faster than anybody managed in classic because it catches all the > corner cases" makes me really scared about it. Okay here goes... The only work I did on classic mesa was on the Unichrome texturing code and not much at that. Working with gallium textures is for me much nicer I can't stress enough how awesome immutable objects are to work with. At least from a driver writer perspective and as AFAIK the immutable object approach has not caused any performance regressions. You create the texture once and then never have to care about it changing the size/format/levels further down the road. > > I always wished that instead of gallium we had just got a reworked > implementation of texture handling in Mesa. But you get so much more. With Gallium being a water tight interface we can insert different layers between the state trackers and drivers. These include rbug the remote debugger. Trace the call tracers and replayer. Galahad the sanity checker for debugging state trackers, in Gallium we don't expect the drivers to do any validation of the incoming state and any such error is regarded as a state tracker bug. Heck you can even run a software rasterizer on top of your hardware driver, which is nice when you want to rule other parts of the stack, letting you remove large swaths of code form where the bug might be, which includes all the nasty GL code. But there is also the view of what you don't get in your driver. You don't need to have any state validation since it should all be handled by the state tracker as mentioned above. You don't need any dri code since that is all handled by another state tracker that is shared across all drivers. All you need to care about is the hardware code. >
[Mesa-dev] Partial merge of shader-work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca, I merged (with some changes) the first 3 patches in your branch. Tomorrow I will merge "glsl: don't fail if EmitNoIfs and we emitted an if" with changes to make the i915 reject shaders that still have if-statements. I'd like some review from someone with Gallium knowledge on the next two. For ir_partial_visitor, I think your idea of having a visitor subclass that effectively ignores certain categories of IR nodes is a good one. I'd like Eric to review "glsl: add continue/break/return unification/elimination pass". I'll try to get some more review comments out tomorrow for the remaining. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyIWbIACgkQX1gOwKyEAw/oJgCdEv9CRi8orTZK6HOMw+CwBdNU WbgAoI1/zYmY0zdXhXr0iN6/VedFgsJZ =udCq -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps
On Thu, Sep 9, 2010 at 2:35 AM, Eric Anholt wrote: > However, the fact that when I ask about performance nobody says "OMG the > texture upload/download/copy/etc. support in gallium is so great and is > way faster than anybody managed in classic because it catches all the > corner cases" makes me really scared about it. > OK so there you have it: The texture upload/download/copy is way faster in r300g than anyone managed in r300c. For example, the ETQW main menu uses some texture streaming and I get 1 fps in r300c and about 30 fps in r300g. That's not something one can ignore. The transfers in r300g were really simple to implement, it's just transfer, map, unmap, transfer (transfer=blit). The code is clean and isolated (about 250 LoC). This is just the driver code. There is also some additional transfer code in st/mesa, but I didn't have to care about that. The overall speed of r300g is either at the same level as r300c or higher, based on what application you look at. Various users have reported that, unlike r300c, all compiz effects just work, kwin works, a lot more games work, and the driver is faster in some apps. We used to have some performance issues in Tremulous not so long ago, but that's been fixed since then. Of course, one can find synthetic tests where one driver is always faster than another. I am talking about real world applications here. For example, I no longer have to kill Strogg in ETQW with the lowest details on my R580 for it to be smooth. r300g is quite optimized (I say "quite", because you're never sure), so the overhead of other mesa components is larger than other Gallium drivers might be able to see. In Tremulous, the overhead of r300g+libdrm is under 50% of the whole time spent in Mesa, and that's without using Draw, so we should start caring about the speed of st/mesa and mesa/main. The only obvious way to get some speed there seems to be merging Mesa core with st/mesa, dropping the classic driver inteface, and simplifying the whole thing. I guess this won't happen until everybody moves to Gallium. It's a sure thing Gallium is the future, and it doesn't seem to be a good idea to implement e.g. LLVM-powered vertex shaders for classic, considering the same thing has already been implemented and now stable in Gallium. The only disadvantage of Gallium seems to be TGSI. It's not better than Mesa IR, because all shaders must pass through Mesa IR anyway. I suppose using GLSL IR or something similar would help some drivers produce more optimized shaders (I am getting at temporary arrays here, which r300 hardware partially supports). Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Trouble building gallium x11/softpipe
On Thu, Sep 9, 2010 at 6:39 AM, Gregory Prisament
wrote:
> With some debugging I've figured out that setting EGL_DRIVERS_PATH to
> $MESA_ROOT/lib/egl fixes my problem. I'm back in business! ('til I hit the
> next roadblock at least). Sorry for the spam.
There is now a single gallium-based EGL driver, egl_gallium.so. Its role is
similar to DRI libGL.so in that it is a slim layer that loads the hardware
drivers (pipe_xxx.so) and client APIs (st_xxx.so), found in $EGL_DRIVERS_PATH.
If the setup is too complex for your need, you may also consider build a
egl_gallium.so that statically links to the softpipe/llvmpipe and the client
APIs selected at build time. Have a look at targets/egl-gdi/ as an example.
The suggested way to configure Mesa has also changed to:
$ ./configure --enable-gles-overlay --with-state-trackers=egl,vega
> Cheers,
> -Greg Prisament, Lychee Software
>
> On Wed, Sep 8, 2010 at 2:31 PM, Gregory Prisament
> wrote:
>>
>> Hi,
>>
>> I'm working with the Khronos Group to implement several EGL extensions in
>> gallium3d. Up until now, I've been working with a mesa codebase that I
>> grabbed way back in April. I'm now trying to migrate to the latest version
>> of mesa (and "rebase" daily) so that I can send my changes to you folk for
>> review.
>>
>> However, it seems my old ways of building no longer work.
>>
>> Specifically, I used to do:
>>
>> ./autogen.sh --with-state-trackers=egl,es,vega --enable-gallium-swrast
>> make
>> export LD_LIBRARY_PATH=$MESA_ROOT/lib
>> export EGL_DRIVER=$MESA_ROOT/lib/egl_x11_swrast.so
>>
>>
>> When I try that today, egl_x11_swrast.so does not get built, and (not
>> surprisingly) EGL initialization fails.
>>
>> Any hints? Are the build instructions documented somewhere? This
>> trial-and-error approach is getting tiresome ;)
>>
>> Thanks so much for your help! If you can get me through this I'll have
>> some exciting patches for you guys!
>> -Greg Prisament, Lychee Software
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GL_NV_texture_env_combine4, Mesa and TNT2
Very hackish patch series for nv0x hardware, please take look and comment on
changes, blame me for errors etc.
Francisco, might be nouveau list is better for this stuff?
From 9bf16a26361ab4a44b6568deae30c523488cde1b Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Mon, 6 Sep 2010 18:17:48 +0400
Subject: [PATCH 1/6] nv0x: use multitexturing engine for A8 textures, fixes teapot demo broken
probably since we started to use _mesa_meta_Bitmap
---
src/mesa/drivers/dri/nouveau/nv04_context.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c b/src/mesa/drivers/dri/nouveau/nv04_context.c
index 6834f7c..af46ce2 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
@@ -38,6 +38,7 @@ nv04_context_engine(GLcontext *ctx)
struct nouveau_hw_state *hw = &to_nouveau_context(ctx)->hw;
struct nouveau_grobj *fahrenheit;
+
if (ctx->Texture.Unit[0].EnvMode == GL_COMBINE ||
ctx->Texture.Unit[0].EnvMode == GL_BLEND ||
ctx->Texture.Unit[0].EnvMode == GL_ADD ||
@@ -46,6 +47,13 @@ nv04_context_engine(GLcontext *ctx)
fahrenheit = hw->eng3dm;
else
fahrenheit = hw->eng3d;
+
+ if (ctx->Texture.Unit[0]._ReallyEnabled) {
+ struct gl_texture_object *t = ctx->Texture.Unit[0]._Current;
+ struct gl_texture_image *ti = t->Image[0][t->BaseLevel];
+ if (ti->_BaseFormat == GL_ALPHA)
+ fahrenheit = hw->eng3dm;
+ }
if (fahrenheit != nctx->eng3d) {
nctx->eng3d = fahrenheit;
--
1.7.0.2
From 8ca9fd5db720af498fcaf1365db19fbd2be57b57 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Mon, 6 Sep 2010 18:26:05 +0400
Subject: [PATCH 2/6] nv0x: add workaround for TNT2 and small sifm copies, shuts up errors but texenv demo still NOT fixed.
---
src/mesa/drivers/dri/nouveau/nv04_surface.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_surface.c b/src/mesa/drivers/dri/nouveau/nv04_surface.c
index e3febf7..48078f9 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_surface.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_surface.c
@@ -410,10 +410,19 @@ nv04_surface_copy(GLcontext *ctx,
nv04_surface_copy_m2mf(ctx, dst, src, dx, dy, sx, sy, w, h);
return;
}
+
+ /* TNT2 seems to be upset if we use sifm with small region,
+ add workaround */
+ int sifm_allowed = 0;
+ if (context_chipset(ctx) < 0x10) {
+ if (w > 8 && h > 8)
+ sifm_allowed = 1;
+ } else { sifm_allowed = 1; }
+
/* Swizzle using sifm+swzsurf. */
if (src->layout == LINEAR && dst->layout == SWIZZLED &&
- dst->cpp != 1 && !(dst->offset & 63)) {
+ dst->cpp != 1 && !(dst->offset & 63) && (sifm_allowed == 1)) {
nv04_surface_copy_swizzle(ctx, dst, src, dx, dy, sx, sy, w, h);
return;
}
--
1.7.0.2
From c183d547ec41466e902248c856c7291dfac33726 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Tue, 7 Sep 2010 19:00:31 +0400
Subject: [PATCH 3/6] nouveau: Trivially move GL_ARB_texture_env_dot3 and GL_ARB_texture_env_combine
from common extension list into nv10 and nv20 specific extension lists, so they will not show up on nv0x.
---
src/mesa/drivers/dri/nouveau/nouveau_context.c |2 --
src/mesa/drivers/dri/nouveau/nv10_context.c|2 ++
src/mesa/drivers/dri/nouveau/nv20_context.c|2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c b/src/mesa/drivers/dri/nouveau/nouveau_context.c
index f481161..e9e7bbf 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
@@ -50,8 +50,6 @@
static const struct dri_extension nouveau_extensions[] = {
{ "GL_ARB_multitexture", NULL },
{ "GL_ARB_texture_env_add", NULL },
- { "GL_ARB_texture_env_combine", NULL },
- { "GL_ARB_texture_env_dot3", NULL },
{ "GL_ARB_texture_mirrored_repeat", NULL },
{ "GL_EXT_fog_coord", GL_EXT_fog_coord_functions },
{ "GL_EXT_framebuffer_blit", NULL },
diff --git a/src/mesa/drivers/dri/nouveau/nv10_context.c b/src/mesa/drivers/dri/nouveau/nv10_context.c
index b6d1036..7f2 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_context.c
@@ -34,6 +34,8 @@
static const struct dri_extension nv10_extensions[] = {
{ "GL_EXT_texture_rectangle", NULL },
+ { "GL_ARB_texture_env_combine", NULL },
+ { "GL_ARB_texture_env_dot3",NULL },
{ NULL,NULL }
};
diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c b/src/mesa/drivers/dri/nouveau/nv20_context.c
index 789dcaa..03cb14a 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
@@ -33,6 +33,8 @@
static const struct dri_extension nv20_extensions[] = {
{ "GL_EXT_texture_rectangle", NULL },
+ { "GL_ARB_texture_env_combine", NULL },
+ { "GL_ARB_texture_env_dot3",NULL },
{ NULL,NULL }
};
--
1.7.0.2
From 3accecebe12d34e74feae8149615c379bea5
[Mesa-dev] Some questions about nouveau classic driver
Hi. I have running linux on my very old machine with nv17 card and I am impressed that kde4 with nouveau driver work so fast. I am also curious about few things: 1. In nvfx was implemented sot so long time ago a new 2d engine. It wil be ported to classic dri driver too ? 2. Will be added support for s3tc ? 3. What extensons are missing ? - I cannot run my favorite game Max Payne with wine :( -- Pobierz za darmo gre! Sprawdz >> http://linkint.pl/f2800 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GL_NV_texture_env_combine4, Mesa and TNT2 , updated
well, i realized there was too many mistakes on my side. For now it "work" as
not assert during two piglit tests.
results:
Results for glean/texCombine4
Returncode: 0
Errors:
libGL: OpenDriver:
trying /mnt/hdd1/src/mesa-clean/mesa/lib/nouveau_vieux_dri.so
Mesa: Mesa 7.9-devel DEBUG build Sep 5 2010 00:01:42
Output:
--
Test the GL_NV_texture_env_combine4 extension.
texCombine4: Error: GL_NV_texure_env_combine4 failed
Current GL state:
COMBINE = GL_ADD_SIGNED_EXT
SOURCE0: GL_ZERO
OPERAND0_RGB: GL_SRC_COLOR
OPERAND0_ALPHA: GL_SRC_ALPHA
SOURCE1: GL_ZERO
OPERAND1_RGB: GL_ONE_MINUS_SRC_COLOR
OPERAND1_ALPHA: GL_ONE_MINUS_SRC_ALPHA
SOURCE2: GL_ZERO
OPERAND2_RGB: GL_ONE_MINUS_SRC_COLOR
OPERAND2_ALPHA: GL_ONE_MINUS_SRC_ALPHA
SOURCE3: GL_ZERO
OPERAND3_RGB: GL_SRC_COLOR
OPERAND3_ALPHA: GL_SRC_ALPHA
Primary Color: 0.995, 0.853, 0.500, 0.642
Constant Color: 0.861, 0.596, 0.091, 0.140
Texture Color: 0.950, 0.925, 0.889, 0.551
Results:
Expected color: 0.000, 0.000, 0.000, 0.000
Rendered color: 0.498, 0.498, 0.498, 0.498
texCombine4: FAIL rgba8, db, z24, s8, win+pmap, id 33
and
Results for glean/texEnv
eturncode: 0
Errors:
libGL: OpenDriver:
trying /mnt/hdd1/src/mesa-clean/mesa/lib/nouveau_vieux_dri.so
Mesa: Mesa 7.9-devel DEBUG build Sep 5 2010 00:01:42
Output:
--
Test basic texture env modes for all base texture formats.
texEnv: FAIL: GL_TEXTURE_ENV_MODE=GL_REPLACE Texture Format=GL_INTENSITY
Fragment Color=(0, 0, 0, 0) Texture Color=(0, 0, 0, 0) Tex Env Color=(0, 0,
0, 0) Blend over=(0.5, 0.5, 0.5, 0.5) Expected=(0.5, 0.5, 0.5, 0.5)
Measured=(0, 0, 0, 1)
texEnv: FAIL: GL_TEXTURE_ENV_MODE=GL_MODULATE Texture Format=GL_INTENSITY
Fragment Color=(0, 0, 0, 0.5) Texture Color=(0, 0, 0, 0) Tex Env Color=(0,
0, 0, 0) Blend over=(0.5, 0.5, 0.5, 0.5) Expected=(0.5, 0.5, 0.5, 0.5)
Measured=(0.247059, 0.247059, 0.247059, 0.501961)
texEnv: FAIL: GL_TEXTURE_ENV_MODE=GL_REPLACE Texture Format=GL_RGB
Fragment Color=(0, 0, 0, 0) Texture Color=(0, 0, 0, 0) Tex Env Color=(0, 0,
0, 0) Blend over=(0.5, 0.5, 0.5, 0.5) Expected=(0.5, 0.5, 0.5, 0.5)
Measured=(0, 0, 0, 1)
texEnv: FAIL rgba8, db, z24, s8, win+pmap, id 33
--
From 9bf16a26361ab4a44b6568deae30c523488cde1b Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Mon, 6 Sep 2010 18:17:48 +0400
Subject: [PATCH 1/7] nv0x: use multitexturing engine for A8 textures, fixes teapot demo broken
probably since we started to use _mesa_meta_Bitmap
---
src/mesa/drivers/dri/nouveau/nv04_context.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c b/src/mesa/drivers/dri/nouveau/nv04_context.c
index 6834f7c..af46ce2 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
@@ -38,6 +38,7 @@ nv04_context_engine(GLcontext *ctx)
struct nouveau_hw_state *hw = &to_nouveau_context(ctx)->hw;
struct nouveau_grobj *fahrenheit;
+
if (ctx->Texture.Unit[0].EnvMode == GL_COMBINE ||
ctx->Texture.Unit[0].EnvMode == GL_BLEND ||
ctx->Texture.Unit[0].EnvMode == GL_ADD ||
@@ -46,6 +47,13 @@ nv04_context_engine(GLcontext *ctx)
fahrenheit = hw->eng3dm;
else
fahrenheit = hw->eng3d;
+
+ if (ctx->Texture.Unit[0]._ReallyEnabled) {
+ struct gl_texture_object *t = ctx->Texture.Unit[0]._Current;
+ struct gl_texture_image *ti = t->Image[0][t->BaseLevel];
+ if (ti->_BaseFormat == GL_ALPHA)
+ fahrenheit = hw->eng3dm;
+ }
if (fahrenheit != nctx->eng3d) {
nctx->eng3d = fahrenheit;
--
1.7.0.2
From 8ca9fd5db720af498fcaf1365db19fbd2be57b57 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Mon, 6 Sep 2010 18:26:05 +0400
Subject: [PATCH 2/7] nv0x: add workaround for TNT2 and small sifm copies, shuts up errors but texenv demo still NOT fixed.
---
src/mesa/drivers/dri/nouveau/nv04_surface.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_surface.c b/src/mesa/drivers/dri/nouveau/nv04_surface.c
index e3febf7..48078f9 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_surface.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_surface.c
@@ -410,10 +410,19 @@ nv04_surface_copy(GLcontext *ctx,
nv04_surface_copy_m2mf(ctx, dst, src, dx, dy, sx, sy, w, h);
return;
}
+
+ /* TNT2 seems to be upset if we use sifm with small region,
+ add workaround */
+ int sifm_allowed = 0;
+ if (context_chipset(ctx) < 0x10) {
+ if (w > 8 && h > 8)
+ sifm_allowed = 1;
+ } else { sifm_allowed = 1; }
+
/* Swizzle
Re: [Mesa-dev] GL_NV_texture_env_combine4, Mesa and TNT2
В сообщении от Wednesday 08 September 2010 18:41:10 Francisco Jerez
написал(а):
> randrianas...@gmail.com writes:
> > Very hackish patch series for nv0x hardware, please take look and comment
> > on changes, blame me for errors etc.
> >
> > Francisco, might be nouveau list is better for this stuff?
>
> It's fine either way, do it as you prefer.
>
> > From 9bf16a26361ab4a44b6568deae30c523488cde1b Mon Sep 17 00:00:00 2001
> > From: Andrew Randrianasulu
> > Date: Mon, 6 Sep 2010 18:17:48 +0400
> > Subject: [PATCH 1/6] nv0x: use multitexturing engine for A8 textures,
> > fixes teapot demo broken probably since we started to use
> > _mesa_meta_Bitmap
>
> Can you please split your commit messages? It goes way over the 80
> column limit.
Will rebase with edited message.
>
> > ---
> > src/mesa/drivers/dri/nouveau/nv04_context.c |8
> > 1 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c
> > b/src/mesa/drivers/dri/nouveau/nv04_context.c index 6834f7c..af46ce2
> > 100644
> > --- a/src/mesa/drivers/dri/nouveau/nv04_context.c
> > +++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
> > @@ -38,6 +38,7 @@ nv04_context_engine(GLcontext *ctx)
> > struct nouveau_hw_state *hw = &to_nouveau_context(ctx)->hw;
> > struct nouveau_grobj *fahrenheit;
> >
> > +
>
> This is useless whitespace.
>
> > if (ctx->Texture.Unit[0].EnvMode == GL_COMBINE ||
> > ctx->Texture.Unit[0].EnvMode == GL_BLEND ||
> > ctx->Texture.Unit[0].EnvMode == GL_ADD ||
> > @@ -46,6 +47,13 @@ nv04_context_engine(GLcontext *ctx)
> > fahrenheit = hw->eng3dm;
> > else
> > fahrenheit = hw->eng3d;
> > +
>
> Same here.
OK
>
> > + if (ctx->Texture.Unit[0]._ReallyEnabled) {
> > + struct gl_texture_object *t = ctx->Texture.Unit[0]._Current;
> > + struct gl_texture_image *ti = t->Image[0][t->BaseLevel];
>
> Inconsistent indentation here.
>
> > + if (ti->_BaseFormat == GL_ALPHA)
> > + fahrenheit = hw->eng3dm;
>
> This is the right thing to do, but we need to check for GL_LUMINANCE
> too.
Already in slightly update patch series, patch 7, i'll rebase/redo whole
series based on your comments.
>
> > + }
> >
> > if (fahrenheit != nctx->eng3d) {
> > nctx->eng3d = fahrenheit;
> > --
> > 1.7.0.2
> >
> > From 8ca9fd5db720af498fcaf1365db19fbd2be57b57 Mon Sep 17 00:00:00 2001
> > From: Andrew Randrianasulu
> > Date: Mon, 6 Sep 2010 18:26:05 +0400
> > Subject: [PATCH 2/6] nv0x: add workaround for TNT2 and small sifm copies,
> > shuts up errors but texenv demo still NOT fixed.
> >
> > ---
> > src/mesa/drivers/dri/nouveau/nv04_surface.c | 11 ++-
> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/nouveau/nv04_surface.c
> > b/src/mesa/drivers/dri/nouveau/nv04_surface.c index e3febf7..48078f9
> > 100644
> > --- a/src/mesa/drivers/dri/nouveau/nv04_surface.c
> > +++ b/src/mesa/drivers/dri/nouveau/nv04_surface.c
> > @@ -410,10 +410,19 @@ nv04_surface_copy(GLcontext *ctx,
> > nv04_surface_copy_m2mf(ctx, dst, src, dx, dy, sx, sy, w, h);
> > return;
> > }
> > +
> > + /* TNT2 seems to be upset if we use sifm with small region,
> > +add workaround */
> > + int sifm_allowed = 0;
> > + if (context_chipset(ctx) < 0x10) {
> > + if (w > 8 && h > 8)
> > + sifm_allowed = 1;
> > + } else { sifm_allowed = 1; }
> > +
>
> It's probably not about size, but about alignment, and most likely we
> can keep using accelerated copies fixing the provided coordinates.
>
> > /* Swizzle using sifm+swzsurf. */
> > if (src->layout == LINEAR && dst->layout == SWIZZLED &&
> > - dst->cpp != 1 && !(dst->offset & 63)) {
> > + dst->cpp != 1 && !(dst->offset & 63) && (sifm_allowed == 1)) {
> > nv04_surface_copy_swizzle(ctx, dst, src, dx, dy, sx, sy, w, h);
> > return;
> > }
> > --
> > 1.7.0.2
> >
> >
> > From c183d547ec41466e902248c856c7291dfac33726 Mon Sep 17 00:00:00 2001
> > From: Andrew Randrianasulu
> > Date: Tue, 7 Sep 2010 19:00:31 +0400
> > Subject: [PATCH 3/6] nouveau: Trivially move GL_ARB_texture_env_dot3 and
> > GL_ARB_texture_env_combine from common extension list into nv10 and nv20
> > specific extension lists, so they will not show up on nv0x.
> >
> > ---
> > src/mesa/drivers/dri/nouveau/nouveau_context.c |2 --
> > src/mesa/drivers/dri/nouveau/nv10_context.c|2 ++
> > src/mesa/drivers/dri/nouveau/nv20_context.c|2 ++
> > 3 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c
> > b/src/mesa/drivers/dri/nouveau/nouveau_context.c index f481161..e9e7bbf
> > 100644
> > --- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
> > +++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
> > @@ -50,8 +50,6 @@
> > static const struct dri_extension nouveau_extensions[] = {
> > {
Re: [Mesa-dev] GL_NV_texture_env_combine4, Mesa and TNT2
sorry, i come to not directly unrelated question:
looking at commit "mesa: initial changes for GL_NV_texture_env_combine4"
http://lists.freedesktop.org/archives/mesa-commit/2009-January/006090.html
i see struct gl_tex_env_combine_state , with some arrays holding texenv
state/parameters.
in nv04_state_frag.c nv0x DRI driver pulls in info from this struct,
but not into arrays!
/* Initialize a combiner_state struct from the texture unit
* context. */
#define INIT_COMBINER(chan, ctx, rc, i) do {\
struct gl_tex_env_combine_state *c =\
ctx->Texture.Unit[i]._CurrentCombine; \
(rc)->ctx = ctx;\
(rc)->unit = i; \
(rc)->alpha = __INIT_COMBINER_ALPHA_##chan; \
(rc)->mode = c->Mode##chan; \
(rc)->source = c->Source##chan; \
(rc)->operand = c->Operand##chan; \
(rc)->logscale = c->ScaleShift##chan; \
(rc)->hw = 0; \
} while (0)
--
I fear doing it in this way will lead to losing state. I'm wrong ? I'm talking
about GL_NV_texture_env_combine4 case!
Sorry, Francisco, i really missed something very important here, excuse me for
moving this off IRC.
В сообщении от Wednesday 08 September 2010 23:25:17 Ian Romanick написал(а):
> Francisco Jerez wrote:
> > randrianas...@gmail.com writes:
> >> Very hackish patch series for nv0x hardware, please take look and
> >> comment on changes, blame me for errors etc.
> >>
> >> Francisco, might be nouveau list is better for this stuff?
> >
> > It's fine either way, do it as you prefer.
>
> Patches to core Mesa should go to mesa-dev for review.
>
> >> From 3accecebe12d34e74feae8149615c379bea54915 Mon Sep 17 00:00:00 2001
> >> From: Andrew Randrianasulu
> >> Date: Wed, 8 Sep 2010 15:27:24 +0400
> >> Subject: [PATCH 5/6] mesa: hack support for EXT_texture_env_combine in
> >> texenv.c, avoid gl errors if only this extension enabled in driver
> >>
> >> ---
> >> src/mesa/main/texenv.c |6 --
> >> 1 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/mesa/main/texenv.c b/src/mesa/main/texenv.c
> >> index 4442fb8..d8402da 100644
> >> --- a/src/mesa/main/texenv.c
> >> +++ b/src/mesa/main/texenv.c
> >> @@ -320,7 +320,8 @@ set_combiner_operand(GLcontext *ctx,
> >>alpha = GL_FALSE;
> >>break;
> >> case GL_OPERAND2_RGB:
> >> - if (ctx->Extensions.ARB_texture_env_combine) {
> >> + if (ctx->Extensions.ARB_texture_env_combine ||
> >> + ctx->Extensions.EXT_texture_env_combine) {
> >> term = 2;
> >> alpha = GL_FALSE;
> >>}
> >> @@ -348,7 +349,8 @@ set_combiner_operand(GLcontext *ctx,
> >>alpha = GL_TRUE;
> >>break;
> >> case GL_OPERAND2_ALPHA:
> >> - if (ctx->Extensions.ARB_texture_env_combine) {
> >> + if (ctx->Extensions.ARB_texture_env_combine ||
> >> + ctx->Extensions.EXT_texture_env_combine) {
> >> term = 2;
> >> alpha = GL_TRUE;
> >>}
> >> --
> >> 1.7.0.2
> >
> > That's incorrect, it makes mesa pass through illegal combinations like:
> >> glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_ONE_MINUS_SRC_COLOR);
>
> I have a pair patches that will fix this. I'm trying to track down an
> unrelated regression that occurred last night first.
>
> >> From 6e3cbb059b96032bd1a800b802e15f0c72e291fd Mon Sep 17 00:00:00 2001
> >> From: Andrew Randrianasulu
> >> Date: Wed, 8 Sep 2010 15:29:11 +0400
> >> Subject: [PATCH 6/6] nv0x: avoid assertion, just hack, we need properly
> >> enable multitexturing engine for advanced texenv modes and/or emulated
> >> textures, may be by dirtying context on texenv changes?
> >>
> >> ---
> >> src/mesa/drivers/dri/nouveau/nv04_state_raster.c | 10 --
> >> 1 files changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> >> b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c index
> >> c191571..a2544fb 100644
> >> --- a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> >> +++ b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> >> @@ -307,11 +307,17 @@ nv04_emit_blend(GLcontext *ctx, int emit)
> >>else
> >>blend |= NV04_TEXTURED_TRIANGLE_BLEND_SHADE_MODE_FLAT;
> >>
> >> +
> >> +
> >>/* Texture environment. */
> >> - if (ctx->Texture._EnabledUnits)
> >> + if (ctx->Texture._EnabledUnits) {
> >> + if ((ctx->Texture.Unit[0].EnvMode == GL_REPLACE) ||
> >> + ctx->Texture.Unit[0].EnvMode == GL_MODULATE ||
> >> + ctx->Texture.Unit[0].EnvMode == GL_DECAL) {
> >>blend |= get_texenv_mode(ctx->Texture.Unit[0].EnvMode);
> >>
Re: [Mesa-dev] NV04 texture_env_combine4.
В сообщении от Thursday 09 September 2010 07:18:26 Francisco Jerez написал(а):
> OK, here it is, it was easier to code than to explain :)
-
Thanks, here is my patch series, updated to current (commit
5ecd9c70cecc05eaa1fef05f9bd4e8cf50f2c03a) Mesa. Patch 0004 obviously collides
with yours. I'll really leave it up to you, as driver author.
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c b/src/mesa/drivers/dri/nouveau/nouveau_context.c
index f481161..a852042 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
@@ -58,8 +58,10 @@ static const struct dri_extension nouveau_extensions[] = {
{ "GL_EXT_framebuffer_object", GL_EXT_framebuffer_object_functions },
{ "GL_EXT_secondary_color", GL_EXT_secondary_color_functions },
{ "GL_EXT_stencil_wrap", NULL },
+ { "GL_EXT_texture_env_combine", NULL },
{ "GL_EXT_texture_lod_bias", NULL },
{ "GL_NV_blend_square", NULL },
+ { "GL_NV_texture_env_combine4", NULL },
{ "GL_SGIS_generate_mipmap", NULL },
{ NULL,NULL }
};
diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c b/src/mesa/drivers/dri/nouveau/nv04_context.c
index 6834f7c..1d34c86 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
@@ -39,6 +39,7 @@ nv04_context_engine(GLcontext *ctx)
struct nouveau_grobj *fahrenheit;
if (ctx->Texture.Unit[0].EnvMode == GL_COMBINE ||
+ ctx->Texture.Unit[0].EnvMode == GL_COMBINE4_NV ||
ctx->Texture.Unit[0].EnvMode == GL_BLEND ||
ctx->Texture.Unit[0].EnvMode == GL_ADD ||
ctx->Texture.Unit[1]._ReallyEnabled ||
diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_frag.c b/src/mesa/drivers/dri/nouveau/nv04_state_frag.c
index d7c86d4..bb5d7dc 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_state_frag.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_state_frag.c
@@ -44,6 +44,7 @@ struct combiner_state {
GLcontext *ctx;
int unit;
GLboolean alpha;
+ GLboolean premodulate;
/* GL state */
GLenum mode;
@@ -66,6 +67,7 @@ struct combiner_state {
(rc)->ctx = ctx;\
(rc)->unit = i; \
(rc)->alpha = __INIT_COMBINER_ALPHA_##chan; \
+ (rc)->premodulate = c->_NumArgs##chan == 4; \
(rc)->mode = c->Mode##chan; \
(rc)->source = c->Source##chan; \
(rc)->operand = c->Operand##chan; \
@@ -79,6 +81,9 @@ static uint32_t
get_input_source(struct combiner_state *rc, int source)
{
switch (source) {
+ case GL_ZERO:
+ return COMBINER_SOURCE(ZERO);
+
case GL_TEXTURE:
return rc->unit ? COMBINER_SOURCE(TEXTURE1) :
COMBINER_SOURCE(TEXTURE0);
@@ -195,11 +200,24 @@ setup_combiner(struct combiner_state *rc)
break;
case GL_ADD:
- INPUT_ARG(rc, 0, 0, 0);
- INPUT_SRC(rc, 1, ZERO, INVERT);
- INPUT_ARG(rc, 2, 1, 0);
- INPUT_SRC(rc, 3, ZERO, INVERT);
- UNSIGNED_OP(rc);
+ case GL_ADD_SIGNED:
+ if (rc->premodulate) {
+ INPUT_ARG(rc, 0, 0, 0);
+ INPUT_ARG(rc, 1, 1, 0);
+ INPUT_ARG(rc, 2, 2, 0);
+ INPUT_ARG(rc, 3, 3, 0);
+ } else {
+ INPUT_ARG(rc, 0, 0, 0);
+ INPUT_SRC(rc, 1, ZERO, INVERT);
+ INPUT_ARG(rc, 2, 1, 0);
+ INPUT_SRC(rc, 3, ZERO, INVERT);
+ }
+
+ if (rc->mode == GL_ADD_SIGNED)
+ SIGNED_OP(rc);
+ else
+ UNSIGNED_OP(rc);
+
break;
case GL_INTERPOLATE:
@@ -210,14 +228,6 @@ setup_combiner(struct combiner_state *rc)
UNSIGNED_OP(rc);
break;
- case GL_ADD_SIGNED:
- INPUT_ARG(rc, 0, 0, 0);
- INPUT_SRC(rc, 1, ZERO, INVERT);
- INPUT_ARG(rc, 2, 1, 0);
- INPUT_SRC(rc, 3, ZERO, INVERT);
- SIGNED_OP(rc);
- break;
-
default:
assert(0);
}
From 92c19bdd1101da592fc4c8346c01333aaad8d16d Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Thu, 9 Sep 2010 07:22:32 +0400
Subject: [PATCH 1/4] nv0x: Add workaround for small sifm transfers, eliminating some noise from
dmesg during texenv run
---
src/mesa/drivers/dri/nouveau/nv04_surface.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_surface.c b/src/mesa/drivers/dri/nouveau/nv04_surface.c
index e3febf7..48078f9 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_surface.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_surface.c
@@ -410,10 +410,19 @@ nv04_surface_copy(GLcontext *ctx,
nv04_surface_copy_m2mf(ctx, dst, src, dx, dy, sx, sy, w, h);
return;
}
+
+ /* TNT2 seems to be upset if we use sifm with small region,
+ add workaround */
+ int sifm_allowed = 0;
+ if (context_chipset(ctx) < 0x10) {
+ if (w > 8 && h > 8)
+ sifm_allowed = 1;
+ } else { sifm_allowed = 1; }
+
/* Swizzle using sifm+swzsurf. */
if (src->layout == LINEAR && dst->layout == SWIZZLED &&
- dst->cpp != 1 && !(dst->offset & 63)) {
+ dst->cpp != 1 && !(dst->offset & 63) && (sifm_allowed == 1)) {
nv04_surface_copy_swizzle(ctx, dst, src, dx, dy, sx, sy, w, h);
return;
}
--
1.7.0.2
From 0751c686413690a2673486234bf9cb7d7956b8a5 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Thu, 9 Sep 2010 07:29:18 +0400
