[Mesa-dev] [Bug 52250] [softpipe] SIGSEGV sp_tex_sample.c:1536
https://bugs.freedesktop.org/show_bug.cgi?id=52250 --- Comment #2 from Michel Dänzer mic...@daenzer.net 2012-07-19 06:09:56 PDT --- Mesa warning: failed to remap index 173 FWIW, that kind of message is usually a sign of an inconsistent build. -- 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] i965/gen7: Increase the WM threads to hardware limits.
This thread count is only supposed to be enabled when WIZ Hashing Disable in
GT_MODE register enabled. I've always been confused whether that means the
bit in the register should be 1 or 0. For my IVB GT2's register 0x7008 value
of 0x0, this appears to work fine.
Improves l4d2 performance at 640x480 by 0.88 +/- 0.11% (n=88). Improves
performance with rasterization at 1280x1024 by 1.45% +/- 0.36% (n=6).
---
src/mesa/drivers/dri/i965/brw_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index f5c8b6e..5a109e3 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -248,7 +248,7 @@ brwCreateContext(int api,
brw-urb.max_vs_entries = 512;
brw-urb.max_gs_entries = 192;
} else if (intel-gt == 2) {
-brw-max_wm_threads = 86;
+brw-max_wm_threads = 172;
brw-max_vs_threads = 128;
brw-max_gs_threads = 128;
brw-urb.size = 256;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen7: Increase the WM threads to hardware limits.
On 07/19/2012 12:35 AM, Eric Anholt wrote:
This thread count is only supposed to be enabled when WIZ Hashing Disable in
GT_MODE register enabled. I've always been confused whether that means the
bit in the register should be 1 or 0. For my IVB GT2's register 0x7008 value
of 0x0, this appears to work fine.
Improves l4d2 performance at 640x480 by 0.88 +/- 0.11% (n=88). Improves
performance with rasterization at 1280x1024 by 1.45% +/- 0.36% (n=6).
---
src/mesa/drivers/dri/i965/brw_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index f5c8b6e..5a109e3 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -248,7 +248,7 @@ brwCreateContext(int api,
brw-urb.max_vs_entries = 512;
brw-urb.max_gs_entries = 192;
} else if (intel-gt == 2) {
- brw-max_wm_threads = 86;
+ brw-max_wm_threads = 172;
brw-max_vs_threads = 128;
brw-max_gs_threads = 128;
brw-urb.size = 256;
Glad to see this.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
With my Sandybridge GT2's register 0x20d0 value of 0x0, bumping the
maximum thread count to 80 also seems to work (Unigine Heaven didn't
tank my system). I haven't done any performance measurements.
It's unclear to me what the right values should be for the GT1 parts.
The documentation is pretty hard to follow. It'd be nice to be able to
bump those too, if it's legal to do so.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Remove open coded version of ir_variable::interpolation_string().
Presumably the function didn't exist when we wrote this code.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/ast_to_hir.cpp | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index bbe8f05..5ad754c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2010,24 +2010,10 @@ apply_type_qualifier_to_variable(const struct
ast_type_qualifier *qual,
if (var-interpolation != INTERP_QUALIFIER_NONE
!(state-target == vertex_shader var-mode == ir_var_out)
!(state-target == fragment_shader var-mode == ir_var_in)) {
- const char *qual_string = NULL;
- switch (var-interpolation) {
- case INTERP_QUALIFIER_FLAT:
-qual_string = flat;
-break;
- case INTERP_QUALIFIER_NOPERSPECTIVE:
-qual_string = noperspective;
-break;
- case INTERP_QUALIFIER_SMOOTH:
-qual_string = smooth;
-break;
- }
-
_mesa_glsl_error(loc, state,
interpolation qualifier `%s' can only be applied to
vertex shader outputs and fragment shader inputs.,
- qual_string);
-
+ var-interpolation_string());
}
var-pixel_center_integer = qual-flags.q.pixel_center_integer;
--
1.7.11.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 --- Comment #7 from Björn Rask lajva...@gmail.com 2012-07-19 08:53:54 PDT --- Created attachment 64376 -- https://bugs.freedesktop.org/attachment.cgi?id=64376 Björns xorg log -- 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 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 --- Comment #8 from Björn Rask lajva...@gmail.com 2012-07-19 08:54:32 PDT --- Created attachment 64377 -- https://bugs.freedesktop.org/attachment.cgi?id=64377 Björns glxinfo -- 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 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 --- Comment #9 from Björn Rask lajva...@gmail.com 2012-07-19 08:55:05 PDT --- Created attachment 64378 -- https://bugs.freedesktop.org/attachment.cgi?id=64378 Björns dmesg -- 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 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 Björn Rask lajva...@gmail.com changed: What|Removed |Added CC||lajva...@gmail.com --- Comment #10 from Björn Rask lajva...@gmail.com 2012-07-19 08:58:37 PDT --- I have xorg-edgers ppa verison on sandy bridge intel graphics. -- 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 demos] eglkms: Track mesa function rename.
On Don, 2012-07-19 at 01:15 -0600, Scott Moreau wrote: gbm_bo_get_pitch was renamed to gbm_bo_get_stride. eglkms fails to build against mesa master without this. --- src/egl/opengl/eglkms.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/egl/opengl/eglkms.c b/src/egl/opengl/eglkms.c index 1006317..6ba0f12 100644 --- a/src/egl/opengl/eglkms.c +++ b/src/egl/opengl/eglkms.c @@ -239,7 +239,7 @@ int main(int argc, char *argv[]) bo = gbm_surface_lock_front_buffer(gs); handle = gbm_bo_get_handle(bo).u32; - stride = gbm_bo_get_pitch(bo); + stride = gbm_bo_get_stride(bo); This is a libgbm ABI break, which requires one of the following: 1. Bumping the libgbm ABI major version. 2. Keeping gbm_bo_get_pitch as an alias of gbm_bo_get_stride (at least until 1. happens for a better reason). 3. Reverting the symbol rename. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] Clean up dFdy() bug fix.
On 18 July 2012 15:11, Kenneth Graunke kenn...@whitecape.org wrote: On 07/18/2012 12:16 PM, Paul Berry wrote: This patch series cleans up a bug fix I made to Mesa on June 22 (commit 82d2596: i965: Compute dFdy() correctly for FBOs). The bug was that the i965 driver wasn't adjusting the dFdy() logic to account for the fact that window system framebuffers use flipped Y coordinates compared to FBOs. The fix was to compile fragment shaders differently when they are used for FBOs vs window system framebuffers. Commit 82d2596 conservatively assumed that all fragment shader programs might use dFdy(), so it recompiled all of them when switching between FBOs and window system framebuffers. For shaders that don't use dFdy(), the recompile is an unnecessary performance hit. This patch series adds accounting to core mesa to keep track of whether or not a shader uses dFdy(), and changes the i965 back-end to only recompile shaders that actually need it. Patches 1-3 may be of interest to non-i965 developers, since the accounting in core Mesa applies to all back-ends. [PATCH 1/4] mesa: Add UsesDFdy to struct gl_fragment_program. [PATCH 2/4] mesa: Set UsesDFdy appropriately for assembly programs. [PATCH 3/4] glsl: Set UsesDFdy appropriately for GLSL shaders. [PATCH 4/4] i965: Avoid unnecessary recompiles for shaders that don't use dFdy(). Looks fine to me, but please get Ian's ack before pushing. Ian, any comments? For the series: Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos] eglkms: Track mesa function rename.
On Thu, Jul 19, 2012 at 8:39 AM, Michel Dänzer mic...@daenzer.net wrote: On Don, 2012-07-19 at 01:15 -0600, Scott Moreau wrote: gbm_bo_get_pitch was renamed to gbm_bo_get_stride. eglkms fails to build against mesa master without this. --- src/egl/opengl/eglkms.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/egl/opengl/eglkms.c b/src/egl/opengl/eglkms.c index 1006317..6ba0f12 100644 --- a/src/egl/opengl/eglkms.c +++ b/src/egl/opengl/eglkms.c @@ -239,7 +239,7 @@ int main(int argc, char *argv[]) bo = gbm_surface_lock_front_buffer(gs); handle = gbm_bo_get_handle(bo).u32; - stride = gbm_bo_get_pitch(bo); + stride = gbm_bo_get_stride(bo); This is a libgbm ABI break, which requires one of the following: 1. Bumping the libgbm ABI major version. 2. Keeping gbm_bo_get_pitch as an alias of gbm_bo_get_stride (at least until 1. happens for a better reason). 3. Reverting the symbol rename. We have not committed to a stable API for GBM yet. It's unfortunate and confusing that an experimental library is released alongside components with very stable and mature APIs, but I don't see any other way to develop this. We're expecting to release Wayland and Weston 1.0 this year (in a couple of months) and at that point we'll lock the API. I can bump the libgbm .so version. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos] eglkms: Track mesa function rename.
On Don, 2012-07-19 at 10:38 -0400, Kristian Høgsberg wrote: On Thu, Jul 19, 2012 at 8:39 AM, Michel Dänzer mic...@daenzer.net wrote: On Don, 2012-07-19 at 01:15 -0600, Scott Moreau wrote: gbm_bo_get_pitch was renamed to gbm_bo_get_stride. eglkms fails to build against mesa master without this. --- src/egl/opengl/eglkms.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/egl/opengl/eglkms.c b/src/egl/opengl/eglkms.c index 1006317..6ba0f12 100644 --- a/src/egl/opengl/eglkms.c +++ b/src/egl/opengl/eglkms.c @@ -239,7 +239,7 @@ int main(int argc, char *argv[]) bo = gbm_surface_lock_front_buffer(gs); handle = gbm_bo_get_handle(bo).u32; - stride = gbm_bo_get_pitch(bo); + stride = gbm_bo_get_stride(bo); This is a libgbm ABI break, which requires one of the following: 1. Bumping the libgbm ABI major version. 2. Keeping gbm_bo_get_pitch as an alias of gbm_bo_get_stride (at least until 1. happens for a better reason). 3. Reverting the symbol rename. We have not committed to a stable API for GBM yet. It's unfortunate and confusing that an experimental library is released alongside components with very stable and mature APIs, but I don't see any other way to develop this. We're expecting to release Wayland and Weston 1.0 this year (in a couple of months) and at that point we'll lock the API. I can bump the libgbm .so version. I think it's necessary[0]. Otherwise, it won't be possible to use drivers from Mesa 8.1 and 8.0 in parallel, will it? [0] If the other options aren't feasible — it seems rather annoying that Mesa demos can't (trivially) build against Mesa 8.1 and older at the same time, for such a minor change. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600g: add htile support v9
On Tue, Jul 17, 2012 at 7:58 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
htile is used for HiZ and HiS support and fast Z/S clears.
This commit just adds the htile setup and Fast Z clear.
We don't take full advantage of HiS with that patch.
v2 really use fast clear, still random issue with some tiles
need to try more flush combination, fix depth/stencil
texture decompression
v3 fix random issue on r6xx/r7xx
v4 rebase on top of lastest mesa, disable CB export when clearing
htile surface to avoid wasting bandwidth
v5 resummarize htile surface when uploading z value. Fix z/stencil
decompression, the custom blitter with custom dsa is no longer
needed.
v6 Reorganize render control/override update mecanism, fixing more
issues in the process.
v7 Add nop after depth surface base update to work around some htile
flushing issue. For htile to 8x8 on r6xx/r7xx as other combination
have issue. Do not enable hyperz when flushing/uncompressing
depth buffer.
v8 Fix htile surface, preload and prefetch setup. Only set preload
and prefetch on htile surface clear like fglrx. Record depth
clear value per level. Support several level for the htile
surface. First depth clear can't be a fast clear.
v9 Fix comments, properly account new register in emit function,
disable fast zclear if clearing different layer of texture
array to different value
Signed-off-by: Pierre-Eric Pelloux-Prayer pell...@gmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_hw_context.c |6 +
src/gallium/drivers/r600/evergreen_state.c | 102 -
src/gallium/drivers/r600/evergreend.h |4 +
src/gallium/drivers/r600/r600_blit.c| 38 +++
src/gallium/drivers/r600/r600_hw_context.c | 25 +
src/gallium/drivers/r600/r600_pipe.c|8 ++
src/gallium/drivers/r600/r600_pipe.h| 13 ++-
src/gallium/drivers/r600/r600_resource.h|7 ++
src/gallium/drivers/r600/r600_state.c | 133
---
src/gallium/drivers/r600/r600_texture.c | 103 ++
src/gallium/drivers/r600/r600d.h|6 +
11 files changed, 399 insertions(+), 46 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 081701f..546c884 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -62,6 +62,9 @@ static const struct r600_reg evergreen_context_reg_list[] =
{
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028058_DB_DEPTH_SIZE, 0, 0},
{R_02805C_DB_DEPTH_SLICE, 0, 0},
+ {R_02802C_DB_DEPTH_CLEAR, 0, 0},
+ {R_028ABC_DB_HTILE_SURFACE, 0, 0},
+ {R_028AC8_DB_PRELOAD_CONTROL, 0, 0},
{R_028204_PA_SC_WINDOW_SCISSOR_TL, 0, 0},
{R_028208_PA_SC_WINDOW_SCISSOR_BR, 0, 0},
{R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0, 0},
@@ -319,6 +322,9 @@ static const struct r600_reg cayman_context_reg_list[] = {
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028058_DB_DEPTH_SIZE, 0, 0},
{R_02805C_DB_DEPTH_SLICE, 0, 0},
+ {R_02802C_DB_DEPTH_CLEAR, 0, 0},
+ {R_028ABC_DB_HTILE_SURFACE, 0, 0},
+ {R_028AC8_DB_PRELOAD_CONTROL, 0, 0},
{R_028204_PA_SC_WINDOW_SCISSOR_TL, 0, 0},
{R_028208_PA_SC_WINDOW_SCISSOR_BR, 0, 0},
{R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0, 0},
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index a66387b..214d76b 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -710,13 +710,15 @@ static void *evergreen_create_blend_state(struct
pipe_context *ctx,
}
blend-cb_target_mask = target_mask;
- if (target_mask)
+ if (target_mask) {
color_control |= S_028808_MODE(V_028808_CB_NORMAL);
- else
+ } else {
color_control |= S_028808_MODE(V_028808_CB_DISABLE);
+ }
r600_pipe_state_add_reg(rstate, R_028808_CB_COLOR_CONTROL,
color_control);
+
/* only have dual source on MRT0 */
blend-dual_src_blend = util_blend_state_is_dual(state, 0);
for (int i = 0; i 8; i++) {
@@ -1668,6 +1670,26 @@ static void evergreen_db(struct r600_context *rctx,
struct r600_pipe_state *rsta
}
}
+ /* hyperz */
+ if (rtex-hyperz) {
+ uint64_t htile_offset =
rtex-hyperz-surface.level[level].offset;
+
+ rctx-db_misc_state.hyperz = true;
+ rctx-db_misc_state.db_htile_surface_mask = 0x;
+ r600_atom_dirty(rctx, rctx-db_misc_state.atom);
+
[Mesa-dev] [PATCH 2/2] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly (#52059)
From: Julien Cristau julien.cris...@logilab.fr
We were stomping on the caller's buffer by ignoring their alignment
requests. This patch makes the USE_XCB path match the older one more
closely.
Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
src/mapi/glapi/gen/glX_proto_send.py | 36 -
1 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index 9068a61..40cb05d 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -673,16 +673,32 @@ generic_%u_byte( GLint rop, const void * ptr )
if f.needs_reply():
print '%s_reply_t *reply = %s_reply(c,
%s, NULL);' % (xcb_name, xcb_name, xcb_request)
- if output and f.reply_always_array:
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
- elif output and not f.reply_always_array:
- if not output.is_image():
- print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
- print '
(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name)
- print 'else'
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
+ if output:
+ if output.is_image():
+ [dim, w, h, d, junk] =
output.get_dimensions()
+ if f.dimensions_in_reply:
+ w = reply-width
+ h = reply-height
+ d = reply-depth
+ if dim 2:
+ h = 1
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (h, h)
+ if dim 3:
+ d = 1
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (d, d)
+
+ print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d,
output.img_format, output.img_type, xcb_name, output.name)
+ else:
+ s = output.size() /
output.get_element_count()
+ if f.reply_always_array:
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
+ else:
+ print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
+ print '
(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name)
+ print 'else'
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
if f.return_type != 'void':
print 'retval = reply-ret_val;'
--
1.7.2.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glapi/glx: Simplify __glXReadPixelReply
From: Julien Cristau julien.cris...@logilab.fr
Doing
size = reply.length * 4;
[...]
extra = 4 - (size 3);
is useless, size 3 will always be 0.
Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
src/mapi/glapi/gen/glX_proto_send.py |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index bec0222..9068a61 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -246,12 +246,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context *
gc, unsigned max_dim,
__glXSetError(gc, GL_OUT_OF_MEMORY);
}
else {
-const GLint extra = 4 - (size 3);
-
_XRead(dpy, buf, size);
-if ( extra 4 ) {
-_XEatData(dpy, extra);
-}
__glEmptyImage(gc, 3, width, height, depth, format, type,
buf, dest);
--
1.7.2.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52059] __indirect_glReadPixels USE_XCB path buffer overflow
https://bugs.freedesktop.org/show_bug.cgi?id=52059 Julien Cristau jcris...@debian.org changed: What|Removed |Added Keywords||patch --- Comment #2 from Julien Cristau jcris...@debian.org 2012-07-19 15:00:53 PDT --- http://lists.freedesktop.org/pipermail/mesa-dev/2012-July/024302.html -- 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 0/5] add wayland-drm test with gbm/intel-driver update
Hi Halley, I don't think we need to create YUYV buffers in GBM. For test cases, it's fine to just use libdrm-intel directly, like what I've done here: http://cgit.freedesktop.org/~krh/simple-yuv and for real use-cases, libva will use libdrm-intel directly. Kristian On Thu, Jul 19, 2012 at 5:41 AM, Zhao, Halley halley.z...@intel.com wrote: Hi Kristian: These changes mostly work for wayland-drm, do you think we'd better have this simple test for wayland-drm? If yes, do you have better idea to create YUYV buffer from gbm? Or just let it be to use GR88 to get buffer with same size. Thanks -Original Message- From: Zhao, Halley Sent: Tuesday, July 17, 2012 3:15 PM To: mesa-dev@lists.freedesktop.org Cc: Zhao, Halley Subject: [PATCH 0/5] add wayland-drm test with gbm/intel-driver update I had tried to add YUYV support to dri image(to support overlay), however Kristian enabled YUYV as a special planar YUV for wayland (two planes which are overlaped). so I try to follow it and pick up the useful part in my previous patches. - add tiling support for bo update (from user data) - add shared_handle (global region name) in gbm - add YUYV support in gbm - test case to render XRGB or YUYV buffer to weston my understanding of current YUV buffer support in mesa is: it can interpret a YUV buffer, not how to create such buffer. it make me a little nervous to add YUYV to gbm since there is no such format in dri image yet (though there is WL_DRM_FORMAT_YUYV for wayland buffer); I just try to use __DRI_IMAGE_FORMAT_GR88 instead to make sure it create buffer with same size. so, one point I want to seek your comments are: should we consider YUYV buffer allocation in mesa/gbm? should we still need a YUYV format for dri image? thanks. Zhao Halley (5): intel driver: dri image write update gbm: add shared_handle(drm buffer region name) gbm dri backend: add YUYV support wayland: add YUYV to wayland-drm test: test case drm-test-client in src/egl/wayland/wayland-drm src/egl/wayland/wayland-drm/Makefile.am | 16 +- src/egl/wayland/wayland-drm/drm-test-client.c | 478 + src/egl/wayland/wayland-drm/wayland-drm.c |3 +- src/gbm/backends/dri/gbm_dri.c| 26 ++ src/gbm/main/gbm.c| 18 + src/gbm/main/gbm.h|8 +- src/gbm/main/gbmint.h |2 + src/mesa/drivers/dri/intel/intel_screen.c | 17 +- 8 files changed, 563 insertions(+), 5 deletions(-) mode change 100644 = 100755 src/egl/wayland/wayland-drm/Makefile.am create mode 100755 src/egl/wayland/wayland-drm/drm-test-client.c mode change 100644 = 100755 src/egl/wayland/wayland-drm/wayland-drm.c mode change 100644 = 100755 src/gbm/backends/dri/gbm_dri.c mode change 100644 = 100755 src/gbm/main/gbm.c mode change 100644 = 100755 src/gbm/main/gbm.h mode change 100644 = 100755 src/gbm/main/gbmint.h -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XOrg EVoC - Piglit tests for ARB_gpu_shader5 and ARB_tessellation_shader
Ken Phillis Jr kphilli...@gmail.com writes: Hi, I am looking to enter the Xorg EVoC for 2012, and am wanting to Implement two Core extensions for OpenGL 4.0 and GLSL 4.00. Name: Piglit - Implement Tessellation shaders Extension Tests Summary: To implement the initial Tessellation shader support into the Piglit testing framework. This will be done using extensions to OpenGL 3.2, and GLSL 1.50. These extensions are called ARB_tessellation_shader, and ARB_gpu_shader5. This is also a bit of putting the cart in front of the horse in terms of piglit's development, since we don't even have geometry shader testing yet, which is required for tesselation. Intel's plans at least don't have us doing GL 3.2 (geometry shaders) until 2013, and I don't expect other community folks to jump on it, at least testing-wise, before then. Description: I would like to start off by studying the Piglit code base, and looking at what changes are required so that the OpenGL 3.20, and GLSL 1.50 overall requirements for these extensions are met. If there is no major problems with the current framework, I'll start Implementing the numerous tests of ARB_tessellation_shader. Once I finish Implementing the tests for this extension, I will move on to the ARB_gpu_shader5 extension, and Implement the core of this extension. Once both Extensions are finished, I will start implementation of the Interaction tests with other extensions. At the end of each Stage I will submit a review of All the code written up to that point, and Improve the overall readability. This includes adding documentation, and comments where Features are added and/or modified. The piece I'm wondering about is how you're going to test your test code. You didn't mention what drivers you'd be working with to do so. Do you have both AMD and NVIDIA hardware available that you can validate your tests against? Though both drivers frequently have conformance issues, you usually need to have some explanation for what they're doing and how it's wrong. Schedule: I plan on working on this project full time for 10 to 14 weeks, and then continue working on this project for another 2 to 4 weeks part time improving documentation and code readability. *Week 1: Study the Specifications and Piglit's Design, and Start implementing the Missing features that will prevent general testing of these two extensions. If no Changes are required, the Implementation of ARB_tessellation_shader will start. *Week 2-4: Continue Implementing the tests and Utilities for the extension ARB_tessellation_shader. *Week 5: Submit the ARB_tessellation_shader source for Code Review, and begin Implementing ARB_gpu_shader5 Utilities and tests. Please start submitting new tests as soon as you have a couple done and ready. It would be sad to get to week 5 and find a bunch of coding style-type issues that you had to go fix up on all the tests. *Week 6-7: Continue the ARB_gpu_shader5 Implementation. *Week 8: Submit ARB_gpu_shader5 sources for Code Review, and then begin Implementing the code review changes for ARB_tessellation_shader. *Week 9: Continue Implementing code review Changes, and begin work on ARB_gpu_shader5, and ARB_tessellation_shader interactions. *Week 10-12: Continue Implementation of Interactions, and Apply changes suggested in code review. *Week 13+: Submit Code for Final Review Once Again, and apply fixes. pgpKTHAtc4u0X.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52250] [softpipe] SIGSEGV sp_tex_sample.c:1536
https://bugs.freedesktop.org/show_bug.cgi?id=52250 Lucas Stach d...@lynxeye.de changed: What|Removed |Added CC|d...@lynxeye.de | -- 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] glsl: Remove open coded version of ir_variable::interpolation_string().
On Thu, Jul 19, 2012 at 1:46 AM, Kenneth Graunke kenn...@whitecape.org wrote:
Presumably the function didn't exist when we wrote this code.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/ast_to_hir.cpp | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index bbe8f05..5ad754c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2010,24 +2010,10 @@ apply_type_qualifier_to_variable(const struct
ast_type_qualifier *qual,
if (var-interpolation != INTERP_QUALIFIER_NONE
!(state-target == vertex_shader var-mode == ir_var_out)
!(state-target == fragment_shader var-mode == ir_var_in)) {
- const char *qual_string = NULL;
- switch (var-interpolation) {
- case INTERP_QUALIFIER_FLAT:
-qual_string = flat;
-break;
- case INTERP_QUALIFIER_NOPERSPECTIVE:
-qual_string = noperspective;
-break;
- case INTERP_QUALIFIER_SMOOTH:
-qual_string = smooth;
-break;
- }
-
_mesa_glsl_error(loc, state,
interpolation qualifier `%s' can only be applied to
vertex shader outputs and fragment shader inputs.,
- qual_string);
-
+ var-interpolation_string());
}
var-pixel_center_integer = qual-flags.q.pixel_center_integer;
--
1.7.11.2
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glapi/glx: Simplify __glXReadPixelReply
On Thu, Jul 19, 2012 at 7:46 AM, Julien Cristau jcris...@debian.org wrote:
From: Julien Cristau julien.cris...@logilab.fr
Doing
size = reply.length * 4;
[...]
extra = 4 - (size 3);
is useless, size 3 will always be 0.
Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
src/mapi/glapi/gen/glX_proto_send.py |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index bec0222..9068a61 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -246,12 +246,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context *
gc, unsigned max_dim,
__glXSetError(gc, GL_OUT_OF_MEMORY);
}
else {
-const GLint extra = 4 - (size 3);
-
_XRead(dpy, buf, size);
-if ( extra 4 ) {
-_XEatData(dpy, extra);
-}
__glEmptyImage(gc, 3, width, height, depth, format, type,
buf, dest);
--
1.7.2.5
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] Clean up dFdy() bug fix.
On 07/19/2012 07:36 AM, Paul Berry wrote: On 18 July 2012 15:11, Kenneth Graunke kenn...@whitecape.org mailto:kenn...@whitecape.org wrote: On 07/18/2012 12:16 PM, Paul Berry wrote: This patch series cleans up a bug fix I made to Mesa on June 22 (commit 82d2596: i965: Compute dFdy() correctly for FBOs). The bug was that the i965 driver wasn't adjusting the dFdy() logic to account for the fact that window system framebuffers use flipped Y coordinates compared to FBOs. The fix was to compile fragment shaders differently when they are used for FBOs vs window system framebuffers. Commit 82d2596 conservatively assumed that all fragment shader programs might use dFdy(), so it recompiled all of them when switching between FBOs and window system framebuffers. For shaders that don't use dFdy(), the recompile is an unnecessary performance hit. This patch series adds accounting to core mesa to keep track of whether or not a shader uses dFdy(), and changes the i965 back-end to only recompile shaders that actually need it. Patches 1-3 may be of interest to non-i965 developers, since the accounting in core Mesa applies to all back-ends. [PATCH 1/4] mesa: Add UsesDFdy to struct gl_fragment_program. [PATCH 2/4] mesa: Set UsesDFdy appropriately for assembly programs. [PATCH 3/4] glsl: Set UsesDFdy appropriately for GLSL shaders. [PATCH 4/4] i965: Avoid unnecessary recompiles for shaders that don't use dFdy(). Looks fine to me, but please get Ian's ack before pushing. Ian, any comments? For the series: Reviewed-by: Kenneth Graunke kenn...@whitecape.org mailto:kenn...@whitecape.org Names like UsesDFdy are one of arguments for separating words with underscores, but, alas. Reviewed-by: Ian Romanick ian.d.roman...@intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Remove open coded version of ir_variable::interpolation_string().
On 07/19/2012 01:46 AM, Kenneth Graunke wrote:
Presumably the function didn't exist when we wrote this code.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast_to_hir.cpp | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index bbe8f05..5ad754c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2010,24 +2010,10 @@ apply_type_qualifier_to_variable(const struct
ast_type_qualifier *qual,
if (var-interpolation != INTERP_QUALIFIER_NONE
!(state-target == vertex_shader var-mode == ir_var_out)
!(state-target == fragment_shader var-mode == ir_var_in)) {
- const char *qual_string = NULL;
- switch (var-interpolation) {
- case INTERP_QUALIFIER_FLAT:
-qual_string = flat;
-break;
- case INTERP_QUALIFIER_NOPERSPECTIVE:
-qual_string = noperspective;
-break;
- case INTERP_QUALIFIER_SMOOTH:
-qual_string = smooth;
-break;
- }
-
_mesa_glsl_error(loc, state,
interpolation qualifier `%s' can only be applied to
vertex shader outputs and fragment shader inputs.,
- qual_string);
-
+ var-interpolation_string());
}
var-pixel_center_integer = qual-flags.q.pixel_center_integer;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 44345] WebGL cars demo crash in llvm::Type::getForwardedTypeInternal()
https://bugs.freedesktop.org/show_bug.cgi?id=44345 José Fonseca jfons...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from José Fonseca jfons...@vmware.com 2012-07-19 16:29:38 UTC --- This should have be fixed, as part of. commit 3469715a8a171512cf9b528702e70393f01c6041 Author: José Fonseca jfons...@vmware.com Date: Fri Jul 13 18:09:30 2012 +0100 gallivm,draw,llvmpipe: Support wider native registers. as we not longer recreate LLVMContexts. Please reopen if it's still there. -- 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 2/2] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly (#52059)
On 07/19/2012 07:46 AM, Julien Cristau wrote:
From: Julien Cristau julien.cris...@logilab.fr
We were stomping on the caller's buffer by ignoring their alignment
requests. This patch makes the USE_XCB path match the older one more
closely.
Signed-off-by: Julien Cristau julien.cris...@logilab.fr
Say
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059
here instead of mentioning the bug in the subject.
---
src/mapi/glapi/gen/glX_proto_send.py | 36 -
1 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index 9068a61..40cb05d 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -673,16 +673,32 @@ generic_%u_byte( GLint rop, const void * ptr )
if f.needs_reply():
print '%s_reply_t *reply = %s_reply(c,
%s, NULL);' % (xcb_name, xcb_name, xcb_request)
- if output and f.reply_always_array:
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
- elif output and not f.reply_always_array:
- if not output.is_image():
- print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
- print '(void)memcpy(%s,
reply-datum, sizeof(reply-datum));' % (output.name)
- print 'else'
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
+ if output:
+ if output.is_image():
+ [dim, w, h, d, junk] =
output.get_dimensions()
+ if f.dimensions_in_reply:
+ w = reply-width
+ h = reply-height
+ d = reply-depth
+ if dim 2:
+ h = 1
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (h, h)
+ if dim 3:
+ d = 1
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (d, d)
+
+ print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d,
output.img_format, output.img_type, xcb_name, output.name)
I was going to comment that 'dim' should be the second parameter to
__glEmptyImage instead of hardcoding 3, but it looks like the dim
parameter isn't used in __glEmptyImage. I think I can recommend a
follow-on patch. :)
+ else:
+ s = output.size() /
output.get_element_count()
I don't see where this variable is used.
+ if f.reply_always_array:
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
+ else:
+ print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
+ print '
(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name)
+ print 'else'
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
if f.return_type != 'void':
print 'retval = reply-ret_val;'
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glapi/glx: Simplify __glXReadPixelReply
On 07/19/2012 07:46 AM, Julien Cristau wrote:
From: Julien Cristau julien.cris...@logilab.fr
Doing
size = reply.length * 4;
[...]
extra = 4 - (size 3);
is useless, size 3 will always be 0.
Signed-off-by: Julien Cristau julien.cris...@logilab.fr
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/glX_proto_send.py |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index bec0222..9068a61 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -246,12 +246,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context *
gc, unsigned max_dim,
__glXSetError(gc, GL_OUT_OF_MEMORY);
}
else {
-const GLint extra = 4 - (size 3);
-
_XRead(dpy, buf, size);
-if ( extra 4 ) {
-_XEatData(dpy, extra);
-}
__glEmptyImage(gc, 3, width, height, depth, format, type,
buf, dest);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] sp_tex_sample: Fix segfault with fbo-cubemap.
On 07/19/2012 10:55 AM, Olivier Galibert wrote:
The cube sampler generates two-dimensional texture coordinates and
hence passes NULL for the array for the third one. The actual 2D
sampler, lower in the pipe, knew not to used that array since it
didn't need it. But the samplers have become single-texel and the
coordinate array dereference has been moved up one step, to a level
where the code does not know only two coordinates are used. Hence the
segfault.
The simplest fix by far is to add a third dummy coordinate array in
the call to the next pipe step, which will be dereferenced to an
harmless 0 which then will be happily ignored by the sampler.
Signed-off-by: Olivier Galibertgalib...@pobox.com
---
src/gallium/drivers/softpipe/sp_tex_sample.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Brown paper bag time. I had tested with (I think) everything with
tex in the name. Guess what fbo-cubemap doesn't have in the name?
Fixes 52250.
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index 292dc6e..2f6e272 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -2090,6 +2090,11 @@ sample_cube(struct tgsi_sampler *tgsi_sampler,
unsigned j;
float [4], [4];
+ /* Not actually used, but the intermediate steps that do the
+* dereferencing don't know it.
+*/
+ float [4] = { 0, 0, 0, 0 };
static const float ...
+
/*
major axis
directiontarget sc tcma
@@ -2157,7 +2162,7 @@ sample_cube(struct tgsi_sampler *tgsi_sampler,
* is not active, this will point somewhere deeper into the
* pipeline, eg. to mip_filter or even img_filter.
*/
- samp-compare(tgsi_sampler, , , NULL, c0, control, rgba);
+ samp-compare(tgsi_sampler, , , , c0, control, rgba);
}
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: Set gl_fragment_program::UsesKill in do_set_program_inouts.
Previously, the code for setting this flag for GLSL programs was
duplicated in three places: brw_link_shader(), glsl_to_tgsi_visitor,
and ir_to_mesa_visitor. In addition to the unnecessary duplication,
there was a performance problem on i965: brw_link_shader() set the
flag before doing its final round of optimizations, which meant that
if the optimizations managed to eliminate all the discard operations,
the flag would still be set, resulting (at least in theory) in slower
performance.
This patch consolidates all of the code that sets UsesKill for GLSL
programs into do_set_program_inouts(), which already is doing a
similar job for UsesDFdy, and which occurs after i965's final round of
optimizations.
Non-GLSL programs (ARB programs and the state tracker's glBitmap
program) are unaffected.
---
src/glsl/ir_set_program_inouts.cpp | 14 ++
src/mesa/drivers/dri/i965/brw_shader.cpp | 25 -
src/mesa/program/ir_to_mesa.cpp|4
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |4
4 files changed, 14 insertions(+), 33 deletions(-)
diff --git a/src/glsl/ir_set_program_inouts.cpp
b/src/glsl/ir_set_program_inouts.cpp
index 845aa11..e5de07e 100644
--- a/src/glsl/ir_set_program_inouts.cpp
+++ b/src/glsl/ir_set_program_inouts.cpp
@@ -62,6 +62,7 @@ public:
virtual ir_visitor_status visit_enter(ir_dereference_array *);
virtual ir_visitor_status visit_enter(ir_function_signature *);
virtual ir_visitor_status visit_enter(ir_expression *);
+ virtual ir_visitor_status visit_enter(ir_discard *);
virtual ir_visitor_status visit(ir_dereference_variable *);
virtual ir_visitor_status visit(ir_variable *);
@@ -180,6 +181,18 @@ ir_set_program_inouts_visitor::visit_enter(ir_expression
*ir)
return visit_continue;
}
+ir_visitor_status
+ir_set_program_inouts_visitor::visit_enter(ir_discard *)
+{
+ /* discards are only allowed in fragment shaders. */
+ assert(is_fragment_shader);
+
+ gl_fragment_program *fprog = (gl_fragment_program *) prog;
+ fprog-UsesKill = true;
+
+ return visit_continue;
+}
+
void
do_set_program_inouts(exec_list *instructions, struct gl_program *prog,
bool is_fragment_shader)
@@ -194,6 +207,7 @@ do_set_program_inouts(exec_list *instructions, struct
gl_program *prog,
memset(fprog-InterpQualifier, 0, sizeof(fprog-InterpQualifier));
fprog-IsCentroid = 0;
fprog-UsesDFdy = false;
+ fprog-UsesKill = false;
}
visit_list_elements(v, instructions);
}
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 140a268..9356714 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -109,31 +109,6 @@ brw_link_shader(struct gl_context *ctx, struct
gl_shader_program *shProg)
vp-UsesClipDistance = shProg-Vert.UsesClipDistance;
}
- if (stage == 1) {
-class uses_kill_visitor : public ir_hierarchical_visitor {
-public:
- uses_kill_visitor() : uses_kill(false)
- {
- /* empty */
- }
-
- virtual ir_visitor_status visit_enter(class ir_discard *ir)
- {
- this-uses_kill = true;
- return visit_stop;
- }
-
- bool uses_kill;
-};
-
-uses_kill_visitor v;
-
-v.run(shader-base.ir);
-
-struct gl_fragment_program *fp = (struct gl_fragment_program *) prog;
-fp-UsesKill = v.uses_kill;
- }
-
void *mem_ctx = ralloc_context(NULL);
bool progress;
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 217a264..8a4f311 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2157,8 +2157,6 @@ ir_to_mesa_visitor::visit(ir_return *ir)
void
ir_to_mesa_visitor::visit(ir_discard *ir)
{
- struct gl_fragment_program *fp = (struct gl_fragment_program *)this-prog;
-
if (ir-condition) {
ir-condition-accept(this);
this-result.negate = ~this-result.negate;
@@ -2166,8 +2164,6 @@ ir_to_mesa_visitor::visit(ir_discard *ir)
} else {
emit(ir, OPCODE_KIL_NV);
}
-
- fp-UsesKill = GL_TRUE;
}
void
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 1d91e36..34dbfd3 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2758,8 +2758,6 @@ glsl_to_tgsi_visitor::visit(ir_return *ir)
void
glsl_to_tgsi_visitor::visit(ir_discard *ir)
{
- struct gl_fragment_program *fp = (struct gl_fragment_program *)this-prog;
-
if (ir-condition) {
ir-condition-accept(this);
this-result.negate = ~this-result.negate;
@@ -2767,8 +2765,6 @@ glsl_to_tgsi_visitor::visit(ir_discard *ir)
} else {
emit(ir, TGSI_OPCODE_KILP);
}
-
- fp-UsesKill = GL_TRUE;
}
void
--
1.7.7.6
Re: [Mesa-dev] [PATCH 2/2] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly (#52059)
On Thu, Jul 19, 2012 at 09:39:09 -0700, Ian Romanick wrote: On 07/19/2012 07:46 AM, Julien Cristau wrote: From: Julien Cristau julien.cris...@logilab.fr We were stomping on the caller's buffer by ignoring their alignment requests. This patch makes the USE_XCB path match the older one more closely. Signed-off-by: Julien Cristau julien.cris...@logilab.fr Say Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059 here instead of mentioning the bug in the subject. Will do. [...] +print ' __glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d, output.img_format, output.img_type, xcb_name, output.name) I was going to comment that 'dim' should be the second parameter to __glEmptyImage instead of hardcoding 3, but it looks like the dim parameter isn't used in __glEmptyImage. I think I can recommend a follow-on patch. :) Ack. +else: +s = output.size() / output.get_element_count() I don't see where this variable is used. Right, I'll drop it. Thanks! Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mapi: share sources.mak with Android again
This (sort of) reverts commit 5154b45217695e5daf24110bcff043fa1959d0a5 mapi: Fix Android build --- src/mapi/Android.mk | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/mapi/Android.mk b/src/mapi/Android.mk index d1749a2..9d54210 100644 --- a/src/mapi/Android.mk +++ b/src/mapi/Android.mk @@ -25,6 +25,10 @@ LOCAL_PATH := $(call my-dir) +# LOCAL_SRC_FILES must only contain relative paths. +MAPI := ./mapi +include $(LOCAL_PATH)/mapi/sources.mak + mapi_abi_headers := # --- @@ -35,13 +39,7 @@ include $(CLEAR_VARS) abi_header := shared-glapi/glapi_mapi_tmp.h -LOCAL_SRC_FILES := \ - mapi/entry.c \ - mapi/mapi_glapi.c \ - mapi/stub.c \ - mapi/table.c \ - mapi/u_current.c \ - mapi/u_execmem.c +LOCAL_SRC_FILES := $(MAPI_GLAPI_FILES) LOCAL_CFLAGS := \ -DMAPI_MODE_GLAPI \ -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mapi: use a path prefix for sources variable
On 07/19/2012 10:59 AM, nobled wrote: This makes it possible to share sources.mak with the Android build again. --- Still todo: sharing this with the SConscript build, which still duplicates the list of sources. src/mapi/glapi/Makefile.am|4 +++- src/mapi/mapi/sources.mak | 25 ++--- src/mapi/shared-glapi/Makefile.am |4 +++- 3 files changed, 20 insertions(+), 13 deletions(-) diff --git a/src/mapi/glapi/Makefile.am b/src/mapi/glapi/Makefile.am index 668d7fa..b9ef88f 100644 --- a/src/mapi/glapi/Makefile.am +++ b/src/mapi/glapi/Makefile.am @@ -19,9 +19,10 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS # IN THE SOFTWARE. -TOP = $(top_srcdir) include sources.mak -include ../mapi/sources.mak + +MAPI = $(srcdir)/../mapi +include $(MAPI)/sources.mak AM_CPPFLAGS = \ $(DEFINES) \ diff --git a/src/mapi/mapi/sources.mak b/src/mapi/mapi/sources.mak index 56f4afd..6c15170 100644 --- a/src/mapi/mapi/sources.mak +++ b/src/mapi/mapi/sources.mak @@ -13,24 +13,27 @@ # # - In bridge mode, mapi provides entry points calling into glapi. To use #this mode, compile MAPI_BRIDGE_FILES with MAPI_MODE_BRIDGE defined. +# +# The variable $(MAPI) must be defined to point to this source directory +# before the following variables can be used. MAPI_UTIL_FILES = \ - $(TOP)/src/mapi/mapi/u_current.c \ - $(TOP)/src/mapi/mapi/u_execmem.c + $(MAPI)/u_current.c \ + $(MAPI)/u_execmem.c MAPI_FILES = \ - $(TOP)/src/mapi/mapi/entry.c \ - $(TOP)/src/mapi/mapi/mapi.c \ - $(TOP)/src/mapi/mapi/stub.c \ - $(TOP)/src/mapi/mapi/table.c \ + $(MAPI)/entry.c \ + $(MAPI)/mapi.c \ + $(MAPI)/stub.c \ + $(MAPI)/table.c \ $(MAPI_UTIL_FILES) MAPI_GLAPI_FILES = \ - $(TOP)/src/mapi/mapi/entry.c \ - $(TOP)/src/mapi/mapi/mapi_glapi.c \ - $(TOP)/src/mapi/mapi/stub.c \ - $(TOP)/src/mapi/mapi/table.c \ + $(MAPI)/entry.c \ + $(MAPI)/mapi_glapi.c \ + $(MAPI)/stub.c \ + $(MAPI)/table.c \ $(MAPI_UTIL_FILES) MAPI_BRIDGE_FILES = \ - $(TOP)/src/mapi/mapi/entry.c + $(MAPI)/entry.c diff --git a/src/mapi/shared-glapi/Makefile.am b/src/mapi/shared-glapi/Makefile.am index 9485683..2cb33fc 100644 --- a/src/mapi/shared-glapi/Makefile.am +++ b/src/mapi/shared-glapi/Makefile.am @@ -1,8 +1,9 @@ # Used by OpenGL ES or when --enable-shared-glapi is specified -TOP = $(top_srcdir) GLAPI = $(top_srcdir)/src/mapi/glapi -include $(top_srcdir)/src/mapi/mapi/sources.mak +MAPI = $(top_srcdir)/src/mapi/mapi + +include $(MAPI)/sources.mak lib_LTLIBRARIES = libglapi.la libglapi_la_SOURCES = $(MAPI_GLAPI_FILES) I just applied this patch to master(fadc9eaf97c0916d5680c1d3b47e80532ede22c1), and it breaks the build with this message: make[2]: Entering directory `/hedgehog/build/mesa/src/src/mapi/shared-glapi' ../../../src/mapi/glapi/gen/glapi_gen.mk:4: *** TOP must be defined.. Stop. make[2]: Leaving directory `/hedgehog/build/mesa/src/src/mapi/shared-glapi' I'm using the autotools build. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mapi: share sources.mak with Android again
On 07/19/2012 11:00 AM, nobled wrote: This (sort of) reverts commit 5154b45217695e5daf24110bcff043fa1959d0a5 mapi: Fix Android build --- src/mapi/Android.mk | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/mapi/Android.mk b/src/mapi/Android.mk index d1749a2..9d54210 100644 --- a/src/mapi/Android.mk +++ b/src/mapi/Android.mk @@ -25,6 +25,10 @@ LOCAL_PATH := $(call my-dir) +# LOCAL_SRC_FILES must only contain relative paths. +MAPI := ./mapi +include $(LOCAL_PATH)/mapi/sources.mak + mapi_abi_headers := It's nice to see the return of sharing source lists with Android, but this patch won't work as-is. In an Android makefile, the current directory '.' is always the top of the Android source tree, not the directoring containing the makefile. If I understand the patch's intent correctly, MAPI should be set as MAPI := $(LOCAL_PATH)/mapi -Chad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): gallium-egl: Implement eglQueryWaylandBufferWL
This commit is causing build failures in several platforms because
EGL_WL_bind_wayland_display is defined everywhere (including windows), and not
just on platforms where wayland-drm.h exists.
Don't know why it was not failing before though.
I'm not very familiar with the st/egl code, but shouldn't the waylayng specific
stuff be in src/gallium/state_trackers/egl/wayland/ instead of
src/gallium/state_trackers/egl/common?
Jose
- Original Message -
Module: Mesa
Branch: master
Commit: e1b45a3c06ec19a2b9f1e0d3f8732aaad2d932da
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e1b45a3c06ec19a2b9f1e0d3f8732aaad2d932da
Author: Kristian Høgsberg k...@bitplanet.net
Date: Thu Jul 19 08:48:45 2012 -0400
gallium-egl: Implement eglQueryWaylandBufferWL
Support this query for gallium EGL too.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
.../state_trackers/egl/common/egl_g3d_api.c| 32
+++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
index 58e772f..f2e86de 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
@@ -39,6 +39,10 @@
#include egl_g3d_st.h
#include native.h
+#ifdef EGL_WL_bind_wayland_display
+#include wayland-drm.h
+#endif
+
/**
* Return the state tracker for the given context.
*/
@@ -873,6 +877,32 @@ egl_g3d_unbind_wayland_display_wl(_EGLDriver
*drv, _EGLDisplay *dpy,
return gdpy-native-wayland_bufmgr-unbind_display(gdpy-native,
wl_dpy);
}
+static EGLBoolean
+egl_g3d_query_wayland_buffer_wl(_EGLDriver *drv, _EGLDisplay *dpy,
+struct wl_buffer *_buffer,
+EGLint attribute, EGLint *value)
+{
+ struct wl_drm_buffer *buffer = (struct wl_drm_buffer *) _buffer;
+ struct pipe_resource *resource = buffer-driver_buffer;
+
+ if (!wayland_buffer_is_drm(buffer-buffer))
+ return EGL_FALSE;
+
+ if (attribute == EGL_WAYLAND_BUFFER_COMPONENTS_WL) {
+ switch (resource-format) {
+ case PIPE_FORMAT_B8G8R8A8_UNORM:
+ *value = EGL_WAYLAND_BUFFER_RGBA_WL;
+ return EGL_TRUE;
+ case PIPE_FORMAT_B8G8R8X8_UNORM:
+ *value = EGL_WAYLAND_BUFFER_RGB_WL;
+ return EGL_TRUE;
+ default:
+ return EGL_FALSE;
+ }
+ }
+
+ return EGL_FALSE;
+}
#endif /* EGL_WL_bind_wayland_display */
void
@@ -907,7 +937,7 @@ egl_g3d_init_driver_api(_EGLDriver *drv)
#ifdef EGL_WL_bind_wayland_display
drv-API.BindWaylandDisplayWL = egl_g3d_bind_wayland_display_wl;
drv-API.UnbindWaylandDisplayWL =
egl_g3d_unbind_wayland_display_wl;
-
+ drv-API.QueryWaylandBufferWL = egl_g3d_query_wayland_buffer_wl;
#endif
drv-API.CreateSyncKHR = egl_g3d_create_sync;
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): gallium-egl: Implement eglQueryWaylandBufferWL
- Original Message - This commit is causing build failures in several platforms because EGL_WL_bind_wayland_display is defined everywhere (including windows), and not just on platforms where wayland-drm.h exists. Actually it is more subtle. On scons + cross mingw it fails as: Compiling src/gallium/state_trackers/egl/common/egl_g3d_api.c ... src/gallium/state_trackers/egl/common/egl_g3d_api.c:43:25: fatal error: wayland-drm.h: No such file or directory On autoconf on ubuntu64 it fails with: gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/egl/main -I../../../../src/egl/wayland/wayland-drm/ -I../../../../include -DHAVE_X11_BACKEND -D_GNU_SOURCE -DPTHREADS -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_LLVM=0x0301 -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC -D_GNU_SOURCE -DPTHREADS -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_LLVM=0x0301 -fvisibility=hidden common/egl_g3d_api.c -o common/egl_g3d_api.o In file included from common/egl_g3d_api.c:43:0: ../../../../src/egl/wayland/wayland-drm/wayland-drm.h:4:28: fatal error: wayland-server.h: No such file or directory Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52277] New: src/gallium/state_trackers/egl/common/egl_g3d_api.c:43:25: fatal error: wayland-drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=52277 Bug #: 52277 Summary: src/gallium/state_trackers/egl/common/egl_g3d_api.c:43 :25: fatal error: wayland-drm.h: No such file or directory Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: v...@freedesktop.org CC: k...@bitplanet.net mesa: d7522ed13052a3d30bc4faedce04685263f57933 (master) $ scons [...] Compiling src/gallium/state_trackers/egl/common/egl_g3d_api.c ... src/gallium/state_trackers/egl/common/egl_g3d_api.c:43:25: fatal error: wayland-drm.h: No such file or directory e1b45a3c06ec19a2b9f1e0d3f8732aaad2d932da is the first bad commit commit e1b45a3c06ec19a2b9f1e0d3f8732aaad2d932da Author: Kristian Høgsberg k...@bitplanet.net Date: Thu Jul 19 08:48:45 2012 -0400 gallium-egl: Implement eglQueryWaylandBufferWL Support this query for gallium EGL too. Signed-off-by: Kristian Høgsberg k...@bitplanet.net :04 04 839d5570d9522949e9c7df98049d2023bf16edbe 73a2c564784ad817bc77b5b4e21deb888f9cf942 Msrc bisect run success -- 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] sp_tex_sample: Fix segfault with fbo-cubemap.
On Thu, Jul 19, 2012 at 10:57:38AM -0600, Brian Paul wrote: static const float ... Indeed. Reviewed-by: Brian Paul bri...@vmware.com Thanks. Could you commit it please? Best, OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: fix masked transformations
Someone tried to be clever and optimized add_vertex_data2() to just use
two points for the texture coordinates and then reuse individual
components. Sadly this is not how matrix multiplication works.
Fixes rendercheck -t tmcoords
Signed-off-by: Lucas Stach d...@lynxeye.de
---
src/gallium/state_trackers/xorg/xorg_renderer.c | 60 +++
1 Datei geändert, 40 Zeilen hinzugefügt(+), 20 Zeilen entfernt(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_renderer.c
b/src/gallium/state_trackers/xorg/xorg_renderer.c
index bf2d5b7..286ab34 100644
--- a/src/gallium/state_trackers/xorg/xorg_renderer.c
+++ b/src/gallium/state_trackers/xorg/xorg_renderer.c
@@ -213,53 +213,73 @@ add_vertex_data2(struct xorg_renderer *r,
struct pipe_resource *mask,
float *src_matrix, float *mask_matrix)
{
- float src_s0, src_t0, src_s1, src_t1;
- float mask_s0, mask_t0, mask_s1, mask_t1;
- float spt0[2], spt1[2];
- float mpt0[2], mpt1[2];
+ float src_s0, src_t0, src_s1, src_t1, src_s2, src_t2, src_s3, src_t3;
+ float mask_s0, mask_t0, mask_s1, mask_t1, mask_s2, mask_t2, mask_s3,
mask_t3;
+ float spt0[2], spt1[2], spt2[2], spt3[2];
+ float mpt0[2], mpt1[2], mpt2[2], mpt3[2];
spt0[0] = srcX;
spt0[1] = srcY;
- spt1[0] = srcX + width;
- spt1[1] = srcY + height;
+ spt1[0] = (srcX + width);
+ spt1[1] = srcY;
+ spt2[0] = (srcX + width);
+ spt2[1] = (srcY + height);
+ spt3[0] = srcX;
+ spt3[1] = (srcY + height);
mpt0[0] = maskX;
mpt0[1] = maskY;
- mpt1[0] = maskX + width;
- mpt1[1] = maskY + height;
+ mpt1[0] = (maskX + width);
+ mpt1[1] = maskY;
+ mpt2[0] = (maskX + width);
+ mpt2[1] = (maskY + height);
+ mpt3[0] = maskX;
+ mpt3[1] = (maskY + height);
if (src_matrix) {
map_point(src_matrix, spt0[0], spt0[1], spt0[0], spt0[1]);
map_point(src_matrix, spt1[0], spt1[1], spt1[0], spt1[1]);
+ map_point(src_matrix, spt2[0], spt2[1], spt2[0], spt2[1]);
+ map_point(src_matrix, spt3[0], spt3[1], spt3[0], spt3[1]);
}
if (mask_matrix) {
map_point(mask_matrix, mpt0[0], mpt0[1], mpt0[0], mpt0[1]);
map_point(mask_matrix, mpt1[0], mpt1[1], mpt1[0], mpt1[1]);
+ map_point(mask_matrix, mpt2[0], mpt2[1], mpt2[0], mpt2[1]);
+ map_point(mask_matrix, mpt3[0], mpt3[1], mpt3[0], mpt3[1]);
}
- src_s0 = spt0[0] / src-width0;
- src_t0 = spt0[1] / src-height0;
- src_s1 = spt1[0] / src-width0;
- src_t1 = spt1[1] / src-height0;
-
- mask_s0 = mpt0[0] / mask-width0;
- mask_t0 = mpt0[1] / mask-height0;
- mask_s1 = mpt1[0] / mask-width0;
- mask_t1 = mpt1[1] / mask-height0;
+ src_s0 = spt0[0] / src-width0;
+ src_s1 = spt1[0] / src-width0;
+ src_s2 = spt2[0] / src-width0;
+ src_s3 = spt3[0] / src-width0;
+ src_t0 = spt0[1] / src-height0;
+ src_t1 = spt1[1] / src-height0;
+ src_t2 = spt2[1] / src-height0;
+ src_t3 = spt3[1] / src-height0;
+
+ mask_s0 = mpt0[0] / mask-width0;
+ mask_s1 = mpt1[0] / mask-width0;
+ mask_s2 = mpt2[0] / mask-width0;
+ mask_s3 = mpt3[0] / mask-width0;
+ mask_t0 = mpt0[1] / mask-height0;
+ mask_t1 = mpt1[1] / mask-height0;
+ mask_t2 = mpt2[1] / mask-height0;
+ mask_t3 = mpt3[1] / mask-height0;
/* 1st vertex */
add_vertex_2tex(r, dstX, dstY,
src_s0, src_t0, mask_s0, mask_t0);
/* 2nd vertex */
add_vertex_2tex(r, dstX + width, dstY,
- src_s1, src_t0, mask_s1, mask_t0);
+ src_s1, src_t1, mask_s1, mask_t1);
/* 3rd vertex */
add_vertex_2tex(r, dstX + width, dstY + height,
- src_s1, src_t1, mask_s1, mask_t1);
+ src_s2, src_t2, mask_s2, mask_t2);
/* 4th vertex */
add_vertex_2tex(r, dstX, dstY + height,
- src_s0, src_t1, mask_s0, mask_t1);
+ src_s3, src_t3, mask_s3, mask_t3);
}
static void
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52250] [softpipe] SIGSEGV sp_tex_sample.c:1536
https://bugs.freedesktop.org/show_bug.cgi?id=52250 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Brian Paul brian.e.p...@gmail.com 2012-07-19 19:26:26 UTC --- Should be fixed with commit fbe3fa74e5cdaf02f3738da7d6052e1f1fd7bbf2 -- 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 (master): gallium-egl: Implement eglQueryWaylandBufferWL
On Thu, Jul 19, 2012 at 2:44 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - This commit is causing build failures in several platforms because EGL_WL_bind_wayland_display is defined everywhere (including windows), and not just on platforms where wayland-drm.h exists. Yes, I see the problem, I'm fixing it now. I'm using the wayland_bufmgr that is already in place now, so it should work as well as before. Kristian Actually it is more subtle. On scons + cross mingw it fails as: Compiling src/gallium/state_trackers/egl/common/egl_g3d_api.c ... src/gallium/state_trackers/egl/common/egl_g3d_api.c:43:25: fatal error: wayland-drm.h: No such file or directory On autoconf on ubuntu64 it fails with: gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/egl/main -I../../../../src/egl/wayland/wayland-drm/ -I../../../../include -DHAVE_X11_BACKEND -D_GNU_SOURCE -DPTHREADS -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_LLVM=0x0301 -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC -D_GNU_SOURCE -DPTHREADS -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_LLVM=0x0301 -fvisibility=hidden common/egl_g3d_api.c -o common/egl_g3d_api.o In file included from common/egl_g3d_api.c:43:0: ../../../../src/egl/wayland/wayland-drm/wayland-drm.h:4:28: fatal error: wayland-server.h: No such file or directory Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=47375 --- Comment #3 from Brian Paul brian.e.p...@gmail.com 2012-07-19 19:31:37 PDT --- (In reply to comment #2) same bug with a radeon 9000 card ( M9 ) : OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2 blender crashs with this message with mesa 8.0.4 : blender: swrast/s_span.c:1327: _swrast_write_rgba_span: Assertion `colorType == 0x1401 || colorType == 0x1406' failed. the bug doesn't occur with an old mesa release ( Mesa-7.11.2 ) Can you get the value of colorType in gdb at the failed assertion? -- 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 v2 01/12] mesa: add glformats integer type/format detection routines
Hi Jordan,
I'd like to see this patch committed so I can do some follow-on
re-org. Just minor comments below.
On Wed, Jul 11, 2012 at 3:58 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
_mesa_is_integer_format is moved to formats.c and renamed
as _mesa_is_enum_format_integer.
_mesa_is_format_unsigned, _mesa_is_type_integer,
_mesa_is_type_unsigned, and _mesa_is_enum_format_or_type_integer
are added.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/main/drawpix.c |3 +-
src/mesa/main/formats.c | 13 ++
src/mesa/main/formats.h |4 +-
src/mesa/main/glformats.c | 185
+
src/mesa/main/glformats.h | 63 ++
src/mesa/main/image.c | 76
src/mesa/main/image.h |3 -
src/mesa/main/pack.c |9 +-
src/mesa/main/readpix.c |7 +-
src/mesa/main/teximage.c | 11 +-
src/mesa/sources.mak |1 +
You also need to add the new source glformats.c file src/mesa/SConscript.
src/mesa/state_tracker/st_cb_drawpixels.c |3 +-
12 files changed, 284 insertions(+), 94 deletions(-)
create mode 100644 src/mesa/main/glformats.c
create mode 100644 src/mesa/main/glformats.h
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index def55dd..7a5597b 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -35,6 +35,7 @@
#include pbo.h
#include state.h
#include dispatch.h
+#include glformats.h
#if FEATURE_drawpix
@@ -89,7 +90,7 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
* input), NVIDIA's implementation also just returns this error despite
* exposing GL_EXT_texture_integer, just return an error regardless.
*/
- if (_mesa_is_integer_format(format)) {
+ if (_mesa_is_enum_format_integer(format)) {
_mesa_error(ctx, GL_INVALID_OPERATION, glDrawPixels(integer format));
goto end;
}
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index ccc0b17..ca739cd 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -28,6 +28,7 @@
#include formats.h
#include mfeatures.h
#include macros.h
+#include glformats.h
/**
@@ -1712,6 +1713,17 @@ _mesa_is_format_integer_color(gl_format format)
/**
+ * Is the given format an unsigned integer format?
+ */
+GLboolean
+_mesa_is_format_unsigned(gl_format format)
+{
+ const struct gl_format_info *info = _mesa_get_format_info(format);
+ return _mesa_is_type_unsigned(info-DataType);
+}
+
+
+/**
* Return color encoding for given format.
* \return GL_LINEAR or GL_SRGB
*/
@@ -2935,3 +2947,4 @@ _mesa_format_matches_format_and_type(gl_format
gl_format,
return GL_FALSE;
}
+
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 3a694a8..176e0fd 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -311,6 +311,9 @@ _mesa_is_format_packed_depth_stencil(gl_format format);
extern GLboolean
_mesa_is_format_integer_color(gl_format format);
+extern GLboolean
+_mesa_is_format_unsigned(gl_format format);
+
extern GLenum
_mesa_get_format_color_encoding(gl_format format);
@@ -346,7 +349,6 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
GLenum format, GLenum type,
GLboolean swapBytes);
-
#ifdef __cplusplus
}
#endif
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
new file mode 100644
index 000..b2277c3
--- /dev/null
+++ b/src/mesa/main/glformats.c
@@ -0,0 +1,185 @@
+/*
+ * Mesa 3-D graphics library
+ * Version: 7.7
Remove the version line, we don'd do that anymore.
+ *
+ * Copyright (C) 1999-2008 Brian Paul All Rights Reserved.
+ * Copyright (c) 2008-2009 VMware, Inc.
You can add an Intel copyright line if you want.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
s/BRIAN PAUL/THE
[Mesa-dev] (no subject)
Hi, This is the second verion of the clipping/interpolation patches. Main differences: - I tried to take all of Paul's remarks into account - I exploded the first patch in 4 independant ones - I've added a patch to ensure that integers pass through unscathed Patch 4/9 is (slightly) controversial. There may be better ways to do it, or at least more general ones. But it's simple, it works, and it allows to validate the other 8. It's an easy one to revert if we build an alternative. Best, OG. [PATCH 1/9] intel gen4-5: fix the vue view in the fs. [PATCH 2/9] intel gen4-5: simplify the bfc copy in the sf. [PATCH 3/9] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE selection. [PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one [PATCH 5/9] intel gen4-5: Compute the interpolation status for every [PATCH 6/9] intel gen4-5: Correctly setup the parameters in the sf. [PATCH 7/9] intel gen4-5: Correctly handle flat vs. non-flat in the [PATCH 8/9] intel gen4-5: Make noperspective clipping work. [PATCH 9/9] intel gen4-5: Don't touch flatshaded values when ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/9] intel gen4-5: fix the vue view in the fs.
In some cases the fragment shader view of the vue registers was out of
sync with the builder. This fixes it.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 -
src/mesa/drivers/dri/i965/brw_wm_pass2.c | 10 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index b3b25cc..3f98137 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -972,8 +972,15 @@ fs_visitor::calculate_urb_setup()
if (c-key.vp_outputs_written BITFIELD64_BIT(i)) {
int fp_index = _mesa_vert_result_to_frag_attrib((gl_vert_result) i);
+ /* The back color slot is skipped when the front color is
+* also written to. In addition, some slots can be
+* written in the vertex shader and not read in the
+* fragment shader. So the register number must always be
+* incremented, mapped or not.
+*/
if (fp_index = 0)
- urb_setup[fp_index] = urb_next++;
+ urb_setup[fp_index] = urb_next;
+ urb_next++;
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_wm_pass2.c
b/src/mesa/drivers/dri/i965/brw_wm_pass2.c
index 27c0a94..eacf7c0 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_pass2.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_pass2.c
@@ -97,8 +97,16 @@ static void init_registers( struct brw_wm_compile *c )
int fp_index = _mesa_vert_result_to_frag_attrib(j);
nr_interp_regs++;
+
+ /* The back color slot is skipped when the front color is
+* also written to. In addition, some slots can be
+* written in the vertex shader and not read in the
+* fragment shader. So the register number must always be
+* incremented, mapped or not.
+*/
if (fp_index = 0)
- prealloc_reg(c, c-payload.input_interp[fp_index], i++);
+ prealloc_reg(c, c-payload.input_interp[fp_index], i);
+i++;
}
}
assert(nr_interp_regs = 1);
--
1.7.10.280.gaa39
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/9] intel gen4-5: simplify the bfc copy in the sf.
This patch is mostly designed to make followup patches simpler, but
it's a simplification by itself.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_sf_emit.c | 93 +--
1 file changed, 52 insertions(+), 41 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index ff6383b..9d8aa38 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
@@ -79,24 +79,9 @@ have_attr(struct brw_sf_compile *c, GLuint attr)
/***
* Twoside lighting
*/
-static void copy_bfc( struct brw_sf_compile *c,
- struct brw_reg vert )
-{
- struct brw_compile *p = c-func;
- GLuint i;
-
- for (i = 0; i 2; i++) {
- if (have_attr(c, VERT_RESULT_COL0+i)
- have_attr(c, VERT_RESULT_BFC0+i))
-brw_MOV(p,
-get_vert_result(c, vert, VERT_RESULT_COL0+i),
-get_vert_result(c, vert, VERT_RESULT_BFC0+i));
- }
-}
-
-
static void do_twoside_color( struct brw_sf_compile *c )
{
+ GLuint i, need_0, need_1;
struct brw_compile *p = c-func;
GLuint backface_conditional = c-key.frontface_ccw ? BRW_CONDITIONAL_G :
BRW_CONDITIONAL_L;
@@ -105,12 +90,14 @@ static void do_twoside_color( struct brw_sf_compile *c )
if (c-key.primitive == SF_UNFILLED_TRIS)
return;
- /* XXX: What happens if BFC isn't present? This could only happen
-* for user-supplied vertex programs, as t_vp_build.c always does
-* the right thing.
+ /* If the vertex shader provides both front and backface color, do
+* the selection. Otherwise the generated code will pick up
+* whichever there is.
*/
- if (!(have_attr(c, VERT_RESULT_COL0) have_attr(c, VERT_RESULT_BFC0))
- !(have_attr(c, VERT_RESULT_COL1) have_attr(c, VERT_RESULT_BFC1)))
+ need_0 = have_attr(c, VERT_RESULT_COL0) have_attr(c, VERT_RESULT_BFC0);
+ need_1 = have_attr(c, VERT_RESULT_COL1) have_attr(c, VERT_RESULT_BFC1);
+
+ if (!need_0 !need_1)
return;
/* Need to use BRW_EXECUTE_4 and also do an 4-wide compare in order
@@ -121,12 +108,15 @@ static void do_twoside_color( struct brw_sf_compile *c )
brw_push_insn_state(p);
brw_CMP(p, vec4(brw_null_reg()), backface_conditional, c-det,
brw_imm_f(0));
brw_IF(p, BRW_EXECUTE_4);
- {
- switch (c-nr_verts) {
- case 3: copy_bfc(c, c-vert[2]);
- case 2: copy_bfc(c, c-vert[1]);
- case 1: copy_bfc(c, c-vert[0]);
- }
+ for (i=0; ic-nr_verts; i++) {
+ if (need_0)
+brw_MOV(p,
+get_vert_result(c, c-vert[i], VERT_RESULT_COL0),
+get_vert_result(c, c-vert[i], VERT_RESULT_BFC0));
+ if (need_1)
+brw_MOV(p,
+get_vert_result(c, c-vert[i], VERT_RESULT_COL1),
+get_vert_result(c, c-vert[i], VERT_RESULT_BFC1));
}
brw_ENDIF(p);
brw_pop_insn_state(p);
@@ -139,20 +129,27 @@ static void do_twoside_color( struct brw_sf_compile *c )
*/
#define VERT_RESULT_COLOR_BITS (BITFIELD64_BIT(VERT_RESULT_COL0) | \
- BITFIELD64_BIT(VERT_RESULT_COL1))
+BITFIELD64_BIT(VERT_RESULT_COL1))
static void copy_colors( struct brw_sf_compile *c,
struct brw_reg dst,
-struct brw_reg src)
+ struct brw_reg src,
+ int allow_twoside)
{
struct brw_compile *p = c-func;
GLuint i;
for (i = VERT_RESULT_COL0; i = VERT_RESULT_COL1; i++) {
- if (have_attr(c,i))
+ if (have_attr(c,i)) {
brw_MOV(p,
get_vert_result(c, dst, i),
get_vert_result(c, src, i));
+
+ } else if(allow_twoside have_attr(c, i - VERT_RESULT_COL0 +
VERT_RESULT_BFC0)) {
+brw_MOV(p,
+get_vert_result(c, dst, i - VERT_RESULT_COL0 +
VERT_RESULT_BFC0),
+get_vert_result(c, src, i - VERT_RESULT_COL0 +
VERT_RESULT_BFC0));
+ }
}
}
@@ -167,9 +164,19 @@ static void do_flatshade_triangle( struct brw_sf_compile
*c )
struct brw_compile *p = c-func;
struct intel_context *intel = p-brw-intel;
struct brw_reg ip = brw_ip_reg();
- GLuint nr = _mesa_bitcount_64(c-key.attrs VERT_RESULT_COLOR_BITS);
GLuint jmpi = 1;
+ GLuint nr;
+
+ if (c-key.do_twoside_color) {
+ nr = ((c-key.attrs (BITFIELD64_BIT(VERT_RESULT_COL0) |
BITFIELD64_BIT(VERT_RESULT_BFC0))) != 0) +
+ ((c-key.attrs (BITFIELD64_BIT(VERT_RESULT_COL1) |
BITFIELD64_BIT(VERT_RESULT_BFC1))) != 0);
+
+ } else {
+ nr = ((c-key.attrs BITFIELD64_BIT(VERT_RESULT_COL0)) != 0) +
+ ((c-key.attrs BITFIELD64_BIT(VERT_RESULT_COL1)) != 0);
+ }
+
if (!nr)
return;
@@ -186,16 +193,16 @@ static void do_flatshade_triangle( struct brw_sf_compile
*c )
brw_MUL(p, c-pv, c-pv,
[Mesa-dev] [PATCH 3/9] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE selection.
Previous code only selected two side in pure fixed-function setups.
This version also activates it when needed with shaders programs.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_sf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 23a874a..791210f 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -192,7 +192,7 @@ brw_upload_sf_prog(struct brw_context *brw)
/* _NEW_LIGHT */
key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
- key.do_twoside_color = (ctx-Light.Enabled ctx-Light.Model.TwoSide);
+ key.do_twoside_color = ctx-VertexProgram._TwoSideEnabled;
/* _NEW_POLYGON */
if (key.do_twoside_color) {
--
1.7.10.280.gaa39
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one one color is written to.
Shaders, piglit test ones in particular, may write only to one of
gl_FrontColor/gl_BackColor. The standard is unclear on whether the
behaviour is defined in that case, but it seems reasonable to support
it.
The choice done there to pick up whichever color was actually written
to. That makes most of the generated piglit tests useless to test the
backface selection, but it's simple and it works.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 +
src/mesa/drivers/dri/i965/brw_wm_pass2.c |9 +
2 files changed, 18 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3f98137..3b62952 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -972,6 +972,15 @@ fs_visitor::calculate_urb_setup()
if (c-key.vp_outputs_written BITFIELD64_BIT(i)) {
int fp_index = _mesa_vert_result_to_frag_attrib((gl_vert_result) i);
+/* Special case: two-sided vertex option, vertex program
+ * only writes to the back color. Map it to the
+ * associated front color location.
+ */
+if (i = VERT_RESULT_BFC0 i = VERT_RESULT_BFC1
+ctx-VertexProgram._TwoSideEnabled
+urb_setup[i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0] == -1)
+ fp_index = i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
+
/* The back color slot is skipped when the front color is
* also written to. In addition, some slots can be
* written in the vertex shader and not read in the
diff --git a/src/mesa/drivers/dri/i965/brw_wm_pass2.c
b/src/mesa/drivers/dri/i965/brw_wm_pass2.c
index eacf7c0..48143f3 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_pass2.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_pass2.c
@@ -96,6 +96,15 @@ static void init_registers( struct brw_wm_compile *c )
if (c-key.vp_outputs_written BITFIELD64_BIT(j)) {
int fp_index = _mesa_vert_result_to_frag_attrib(j);
+/* Special case: two-sided vertex option, vertex program
+ * only writes to the back color. Map it to the
+ * associated front color location.
+ */
+if (j = VERT_RESULT_BFC0 j = VERT_RESULT_BFC1
+intel-ctx.VertexProgram._TwoSideEnabled
+!(c-key.vp_outputs_written BITFIELD64_BIT(j -
VERT_RESULT_BFC0 + VERT_RESULT_COL0)))
+ fp_index = j - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
+
nr_interp_regs++;
/* The back color slot is skipped when the front color is
--
1.7.10.280.gaa39
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/9] intel gen4-5: Compute the interpolation status for every variable in one place.
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c| 90 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965/brw_context.h | 11
src/mesa/drivers/dri/i965/brw_sf.c |5 +-
src/mesa/drivers/dri/i965/brw_sf.h |1 +
src/mesa/drivers/dri/i965/brw_wm.c |2 +
src/mesa/drivers/dri/i965/brw_wm.h |1 +
7 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index d411208..b4a2e0a 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -47,6 +47,86 @@
#define FRONT_UNFILLED_BIT 0x1
#define BACK_UNFILLED_BIT 0x2
+/**
+ * Lookup the interpolation mode information for every element in the
+ * vue.
+ */
+static void
+brw_lookup_interpolation(struct brw_context *brw)
+{
+ /* pprog means previous program, i.e. the last program before the
+* fragment shader. It can only be the vertex shader for now, but
+* it may be a geometry shader in the future.
+*/
+ const struct gl_program *pprog = brw-vertex_program-Base;
+ const struct gl_fragment_program *fprog = brw-fragment_program;
+ struct brw_vue_map *vue_map = brw-vs.prog_data-vue_map;
+
+ /* Default everything to INTERP_QUALIFIER_NONE */
+ memset(brw-interpolation_mode, INTERP_QUALIFIER_NONE, BRW_VERT_RESULT_MAX);
+
+ /* If there is no fragment shader, interpolation won't be needed,
+* so defaulting to none is good.
+*/
+ if (!fprog)
+ return;
+
+ for (int i = 0; i vue_map-num_slots; i++) {
+ /* First lookup the vert result, skip if there isn't one */
+ int vert_result = vue_map-slot_to_vert_result[i];
+ if (vert_result == BRW_VERT_RESULT_MAX)
+ continue;
+
+ /* HPOS is special. In the clipper, it is handled specifically,
+ * so its value is irrelevant. In the sf, it's forced to
+ * linear. In the wm, it's special cased, irrelevant again. So
+ * force linear to remove the sf special case.
+ */
+ if (vert_result == VERT_RESULT_HPOS) {
+ brw-interpolation_mode[i] = INTERP_QUALIFIER_NOPERSPECTIVE;
+ continue;
+ }
+
+ /* There is a 1-1 mapping of vert result to frag attrib except
+ * for BackColor and vars
+ */
+ int frag_attrib = vert_result;
+ if (vert_result = VERT_RESULT_BFC0 vert_result = VERT_RESULT_BFC1)
+ frag_attrib = vert_result - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
+ else if(vert_result = VERT_RESULT_VAR0)
+ frag_attrib = vert_result - VERT_RESULT_VAR0 + FRAG_ATTRIB_VAR0;
+
+ /* If the output is not used by the fragment shader, skip it. */
+ if (!(fprog-Base.InputsRead BITFIELD64_BIT(frag_attrib)))
+ continue;
+
+ /* Lookup the interpolation mode */
+ enum glsl_interp_qualifier interpolation_mode =
fprog-InterpQualifier[frag_attrib];
+
+ /* If the mode is not specified, then the default varies. Color
+ * values follow the shader model, while all the rest uses
+ * smooth.
+ */
+ if (interpolation_mode == INTERP_QUALIFIER_NONE) {
+ if (frag_attrib = FRAG_ATTRIB_COL0 frag_attrib =
FRAG_ATTRIB_COL1)
+interpolation_mode = brw-intel.ctx.Light.ShadeModel == GL_FLAT ?
INTERP_QUALIFIER_FLAT : INTERP_QUALIFIER_SMOOTH;
+ else
+interpolation_mode = INTERP_QUALIFIER_SMOOTH;
+ }
+
+ /* Finally, if we have both a front color and a back color for
+ * the same channel, the selection will be done before
+ * interpolation and the back color copied over the front color
+ * if necessary. So interpolating the back color is
+ * unnecessary.
+ */
+ if (vert_result = VERT_RESULT_BFC0 vert_result = VERT_RESULT_BFC1)
+ if (pprog-OutputsWritten BITFIELD64_BIT(vert_result -
VERT_RESULT_BFC0 + VERT_RESULT_COL0))
+interpolation_mode = INTERP_QUALIFIER_NONE;
+
+ brw-interpolation_mode[i] = interpolation_mode;
+ }
+}
static void compile_clip_prog( struct brw_context *brw,
struct brw_clip_prog_key *key )
@@ -143,6 +223,10 @@ brw_upload_clip_prog(struct brw_context *brw)
/* Populate the key:
*/
+
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ brw_lookup_interpolation(brw);
+
/* BRW_NEW_REDUCED_PRIMITIVE */
key.primitive = brw-intel.reduced_primitive;
/* CACHE_NEW_VS_PROG (also part of VUE map) */
@@ -150,6 +234,10 @@ brw_upload_clip_prog(struct brw_context *brw)
/* _NEW_LIGHT */
key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
+
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX);
[Mesa-dev] [PATCH 6/9] intel gen4-5: Correctly setup the parameters in the sf.
This patch also correct a couple of problems with noperspective
interpolation.
At that point all the glsl 1.1/1.3 interpolation tests that do not
clip pass (the -none ones).
The fs code does not use the pre-resolved interpolation modes in order
not to mess with gen6+. Sharing the resolution would require putting
brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
thing, but it could have unexpected consequences, so it's better be
done independently in any case.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 15 +++
src/mesa/drivers/dri/i965/brw_sf.c | 12 +-
src/mesa/drivers/dri/i965/brw_sf.h |2 +-
src/mesa/drivers/dri/i965/brw_sf_emit.c | 164 +-
5 files changed, 106 insertions(+), 89 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3b62952..4734a5d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -757,7 +757,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
inst-predicated = true;
inst-predicate_inverse = true;
}
- if (intel-gen 6) {
+ if (intel-gen 6 interpolation_mode ==
INTERP_QUALIFIER_SMOOTH) {
emit(BRW_OPCODE_MUL, attr, attr, this-pixel_w);
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 08c0130..c6dc265 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1872,6 +1872,21 @@ fs_visitor::emit_interpolation_setup_gen4()
emit(BRW_OPCODE_ADD, this-delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC],
this-pixel_y, fs_reg(negate(brw_vec1_grf(1, 1;
+ /*
+* On Gen4-5, we accomplish perspective-correct interpolation by
+* dividing the attribute values by w in the sf shader,
+* interpolating the result linearly in screen space, and then
+* multiplying by w in the fragment shader. So the interpolation
+* step is always linear in screen space, regardless of whether the
+* attribute is perspective or non-perspective. Accordingly, we
+* use the same delta_x and delta_y values for both kinds of
+* interpolation.
+*/
+ this-delta_x[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
+ this-delta_x[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
+ this-delta_y[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
+ this-delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
+
this-current_annotation = compute pos.w and 1/pos.w;
/* Compute wpos.w. It's always in our setup, since it's needed to
* interpolate the other attributes.
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 26cbaf7..c00e85a 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -139,6 +139,7 @@ brw_upload_sf_prog(struct brw_context *brw)
struct brw_sf_prog_key key;
/* _NEW_BUFFERS */
bool render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer);
+ int i;
memset(key, 0, sizeof(key));
@@ -190,11 +191,16 @@ brw_upload_sf_prog(struct brw_context *brw)
if ((ctx-Point.SpriteOrigin == GL_LOWER_LEFT) != render_to_fbo)
key.sprite_origin_lower_left = true;
- /* _NEW_LIGHT */
- key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ key.has_flat_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw-interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+ }
+ }
key.do_twoside_color = ctx-VertexProgram._TwoSideEnabled;
- /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX);
/* _NEW_POLYGON */
diff --git a/src/mesa/drivers/dri/i965/brw_sf.h
b/src/mesa/drivers/dri/i965/brw_sf.h
index 5e261fb..47fdb3e 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.h
+++ b/src/mesa/drivers/dri/i965/brw_sf.h
@@ -50,7 +50,7 @@ struct brw_sf_prog_key {
uint8_t point_sprite_coord_replace;
GLuint primitive:2;
GLuint do_twoside_color:1;
- GLuint do_flat_shading:1;
+ GLuint has_flat_shading:1;
GLuint frontface_ccw:1;
GLuint do_point_sprite:1;
GLuint do_point_coord:1;
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index 9d8aa38..c99578a 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
@@ -44,6 +44,17 @@
/**
+ * Determine the vue slot corresponding to the given half of the given
+ * register. half=0 means the first half of a register, half=1 means the
+ * second half.
+
[Mesa-dev] [PATCH 7/9] intel gen4-5: Correctly handle flat vs. non-flat in the clipper.
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_clip.c | 13 --
src/mesa/drivers/dri/i965/brw_clip.h |6 +--
src/mesa/drivers/dri/i965/brw_clip_line.c |6 +--
src/mesa/drivers/dri/i965/brw_clip_tri.c | 20 -
src/mesa/drivers/dri/i965/brw_clip_unfilled.c |2 +-
src/mesa/drivers/dri/i965/brw_clip_util.c | 56 +++--
src/mesa/drivers/dri/i965/brw_sf_emit.c |8
7 files changed, 50 insertions(+), 61 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index b4a2e0a..8512172 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -218,7 +218,7 @@ brw_upload_clip_prog(struct brw_context *brw)
struct intel_context *intel = brw-intel;
struct gl_context *ctx = intel-ctx;
struct brw_clip_prog_key key;
-
+ int i;
memset(key, 0, sizeof(key));
/* Populate the key:
@@ -231,11 +231,16 @@ brw_upload_clip_prog(struct brw_context *brw)
key.primitive = brw-intel.reduced_primitive;
/* CACHE_NEW_VS_PROG (also part of VUE map) */
key.attrs = brw-vs.prog_data-outputs_written;
- /* _NEW_LIGHT */
- key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ key.has_flat_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw-interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+ }
+ }
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
- /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX);
/* _NEW_TRANSFORM (also part of VUE map)*/
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index e78d074..3ad2e13 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -46,7 +46,7 @@ struct brw_clip_prog_key {
unsigned char interpolation_mode[BRW_VERT_RESULT_MAX]; /* copy of the main
context */
GLuint primitive:4;
GLuint nr_userclip:4;
- GLuint do_flat_shading:1;
+ GLuint has_flat_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2; /* includes cull information */
@@ -166,8 +166,8 @@ void brw_clip_kill_thread(struct brw_clip_compile *c);
struct brw_reg brw_clip_plane_stride( struct brw_clip_compile *c );
struct brw_reg brw_clip_plane0_address( struct brw_clip_compile *c );
-void brw_clip_copy_colors( struct brw_clip_compile *c,
- GLuint to, GLuint from );
+void brw_clip_copy_flatshaded_attributes( struct brw_clip_compile *c,
+ GLuint to, GLuint from );
void brw_clip_init_clipmask( struct brw_clip_compile *c );
diff --git a/src/mesa/drivers/dri/i965/brw_clip_line.c
b/src/mesa/drivers/dri/i965/brw_clip_line.c
index 6cf2bd2..729d8c0 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_line.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_line.c
@@ -271,11 +271,11 @@ void brw_emit_line_clip( struct brw_clip_compile *c )
brw_clip_line_alloc_regs(c);
brw_clip_init_ff_sync(c);
- if (c-key.do_flat_shading) {
+ if (c-key.has_flat_shading) {
if (c-key.pv_first)
- brw_clip_copy_colors(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
else
- brw_clip_copy_colors(c, 0, 1);
+ brw_clip_copy_flatshaded_attributes(c, 0, 1);
}
clip_and_emit_line(c);
diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c
b/src/mesa/drivers/dri/i965/brw_clip_tri.c
index a29f8e0..71225f5 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_tri.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c
@@ -187,8 +187,8 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
brw_IF(p, BRW_EXECUTE_1);
{
- brw_clip_copy_colors(c, 1, 0);
- brw_clip_copy_colors(c, 2, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 2, 0);
}
brw_ELSE(p);
{
@@ -200,19 +200,19 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
brw_imm_ud(_3DPRIM_TRIFAN));
brw_IF(p, BRW_EXECUTE_1);
{
- brw_clip_copy_colors(c, 0, 1);
- brw_clip_copy_colors(c, 2, 1);
+ brw_clip_copy_flatshaded_attributes(c, 0, 1);
+ brw_clip_copy_flatshaded_attributes(c, 2, 1);
}
brw_ELSE(p);
{
- brw_clip_copy_colors(c, 1, 0);
- brw_clip_copy_colors(c, 2, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 2, 0);
}
[Mesa-dev] [PATCH 8/9] intel gen4-5: Make noperspective clipping work.
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri/i965/brw_clip_util.c | 147 ++---
3 files changed, 146 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 8512172..eca2844 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -239,6 +239,15 @@ brw_upload_clip_prog(struct brw_context *brw)
break;
}
}
+ key.has_noperspective_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw-interpolation_mode[i] == INTERP_QUALIFIER_NOPERSPECTIVE
+ brw-vs.prog_data-vue_map.slot_to_vert_result[i] !=
VERT_RESULT_HPOS) {
+ key.has_noperspective_shading = 1;
+ break;
+ }
+ }
+
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX);
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index 3ad2e13..66dd928 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -47,6 +47,7 @@ struct brw_clip_prog_key {
GLuint primitive:4;
GLuint nr_userclip:4;
GLuint has_flat_shading:1;
+ GLuint has_noperspective_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2; /* includes cull information */
diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c
b/src/mesa/drivers/dri/i965/brw_clip_util.c
index 692573e..b06ad1d 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -129,6 +129,8 @@ static void brw_clip_project_vertex( struct
brw_clip_compile *c,
/* Interpolate between two vertices and put the result into a0.0.
* Increment a0.0 accordingly.
+ *
+ * Beware that dest_ptr can be equal to v0_ptr.
*/
void brw_clip_interp_vertex( struct brw_clip_compile *c,
struct brw_indirect dest_ptr,
@@ -138,7 +140,8 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
bool force_edgeflag)
{
struct brw_compile *p = c-func;
- struct brw_reg tmp = get_tmp(c);
+ struct brw_context *brw = p-brw;
+ struct brw_reg t_nopersp, v0_ndc_copy;
GLuint slot;
/* Just copy the vertex header:
@@ -148,13 +151,130 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
* back on Ironlake, so needn't change it
*/
brw_copy_indirect_to_indirect(p, dest_ptr, v0_ptr, 1);
-
- /* Iterate over each attribute (could be done in pairs?)
+
+ /*
+* First handle the 3D and NDC positioning, in case we need
+* noperspective interpolation. Doing it early has no performance
+* impact in any case.
+*/
+
+ /* Start by picking up the v0 NDC coordinates, because that vertex
+* may be shared with the destination.
+*/
+ if (c-key.has_noperspective_shading) {
+ GLuint offset = brw_vert_result_to_offset(c-vue_map,
+BRW_VERT_RESULT_NDC);
+ v0_ndc_copy = get_tmp(c);
+ brw_MOV(p, v0_ndc_copy, deref_4f(v0_ptr, offset));
+ }
+
+ /*
+* Compute the new 3D position
+*
+* dest_hpos = v0_hpos * (1 - t0) + v1_hpos * t0
+*/
+ {
+ GLuint delta = brw_vert_result_to_offset(c-vue_map, VERT_RESULT_HPOS);
+ struct brw_reg tmp = get_tmp(c);
+ brw_MUL(p,
+ vec4(brw_null_reg()),
+ deref_4f(v1_ptr, delta),
+ t0);
+
+ brw_MAC(p,
+ tmp,
+ negate(deref_4f(v0_ptr, delta)),
+ t0);
+
+ brw_ADD(p,
+ deref_4f(dest_ptr, delta),
+ deref_4f(v0_ptr, delta),
+ tmp);
+ release_tmp(c, tmp);
+ }
+
+ /* Then recreate the projected (NDC) coordinate in the new vertex
+* header
+*/
+ brw_clip_project_vertex(c, dest_ptr);
+
+ /*
+* If we have noperspective attributes, we now need to compute the
+* screen-space t.
+*/
+ if (c-key.has_noperspective_shading) {
+ GLuint delta = brw_vert_result_to_offset(c-vue_map,
BRW_VERT_RESULT_NDC);
+ struct brw_reg tmp = get_tmp(c);
+ t_nopersp = get_tmp(c);
+
+ /* Build a register with coordinates from the second and new vertices
+ *
+ * t_nopersp = vec4(v1.xy, dest.xy)
+ */
+ brw_MOV(p, t_nopersp, deref_4f(v1_ptr, delta));
+ brw_MOV(p, tmp, deref_4f(dest_ptr, delta));
+ brw_set_access_mode(p, BRW_ALIGN_16);
+ brw_MOV(p,
+ brw_writemask(t_nopersp, WRITEMASK_ZW),
+ brw_swizzle(tmp, 0,1,0,1));
+
+ /* Subtract the coordinates of the first
[Mesa-dev] [PATCH 9/9] intel gen4-5: Don't touch flatshaded values when clipping, only copy them.
This patch ensures that integers will pass through unscathed. Doing
(useless) computations on them is risky, especially when their bit
patterns correspond to values like inf or nan.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip_util.c | 48 ++---
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c
b/src/mesa/drivers/dri/i965/brw_clip_util.c
index b06ad1d..998c304 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -293,30 +293,42 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
* header), so interpolate:
*
*New = attr0 + t*attr1 - t*attr0
+ *
+ * unless it's flat shaded, then just copy the value from a
+ * source vertex.
*/
- struct brw_reg tmp = get_tmp(c);
+ GLuint interp = brw-interpolation_mode[slot];
- struct brw_reg t =
-brw-interpolation_mode[slot] == INTERP_QUALIFIER_NOPERSPECTIVE ?
-t_nopersp : t0;
+ if(interp == INTERP_QUALIFIER_SMOOTH ||
+interp == INTERP_QUALIFIER_NOPERSPECTIVE) {
+struct brw_reg tmp = get_tmp(c);
+struct brw_reg t =
+ interp == INTERP_QUALIFIER_NOPERSPECTIVE ?
+ t_nopersp : t0;
-brw_MUL(p,
-vec4(brw_null_reg()),
-deref_4f(v1_ptr, delta),
-t);
+brw_MUL(p,
+vec4(brw_null_reg()),
+deref_4f(v1_ptr, delta),
+t);
-brw_MAC(p,
-tmp,
-negate(deref_4f(v0_ptr, delta)),
-t);
+brw_MAC(p,
+tmp,
+negate(deref_4f(v0_ptr, delta)),
+t);
-brw_ADD(p,
-deref_4f(dest_ptr, delta),
-deref_4f(v0_ptr, delta),
-tmp);
-
- release_tmp(c, tmp);
+brw_ADD(p,
+deref_4f(dest_ptr, delta),
+deref_4f(v0_ptr, delta),
+tmp);
+
+release_tmp(c, tmp);
+
+ } else if(interp == INTERP_QUALIFIER_FLAT) {
+brw_MOV(p,
+deref_4f(dest_ptr, delta),
+deref_4f(v0_ptr, delta));
+ }
}
}
--
1.7.10.280.gaa39
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): gallium-egl: Implement eglQueryWaylandBufferWL
On Thu, Jul 19, 2012 at 3:26 PM, Kristian Høgsberg k...@bitplanet.net wrote: On Thu, Jul 19, 2012 at 2:44 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - This commit is causing build failures in several platforms because EGL_WL_bind_wayland_display is defined everywhere (including windows), and not just on platforms where wayland-drm.h exists. Yes, I see the problem, I'm fixing it now. I'm using the wayland_bufmgr that is already in place now, so it should work as well as before. Kristian Should be fixed in mesa master now. Kristian Actually it is more subtle. On scons + cross mingw it fails as: Compiling src/gallium/state_trackers/egl/common/egl_g3d_api.c ... src/gallium/state_trackers/egl/common/egl_g3d_api.c:43:25: fatal error: wayland-drm.h: No such file or directory On autoconf on ubuntu64 it fails with: gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/egl/main -I../../../../src/egl/wayland/wayland-drm/ -I../../../../include -DHAVE_X11_BACKEND -D_GNU_SOURCE -DPTHREADS -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_LLVM=0x0301 -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC -D_GNU_SOURCE -DPTHREADS -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_LLVM=0x0301 -fvisibility=hidden common/egl_g3d_api.c -o common/egl_g3d_api.o In file included from common/egl_g3d_api.c:43:0: ../../../../src/egl/wayland/wayland-drm/wayland-drm.h:4:28: fatal error: wayland-server.h: No such file or directory Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Prevent repeated glDeleteShader() from blowing away our refcounts.
Calling glDeleteShader() should mark shaders as pending for deletion,
but shouldn't decrement the refcount every time. Otherwise, repeated
glDeleteShader() is not safe.
This is particularly bad since glDeleteProgram() frees shaders: if you
first call glDeleteShader() on the shaders attached to the program (thus
decrementing the refcount), then called glDeleteProgram(), it would try
to free them again (decrementing the refcount another time), causing
a refcount 0 assertion to fail.
Similar to commit d950a778.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/shaderapi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 6927368..7c97a63 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -346,10 +346,12 @@ delete_shader(struct gl_context *ctx, GLuint shader)
if (!sh)
return;
- sh-DeletePending = GL_TRUE;
+ if (!sh-DeletePending) {
+ sh-DeletePending = GL_TRUE;
- /* effectively, decr sh's refcount */
- _mesa_reference_shader(ctx, sh, NULL);
+ /* effectively, decr sh's refcount */
+ _mesa_reference_shader(ctx, sh, NULL);
+ }
}
--
1.7.11.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Set gl_fragment_program::UsesKill in do_set_program_inouts.
Paul Berry stereotype...@gmail.com writes: Previously, the code for setting this flag for GLSL programs was duplicated in three places: brw_link_shader(), glsl_to_tgsi_visitor, and ir_to_mesa_visitor. In addition to the unnecessary duplication, there was a performance problem on i965: brw_link_shader() set the flag before doing its final round of optimizations, which meant that if the optimizations managed to eliminate all the discard operations, the flag would still be set, resulting (at least in theory) in slower performance. This patch consolidates all of the code that sets UsesKill for GLSL programs into do_set_program_inouts(), which already is doing a similar job for UsesDFdy, and which occurs after i965's final round of optimizations. Non-GLSL programs (ARB programs and the state tracker's glBitmap program) are unaffected. This series is: Reviewed-by: Eric Anholt e...@anholt.net pgpcn42WT4mjT.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 1/7] i965: Add support for AVG instruction.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote:
From the Ivy Bridge PRM, Vol4 Part3 p152:
The avg instruction performs component-wise integer average of
src0 and src1 and stores the results in dst. An integer average
uses integer upward rounding. It is equivalent to increment one to
the addition of src0 and src1 and then apply an arithmetic right
shift to this intermediate value.
---
src/mesa/drivers/dri/i965/brw_eu.h |1 +
src/mesa/drivers/dri/i965/brw_eu_emit.c | 22 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h
b/src/mesa/drivers/dri/i965/brw_eu.h
index f25b09d..233b94c 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -861,6 +861,7 @@ ALU2(RSL)
ALU2(ASR)
ALU2(JMPI)
ALU2(ADD)
+ALU2(AVG)
ALU2(MUL)
ALU1(FRC)
ALU1(RNDD)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 8de872e..93e84ae 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -929,6 +929,28 @@ struct brw_instruction *brw_ADD(struct brw_compile
*p,
return brw_alu2(p, BRW_OPCODE_ADD, dest, src0, src1);
}
+struct brw_instruction *brw_AVG(struct brw_compile *p,
+struct brw_reg dest,
+struct brw_reg src0,
+struct brw_reg src1)
+{
+ assert(dest.type == src0.type);
+ assert(src0.type == src1.type);
+ switch (src0.type) {
+ case BRW_REGISTER_TYPE_B:
+ case BRW_REGISTER_TYPE_UB:
+ case BRW_REGISTER_TYPE_W:
+ case BRW_REGISTER_TYPE_UW:
+ case BRW_REGISTER_TYPE_D:
+ case BRW_REGISTER_TYPE_UD:
+ break;
+ default:
+ assert(!Bad type for brw_AVG);
+ }
+
+ return brw_alu2(p, BRW_OPCODE_AVG, dest, src0, src1);
+}
+
struct brw_instruction *brw_MUL(struct brw_compile *p,
struct brw_reg dest,
struct brw_reg src0,
--
1.7.7.6
This patch is
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Prevent repeated glDeleteShader() from blowing away our refcounts.
On 07/19/2012 02:41 PM, Kenneth Graunke wrote:
Calling glDeleteShader() should mark shaders as pending for deletion,
but shouldn't decrement the refcount every time. Otherwise, repeated
glDeleteShader() is not safe.
This is particularly bad since glDeleteProgram() frees shaders: if you
first call glDeleteShader() on the shaders attached to the program (thus
decrementing the refcount), then called glDeleteProgram(), it would try
to free them again (decrementing the refcount another time), causing
a refcount 0 assertion to fail.
Similar to commit d950a778.
Candidate for the 8.0 branch?
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/main/shaderapi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 6927368..7c97a63 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -346,10 +346,12 @@ delete_shader(struct gl_context *ctx, GLuint shader)
if (!sh)
return;
- sh-DeletePending = GL_TRUE;
+ if (!sh-DeletePending) {
+ sh-DeletePending = GL_TRUE;
- /* effectively, decr sh's refcount */
- _mesa_reference_shader(ctx,sh, NULL);
+ /* effectively, decr sh's refcount */
+ _mesa_reference_shader(ctx,sh, NULL);
+ }
}
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
I have these issues with the patch: 1) On GPUs without a vertex cache, you flush the texture cache every draw operation. Are you kidding? 2) All colorbuffers / streamout buffers are flushed, even those which are not enabled. E.g. instead of flushing only CB0 when there is only one, this code flushes all of them. Why? This either needs an explanation or it should only flush the buffers which are enabled (like the old code did). 3) Please explain: - why you added PS_PARTIAL_FLUSH in r600_texture_barrier and r600_set_framebuffer_state. - why you added CACHE_FLUSH_AND_INV_EVENT in set_framebuffer_state for R700 and evergreen. - why you applied the CB flush workarounds meant for RV6xx to all R600 and R700 chipsets. - why the streamout workaround for RV6xx (S_0085F0_DEST_BASE_0_ENA) is applied to all R600, R700, and evergreen chipsets. - why R600_CONTEXT_FLUSH_AND_INV emits SURFACE_SYNC on evergreen, resulting in emission of SURFACE_SYNC twice in a row in most situations. Flushing has always worked without all the changes (1, 2, 3) mentioned above, so please if you don't have a reasonable explanation, revert to the old behavior. 4) R600_CONTEXT_DRAW_FLUSH is a misleading name. Please rename it to R600_CONTEXT_PS_PARTIAL_FLUSH. Also, FLUSH_AND_INV_DB_META should be prefixed with EVENT_TYPE_. Overall, the idea of simplifying flushing is good, but the result looks worse than what is in master already and it generally adds more work for the hardware. Also, the title is misleading. The patch doesn't fix flushing in general, because there was nothing wrong with it in the first place. Except maybe hyperz, which is almost unrelated to what the patch tries to achieve. Marek On Tue, Jul 17, 2012 at 7:58 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Flushing and synchronization only need to happen at begining and end of cs, and after each draw packet if necessary. This patch is especialy needed for hyperz/htile feature. v2: Separate evergreen and r6xx/r7xx flushing/syncing allow easier specialization of each functions. Fix r6xx/r7xx regression. Signed-off-by: Jerome Glisse jgli...@redhat.com --- src/gallium/drivers/r600/evergreen_compute.c | 23 +-- .../drivers/r600/evergreen_compute_internal.c |4 +- src/gallium/drivers/r600/evergreen_hw_context.c| 110 ++- src/gallium/drivers/r600/evergreen_state.c | 14 +- src/gallium/drivers/r600/evergreend.h |3 +- src/gallium/drivers/r600/r600.h| 19 +- src/gallium/drivers/r600/r600_buffer.c |2 +- src/gallium/drivers/r600/r600_hw_context.c | 203 src/gallium/drivers/r600/r600_hw_context_priv.h|3 +- src/gallium/drivers/r600/r600_pipe.c |2 - src/gallium/drivers/r600/r600_pipe.h |6 +- src/gallium/drivers/r600/r600_state.c | 23 +-- src/gallium/drivers/r600/r600_state_common.c | 68 ++- 13 files changed, 297 insertions(+), 183 deletions(-) diff --git a/src/gallium/drivers/r600/evergreen_compute.c b/src/gallium/drivers/r600/evergreen_compute.c index 947a328..37c3395 100644 --- a/src/gallium/drivers/r600/evergreen_compute.c +++ b/src/gallium/drivers/r600/evergreen_compute.c @@ -96,7 +96,7 @@ static void evergreen_cs_set_vertex_buffer( vb-buffer = buffer; vb-user_buffer = NULL; - r600_inval_vertex_cache(rctx); + rctx-flags |= R600_CONTEXT_VTX_FLUSH; state-dirty_mask |= 1 vb_index; r600_atom_dirty(rctx, state-atom); } @@ -208,8 +208,7 @@ static void evergreen_bind_compute_state(struct pipe_context *ctx_, void *state) res-usage = RADEON_USAGE_READ; res-coher_bo_size = ctx-cs_shader-bc.ndw*4; - r600_inval_shader_cache(ctx); - + ctx-flags |= R600_CONTEXT_SH_FLUSH; } /* The kernel parameters are stored a vtx buffer (ID=0), besides the explicit @@ -364,8 +363,11 @@ static void compute_emit_cs(struct r600_context *ctx) */ r600_emit_atom(ctx, ctx-start_compute_cs_cmd.atom); + ctx-flags |= R600_CONTEXT_CB_FLUSH; + r600_flush_emit(ctx); + /* Emit cb_state */ -cb_state = ctx-states[R600_PIPE_STATE_FRAMEBUFFER]; + cb_state = ctx-states[R600_PIPE_STATE_FRAMEBUFFER]; r600_context_pipe_state_emit(ctx, cb_state, RADEON_CP_PACKET3_COMPUTE_MODE); /* Emit vertex buffer state */ @@ -405,15 +407,8 @@ static void compute_emit_cs(struct r600_context *ctx) } } - /* r600_flush_framebuffer() updates the cb_flush_flags and then -* calls r600_emit_atom() on the ctx-surface_sync_cmd.atom, which emits -* a SURFACE_SYNC packet via r600_emit_surface_sync(). -* -* XXX r600_emit_surface_sync() hardcodes the CP_COHER_SIZE to -* 0x, so we will need to add a field to struct -*
[Mesa-dev] [Bug 38970] [bisected]piglit glx/glx-pixmap-multi failed
https://bugs.freedesktop.org/show_bug.cgi?id=38970 ajax at nwnk dot net a...@nwnk.net changed: What|Removed |Added AssignedTo|a...@nwnk.net |xunx.f...@intel.com --- Comment #18 from ajax at nwnk dot net a...@nwnk.net 2012-07-19 22:37:00 PDT --- I'm not working on this issue, reassigning back to Intel. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mapi: use a path prefix for sources variable
This makes it possible to share sources.mak with the Android build again. v2: Keep $(TOP) variable that is actually used by an included Makefile. --- src/mapi/glapi/Makefile.am|5 +++-- src/mapi/mapi/sources.mak | 25 ++--- src/mapi/shared-glapi/Makefile.am |7 +-- 3 files changed, 22 insertions(+), 15 deletions(-) diff --git a/src/mapi/glapi/Makefile.am b/src/mapi/glapi/Makefile.am index 668d7fa..b6c4345 100644 --- a/src/mapi/glapi/Makefile.am +++ b/src/mapi/glapi/Makefile.am @@ -19,9 +19,10 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS # IN THE SOFTWARE. -TOP = $(top_srcdir) include sources.mak -include ../mapi/sources.mak + +MAPI = $(srcdir)/../mapi +include $(MAPI)/sources.mak AM_CPPFLAGS = \ $(DEFINES) \ diff --git a/src/mapi/mapi/sources.mak b/src/mapi/mapi/sources.mak index 56f4afd..6c15170 100644 --- a/src/mapi/mapi/sources.mak +++ b/src/mapi/mapi/sources.mak @@ -13,24 +13,27 @@ # # - In bridge mode, mapi provides entry points calling into glapi. To use #this mode, compile MAPI_BRIDGE_FILES with MAPI_MODE_BRIDGE defined. +# +# The variable $(MAPI) must be defined to point to this source directory +# before the following variables can be used. MAPI_UTIL_FILES = \ - $(TOP)/src/mapi/mapi/u_current.c \ - $(TOP)/src/mapi/mapi/u_execmem.c + $(MAPI)/u_current.c \ + $(MAPI)/u_execmem.c MAPI_FILES = \ - $(TOP)/src/mapi/mapi/entry.c \ - $(TOP)/src/mapi/mapi/mapi.c \ - $(TOP)/src/mapi/mapi/stub.c \ - $(TOP)/src/mapi/mapi/table.c \ + $(MAPI)/entry.c \ + $(MAPI)/mapi.c \ + $(MAPI)/stub.c \ + $(MAPI)/table.c \ $(MAPI_UTIL_FILES) MAPI_GLAPI_FILES = \ - $(TOP)/src/mapi/mapi/entry.c \ - $(TOP)/src/mapi/mapi/mapi_glapi.c \ - $(TOP)/src/mapi/mapi/stub.c \ - $(TOP)/src/mapi/mapi/table.c \ + $(MAPI)/entry.c \ + $(MAPI)/mapi_glapi.c \ + $(MAPI)/stub.c \ + $(MAPI)/table.c \ $(MAPI_UTIL_FILES) MAPI_BRIDGE_FILES = \ - $(TOP)/src/mapi/mapi/entry.c + $(MAPI)/entry.c diff --git a/src/mapi/shared-glapi/Makefile.am b/src/mapi/shared-glapi/Makefile.am index 9485683..de958f6 100644 --- a/src/mapi/shared-glapi/Makefile.am +++ b/src/mapi/shared-glapi/Makefile.am @@ -1,13 +1,16 @@ # Used by OpenGL ES or when --enable-shared-glapi is specified -TOP = $(top_srcdir) GLAPI = $(top_srcdir)/src/mapi/glapi -include $(top_srcdir)/src/mapi/mapi/sources.mak +MAPI = $(top_srcdir)/src/mapi/mapi + +include $(MAPI)/sources.mak lib_LTLIBRARIES = libglapi.la libglapi_la_SOURCES = $(MAPI_GLAPI_FILES) libglapi_la_LDFLAGS = -no-undefined +# FIXME: eliminate the use of $(TOP) +TOP = $(top_srcdir) include $(GLAPI)/gen/glapi_gen.mk glapi_mapi_tmp.h : $(GLAPI)/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps) $(call glapi_gen_mapi,$,shared-glapi) -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] autoconf: add $(TOP_SRCDIR) substitution
Useful while the static Makefiles are still alive. --- configs/current.in |4 +++- configure.ac | 15 ++- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/configs/current.in b/configs/current.in index dc0dea8..ea926d5 100644 --- a/configs/current.in +++ b/configs/current.in @@ -1,7 +1,9 @@ # Autoconf configuration +TOP_SRCDIR = @TOP_SRCDIR@ + # Pull in the defaults -include $(TOP)/configs/default +include $(TOP_SRCDIR)/configs/default # This is generated by configure CONFIG_NAME = autoconf diff --git a/configure.ac b/configure.ac index 1d60957..344d054 100644 --- a/configure.ac +++ b/configure.ac @@ -13,9 +13,22 @@ AC_CANONICAL_HOST AM_INIT_AUTOMAKE([foreign]) dnl http://people.gnome.org/~walters/docs/build-api.txt -dnl We don't support srcdir != builddir. +dnl We don't support srcdir != builddir yet. echo \#buildapi-variable-no-builddir /dev/null +dnl This is for the sake of the static Makefiles until they're +dnl finally gone for good. +TOP_SRCDIR=$srcdir +case $TOP_SRCDIR in +[\\/]*) +dnl Path is already absolute. +;; +*) +TOP_SRCDIR=$ac_pwd/$TOP_SRCDIR +;; +esac +AC_SUBST(TOP_SRCDIR) + # Support silent build rules, requires at least automake-1.11. Disable # by either passing --disable-silent-rules to configure or passing V=1 # to make -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] mapi: drop use of $(TOP)
Use $(TOP_SRCDIR) in the static Makefile, but use a more specific variable for glapi_gen.mk now. --- src/mapi/es1api/Makefile |4 ++-- src/mapi/glapi/gen/glapi_gen.mk | 14 +++--- src/mapi/shared-glapi/Makefile.am |2 -- 3 files changed, 9 insertions(+), 11 deletions(-) diff --git a/src/mapi/es1api/Makefile b/src/mapi/es1api/Makefile index a9c9123..91ae815 100644 --- a/src/mapi/es1api/Makefile +++ b/src/mapi/es1api/Makefile @@ -32,8 +32,8 @@ endif ESAPI = $(ES)api -GLAPI := $(TOP)/src/mapi/glapi -MAPI := $(TOP)/src/mapi/mapi +GLAPI := $(TOP_SRCDIR)/src/mapi/glapi +MAPI := $(TOP_SRCDIR)/src/mapi/mapi esapi_CPPFLAGS := \ -I$(TOP)/include \ diff --git a/src/mapi/glapi/gen/glapi_gen.mk b/src/mapi/glapi/gen/glapi_gen.mk index 1b05a40..fdc7e19 100644 --- a/src/mapi/glapi/gen/glapi_gen.mk +++ b/src/mapi/glapi/gen/glapi_gen.mk @@ -1,14 +1,14 @@ # Helpers for glapi header generation -ifndef TOP -$(error TOP must be defined.) +ifndef GLAPI +$(error GLAPI must be defined to point to src/mapi/glapi) endif glapi_gen_common_deps := \ - $(wildcard $(TOP)/src/mapi/glapi/gen/*.xml) \ - $(wildcard $(TOP)/src/mapi/glapi/gen/*.py) + $(wildcard $(GLAPI)/gen/*.xml) \ + $(wildcard $(GLAPI)/gen/*.py) -glapi_gen_mapi_script := $(TOP)/src/mapi/mapi/mapi_abi.py +glapi_gen_mapi_script := $(GLAPI)/../mapi/mapi_abi.py glapi_gen_mapi_deps := \ $(glapi_gen_mapi_script) \ $(glapi_gen_common_deps) @@ -21,7 +21,7 @@ $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS) $(glapi_gen_mapi_script) \ --mode lib --printer $(2) $(1) $@ endef -glapi_gen_dispatch_script := $(TOP)/src/mapi/glapi/gen/gl_table.py +glapi_gen_dispatch_script := $(GLAPI)/gen/gl_table.py glapi_gen_dispatch_deps := $(glapi_gen_common_deps) # $(1): path to an XML file @@ -32,7 +32,7 @@ $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS) $(glapi_gen_dispatch_script) \ -f $(1) -m remap_table $(if $(2),-c $(2),) $@ endef -glapi_gen_remap_script := $(TOP)/src/mapi/glapi/gen/remap_helper.py +glapi_gen_remap_script := $(GLAPI)/gen/remap_helper.py glapi_gen_remap_deps := $(glapi_gen_common_deps) # $(1): path to an XML file diff --git a/src/mapi/shared-glapi/Makefile.am b/src/mapi/shared-glapi/Makefile.am index de958f6..db68683 100644 --- a/src/mapi/shared-glapi/Makefile.am +++ b/src/mapi/shared-glapi/Makefile.am @@ -9,8 +9,6 @@ lib_LTLIBRARIES = libglapi.la libglapi_la_SOURCES = $(MAPI_GLAPI_FILES) libglapi_la_LDFLAGS = -no-undefined -# FIXME: eliminate the use of $(TOP) -TOP = $(top_srcdir) include $(GLAPI)/gen/glapi_gen.mk glapi_mapi_tmp.h : $(GLAPI)/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps) $(call glapi_gen_mapi,$,shared-glapi) -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/7] i965/blorp: Fix integer downsampling on Gen7.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote:
When downsampling an integer-format buffer on Gen7, we need to use the
avg instruction rather than the add instruction, to ensure that we
don't overflow the range of 32-bit integers. Also, we need to use the
proper register type (BRW_REGISTER_TYPE_D or BRW_REGISTER_TYPE_UD) for
intermediate color data and for writing to the render target.
Note: this patch causes blorp to use the proper register type for all
operations (downsampling, upsampling, and ordinary blits). Strictly
speaking, this is only necessary for downsampling, because the other
operations exclusively use MOV instructions on the color data. But
it's simpler to use the proper register type in all cases.
---
src/mesa/drivers/dri/i965/brw_blorp.h|5 ++
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 61
+-
2 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 053eef7..9af492d 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -223,6 +223,11 @@ struct brw_blorp_blit_prog_key
/* Actual MSAA layout used by the destination image. */
intel_msaa_layout dst_layout;
+ /* Type of the data to be read from the texture (one of
+* BRW_REGISTER_TYPE_{UD,D,F}).
+*/
+ unsigned texture_data_type;
+
/* True if the source image is W tiled. If true, the surface state for
the
* source image must be configured as Y tiled, and tex_samples must be 0.
*/
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 74ae52d..32fd48e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -696,7 +696,9 @@ brw_blorp_blit_program::alloc_regs()
alloc_push_const_regs(reg);
reg += BRW_BLORP_NUM_PUSH_CONST_REGS;
for (unsigned i = 0; i ARRAY_SIZE(texture_data); ++i) {
- this-texture_data[i] = vec16(brw_vec8_grf(reg, 0)); reg += 8;
+ this-texture_data[i] =
+ retype(vec16(brw_vec8_grf(reg, 0)), key-texture_data_type);
+ reg += 8;
}
this-mcs_data =
retype(brw_vec8_grf(reg, 0), BRW_REGISTER_TYPE_UD); reg += 8;
@@ -1117,7 +1119,16 @@ brw_blorp_blit_program::manual_blend()
* operations we do is equal to the number of trailing 1 bits in i. This
* works provided the total number of samples is a power of two, which it
* always is for i965.
+*
+* For integer formats, we replace the add operations with average
+* operations and skip the final division.
*/
+ typedef struct brw_instruction *(*brw_op2_ptr)(struct brw_compile *,
+ struct brw_reg,
+ struct brw_reg,
+ struct brw_reg);
+ brw_op2_ptr combine_op =
+ key-texture_data_type == BRW_REGISTER_TYPE_F ? brw_ADD : brw_AVG;
unsigned stack_depth = 0;
for (int i = 0; i num_samples; ++i) {
assert(stack_depth == _mesa_bitcount(i)); /* Loop invariant */
@@ -1139,9 +1150,9 @@ brw_blorp_blit_program::manual_blend()
/* TODO: should use a smaller loop bound for non_RGBA formats */
for (int k = 0; k 4; ++k) {
-brw_ADD(func, offset(texture_data[stack_depth - 1], 2*k),
-offset(vec8(texture_data[stack_depth - 1]), 2*k),
-offset(vec8(texture_data[stack_depth]), 2*k));
+combine_op(func, offset(texture_data[stack_depth - 1], 2*k),
+ offset(vec8(texture_data[stack_depth - 1]), 2*k),
+ offset(vec8(texture_data[stack_depth]), 2*k));
}
}
}
@@ -1149,12 +1160,14 @@ brw_blorp_blit_program::manual_blend()
/* We should have just 1 sample on the stack now. */
assert(stack_depth == 1);
- /* Scale the result down by a factor of num_samples */
- /* TODO: should use a smaller loop bound for non-RGBA formats */
- for (int j = 0; j 4; ++j) {
- brw_MUL(func, offset(texture_data[0], 2*j),
- offset(vec8(texture_data[0]), 2*j),
- brw_imm_f(1.0/num_samples));
+ if (key-texture_data_type == BRW_REGISTER_TYPE_F) {
+ /* Scale the result down by a factor of num_samples */
+ /* TODO: should use a smaller loop bound for non-RGBA formats */
+ for (int j = 0; j 4; ++j) {
+ brw_MUL(func, offset(texture_data[0], 2*j),
+ offset(vec8(texture_data[0]), 2*j),
+ brw_imm_f(1.0/num_samples));
+ }
}
}
@@ -1319,7 +1332,8 @@ brw_blorp_blit_program::texture_lookup(struct brw_reg
dst,
void
brw_blorp_blit_program::render_target_write()
{
- struct brw_reg mrf_rt_write =
Re: [Mesa-dev] [PATCH v2 01/12] mesa: add glformats integer type/format detection routines
On Thu, Jul 19, 2012 at 12:54 PM, Brian Paul brian.e.p...@gmail.com wrote:
Hi Jordan,
I'd like to see this patch committed so I can do some follow-on
re-org. Just minor comments below.
Do you mean you would like to see it committed before the
rest of the series?
I'll fix your other recommendations.
Thanks,
-Jordan
On Wed, Jul 11, 2012 at 3:58 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
_mesa_is_integer_format is moved to formats.c and renamed
as _mesa_is_enum_format_integer.
_mesa_is_format_unsigned, _mesa_is_type_integer,
_mesa_is_type_unsigned, and _mesa_is_enum_format_or_type_integer
are added.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/main/drawpix.c |3 +-
src/mesa/main/formats.c | 13 ++
src/mesa/main/formats.h |4 +-
src/mesa/main/glformats.c | 185
+
src/mesa/main/glformats.h | 63 ++
src/mesa/main/image.c | 76
src/mesa/main/image.h |3 -
src/mesa/main/pack.c |9 +-
src/mesa/main/readpix.c |7 +-
src/mesa/main/teximage.c | 11 +-
src/mesa/sources.mak |1 +
You also need to add the new source glformats.c file src/mesa/SConscript.
src/mesa/state_tracker/st_cb_drawpixels.c |3 +-
12 files changed, 284 insertions(+), 94 deletions(-)
create mode 100644 src/mesa/main/glformats.c
create mode 100644 src/mesa/main/glformats.h
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index def55dd..7a5597b 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -35,6 +35,7 @@
#include pbo.h
#include state.h
#include dispatch.h
+#include glformats.h
#if FEATURE_drawpix
@@ -89,7 +90,7 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
* input), NVIDIA's implementation also just returns this error despite
* exposing GL_EXT_texture_integer, just return an error regardless.
*/
- if (_mesa_is_integer_format(format)) {
+ if (_mesa_is_enum_format_integer(format)) {
_mesa_error(ctx, GL_INVALID_OPERATION, glDrawPixels(integer
format));
goto end;
}
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index ccc0b17..ca739cd 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -28,6 +28,7 @@
#include formats.h
#include mfeatures.h
#include macros.h
+#include glformats.h
/**
@@ -1712,6 +1713,17 @@ _mesa_is_format_integer_color(gl_format format)
/**
+ * Is the given format an unsigned integer format?
+ */
+GLboolean
+_mesa_is_format_unsigned(gl_format format)
+{
+ const struct gl_format_info *info = _mesa_get_format_info(format);
+ return _mesa_is_type_unsigned(info-DataType);
+}
+
+
+/**
* Return color encoding for given format.
* \return GL_LINEAR or GL_SRGB
*/
@@ -2935,3 +2947,4 @@ _mesa_format_matches_format_and_type(gl_format
gl_format,
return GL_FALSE;
}
+
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 3a694a8..176e0fd 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -311,6 +311,9 @@ _mesa_is_format_packed_depth_stencil(gl_format format);
extern GLboolean
_mesa_is_format_integer_color(gl_format format);
+extern GLboolean
+_mesa_is_format_unsigned(gl_format format);
+
extern GLenum
_mesa_get_format_color_encoding(gl_format format);
@@ -346,7 +349,6 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
GLenum format, GLenum type,
GLboolean swapBytes);
-
#ifdef __cplusplus
}
#endif
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
new file mode 100644
index 000..b2277c3
--- /dev/null
+++ b/src/mesa/main/glformats.c
@@ -0,0 +1,185 @@
+/*
+ * Mesa 3-D graphics library
+ * Version: 7.7
Remove the version line, we don'd do that anymore.
+ *
+ * Copyright (C) 1999-2008 Brian Paul All Rights Reserved.
+ * Copyright (c) 2008-2009 VMware, Inc.
You can add an Intel copyright line if you want.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT
Re: [Mesa-dev] XOrg EVoC - Piglit tests for ARB_gpu_shader5 and ARB_tessellation_shader
On Thu, Jul 19, 2012 at 10:13 AM, Eric Anholt e...@anholt.net wrote: Ken Phillis Jr kphilli...@gmail.com writes: Hi, I am looking to enter the Xorg EVoC for 2012, and am wanting to Implement two Core extensions for OpenGL 4.0 and GLSL 4.00. Name: Piglit - Implement Tessellation shaders Extension Tests Summary: To implement the initial Tessellation shader support into the Piglit testing framework. This will be done using extensions to OpenGL 3.2, and GLSL 1.50. These extensions are called ARB_tessellation_shader, and ARB_gpu_shader5. This is also a bit of putting the cart in front of the horse in terms of piglit's development, since we don't even have geometry shader testing yet, which is required for tesselation. Intel's plans at least don't have us doing GL 3.2 (geometry shaders) until 2013, and I don't expect other community folks to jump on it, at least testing-wise, before then. I know that the opengl 3.x code is not in place for mesa for the most part. It's just that it's probably more worth while to add as much tests as possible to get people interested in developing mesa and the drivers. Description: I would like to start off by studying the Piglit code base, and looking at what changes are required so that the OpenGL 3.20, and GLSL 1.50 overall requirements for these extensions are met. If there is no major problems with the current framework, I'll start Implementing the numerous tests of ARB_tessellation_shader. Once I finish Implementing the tests for this extension, I will move on to the ARB_gpu_shader5 extension, and Implement the core of this extension. Once both Extensions are finished, I will start implementation of the Interaction tests with other extensions. At the end of each Stage I will submit a review of All the code written up to that point, and Improve the overall readability. This includes adding documentation, and comments where Features are added and/or modified. The piece I'm wondering about is how you're going to test your test code. You didn't mention what drivers you'd be working with to do so. Do you have both AMD and NVIDIA hardware available that you can validate your tests against? Though both drivers frequently have conformance issues, you usually need to have some explanation for what they're doing and how it's wrong. I was planning on testing against Opengl 4.x capable Nvidia and Radeon graphics cards. Also, needless to say, that also includes testing their latest drivers to at least make sure the tests are somewhat working properly. After All, It's not that difficult to expect that both cards will have drivers that don't fully comply with all the specifications. Schedule: I plan on working on this project full time for 10 to 14 weeks, and then continue working on this project for another 2 to 4 weeks part time improving documentation and code readability. *Week 1: Study the Specifications and Piglit's Design, and Start implementing the Missing features that will prevent general testing of these two extensions. If no Changes are required, the Implementation of ARB_tessellation_shader will start. *Week 2-4: Continue Implementing the tests and Utilities for the extension ARB_tessellation_shader. *Week 5: Submit the ARB_tessellation_shader source for Code Review, and begin Implementing ARB_gpu_shader5 Utilities and tests. Please start submitting new tests as soon as you have a couple done and ready. It would be sad to get to week 5 and find a bunch of coding style-type issues that you had to go fix up on all the tests. All along the development will be sent regularly to the publicly available github repository (https://github.com/kphillisjr/piglit ). This means that when work is completed it's first sent here, and then if a user (or developer ) wants to pull the changes and test them themselves they are free to do so. The 5th week is more of a broad request for test users to be able to see if the tests are working and also see if the tests actually cause some systems to crash because of driver bugs. I will also probably wind up sending a request with more than 20 patches at this time. *Week 6-7: Continue the ARB_gpu_shader5 Implementation. *Week 8: Submit ARB_gpu_shader5 sources for Code Review, and then begin Implementing the code review changes for ARB_tessellation_shader. *Week 9: Continue Implementing code review Changes, and begin work on ARB_gpu_shader5, and ARB_tessellation_shader interactions. *Week 10-12: Continue
Re: [Mesa-dev] [PATCH 5/7] i965/blorp: Configure SURFACE_STATE correctly for IMS surfaces.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote:
This patch modifies gen7_set_surface_num_multisamples() to set up the
SURFACE_STATE appropriately for texturing from IMS format MSAA
surfaces (which are only used on Gen7 for depth and stencil buffers).
Since the function now sets more than just the number of multisamples,
it's been renamed to gen7_set_surface_msaa().
This will make it possible to remove some kludginess from the blorp
engine.
---
src/mesa/drivers/dri/i965/brw_state.h |7 +--
src/mesa/drivers/dri/i965/gen7_blorp.cpp |2 +-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 11 ---
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 1c70db2..68e92a8 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -39,6 +39,8 @@
extern C {
#endif
+enum intel_msaa_layout;
+
extern const struct brw_tracked_state brw_blend_constant_color;
extern const struct brw_tracked_state brw_cc_vp;
extern const struct brw_tracked_state brw_cc_unit;
@@ -199,8 +201,9 @@ GLuint translate_tex_format(gl_format mesa_format,
/* gen7_wm_surface_state.c */
void gen7_set_surface_tiling(struct gen7_surface_state *surf, uint32_t
tiling);
-void gen7_set_surface_num_multisamples(struct gen7_surface_state *surf,
- unsigned num_samples);
+void gen7_set_surface_msaa(struct gen7_surface_state *surf,
+ unsigned num_samples,
+ enum intel_msaa_layout layout);
void gen7_set_surface_mcs_info(struct brw_context *brw,
struct gen7_surface_state *surf,
uint32_t surf_offset,
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index f087dbd..cc28d8c 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -180,7 +180,7 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
pitch_bytes *= 2;
surf-ss3.pitch = pitch_bytes - 1;
- gen7_set_surface_num_multisamples(surf, surface-num_samples);
+ gen7_set_surface_msaa(surf, surface-num_samples, surface-msaa_layout);
if (surface-msaa_layout == INTEL_MSAA_LAYOUT_CMS) {
gen7_set_surface_mcs_info(brw, surf, wm_surf_offset,
surface-mt-mcs_mt, is_render_target);
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index f037026..869f943 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -56,8 +56,8 @@ gen7_set_surface_tiling(struct gen7_surface_state *surf,
uint32_t tiling)
void
-gen7_set_surface_num_multisamples(struct gen7_surface_state *surf,
- unsigned num_samples)
+gen7_set_surface_msaa(struct gen7_surface_state *surf, unsigned num_samples,
+ enum intel_msaa_layout layout)
{
if (num_samples 4)
surf-ss4.num_multisamples = GEN7_SURFACE_MULTISAMPLECOUNT_8;
@@ -65,6 +65,11 @@ gen7_set_surface_num_multisamples(struct
gen7_surface_state *surf,
surf-ss4.num_multisamples = GEN7_SURFACE_MULTISAMPLECOUNT_4;
else
surf-ss4.num_multisamples = GEN7_SURFACE_MULTISAMPLECOUNT_1;
+
+ surf-ss4.multisampled_surface_storage_format =
+ layout == INTEL_MSAA_LAYOUT_IMS ?
+ GEN7_SURFACE_MSFMT_DEPTH_STENCIL :
+ GEN7_SURFACE_MSFMT_MSS;
}
@@ -490,7 +495,7 @@ gen7_update_renderbuffer_surface(struct brw_context *brw,
gen7_set_surface_tiling(surf, region-tiling);
surf-ss3.pitch = (region-pitch * region-cpp) - 1;
- gen7_set_surface_num_multisamples(surf, irb-mt-num_samples);
+ gen7_set_surface_msaa(surf, irb-mt-num_samples, irb-mt-msaa_layout);
if (irb-mt-msaa_layout == INTEL_MSAA_LAYOUT_CMS) {
gen7_set_surface_mcs_info(brw, surf, brw-wm.surf_offset[unit],
--
1.7.7.6
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] i965/blorp: Loosen assertions in compute_msaa_layout_for_pipeline.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote:
Previously, on Gen7, compute_msaa_layout_for_pipeline() would verify
that IMS layout is not used. However, now that we configure
SURFACE_STATE correctly for IMS surfaces, IMS layout is available.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index c8db662..c5e0ef9 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1432,20 +1432,15 @@ compute_msaa_layout_for_pipeline(struct brw_context
*brw, unsigned num_samples,
assert(true_layout == INTEL_MSAA_LAYOUT_NONE ||
true_layout == INTEL_MSAA_LAYOUT_IMS);
return INTEL_MSAA_LAYOUT_NONE;
+ } else {
+ assert(true_layout != INTEL_MSAA_LAYOUT_NONE);
}
/* Prior to Gen7, all MSAA surfaces use IMS layout. */
if (brw-intel.gen == 6) {
assert(true_layout == INTEL_MSAA_LAYOUT_IMS);
- return INTEL_MSAA_LAYOUT_IMS;
}
- /* Since blorp uses color textures and render targets to do all its work
-* (even when blitting stencil and depth data), we always have to
configure
-* the Gen7 GPU to use UMS or CMS layout on Gen7.
-*/
- assert(true_layout == INTEL_MSAA_LAYOUT_UMS ||
- true_layout == INTEL_MSAA_LAYOUT_CMS);
return true_layout;
}
--
1.7.7.6
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52282] New: [softpipe] piglit arb_shader_texture_lod-texgrad regression
https://bugs.freedesktop.org/show_bug.cgi?id=52282
Bug #: 52282
Summary: [softpipe] piglit arb_shader_texture_lod-texgrad
regression
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
CC: galib...@pobox.com
Created attachment 64410
-- https://bugs.freedesktop.org/attachment.cgi?id=64410
arb_shader_texture_lod-texgrad.png
mesa: a8c092266e9885f3370bbeae15bd80ebf035d05d (master)
Run piglit arb_shader_texture_lod-texgrad on softpipe.
$ ./bin/arb_shader_texture_lod-texgrad -auto
Mesa warning: failed to remap index 173
Left: texture2D, Right: texture2DGradARB
Probe at (4,3)
Left: 0.00 1.00 0.00 1.00
Right: 0.00 0.976471 0.00 1.00
PIGLIT: {'result': 'fail' }
229a1a7e4da1a9c60b35b79f2a63e0bab451a76e is the first bad commit
commit 229a1a7e4da1a9c60b35b79f2a63e0bab451a76e
Author: Olivier Galibert galib...@pobox.com
Date: Tue Jun 19 21:01:37 2012 +0200
softpipe: Take all lods into account when texture sampling.
This patch churns a lot because it needs to change 4-wide filters into
single pixel filters, since each fragment may use a different filter.
The only case not entirely supported is the anisotropic filtering.
Not sure what we want to do there, since a full quad is required by
that filter.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Brian Paul bri...@vmware.com
:04 04 b097530109abfbb406df16689a45154ba31e72f1
37331d8c61f88d8908f3bd5056fd4a0a0e3d M src
bisect run success
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] i965/blorp: Use IMS layout when texturing from depth/stencil surfaces.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote:
Previously, on Gen7, when texturing from a depth or stencil surface,
the blorp engine would configure the 3D pipeline as though the input
surface was non-multisampled, and perform the necessary coordinate
transformations in the fragment shader to account for the IMS layout.
This meant outputting a lot of extra fragment shader code, and it
raised some uncertainty about how to deal with very large surfaces.
This patch modifies blorp to configure the 3D pipeline properly for
IMS layout when reading from depth and stencil surfaces.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 66
+-
1 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index c5e0ef9..f72145f 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1246,18 +1246,31 @@ brw_blorp_blit_program::texel_fetch(struct brw_reg
dst)
s_is_zero ? 2 : 5);
break;
case 7:
- if (key-tex_samples 0) {
- if (key-tex_layout == INTEL_MSAA_LAYOUT_CMS) {
-texture_lookup(dst, GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DMS,
- gen7_ld2dms_args, ARRAY_SIZE(gen7_ld2dms_args));
- } else {
-texture_lookup(dst, GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DSS,
- gen7_ld2dss_args, ARRAY_SIZE(gen7_ld2dss_args));
- }
- } else {
+ switch (key-tex_layout) {
+ case INTEL_MSAA_LAYOUT_IMS:
+ /* From the Ivy Bridge PRM, Vol4 Part1 p72 (Multisampled Surface
Storage
+ * Format):
+ *
+ * If this field is MSFMT_DEPTH_STENCIL
+ * [a.k.a. INTEL_MSAA_LAYOUT_IMS], the only sampling engine
+ * messages allowed are ld2dms, resinfo, and sampleinfo.
+ *
+ * So fall through to emit the same message as we use for
+ * INTEL_MSAA_LAYOUT_CMS.
+ */
+ case INTEL_MSAA_LAYOUT_CMS:
+ texture_lookup(dst, GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DMS,
+gen7_ld2dms_args, ARRAY_SIZE(gen7_ld2dms_args));
+ break;
+ case INTEL_MSAA_LAYOUT_UMS:
+ texture_lookup(dst, GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DSS,
+gen7_ld2dss_args, ARRAY_SIZE(gen7_ld2dss_args));
+ break;
+ case INTEL_MSAA_LAYOUT_NONE:
assert(s_is_zero);
texture_lookup(dst, GEN5_SAMPLER_MESSAGE_SAMPLE_LD, gen7_ld_args,
ARRAY_SIZE(gen7_ld_args));
+ break;
}
break;
default:
@@ -1321,7 +1334,22 @@ brw_blorp_blit_program::texture_lookup(struct brw_reg
dst,
expand_to_32_bits(S, mrf);
break;
case SAMPLER_MESSAGE_ARG_MCS_INT:
- brw_MOV(func, mrf, mcs_data);
+ switch (key-tex_layout) {
+ case INTEL_MSAA_LAYOUT_CMS:
+brw_MOV(func, mrf, mcs_data);
+break;
+ case INTEL_MSAA_LAYOUT_IMS:
+/* When sampling from an IMS surface, MCS data is not relevant,
+ * and the hardware ignores it. So don't bother populating it.
+ */
+break;
+ default:
+/* We shouldn't be trying to send MCS data with any other
+ * layouts.
+ */
+assert (!Unsupported layout for MCS data);
+break;
+ }
break;
case SAMPLER_MESSAGE_ARG_ZERO_INT:
brw_MOV(func, mrf, brw_imm_ud(0));
@@ -1485,19 +1513,11 @@ brw_blorp_blit_params::brw_blorp_blit_params(struct
brw_context *brw,
}
if (brw-intel.gen 6) {
- /* Gen7's texturing hardware only supports the IMS layout with the
- * ld2dms instruction (which blorp doesn't use). So if the source is
- * IMS, we'll have to map it as a single-sampled texture and
- * de-interleave the samples ourselves.
- */
- if (src_mt-msaa_layout == INTEL_MSAA_LAYOUT_IMS)
- src.num_samples = 0;
-
- /* Similarly, Gen7's rendering hardware only supports the IMS layout
for
- * depth and stencil render targets. Blorp always maps its destination
- * surface as a color render target (even if it's actually a depth or
- * stencil buffer). So if the destination is IMS, we'll have to map it
- * as a single-sampled texture and interleave the samples ourselves.
+ /* Gen7's rendering hardware only supports the IMS layout for depth and
+ * stencil render targets. Blorp always maps its destination surface
as
+ * a color render target (even if it's actually a depth or stencil
+ * buffer). So if the destination is IMS, we'll have to map it as a
+ * single-sampled texture and interleave the samples
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Fri, Jul 20, 2012 at 1:34 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Jul 19, 2012 at 6:07 PM, Marek Olšák mar...@gmail.com wrote: I have these issues with the patch: 1) On GPUs without a vertex cache, you flush the texture cache every draw operation. Are you kidding? Show me one app with perf regression due to that ? Or just go look at what fglrx is doing. I don't believe that fglrx unconditionally emits SURFACE_SYNC with TC_ACTION_ENA before every DRAW packet. I just don't buy that. It's too stupid to be true. And considering that it wasn't needed before, it's not needed now either. Please give me some other argument than just fglrx. 2) All colorbuffers / streamout buffers are flushed, even those which are not enabled. E.g. instead of flushing only CB0 when there is only one, this code flushes all of them. Why? This either needs an explanation or it should only flush the buffers which are enabled (like the old code did). fglrx + no perf regression ... The no perf regression argument doesn't apply here, because it just might not be the bottleneck now. I'm willing to step aside from this one issue though. 3) Please explain: - why you added PS_PARTIAL_FLUSH in r600_texture_barrier and r600_set_framebuffer_state. fglrx is doing something similar But not exactly the same thing, right? So there's no reason for it to be there. - why you added CACHE_FLUSH_AND_INV_EVENT in set_framebuffer_state for R700 and evergreen. fglrx ... - why you applied the CB flush workarounds meant for RV6xx to all R600 and R700 chipsets. fglrx ... - why the streamout workaround for RV6xx (S_0085F0_DEST_BASE_0_ENA) is applied to all R600, R700, and evergreen chipsets. didn't hurt thought fglrx is not using that at all but i did not wanted to remove it Well, you didn't remove it. You added it for those other chipsets. That's a difference. You don't even know what you did there, do you? :) All the things I mentioned are either half-assed or added for no reason. Fglrx might do all sorts of stupid things or for its own reasons, but that doesn't mean it's automatically good for us. Besides that, it's almost impossible to figure out why a CS was built up exactly the way it was without access to the driver code and to its developers. - why R600_CONTEXT_FLUSH_AND_INV emits SURFACE_SYNC on evergreen, resulting in emission of SURFACE_SYNC twice in a row in most situations. fglrx is doing that and without that lockup ... Hm, now you're talking. So do you need: FLUSH_AND_INV + SURFACE_SYNC (COHER_CNTL = ~0) or do you need: FLUSH_AND_INV + SURFACE_SYNC (COHER_CNTL = ~0) + SURFACE_SYNC (COHER_CNTL = according to flags) for it not to lock up? Flushing has always worked without all the changes (1, 2, 3) mentioned above, so please if you don't have a reasonable explanation, revert to the old behavior. Well if you have a better solution please show me ... I already showed you in the first reply. If you are unwilling to change your patches even a little bit, I'll happily take them over from you. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] i965/blorp: Modify manual_blend() to avoid unnecessary loss of precision.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote:
When downsampling from an MSAA image to a single-sampled image, it is
inevitable that some loss of numerical precision will occur, since we
have to use 32-bit floating point registers to hold the intermediate
results while blending. However, it seems reasonable to expect that
when all samples corresponding to a given pixel have the exact same
color value, there will be no loss of precision.
Previously, we averaged samples as follows:
blend = (((sample[0] + sample[1]) + sample[2]) + sample[3]) / 4
This had the potential to lose numerical precision when all samples
have the same color value, since ((sample[0] + sample[1]) + sample[2])
may not be precisely representable as a 32-bit float, even if the
individual samples are.
This patch changes the formula to:
blend = ((sample[0] + sample[1]) + (sample[2] + sample[3])) / 4
This avoids any loss of precision in the event that all samples are
the same, by ensuring that each addition operation adds two equal
values.
As a side benefit, this puts the formula in the form we will need in
order to implement correct blending of integer formats.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 117
--
1 files changed, 90 insertions(+), 27 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 6954733..74ae52d 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -434,6 +434,11 @@ private:
const sampler_message_arg *args, int num_args);
void render_target_write();
+ /**
+* Base-2 logarithm of the maximum number of samples that can be blended.
+*/
+ static const unsigned LOG2_MAX_BLEND_SAMPLES = 2;
+
void *mem_ctx;
struct brw_context *brw;
const brw_blorp_blit_prog_key *key;
@@ -455,13 +460,8 @@ private:
struct brw_reg offset;
} x_transform, y_transform;
- /* Data to be written to render target (4 vec16's) */
- struct brw_reg result;
-
- /* Auxiliary storage for data returned by a sampling operation when
-* blending (4 vec16's)
-*/
- struct brw_reg texture_data;
+ /* Data read from texture (4 vec16's per array element) */
+ struct brw_reg texture_data[LOG2_MAX_BLEND_SAMPLES + 1];
/* Auxiliary storage for the contents of the MCS surface.
*
@@ -622,7 +622,7 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
if (brw-intel.gen == 6) {
/* Gen6 hardware an automatically blend using the SAMPLE message */
single_to_blend();
- sample(result);
+ sample(texture_data[0]);
} else {
/* Gen7+ hardware doesn't automaticaly blend. */
manual_blend();
@@ -656,7 +656,7 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
*/
if (key-tex_layout == INTEL_MSAA_LAYOUT_CMS)
mcs_fetch();
- texel_fetch(result);
+ texel_fetch(texture_data[0]);
}
/* Finally, write the fetched (or blended) value to the render target and
@@ -695,8 +695,9 @@ brw_blorp_blit_program::alloc_regs()
prog_data.first_curbe_grf = reg;
alloc_push_const_regs(reg);
reg += BRW_BLORP_NUM_PUSH_CONST_REGS;
- this-result = vec16(brw_vec8_grf(reg, 0)); reg += 8;
- this-texture_data = vec16(brw_vec8_grf(reg, 0)); reg += 8;
+ for (unsigned i = 0; i ARRAY_SIZE(texture_data); ++i) {
+ this-texture_data[i] = vec16(brw_vec8_grf(reg, 0)); reg += 8;
+ }
this-mcs_data =
retype(brw_vec8_grf(reg, 0), BRW_REGISTER_TYPE_UD); reg += 8;
for (int i = 0; i 2; ++i) {
@@ -711,6 +712,9 @@ brw_blorp_blit_program::alloc_regs()
this-t1 = vec16(retype(brw_vec8_grf(reg++, 0), BRW_REGISTER_TYPE_UW));
this-t2 = vec16(retype(brw_vec8_grf(reg++, 0), BRW_REGISTER_TYPE_UW));
+ /* Make sure we didn't run out of registers */
+ assert(reg = GEN7_MRF_HACK_START);
+
int mrf = 2;
this-base_mrf = mrf;
}
@@ -1061,6 +1065,24 @@ brw_blorp_blit_program::single_to_blend()
SWAP_XY_AND_XPYP();
}
+
+/**
+ * Count the number of trailing 1 bits in the given value. For example:
+ *
+ * count_trailing_one_bits(0) == 0
+ * count_trailing_one_bits(7) == 3
+ * count_trailing_one_bits(11) == 2
+ */
+inline int count_trailing_one_bits(unsigned value)
+{
+#if defined(__GNUC__) ((__GNUC__ * 100 + __GNUC_MINOR__) = 304) /* gcc
3.4 or later */
+ return __builtin_ctz(~value);
+#else
+ return _mesa_bitcount(value ~(value + 1));
+#endif
+}
+
+
void
brw_blorp_blit_program::manual_blend()
{
@@ -1070,27 +1092,68 @@ brw_blorp_blit_program::manual_blend()
if (key-tex_layout == INTEL_MSAA_LAYOUT_CMS)
mcs_fetch();
- /* Gather sample 0 data first */
- s_is_zero = true;
- texel_fetch(result);
-
- /* Gather data for
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Thu, Jul 19, 2012 at 9:00 PM, Marek Olšák mar...@gmail.com wrote: On Fri, Jul 20, 2012 at 1:34 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Jul 19, 2012 at 6:07 PM, Marek Olšák mar...@gmail.com wrote: I have these issues with the patch: 1) On GPUs without a vertex cache, you flush the texture cache every draw operation. Are you kidding? Show me one app with perf regression due to that ? Or just go look at what fglrx is doing. I don't believe that fglrx unconditionally emits SURFACE_SYNC with TC_ACTION_ENA before every DRAW packet. I just don't buy that. It's too stupid to be true. And considering that it wasn't needed before, it's not needed now either. Please give me some other argument than just fglrx. No fglrx don't set it for each draw, fglrx set it if a bunch of reg is touch. Given than right now we pretty much always touch one of those reg btw draw it just turn up that my patch trigger the flush btw each draw. 2) All colorbuffers / streamout buffers are flushed, even those which are not enabled. E.g. instead of flushing only CB0 when there is only one, this code flushes all of them. Why? This either needs an explanation or it should only flush the buffers which are enabled (like the old code did). fglrx + no perf regression ... The no perf regression argument doesn't apply here, because it just might not be the bottleneck now. I'm willing to step aside from this one issue though. I am just trying to stick to fglrx pattern. 3) Please explain: - why you added PS_PARTIAL_FLUSH in r600_texture_barrier and r600_set_framebuffer_state. fglrx is doing something similar But not exactly the same thing, right? So there's no reason for it to be there. It's hard to do as fglrx as the pattern is evading me no matter how much different app command stream i look at i always find an exception to rule i formulating. - why you added CACHE_FLUSH_AND_INV_EVENT in set_framebuffer_state for R700 and evergreen. fglrx ... - why you applied the CB flush workarounds meant for RV6xx to all R600 and R700 chipsets. fglrx ... - why the streamout workaround for RV6xx (S_0085F0_DEST_BASE_0_ENA) is applied to all R600, R700, and evergreen chipsets. didn't hurt thought fglrx is not using that at all but i did not wanted to remove it Well, you didn't remove it. You added it for those other chipsets. That's a difference. You don't even know what you did there, do you? :) All the things I mentioned are either half-assed or added for no reason. Fglrx might do all sorts of stupid things or for its own reasons, but that doesn't mean it's automatically good for us. Besides that, it's almost impossible to figure out why a CS was built up exactly the way it was without access to the driver code and to its developers. Oh yeah i don't have fucking clue, i am fucking cluesless, i am just a fool that write fucking random line of code and have no fucking idea of what i am doing. Of course you know better, please enlight me. I am totaly on board with fglrx doing stupid things but yet it does not lockup ... so one of those stupid things is important and until someone figure which one i would rather do more stupid thing and not lockup then trying to pretend that flushing is a bottleneck with the driver right now. - why R600_CONTEXT_FLUSH_AND_INV emits SURFACE_SYNC on evergreen, resulting in emission of SURFACE_SYNC twice in a row in most situations. fglrx is doing that and without that lockup ... Hm, now you're talking. So do you need: FLUSH_AND_INV + SURFACE_SYNC (COHER_CNTL = ~0) or do you need: FLUSH_AND_INV + SURFACE_SYNC (COHER_CNTL = ~0) + SURFACE_SYNC (COHER_CNTL = according to flags) for it not to lock up? flush inv is always follow by surface sync with few exception (on which i am not clear but there is always a surface sync before a draw after a flush inv. Flushing has always worked without all the changes (1, 2, 3) mentioned above, so please if you don't have a reasonable explanation, revert to the old behavior. Well if you have a better solution please show me ... I already showed you in the first reply. If you are unwilling to change your patches even a little bit, I'll happily take them over from you. Marek Oh i will change them, just not the way you like, i am trying to avoid lockup, you oubviously don't give a shit about that Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/7] i965/blorp: Improvements to the blorp engine for Gen7.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote: This patch series makes three improvements to the blorp engine (which does MSAA resolves and other blits) for Gen7: Patches 1-3 fix downsampling of integer format framebuffers on Gen7, by using the AVG instruction to average the samples, rather than adding the samples and performing a division. This is necessary to avoid overflow with 32-bit integer buffers. In the process, we rearrange the order of adds/averages to reduce the accumulation of numerical errors (patch 2). Patch 4 adds an optimization to the MSAA resolve when using Gen7's CMS MSAA layout: when the MCS buffer indicates that all samples corresponding to a given pixel contain the same color value, we don't have to load all the samples and average them; we just load the first sample and use its value. Patches 5-7 make blorp take advantage of the 3D pipeline's ability to decode the IMS MSAA layout when reading from depth and stencil textures. Previously blorp would emit extra shader instructions to account for the IMS MSAA layout. This change should make blits from multisampled depth and stencil buffers more efficient. [PATCH 1/7] i965: Add support for AVG instruction. [PATCH 2/7] i965/blorp: Modify manual_blend() to avoid unnecessary loss of precision. [PATCH 3/7] i965/blorp: Fix integer downsampling on Gen7. [PATCH 4/7] i965/blorp: Optimize manual_blend() for compressed multisampled surfaces. [PATCH 5/7] i965/blorp: Configure SURFACE_STATE correctly for IMS surfaces. [PATCH 6/7] i965/blorp: Loosen assertions in compute_msaa_layout_for_pipeline. [PATCH 7/7] i965/blorp: Use IMS layout when texturing from depth/stencil surfaces. Paul, Most of the code in these patches was unfamiliar to me. I reviewed these patches by referring to ivybridge PRM and assume that you have already tested them on a ivybridge system. I couldn't test because i don't have one. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/7] i965/blorp: Optimize manual_blend() for compressed multisampled surfaces.
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry stereotype...@gmail.com wrote:
When downsampling a compressed multisampled surface, we can take a
shortcut to downsample any pixels that were completely covered by a
single primitive. In this case, the first color value we fetch is the
correct final color for the downsampled pixel, so we can skip the rest
of the blending operation.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 32fd48e..c8db662 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1143,6 +1143,26 @@ brw_blorp_blit_program::manual_blend()
}
texel_fetch(texture_data[stack_depth++]);
+ if (i == 0 key-tex_layout == INTEL_MSAA_LAYOUT_CMS) {
+ /* The Ivy Bridge PRM, Vol4 Part1 p27 (Multisample Control Surface)
+ * suggests an optimization:
+ *
+ * A simple optimization with probable large return in
+ * performance is to compare the MCS value to zero (indicating
+ * all samples are on sample slice 0), and sample only from
+ * sample slice 0 using ld2dss if MCS is zero.
+ *
+ * Note that in the case where the MCS value is zero, sampling from
+ * sample slice 0 using ld2dss and sampling from sample 0 using
+ * ld2dms are equivalent (since all samples are on sample slice 0).
+ * Since we have already sampled from sample 0, all we need to do is
+ * skip the remaining fetches and averaging if MCS is zero.
+ */
+ brw_CMP(func, vec16(brw_null_reg()), BRW_CONDITIONAL_NZ,
+ mcs_data, brw_imm_ud(0));
+ brw_IF(func, BRW_EXECUTE_16);
+ }
+
/* Do count_trailing_one_bits(i) times */
for (int j = count_trailing_one_bits(i); j-- 0; ) {
assert(stack_depth = 2);
@@ -1169,6 +1189,9 @@ brw_blorp_blit_program::manual_blend()
brw_imm_f(1.0/num_samples));
}
}
+
+ if (key-tex_layout == INTEL_MSAA_LAYOUT_CMS)
+ brw_ENDIF(func);
}
/**
--
1.7.7.6
This is a useful optimization.
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
I actually care a lot about lockups. Well, you are complaing about lockups, yet you have quite obvious bugs in your hyperz code, so let's fix them first. (I wouldn't even try and run the hyperz code in its current state. Please don't take that personally.) Then, if the lockups persist, we can start looking into *what* fixes them. You seem to think that this patch helps a lot, but you don't say why. Aren't you interested in what sequence of GPU commands helps? If I am counting correctly, there are 7 changes in behavior in this patch. It should be pretty easy to nail down the few that help, document them (like /* these two lines fix a lockup with hyperz */), and discard the rest. The documenting part is very important, so that the other developers won't break your code accidentally. Marek On Fri, Jul 20, 2012 at 3:12 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Jul 19, 2012 at 9:00 PM, Marek Olšák mar...@gmail.com wrote: On Fri, Jul 20, 2012 at 1:34 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Jul 19, 2012 at 6:07 PM, Marek Olšák mar...@gmail.com wrote: I have these issues with the patch: 1) On GPUs without a vertex cache, you flush the texture cache every draw operation. Are you kidding? Show me one app with perf regression due to that ? Or just go look at what fglrx is doing. I don't believe that fglrx unconditionally emits SURFACE_SYNC with TC_ACTION_ENA before every DRAW packet. I just don't buy that. It's too stupid to be true. And considering that it wasn't needed before, it's not needed now either. Please give me some other argument than just fglrx. No fglrx don't set it for each draw, fglrx set it if a bunch of reg is touch. Given than right now we pretty much always touch one of those reg btw draw it just turn up that my patch trigger the flush btw each draw. 2) All colorbuffers / streamout buffers are flushed, even those which are not enabled. E.g. instead of flushing only CB0 when there is only one, this code flushes all of them. Why? This either needs an explanation or it should only flush the buffers which are enabled (like the old code did). fglrx + no perf regression ... The no perf regression argument doesn't apply here, because it just might not be the bottleneck now. I'm willing to step aside from this one issue though. I am just trying to stick to fglrx pattern. 3) Please explain: - why you added PS_PARTIAL_FLUSH in r600_texture_barrier and r600_set_framebuffer_state. fglrx is doing something similar But not exactly the same thing, right? So there's no reason for it to be there. It's hard to do as fglrx as the pattern is evading me no matter how much different app command stream i look at i always find an exception to rule i formulating. - why you added CACHE_FLUSH_AND_INV_EVENT in set_framebuffer_state for R700 and evergreen. fglrx ... - why you applied the CB flush workarounds meant for RV6xx to all R600 and R700 chipsets. fglrx ... - why the streamout workaround for RV6xx (S_0085F0_DEST_BASE_0_ENA) is applied to all R600, R700, and evergreen chipsets. didn't hurt thought fglrx is not using that at all but i did not wanted to remove it Well, you didn't remove it. You added it for those other chipsets. That's a difference. You don't even know what you did there, do you? :) All the things I mentioned are either half-assed or added for no reason. Fglrx might do all sorts of stupid things or for its own reasons, but that doesn't mean it's automatically good for us. Besides that, it's almost impossible to figure out why a CS was built up exactly the way it was without access to the driver code and to its developers. Oh yeah i don't have fucking clue, i am fucking cluesless, i am just a fool that write fucking random line of code and have no fucking idea of what i am doing. Of course you know better, please enlight me. I am totaly on board with fglrx doing stupid things but yet it does not lockup ... so one of those stupid things is important and until someone figure which one i would rather do more stupid thing and not lockup then trying to pretend that flushing is a bottleneck with the driver right now. - why R600_CONTEXT_FLUSH_AND_INV emits SURFACE_SYNC on evergreen, resulting in emission of SURFACE_SYNC twice in a row in most situations. fglrx is doing that and without that lockup ... Hm, now you're talking. So do you need: FLUSH_AND_INV + SURFACE_SYNC (COHER_CNTL = ~0) or do you need: FLUSH_AND_INV + SURFACE_SYNC (COHER_CNTL = ~0) + SURFACE_SYNC (COHER_CNTL = according to flags) for it not to lock up? flush inv is always follow by surface sync with few exception (on which i am not clear but there is always a surface sync before a draw after a flush inv. Flushing has always worked without all the changes (1, 2, 3) mentioned above, so please if you don't have a reasonable explanation, revert to the old behavior. Well if you have a better solution please
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák mar...@gmail.com wrote: I actually care a lot about lockups. Well, you are complaing about lockups, yet you have quite obvious bugs in your hyperz code, so let's fix them first. (I wouldn't even try and run the hyperz code in its current state. Please don't take that personally.) Then, if the lockups persist, we can start looking into *what* fixes them. You seem to think that this patch helps a lot, but you don't say why. Aren't you interested in what sequence of GPU commands helps? If I am counting correctly, there are 7 changes in behavior in this patch. It should be pretty easy to nail down the few that help, document them (like /* these two lines fix a lockup with hyperz */), and discard the rest. The documenting part is very important, so that the other developers won't break your code accidentally. Marek You haven't even try hyperz and you say i have an obvious bug, that's kind of funny, but you would not know why. I try pretty much all of the thing my patch do in isolation and combination of each other and the only way i got improvement is with something similar to this patch. Remove one things and i can find things program that are more likely to lockup. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák mar...@gmail.com wrote: I actually care a lot about lockups. Well, you are complaing about lockups, yet you have quite obvious bugs in your hyperz code, so let's fix them first. (I wouldn't even try and run the hyperz code in its current state. Please don't take that personally.) Then, if the lockups persist, we can start looking into *what* fixes them. You seem to think that this patch helps a lot, but you don't say why. Aren't you interested in what sequence of GPU commands helps? If I am counting correctly, there are 7 changes in behavior in this patch. It should be pretty easy to nail down the few that help, document them (like /* these two lines fix a lockup with hyperz */), and discard the rest. The documenting part is very important, so that the other developers won't break your code accidentally. Marek You haven't even try hyperz and you say i have an obvious bug, that's kind of funny, but you would not know why. I try pretty much all of Oh come on, I already told you about all the bugs I found in the hyperz patch. You now know them too, and so does everybody else reading mesa-dev. Marek the thing my patch do in isolation and combination of each other and the only way i got improvement is with something similar to this patch. Remove one things and i can find things program that are more likely to lockup. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák mar...@gmail.com wrote: On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák mar...@gmail.com wrote: I actually care a lot about lockups. Well, you are complaing about lockups, yet you have quite obvious bugs in your hyperz code, so let's fix them first. (I wouldn't even try and run the hyperz code in its current state. Please don't take that personally.) Then, if the lockups persist, we can start looking into *what* fixes them. You seem to think that this patch helps a lot, but you don't say why. Aren't you interested in what sequence of GPU commands helps? If I am counting correctly, there are 7 changes in behavior in this patch. It should be pretty easy to nail down the few that help, document them (like /* these two lines fix a lockup with hyperz */), and discard the rest. The documenting part is very important, so that the other developers won't break your code accidentally. Marek You haven't even try hyperz and you say i have an obvious bug, that's kind of funny, but you would not know why. I try pretty much all of Oh come on, I already told you about all the bugs I found in the hyperz patch. You now know them too, and so does everybody else reading mesa-dev. Marek None of the issue you pointed out showed in piglit, none of them did have impact on things like openarena, nexuiz, doomIII, lightmark, ... so no issue you pointed does not cripple the hyperz patch, it's working quite well for many things. Before you extrapolate, yes issue you pointed out have impact in backward use of GL but none the less i addressed them and i can tell you it does help a bit with lockup. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
