Re: [Mesa-dev] [PATCH 2/6] glsl: Optimize log(exp(x)) and exp(log(x)) into x.
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote: --- src/glsl/opt_algebraic.cpp | 36 1 file changed, 36 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 6b0d992..4aa49e5 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -252,6 +252,42 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) } break; + case ir_unop_exp: + if (op_expr[0] == NULL) +break; How can this happen?! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glsl: Optimize ~~x into x.
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote:
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 332f0b7..6b0d992 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -218,6 +218,18 @@ ir_algebraic_visitor::handle_expression(ir_expression
*ir)
this-mem_ctx = ralloc_parent(ir);
switch (ir-operation) {
+ case ir_unop_bit_not:
+ if (op_expr[0] == NULL)
+break;
How can this happen?!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/9] glsl: Add array specifier to ast code
On Sat, 2014-01-18 at 14:57 +1100, Timothy Arceri wrote:
diff --git a/src/glsl/glsl_parser_extras.cpp
b/src/glsl/glsl_parser_extras.cpp
index 21dc3ab..92076b5 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -484,6 +484,7 @@ struct _mesa_glsl_extension {
static const _mesa_glsl_extension _mesa_glsl_supported_extensions[] = {
/* API availability */
/* name GL ES supported flag
*/
+ EXT(ARB_arrays_of_arrays, true, false,
ARB_arrays_of_arrays),
EXT(ARB_conservative_depth, true, false,
ARB_conservative_depth),
EXT(ARB_draw_buffers, true, false, dummy_true),
EXT(ARB_draw_instanced, true, false,
ARB_draw_instanced),
@@ -769,7 +770,7 @@ _mesa_ast_set_aggregate_type(const ast_type_specifier
*type,
link);
bool is_array = decl_list-type-specifier-is_array;
-ast_expression *array_size =
decl_list-type-specifier-array_size;
+ast_array_specifier *array_specifier =
decl_list-type-specifier-array_specifier;
/* Recognize variable declarations with the bracketed size
attached
* to the type rather than the variable name as arrays. E.g.,
@@ -777,19 +778,18 @@ _mesa_ast_set_aggregate_type(const
ast_type_specifier *type,
* float a[2];
* float[2] b;
*
- * are both arrays, but a's array_size is
decl-array_size, while
- * b's array_size is
decl_list-type-specifier-array_size.
+ * are both arrays, but a's array_specifier is
decl-array_specifier, while
+ * b's array_specifier is
decl_list-type-specifier-array_specifier.
*/
if (!is_array) {
- /* FINISHME: Update when ARB_array_of_arrays is
supported. */
There's another identical FINISHME in this function that I don't see
in this patch.
is_array = decl-is_array;
- array_size = decl-array_size;
+ array_specifier = decl-array_specifier;
}
I don't think this is going to work for
float[2] a[3]
will it? is_array will be true, but the whole array_specifier won't be
complete.
The arrays of arrays support is added in patch 7. These changes are just
to get things working with new array specifier. I should have left the
TODO removal until patch 7.
I meant to say: The FULL arrays of arrays support is added in patch 7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 --- Comment #18 from Benjamin Bellec b.bel...@gmail.com --- Confirmed with TF2 (Linux edition). Same behavior with MSAAx2 and MSAAx4-6-8. -- 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] Error in configuring mesa.
sudo apt-get install llvm-dev worked for me. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: fix incorrect vertex size computation in LLVM drawing code
Ping.
On 01/14/2014 05:47 PM, Brian Paul wrote:
We were calling draw_total_vs_outputs() too early. The call to
draw_pt_emit_prepare() could result in the vertex size changing.
So call draw_total_vs_outputs() after draw_pt_emit_prepare().
This fix would seem to be needed for the non-LLVM code as well,
but it's not obvious. Instead, I added an assertion there to
try to catch this problem if it were to occur there.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72926
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c |7 +--
.../draw/draw_pt_fetch_shade_pipeline_llvm.c | 22
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
index 8fcc170..2c5c4cd 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
@@ -72,8 +72,8 @@ static void fetch_pipeline_prepare( struct draw_pt_middle_end
*middle,
const unsigned gs_out_prim = (gs ? gs-output_primitive :
u_assembled_prim(prim));
- unsigned nr = MAX2( vs-info.num_inputs,
- draw_total_vs_outputs(draw) );
+ unsigned nr_vs_outputs = draw_total_vs_outputs(draw);
+ unsigned nr = MAX2(vs-info.num_inputs, nr_vs_outputs);
if (gs) {
nr = MAX2(nr, gs-info.num_outputs + 1);
@@ -129,6 +129,9 @@ static void fetch_pipeline_prepare( struct
draw_pt_middle_end *middle,
/* No need to prepare the shader.
*/
vs-prepare(vs, draw);
+
+ /* Make sure that the vertex size didn't change at any point above */
+ assert(nr_vs_outputs == draw_total_vs_outputs(draw));
}
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
index 9f17241..60ec528 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
@@ -141,19 +141,11 @@ llvm_middle_end_prepare( struct draw_pt_middle_end
*middle,
struct draw_geometry_shader *gs = draw-gs.geometry_shader;
const unsigned out_prim = gs ? gs-output_primitive :
u_assembled_prim(in_prim);
- const unsigned nr = MAX2(vs-info.num_inputs,
-draw_total_vs_outputs(draw));
+ unsigned nr;
fpme-input_prim = in_prim;
fpme-opt = opt;
- /* Always leave room for the vertex header whether we need it or
-* not. It's hard to get rid of it in particular because of the
-* viewport code in draw_pt_post_vs.c.
-*/
- fpme-vertex_size = sizeof(struct vertex_header) + nr * 4 * sizeof(float);
-
-
draw_pt_post_vs_prepare( fpme-post_vs,
draw-clip_xy,
draw-clip_z,
@@ -177,6 +169,18 @@ llvm_middle_end_prepare( struct draw_pt_middle_end *middle,
*max_vertices = 4096;
}
+ /* Get the number of float[4] attributes per vertex.
+* Note: this must be done after draw_pt_emit_prepare() since that
+* can effect the vertex size.
+*/
+ nr = MAX2(vs-info.num_inputs, draw_total_vs_outputs(draw));
+
+ /* Always leave room for the vertex header whether we need it or
+* not. It's hard to get rid of it in particular because of the
+* viewport code in draw_pt_post_vs.c.
+*/
+ fpme-vertex_size = sizeof(struct vertex_header) + nr * 4 * sizeof(float);
+
/* return even number */
*max_vertices = *max_vertices ~1;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gallium: remove PIPE_CAP_SCALED_RESOLVE
On 01/18/2014 05:40 AM, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com If any driver doesn't support this, it can use a blit after resolving the samples. 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 1/2] gallium: remove PIPE_CAP_MAX_COMBINED_SAMPLERS
On 01/18/2014 05:40 AM, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com This can be derived from the shader caps. --- src/gallium/docs/source/screen.rst | 2 -- src/gallium/drivers/freedreno/freedreno_screen.c | 2 -- src/gallium/drivers/i915/i915_screen.c | 7 --- src/gallium/drivers/ilo/ilo_screen.c | 2 -- src/gallium/drivers/llvmpipe/lp_screen.c | 2 -- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 -- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 -- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 -- src/gallium/drivers/r300/r300_screen.c | 2 -- src/gallium/drivers/r600/r600_pipe.c | 2 -- src/gallium/drivers/radeonsi/si_pipe.c | 2 -- src/gallium/drivers/softpipe/sp_screen.c | 2 -- src/gallium/drivers/svga/svga_screen.c | 2 -- src/gallium/include/pipe/p_defines.h | 3 --- src/mesa/state_tracker/st_extensions.c | 10 ++ 15 files changed, 6 insertions(+), 38 deletions(-) ... diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index c17601a..4231d4c 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -89,10 +89,6 @@ void st_init_limits(struct st_context *st) c-MaxArrayTextureLayers = screen-get_param(screen, PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS); - c-MaxCombinedTextureImageUnits - = _min(screen-get_param(screen, PIPE_CAP_MAX_COMBINED_SAMPLERS), - MAX_COMBINED_TEXTURE_IMAGE_UNITS); - /* Define max viewport size and max renderbuffer size in terms of * max texture size (note: max tex RECT size = max tex 2D size). * If this isn't true for some hardware we'll need new PIPE_CAP_ queries. @@ -243,6 +239,12 @@ void st_init_limits(struct st_context *st) options-LowerClipDistance = true; } + c-MaxCombinedTextureImageUnits = + _min(c-Program[MESA_SHADER_VERTEX].MaxTextureImageUnits + + c-Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits + + c-Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits, + MAX_COMBINED_TEXTURE_IMAGE_UNITS); + /* This depends on program constants. */ c-MaxTextureCoordUnits = _min(c-Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits, MAX_TEXTURE_COORD_UNITS); I'm not sure about this. The concept of MAX_COMBINED_TEXTURE_IMAGE_UNITS goes back to the first shader hardware where texture image units might be shared between the VS and FS. The question is whether any of the hardware we care about has that restriction. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos] opengles2/es2tri: add precision qualifier to the fragment shader
On 01/19/2014 08:34 AM, Emil Velikov wrote:
The missing qualifier causes failure during the compilation stage.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D73631k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=XLIZ2HrbWqVFmoj1r3Eja4KyN0tfIdzTujHTgApHnYg%3D%0As=cb63d2bc49ebf80596286653cf46895006092b22e372dadff893fab49b71c6ff
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/egl/opengles2/es2tri.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/opengles2/es2tri.c b/src/egl/opengles2/es2tri.c
index 6dcc1b8..349a576 100644
--- a/src/egl/opengles2/es2tri.c
+++ b/src/egl/opengles2/es2tri.c
@@ -139,6 +139,7 @@ static void
create_shaders(void)
{
static const char *fragShaderText =
+ precision mediump float;\n
varying vec4 v_color;\n
void main() {\n
gl_FragColor = v_color;\n
Reviewed-by: Brian Paul bri...@vmware.com
I think I wrote some of those old tests. You might want to check the
rest for the same issue if you haven't already.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: how to force glLinkProgram to create/translate the program?
On 01/19/2014 12:16 AM, Ilia Mirkin wrote: Hi, My goal is to extend shader-db to be able to be used with nouveau, as I'm about to attempt a few compiler optimizations. But I'm having trouble with the very first step -- getting the driver to spit out the generated code. I've added logic to nouveau to translate the program as soon as it's available rather than on first use. However it seems that mesa/st has similar delaying logic, which makes it so that none of this is called when merely calling glLinkProgram. Right. The issue is shader variants. It's often the case that misc GL state interacts with the VS/FS code. For example, depending on whether we're drawing to the window or an FBO we have to invert the Y coordinate of gl_FragCoord in the FS by creating a FS variant. We postpone creating/bind shader variants until draw time, just like other state validation. I'm having trouble figuring out how to bypass this and make it call update_vp/fp/gp which appear like they'll actually call pipe-create_fs_state/etc. I see st_link_shader getting called, as expected, which creates the TGSI... but what to do from there? If you were to short-circuit the validation steps above and force the VS/FS to get propagated to the driver ASAP, there's a chance the shader wouldn't actually do everything that it normally would (ex: invert Y). I don't know if that matters to you. In any case, there's no simple solution to this. You'll probably have to hack something up. If it turns out simple, maybe we could enable it with a debug flag. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: clean up d3d style point clipping
Looks good to me AFAICT.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Instead of skipping x/y clipping completely if there's point_tri_clip points
use guard band clipping. This should be easier (previously we could not
disable
generating the x/y bits in the clip mask for llvm path, hence requiring
custom
clip path), and it also allows us to enable this for tris-as-points more
easily
too (this would require custom tri clip filtering too otherwise). Moreover,
some unexpected things could have happen if there's a NaN or just a huge
number
in some tri-turned-point, as the driver's rasterizer would need to deal with
it
and that might well lead to undefined behavior in typical rasterizers (which
need to convert these numbers to fixed point). Using a guardband should hence
be more robust, while usually guaranteeing the same results. (Only
usually
because unlike hw guardbands draw guardband is always just twice the vp size,
hence small vp but large points could still lead to different results.)
Unfortunately because the clipmask generated is completely unaffected by
guard
band clipping, we still need a custom clip stage for points (but not for
tris,
as the actual clipping there takes guard band into account).
---
src/gallium/auxiliary/draw/draw_context.c |8 ++---
src/gallium/auxiliary/draw/draw_pipe_clip.c| 34
++--
src/gallium/auxiliary/draw/draw_private.h |2 +-
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c | 15 +
.../draw/draw_pt_fetch_shade_pipeline_llvm.c |8 +++--
5 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c
b/src/gallium/auxiliary/draw/draw_context.c
index 9b5bcb5..842fdd3 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -262,10 +262,10 @@ static void update_clip_flags( struct draw_context
*draw )
draw-rasterizer draw-rasterizer-depth_clip);
draw-clip_user = draw-rasterizer
draw-rasterizer-clip_plane_enable != 0;
- draw-clip_points_xy = draw-clip_xy
- (!draw-driver.bypass_clip_points ||
- (draw-rasterizer
- !draw-rasterizer-point_tri_clip));
+ draw-guard_band_points_xy = draw-guard_band_xy ||
+(draw-driver.bypass_clip_points
+(draw-rasterizer
+ draw-rasterizer-point_tri_clip));
}
/**
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index adfa4b6..9b339ae 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -615,19 +615,33 @@ clip_point( struct draw_stage *stage,
stage-next-point( stage-next, header );
}
+
/*
* Clip points but ignore the first 4 (xy) clip planes.
- * (This is necessary because we don't generate a different shader variant
- * just for points hence xy clip bits are still generated. This is not
really
- * optimal because of the extra calculations both in generating clip masks
- * and executing the clip stage but it gets the job done.)
+ * (Because the generated clip mask is completely unaffacted by guard band,
+ * we still need to manually evaluate the x/y planes if they are outside
+ * the guard band and not just outside the vp.)
*/
static void
-clip_point_no_xy( struct draw_stage *stage,
- struct prim_header *header )
+clip_point_guard_xy( struct draw_stage *stage,
+ struct prim_header *header )
{
- if ((header-v[0]-clipmask 0xfff0) == 0)
- stage-next-point( stage-next, header );
+ unsigned clipmask = header-v[0]-clipmask;
+ if ((clipmask 0x) == 0)
+ stage-next-point(stage-next, header);
+ else if ((clipmask 0xfff0) == 0) {
+ while (clipmask) {
+ const unsigned plane_idx = ffs(clipmask)-1;
+ clipmask = ~(1 plane_idx); /* turn off this plane's bit */
+ /* TODO: this should really do proper guardband clipping,
+ * currently just throw out infs/nans.
+ */
+ if (util_is_inf_or_nan(header-v[0]-clip[0]) ||
+ util_is_inf_or_nan(header-v[0]-clip[1]))
+return;
+ }
+ stage-next-point(stage-next, header);
+ }
}
@@ -636,7 +650,7 @@ static void
clip_first_point( struct draw_stage *stage,
struct prim_header *header )
{
- stage-point = stage-draw-clip_points_xy ? clip_point :
clip_point_no_xy;
+ stage-point = stage-draw-guard_band_points_xy ? clip_point_guard_xy :
clip_point;
stage-point(stage, header);
}
@@ -662,7 +676,7 @@ clip_line( struct draw_stage *stage,
static void
clip_tri( struct draw_stage
Re: [Mesa-dev] [PATCH] st/vdpau: s/surface/resource/ to fix compiler warning
Not critical, but indeed wrong. Reviewed-by: Christian König christian.koe...@amd.com Am 20.01.2014 16:51, schrieb Brian Paul: --- src/gallium/state_trackers/vdpau/output.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/vdpau/output.c b/src/gallium/state_trackers/vdpau/output.c index 59874cb..aa7e997 100644 --- a/src/gallium/state_trackers/vdpau/output.c +++ b/src/gallium/state_trackers/vdpau/output.c @@ -117,7 +117,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device, err_resource: pipe_sampler_view_reference(vlsurface-sampler_view, NULL); pipe_surface_reference(vlsurface-surface, NULL); - pipe_surface_reference(res, NULL); + pipe_resource_reference(res, NULL); err_unlock: pipe_mutex_unlock(dev-mutex); FREE(vlsurface); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] swrast: check for null/-1 when mapping renderbuffers
Fixes fbo-drawbuffers-none crash (but test still fails).
https://bugs.freedesktop.org/show_bug.cgi?id=73757
---
src/mesa/swrast/s_renderbuffer.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/swrast/s_renderbuffer.c b/src/mesa/swrast/s_renderbuffer.c
index e3f33de..a19d02a 100644
--- a/src/mesa/swrast/s_renderbuffer.c
+++ b/src/mesa/swrast/s_renderbuffer.c
@@ -659,8 +659,10 @@ _swrast_map_renderbuffers(struct gl_context *ctx)
}
for (buf = 0; buf fb-_NumColorDrawBuffers; buf++) {
- map_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
- find_renderbuffer_colortype(fb-_ColorDrawBuffers[buf]);
+ if (fb-_ColorDrawBufferIndexes[buf] = 0) {
+ map_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
+ find_renderbuffer_colortype(fb-_ColorDrawBuffers[buf]);
+ }
}
}
@@ -688,6 +690,8 @@ _swrast_unmap_renderbuffers(struct gl_context *ctx)
}
for (buf = 0; buf fb-_NumColorDrawBuffers; buf++) {
- unmap_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
+ if (fb-_ColorDrawBufferIndexes[buf] = 0) {
+ unmap_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
+ }
}
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] softpipe: fix crash when accessing null colorbuffer
Fixes piglit fbo-missing-attachment-blit test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73755
---
src/gallium/drivers/softpipe/sp_quad_blend.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
b/src/gallium/drivers/softpipe/sp_quad_blend.c
index fb19ba5..41149a0 100644
--- a/src/gallium/drivers/softpipe/sp_quad_blend.c
+++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
@@ -1232,7 +1232,10 @@ choose_blend_quad(struct quad_stage *qs,
softpipe-blend-rt[0].colormask == 0xf
softpipe-framebuffer.nr_cbufs == 1)
{
- if (!blend-rt[0].blend_enable) {
+ if (softpipe-framebuffer.cbufs[0] == NULL) {
+ qs-run = blend_noop;
+ }
+ else if (!blend-rt[0].blend_enable) {
qs-run = single_output_color;
}
else if (blend-rt[0].rgb_src_factor == blend-rt[0].alpha_src_factor
--
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 2/2] swrast: check for null/-1 when mapping renderbuffers
Am 20.01.2014 17:07, schrieb Brian Paul:
Fixes fbo-drawbuffers-none crash (but test still fails).
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D73757k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=NwAWyMUIHlva0Hyr49qYFUYZHuaGQC9RtQJg%2BNie8g0%3D%0As=bdbd75884c7f5caf0bed2245042a4002952f6e6ffecf7f2cdd55e7da4fa003cc
---
src/mesa/swrast/s_renderbuffer.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/swrast/s_renderbuffer.c
b/src/mesa/swrast/s_renderbuffer.c
index e3f33de..a19d02a 100644
--- a/src/mesa/swrast/s_renderbuffer.c
+++ b/src/mesa/swrast/s_renderbuffer.c
@@ -659,8 +659,10 @@ _swrast_map_renderbuffers(struct gl_context *ctx)
}
for (buf = 0; buf fb-_NumColorDrawBuffers; buf++) {
- map_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
- find_renderbuffer_colortype(fb-_ColorDrawBuffers[buf]);
+ if (fb-_ColorDrawBufferIndexes[buf] = 0) {
+ map_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
+ find_renderbuffer_colortype(fb-_ColorDrawBuffers[buf]);
+ }
}
}
@@ -688,6 +690,8 @@ _swrast_unmap_renderbuffers(struct gl_context *ctx)
}
for (buf = 0; buf fb-_NumColorDrawBuffers; buf++) {
- unmap_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
+ if (fb-_ColorDrawBufferIndexes[buf] = 0) {
+ unmap_attachment(ctx, fb, fb-_ColorDrawBufferIndexes[buf]);
+ }
}
}
For the series:
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73757] [swrast] SIGSEGV swrast/s_renderbuffer.c:559
https://bugs.freedesktop.org/show_bug.cgi?id=73757 Brian Paul bri...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Brian Paul bri...@vmware.com --- Crash fixed with 799abb271a248f646faa5cc859968f8c71e1ef16. Note, the test still doesn't pass though. -- 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/st: how to force glLinkProgram to create/translate the program?
Brian Paul bri...@vmware.com writes: On 01/19/2014 12:16 AM, Ilia Mirkin wrote: Hi, My goal is to extend shader-db to be able to be used with nouveau, as I'm about to attempt a few compiler optimizations. But I'm having trouble with the very first step -- getting the driver to spit out the generated code. I've added logic to nouveau to translate the program as soon as it's available rather than on first use. However it seems that mesa/st has similar delaying logic, which makes it so that none of this is called when merely calling glLinkProgram. Right. The issue is shader variants. It's often the case that misc GL state interacts with the VS/FS code. For example, depending on whether we're drawing to the window or an FBO we have to invert the Y coordinate of gl_FragCoord in the FS by creating a FS variant. We postpone creating/bind shader variants until draw time, just like other state validation. I'm having trouble figuring out how to bypass this and make it call update_vp/fp/gp which appear like they'll actually call pipe-create_fs_state/etc. I see st_link_shader getting called, as expected, which creates the TGSI... but what to do from there? If you were to short-circuit the validation steps above and force the VS/FS to get propagated to the driver ASAP, there's a chance the shader wouldn't actually do everything that it normally would (ex: invert Y). I don't know if that matters to you. In any case, there's no simple solution to this. You'll probably have to hack something up. If it turns out simple, maybe we could enable it with a debug flag. Yeah, that's what we did in i965, too: Do a first compile all the way through the backend with a bunch of reasonable guesses, and note when those guesses are wrong under perf_debug(). The value from being able to do shader_db was huge. As a bonus, it reduces stuttering when first starting to draw using your shaders (assuming you guess correctly sometimes, which appears to be pretty easy). pgpimyQpMgkcr.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 2/6] glsl: Optimize log(exp(x)) and exp(log(x)) into x.
Erik Faye-Lund kusmab...@gmail.com writes: On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote: --- src/glsl/opt_algebraic.cpp | 36 1 file changed, 36 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 6b0d992..4aa49e5 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -252,6 +252,42 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) } break; + case ir_unop_exp: + if (op_expr[0] == NULL) +break; How can this happen?! If the first operand itself isn't an expression (for example, it's a swizzle of something else). pgpvRj86phQxw.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 2/6] glsl: Optimize log(exp(x)) and exp(log(x)) into x.
On Mon, Jan 20, 2014 at 5:39 PM, Eric Anholt e...@anholt.net wrote: Erik Faye-Lund kusmab...@gmail.com writes: On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote: --- src/glsl/opt_algebraic.cpp | 36 1 file changed, 36 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 6b0d992..4aa49e5 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -252,6 +252,42 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) } break; + case ir_unop_exp: + if (op_expr[0] == NULL) +break; How can this happen?! If the first operand itself isn't an expression (for example, it's a swizzle of something else). But what is something else? The GLSL grammar defines the arguments to be assignment_expressions, so they should always be expressions, no? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] cl: Add support for OpenCV unit tests v2
On Fri, Jan 17, 2014 at 03:04:46PM -0800, Dylan Baker wrote:
I think you meant to ping the piglit list not mesa dev :)
In general this looks a lot better, I've got a few little things for you
On Friday, January 17, 2014 02:30:13 PM Tom Stellard wrote:
From: Tom Stellard thomas.stell...@amd.com
This enables piglit to run and interpret the results from OpenCV's
gtest based opencv_test_ocl program.
This patch adds two new CMake configuration variables:
OPENCL_OpenCVTestOCL_BINDIR: You can use this variable to enable
the OpenCV tests by setting it to the full path of the
bin directory in your opencv build tree (e.g. /home/user/opencv/build/bin).
OPENCL_OpenCVTestOCL_WORKDIR: (Optional)If you don't want to use
OpenCV's default work directory, you can use this variable to specify
a different one.
v2:
- Python code cleanups
XXX: opencv
---
CMakeLists.txt| 9 ++-
tests/all_cl.py | 4 ++
tests/cl/program/execute/opencv-merge-hist.cl | 98
--- tests/ocl_config.py.in|
31 +
tests/opencv.py | 76 +
5 files changed, 119 insertions(+), 99 deletions(-)
delete mode 100644 tests/cl/program/execute/opencv-merge-hist.cl
create mode 100644 tests/ocl_config.py.in
create mode 100644 tests/opencv.py
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1befffb..37eac65 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -92,7 +92,10 @@ if(PIGLIT_BUILD_GLES3_TESTS AND NOT PIGLIT_USE_WAFFLE)
endif(PIGLIT_BUILD_GLES3_TESTS AND NOT PIGLIT_USE_WAFFLE)
if(PIGLIT_BUILD_CL_TESTS)
- find_package(OpenCL REQUIRED)
+find_package(OpenCL REQUIRED)
+set(OPENCL_OpenCVTestOCL_BINDIR CACHE STRING Directory with the
opencv_ocl_test program ) +set(OPENCL_OpenCVTestOCL_WORKDIR
CACHE STRING
+Directory with the opencv test resources (This is not needed
if your OpenCV build directory was $(opencv_src_dir)/build ) )
endif(PIGLIT_BUILD_CL_TESTS)
IF(${CMAKE_SYSTEM_NAME} MATCHES Linux)
@@ -356,6 +359,10 @@ configure_file(
${piglit_SOURCE_DIR}/tests/util/config.h.in
${piglit_BINARY_DIR}/tests/util/config.h
)
+configure_file(
+ ${piglit_SOURCE_DIR}/tests/ocl_config.py.in
+ ${piglit_BINARY_DIR}/tests/ocl_config.py
+)
include(cmake/piglit_util.cmake)
include(cmake/piglit_glapi.cmake)
diff --git a/tests/all_cl.py b/tests/all_cl.py
index a7d7106..b9c112a 100644
--- a/tests/all_cl.py
+++ b/tests/all_cl.py
@@ -7,6 +7,8 @@ __all__ = ['profile']
import os
import os.path as path
+from tests.opencv import add_opencv_tests
+
from framework.core import Group, TestProfile
from framework.exectest import PlainExecTest
@@ -122,3 +124,5 @@ add_program_test_dir(program_execute_builtin,
'generated_tests/cl/builtin/relati program_execute_store = Group()
program[Execute][Store] = program_execute_store
add_program_test_dir(program_execute_store, 'generated_tests/cl/store')
+
+add_opencv_tests(profile)
diff --git a/tests/cl/program/execute/opencv-merge-hist.cl
b/tests/cl/program/execute/opencv-merge-hist.cl deleted file mode 100644
index 8dccf24..000
--- a/tests/cl/program/execute/opencv-merge-hist.cl
+++ /dev/null
@@ -1,98 +0,0 @@
-/*!
-[config]
-name: OpenCV merge-hist
-kernel_name: merge_hist
-dimensions: 1
-global_size: 65536 1 1
-local_size: 256 1 1
-
-# This test checks that the loop:
-# for(int stride = HISTOGRAM256_WORK_GROUP_SIZE /2; stride 0; stride =
1) -# in this kernel is unrolled correctly or not unrolled at all. The
Clang -# OpenCL frontend was unrolling this in way that created illegal
uses of the -# barrier() builtin which resulted in GPU hangs on r600g.
-[test]
-arg_in: 0 buffer int[65536] repeat 0
-arg_out: 1 buffer int[256] repeat 0
-arg_in: 2 int 256
-
-!*/
-
-// The kernel in this test is taken from the opencv library (opencv.org)
-// File: modules/ocl/src/opencl/imgproc_histogram.cl
-//
-// License Agreement
-//For Open Source Computer Vision Library
-//
-// Copyright (C) 2010-2012, Institute Of Software Chinese Academy Of
Science, all rights reserved. -// Copyright (C) 2010-2012, Advanced Micro
Devices, Inc., all rights reserved. -// Copyright (C) 2010-2012,
Multicoreware, Inc., all rights reserved. -// Third party copyrights are
property of their respective owners. -//
-// @Authors
-//Niko Li, newlife20080...@gmail.com
-//Jia Haipeng, jiahaipen...@gmail.com
-//Xu Pang, pangxu...@163.com
-//Wenju He, we...@multicorewareinc.com
-// Redistribution and use in source and binary forms, with or without
modification, -// are permitted provided that the following conditions are
met:
-//
-// *
Re: [Mesa-dev] [PATCH] draw: fix incorrect vertex size computation in LLVM drawing code
Good catch Brian. Change looks good to me AFAICT.
We do need more this sort of assertions in the draw module. I never fail to
get surprised at how intricate and sensitive draw module is -- mostly due the
fact that it reaches out to the upstream gallium interface from within the
driver. I do hope one day the state trackers just use geometry shaders for all
those things, so that the draw module is a straighforward VS/GS processor, and
does not need to create its own fragment sahders. (It is unfortunate that with
util/u_blitter we replicate the bad example of reaching out to gallium
interface from inside the driver.)
Jose
- Original Message -
We were calling draw_total_vs_outputs() too early. The call to
draw_pt_emit_prepare() could result in the vertex size changing.
So call draw_total_vs_outputs() after draw_pt_emit_prepare().
This fix would seem to be needed for the non-LLVM code as well,
but it's not obvious. Instead, I added an assertion there to
try to catch this problem if it were to occur there.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D72926k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=91zldQ8lO5OhCBRVy4vcYnfNUSKL3Bo1lcxmHhpMqWQ%3D%0As=2dc25b5d2d9cdcc89cb242f8bdd09f59761026dd200cea7eb9dd3278928e3603
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c |7 +--
.../draw/draw_pt_fetch_shade_pipeline_llvm.c | 22
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
index 8fcc170..2c5c4cd 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
@@ -72,8 +72,8 @@ static void fetch_pipeline_prepare( struct
draw_pt_middle_end *middle,
const unsigned gs_out_prim = (gs ? gs-output_primitive :
u_assembled_prim(prim));
- unsigned nr = MAX2( vs-info.num_inputs,
-draw_total_vs_outputs(draw) );
+ unsigned nr_vs_outputs = draw_total_vs_outputs(draw);
+ unsigned nr = MAX2(vs-info.num_inputs, nr_vs_outputs);
if (gs) {
nr = MAX2(nr, gs-info.num_outputs + 1);
@@ -129,6 +129,9 @@ static void fetch_pipeline_prepare( struct
draw_pt_middle_end *middle,
/* No need to prepare the shader.
*/
vs-prepare(vs, draw);
+
+ /* Make sure that the vertex size didn't change at any point above */
+ assert(nr_vs_outputs == draw_total_vs_outputs(draw));
}
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
index 9f17241..60ec528 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
@@ -141,19 +141,11 @@ llvm_middle_end_prepare( struct draw_pt_middle_end
*middle,
struct draw_geometry_shader *gs = draw-gs.geometry_shader;
const unsigned out_prim = gs ? gs-output_primitive :
u_assembled_prim(in_prim);
- const unsigned nr = MAX2(vs-info.num_inputs,
-draw_total_vs_outputs(draw));
+ unsigned nr;
fpme-input_prim = in_prim;
fpme-opt = opt;
- /* Always leave room for the vertex header whether we need it or
-* not. It's hard to get rid of it in particular because of the
-* viewport code in draw_pt_post_vs.c.
-*/
- fpme-vertex_size = sizeof(struct vertex_header) + nr * 4 *
sizeof(float);
-
-
draw_pt_post_vs_prepare( fpme-post_vs,
draw-clip_xy,
draw-clip_z,
@@ -177,6 +169,18 @@ llvm_middle_end_prepare( struct draw_pt_middle_end
*middle,
*max_vertices = 4096;
}
+ /* Get the number of float[4] attributes per vertex.
+* Note: this must be done after draw_pt_emit_prepare() since that
+* can effect the vertex size.
+*/
+ nr = MAX2(vs-info.num_inputs, draw_total_vs_outputs(draw));
+
+ /* Always leave room for the vertex header whether we need it or
+* not. It's hard to get rid of it in particular because of the
+* viewport code in draw_pt_post_vs.c.
+*/
+ fpme-vertex_size = sizeof(struct vertex_header) + nr * 4 *
sizeof(float);
+
/* return even number */
*max_vertices = *max_vertices ~1;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] mesa/st: how to force glLinkProgram to create/translate the program?
I used to have a patch which precompiles some of the commonly used shader variants, but I seem to have deleted it because Wine also loaded shaders on demand and compiling more shader variants than necessary could only make it worse. Marek On Sun, Jan 19, 2014 at 9:16 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Hi, My goal is to extend shader-db to be able to be used with nouveau, as I'm about to attempt a few compiler optimizations. But I'm having trouble with the very first step -- getting the driver to spit out the generated code. I've added logic to nouveau to translate the program as soon as it's available rather than on first use. However it seems that mesa/st has similar delaying logic, which makes it so that none of this is called when merely calling glLinkProgram. I'm having trouble figuring out how to bypass this and make it call update_vp/fp/gp which appear like they'll actually call pipe-create_fs_state/etc. I see st_link_shader getting called, as expected, which creates the TGSI... but what to do from there? Thanks, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72926] [REGRESSION, swrast] Memory-related crash with anti-aliasing enabled
https://bugs.freedesktop.org/show_bug.cgi?id=72926 Brian Paul bri...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Brian Paul bri...@vmware.com --- Patch committed to master: ad814d04ca5d579538885a595331b5b27caefd2a -- 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/st: how to force glLinkProgram to create/translate the program?
On Mon, Jan 20, 2014 at 10:23 AM, Brian Paul bri...@vmware.com wrote: I'm having trouble figuring out how to bypass this and make it call update_vp/fp/gp which appear like they'll actually call pipe-create_fs_state/etc. I see st_link_shader getting called, as expected, which creates the TGSI... but what to do from there? If you were to short-circuit the validation steps above and force the VS/FS to get propagated to the driver ASAP, there's a chance the shader wouldn't actually do everything that it normally would (ex: invert Y). I don't know if that matters to you. Not at all. This is for checking various nouveau compiler optimizations against input shaders. I think that as long as the shaders passed to the driver remain basically the same, it should still be useful for comparing emitted code with different (nouveau) compiler versions. In any case, there's no simple solution to this. You'll probably have to hack something up. If it turns out simple, maybe we could enable it with a debug flag. Could you suggest a way for hacking this up? i.e. what functions might I call from where? I'm definitely having trouble groking the code paths that cause things to be sent right now. Thanks, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glsl: Optimize ~~x into x.
On 01/19/2014 11:18 PM, Eric Anholt wrote:
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 332f0b7..6b0d992 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -218,6 +218,18 @@ ir_algebraic_visitor::handle_expression(ir_expression
*ir)
this-mem_ctx = ralloc_parent(ir);
switch (ir-operation) {
+ case ir_unop_bit_not:
+ if (op_expr[0] == NULL)
+ break;
+
+ switch (op_expr[0]-operation) {
+ case ir_unop_bit_not:
+ return abs(op_expr[0]-operands[0]);
Copy and paste error? I really don't think you want to abs().
+ default:
+ break;
+ }
+ break;
+
case ir_unop_abs:
if (op_expr[0] == NULL)
break;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glsl: Optimize ~~x into x.
On 01/20/2014 12:38 AM, Erik Faye-Lund wrote:
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote:
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 332f0b7..6b0d992 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -218,6 +218,18 @@ ir_algebraic_visitor::handle_expression(ir_expression
*ir)
this-mem_ctx = ralloc_parent(ir);
switch (ir-operation) {
+ case ir_unop_bit_not:
+ if (op_expr[0] == NULL)
+break;
How can this happen?!
Easy. op_expr[i] == ir-operand[i]-as_expression(). If the operand is
not an ir_expression object, this will be NULL. For example, it could
be an ir_swizzle, ir_constant, ir_dereference_variable...or pretty much
any other ir_rvalue derivative.
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] svga: fix clearing for null color buffers
Fixes piglit fbo-drawbuffers-none glClear test.
---
src/gallium/drivers/svga/svga_pipe_clear.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_clear.c
b/src/gallium/drivers/svga/svga_pipe_clear.c
index 5deebb2..21869e9 100644
--- a/src/gallium/drivers/svga/svga_pipe_clear.c
+++ b/src/gallium/drivers/svga/svga_pipe_clear.c
@@ -59,12 +59,12 @@ try_clear(struct svga_context *svga,
}
}
- if ((buffers PIPE_CLEAR_COLOR) fb-cbufs[0]) {
+ if (buffers PIPE_CLEAR_COLOR) {
flags |= SVGA3D_CLEAR_COLOR;
util_pack_color(color-f, PIPE_FORMAT_B8G8R8A8_UNORM, uc);
- rect.w = fb-cbufs[0]-width;
- rect.h = fb-cbufs[0]-height;
+ rect.w = fb-width;
+ rect.h = fb-height;
}
if ((buffers PIPE_CLEAR_DEPTHSTENCIL) fb-zsbuf) {
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] svga: implement TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS
Fixes several colorbuffer tests, including piglit fbo-drawbuffers-none
for gl_FragColor and glDrawPixels cases.
v2: rework patch to only avoid creating extra shader variants when
TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS is not specified. Per Jose.
Use a write_color0_to_n_cbufs key field to replicate color0 to N
color buffers only when N 0 and WRITES_ALL_CBUFS is set.
---
src/gallium/drivers/svga/svga_state_fs.c |8 +
src/gallium/drivers/svga/svga_tgsi.h |1 +
src/gallium/drivers/svga/svga_tgsi_decl_sm30.c | 37 +++-
src/gallium/drivers/svga/svga_tgsi_insn.c |9 ++
4 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 51d0eb5..1e9fb43 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -276,6 +276,12 @@ make_fs_key(const struct svga_context *svga,
key-sprite_origin_lower_left = (svga-curr.rast-templ.sprite_coord_mode
== PIPE_SPRITE_COORD_LOWER_LEFT);
+ /* SVGA_NEW_FRAME_BUFFER */
+ if (fs-base.info.color0_writes_all_cbufs) {
+ /* Replicate color0 output to N colorbuffers */
+ key-write_color0_to_n_cbufs = svga-curr.framebuffer.nr_cbufs;
+ }
+
return PIPE_OK;
}
@@ -296,6 +302,7 @@ emit_hw_fs(struct svga_context *svga, unsigned dirty)
* SVGA_NEW_RAST
* SVGA_NEW_NEED_SWTNL
* SVGA_NEW_SAMPLER
+* SVGA_NEW_FRAME_BUFFER
*/
ret = make_fs_key( svga, fs, key );
if (ret != PIPE_OK)
@@ -335,6 +342,7 @@ struct svga_tracked_state svga_hw_fs =
SVGA_NEW_NEED_SWTNL |
SVGA_NEW_RAST |
SVGA_NEW_SAMPLER |
+SVGA_NEW_FRAME_BUFFER |
SVGA_NEW_BLEND),
emit_hw_fs
};
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 0e06dbf..591dd6a 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -56,6 +56,7 @@ struct svga_fs_compile_key
unsigned light_twoside:1;
unsigned front_ccw:1;
unsigned white_fragments:1;
+ unsigned write_color0_to_n_cbufs:3;
unsigned num_textures:8;
unsigned num_unnormalized_coords:8;
unsigned sprite_origin_lower_left:1;
diff --git a/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
b/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
index e0a30a5..137afd6 100644
--- a/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
+++ b/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
@@ -327,14 +327,35 @@ ps30_output(struct svga_shader_emitter *emit,
{
switch (semantic.Name) {
case TGSI_SEMANTIC_COLOR:
- if (emit-unit == PIPE_SHADER_FRAGMENT
- emit-key.fkey.white_fragments) {
-
- emit-output_map[idx] = dst_register( SVGA3DREG_TEMP,
- emit-nr_hw_temp++ );
- emit-temp_color_output[idx] = emit-output_map[idx];
- emit-true_color_output[idx] = dst_register(SVGA3DREG_COLOROUT,
- semantic.Index);
+ if (emit-unit == PIPE_SHADER_FRAGMENT) {
+ if (emit-key.fkey.white_fragments) {
+/* Used for XOR logicop mode */
+emit-output_map[idx] = dst_register( SVGA3DREG_TEMP,
+ emit-nr_hw_temp++ );
+emit-temp_color_output[idx] = emit-output_map[idx];
+emit-true_color_output[idx] = dst_register(SVGA3DREG_COLOROUT,
+semantic.Index);
+ }
+ else if (emit-key.fkey.write_color0_to_n_cbufs) {
+/* We'll write color output [0] to all render targets.
+ * Prepare all the output registers here, but only when the
+ * semantic.Index == 0 so we don't do this more than once.
+ */
+if (semantic.Index == 0) {
+ unsigned i;
+ for (i = 0; i emit-key.fkey.write_color0_to_n_cbufs; i++) {
+ emit-output_map[i] = dst_register(SVGA3DREG_TEMP,
+ emit-nr_hw_temp++);
+ emit-temp_color_output[i] = emit-output_map[i];
+ emit-true_color_output[i] = dst_register(SVGA3DREG_COLOROUT,
+i);
+ }
+}
+ }
+ else {
+emit-output_map[idx] =
+ dst_register(SVGA3DREG_COLOROUT, semantic.Index);
+ }
}
else {
emit-output_map[idx] = dst_register( SVGA3DREG_COLOROUT,
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index 2143546..ce00da6 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -3074,6 +3074,15 @@ emit_ps_postamble(struct svga_shader_emitter *emit)
[Mesa-dev] [PATCH] docs: remove some ancient README.* files
None of this info is relevant anymore. --- docs/README.CYGWIN | 256 --- docs/README.MITS| 102 docs/README.QUAKE | 207 - docs/README.THREADS | 52 --- 4 files changed, 617 deletions(-) delete mode 100644 docs/README.CYGWIN delete mode 100644 docs/README.MITS delete mode 100644 docs/README.QUAKE delete mode 100644 docs/README.THREADS diff --git a/docs/README.CYGWIN b/docs/README.CYGWIN deleted file mode 100644 index 58d5af3..000 --- a/docs/README.CYGWIN +++ /dev/null @@ -1,256 +0,0 @@ - - Mesa Cygwin/X11 Information - - -WARNING -=== - -If you installed X11 (packages xorg-x11-devel and xorg-x11-bin-dlls ) with the -latest setup.exe from Cygwin the GL (Mesa) libraries and include are already -installed in /usr/X11R6. - -The following will explain how to replace them. - -Installation - - -How to compile Mesa on Cygwin/X11 systems: - -1. Shared libs: -type 'make cygwin-sl'. - -When finished, the Mesa DLL will be in the Mesa-x.y/lib/ and -Mesa-x.y/bin directories. - - -2. Static libs: -type 'make cygwin-static'. -When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory. - -Header and library files: - After you've compiled Mesa and tried the demos I recommend the following - procedure for installing Mesa. - - Copy the Mesa include/GL directory to /usr/X11R6/include: - cp -a include/GL /usr/X11R6/include - - Copy the Mesa library files to /usr/X11R6/lib: - cp -a lib/* /usr/X11R6ocal/lib - - Copy the Mesa bin files (used by the DLL stuff) to /usr/X11R6/bin: - cp -a lib/cyg* /usr/X11R6/bin - -Xt/Motif widgets: - If you want to use Mesa or OpenGL in your Xt/Motif program you can build - the widgets found in either the widgets-mesa or widgets-sgi directories. - The former were written for Mesa and the later are the original SGI - widgets. Look in those directories for more information. - For the Motif widgets you must have downloaded the lesstif package. - - -Using the library -= - -Configuration options: - The file src/mesa/main/config.h has many parameters which you can adjust - such as maximum number of lights, clipping planes, maximum texture size, - etc. In particular, you may want to change DEPTH_BITS from 16 to 32 - if a 16-bit depth buffer isn't precise enough for your application. - - -Shared libraries: - If you compile shared libraries (Win32 DLLS) you may have to set an - environment variable to specify where the Mesa libraries are located. - Set the PATH variable to include /your-dir/Mesa-2.6/bin. - Otherwise, when you try to run a demo it may fail with a message saying - that one or more DLL couldn't be found. - - -Xt/Motif Widgets: - Two versions of the Xt/Motif OpenGL drawing area widgets are included: - - widgets-sgi/ SGI's stock widgets - widgets-mesa/Mesa-tuned widgets - - Look in those directories for details - - -Togl: - Togl is an OpenGL/Mesa widget for Tcl/Tk. - See http://togl.sourceforge.net for more information. - - - -X Display Modes: - Mesa supports RGB(A) rendering into almost any X visual type and depth. - - The glXChooseVisual function tries its best to pick an appropriate visual - for the given attribute list. However, if this doesn't suit your needs - you can force Mesa to use any X visual you want (any supported by your - X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL - environment variables. When an RGB visual is requested, glXChooseVisual - will first look if the MESA_RGB_VISUAL variable is defined. If so, it - will try to use the specified visual. Similarly, when a color index - visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL - variable. - - The format of accepted values is: visual-class depth - Here are some examples: - - using the C-shell: - % setenv MESA_RGB_VISUAL TrueColor 8 // 8-bit TrueColor - % setenv MESA_CI_VISUAL PseudoColor 12// 12-bit PseudoColor - % setenv MESA_RGB_VISUAL PseudoColor 8// 8-bit PseudoColor - - using the KornShell: - $ export MESA_RGB_VISUAL=TrueColor 8 - $ export MESA_CI_VISUAL=PseudoColor 12 - $ export MESA_RGB_VISUAL=PseudoColor 8 - - -Double buffering: - Mesa can use either an X Pixmap or XImage as the backbuffer when in - double buffer mode. Using GLX, the default is to use an XImage. The - MESA_BACK_BUFFER environment variable can override this. The valid - values for MESA_BACK_BUFFER are: Pixmap and XImage (only the first - letter is checked, case doesn't matter). - - A pixmap is faster when drawing simple lines and polygons while an - XImage is faster when Mesa has to do pixel-by-pixel rendering. If you - need depth buffering the XImage will almost surely be faster.
[Mesa-dev] [PATCH 2/3] svga: rename color output variables
Just to be bit more readable.
---
src/gallium/drivers/svga/svga_tgsi_decl_sm30.c |6 +++---
src/gallium/drivers/svga/svga_tgsi_emit.h |5 +++--
src/gallium/drivers/svga/svga_tgsi_insn.c |8
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
b/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
index 7faa275..e0a30a5 100644
--- a/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
+++ b/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
@@ -332,9 +332,9 @@ ps30_output(struct svga_shader_emitter *emit,
emit-output_map[idx] = dst_register( SVGA3DREG_TEMP,
emit-nr_hw_temp++ );
- emit-temp_col[idx] = emit-output_map[idx];
- emit-true_col[idx] = dst_register( SVGA3DREG_COLOROUT,
- semantic.Index );
+ emit-temp_color_output[idx] = emit-output_map[idx];
+ emit-true_color_output[idx] = dst_register(SVGA3DREG_COLOROUT,
+ semantic.Index);
}
else {
emit-output_map[idx] = dst_register( SVGA3DREG_COLOROUT,
diff --git a/src/gallium/drivers/svga/svga_tgsi_emit.h
b/src/gallium/drivers/svga/svga_tgsi_emit.h
index e36a955..28b8e69 100644
--- a/src/gallium/drivers/svga/svga_tgsi_emit.h
+++ b/src/gallium/drivers/svga/svga_tgsi_emit.h
@@ -119,8 +119,9 @@ struct svga_shader_emitter
/* shared output for depth and fog */
SVGA3dShaderDestToken vs_depth_fog;
- SVGA3dShaderDestToken temp_col[PIPE_MAX_COLOR_BUFS];
- SVGA3dShaderDestToken true_col[PIPE_MAX_COLOR_BUFS];
+ /* PS output colors */
+ SVGA3dShaderDestToken temp_color_output[PIPE_MAX_COLOR_BUFS];
+ SVGA3dShaderDestToken true_color_output[PIPE_MAX_COLOR_BUFS];
SVGA3dShaderDestToken temp_psiz;
SVGA3dShaderDestToken true_psiz;
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index 0865095..2143546 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -3059,7 +3059,7 @@ emit_ps_postamble(struct svga_shader_emitter *emit)
}
for (i = 0; i PIPE_MAX_COLOR_BUFS; i++) {
- if (SVGA3dShaderGetRegType(emit-true_col[i].value) != 0) {
+ if (SVGA3dShaderGetRegType(emit-true_color_output[i].value) != 0) {
/* Potentially override output colors with white for XOR
* logicop workaround.
*/
@@ -3070,15 +3070,15 @@ emit_ps_postamble(struct svga_shader_emitter *emit)
if (!submit_op1( emit,
inst_token(SVGA3DOP_MOV),
- emit-true_col[i],
+ emit-true_color_output[i],
one ))
return FALSE;
}
else {
if (!submit_op1( emit,
inst_token(SVGA3DOP_MOV),
- emit-true_col[i],
- src(emit-temp_col[i]) ))
+ emit-true_color_output[i],
+ src(emit-temp_color_output[i]) ))
return FALSE;
}
}
--
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 1/6] glsl: Optimize ~~x into x.
On Sun, Jan 19, 2014 at 11:18 PM, Eric Anholt e...@anholt.net wrote:
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 332f0b7..6b0d992 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -218,6 +218,18 @@ ir_algebraic_visitor::handle_expression(ir_expression
*ir)
this-mem_ctx = ralloc_parent(ir);
switch (ir-operation) {
+ case ir_unop_bit_not:
+ if (op_expr[0] == NULL)
+break;
+
+ switch (op_expr[0]-operation) {
+ case ir_unop_bit_not:
+ return abs(op_expr[0]-operands[0]);
With the abs() removed, this and the rest of the series is
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 3/3] svga: implement TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS
Series looks great to me.
Jose
- Original Message -
Fixes several colorbuffer tests, including piglit fbo-drawbuffers-none
for gl_FragColor and glDrawPixels cases.
v2: rework patch to only avoid creating extra shader variants when
TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS is not specified. Per Jose.
Use a write_color0_to_n_cbufs key field to replicate color0 to N
color buffers only when N 0 and WRITES_ALL_CBUFS is set.
---
src/gallium/drivers/svga/svga_state_fs.c |8 +
src/gallium/drivers/svga/svga_tgsi.h |1 +
src/gallium/drivers/svga/svga_tgsi_decl_sm30.c | 37
+++-
src/gallium/drivers/svga/svga_tgsi_insn.c |9 ++
4 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 51d0eb5..1e9fb43 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -276,6 +276,12 @@ make_fs_key(const struct svga_context *svga,
key-sprite_origin_lower_left = (svga-curr.rast-templ.sprite_coord_mode
== PIPE_SPRITE_COORD_LOWER_LEFT);
+ /* SVGA_NEW_FRAME_BUFFER */
+ if (fs-base.info.color0_writes_all_cbufs) {
+ /* Replicate color0 output to N colorbuffers */
+ key-write_color0_to_n_cbufs = svga-curr.framebuffer.nr_cbufs;
+ }
+
return PIPE_OK;
}
@@ -296,6 +302,7 @@ emit_hw_fs(struct svga_context *svga, unsigned dirty)
* SVGA_NEW_RAST
* SVGA_NEW_NEED_SWTNL
* SVGA_NEW_SAMPLER
+* SVGA_NEW_FRAME_BUFFER
*/
ret = make_fs_key( svga, fs, key );
if (ret != PIPE_OK)
@@ -335,6 +342,7 @@ struct svga_tracked_state svga_hw_fs =
SVGA_NEW_NEED_SWTNL |
SVGA_NEW_RAST |
SVGA_NEW_SAMPLER |
+SVGA_NEW_FRAME_BUFFER |
SVGA_NEW_BLEND),
emit_hw_fs
};
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 0e06dbf..591dd6a 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -56,6 +56,7 @@ struct svga_fs_compile_key
unsigned light_twoside:1;
unsigned front_ccw:1;
unsigned white_fragments:1;
+ unsigned write_color0_to_n_cbufs:3;
unsigned num_textures:8;
unsigned num_unnormalized_coords:8;
unsigned sprite_origin_lower_left:1;
diff --git a/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
b/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
index e0a30a5..137afd6 100644
--- a/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
+++ b/src/gallium/drivers/svga/svga_tgsi_decl_sm30.c
@@ -327,14 +327,35 @@ ps30_output(struct svga_shader_emitter *emit,
{
switch (semantic.Name) {
case TGSI_SEMANTIC_COLOR:
- if (emit-unit == PIPE_SHADER_FRAGMENT
- emit-key.fkey.white_fragments) {
-
- emit-output_map[idx] = dst_register( SVGA3DREG_TEMP,
- emit-nr_hw_temp++ );
- emit-temp_color_output[idx] = emit-output_map[idx];
- emit-true_color_output[idx] = dst_register(SVGA3DREG_COLOROUT,
- semantic.Index);
+ if (emit-unit == PIPE_SHADER_FRAGMENT) {
+ if (emit-key.fkey.white_fragments) {
+/* Used for XOR logicop mode */
+emit-output_map[idx] = dst_register( SVGA3DREG_TEMP,
+ emit-nr_hw_temp++ );
+emit-temp_color_output[idx] = emit-output_map[idx];
+emit-true_color_output[idx] = dst_register(SVGA3DREG_COLOROUT,
+semantic.Index);
+ }
+ else if (emit-key.fkey.write_color0_to_n_cbufs) {
+/* We'll write color output [0] to all render targets.
+ * Prepare all the output registers here, but only when the
+ * semantic.Index == 0 so we don't do this more than once.
+ */
+if (semantic.Index == 0) {
+ unsigned i;
+ for (i = 0; i emit-key.fkey.write_color0_to_n_cbufs; i++)
{
+ emit-output_map[i] = dst_register(SVGA3DREG_TEMP,
+ emit-nr_hw_temp++);
+ emit-temp_color_output[i] = emit-output_map[i];
+ emit-true_color_output[i] =
dst_register(SVGA3DREG_COLOROUT,
+i);
+ }
+}
+ }
+ else {
+emit-output_map[idx] =
+ dst_register(SVGA3DREG_COLOROUT, semantic.Index);
+ }
}
else {
emit-output_map[idx] = dst_register( SVGA3DREG_COLOROUT,
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index 2143546..ce00da6 100644
---
[Mesa-dev] [Bug 73808] loader.c(90) : error C2365: 'log' : redefinition; previous definition was 'function'
https://bugs.freedesktop.org/show_bug.cgi?id=73808 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vinson Lee v...@freedesktop.org --- commit d43260b59e1db8261bf581f5316d7634b7102ff6 Author: José Fonseca jfons...@vmware.com Date: Mon Jan 20 13:57:12 2014 + logger: s/\log\/log_/ Currently the MSVC build is broken because of conflicting definitions of 'log' function. I didn't investigate thoroughly, but I suspect the it is conflicting standard math.h's log. log_ is admittedly not a great name, but it is better than a broken build. A better one can be used in a follow-on build. -- 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 4/6] svga: simplify common immediate value construction
Use some new helper functions to make the code much more readable.
And fix wrong value for XPD's w result.
---
src/gallium/drivers/svga/svga_tgsi_emit.h |4 +-
src/gallium/drivers/svga/svga_tgsi_insn.c | 202 -
2 files changed, 115 insertions(+), 91 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_emit.h
b/src/gallium/drivers/svga/svga_tgsi_emit.h
index 28b8e69..d31b866 100644
--- a/src/gallium/drivers/svga/svga_tgsi_emit.h
+++ b/src/gallium/drivers/svga/svga_tgsi_emit.h
@@ -85,8 +85,8 @@ struct svga_shader_emitter
boolean in_main_func;
- boolean created_zero_immediate;
- int zero_immediate_idx;
+ boolean created_common_immediate;
+ int common_immediate_idx;
boolean created_loop_const;
int loop_const_idx;
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index 062579b..88c96c0 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -810,30 +810,6 @@ emit_def_const(struct svga_shader_emitter *emit,
}
-/**
- * Create/emit a constant with values {0, 0.5, -1, 1}.
- * We can swizzle this to produce other useful constants such as
- * {0, 0, 0, 0}, {1, 1, 1, 1}, etc.
- */
-static boolean
-create_zero_immediate( struct svga_shader_emitter *emit )
-{
- unsigned idx = emit-nr_hw_float_const++;
-
- /* Emit the constant (0, 0.5, -1, 1) and use swizzling to generate
-* other useful vectors.
-*/
- if (!emit_def_const( emit, SVGA3D_CONST_TYPE_FLOAT,
-idx, 0, 0.5, -1, 1 ))
- return FALSE;
-
- emit-zero_immediate_idx = idx;
- emit-created_zero_immediate = TRUE;
-
- return TRUE;
-}
-
-
static boolean
create_loop_const( struct svga_shader_emitter *emit )
{
@@ -905,30 +881,93 @@ get_vface( struct svga_shader_emitter *emit )
/**
- * returns {0, 0, 0, 1} immediate
+ * Create/emit a common constant with values {0, 0.5, -1, 1}.
+ * We can swizzle this to produce other useful constants such as
+ * {0, 0, 0, 0}, {1, 1, 1, 1}, etc.
+ */
+static boolean
+create_common_immediate( struct svga_shader_emitter *emit )
+{
+ unsigned idx = emit-nr_hw_float_const++;
+
+ /* Emit the constant (0, 0.5, -1, 1) and use swizzling to generate
+* other useful vectors.
+*/
+ if (!emit_def_const( emit, SVGA3D_CONST_TYPE_FLOAT,
+idx, 0.0f, 0.5f, -1.0f, 1.0f ))
+ return FALSE;
+
+ emit-common_immediate_idx = idx;
+ emit-created_common_immediate = TRUE;
+
+ return TRUE;
+}
+
+
+/**
+ * Return swizzle/position for the given value in the common immediate.
+ */
+static inline unsigned
+common_immediate_swizzle(float value)
+{
+ if (value == 0.0f)
+ return TGSI_SWIZZLE_X;
+ else if (value == 0.5f)
+ return TGSI_SWIZZLE_Y;
+ else if (value == -1.0f)
+ return TGSI_SWIZZLE_Z;
+ else if (value == 1.0f)
+ return TGSI_SWIZZLE_W;
+ else {
+ assert(!illegal value in common_immediate_swizzle);
+ return TGSI_SWIZZLE_X;
+ }
+}
+
+
+/**
+ * Returns an immediate reg where all the terms are either 0, 1, -1 or 0.5
+ */
+static struct src_register
+get_immediate(struct svga_shader_emitter *emit,
+ float x, float y, float z, float w)
+{
+ unsigned sx = common_immediate_swizzle(x);
+ unsigned sy = common_immediate_swizzle(y);
+ unsigned sz = common_immediate_swizzle(z);
+ unsigned sw = common_immediate_swizzle(w);
+ assert(emit-created_common_immediate);
+ assert(emit-common_immediate_idx = 0);
+ return swizzle(src_register(SVGA3DREG_CONST, emit-common_immediate_idx),
+ sx, sy, sz, sw);
+}
+
+
+/**
+ * returns {0, 0, 0, 0} immediate
*/
static struct src_register
get_zero_immediate( struct svga_shader_emitter *emit )
{
- assert(emit-created_zero_immediate);
- assert(emit-zero_immediate_idx = 0);
+ assert(emit-created_common_immediate);
+ assert(emit-common_immediate_idx = 0);
return swizzle(src_register( SVGA3DREG_CONST,
-emit-zero_immediate_idx),
- 0, 0, 0, 3);
+emit-common_immediate_idx),
+ 0, 0, 0, 0);
}
/**
- * returns {1, 1, 1, -1} immediate
+ * returns {1, 1, 1, 1} immediate
*/
static struct src_register
-get_pos_neg_one_immediate( struct svga_shader_emitter *emit )
+get_one_immediate( struct svga_shader_emitter *emit )
{
- assert(emit-created_zero_immediate);
- assert(emit-zero_immediate_idx = 0);
+ assert(emit-created_common_immediate);
+ assert(emit-common_immediate_idx = 0);
return swizzle(src_register( SVGA3DREG_CONST,
-emit-zero_immediate_idx),
- 3, 3, 3, 2);
+emit-common_immediate_idx),
+ 3, 3, 3, 3);
}
@@ -938,9 +977,9 @@ get_pos_neg_one_immediate( struct svga_shader_emitter *emit
)
static struct src_register
get_half_immediate( struct svga_shader_emitter
[Mesa-dev] [PATCH 5/6] svga: whitespace, formatting fixes in svga_state_framebuffer.c
---
src/gallium/drivers/svga/svga_state_framebuffer.c | 57 ++---
1 file changed, 26 insertions(+), 31 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_framebuffer.c
b/src/gallium/drivers/svga/svga_state_framebuffer.c
index 6976d37..1497116 100644
--- a/src/gallium/drivers/svga/svga_state_framebuffer.c
+++ b/src/gallium/drivers/svga/svga_state_framebuffer.c
@@ -66,22 +66,22 @@ emit_framebuffer( struct svga_context *svga,
* We need to reemit non-null surface bindings, even when they are not
* dirty, to ensure that the resources are paged in.
*/
-
+
for (i = 0; i svgascreen-max_color_buffers; i++) {
if (curr-cbufs[i] != hw-cbufs[i] ||
(reemit hw-cbufs[i])) {
if (svga-curr.nr_fbs++ MAX_RT_PER_BATCH)
return PIPE_ERROR_OUT_OF_MEMORY;
- ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_COLOR0 + i,
curr-cbufs[i]);
+ ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_COLOR0 + i,
+ curr-cbufs[i]);
if (ret != PIPE_OK)
return ret;
-
+
pipe_surface_reference(hw-cbufs[i], curr-cbufs[i]);
}
}
-
if (curr-zsbuf != hw-zsbuf ||
(reemit hw-zsbuf)) {
ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_DEPTH, curr-zsbuf);
@@ -90,7 +90,8 @@ emit_framebuffer( struct svga_context *svga,
if (curr-zsbuf
curr-zsbuf-format == PIPE_FORMAT_S8_UINT_Z24_UNORM) {
- ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_STENCIL,
curr-zsbuf);
+ ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_STENCIL,
+ curr-zsbuf);
if (ret != PIPE_OK)
return ret;
}
@@ -99,7 +100,7 @@ emit_framebuffer( struct svga_context *svga,
if (ret != PIPE_OK)
return ret;
}
-
+
pipe_surface_reference(hw-zsbuf, curr-zsbuf);
}
@@ -129,7 +130,8 @@ svga_reemit_framebuffer_bindings(struct svga_context *svga)
for (i = 0; i svgascreen-max_color_buffers; i++) {
if (hw-cbufs[i]) {
- ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_COLOR0 + i,
hw-cbufs[i]);
+ ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_COLOR0 + i,
+ hw-cbufs[i]);
if (ret != PIPE_OK) {
return ret;
}
@@ -163,7 +165,7 @@ svga_reemit_framebuffer_bindings(struct svga_context *svga)
}
-struct svga_tracked_state svga_hw_framebuffer =
+struct svga_tracked_state svga_hw_framebuffer =
{
hw framebuffer state,
SVGA_NEW_FRAME_BUFFER,
@@ -173,7 +175,7 @@ struct svga_tracked_state svga_hw_framebuffer =
-/***
+/***
*/
static enum pipe_error
@@ -198,8 +200,8 @@ emit_viewport( struct svga_context *svga,
float fx =viewport-scale[0] * -1.0f + viewport-translate[0];
float fy = flip * viewport-scale[1] * -1.0f + viewport-translate[1];
- float fw =viewport-scale[0] * 2.0f;
- float fh = flip * viewport-scale[1] * 2.0f;
+ float fw =viewport-scale[0] * 2.0f;
+ float fh = flip * viewport-scale[1] * 2.0f;
memset( prescale, 0, sizeof(prescale) );
@@ -225,13 +227,11 @@ emit_viewport( struct svga_context *svga,
prescale.translate[3] = 0;
prescale.enabled = TRUE;
-
-
if (fw 0) {
prescale.scale[0] *= -1.0f;
prescale.translate[0] += -fw;
fw = -fw;
- fx =viewport-scale[0] * 1.0f + viewport-translate[0];
+ fx = viewport-scale[0] * 1.0f + viewport-translate[0];
}
if (fh 0.0) {
@@ -244,7 +244,7 @@ emit_viewport( struct svga_context *svga,
if (fx 0) {
prescale.translate[0] += fx;
- prescale.scale[0] *= fw / (fw + fx);
+ prescale.scale[0] *= fw / (fw + fx);
fw += fx;
fx = 0.0f;
}
@@ -256,17 +256,16 @@ emit_viewport( struct svga_context *svga,
else {
prescale.translate[1] += fy;
}
- prescale.scale[1] *= fh / (fh + fy);
+ prescale.scale[1] *= fh / (fh + fy);
fh += fy;
fy = 0.0f;
}
if (fx + fw fb_width) {
- prescale.scale[0] *= fw / (fb_width - fx);
+ prescale.scale[0] *= fw / (fb_width - fx);
prescale.translate[0] -= fx * (fw / (fb_width - fx));
prescale.translate[0] += fx;
fw = fb_width - fx;
-
}
if (fy + fh fb_height) {
@@ -289,7 +288,6 @@ emit_viewport( struct svga_context *svga,
goto out;
}
-
/* D3D viewport is integer space. Convert fx,fy,etc. to
* integers.
*
@@ -315,7 +313,6 @@ emit_viewport( struct svga_context *svga,
rect.w,
rect.h);
-
/* Finally, to get GL rasterization rules, need to tweak the
* screen-space coordinates slightly relative to D3D which is
* what hardware
[Mesa-dev] [PATCH 2/6] svga: assorted cleanups in shader code
---
src/gallium/drivers/svga/svga_state_fs.c |1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 36f2cd5..1afdae9 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -293,7 +293,6 @@ make_fs_key(const struct svga_context *svga,
}
-
static enum pipe_error
emit_hw_fs(struct svga_context *svga, unsigned dirty)
{
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] svga: rename shader_result - variant
To be more consisten with other parts of gallium. Plus, update/add
various comments.
---
src/gallium/drivers/svga/svga_context.h | 15 ++--
src/gallium/drivers/svga/svga_pipe_fs.c | 18 ++---
src/gallium/drivers/svga/svga_pipe_vs.c | 18 ++---
src/gallium/drivers/svga/svga_state_constants.c | 24 +++
src/gallium/drivers/svga/svga_state_fs.c| 83 --
src/gallium/drivers/svga/svga_state_vs.c| 86 ---
src/gallium/drivers/svga/svga_tgsi.c| 34 -
src/gallium/drivers/svga/svga_tgsi.h| 22 +++---
8 files changed, 158 insertions(+), 142 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_context.h
b/src/gallium/drivers/svga/svga_context.h
index dee0cec..f75fac5 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -50,7 +50,7 @@
struct draw_vertex_shader;
struct draw_fragment_shader;
-struct svga_shader_result;
+struct svga_shader_variant;
struct SVGACmdMemory;
struct util_bitmask;
@@ -61,11 +61,13 @@ struct svga_shader
struct tgsi_shader_info info;
- struct svga_shader_result *results;
+ /** Head of linked list of variants */
+ struct svga_shader_variant *variants;
unsigned id; /** for debugging only */
};
+
struct svga_fragment_shader
{
struct svga_shader base;
@@ -78,6 +80,7 @@ struct svga_fragment_shader
int8_t generic_remap_table[MAX_GENERIC_VARYING];
};
+
struct svga_vertex_shader
{
struct svga_shader base;
@@ -282,8 +285,8 @@ struct svga_hw_draw_state
unsigned ts[SVGA3D_PIXEL_SAMPLERREG_MAX][SVGA3D_TS_MAX];
float cb[PIPE_SHADER_TYPES][SVGA3D_CONSTREG_MAX][4];
- struct svga_shader_result *fs;
- struct svga_shader_result *vs;
+ struct svga_shader_variant *fs;
+ struct svga_shader_variant *vs;
struct svga_hw_view_state views[PIPE_MAX_SAMPLERS];
unsigned num_views;
@@ -405,8 +408,8 @@ struct svga_context
#define SVGA_NEW_NEED_PIPELINE 0x10
#define SVGA_NEW_NEED_SWVFETCH 0x20
#define SVGA_NEW_NEED_SWTNL 0x40
-#define SVGA_NEW_FS_RESULT 0x80
-#define SVGA_NEW_VS_RESULT 0x100
+#define SVGA_NEW_FS_VARIANT 0x80
+#define SVGA_NEW_VS_VARIANT 0x100
#define SVGA_NEW_TEXTURE_FLAGS 0x400
#define SVGA_NEW_STENCIL_REF 0x800
diff --git a/src/gallium/drivers/svga/svga_pipe_fs.c
b/src/gallium/drivers/svga/svga_pipe_fs.c
index 4c04ea0..7bdcd8e 100644
--- a/src/gallium/drivers/svga/svga_pipe_fs.c
+++ b/src/gallium/drivers/svga/svga_pipe_fs.c
@@ -88,33 +88,33 @@ svga_delete_fs_state(struct pipe_context *pipe, void
*shader)
{
struct svga_context *svga = svga_context(pipe);
struct svga_fragment_shader *fs = (struct svga_fragment_shader *) shader;
- struct svga_shader_result *result, *tmp;
+ struct svga_shader_variant *variant, *tmp;
enum pipe_error ret;
svga_hwtnl_flush_retry(svga);
draw_delete_fragment_shader(svga-swtnl.draw, fs-draw_shader);
- for (result = fs-base.results; result; result = tmp) {
- tmp = result-next;
+ for (variant = fs-base.variants; variant; variant = tmp) {
+ tmp = variant-next;
- ret = SVGA3D_DestroyShader(svga-swc, result-id, SVGA3D_SHADERTYPE_PS);
+ ret = SVGA3D_DestroyShader(svga-swc, variant-id, SVGA3D_SHADERTYPE_PS);
if (ret != PIPE_OK) {
svga_context_flush(svga, NULL);
- ret = SVGA3D_DestroyShader(svga-swc, result-id,
+ ret = SVGA3D_DestroyShader(svga-swc, variant-id,
SVGA3D_SHADERTYPE_PS);
assert(ret == PIPE_OK);
}
- util_bitmask_clear(svga-fs_bm, result-id);
+ util_bitmask_clear(svga-fs_bm, variant-id);
- svga_destroy_shader_result(result);
+ svga_destroy_shader_variant(variant);
/*
- * Remove stale references to this result to ensure a new result on the
+ * Remove stale references to this variant to ensure a new variant on the
* same address will be detected as a change.
*/
- if (result == svga-state.hw_draw.fs)
+ if (variant == svga-state.hw_draw.fs)
svga-state.hw_draw.fs = NULL;
}
diff --git a/src/gallium/drivers/svga/svga_pipe_vs.c
b/src/gallium/drivers/svga/svga_pipe_vs.c
index 72e2fc1..fd132eb 100644
--- a/src/gallium/drivers/svga/svga_pipe_vs.c
+++ b/src/gallium/drivers/svga/svga_pipe_vs.c
@@ -148,33 +148,33 @@ svga_delete_vs_state(struct pipe_context *pipe, void
*shader)
{
struct svga_context *svga = svga_context(pipe);
struct svga_vertex_shader *vs = (struct svga_vertex_shader *)shader;
- struct svga_shader_result *result, *tmp;
+ struct svga_shader_variant *variant, *tmp;
enum pipe_error ret;
svga_hwtnl_flush_retry(svga);
draw_delete_vertex_shader(svga-swtnl.draw, vs-draw_shader);
- for (result = vs-base.results; result; result = tmp) {
- tmp =
[Mesa-dev] [PATCH 6/6] svga: minor code movement in svga_tgsi_insn.c
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 94 ++---
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index 88c96c0..4d78e96 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -729,45 +729,6 @@ alias_src_dst(struct src_register src,
/**
- * Translate/emit a LRP (linear interpolation) instruction.
- */
-static boolean
-submit_lrp(struct svga_shader_emitter *emit,
- SVGA3dShaderDestToken dst,
- struct src_register src0,
- struct src_register src1,
- struct src_register src2)
-{
- SVGA3dShaderDestToken tmp;
- boolean need_dst_tmp = FALSE;
-
- /* The dst reg must be a temporary, and not be the same as src0 or src2 */
- if (SVGA3dShaderGetRegType(dst.value) != SVGA3DREG_TEMP ||
- alias_src_dst(src0, dst) ||
- alias_src_dst(src2, dst))
- need_dst_tmp = TRUE;
-
- if (need_dst_tmp) {
- tmp = get_temp( emit );
- tmp.mask = dst.mask;
- }
- else {
- tmp = dst;
- }
-
- if (!submit_op3(emit, inst_token( SVGA3DOP_LRP ), tmp, src0, src1, src2))
- return FALSE;
-
- if (need_dst_tmp) {
- if (!submit_op1(emit, inst_token( SVGA3DOP_MOV ), dst, src( tmp )))
- return FALSE;
- }
-
- return TRUE;
-}
-
-
-/**
* Helper for emitting SVGA immediate values using the SVGA3DOP_DEF[I]
* instructions.
*/
@@ -1092,20 +1053,20 @@ emit_if(struct svga_shader_emitter *emit,
static boolean
-emit_endif(struct svga_shader_emitter *emit,
- const struct tgsi_full_instruction *insn)
+emit_else(struct svga_shader_emitter *emit,
+ const struct tgsi_full_instruction *insn)
{
- emit-dynamic_branching_level--;
-
- return emit_instruction(emit, inst_token(SVGA3DOP_ENDIF));
+ return emit_instruction(emit, inst_token(SVGA3DOP_ELSE));
}
static boolean
-emit_else(struct svga_shader_emitter *emit,
- const struct tgsi_full_instruction *insn)
+emit_endif(struct svga_shader_emitter *emit,
+ const struct tgsi_full_instruction *insn)
{
- return emit_instruction(emit, inst_token(SVGA3DOP_ELSE));
+ emit-dynamic_branching_level--;
+
+ return emit_instruction(emit, inst_token(SVGA3DOP_ENDIF));
}
@@ -2335,6 +2296,45 @@ emit_xpd(struct svga_shader_emitter *emit,
/**
+ * Emit a LRP (linear interpolation) instruction.
+ */
+static boolean
+submit_lrp(struct svga_shader_emitter *emit,
+ SVGA3dShaderDestToken dst,
+ struct src_register src0,
+ struct src_register src1,
+ struct src_register src2)
+{
+ SVGA3dShaderDestToken tmp;
+ boolean need_dst_tmp = FALSE;
+
+ /* The dst reg must be a temporary, and not be the same as src0 or src2 */
+ if (SVGA3dShaderGetRegType(dst.value) != SVGA3DREG_TEMP ||
+ alias_src_dst(src0, dst) ||
+ alias_src_dst(src2, dst))
+ need_dst_tmp = TRUE;
+
+ if (need_dst_tmp) {
+ tmp = get_temp( emit );
+ tmp.mask = dst.mask;
+ }
+ else {
+ tmp = dst;
+ }
+
+ if (!submit_op3(emit, inst_token( SVGA3DOP_LRP ), tmp, src0, src1, src2))
+ return FALSE;
+
+ if (need_dst_tmp) {
+ if (!submit_op1(emit, inst_token( SVGA3DOP_MOV ), dst, src( tmp )))
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
+
+/**
* Translate/emit LRP (Linear Interpolation) instruction.
*/
static boolean
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] svga: add comments, etc to svga_tgsi_insn.c code
To make things a little easier to understand for newcomers.
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 194 -
1 file changed, 163 insertions(+), 31 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index ce00da6..062579b 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -56,8 +56,7 @@ translate_opcode(uint opcode)
case TGSI_OPCODE_NOP:return SVGA3DOP_NOP;
case TGSI_OPCODE_NRM4: return SVGA3DOP_NRM;
default:
- debug_printf(Unkown opcode %u\n, opcode);
- assert( 0 );
+ assert(!svga: unexpected opcode in translate_opcode());
return SVGA3DOP_LAST_INST;
}
}
@@ -75,12 +74,17 @@ translate_file(unsigned file)
case TGSI_FILE_SAMPLER: return SVGA3DREG_SAMPLER;
case TGSI_FILE_ADDRESS: return SVGA3DREG_ADDR;
default:
- assert( 0 );
+ assert(!svga: unexpected register file in translate_file());
return SVGA3DREG_TEMP;
}
}
+/**
+ * Translate a TGSI destination register to an SVGA3DShaderDestToken.
+ * \param insn the TGSI instruction
+ * \param idx which TGSI dest register to translate (usually (always?) zero)
+ */
static SVGA3dShaderDestToken
translate_dst_register( struct svga_shader_emitter *emit,
const struct tgsi_full_instruction *insn,
@@ -184,6 +188,9 @@ svga_arl_adjustment( const struct svga_shader_emitter *emit
)
}
+/**
+ * Translate a TGSI src register to a src_register.
+ */
static struct src_register
translate_src_register( const struct svga_shader_emitter *emit,
const struct tgsi_full_src_register *reg )
@@ -300,6 +307,9 @@ release_temp( struct svga_shader_emitter *emit,
}
+/**
+ * Release all temps.
+ */
static void
reset_temp_regs(struct svga_shader_emitter *emit)
{
@@ -472,6 +482,9 @@ emit_repl(struct svga_shader_emitter *emit,
}
+/**
+ * Submit/emit an instruction with zero operands.
+ */
static boolean
submit_op0(struct svga_shader_emitter *emit,
SVGA3dShaderInstToken inst,
@@ -482,6 +495,9 @@ submit_op0(struct svga_shader_emitter *emit,
}
+/**
+ * Submit/emit an instruction with one operand.
+ */
static boolean
submit_op1(struct svga_shader_emitter *emit,
SVGA3dShaderInstToken inst,
@@ -493,6 +509,8 @@ submit_op1(struct svga_shader_emitter *emit,
/**
+ * Submit/emit an instruction with two operands.
+ *
* SVGA shaders may not refer to 1 constant register in a single
* instruction. This function checks for that usage and inserts a
* move to temporary if detected.
@@ -543,6 +561,8 @@ submit_op2(struct svga_shader_emitter *emit,
/**
+ * Submit/emit an instruction with three operands.
+ *
* SVGA shaders may not refer to 1 constant register in a single
* instruction. This function checks for that usage and inserts a
* move to temporary if detected.
@@ -613,6 +633,8 @@ submit_op3(struct svga_shader_emitter *emit,
/**
+ * Submit/emit an instruction with four operands.
+ *
* SVGA shaders may not refer to 1 constant register in a single
* instruction. This function checks for that usage and inserts a
* move to temporary if detected.
@@ -706,6 +728,9 @@ alias_src_dst(struct src_register src,
}
+/**
+ * Translate/emit a LRP (linear interpolation) instruction.
+ */
static boolean
submit_lrp(struct svga_shader_emitter *emit,
SVGA3dShaderDestToken dst,
@@ -742,6 +767,10 @@ submit_lrp(struct svga_shader_emitter *emit,
}
+/**
+ * Helper for emitting SVGA immediate values using the SVGA3DOP_DEF[I]
+ * instructions.
+ */
static boolean
emit_def_const(struct svga_shader_emitter *emit,
SVGA3dShaderConstType type,
@@ -781,6 +810,11 @@ emit_def_const(struct svga_shader_emitter *emit,
}
+/**
+ * Create/emit a constant with values {0, 0.5, -1, 1}.
+ * We can swizzle this to produce other useful constants such as
+ * {0, 0, 0, 0}, {1, 1, 1, 1}, etc.
+ */
static boolean
create_zero_immediate( struct svga_shader_emitter *emit )
{
@@ -943,8 +977,8 @@ get_fake_arl_const( struct svga_shader_emitter *emit )
/**
- * Return the register which holds the current dimenions of the
- * texture bound to the given sampler
+ * Return a register which holds the width and height of the texture
+ * currently bound to the given sampler.
*/
static struct src_register
get_tex_dimensions( struct svga_shader_emitter *emit, int sampler_num )
@@ -1241,6 +1275,9 @@ emit_nrm(struct svga_shader_emitter *emit,
}
+/**
+ * Sine / Cosine helper function.
+ */
static boolean
do_emit_sincos(struct svga_shader_emitter *emit,
SVGA3dShaderDestToken dst,
@@ -1251,6 +1288,9 @@ do_emit_sincos(struct svga_shader_emitter *emit,
}
+/**
+ * Translate/emit a TGSI SIN, COS or CSC instruction.
+ */
static boolean
emit_sincos(struct svga_shader_emitter *emit,
const struct
[Mesa-dev] [PATCH 1/4] radeon / r200: Fix incompatible pointer type warning
From: Ian Romanick ian.d.roman...@intel.com
When parameters were removed from dd_function_table::Viewport (commit
065bd6ff), radeon_viewport (in both radeon and r200) started generating
a warning.
radeon_common.c: In function 'r200_radeon_viewport':
radeon_common.c:415:15: warning: assignment from incompatible pointer type
[enabled by default]
radeon_common.c:419:23: warning: assignment from incompatible pointer type
[enabled by default]
I didn't notice this initially, and it's harmless because the function is
never called through the incorrectly typed pointer.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Marek Olšák marek.ol...@amd.com
---
src/mesa/drivers/dri/radeon/radeon_common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c
b/src/mesa/drivers/dri/radeon/radeon_common.c
index 2df4388..5c2b823 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common.c
@@ -400,8 +400,7 @@ void radeon_viewport(struct gl_context *ctx)
{
radeonContextPtr radeon = RADEON_CONTEXT(ctx);
__DRIcontext *driContext = radeon-dri.context;
- void (*old_viewport)(struct gl_context *ctx, GLint x, GLint y,
-GLsizei w, GLsizei h);
+ void (*old_viewport)(struct gl_context *ctx);
if (_mesa_is_winsys_fbo(ctx-DrawBuffer)) {
if (radeon-is_front_buffer_rendering) {
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] radeon / r200: Fix 'empty body' warning
From: Ian Romanick ian.d.roman...@intel.com
radeon_common.c: In function 'radeon_draw_buffer':
radeon_common.c:237:3: warning: suggest braces around empty body in an 'if'
statement [-Wempty-body]
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Marek Olšák marek.ol...@amd.com
---
src/mesa/drivers/dri/radeon/radeon_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c
b/src/mesa/drivers/dri/radeon/radeon_common.c
index 5c2b823..ab1b719 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common.c
@@ -233,9 +233,9 @@ void radeon_draw_buffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
return;
}
- if (fb-Name)
+ if (fb-Name) {
;/* do something depthy/stencily TODO */
-
+}
/* none */
if (fb-Name == 0) {
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] radeon / r200: Remove unused 'dostate' parameter
From: Ian Romanick ian.d.roman...@intel.com This parameter hasn't been used since January 2010 (commit 29e02c7). Fixes the following warning in both radeon and r200: radeon_common.c: In function 'r200_rcommonBeginBatch': radeon_common.c:762:14: warning: unused parameter 'dostate' [-Wunused-parameter] Note that now BEGIN_BATCH and BEGIN_PATCH_NO_AUTOSTATE are identical. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: Alex Deucher alexander.deuc...@amd.com Cc: Marek Olšák marek.ol...@amd.com --- src/mesa/drivers/dri/radeon/radeon_cmdbuf.h | 5 ++--- src/mesa/drivers/dri/radeon/radeon_common.c | 1 - 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/radeon/radeon_cmdbuf.h b/src/mesa/drivers/dri/radeon/radeon_cmdbuf.h index efccc81..63f51c3 100644 --- a/src/mesa/drivers/dri/radeon/radeon_cmdbuf.h +++ b/src/mesa/drivers/dri/radeon/radeon_cmdbuf.h @@ -9,7 +9,6 @@ void rcommonDestroyCmdBuf(radeonContextPtr rmesa); void rcommonBeginBatch(radeonContextPtr rmesa, int n, - int dostate, const char *file, const char *function, int line); @@ -32,12 +31,12 @@ void rcommonBeginBatch(radeonContextPtr rmesa, * Prepare writing n dwords to the command buffer, * including producing any necessary state emits on buffer wraparound. */ -#define BEGIN_BATCH(n) rcommonBeginBatch(b_l_rmesa, n, 1, __FILE__, __FUNCTION__, __LINE__) +#define BEGIN_BATCH(n) rcommonBeginBatch(b_l_rmesa, n, __FILE__, __FUNCTION__, __LINE__) /** * Same as BEGIN_BATCH, but do not cause automatic state emits. */ -#define BEGIN_BATCH_NO_AUTOSTATE(n) rcommonBeginBatch(b_l_rmesa, n, 0, __FILE__, __FUNCTION__, __LINE__) +#define BEGIN_BATCH_NO_AUTOSTATE(n) rcommonBeginBatch(b_l_rmesa, n, __FILE__, __FUNCTION__, __LINE__) /** * Write one dword to the command buffer. diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c b/src/mesa/drivers/dri/radeon/radeon_common.c index ab1b719..319a38d 100644 --- a/src/mesa/drivers/dri/radeon/radeon_common.c +++ b/src/mesa/drivers/dri/radeon/radeon_common.c @@ -759,7 +759,6 @@ void rcommonDestroyCmdBuf(radeonContextPtr rmesa) } void rcommonBeginBatch(radeonContextPtr rmesa, int n, - int dostate, const char *file, const char *function, int line) -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] radeon / r200: Eliminate BEGIN_BATCH_NO_AUTOSTATE
From: Ian Romanick ian.d.roman...@intel.com
Sed job:
grep -lr BEGIN_BATCH_NO_AUTOSTATE src/mesa/drivers/dri/ | while read f
do
cat $f | sed 's/BEGIN_BATCH_NO_AUTOSTATE/BEGIN_BATCH/g' x
mv x $f
done
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Marek Olšák marek.ol...@amd.com
---
src/mesa/drivers/dri/r200/r200_blit.c | 2 +-
src/mesa/drivers/dri/r200/r200_cmdbuf.c | 2 +-
src/mesa/drivers/dri/r200/r200_context.c| 2 +-
src/mesa/drivers/dri/r200/r200_state_init.c | 18 +-
src/mesa/drivers/dri/radeon/radeon_blit.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_cmdbuf.h | 9 ++---
src/mesa/drivers/dri/radeon/radeon_common.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_context.c| 2 +-
src/mesa/drivers/dri/radeon/radeon_ioctl.c | 4 ++--
src/mesa/drivers/dri/radeon/radeon_queryobj.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_state_init.c | 14 +++---
11 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_blit.c
b/src/mesa/drivers/dri/r200/r200_blit.c
index a6a1a3f..666fbad 100644
--- a/src/mesa/drivers/dri/r200/r200_blit.c
+++ b/src/mesa/drivers/dri/r200/r200_blit.c
@@ -337,7 +337,7 @@ static inline void emit_cb_setup(struct r200_context *r200,
if (bo-flags RADEON_BO_FLAGS_MICRO_TILE)
dst_pitch |= R200_COLOR_MICROTILE_ENABLE;
-BEGIN_BATCH_NO_AUTOSTATE(22);
+BEGIN_BATCH(22);
OUT_BATCH_REGVAL(R200_RE_AUX_SCISSOR_CNTL, 0);
OUT_BATCH_REGVAL(R200_RE_CNTL, 0);
OUT_BATCH_REGVAL(RADEON_RE_TOP_LEFT, 0);
diff --git a/src/mesa/drivers/dri/r200/r200_cmdbuf.c
b/src/mesa/drivers/dri/r200/r200_cmdbuf.c
index b351c20..1e6c0d8 100644
--- a/src/mesa/drivers/dri/r200/r200_cmdbuf.c
+++ b/src/mesa/drivers/dri/r200/r200_cmdbuf.c
@@ -211,7 +211,7 @@ void r200EmitMaxVtxIndex(r200ContextPtr rmesa, int count)
{
BATCH_LOCALS(rmesa-radeon);
- BEGIN_BATCH_NO_AUTOSTATE(2);
+ BEGIN_BATCH(2);
OUT_BATCH(CP_PACKET0(R200_SE_VF_MAX_VTX_INDX, 0));
OUT_BATCH(count);
END_BATCH();
diff --git a/src/mesa/drivers/dri/r200/r200_context.c
b/src/mesa/drivers/dri/r200/r200_context.c
index d915207..47269b2 100644
--- a/src/mesa/drivers/dri/r200/r200_context.c
+++ b/src/mesa/drivers/dri/r200/r200_context.c
@@ -169,7 +169,7 @@ static void r200_emit_query_finish(radeonContextPtr radeon)
BATCH_LOCALS(radeon);
struct radeon_query_object *query = radeon-query.current;
- BEGIN_BATCH_NO_AUTOSTATE(4);
+ BEGIN_BATCH(4);
OUT_BATCH(CP_PACKET0(RADEON_RB3D_ZPASS_ADDR, 0));
OUT_BATCH_RELOC(0, query-bo, query-curr_offset, 0, RADEON_GEM_DOMAIN_GTT,
0);
END_BATCH();
diff --git a/src/mesa/drivers/dri/r200/r200_state_init.c
b/src/mesa/drivers/dri/r200/r200_state_init.c
index bf9cef0..79aa753 100644
--- a/src/mesa/drivers/dri/r200/r200_state_init.c
+++ b/src/mesa/drivers/dri/r200/r200_state_init.c
@@ -293,7 +293,7 @@ VP_CHECK( tcl_vpp_size_add4,
ctx-VertexProgram.Current-Base.NumNativeParameter
_start = h.veclinear.addr_lo | (h.veclinear.addr_hi 8); \
_sz = h.veclinear.count * 4; \
if (_sz) { \
-BEGIN_BATCH_NO_AUTOSTATE(dwords); \
+BEGIN_BATCH(dwords); \
OUT_BATCH(CP_PACKET0(RADEON_SE_TCL_STATE_FLUSH, 0)); \
OUT_BATCH(0); \
OUT_BATCH(CP_PACKET0(R200_SE_TCL_VECTOR_INDX_REG, 0)); \
@@ -346,7 +346,7 @@ static void mtl_emit(struct gl_context *ctx, struct
radeon_state_atom *atom)
BATCH_LOCALS(r200-radeon);
uint32_t dwords = atom-check(ctx, atom);
- BEGIN_BATCH_NO_AUTOSTATE(dwords);
+ BEGIN_BATCH(dwords);
OUT_VEC(atom-cmd[MTL_CMD_0], (atom-cmd+1));
OUT_SCL2(atom-cmd[MTL_CMD_1], (atom-cmd + 18));
END_BATCH();
@@ -358,7 +358,7 @@ static void lit_emit(struct gl_context *ctx, struct
radeon_state_atom *atom)
BATCH_LOCALS(r200-radeon);
uint32_t dwords = atom-check(ctx, atom);
- BEGIN_BATCH_NO_AUTOSTATE(dwords);
+ BEGIN_BATCH(dwords);
OUT_VEC(atom-cmd[LIT_CMD_0], atom-cmd+1);
OUT_SCL(atom-cmd[LIT_CMD_1], atom-cmd+LIT_CMD_1+1);
END_BATCH();
@@ -370,7 +370,7 @@ static void ptp_emit(struct gl_context *ctx, struct
radeon_state_atom *atom)
BATCH_LOCALS(r200-radeon);
uint32_t dwords = atom-check(ctx, atom);
- BEGIN_BATCH_NO_AUTOSTATE(dwords);
+ BEGIN_BATCH(dwords);
OUT_VEC(atom-cmd[PTP_CMD_0], atom-cmd+1);
OUT_VEC(atom-cmd[PTP_CMD_1], atom-cmd+PTP_CMD_1+1);
END_BATCH();
@@ -391,7 +391,7 @@ static void scl_emit(struct gl_context *ctx, struct
radeon_state_atom *atom)
BATCH_LOCALS(r200-radeon);
uint32_t dwords = atom-check(ctx, atom);
- BEGIN_BATCH_NO_AUTOSTATE(dwords);
+ BEGIN_BATCH(dwords);
OUT_SCL(atom-cmd[0], atom-cmd+1);
END_BATCH();
}
@@ -403,7 +403,7 @@ static void
Re: [Mesa-dev] [PATCH] docs: remove some ancient README.* files
Mem-or-is! Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 01/20/2014 12:05 PM, Brian Paul wrote: None of this info is relevant anymore. --- docs/README.CYGWIN | 256 --- docs/README.MITS| 102 docs/README.QUAKE | 207 - docs/README.THREADS | 52 --- 4 files changed, 617 deletions(-) delete mode 100644 docs/README.CYGWIN delete mode 100644 docs/README.MITS delete mode 100644 docs/README.QUAKE delete mode 100644 docs/README.THREADS diff --git a/docs/README.CYGWIN b/docs/README.CYGWIN deleted file mode 100644 index 58d5af3..000 --- a/docs/README.CYGWIN +++ /dev/null @@ -1,256 +0,0 @@ - - Mesa Cygwin/X11 Information - - -WARNING -=== - -If you installed X11 (packages xorg-x11-devel and xorg-x11-bin-dlls ) with the -latest setup.exe from Cygwin the GL (Mesa) libraries and include are already -installed in /usr/X11R6. - -The following will explain how to replace them. - -Installation - - -How to compile Mesa on Cygwin/X11 systems: - -1. Shared libs: -type 'make cygwin-sl'. - -When finished, the Mesa DLL will be in the Mesa-x.y/lib/ and -Mesa-x.y/bin directories. - - -2. Static libs: -type 'make cygwin-static'. -When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory. - -Header and library files: - After you've compiled Mesa and tried the demos I recommend the following - procedure for installing Mesa. - - Copy the Mesa include/GL directory to /usr/X11R6/include: - cp -a include/GL /usr/X11R6/include - - Copy the Mesa library files to /usr/X11R6/lib: - cp -a lib/* /usr/X11R6ocal/lib - - Copy the Mesa bin files (used by the DLL stuff) to /usr/X11R6/bin: - cp -a lib/cyg* /usr/X11R6/bin - -Xt/Motif widgets: - If you want to use Mesa or OpenGL in your Xt/Motif program you can build - the widgets found in either the widgets-mesa or widgets-sgi directories. - The former were written for Mesa and the later are the original SGI - widgets. Look in those directories for more information. - For the Motif widgets you must have downloaded the lesstif package. - - -Using the library -= - -Configuration options: - The file src/mesa/main/config.h has many parameters which you can adjust - such as maximum number of lights, clipping planes, maximum texture size, - etc. In particular, you may want to change DEPTH_BITS from 16 to 32 - if a 16-bit depth buffer isn't precise enough for your application. - - -Shared libraries: - If you compile shared libraries (Win32 DLLS) you may have to set an - environment variable to specify where the Mesa libraries are located. - Set the PATH variable to include /your-dir/Mesa-2.6/bin. - Otherwise, when you try to run a demo it may fail with a message saying - that one or more DLL couldn't be found. - - -Xt/Motif Widgets: - Two versions of the Xt/Motif OpenGL drawing area widgets are included: - - widgets-sgi/ SGI's stock widgets - widgets-mesa/ Mesa-tuned widgets - - Look in those directories for details - - -Togl: - Togl is an OpenGL/Mesa widget for Tcl/Tk. - See http://togl.sourceforge.net for more information. - - - -X Display Modes: - Mesa supports RGB(A) rendering into almost any X visual type and depth. - - The glXChooseVisual function tries its best to pick an appropriate visual - for the given attribute list. However, if this doesn't suit your needs - you can force Mesa to use any X visual you want (any supported by your - X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL - environment variables. When an RGB visual is requested, glXChooseVisual - will first look if the MESA_RGB_VISUAL variable is defined. If so, it - will try to use the specified visual. Similarly, when a color index - visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL - variable. - - The format of accepted values is: visual-class depth - Here are some examples: - - using the C-shell: - % setenv MESA_RGB_VISUAL TrueColor 8 // 8-bit TrueColor - % setenv MESA_CI_VISUAL PseudoColor 12// 12-bit PseudoColor - % setenv MESA_RGB_VISUAL PseudoColor 8// 8-bit PseudoColor - - using the KornShell: - $ export MESA_RGB_VISUAL=TrueColor 8 - $ export MESA_CI_VISUAL=PseudoColor 12 - $ export MESA_RGB_VISUAL=PseudoColor 8 - - -Double buffering: - Mesa can use either an X Pixmap or XImage as the backbuffer when in - double buffer mode. Using GLX, the default is to use an XImage. The - MESA_BACK_BUFFER environment variable can override this. The valid - values for MESA_BACK_BUFFER are: Pixmap and XImage (only the first - letter is checked, case
Re: [Mesa-dev] [PATCH v3 1/1] clover: Don't crash on NULL global buffer objects.
On Sat, 2014-01-18 at 13:34 +0100, Francisco Jerez wrote:
Jan Vesely jan.ves...@rutgers.edu writes:
Specs say If the argument is a buffer object, the arg_value
pointer can be NULL or point to a NULL value in which case a NULL
value will be used as the value for the argument declared as a
pointer to __global or __constant memory in the kernel.
So don't crash when somebody does that.
v2: Insert NULL into input buffer instead of buffer handle pair
Fix constant_argument too
Drop r600 driver changes
v3: Fix inserting NULL pointer
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
Looks OK to me,
Reviewed-by: Francisco Jerez curroje...@riseup.net
Thank you, can you push it as well? I don't have commit access.
Thanks.
---
src/gallium/state_trackers/clover/core/kernel.cpp | 34
+++
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp
b/src/gallium/state_trackers/clover/core/kernel.cpp
index 58780d6..fb826c1 100644
--- a/src/gallium/state_trackers/clover/core/kernel.cpp
+++ b/src/gallium/state_trackers/clover/core/kernel.cpp
@@ -327,7 +327,7 @@ kernel::global_argument::set(size_t size, const void
*value) {
if (size != sizeof(cl_mem))
throw error(CL_INVALID_ARG_SIZE);
- buf = objbuffer(*(cl_mem *)value);
+ buf = pobjbuffer(value ? *(cl_mem *)value : NULL);
_set = true;
}
@@ -335,8 +335,14 @@ void
kernel::global_argument::bind(exec_context ctx,
const module::argument marg) {
align(ctx.input, marg.target_align);
- ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
- ctx.g_buffers.push_back(buf-resource(*ctx.q).pipe);
+
+ if (buf) {
+ ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
+ ctx.g_buffers.push_back(buf-resource(*ctx.q).pipe);
+ } else {
+ //NULL pointer
+ allocate(ctx.input, marg.target_size);
+ }
}
void
@@ -379,22 +385,28 @@ kernel::constant_argument::set(size_t size, const
void *value) {
if (size != sizeof(cl_mem))
throw error(CL_INVALID_ARG_SIZE);
- buf = objbuffer(*(cl_mem *)value);
+ buf = pobjbuffer(value ? *(cl_mem *)value : NULL);
_set = true;
}
void
kernel::constant_argument::bind(exec_context ctx,
const module::argument marg) {
- auto v = bytes(ctx.resources.size() 24);
-
- extend(v, module::argument::zero_ext, marg.target_size);
- byteswap(v, ctx.q-dev.endianness());
align(ctx.input, marg.target_align);
- insert(ctx.input, v);
- st = buf-resource(*ctx.q).bind_surface(*ctx.q, false);
- ctx.resources.push_back(st);
+ if (buf) {
+ auto v = bytes(ctx.resources.size() 24);
+
+ extend(v, module::argument::zero_ext, marg.target_size);
+ byteswap(v, ctx.q-dev.endianness());
+ insert(ctx.input, v);
+
+ st = buf-resource(*ctx.q).bind_surface(*ctx.q, false);
+ ctx.resources.push_back(st);
+ } else {
+ //NULL pointer
+ allocate(ctx.input, marg.target_size);
+ }
}
void
--
1.8.4.2
--
Jan Vesely jan.ves...@rutgers.edu
--
Jan Vesely jan.ves...@rutgers.edu
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glsl: Optimize ~~x into x.
On 01/19/2014 11:18 PM, Eric Anholt wrote:
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 332f0b7..6b0d992 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -218,6 +218,18 @@ ir_algebraic_visitor::handle_expression(ir_expression
*ir)
this-mem_ctx = ralloc_parent(ir);
switch (ir-operation) {
+ case ir_unop_bit_not:
+ if (op_expr[0] == NULL)
+ break;
+
+ switch (op_expr[0]-operation) {
+ case ir_unop_bit_not:
+ return abs(op_expr[0]-operands[0]);
abs? Looks like a copy and paste bug.
Also, could this merge with the neg path?
case ir_unop_bit_not:
case ir_unop_neg:
if (op_expr[0] == NULL)
break;
if (op_expr[0]-operation == ir-operation)
return op_expr[0]-operands[0];
break;
+ default:
+ break;
+ }
+ break;
+
case ir_unop_abs:
if (op_expr[0] == NULL)
break;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] glsl: Optimize log(exp(x)) and exp(log(x)) into x.
On 01/20/2014 08:42 AM, Erik Faye-Lund wrote: On Mon, Jan 20, 2014 at 5:39 PM, Eric Anholt e...@anholt.net wrote: Erik Faye-Lund kusmab...@gmail.com writes: On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote: --- src/glsl/opt_algebraic.cpp | 36 1 file changed, 36 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 6b0d992..4aa49e5 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -252,6 +252,42 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) } break; + case ir_unop_exp: + if (op_expr[0] == NULL) +break; How can this happen?! If the first operand itself isn't an expression (for example, it's a swizzle of something else). But what is something else? The GLSL grammar defines the arguments to be assignment_expressions, so they should always be expressions, no? ir_dereference isn't a subclass of ir_expression, for example. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: Generate GL_INVALID_OPERATION for unsupported DSA TexStorage functions
From: Ian Romanick ian.d.roman...@intel.com
We have to make the functions available to work around a GLEW bug (see
comments already in the code), but if an application calls one of these
functions we should still generate GL_INVALID_OPERATION.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
I also thought about just having these functions call _mesa_generic_nop
instead. That would make the code smaller, but it would mean that we
lose the specific error messages.
src/mesa/main/texstorage.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index cc9f38b..c1d2a5a 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -469,12 +469,16 @@ _mesa_TextureStorage1DEXT(GLuint texture, GLenum target,
GLsizei levels,
GLenum internalformat,
GLsizei width)
{
+ GET_CURRENT_CONTEXT(ctx);
+
(void) texture;
(void) target;
(void) levels;
(void) internalformat;
(void) width;
- /* no-op */
+
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glTextureStorage1DEXT not supported);
}
@@ -483,13 +487,17 @@ _mesa_TextureStorage2DEXT(GLuint texture, GLenum target,
GLsizei levels,
GLenum internalformat,
GLsizei width, GLsizei height)
{
+ GET_CURRENT_CONTEXT(ctx);
+
(void) texture;
(void) target;
(void) levels;
(void) internalformat;
(void) width;
(void) height;
- /* no-op */
+
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glTextureStorage2DEXT not supported);
}
@@ -499,6 +507,8 @@ _mesa_TextureStorage3DEXT(GLuint texture, GLenum target,
GLsizei levels,
GLenum internalformat,
GLsizei width, GLsizei height, GLsizei depth)
{
+ GET_CURRENT_CONTEXT(ctx);
+
(void) texture;
(void) target;
(void) levels;
@@ -506,5 +516,7 @@ _mesa_TextureStorage3DEXT(GLuint texture, GLenum target,
GLsizei levels,
(void) width;
(void) height;
(void) depth;
- /* no-op */
+
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glTextureStorage3DEXT not supported);
}
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: Silence many unused parameter warnings
From: Ian Romanick ian.d.roman...@intel.com
main/texstorage.c: In function '_mesa_alloc_texture_storage':
main/texstorage.c:240:53: warning: unused parameter 'width' [-Wunused-parameter]
main/texstorage.c:241:37: warning: unused parameter 'height'
[-Wunused-parameter]
main/texstorage.c:241:53: warning: unused parameter 'depth' [-Wunused-parameter]
main/texstorage.c: In function '_mesa_TextureStorage1DEXT':
main/texstorage.c:464:34: warning: unused parameter 'texture'
[-Wunused-parameter]
main/texstorage.c:464:50: warning: unused parameter 'target'
[-Wunused-parameter]
main/texstorage.c:464:66: warning: unused parameter 'levels'
[-Wunused-parameter]
main/texstorage.c:465:34: warning: unused parameter 'internalformat'
[-Wunused-parameter]
main/texstorage.c:466:35: warning: unused parameter 'width' [-Wunused-parameter]
main/texstorage.c: In function '_mesa_TextureStorage2DEXT':
main/texstorage.c:473:34: warning: unused parameter 'texture'
[-Wunused-parameter]
main/texstorage.c:473:50: warning: unused parameter 'target'
[-Wunused-parameter]
main/texstorage.c:473:66: warning: unused parameter 'levels'
[-Wunused-parameter]
main/texstorage.c:474:34: warning: unused parameter 'internalformat'
[-Wunused-parameter]
main/texstorage.c:475:35: warning: unused parameter 'width' [-Wunused-parameter]
main/texstorage.c:475:50: warning: unused parameter 'height'
[-Wunused-parameter]
main/texstorage.c: In function '_mesa_TextureStorage3DEXT':
main/texstorage.c:483:34: warning: unused parameter 'texture'
[-Wunused-parameter]
main/texstorage.c:483:50: warning: unused parameter 'target'
[-Wunused-parameter]
main/texstorage.c:483:66: warning: unused parameter 'levels'
[-Wunused-parameter]
main/texstorage.c:484:34: warning: unused parameter 'internalformat'
[-Wunused-parameter]
main/texstorage.c:485:35: warning: unused parameter 'width' [-Wunused-parameter]
main/texstorage.c:485:50: warning: unused parameter 'height'
[-Wunused-parameter]
main/texstorage.c:485:66: warning: unused parameter 'depth' [-Wunused-parameter]
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/texstorage.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index 3157d97..cc9f38b 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -244,6 +244,10 @@ _mesa_alloc_texture_storage(struct gl_context *ctx,
int face;
int level;
+ (void) width;
+ (void) height;
+ (void) depth;
+
for (face = 0; face numFaces; face++) {
for (level = 0; level levels; level++) {
struct gl_texture_image *const texImage = texObj-Image[face][level];
@@ -465,6 +469,11 @@ _mesa_TextureStorage1DEXT(GLuint texture, GLenum target,
GLsizei levels,
GLenum internalformat,
GLsizei width)
{
+ (void) texture;
+ (void) target;
+ (void) levels;
+ (void) internalformat;
+ (void) width;
/* no-op */
}
@@ -474,6 +483,12 @@ _mesa_TextureStorage2DEXT(GLuint texture, GLenum target,
GLsizei levels,
GLenum internalformat,
GLsizei width, GLsizei height)
{
+ (void) texture;
+ (void) target;
+ (void) levels;
+ (void) internalformat;
+ (void) width;
+ (void) height;
/* no-op */
}
@@ -484,5 +499,12 @@ _mesa_TextureStorage3DEXT(GLuint texture, GLenum target,
GLsizei levels,
GLenum internalformat,
GLsizei width, GLsizei height, GLsizei depth)
{
+ (void) texture;
+ (void) target;
+ (void) levels;
+ (void) internalformat;
+ (void) width;
+ (void) height;
+ (void) depth;
/* no-op */
}
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GalliumCompute / OpenCL on Radeon HD7790
On Mon, Jan 20, 2014 at 11:14:18AM -0800, ian_br...@fastmail.net wrote: On Mon, 20 Jan 2014 08:00:39 -0800 Tom Stellard t...@stellard.net wrote: http://dri.freedesktop.org/wiki/GalliumCompute/ Could anybody clarify whether the information on the wiki page should apply to a Radeon HD7790 card? Could the wiki be updated to be more specific about which GPUs it is relevant to? Sea Islands GPUs are supported. I've added this to the wiki page. Thanks. Let me then ask another question: since the new Radeon R9-280X, R9-270X, and R7-260X cards are supposed to be based on Southern/Sea Islands GPUs, would it be safe to assume that they would also be supported? Yes, they should all be work too, but Southern/Sea Islands OpenCL support is still in the early stages, so you will have to test it out to see what works for you. http://www.anandtech.com/show/7400/the-radeon-r9-280x-review-feat-asus-xfx The engineering vs marketing names link on the wiki page should be updated: http://www.x.org/wiki/RadeonFeature/#index5h2 And perhaps that table should itself be updated to include the new Rx-2yy GPUs, especially if those = 280 can be considered equivalent to the HD7000 series. Also, could the build instructions comment on whether packages from the Linux distribution (Debian?) might do as well? Or would those not have been built with options like --enable-experimental-targets=R600, --with-gallium-drivers=r600, and --enable-opencl? If you are using Gentoo, then it is possible to enable opencl support when installing the - package of mesa. I'm not sure if any other distros provide packages with OpenCL enabled. On Mon, 20 Jan 2014 11:49:40 +0900 Michel Dänzer mic...@daenzer.net wrote: The Debian Mesa packages aren't built with --enable-opencl yet, there are Debian bug reports requesting that. Is Mesa the only issue? Is it likely that distribution packages for LLVM, Clang, and libclc would be sufficient, or would they require custom builds as well? Especially for newer hardware, you would need to custom build the latest code of these packages for best results. The packages provided by distributions are probably too old to do anything useful with OpenCL. -Tom Again, please CC me on any replies. -- Ian Bruce ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: Generate GL_INVALID_OPERATION for unsupported DSA TexStorage functions
On 01/20/2014 12:07 PM, Ian Romanick wrote: From: Ian Romanick ian.d.roman...@intel.com We have to make the functions available to work around a GLEW bug (see comments already in the code), but if an application calls one of these functions we should still generate GL_INVALID_OPERATION. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- I also thought about just having these functions call _mesa_generic_nop instead. That would make the code smaller, but it would mean that we lose the specific error messages. For both: 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] GalliumCompute / OpenCL on Radeon HD7790
On Mon, 20 Jan 2014 08:00:39 -0800 Tom Stellard t...@stellard.net wrote: http://dri.freedesktop.org/wiki/GalliumCompute/ Could anybody clarify whether the information on the wiki page should apply to a Radeon HD7790 card? Could the wiki be updated to be more specific about which GPUs it is relevant to? Sea Islands GPUs are supported. I've added this to the wiki page. Thanks. Let me then ask another question: since the new Radeon R9-280X, R9-270X, and R7-260X cards are supposed to be based on Southern/Sea Islands GPUs, would it be safe to assume that they would also be supported? http://www.anandtech.com/show/7400/the-radeon-r9-280x-review-feat-asus-xfx The engineering vs marketing names link on the wiki page should be updated: http://www.x.org/wiki/RadeonFeature/#index5h2 And perhaps that table should itself be updated to include the new Rx-2yy GPUs, especially if those = 280 can be considered equivalent to the HD7000 series. Also, could the build instructions comment on whether packages from the Linux distribution (Debian?) might do as well? Or would those not have been built with options like --enable-experimental-targets=R600, --with-gallium-drivers=r600, and --enable-opencl? If you are using Gentoo, then it is possible to enable opencl support when installing the - package of mesa. I'm not sure if any other distros provide packages with OpenCL enabled. On Mon, 20 Jan 2014 11:49:40 +0900 Michel Dänzer mic...@daenzer.net wrote: The Debian Mesa packages aren't built with --enable-opencl yet, there are Debian bug reports requesting that. Is Mesa the only issue? Is it likely that distribution packages for LLVM, Clang, and libclc would be sufficient, or would they require custom builds as well? Again, please CC me on any replies. -- Ian Bruce ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] glsl: Disable ARB_texture_rectangle in shader version 100.
On Fri, Jan 17, 2014 at 9:09 PM, Matt Turner matts...@gmail.com wrote:
From: Anuj Phogat anuj.pho...@gmail.com
OpenGL with ARB_ES2_compatibility allows shaders that specify #version
100.
This fixes the Khronos OpenGL test(Texture_Rectangle_Samplers_frag.test)
failure.
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Matt Turner matts...@gmail.com
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/glsl/glsl_parser_extras.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index e67988f..c2ef3a0 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -291,6 +291,10 @@
_mesa_glsl_parse_state::process_version_directive(YYLTYPE *locp, int version,
}
}
+ if (this-es_shader) {
+ this-ARB_texture_rectangle_enable = false;
+ }
+
this-language_version = version;
bool supported = false;
--
1.8.3.2
I agree this is a better place to disable the extension.
Thanks Matt.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73638] [llvmpipe] piglit fbo-missing-attachment-blit es2 from regression
https://bugs.freedesktop.org/show_bug.cgi?id=73638 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vinson Lee v...@freedesktop.org --- commit d6fa71fbb0d365cefdabfea9de62cfece71f7486 Author: Brian Paul bri...@vmware.com Date: Wed Jan 15 18:09:56 2014 -0800 llvmpipe: handle NULL color buffer pointers Fixes regression from 9baa45f78b8ca7d66280e36009b6a685055d7cd6 v2: incorporate a few small changes suggested by Roland. Reviewed-by: José Fonseca jfons...@vmware.com Reviewed-by: Roland Scheidegger srol...@vmware.com -- 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] loader: Get driver name from udev hwdb when available
The udev hwdb is a mechanism for applying udev properties to devices at
hotplug time. The hwdb text files are compiled into a binary database
that lets udev efficiently look up and apply properties to devices that
match a given modalias.
This patch exports the mesa PCI ID tables as hwdb files and extends the
loader code to try to look up the driver name from the DRI_DRIVER udev
property. The benefits to this approach are:
- No longer PCI specific, any device udev can match with a modalias can
be assigned a DRI driver.
- Available outside mesa; writing a DRI2 compatible generic DDX with
glamor needs to know the DRI driver name to send to the client.
- Can be overridden by custom udev rules.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
configure.ac | 14 ++
src/loader/Makefile.am | 15 +++
src/loader/dump-hwdb.c | 31 +++
src/loader/loader.c| 33 +
src/loader/loader.h| 2 +-
5 files changed, 86 insertions(+), 9 deletions(-)
create mode 100644 src/loader/dump-hwdb.c
diff --git a/configure.ac b/configure.ac
index d9e1896..8670908 100644
--- a/configure.ac
+++ b/configure.ac
@@ -771,6 +771,20 @@ if test x$have_libdrm = xyes; then
DEFINES=$DEFINES -DHAVE_LIBDRM
fi
+# This /lib prefix does not change with 32/64 bits it's always /lib
+case $prefix in
+/usr) default_udevhwdbdir=/lib/udev/hwdb.d ;;
+NONE) default_udevhwdbdir=${ac_default_prefix}/lib/udev/hwdb.d ;;
+*)default_udevhwdbdir=$prefix/lib/udev/hwdb.d ;;
+esac
+
+AC_ARG_WITH([udev-hwdb-dir],
+[AS_HELP_STRING([--with-udev-hwdb-dir=DIR],
+[directory for the udev hwdb @:@/lib/udev/hwdb.d@:@])],
+[udevhwdbdir=$withval],
+[udevhwdbdir=$default_udevhwdbdir])
+AC_SUBST([udevhwdbdir])
+
PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
have_libudev=yes, have_libudev=no)
diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
index 371dd57..bf3918b 100644
--- a/src/loader/Makefile.am
+++ b/src/loader/Makefile.am
@@ -44,3 +44,18 @@ libloader_la_LIBADD += \
endif
libloader_la_SOURCES = $(LOADER_C_FILES)
+
+
+noinst_PROGRAMS = dump-hwdb
+dump_hwdb_SOURCES = dump-hwdb.c
+dump_hwdb_CPPFLAGS = -I$(top_srcdir)/include
+
+dist_udevhwdb_DATA = 20-dri-driver.hwdb
+
+# Update hwdb on installation. Do not bother if installing
+# in DESTDIR, since this is likely for packaging purposes.
+install-data-hook:
+ -test -n $(DESTDIR) || udevadm hwdb --update
+
+20-dri-driver.hwdb : dump-hwdb
+ $(builddir)/dump-hwdb $@
diff --git a/src/loader/dump-hwdb.c b/src/loader/dump-hwdb.c
new file mode 100644
index 000..d48452d
--- /dev/null
+++ b/src/loader/dump-hwdb.c
@@ -0,0 +1,31 @@
+#include stdlib.h
+#include stdio.h
+
+#define DRIVER_MAP_DRI2_ONLY
+#define __IS_LOADER
+
+#include loader.h
+#include pci_ids/pci_id_driver_map.h
+
+#define PROP_NAME DRI_DRIVER
+
+int main(int argc, char *argv[])
+{
+ int i, j;
+
+ for (i = 0; driver_map[i].driver; i++) {
+ if (driver_map[i].num_chips_ids == -1) {
+ /* Add a match for display base class (bc03) for drivers that don't
+ * export per-device IDs (nouveau) */
+ printf(pci:v%08x*bc03*\n PROP_NAME =%s\n\n,
+driver_map[i].vendor_id, driver_map[i].driver);
+ continue;
+ }
+
+ for (j = 0; j driver_map[i].num_chips_ids; j++)
+ printf(pci:v%08xd%08x*\n PROP_NAME =%s\n\n,
+driver_map[i].vendor_id,
+driver_map[i].chip_ids[j],
+driver_map[i].driver);
+ }
+}
diff --git a/src/loader/loader.c b/src/loader/loader.c
index a5bd769..03d8148 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -114,13 +114,15 @@ udev_device_new_from_fd(struct udev *udev, int fd)
}
int
-loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
+loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id, char **driver)
{
struct udev *udev = NULL;
struct udev_device *device = NULL, *parent;
const char *pci_id;
+ const char *hwdb_driver;
*chip_id = -1;
+ *driver = NULL;
udev = udev_new();
device = udev_device_new_from_fd(udev, fd);
@@ -133,6 +135,12 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
goto out;
}
+ hwdb_driver = udev_device_get_property_value(parent, DRI_DRIVER);
+ if (hwdb_driver != NULL) {
+ *driver = strdup(hwdb_driver);
+ goto out;
+ }
+
pci_id = udev_device_get_property_value(parent, PCI_ID);
if (pci_id == NULL ||
sscanf(pci_id, %x:%x, vendor_id, chip_id) != 2) {
@@ -147,7 +155,7 @@ out:
if (udev)
udev_unref(udev);
- return (*chip_id = 0);
+ return (*driver != NULL) || (*chip_id = 0);
}
#elif defined(ANDROID) !defined(__NOT_HAVE_DRM_H)
@@ -158,11 +166,12 @@ out:
#include radeon_drm.h
int
-loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
+loader_get_pci_id_for_fd(int
[Mesa-dev] [Bug 73846] New: [llvmpipe] lp_test_format fails with llvm-3.5svn = r199602
https://bugs.freedesktop.org/show_bug.cgi?id=73846 Priority: medium Bug ID: 73846 CC: bri...@vmware.com, jfons...@vmware.com, srol...@vmware.com Assignee: mesa-dev@lists.freedesktop.org Summary: [llvmpipe] lp_test_format fails with llvm-3.5svn = r199602 Severity: normal Classification: Unclassified OS: All Reporter: v...@freedesktop.org URL: http://llvm.org/bugs/show_bug.cgi?id=18550 Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa Starting with llvm-3.5svn r199602, lp_test_format fails SCALED unorm8 and USCALED unorm8 cases. commit 0487faa97b7afd3e186bd6a56c864b7e66e354a0 Author: Benjamin Kramer benny@googlemail.com Date: Sun Jan 19 15:24:22 2014 + InstCombine: Teach most integer add/sub/mul/div combines how to deal with vectors. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199602 91177308-0d34-0410-b5e6-96231b3b80d8 From http://llvm.org/bugs/show_bug.cgi?id=18550#c5, the above commit exposed a Mesa bug. -- 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] dri-vmwgfx: add __driDriverGetExtensions_vmwgfx() function
To resolve missing symbol since last year's megadriver changes.
Doesn't seem to be needed all systems though. Hmm.
---
src/gallium/targets/dri-vmwgfx/target.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/gallium/targets/dri-vmwgfx/target.c
b/src/gallium/targets/dri-vmwgfx/target.c
index e3fbda1..683e848 100644
--- a/src/gallium/targets/dri-vmwgfx/target.c
+++ b/src/gallium/targets/dri-vmwgfx/target.c
@@ -1,4 +1,6 @@
+#include GL/gl.h
+#include GL/internal/dri_interface.h
#include target-helpers/inline_wrapper_sw_helper.h
#include target-helpers/inline_debug_helper.h
#include state_tracker/drm_driver.h
@@ -50,3 +52,17 @@ static const struct drm_conf_ret *drm_configuration(enum
drm_conf conf)
}
DRM_DRIVER_DESCRIPTOR(vmwgfx, vmwgfx, create_screen, drm_configuration)
+
+
+/* Use extension list from src/gallium/state_trackers/dri/drm/dri2.c */
+extern const __DRIextension *__driDriverExtensions[];
+
+/* dummy prototype */
+PUBLIC const __DRIextension **
+__driDriverGetExtensions_vmwgfx(void);
+
+PUBLIC const __DRIextension **
+__driDriverGetExtensions_vmwgfx(void)
+{
+ return __driDriverExtensions;
+}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r600 Evergreen Compute and compute_memory_grow_pool
The compute memory pool used by the gallium r600 driver seems to be problematic. The pool looks to be a single radeon buffer object. There could be multiple maps set up into that single buffer object. If there is a need to grow the pool, then the resource associated with the buffer object is destroyed, which results in all of the maps for that buffer object also being destroyed. When the new larger pool is created, the pointers that the application has to the mapped region are no longer valid. A temporary work-around would appear to be to make sure that the buffer pool is large enough that there isn't a need to grow the pool once any maps into it are created. A longer term solution seems much harder. Even if the maps could all be precisely recreated into the newly allocated buffer object, there would be a period of time when the pointers held by the application would be invalid. John Hrustich LM Master Software Architect, Mission Systems and Training Lockheed Martin Corporation 1801 State Route 17C, Mail Drop 0220, Owego, NY 13827 O 607-751-4206 | E john.hrust...@lmco.com 100 Years of Accelerating Tomorrow ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600 Evergreen Compute and compute_memory_grow_pool
On Mon, Jan 20, 2014 at 09:32:11PM +, Hrustich, John wrote: The compute memory pool used by the gallium r600 driver seems to be problematic. The pool looks to be a single radeon buffer object. There could be multiple maps set up into that single buffer object. If there is a need to grow the pool, then the resource associated with the buffer object is destroyed, which results in all of the maps for that buffer object also being destroyed. When the new larger pool is created, the pointers that the application has to the mapped region are no longer valid. A temporary work-around would appear to be to make sure that the buffer pool is large enough that there isn't a need to grow the pool once any maps into it are created. A longer term solution seems much harder. Even if the maps could all be precisely recreated into the newly allocated buffer object, there would be a period of time when the pointers held by the application would be invalid. This is just one of the many problems with the compute memory pool. It would be good to have some piglit tests for the use case you described. I think the compute code in r600g has stabilized enough now that we could consider replacing the memory pool with something else. I'm open to suggestions if you have any ideas. -Tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GalliumCompute / OpenCL on Radeon HD7790
I'm not sure about debian's upstream packages, but at least Ubuntu's xorg-edgers PPA has llvm-3.4 packages available and I suspect that a variant of those will end up in the 14.04 LTS release. I've successfully built libclc and Mesa w/ OpenCL support against those packages after some massaging (need to create a few symlinks which are missing because the packages don't install /usr/bin/llvm-config, but instead installs llvm-config-3.4). But as I said, I haven't used Debian's packages directly (and I usually build most things directly from source). --Aaron On Mon, Jan 20, 2014 at 2:13 PM, Tom Stellard t...@stellard.net wrote: On Mon, Jan 20, 2014 at 11:14:18AM -0800, ian_br...@fastmail.net wrote: On Mon, 20 Jan 2014 08:00:39 -0800 Tom Stellard t...@stellard.net wrote: http://dri.freedesktop.org/wiki/GalliumCompute/ Could anybody clarify whether the information on the wiki page should apply to a Radeon HD7790 card? Could the wiki be updated to be more specific about which GPUs it is relevant to? Sea Islands GPUs are supported. I've added this to the wiki page. Thanks. Let me then ask another question: since the new Radeon R9-280X, R9-270X, and R7-260X cards are supposed to be based on Southern/Sea Islands GPUs, would it be safe to assume that they would also be supported? Yes, they should all be work too, but Southern/Sea Islands OpenCL support is still in the early stages, so you will have to test it out to see what works for you. http://www.anandtech.com/show/7400/the-radeon-r9-280x-review-feat-asus-xfx The engineering vs marketing names link on the wiki page should be updated: http://www.x.org/wiki/RadeonFeature/#index5h2 And perhaps that table should itself be updated to include the new Rx-2yy GPUs, especially if those = 280 can be considered equivalent to the HD7000 series. Also, could the build instructions comment on whether packages from the Linux distribution (Debian?) might do as well? Or would those not have been built with options like --enable-experimental-targets=R600, --with-gallium-drivers=r600, and --enable-opencl? If you are using Gentoo, then it is possible to enable opencl support when installing the - package of mesa. I'm not sure if any other distros provide packages with OpenCL enabled. On Mon, 20 Jan 2014 11:49:40 +0900 Michel Dänzer mic...@daenzer.net wrote: The Debian Mesa packages aren't built with --enable-opencl yet, there are Debian bug reports requesting that. Is Mesa the only issue? Is it likely that distribution packages for LLVM, Clang, and libclc would be sufficient, or would they require custom builds as well? Especially for newer hardware, you would need to custom build the latest code of these packages for best results. The packages provided by distributions are probably too old to do anything useful with OpenCL. -Tom Again, please CC me on any replies. -- Ian Bruce ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73854] New: Half-Life 1-based Games Segfault
https://bugs.freedesktop.org/show_bug.cgi?id=73854 Priority: medium Bug ID: 73854 Assignee: mesa-dev@lists.freedesktop.org Summary: Half-Life 1-based Games Segfault Severity: normal Classification: Unclassified OS: All Reporter: mmstick...@gmail.com Hardware: Other Status: NEW Version: git Component: Mesa core Product: Mesa All games that use the GoldSrc engine segfault on launch with the latest git. It doesn't segfault when launching with the stable mesa 10.0.1/10.0.2. -- 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 73854] GoldSrc and Source Games Segfault on Launch
https://bugs.freedesktop.org/show_bug.cgi?id=73854 mmstick...@gmail.com changed: What|Removed |Added Summary|Half-Life 1-based Games |GoldSrc and Source Games |Segfault|Segfault on Launch -- 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 73854] GoldSrc and Source Games Segfault on Launch
https://bugs.freedesktop.org/show_bug.cgi?id=73854 --- Comment #1 from mmstick...@gmail.com --- I see that now, all Source games segfault as well. -- 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 73854] GoldSrc and Source Games Segfault on Launch
https://bugs.freedesktop.org/show_bug.cgi?id=73854 --- Comment #2 from mmstick...@gmail.com --- This happens on all of my systems: a Radeon HD 4650 laptop, Radeon HD 6850 desktop, and Radeon HD 7950 desktop. -- 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 73854] GoldSrc and Source Games Segfault on Launch
https://bugs.freedesktop.org/show_bug.cgi?id=73854 --- Comment #3 from Alex Deucher ag...@yahoo.com --- Can you bisect? -- 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/st: how to force glLinkProgram to create/translate the program?
It was pretty simple IIRC. You just need to call st_get_fp(vp)_variant to create a pipe shader. I think st_program_string_notify is the right place. Marek On Mon, Jan 20, 2014 at 7:23 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jan 20, 2014 at 10:23 AM, Brian Paul bri...@vmware.com wrote: I'm having trouble figuring out how to bypass this and make it call update_vp/fp/gp which appear like they'll actually call pipe-create_fs_state/etc. I see st_link_shader getting called, as expected, which creates the TGSI... but what to do from there? If you were to short-circuit the validation steps above and force the VS/FS to get propagated to the driver ASAP, there's a chance the shader wouldn't actually do everything that it normally would (ex: invert Y). I don't know if that matters to you. Not at all. This is for checking various nouveau compiler optimizations against input shaders. I think that as long as the shaders passed to the driver remain basically the same, it should still be useful for comparing emitted code with different (nouveau) compiler versions. In any case, there's no simple solution to this. You'll probably have to hack something up. If it turns out simple, maybe we could enable it with a debug flag. Could you suggest a way for hacking this up? i.e. what functions might I call from where? I'm definitely having trouble groking the code paths that cause things to be sent right now. Thanks, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GalliumCompute / OpenCL on Radeon HD7790
On Mon, 2014-01-20 at 16:30 -0600, Aaron Watry wrote: I'm not sure about debian's upstream packages, but at least Ubuntu's xorg-edgers PPA has llvm-3.4 packages available and I suspect that a variant of those will end up in the 14.04 LTS release. I've successfully built libclc and Mesa w/ OpenCL support against those packages after some massaging (need to create a few symlinks which are missing because the packages don't install /usr/bin/llvm-config, but instead installs llvm-config-3.4). You can use --with-llvm-prefix=/usr/lib/llvm-3.[45] for that. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73854] GoldSrc and Source Games Segfault on Launch
https://bugs.freedesktop.org/show_bug.cgi?id=73854 --- Comment #4 from Michel Dänzer mic...@daenzer.net --- Please provide a backtrace for the segfault. -- 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] dri-vmwgfx: add __driDriverGetExtensions_vmwgfx() function
I can't see why this would be needed at all. The X.Org loader was modified to look for the new symbol names (i.e., the one added in this patch) but still looks for the regular ones too. And since Jordan's patch to megadrivers, the X.Org loader doesn't even need to look for the new symbol names. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] draw: fix points with negative w coords for d3d style point clipping
From: Roland Scheidegger srol...@vmware.com Even with depth clipping disabled, vertices which have negative w coords must be discarded. And since we don't have a proper guardband implementation yet (relying on driver to handle all values except infs/nans in rasterization for such points) we need to kill them off manually (as they can end up with coordinates inside viewport otherwise). --- src/gallium/auxiliary/draw/draw_pipe_clip.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c b/src/gallium/auxiliary/draw/draw_pipe_clip.c index 8bdb882..eb0813d 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_clip.c +++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c @@ -635,8 +635,13 @@ clip_point_guard_xy( struct draw_stage *stage, clipmask = ~(1 plane_idx); /* turn off this plane's bit */ /* TODO: this should really do proper guardband clipping, * currently just throw out infs/nans. + * Also note that vertices with negative w values MUST be tossed + * out (not sure if proper guardband clipping would do this + * automatically). These would usually be captured by depth clip + * too but this can be disabled. */ - if (util_is_inf_or_nan(header-v[0]-clip[0]) || + if (header-v[0]-clip[3] = 0 || + util_is_inf_or_nan(header-v[0]-clip[0]) || util_is_inf_or_nan(header-v[0]-clip[1])) return; } @@ -645,7 +650,6 @@ clip_point_guard_xy( struct draw_stage *stage, } - static void clip_first_point( struct draw_stage *stage, struct prim_header *header ) -- 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 24/42] i965/blorp: move emission of sample combining into eu-emitter
On 20 December 2013 06:38, Topi Pohjolainen topi.pohjolai...@intel.comwrote:
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
index b189aa2..dcfd82b 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -148,3 +148,15 @@ brw_blorp_eu_emitter::emit_render_target_write(const
struct brw_reg src0,
true /* eot */,
use_header);
}
+
+void
+brw_blorp_eu_emitter::emit_combine(unsigned texture_data_type,
+ const struct brw_reg dst,
+ const struct brw_reg src_1,
+ const struct brw_reg src_2)
+{
+ if (texture_data_type == BRW_REGISTER_TYPE_F)
+ brw_ADD(func, dst, src_1, src_2);
+ else
+ brw_AVG(func, dst, src_1, src_2);
+}
It's a bit of an awkward split to have most of the algorithm for combining
samples in brw_blorp_blit_program::manual_blend_average(), but the choice
of whether to use ADD or AVG is here in
brw_blorp_eu_emitter::emit_combine(). How about if we replace
texture_data_type with a bool called combine_using_add? That way someone
reading manual_blend_average() won't have to refer to emit_combine() to
understand what the algorithm does; and similarly someone reading
emt_combine() won't have to look at manual_blend_average() to understand
why we use ADD for floats and AVG for ints.
With that change, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 4/8] mesa: MESA_FORMAT Type P Conversion
On Sun, Jan 19, 2014 at 7:56 PM, Michel Dänzer mic...@daenzer.net wrote: On Fre, 2014-01-17 at 03:47 -0800, Mark Mueller wrote: diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h index 348d2f4..fb43c83 100644 --- a/src/mesa/main/formats.h +++ b/src/mesa/main/formats.h @@ -182,14 +182,14 @@ typedef enum MESA_FORMAT_RGB_UNORM8, /* Type P formats */ - MESA_FORMAT_RGB565, /* RGGG GGGB */ - MESA_FORMAT_RGB565_REV, /* GGGB RGGG */ - MESA_FORMAT_ARGB, /* */ - MESA_FORMAT_ARGB_REV, /* */ - MESA_FORMAT_RGBA5551,/* RGGG GGBB BBBA */ - MESA_FORMAT_ARGB1555, /* ARRR RRGG GGGB */ - MESA_FORMAT_ARGB1555_REV, /* GGGB ARRR RRGG */ - MESA_FORMAT_AL44, /* */ + MESA_FORMAT_B5G6R5_UNORM, /* BGGG GGGR */ + MESA_FORMAT_R5G6B5_UNORM, /* RGGG GGGB */ + MESA_FORMAT_B4G4R4A4_UNORM, /* */ + MESA_FORMAT_A4R4G4B4_UNORM, /* */ + MESA_FORMAT_A1B5G5R5_UNORM, /* ARRR RRGG GGGB */ + MESA_FORMAT_B5G5R5A1_UNORM, /* BGGG GGRR RRRA */ + MESA_FORMAT_A1R5G5B5_UNORM, /* ARRR RRGG GGGB */ + MESA_FORMAT_L4A4_UNORM, /* */ Please keep these comments aligned with the other comments describing packed format layouts. (Please also don't remove the header comments explaining the format of these comments) Sorry, there were some fossilized tabs in there that I _had_ removed in an earlier patch but they came back like the night of the living dead. Also, why are you changing the component order in the comments for these, but not for some other packed formats in the series? Last but not least, there are a few cases in the series where you're defining a format as 'type A', when these comments clearly show that they're packed formats. Please be careful. Unlike the 100's of global substitutions, all of the comments have to be done by hand and there were some stragglers that got through. With the major shift to a lot more P type formats, much of that has changed again. I should have a new patchset revision ready by tomorrow. Mark ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 27/42] i965/blorp: wrap LRP
On 20 December 2013 06:38, Topi Pohjolainen topi.pohjolai...@intel.comwrote:
The split of the emission of the two halfs into single emission
call prapares for fs_generator support that already does similar
thing. No regressions seen on IVB (unit tests and piglit quick).
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 26
++
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h | 13 +
2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 1b7310b..b95104e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1679,29 +1679,23 @@
brw_blorp_blit_program::manual_blend_bilinear(unsigned num_samples)
}
#define SAMPLE(x, y) offset(texture_data[x], y)
- brw_set_access_mode(func, BRW_ALIGN_16);
- brw_set_compression_control(func, BRW_COMPRESSION_NONE);
for (int index = 3; index 0; ) {
/* Since we're doing SIMD16, 4 color channels fits in to 8
registers.
* Counter value of 8 in 'for' loop below is used to interpolate all
* the color components.
*/
- for (int k = 0; k 8; ++k)
- brw_LRP(func,
- vec8(SAMPLE(index - 1, k)),
- offset(x_frac, k 1),
- SAMPLE(index, k),
- SAMPLE(index - 1, k));
+ for (int k = 0; k 8; k += 2)
+ emit_lrp(vec8(SAMPLE(index - 1, k)),
+ offset(x_frac, k 1),
This line can just be x_frac now, because k is always even, so (k 1) is
always zero.
+ SAMPLE(index, k),
+ SAMPLE(index - 1, k));
index -= 2;
}
- for (int k = 0; k 8; ++k)
- brw_LRP(func,
- vec8(SAMPLE(0, k)),
- offset(y_frac, k 1),
- vec8(SAMPLE(2, k)),
- vec8(SAMPLE(0, k)));
- brw_set_compression_control(func, BRW_COMPRESSION_COMPRESSED);
- brw_set_access_mode(func, BRW_ALIGN_1);
+ for (int k = 0; k 8; k += 2)
+ emit_lrp(vec8(SAMPLE(0, k)),
+ offset(y_frac, k 1),
Same comment applies here.
+ vec8(SAMPLE(2, k)),
+ vec8(SAMPLE(0, k)));
#undef SAMPLE
}
With those two things fixed, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 37/42] i965/blorp: wrap brw_IF/ELSE/ENDIF() into eu-emitter
On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.comwrote:
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
index 1ecf076..3f2301c 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
@@ -162,6 +162,24 @@ protected:
brw_RNDD(func, dst, src);
}
+ inline void emit_if(int op,
+ const struct brw_reg x,
+ const struct brw_reg y)
+ {
+ brw_CMP(func, vec16(brw_null_reg()), op, x, y);
+ brw_IF(func, BRW_EXECUTE_16);
+ }
Can we maybe call tihs emit_cmp_if(), so that it's clear when looking at
the caller that it performs both a CMP and an IF?
With that change, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 38/42] i965/fs: allow unit tests to dump the final patched assembly
On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.comwrote: Unit tests comparing generated blorp programs to known good need to have the dump in designated file instead of in default standard output. The comparison also expects the jump counters of if-else-instructions to be correctly set and hence the dump needs to be taken _after_ 'patch_IF_ELSE()' is run (the default dump of the fs_generator does this before). Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com --- src/mesa/drivers/dri/i965/brw_fs.h | 7 +-- src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 15 +-- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.h b/src/mesa/drivers/dri/i965/brw_fs.h index 9bef07c..d40d0a8 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.h +++ b/src/mesa/drivers/dri/i965/brw_fs.h @@ -510,10 +510,13 @@ public: const unsigned *generate_assembly(exec_list *simd8_instructions, exec_list *simd16_instructions, - unsigned *assembly_size); + unsigned *assembly_size, + bool dump_enabled = false, + FILE *dump_file = stdout); Nit pick: rather than add 2 args, wouldn't it be easier to just add the dump_file arg, with a default value of NULL, and only dump instructions if it is non-NULL? Either way, the patch is: Reviewed-by: Paul Berry stereotype...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 39/42] i965/fs: introduce blorp specific rt-write for fs_generator
On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.comwrote:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index df91235..4c159e6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -190,6 +190,21 @@ fs_generator::generate_fb_write(fs_inst *inst)
mark_surface_used(surf_index);
}
+void
+fs_generator::generate_blorp_fb_write(fs_inst *inst)
+{
+ brw_fb_WRITE(p,
+16 /* dispatch_width */,
+inst-base_mrf,
+brw_reg_from_fs_reg(inst-src[0]),
+BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD16_SINGLE_SOURCE,
+1 /* BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX */,
This seems like it would lead to a maintenance burden if anyone ever
decides to change BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX to a number
other than 1. Can we move the declaration of
BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX to somewhere that's accessible
to this file so that we can just pass it in directly? Alternatively, we
could store it in inst-target.
With that issue addressed, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
+inst-mlen,
+0,
+true,
+inst-header_present);
+}
+
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 41/42] i965/eu: introduce blorp specific flavour of lrp
On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.comwrote: This is rather ugly but as I couldn't think of anything better for now and wanted to get the rest of the series under review, I left it as it is. Even though immediately surrounding code has tabs this piece is written space-indented. Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com This patch is unnecessary. The blorp specific flavour of lrp is actually a previously undiscovered bug in blorp: blorp should be using BRW_COMPRESSION_2NDHALF for its second half LRPs. I believe the bug may be benign, but we should fix it anyhow, and I think we can fix it by just dropping this patch entirely. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 24/42] i965/blorp: move emission of sample combining into eu-emitter
On 20 January 2014 19:36, Paul Berry stereotype...@gmail.com wrote:
On 20 December 2013 06:38, Topi Pohjolainen topi.pohjolai...@intel.comwrote:
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
index b189aa2..dcfd82b 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -148,3 +148,15 @@ brw_blorp_eu_emitter::emit_render_target_write(const
struct brw_reg src0,
true /* eot */,
use_header);
}
+
+void
+brw_blorp_eu_emitter::emit_combine(unsigned texture_data_type,
+ const struct brw_reg dst,
+ const struct brw_reg src_1,
+ const struct brw_reg src_2)
+{
+ if (texture_data_type == BRW_REGISTER_TYPE_F)
+ brw_ADD(func, dst, src_1, src_2);
+ else
+ brw_AVG(func, dst, src_1, src_2);
+}
It's a bit of an awkward split to have most of the algorithm for combining
samples in brw_blorp_blit_program::manual_blend_average(), but the choice
of whether to use ADD or AVG is here in
brw_blorp_eu_emitter::emit_combine(). How about if we replace
texture_data_type with a bool called combine_using_add? That way someone
reading manual_blend_average() won't have to refer to emit_combine() to
understand what the algorithm does; and similarly someone reading
emt_combine() won't have to look at manual_blend_average() to understand
why we use ADD for floats and AVG for ints.
On further reflection, I think it would be even better to replace the
texture_data_type argument with an opcode argument--that way the caller can
pass in BRW_OPCODE_ADD or BRW_OPCODE_AVG. Once we get to patch 42/42, this
function can be changed to just plumb the opcode straight through into the
fs_inst constructor.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 42/42] i965/blorp: switch eu-emitter to use FS IR and fs_generator
On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.comwrote: Unfortunately the unit tests need to be patched as well. This is because the direct eu-emitter only patches jump counters for if-else (see patch_IF_ELSE()) while the fs_generator patches the endif as well (see brw_set_uip_jip()). I think the fact that blorp wasn't patching jump counters for if-else was a previously undiscovered bug in blorp. I suspect that the reason we never discovered it was because blorp doesn't contain complex enough flow control to cause an endif to ever execute a jump. I'd recommend splitting this patch into two patches: 1. fix the previously undiscovered blorp bug (by having blorp call brw_set_uip_jip() at the appropriate time) and update the unit tests. 2. switch eu-emitter to use FS IR and fs_generator. That will make it a lot easier to reassure ourselves that the changes are correct, and in the unlikely event that we later discover that they aren't, it'll make it easier to bisect to the problem. With this patch split, it is: Reviewed-by: Paul Berry stereotype...@gmail.com I've sent comments on patches 24, 27, 37, 38, 39, and 41. All the others are: Reviewed-by: Paul Berry stereotype...@gmail.com I really like how you structured this series, Topi. It was easy to follow what you did and to reassure myself that it was correct. And I'm really glad you did it, since it led us to discover two preexisting bugs! Nice work. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: dump geometry shaders when using LP_DEBUG=tgsi
From: Dave Airlie airl...@redhat.com
for consistency with vs and fs dumpers.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/llvmpipe/lp_state_gs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_gs.c
b/src/gallium/drivers/llvmpipe/lp_state_gs.c
index 8f4f389..74cf992 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_gs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_gs.c
@@ -28,6 +28,7 @@
#include lp_context.h
#include lp_state.h
#include lp_texture.h
+#include lp_debug.h
#include pipe/p_defines.h
#include util/u_memory.h
@@ -50,8 +51,10 @@ llvmpipe_create_gs_state(struct pipe_context *pipe,
goto fail;
/* debug */
- if (0)
+ if (LP_DEBUG DEBUG_TGSI) {
+ debug_printf(llvmpipe: Create geometry shader %p:\n, (void *)state);
tgsi_dump(templ-tokens, 0);
+ }
/* copy stream output info */
state-shader = *templ;
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73854] GoldSrc and Source Games Segfault on Launch
https://bugs.freedesktop.org/show_bug.cgi?id=73854 --- Comment #5 from Nicholas Miell nmi...@gmail.com --- Half-Life (GoldSrc): #0 0x4ccc63c8 in udev_list_entry_get_next () from /lib/libudev.so.1 #1 0x4cccb9db in udev_monitor_filter_update () from /lib/libudev.so.1 #2 0xf063c13e in udev_monitor_enable_receiving () from /home/nicholas/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libudev.so.0 #3 0xf48fc4bf in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/libSDL2-2.0.so.0 #4 0xf48e7817 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/libSDL2-2.0.so.0 #5 0xf485e874 in SDL_InitSubSystem () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/libSDL2-2.0.so.0 #6 0xf4b9ab63 in CGame::CreateGameWindow (this=0xf52ee6e0 g_Game) at ../engine/sys_sdlwind.cpp:761 #7 0xf4b9a6fc in Init (pvInstance=optimized out, this=0xa02ced8) at ../engine/sys_getmodes.cpp:338 #8 CVideoMode_OpenGL::Init (this=0xa02ced8, pvInstance=0x0) at ../engine/sys_getmodes.cpp:1587 #9 0xf4ad203a in RunListenServer (instance=0x0, basedir=0x804b220 szBaseDir /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life, cmdline=0x9e86548 /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/hl_linux -steam, postRestartCmdLineArgs=0x804d360 main::szNewCommandParams , launcherFactory=0x8049350 CreateInterfaceLocal(char const*, int*), filesystemFactory= 0xf7694ad0 CreateInterface(char const*, int*)) at ../engine/sys_dll2.cpp:916 #10 0x08048d67 in main (argc=2, argv=0xffe1c9a4) at ../launcher/launcher.cpp:439 Half-Life 2 (Source): #0 0x4ccc63c8 in udev_list_entry_get_next () from /lib/libudev.so.1 #1 0x4cccb9db in udev_monitor_filter_update () from /lib/libudev.so.1 #2 0xed1d713e in udev_monitor_enable_receiving () from /home/nicholas/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libudev.so.0 #3 0xf5a5d761 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/libSDL2-2.0.so.0 #4 0xf59e68be in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/libSDL2-2.0.so.0 #5 0xf59b8f25 in SDL_InitSubSystem () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/libSDL2-2.0.so.0 #6 0xf168c802 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/inputsystem.so #7 0xf168a650 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/inputsystem.so #8 0xf60bf826 in ?? () from bin/launcher.so #9 0xf60bf902 in ?? () from bin/launcher.so #10 0xf60bfb88 in ?? () from bin/launcher.so #11 0xf60bfba0 in ?? () from bin/launcher.so #12 0xf60a7d95 in LauncherMain () from bin/launcher.so #13 0x08048504 in main () Did Mesa gain an udev dependency recently? -- 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 41/42] i965/eu: introduce blorp specific flavour of lrp
On Mon, Jan 20, 2014 at 08:11:06PM -0800, Paul Berry wrote: On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.com wrote: This is rather ugly but as I couldn't think of anything better for now and wanted to get the rest of the series under review, I left it as it is. Even though immediately surrounding code has tabs this piece is written space-indented. Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com This patch is unnecessary. The blorp specific flavour of lrp is actually a previously undiscovered bug in blorp: blorp should be using BRW_COMPRESSION_2NDHALF for its second half LRPs. I believe the bug may be benign, but we should fix it anyhow, and I think we can fix it by just dropping this patch entirely. Oh, very nice. Now it makes more sense. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 38/42] i965/fs: allow unit tests to dump the final patched assembly
On Mon, Jan 20, 2014 at 07:58:08PM -0800, Paul Berry wrote: On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.com wrote: Unit tests comparing generated blorp programs to known good need to have the dump in designated file instead of in default standard output. The comparison also expects the jump counters of if-else-instructions to be correctly set and hence the dump needs to be taken _after_ 'patch_IF_ELSE()' is run (the default dump of the fs_generator does this before). Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com --- src/mesa/drivers/dri/i965/brw_fs.h | 7 +-- src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 15 +-- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.h b/src/mesa/drivers/dri/i965/brw_fs.h index 9bef07c..d40d0a8 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.h +++ b/src/mesa/drivers/dri/i965/brw_fs.h @@ -510,10 +510,13 @@ public: const unsigned *generate_assembly(exec_list *simd8_instructions, exec_list *simd16_instructions, - unsigned *assembly_size); + unsigned *assembly_size, + bool dump_enabled = false, + FILE *dump_file = stdout); Nit pick: rather than add 2 args, wouldn't it be easier to just add the dump_file arg, with a default value of NULL, and only dump instructions if it is non-NULL? I'll change that, I actually had what you suggest originally :) Either way, the patch is: Reviewed-by: Paul Berry stereotype...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 37/42] i965/blorp: wrap brw_IF/ELSE/ENDIF() into eu-emitter
On Mon, Jan 20, 2014 at 07:54:25PM -0800, Paul Berry wrote:
On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.com
wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
index 1ecf076..3f2301c 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
@@ -162,6 +162,24 @@ protected:
brw_RNDD(func, dst, src);
}
+ inline void emit_if(int op,
+ const struct brw_reg x,
+ const struct brw_reg y)
+ {
+ brw_CMP(func, vec16(brw_null_reg()), op, x, y);
+ brw_IF(func, BRW_EXECUTE_16);
+ }
Can we maybe call tihs emit_cmp_if(), so that it's clear when looking at
the caller that it performs both a CMP and an IF?
Yes, clearly better, I'll revise.
With that change, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 27/42] i965/blorp: wrap LRP
On Mon, Jan 20, 2014 at 07:47:45PM -0800, Paul Berry wrote:
On 20 December 2013 06:38, Topi Pohjolainen topi.pohjolai...@intel.com
wrote:
The split of the emission of the two halfs into single emission
call prapares for fs_generator support that already does similar
thing. No regressions seen on IVB (unit tests and piglit quick).
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 26
++
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h | 13 +
2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 1b7310b..b95104e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1679,29 +1679,23 @@
brw_blorp_blit_program::manual_blend_bilinear(unsigned num_samples)
}
#define SAMPLE(x, y) offset(texture_data[x], y)
- brw_set_access_mode(func, BRW_ALIGN_16);
- brw_set_compression_control(func, BRW_COMPRESSION_NONE);
for (int index = 3; index 0; ) {
/* Since we're doing SIMD16, 4 color channels fits in to 8
registers.
* Counter value of 8 in 'for' loop below is used to interpolate
all
* the color components.
*/
- for (int k = 0; k 8; ++k)
- brw_LRP(func,
- vec8(SAMPLE(index - 1, k)),
- offset(x_frac, k 1),
- SAMPLE(index, k),
- SAMPLE(index - 1, k));
+ for (int k = 0; k 8; k += 2)
+ emit_lrp(vec8(SAMPLE(index - 1, k)),
+ offset(x_frac, k 1),
This line can just be x_frac now, because k is always even, so (k 1)
is always zero.
Nice catch, I probably should have paid more attention to what I was doing also.
+ SAMPLE(index, k),
+ SAMPLE(index - 1, k));
index -= 2;
}
- for (int k = 0; k 8; ++k)
- brw_LRP(func,
- vec8(SAMPLE(0, k)),
- offset(y_frac, k 1),
- vec8(SAMPLE(2, k)),
- vec8(SAMPLE(0, k)));
- brw_set_compression_control(func, BRW_COMPRESSION_COMPRESSED);
- brw_set_access_mode(func, BRW_ALIGN_1);
+ for (int k = 0; k 8; k += 2)
+ emit_lrp(vec8(SAMPLE(0, k)),
+ offset(y_frac, k 1),
Same comment applies here.
+ vec8(SAMPLE(2, k)),
+ vec8(SAMPLE(0, k)));
#undef SAMPLE
}
With those two things fixed, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] st/mesa: ARB_viewport_array support
Hey, This is just a couple of patches I threw together to interface the new mesa viewport array code to gallium, I've ran a few tests on llvmpipe, and they seem to pass with this code. The only question I really have is do we want to expand the CSO interface to cover this or not? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 24/42] i965/blorp: move emission of sample combining into eu-emitter
On Mon, Jan 20, 2014 at 08:30:41PM -0800, Paul Berry wrote:
On 20 January 2014 19:36, Paul Berry stereotype...@gmail.com wrote:
On 20 December 2013 06:38, Topi Pohjolainen topi.pohjolai...@intel.com
wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
index b189aa2..dcfd82b 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -148,3 +148,15 @@
brw_blorp_eu_emitter::emit_render_target_write(const struct brw_reg
src0,
true /* eot */,
use_header);
}
+
+void
+brw_blorp_eu_emitter::emit_combine(unsigned texture_data_type,
+ const struct brw_reg dst,
+ const struct brw_reg src_1,
+ const struct brw_reg src_2)
+{
+ if (texture_data_type == BRW_REGISTER_TYPE_F)
+ brw_ADD(func, dst, src_1, src_2);
+ else
+ brw_AVG(func, dst, src_1, src_2);
+}
It's a bit of an awkward split to have most of the algorithm for
combining samples in brw_blorp_blit_program::manual_blend_average(), but
the choice of whether to use ADD or AVG is here in
brw_blorp_eu_emitter::emit_combine(). How about if we replace
texture_data_type with a bool called combine_using_add? That way
someone reading manual_blend_average() won't have to refer to
emit_combine() to understand what the algorithm does; and similarly
someone reading emt_combine() won't have to look at
manual_blend_average() to understand why we use ADD for floats and AVG
for ints.
On further reflection, I think it would be even better to replace the
texture_data_type argument with an opcode argument--that way the caller
can pass in BRW_OPCODE_ADD or BRW_OPCODE_AVG. Once we get to patch 42/42,
this function can be changed to just plumb the opcode straight through
into the fs_inst constructor.
I like that, version two on its way, thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/mesa: add support for viewport index semantic
From: Dave Airlie airl...@redhat.com This adds GS output and FS input support, even though FS input support isn't supported until GLSL 4.30 from what I can see. Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/state_tracker/st_program.c | 9 + 1 file changed, 9 insertions(+) diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index 2d6d430..cdb6662 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_tracker/st_program.c @@ -572,6 +572,11 @@ st_translate_fragment_program(struct st_context *st, input_semantic_index[slot] = 0; interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; break; + case VARYING_SLOT_VIEWPORT: +input_semantic_name[slot] = TGSI_SEMANTIC_VIEWPORT_INDEX; +input_semantic_index[slot] = 0; +interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; +break; case VARYING_SLOT_CLIP_DIST0: input_semantic_name[slot] = TGSI_SEMANTIC_CLIPDIST; input_semantic_index[slot] = 0; @@ -1028,6 +1033,10 @@ st_translate_geometry_program(struct st_context *st, gs_output_semantic_name[slot] = TGSI_SEMANTIC_PRIMID; gs_output_semantic_index[slot] = 0; break; + case VARYING_SLOT_VIEWPORT: +gs_output_semantic_name[slot] = TGSI_SEMANTIC_VIEWPORT_INDEX; +gs_output_semantic_index[slot] = 0; +break; case VARYING_SLOT_TEX0: case VARYING_SLOT_TEX1: case VARYING_SLOT_TEX2: -- 1.8.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/mesa: add support for GL_ARB_viewport_array (v0.2)
From: Dave Airlie airl...@redhat.com
this just ties the mesa code to the pre-existing gallium interface,
I'm not sure what to do with the CSO stuff yet.
0.2: fix min/max bounds
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_atom_scissor.c | 75 ---
src/mesa/state_tracker/st_atom_viewport.c | 37 ---
src/mesa/state_tracker/st_context.h | 4 +-
src/mesa/state_tracker/st_draw_feedback.c | 2 +-
src/mesa/state_tracker/st_extensions.c| 9
5 files changed, 72 insertions(+), 55 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_scissor.c
b/src/mesa/state_tracker/st_atom_scissor.c
index a1f72da..50b921a 100644
--- a/src/mesa/state_tracker/st_atom_scissor.c
+++ b/src/mesa/state_tracker/st_atom_scissor.c
@@ -43,51 +43,56 @@
static void
update_scissor( struct st_context *st )
{
- struct pipe_scissor_state scissor;
+ struct pipe_scissor_state scissor[PIPE_MAX_VIEWPORTS];
const struct gl_context *ctx = st-ctx;
const struct gl_framebuffer *fb = ctx-DrawBuffer;
GLint miny, maxy;
+ int i;
+ bool changed = false;
+ for (i = 0 ; i ctx-Const.MaxViewports; i++) {
+ scissor[i].minx = 0;
+ scissor[i].miny = 0;
+ scissor[i].maxx = fb-Width;
+ scissor[i].maxy = fb-Height;
- scissor.minx = 0;
- scissor.miny = 0;
- scissor.maxx = fb-Width;
- scissor.maxy = fb-Height;
+ if (ctx-Scissor.EnableFlags (1 i)) {
+ /* need to be careful here with xmax or ymax 0 */
+ GLint xmax = MAX2(0, ctx-Scissor.ScissorArray[i].X +
ctx-Scissor.ScissorArray[i].Width);
+ GLint ymax = MAX2(0, ctx-Scissor.ScissorArray[i].Y +
ctx-Scissor.ScissorArray[i].Height);
- if (ctx-Scissor.EnableFlags 1) {
- /* need to be careful here with xmax or ymax 0 */
- GLint xmax = MAX2(0, ctx-Scissor.ScissorArray[0].X +
ctx-Scissor.ScissorArray[0].Width);
- GLint ymax = MAX2(0, ctx-Scissor.ScissorArray[0].Y +
ctx-Scissor.ScissorArray[0].Height);
+ if (ctx-Scissor.ScissorArray[i].X (GLint)scissor[i].minx)
+scissor[i].minx = ctx-Scissor.ScissorArray[i].X;
+ if (ctx-Scissor.ScissorArray[i].Y (GLint)scissor[i].miny)
+scissor[i].miny = ctx-Scissor.ScissorArray[i].Y;
- if (ctx-Scissor.ScissorArray[0].X (GLint)scissor.minx)
- scissor.minx = ctx-Scissor.ScissorArray[0].X;
- if (ctx-Scissor.ScissorArray[0].Y (GLint)scissor.miny)
- scissor.miny = ctx-Scissor.ScissorArray[0].Y;
+ if (xmax (GLint) scissor[i].maxx)
+scissor[i].maxx = xmax;
+ if (ymax (GLint) scissor[i].maxy)
+scissor[i].maxy = ymax;
- if (xmax (GLint) scissor.maxx)
- scissor.maxx = xmax;
- if (ymax (GLint) scissor.maxy)
- scissor.maxy = ymax;
+ /* check for null space */
+ if (scissor[i].minx = scissor[i].maxx || scissor[i].miny =
scissor[i].maxy)
+scissor[i].minx = scissor[i].miny = scissor[i].maxx =
scissor[i].maxy = 0;
+ }
- /* check for null space */
- if (scissor.minx = scissor.maxx || scissor.miny = scissor.maxy)
- scissor.minx = scissor.miny = scissor.maxx = scissor.maxy = 0;
- }
-
- /* Now invert Y if needed.
-* Gallium drivers use the convention Y=0=top for surfaces.
-*/
- if (st_fb_orientation(fb) == Y_0_TOP) {
- miny = fb-Height - scissor.maxy;
- maxy = fb-Height - scissor.miny;
- scissor.miny = miny;
- scissor.maxy = maxy;
- }
+ /* Now invert Y if needed.
+ * Gallium drivers use the convention Y=0=top for surfaces.
+ */
+ if (st_fb_orientation(fb) == Y_0_TOP) {
+ miny = fb-Height - scissor[i].maxy;
+ maxy = fb-Height - scissor[i].miny;
+ scissor[i].miny = miny;
+ scissor[i].maxy = maxy;
+ }
- if (memcmp(scissor, st-state.scissor, sizeof(scissor)) != 0) {
- /* state has changed */
- st-state.scissor = scissor; /* struct copy */
- st-pipe-set_scissor_states(st-pipe, 0, 1, scissor); /* activate */
+ if (memcmp(scissor[i], st-state.scissor[i], sizeof(scissor)) != 0) {
+ /* state has changed */
+ st-state.scissor[i] = scissor[i]; /* struct copy */
+ changed = true;
+ }
}
+ if (changed)
+ st-pipe-set_scissor_states(st-pipe, 0, ctx-Const.MaxViewports,
scissor); /* activate */
}
diff --git a/src/mesa/state_tracker/st_atom_viewport.c
b/src/mesa/state_tracker/st_atom_viewport.c
index 8c6d679..7584f9b 100644
--- a/src/mesa/state_tracker/st_atom_viewport.c
+++ b/src/mesa/state_tracker/st_atom_viewport.c
@@ -43,7 +43,7 @@ update_viewport( struct st_context *st )
{
struct gl_context *ctx = st-ctx;
GLfloat yScale, yBias;
-
+ int i;
/* _NEW_BUFFERS
*/
if (st_fb_orientation(ctx-DrawBuffer) == Y_0_TOP) {
@@ -61,26 +61,29 @@ update_viewport( struct st_context *st )
/* _NEW_VIEWPORT
*/
+ for (i = 0; i
Re: [Mesa-dev] [PATCH 42/42] i965/blorp: switch eu-emitter to use FS IR and fs_generator
On Mon, Jan 20, 2014 at 08:35:44PM -0800, Paul Berry wrote: On 20 December 2013 06:39, Topi Pohjolainen topi.pohjolai...@intel.com wrote: Unfortunately the unit tests need to be patched as well. This is because the direct eu-emitter only patches jump counters for if-else (see patch_IF_ELSE()) while the fs_generator patches the endif as well (see brw_set_uip_jip()). I think the fact that blorp wasn't patching jump counters for if-else was a previously undiscovered bug in blorp. I suspect that the reason we never discovered it was because blorp doesn't contain complex enough flow control to cause an endif to ever execute a jump. I'd recommend splitting this patch into two patches: 1. fix the previously undiscovered blorp bug (by having blorp call brw_set_uip_jip() at the appropriate time) and update the unit tests. I'll work on this first, and then rebase the rest on top. 2. switch eu-emitter to use FS IR and fs_generator. That will make it a lot easier to reassure ourselves that the changes are correct, and in the unlikely event that we later discover that they aren't, it'll make it easier to bisect to the problem. With this patch split, it is: Reviewed-by: Paul Berry stereotype...@gmail.com I've sent comments on patches 24, 27, 37, 38, 39, and 41. All the others are: Reviewed-by: Paul Berry stereotype...@gmail.com I really like how you structured this series, Topi. It was easy to follow what you did and to reassure myself that it was correct. And I'm really glad you did it, since it led us to discover two preexisting bugs! Nice work. Well, I'm really glad you liked it. I desperately wanted to avoid a mega patch but the same time would have liked to do the changes in place instead of the split into a separate emitter. After a while I just gave up as I couldn't get anywhere and opted for the split instead. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Reserve space for Vertex Count in GS outputs.
v2: Also increment ir-offset in the GS visitor, rather than at the final assembly generation stage (requested by Paul). Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_vec4_gs.c | 6 ++ src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 7 +++ 2 files changed, 13 insertions(+) Hey Paul, I think I implemented all of your feedback from last time. (Previously, I'd done this in gen8_vec4_generator, and you asked me to move it to the visitor. This patch does that - and it is indeed much nicer.) --Ken diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c b/src/mesa/drivers/dri/i965/brw_vec4_gs.c index 018b0b6..c40112b 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_gs.c +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs.c @@ -194,6 +194,12 @@ do_gs_prog(struct brw_context *brw, c.prog_data.output_vertex_size_hwords * 32 * gp-program.VerticesOut; output_size_bytes += 32 * c.prog_data.control_data_header_size_hwords; + /* Broadwell stores Vertex Count as a full 8 DWord (32 byte) URB output, +* which comes before the control header. +*/ + if (brw-gen = 8) + output_size_bytes += 32; + assert(output_size_bytes = 1); if (output_size_bytes GEN7_MAX_GS_URB_ENTRY_SIZE_BYTES) return false; diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp index f33c80d..f0351ea 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp @@ -267,6 +267,13 @@ vec4_gs_visitor::emit_urb_write_opcode(bool complete) vec4_instruction *inst = emit(GS_OPCODE_URB_WRITE); inst-offset = c-prog_data.control_data_header_size_hwords; + + /* We need to increment Global Offset by 1 to make room for Broadwell's +* extra Vertex Count payload at the beginning of the URB entry. +*/ + if (brw-gen = 8) + inst-offset++; + inst-urb_write_flags = BRW_URB_WRITE_PER_SLOT_OFFSET; return inst; } -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73854] GoldSrc and Source Games Segfault on Launch
https://bugs.freedesktop.org/show_bug.cgi?id=73854 --- Comment #6 from Tapani Pälli lem...@gmail.com --- For me CounterStrike 1.6 works fine using 10.1.0-devel (git-ded5674), this is with Intel Haswell and Ubuntu 12.04, I believe this game is using GoldSrc engine. I also tried HL2 with Ivybridge + mesa master and it worked fine. Not sure how to track libudev version (which is used), steam-runtime has its own copy of libudev so maybe it causes some conflict in your system? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Reserve space for Vertex Count in GS outputs.
On 20 January 2014 22:56, Kenneth Graunke kenn...@whitecape.org wrote: v2: Also increment ir-offset in the GS visitor, rather than at the final assembly generation stage (requested by Paul). Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_vec4_gs.c | 6 ++ src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 7 +++ 2 files changed, 13 insertions(+) Hey Paul, I think I implemented all of your feedback from last time. (Previously, I'd done this in gen8_vec4_generator, and you asked me to move it to the visitor. This patch does that - and it is indeed much nicer.) --Ken Looks good, thanks! Reviewed-by: Paul Berry stereotype...@gmail.com diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c b/src/mesa/drivers/dri/i965/brw_vec4_gs.c index 018b0b6..c40112b 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_gs.c +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs.c @@ -194,6 +194,12 @@ do_gs_prog(struct brw_context *brw, c.prog_data.output_vertex_size_hwords * 32 * gp-program.VerticesOut; output_size_bytes += 32 * c.prog_data.control_data_header_size_hwords; + /* Broadwell stores Vertex Count as a full 8 DWord (32 byte) URB output, +* which comes before the control header. +*/ + if (brw-gen = 8) + output_size_bytes += 32; + assert(output_size_bytes = 1); if (output_size_bytes GEN7_MAX_GS_URB_ENTRY_SIZE_BYTES) return false; diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp index f33c80d..f0351ea 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp @@ -267,6 +267,13 @@ vec4_gs_visitor::emit_urb_write_opcode(bool complete) vec4_instruction *inst = emit(GS_OPCODE_URB_WRITE); inst-offset = c-prog_data.control_data_header_size_hwords; + + /* We need to increment Global Offset by 1 to make room for Broadwell's +* extra Vertex Count payload at the beginning of the URB entry. +*/ + if (brw-gen = 8) + inst-offset++; + inst-urb_write_flags = BRW_URB_WRITE_PER_SLOT_OFFSET; return inst; } -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
