Re: [Mesa-dev] [PATCH] i965: Emit a performance warning on conditional rendering.
Since we were just discussing this in IRC,
Reviewed-by: Chris Forbes
On Mon, Aug 4, 2014 at 6:54 PM, Kenneth Graunke wrote:
> We have a CPU-side implementation of conditional rendering; it really
> should be done on the GPU. It's not necessarily that hard, but nobody
> has gotten to fixing it yet.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_draw.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 4dae7d3..412c360 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -539,6 +539,11 @@ void brw_draw_prims( struct gl_context *ctx,
>
> assert(unused_tfb_object == NULL);
>
> + if (ctx->Query.CondRenderQuery) {
> + perf_debug("Conditional rendering is implemented in software and may "
> + "stall. This should be fixed in the driver.\n");
> + }
> +
> if (!_mesa_check_conditional_render(ctx))
>return;
>
> --
> 2.0.2
>
> ___
> 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] [PATCH] meta: Remove dither bit from blit paths that do not need it
On Sun, Aug 03, 2014 at 06:32:54PM -0700, Kenneth Graunke wrote: > On Friday, August 01, 2014 08:37:53 PM Topi Pohjolainen wrote: > > Similarly to an older patch. This is the minimum needed to fix the > > bug but there are other meta-paths remaining that have the bit > > since its introduction but not before. > > Why not just drop the > >_mesa_set_enable(ctx, GL_DITHER, GL_TRUE); > > in _mesa_meta_begin(), which was introduced in commit > 05b52efbc977311c96ba31ac5fa2c95fe525d85e? > > Neil's new glClearTexSubImage path only wants it to be saved/restored so he > can /disable/ it. I see no reason to explicitly turn it /on/ for all paths... > > That should fix the bug. I'm fine with this. But just to mention, we discussed this a little when Neil introduded the original logic. The spec for glEnable() says that by default all the capabilities are disabled except GL_DITHER which is TRUE. To me it is not entirely clear if meta paths should be using the default state or the current. > > > > > commit e526ebf35c113d59eb0b860e492c1308d3862ee9 > > Author: Kenneth Graunke > > Date: Mon May 5 14:03:46 2014 -0700 > > > > meta: Add a new MESA_META_DRAW_BUFFERS bit. > > > > This will be used for saving/restoring the glDrawBuffers state. > > For now, make sure that existing users of MESA_META_ALL don't get > > the new bit, since they probably won't want it. > > > > Cc: "10.2" > > Signed-off-by: Kenneth Graunke > > Reviewed-by: Anuj Phogat > > Reviewed-by: Eric Anholt > > Quoting this commit message is a bit confusing - usually, when people quote > other commits, it's referring to a regression...and the regression was from > 05b52efbc977311c96ba31ac5fa2c95fe525d85e. Masking off unnecessary > save/restore bits is a pretty common thing to do. > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=81828. > > > > Signed-off-by: Topi Pohjolainen > > CC: Neil Roberts > > --- > > src/mesa/drivers/common/meta.c | 3 ++- > > src/mesa/drivers/common/meta_blit.c | 3 ++- > > 2 files changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c > > index 604bc21..b4f26d0 100644 > > --- a/src/mesa/drivers/common/meta.c > > +++ b/src/mesa/drivers/common/meta.c > > @@ -2798,7 +2798,8 @@ copytexsubimage_using_blit_framebuffer(struct > > gl_context *ctx, GLuint dims, > > > > _mesa_unlock_texture(ctx, texObj); > > > > - _mesa_meta_begin(ctx, MESA_META_ALL & ~MESA_META_DRAW_BUFFERS); > > + _mesa_meta_begin(ctx, MESA_META_ALL & ~(MESA_META_DRAW_BUFFERS | > > + MESA_META_DITHER)); > > > > _mesa_GenFramebuffers(1, &fbo); > > _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo); > > diff --git a/src/mesa/drivers/common/meta_blit.c > > b/src/mesa/drivers/common/meta_blit.c > > index bbf0c3c..d150e8a 100644 > > --- a/src/mesa/drivers/common/meta_blit.c > > +++ b/src/mesa/drivers/common/meta_blit.c > > @@ -707,7 +707,8 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx, > > /* Only scissor affects blit, but we're doing to set a custom scissor if > > * necessary anyway, so save/clear state. > > */ > > - _mesa_meta_begin(ctx, MESA_META_ALL & ~MESA_META_DRAW_BUFFERS); > > + _mesa_meta_begin(ctx, MESA_META_ALL & ~(MESA_META_DRAW_BUFFERS | > > + MESA_META_DITHER)); > > > > /* If the clipping earlier changed the destination rect at all, then > > * enable the scissor to clip to it. > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] winsys/radeon: fix nop packet padding for hawaii
On 02.08.2014 03:30, Andreas Boll wrote:
> The initial firmware for hawaii does not support type3 nop packet.
> Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
> If the returned value is 3, then the new firmware is used.
>
> This patch uses type2 for the old firmware and type3 for the new firmware.
>
> It fixes the cases when the old firmware is used and the user wants to
> manually enable acceleration.
> The two possible scenarios are:
> - the kernel has no support for the new firmware.
> - the kernel has support for the new firmware but only the old firmware
>is available.
>
> v2:
> - Fix indentation
> - Use private struct radeon_drm_winsys instead of public struct radeon_info
> - Rename r600_accel_working2 to accel_working2
>
> v3:
> - Use type2 nop packet for returned value < 3
>
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: Alex Deucher
> Cc: Jérôme Glisse
> Cc: Marek Olšák
> Signed-off-by: Andreas Boll
> ---
>
> Unfortunately I can't test this patch myself since I don't own a hawaii card.
> So I'd need someone to test this patch on kernel >= 3.16-rc7.
> This patch would bring us one step further for hawaii acceleration on kernel
> 3.16.
>
> Note: v3 is required for this kernel patch:
> http://lists.freedesktop.org/archives/dri-devel/2014-August/065308.html
>
> Finally we could enable hawaii acceleration if the query returns > 2
[...]
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> index 910d06b..9c55c11 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> @@ -395,6 +395,9 @@ static boolean do_winsys_init(struct radeon_drm_winsys
> *ws)
> radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_SH_PER_SE, NULL,
> &ws->info.max_sh_per_se);
>
> +radeon_get_drm_value(ws->fd, RADEON_INFO_ACCEL_WORKING2, NULL,
> + &ws->accel_working2);
> +
> if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, NULL,
> ws->info.si_tile_mode_array)) {
> ws->info.si_tile_mode_array_valid = TRUE;
Please make the winsys fail to initialize on Hawaii if
RADEON_INFO_ACCEL_WORKING2 returns < 2.
--
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
Re: [Mesa-dev] [PATCH v3 10/19] i965/gen6 depth surface: calculate minimum array element being rendered
On Fri, Aug 01, 2014 at 12:43:38PM -0700, Jordan Justen wrote:
> On Fri, Aug 1, 2014 at 2:44 AM, Pohjolainen, Topi
> wrote:
> > On Fri, Aug 01, 2014 at 12:53:40AM -0700, Jordan Justen wrote:
> >> (a23cfb8 for gen6)
> >>
> >> In layered rendering this will be 0. Otherwise it will be the
> >> selected slice.
> >>
> >> Signed-off-by: Jordan Justen
> >> ---
> >> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 3 +++
> >> src/mesa/drivers/dri/i965/gen6_depth_state.c | 10 ++
> >> 2 files changed, 13 insertions(+)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> index 131c4aa..ff1732d 100644
> >> --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> @@ -793,6 +793,7 @@ gen6_blorp_emit_depth_stencil_config(struct
> >> brw_context *brw,
> >> uint32_t tile_mask_x, tile_mask_y;
> >> uint32_t surftype;
> >> unsigned int depth = MAX2(params->depth.mt->logical_depth0, 1);
> >> + unsigned int min_array_element;
> >> GLenum gl_target = params->depth.mt->target;
> >> unsigned int lod;
> >>
> >> @@ -818,6 +819,8 @@ gen6_blorp_emit_depth_stencil_config(struct
> >> brw_context *brw,
> >> NULL,
> >> &tile_mask_x, &tile_mask_y);
> >>
> >> + min_array_element = params->depth.layer;
> >
> > This could be slightly simpler:
> >
> > const unsigned min_array_element = params->depth.layer;
> >
> >> +
> >> lod = params->depth.level - params->depth.mt->first_level;
> >>
> >> /* 3DSTATE_DEPTH_BUFFER */
> >> diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> >> b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> >> index 1f36ed8..5e3981c 100644
> >> --- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> >> +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> >> @@ -48,6 +48,7 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
> >> struct gl_framebuffer *fb = ctx->DrawBuffer;
> >> uint32_t surftype;
> >> unsigned int depth = 1;
> >> + unsigned int min_array_element;
> >> GLenum gl_target = GL_TEXTURE_2D;
> >> unsigned int lod;
> >> const struct intel_renderbuffer *irb = NULL;
> >> @@ -100,6 +101,15 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
> >>break;
> >> }
> >>
> >> + if (fb->MaxNumLayers > 0 || !irb) {
> >> + min_array_element = 0;
> >> + } else if (irb->mt->num_samples > 1) {
> >> + /* Convert physical layer to logical layer. */
> >> + min_array_element = irb->mt_layer / irb->mt->num_samples;
> >
> > I still don't understand this. This would be needed only for surfaces were
> > samples indices are in their own layers. On gen6 this is never the case as
> > all the surfaces are interleaved (i.e., samples are in the same physical
> > layer). Moreover, this is true also on gen7 for depth surfaces - and hence
> > I'm also questioning the existing logic in the gen7 specific path.
>
> I looked again, and I think gen7/gen8 does not divide by num_samples
> for depth state. (Chris changed this in 77d55ef4.) It does in
> gen7_wm_surface_state.c.
>
> A piglit run verifies that this works for gen6:
> const unsigned min_array_element = irb ? irb->mt_layer : 0;
> This matches gen7 & gen8 for depth state, so I'll change to this.
> Would that get an r-b from you for this patch?
Sure.
>
> But delving further into the "divide by num_samples" question,
> git grep -C5 "mt_layer =" src/mesa/drivers/dri/i965
> turned up some interesting results.
>
> intel_fbo.c:
> irb->mt_layer = layer_multiplier * layer;
> (For gen7+ UMS/CMS layer_multiplier = mt->num_samples)
>
> intel_fbo.h:
> * Note: for a 2D multisample array texture on Gen7+ using
> * INTEL_MSAA_LAYOUT_UMS or INTEL_MSAA_LAYOUT_CMS, mt_layer is the physical
> * layer holding sample 0. So, for example, if mt->num_samples == 4, then
> * logical layer n corresponds to mt_layer == 4*n.
>
> intel_mipmap_tree.c:compute_msaa_layout always returns IMS for depth,
> so that explains why in all cases we don't divide by num_samples for
> depth.
>
> It might be better to make a helper routine that adjusts layer based
> on the msaa layout type. Basically if UMS/CMS, divide by num_samples.
>
> Right now there is a lot of code path knowledge in this calculation.
> For instance:
> * on depth paths we are using IMS, so don't divide
> * on gen6 we only use IMS for color, so don't divide
> * on gen7/8 color, we are using UMS/CMS, so divide
Thanks for clarifying all this. And the helper sounds like a really good idea.
>
> -Jordan
>
> >> + } else {
> >> + min_array_element = irb->mt_layer;
> >> + }
> >> +
> >> lod = irb ? irb->mt_level - irb->mt->first_level : 0;
> >>
> >> BEGIN_BATCH(7);
> >> --
> >> 2.0.1
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> http://lists.freedesktop.org/mail
Re: [Mesa-dev] [PATCH v3 13/19] i965/gen6 depth surface: program 3DSTATE_DEPTH_BUFFER to top of surface
On Fri, Aug 01, 2014 at 01:27:49PM -0700, Jordan Justen wrote:
> On Fri, Aug 1, 2014 at 1:53 AM, Pohjolainen, Topi
> wrote:
> > On Fri, Aug 01, 2014 at 12:53:43AM -0700, Jordan Justen wrote:
> >> (bf25ee2 for gen6)
> >>
> >> Previously we would always find the 2D sub-surface of interest,
> >> and then program the surface to this location. Now we always
> >> program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
> >> To select the lod/slice, we utilize the lod & minimum array
> >> element fields.
> >>
> >> We also must disable brw_workaround_depthstencil_alignment for
> >> gen >= 6. Now the hardware will handle alignment when rendering
> >> to additional slices/LODs.
> >>
> >> v3:
> >> * Set depth_mt bo RELOC offset to 0, as was done in bf25ee2
> >>
> >> Signed-off-by: Jordan Justen
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56127
> >> ---
> >> src/mesa/drivers/dri/i965/brw_misc_state.c | 4 +-
> >> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 71
> >> +---
> >> src/mesa/drivers/dri/i965/gen6_depth_state.c | 35 ++
> >> 3 files changed, 51 insertions(+), 59 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
> >> b/src/mesa/drivers/dri/i965/brw_misc_state.c
> >> index 76e22bd..e3980fc 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_misc_state.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
> >> @@ -261,10 +261,10 @@ brw_workaround_depthstencil_alignment(struct
> >> brw_context *brw,
> >> if (stencil_irb)
> >>brw->depthstencil.stencil_mt = get_stencil_miptree(stencil_irb);
> >>
> >> - /* Gen7+ doesn't require the workarounds, since we always program the
> >> + /* Gen6+ doesn't require the workarounds, since we always program the
> >> * surface state at the start of the whole surface.
> >> */
> >> - if (brw->gen >= 7)
> >> + if (brw->gen >= 6)
> >>return;
> >>
> >> /* Check if depth buffer is in depth/stencil format. If so, then it's
> >> only
> >> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> index dca6bfc..5a56442 100644
> >> --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> >> @@ -787,10 +787,6 @@ static void
> >> gen6_blorp_emit_depth_stencil_config(struct brw_context *brw,
> >> const brw_blorp_params *params)
> >> {
> >> - struct gl_context *ctx = &brw->ctx;
> >> - uint32_t draw_x = params->depth.x_offset;
> >> - uint32_t draw_y = params->depth.y_offset;
> >> - uint32_t tile_mask_x, tile_mask_y;
> >> uint32_t surfwidth, surfheight;
> >> uint32_t surftype;
> >> unsigned int depth = MAX2(params->depth.mt->logical_depth0, 1);
> >> @@ -814,12 +810,6 @@ gen6_blorp_emit_depth_stencil_config(struct
> >> brw_context *brw,
> >>break;
> >> }
> >>
> >> - brw_get_depthstencil_tile_masks(params->depth.mt,
> >> - params->depth.level,
> >> - params->depth.layer,
> >> - NULL,
> >> - &tile_mask_x, &tile_mask_y);
> >> -
> >> min_array_element = params->depth.layer;
> >>
> >> lod = params->depth.level - params->depth.mt->first_level;
> >> @@ -838,55 +828,42 @@ gen6_blorp_emit_depth_stencil_config(struct
> >> brw_context *brw,
> >>
> >> /* 3DSTATE_DEPTH_BUFFER */
> >> {
> >> - uint32_t tile_x = draw_x & tile_mask_x;
> >> - uint32_t tile_y = draw_y & tile_mask_y;
> >> - uint32_t offset =
> >> - intel_miptree_get_aligned_offset(params->depth.mt,
> >> - draw_x & ~tile_mask_x,
> >> - draw_y & ~tile_mask_y, false);
> >> -
> >> - /* According to the Sandy Bridge PRM, volume 2 part 1, pp326-327
> >> - * (3DSTATE_DEPTH_BUFFER dw5), in the documentation for "Depth
> >> - * Coordinate Offset X/Y":
> >> - *
> >> - * "The 3 LSBs of both offsets must be zero to ensure correct
> >> - * alignment"
> >> - *
> >> - * We have no guarantee that tile_x and tile_y are correctly
> >> aligned,
> >> - * since they are determined by the mipmap layout, which is only
> >> aligned
> >> - * to multiples of 4.
> >> - *
> >> - * So, to avoid hanging the GPU, just smash the low order 3 bits of
> >> - * tile_x and tile_y to 0. This is a temporary workaround until we
> >> come
> >> - * up with a better solution.
> >> - */
> >> - WARN_ONCE((tile_x & 7) || (tile_y & 7),
> >> -"Depth/stencil buffer needs alignment to 8-pixel
> >> boundaries.\n"
> >> -"Truncating offset, bad rendering may occur.\n");
> >> - tile_x &= ~7;
> >> - tile_y &= ~7;
> >> -
> >>intel_emit_post_sync_nonzero_flush(brw);
> >>intel_emit_depth_stal
[Mesa-dev] [PATCH 02/11] i965/fs: Collect all emits of texture ops for Gen5/6 into one place
Reduces duplication, and will do so even more when we change the sampler
plumbing.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 31
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index d16a253..21863ee 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1324,24 +1324,24 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
mlen += reg_width;
}
- fs_inst *inst = NULL;
+ enum opcode opcode;
switch (ir->op) {
case ir_tex:
- inst = emit(SHADER_OPCODE_TEX, dst, reg_undef);
+ opcode = SHADER_OPCODE_TEX;
break;
case ir_txb:
mlen = MAX2(mlen, header_present + 4 * reg_width);
emit(MOV(fs_reg(MRF, base_mrf + mlen), lod));
mlen += reg_width;
- inst = emit(FS_OPCODE_TXB, dst, reg_undef);
+ opcode = FS_OPCODE_TXB;
break;
case ir_txl:
mlen = MAX2(mlen, header_present + 4 * reg_width);
emit(MOV(fs_reg(MRF, base_mrf + mlen), lod));
mlen += reg_width;
- inst = emit(SHADER_OPCODE_TXL, dst, reg_undef);
+ opcode = SHADER_OPCODE_TXL;
break;
case ir_txd: {
mlen = MAX2(mlen, header_present + 4 * reg_width); /* skip over 'ai' */
@@ -1365,23 +1365,26 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
mlen += reg_width;
}
- inst = emit(SHADER_OPCODE_TXD, dst);
+ opcode = SHADER_OPCODE_TXD;
break;
}
case ir_txs:
emit(MOV(fs_reg(MRF, base_mrf + mlen, BRW_REGISTER_TYPE_UD), lod));
mlen += reg_width;
- inst = emit(SHADER_OPCODE_TXS, dst, reg_undef);
+
+ opcode = SHADER_OPCODE_TXS;
break;
case ir_query_levels:
emit(MOV(fs_reg(MRF, base_mrf + mlen, BRW_REGISTER_TYPE_UD),
fs_reg(0u)));
mlen += reg_width;
- inst = emit(SHADER_OPCODE_TXS, dst, reg_undef);
+
+ opcode = SHADER_OPCODE_TXS;
break;
case ir_txf:
mlen = header_present + 4 * reg_width;
emit(MOV(fs_reg(MRF, base_mrf + mlen - reg_width, BRW_REGISTER_TYPE_UD),
lod));
- inst = emit(SHADER_OPCODE_TXF, dst, reg_undef);
+
+ opcode = SHADER_OPCODE_TXF;
break;
case ir_txf_ms:
mlen = header_present + 4 * reg_width;
@@ -1391,18 +1394,20 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
/* sample index */
emit(MOV(fs_reg(MRF, base_mrf + mlen, BRW_REGISTER_TYPE_UD),
sample_index));
mlen += reg_width;
- inst = emit(SHADER_OPCODE_TXF_CMS, dst, reg_undef);
+
+ opcode = SHADER_OPCODE_TXF_CMS;
break;
case ir_lod:
- inst = emit(SHADER_OPCODE_LOD, dst, reg_undef);
+ opcode = SHADER_OPCODE_LOD;
break;
case ir_tg4:
- inst = emit(SHADER_OPCODE_TG4, dst, reg_undef);
+ opcode = SHADER_OPCODE_TG4;
break;
default:
- fail("unrecognized texture opcode");
- break;
+ unreachable("not reached");
}
+
+ fs_inst *inst = emit(opcode, dst, reg_undef);
inst->base_mrf = base_mrf;
inst->mlen = mlen;
inst->header_present = header_present;
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/11] i965/fs: Collect all emits of texture ops for Gen4 into one place
Reduces duplication, and will do so even more when we change the sampler
plumbing.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 31 ++--
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 0d9c684..d16a253 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1251,29 +1251,20 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
BRW_REGISTER_TYPE_F));
}
- fs_inst *inst = NULL;
+ enum opcode opcode;
+
switch (ir->op) {
- case ir_tex:
- inst = emit(SHADER_OPCODE_TEX, dst, reg_undef);
- break;
- case ir_txb:
- inst = emit(FS_OPCODE_TXB, dst, reg_undef);
- break;
- case ir_txl:
- inst = emit(SHADER_OPCODE_TXL, dst, reg_undef);
- break;
- case ir_txd:
- inst = emit(SHADER_OPCODE_TXD, dst, reg_undef);
- break;
- case ir_txs:
- inst = emit(SHADER_OPCODE_TXS, dst, reg_undef);
- break;
- case ir_txf:
- inst = emit(SHADER_OPCODE_TXF, dst, reg_undef);
- break;
+ case ir_tex: opcode = SHADER_OPCODE_TEX; break;
+ case ir_txb: opcode = FS_OPCODE_TXB; break;
+ case ir_txl: opcode = SHADER_OPCODE_TXL; break;
+ case ir_txd: opcode = SHADER_OPCODE_TXD; break;
+ case ir_txs: opcode = SHADER_OPCODE_TXS; break;
+ case ir_txf: opcode = SHADER_OPCODE_TXF; break;
default:
- fail("unrecognized texture opcode");
+ unreachable("not reached");
}
+
+ fs_inst *inst = emit(opcode, dst, reg_undef);
inst->base_mrf = base_mrf;
inst->mlen = mlen;
inst->header_present = true;
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/11] i965: Rework sampler index handling in LIR
Previously sampler indices were stored in a dedicated field of backend_instruction. This series reworks them to be passed as the src1 operand, mirroring how we deal with UBO accesses, etc. This is required in order to relax the restriction that sampler array indices be constant expressions. (Well, to do it tidily, at least.) No regressions on my Haswell. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/11] i965/fs: pass sampler as src1 of texture op
---
src/mesa/drivers/dri/i965/brw_fs.h | 15 +++---
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 29 ++--
3 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 9ba3f38..47aebad 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -241,8 +241,8 @@ public:
void visit(ir_emit_vertex *);
void visit(ir_end_primitive *);
- uint32_t gather_channel(ir_texture *ir, int sampler);
- void swizzle_result(ir_texture *ir, fs_reg orig_val, int sampler);
+ uint32_t gather_channel(ir_texture *ir, uint32_t sampler);
+ void swizzle_result(ir_texture *ir, fs_reg orig_val, uint32_t sampler);
fs_inst *emit(fs_inst *inst);
void emit(exec_list list);
@@ -371,16 +371,17 @@ public:
void emit_interpolation_setup_gen6();
void compute_sample_position(fs_reg dst, fs_reg int_sample_pos);
fs_reg rescale_texcoord(ir_texture *ir, fs_reg coordinate,
- bool is_rect, int sampler, int texunit);
+ bool is_rect, uint32_t sampler, int texunit);
fs_inst *emit_texture_gen4(ir_texture *ir, fs_reg dst, fs_reg coordinate,
- fs_reg shadow_comp, fs_reg lod, fs_reg lod2);
+ fs_reg shadow_comp, fs_reg lod, fs_reg lod2,
+ uint32_t sampler);
fs_inst *emit_texture_gen5(ir_texture *ir, fs_reg dst, fs_reg coordinate,
fs_reg shadow_comp, fs_reg lod, fs_reg lod2,
- fs_reg sample_index);
+ fs_reg sample_index, uint32_t sampler);
fs_inst *emit_texture_gen7(ir_texture *ir, fs_reg dst, fs_reg coordinate,
fs_reg shadow_comp, fs_reg lod, fs_reg lod2,
- fs_reg sample_index, fs_reg mcs, int sampler);
- fs_reg emit_mcs_fetch(ir_texture *ir, fs_reg coordinate, int sampler);
+ fs_reg sample_index, fs_reg mcs, uint32_t
sampler);
+ fs_reg emit_mcs_fetch(ir_texture *ir, fs_reg coordinate, uint32_t sampler);
void emit_gen6_gather_wa(uint8_t wa, fs_reg dst);
fs_reg fix_math_operand(fs_reg src);
fs_inst *emit_math(enum opcode op, fs_reg dst, fs_reg src0);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
index 0c5daa7..35c056f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
@@ -493,9 +493,9 @@ fs_visitor::emit_fragment_program_code()
if (brw->gen >= 7) {
inst = emit_texture_gen7(ir, dst, coordinate, shadow_c, lod, dpdy,
sample_index, fs_reg(0u), fpi->TexSrcUnit);
} else if (brw->gen >= 5) {
-inst = emit_texture_gen5(ir, dst, coordinate, shadow_c, lod, dpdy,
sample_index);
+inst = emit_texture_gen5(ir, dst, coordinate, shadow_c, lod, dpdy,
sample_index, fpi->TexSrcUnit);
} else {
-inst = emit_texture_gen4(ir, dst, coordinate, shadow_c, lod, dpdy);
+inst = emit_texture_gen4(ir, dst, coordinate, shadow_c, lod, dpdy,
fpi->TexSrcUnit);
}
inst->sampler = fpi->TexSrcUnit;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 21863ee..8a69f25 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1119,7 +1119,8 @@ fs_visitor::visit(ir_assignment *ir)
fs_inst *
fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, fs_reg coordinate,
- fs_reg shadow_c, fs_reg lod, fs_reg dPdy)
+ fs_reg shadow_c, fs_reg lod, fs_reg dPdy,
+ uint32_t sampler)
{
int mlen;
int base_mrf = 1;
@@ -1264,7 +1265,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
unreachable("not reached");
}
- fs_inst *inst = emit(opcode, dst, reg_undef);
+ fs_inst *inst = emit(opcode, dst, reg_undef, fs_reg(sampler));
inst->base_mrf = base_mrf;
inst->mlen = mlen;
inst->header_present = true;
@@ -1292,7 +1293,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
fs_inst *
fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg dst, fs_reg coordinate,
fs_reg shadow_c, fs_reg lod, fs_reg lod2,
- fs_reg sample_index)
+ fs_reg sample_index, uint32_t sampler)
{
int mlen = 0;
int base_mrf = 2;
@@ -1407,7 +1408,7 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
unreachable("not reached");
}
- fs_inst *inst = emit(opcode, dst, reg_undef);
+ fs_inst *inst = emit(opcode, dst, reg_und
[Mesa-dev] [PATCH 06/11] i965/fs/Gen8: Pass sampler_index to generate_tex
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_fs.h | 3 ++-
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 18 --
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index f3ce4e0..dfb13ea 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -717,7 +717,8 @@ private:
void generate_fb_write(fs_inst *inst);
void generate_linterp(fs_inst *inst, struct brw_reg dst,
struct brw_reg *src);
- void generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg src);
+ void generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg src,
+ struct brw_reg sampler_index);
void generate_math1(fs_inst *inst, struct brw_reg dst, struct brw_reg src);
void generate_math2(fs_inst *inst, struct brw_reg dst,
struct brw_reg src0, struct brw_reg src1);
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index 4e53d15..f4aae67 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -153,7 +153,8 @@ gen8_fs_generator::generate_linterp(fs_inst *inst,
void
gen8_fs_generator::generate_tex(fs_inst *ir,
struct brw_reg dst,
-struct brw_reg src)
+struct brw_reg src,
+struct brw_reg sampler_index)
{
int msg_type = -1;
int rlen = 4;
@@ -238,6 +239,11 @@ gen8_fs_generator::generate_tex(fs_inst *ir,
dst = vec16(dst);
}
+ assert(sampler_index.file == BRW_IMMEDIATE_VALUE);
+ assert(sampler_index.type == BRW_REGISTER_TYPE_UD);
+
+ uint32_t sampler = sampler_index.dw1.ud;
+
if (ir->header_present) {
/* The send-from-GRF for SIMD16 texturing with a header has an extra
* hardware register allocated to it, which we need to skip over (since
@@ -258,7 +264,7 @@ gen8_fs_generator::generate_tex(fs_inst *ir,
brw_imm_ud(ir->texture_offset));
}
- if (ir->sampler >= 16) {
+ if (sampler >= 16) {
/* The "Sampler Index" field can only store values between 0 and 15.
* However, we can add an offset to the "Sampler State Pointer"
* field, effectively selecting a different set of 16 samplers.
@@ -271,7 +277,7 @@ gen8_fs_generator::generate_tex(fs_inst *ir,
gen8_instruction *add =
ADD(get_element_ud(src, 3),
get_element_ud(brw_vec8_grf(0, 0), 3),
-brw_imm_ud(16 * (ir->sampler / 16) * sampler_state_size));
+brw_imm_ud(16 * (sampler / 16) * sampler_state_size));
gen8_set_mask_control(add, BRW_MASK_DISABLE);
}
@@ -279,14 +285,14 @@ gen8_fs_generator::generate_tex(fs_inst *ir,
}
uint32_t surf_index =
- prog_data->base.binding_table.texture_start + ir->sampler;
+ prog_data->base.binding_table.texture_start + sampler;
gen8_instruction *inst = next_inst(BRW_OPCODE_SEND);
gen8_set_dst(brw, inst, dst);
gen8_set_src0(brw, inst, src);
gen8_set_sampler_message(brw, inst,
surf_index,
-ir->sampler % 16,
+sampler % 16,
msg_type,
rlen,
ir->mlen,
@@ -1137,7 +1143,7 @@ gen8_fs_generator::generate_code(exec_list *instructions)
case SHADER_OPCODE_LOD:
case SHADER_OPCODE_TG4:
case SHADER_OPCODE_TG4_OFFSET:
- generate_tex(ir, dst, src[0]);
+ generate_tex(ir, dst, src[0], src[1]);
break;
case FS_OPCODE_DDX:
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/11] i965/fs/Gen4-7: Pass sampler_index to generate_tex
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_fs.h | 3 ++-
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 18 --
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 47aebad..f3ce4e0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -594,7 +594,8 @@ private:
void generate_pixel_xy(struct brw_reg dst, bool is_x);
void generate_linterp(fs_inst *inst, struct brw_reg dst,
struct brw_reg *src);
- void generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg src);
+ void generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg src,
+ struct brw_reg sampler_index);
void generate_math_gen6(fs_inst *inst,
struct brw_reg dst,
struct brw_reg src0,
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 0cf9cfe..5f5c23e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -368,7 +368,8 @@ fs_generator::generate_math_g45(fs_inst *inst,
}
void
-fs_generator::generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg
src)
+fs_generator::generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg
src,
+ struct brw_reg sampler_index)
{
int msg_type = -1;
int rlen = 4;
@@ -536,6 +537,11 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
src.nr++;
}
+ assert(sampler_index.file == BRW_IMMEDIATE_VALUE);
+ assert(sampler_index.type == BRW_REGISTER_TYPE_UD);
+
+ uint32_t sampler = sampler_index.dw1.ud;
+
/* Load the message header if present. If there's a texture offset,
* we need to set it up explicitly and load the offset bitfield.
* Otherwise, we can use an implied move from g0 to the first message reg.
@@ -566,7 +572,7 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
brw_imm_ud(inst->texture_offset));
}
- if (inst->sampler >= 16) {
+ if (sampler >= 16) {
/* The "Sampler Index" field can only store values between 0 and
15.
* However, we can add an offset to the "Sampler State Pointer"
* field, effectively selecting a different set of 16 samplers.
@@ -580,7 +586,7 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
brw_ADD(p,
get_element_ud(header_reg, 3),
get_element_ud(brw_vec8_grf(0, 0), 3),
-brw_imm_ud(16 * (inst->sampler / 16) *
sampler_state_size));
+brw_imm_ud(16 * (sampler / 16) * sampler_state_size));
}
brw_pop_insn_state(p);
}
@@ -589,14 +595,14 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
uint32_t surface_index = ((inst->opcode == SHADER_OPCODE_TG4 ||
inst->opcode == SHADER_OPCODE_TG4_OFFSET)
? prog_data->base.binding_table.gather_texture_start
- : prog_data->base.binding_table.texture_start) + inst->sampler;
+ : prog_data->base.binding_table.texture_start) + sampler;
brw_SAMPLE(p,
retype(dst, BRW_REGISTER_TYPE_UW),
inst->base_mrf,
src,
surface_index,
- inst->sampler % 16,
+ sampler % 16,
msg_type,
rlen,
inst->mlen,
@@ -1745,7 +1751,7 @@ fs_generator::generate_code(exec_list *instructions)
case SHADER_OPCODE_LOD:
case SHADER_OPCODE_TG4:
case SHADER_OPCODE_TG4_OFFSET:
-generate_tex(inst, dst, src[0]);
+generate_tex(inst, dst, src[0], src[1]);
break;
case FS_OPCODE_DDX:
generate_ddx(inst, dst, src[0]);
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/11] i965/blorp: Put sampler index in src1 of texture ops
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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 c1676a9..7d4b327 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -78,7 +78,8 @@ brw_blorp_eu_emitter::emit_texture_lookup(const struct
brw_reg &dst,
unsigned base_mrf,
unsigned msg_length)
{
- fs_inst *inst = new (mem_ctx) fs_inst(op, dst, brw_message_reg(base_mrf));
+ fs_inst *inst = new (mem_ctx) fs_inst(op, dst, brw_message_reg(base_mrf),
+ fs_reg(0u));
inst->base_mrf = base_mrf;
inst->mlen = msg_length;
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/11] i965/vec4: Collect all emits of texture ops into one place
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 38 --
1 file changed, 12 insertions(+), 26 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index f03b3c9..47ad744 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2430,33 +2430,17 @@ vec4_visitor::visit(ir_texture *ir)
break;
}
- vec4_instruction *inst = NULL;
+ enum opcode opcode;
switch (ir->op) {
- case ir_tex:
- case ir_txl:
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXL);
- break;
- case ir_txd:
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXD);
- break;
- case ir_txf:
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXF);
- break;
- case ir_txf_ms:
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXF_CMS);
- break;
- case ir_txs:
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXS);
- break;
- case ir_tg4:
- if (has_nonconstant_offset)
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TG4_OFFSET);
- else
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TG4);
- break;
- case ir_query_levels:
- inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXS);
- break;
+ case ir_tex: opcode = SHADER_OPCODE_TXL; break;
+ case ir_txl: opcode = SHADER_OPCODE_TXL; break;
+ case ir_txd: opcode = SHADER_OPCODE_TXD; break;
+ case ir_txf: opcode = SHADER_OPCODE_TXF; break;
+ case ir_txf_ms: opcode = SHADER_OPCODE_TXF_CMS; break;
+ case ir_txs: opcode = SHADER_OPCODE_TXS; break;
+ case ir_tg4: opcode = has_nonconstant_offset
+ ? SHADER_OPCODE_TG4_OFFSET : SHADER_OPCODE_TG4; break;
+ case ir_query_levels: opcode = SHADER_OPCODE_TXS; break;
case ir_txb:
unreachable("TXB is not valid for vertex shaders.");
case ir_lod:
@@ -2465,6 +2449,8 @@ vec4_visitor::visit(ir_texture *ir)
unreachable("Unrecognized tex op");
}
+ vec4_instruction *inst = new(mem_ctx) vec4_instruction(this, opcode);
+
if (ir->offset != NULL && ir->op != ir_txf)
inst->texture_offset = brw_texture_offset(ctx,
ir->offset->as_constant());
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/11] i965/vec4: Pass sampler index in src1 for texture ops
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vec4.h | 6 +++---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 12
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 3d0df77..08a2638 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -527,10 +527,10 @@ public:
void emit_pack_half_2x16(dst_reg dst, src_reg src0);
void emit_unpack_half_2x16(dst_reg dst, src_reg src0);
- uint32_t gather_channel(ir_texture *ir, int sampler);
- src_reg emit_mcs_fetch(ir_texture *ir, src_reg coordinate, int sampler);
+ uint32_t gather_channel(ir_texture *ir, uint32_t sampler);
+ src_reg emit_mcs_fetch(ir_texture *ir, src_reg coordinate, uint32_t
sampler);
void emit_gen6_gather_wa(uint8_t wa, dst_reg dst);
- void swizzle_result(ir_texture *ir, src_reg orig_val, int sampler);
+ void swizzle_result(ir_texture *ir, src_reg orig_val, uint32_t sampler);
void emit_ndc_computation();
void emit_psiz_and_flags(struct brw_reg reg);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 47ad744..ca15bc9 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2314,7 +2314,7 @@ vec4_visitor::visit(ir_call *ir)
}
src_reg
-vec4_visitor::emit_mcs_fetch(ir_texture *ir, src_reg coordinate, int sampler)
+vec4_visitor::emit_mcs_fetch(ir_texture *ir, src_reg coordinate, uint32_t
sampler)
{
vec4_instruction *inst = new(mem_ctx) vec4_instruction(this,
SHADER_OPCODE_TXF_MCS);
inst->base_mrf = 2;
@@ -2323,6 +2323,8 @@ vec4_visitor::emit_mcs_fetch(ir_texture *ir, src_reg
coordinate, int sampler)
inst->dst = dst_reg(this, glsl_type::uvec4_type);
inst->dst.writemask = WRITEMASK_XYZW;
+ inst->src[1] = src_reg(sampler);
+
/* parameters are: u, v, r, lod; lod will always be zero due to api
restrictions */
int param_base = inst->base_mrf;
int coord_mask = (1 << ir->coordinate->type->vector_elements) - 1;
@@ -2341,7 +2343,7 @@ vec4_visitor::emit_mcs_fetch(ir_texture *ir, src_reg
coordinate, int sampler)
void
vec4_visitor::visit(ir_texture *ir)
{
- int sampler =
+ uint32_t sampler =
_mesa_get_sampler_uniform_value(ir->sampler, shader_prog, prog);
/* When tg4 is used with the degenerate ZERO/ONE swizzles, don't bother
@@ -2474,6 +2476,8 @@ vec4_visitor::visit(ir_texture *ir)
inst->dst.writemask = WRITEMASK_XYZW;
inst->shadow_compare = ir->shadow_comparitor != NULL;
+ inst->src[1] = src_reg(sampler);
+
/* MRF for the first parameter */
int param_base = inst->base_mrf + inst->header_present;
@@ -2625,7 +2629,7 @@ vec4_visitor::emit_gen6_gather_wa(uint8_t wa, dst_reg dst)
* Set up the gather channel based on the swizzle, for gather4.
*/
uint32_t
-vec4_visitor::gather_channel(ir_texture *ir, int sampler)
+vec4_visitor::gather_channel(ir_texture *ir, uint32_t sampler)
{
ir_constant *chan = ir->lod_info.component->as_constant();
int swiz = GET_SWZ(key->tex.swizzles[sampler], chan->value.i[0]);
@@ -2646,7 +2650,7 @@ vec4_visitor::gather_channel(ir_texture *ir, int sampler)
}
void
-vec4_visitor::swizzle_result(ir_texture *ir, src_reg orig_val, int sampler)
+vec4_visitor::swizzle_result(ir_texture *ir, src_reg orig_val, uint32_t
sampler)
{
int s = key->tex.swizzles[sampler];
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/11] i965: Get rid of backend_instruction::sampler
The generators no longer use this.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 1 -
src/mesa/drivers/dri/i965/brw_fs.cpp| 1 -
src/mesa/drivers/dri/i965/brw_fs_cse.cpp| 1 -
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 1 -
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp| 3 ---
src/mesa/drivers/dri/i965/brw_shader.h | 1 -
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 3 ---
7 files changed, 11 deletions(-)
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 7d4b327..6fc1e95 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -83,7 +83,6 @@ brw_blorp_eu_emitter::emit_texture_lookup(const struct
brw_reg &dst,
inst->base_mrf = base_mrf;
inst->mlen = msg_length;
- inst->sampler = 0;
inst->header_present = false;
insts.push_tail(inst);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0d1185b..15ad035 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -348,7 +348,6 @@ fs_inst::equals(fs_inst *inst) const
conditional_mod == inst->conditional_mod &&
mlen == inst->mlen &&
base_mrf == inst->base_mrf &&
- sampler == inst->sampler &&
target == inst->target &&
eot == inst->eot &&
header_present == inst->header_present &&
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index 63d87f9..01790ad 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
@@ -157,7 +157,6 @@ instructions_match(fs_inst *a, fs_inst *b)
a->mlen == b->mlen &&
a->regs_written == b->regs_written &&
a->base_mrf == b->base_mrf &&
- a->sampler == b->sampler &&
a->eot == b->eot &&
a->header_present == b->header_present &&
a->shadow_compare == b->shadow_compare)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
index 35c056f..8d07be2 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
@@ -498,7 +498,6 @@ fs_visitor::emit_fragment_program_code()
inst = emit_texture_gen4(ir, dst, coordinate, shadow_c, lod, dpdy,
fpi->TexSrcUnit);
}
- inst->sampler = fpi->TexSrcUnit;
inst->shadow_compare = fpi->TexShadow;
/* Reuse the GLSL swizzle_result() handler. */
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 8a69f25..32d0cb0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1769,7 +1769,6 @@ fs_visitor::emit_mcs_fetch(ir_texture *ir, fs_reg
coordinate, uint32_t sampler)
inst->regs_written = 4; /* we only care about one reg of response,
* but the sampler always writes 4/8
*/
- inst->sampler = sampler;
return dest;
}
@@ -1891,8 +1890,6 @@ fs_visitor::visit(ir_texture *ir)
if (ir->op == ir_tg4)
inst->texture_offset |= gather_channel(ir, sampler) << 16; // M0.2:16-17
- inst->sampler = sampler;
-
if (ir->shadow_comparitor)
inst->shadow_compare = true;
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index 5c48671..5980cf0 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -108,7 +108,6 @@ struct backend_instruction {
uint32_t texture_offset; /**< Texture offset bitfield */
uint32_t offset; /**< spill/unspill offset */
- uint8_t sampler;
uint8_t mlen; /**< SEND message length */
int8_t base_mrf; /**< First MRF in the SEND message, if mlen is nonzero. */
uint8_t target; /**< MRT target. */
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index ca15bc9..f72dbbe 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -45,7 +45,6 @@ vec4_instruction::vec4_instruction(vec4_visitor *v,
this->no_dd_check = false;
this->writes_accumulator = false;
this->conditional_mod = BRW_CONDITIONAL_NONE;
- this->sampler = 0;
this->texture_offset = 0;
this->target = 0;
this->shadow_compare = false;
@@ -2319,7 +2318,6 @@ vec4_visitor::emit_mcs_fetch(ir_texture *ir, src_reg
coordinate, uint32_t sample
vec4_instruction *inst = new(mem_ctx) vec4_instruction(this,
SHADER_OPCODE_TXF_MCS);
inst->base_mrf = 2;
inst->mlen = 1;
- inst->sampler = sampler;
inst->dst = dst_reg(th
[Mesa-dev] [PATCH 10/11] i965/vec4/Gen8: Use src1 for sampler_index instead of ->sampler field
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vec4.h | 3 ++-
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 19 +--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 24ad75c..9bfc9a0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -728,7 +728,8 @@ private:
struct brw_reg *src);
void generate_tex(vec4_instruction *inst,
- struct brw_reg dst);
+ struct brw_reg dst,
+ struct brw_reg sampler_index);
void generate_urb_write(vec4_instruction *ir, bool copy_g0);
void generate_gs_thread_end(vec4_instruction *ir);
diff --git a/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
index ee8e85e..6951f88 100644
--- a/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
@@ -50,7 +50,8 @@ gen8_vec4_generator::~gen8_vec4_generator()
}
void
-gen8_vec4_generator::generate_tex(vec4_instruction *ir, struct brw_reg dst)
+gen8_vec4_generator::generate_tex(vec4_instruction *ir, struct brw_reg dst,
+ struct brw_reg sampler_index)
{
int msg_type = 0;
@@ -100,6 +101,11 @@ gen8_vec4_generator::generate_tex(vec4_instruction *ir,
struct brw_reg dst)
unreachable("should not get here: invalid VS texture opcode");
}
+ assert(sampler_index.file == BRW_IMMEDIATE_VALUE);
+ assert(sampler_index.type == BRW_REGISTER_TYPE_UD);
+
+ uint32_t sampler = sampler_index.dw1.ud;
+
if (ir->header_present) {
MOV_RAW(retype(brw_message_reg(ir->base_mrf), BRW_REGISTER_TYPE_UD),
retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
@@ -113,7 +119,7 @@ gen8_vec4_generator::generate_tex(vec4_instruction *ir,
struct brw_reg dst)
brw_imm_ud(ir->texture_offset));
}
- if (ir->sampler >= 16) {
+ if (sampler >= 16) {
/* The "Sampler Index" field can only store values between 0 and 15.
* However, we can add an offset to the "Sampler State Pointer"
* field, effectively selecting a different set of 16 samplers.
@@ -126,7 +132,7 @@ gen8_vec4_generator::generate_tex(vec4_instruction *ir,
struct brw_reg dst)
gen8_instruction *add =
ADD(get_element_ud(brw_message_reg(ir->base_mrf), 3),
get_element_ud(brw_vec8_grf(0, 0), 3),
-brw_imm_ud(16 * (ir->sampler / 16) * sampler_state_size));
+brw_imm_ud(16 * (sampler / 16) * sampler_state_size));
gen8_set_mask_control(add, BRW_MASK_DISABLE);
}
@@ -134,14 +140,14 @@ gen8_vec4_generator::generate_tex(vec4_instruction *ir,
struct brw_reg dst)
}
uint32_t surf_index =
- prog_data->base.binding_table.texture_start + ir->sampler;
+ prog_data->base.binding_table.texture_start + sampler;
gen8_instruction *inst = next_inst(BRW_OPCODE_SEND);
gen8_set_dst(brw, inst, dst);
gen8_set_src0(brw, inst, brw_message_reg(ir->base_mrf));
gen8_set_sampler_message(brw, inst,
surf_index,
-ir->sampler % 16,
+sampler % 16,
msg_type,
1,
ir->mlen,
@@ -765,7 +771,8 @@
gen8_vec4_generator::generate_vec4_instruction(vec4_instruction *instruction,
case SHADER_OPCODE_TXS:
case SHADER_OPCODE_TG4:
case SHADER_OPCODE_TG4_OFFSET:
- generate_tex(ir, dst);
+ /* note: src[0] is unused. */
+ generate_tex(ir, dst, src[1]);
break;
case VS_OPCODE_URB_WRITE:
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/11] i965/vec4/Gen4-7: Use src1 for sampler_index instead of ->sampler field
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vec4.h | 5 +++--
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 18 --
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 08a2638..24ad75c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -645,8 +645,9 @@ private:
struct brw_reg src1);
void generate_tex(vec4_instruction *inst,
-struct brw_reg dst,
-struct brw_reg src);
+ struct brw_reg dst,
+ struct brw_reg src,
+ struct brw_reg sampler_index);
void generate_vs_urb_write(vec4_instruction *inst);
void generate_gs_urb_write(vec4_instruction *inst);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 87cc664..c760a1c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -225,7 +225,8 @@ vec4_generator::generate_math2_gen4(vec4_instruction *inst,
void
vec4_generator::generate_tex(vec4_instruction *inst,
struct brw_reg dst,
- struct brw_reg src)
+ struct brw_reg src,
+ struct brw_reg sampler_index)
{
int msg_type = -1;
@@ -313,6 +314,11 @@ vec4_generator::generate_tex(vec4_instruction *inst,
assert(msg_type != -1);
+ assert(sampler_index.file == BRW_IMMEDIATE_VALUE);
+ assert(sampler_index.type == BRW_REGISTER_TYPE_UD);
+
+ uint32_t sampler = sampler_index.dw1.ud;
+
/* Load the message header if present. If there's a texture offset, we need
* to set it up explicitly and load the offset bitfield. Otherwise, we can
* use an implied move from g0 to the first message register.
@@ -338,7 +344,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
brw_imm_ud(inst->texture_offset));
}
- if (inst->sampler >= 16) {
+ if (sampler >= 16) {
/* The "Sampler Index" field can only store values between 0 and
15.
* However, we can add an offset to the "Sampler State Pointer"
* field, effectively selecting a different set of 16 samplers.
@@ -352,7 +358,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
brw_ADD(p,
get_element_ud(header, 3),
get_element_ud(brw_vec8_grf(0, 0), 3),
-brw_imm_ud(16 * (inst->sampler / 16) *
sampler_state_size));
+brw_imm_ud(16 * (sampler / 16) * sampler_state_size));
}
brw_pop_insn_state(p);
}
@@ -375,14 +381,14 @@ vec4_generator::generate_tex(vec4_instruction *inst,
uint32_t surface_index = ((inst->opcode == SHADER_OPCODE_TG4 ||
inst->opcode == SHADER_OPCODE_TG4_OFFSET)
? prog_data->base.binding_table.gather_texture_start
- : prog_data->base.binding_table.texture_start) + inst->sampler;
+ : prog_data->base.binding_table.texture_start) + sampler;
brw_SAMPLE(p,
dst,
inst->base_mrf,
src,
surface_index,
- inst->sampler % 16,
+ sampler % 16,
msg_type,
1, /* response length */
inst->mlen,
@@ -1182,7 +1188,7 @@
vec4_generator::generate_vec4_instruction(vec4_instruction *instruction,
case SHADER_OPCODE_TXS:
case SHADER_OPCODE_TG4:
case SHADER_OPCODE_TG4_OFFSET:
- generate_tex(inst, dst, src[0]);
+ generate_tex(inst, dst, src[0], src[1]);
break;
case VS_OPCODE_URB_WRITE:
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] meta: Initialize the variable in declaration statement
On Wed, Jul 30, 2014 at 07:11:23PM -0700, Anuj Phogat wrote:
> Saves one line of code :)
>
> Signed-off-by: Anuj Phogat
> ---
> Realized today that I never really sent this series out to the list.
>
> src/mesa/drivers/common/meta.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index f1f5729..28bd065 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -2721,9 +2721,7 @@ _mesa_meta_blit_shader_table_cleanup(struct
> blit_shader_table *table)
> static GLenum
> get_temp_image_type(struct gl_context *ctx, mesa_format format)
> {
> - GLenum baseFormat;
> -
> - baseFormat = _mesa_get_format_base_format(format);
> + GLenum baseFormat = _mesa_get_format_base_format(format);
You could declare it constant while you're at it.
Reviewed-by: Topi Pohjolainen
>
> switch (baseFormat) {
> case GL_RGBA:
> --
> 1.9.3
>
> ___
> 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] [PATCH 2/5] meta: Use _mesa_get_format_bits() to get the GL_RED_BITS
On Wed, Jul 30, 2014 at 07:11:24PM -0700, Anuj Phogat wrote:
> We currently get red bits from ctx->DrawBuffer->Visual.redBits
> by making a false assumption that the texture we're writing to
> (in glCopyTexImage2D()) is used as a DrawBuffer.
>
> Fixes many failures in gles3 Khronos CTS test:
> copy_tex_image_conversions_required
>
> Cc:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/common/meta.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index 28bd065..ba84eb8 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -2722,6 +2722,7 @@ static GLenum
> get_temp_image_type(struct gl_context *ctx, mesa_format format)
> {
> GLenum baseFormat = _mesa_get_format_base_format(format);
> + GLint format_red_bits = _mesa_get_format_bits(format, GL_RED_BITS);
Now the results depend only on the given format and not on the current state.
Even though there are things I don't know about meta and gl-state, this makes
perfect sense to me.
You declare it constant as well.
Reviewed-by: Topi Pohjolainen
>
> switch (baseFormat) {
> case GL_RGBA:
> @@ -2732,9 +2733,9 @@ get_temp_image_type(struct gl_context *ctx, mesa_format
> format)
> case GL_LUMINANCE:
> case GL_LUMINANCE_ALPHA:
> case GL_INTENSITY:
> - if (ctx->DrawBuffer->Visual.redBits <= 8) {
> + if (format_red_bits <= 8) {
> return GL_UNSIGNED_BYTE;
> - } else if (ctx->DrawBuffer->Visual.redBits <= 16) {
> + } else if (format_red_bits <= 16) {
> return GL_UNSIGNED_SHORT;
>} else {
> GLenum datatype = _mesa_get_format_datatype(format);
> --
> 1.9.3
>
> ___
> 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] [PATCH] glsl: fix switch statement default case regressions
Reviewed-by: Chris Forbes
On Fri, Jul 25, 2014 at 6:40 PM, Tapani Pälli wrote:
> This patch fixes regressions caused by commit 48deb4d. Regressions
> happened because 'run_default' var did not initialized when default
> case was the last one.
>
> Now all the switch tests in es3conform suite are passing.
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/ast_to_hir.cpp | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index a15ee9c..7249a06 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -4597,12 +4597,6 @@ ast_case_statement_list::hir(exec_list *instructions,
> */
> if (!default_case.is_empty()) {
>
> - /* Default case was the last one, no checks required. */
> - if (after_default.is_empty()) {
> - instructions->append_list(&default_case);
> - return NULL;
> - }
> -
>ir_rvalue *const true_val = new (state) ir_constant(true);
>ir_dereference_variable *deref_run_default_var =
> new(state) ir_dereference_variable(state->switch_state.run_default);
> @@ -4614,6 +4608,12 @@ ast_case_statement_list::hir(exec_list *instructions,
> new(state) ir_assignment(deref_run_default_var, true_val);
>instructions->push_tail(init_var);
>
> + /* Default case was the last one, no checks required. */
> + if (after_default.is_empty()) {
> + instructions->append_list(&default_case);
> + return NULL;
> + }
> +
>foreach_in_list(ir_instruction, ir, &after_default) {
> ir_assignment *assign = ir->as_assignment();
>
> --
> 1.8.3.1
>
> ___
> 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] [PATCH 2/5] meta: Use _mesa_get_format_bits() to get the GL_RED_BITS
On Mon, Aug 04, 2014 at 12:11:53PM +0300, Pohjolainen, Topi wrote:
> On Wed, Jul 30, 2014 at 07:11:24PM -0700, Anuj Phogat wrote:
> > We currently get red bits from ctx->DrawBuffer->Visual.redBits
> > by making a false assumption that the texture we're writing to
> > (in glCopyTexImage2D()) is used as a DrawBuffer.
> >
> > Fixes many failures in gles3 Khronos CTS test:
> > copy_tex_image_conversions_required
> >
> > Cc:
> > Signed-off-by: Anuj Phogat
> > ---
> > src/mesa/drivers/common/meta.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> > index 28bd065..ba84eb8 100644
> > --- a/src/mesa/drivers/common/meta.c
> > +++ b/src/mesa/drivers/common/meta.c
> > @@ -2722,6 +2722,7 @@ static GLenum
> > get_temp_image_type(struct gl_context *ctx, mesa_format format)
> > {
> > GLenum baseFormat = _mesa_get_format_base_format(format);
> > + GLint format_red_bits = _mesa_get_format_bits(format, GL_RED_BITS);
>
> Now the results depend only on the given format and not on the current state.
> Even though there are things I don't know about meta and gl-state, this makes
> perfect sense to me.
> You declare it constant as well.
s/You declare/You could declare/
>
> Reviewed-by: Topi Pohjolainen
>
> >
> > switch (baseFormat) {
> > case GL_RGBA:
> > @@ -2732,9 +2733,9 @@ get_temp_image_type(struct gl_context *ctx,
> > mesa_format format)
> > case GL_LUMINANCE:
> > case GL_LUMINANCE_ALPHA:
> > case GL_INTENSITY:
> > - if (ctx->DrawBuffer->Visual.redBits <= 8) {
> > + if (format_red_bits <= 8) {
> > return GL_UNSIGNED_BYTE;
> > - } else if (ctx->DrawBuffer->Visual.redBits <= 16) {
> > + } else if (format_red_bits <= 16) {
> > return GL_UNSIGNED_SHORT;
> >} else {
> > GLenum datatype = _mesa_get_format_datatype(format);
> > --
> > 1.9.3
> >
> > ___
> > 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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] meta: Move the call to _mesa_get_format_datatype() out of switch
On Wed, Jul 30, 2014 at 07:11:25PM -0700, Anuj Phogat wrote:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/common/meta.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index ba84eb8..e94 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -2722,6 +2722,7 @@ static GLenum
> get_temp_image_type(struct gl_context *ctx, mesa_format format)
> {
> GLenum baseFormat = _mesa_get_format_base_format(format);
> + GLenum datatype = _mesa_get_format_datatype(format);
Same here, could be constant.
Reviewed-by: Topi Pohjolainen
> GLint format_red_bits = _mesa_get_format_bits(format, GL_RED_BITS);
>
> switch (baseFormat) {
> @@ -2738,25 +2739,20 @@ get_temp_image_type(struct gl_context *ctx,
> mesa_format format)
>} else if (format_red_bits <= 16) {
> return GL_UNSIGNED_SHORT;
>} else {
> - GLenum datatype = _mesa_get_format_datatype(format);
> if (datatype == GL_INT || datatype == GL_UNSIGNED_INT)
> return datatype;
> return GL_FLOAT;
>}
> - case GL_DEPTH_COMPONENT: {
> - GLenum datatype = _mesa_get_format_datatype(format);
> + case GL_DEPTH_COMPONENT:
>if (datatype == GL_FLOAT)
> return GL_FLOAT;
>else
> return GL_UNSIGNED_INT;
> - }
> - case GL_DEPTH_STENCIL: {
> - GLenum datatype = _mesa_get_format_datatype(format);
> + case GL_DEPTH_STENCIL:
>if (datatype == GL_FLOAT)
> return GL_FLOAT_32_UNSIGNED_INT_24_8_REV;
>else
> return GL_UNSIGNED_INT_24_8;
> - }
> default:
>_mesa_problem(ctx, "Unexpected format %d in get_temp_image_type()",
> baseFormat);
> --
> 1.9.3
>
> ___
> 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] [PATCH 4/5] meta: Fix datatype computation in get_temp_image_type()
On Wed, Jul 30, 2014 at 07:11:26PM -0700, Anuj Phogat wrote:
> Changes in the patch will cause datatype to be computed
> correctly for 8 and 16 bit integer formats. For example:
> GL_RG8I, GL_RG16I etc.
>
> Fixes many failures in gles3 Khronos CTS test:
> copy_tex_image_conversions_required
> copy_tex_image_conversions_forbidden
Is this a regression caused by the patch number two or already broken? If
the former than we should merge them. Otherwise:
Reviewed-by: Topi Pohjolainen
>
> Cc:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/common/meta.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index e94..fdac546 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -2734,15 +2734,14 @@ get_temp_image_type(struct gl_context *ctx,
> mesa_format format)
> case GL_LUMINANCE:
> case GL_LUMINANCE_ALPHA:
> case GL_INTENSITY:
> - if (format_red_bits <= 8) {
> + if (datatype == GL_INT || datatype == GL_UNSIGNED_INT) {
> + return datatype;
> + } else if (format_red_bits <= 8) {
> return GL_UNSIGNED_BYTE;
>} else if (format_red_bits <= 16) {
> return GL_UNSIGNED_SHORT;
> - } else {
> - if (datatype == GL_INT || datatype == GL_UNSIGNED_INT)
> -return datatype;
> - return GL_FLOAT;
>}
> + return GL_FLOAT;
> case GL_DEPTH_COMPONENT:
>if (datatype == GL_FLOAT)
> return GL_FLOAT;
> --
> 1.9.3
>
> ___
> 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 v4] winsys/radeon: fix nop packet padding for hawaii
The initial firmware for hawaii does not support type3 nop packet.
Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
If the returned value is 3, then the new firmware is used.
This patch uses type2 for the old firmware and type3 for the new firmware.
It fixes the cases when the old firmware is used and the user wants to
manually enable acceleration.
The two possible scenarios are:
- the kernel has no support for the new firmware.
- the kernel has support for the new firmware but only the old firmware
is available.
Additionaly this patch disables GPU acceleration on hawaii if the kernel
returns a value < 2. In this case the kernel hasn't the required fixes
for proper acceleration.
v2:
- Fix indentation
- Use private struct radeon_drm_winsys instead of public struct radeon_info
- Rename r600_accel_working2 to accel_working2
v3:
- Use type2 nop packet for returned value < 3
v4:
- Fail to initialize winsys for returned value < 2
Cc: mesa-sta...@lists.freedesktop.org
Cc: Alex Deucher
Cc: Jérôme Glisse
Cc: Marek Olšák
Cc: Michel Dänzer
Signed-off-by: Andreas Boll
---
Unfortunately I can't test this patch myself since I don't own a hawaii card.
So I'd need someone to test this patch on kernel >= 3.16-rc7 + these patches
[1-2].
This patch would bring us one step further for hawaii acceleration on kernel
3.16.
Finally we can enable hawaii acceleration if the query returns > 2 [3].
Andreas.
[1] http://lists.freedesktop.org/archives/dri-devel/2014-August/065305.html
[2] http://lists.freedesktop.org/archives/dri-devel/2014-August/065306.html
[3] http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 6 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 10 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index a06ecb2..dd109af 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -446,8 +446,12 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
*rcs,
case RING_GFX:
/* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
* r6xx, requires at least 4 dw alignment to avoid a hw bug.
+ * hawaii with old firmware needs type2 nop packet.
+ * accel_working2 with value 2 indicates the new firmware.
*/
-if (cs->ws->info.chip_class <= SI) {
+if (cs->ws->info.chip_class <= SI ||
+(cs->ws->info.family == CHIP_HAWAII &&
+ cs->ws->accel_working2 < 3)) {
while (rcs->cdw & 7)
OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
} else {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 910d06b..ecff0e7 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -395,6 +395,16 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_SH_PER_SE, NULL,
&ws->info.max_sh_per_se);
+radeon_get_drm_value(ws->fd, RADEON_INFO_ACCEL_WORKING2, NULL,
+ &ws->accel_working2);
+if (ws->info.family == CHIP_HAWAII && ws->accel_working2 < 2) {
+fprintf(stderr, "radeon: GPU acceleration for Hawaii disabled, "
+"returned accel_working2 value %u is smaller than 2. "
+"Please install a newer kernel.\n",
+ws->accel_working2);
+return FALSE;
+}
+
if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, NULL,
ws->info.si_tile_mode_array)) {
ws->info.si_tile_mode_array_valid = TRUE;
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
index ea6f7f0..aebc391 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
@@ -55,6 +55,7 @@ struct radeon_drm_winsys {
enum radeon_generation gen;
struct radeon_info info;
uint32_t va_start;
+uint32_t accel_working2;
struct pb_manager *kman;
struct pb_manager *cman_vram;
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] mesa/meta: Add a partial implementation of CopyImageSubData
Jason Ekstrand writes: > Done. Other than that, does this count as a R-B? Yeah, with the cleanup step it looks good to me. Reviewed-by: Neil Roberts Regards, - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4] winsys/radeon: fix nop packet padding for hawaii
Am 04.08.2014 um 12:48 schrieb Andreas Boll:
The initial firmware for hawaii does not support type3 nop packet.
Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
If the returned value is 3, then the new firmware is used.
This patch uses type2 for the old firmware and type3 for the new firmware.
AFAIK the type2 nop packet is deprecated because it was found to not
work correctly in some situations. The hack with the type3 nop packet
and the strange size field was added to work around this.
I won't advise using any stack that still uses the old nop packet and
firmware, that might not be very not reliable. So we should print at
least a big warning if that's the case.
Regards,
Christian.
It fixes the cases when the old firmware is used and the user wants to
manually enable acceleration.
The two possible scenarios are:
- the kernel has no support for the new firmware.
- the kernel has support for the new firmware but only the old firmware
is available.
Additionaly this patch disables GPU acceleration on hawaii if the kernel
returns a value < 2. In this case the kernel hasn't the required fixes
for proper acceleration.
v2:
- Fix indentation
- Use private struct radeon_drm_winsys instead of public struct radeon_info
- Rename r600_accel_working2 to accel_working2
v3:
- Use type2 nop packet for returned value < 3
v4:
- Fail to initialize winsys for returned value < 2
Cc: mesa-sta...@lists.freedesktop.org
Cc: Alex Deucher
Cc: Jérôme Glisse
Cc: Marek Olšák
Cc: Michel Dänzer
Signed-off-by: Andreas Boll
---
Unfortunately I can't test this patch myself since I don't own a hawaii card.
So I'd need someone to test this patch on kernel >= 3.16-rc7 + these patches
[1-2].
This patch would bring us one step further for hawaii acceleration on kernel
3.16.
Finally we can enable hawaii acceleration if the query returns > 2 [3].
Andreas.
[1] http://lists.freedesktop.org/archives/dri-devel/2014-August/065305.html
[2] http://lists.freedesktop.org/archives/dri-devel/2014-August/065306.html
[3] http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 6 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 10 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index a06ecb2..dd109af 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -446,8 +446,12 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
*rcs,
case RING_GFX:
/* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
* r6xx, requires at least 4 dw alignment to avoid a hw bug.
+ * hawaii with old firmware needs type2 nop packet.
+ * accel_working2 with value 2 indicates the new firmware.
*/
-if (cs->ws->info.chip_class <= SI) {
+if (cs->ws->info.chip_class <= SI ||
+(cs->ws->info.family == CHIP_HAWAII &&
+ cs->ws->accel_working2 < 3)) {
while (rcs->cdw & 7)
OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
} else {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 910d06b..ecff0e7 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -395,6 +395,16 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_SH_PER_SE, NULL,
&ws->info.max_sh_per_se);
+radeon_get_drm_value(ws->fd, RADEON_INFO_ACCEL_WORKING2, NULL,
+ &ws->accel_working2);
+if (ws->info.family == CHIP_HAWAII && ws->accel_working2 < 2) {
+fprintf(stderr, "radeon: GPU acceleration for Hawaii disabled, "
+"returned accel_working2 value %u is smaller than 2. "
+"Please install a newer kernel.\n",
+ws->accel_working2);
+return FALSE;
+}
+
if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, NULL,
ws->info.si_tile_mode_array)) {
ws->info.si_tile_mode_array_valid = TRUE;
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
index ea6f7f0..aebc391 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
@@ -55,6 +55,7 @@ struct radeon_drm_winsys {
enum radeon_generation gen;
struct radeon_info info;
uint32_t va_start;
+uint32_t accel_working2;
struct pb_manager *kman;
struct pb_manager *cman_vram;
___
mesa-dev mai
Re: [Mesa-dev] [PATCH v4] winsys/radeon: fix nop packet padding for hawaii
Am 04.08.2014 um 12:48 schrieb Andreas Boll:
The initial firmware for hawaii does not support type3 nop packet.
Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
If the returned value is 3, then the new firmware is used.
This patch uses type2 for the old firmware and type3 for the new firmware.
AFAIK the type2 nop packet is deprecated because it was found to not
work correctly in some situations. The hack with the type3 nop packet
and the strange size field was added to work around this.
I won't advise using any stack that still uses the old nop packet and
firmware, that might not be very not reliable. So we should print at
least a big warning if that's the case.
Regards,
Christian.
It fixes the cases when the old firmware is used and the user wants to
manually enable acceleration.
The two possible scenarios are:
- the kernel has no support for the new firmware.
- the kernel has support for the new firmware but only the old firmware
is available.
Additionaly this patch disables GPU acceleration on hawaii if the kernel
returns a value < 2. In this case the kernel hasn't the required fixes
for proper acceleration.
v2:
- Fix indentation
- Use private struct radeon_drm_winsys instead of public struct radeon_info
- Rename r600_accel_working2 to accel_working2
v3:
- Use type2 nop packet for returned value < 3
v4:
- Fail to initialize winsys for returned value < 2
Cc: mesa-sta...@lists.freedesktop.org
Cc: Alex Deucher
Cc: Jérôme Glisse
Cc: Marek Olšák
Cc: Michel Dänzer
Signed-off-by: Andreas Boll
---
Unfortunately I can't test this patch myself since I don't own a hawaii card.
So I'd need someone to test this patch on kernel >= 3.16-rc7 + these patches
[1-2].
This patch would bring us one step further for hawaii acceleration on kernel
3.16.
Finally we can enable hawaii acceleration if the query returns > 2 [3].
Andreas.
[1] http://lists.freedesktop.org/archives/dri-devel/2014-August/065305.html
[2] http://lists.freedesktop.org/archives/dri-devel/2014-August/065306.html
[3] http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 6 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 10 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index a06ecb2..dd109af 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -446,8 +446,12 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
*rcs,
case RING_GFX:
/* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
* r6xx, requires at least 4 dw alignment to avoid a hw bug.
+ * hawaii with old firmware needs type2 nop packet.
+ * accel_working2 with value 2 indicates the new firmware.
*/
-if (cs->ws->info.chip_class <= SI) {
+if (cs->ws->info.chip_class <= SI ||
+(cs->ws->info.family == CHIP_HAWAII &&
+ cs->ws->accel_working2 < 3)) {
while (rcs->cdw & 7)
OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
} else {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 910d06b..ecff0e7 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -395,6 +395,16 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_SH_PER_SE, NULL,
&ws->info.max_sh_per_se);
+radeon_get_drm_value(ws->fd, RADEON_INFO_ACCEL_WORKING2, NULL,
+ &ws->accel_working2);
+if (ws->info.family == CHIP_HAWAII && ws->accel_working2 < 2) {
+fprintf(stderr, "radeon: GPU acceleration for Hawaii disabled, "
+"returned accel_working2 value %u is smaller than 2. "
+"Please install a newer kernel.\n",
+ws->accel_working2);
+return FALSE;
+}
+
if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, NULL,
ws->info.si_tile_mode_array)) {
ws->info.si_tile_mode_array_valid = TRUE;
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
index ea6f7f0..aebc391 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
@@ -55,6 +55,7 @@ struct radeon_drm_winsys {
enum radeon_generation gen;
struct radeon_info info;
uint32_t va_start;
+uint32_t accel_working2;
struct pb_manager *kman;
struct pb_manager *cman_vram;
___
mesa-dev mai
Re: [Mesa-dev] [PATCH 02/20] i965: Add and use foreach_block macro.
On Thu, Jul 24, 2014 at 07:54:09PM -0700, Matt Turner wrote:
> Use this as an opportunity to rename 'block_num' to 'num'. block->num is
> clear, and block->block_num has always been redundant.
> ---
> src/mesa/drivers/dri/i965/brw_cfg.cpp | 17 ++---
> src/mesa/drivers/dri/i965/brw_cfg.h| 5 +-
> .../drivers/dri/i965/brw_dead_control_flow.cpp | 3 +-
> .../drivers/dri/i965/brw_fs_copy_propagation.cpp | 89
> ++
> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 4 +-
> .../dri/i965/brw_fs_dead_code_eliminate.cpp| 5 +-
> .../drivers/dri/i965/brw_fs_live_variables.cpp | 50 ++--
> .../dri/i965/brw_fs_peephole_predicated_break.cpp | 9 +--
> .../dri/i965/brw_fs_saturate_propagation.cpp | 5 +-
> src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 4 +-
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 +-
> src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 4 +-
> .../drivers/dri/i965/brw_vec4_live_variables.cpp | 50 ++--
> src/mesa/drivers/dri/i965/intel_asm_annotation.c | 8 +-
> 14 files changed, 116 insertions(+), 143 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
> b/src/mesa/drivers/dri/i965/brw_cfg.cpp
> index 4a5c912..d806b83 100644
> --- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
> @@ -51,7 +51,7 @@ link(void *mem_ctx, bblock_t *block)
> }
>
> bblock_t::bblock_t() :
> - start_ip(0), end_ip(0), block_num(0)
> + start_ip(0), end_ip(0), num(0)
> {
> start = NULL;
> end = NULL;
> @@ -284,7 +284,7 @@ cfg_t::set_next_block(bblock_t **cur, bblock_t *block,
> int ip)
> }
>
> block->start_ip = ip;
> - block->block_num = num_blocks++;
> + block->num = num_blocks++;
> block_list.push_tail(&block->link);
> *cur = block;
> }
> @@ -295,7 +295,7 @@ cfg_t::make_block_array()
> blocks = ralloc_array(mem_ctx, bblock_t *, num_blocks);
>
> int i = 0;
> - foreach_list_typed(bblock_t, block, link, &block_list) {
> + foreach_block (block, this) {
>blocks[i++] = block;
> }
> assert(i == num_blocks);
> @@ -304,19 +304,18 @@ cfg_t::make_block_array()
> void
> cfg_t::dump(backend_visitor *v)
> {
> - for (int b = 0; b < this->num_blocks; b++) {
> -bblock_t *block = this->blocks[b];
> - fprintf(stderr, "START B%d", b);
> + foreach_block (block, this) {
> + fprintf(stderr, "START B%d", block->num);
>foreach_list_typed(bblock_link, link, link, &block->parents) {
> fprintf(stderr, " <-B%d",
> - link->block->block_num);
> + link->block->num);
>}
>fprintf(stderr, "\n");
>block->dump(v);
> - fprintf(stderr, "END B%d", b);
> + fprintf(stderr, "END B%d", block->num);
>foreach_list_typed(bblock_link, link, link, &block->children) {
> fprintf(stderr, " ->B%d",
> - link->block->block_num);
> + link->block->num);
>}
>fprintf(stderr, "\n");
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
> b/src/mesa/drivers/dri/i965/brw_cfg.h
> index 324df6c..f7203e2 100644
> --- a/src/mesa/drivers/dri/i965/brw_cfg.h
> +++ b/src/mesa/drivers/dri/i965/brw_cfg.h
> @@ -71,7 +71,7 @@ struct bblock_t {
>
> struct exec_list parents;
> struct exec_list children;
> - int block_num;
> + int num;
>
> /* If the current basic block ends in an IF, ELSE, or ENDIF instruction,
> * these pointers will hold the locations of the other associated control
> @@ -109,6 +109,9 @@ struct cfg_t {
> foreach_block (__block, __cfg) \
>foreach_inst_in_block (__type, __inst, __block)
>
> +#define foreach_block(__block, __cfg) \
> + foreach_list_typed (bblock_t, __block, link, &(__cfg)->block_list)
> +
> #define foreach_inst_in_block(__type, __inst, __block) \
> for (__type *__inst = (__type *)__block->start; \
> __inst != __block->end->next; \
> diff --git a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
> b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
> index f0530a1..e6ace5c 100644
> --- a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
> @@ -42,8 +42,7 @@ dead_control_flow_eliminate(backend_visitor *v)
>
> v->calculate_cfg();
>
> - for (int b = 0; b < v->cfg->num_blocks; b++) {
> - bblock_t *block = v->cfg->blocks[b];
> + foreach_block (block, v->cfg) {
>bool found = false;
>
>/* ENDIF instructions, by definition, can only be found at the start of
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> index 0716202..587e231 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> +++ b/src/mesa/dr
Re: [Mesa-dev] [PATCH 01/20] i965/cfg: Embed link in bblock_t for main block list.
On Thu, Jul 24, 2014 at 07:54:08PM -0700, Matt Turner wrote:
> The next patch adds a foreach_block (block, cfg) macro, which works
> better if it provides a direct bblock_t pointer, rather than a
> bblock_link pointer that you have to use to find the actual block.
> ---
> src/mesa/drivers/dri/i965/brw_cfg.cpp | 10 +-
> src/mesa/drivers/dri/i965/brw_cfg.h | 2 ++
> 2 files changed, 7 insertions(+), 5 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
> b/src/mesa/drivers/dri/i965/brw_cfg.cpp
> index 07111f5..4a5c912 100644
> --- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
> @@ -67,8 +67,8 @@ bblock_t::bblock_t() :
> void
> bblock_t::add_successor(void *mem_ctx, bblock_t *successor)
> {
> - successor->parents.push_tail(link(mem_ctx, this));
> - children.push_tail(link(mem_ctx, successor));
> + successor->parents.push_tail(::link(mem_ctx, this));
> + children.push_tail(::link(mem_ctx, successor));
> }
>
> void
> @@ -285,7 +285,7 @@ cfg_t::set_next_block(bblock_t **cur, bblock_t *block,
> int ip)
>
> block->start_ip = ip;
> block->block_num = num_blocks++;
> - block_list.push_tail(link(mem_ctx, block));
> + block_list.push_tail(&block->link);
> *cur = block;
> }
>
> @@ -295,8 +295,8 @@ cfg_t::make_block_array()
> blocks = ralloc_array(mem_ctx, bblock_t *, num_blocks);
>
> int i = 0;
> - foreach_list_typed(bblock_link, link, link, &block_list) {
> - blocks[i++] = link->block;
> + foreach_list_typed(bblock_t, block, link, &block_list) {
> + blocks[i++] = block;
> }
> assert(i == num_blocks);
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
> b/src/mesa/drivers/dri/i965/brw_cfg.h
> index 01fcc1b..324df6c 100644
> --- a/src/mesa/drivers/dri/i965/brw_cfg.h
> +++ b/src/mesa/drivers/dri/i965/brw_cfg.h
> @@ -61,6 +61,8 @@ struct bblock_t {
> void dump(backend_visitor *v);
> #endif
>
> + struct exec_node link;
> +
> struct backend_instruction *start;
> struct backend_instruction *end;
>
> --
> 1.8.5.5
>
> ___
> 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 0/2] clover: add clCompileProgram
Hello I'm done with the clCompile part of OpenCL 1.2. As you can see I use char* data to transfert data from core to llvm. At first I was thinking of using std class but we need to be binary safe when data are transfert beetween c++98/c++11 compiled code. Then I try to use compat class, but it add unexpected behavior. It's looks like they are acting like std, but they don't. For exemple vector.reserve is actually making the vector size grown, not like std::vector. Also std::string.c_str is always null terminated. compat::string is not. At the end I decide to use const char* as it also avoid some memory copy, but I can rewrite the patch if it's needed. And I think compat need to be fixed. EdB (2): clover: std::pair is not c++98/c++11 safe clover: add clCompileProgram src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +- src/gallium/state_trackers/clover/api/program.cpp | 41 -- .../state_trackers/clover/core/compiler.hpp| 11 +++--- src/gallium/state_trackers/clover/core/program.cpp | 14 ++-- src/gallium/state_trackers/clover/core/program.hpp | 5 ++- .../state_trackers/clover/llvm/invocation.cpp | 33 + src/gallium/state_trackers/clover/util/compat.hpp | 6 7 files changed, 95 insertions(+), 17 deletions(-) -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] clover: std::pair is not c++98/c++11 safe
add a simple compat::pair
---
src/gallium/state_trackers/clover/util/compat.hpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/clover/util/compat.hpp
b/src/gallium/state_trackers/clover/util/compat.hpp
index 50e1c7d..c5d1b39 100644
--- a/src/gallium/state_trackers/clover/util/compat.hpp
+++ b/src/gallium/state_trackers/clover/util/compat.hpp
@@ -295,6 +295,12 @@ namespace clover {
}
};
+ template
+ struct pair {
+ T1 first;
+ T2 second;
+ };
+
template
bool
operator==(const vector_ref &a, const vector_ref &b) {
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] clover: add clCompileProgram
---
src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
src/gallium/state_trackers/clover/api/program.cpp | 41 --
.../state_trackers/clover/core/compiler.hpp| 11 +++---
src/gallium/state_trackers/clover/core/program.cpp | 14 ++--
src/gallium/state_trackers/clover/core/program.hpp | 5 ++-
.../state_trackers/clover/llvm/invocation.cpp | 33 +
6 files changed, 89 insertions(+), 17 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 35d150d..b5a4094 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -122,7 +122,7 @@ namespace clover {
clReleaseDevice,
clCreateImage,
clCreateProgramWithBuiltInKernels,
- NULL, // clCompileProgram
+ clCompileProgram,
NULL, // clLinkProgram
clUnloadPlatformCompiler,
NULL, // clGetKernelArgInfo
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index b81ce69..b0a906e 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -153,13 +153,35 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
const cl_device_id *d_devs, const char *p_opts,
void (*pfn_notify)(cl_program, void *),
void *user_data) try {
+ return clCompileProgram(d_prog, num_devs, d_devs, p_opts,
+ 0, 0, 0,
+ pfn_notify, user_data);
+
+} catch (error &e) {
+ return e.get();
+}
+
+CLOVER_API cl_int
+clCompileProgram(cl_program d_prog, cl_uint num_devs,
+ const cl_device_id *d_devs, const char *p_opts,
+ cl_uint num_headers, const cl_program *d_header_progs,
+ const char **header_names,
+ void (*pfn_notify)(cl_program, void *),
+ void *user_data) try {
+
auto &prog = obj(d_prog);
auto devs = (d_devs ? objs(d_devs, num_devs) :
ref_vector(prog.context().devices()));
auto opts = (p_opts ? p_opts : "");
- if (bool(num_devs) != bool(d_devs) ||
- (!pfn_notify && user_data))
+ if (bool(num_devs) != bool(d_devs))
+ throw error(CL_INVALID_VALUE);
+
+ if (!pfn_notify && user_data)
+ throw error(CL_INVALID_VALUE);
+
+ if (bool(num_headers) != bool(header_names) ||
+ bool(num_headers) != bool(d_header_progs))
throw error(CL_INVALID_VALUE);
if (any_of([&](const device &dev) {
@@ -167,7 +189,20 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
}, devs))
throw error(CL_INVALID_DEVICE);
- prog.build(devs, opts);
+ std::map headers;
+ for (unsigned int i = 0; i < num_headers; ++i) {
+ auto h_name = std::string(header_names[i]);
+ auto &h_prog = obj(d_header_progs[i]);
+
+ // The specs is unclear on what to do in that case,
+ // however it says that headers have to be with sources
+ if (!h_prog.has_source)
+ throw error(CL_INVALID_OPERATION);
+
+ headers.insert(make_pair(h_name, h_prog.source()));
+ }
+
+ prog.build(devs, opts, headers);
return CL_SUCCESS;
} catch (error &e) {
diff --git a/src/gallium/state_trackers/clover/core/compiler.hpp
b/src/gallium/state_trackers/clover/core/compiler.hpp
index 6ef84d1..3b1d9fc 100644
--- a/src/gallium/state_trackers/clover/core/compiler.hpp
+++ b/src/gallium/state_trackers/clover/core/compiler.hpp
@@ -23,6 +23,8 @@
#ifndef CLOVER_CORE_COMPILER_HPP
#define CLOVER_CORE_COMPILER_HPP
+#include
+
#include "util/compat.hpp"
#include "core/error.hpp"
#include "core/module.hpp"
@@ -30,10 +32,11 @@
namespace clover {
module compile_program_llvm(const compat::string &source,
- pipe_shader_ir ir,
- const compat::string &target,
- const compat::string &opts,
- compat::string &r_log);
+ const compat::vector> &headers,
+ pipe_shader_ir ir,
+ const compat::string &target,
+ const compat::string &opts,
+ compat::string &r_log);
module compile_program_tgsi(const compat::string &source);
}
diff --git a/src/gallium/state_trackers/clover/core/program.cpp
b/src/gallium/state_trackers/clover/core/program.cpp
index e09c3aa..b0a0a25 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -41,7 +41,8 @@ program::program(clover::context &ctx,
}
void
-program::build(const ref_vector &devs, const char *opts) {
+program::build(const ref_vector &devs, const char *opts,
+ const string_map &headers) {
if (has_source) {
_devices = devs;
@@ -54,10 +55,19 @@ program::build(c
Re: [Mesa-dev] [PATCH 1/3] llvmpipe: implement support for cube map arrays
On 08/01/2014 08:12 PM, srol...@vmware.com wrote: From: Roland Scheidegger This just covers the resource side of things, not the actual sampling. Here things are trivial as cube map arrays are identical to 2d arrays in all respects. --- src/gallium/drivers/llvmpipe/lp_screen.c| 3 ++- src/gallium/drivers/llvmpipe/lp_setup.c | 6 +- src/gallium/drivers/llvmpipe/lp_state_sampler.c | 6 +- src/gallium/drivers/llvmpipe/lp_texture.c | 3 ++- src/gallium/drivers/llvmpipe/lp_texture.h | 2 ++ 5 files changed, 16 insertions(+), 4 deletions(-) The series LGTM. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri/xmlconfig: s/uint/unsigned int/
On 08/03/2014 02:03 PM, Vinson Lee wrote:
This patch fixes this build error on Mac OS X.
./xmlconfig.h:61:5: error: unknown type name 'uint'; did you mean 'int'?
uint nRanges; /**< \brief Number of ranges */
^~~~
int
./xmlconfig.h:79:5: error: unknown type name 'uint'; did you mean 'int'?
uint tableSize;
^~~~
int
Signed-off-by: Vinson Lee
---
src/mesa/drivers/dri/common/xmlconfig.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.h
b/src/mesa/drivers/dri/common/xmlconfig.h
index af03234..8969843 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.h
+++ b/src/mesa/drivers/dri/common/xmlconfig.h
@@ -58,7 +58,7 @@ typedef struct driOptionInfo {
char *name; /**< \brief Name */
driOptionType type; /**< \brief Type */
driOptionRange *ranges; /**< \brief Array of ranges */
-uint nRanges; /**< \brief Number of ranges */
+unsigned int nRanges; /**< \brief Number of ranges */
} driOptionInfo;
/** \brief Option cache
@@ -76,7 +76,7 @@ typedef struct driOptionCache {
* \li Default values in screen
* \li Actual values in contexts
*/
-uint tableSize;
+unsigned int tableSize;
/**< \brief Size of the arrays
*
* In the current implementation it's not actually a size but log2(size).
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4] winsys/radeon: fix nop packet padding for hawaii
2014-08-04 13:40 GMT+02:00 Christian König :
> Am 04.08.2014 um 12:48 schrieb Andreas Boll:
>>
>> The initial firmware for hawaii does not support type3 nop packet.
>>
>> Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
>> If the returned value is 3, then the new firmware is used.
>>
>> This patch uses type2 for the old firmware and type3 for the new firmware.
>
>
> AFAIK the type2 nop packet is deprecated because it was found to not work
> correctly in some situations. The hack with the type3 nop packet and the
> strange size field was added to work around this.
>
> I won't advise using any stack that still uses the old nop packet and
> firmware, that might not be very not reliable. So we should print at least a
> big warning if that's the case.
>
> Regards,
> Christian.
>
Would a warning in Xorg log be sufficient or do you want an error message in
the winsys init code?
Andreas.
>>
>> It fixes the cases when the old firmware is used and the user wants to
>> manually enable acceleration.
>> The two possible scenarios are:
>> - the kernel has no support for the new firmware.
>> - the kernel has support for the new firmware but only the old firmware
>> is available.
>>
>> Additionaly this patch disables GPU acceleration on hawaii if the kernel
>> returns a value < 2. In this case the kernel hasn't the required fixes
>> for proper acceleration.
>>
>> v2:
>> - Fix indentation
>> - Use private struct radeon_drm_winsys instead of public struct
>> radeon_info
>> - Rename r600_accel_working2 to accel_working2
>>
>> v3:
>> - Use type2 nop packet for returned value < 3
>>
>> v4:
>> - Fail to initialize winsys for returned value < 2
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>> Cc: Alex Deucher
>> Cc: Jérôme Glisse
>> Cc: Marek Olšák
>> Cc: Michel Dänzer
>> Signed-off-by: Andreas Boll
>> ---
>>
>> Unfortunately I can't test this patch myself since I don't own a hawaii
>> card.
>> So I'd need someone to test this patch on kernel >= 3.16-rc7 + these
>> patches
>> [1-2].
>>
>> This patch would bring us one step further for hawaii acceleration on
>> kernel
>> 3.16.
>>
>> Finally we can enable hawaii acceleration if the query returns > 2 [3].
>>
>> Andreas.
>>
>> [1]
>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065305.html
>> [2]
>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065306.html
>> [3] http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html
>>
>> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 6 +-
>> src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 10 ++
>> src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 1 +
>> 3 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> index a06ecb2..dd109af 100644
>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> @@ -446,8 +446,12 @@ static void radeon_drm_cs_flush(struct
>> radeon_winsys_cs *rcs,
>> case RING_GFX:
>> /* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
>>* r6xx, requires at least 4 dw alignment to avoid a hw bug.
>> + * hawaii with old firmware needs type2 nop packet.
>> + * accel_working2 with value 2 indicates the new firmware.
>>*/
>> -if (cs->ws->info.chip_class <= SI) {
>> +if (cs->ws->info.chip_class <= SI ||
>> +(cs->ws->info.family == CHIP_HAWAII &&
>> + cs->ws->accel_working2 < 3)) {
>> while (rcs->cdw & 7)
>> OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
>> } else {
>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>> index 910d06b..ecff0e7 100644
>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>> @@ -395,6 +395,16 @@ static boolean do_winsys_init(struct
>> radeon_drm_winsys *ws)
>> radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_SH_PER_SE, NULL,
>>&ws->info.max_sh_per_se);
>> +radeon_get_drm_value(ws->fd, RADEON_INFO_ACCEL_WORKING2, NULL,
>> + &ws->accel_working2);
>> +if (ws->info.family == CHIP_HAWAII && ws->accel_working2 < 2) {
>> +fprintf(stderr, "radeon: GPU acceleration for Hawaii disabled, "
>> +"returned accel_working2 value %u is smaller than 2. "
>> +"Please install a newer kernel.\n",
>> +ws->accel_working2);
>> +return FALSE;
>> +}
>> +
>> if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY,
>> NULL,
>>ws->info.si_tile_mode_array)) {
>> ws->info.si_tile_mode_array_valid = TRUE;
>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
>> b/src/gallium/w
Re: [Mesa-dev] [PATCH v2 09/13] mesa/format_utils: Add a function to convert a mesa_format to an array format
On 08/02/2014 02:11 PM, Jason Ekstrand wrote:
This commits adds the _mesa_format_to_arary function that determines if the
"array"
given format can be represented as an array format and computes the array
format parameters. This is a direct helper function for using
_mesa_swizzle_and_convert
v2: Better documentation and commit message
Signed-off-by: Jason Ekstrand
---
src/mesa/main/format_utils.c | 105 +++
src/mesa/main/format_utils.h | 4 ++
2 files changed, 109 insertions(+)
diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c
index d60aeb3..95b4612 100644
--- a/src/mesa/main/format_utils.c
+++ b/src/mesa/main/format_utils.c
@@ -55,6 +55,111 @@ _mesa_srgb_ubyte_to_linear_float(uint8_t cl)
return lut[cl];
}
+static const uint8_t map_identity[7] = { 0, 1, 2, 3, 4, 5, 6 };
+static const uint8_t map_3210[7] = { 3, 2, 1, 0, 4, 5, 6 };
+static const uint8_t map_1032[7] = { 1, 0, 3, 2, 4, 5, 6 };
+
+/**
+ * Describes a format as an array format, if possible
+ *
+ * A helper function for figuring out if a (possibly packed) format is
+ * actually an array format and, if so, what the array parameters are.
+ *
+ * \param[in] format the mesa format
+ * \param[out] type the GL type of the array (GL_BYTE, etc.)
+ * \param[out] num_components the number of components in the array
+ * \param[out] swizzlea swizzle describing how to get from the
+ *given format to RGBA
+ * \param[out] normalized for integer formats, this represents whether
+ *the format is a normalized integer or a
+ *regular integer
+ * \return true if this format is an array format, false otherwise
+ */
+bool
+_mesa_format_to_array(mesa_format format, GLenum *type, int *num_components,
+ uint8_t swizzle[4], bool *normalized)
+{
+ int i;
+ GLuint format_components;
+ uint8_t packed_swizzle[4];
+ const uint8_t *endian;
+
+ if (_mesa_is_format_compressed(format))
+ return false;
+
+ *normalized = !_mesa_is_format_integer(format);
+
+ _mesa_format_to_type_and_comps(format, type, &format_components);
+
+ switch (_mesa_get_format_layout(format)) {
+ case MESA_FORMAT_LAYOUT_ARRAY:
+ *num_components = format_components;
+ _mesa_get_format_swizzle(format, swizzle);
+ return true;
+ case MESA_FORMAT_LAYOUT_PACKED:
+ switch (*type) {
+ case GL_UNSIGNED_BYTE:
+ case GL_BYTE:
+ if (_mesa_get_format_max_bits(format) != 8)
+return false;
+ *num_components = _mesa_get_format_bytes(format);
+ switch (*num_components) {
+ case 1:
+endian = map_identity;
+break;
+ case 2:
+endian = _mesa_little_endian() ? map_identity : map_1032;
+break;
+ case 4:
+endian = _mesa_little_endian() ? map_identity : map_3210;
+break;
+ default:
+assert(!"Invalid number of components");
I think MSVC (and maybe optimized gcc) will complain than 'endian' is
not initialized for all cases. It would probably be best to initialize
endian to point to map_identity[] in the declaration. If the
"impossible" happens and the default case is hit in release build, we
should try to not crash.
+ }
+ break;
+ case GL_UNSIGNED_SHORT:
+ case GL_SHORT:
+ case GL_HALF_FLOAT:
+ if (_mesa_get_format_max_bits(format) != 16)
+return false;
+ *num_components = _mesa_get_format_bytes(format) / 2;
+ switch (*num_components) {
+ case 1:
+endian = map_identity;
+break;
+ case 2:
+endian = _mesa_little_endian() ? map_identity : map_1032;
+break;
+ default:
+assert(!"Invalid number of components");
+ }
+ break;
+ case GL_UNSIGNED_INT:
+ case GL_INT:
+ case GL_FLOAT:
+ /* This isn't packed. At least not really. */
+ assert(format_components == 1);
+ if (_mesa_get_format_max_bits(format) != 32)
+return false;
+ *num_components = format_components;
+ endian = map_identity;
+ break;
+ default:
+ return false;
+ }
+
+ _mesa_get_format_swizzle(format, packed_swizzle);
+
+ for (i = 0; i < 4; ++i)
+ swizzle[i] = endian[packed_swizzle[i]];
+
+ return true;
+ case MESA_FORMAT_LAYOUT_OTHER:
+ default:
+ return false;
+ }
+}
+
/* A bunch of format conversion macros and helper functions used below */
/* Only guaranteed to work for BITS <= 32 */
diff --git a/src/mesa/main/format_utils.h b/src/mesa/main/format_utils.h
index 1a6d7e0..632600e 100644
--- a/src/mesa/main/format_utils.h
+++ b/src/mesa/main/format_utils.h
@@ -65,6 +65,10 @@ _mesa_srgb_to_linear(float cs)
float _mesa_srgb_ubyte_to_linear_float(uint8
Re: [Mesa-dev] [PATCH v2 00/13] Rework the texture upload code
On 08/02/2014 02:11 PM, Jason Ekstrand wrote: This is a direct rework of the patch series starting here: https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/mesa-dev/2014-July/063483.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=HUNGyfTjzYlF3%2Btw%2FjiWURrNNVka9h4tzUBJn2NWblc%3D%0A&s=84e48a860d7664f8bb436d19d243010ab827e21e93a0bbe3bfdeee11eb89854a I've tried to address all of the direct comments given on those patches. This version is much better documented and even a little faster. Jason Ekstrand (13): mesa: Add a format description CSV file mesa: Add python to parse the formats CSV file mesa/formats: Autogenerate the format_info structure from a CSV file mesa/formats: Remove IndexBits mesa/formats: Add layout and swizzle information meas: Gather some common format conversion functions into a single file mesa/imports: Add a _mesa_half_is_negative helper function mesa/format_utils: Add a general format conversion function mesa/format_utils: Add a function to convert a mesa_format to an array format main/texstore: Split texture storage into three functions mesa/texstore: Use _mesa_swizzle_and_convert when possible mesa/texstore: Add a generic float/normalized rgba texture upload path mesa/texstore: Add a generic rgba integer texture upload path src/mesa/Makefile.am | 10 + src/mesa/Makefile.sources|1 + src/mesa/SConscript |1 + src/mesa/main/.gitignore |1 + src/mesa/main/format_info.py | 192 +++ src/mesa/main/format_pack.c | 102 +- src/mesa/main/format_parser.py | 521 +++ src/mesa/main/format_unpack.c| 69 +- src/mesa/main/format_unpack.h|3 - src/mesa/main/format_utils.c | 1005 src/mesa/main/format_utils.h | 77 + src/mesa/main/formats.c | 1786 + src/mesa/main/formats.csv| 282 src/mesa/main/formats.h | 29 + src/mesa/main/imports.h |5 + src/mesa/main/texcompress_etc.c | 20 +- src/mesa/main/texcompress_s3tc.c | 26 +- src/mesa/main/texstore.c | 3197 +++--- 18 files changed, 2834 insertions(+), 4493 deletions(-) create mode 100644 src/mesa/main/format_info.py create mode 100755 src/mesa/main/format_parser.py create mode 100644 src/mesa/main/format_utils.c create mode 100644 src/mesa/main/format_utils.h create mode 100644 src/mesa/main/formats.csv I did a quick re-review and things look pretty good. Just some minor nit-picks on a few patches. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 08/13] mesa/format_utils: Add a general format conversion function
On 08/02/2014 02:11 PM, Jason Ekstrand wrote: Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance Signed-off-by: Jason Ekstrand --- src/mesa/main/format_utils.c | 844 +++ src/mesa/main/format_utils.h | 5 + 2 files changed, 849 insertions(+) diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c index 241c158..d60aeb3 100644 --- a/src/mesa/main/format_utils.c +++ b/src/mesa/main/format_utils.c @@ -54,3 +54,847 @@ _mesa_srgb_ubyte_to_linear_float(uint8_t cl) return lut[cl]; } + +/* A bunch of format conversion macros and helper functions used below */ + +/* Only guaranteed to work for BITS <= 32 */ +#define MAX_UINT(BITS) ((BITS) == 32 ? UINT32_MAX : ((1u << (BITS)) - 1)) +#define MAX_INT(BITS) (int)MAX_UINT((BITS) - 1) I'd probably put one more set of parens around the whole macro body, just to be safe. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 06/13] meas: Gather some common format conversion functions into a single file
Typo in subject line: s/meas/mesa/ On 08/02/2014 02:11 PM, Jason Ekstrand wrote: This initial commit puts all of the RGB <-> sRGB conversion functions in format_utils.c. v2: Shorter commit subject and added format_utils.c to SConscript Signed-off-by: Jason Ekstrand --- src/mesa/Makefile.sources| 1 + src/mesa/SConscript | 1 + src/mesa/main/format_pack.c | 102 ++- src/mesa/main/format_unpack.c| 69 -- src/mesa/main/format_unpack.h| 3 -- src/mesa/main/format_utils.c | 56 + src/mesa/main/format_utils.h | 68 ++ src/mesa/main/texcompress_etc.c | 20 src/mesa/main/texcompress_s3tc.c | 26 +- 9 files changed, 205 insertions(+), 141 deletions(-) create mode 100644 src/mesa/main/format_utils.c create mode 100644 src/mesa/main/format_utils.h ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 03/13] mesa/formats: Autogenerate the format_info structure from a CSV file
On 08/02/2014 02:11 PM, Jason Ekstrand wrote:
Instead of a having all of the format metadata in a gigantic hard-to-edit
array of type struct format_info, we now use a human-readable CSV file.
The CSV file also contains more format information than the format_info
struct contained so we can potentially make format_info more detailed later.
The idea (and some of the implementation) for this was taken from the
gallium driver. However, due to differences in the way the two systems
handle formats, they are NOT the same; watch out for differences.
Signed-off-by: Jason Ekstrand
---
src/mesa/Makefile.am | 10 +
src/mesa/main/.gitignore |1 +
src/mesa/main/format_info.py | 181 +
src/mesa/main/formats.c | 1739 +-
4 files changed, 193 insertions(+), 1738 deletions(-)
create mode 100644 src/mesa/main/format_info.py
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 88eeff9..57c1e4a 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -64,6 +64,7 @@ include Makefile.sources
BUILT_SOURCES = \
main/get_hash.h \
+main/format_info.c \
$(BUILDDIR)main/git_sha1.h \
$(BUILDDIR)program/program_parse.tab.c \
$(BUILDDIR)program/lex.yy.c
@@ -81,6 +82,15 @@ main/get_hash.h: $(GLAPI)/gl_and_es_API.xml
main/get_hash_params.py \
-f $< > $@.tmp; \
mv $@.tmp $@;
+main/format_info.c: main/formats.csv\
+main/format_parser.py main/format_info.py
+ $(AM_V_GEN)set -e; \
+ $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/main/format_info.py\
+ $< > $@.tmp; \
+ mv $@.tmp $@;
+
+main/formats.c: main/format_info.c
+
noinst_LTLIBRARIES = $(ARCH_LIBS)
if NEED_LIBMESA
noinst_LTLIBRARIES += libmesa.la
Looks like we need to update the SConscipt file too. Can you take care
of that?
Maybe the new python script should be added in one commit, then switch
over the Makefile/SConscript building in another commit?
diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore
index 837f490..fec0629 100644
--- a/src/mesa/main/.gitignore
+++ b/src/mesa/main/.gitignore
@@ -8,3 +8,4 @@ git_sha1.h.tmp
remap_helper.h
get_hash.h
get_hash.h.tmp
+format_info.c
diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
new file mode 100644
index 000..9b63bfb
--- /dev/null
+++ b/src/mesa/main/format_info.py
@@ -0,0 +1,181 @@
+#!/usr/bin/env python
+#
+# Copyright 2014 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the
+# "Software"), to deal in the Software without restriction, including
+# without limitation the rights to use, copy, modify, merge, publish,
+# distribute, sub license, and/or sell copies of the Software, and to
+# permit persons to whom the Software is furnished to do so, subject to
+# the following conditions:
+#
+# The above copyright notice and this permission notice (including the
+# next paragraph) shall be included in all copies or substantial portions
+# of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+# IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+# ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+# TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+import format_parser as parser
+import sys
+
+def get_gl_base_format(fmat):
+ if fmat.name == 'MESA_FORMAT_NONE':
+ return 'GL_NONE'
+ elif fmat.name in ['MESA_FORMAT_YCBCR', 'MESA_FORMAT_YCBCR_REV']:
+ return 'GL_YCBCR_MESA'
+ elif fmat.has_channel('r'):
+ if fmat.has_channel('g'):
+ if fmat.has_channel('b'):
+if fmat.has_channel('a'):
+ return 'GL_RGBA'
+else:
+ return 'GL_RGB'
+ else:
+return 'GL_RG'
+ else:
+ return 'GL_RED'
+ elif fmat.has_channel('l'):
+ if fmat.has_channel('a'):
+ return 'GL_LUMINANCE_ALPHA'
+ else:
+ return 'GL_LUMINANCE'
+ elif fmat.has_channel('a') and fmat.num_channels() == 1:
+ return 'GL_ALPHA'
+ elif fmat.has_channel('z'):
+ if fmat.has_channel('s'):
+ return 'GL_DEPTH_STENCIL'
+ else:
+ return 'GL_DEPTH_COMPONENT'
+ elif fmat.has_channel('s'):
+ return 'GL_STENCIL_INDEX'
+ elif fmat.has_channel('i') and fmat.num_channels() == 1:
+ return 'GL_INTENSITY'
+ else:
+ assert False
+
+def get_gl_data_type(fmat):
+ if fmat.is_compressed():
+ if
Re: [Mesa-dev] [PATCH 0/5] OpenGL ES improvements
Am 03.08.2014 14:40, schrieb Marek Olšák: > Hi everyone, > > This series adds: > - Support for ETC2 texture formats to all gallium drivers. This is a > requirement for OpenGL ES 3.0, which can now be considered feature-complete > as far as I know. Textures of such formats are loaded as plain R/RG/RGBA in > st/mesa due to lack of hardware support. There is no real gallium support for > the new formats. The i965 driver is doing the same thing. > - Support for GL_ARB_ES3_compatibility, which requires ETC2 texture formats, > for all gallium drivers that support GLSL 3.30. > - Support for GL_OES_compressed_ETC1_RGB8_texture for all gallium drivers. > This is also loaded as plain RGBA by st/Mesa. > > Please review. > > Marek The series looks ok to me though I think it would be good if real etc1/etc2 support was added to gallium (well etc1 is already there). There's quite plenty of hw with gallium supported drivers which can do at least some of it: - all adrenos 2xx/3xx can do etc1 unless I'm mistaken, and adreno 3xx should be able to do etc2. - some intel hw (baytrail/gen8) can do etc1/etc2. - gk20a probably also could do etc1/etc2. I am actually sort of surprised some amd parts can't do it (kabini and friends), are you sure they really can't? Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: adjust Z coordinates for quad clearing
Specify the quad's Z position in clip coordinate space, not normalized Z space. Use viewport scale, translation = 0.5, 0.5. Before, we were specifying the quad's Z position in [0,1] and using viewport scale=1.0, translate=0.0. That works fine, unless your driver needs to work in clip coordinate space and needs to reconstruct viewport near/far values from the scale/translation factors. The VMware svga driver falls into that category. When we did that reconstruction we wound up with near=-1 and far=1 which are outside the limits of [0,1]. In some cases, this caused the quad to be drawn at the wrong depth. In other cases it was clipped away. Fixes some scissored depth clears with VMware driver. This should have no effect on other drivers. --- src/mesa/state_tracker/st_cb_clear.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_clear.c b/src/mesa/state_tracker/st_cb_clear.c index 4bfa8d7..4ca6de3 100644 --- a/src/mesa/state_tracker/st_cb_clear.c +++ b/src/mesa/state_tracker/st_cb_clear.c @@ -173,6 +173,9 @@ draw_quad(struct st_context *st, return; } + /* Convert Z from [0,1] to [-1,1] range */ + z = z * 2.0f - 1.0f; + /* positions */ vertices[0][0][0] = x0; vertices[0][0][1] = y0; @@ -319,11 +322,11 @@ clear_with_quad(struct gl_context *ctx, unsigned clear_buffers) struct pipe_viewport_state vp; vp.scale[0] = 0.5f * fb_width; vp.scale[1] = fb_height * (invert ? -0.5f : 0.5f); - vp.scale[2] = 1.0f; + vp.scale[2] = 0.5; vp.scale[3] = 1.0f; vp.translate[0] = 0.5f * fb_width; vp.translate[1] = 0.5f * fb_height; - vp.translate[2] = 0.0f; + vp.translate[2] = 0.5; vp.translate[3] = 0.0f; cso_set_viewport(st->cso_context, &vp); } -- 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 0/5] OpenGL ES improvements
On Mon, Aug 4, 2014 at 11:54 AM, Roland Scheidegger wrote: > Am 03.08.2014 14:40, schrieb Marek Olšák: >> Hi everyone, >> >> This series adds: >> - Support for ETC2 texture formats to all gallium drivers. This is a >> requirement for OpenGL ES 3.0, which can now be considered feature-complete >> as far as I know. Textures of such formats are loaded as plain R/RG/RGBA in >> st/mesa due to lack of hardware support. There is no real gallium support >> for the new formats. The i965 driver is doing the same thing. >> - Support for GL_ARB_ES3_compatibility, which requires ETC2 texture formats, >> for all gallium drivers that support GLSL 3.30. >> - Support for GL_OES_compressed_ETC1_RGB8_texture for all gallium drivers. >> This is also loaded as plain RGBA by st/Mesa. >> >> Please review. >> >> Marek > > The series looks ok to me though I think it would be good if real > etc1/etc2 support was added to gallium (well etc1 is already there). > There's quite plenty of hw with gallium supported drivers which can do > at least some of it: > - all adrenos 2xx/3xx can do etc1 unless I'm mistaken, and adreno 3xx > should be able to do etc2. > - some intel hw (baytrail/gen8) can do etc1/etc2. > - gk20a probably also could do etc1/etc2. > > I am actually sort of surprised some amd parts can't do it (kabini and > friends), are you sure they really can't? Yes. They don't support it. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] c11/threads: add missing brackets around _MTX_INITIALIZER_NP
On 02/08/14 02:51, Emil Velikov wrote:
> On 02/08/14 00:26, Ian Romanick wrote:
>> On 08/01/2014 09:41 AM, Emil Velikov wrote:
>>> ... for win32 builds. Spotted this warning when I've imported the
>>> library into waffle, and gave mingw-w64-gcc a bash at compiling it.
>>>
>>> src/waffle/core/wcore_display.c:37:5: warning: missing braces around
>>> initializer [-Wmissing-braces]
>>> static mtx_t mutex = _MTX_INITIALIZER_NP;
>>> ^
>>>
>>> Signed-off-by: Emil Velikov
>>> ---
>>> include/c11/threads_win32.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/c11/threads_win32.h b/include/c11/threads_win32.h
>>> index 5298a84..35880ba 100644
>>> --- a/include/c11/threads_win32.h
>>> +++ b/include/c11/threads_win32.h
>>> @@ -85,7 +85,7 @@ Configuration macro:
>>> #define TSS_DTOR_ITERATIONS 1
>>>
>>> // FIXME: temporary non-standard hack to ease transition
>>> -#define _MTX_INITIALIZER_NP {(PCRITICAL_SECTION_DEBUG)-1, -1, 0, 0, 0, 0}
>>> +#define _MTX_INITIALIZER_NP {{(PCRITICAL_SECTION_DEBUG)-1, -1, 0, 0, 0, 0}}
>>
>> This is because CRITICAL_SECTION is actually a typedef of a pointer to
>> some structure type, so it needs to be initialized like an array of
>> strcutres. Yeah?
>>
> I wish I could agree.
>
> CRITICAL_SECTION is a typedef of a typedef'ed struct (no pointers yet) where
> the first member is a struct *, as seen below.
>
> typedef B CRITICAL_SECTION;
> typedef struct A {
>struct *bla;
>...
> } B;
>
> I remember spending a few hours reading and experimenting with this and every
> way I looked at it current code seems sane. In the end I've smashed the
> brackets not to pollute the build log and carried on with other stuff :) Don't
> think I have checked if MSVC complained about the issue though. Will give it a
> try next time I reboot.
>
>
>> I searched a bit on the net, and I could not find a single example of
>> initializing a win32 CRITICAL_SECTION this way. Is this a good idea?
>> The FIXME comment doesn't inspire confidence...
>>
> Same here. AFAICS one should init the "mutex" via InitializeCriticalSection or
> InitializeCriticalSectionAndSpinCount. Either of which is very Win32 specific
> and not at all portable. Perhaps Jose (the author) can share some more
> insights on the topic ?
>
Fun stuff. MSVC produces _no_ warnings with or without this patch. Not sure
what exactly is happening here, perhaps I'm hitting some obscure mingw-w64
(gcc?) bug ?
-Emil
>
> -Emil
>
>>> /* types */
>>> typedef struct cnd_t {
>>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/4] ra: consider all spillable nodes for spilling
Connor Abbott writes: > On Fri, Aug 1, 2014 at 12:25 PM, Eric Anholt wrote: >> Connor Abbott writes: >> >>> On Fri, Aug 1, 2014 at 11:51 AM, Eric Anholt wrote: Connor Abbott writes: > On Thu, Jul 31, 2014 at 1:05 PM, Eric Anholt wrote: >> Connor Abbott writes: >>> That's not necessarily true - you could want to spill a trivially >>> colored register that interferes with a non trivially colored >>> register, especially if the spill cost of the non trivially colored >>> register is higher than that of the trivially colored register because >>> e.g. the non trivially colored register is used in a loop. Especially, >>> I ran into trouble with the varying packing tests in piglit which >>> after a few rounds of spilling looked something like: >> >> If it's trivially colorable, then when you're trying to get a >> non-conflicting color for a difficult neighbor (an optimistic-coloring >> one near the top of the stack that's triggering the need for spilling), >> it's out consideration because it's deeper in the stack. > > Right... so in that case, can't we just ignore everything on the stack > below the node that couldn't be colored in ra_select()? Yep, that's what the code's doing currently. >>> >>> No, it's also considering other optimistically colored nodes below the >>> one that failed on the stack... see patch 3 in v3 of my series, which >>> changes the code to actually do that. >> >> Oh, I misread you as saying s/couldn't be colored/first couldn't be >> trivially colored/. It seems like obviously the behavior we want, to >> me. > > Cool, then can you put your r-b on the last two patches of the v3 > series so we can push it? Not really -- I'm saying that we *do* want to consider the other optimistically colored nodes. Those ones lower in the stack might actually be useful to spill, since if spilled they could potentially make other values trivially colorable, which would change the order of pushes and might make our node colorable. pgp6CEuge9xHS.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] mesa: Actually use the Mesa IR optimizer for ARB programs.
Kenneth Graunke writes: > On Haswell, this cuts 1-3 instructions from 183 vertex shaders in > "Shadowrun Returns", "Shatter", and "Trine 2." It adds 2 instructions > to a single fragment shader in "Closure." Reviewed-by: Eric Anholt pgpJJ9s8qS1qU.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 v2 3/4] ra: consider all spillable nodes for spilling
On Mon, Aug 4, 2014 at 9:46 AM, Eric Anholt wrote: > Connor Abbott writes: > >> On Fri, Aug 1, 2014 at 12:25 PM, Eric Anholt wrote: >>> Connor Abbott writes: >>> On Fri, Aug 1, 2014 at 11:51 AM, Eric Anholt wrote: > Connor Abbott writes: > >> On Thu, Jul 31, 2014 at 1:05 PM, Eric Anholt wrote: >>> Connor Abbott writes: That's not necessarily true - you could want to spill a trivially colored register that interferes with a non trivially colored register, especially if the spill cost of the non trivially colored register is higher than that of the trivially colored register because e.g. the non trivially colored register is used in a loop. Especially, I ran into trouble with the varying packing tests in piglit which after a few rounds of spilling looked something like: >>> >>> If it's trivially colorable, then when you're trying to get a >>> non-conflicting color for a difficult neighbor (an optimistic-coloring >>> one near the top of the stack that's triggering the need for spilling), >>> it's out consideration because it's deeper in the stack. >> >> Right... so in that case, can't we just ignore everything on the stack >> below the node that couldn't be colored in ra_select()? > > Yep, that's what the code's doing currently. No, it's also considering other optimistically colored nodes below the one that failed on the stack... see patch 3 in v3 of my series, which changes the code to actually do that. >>> >>> Oh, I misread you as saying s/couldn't be colored/first couldn't be >>> trivially colored/. It seems like obviously the behavior we want, to >>> me. >> >> Cool, then can you put your r-b on the last two patches of the v3 >> series so we can push it? > > Not really -- I'm saying that we *do* want to consider the other > optimistically colored nodes. Those ones lower in the stack might > actually be useful to spill, since if spilled they could potentially > make other values trivially colorable, which would change the order of > pushes and might make our node colorable. > Well, you could apply that same argument to *any* spillable node in the graph, which brings us right back to where we started. I think what we have now is a rather arbitrary compromise between "consider everything for spilling because it might make other things trivially colorable" and "only spill the things we know are likely to help." I still think we should go with the former, since it produces numbers equivalent to what we have right now instead of slightly worse numbers. And besides, as I noted in the commit message, considering those nodes doesn't seem to be useful in practice since we get the exact same code anyways - even with reducing the number of registers to make more things spill. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/4] ra: consider all spillable nodes for spilling
Connor Abbott writes: > On Mon, Aug 4, 2014 at 9:46 AM, Eric Anholt wrote: >> Connor Abbott writes: >> >>> On Fri, Aug 1, 2014 at 12:25 PM, Eric Anholt wrote: Connor Abbott writes: > On Fri, Aug 1, 2014 at 11:51 AM, Eric Anholt wrote: >> Connor Abbott writes: >> >>> On Thu, Jul 31, 2014 at 1:05 PM, Eric Anholt wrote: Connor Abbott writes: > That's not necessarily true - you could want to spill a trivially > colored register that interferes with a non trivially colored > register, especially if the spill cost of the non trivially colored > register is higher than that of the trivially colored register because > e.g. the non trivially colored register is used in a loop. Especially, > I ran into trouble with the varying packing tests in piglit which > after a few rounds of spilling looked something like: If it's trivially colorable, then when you're trying to get a non-conflicting color for a difficult neighbor (an optimistic-coloring one near the top of the stack that's triggering the need for spilling), it's out consideration because it's deeper in the stack. >>> >>> Right... so in that case, can't we just ignore everything on the stack >>> below the node that couldn't be colored in ra_select()? >> >> Yep, that's what the code's doing currently. > > No, it's also considering other optimistically colored nodes below the > one that failed on the stack... see patch 3 in v3 of my series, which > changes the code to actually do that. Oh, I misread you as saying s/couldn't be colored/first couldn't be trivially colored/. It seems like obviously the behavior we want, to me. >>> >>> Cool, then can you put your r-b on the last two patches of the v3 >>> series so we can push it? >> >> Not really -- I'm saying that we *do* want to consider the other >> optimistically colored nodes. Those ones lower in the stack might >> actually be useful to spill, since if spilled they could potentially >> make other values trivially colorable, which would change the order of >> pushes and might make our node colorable. >> > > Well, you could apply that same argument to *any* spillable node in > the graph, which brings us right back to where we started. I think > what we have now is a rather arbitrary compromise between "consider > everything for spilling because it might make other things trivially > colorable" and "only spill the things we know are likely to help." I > still think we should go with the former, since it produces numbers > equivalent to what we have right now instead of slightly worse > numbers. And besides, as I noted in the commit message, considering > those nodes doesn't seem to be useful in practice since we get the > exact same code anyways - even with reducing the number of registers > to make more things spill. I don't believe that's true. The argument before was about trivially-colorable things -- things that always appear in the stack before the optimistic things. They can't have an effect on the things higher in the stack, becuase they're already in the stack and you know you can color them regardless of choices higher in the stack, so you don't have to spill them ever. For your optimistic nodes, though, even though you've put them in the stack, you want to consider them for spilling because even once you resolve the spills and manage to color things high in the stack (in your scheme), you may have to spill that lower-down optimistic node anyway. So you failed to consider an important node for spilling, that might have also resolved your higher-in-the-stack troubles, and got extra spilling as a result. pgppBMyWP9sIS.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] c11/threads: add missing brackets around _MTX_INITIALIZER_NP
Am 02.08.2014 03:51, schrieb Emil Velikov:
> On 02/08/14 00:26, Ian Romanick wrote:
>> On 08/01/2014 09:41 AM, Emil Velikov wrote:
>>> ... for win32 builds. Spotted this warning when I've imported the
>>> library into waffle, and gave mingw-w64-gcc a bash at compiling it.
>>>
>>> src/waffle/core/wcore_display.c:37:5: warning: missing braces around
>>> initializer [-Wmissing-braces]
>>> static mtx_t mutex = _MTX_INITIALIZER_NP;
>>> ^
>>>
>>> Signed-off-by: Emil Velikov
>>> ---
>>> include/c11/threads_win32.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/c11/threads_win32.h b/include/c11/threads_win32.h
>>> index 5298a84..35880ba 100644
>>> --- a/include/c11/threads_win32.h
>>> +++ b/include/c11/threads_win32.h
>>> @@ -85,7 +85,7 @@ Configuration macro:
>>> #define TSS_DTOR_ITERATIONS 1
>>>
>>> // FIXME: temporary non-standard hack to ease transition
>>> -#define _MTX_INITIALIZER_NP {(PCRITICAL_SECTION_DEBUG)-1, -1, 0, 0, 0, 0}
>>> +#define _MTX_INITIALIZER_NP {{(PCRITICAL_SECTION_DEBUG)-1, -1, 0, 0, 0, 0}}
>>
>> This is because CRITICAL_SECTION is actually a typedef of a pointer to
>> some structure type, so it needs to be initialized like an array of
>> strcutres. Yeah?
>>
> I wish I could agree.
>
> CRITICAL_SECTION is a typedef of a typedef'ed struct (no pointers yet) where
> the first member is a struct *, as seen below.
>
> typedef B CRITICAL_SECTION;
> typedef struct A {
>struct *bla;
>...
> } B;
>
> I remember spending a few hours reading and experimenting with this and every
> way I looked at it current code seems sane. In the end I've smashed the
> brackets not to pollute the build log and carried on with other stuff :) Don't
> think I have checked if MSVC complained about the issue though. Will give it a
> try next time I reboot.
>
>
>> I searched a bit on the net, and I could not find a single example of
>> initializing a win32 CRITICAL_SECTION this way. Is this a good idea?
>> The FIXME comment doesn't inspire confidence...
>>
> Same here. AFAICS one should init the "mutex" via InitializeCriticalSection or
> InitializeCriticalSectionAndSpinCount. Either of which is very Win32 specific
> and not at all portable. Perhaps Jose (the author) can share some more
> insights on the topic ?
>
>
Yeah that seems fairly hacky. The idea is explained here (near the
beginning): http://locklessinc.com/articles/pthreads_on_windows/ -
according to the comments it doesn't work on windows xp even.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: Fix Altivec pack intrinsics for little-endian
This patch fixes use of Altivec pack intrinsics on little-endian PowerPC
systems. Since little-endian operation only affects the load and store
instructions, the semantics of pack (and other) instructions that take
two input vectors implicitly change: the pack instructions still fill
a register placing values from the first operand into the "high" parts
of the register, and values from the second operand into the "low" parts
of the register, but since vector loads and stores perform an endian swap,
the high parts end up at high memory addresses.
To still achieve the desired effect, we have to swap the two inputs to
the pack instruction on little-endian systems. This is done automatically
by the back-end for instructions generated by LLVM, but needs to be done
manually when emitting intrisincs (which still result in that instruction
being emitted directly).
Signed-off-by: Ulrich Weigand
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index a48a922..cdf6d80 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -464,6 +464,7 @@ lp_build_pack2(struct gallivm_state *gallivm,
if((util_cpu_caps.has_sse2 || util_cpu_caps.has_altivec) &&
src_type.width * src_type.length >= 128) {
const char *intrinsic = NULL;
+ boolean swap_intrinsic_operands = FALSE;
switch(src_type.width) {
case 32:
@@ -482,6 +483,9 @@ lp_build_pack2(struct gallivm_state *gallivm,
} else {
intrinsic = "llvm.ppc.altivec.vpkuwus";
}
+#ifdef PIPE_ARCH_LITTLE_ENDIAN
+ swap_intrinsic_operands = TRUE;
+#endif
}
break;
case 16:
@@ -490,12 +494,18 @@ lp_build_pack2(struct gallivm_state *gallivm,
intrinsic = "llvm.x86.sse2.packsswb.128";
} else if (util_cpu_caps.has_altivec) {
intrinsic = "llvm.ppc.altivec.vpkshss";
+#ifdef PIPE_ARCH_LITTLE_ENDIAN
+ swap_intrinsic_operands = TRUE;
+#endif
}
} else {
if (util_cpu_caps.has_sse2) {
intrinsic = "llvm.x86.sse2.packuswb.128";
} else if (util_cpu_caps.has_altivec) {
intrinsic = "llvm.ppc.altivec.vpkshus";
+#ifdef PIPE_ARCH_LITTLE_ENDIAN
+ swap_intrinsic_operands = TRUE;
+#endif
}
}
break;
@@ -504,7 +514,11 @@ lp_build_pack2(struct gallivm_state *gallivm,
if (intrinsic) {
if (src_type.width * src_type.length == 128) {
LLVMTypeRef intr_vec_type = lp_build_vec_type(gallivm, intr_type);
-res = lp_build_intrinsic_binary(builder, intrinsic, intr_vec_type,
lo, hi);
+if (swap_intrinsic_operands) {
+ res = lp_build_intrinsic_binary(builder, intrinsic,
intr_vec_type, hi, lo);
+} else {
+ res = lp_build_intrinsic_binary(builder, intrinsic,
intr_vec_type, lo, hi);
+}
if (dst_vec_type != intr_vec_type) {
res = LLVMBuildBitCast(builder, res, dst_vec_type, "");
}
@@ -513,6 +527,8 @@ lp_build_pack2(struct gallivm_state *gallivm,
int num_split = src_type.width * src_type.length / 128;
int i;
int nlen = 128 / src_type.width;
+int lo_off = swap_intrinsic_operands ? nlen : 0;
+int hi_off = swap_intrinsic_operands ? 0 : nlen;
struct lp_type ndst_type = lp_type_unorm(dst_type.width, 128);
struct lp_type nintr_type = lp_type_unorm(intr_type.width, 128);
LLVMValueRef tmpres[LP_MAX_VECTOR_WIDTH / 128];
@@ -524,9 +540,9 @@ lp_build_pack2(struct gallivm_state *gallivm,
for (i = 0; i < num_split / 2; i++) {
tmplo = lp_build_extract_range(gallivm,
- lo, i*nlen*2, nlen);
+ lo, i*nlen*2 + lo_off, nlen);
tmphi = lp_build_extract_range(gallivm,
- lo, i*nlen*2 + nlen, nlen);
+ lo, i*nlen*2 + hi_off, nlen);
tmpres[i] = lp_build_intrinsic_binary(builder, intrinsic,
nintr_vec_type, tmplo,
tmphi);
if (ndst_vec_type != nintr_vec_type) {
@@ -535,9 +551,9 @@ lp_build_pack2(struct gallivm_state *gallivm,
}
for (i = 0; i < num_split / 2; i++) {
tmplo = lp_build_extract_range(gallivm,
- hi, i*nlen*2, nlen);
+ hi, i*nlen*2 + lo_off, nlen);
tmphi = lp_build_extract_range(gallivm,
-
Re: [Mesa-dev] [PATCH v2 3/4] ra: consider all spillable nodes for spilling
On Mon, Aug 4, 2014 at 10:17 AM, Eric Anholt wrote: > Connor Abbott writes: > >> On Mon, Aug 4, 2014 at 9:46 AM, Eric Anholt wrote: >>> Connor Abbott writes: >>> On Fri, Aug 1, 2014 at 12:25 PM, Eric Anholt wrote: > Connor Abbott writes: > >> On Fri, Aug 1, 2014 at 11:51 AM, Eric Anholt wrote: >>> Connor Abbott writes: >>> On Thu, Jul 31, 2014 at 1:05 PM, Eric Anholt wrote: > Connor Abbott writes: >> That's not necessarily true - you could want to spill a trivially >> colored register that interferes with a non trivially colored >> register, especially if the spill cost of the non trivially colored >> register is higher than that of the trivially colored register >> because >> e.g. the non trivially colored register is used in a loop. >> Especially, >> I ran into trouble with the varying packing tests in piglit which >> after a few rounds of spilling looked something like: > > If it's trivially colorable, then when you're trying to get a > non-conflicting color for a difficult neighbor (an optimistic-coloring > one near the top of the stack that's triggering the need for > spilling), > it's out consideration because it's deeper in the stack. Right... so in that case, can't we just ignore everything on the stack below the node that couldn't be colored in ra_select()? >>> >>> Yep, that's what the code's doing currently. >> >> No, it's also considering other optimistically colored nodes below the >> one that failed on the stack... see patch 3 in v3 of my series, which >> changes the code to actually do that. > > Oh, I misread you as saying s/couldn't be colored/first couldn't be > trivially colored/. It seems like obviously the behavior we want, to > me. Cool, then can you put your r-b on the last two patches of the v3 series so we can push it? >>> >>> Not really -- I'm saying that we *do* want to consider the other >>> optimistically colored nodes. Those ones lower in the stack might >>> actually be useful to spill, since if spilled they could potentially >>> make other values trivially colorable, which would change the order of >>> pushes and might make our node colorable. >>> >> >> Well, you could apply that same argument to *any* spillable node in >> the graph, which brings us right back to where we started. I think >> what we have now is a rather arbitrary compromise between "consider >> everything for spilling because it might make other things trivially >> colorable" and "only spill the things we know are likely to help." I >> still think we should go with the former, since it produces numbers >> equivalent to what we have right now instead of slightly worse >> numbers. And besides, as I noted in the commit message, considering >> those nodes doesn't seem to be useful in practice since we get the >> exact same code anyways - even with reducing the number of registers >> to make more things spill. > > I don't believe that's true. The argument before was about > trivially-colorable things -- things that always appear in the stack > before the optimistic things. They can't have an effect on the things > higher in the stack, becuase they're already in the stack and you know > you can color them regardless of choices higher in the stack, so you > don't have to spill them ever. > > For your optimistic nodes, though, even though you've put them in the > stack, you want to consider them for spilling because even once you > resolve the spills and manage to color things high in the stack (in your > scheme), you may have to spill that lower-down optimistic node anyway. > So you failed to consider an important node for spilling, that might > have also resolved your higher-in-the-stack troubles, and got extra > spilling as a result. How, exactly, could spilling in this case ever resolve the "higher-in-the-stack troubles"? Say we have an optimistically colored node A, that is lower on the stack than the optimistically colored node B that is currently failing to be colored. There are two effects of spilling A: 1) Some of the nodes that we split A into may become trivially colorable, which will push them down on the stack - but this is all happening below B on the stack anyways, so it doesn't make any difference for now. 2) Some of the nodes that were interfering with A may no longer interfere with any of the nodes we split A into - but again, we only care about B or nodes above B on the stack, so we don't count that interference anyways, and therefore we still haven't gained anything. So although spilling A may help in the future, I still fail to see how it could help now - we still have to spill nodes above B (or B itself) before we can make progress. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http:
Re: [Mesa-dev] [PATCH 5/5 v2] i965: Add support for ARB_copy_image
One case where the memcpy path won't work is if the source and destination are the same buffer. In that case it tries to map the texture twice and hits an assert. I think this could be a legitimate use case if the source and destination rectangles don't overlap. The extension spec isn't very clear on whether this is allowed but the spec for GL 4.4 actually mentions blitting between a single buffer and implies that it's ok if the rectangles don't overlap. Perhaps one way to solve this would be to check if src_mt==dst_mt and if so it could map the union of both rectangles as read and write. It would then have to manually offset the source and destination pointers to the right place. You might also want to update the commit message as the patch is no longer restricted to a pitch of at most INT16_MAX. Regards, - Neil Jason Ekstrand writes: > This, together with the meta path, provides a almost-complete implemetation > of ARB_copy_image. The only case that won't work is if one of the textures > is compressed and has a pitch greater than INT16_MAX. I think that's good > enough to justify turning on the extension. > > v2: Add a fallback memcpy path for when the texture is too big for the > blitter > > Signed-off-by: Jason Ekstrand ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5 v2] i965: Add support for ARB_copy_image
Thanks Neil, I'll make that change. Should be simple enough. --Jason On Mon, Aug 4, 2014 at 10:51 AM, Neil Roberts wrote: > One case where the memcpy path won't work is if the source and > destination are the same buffer. In that case it tries to map the > texture twice and hits an assert. I think this could be a legitimate use > case if the source and destination rectangles don't overlap. The > extension spec isn't very clear on whether this is allowed but the spec > for GL 4.4 actually mentions blitting between a single buffer and > implies that it's ok if the rectangles don't overlap. Perhaps one way to > solve this would be to check if src_mt==dst_mt and if so it could map > the union of both rectangles as read and write. It would then have to > manually offset the source and destination pointers to the right place. > > You might also want to update the commit message as the patch is no > longer restricted to a pitch of at most INT16_MAX. > > Regards, > - Neil > > Jason Ekstrand writes: > > > This, together with the meta path, provides a almost-complete > implemetation > > of ARB_copy_image. The only case that won't work is if one of the > textures > > is compressed and has a pitch greater than INT16_MAX. I think that's > good > > enough to justify turning on the extension. > > > > v2: Add a fallback memcpy path for when the texture is too big for the > > blitter > > > > Signed-off-by: Jason Ekstrand > ___ > 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] [PATCH 1/3] glsl: Make it possible to ignore built-ins when matching signatures.
Series is
Reviewed-by: Ian Romanick
Thanks, Ken!
On 07/24/2014 02:05 PM, Kenneth Graunke wrote:
> Historically, we've implemented the rules for overriding built-in
> functions by creating multiple ir_functions and relying on the symbol
> table to hide the one containing built-in functions. That works, but
> has a few drawbacks, so the next patch will change it.
>
> Instead, we'll have a single ir_function for a particular name, which
> will contain both built-in and user-defined signatures. Passing an
> extra parameter to matching_signature makes it easy to ignore built-ins
> when they're supposed to be hidden.
>
> I didn't add the parameter to exact_matching_signature since it wasn't
> necessary.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/ast_function.cpp | 15 ---
> src/glsl/builtin_functions.cpp | 3 ++-
> src/glsl/ir.h | 4 +++-
> src/glsl/ir_function.cpp | 10 +++---
> src/glsl/ir_reader.cpp | 3 ++-
> src/glsl/link_functions.cpp| 2 +-
> src/glsl/linker.cpp| 3 ++-
> src/glsl/lower_packed_varyings.cpp | 2 +-
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
> src/mesa/program/ir_to_mesa.cpp| 2 +-
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
> 12 files changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> index 4981fe1..39c7bee 100644
> --- a/src/glsl/ast_function.cpp
> +++ b/src/glsl/ast_function.cpp
> @@ -450,20 +450,21 @@ match_function_by_name(const char *name,
>goto done; /* no match */
>
> if (f != NULL) {
> + /* In desktop GL, the presence of a user-defined signature hides any
> + * built-in signatures, so we must ignore them. In contrast, in ES2
> + * user-defined signatures add new overloads, so we must consider them.
> + */
> + bool allow_builtins = state->es_shader || !f->has_user_signature();
> +
>/* Look for a match in the local shader. If exact, we're done. */
>bool is_exact = false;
>sig = local_sig = f->matching_signature(state, actual_parameters,
> - &is_exact);
> + allow_builtins, &is_exact);
>if (is_exact)
>goto done;
>
> - if (!state->es_shader && f->has_user_signature()) {
> - /* In desktop GL, the presence of a user-defined signature hides any
> - * built-in signatures, so we must ignore them. In contrast, in ES2
> - * user-defined signatures add new overloads, so we must proceed.
> - */
> + if (!allow_builtins)
>goto done;
> - }
> }
>
> /* Local shader has no exact candidates; check the built-ins. */
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
> index e01742c..185fe98 100644
> --- a/src/glsl/builtin_functions.cpp
> +++ b/src/glsl/builtin_functions.cpp
> @@ -706,7 +706,8 @@ builtin_builder::find(_mesa_glsl_parse_state *state,
> if (f == NULL)
>return NULL;
>
> - ir_function_signature *sig = f->matching_signature(state,
> actual_parameters);
> + ir_function_signature *sig =
> + f->matching_signature(state, actual_parameters, true);
> if (sig == NULL)
>return NULL;
>
> diff --git a/src/glsl/ir.h b/src/glsl/ir.h
> index ea19924..260dd34 100644
> --- a/src/glsl/ir.h
> +++ b/src/glsl/ir.h
> @@ -974,6 +974,7 @@ public:
> */
> ir_function_signature *matching_signature(_mesa_glsl_parse_state *state,
> const exec_list *actual_param,
> + bool allow_builtins,
>bool *match_is_exact);
>
> /**
> @@ -981,7 +982,8 @@ public:
> * conversions into account.
> */
> ir_function_signature *matching_signature(_mesa_glsl_parse_state *state,
> - const exec_list *actual_param);
> + const exec_list *actual_param,
> + bool allow_builtins);
>
> /**
> * Find a signature that exactly matches a set of actual parameters
> without
> diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
> index 7d6c2f4..98bec45 100644
> --- a/src/glsl/ir_function.cpp
> +++ b/src/glsl/ir_function.cpp
> @@ -281,15 +281,18 @@ choose_best_inexact_overload(_mesa_glsl_parse_state
> *state,
>
> ir_function_signature *
> ir_function::matching_signature(_mesa_glsl_parse_state *state,
> -const exec_list *actual_parameters)
> +const exec_list *actual_parameters,
> +
Re: [Mesa-dev] [PATCH v2 09/13] mesa/format_utils: Add a function to convert a mesa_format to an array format
On Mon, Aug 4, 2014 at 7:55 AM, Brian Paul wrote:
> On 08/02/2014 02:11 PM, Jason Ekstrand wrote:
>
>> This commits adds the _mesa_format_to_arary function that determines if
>> the
>>
>
> "array"
>
>
>
> given format can be represented as an array format and computes the array
>> format parameters. This is a direct helper function for using
>> _mesa_swizzle_and_convert
>>
>> v2: Better documentation and commit message
>>
>> Signed-off-by: Jason Ekstrand
>> ---
>> src/mesa/main/format_utils.c | 105 ++
>> +
>> src/mesa/main/format_utils.h | 4 ++
>> 2 files changed, 109 insertions(+)
>>
>> diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c
>> index d60aeb3..95b4612 100644
>> --- a/src/mesa/main/format_utils.c
>> +++ b/src/mesa/main/format_utils.c
>> @@ -55,6 +55,111 @@ _mesa_srgb_ubyte_to_linear_float(uint8_t cl)
>> return lut[cl];
>> }
>>
>> +static const uint8_t map_identity[7] = { 0, 1, 2, 3, 4, 5, 6 };
>> +static const uint8_t map_3210[7] = { 3, 2, 1, 0, 4, 5, 6 };
>> +static const uint8_t map_1032[7] = { 1, 0, 3, 2, 4, 5, 6 };
>> +
>> +/**
>> + * Describes a format as an array format, if possible
>> + *
>> + * A helper function for figuring out if a (possibly packed) format is
>> + * actually an array format and, if so, what the array parameters are.
>> + *
>> + * \param[in] format the mesa format
>> + * \param[out] type the GL type of the array (GL_BYTE, etc.)
>> + * \param[out] num_components the number of components in the array
>> + * \param[out] swizzlea swizzle describing how to get from the
>> + *given format to RGBA
>> + * \param[out] normalized for integer formats, this represents
>> whether
>> + *the format is a normalized integer or a
>> + *regular integer
>> + * \return true if this format is an array format, false otherwise
>> + */
>> +bool
>> +_mesa_format_to_array(mesa_format format, GLenum *type, int
>> *num_components,
>> + uint8_t swizzle[4], bool *normalized)
>> +{
>> + int i;
>> + GLuint format_components;
>> + uint8_t packed_swizzle[4];
>> + const uint8_t *endian;
>> +
>> + if (_mesa_is_format_compressed(format))
>> + return false;
>> +
>> + *normalized = !_mesa_is_format_integer(format);
>> +
>> + _mesa_format_to_type_and_comps(format, type, &format_components);
>> +
>> + switch (_mesa_get_format_layout(format)) {
>> + case MESA_FORMAT_LAYOUT_ARRAY:
>> + *num_components = format_components;
>> + _mesa_get_format_swizzle(format, swizzle);
>> + return true;
>> + case MESA_FORMAT_LAYOUT_PACKED:
>> + switch (*type) {
>> + case GL_UNSIGNED_BYTE:
>> + case GL_BYTE:
>> + if (_mesa_get_format_max_bits(format) != 8)
>> +return false;
>> + *num_components = _mesa_get_format_bytes(format);
>> + switch (*num_components) {
>> + case 1:
>> +endian = map_identity;
>> +break;
>> + case 2:
>> +endian = _mesa_little_endian() ? map_identity : map_1032;
>> +break;
>> + case 4:
>> +endian = _mesa_little_endian() ? map_identity : map_3210;
>> +break;
>> + default:
>> +assert(!"Invalid number of components");
>>
>
> I think MSVC (and maybe optimized gcc) will complain than 'endian' is not
> initialized for all cases. It would probably be best to initialize endian
> to point to map_identity[] in the declaration. If the "impossible" happens
> and the default case is hit in release build, we should try to not crash.
>
>
>
Thanks Brian, fixed. I also fixed it for the GL_SHORT case below too.
--Jason
>
>
> + }
>> + break;
>> + case GL_UNSIGNED_SHORT:
>> + case GL_SHORT:
>> + case GL_HALF_FLOAT:
>> + if (_mesa_get_format_max_bits(format) != 16)
>> +return false;
>> + *num_components = _mesa_get_format_bytes(format) / 2;
>> + switch (*num_components) {
>> + case 1:
>> +endian = map_identity;
>> +break;
>> + case 2:
>> +endian = _mesa_little_endian() ? map_identity : map_1032;
>> +break;
>> + default:
>> +assert(!"Invalid number of components");
>> + }
>> + break;
>> + case GL_UNSIGNED_INT:
>> + case GL_INT:
>> + case GL_FLOAT:
>> + /* This isn't packed. At least not really. */
>> + assert(format_components == 1);
>> + if (_mesa_get_format_max_bits(format) != 32)
>> +return false;
>> + *num_components = format_components;
>> + endian = map_identity;
>> + break;
>> + default:
>> + return false;
>> + }
>> +
>> + _mesa_get_format_swizzle(format, packed_swizzle);
>> +
>> + for (i = 0; i < 4; ++i)
>> + swizzle[i] = endia
Re: [Mesa-dev] [PATCH v2 3/4] ra: consider all spillable nodes for spilling
On Mon, Aug 4, 2014 at 10:42 AM, Connor Abbott wrote: > On Mon, Aug 4, 2014 at 10:17 AM, Eric Anholt wrote: >> Connor Abbott writes: >> >>> On Mon, Aug 4, 2014 at 9:46 AM, Eric Anholt wrote: Connor Abbott writes: > On Fri, Aug 1, 2014 at 12:25 PM, Eric Anholt wrote: >> Connor Abbott writes: >> >>> On Fri, Aug 1, 2014 at 11:51 AM, Eric Anholt wrote: Connor Abbott writes: > On Thu, Jul 31, 2014 at 1:05 PM, Eric Anholt wrote: >> Connor Abbott writes: >>> That's not necessarily true - you could want to spill a trivially >>> colored register that interferes with a non trivially colored >>> register, especially if the spill cost of the non trivially colored >>> register is higher than that of the trivially colored register >>> because >>> e.g. the non trivially colored register is used in a loop. >>> Especially, >>> I ran into trouble with the varying packing tests in piglit which >>> after a few rounds of spilling looked something like: >> >> If it's trivially colorable, then when you're trying to get a >> non-conflicting color for a difficult neighbor (an >> optimistic-coloring >> one near the top of the stack that's triggering the need for >> spilling), >> it's out consideration because it's deeper in the stack. > > Right... so in that case, can't we just ignore everything on the stack > below the node that couldn't be colored in ra_select()? Yep, that's what the code's doing currently. >>> >>> No, it's also considering other optimistically colored nodes below the >>> one that failed on the stack... see patch 3 in v3 of my series, which >>> changes the code to actually do that. >> >> Oh, I misread you as saying s/couldn't be colored/first couldn't be >> trivially colored/. It seems like obviously the behavior we want, to >> me. > > Cool, then can you put your r-b on the last two patches of the v3 > series so we can push it? Not really -- I'm saying that we *do* want to consider the other optimistically colored nodes. Those ones lower in the stack might actually be useful to spill, since if spilled they could potentially make other values trivially colorable, which would change the order of pushes and might make our node colorable. >>> >>> Well, you could apply that same argument to *any* spillable node in >>> the graph, which brings us right back to where we started. I think >>> what we have now is a rather arbitrary compromise between "consider >>> everything for spilling because it might make other things trivially >>> colorable" and "only spill the things we know are likely to help." I >>> still think we should go with the former, since it produces numbers >>> equivalent to what we have right now instead of slightly worse >>> numbers. And besides, as I noted in the commit message, considering >>> those nodes doesn't seem to be useful in practice since we get the >>> exact same code anyways - even with reducing the number of registers >>> to make more things spill. >> >> I don't believe that's true. The argument before was about >> trivially-colorable things -- things that always appear in the stack >> before the optimistic things. They can't have an effect on the things >> higher in the stack, becuase they're already in the stack and you know >> you can color them regardless of choices higher in the stack, so you >> don't have to spill them ever. >> >> For your optimistic nodes, though, even though you've put them in the >> stack, you want to consider them for spilling because even once you >> resolve the spills and manage to color things high in the stack (in your >> scheme), you may have to spill that lower-down optimistic node anyway. >> So you failed to consider an important node for spilling, that might >> have also resolved your higher-in-the-stack troubles, and got extra >> spilling as a result. > > How, exactly, could spilling in this case ever resolve the > "higher-in-the-stack troubles"? Say we have an optimistically colored > node A, that is lower on the stack than the optimistically colored > node B that is currently failing to be colored. There are two effects > of spilling A: > > 1) Some of the nodes that we split A into may become trivially > colorable, which will push them down on the stack - but this is all > happening below B on the stack anyways, so it doesn't make any > difference for now. > > 2) Some of the nodes that were interfering with A may no longer > interfere with any of the nodes we split A into - but again, we only > care about B or nodes above B on the stack, so we don't count that > interference anyways, and therefore we still haven't gained anything. > > So although spilling A may help in the future, I still fail to see how > it could help now - we st
Re: [Mesa-dev] [PATCH v2 08/13] mesa/format_utils: Add a general format conversion function
On Mon, Aug 4, 2014 at 7:55 AM, Brian Paul wrote: > On 08/02/2014 02:11 PM, Jason Ekstrand wrote: > >> Most format conversion operations required by GL can be performed by >> converting one channel at a time, shuffling the channels around, and >> optionally filling missing channels with zeros and ones. This adds a >> function to do just that in a general, yet efficient, way. >> >> v2: >> * Add better comments including full docs for functions >> * Don't use __typeof__ >> * Use inline helpers instead of writing out conversions by hand, >> * Force full loop unrolling for better performance >> >> Signed-off-by: Jason Ekstrand >> --- >> src/mesa/main/format_utils.c | 844 ++ >> + >> src/mesa/main/format_utils.h | 5 + >> 2 files changed, 849 insertions(+) >> >> diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c >> index 241c158..d60aeb3 100644 >> --- a/src/mesa/main/format_utils.c >> +++ b/src/mesa/main/format_utils.c >> @@ -54,3 +54,847 @@ _mesa_srgb_ubyte_to_linear_float(uint8_t cl) >> >> return lut[cl]; >> } >> + >> +/* A bunch of format conversion macros and helper functions used below */ >> + >> +/* Only guaranteed to work for BITS <= 32 */ >> +#define MAX_UINT(BITS) ((BITS) == 32 ? UINT32_MAX : ((1u << (BITS)) - 1)) >> +#define MAX_INT(BITS) (int)MAX_UINT((BITS) - 1) >> > > I'd probably put one more set of parens around the whole macro body, just > to be safe. > Yup, fixed. --Jason > > -Brian > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] clover: add clCompileProgram
On Aug 4, 2014, at 8:03 AM, EdB wrote: > Hello > > I'm done with the clCompile part of OpenCL 1.2. > > As you can see I use char* data to transfert data from core to llvm. > > At first I was thinking of using std class but we need to be binary safe > when data are transfert beetween c++98/c++11 compiled code. > > Then I try to use compat class, but it add unexpected behavior. > It's looks like they are acting like std, but they don't. > For exemple vector.reserve is actually making the vector size grown, > not like std::vector. Also std::string.c_str is always null terminated. > compat::string is not. I’ve run into many memory corruption problems with the compat:: stuff that is fixed by replacing it all with the std::versions. The compat version differences, while still looking similar is also pretty bad. Can we just get rid of compat? > > At the end I decide to use const char* as it also avoid some memory copy, > but I can rewrite the patch if it's needed. > And I think compat need to be fixed. > > EdB (2): > clover: std::pair is not c++98/c++11 safe > clover: add clCompileProgram > > src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +- > src/gallium/state_trackers/clover/api/program.cpp | 41 -- > .../state_trackers/clover/core/compiler.hpp| 11 +++--- > src/gallium/state_trackers/clover/core/program.cpp | 14 ++-- > src/gallium/state_trackers/clover/core/program.hpp | 5 ++- > .../state_trackers/clover/llvm/invocation.cpp | 33 + > src/gallium/state_trackers/clover/util/compat.hpp | 6 > 7 files changed, 95 insertions(+), 17 deletions(-) > > -- > 2.0.4 > > ___ > 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] [PATCH 00/11] i965: Rework sampler index handling in LIR
This series looks good to me: Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] targets/vdpau: link with libmesautil.la to fix build breakage
--- src/gallium/targets/vdpau/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/targets/vdpau/Makefile.am b/src/gallium/targets/vdpau/Makefile.am index 8c1e1f6..6c92cd8 100644 --- a/src/gallium/targets/vdpau/Makefile.am +++ b/src/gallium/targets/vdpau/Makefile.am @@ -27,6 +27,7 @@ endif # HAVE_LD_VERSION_SCRIPT libvdpau_gallium_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/vdpau/libvdpautracker.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(VDPAU_LIBS) \ $(LIBDRM_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) -- 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] xlib: fix missing mesautil build breakage
Fixes the non-DRI build. --- src/mesa/drivers/x11/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/drivers/x11/Makefile.am b/src/mesa/drivers/x11/Makefile.am index 7a35132..40b01dd 100644 --- a/src/mesa/drivers/x11/Makefile.am +++ b/src/mesa/drivers/x11/Makefile.am @@ -27,6 +27,7 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa \ + -I$(top_srcdir)/src \ -I$(top_srcdir)/src/mesa/main \ $(X11_INCLUDES) \ $(DEFINES) -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] loader: silence declarations after code warning
Remove the semicolon from the macro. All the instances of the macro end with a semicolon already. --- src/loader/loader.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/loader/loader.c b/src/loader/loader.c index 47e1f58..b159c51 100644 --- a/src/loader/loader.c +++ b/src/loader/loader.c @@ -146,7 +146,7 @@ checked_dlsym(void *dlopen_handle, const char *name) } #define UDEV_SYMBOL(ret, name, args) \ - ret (*name) args = checked_dlsym(udev_dlopen_handle(), #name); + ret (*name) args = checked_dlsym(udev_dlopen_handle(), #name) static inline struct udev_device * -- 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] winsys/sw/dri: silence void pointer arithmetic warning
---
src/gallium/winsys/sw/dri/dri_sw_winsys.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
index 6fed22b..24d6308 100644
--- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
@@ -185,7 +185,8 @@ dri_sw_displaytarget_display(struct sw_winsys *ws,
if (box) {
void *data;
- data = dri_sw_dt->data + (dri_sw_dt->stride * box->y) + box->x * blsize;
+ data = (char *) dri_sw_dt->data
+ + (dri_sw_dt->stride * box->y) + box->x * blsize;
dri_sw_ws->lf->put_image2(dri_drawable, data,
box->x, box->y, box->width, box->height,
dri_sw_dt->stride);
} else {
--
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/2] xlib: fix missing mesautil build breakage
Both patches: Reviewed-by: Jason Ekstrand On Mon, Aug 4, 2014 at 12:09 PM, Brian Paul wrote: > Fixes the non-DRI build. > --- > src/mesa/drivers/x11/Makefile.am |1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/mesa/drivers/x11/Makefile.am > b/src/mesa/drivers/x11/Makefile.am > index 7a35132..40b01dd 100644 > --- a/src/mesa/drivers/x11/Makefile.am > +++ b/src/mesa/drivers/x11/Makefile.am > @@ -27,6 +27,7 @@ AM_CPPFLAGS = \ > -I$(top_srcdir)/include \ > -I$(top_srcdir)/src/mapi \ > -I$(top_srcdir)/src/mesa \ > + -I$(top_srcdir)/src \ > -I$(top_srcdir)/src/mesa/main \ > $(X11_INCLUDES) \ > $(DEFINES) > -- > 1.7.10.4 > > ___ > 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 1/4] i965/guardband: Improve comments for guardband clipping
While working in this part of the code I had a great deal of trouble understanding what it was trying to do, and matching it with the spec. (mostly due bad wording in the PRM). To help future people, I've cleaned up the wording and provided some ascii art. --- src/mesa/drivers/dri/i965/gen8_viewport_state.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c b/src/mesa/drivers/dri/i965/gen8_viewport_state.c index b366246..b5171e0 100644 --- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c +++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c @@ -71,10 +71,24 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw) * maximum screen space coordinates of a small object may larger, but we * have no way to enforce the object size other than through clipping. * - * If you're surprised that we set clip to -gbx to +gbx and it seems like - * we'll end up with 16384 wide, note that for a 8192-wide render target, - * we'll end up with a normal (-1, 1) clip volume that just covers the - * drawable. + * The goal is to create the maximum sized guardband (8K x 8K) with the + * viewport rectangle in the center of the guardband. This looks weird + * because the hardware wants coordinates that are scaled to the viewport + * in NDC. In other words, an 8K x 8K viewport would have [-1,1] for X and Y. + * A 4K viewport would be [-2,2], 2K := [-4,4] etc. + * + * + * |Guardband | + * | | + * | | + * | |viewport | | + * | | | | + * | | | | + * | |__| | + * | | + * | | + * |__| + * */ const float maximum_guardband_extent = 8192; float gbx = maximum_guardband_extent / ctx->ViewportArray[i].Width; -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] i965/clip: Removing scissor atom
On GEN8, a change in scissor state does not effect anything for the
clipper/sf hardware state. The hardware will always do the right thing
once the viewport extents are programmed. We can therefore remove the
unecessary state emission.
Ken originally spotted this.
---
src/mesa/drivers/dri/i965/gen8_viewport_state.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
index 04a4530..d7e06c4 100644
--- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
@@ -100,13 +100,17 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
vp[10] = -gby; /* y-min */
vp[11] = gby; /* y-max */
- /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport
+ /* _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport
* The hardware will take the intersection of the drawing rectangle,
* scissor rectangle, and the viewport extents. We don't need to be
* smart, and can therefore just program the viewport extents.
*/
float viewport_Xmax = ctx->ViewportArray[i].X +
ctx->ViewportArray[i].Width;
float viewport_Ymax = ctx->ViewportArray[i].Y +
ctx->ViewportArray[i].Height;
+ if (viewport_Ymax < ctx->DrawBuffer->_Ymax ||
+viewport_Xmax < ctx->DrawBuffer->_Xmax) {
+perf_debug("Using viewport extents for savings\n");
+ }
if (render_to_fbo) {
vp[12] = ctx->ViewportArray[i].X;
vp[13] = viewport_Xmax - 1;
@@ -130,7 +134,7 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
const struct brw_tracked_state gen8_sf_clip_viewport = {
.dirty = {
- .mesa = _NEW_BUFFERS | _NEW_SCISSOR | _NEW_VIEWPORT,
+ .mesa = _NEW_BUFFERS | _NEW_VIEWPORT,
.brw = BRW_NEW_BATCH,
.cache = 0,
},
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965/guardband: Enable for all viewport dimensions (GEN8+)
The goal of guardband clipping is to try to avoid 3d clipping because it
is an expensive operation. When guardband clipping is disabled, all
geometry that intersects the viewport is to the FF 3d clipper. Objects
which are entirely enclosed within the viewport are said to be
"trivially accepted" while those entirely outside of the viewport are,
"trivially rejected".
When guardband clipping is turned on the above behavior is change such
that if the geometry is within the guardband, and intersects the
viewport, it skips the 3d clipper. Prior to GEN8, this was problematic
if the viewport was smaller than the screen as it could allow for
rendering to occur outside of the viewport. That could be mitigated if
the programmer specified a scissor region which was less than or equal
to the viewport - but this is not required for correctness in OpenGL. In
theory you could be clever with the guardband so as not to invoke this
problem. We do not do this, and have no data that suggests we should
bother (nor the converse data).
With viewport extents in place on GEN8, it should be safe to turn on
guardband clipping for all cases
While here, add a comment to the code which confused me thoroughly.
---
src/mesa/drivers/dri/i965/gen6_clip_state.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index 52027e0..42e78a1 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -97,17 +97,26 @@ upload_clip_state(struct brw_context *brw)
GEN6_USER_CLIP_CLIP_DISTANCES_SHIFT);
dw2 |= GEN6_CLIP_GB_TEST;
- for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
- if (ctx->ViewportArray[i].X != 0 ||
- ctx->ViewportArray[i].Y != 0 ||
- ctx->ViewportArray[i].Width != (float) fb->Width ||
- ctx->ViewportArray[i].Height != (float) fb->Height) {
- dw2 &= ~GEN6_CLIP_GB_TEST;
- if (brw->gen >= 8) {
-perf_debug("Disabling GB clipping due to lack of Gen8 viewport "
- "clipping setup code. This should be fixed.\n");
+ /* If the viewport dimensions < screen dimensions we have to disable
+* guardband clipping. This is because as the code works today, the
+* guardband rectangle is set to a fixed size. If that size is larger than
+* the viewport (likely) Guardband clipping can potentially make geometry
+* bypass the 3d clipping phase (geometry which intersects the viewport).
+* This will possibly cause rendering to occur outside of the viewport, but
+* inside the screen.
+*
+* On GEN8 we get a useful viewport extents test which allows us to
+* ignore this entirely.
+*/
+ if (brw->gen < 8) {
+ for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
+ if (ctx->ViewportArray[i].X != 0 ||
+ ctx->ViewportArray[i].Y != 0 ||
+ ctx->ViewportArray[i].Width != (float) fb->Width ||
+ ctx->ViewportArray[i].Height != (float) fb->Height) {
+dw2 &= ~GEN6_CLIP_GB_TEST;
+break;
}
- break;
}
}
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] BDW viewport extents + misc
The patch commit messages and comments within the diffs explain the intricacies of viewport extents and clipping. So rather, here is the data for these patches. All of the following is for a Broadwell system (which introduced viewport extents). EGYPT PERF == No change WARSOW PERF === No change piglit == viewport extents only: spec/ARB_viewport_array/render-scissor/Render multi-viewport scissor test: fail pass spec/glsl-1.30/execution/built-in-functions/vs-max-ivec4-int: fail pass spec/ARB_viewport_array/render-scissor/Render multi-scissor rectangles: fail pass spec/glsl-1.50/execution/geometry/max-input-components: fail pass viewport extents + gb clipping: spec/ARB_viewport_array/render-scissor/Render multi-viewport scissor test: fail pass spec/glsl-1.30/execution/built-in-functions/vs-max-ivec4-int: fail pass spec/ARB_viewport_array/render-scissor/Render multi-scissor rectangles: fail pass all: spec/ARB_viewport_array/render-scissor/Render multi-viewport scissor test: fail pass spec/glsl-1.30/execution/built-in-functions/vs-max-ivec4-int: fail pass spec/ARB_viewport_array/render-scissor/Render multi-scissor rectangles: fail pass As you can observe, there are no wins found here other than conformance. Given our understanding of the hardware, we expect these patches to produce a performance improvements for certain applications (specifically those which define viewports smaller than the drawing rectangle, but some other caveats apply on top of that). Ben Widawsky (4): i965/guardband: Improve comments for guardband clipping i965: Viewport extents on GEN8 i965/guardband: Enable for all viewport dimensions (GEN8+) i965/clip: Removing scissor atom src/mesa/drivers/dri/i965/gen6_clip_state.c | 29 +- src/mesa/drivers/dri/i965/gen8_viewport_state.c | 52 ++--- 2 files changed, 57 insertions(+), 24 deletions(-) -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] i965: Viewport extents on GEN8
Viewport extents are a 3rd rectangle that defines which pixels get
discarded as part of the rasterization process. This can potentially
improve performance by reducing cache usage, and freeing up PS cycles.
It also permits the use of guardband clipping in all cases (see later
patch). The actual pixels drawn to the screen are an intersection of the
drawing rectangle, the viewport extents, and the scissor rectangle.
Scissor rectangle is not super important this discussion as it should
always help do the right thing provided the programmer uses it.
switch (viewport dimensions, drawrect dimension) {
case viewport > drawing rectangle: no effects; break;
case viewport == drawing rectangle: no effects; break;
case viewport < drawing rectangle:
Pixels (after the viewport transformation but before expensive
rastersizing and shading operations) which are outside of the
viewport are discarded.
}
I am unable to find a test case where this improves performance, but in
all my testing it doesn't hurt performance, and intuitively, it should
not ever hurt performance. It also permits us to use the guardband more
freely (see upcoming patch).
v2: Updating commit message.
---
src/mesa/drivers/dri/i965/gen8_viewport_state.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
index b5171e0..04a4530 100644
--- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
@@ -100,17 +100,23 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
vp[10] = -gby; /* y-min */
vp[11] = gby; /* y-max */
- /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport */
+ /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport
+ * The hardware will take the intersection of the drawing rectangle,
+ * scissor rectangle, and the viewport extents. We don't need to be
+ * smart, and can therefore just program the viewport extents.
+ */
+ float viewport_Xmax = ctx->ViewportArray[i].X +
ctx->ViewportArray[i].Width;
+ float viewport_Ymax = ctx->ViewportArray[i].Y +
ctx->ViewportArray[i].Height;
if (render_to_fbo) {
- vp[12] = ctx->DrawBuffer->_Xmin;
- vp[13] = ctx->DrawBuffer->_Xmax - 1;
- vp[14] = ctx->DrawBuffer->_Ymin;
- vp[15] = ctx->DrawBuffer->_Ymax - 1;
+ vp[12] = ctx->ViewportArray[i].X;
+ vp[13] = viewport_Xmax - 1;
+ vp[14] = ctx->ViewportArray[i].Y;
+ vp[15] = viewport_Ymax - 1;
} else {
- vp[12] = ctx->DrawBuffer->_Xmin;
- vp[13] = ctx->DrawBuffer->_Xmax - 1;
- vp[14] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymax;
- vp[15] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymin - 1;
+ vp[12] = ctx->ViewportArray[i].X;
+ vp[13] = viewport_Xmax - 1;
+ vp[14] = ctx->DrawBuffer->Height - viewport_Ymax;
+ vp[15] = ctx->DrawBuffer->Height - ctx->ViewportArray[i].Y - 1;
}
vp += 16;
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/10] [RFC] Probably useless algebraic optimizations
thomashellan...@gmail.com writes: > From: Thomas Helland > > When writing that A || (A && B) patch some > days ago I also wrote some other patches > that have no impact on my collection of shaders. > (shader-db + Some TF2 and Portal-shaders). > No reduction in instruction count, and no > significant increase in compilation time. > > I decided to put them up here anyway, as > with your collection of shaders maybe YMMV. I'm definitely interested in seeing our optimizer gain features like this, even if we don't have samples of code triggering them in our database yet. What we have in shader-db from real-world apps is a subset of what our compiler will encounter -- it doesn't tend to cover code by novice shader developers, nor does it cover more-complex, more-code-generated code we expect to see in the future. If the patches are cleaned up to use spaces instead of tabs, and avoid trailing whitespace, patches 1-4, 7-8, and 10 are: Reviewed-by: Eric Anholt For the sub case, I'm going want to disable lower_sub_to_add_neg on my hardware, since I've got SUB but no negate modifier on operands. This makes the (A - neg(B)) patch interesting to me. However, since neg(A) - B -> neg(A+B) was questioned, and it would be no change for me as well, I think we should probably drop that half. The min/max patches I'm not that interested in -- I think that class of optimization would be better handled in an pass that can track various bounds that values might have over time, rather than being a special case in algebraic. pgpGRsZHkrClO.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] src/Makefile.am: Move gtest before util
Since the ralloc test in util/tests needs gtest, we need to make sure that the gtest subdir is loaded first. This fixes bug #82148. Signed-off-by: Jason Ekstrand --- src/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 2634c34..cede508 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -19,7 +19,7 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS # IN THE SOFTWARE. -SUBDIRS = util gtest mapi +SUBDIRS = gtest util mapi if NEED_OPENGL_COMMON SUBDIRS += glsl mesa -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: include c99_compat.h in hash_table.h to get 'inline' definition
--- src/util/hash_table.h |1 + 1 file changed, 1 insertion(+) diff --git a/src/util/hash_table.h b/src/util/hash_table.h index 9b67f05..d6b6ebf 100644 --- a/src/util/hash_table.h +++ b/src/util/hash_table.h @@ -31,6 +31,7 @@ #include #include #include +#include "c99_compat.h" #include "macros.h" #ifdef __cplusplus -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: Add libmesautil dependency to gdm and xa targets
Signed-off-by: Jason Ekstrand --- src/gallium/targets/gbm/Makefile.am | 1 + src/gallium/targets/xa/Makefile.am | 1 + 2 files changed, 2 insertions(+) diff --git a/src/gallium/targets/gbm/Makefile.am b/src/gallium/targets/gbm/Makefile.am index 2345ce3..a5f7070 100644 --- a/src/gallium/targets/gbm/Makefile.am +++ b/src/gallium/targets/gbm/Makefile.am @@ -34,6 +34,7 @@ gbm_gallium_drm_la_SOURCES = gbm_gallium_drm_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/gbm/libgbm.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(LIBDRM_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) diff --git a/src/gallium/targets/xa/Makefile.am b/src/gallium/targets/xa/Makefile.am index 73bf664..1a37b9a 100644 --- a/src/gallium/targets/xa/Makefile.am +++ b/src/gallium/targets/xa/Makefile.am @@ -36,6 +36,7 @@ libxatracker_la_SOURCES = libxatracker_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/xa/libxatracker.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(LIBDRM_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Add libmesautil dependency to gdm and xa targets
On 08/04/2014 01:35 PM, Jason Ekstrand wrote: Signed-off-by: Jason Ekstrand --- src/gallium/targets/gbm/Makefile.am | 1 + src/gallium/targets/xa/Makefile.am | 1 + 2 files changed, 2 insertions(+) diff --git a/src/gallium/targets/gbm/Makefile.am b/src/gallium/targets/gbm/Makefile.am index 2345ce3..a5f7070 100644 --- a/src/gallium/targets/gbm/Makefile.am +++ b/src/gallium/targets/gbm/Makefile.am @@ -34,6 +34,7 @@ gbm_gallium_drm_la_SOURCES = gbm_gallium_drm_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/gbm/libgbm.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(LIBDRM_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) diff --git a/src/gallium/targets/xa/Makefile.am b/src/gallium/targets/xa/Makefile.am index 73bf664..1a37b9a 100644 --- a/src/gallium/targets/xa/Makefile.am +++ b/src/gallium/targets/xa/Makefile.am @@ -36,6 +36,7 @@ libxatracker_la_SOURCES = libxatracker_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/xa/libxatracker.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(LIBDRM_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: include c99_compat.h in format_srgb.h to get 'inline' definition
--- src/util/format_srgb.h |1 + 1 file changed, 1 insertion(+) diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h index 17ba283..4a8d73f 100644 --- a/src/util/format_srgb.h +++ b/src/util/format_srgb.h @@ -39,6 +39,7 @@ #include #include +#include "c99_compat.h" extern const float util_format_srgb_8unorm_to_linear_float_table[256]; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: include c99_compat.h in hash_table.h to get 'inline' definition
Reviewed-by: Jason Ekstrand On Mon, Aug 4, 2014 at 12:35 PM, Brian Paul wrote: > --- > src/util/hash_table.h |1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/util/hash_table.h b/src/util/hash_table.h > index 9b67f05..d6b6ebf 100644 > --- a/src/util/hash_table.h > +++ b/src/util/hash_table.h > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include "c99_compat.h" > #include "macros.h" > > #ifdef __cplusplus > -- > 1.7.10.4 > > ___ > 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] [PATCH] util: include c99_compat.h in format_srgb.h to get 'inline' definition
Reviewed-by: Jason Ekstrand On Mon, Aug 4, 2014 at 12:38 PM, Brian Paul wrote: > --- > src/util/format_srgb.h |1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h > index 17ba283..4a8d73f 100644 > --- a/src/util/format_srgb.h > +++ b/src/util/format_srgb.h > @@ -39,6 +39,7 @@ > > #include > #include > +#include "c99_compat.h" > > extern const float > util_format_srgb_8unorm_to_linear_float_table[256]; > -- > 1.7.10.4 > > ___ > 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] [PATCH] meta: Remove dither bit from blit paths that do not need it
I'm not sure about either of these patches. It looks like according to the GL 4.4 spec dithering is not supposed to affect glBlitFramebuffer: “When values are written to the draw buffers, blit operations bypass most of the fragment pipeline. The only fragment operations which affect a blit are the pixel ownership test, the scissor test, and sRGB conversion (see section 17.3.9). Color, depth, and stencil masks (see section 17.4.2) are ignored.” I assume dithering is part of the ‘fragment operations’ because it is listed under the section ‘17.3 Per-Fragment Operations’ in the spec. In that case _mesa_meta_BlitFramebuffer should always act as if dithering is disabled. Therefore we had a bug before and after my patch. Before the patch dithering would be enabled or not depending on what the application set it to, which would usually be left as GL_TRUE. After the patch it is forced to GL_TRUE. It looks like the bug was hidden before my patch because the test suite explicitly disables dithering before running any tests. I think the right thing to do would be to make _mesa_meta_BlitFramebuffer use the MESA_META_DITHER state flag but then explicitly disable dithering. I think it would be weird if we didn't set dithering to TRUE when saving the state for MESA_META_DITHER because as far as I understand _mesa_meta_begin is expected to reset all of the selected state to the default values and the default for dithering is TRUE. - Neil "Pohjolainen, Topi" writes: > On Sun, Aug 03, 2014 at 06:32:54PM -0700, Kenneth Graunke wrote: >> On Friday, August 01, 2014 08:37:53 PM Topi Pohjolainen wrote: >> > Similarly to an older patch. This is the minimum needed to fix the >> > bug but there are other meta-paths remaining that have the bit >> > since its introduction but not before. >> >> Why not just drop the >> >>_mesa_set_enable(ctx, GL_DITHER, GL_TRUE); >> >> in _mesa_meta_begin(), which was introduced in commit >> 05b52efbc977311c96ba31ac5fa2c95fe525d85e? >> >> Neil's new glClearTexSubImage path only wants it to be saved/restored so he >> can /disable/ it. I see no reason to explicitly turn it /on/ for all >> paths... >> >> That should fix the bug. > > I'm fine with this. But just to mention, we discussed this a little when Neil > introduded the original logic. The spec for glEnable() says that by default > all the capabilities are disabled except GL_DITHER which is TRUE. To me it is > not entirely clear if meta paths should be using the default state or the > current. > >> >> > >> > commit e526ebf35c113d59eb0b860e492c1308d3862ee9 >> > Author: Kenneth Graunke >> > Date: Mon May 5 14:03:46 2014 -0700 >> > >> > meta: Add a new MESA_META_DRAW_BUFFERS bit. >> > >> > This will be used for saving/restoring the glDrawBuffers state. >> > For now, make sure that existing users of MESA_META_ALL don't get >> > the new bit, since they probably won't want it. >> > >> > Cc: "10.2" >> > Signed-off-by: Kenneth Graunke >> > Reviewed-by: Anuj Phogat >> > Reviewed-by: Eric Anholt >> >> Quoting this commit message is a bit confusing - usually, when people quote >> other commits, it's referring to a regression...and the regression was from >> 05b52efbc977311c96ba31ac5fa2c95fe525d85e. Masking off unnecessary >> save/restore bits is a pretty common thing to do. >> >> > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=81828. >> > >> > Signed-off-by: Topi Pohjolainen >> > CC: Neil Roberts >> > --- >> > src/mesa/drivers/common/meta.c | 3 ++- >> > src/mesa/drivers/common/meta_blit.c | 3 ++- >> > 2 files changed, 4 insertions(+), 2 deletions(-) >> > >> > diff --git a/src/mesa/drivers/common/meta.c >> > b/src/mesa/drivers/common/meta.c >> > index 604bc21..b4f26d0 100644 >> > --- a/src/mesa/drivers/common/meta.c >> > +++ b/src/mesa/drivers/common/meta.c >> > @@ -2798,7 +2798,8 @@ copytexsubimage_using_blit_framebuffer(struct >> > gl_context *ctx, GLuint dims, >> > >> > _mesa_unlock_texture(ctx, texObj); >> > >> > - _mesa_meta_begin(ctx, MESA_META_ALL & ~MESA_META_DRAW_BUFFERS); >> > + _mesa_meta_begin(ctx, MESA_META_ALL & ~(MESA_META_DRAW_BUFFERS | >> > + MESA_META_DITHER)); >> > >> > _mesa_GenFramebuffers(1, &fbo); >> > _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo); >> > diff --git a/src/mesa/drivers/common/meta_blit.c >> > b/src/mesa/drivers/common/meta_blit.c >> > index bbf0c3c..d150e8a 100644 >> > --- a/src/mesa/drivers/common/meta_blit.c >> > +++ b/src/mesa/drivers/common/meta_blit.c >> > @@ -707,7 +707,8 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx, >> > /* Only scissor affects blit, but we're doing to set a custom scissor >> > if >> > * necessary anyway, so save/clear state. >> > */ >> > - _mesa_meta_begin(ctx, MESA_META_ALL & ~MESA_META_DRAW_BUFFERS); >> > + _mesa_meta_begin(ctx, MESA_META_ALL & ~(MESA_META_DRAW_BUFFERS | >> > +
[Mesa-dev] meta: Disable dithering during glBlitFramebuffer
According to the GL spec the only fragment operations that should affect glBlitFramebuffer are “the pixel ownership test, the scissor test, and sRGB conversion”. That implies that dithering should not be performed so we need to disable it when implementing the blit with a render. Before commit 05b52efbc97731 the dithering state would be left as whatever the application picks (the default being GL_TRUE) and after that commit it was explicitly enabled. Neither of these were correct. https://bugs.freedesktop.org/show_bug.cgi?id=81828 --- src/mesa/drivers/common/meta_blit.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/common/meta_blit.c b/src/mesa/drivers/common/meta_blit.c index bbf0c3c..b28b9d0 100644 --- a/src/mesa/drivers/common/meta_blit.c +++ b/src/mesa/drivers/common/meta_blit.c @@ -709,6 +709,9 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx, */ _mesa_meta_begin(ctx, MESA_META_ALL & ~MESA_META_DRAW_BUFFERS); + /* Dithering shouldn't be performed for glBlitFramebuffer */ + _mesa_set_enable(ctx, GL_DITHER, GL_FALSE); + /* If the clipping earlier changed the destination rect at all, then * enable the scissor to clip to it. */ -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] src/Makefile.am: Move gtest before util
On 08/04/2014 01:27 PM, Jason Ekstrand wrote: Since the ralloc test in util/tests needs gtest, we need to make sure that the gtest subdir is loaded first. This fixes bug #82148. Signed-off-by: Jason Ekstrand --- src/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 2634c34..cede508 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -19,7 +19,7 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS # IN THE SOFTWARE. -SUBDIRS = util gtest mapi +SUBDIRS = gtest util mapi if NEED_OPENGL_COMMON SUBDIRS += glsl mesa I don't think I've run into this problem here, but LGTM. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] wmesa: link with mesautil
---
src/mesa/drivers/windows/gdi/SConscript |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/windows/gdi/SConscript
b/src/mesa/drivers/windows/gdi/SConscript
index 10a7eea..1f4d7e1 100644
--- a/src/mesa/drivers/windows/gdi/SConscript
+++ b/src/mesa/drivers/windows/gdi/SConscript
@@ -3,6 +3,7 @@ Import('*')
env = env.Clone()
env.Prepend(CPPPATH = [
+'#src',
'#src/mapi',
'#src/mesa',
])
@@ -16,6 +17,7 @@ if not env['gles']:
env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
env.Prepend(LIBS = [
+mesautil,
glapi,
mesa,
glsl,
--
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] targets:libgl-gdi: link with mesautil
---
src/gallium/targets/libgl-gdi/SConscript |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/targets/libgl-gdi/SConscript
b/src/gallium/targets/libgl-gdi/SConscript
index f8393da..594f34d 100644
--- a/src/gallium/targets/libgl-gdi/SConscript
+++ b/src/gallium/targets/libgl-gdi/SConscript
@@ -6,6 +6,7 @@ Import('*')
env = env.Clone()
env.Append(CPPPATH = [
+'#src',
'#src/gallium/state_trackers/wgl',
'#src/gallium/winsys/sw',
])
@@ -17,6 +18,8 @@ env.Append(LIBS = [
'ws2_32',
])
+env.Prepend(LIBS = [mesautil])
+
sources = ['libgl_gdi.c']
drivers = []
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] osmesa: link with mesautil
--- src/mesa/drivers/osmesa/SConscript |1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/drivers/osmesa/SConscript b/src/mesa/drivers/osmesa/SConscript index cbff594..caa14d3 100644 --- a/src/mesa/drivers/osmesa/SConscript +++ b/src/mesa/drivers/osmesa/SConscript @@ -10,6 +10,7 @@ env.Prepend(CPPPATH = [ ]) env.Prepend(LIBS = [ +mesautil, glapi, mesa, glsl, -- 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] targets/egl-static: link with libmesautil.la
--- src/gallium/targets/egl-static/Makefile.am |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/targets/egl-static/Makefile.am b/src/gallium/targets/egl-static/Makefile.am index 84f3338..ff053e2 100644 --- a/src/gallium/targets/egl-static/Makefile.am +++ b/src/gallium/targets/egl-static/Makefile.am @@ -64,6 +64,7 @@ egl_gallium_la_SOURCES = \ egl_gallium_la_LIBADD = \ $(top_builddir)/src/loader/libloader.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(top_builddir)/src/gallium/drivers/identity/libidentity.la \ $(top_builddir)/src/gallium/drivers/trace/libtrace.la \ $(top_builddir)/src/gallium/drivers/rbug/librbug.la \ @@ -108,7 +109,8 @@ AM_CPPFLAGS += \ -DFEATURE_GL=1 egl_gallium_la_LIBADD += \ - $(top_builddir)/src/mesa/libmesagallium.la + $(top_builddir)/src/mesa/libmesagallium.la \ + $(top_builddir)/src/util/libmesautil.la # make st/mesa built-in when there is a single glapi provider if HAVE_SHARED_GLAPI egl_gallium_la_LIBADD += \ @@ -127,6 +129,7 @@ st_GL_la_LDFLAGS = $(AM_LDFLAGS) # st_GL, built only when shared glapi is not enabled st_GL_la_LIBADD = \ $(top_builddir)/src/mesa/libmesagallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ $(top_builddir)/src/mapi/glapi/libglapi.la \ $(GALLIUM_COMMON_LIB_DEPS) -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] targets/graw-gdi: link with mesautil, not mesautils
--- src/gallium/targets/graw-gdi/SConscript |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/targets/graw-gdi/SConscript b/src/gallium/targets/graw-gdi/SConscript index dc7b7f1..f8db6e6 100644 --- a/src/gallium/targets/graw-gdi/SConscript +++ b/src/gallium/targets/graw-gdi/SConscript @@ -10,7 +10,7 @@ env.Append(CPPPATH = [ ]) env.Prepend(LIBS = [ -mesautils, +mesautil, gallium, 'gdi32', 'user32', -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] targets/egl-static: link with libmesautil.la
--- src/gallium/targets/egl-static/SConscript |1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/targets/egl-static/SConscript b/src/gallium/targets/egl-static/SConscript index 33db8e9..e423d5d 100644 --- a/src/gallium/targets/egl-static/SConscript +++ b/src/gallium/targets/egl-static/SConscript @@ -32,6 +32,7 @@ env.Prepend(LIBS = [ trace, galahad, libloader, +mesautil, gallium, egl, st_egl, -- 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] targets/egl-static: link with libmesautil.la
On 04/08/14 21:16, Brian Paul wrote: > --- > src/gallium/targets/egl-static/Makefile.am |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/targets/egl-static/Makefile.am > b/src/gallium/targets/egl-static/Makefile.am > index 84f3338..ff053e2 100644 > --- a/src/gallium/targets/egl-static/Makefile.am > +++ b/src/gallium/targets/egl-static/Makefile.am > @@ -64,6 +64,7 @@ egl_gallium_la_SOURCES = \ > egl_gallium_la_LIBADD = \ > $(top_builddir)/src/loader/libloader.la \ > $(top_builddir)/src/gallium/auxiliary/libgallium.la \ > + $(top_builddir)/src/util/libmesautil.la \ > $(top_builddir)/src/gallium/drivers/identity/libidentity.la \ > $(top_builddir)/src/gallium/drivers/trace/libtrace.la \ > $(top_builddir)/src/gallium/drivers/rbug/librbug.la \ > @@ -108,7 +109,8 @@ AM_CPPFLAGS += \ > -DFEATURE_GL=1 > > egl_gallium_la_LIBADD += \ > - $(top_builddir)/src/mesa/libmesagallium.la > + $(top_builddir)/src/mesa/libmesagallium.la \ > + $(top_builddir)/src/util/libmesautil.la Guessing that this will cause duplicate symbols and the build will fail ? -Emil > # make st/mesa built-in when there is a single glapi provider > if HAVE_SHARED_GLAPI > egl_gallium_la_LIBADD += \ > @@ -127,6 +129,7 @@ st_GL_la_LDFLAGS = $(AM_LDFLAGS) > # st_GL, built only when shared glapi is not enabled > st_GL_la_LIBADD = \ > $(top_builddir)/src/mesa/libmesagallium.la \ > + $(top_builddir)/src/util/libmesautil.la \ > $(top_builddir)/src/gallium/auxiliary/libgallium.la \ > $(top_builddir)/src/mapi/glapi/libglapi.la \ > $(GALLIUM_COMMON_LIB_DEPS) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/x86: put code in braces to silence declarations after code warning
---
src/mesa/x86/common_x86.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/mesa/x86/common_x86.c b/src/mesa/x86/common_x86.c
index b401c35..2a936a4 100644
--- a/src/mesa/x86/common_x86.c
+++ b/src/mesa/x86/common_x86.c
@@ -343,16 +343,18 @@ _mesa_get_x86_features(void)
#endif
#elif defined(USE_X86_64_ASM)
- unsigned int uninitialized_var(eax), uninitialized_var(ebx),
-uninitialized_var(ecx), uninitialized_var(edx);
+ {
+ unsigned int uninitialized_var(eax), uninitialized_var(ebx),
+ uninitialized_var(ecx), uninitialized_var(edx);
- /* Always available on x86-64. */
- _mesa_x86_cpu_features |= X86_FEATURE_XMM | X86_FEATURE_XMM2;
+ /* Always available on x86-64. */
+ _mesa_x86_cpu_features |= X86_FEATURE_XMM | X86_FEATURE_XMM2;
- __get_cpuid(1, &eax, &ebx, &ecx, &edx);
+ __get_cpuid(1, &eax, &ebx, &ecx, &edx);
- if (ecx & bit_SSE4_1)
- _mesa_x86_cpu_features |= X86_FEATURE_SSE4_1;
+ if (ecx & bit_SSE4_1)
+ _mesa_x86_cpu_features |= X86_FEATURE_SSE4_1;
+ }
#endif /* USE_X86_64_ASM */
(void) detection_debug;
--
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] egl: Fix OpenGL ES version checks in _eglParseContextAttribList()
On Fri, Aug 1, 2014 at 4:12 PM, Ian Romanick wrote: > On 06/18/2014 05:49 PM, Anuj Phogat wrote: >> Fixes gles3 Khronos CTS test: >> egl_create_context.egl_create_context >> >> Cc: >> Signed-off-by: Anuj Phogat >> --- >> src/egl/main/eglcontext.c | 11 --- >> 1 file changed, 8 insertions(+), 3 deletions(-) >> >> diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c >> index 70277ab..b8b30cb 100644 >> --- a/src/egl/main/eglcontext.c >> +++ b/src/egl/main/eglcontext.c >> @@ -322,10 +322,15 @@ _eglParseContextAttribList(_EGLContext *ctx, >> _EGLDisplay *dpy, >> break; >> >>case 3: >> - default: >> - /* Don't put additional version checks here. We don't know that >> - * there won't be versions > 3.0. >> + /* Update this condition if new OpenGL ES 3.x (x > 1) version is >> + * announced. >>*/ >> + if (ctx->ClientMinorVersion > 1) >> +err = EGL_BAD_MATCH; > > I dug around in our EGL code and in the test case a bit more. I think > if you delete the preceeding if-statement and add the following to the > commit message: > > We would generate EGL_BAD_CONFIG because _eglGetContextAPIBit > returns zero for the combination of EGL_OPENGL_ES_API and a major > version > 3. By just returning zero, the caller can't tell the > difference between a bad version (which should generate > EGL_BAD_MATCH) and a bad API (which should generate > EGL_BAD_CONFIG). This patch causes us to filter out major > versions > 3 at a point where we can generate the correct error. > > The patch will be > > Reviewed-by: Ian Romanick > > We could also fix this a couple other ways, but I think they're all more > intrusive and not worth the effort. > Fixed as you recommended. Thanks. >> + break; >> + >> + default: >> + err = EGL_BAD_MATCH; >> break; >>} >> } > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/x86: put code in braces to silence declarations after code warning
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] OpenGL ES improvements
Like Alex said. I don't plan to add gallium support if our hardware cannot do it. Marek On Mon, Aug 4, 2014 at 5:54 PM, Roland Scheidegger wrote: > Am 03.08.2014 14:40, schrieb Marek Olšák: >> Hi everyone, >> >> This series adds: >> - Support for ETC2 texture formats to all gallium drivers. This is a >> requirement for OpenGL ES 3.0, which can now be considered feature-complete >> as far as I know. Textures of such formats are loaded as plain R/RG/RGBA in >> st/mesa due to lack of hardware support. There is no real gallium support >> for the new formats. The i965 driver is doing the same thing. >> - Support for GL_ARB_ES3_compatibility, which requires ETC2 texture formats, >> for all gallium drivers that support GLSL 3.30. >> - Support for GL_OES_compressed_ETC1_RGB8_texture for all gallium drivers. >> This is also loaded as plain RGBA by st/Mesa. >> >> Please review. >> >> Marek > > The series looks ok to me though I think it would be good if real > etc1/etc2 support was added to gallium (well etc1 is already there). > There's quite plenty of hw with gallium supported drivers which can do > at least some of it: > - all adrenos 2xx/3xx can do etc1 unless I'm mistaken, and adreno 3xx > should be able to do etc2. > - some intel hw (baytrail/gen8) can do etc1/etc2. > - gk20a probably also could do etc1/etc2. > > I am actually sort of surprised some amd parts can't do it (kabini and > friends), are you sure they really can't? > > Roland > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] targets/egl-static: link with libmesautil.la
On 08/04/2014 02:21 PM, Emil Velikov wrote: On 04/08/14 21:16, Brian Paul wrote: --- src/gallium/targets/egl-static/Makefile.am |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/targets/egl-static/Makefile.am b/src/gallium/targets/egl-static/Makefile.am index 84f3338..ff053e2 100644 --- a/src/gallium/targets/egl-static/Makefile.am +++ b/src/gallium/targets/egl-static/Makefile.am @@ -64,6 +64,7 @@ egl_gallium_la_SOURCES = \ egl_gallium_la_LIBADD = \ $(top_builddir)/src/loader/libloader.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(top_builddir)/src/gallium/drivers/identity/libidentity.la \ $(top_builddir)/src/gallium/drivers/trace/libtrace.la \ $(top_builddir)/src/gallium/drivers/rbug/librbug.la \ @@ -108,7 +109,8 @@ AM_CPPFLAGS += \ -DFEATURE_GL=1 egl_gallium_la_LIBADD += \ - $(top_builddir)/src/mesa/libmesagallium.la + $(top_builddir)/src/mesa/libmesagallium.la \ + $(top_builddir)/src/util/libmesautil.la Guessing that this will cause duplicate symbols and the build will fail ? Yeah, I didn't mean to send this patch. Disregard. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] targets:libgl-gdi: link with mesautil
For some reason, I'm not seeing patch 2. 3, 4, 5, and 6 look fine to me. I
haven't tested them, but they seem consistent with what I did in other
places.
On Mon, Aug 4, 2014 at 1:16 PM, Brian Paul wrote:
> ---
> src/gallium/targets/libgl-gdi/SConscript |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/targets/libgl-gdi/SConscript
> b/src/gallium/targets/libgl-gdi/SConscript
> index f8393da..594f34d 100644
> --- a/src/gallium/targets/libgl-gdi/SConscript
> +++ b/src/gallium/targets/libgl-gdi/SConscript
> @@ -6,6 +6,7 @@ Import('*')
> env = env.Clone()
>
> env.Append(CPPPATH = [
> +'#src',
> '#src/gallium/state_trackers/wgl',
> '#src/gallium/winsys/sw',
> ])
> @@ -17,6 +18,8 @@ env.Append(LIBS = [
> 'ws2_32',
> ])
>
> +env.Prepend(LIBS = [mesautil])
> +
> sources = ['libgl_gdi.c']
> drivers = []
>
> --
> 1.7.10.4
>
> ___
> 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] targets/omx: automake: link against libmesautil.la
Or the build will fail due to unresolved symbols. Signed-off-by: Emil Velikov --- src/gallium/targets/omx/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/targets/omx/Makefile.am b/src/gallium/targets/omx/Makefile.am index 3840143..4045548 100644 --- a/src/gallium/targets/omx/Makefile.am +++ b/src/gallium/targets/omx/Makefile.am @@ -26,6 +26,7 @@ endif # HAVE_LD_VERSION_SCRIPT libomx_mesa_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/omx/libomxtracker.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(OMX_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] targets/xvmc: automake: link against libmesautil.la
Or the build will fail due to unresolved symbols. Signed-off-by: Emil Velikov --- src/gallium/targets/xvmc/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/targets/xvmc/Makefile.am b/src/gallium/targets/xvmc/Makefile.am index 329a1d4..884bccf 100644 --- a/src/gallium/targets/xvmc/Makefile.am +++ b/src/gallium/targets/xvmc/Makefile.am @@ -26,6 +26,7 @@ endif # HAVE_LD_VERSION_SCRIPT libXvMCgallium_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/xvmc/libxvmctracker.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(XVMC_LIBS) \ $(LIBDRM_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/13] i965/fs: make rescale_texcoord() more generic
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 ++-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 482b92f..21b7f23 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -370,7 +370,7 @@ public:
void emit_interpolation_setup_gen4();
void emit_interpolation_setup_gen6();
void compute_sample_position(fs_reg dst, fs_reg int_sample_pos);
- fs_reg rescale_texcoord(ir_texture *ir, fs_reg coordinate,
+ fs_reg rescale_texcoord(fs_reg coordinate, const glsl_type *coord_type,
bool is_rect, int sampler, int texunit);
fs_inst *emit_texture_gen4(ir_texture *ir, fs_reg dst, fs_reg coordinate,
fs_reg shadow_comp, fs_reg lod, fs_reg lod2);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
index 84e83b9..a8f0133 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
@@ -484,7 +484,7 @@ fs_visitor::emit_fragment_program_code()
if (fpi->TexShadow)
shadow_c = offset(coordinate, 2);
- coordinate = rescale_texcoord(ir, coordinate,
+ coordinate = rescale_texcoord(coordinate, coordinate_type,
fpi->TexSrcTarget == TEXTURE_RECT_INDEX,
fpi->TexSrcUnit, fpi->TexSrcUnit);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index adbdf42..876847d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1606,7 +1606,7 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
}
fs_reg
-fs_visitor::rescale_texcoord(ir_texture *ir, fs_reg coordinate,
+fs_visitor::rescale_texcoord(fs_reg coordinate, const glsl_type *coord_type,
bool is_rect, int sampler, int texunit)
{
fs_inst *inst = NULL;
@@ -1664,7 +1664,7 @@ fs_visitor::rescale_texcoord(ir_texture *ir, fs_reg
coordinate,
* tracking to get the scaling factor.
*/
if (brw->gen < 6 && is_rect) {
- fs_reg dst = fs_reg(this, ir->coordinate->type);
+ fs_reg dst = fs_reg(this, coord_type);
fs_reg src = coordinate;
coordinate = dst;
@@ -1704,9 +1704,9 @@ fs_visitor::rescale_texcoord(ir_texture *ir, fs_reg
coordinate,
}
}
- if (ir->coordinate && needs_gl_clamp) {
+ if (coord_type && needs_gl_clamp) {
for (unsigned int i = 0;
- i < MIN2(ir->coordinate->type->vector_elements, 3); i++) {
+ i < MIN2(coord_type->vector_elements, 3); i++) {
if (key->tex.gl_clamp_mask[i] & (1 << sampler)) {
fs_reg chan = coordinate;
chan.reg_offset += i;
@@ -1796,7 +1796,8 @@ fs_visitor::visit(ir_texture *ir)
if (ir->coordinate) {
ir->coordinate->accept(this);
- coordinate = rescale_texcoord(ir, this->result,
+ coordinate = rescale_texcoord(this->result,
+ir->coordinate ? ir->coordinate->type :
NULL,
ir->sampler->type->sampler_dimensionality
==
GLSL_SAMPLER_DIM_RECT,
sampler, texunit);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/13] i965/fs: don't use ir->shadow_comparitor in emit_texture_*
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 4 +---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 8
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
index 0c5daa7..80075dd6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
@@ -480,10 +480,8 @@ fs_visitor::emit_fragment_program_code()
ir_constant_data junk_data;
ir->coordinate = new(mem_ctx) ir_constant(coordinate_type,
&junk_data);
- if (fpi->TexShadow) {
+ if (fpi->TexShadow)
shadow_c = offset(coordinate, 2);
-ir->shadow_comparitor = new(mem_ctx) ir_constant(0.0f);
- }
coordinate = rescale_texcoord(ir, coordinate,
fpi->TexSrcTarget == TEXTURE_RECT_INDEX,
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 3b03eef..d25e9aa 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1105,7 +1105,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
/* g0 header. */
mlen = 1;
- if (ir->shadow_comparitor) {
+ if (shadow_c.file != BAD_FILE) {
for (int i = 0; i < ir->coordinate->type->vector_elements; i++) {
emit(MOV(fs_reg(MRF, base_mrf + mlen + i), coordinate));
coordinate.reg_offset++;
@@ -1302,7 +1302,7 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
}
mlen += vector_elements * reg_width;
- if (ir->shadow_comparitor) {
+ if (shadow_c.file != BAD_FILE) {
mlen = MAX2(mlen, header_present + 4 * reg_width);
emit(MOV(fs_reg(MRF, base_mrf + mlen), shadow_c));
@@ -1431,7 +1431,7 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
length++;
}
- if (ir->shadow_comparitor) {
+ if (shadow_c.file != BAD_FILE) {
emit(MOV(sources[length], shadow_c));
length++;
}
@@ -1526,7 +1526,7 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
break;
case ir_tg4:
if (has_nonconstant_offset) {
- if (ir->shadow_comparitor)
+ if (shadow_c.file != BAD_FILE)
no16("Gen7 does not support gather4_po_c in SIMD16 mode.");
/* More crazy intermixing */
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/13] i965/fs: make gather_channel() more generic
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index d3c2e5f..b0f26a5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -241,7 +241,7 @@ public:
void visit(ir_emit_vertex *);
void visit(ir_end_primitive *);
- uint32_t gather_channel(ir_texture *ir, int sampler);
+ uint32_t gather_channel(int orig_chan, int sampler);
void swizzle_result(ir_texture_opcode op, int dest_components,
fs_reg orig_val, int sampler);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 16afd28..8020470 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1957,10 +1957,9 @@ fs_visitor::emit_gen6_gather_wa(uint8_t wa, fs_reg dst)
* Set up the gather channel based on the swizzle, for gather4.
*/
uint32_t
-fs_visitor::gather_channel(ir_texture *ir, int sampler)
+fs_visitor::gather_channel(int orig_chan, int sampler)
{
- ir_constant *chan = ir->lod_info.component->as_constant();
- int swiz = GET_SWZ(key->tex.swizzles[sampler], chan->value.i[0]);
+ int swiz = GET_SWZ(key->tex.swizzles[sampler], orig_chan);
switch (swiz) {
case SWIZZLE_X: return 0;
case SWIZZLE_Y:
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/13] i965/fs: make swizzle_result() more generic
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs.h | 3 ++-
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 10 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index b86e65e..d3c2e5f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -242,7 +242,8 @@ public:
void visit(ir_end_primitive *);
uint32_t gather_channel(ir_texture *ir, int sampler);
- void swizzle_result(ir_texture *ir, fs_reg orig_val, int sampler);
+ void swizzle_result(ir_texture_opcode op, int dest_components,
+ fs_reg orig_val, int sampler);
fs_inst *emit(fs_inst *inst);
void emit(exec_list list);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
index 7048ed4..fb46a27 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
@@ -500,7 +500,7 @@ fs_visitor::emit_fragment_program_code()
inst->shadow_compare = fpi->TexShadow;
/* Reuse the GLSL swizzle_result() handler. */
- swizzle_result(ir, dst, fpi->TexSrcUnit);
+ swizzle_result(ir->op, 4, dst, fpi->TexSrcUnit);
dst = this->result;
break;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 3ac19c1..16afd28 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1982,9 +1982,10 @@ fs_visitor::gather_channel(ir_texture *ir, int sampler)
* EXT_texture_swizzle as well as DEPTH_TEXTURE_MODE for shadow comparisons.
*/
void
-fs_visitor::swizzle_result(ir_texture *ir, fs_reg orig_val, int sampler)
+fs_visitor::swizzle_result(ir_texture_opcode op, int dest_components,
+ fs_reg orig_val, int sampler)
{
- if (ir->op == ir_query_levels) {
+ if (op == ir_query_levels) {
/* # levels is in .w */
orig_val.reg_offset += 3;
this->result = orig_val;
@@ -1996,12 +1997,11 @@ fs_visitor::swizzle_result(ir_texture *ir, fs_reg
orig_val, int sampler)
/* txs,lod don't actually sample the texture, so swizzling the result
* makes no sense.
*/
- if (ir->op == ir_txs || ir->op == ir_lod || ir->op == ir_tg4)
+ if (op == ir_txs || op == ir_lod || op == ir_tg4)
return;
- if (ir->type == glsl_type::float_type) {
+ if (dest_components == 1) {
/* Ignore DEPTH_TEXTURE_MODE swizzling. */
- assert(ir->sampler->type->sampler_shadow);
} else if (key->tex.swizzles[sampler] != SWIZZLE_NOOP) {
fs_reg swizzled_result = fs_reg(this, glsl_type::vec4_type);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/13] i965: make brw_texture_offset() more generic
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 +++-
src/mesa/drivers/dri/i965/brw_shader.cpp | 13 +
src/mesa/drivers/dri/i965/brw_shader.h | 3 ++-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 +++-
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index d25e9aa..18cfb76 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1865,7 +1865,9 @@ fs_visitor::visit(ir_texture *ir)
}
if (ir->offset != NULL && ir->op != ir_txf)
- inst->texture_offset = brw_texture_offset(ctx,
ir->offset->as_constant());
+ inst->texture_offset =
+ brw_texture_offset(ctx, ir->offset->as_constant()->value.i,
+ir->offset->type->vector_elements);
if (ir->op == ir_tg4)
inst->texture_offset |= gather_channel(ir, sampler) << 16; // M0.2:16-17
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index f56ea68..09ecfff 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -364,18 +364,15 @@ brw_math_function(enum opcode op)
}
uint32_t
-brw_texture_offset(struct gl_context *ctx, ir_constant *offset)
+brw_texture_offset(struct gl_context *ctx, int *offsets,
+ unsigned num_components)
{
/* If the driver does not support GL_ARB_gpu_shader5, the offset
* must be constant.
*/
- assert(offset != NULL || ctx->Extensions.ARB_gpu_shader5);
+ assert(offsets != NULL || ctx->Extensions.ARB_gpu_shader5);
- if (!offset) return 0; /* nonconstant offset; caller will handle it. */
-
- signed char offsets[3];
- for (unsigned i = 0; i < offset->type->vector_elements; i++)
- offsets[i] = (signed char) offset->value.i[i];
+ if (!offsets) return 0; /* nonconstant offset; caller will handle it. */
/* Combine all three offsets into a single unsigned dword:
*
@@ -384,7 +381,7 @@ brw_texture_offset(struct gl_context *ctx, ir_constant
*offset)
*bits 3:0 - R Offset (Z component)
*/
unsigned offset_bits = 0;
- for (unsigned i = 0; i < offset->type->vector_elements; i++) {
+ for (unsigned i = 0; i < num_components; i++) {
const unsigned shift = 4 * (2 - i);
offset_bits |= (offsets[i] << shift) & (0xF << shift);
}
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index 5c48671..de901fa 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -177,7 +177,8 @@ public:
virtual void invalidate_live_intervals() = 0;
};
-uint32_t brw_texture_offset(struct gl_context *ctx, ir_constant *offset);
+uint32_t brw_texture_offset(struct gl_context *ctx, int *offsets,
+unsigned num_components);
#endif /* __cplusplus */
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index e16e93c..48297f6 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2443,7 +2443,9 @@ vec4_visitor::visit(ir_texture *ir)
}
if (ir->offset != NULL && ir->op != ir_txf)
- inst->texture_offset = brw_texture_offset(ctx,
ir->offset->as_constant());
+ inst->texture_offset =
+ brw_texture_offset(ctx, ir->offset->as_constant()->value.i,
+ir->offset->type->vector_elements);
/* Stuff the channel select bits in the top of the texture offset */
if (ir->op == ir_tg4)
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
