[Mesa-dev] [Bug 29262] New: Compilation error git Mesa 7.9-devel
https://bugs.freedesktop.org/show_bug.cgi?id=29262 Summary: Compilation error git Mesa 7.9-devel Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: wol...@onsneteindhoven.nl Compilation of the latest git Mesa shows the following errors: make - In file included from main/api_exec.c:117:0: ../../src/mesa/main/remap_helper.h:4493:13: error: ‘DrawArraysInstanced_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4494:13: error: ‘DrawElementsInstanced_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4627:13: error: ‘FramebufferTextureARB_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4628:13: error: ‘FramebufferTextureFaceARB_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4629:13: error: ‘ProgramParameteriARB_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4645:13: error: ‘BindTransformFeedback_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4646:13: error: ‘DeleteTransformFeedbacks_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4647:13: error: ‘DrawTransformFeedback_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4648:13: error: ‘GenTransformFeedbacks_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4649:13: error: ‘IsTransformFeedback_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4650:13: error: ‘PauseTransformFeedback_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4651:13: error: ‘ResumeTransformFeedback_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4870:13: error: ‘BeginTransformFeedbackEXT_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4871:13: error: ‘BindBufferBaseEXT_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4872:13: error: ‘BindBufferOffsetEXT_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4873:13: error: ‘BindBufferRangeEXT_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4874:13: error: ‘EndTransformFeedbackEXT_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4875:13: error: ‘GetTransformFeedbackVaryingEXT_remap_index’ undeclared here (not in a function) ../../src/mesa/main/remap_helper.h:4876:13: error: ‘TransformFeedbackVaryingsEXT_remap_index’ undeclared here (not in a function) main/api_exec.c: In function ‘_mesa_create_exec_table’: main/api_exec.c:737:4: warning: implicit declaration of function ‘SET_FramebufferTextureARB’ main/api_exec.c:738:4: warning: implicit declaration of function ‘SET_FramebufferTextureFaceARB’ make[2]: *** [main/api_exec.o] Error 1 make[2]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src' make: *** [default] Error 1 - -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29229] Regression: glXChooseVisual segfaults when using swrast.
https://bugs.freedesktop.org/show_bug.cgi?id=29229 Nick Bowler changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Nick Bowler 2010-07-26 07:32:12 PDT --- Looks like this was fixed over the weekend... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29170] [regression] Far Cry (in Wine) hangs on level load
https://bugs.freedesktop.org/show_bug.cgi?id=29170 --- Comment #4 from Nick Bowler 2010-07-26 07:33:18 PDT --- Can you try again with latest git? I think this might be fixed now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29170] [regression] Far Cry (in Wine) hangs on level load
https://bugs.freedesktop.org/show_bug.cgi?id=29170 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Sven Arvidsson 2010-07-26 07:39:52 PDT --- Yes, seems to work fine now, thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29264] New: latest mesa causes screen to not be redrawn
https://bugs.freedesktop.org/show_bug.cgi?id=29264 Summary: latest mesa causes screen to not be redrawn Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: GLX AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: chainsawb...@gmail.com i git bisected to this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7a66e549583a3168f05acc7df1e872d218fd670d im running compiz and gentoo x11 overlay ( mesa, ati driver, libdrm and drm-radeon-testing kernel from git) radeon r600 driver the screen only seems to be redrawn by triggering certan efects ie water effect and expo will cause it to redraw - as soon as the effects finish it stops redrawing the mouse always shows correctly -- 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] Gallium depth clamp support
On 07/23/2010 03:27 PM, Roland Scheidegger wrote: On 22.07.2010 01:27, Brian Paul wrote: On 07/21/2010 05:19 PM, Marek Olšák wrote: On Thu, Jul 22, 2010 at 12:17 AM, Roland Scheideggermailto:srol...@vmware.com>> wrote: Marek Olšák wrote: Hi, there is a new branch gallium-depth-clamp in the main repository which implements ARB_depth_clamp in Gallium. Wine uses this extension to disable clipping when it's requested from a D3D9 app, so it's an important one. There is a new state "depth_clamp" in pipe_clip_state, and a new cap PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in Gallium instead, it's ok with me. There are several reasons I put the enable bit in pipe_clip_state, but the most important one is that Z clipping must be disabled in hardware first for it to work. It also implements depth_clamp handling in cso_cache and wires up ARB_depth_clamp in st/mesa. The support in Draw has also been implemented, and both softpipe and llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp One thing I was wondering does it actually make sense to call it depth clamp? I think d3d10 name for once (which calls this functionality depth clip though of course this means enable/disable is reversed) makes more sense - this disables near/far plane clipping, hence the necessity to clamp to 0/1. I guess having this in clip state is ok - d3d10 puts depth clip into rasterizer state, but then again d3d10 doesn't have any clip state... Depth clip does sound better to me, but honestly I don't care how we call it. If you like the D3D naming, so be it. There's two aspects to the GL extension: - near/far Z clipping - fragment Z clamping during interpolation I think pipe_clip_state::depth_clamp should become pipe_clip_state::depth_clip. Then, I'd probably add the second part of this as pipe_rasterizer_state::depth_clamp to enable/disable fragment Z clamping. GL would set both pieces of state in tandem. I think we should have two pieces of state to avoid interdependencies between clip state and rasterization state in the drivers. I'm not sure how this is expressed in Direct3D. d3d10 always clamps z to viewport min/max depth, regardless if depth clipping is enabled or not (hmm does it really make a difference when depth clipping is enabled? Maybe only for OGL rasterpos and similar legacy stuff?). I was also thinking of floating point Z buffers which don't necessarily clamp Z to [0,1]. You might want to disable Z clipping as well as fragment Z clamping. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29264] latest mesa causes screen to not be redrawn
https://bugs.freedesktop.org/show_bug.cgi?id=29264 Kristian Høgsberg changed: What|Removed |Added CC||k...@bitplanet.net --- Comment #1 from Kristian Høgsberg 2010-07-26 12:53:24 PDT --- Should be fixed in git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves
On Sun, 25 Jul 2010 21:30:19 -0700, Benjamin Segovia wrote: > - Several routines directly analyze the grf-to-mrf moves from the Gen binary > code. When it is possible, the mov is removed and the message register is > directly written in the arithmetic instruction > > - Also redundant mrf-to-grf moves are removed (frequently for example, when > sampling many textures with the same uv) > > - Code was tested with piglit, warsow and nexuiz on an Ironlake machine. No > regression was found there > > - Note that the optimizations are *deactivated* on Gen4 and Gen6 since I did > test them properly yet. No reason there are bugs but who knows > > - The optimizations are currently done in branch free programs *only*. > Considering branches is more complicated and there are actually two paths: > one for branch free programs and one for programs with branches Yeah, the remove-repeated-mov pass at least seems like it could be changed to a basic-block pass successfully. Less so for the other one. > > - Also some other optimizations should be done during the emission itself but > considering that some code is shader between vertex shaders (AOS) and pixel > shaders (SOA) and that we may have branches or not, it is pretty hard to > both > factorize the code and have one good set of strategies Looks pretty good, and the generated programs sure look a lot better. I've gone ahead and pushed it plus a few cleanups of the code. pgp7WJOuTPr7b.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29235] OpenGL applications segfault in glxMakeCurrent with git mesa
https://bugs.freedesktop.org/show_bug.cgi?id=29235 Giacomo Perale changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Giacomo Perale 2010-07-26 13:45:08 PDT --- fixed in git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves
Thanks for the cleanup. I rushed the code yesterday and it was not quite perfect. From: Eric Anholt [e...@anholt.net] Sent: Monday, July 26, 2010 2:12 PM To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves On Sun, 25 Jul 2010 21:30:19 -0700, Benjamin Segovia wrote: > - Several routines directly analyze the grf-to-mrf moves from the Gen binary > code. When it is possible, the mov is removed and the message register is > directly written in the arithmetic instruction > > - Also redundant mrf-to-grf moves are removed (frequently for example, when > sampling many textures with the same uv) > > - Code was tested with piglit, warsow and nexuiz on an Ironlake machine. No > regression was found there > > - Note that the optimizations are *deactivated* on Gen4 and Gen6 since I did > test them properly yet. No reason there are bugs but who knows > > - The optimizations are currently done in branch free programs *only*. > Considering branches is more complicated and there are actually two paths: > one for branch free programs and one for programs with branches Yeah, the remove-repeated-mov pass at least seems like it could be changed to a basic-block pass successfully. Less so for the other one. > > - Also some other optimizations should be done during the emission itself but > considering that some code is shader between vertex shaders (AOS) and pixel > shaders (SOA) and that we may have branches or not, it is pretty hard to > both > factorize the code and have one good set of strategies Looks pretty good, and the generated programs sure look a lot better. I've gone ahead and pushed it plus a few cleanups of the code. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves
On Sun, 25 Jul 2010 21:31:29 -0700, "Segovia, Benjamin" wrote: > Also, is there any way to completely deactivate all forms of > synchronization for the display? There are some posts related to > that. I would like to swap the frame buffers with no wait (if it is > possible). Otherwise, it is still hard to monitor the performance > changes. vblank_mode=0 in the environment (can also be set globally with driconf) Also, if you haven't found it yet, intel_gpu_top from intel-gpu-tools can be useful in seeing what pipeline stages are busy. pgp93CNNZz37H.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] i965: merging the two compilation paths for fragment programs?
Hello all, i965 has today an issue with fp compilation. There are two passes: one for branch-free programs and one for the others. For "branch porograms", the code is generated by a _direct_ translation of the mesa gpu program. Even if with some optimizations in prog_optimize.c and the new upcoming compiler, it sounds clearly not enough. In particular, the mrf-to-grf move removes do not work and the better mov analysis (pass0, pass1, pass2 in i965 backend) done on the scalar code is not done at all if you have one branch. What we need to unify all this is at least a control flow graph (cfg). The question is where to build it. glsl2 will have its own representation. Unfortunately, I imagine we can not use it in a short term for the back-ends since it means, breaking everything. So, maybe a simple strategy will be to have a cfg for each mesa program, cfg that can be built by the front end or by the back end if the front end did not provide it. Also, glsl2 could provide a cfg builder of its own from its own inner reprensation to the Mesa one (?) So, what I plan to do right now as a proof of concept is to build a generic cfg (on _Mesa_ code not on Gen code) in the i965 back end and unify the i965 shader compilers using it. Then, if other back ends may use it, it could be fine to move it in the front end. What do you think about that? Cheers, Ben ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves
vblank_mode=0. Are you sure? The performance become a disaster with it (i just tried). I am looking at intel_gpu_top from intel-gpu-tools. They sound great :) From: Eric Anholt [e...@anholt.net] Sent: Monday, July 26, 2010 5:43 PM To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves On Sun, 25 Jul 2010 21:31:29 -0700, "Segovia, Benjamin" wrote: > Also, is there any way to completely deactivate all forms of > synchronization for the display? There are some posts related to > that. I would like to swap the frame buffers with no wait (if it is > possible). Otherwise, it is still hard to monitor the performance > changes. vblank_mode=0 in the environment (can also be set globally with driconf) Also, if you haven't found it yet, intel_gpu_top from intel-gpu-tools can be useful in seeing what pipeline stages are busy. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front end
On Mon, 19 Jul 2010 16:01:02 -0700, Benjamin Segovia
wrote:
> - Improved optimization of GPU programs. Now, swizzling is taken into account
> and swizzles are properly transformed while removing mov instructions.
> Removals of mov instructions are now much more effective
>
> - Analysis of control flows is still very primitive and far more too
> conservative. Shaders using a lot of branches will be less optimized than
> straightforward ones
>
> - Main things to do next is:
>* instruction merging like for example merging:
>mul a.x b.x c.x
>mul a.y b.y c.y
>mul a.z b.z c.z
> into
>mul a.xyz b.xyz c.xyz
>* register renaming to avoid some still unecessary movs
>
> - Tested with piglit. I run all the shaders and compare output from the new
> version with the old one. Also, run openarena, nexuiz and warsow. All games
> perfectly run and GPU code is clearly improved. Note that I only use my
> Intel
> Gen GPU for the backend. So everything was tested using classic Mesa with
> the Intel i965 driver.
Added two new testcases to piglit, glsl-fs-add-masked and
glsl-fs-mov-masked, to catch bugs in this that I found while reviewing
the code after my GLSL demo started failing. Patch included for
glsl-fs-add-masked (MOV dst.xz, src uses the X and Z channels of src,
not X and Y), feel free to squash it into a fixed patch.
glsl-vs-arrays, glsl-vs-arrays-2, and glsl-vs-mov-after-deref also
started failing for me as well after applying your change. Lots of
important code seems to have been optimized out. I'm guessing RelAddr
handling is broken. Everywhere else that bit_count is used looks bogus
to me, but I haven't constructed tests for them yet.
I'm not a fan of bit_clear[], bit_scan[], or expand_one[] either. They
obfuscate the code to me.
From 9c7fb7b5b6f299b19d27245f2b68853521499afa Mon Sep 17 00:00:00 2001
From: Eric Anholt
Date: Mon, 26 Jul 2010 16:20:11 -0700
Subject: [PATCH] mesa: Fix bug in handling of read channel masks
get_src_arg_mask.
Fixes piglit glsl-fs-add-masked, and my GLSL demo.
---
src/mesa/program/prog_optimize.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index 9119b10..c853330 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -51,12 +51,11 @@ static const int expand_one[5] = {0,1,3,7,15};
static GLuint
get_src_arg_mask(const struct prog_instruction *inst, int arg, int dst_mask)
{
- int read_mask, channel_mask, read_count;
+ int read_mask, channel_mask;
int comp;
/* Form the dst register, find the written channels */
if (inst->CondUpdate) {
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
}
else {
@@ -67,8 +66,7 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
case OPCODE_MAD:
case OPCODE_MUL:
case OPCODE_SUB:
- read_count = bit_count[inst->DstReg.WriteMask & dst_mask];
- channel_mask = expand_one[read_count];
+ channel_mask = inst->DstReg.WriteMask & dst_mask;
break;
case OPCODE_RCP:
case OPCODE_SIN:
@@ -76,20 +74,16 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
case OPCODE_RSQ:
case OPCODE_POW:
case OPCODE_EX2:
- read_count = 1;
channel_mask = WRITEMASK_X;
break;
case OPCODE_DP2:
- read_count = 2;
channel_mask = WRITEMASK_XY;
break;
case OPCODE_DP3:
case OPCODE_XPD:
- read_count = 3;
channel_mask = WRITEMASK_XYZ;
break;
default:
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
break;
}
@@ -99,9 +93,9 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
* components are actually read
*/
read_mask = 0;
- for (comp = 0; comp < read_count; ++comp) {
+ for (comp = 0; comp < 4; ++comp) {
const int coord = GET_SWZ(inst->SrcReg[arg].Swizzle, comp);
- if (coord <= SWIZZLE_W)
+ if (channel_mask & (1 << comp) && coord <= SWIZZLE_W)
read_mask |= 1 << coord;
}
--
1.7.1
pgphhb7RALLpA.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front end
- Hmm, first bug is clearly something I misunderstood. You say:
in "mov dst.xz src" src will use .xz and not .xy? But the swizzle is still.
xyzw or do I miss a point?
- I am not sure but the other test were skipped I think with my version of
piglit + mesa. I have to check that again.
- For bit_scan, bit_cound, what would you prefer?
Cheers,
Ben
From: Eric Anholt [e...@anholt.net]
Sent: Monday, July 26, 2010 6:03 PM
To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front
end
On Mon, 19 Jul 2010 16:01:02 -0700, Benjamin Segovia
wrote:
> - Improved optimization of GPU programs. Now, swizzling is taken into account
> and swizzles are properly transformed while removing mov instructions.
> Removals of mov instructions are now much more effective
>
> - Analysis of control flows is still very primitive and far more too
> conservative. Shaders using a lot of branches will be less optimized than
> straightforward ones
>
> - Main things to do next is:
>* instruction merging like for example merging:
>mul a.x b.x c.x
>mul a.y b.y c.y
>mul a.z b.z c.z
> into
>mul a.xyz b.xyz c.xyz
>* register renaming to avoid some still unecessary movs
>
> - Tested with piglit. I run all the shaders and compare output from the new
> version with the old one. Also, run openarena, nexuiz and warsow. All games
> perfectly run and GPU code is clearly improved. Note that I only use my
> Intel
> Gen GPU for the backend. So everything was tested using classic Mesa with
> the Intel i965 driver.
Added two new testcases to piglit, glsl-fs-add-masked and
glsl-fs-mov-masked, to catch bugs in this that I found while reviewing
the code after my GLSL demo started failing. Patch included for
glsl-fs-add-masked (MOV dst.xz, src uses the X and Z channels of src,
not X and Y), feel free to squash it into a fixed patch.
glsl-vs-arrays, glsl-vs-arrays-2, and glsl-vs-mov-after-deref also
started failing for me as well after applying your change. Lots of
important code seems to have been optimized out. I'm guessing RelAddr
handling is broken. Everywhere else that bit_count is used looks bogus
to me, but I haven't constructed tests for them yet.
I'm not a fan of bit_clear[], bit_scan[], or expand_one[] either. They
obfuscate the code to me.
>From 9c7fb7b5b6f299b19d27245f2b68853521499afa Mon Sep 17 00:00:00 2001
From: Eric Anholt
Date: Mon, 26 Jul 2010 16:20:11 -0700
Subject: [PATCH] mesa: Fix bug in handling of read channel masks
get_src_arg_mask.
Fixes piglit glsl-fs-add-masked, and my GLSL demo.
---
src/mesa/program/prog_optimize.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index 9119b10..c853330 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -51,12 +51,11 @@ static const int expand_one[5] = {0,1,3,7,15};
static GLuint
get_src_arg_mask(const struct prog_instruction *inst, int arg, int dst_mask)
{
- int read_mask, channel_mask, read_count;
+ int read_mask, channel_mask;
int comp;
/* Form the dst register, find the written channels */
if (inst->CondUpdate) {
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
}
else {
@@ -67,8 +66,7 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
case OPCODE_MAD:
case OPCODE_MUL:
case OPCODE_SUB:
- read_count = bit_count[inst->DstReg.WriteMask & dst_mask];
- channel_mask = expand_one[read_count];
+ channel_mask = inst->DstReg.WriteMask & dst_mask;
break;
case OPCODE_RCP:
case OPCODE_SIN:
@@ -76,20 +74,16 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
case OPCODE_RSQ:
case OPCODE_POW:
case OPCODE_EX2:
- read_count = 1;
channel_mask = WRITEMASK_X;
break;
case OPCODE_DP2:
- read_count = 2;
channel_mask = WRITEMASK_XY;
break;
case OPCODE_DP3:
case OPCODE_XPD:
- read_count = 3;
channel_mask = WRITEMASK_XYZ;
break;
default:
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
break;
}
@@ -99,9 +93,9 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
* components are actually read
*/
read_mask = 0;
- for (comp = 0; comp < read_count; ++comp) {
+ for (comp = 0; comp < 4; ++comp) {
const int coord = GET_SWZ(inst->SrcReg[arg].Swizzle, comp);
- if (coord <= SWIZZLE_W)
+ if (channel_mask & (1 << comp) && coord <= SWIZZLE_W)
read_mask |= 1 << coord;
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.free
Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front end
So basically,
"mov dst.xz src.yw" is impossible with mesa code?
Ben
From: mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org
[mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org] On Behalf
Of Segovia, Benjamin [benjamin.sego...@intel.com]
Sent: Monday, July 26, 2010 6:13 PM
To: Eric Anholt; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front
end
- Hmm, first bug is clearly something I misunderstood. You say:
in "mov dst.xz src" src will use .xz and not .xy? But the swizzle is still.
xyzw or do I miss a point?
- I am not sure but the other test were skipped I think with my version of
piglit + mesa. I have to check that again.
- For bit_scan, bit_cound, what would you prefer?
Cheers,
Ben
From: Eric Anholt [e...@anholt.net]
Sent: Monday, July 26, 2010 6:03 PM
To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front
end
On Mon, 19 Jul 2010 16:01:02 -0700, Benjamin Segovia
wrote:
> - Improved optimization of GPU programs. Now, swizzling is taken into account
> and swizzles are properly transformed while removing mov instructions.
> Removals of mov instructions are now much more effective
>
> - Analysis of control flows is still very primitive and far more too
> conservative. Shaders using a lot of branches will be less optimized than
> straightforward ones
>
> - Main things to do next is:
>* instruction merging like for example merging:
>mul a.x b.x c.x
>mul a.y b.y c.y
>mul a.z b.z c.z
> into
>mul a.xyz b.xyz c.xyz
>* register renaming to avoid some still unecessary movs
>
> - Tested with piglit. I run all the shaders and compare output from the new
> version with the old one. Also, run openarena, nexuiz and warsow. All games
> perfectly run and GPU code is clearly improved. Note that I only use my
> Intel
> Gen GPU for the backend. So everything was tested using classic Mesa with
> the Intel i965 driver.
Added two new testcases to piglit, glsl-fs-add-masked and
glsl-fs-mov-masked, to catch bugs in this that I found while reviewing
the code after my GLSL demo started failing. Patch included for
glsl-fs-add-masked (MOV dst.xz, src uses the X and Z channels of src,
not X and Y), feel free to squash it into a fixed patch.
glsl-vs-arrays, glsl-vs-arrays-2, and glsl-vs-mov-after-deref also
started failing for me as well after applying your change. Lots of
important code seems to have been optimized out. I'm guessing RelAddr
handling is broken. Everywhere else that bit_count is used looks bogus
to me, but I haven't constructed tests for them yet.
I'm not a fan of bit_clear[], bit_scan[], or expand_one[] either. They
obfuscate the code to me.
>From 9c7fb7b5b6f299b19d27245f2b68853521499afa Mon Sep 17 00:00:00 2001
From: Eric Anholt
Date: Mon, 26 Jul 2010 16:20:11 -0700
Subject: [PATCH] mesa: Fix bug in handling of read channel masks
get_src_arg_mask.
Fixes piglit glsl-fs-add-masked, and my GLSL demo.
---
src/mesa/program/prog_optimize.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index 9119b10..c853330 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -51,12 +51,11 @@ static const int expand_one[5] = {0,1,3,7,15};
static GLuint
get_src_arg_mask(const struct prog_instruction *inst, int arg, int dst_mask)
{
- int read_mask, channel_mask, read_count;
+ int read_mask, channel_mask;
int comp;
/* Form the dst register, find the written channels */
if (inst->CondUpdate) {
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
}
else {
@@ -67,8 +66,7 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
case OPCODE_MAD:
case OPCODE_MUL:
case OPCODE_SUB:
- read_count = bit_count[inst->DstReg.WriteMask & dst_mask];
- channel_mask = expand_one[read_count];
+ channel_mask = inst->DstReg.WriteMask & dst_mask;
break;
case OPCODE_RCP:
case OPCODE_SIN:
@@ -76,20 +74,16 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mask)
case OPCODE_RSQ:
case OPCODE_POW:
case OPCODE_EX2:
- read_count = 1;
channel_mask = WRITEMASK_X;
break;
case OPCODE_DP2:
- read_count = 2;
channel_mask = WRITEMASK_XY;
break;
case OPCODE_DP3:
case OPCODE_XPD:
- read_count = 3;
channel_mask = WRITEMASK_XYZ;
break;
default:
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
break;
}
@@ -99,9 +93,9 @@ get_src_arg_mask(const struct prog_instruction *inst, int
arg, int dst_mas
Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front end
mov dst.xz src.yyww
The second and y and w can be anything.
Cheers Jakob.
On 26 jul 2010, at 17.14, Segovia, Benjamin wrote:
So basically,
"mov dst.xz src.yw" is impossible with mesa code?
Ben
From: mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org
[mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org]
On Behalf Of Segovia, Benjamin [benjamin.sego...@intel.com]
Sent: Monday, July 26, 2010 6:13 PM
To: Eric Anholt; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in
Mesa front end
- Hmm, first bug is clearly something I misunderstood. You say:
in "mov dst.xz src" src will use .xz and not .xy? But the swizzle is
still. xyzw or do I miss a point?
- I am not sure but the other test were skipped I think with my
version of piglit + mesa. I have to check that again.
- For bit_scan, bit_cound, what would you prefer?
Cheers,
Ben
From: Eric Anholt [e...@anholt.net]
Sent: Monday, July 26, 2010 6:03 PM
To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in
Mesa front end
On Mon, 19 Jul 2010 16:01:02 -0700, Benjamin Segovia > wrote:
- Improved optimization of GPU programs. Now, swizzling is taken
into account
and swizzles are properly transformed while removing mov
instructions.
Removals of mov instructions are now much more effective
- Analysis of control flows is still very primitive and far more too
conservative. Shaders using a lot of branches will be less
optimized than
straightforward ones
- Main things to do next is:
* instruction merging like for example merging:
mul a.x b.x c.x
mul a.y b.y c.y
mul a.z b.z c.z
into
mul a.xyz b.xyz c.xyz
* register renaming to avoid some still unecessary movs
- Tested with piglit. I run all the shaders and compare output from
the new
version with the old one. Also, run openarena, nexuiz and warsow.
All games
perfectly run and GPU code is clearly improved. Note that I only
use my Intel
Gen GPU for the backend. So everything was tested using classic
Mesa with
the Intel i965 driver.
Added two new testcases to piglit, glsl-fs-add-masked and
glsl-fs-mov-masked, to catch bugs in this that I found while reviewing
the code after my GLSL demo started failing. Patch included for
glsl-fs-add-masked (MOV dst.xz, src uses the X and Z channels of src,
not X and Y), feel free to squash it into a fixed patch.
glsl-vs-arrays, glsl-vs-arrays-2, and glsl-vs-mov-after-deref also
started failing for me as well after applying your change. Lots of
important code seems to have been optimized out. I'm guessing RelAddr
handling is broken. Everywhere else that bit_count is used looks
bogus
to me, but I haven't constructed tests for them yet.
I'm not a fan of bit_clear[], bit_scan[], or expand_one[] either.
They
obfuscate the code to me.
From 9c7fb7b5b6f299b19d27245f2b68853521499afa Mon Sep 17 00:00:00 2001
From: Eric Anholt
Date: Mon, 26 Jul 2010 16:20:11 -0700
Subject: [PATCH] mesa: Fix bug in handling of read channel masks
get_src_arg_mask.
Fixes piglit glsl-fs-add-masked, and my GLSL demo.
---
src/mesa/program/prog_optimize.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/
prog_optimize.c
index 9119b10..c853330 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -51,12 +51,11 @@ static const int expand_one[5] = {0,1,3,7,15};
static GLuint
get_src_arg_mask(const struct prog_instruction *inst, int arg, int
dst_mask)
{
- int read_mask, channel_mask, read_count;
+ int read_mask, channel_mask;
int comp;
/* Form the dst register, find the written channels */
if (inst->CondUpdate) {
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
}
else {
@@ -67,8 +66,7 @@ get_src_arg_mask(const struct prog_instruction
*inst, int arg, int dst_mask)
case OPCODE_MAD:
case OPCODE_MUL:
case OPCODE_SUB:
- read_count = bit_count[inst->DstReg.WriteMask & dst_mask];
- channel_mask = expand_one[read_count];
+ channel_mask = inst->DstReg.WriteMask & dst_mask;
break;
case OPCODE_RCP:
case OPCODE_SIN:
@@ -76,20 +74,16 @@ get_src_arg_mask(const struct prog_instruction
*inst, int arg, int dst_mask)
case OPCODE_RSQ:
case OPCODE_POW:
case OPCODE_EX2:
- read_count = 1;
channel_mask = WRITEMASK_X;
break;
case OPCODE_DP2:
- read_count = 2;
channel_mask = WRITEMASK_XY;
break;
case OPCODE_DP3:
case OPCODE_XPD:
- read_count = 3;
channel_mask = WRITEMASK_XYZ;
break;
default:
- read_count = 4;
channel_mask = WRITEMASK_XYZW;
break;
}
@@ -99,9
Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front end
Wouarf. This is a pretty big mistake :) Crazy it passes the tests.
I am submitting a new patch. Just looking at the indirection stuff for vertex
arrays.
Thanks
Ben
From: Jakob Bornecrantz [ja...@vmware.com]
Sent: Monday, July 26, 2010 6:19 PM
To: Segovia, Benjamin
Cc: Eric Anholt; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in Mesa front
end
mov dst.xz src.yyww
The second and y and w can be anything.
Cheers Jakob.
On 26 jul 2010, at 17.14, Segovia, Benjamin wrote:
> So basically,
>
> "mov dst.xz src.yw" is impossible with mesa code?
>
> Ben
>
>
> From: mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org
> [mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org]
> On Behalf Of Segovia, Benjamin [benjamin.sego...@intel.com]
> Sent: Monday, July 26, 2010 6:13 PM
> To: Eric Anholt; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in
> Mesa front end
>
> - Hmm, first bug is clearly something I misunderstood. You say:
>
> in "mov dst.xz src" src will use .xz and not .xy? But the swizzle is
> still. xyzw or do I miss a point?
>
> - I am not sure but the other test were skipped I think with my
> version of piglit + mesa. I have to check that again.
>
> - For bit_scan, bit_cound, what would you prefer?
>
> Cheers,
> Ben
>
>
> From: Eric Anholt [e...@anholt.net]
> Sent: Monday, July 26, 2010 6:03 PM
> To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] Better GPU program optimization in
> Mesa front end
>
> On Mon, 19 Jul 2010 16:01:02 -0700, Benjamin Segovia
> > wrote:
>> - Improved optimization of GPU programs. Now, swizzling is taken
>> into account
>> and swizzles are properly transformed while removing mov
>> instructions.
>> Removals of mov instructions are now much more effective
>>
>> - Analysis of control flows is still very primitive and far more too
>> conservative. Shaders using a lot of branches will be less
>> optimized than
>> straightforward ones
>>
>> - Main things to do next is:
>> * instruction merging like for example merging:
>> mul a.x b.x c.x
>> mul a.y b.y c.y
>> mul a.z b.z c.z
>> into
>> mul a.xyz b.xyz c.xyz
>> * register renaming to avoid some still unecessary movs
>>
>> - Tested with piglit. I run all the shaders and compare output from
>> the new
>> version with the old one. Also, run openarena, nexuiz and warsow.
>> All games
>> perfectly run and GPU code is clearly improved. Note that I only
>> use my Intel
>> Gen GPU for the backend. So everything was tested using classic
>> Mesa with
>> the Intel i965 driver.
>
> Added two new testcases to piglit, glsl-fs-add-masked and
> glsl-fs-mov-masked, to catch bugs in this that I found while reviewing
> the code after my GLSL demo started failing. Patch included for
> glsl-fs-add-masked (MOV dst.xz, src uses the X and Z channels of src,
> not X and Y), feel free to squash it into a fixed patch.
>
> glsl-vs-arrays, glsl-vs-arrays-2, and glsl-vs-mov-after-deref also
> started failing for me as well after applying your change. Lots of
> important code seems to have been optimized out. I'm guessing RelAddr
> handling is broken. Everywhere else that bit_count is used looks
> bogus
> to me, but I haven't constructed tests for them yet.
>
> I'm not a fan of bit_clear[], bit_scan[], or expand_one[] either.
> They
> obfuscate the code to me.
>
> From 9c7fb7b5b6f299b19d27245f2b68853521499afa Mon Sep 17 00:00:00 2001
> From: Eric Anholt
> Date: Mon, 26 Jul 2010 16:20:11 -0700
> Subject: [PATCH] mesa: Fix bug in handling of read channel masks
> get_src_arg_mask.
>
> Fixes piglit glsl-fs-add-masked, and my GLSL demo.
> ---
> src/mesa/program/prog_optimize.c | 14 --
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/
> prog_optimize.c
> index 9119b10..c853330 100644
> --- a/src/mesa/program/prog_optimize.c
> +++ b/src/mesa/program/prog_optimize.c
> @@ -51,12 +51,11 @@ static const int expand_one[5] = {0,1,3,7,15};
> static GLuint
> get_src_arg_mask(const struct prog_instruction *inst, int arg, int
> dst_mask)
> {
> - int read_mask, channel_mask, read_count;
> + int read_mask, channel_mask;
>int comp;
>
>/* Form the dst register, find the written channels */
>if (inst->CondUpdate) {
> - read_count = 4;
> channel_mask = WRITEMASK_XYZW;
>}
>else {
> @@ -67,8 +66,7 @@ get_src_arg_mask(const struct prog_instruction
> *inst, int arg, int dst_mask)
> case OPCODE_MAD:
> case OPCODE_MUL:
> case OPCODE_SUB:
> - read_count = bit_count[inst->DstReg.WriteMask & dst_mask];
> - channel_mask = expand_one[read_count];
> + channel_mask = inst->DstReg.WriteMask & dst_mask;
>
Re: [Mesa-dev] opencl (clover) patches question
I was just playing around with it, I'll keep my eye on the gallium resources branch to see how things materialize On Fri, Jul 23, 2010 at 10:39 AM, Zack Rusin wrote: > On Thursday 22 July 2010 20:33:59 Anthony Waters wrote: >> sounds good, >> >> the patches in >> http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg10561.html >> don't produce any conflicts with the commit from 3/28, they applied >> cleanly into my working copy with a 3 way merge through git am -3 >> >> not sure if this is a concern or not, but after the 3 way merge the >> commit log is not in chronological order anymore > > That doesn't really matter. Just so that I know do you actually have a plan or > are you just playing around? I'm asking because the reason the Clover > repository is waiting is because the entire codebase will depend on the > infrastructure for GPGPU in Gallium, Clang integration and LLVM code-gen code. > In the gallium resources branch I've the first crucial part of the changes in > Gallium which is support for buffer reads and gather instructions. Then we'll > need to implement scatter and memory spaces. > TBH anything short of that Gallium/Clang/LLVM infrastructure work is at this > point not very useful because it will just be rewritten later. Actually from > the simpler stuff maybe cleaning up the build system or changing the testing > framework to QtTest would be useful for later. I wouldn't spend any time on > anything but that at this point. > > z > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29264] latest mesa causes screen to not be redrawn
https://bugs.freedesktop.org/show_bug.cgi?id=29264 aaron changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from aaron 2010-07-26 19:44:06 PDT --- yep - its fixed for me :) thanks -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH-v2] gallium: Unified draw_vbo.
This is the second try for unified draw_vbo call. I again upload the patches as a branch here http://cgit.freedesktop.org/~olv/mesa/log/?h=gallium-unified-draw-2 due to the size. Changes since v1: - make index buffer a state and add pipe_context::set_index_buffer - there is a boolean in pipe_draw_info controlling whether draw_vbo should or should not use the index buffer Please review. -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
