Re: [Mesa-dev] [PATCH] meta: Call glObjectLabel before linking.
Reviewed-by: Jordan Justen On Mon, Jun 30, 2014 at 5:55 PM, Kenneth Graunke wrote: > i965 precompiles shaders at link time, and prints a disassembly if > INTEL_DEBUG=vs,gs,fs, including the shader name. However, blit shaders > were showing up as "unnamed" since we hadn't set a name prior to > linking. > > Signed-off-by: Kenneth Graunke > --- > src/mesa/drivers/common/meta.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c > index 1a2e453..89d2d75 100644 > --- a/src/mesa/drivers/common/meta.c > +++ b/src/mesa/drivers/common/meta.c > @@ -217,6 +217,7 @@ _mesa_meta_compile_and_link_program(struct gl_context > *ctx, > fs_source); > > *program = _mesa_CreateProgram(); > + _mesa_ObjectLabel(GL_PROGRAM, *program, -1, name); > _mesa_AttachShader(*program, fs); > _mesa_DeleteShader(fs); > _mesa_AttachShader(*program, vs); > @@ -224,7 +225,6 @@ _mesa_meta_compile_and_link_program(struct gl_context > *ctx, > _mesa_BindAttribLocation(*program, 0, "position"); > _mesa_BindAttribLocation(*program, 1, "texcoords"); > _mesa_meta_link_program_with_debug(ctx, *program); > - _mesa_ObjectLabel(GL_PROGRAM, *program, -1, name); > > _mesa_UseProgram(*program); > } > -- > 2.0.0 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Use single dispatch mode as fallback to dual object mode when possible.
Currently, when a geometry shader can't use dual object mode we fall back to
dual instance mode, however, when invocations == 1, single dispatch mode is
more performant and equally efficient in terms of register pressure.
Single dispatch mode requires that the driver can handle interleaving of
registers, but this is already supported (dual instance mode has the same
requirement).
---
There is a comment in the code suggesting that SINGLE dispatch mode could not
be used because the visitor and generator classes did not support interleaving
of general purpose registers so we should fall back to DUAL_ISNTANCE
when DUAL_OBJECT could not be used. However DUAL_INSTANCE also requires
interleaving, so unless I am missing something this does not seem to make
a lot of sense.
Indeed, SINGLE dispatch mode seems to work just fine: I forced SINGLE dispatch
mode with a batch of standalone programs I have that use geometry shaders and
they work ok. I also did a complete piglit test run with this patch applied and
observed no regressions (all this on IvyBridge).
The comment also suggests that SINGLE dispatch mode would have even less
register pressure than DUAL_INSTANCE, but given that both require interleaving
I guess they wold be the same in this regard.
According to the documentation, SINGLE dispatch mode is preferred when
Invocations == 1 and DUAL_INSTANCE is preferred when Invocations > 1 to
optimize performance, so instead of always falling back to DUAL_INSTANCE mode
as we are doing now, or always falling back to SINGLE mode as the comment
suggested, I select between the two based on the Invocation count.
src/mesa/drivers/dri/i965/brw_context.h | 8 ---
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 26 +++
src/mesa/drivers/dri/i965/gen7_gs_state.c | 4 +---
src/mesa/drivers/dri/i965/gen8_gs_state.c | 4 +---
4 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index c68167f..4473f04 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -647,10 +647,12 @@ struct brw_gs_prog_data
int invocations;
/**
-* True if the thread should be dispatched in DUAL_INSTANCE mode, false if
-* it should be dispatched in DUAL_OBJECT mode.
+* Dispatch mode, can be any of:
+* GEN7_GS_DISPATCH_MODE_DUAL_OBJECT
+* GEN7_GS_DISPATCH_MODE_DUAL_INSTANCE
+* GEN7_GS_DISPATCH_MODE_SINGLE
*/
- bool dual_instanced_dispatch;
+ int dispatch_mode;
};
/** Number of texture sampler units */
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index b245924..8e4d805 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -102,10 +102,11 @@ vec4_gs_visitor::setup_payload()
{
int attribute_map[BRW_VARYING_SLOT_COUNT * MAX_GS_INPUT_VERTICES];
- /* If we are in dual instanced mode, then attributes are going to be
-* interleaved, so one register contains two attribute slots.
+ /* If we are in dual instanced or single mode, then attributes are going
+* to be interleaved, so one register contains two attribute slots.
*/
- int attributes_per_reg = c->prog_data.dual_instanced_dispatch ? 2 : 1;
+ int attributes_per_reg =
+ c->prog_data.dispatch_mode == GEN7_GS_DISPATCH_MODE_DUAL_OBJECT ? 1 : 2;
/* If a geometry shader tries to read from an input that wasn't written by
* the vertex shader, that produces undefined results, but it shouldn't
@@ -130,8 +131,7 @@ vec4_gs_visitor::setup_payload()
reg = setup_varying_inputs(reg, attribute_map, attributes_per_reg);
- lower_attributes_to_hw_regs(attribute_map,
- c->prog_data.dual_instanced_dispatch);
+ lower_attributes_to_hw_regs(attribute_map, attributes_per_reg > 1);
this->first_non_payload_grf = reg;
}
@@ -647,7 +647,7 @@ brw_gs_emit(struct brw_context *brw,
*/
if (c->prog_data.invocations <= 1 &&
likely(!(INTEL_DEBUG & DEBUG_NO_DUAL_OBJECT_GS))) {
- c->prog_data.dual_instanced_dispatch = false;
+ c->prog_data.dispatch_mode = GEN7_GS_DISPATCH_MODE_DUAL_OBJECT;
vec4_gs_visitor v(brw, c, prog, mem_ctx, true /* no_spills */);
if (v.run()) {
@@ -659,15 +659,15 @@ brw_gs_emit(struct brw_context *brw,
/* Either we failed to compile in DUAL_OBJECT mode (probably because it
* would have required spilling) or DUAL_OBJECT mode is disabled. So fall
-* back to DUAL_INSTANCED mode, which consumes fewer registers.
+* back to DUAL_INSTANCED or SINGLE mode, which consumes fewer registers.
*
-* FIXME: In an ideal world we'd fall back to SINGLE mode, which would
-* allow us to interleave general purpose registers (resulting in even less
-* likelihood of spilling). But at the moment, the vec4
Re: [Mesa-dev] [PATCH 2/4] gallium: add cap to show that fs can accept layer/viewport inputs
Sure though it seems a bit unfortunate if all the code is already there... Please also enable it for llvmpipe. Roland Am 30.06.2014 17:22, schrieb Ilia Mirkin: > Looks like it'll be a while before someone can look at my r600 patch > which makes layer/viewport available in the fragment shader. Roland, > would you be OK with a version of this patch which adds a new CAP for > viewport/layer support in FS? (To be enabled only on nv50/nvc0 for > now.) The cap can later be removed. > > On Sun, Jun 22, 2014 at 11:10 AM, Ilia Mirkin wrote: >> Signed-off-by: Ilia Mirkin >> --- >> src/gallium/docs/source/screen.rst | 2 ++ >> src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >> src/gallium/drivers/i915/i915_screen.c | 1 + >> src/gallium/drivers/ilo/ilo_screen.c | 1 + >> src/gallium/drivers/llvmpipe/lp_screen.c | 1 + >> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >> src/gallium/drivers/r300/r300_screen.c | 1 + >> src/gallium/drivers/r600/r600_pipe.c | 1 + >> src/gallium/drivers/radeonsi/si_pipe.c | 1 + >> src/gallium/drivers/softpipe/sp_screen.c | 1 + >> src/gallium/drivers/svga/svga_screen.c | 1 + >> src/gallium/include/pipe/p_defines.h | 3 ++- >> src/mesa/state_tracker/st_extensions.c | 1 + >> 15 files changed, 17 insertions(+), 1 deletion(-) >> >> diff --git a/src/gallium/docs/source/screen.rst >> b/src/gallium/docs/source/screen.rst >> index 1a80b04..ebebfe8 100644 >> --- a/src/gallium/docs/source/screen.rst >> +++ b/src/gallium/docs/source/screen.rst >> @@ -205,6 +205,8 @@ The integer capabilities: >> * ``PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION``: Whether >>TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION is supported, which disables >> clipping >>and viewport transformation. >> +* ``PIPE_CAP_TGSI_FS_LAYER_VIEWPORT``: Whether the fragment shader can >> accept >> + ``TGSI_SEMANTIC_LAYER`` and ``TGSI_SEMANTIC_VIEWPORT_INDEX`` inputs. >> >> >> .. _pipe_capf: >> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c >> b/src/gallium/drivers/freedreno/freedreno_screen.c >> index e7a185d..fa201ce 100644 >> --- a/src/gallium/drivers/freedreno/freedreno_screen.c >> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c >> @@ -215,6 +215,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum >> pipe_cap param) >> case PIPE_CAP_SAMPLE_SHADING: >> case PIPE_CAP_TEXTURE_GATHER_OFFSETS: >> case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: >> + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: >> return 0; >> >> /* Stream output. */ >> diff --git a/src/gallium/drivers/i915/i915_screen.c >> b/src/gallium/drivers/i915/i915_screen.c >> index 79d8659..b776c49 100644 >> --- a/src/gallium/drivers/i915/i915_screen.c >> +++ b/src/gallium/drivers/i915/i915_screen.c >> @@ -223,6 +223,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap >> cap) >> case PIPE_CAP_SAMPLE_SHADING: >> case PIPE_CAP_TEXTURE_GATHER_OFFSETS: >> case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: >> + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: >>return 0; >> >> case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: >> diff --git a/src/gallium/drivers/ilo/ilo_screen.c >> b/src/gallium/drivers/ilo/ilo_screen.c >> index b08ae20..4b1fe35 100644 >> --- a/src/gallium/drivers/ilo/ilo_screen.c >> +++ b/src/gallium/drivers/ilo/ilo_screen.c >> @@ -442,6 +442,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap >> param) >> case PIPE_CAP_SAMPLE_SHADING: >> case PIPE_CAP_TEXTURE_GATHER_OFFSETS: >> case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: >> + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: >>return 0; >> >> default: >> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c >> b/src/gallium/drivers/llvmpipe/lp_screen.c >> index a6b712a..3ccbcd3 100644 >> --- a/src/gallium/drivers/llvmpipe/lp_screen.c >> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c >> @@ -244,6 +244,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum >> pipe_cap param) >> case PIPE_CAP_SAMPLE_SHADING: >> case PIPE_CAP_TEXTURE_GATHER_OFFSETS: >> case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: >> + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: >>return 0; >> case PIPE_CAP_FAKE_SW_MSAA: >> return 1; >> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> index 5c3d783..db4755b 100644 >> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> @@ -146,6 +146,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum >> pipe_cap param) >> case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: >> case PIPE_CAP_USER_VERTEX_BUFFERS: >> case PIPE_CAP_COMPUTE: >> + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: >>
Re: [Mesa-dev] [PATCH v2 4/9] gallium: add a cap for max vertex streams
Am 30.06.2014 19:43, schrieb Ilia Mirkin: > On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger > wrote: >> 3-4 look alright to me. > > Does this count as a R-b? Looks like the core changes have landed, so > I'm going to be looking to push all this out ~tomorrow. > >> I wonder if the cap name is actually "correct" >> or if it should have some STREAM_OUT in it. But doesn't really matter I >> guess. > > It doesn't really matter to me... same as with the index thing, as > long as everyone agrees, I'm happy with whatever. > > It does seem like it's specific to vertex stream quantities, not > stream-out though. With AMD_tf4, you can also rasterize multpile > vertex streams, which would also be subject to the same limit. But > it's all tied pretty closely together -- e.g. the extension is > AMD_transform_feedback4, not AMD_fragment_vertex_streams or something. > >> Longer term I think we might want to merge some caps. Everybody >> (supporting stream out) will either support 1 or 4 streams along with >> other functionality anyway. > > Agreed. And I like Marek's suggestion of using the GLSL level. Until > then, this is OK though? Yes, Reviewed-by: Roland Scheidegger > >> >> Roland >> >> >> Am 28.06.2014 05:50, schrieb Ilia Mirkin: >>> Signed-off-by: Ilia Mirkin >>> Reviewed-by: Marek Olšák >>> Reviewed-by: Brian Paul >>> --- >>> >>> v1 -> v2: >>> - add an assert to make sure it's <= 4 >>> - add a note in docs about expected values >>> >>> src/gallium/docs/source/screen.rst | 3 +++ >>> src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >>> src/gallium/drivers/i915/i915_screen.c | 1 + >>> src/gallium/drivers/ilo/ilo_screen.c | 1 + >>> src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++ >>> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >>> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 ++ >>> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++ >>> src/gallium/drivers/r300/r300_screen.c | 1 + >>> src/gallium/drivers/r600/r600_pipe.c | 2 ++ >>> src/gallium/drivers/radeonsi/si_pipe.c | 2 ++ >>> src/gallium/drivers/softpipe/sp_screen.c | 2 ++ >>> src/gallium/drivers/svga/svga_screen.c | 1 + >>> src/gallium/include/pipe/p_defines.h | 3 ++- >>> src/mesa/state_tracker/st_extensions.c | 5 + >>> 15 files changed, 28 insertions(+), 1 deletion(-) >>> >>> diff --git a/src/gallium/docs/source/screen.rst >>> b/src/gallium/docs/source/screen.rst >>> index 1a80b04..5e01df5 100644 >>> --- a/src/gallium/docs/source/screen.rst >>> +++ b/src/gallium/docs/source/screen.rst >>> @@ -205,6 +205,9 @@ The integer capabilities: >>> * ``PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION``: Whether >>>TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION is supported, which disables >>> clipping >>>and viewport transformation. >>> +* ``PIPE_CAP_MAX_VERTEX_STREAMS``: The maximum number of vertex streams >>> + supported by the geometry shader. If stream-out is supported, this >>> should be >>> + at least 1. If stream-out is not supported, this should be 0. >>> >>> >>> .. _pipe_capf: >>> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c >>> b/src/gallium/drivers/freedreno/freedreno_screen.c >>> index e7a185d..9200962 100644 >>> --- a/src/gallium/drivers/freedreno/freedreno_screen.c >>> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c >>> @@ -227,6 +227,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum >>> pipe_cap param) >>> /* Geometry shader output, unsupported. */ >>> case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES: >>> case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: >>> + case PIPE_CAP_MAX_VERTEX_STREAMS: >>> return 0; >>> >>> /* Texturing. */ >>> diff --git a/src/gallium/drivers/i915/i915_screen.c >>> b/src/gallium/drivers/i915/i915_screen.c >>> index 79d8659..036f706 100644 >>> --- a/src/gallium/drivers/i915/i915_screen.c >>> +++ b/src/gallium/drivers/i915/i915_screen.c >>> @@ -270,6 +270,7 @@ i915_get_param(struct pipe_screen *screen, enum >>> pipe_cap cap) >>> /* Geometry shader output, unsupported. */ >>> case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES: >>> case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: >>> + case PIPE_CAP_MAX_VERTEX_STREAMS: >>>return 0; >>> >>> /* Fragment coordinate conventions. */ >>> diff --git a/src/gallium/drivers/ilo/ilo_screen.c >>> b/src/gallium/drivers/ilo/ilo_screen.c >>> index b08ae20..8f8e152 100644 >>> --- a/src/gallium/drivers/ilo/ilo_screen.c >>> +++ b/src/gallium/drivers/ilo/ilo_screen.c >>> @@ -375,6 +375,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap >>> param) >>>return ILO_MAX_SO_BINDINGS; >>> case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES: >>> case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: >>> + case PIPE_CAP_MAX_VERTEX_STREAMS: >>>return 0; >>> case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME: >>>if
Re: [Mesa-dev] [PATCH 2/3] i965/fs: Pass cfg to calculate_live_intervals().
On Mon, Jun 30, 2014 at 10:11:41AM -0700, Matt Turner wrote:
> We've often created the CFG immediately before, so use it when
> available.
> ---
> src/mesa/drivers/dri/i965/brw_fs.h| 2 +-
> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 3 +--
> src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 2 +-
> src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp | 12
> src/mesa/drivers/dri/i965/brw_fs_live_variables.h | 4 ++--
> src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp | 4 ++--
> 6 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index 58e7175..961c56c 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -373,7 +373,7 @@ public:
> void assign_constant_locations();
> void demote_pull_constants();
> void invalidate_live_intervals();
> - void calculate_live_intervals();
> + void calculate_live_intervals(const cfg_t *cfg = NULL);
Here in this patch quite a few calls are modified to pass a pointer explicitly,
were there some calls left without?
> void calculate_register_pressure();
> bool opt_algebraic();
> bool opt_cse();
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
> index 381c569..5727801 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
> @@ -317,9 +317,8 @@ fs_visitor::opt_cse()
> {
> bool progress = false;
>
> - calculate_live_intervals();
> -
> cfg_t cfg(&instructions);
> + calculate_live_intervals(&cfg);
>
> for (int b = 0; b < cfg.num_blocks; b++) {
>bblock_t *block = cfg.blocks[b];
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> index 7b2d4aa..d41a42c 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> @@ -41,7 +41,7 @@ fs_visitor::dead_code_eliminate()
>
> cfg_t cfg(&instructions);
>
> - calculate_live_intervals();
> + calculate_live_intervals(&cfg);
>
> int num_vars = live_intervals->num_vars;
> BITSET_WORD *live = ralloc_array(NULL, BITSET_WORD,
> BITSET_WORDS(num_vars));
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
> index 0973dc9..585dc3d 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
> @@ -243,7 +243,7 @@ fs_live_variables::var_from_reg(fs_reg *reg)
> return var_from_vgrf[reg->reg] + reg->reg_offset;
> }
>
> -fs_live_variables::fs_live_variables(fs_visitor *v, cfg_t *cfg)
> +fs_live_variables::fs_live_variables(fs_visitor *v, const cfg_t *cfg)
> : v(v), cfg(cfg)
> {
> mem_ctx = ralloc_context(NULL);
> @@ -304,7 +304,7 @@ fs_visitor::invalidate_live_intervals()
> * information about whole VGRFs.
> */
> void
> -fs_visitor::calculate_live_intervals()
> +fs_visitor::calculate_live_intervals(const cfg_t *cfg)
> {
> if (this->live_intervals)
>return;
> @@ -320,8 +320,12 @@ fs_visitor::calculate_live_intervals()
>virtual_grf_end[i] = -1;
> }
>
> - cfg_t cfg(&instructions);
> - this->live_intervals = new(mem_ctx) fs_live_variables(this, &cfg);
> + if (cfg) {
> + this->live_intervals = new(mem_ctx) fs_live_variables(this, cfg);
> + } else {
> + cfg_t cfg(&instructions);
> + this->live_intervals = new(mem_ctx) fs_live_variables(this, &cfg);
> + }
>
> /* Merge the per-component live ranges to whole VGRF live ranges. */
> for (int i = 0; i < live_intervals->num_vars; i++) {
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.h
> b/src/mesa/drivers/dri/i965/brw_fs_live_variables.h
> index 5a7dd27..13c3eb4 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.h
> @@ -57,7 +57,7 @@ class fs_live_variables {
> public:
> DECLARE_RALLOC_CXX_OPERATORS(fs_live_variables)
>
> - fs_live_variables(fs_visitor *v, cfg_t *cfg);
> + fs_live_variables(fs_visitor *v, const cfg_t *cfg);
> ~fs_live_variables();
>
> bool vars_interfere(int a, int b);
> @@ -97,7 +97,7 @@ protected:
> void compute_start_end();
>
> fs_visitor *v;
> - cfg_t *cfg;
> + const cfg_t *cfg;
> void *mem_ctx;
>
> };
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
> index 079eb2e..1287adb 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
> @@ -93,10 +93,10 @@ fs_visitor::opt_saturate_propagation()
> {
> bool progress = false;
>
>
Re: [Mesa-dev] [PATCH v3] i965: Implement GL_PRIMITIVES_GENERATED with non-zero streams.
On Thu, 2014-06-26 at 08:24 +0200, Iago Toral Quiroga wrote:
> So far we have been using CL_INVOCATION_COUNT to resolve this query
> but this
> is no good with streams, as only stream 0 reaches the clipping
> stage. Instead
> we will use SO_PRIM_STORAGE_NEEDED which can keep track of the
> primitives sent
> to each individual stream.
>
> Since SO_PRIM_STORAGE_NEEDED is related to the SOL stage and
> according to
> ARB_transform_feedback3 we need to be able to query primitives
> generated in
> each stream whether transform feedback is active or not what we do
> is to
> enable the SOL unit even if transform feedback is not active but
> disable all
> output buffers in that case. This effectively disables transform
> feedback
> but permits activation of statistics enabling SO_PRIM_STORAGE_NEEDED
> even
> when transform feedback is not active.
> ---
> src/mesa/drivers/dri/i965/gen6_queryobj.c | 13 +
> src/mesa/drivers/dri/i965/gen7_sol_state.c | 20 +---
> 2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c
> b/src/mesa/drivers/dri/i965/gen6_queryobj.c
> index 0cb64ca..b4b1509 100644
> --- a/src/mesa/drivers/dri/i965/gen6_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/gen6_queryobj.c
> @@ -84,11 +84,16 @@ brw_store_register_mem64(struct brw_context *brw,
> static void
> write_primitives_generated(struct brw_context *brw,
> - drm_intel_bo *query_bo, int idx)
> + drm_intel_bo *query_bo, int stream, int
> idx)
> {
> intel_batchbuffer_emit_mi_flush(brw);
> - brw_store_register_mem64(brw, query_bo, CL_INVOCATION_COUNT,
> idx);
> + if (brw->gen >= 7) {
> + brw_store_register_mem64(brw, query_bo,
> + GEN7_SO_PRIM_STORAGE_NEEDED(stream),
> idx);
> + } else {
> + brw_store_register_mem64(brw, query_bo, CL_INVOCATION_COUNT,
> idx);
> + }
> }
> static void
> @@ -240,7 +245,7 @@ gen6_begin_query(struct gl_context *ctx, struct
> gl_query_object *q)
>break;
> case GL_PRIMITIVES_GENERATED:
> - write_primitives_generated(brw, query->bo, 0);
> + write_primitives_generated(brw, query->bo,
> query->Base.Stream, 0);
>break;
> case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
> @@ -279,7 +284,7 @@ gen6_end_query(struct gl_context *ctx, struct
> gl_query_object *q)
>break;
> case GL_PRIMITIVES_GENERATED:
> - write_primitives_generated(brw, query->bo, 1);
> + write_primitives_generated(brw, query->bo,
> query->Base.Stream, 1);
>break;
> case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
> diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
> b/src/mesa/drivers/dri/i965/gen7_sol_state.c
> index 11b2e2e..d2c3ae3 100644
> --- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
> @@ -223,14 +223,28 @@ upload_3dstate_streamout(struct brw_context
> *brw, bool active,
> uint32_t dw1 = 0, dw2 = 0;
> int i;
> + /*
> +* From ARB_transform_feedback3:
> +*
> +* "When a generated primitive query for a vertex stream is
> active, the
> +* primitives-generated count is incremented every time a
> primitive
> +* emitted to that stream reaches the Discarding Rasterization
> stage
> +* (see Section 3.x) right before rasterization. This counter
> is
> +* incremented whether or not transform feedback is active."
> +*
> +* Since we can only keep track of generated primitives for each
> stream
> +* in the SOL stage we need to make sure it is always active
> even if
> +* transform beedback is not. This way we can track primitives
> generated
> +* in each stream via SO_PRIMITIVE_STORAGE_NEEDED.
> +*/
> + dw1 |= SO_FUNCTION_ENABLE;
> + dw1 |= SO_STATISTICS_ENABLE;
> +
> if (active) {
>int urb_entry_read_offset = 0;
>int urb_entry_read_length = (vue_map->num_slots + 1) / 2 -
> urb_entry_read_offset;
> - dw1 |= SO_FUNCTION_ENABLE;
> - dw1 |= SO_STATISTICS_ENABLE;
> -
>/* _NEW_LIGHT */
>if (ctx->Light.ProvokingVertex != GL_FIRST_VERTEX_CONVENTION)
> dw1 |= SO_REORDER_TRAILING;
I'm getting an instant GPU lockup on Ivy Bridge (3840QM) which I've
bisected to this commit in mesa/mesa git master.
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] non-DRI build break
I configured with: ./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug --enable-xlib-glx --disable-driglx-direct --disable-dri --enable-gallium-osmesa --with-gallium-drivers=swrast --enable-gallium-tests So no DRI code should be used. When I compile: gmake[2]: Entering directory `/home/brianp/projects/Mesa/mesa/src/loader' CC libloader_la-loader.lo loader.c:333:5: error: expected ',' or ';' before 'DRI_CONF_SECTION_INITIALIZATION' gmake[2]: *** [libloader_la-loader.lo] Error 1 Reverting commit 3ecd9e1a93817180fa fixes the build for me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/9] gallium: add a cap for max vertex streams
On Tue, Jul 1, 2014 at 8:39 AM, Roland Scheidegger wrote: > Am 30.06.2014 19:43, schrieb Ilia Mirkin: >> On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger >> wrote: >>> 3-4 look alright to me. >> >> Does this count as a R-b? Looks like the core changes have landed, so >> I'm going to be looking to push all this out ~tomorrow. >> >>> I wonder if the cap name is actually "correct" >>> or if it should have some STREAM_OUT in it. But doesn't really matter I >>> guess. >> >> It doesn't really matter to me... same as with the index thing, as >> long as everyone agrees, I'm happy with whatever. >> >> It does seem like it's specific to vertex stream quantities, not >> stream-out though. With AMD_tf4, you can also rasterize multpile >> vertex streams, which would also be subject to the same limit. But >> it's all tied pretty closely together -- e.g. the extension is >> AMD_transform_feedback4, not AMD_fragment_vertex_streams or something. >> >>> Longer term I think we might want to merge some caps. Everybody >>> (supporting stream out) will either support 1 or 4 streams along with >>> other functionality anyway. >> >> Agreed. And I like Marek's suggestion of using the GLSL level. Until >> then, this is OK though? > > Yes, > Reviewed-by: Roland Scheidegger Great. Is that for the non-nvc0 bits of the series, or just this patch? (or some other subset...) Just want to get all the annotations right before pushing :) -ilia > >> >>> >>> Roland >>> >>> >>> Am 28.06.2014 05:50, schrieb Ilia Mirkin: Signed-off-by: Ilia Mirkin Reviewed-by: Marek Olšák Reviewed-by: Brian Paul --- v1 -> v2: - add an assert to make sure it's <= 4 - add a note in docs about expected values src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++ src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++ src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 2 ++ src/gallium/drivers/radeonsi/si_pipe.c | 2 ++ src/gallium/drivers/softpipe/sp_screen.c | 2 ++ src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 3 ++- src/mesa/state_tracker/st_extensions.c | 5 + 15 files changed, 28 insertions(+), 1 deletion(-) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 1a80b04..5e01df5 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -205,6 +205,9 @@ The integer capabilities: * ``PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION``: Whether TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION is supported, which disables clipping and viewport transformation. +* ``PIPE_CAP_MAX_VERTEX_STREAMS``: The maximum number of vertex streams + supported by the geometry shader. If stream-out is supported, this should be + at least 1. If stream-out is not supported, this should be 0. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index e7a185d..9200962 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -227,6 +227,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) /* Geometry shader output, unsupported. */ case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES: case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: + case PIPE_CAP_MAX_VERTEX_STREAMS: return 0; /* Texturing. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 79d8659..036f706 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -270,6 +270,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) /* Geometry shader output, unsupported. */ case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES: case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: + case PIPE_CAP_MAX_VERTEX_STREAMS: return 0; /* Fragment coordinate conventions. */ diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index b08ae20..8f8e152 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -375,6 +375,7 @@ ilo_get
[Mesa-dev] [PATCH] docs: update hw-dependent bits of ARB_gpu_shader5
Some of the features are completely implemented by core, while others have hardware dependencies. Create a list of drivers supporting each sub-feature that must have hw support. Signed-off-by: Ilia Mirkin --- docs/GL3.txt | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index e9ccf63..8ef4947 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -104,12 +104,12 @@ GL 4.0: - Dynamically uniform sampler array indices started (Chris) - Dynamically uniform UBO array indices started (Chris) - Implicit signed -> unsigned conversionsDONE - - Fused multiply-add DONE - - Packing/bitfield/conversion functions DONE - - Enhanced textureGather DONE - - Geometry shader instancing DONE + - Fused multiply-add DONE (i965, nvc0) + - Packing/bitfield/conversion functions DONE (i965, nvc0) + - Enhanced textureGather DONE (i965, nvc0, radeonsi) + - Geometry shader instancing DONE (i965, nvc0) - Geometry shader multiple streams DONE (i965, nvc0) - - Enhanced per-sample shadingDONE + - Enhanced per-sample shadingDONE (i965) - Interpolation functionsstarted (Chris) - New overload resolution rules DONE GL_ARB_gpu_shader_fp64 started (Dave) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] non-DRI build break
In src/loader/Makefile.am, the test 'if NEED_OPENGL_COMMON' should probably be more restrictive, I'm looking at it. Axel On 01/07/2014 10:22, Brian Paul wrote : I configured with: ./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug --enable-xlib-glx --disable-driglx-direct --disable-dri --enable-gallium-osmesa --with-gallium-drivers=swrast --enable-gallium-tests So no DRI code should be used. When I compile: gmake[2]: Entering directory `/home/brianp/projects/Mesa/mesa/src/loader' CC libloader_la-loader.lo loader.c:333:5: error: expected ',' or ';' before 'DRI_CONF_SECTION_INITIALIZATION' gmake[2]: *** [libloader_la-loader.lo] Error 1 Reverting commit 3ecd9e1a93817180fa fixes the build for me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] st/mesa: allow 2D indexing for all shader types in translate_src()
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 3391a14..1020d36 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4484,7 +4484,10 @@ translate_src(struct st_translate *t, const st_src_reg
*src_reg)
{
struct ureg_src src = src_register(t, src_reg->file, src_reg->index,
src_reg->index2D);
- if (t->procType == TGSI_PROCESSOR_GEOMETRY && src_reg->has_index2) {
+ if (src_reg->has_index2) {
+ /* 2D indexes occur with geometry shader inputs (attrib, vertex)
+ * and UBO constant buffers (buffer, position).
+ */
src = src_register(t, src_reg->file, src_reg->index, src_reg->index2D);
if (src_reg->reladdr2)
src = ureg_src_dimension_indirect(src, ureg_src(t->address[1]),
--
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/5] st/mesa: fix incorrect size of UBO declarations
UniformBufferSize is in bytes so we need to divide by 16 to get the
number of constant buffer slots. Also, the ureg_DECL_constant2D()
function takes first..last parameters so we need to subtract one
for the last value.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 3933e69..324d4d0 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -5123,7 +5123,14 @@ st_translate_program(
unsigned num_ubos = program->shader->NumUniformBlocks;
for (i = 0; i < num_ubos; i++) {
- ureg_DECL_constant2D(t->ureg, 0,
program->shader->UniformBlocks[i].UniformBufferSize / 4, i + 1);
+ unsigned size =
+program->shader_program->UniformBlocks[i].UniformBufferSize;
+ unsigned num_const_vecs = (size + 15) / 16;
+ unsigned first, last;
+ assert(num_const_vecs > 0);
+ first = 0;
+ last = num_const_vecs > 0 ? num_const_vecs - 1 : 0;
+ ureg_DECL_constant2D(t->ureg, first, last, i + 1);
}
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] mesa: update comment for UniformBufferSize to indicate size is in bytes
--- src/mesa/main/mtypes.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index eaf3776..e78bcde 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -2560,7 +2560,7 @@ struct gl_uniform_block GLuint Binding; /** -* Minimum size of a buffer object to back this uniform buffer +* Minimum size (in bytes) of a buffer object to back this uniform buffer * (GL_UNIFORM_BLOCK_DATA_SIZE). */ GLuint UniformBufferSize; -- 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/5] st/mesa: don't use address register for constant-indexed ir_binop_ubo_load
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 1020d36..3933e69 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1971,9 +1971,17 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
assert(ir->type->is_vector() || ir->type->is_scalar());
if (const_offset_ir) {
- index_reg = st_src_reg_for_int(const_offset / 16);
- } else {
- emit(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), op[1],
st_src_reg_for_int(4));
+ /* Constant index into constant buffer */
+ cbuf.reladdr = NULL;
+ cbuf.index = const_offset / 16;
+ cbuf.has_index2 = true;
+ }
+ else {
+ /* Relative/variable index into constant buffer */
+ emit(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), op[1],
+ st_src_reg_for_int(4));
+ cbuf.reladdr = ralloc(mem_ctx, st_src_reg);
+ memcpy(cbuf.reladdr, &index_reg, sizeof(index_reg));
}
cbuf.swizzle = swizzle_for_size(ir->type->vector_elements);
@@ -1982,9 +1990,6 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
const_offset % 16 / 4,
const_offset % 16 / 4);
- cbuf.reladdr = ralloc(mem_ctx, st_src_reg);
- memcpy(cbuf.reladdr, &index_reg, sizeof(index_reg));
-
if (ir->type->base_type == GLSL_TYPE_BOOL) {
emit(ir, TGSI_OPCODE_USNE, result_dst, cbuf, st_src_reg_for_int(0));
} else {
--
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/5] st/mesa: don't ignore const buf index in src_register()
Otherwise, if we were creating a const buffer src register for a UBO
the index into the UBO was always zero.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index cac1e0f..3391a14 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4396,7 +4396,7 @@ src_register(struct st_translate *t,
case PROGRAM_CONSTANT: /* ie, immediate */
if (index2D) {
struct ureg_src src;
- src = ureg_src_register(TGSI_FILE_CONSTANT, 0);
+ src = ureg_src_register(TGSI_FILE_CONSTANT, index);
src.Dimension = 1;
src.DimensionIndex = index2D;
return src;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Allow the blorp blit between BGR and RGB
> FWIW, I relaxed the format restrictions in
> brw_blorp_copytexsubimage, so it can handle general format
> conversions as well (i.e. RGBA_FLOAT16 -> RGBA_UNORM). There's
> no reason we couldn't do that for BlitFramebuffer as well, I just
> forgot to do it (and then we decided to make it a newbie task, and
> then the newbie didn't do said task, and...oops.)
Ok, I think that is a good idea. Here is a patch to do it. I'm also
sending a test to the piglit mailing list that tries blitting between
different formats.
Regards,
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
Subject: i965: Don't check for format differences when using the blorp blitter
Previously the blorp blitter wouldn't be used if the source and destination
buffer had a different format other than swizzling between RGB and BGR and
adding or removing a dummy alpha channel. However there's no reason why the
blorp code path can't be used to do almost all format conversions so this
patch just removes the checks. However it does explicitly disable converting
to/from MESA_FORMAT_Z24_UNORM_X8_UINT because there is a similar check
brw_blorp_copytexsubimage.
This doesn't cause any Piglit test regressions at least on Ivybridge.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 66 +---
1 file changed, 12 insertions(+), 54 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index d7f5f7d..6a4918e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -120,52 +120,6 @@ do_blorp_blit(struct brw_context *brw, GLbitfield
buffer_bit,
}
static bool
-format_is_rgba_or_rgbx_byte(mesa_format format)
-{
- switch (format) {
- case MESA_FORMAT_B8G8R8X8_UNORM:
- case MESA_FORMAT_B8G8R8A8_UNORM:
- case MESA_FORMAT_R8G8B8X8_UNORM:
- case MESA_FORMAT_R8G8B8A8_UNORM:
- return true;
- default:
- return false;
- }
-}
-
-static bool
-color_formats_match(mesa_format src_format, mesa_format dst_format)
-{
- mesa_format linear_src_format = _mesa_get_srgb_format_linear(src_format);
- mesa_format linear_dst_format = _mesa_get_srgb_format_linear(dst_format);
-
- /* Normally, we require the formats to be equal. However, we also support
-* blitting from ARGB to XRGB (discarding alpha), and from XRGB to ARGB
-* (overriding alpha to 1.0 via blending) as well as swizzling between BGR
-* and RGB.
-*/
-
- return (linear_src_format == linear_dst_format ||
- (format_is_rgba_or_rgbx_byte(linear_src_format) &&
-format_is_rgba_or_rgbx_byte(linear_dst_format)));
-}
-
-static bool
-formats_match(GLbitfield buffer_bit, struct intel_renderbuffer *src_irb,
- struct intel_renderbuffer *dst_irb)
-{
- /* Note: don't just check gl_renderbuffer::Format, because in some cases
-* multiple gl_formats resolve to the same native type in the miptree (for
-* example MESA_FORMAT_Z24_UNORM_X8_UINT and
MESA_FORMAT_Z24_UNORM_S8_UINT), and we can blit
-* between those formats.
-*/
- mesa_format src_format = find_miptree(buffer_bit, src_irb)->format;
- mesa_format dst_format = find_miptree(buffer_bit, dst_irb)->format;
-
- return color_formats_match(src_format, dst_format);
-}
-
-static bool
try_blorp_blit(struct brw_context *brw,
GLfloat srcX0, GLfloat srcY0, GLfloat srcX1, GLfloat srcY1,
GLfloat dstX0, GLfloat dstY0, GLfloat dstX1, GLfloat dstY1,
@@ -191,16 +145,13 @@ try_blorp_blit(struct brw_context *brw,
/* Find buffers */
struct intel_renderbuffer *src_irb;
struct intel_renderbuffer *dst_irb;
+ struct intel_mipmap_tree *src_mt;
+ struct intel_mipmap_tree *dst_mt;
switch (buffer_bit) {
case GL_COLOR_BUFFER_BIT:
src_irb = intel_renderbuffer(read_fb->_ColorReadBuffer);
for (unsigned i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; ++i) {
dst_irb = intel_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[i]);
- if (dst_irb && !formats_match(buffer_bit, src_irb, dst_irb))
-return false;
- }
- for (unsigned i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; ++i) {
- dst_irb = intel_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[i]);
if (dst_irb)
do_blorp_blit(brw, buffer_bit, src_irb, dst_irb, srcX0, srcY0,
srcX1, srcY1, dstX0, dstY0, dstX1, dstY1,
@@ -212,8 +163,17 @@ try_blorp_blit(struct brw_context *brw,
intel_renderbuffer(read_fb->Attachment[BUFFER_DEPTH].Renderbuffer);
dst_irb =
intel_renderbuffer(draw_fb->Attachment[BUFFER_DEPTH].Renderbuffer);
- if (!formats_match(buffer_bit, src_irb, dst_irb))
+ src_mt = find_miptree(buffer_bit, src_irb);
+ dst_mt = find_miptree(buffer_bit, dst_irb);
+
+ /* We can't handle format conversions between Z24 and other formats
+ * since we have to lie about th
Re: [Mesa-dev] [PATCH v2] r600g: allow viewport index/layer to be sent to fs
On Tue, Jun 24, 2014 at 8:43 PM, Ilia Mirkin wrote:
> In order to support ARB_fragment_layer_viewport, we need to explicitly
> send these along to the fragment shader, since it has no other way to
> retrieve them.
>
> Signed-off-by: Ilia Mirkin
> Tested-by: Tobias Droste
> ---
>
> v1 -> v2:
>
> - Add forgotten copy to initialize new output with the settings of the
> previous one for vertex layer
>
> Tobias was able to test this version with the vertex shader setting the layer
> as well. (And it passed. The first version crashed his box.)
>
> I would like to reiterate my disclaimers from the v1 commit... I don't know
> much about r600, don't have the hw, and was just going on the advice of Alex
> Deucher and Jerome Glisse. I largely copied how clipvertex was handled.
This looks good to me.
Reviewed-by: Alex Deucher
>
> It's unclear to me whether these outputs will be eliminated in the
> (overwhelmingly common) case where the fragment shader does not actually
> consume them, but I was told they would be.
>
> src/gallium/drivers/r600/r600_shader.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c
> b/src/gallium/drivers/r600/r600_shader.c
> index b3d1998..3767e5f 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -498,8 +498,6 @@ static int r600_spi_sid(struct r600_shader_io * io)
> if (name == TGSI_SEMANTIC_POSITION ||
> name == TGSI_SEMANTIC_PSIZE ||
> name == TGSI_SEMANTIC_EDGEFLAG ||
> - name == TGSI_SEMANTIC_LAYER ||
> - name == TGSI_SEMANTIC_VIEWPORT_INDEX ||
> name == TGSI_SEMANTIC_FACE)
> index = 0;
> else {
> @@ -1337,6 +1335,12 @@ static int generate_gs_copy_shader(struct r600_context
> *rctx,
> ctx.shader->vs_out_point_size = 1;
> break;
> case TGSI_SEMANTIC_LAYER:
> + if (out->spi_sid) {
> + /* duplicate it as PARAM to pass to the pixel
> shader */
> + output.array_base = next_param++;
> + r600_bytecode_add_output(ctx.bc, &output);
> + last_exp_param = ctx.bc->cf_last;
> + }
> output.array_base = 61;
> if (next_clip_pos == 61)
> next_clip_pos = 62;
> @@ -1349,6 +1353,12 @@ static int generate_gs_copy_shader(struct r600_context
> *rctx,
> ctx.shader->vs_out_layer = 1;
> break;
> case TGSI_SEMANTIC_VIEWPORT_INDEX:
> + if (out->spi_sid) {
> + /* duplicate it as PARAM to pass to the pixel
> shader */
> + output.array_base = next_param++;
> + r600_bytecode_add_output(ctx.bc, &output);
> + last_exp_param = ctx.bc->cf_last;
> + }
> output.array_base = 61;
> if (next_clip_pos == 61)
> next_clip_pos = 62;
> @@ -2016,6 +2026,14 @@ static int r600_shader_from_tgsi(struct r600_context
> *rctx,
> pos_emitted = true;
> break;
> case TGSI_SEMANTIC_LAYER:
> + /* spi_sid is 0 for outputs that are
> +* not consumed by PS */
> + if (shader->output[i].spi_sid) {
> + output[j].array_base =
> next_param_base++;
> + output[j].type =
> V_SQ_CF_ALLOC_EXPORT_WORD0_SQ_EXPORT_PARAM;
> + j++;
> + memcpy(&output[j],
> &output[j-1], sizeof(struct r600_bytecode_output));
> + }
> output[j].array_base = 61;
> output[j].swizzle_x = 7;
> output[j].swizzle_y = 7;
> --
> 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
Re: [Mesa-dev] non-DRI build break
Hi, This path should resolve the problem. Axel On 01/07/2014 10:53, Axel Davy wrote : In src/loader/Makefile.am, the test 'if NEED_OPENGL_COMMON' should probably be more restrictive, I'm looking at it. Axel On 01/07/2014 10:22, Brian Paul wrote : I configured with: ./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug --enable-xlib-glx --disable-driglx-direct --disable-dri --enable-gallium-osmesa --with-gallium-drivers=swrast --enable-gallium-tests So no DRI code should be used. When I compile: gmake[2]: Entering directory `/home/brianp/projects/Mesa/mesa/src/loader' CC libloader_la-loader.lo loader.c:333:5: error: expected ',' or ';' before 'DRI_CONF_SECTION_INITIALIZATION' gmake[2]: *** [libloader_la-loader.lo] Error 1 Reverting commit 3ecd9e1a93817180fa fixes the build for me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev >From c79a9c85e8238ce32ed59ec1d02f69b5aeb813d7 Mon Sep 17 00:00:00 2001 From: Axel Davy Date: Tue, 1 Jul 2014 11:15:41 -0400 Subject: [PATCH] Fix the condition in src/loader/Makefile.am we want to have the dri common files compiled to define USE_DRICONF. We need to check both NEED_OPENGL_COMMON and HAVE_DRICOMMON Signed-off-by: Axel Davy --- src/loader/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am index ae8a844..c02de6f 100644 --- a/src/loader/Makefile.am +++ b/src/loader/Makefile.am @@ -33,6 +33,7 @@ libloader_la_SOURCES = $(LOADER_C_FILES) libloader_la_LIBADD = if NEED_OPENGL_COMMON +if HAVE_DRICOMMON libloader_la_CPPFLAGS += \ -I$(top_srcdir)/src/mesa/drivers/dri/common/ \ -I$(top_builddir)/src/mesa/drivers/dri/common/ \ @@ -47,6 +48,7 @@ libloader_la_LIBADD += \ -lm \ $(EXPAT_LIBS) endif +endif if !HAVE_LIBDRM libloader_la_CPPFLAGS += \ -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] non-DRI build break
That works. Tested-by: Brian Paul On 07/01/2014 09:19 AM, Axel Davy wrote: Hi, This path should resolve the problem. Axel On 01/07/2014 10:53, Axel Davy wrote : In src/loader/Makefile.am, the test 'if NEED_OPENGL_COMMON' should probably be more restrictive, I'm looking at it. Axel On 01/07/2014 10:22, Brian Paul wrote : I configured with: ./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug --enable-xlib-glx --disable-driglx-direct --disable-dri --enable-gallium-osmesa --with-gallium-drivers=swrast --enable-gallium-tests So no DRI code should be used. When I compile: gmake[2]: Entering directory `/home/brianp/projects/Mesa/mesa/src/loader' CC libloader_la-loader.lo loader.c:333:5: error: expected ',' or ';' before 'DRI_CONF_SECTION_INITIALIZATION' gmake[2]: *** [libloader_la-loader.lo] Error 1 Reverting commit 3ecd9e1a93817180fa fixes the build for me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=cj12Q%2FBfA25RIPaLheckQPAaMWMlA%2FFTvPRlosz69Ho%3D%0A&s=384c0580e1d5604fa1241249c9a6cd439d3b0e8e2bdcaca5b0593ff7b5208f4f ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: allow viewport index/layer to be sent to fs
On Tue, Jul 1, 2014 at 11:13 AM, Alex Deucher wrote:
> On Tue, Jun 24, 2014 at 8:43 PM, Ilia Mirkin wrote:
>> In order to support ARB_fragment_layer_viewport, we need to explicitly
>> send these along to the fragment shader, since it has no other way to
>> retrieve them.
>>
>> Signed-off-by: Ilia Mirkin
>> Tested-by: Tobias Droste
>> ---
>>
>> v1 -> v2:
>>
>> - Add forgotten copy to initialize new output with the settings of the
>> previous one for vertex layer
>>
>> Tobias was able to test this version with the vertex shader setting the layer
>> as well. (And it passed. The first version crashed his box.)
>>
>> I would like to reiterate my disclaimers from the v1 commit... I don't know
>> much about r600, don't have the hw, and was just going on the advice of Alex
>> Deucher and Jerome Glisse. I largely copied how clipvertex was handled.
>
> This looks good to me.
>
> Reviewed-by: Alex Deucher
Great! Marek had indicated on IRC that it'd be a while before he could
look at it. Should I wait for him, or is this good to go in? [Not sure
who the experts are on the radeon side of things...] Please note that
the testing that was done was only on the ARB_fragment_layer_viewport
tests, on only one card (evergreen, if memory serves), not a full
piglit run.
>
>>
>> It's unclear to me whether these outputs will be eliminated in the
>> (overwhelmingly common) case where the fragment shader does not actually
>> consume them, but I was told they would be.
>>
>> src/gallium/drivers/r600/r600_shader.c | 22 --
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_shader.c
>> b/src/gallium/drivers/r600/r600_shader.c
>> index b3d1998..3767e5f 100644
>> --- a/src/gallium/drivers/r600/r600_shader.c
>> +++ b/src/gallium/drivers/r600/r600_shader.c
>> @@ -498,8 +498,6 @@ static int r600_spi_sid(struct r600_shader_io * io)
>> if (name == TGSI_SEMANTIC_POSITION ||
>> name == TGSI_SEMANTIC_PSIZE ||
>> name == TGSI_SEMANTIC_EDGEFLAG ||
>> - name == TGSI_SEMANTIC_LAYER ||
>> - name == TGSI_SEMANTIC_VIEWPORT_INDEX ||
>> name == TGSI_SEMANTIC_FACE)
>> index = 0;
>> else {
>> @@ -1337,6 +1335,12 @@ static int generate_gs_copy_shader(struct
>> r600_context *rctx,
>> ctx.shader->vs_out_point_size = 1;
>> break;
>> case TGSI_SEMANTIC_LAYER:
>> + if (out->spi_sid) {
>> + /* duplicate it as PARAM to pass to the
>> pixel shader */
>> + output.array_base = next_param++;
>> + r600_bytecode_add_output(ctx.bc, &output);
>> + last_exp_param = ctx.bc->cf_last;
>> + }
>> output.array_base = 61;
>> if (next_clip_pos == 61)
>> next_clip_pos = 62;
>> @@ -1349,6 +1353,12 @@ static int generate_gs_copy_shader(struct
>> r600_context *rctx,
>> ctx.shader->vs_out_layer = 1;
>> break;
>> case TGSI_SEMANTIC_VIEWPORT_INDEX:
>> + if (out->spi_sid) {
>> + /* duplicate it as PARAM to pass to the
>> pixel shader */
>> + output.array_base = next_param++;
>> + r600_bytecode_add_output(ctx.bc, &output);
>> + last_exp_param = ctx.bc->cf_last;
>> + }
>> output.array_base = 61;
>> if (next_clip_pos == 61)
>> next_clip_pos = 62;
>> @@ -2016,6 +2026,14 @@ static int r600_shader_from_tgsi(struct r600_context
>> *rctx,
>> pos_emitted = true;
>> break;
>> case TGSI_SEMANTIC_LAYER:
>> + /* spi_sid is 0 for outputs that are
>> +* not consumed by PS */
>> + if (shader->output[i].spi_sid) {
>> + output[j].array_base =
>> next_param_base++;
>> + output[j].type =
>> V_SQ_CF_ALLOC_EXPORT_WORD0_SQ_EXPORT_PARAM;
>> + j++;
>> + memcpy(&output[j],
>> &output[j-1], sizeof(struct r600_bytecode_output));
>> + }
>> output[j].array_base = 61;
>> output[j].swizzle_x = 7;
>> output[j].swizzle_y = 7;
>> --
>> 1.8.5.5
>>
>> _
Re: [Mesa-dev] [PATCH 5/5] mesa: update comment for UniformBufferSize to indicate size is in bytes
Am 01.07.2014 16:53, schrieb Brian Paul: > --- > src/mesa/main/mtypes.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h > index eaf3776..e78bcde 100644 > --- a/src/mesa/main/mtypes.h > +++ b/src/mesa/main/mtypes.h > @@ -2560,7 +2560,7 @@ struct gl_uniform_block > GLuint Binding; > > /** > -* Minimum size of a buffer object to back this uniform buffer > +* Minimum size (in bytes) of a buffer object to back this uniform buffer > * (GL_UNIFORM_BLOCK_DATA_SIZE). > */ > GLuint UniformBufferSize; > Series is: Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/9] gallium: add a cap for max vertex streams
Am 01.07.2014 16:25, schrieb Ilia Mirkin: > On Tue, Jul 1, 2014 at 8:39 AM, Roland Scheidegger wrote: >> Am 30.06.2014 19:43, schrieb Ilia Mirkin: >>> On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger >>> wrote: 3-4 look alright to me. >>> >>> Does this count as a R-b? Looks like the core changes have landed, so >>> I'm going to be looking to push all this out ~tomorrow. >>> I wonder if the cap name is actually "correct" or if it should have some STREAM_OUT in it. But doesn't really matter I guess. >>> >>> It doesn't really matter to me... same as with the index thing, as >>> long as everyone agrees, I'm happy with whatever. >>> >>> It does seem like it's specific to vertex stream quantities, not >>> stream-out though. With AMD_tf4, you can also rasterize multpile >>> vertex streams, which would also be subject to the same limit. But >>> it's all tied pretty closely together -- e.g. the extension is >>> AMD_transform_feedback4, not AMD_fragment_vertex_streams or something. >>> Longer term I think we might want to merge some caps. Everybody (supporting stream out) will either support 1 or 4 streams along with other functionality anyway. >>> >>> Agreed. And I like Marek's suggestion of using the GLSL level. Until >>> then, this is OK though? >> >> Yes, >> Reviewed-by: Roland Scheidegger > > Great. Is that for the non-nvc0 bits of the series, or just this > patch? (or some other subset...) Just want to get all the annotations > right before pushing :) All the non-nvc0 bits. Roland > -ilia > >> >>> Roland Am 28.06.2014 05:50, schrieb Ilia Mirkin: > Signed-off-by: Ilia Mirkin > Reviewed-by: Marek Olšák > Reviewed-by: Brian Paul > --- > > v1 -> v2: > - add an assert to make sure it's <= 4 > - add a note in docs about expected values > > src/gallium/docs/source/screen.rst | 3 +++ > src/gallium/drivers/freedreno/freedreno_screen.c | 1 + > src/gallium/drivers/i915/i915_screen.c | 1 + > src/gallium/drivers/ilo/ilo_screen.c | 1 + > src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++ > src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 ++ > src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++ > src/gallium/drivers/r300/r300_screen.c | 1 + > src/gallium/drivers/r600/r600_pipe.c | 2 ++ > src/gallium/drivers/radeonsi/si_pipe.c | 2 ++ > src/gallium/drivers/softpipe/sp_screen.c | 2 ++ > src/gallium/drivers/svga/svga_screen.c | 1 + > src/gallium/include/pipe/p_defines.h | 3 ++- > src/mesa/state_tracker/st_extensions.c | 5 + > 15 files changed, 28 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/docs/source/screen.rst > b/src/gallium/docs/source/screen.rst > index 1a80b04..5e01df5 100644 > --- a/src/gallium/docs/source/screen.rst > +++ b/src/gallium/docs/source/screen.rst > @@ -205,6 +205,9 @@ The integer capabilities: > * ``PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION``: Whether >TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION is supported, which disables > clipping >and viewport transformation. > +* ``PIPE_CAP_MAX_VERTEX_STREAMS``: The maximum number of vertex streams > + supported by the geometry shader. If stream-out is supported, this > should be > + at least 1. If stream-out is not supported, this should be 0. > > > .. _pipe_capf: > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c > b/src/gallium/drivers/freedreno/freedreno_screen.c > index e7a185d..9200962 100644 > --- a/src/gallium/drivers/freedreno/freedreno_screen.c > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c > @@ -227,6 +227,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum > pipe_cap param) > /* Geometry shader output, unsupported. */ > case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES: > case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: > + case PIPE_CAP_MAX_VERTEX_STREAMS: > return 0; > > /* Texturing. */ > diff --git a/src/gallium/drivers/i915/i915_screen.c > b/src/gallium/drivers/i915/i915_screen.c > index 79d8659..036f706 100644 > --- a/src/gallium/drivers/i915/i915_screen.c > +++ b/src/gallium/drivers/i915/i915_screen.c > @@ -270,6 +270,7 @@ i915_get_param(struct pipe_screen *screen, enum > pipe_cap cap) > /* Geometry shader output, unsupported. */ > case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES: > case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: > + case PIPE_CAP_MAX_VERTEX_STREAMS: >return 0; > > /* Fragment coordinate conventions. */ > diff --git a/src/gallium/drivers/ilo/ilo_screen.c > b/sr
Re: [Mesa-dev] [PATCH 5/5] mesa: update comment for UniformBufferSize to indicate size is in bytes
On 07/01/2014 09:25 AM, Roland Scheidegger wrote: Am 01.07.2014 16:53, schrieb Brian Paul: --- src/mesa/main/mtypes.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index eaf3776..e78bcde 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -2560,7 +2560,7 @@ struct gl_uniform_block GLuint Binding; /** -* Minimum size of a buffer object to back this uniform buffer +* Minimum size (in bytes) of a buffer object to back this uniform buffer * (GL_UNIFORM_BLOCK_DATA_SIZE). */ GLuint UniformBufferSize; Series is: Reviewed-by: Roland Scheidegger Thanks. I'm going to beef-up the comment on patch 3 before pushing. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] non-DRI build break
I don't have push access. Could you push it ? On 01/07/2014 11:22, Brian Paul wrote : That works. Tested-by: Brian Paul On 07/01/2014 09:19 AM, Axel Davy wrote: Hi, This path should resolve the problem. Axel On 01/07/2014 10:53, Axel Davy wrote : In src/loader/Makefile.am, the test 'if NEED_OPENGL_COMMON' should probably be more restrictive, I'm looking at it. Axel On 01/07/2014 10:22, Brian Paul wrote : I configured with: ./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug --enable-xlib-glx --disable-driglx-direct --disable-dri --enable-gallium-osmesa --with-gallium-drivers=swrast --enable-gallium-tests So no DRI code should be used. When I compile: gmake[2]: Entering directory `/home/brianp/projects/Mesa/mesa/src/loader' CC libloader_la-loader.lo loader.c:333:5: error: expected ',' or ';' before 'DRI_CONF_SECTION_INITIALIZATION' gmake[2]: *** [libloader_la-loader.lo] Error 1 Reverting commit 3ecd9e1a93817180fa fixes the build for me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=cj12Q%2FBfA25RIPaLheckQPAaMWMlA%2FFTvPRlosz69Ho%3D%0A&s=384c0580e1d5604fa1241249c9a6cd439d3b0e8e2bdcaca5b0593ff7b5208f4f ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] non-DRI build break
Done. -Brian On 07/01/2014 09:40 AM, Axel Davy wrote: I don't have push access. Could you push it ? On 01/07/2014 11:22, Brian Paul wrote : That works. Tested-by: Brian Paul On 07/01/2014 09:19 AM, Axel Davy wrote: Hi, This path should resolve the problem. Axel On 01/07/2014 10:53, Axel Davy wrote : In src/loader/Makefile.am, the test 'if NEED_OPENGL_COMMON' should probably be more restrictive, I'm looking at it. Axel On 01/07/2014 10:22, Brian Paul wrote : I configured with: ./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug --enable-xlib-glx --disable-driglx-direct --disable-dri --enable-gallium-osmesa --with-gallium-drivers=swrast --enable-gallium-tests So no DRI code should be used. When I compile: gmake[2]: Entering directory `/home/brianp/projects/Mesa/mesa/src/loader' CC libloader_la-loader.lo loader.c:333:5: error: expected ',' or ';' before 'DRI_CONF_SECTION_INITIALIZATION' gmake[2]: *** [libloader_la-loader.lo] Error 1 Reverting commit 3ecd9e1a93817180fa fixes the build for me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=cj12Q%2FBfA25RIPaLheckQPAaMWMlA%2FFTvPRlosz69Ho%3D%0A&s=384c0580e1d5604fa1241249c9a6cd439d3b0e8e2bdcaca5b0593ff7b5208f4f ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75913] Add support DRI_PRIME to drirc
https://bugs.freedesktop.org/show_bug.cgi?id=75913 commiethebeas...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from commiethebeas...@gmail.com --- Fixed by 3ecd9e1a93817180fa5b280e5fe11c903cca38ba -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: allow viewport index/layer to be sent to fs
If the tests pass, the patch can be merged.
Marek
On Tue, Jul 1, 2014 at 5:25 PM, Ilia Mirkin wrote:
> On Tue, Jul 1, 2014 at 11:13 AM, Alex Deucher wrote:
>> On Tue, Jun 24, 2014 at 8:43 PM, Ilia Mirkin wrote:
>>> In order to support ARB_fragment_layer_viewport, we need to explicitly
>>> send these along to the fragment shader, since it has no other way to
>>> retrieve them.
>>>
>>> Signed-off-by: Ilia Mirkin
>>> Tested-by: Tobias Droste
>>> ---
>>>
>>> v1 -> v2:
>>>
>>> - Add forgotten copy to initialize new output with the settings of the
>>> previous one for vertex layer
>>>
>>> Tobias was able to test this version with the vertex shader setting the
>>> layer
>>> as well. (And it passed. The first version crashed his box.)
>>>
>>> I would like to reiterate my disclaimers from the v1 commit... I don't know
>>> much about r600, don't have the hw, and was just going on the advice of Alex
>>> Deucher and Jerome Glisse. I largely copied how clipvertex was handled.
>>
>> This looks good to me.
>>
>> Reviewed-by: Alex Deucher
>
> Great! Marek had indicated on IRC that it'd be a while before he could
> look at it. Should I wait for him, or is this good to go in? [Not sure
> who the experts are on the radeon side of things...] Please note that
> the testing that was done was only on the ARB_fragment_layer_viewport
> tests, on only one card (evergreen, if memory serves), not a full
> piglit run.
>
>>
>>>
>>> It's unclear to me whether these outputs will be eliminated in the
>>> (overwhelmingly common) case where the fragment shader does not actually
>>> consume them, but I was told they would be.
>>>
>>> src/gallium/drivers/r600/r600_shader.c | 22 --
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/r600/r600_shader.c
>>> b/src/gallium/drivers/r600/r600_shader.c
>>> index b3d1998..3767e5f 100644
>>> --- a/src/gallium/drivers/r600/r600_shader.c
>>> +++ b/src/gallium/drivers/r600/r600_shader.c
>>> @@ -498,8 +498,6 @@ static int r600_spi_sid(struct r600_shader_io * io)
>>> if (name == TGSI_SEMANTIC_POSITION ||
>>> name == TGSI_SEMANTIC_PSIZE ||
>>> name == TGSI_SEMANTIC_EDGEFLAG ||
>>> - name == TGSI_SEMANTIC_LAYER ||
>>> - name == TGSI_SEMANTIC_VIEWPORT_INDEX ||
>>> name == TGSI_SEMANTIC_FACE)
>>> index = 0;
>>> else {
>>> @@ -1337,6 +1335,12 @@ static int generate_gs_copy_shader(struct
>>> r600_context *rctx,
>>> ctx.shader->vs_out_point_size = 1;
>>> break;
>>> case TGSI_SEMANTIC_LAYER:
>>> + if (out->spi_sid) {
>>> + /* duplicate it as PARAM to pass to the
>>> pixel shader */
>>> + output.array_base = next_param++;
>>> + r600_bytecode_add_output(ctx.bc, &output);
>>> + last_exp_param = ctx.bc->cf_last;
>>> + }
>>> output.array_base = 61;
>>> if (next_clip_pos == 61)
>>> next_clip_pos = 62;
>>> @@ -1349,6 +1353,12 @@ static int generate_gs_copy_shader(struct
>>> r600_context *rctx,
>>> ctx.shader->vs_out_layer = 1;
>>> break;
>>> case TGSI_SEMANTIC_VIEWPORT_INDEX:
>>> + if (out->spi_sid) {
>>> + /* duplicate it as PARAM to pass to the
>>> pixel shader */
>>> + output.array_base = next_param++;
>>> + r600_bytecode_add_output(ctx.bc, &output);
>>> + last_exp_param = ctx.bc->cf_last;
>>> + }
>>> output.array_base = 61;
>>> if (next_clip_pos == 61)
>>> next_clip_pos = 62;
>>> @@ -2016,6 +2026,14 @@ static int r600_shader_from_tgsi(struct r600_context
>>> *rctx,
>>> pos_emitted = true;
>>> break;
>>> case TGSI_SEMANTIC_LAYER:
>>> + /* spi_sid is 0 for outputs that are
>>> +* not consumed by PS */
>>> + if (shader->output[i].spi_sid) {
>>> + output[j].array_base =
>>> next_param_base++;
>>> + output[j].type =
>>> V_SQ_CF_ALLOC_EXPORT_WORD0_SQ_EXPORT_PARAM;
>>> + j++;
>>> + memcpy(&output[j],
>>> &output[j-1], sizeof(struct r600_bytecode_output));
>>> + }
>>>
Re: [Mesa-dev] [PATCH 2/5] mesa/main: Add generic bits of ARB_clear_texture implementation
Jason Ekstrand writes: >> + texImages[0] = _mesa_select_tex_image(ctx, texObj, texObj->Target, >> level); >> > > Do you want this inside an else block? I think it's quite a common idiom in Mesa to handle the special cases as a series of if-statements with a return upfront before handling the normal case at the end without an else. But yes, in this instance it does look a bit odd because the there is only one special case and the normal case is very short, so I don't mind changing it. Regards, - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] mesa/main: Add generic bits of ARB_clear_texture implementation
Ian Romanick writes: > Are there potentially cases where the first clear_tex_image could > succeed but the second fail? If so, then this is no good. If a GL call > generates an error (other than GL_NO_MEMORY), it is supposed to be as > though nothing happened. Urgh, yes, you're right because for example GL would let you make one face of a cubemap texture be compressed while the others aren't. I'll change it to have a separate loop for the checks as you suggest. Thanks for the review. - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] texstore: Add a generic implementation of GL_ARB_clear_texture
Jason Ekstrand writes:
>> +static void
>> +clear_image_to_zero(GLubyte *dstMap, GLint dstRowStride,
>> +GLsizei width, GLsizei height,
>> +GLsizei clearValueSize)
>> +{
>> + while (height-- > 0) {
>> + memset(dstMap, 0, clearValueSize * width);
>> + dstMap += dstRowStride;
>> + }
>> +}
>>
>
> Technically, this should always work, but you might want to throw in a
> comment about floating-point textures.
I'm not sure what you mean here. Are you saying that hypothetically
floating-point textures might not represent 0 as zero bytes?
> Other than that, looks good to me. (I'll second Ilia's MS comment
> though.)
Does that count as ‘reviewed-by’? (Yes, in the github branch I've made
the two changes that Ilia suggested.)
Thanks for the review.
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] mesa/main: Add generic bits of ARB_clear_texture implementation
On Tue, Jul 1, 2014 at 10:09 AM, Neil Roberts wrote: > Jason Ekstrand writes: > > >> + texImages[0] = _mesa_select_tex_image(ctx, texObj, texObj->Target, > >> level); > >> > > > > Do you want this inside an else block? > > I think it's quite a common idiom in Mesa to handle the special cases as > a series of if-statements with a return upfront before handling the > normal case at the end without an else. But yes, in this instance it > does look a bit odd because the there is only one special case and the > normal case is very short, so I don't mind changing it. > Sorry, I missed the return. In that case, I don't think it matters; feel free to leave it alone. --Jason > > Regards, > - Neil > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] texstore: Add a generic implementation of GL_ARB_clear_texture
On Tue, Jul 1, 2014 at 11:06 AM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
> >> +static void
> >> +clear_image_to_zero(GLubyte *dstMap, GLint dstRowStride,
> >> +GLsizei width, GLsizei height,
> >> +GLsizei clearValueSize)
> >> +{
> >> + while (height-- > 0) {
> >> + memset(dstMap, 0, clearValueSize * width);
> >> + dstMap += dstRowStride;
> >> + }
> >> +}
> >>
> >
> > Technically, this should always work, but you might want to throw in a
> > comment about floating-point textures.
>
> I'm not sure what you mean here. Are you saying that hypothetically
> floating-point textures might not represent 0 as zero bytes?
>
sorry, I got nervous about memsetting floats. It isn't actually a problem
though since floating-point zero is just all zeroes. It doesn't really
matter much.
>
> > Other than that, looks good to me. (I'll second Ilia's MS comment
> > though.)
>
> Does that count as ‘reviewed-by’? (Yes, in the github branch I've made
> the two changes that Ilia suggested.)
>
Sure.
Reviewed-by: Jason Ekstrand
>
> Thanks for the review.
>
> - Neil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: Update discard jump to preserve uniform loads via sampler.
Commit 17c7ead7 exposed a bug in how uniform loading happens in the
presence of discard. It manifested itself in an application as
randomly incorrect pixels on the borders of conditional areas.
This is due to how discards jump to the end of the shader incorrectly
for some channels. The current implementation checks each 2x2
subspan to preserve derivatives. When uniform loading via samplers
was turned on, it uses a full execution mask, as stated in
lower_uniform_pull_constant_loads(), and only populates four channels
of the destination (see generate_uniform_pull_constant_load_gen7()).
It happens incorrectly when the first subspan has been jumped over.
The series that implemented this optimization was done before the
changes to use samplers for uniform loads. Uniform sampler loads
use special execution masks and only populate four channels, so we
can't jump over those or corruption ensues.
This fix only jumps to the end of the shader if all relevant channels
are disabled, i.e. all 8 or 16, depending on dispatch. This
preserves the original GLbenchmark 2.7 speedup noted in commit
beafced2.
It changes the shader assembly accordingly:
before : (-f0.1.any4h) halt(8) 17 2 null { align1 WE_all 1Q };
after(8) : (-f0.1.any8h) halt(8) 17 2 null { align1 WE_all 1Q };
after(16): (-f0.1.any16h) halt(16) 17 2 null { align1 WE_all 1H };
v2: Cleaned up comments and conditional ordering.
Signed-off-by: Cody Northrop
Reviewed-by: Mike Stroyan
Reviewed-by: Kenneth Graunke
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79948
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 654f5fe..3516aca 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1929,15 +1929,14 @@ fs_visitor::visit(ir_discard *ir)
if (brw->gen >= 6) {
/* For performance, after a discard, jump to the end of the shader.
- * However, many people will do foliage by discarding based on a
- * texture's alpha mask, and then continue on to texture with the
- * remaining pixels. To avoid trashing the derivatives for those
- * texture samples, we'll only jump if all of the pixels in the subspan
- * have been discarded.
+ * Only jump if all relavant channels have been discarded.
*/
fs_inst *discard_jump = emit(FS_OPCODE_DISCARD_JUMP);
discard_jump->flag_subreg = 1;
- discard_jump->predicate = BRW_PREDICATE_ALIGN1_ANY4H;
+
+ discard_jump->predicate = (dispatch_width == 8)
+? BRW_PREDICATE_ALIGN1_ANY8H
+: BRW_PREDICATE_ALIGN1_ANY16H;
discard_jump->predicate_inverse = true;
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] llvmpipe: get rid of llvmpipe_get_texture_tile_linear
From: Roland Scheidegger
Because the layout is always linear this didn't really do much any longer -
at some point this triggered per-tile swizzled->linear conversion. The x/y
coords were ignored too.
Apart from triggering conversion, this also invoked alloc_image_data(), which
could only actually trigger mapping of display target resources. So, instead
just call resource_map in the callers (which also gives the ability to unmap
again). Note that mapping/unmapping of display target resources still isn't
really all that clean (map/unmap may be unmatched, and all such mappings use
the same pointer thus usage flags are a lie).
---
src/gallium/drivers/llvmpipe/lp_surface.c | 86 ++-
src/gallium/drivers/llvmpipe/lp_texture.c | 32 +---
src/gallium/drivers/llvmpipe/lp_texture.h | 6 ---
3 files changed, 17 insertions(+), 107 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_surface.c
b/src/gallium/drivers/llvmpipe/lp_surface.c
index 09ca39d..08f968f 100644
--- a/src/gallium/drivers/llvmpipe/lp_surface.c
+++ b/src/gallium/drivers/llvmpipe/lp_surface.c
@@ -35,22 +35,6 @@
#include "lp_query.h"
-/**
- * Adjust x, y, width, height to lie on tile bounds.
- */
-static void
-adjust_to_tile_bounds(unsigned x, unsigned y, unsigned width, unsigned height,
- unsigned *x_tile, unsigned *y_tile,
- unsigned *w_tile, unsigned *h_tile)
-{
- *x_tile = x & ~(TILE_SIZE - 1);
- *y_tile = y & ~(TILE_SIZE - 1);
- *w_tile = ((x + width + TILE_SIZE - 1) & ~(TILE_SIZE - 1)) - *x_tile;
- *h_tile = ((y + height + TILE_SIZE - 1) & ~(TILE_SIZE - 1)) - *y_tile;
-}
-
-
-
static void
lp_resource_copy(struct pipe_context *pipe,
struct pipe_resource *dst, unsigned dst_level,
@@ -64,7 +48,6 @@ lp_resource_copy(struct pipe_context *pipe,
unsigned width = src_box->width;
unsigned height = src_box->height;
unsigned depth = src_box->depth;
- unsigned z;
llvmpipe_flush_resource(pipe,
dst, dst_level,
@@ -94,61 +77,16 @@ lp_resource_copy(struct pipe_context *pipe,
src_box->width, src_box->height, src_box->depth);
*/
- for (z = 0; z < src_box->depth; z++){
-
- /* set src tiles to linear layout */
- {
- unsigned tx, ty, tw, th;
- unsigned x, y;
+ /* make sure display target resources (which cannot have levels/layers) are
mapped */
+ if (src_tex->dt)
+ (void) llvmpipe_resource_map(src, src_level, 0, LP_TEX_USAGE_READ);
+ if (dst_tex->dt)
+ /*
+ * Could set this to WRITE_ALL if complete dst is covered but it gets
+ * ignored anyway.
+ */
+ (void) llvmpipe_resource_map(dst, dst_level, 0, LP_TEX_USAGE_READ_WRITE);
- adjust_to_tile_bounds(src_box->x, src_box->y, width, height,
- &tx, &ty, &tw, &th);
-
- for (y = 0; y < th; y += TILE_SIZE) {
-for (x = 0; x < tw; x += TILE_SIZE) {
- (void) llvmpipe_get_texture_tile_linear(src_tex,
- src_box->z + z,
src_level,
- LP_TEX_USAGE_READ,
- tx + x, ty + y);
-}
- }
- }
-
- /* set dst tiles to linear layout */
- {
- unsigned tx, ty, tw, th;
- unsigned x, y;
- enum lp_texture_usage usage;
-
- adjust_to_tile_bounds(dstx, dsty, width, height, &tx, &ty, &tw, &th);
-
- for (y = 0; y < th; y += TILE_SIZE) {
-boolean contained_y = ty + y >= dsty &&
- ty + y + TILE_SIZE <= dsty + height ?
- TRUE : FALSE;
-
-for (x = 0; x < tw; x += TILE_SIZE) {
- boolean contained_x = tx + x >= dstx &&
- tx + x + TILE_SIZE <= dstx + width ?
- TRUE : FALSE;
-
- /*
-* Set the usage mode to WRITE_ALL for the tiles which are
-* completely contained by the dest rectangle.
-*/
- if (contained_y && contained_x)
- usage = LP_TEX_USAGE_WRITE_ALL;
- else
- usage = LP_TEX_USAGE_READ_WRITE;
-
- (void) llvmpipe_get_texture_tile_linear(dst_tex,
- dstz + z, dst_level,
- usage,
- tx + x, ty + y);
-}
- }
- }
- }
/* copy */
{
@@ -171,6 +109,12 @@ lp_resource_copy(struct pipe_context *pipe,
src_box->x, src_box->y, 0);
}
}
+
+ if (src_tex->dt)
+ llvmpipe_resource_unmap(src, 0, 0);
+ if (dst_tex->dt)
+ llvmpipe_resource_unmap(dst, 0, 0);
+
}
diff --git a
[Mesa-dev] [PATCH 3/6] llvmpipe: allocate regular texture memory upfront
From: Roland Scheidegger
The deferred allocation doesn't really make much sense anymore, since we no
longer allocate swizzled/linear memory in chunks and not per level / slice
neither.
This means we could fail resource creation a bit more (could already fail in
theory anyway) but should not fail maps later (right now, callers can't deal
with neither really).
---
src/gallium/drivers/llvmpipe/lp_texture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index a156449..f95b2a2 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -59,6 +59,8 @@ static struct llvmpipe_resource resource_list;
#endif
static unsigned id_counter = 0;
+static void
+alloc_image_data(struct llvmpipe_resource *lpr);
/**
* Conventional allocation path for non-display textures:
@@ -247,6 +249,11 @@ llvmpipe_resource_create(struct pipe_screen *_screen,
/* texture map */
if (!llvmpipe_texture_layout(screen, lpr))
goto fail;
+
+ alloc_image_data(lpr);
+ if (!lpr->tex_data) {
+goto fail;
+ }
}
}
else {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] llvmpipe: get rid of linear_img struct
From: Roland Scheidegger
Just use a tex_data pointer directly - the description was no longer correct
neither.
---
src/gallium/drivers/llvmpipe/lp_setup.c | 2 +-
src/gallium/drivers/llvmpipe/lp_state_sampler.c | 2 +-
src/gallium/drivers/llvmpipe/lp_texture.c | 39 ++---
src/gallium/drivers/llvmpipe/lp_texture.h | 9 +-
4 files changed, 19 insertions(+), 33 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index 046611a..cbf465e 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -818,7 +818,7 @@ lp_setup_set_fragment_sampler_views(struct lp_setup_context
*setup,
*/
mip_ptr = llvmpipe_get_texture_image_all(lp_tex, first_level,
LP_TEX_USAGE_READ);
- jit_tex->base = lp_tex->linear_img.data;
+ jit_tex->base = lp_tex->tex_data;
}
else {
mip_ptr = lp_tex->data;
diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
index 0b227ea..d204378 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
@@ -244,7 +244,7 @@ prepare_shader_sampling(
/* XXX this may fail due to OOM ? */
mip_ptr = llvmpipe_get_texture_image_all(lp_tex,
view->u.tex.first_level,
LP_TEX_USAGE_READ);
- addr = lp_tex->linear_img.data;
+ addr = lp_tex->tex_data;
for (j = first_level; j <= last_level; j++) {
mip_ptr = llvmpipe_get_texture_image_all(lp_tex, j,
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index d60d101..a156449 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -301,9 +301,9 @@ llvmpipe_resource_destroy(struct pipe_screen *pscreen,
}
else if (llvmpipe_resource_is_texture(pt)) {
/* free linear image data */
- if (lpr->linear_img.data) {
- align_free(lpr->linear_img.data);
- lpr->linear_img.data = NULL;
+ if (lpr->tex_data) {
+ align_free(lpr->tex_data);
+ lpr->tex_data = NULL;
}
}
else if (!lpr->userBuffer) {
@@ -359,7 +359,7 @@ llvmpipe_resource_map(struct pipe_resource *resource,
map = winsys->displaytarget_map(winsys, lpr->dt, dt_usage);
/* install this linear image in texture data structure */
- lpr->linear_img.data = map;
+ lpr->tex_data = map;
return map;
}
@@ -726,16 +726,14 @@ ubyte *
llvmpipe_get_texture_image_address(struct llvmpipe_resource *lpr,
unsigned face_slice, unsigned level)
{
- struct llvmpipe_texture_image *img;
unsigned offset;
- img = &lpr->linear_img;
offset = lpr->mip_offsets[level];
if (face_slice > 0)
offset += face_slice * tex_image_face_size(lpr, level);
- return (ubyte *) img->data + offset;
+ return (ubyte *) lpr->tex_data + offset;
}
@@ -759,7 +757,7 @@ alloc_image_data(struct llvmpipe_resource *lpr)
assert(lpr->base.last_level == 0);
- lpr->linear_img.data =
+ lpr->tex_data =
winsys->displaytarget_map(winsys, lpr->dt,
PIPE_TRANSFER_READ_WRITE);
}
@@ -774,9 +772,9 @@ alloc_image_data(struct llvmpipe_resource *lpr)
lpr->mip_offsets[level] = offset;
offset += align(buffer_size, alignment);
}
- lpr->linear_img.data = align_malloc(offset, alignment);
- if (lpr->linear_img.data) {
- memset(lpr->linear_img.data, 0, offset);
+ lpr->tex_data = align_malloc(offset, alignment);
+ if (lpr->tex_data) {
+ memset(lpr->tex_data, 0, offset);
}
}
}
@@ -795,7 +793,6 @@ llvmpipe_get_texture_image(struct llvmpipe_resource *lpr,
unsigned face_slice, unsigned level,
enum lp_texture_usage usage)
{
- struct llvmpipe_texture_image *target_img;
void *target_data;
unsigned target_offset;
unsigned *target_off_ptr;
@@ -805,17 +802,14 @@ llvmpipe_get_texture_image(struct llvmpipe_resource *lpr,
usage == LP_TEX_USAGE_WRITE_ALL);
if (lpr->dt) {
- assert(lpr->linear_img.data);
+ assert(lpr->tex_data);
}
- target_img = &lpr->linear_img;
target_off_ptr = lpr->mip_offsets;
- target_data = target_img->data;
- if (!target_data) {
+ if (!lpr->tex_data) {
/* allocate memory for the target image now */
alloc_image_data(lpr);
- target_data = target_img->data;
}
target_offset = target_off_ptr[level];
@@ -824,8 +818,8 @@ llvmpipe_get_texture_image(struct llvmpipe_resource *lpr,
ta
[Mesa-dev] [PATCH 4/6] llvmpipe: get rid of llvmpipe_get_texture_image_all
From: Roland Scheidegger
Once used for invoking swizzled->linear conversion for all needed images.
But we now have a single allocation for all images in a resource, thus looping
through all slices is rather pointless, conversion doesn't happen neither.
Also simplify the sampling setup code to use the mip_offsets array in the
resource directly - if the (non display target) resource exists its memory
will already be allocated as well.
---
src/gallium/drivers/llvmpipe/lp_setup.c | 24
src/gallium/drivers/llvmpipe/lp_state_sampler.c | 20 +++-
src/gallium/drivers/llvmpipe/lp_texture.c | 23 ---
src/gallium/drivers/llvmpipe/lp_texture.h | 5 -
4 files changed, 7 insertions(+), 65 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index cbf465e..d728e85 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -802,7 +802,6 @@ lp_setup_set_fragment_sampler_views(struct lp_setup_context
*setup,
if (!lp_tex->dt) {
/* regular texture - setup array of mipmap level offsets */
-void *mip_ptr;
int j;
unsigned first_level = 0;
unsigned last_level = 0;
@@ -812,22 +811,14 @@ lp_setup_set_fragment_sampler_views(struct
lp_setup_context *setup,
last_level = view->u.tex.last_level;
assert(first_level <= last_level);
assert(last_level <= res->last_level);
-
- /*
-* The complexity here should no longer be necessary.
-*/
- mip_ptr = llvmpipe_get_texture_image_all(lp_tex, first_level,
-LP_TEX_USAGE_READ);
jit_tex->base = lp_tex->tex_data;
}
else {
- mip_ptr = lp_tex->data;
- jit_tex->base = mip_ptr;
+ jit_tex->base = lp_tex->data;
}
-if ((LP_PERF & PERF_TEX_MEM) || !mip_ptr) {
- /* out of memory - use dummy tile memory */
- /* Note if using PERF_TEX_MEM will also skip tile conversion */
+if (LP_PERF & PERF_TEX_MEM) {
+ /* use dummy tile memory */
jit_tex->base = lp_dummy_tile;
jit_tex->width = TILE_SIZE/8;
jit_tex->height = TILE_SIZE/8;
@@ -847,14 +838,7 @@ lp_setup_set_fragment_sampler_views(struct
lp_setup_context *setup,
if (llvmpipe_resource_is_texture(res)) {
for (j = first_level; j <= last_level; j++) {
- mip_ptr = llvmpipe_get_texture_image_all(lp_tex, j,
-
LP_TEX_USAGE_READ);
- jit_tex->mip_offsets[j] = (uint8_t *)mip_ptr - (uint8_t
*)jit_tex->base;
- /*
- * could get mip offset directly but need call above to
- * invoke tiled->linear conversion.
- */
- assert(lp_tex->mip_offsets[j] == jit_tex->mip_offsets[j]);
+ jit_tex->mip_offsets[j] = lp_tex->mip_offsets[j];
jit_tex->row_stride[j] = lp_tex->row_stride[j];
jit_tex->img_stride[j] = lp_tex->img_stride[j];
}
diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
index d204378..a14a64f 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
@@ -232,29 +232,16 @@ prepare_shader_sampling(
/* regular texture - setup array of mipmap level offsets */
struct pipe_resource *res = view->texture;
int j;
-void *mip_ptr;
if (llvmpipe_resource_is_texture(res)) {
first_level = view->u.tex.first_level;
last_level = view->u.tex.last_level;
assert(first_level <= last_level);
assert(last_level <= res->last_level);
-
- /* must trigger allocation first before we can get base ptr */
- /* XXX this may fail due to OOM ? */
- mip_ptr = llvmpipe_get_texture_image_all(lp_tex,
view->u.tex.first_level,
-LP_TEX_USAGE_READ);
addr = lp_tex->tex_data;
for (j = first_level; j <= last_level; j++) {
- mip_ptr = llvmpipe_get_texture_image_all(lp_tex, j,
- LP_TEX_USAGE_READ);
- mip_offsets[j] = (uint8_t *)mip_ptr - (uint8_t *)addr;
- /*
- * could get mip offset directly but need call above to
- * invoke tiled->linear conversion.
-
[Mesa-dev] [PATCH 5/6] llvmpipe: get rid of llvmpipe_get_texture_image
From: Roland Scheidegger
The only caller left used it only for non display target textures,
hence it was really the same as llvmpipe_get_texture_image_address - it
also had a usage flag but this was ignored anyway.
---
src/gallium/drivers/llvmpipe/lp_texture.c | 48 +--
src/gallium/drivers/llvmpipe/lp_texture.h | 5
2 files changed, 1 insertion(+), 52 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index f5383dc..3cb421c 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -372,7 +372,7 @@ llvmpipe_resource_map(struct pipe_resource *resource,
}
else if (llvmpipe_resource_is_texture(resource)) {
- map = llvmpipe_get_texture_image(lpr, layer, level, tex_usage);
+ map = llvmpipe_get_texture_image_address(lpr, layer, level);
return map;
}
else {
@@ -787,52 +787,6 @@ alloc_image_data(struct llvmpipe_resource *lpr)
}
-
-/**
- * Return pointer to texture image data
- * for a particular cube face or 3D texture slice.
- *
- * \param face_slice the cube face or 3D slice of interest
- * \param usage one of LP_TEX_USAGE_READ/WRITE_ALL/READ_WRITE
- */
-void *
-llvmpipe_get_texture_image(struct llvmpipe_resource *lpr,
- unsigned face_slice, unsigned level,
- enum lp_texture_usage usage)
-{
- void *target_data;
- unsigned target_offset;
- unsigned *target_off_ptr;
-
- assert(usage == LP_TEX_USAGE_READ ||
- usage == LP_TEX_USAGE_READ_WRITE ||
- usage == LP_TEX_USAGE_WRITE_ALL);
-
- if (lpr->dt) {
- assert(lpr->tex_data);
- }
-
- target_off_ptr = lpr->mip_offsets;
-
- if (!lpr->tex_data) {
- /* allocate memory for the target image now */
- alloc_image_data(lpr);
- }
-
- target_offset = target_off_ptr[level];
-
- if (face_slice > 0) {
- target_offset += face_slice * tex_image_face_size(lpr, level);
- }
-
- if (lpr->tex_data) {
- target_data = (uint8_t *) lpr->tex_data + target_offset;
- }
-
- return target_data;
-}
-
-
/**
* Get pointer to a linear image (not the tile!) at tile (x,y).
* \return pointer to start of image/face (not the tile)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.h
b/src/gallium/drivers/llvmpipe/lp_texture.h
index 5eb0f5a..b163226 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.h
+++ b/src/gallium/drivers/llvmpipe/lp_texture.h
@@ -217,11 +217,6 @@ ubyte *
llvmpipe_get_texture_image_address(struct llvmpipe_resource *lpr,
unsigned face_slice, unsigned level);
-void *
-llvmpipe_get_texture_image(struct llvmpipe_resource *resource,
- unsigned face_slice, unsigned level,
- enum lp_texture_usage usage);
-
ubyte *
llvmpipe_get_texture_tile_linear(struct llvmpipe_resource *lpr,
unsigned face_slice, unsigned level,
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] llvmpipe: (trivial) rename linear_mip_offsets to mip_offsets
From: Roland Scheidegger
Since switching to non-swizzled rendering we only have "normal", aka linear,
offsets.
---
src/gallium/drivers/llvmpipe/lp_setup.c | 2 +-
src/gallium/drivers/llvmpipe/lp_state_sampler.c | 2 +-
src/gallium/drivers/llvmpipe/lp_texture.c | 6 +++---
src/gallium/drivers/llvmpipe/lp_texture.h | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index 77ac3af..046611a 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -854,7 +854,7 @@ lp_setup_set_fragment_sampler_views(struct lp_setup_context
*setup,
* could get mip offset directly but need call above to
* invoke tiled->linear conversion.
*/
- assert(lp_tex->linear_mip_offsets[j] ==
jit_tex->mip_offsets[j]);
+ assert(lp_tex->mip_offsets[j] == jit_tex->mip_offsets[j]);
jit_tex->row_stride[j] = lp_tex->row_stride[j];
jit_tex->img_stride[j] = lp_tex->img_stride[j];
}
diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
index 09bc928..0b227ea 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
@@ -254,7 +254,7 @@ prepare_shader_sampling(
* could get mip offset directly but need call above to
* invoke tiled->linear conversion.
*/
- assert(lp_tex->linear_mip_offsets[j] == mip_offsets[j]);
+ assert(lp_tex->mip_offsets[j] == mip_offsets[j]);
row_stride[j] = lp_tex->row_stride[j];
img_stride[j] = lp_tex->img_stride[j];
}
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 6df88d0..d60d101 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -730,7 +730,7 @@ llvmpipe_get_texture_image_address(struct llvmpipe_resource
*lpr,
unsigned offset;
img = &lpr->linear_img;
- offset = lpr->linear_mip_offsets[level];
+ offset = lpr->mip_offsets[level];
if (face_slice > 0)
offset += face_slice * tex_image_face_size(lpr, level);
@@ -771,7 +771,7 @@ alloc_image_data(struct llvmpipe_resource *lpr)
*/
for (level = 0; level <= lpr->base.last_level; level++) {
uint buffer_size = tex_image_size(lpr, level);
- lpr->linear_mip_offsets[level] = offset;
+ lpr->mip_offsets[level] = offset;
offset += align(buffer_size, alignment);
}
lpr->linear_img.data = align_malloc(offset, alignment);
@@ -809,7 +809,7 @@ llvmpipe_get_texture_image(struct llvmpipe_resource *lpr,
}
target_img = &lpr->linear_img;
- target_off_ptr = lpr->linear_mip_offsets;
+ target_off_ptr = lpr->mip_offsets;
target_data = target_img->data;
if (!target_data) {
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.h
b/src/gallium/drivers/llvmpipe/lp_texture.h
index af11848..e26d044 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.h
+++ b/src/gallium/drivers/llvmpipe/lp_texture.h
@@ -74,7 +74,7 @@ struct llvmpipe_resource
/** Number of 3D slices or cube faces per level */
unsigned num_slices_faces[LP_MAX_TEXTURE_LEVELS];
/** Offset to start of mipmap level, in bytes */
- unsigned linear_mip_offsets[LP_MAX_TEXTURE_LEVELS];
+ unsigned mip_offsets[LP_MAX_TEXTURE_LEVELS];
/**
* Display target, for textures with the PIPE_BIND_DISPLAY_TARGET
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] target-helpers: don't use designated initializers
From: Roland Scheidegger
it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
in more places, in particular even for things buildable with msvc, and hence
those break the build.
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
index a03db3a..3b36316 100644
--- a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
+++ b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
@@ -210,13 +210,13 @@ dd_driver_name(void)
}
static const struct drm_conf_ret throttle_ret = {
- .type = DRM_CONF_INT,
- .val.val_int = 2,
+ DRM_CONF_INT,
+ {2},
};
static const struct drm_conf_ret share_fd_ret = {
- .type = DRM_CONF_BOOL,
- .val.val_int = true,
+ DRM_CONF_BOOL,
+ {true},
};
static const struct drm_conf_ret *
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] llvmpipe: get rid of llvmpipe_get_texture_tile_linear
On 07/01/2014 01:05 PM, srol...@vmware.com wrote: From: Roland Scheidegger Because the layout is always linear this didn't really do much any longer - at some point this triggered per-tile swizzled->linear conversion. The x/y coords were ignored too. Apart from triggering conversion, this also invoked alloc_image_data(), which could only actually trigger mapping of display target resources. So, instead just call resource_map in the callers (which also gives the ability to unmap again). Note that mapping/unmapping of display target resources still isn't really all that clean (map/unmap may be unmatched, and all such mappings use the same pointer thus usage flags are a lie). --- src/gallium/drivers/llvmpipe/lp_surface.c | 86 ++- src/gallium/drivers/llvmpipe/lp_texture.c | 32 +--- src/gallium/drivers/llvmpipe/lp_texture.h | 6 --- 3 files changed, 17 insertions(+), 107 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] target-helpers: don't use designated initializers
On 07/01/2014 01:17 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
in more places, in particular even for things buildable with msvc, and hence
those break the build.
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
index a03db3a..3b36316 100644
--- a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
+++ b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
@@ -210,13 +210,13 @@ dd_driver_name(void)
}
static const struct drm_conf_ret throttle_ret = {
- .type = DRM_CONF_INT,
- .val.val_int = 2,
+ DRM_CONF_INT,
+ {2},
};
static const struct drm_conf_ret share_fd_ret = {
- .type = DRM_CONF_BOOL,
- .val.val_int = true,
+ DRM_CONF_BOOL,
+ {true},
};
static const struct drm_conf_ret *
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] i965/fs: Update discard jump to preserve uniform loads via sampler.
On Tuesday, July 01, 2014 12:43:54 PM Cody Northrop wrote:
> Commit 17c7ead7 exposed a bug in how uniform loading happens in the
> presence of discard. It manifested itself in an application as
> randomly incorrect pixels on the borders of conditional areas.
>
> This is due to how discards jump to the end of the shader incorrectly
> for some channels. The current implementation checks each 2x2
> subspan to preserve derivatives. When uniform loading via samplers
> was turned on, it uses a full execution mask, as stated in
> lower_uniform_pull_constant_loads(), and only populates four channels
> of the destination (see generate_uniform_pull_constant_load_gen7()).
> It happens incorrectly when the first subspan has been jumped over.
>
> The series that implemented this optimization was done before the
> changes to use samplers for uniform loads. Uniform sampler loads
> use special execution masks and only populate four channels, so we
> can't jump over those or corruption ensues.
>
> This fix only jumps to the end of the shader if all relevant channels
> are disabled, i.e. all 8 or 16, depending on dispatch. This
> preserves the original GLbenchmark 2.7 speedup noted in commit
> beafced2.
>
> It changes the shader assembly accordingly:
>
> before : (-f0.1.any4h) halt(8) 17 2 null { align1 WE_all 1Q };
> after(8) : (-f0.1.any8h) halt(8) 17 2 null { align1 WE_all 1Q };
> after(16): (-f0.1.any16h) halt(16) 17 2 null { align1 WE_all 1H };
>
> v2: Cleaned up comments and conditional ordering.
>
> Signed-off-by: Cody Northrop
> Reviewed-by: Mike Stroyan
> Reviewed-by: Kenneth Graunke
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79948
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 654f5fe..3516aca 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -1929,15 +1929,14 @@ fs_visitor::visit(ir_discard *ir)
>
> if (brw->gen >= 6) {
>/* For performance, after a discard, jump to the end of the shader.
> - * However, many people will do foliage by discarding based on a
> - * texture's alpha mask, and then continue on to texture with the
> - * remaining pixels. To avoid trashing the derivatives for those
> - * texture samples, we'll only jump if all of the pixels in the
subspan
> - * have been discarded.
> + * Only jump if all relavant channels have been discarded.
> */
>fs_inst *discard_jump = emit(FS_OPCODE_DISCARD_JUMP);
>discard_jump->flag_subreg = 1;
> - discard_jump->predicate = BRW_PREDICATE_ALIGN1_ANY4H;
> +
> + discard_jump->predicate = (dispatch_width == 8)
> +? BRW_PREDICATE_ALIGN1_ANY8H
> +: BRW_PREDICATE_ALIGN1_ANY16H;
>discard_jump->predicate_inverse = true;
> }
> }
>
Pushed, thanks!
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Fix aggregates with dynamic initializers.
Vectors are falling in to the ir_dereference_array() path.
Without this change, the following glsl aborts the debug driver,
or gets the wrong answer in release:
mat2x2 a = mat2( vec2( 1.0, vertex.x ), vec2( 0.0, 1.0 ) );
Also submitting piglit tests, will reference in bug.
Signed-off-by: Cody Northrop
Reviewed-by: Courtney Goeltzenleuchter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79373
---
src/glsl/ast_function.cpp | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 8e91a1e..9de6f05 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -751,10 +751,20 @@ process_vec_mat_constructor(exec_list *instructions,
int i = 0;
foreach_list(node, &actual_parameters) {
ir_rvalue *rhs = (ir_rvalue *) node;
- ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
- new(ctx) ir_constant(i));
+ ir_instruction *assignment = NULL;
+
+ if (var->type->is_array() || var->type->is_matrix()) {
+ ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
+ new(ctx) ir_constant(i));
+ assignment = new(ctx) ir_assignment(lhs, rhs, NULL);
+ } else {
+ /* use writemask rather than index for vector */
+ assert(var->type->is_vector());
+ assert(i < 4);
+ ir_dereference *lhs = new(ctx) ir_dereference_variable(var);
+ assignment = new(ctx) ir_assignment(lhs, rhs, NULL, (unsigned)(1 <<
i));
+ }
- ir_instruction *assignment = new(ctx) ir_assignment(lhs, rhs, NULL);
instructions->push_tail(assignment);
i++;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] glsl/glcpp: Fix glcpp to properly lex entire "preprocessing numbers"
On Thu, Jun 26, 2014 at 2:54 PM, Carl Worth wrote:
> The preprocessor defines a notions of a "preprocessing number" that
> starts with either a digit or a decimal point, and continues with zero
> or more of digits, decimal points, identifier characters, or the sign
> symbols, ('-' and '+').
>
> Prior to this change, preprocessing numbers were lexed as some
> combination of OTHER and IDENTIFIER tokens. This had the problem of
> causing undesired macro expansion in some cases.
>
> We add tests to ensure that the undesired macro expansion does not
> happen in cases such as:
>
> #define e +1
> #define xyz -2
>
> int n = 1e;
> int p = 1xyz;
>
> In either case these macro definitions have no effect after this
> change, so that the numeric literals, (whether valid or not), will be
> passed on as-is from the preprocessor to the compiler proper.
>
> This fixes the following Khronos GLES3 CTS tests:
>
> preprocessor.basic.correct_phases_vertex
> preprocessor.basic.correct_phases_fragment
>
> v2. Thanks to Anuj Phogat for improving the original regular expression,
> (which accepted a '+' or '-', where these are only allowed after one of
> [eEpP]. I also expanded the test to exercise this.
>
> v3. Also fixed regular expression to require at least one digit at the
> beginning (after an optional period). Otherwise, a string such as ".xyz" was
> getting sucked up as a preprocessing number, (where obviously this should be a
> field access). Again, I expanded the test to exercise this.
>
V3 fixes a CTS failure caused by V2 in GL3Tests.shadow.shadow_compilation_frag.
> Reviewed-by: Anuj Phogat
> ---
>
> > It causes '2.0-MACRO' to incorrectly lexed as a preprocessing number.
> > Around 30 GLES3 CTS tests failed with this patch.
> >
> > I think using below definition of preprocessing numbers should work fine:
> > PP_NUMBER \.?[0-9]([._a-zA-Z0-9]|[eEpP][+-])*
>
> Thanks, Anuj. When I first saw your follow-up here, I saw the new
> alternation to pull the exponent piece, ("e+", etc.) separate from
> the main character class. But I missed that you als fixed the initial
> optional '.' followed by a required digit.
>
> I ended up implementing that second fix independently, and only now
> while sending the patch again do I see that you had that fixed in your
> regular expression as well.
>
> Thanks again. This new version also adds a bunch of testing to
> "make check", (and fixes all the regressions that piglit found with
> my earlier regular expression.
>
> src/glsl/glcpp/glcpp-lex.l | 6
> src/glsl/glcpp/tests/124-preprocessing-numbers.c | 37 +
> .../tests/124-preprocessing-numbers.c.expected | 38
> ++
> 3 files changed, 81 insertions(+)
> create mode 100644 src/glsl/glcpp/tests/124-preprocessing-numbers.c
> create mode 100644 src/glsl/glcpp/tests/124-preprocessing-numbers.c.expected
>
> diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
> index d5fb087..9563817 100644
> --- a/src/glsl/glcpp/glcpp-lex.l
> +++ b/src/glsl/glcpp/glcpp-lex.l
> @@ -76,6 +76,7 @@ NEWLINE [\n]
> HSPACE [ \t]
> HASH ^{HSPACE}*#{HSPACE}*
> IDENTIFIER [_a-zA-Z][_a-zA-Z0-9]*
> +PP_NUMBER [.]?[0-9]([._a-zA-Z0-9]|[eEpP][-+])*
> PUNCTUATION[][(){}.&*~!/%<>^|;,=+-]
>
> /* The OTHER class is simply a catch-all for things that the CPP
> @@ -330,6 +331,11 @@ HEXADECIMAL_INTEGER0[xX][0-9a-fA-F]+[uU]?
> return IDENTIFIER;
> }
>
> +{PP_NUMBER} {
> + yylval->str = ralloc_strdup (yyextra, yytext);
> + return OTHER;
> +}
> +
> {PUNCTUATION} {
> return yytext[0];
> }
> diff --git a/src/glsl/glcpp/tests/124-preprocessing-numbers.c
> b/src/glsl/glcpp/tests/124-preprocessing-numbers.c
> new file mode 100644
> index 000..8019804
> --- /dev/null
> +++ b/src/glsl/glcpp/tests/124-preprocessing-numbers.c
> @@ -0,0 +1,37 @@
> +#define e THIS_SHOULD_NOT_BE_EXPANDED
> +#define E NOR_THIS
> +#define p NOT_THIS_EITHER
> +#define P AND_SURELY_NOT_THIS
> +#define OK CRAZY_BUT_TRUE_THIS_NEITHER
> +
> +/* This one is actually meant to be expanded */
> +#define MUST_EXPAND GO
> +
> +/* The following are "preprocessing numbers" and should not trigger macro
> + * expansion. */
> +1e
> +1OK
> +
> +/* These are also "preprocessing numbers", so no expansion */
> +123e+OK
> +.23E+OK
> +1.3e-OK
> +12.E-OK
> +123p+OK
> +.23P+OK
> +1.3p-OK
> +12.P-OK
> +123..OK
> +.23.OK.OK
> +
> +/* Importantly, just before the MUST_EXPAND in each of these, the preceding
> + * "preprocessing number" ends and we have an actual expression. So the
> + * MUST_EXPAND macro must be expanded (who would have though?) in each case.
> */
> +123ef+MUST_EXPAND
> +.23E3-MUST_EXPAND
> +1.3e--MUST_EXPAND
> +12.E-&MUST_EXPAND
> +123p+OK+MUST_EXPAND
> +.23P+OK;MUST_EXPAND
> +1.3p-OK-MUST_EXPAND
> +12.P-OK&MUST_EXPAND
> diff --git a/src/glsl/g
[Mesa-dev] [PATCH v2] glsl: Fix aggregates with dynamic initializers.
From: Cody Northrop
Vectors are falling in to the ir_dereference_array() path.
Without this change, the following glsl aborts the debug driver,
or gets the wrong answer in release:
mat2x2 a = mat2( vec2( 1.0, vertex.x ), vec2( 0.0, 1.0 ) );
Also submitting piglit tests, will reference in bug.
v2: Rebase on Mesa master.
Signed-off-by: Cody Northrop
Reviewed-by: Courtney Goeltzenleuchter
Reviewed-by: Kenneth Graunke
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79373
---
src/glsl/ast_function.cpp | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
Hi Cody,
Your patch didn't apply to master due to Matt's foreach_list changes;
I did the obvious rebase. Otherwise, it looks great. Thanks for fixing
this and improving our tests!
I'll plan to commit this tomorrow unless anyone else has objections.
--Ken
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index cdb34cc..98288d2 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -743,10 +743,20 @@ process_vec_mat_constructor(exec_list *instructions,
int i = 0;
foreach_in_list(ir_rvalue, rhs, &actual_parameters) {
- ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
- new(ctx) ir_constant(i));
+ ir_instruction *assignment = NULL;
+
+ if (var->type->is_array() || var->type->is_matrix()) {
+ ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
+ new(ctx) ir_constant(i));
+ assignment = new(ctx) ir_assignment(lhs, rhs, NULL);
+ } else {
+ /* use writemask rather than index for vector */
+ assert(var->type->is_vector());
+ assert(i < 4);
+ ir_dereference *lhs = new(ctx) ir_dereference_variable(var);
+ assignment = new(ctx) ir_assignment(lhs, rhs, NULL, (unsigned)(1 <<
i));
+ }
- ir_instruction *assignment = new(ctx) ir_assignment(lhs, rhs, NULL);
instructions->push_tail(assignment);
i++;
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] target-helpers: don't use designated initializers
On 01/07/14 20:17, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
> in more places, in particular even for things buildable with msvc, and hence
> those break the build.
Microsoft were kind enough to finally add support for this C99 feature with
VC12 (msvc 2013). Any idea if/when you'll have the chance to update ?
Reviewed-by: Emil Velikov
> ---
> src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
> b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
> index a03db3a..3b36316 100644
> --- a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
> +++ b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
> @@ -210,13 +210,13 @@ dd_driver_name(void)
> }
>
> static const struct drm_conf_ret throttle_ret = {
> - .type = DRM_CONF_INT,
> - .val.val_int = 2,
> + DRM_CONF_INT,
> + {2},
> };
>
> static const struct drm_conf_ret share_fd_ret = {
> - .type = DRM_CONF_BOOL,
> - .val.val_int = true,
> + DRM_CONF_BOOL,
> + {true},
> };
>
> static const struct drm_conf_ret *
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] target-helpers: don't use designated initializers
Typically, updating our environment to use new compilers is not easy
because of various dependencies, etc. It'll probably be a while.
-Brian
On 07/01/2014 03:47 PM, Emil Velikov wrote:
On 01/07/14 20:17, srol...@vmware.com wrote:
From: Roland Scheidegger
it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
in more places, in particular even for things buildable with msvc, and hence
those break the build.
Microsoft were kind enough to finally add support for this C99 feature with
VC12 (msvc 2013). Any idea if/when you'll have the chance to update ?
Reviewed-by: Emil Velikov
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
index a03db3a..3b36316 100644
--- a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
+++ b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
@@ -210,13 +210,13 @@ dd_driver_name(void)
}
static const struct drm_conf_ret throttle_ret = {
- .type = DRM_CONF_INT,
- .val.val_int = 2,
+ DRM_CONF_INT,
+ {2},
};
static const struct drm_conf_ret share_fd_ret = {
- .type = DRM_CONF_BOOL,
- .val.val_int = true,
+ DRM_CONF_BOOL,
+ {true},
};
static const struct drm_conf_ret *
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=%2BIzcYkOcw5m%2FMCgCtnTawQatbAYAkdTxMw46bNdhy40%3D%0A&s=098d467738bddbd233ce9172f902c2bf335ea907b5e4e36450bfe89ae1b09931
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] glsl/glcpp: Alphabetize lists of start conditions
There is no behavioral change here. It's just easier to verify that lists
of start conditions include all expected conditions when they appear in a
consistent order.
The state is special, so it appears first in all lists. All others
appear in alphabetical order.
---
src/glsl/glcpp/glcpp-lex.l | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index 539b46c..e82b85d 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -165,7 +165,7 @@ glcpp_lex_update_state_per_token (glcpp_parser_t *parser,
int token)
* update the "Internal compiler error" catch-all rule near the end of
* this file. */
-%x DONE COMMENT HASH UNREACHABLE DEFINE NEWLINE_CATCHUP
+%x COMMENT DEFINE DONE HASH NEWLINE_CATCHUP UNREACHABLE
SPACE [[:space:]]
NONSPACE [^[:space:]]
@@ -253,7 +253,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
}
/* Multi-line comments */
-"/*" { yy_push_state(COMMENT, yyscanner); }
+"/*" { yy_push_state(COMMENT, yyscanner); }
[^*\r\n]*
[^*\r\n]*[\r\n]{ yylineno++; yycolumn = 0;
parser->commented_newlines++; }
"*"+[^*/\r\n]*
@@ -542,7 +542,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
* rule, then we have made a mistake above and need to fix one or more
* of the preceding patterns to match that input. */
-. {
+. {
glcpp_error(yylloc, yyextra, "Internal compiler error: Unexpected
character: %s", yytext);
}
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] glsl: Add flex options to eliminate the default rule
We've had bugs in the past where we have been inadvertently matching the
default rule.
Just as we did in the pre-processor in the previous commit, we can use:
%option warn nodefault
in the compiler to instruct flex to not generate the default rule, and
further to warn if our set of rules could let any characters go unmatched.
With this warning active, flex actually warns that the catch-all rule we
recently added to the compiler could never be matched. Since that is all
safely determined at compile time now, we can safely drop this run-time
compiler error message, (as we do in this commit).
---
src/glsl/glsl_lexer.ll | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index 1a0dde2..b7c4aad 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -152,6 +152,7 @@ literal_integer(char *text, int len, struct
_mesa_glsl_parse_state *state,
%option never-interactive
%option prefix="_mesa_glsl_lexer_"
%option extra-type="struct _mesa_glsl_parse_state *"
+%option warn nodefault
/* Note: When adding any start conditions to this list, you must also
* update the "Internal compiler error" catch-all rule near the end of
@@ -559,16 +560,6 @@ subroutine KEYWORD(0, 300, 0, 0, SUBROUTINE);
. { return yytext[0]; }
- /* This is a catch-all to avoid the annoying default flex action which
-* matches any character and prints it. If any input ever matches this
-* rule, then we have made a mistake above and need to fix one or more
-* of the preceding patterns to match that input. */
-. {
- _mesa_glsl_error(yylloc, yyextra,
- "Internal compiler error: Unexpected character: %s",
yytext);
-}
-
-
%%
int
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] glsl/glcpp: Add flex options to eliminate the default rule.
We've had multiple bugs in the past where we have been inadvertently matching
the default rule, (which we never want to do). We recently added a catch-all
rule to avoid this, (and made this rule robust for future start conditions).
Kristian pointed out that flex allows us to go one step better. This syntax:
%option warn nodefault
instructs flex to not generate the default rule at all. Further, flex will
generate a warning at compile time if the set of rules we provide are
inadequate, (such that it would be possible for the default rule to be
matched).
With this warning in place, I found that the catch-all rule was in fact
missing something. The catch-all rule uses a pattern of "." which doesn't
match newlines. So here we extend the newline-matching rule to all start
conditions. That is enough to convince flex that it really doesn't need
any default rule.
---
src/glsl/glcpp/glcpp-lex.l | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index 333d4ae..b2b109e 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -160,6 +160,7 @@ glcpp_lex_update_state_per_token (glcpp_parser_t *parser,
int token)
%option prefix="glcpp_"
%option stack
%option never-interactive
+%option warn nodefault
/* Note: When adding any start conditions to this list, you must also
* update the "Internal compiler error" catch-all rule near the end of
@@ -516,7 +517,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
/* We preserve all newlines, even between #if 0..#endif, so no
skipping.. */
-[\r\n] {
+<*>[\r\n] {
if (parser->commented_newlines) {
BEGIN NEWLINE_CATCHUP;
}
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] glsl/glcpp: Combine the two rules matching any character
Using a single rule here means that we can use the <*> syntax to match
all start conditions. This makes the catch-all rule more robust against
the addition of future start conditions, (no need to maintain an ever-
growing list of start conditions for this rul).
---
src/glsl/glcpp/glcpp-lex.l | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index e82b85d..333d4ae 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -542,17 +542,17 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
* rule, then we have made a mistake above and need to fix one or more
* of the preceding patterns to match that input. */
-. {
+<*>. {
glcpp_error(yylloc, yyextra, "Internal compiler error: Unexpected
character: %s", yytext);
-}
/* We don't actually use the UNREACHABLE start condition. We
- only have this action here so that we can pretend to call some
+ only have this block here so that we can pretend to call some
generated functions, (to avoid "defined but not used"
warnings. */
-. {
- unput('.');
- yy_top_state(yyextra);
+if (YY_START == UNREACHABLE) {
+ unput('.');
+ yy_top_state(yyextra);
+ }
}
%%
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 22/23] glsl/glcpp: Add a catch-all rule for unexpected characters.
Kristian Høgsberg writes: > Oh, I should have read the rest of the page - there's %option warn to > go with nodefault: > > warn about certain things. In particular, if the default rule can > be matched but no default rule has been given, the flex will warn > you. We recommend using this option always. > > which looks like flex can detect this condition at compile time and > warn about it. Thanks, Kristian! That's a very handy feature, and yes, it does work like you hoped. Flex can tell us at compile-time whether the set of rules we have will cover all characters and in all start conditions. I've just sent a little series of 4 patches to add these options to both glcpp and the main glsl compiler. (I would have sent them as replies, but I botched the git-send-email command yet again and they went out already). -Carl -- carl.d.wo...@intel.com pgplNO5qtElOl.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] target-helpers: don't use designated initializers
Am 01.07.2014 23:47, schrieb Emil Velikov:
> On 01/07/14 20:17, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
>> in more places, in particular even for things buildable with msvc, and hence
>> those break the build.
> Microsoft were kind enough to finally add support for this C99 feature with
> VC12 (msvc 2013).
Yeah I know. Only 15 years late...
> Any idea if/when you'll have the chance to update ?
I think there were some things preventing this to happen soon though I
can't remember the details...
Roland
>
> Reviewed-by: Emil Velikov
>> ---
>> src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
>> b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
>> index a03db3a..3b36316 100644
>> --- a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
>> +++ b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
>> @@ -210,13 +210,13 @@ dd_driver_name(void)
>> }
>>
>> static const struct drm_conf_ret throttle_ret = {
>> - .type = DRM_CONF_INT,
>> - .val.val_int = 2,
>> + DRM_CONF_INT,
>> + {2},
>> };
>>
>> static const struct drm_conf_ret share_fd_ret = {
>> - .type = DRM_CONF_BOOL,
>> - .val.val_int = true,
>> + DRM_CONF_BOOL,
>> + {true},
>> };
>>
>> static const struct drm_conf_ret *
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] i965/hiz: Start to separate miptree out from hiz buffers
Today we allocate a miptree's for the hiz buffer. We needed this in
the past because we would point the hardware at offsets of the hiz
buffer. Since the hiz format is not documented, this is not a good
idea.
Since moving to support layered rendering on Gen7+, we no longer point
at an offset into the buffer on Gen7+.
Therefore, to support hiz on Gen7+, we don't need a full miptree
structure allocated.
This patch starts to create a new auxiliary buffer structure
(intel_miptree_aux_buffer) that can be a more simplistic miptree
side-band buffer associated with a miptree. (For example, to serve the
needs of the hiz buffer.)
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_misc_state.c| 4 +-
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/gen7_misc_state.c | 2 +-
src/mesa/drivers/dri/i965/gen8_depth_state.c | 6 +--
src/mesa/drivers/dri/i965/intel_fbo.c | 4 +-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 55 +++
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 29 --
8 files changed, 76 insertions(+), 28 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..af900cd 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -182,7 +182,7 @@ brw_get_depthstencil_tile_masks(struct intel_mipmap_tree
*depth_mt,
if (intel_miptree_level_has_hiz(depth_mt, depth_level)) {
uint32_t hiz_tile_mask_x, hiz_tile_mask_y;
- intel_miptree_get_tile_masks(depth_mt->hiz_mt,
+ intel_miptree_get_tile_masks(depth_mt->hiz_buf->mt,
&hiz_tile_mask_x, &hiz_tile_mask_y,
false);
@@ -643,7 +643,7 @@ brw_emit_depth_stencil_hiz(struct brw_context *brw,
/* Emit hiz buffer. */
if (hiz) {
- struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_mt;
+ struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_buf->mt;
BEGIN_BATCH(3);
OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
OUT_BATCH(hiz_mt->pitch - 1);
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index eb865b9..282c7b2 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -855,7 +855,7 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
*brw,
/* 3DSTATE_HIER_DEPTH_BUFFER */
{
- struct intel_mipmap_tree *hiz_mt = params->depth.mt->hiz_mt;
+ struct intel_mipmap_tree *hiz_mt = params->depth.mt->hiz_buf->mt;
uint32_t hiz_offset =
intel_miptree_get_aligned_offset(hiz_mt,
draw_x & ~tile_mask_x,
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 0ad570b..d0d623d 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -752,7 +752,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
/* 3DSTATE_HIER_DEPTH_BUFFER */
{
- struct intel_mipmap_tree *hiz_mt = params->depth.mt->hiz_mt;
+ struct intel_mipmap_tree *hiz_mt = params->depth.mt->hiz_buf->mt;
BEGIN_BATCH(3);
OUT_BATCH((GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 22911bf..6c6a79b 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -145,7 +145,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
OUT_BATCH(0);
ADVANCE_BATCH();
} else {
- struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_mt;
+ struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_buf->mt;
BEGIN_BATCH(3);
OUT_BATCH(GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16 | (3 - 2));
OUT_BATCH((mocs << 25) |
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index 7c3bfe0..b6f373d 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -89,10 +89,10 @@ emit_depth_packets(struct brw_context *brw,
} else {
BEGIN_BATCH(5);
OUT_BATCH(GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16 | (5 - 2));
- OUT_BATCH((depth_mt->hiz_mt->pitch - 1) | BDW_MOCS_WB << 25);
- OUT_RELOC64(depth_mt->hiz_mt->bo,
+ OUT_BATCH((depth_mt->hiz_buf->mt->pitch - 1) | BDW_MOCS_WB << 25);
+ OUT_RELOC64(depth_mt->hiz_buf->mt->bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
- OUT_BATCH(depth_mt->hiz_mt->qpitch >> 2);
+ OUT_BATCH(depth_mt->hiz_buf->mt->qpitch >> 2);
ADVANCE_BATCH();
}
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drive
[Mesa-dev] [PATCH 2/6] i965/gen7: Don't rely directly on the hiz miptree structure
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp| 6 +++---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 7 ---
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index d0d623d..ebfe6d1 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -752,13 +752,13 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
/* 3DSTATE_HIER_DEPTH_BUFFER */
{
- struct intel_mipmap_tree *hiz_mt = params->depth.mt->hiz_buf->mt;
+ struct intel_miptree_aux_buffer *hiz_buf = params->depth.mt->hiz_buf;
BEGIN_BATCH(3);
OUT_BATCH((GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
OUT_BATCH((mocs << 25) |
-(hiz_mt->pitch - 1));
- OUT_RELOC(hiz_mt->bo,
+(hiz_buf->pitch - 1));
+ OUT_RELOC(hiz_buf->bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
0);
ADVANCE_BATCH();
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 6c6a79b..8f8c33e 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -145,12 +145,13 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
OUT_BATCH(0);
ADVANCE_BATCH();
} else {
- struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_buf->mt;
+ struct intel_miptree_aux_buffer *hiz_buf = depth_mt->hiz_buf;
+
BEGIN_BATCH(3);
OUT_BATCH(GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16 | (3 - 2));
OUT_BATCH((mocs << 25) |
-(hiz_mt->pitch - 1));
- OUT_RELOC(hiz_mt->bo,
+(hiz_buf->pitch - 1));
+ OUT_RELOC(hiz_buf->bo,
I915_GEM_DOMAIN_RENDER,
I915_GEM_DOMAIN_RENDER,
0);
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] i965/gen8: Enable hiz for all depth levels
After modifying the hiz buffer allocation and qpitch calculation, hiz
appears to work in all cases on gen8.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index e959b8c..3148821 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1355,7 +1355,7 @@ intel_miptree_level_enable_hiz(struct brw_context *brw,
{
assert(mt->hiz_buf);
- if (brw->gen >= 8 || brw->is_haswell) {
+ if (brw->is_haswell) {
uint32_t width = minify(mt->physical_width0, level);
uint32_t height = minify(mt->physical_height0, level);
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] i965/gen8: Don't allocate hiz miptree structure
We now skip allocating a hiz miptree for gen8. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index b308b0c..e959b8c 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1471,7 +1471,7 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
{
assert(mt->hiz_buf == NULL);
- if (brw->gen == 7) {
+ if (brw->gen >= 7) {
mt->hiz_buf = intel_hiz_buf_create(brw, mt);
} else {
mt->hiz_buf = intel_hiz_miptree_buf_create(brw, mt);
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/6] i965 gen7+ hiz buffer change; always enable gen8 hiz
The hiz buffer doesn't have a documented structure. Nevertheless, we allocate a miptree structure for the hiz buffer. In the past we relied on setting up the surface such that we had to point at an offset within the hiz buffer. For gen7+ we no longer do this. We now always point the surface to the beginning of the buffer. (For the surface, and for the hiz buffer.) This means that we can now stop allocating a miptree structure for gen7+. This also appears to fix a bug. In allocating the hiz buffer, the gen7 PRM says that the hiz buffer "Qpitch is computed using vertical alignment j=8." With our old strategy of allocating a miptree, we would only use a value of j=4. I suspect that this is what allows the "i965/gen8: Enable hiz for all depth levels" patch to work. No piglit regressions were seen on gen7 or gen8. This series is available in the non-miptree-hiz branch of: git://people.freedesktop.org/~jljusten/mesa Jordan Justen (6): i965/hiz: Start to separate miptree out from hiz buffers i965/gen7: Don't rely directly on the hiz miptree structure i965/gen8: Don't rely directly on the hiz miptree structure i965/gen7: Don't allocate hiz miptree structure i965/gen8: Don't allocate hiz miptree structure i965/gen8: Enable hiz for all depth levels src/mesa/drivers/dri/i965/brw_misc_state.c| 4 +- src/mesa/drivers/dri/i965/gen6_blorp.cpp | 2 +- src/mesa/drivers/dri/i965/gen7_blorp.cpp | 6 +- src/mesa/drivers/dri/i965/gen7_misc_state.c | 7 +- src/mesa/drivers/dri/i965/gen8_depth_state.c | 6 +- src/mesa/drivers/dri/i965/intel_fbo.c | 4 +- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 120 ++ src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 29 ++- 8 files changed, 145 insertions(+), 33 deletions(-) -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] i965/gen8: Don't rely directly on the hiz miptree structure
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen8_depth_state.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index b6f373d..8774595 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -89,10 +89,10 @@ emit_depth_packets(struct brw_context *brw,
} else {
BEGIN_BATCH(5);
OUT_BATCH(GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16 | (5 - 2));
- OUT_BATCH((depth_mt->hiz_buf->mt->pitch - 1) | BDW_MOCS_WB << 25);
- OUT_RELOC64(depth_mt->hiz_buf->mt->bo,
+ OUT_BATCH((depth_mt->hiz_buf->pitch - 1) | BDW_MOCS_WB << 25);
+ OUT_RELOC64(depth_mt->hiz_buf->bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
- OUT_BATCH(depth_mt->hiz_buf->mt->qpitch >> 2);
+ OUT_BATCH(depth_mt->hiz_buf->qpitch >> 2);
ADVANCE_BATCH();
}
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] i965/gen7: Don't allocate hiz miptree structure
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 67 ++-
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 8719c29..b308b0c 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -823,7 +823,10 @@ intel_miptree_release(struct intel_mipmap_tree **mt)
drm_intel_bo_unreference((*mt)->bo);
intel_miptree_release(&(*mt)->stencil_mt);
if ((*mt)->hiz_buf) {
- intel_miptree_release(&(*mt)->hiz_buf->mt);
+ if ((*mt)->hiz_buf->mt)
+intel_miptree_release(&(*mt)->hiz_buf->mt);
+ else
+drm_intel_bo_unreference((*mt)->hiz_buf->bo);
free((*mt)->hiz_buf);
}
intel_miptree_release(&(*mt)->mcs_mt);
@@ -1375,6 +1378,61 @@ intel_miptree_level_enable_hiz(struct brw_context *brw,
static struct intel_miptree_aux_buffer *
+intel_hiz_buf_create(struct brw_context *brw,
+ struct intel_mipmap_tree *mt)
+{
+ unsigned hz_width, hz_height;
+ unsigned H0, h0, h1, Z0;
+ const unsigned j = 8;
+ struct intel_miptree_aux_buffer *buf = calloc(sizeof(*buf), 1);
+
+ if (!buf)
+ return NULL;
+
+ H0 = mt->logical_height0;
+ h0 = ALIGN(H0, j);
+ h1 = ALIGN(minify(H0, 1), j);
+ Z0 = mt->logical_depth0;
+
+ buf->qpitch = h0 + h1 + (12 * j);
+
+ hz_width = ALIGN(mt->logical_width0, 16);
+
+ if (mt->target == GL_TEXTURE_3D) {
+ unsigned H_i = H0;
+ unsigned Z_i = Z0;
+ unsigned sum_h_i = 0;
+ hz_height = 0;
+ for (int level = mt->first_level; level <= mt->last_level; ++level) {
+ unsigned h_i = ALIGN(H_i, j);
+ hz_height += h_i * Z_i;
+ sum_h_i += h_i;
+ H_i = minify(H_i, 1);
+ Z_i = minify(Z_i, 1);
+ }
+ buf->qpitch = h0 + MAX2(h1, sum_h_i);
+ hz_height = ALIGN(hz_height, 2) >> 1;
+ } else {
+ hz_height = (ALIGN(buf->qpitch, 8) / 2) * Z0;
+ if (mt->target == GL_TEXTURE_CUBE_MAP_ARRAY ||
+ mt->target == GL_TEXTURE_CUBE_MAP) {
+ hz_height *= 6;
+ }
+ }
+
+ unsigned long pitch;
+ uint32_t tiling = I915_TILING_Y;
+ buf->bo = drm_intel_bo_alloc_tiled(brw->bufmgr, "hiz",
+ hz_width, hz_height, mt->cpp,
+ &tiling, &pitch,
+ BO_ALLOC_FOR_RENDER);
+ buf->pitch = pitch;
+
+ return buf;
+}
+
+
+static struct intel_miptree_aux_buffer *
intel_hiz_miptree_buf_create(struct brw_context *brw,
struct intel_mipmap_tree *mt)
{
@@ -1412,7 +1470,12 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
struct intel_mipmap_tree *mt)
{
assert(mt->hiz_buf == NULL);
- mt->hiz_buf = intel_hiz_miptree_buf_create(brw, mt);
+
+ if (brw->gen == 7) {
+ mt->hiz_buf = intel_hiz_buf_create(brw, mt);
+ } else {
+ mt->hiz_buf = intel_hiz_miptree_buf_create(brw, mt);
+ }
if (!mt->hiz_buf)
return false;
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Don't enable SOL statistics during meta operations.
The GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN counter is not supposed to
increment during glGenerateMipmap(). I don't think either counter is
supposed to increment during most meta operations, so simply turn off
statistics during those.
Fixes one Piglit test:
spec/EXT_transform_feedback/generatemipmap prims_written
Signed-off-by: Kenneth Graunke
Cc: Iago Toral Quiroga
Cc: Chris Forbes
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index 558b525..eccd5a5 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
@@ -240,7 +240,8 @@ upload_3dstate_streamout(struct brw_context *brw, bool
active,
* in each stream via SO_PRIMITIVE_STORAGE_NEEDED.
*/
dw1 |= SO_FUNCTION_ENABLE;
- dw1 |= SO_STATISTICS_ENABLE;
+ if (!brw->meta_in_progress)
+ dw1 |= SO_STATISTICS_ENABLE;
if (active) {
int urb_entry_read_offset = 0;
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Disable SOL buffers and decls when not doing transform feedback.
Previously, we only emitted 3DSTATE_SO_BUFFER and 3DSTATE_SO_DECL_LIST
when transform feedback was active. When it was inactive, we disabled
the SOL stage in 3DSTATE_SOL so the other state would be ignored.
In commit 3178d2474ae5bdd1102fb3d76a60d1d63c961ff5, Iago enabled the SOL
stage universally, so we could implement the GL_PRIMITIVES_GENERATED
statistics counter. This caused every Piglit test to trigger assertions
in the simulator, and apparently caused GPU hangs for some users.
Apparently, we're supposed to program 3DSTATE_SO_DECL_LIST to zero when
output streams are inactive, but we hadn't been doing so. Now that SOL
is on, we need to do that properly.
Experimentally, it looks like we also need to program 3DSTATE_SO_BUFFER
to zero as well, or else I get many GPU hangs on Haswell.
Signed-off-by: Kenneth Graunke
Cc: Iago Toral Quiroga
Cc: Chris Forbes
Cc: Steven Newbury
---
src/mesa/drivers/dri/i965/brw_state.h | 3 ++-
src/mesa/drivers/dri/i965/gen7_sol_state.c | 34 ++
src/mesa/drivers/dri/i965/gen8_sol_state.c | 2 +-
3 files changed, 28 insertions(+), 11 deletions(-)
Iago,
I noticed that pretty much every Piglit test broke in our simulation
environment after your patch to turn on SOL by default. Something about
SO_DECLs not being right. This patch seems to fix the issue. Does it
look reasonable to you?
Steven,
Does this fix your GPU hangs on Ivybridge?
Thanks!
--Ken
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index c52a977..2c1fc87 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -237,7 +237,8 @@ void gen7_init_vtable_surface_functions(struct brw_context
*brw);
/* gen7_sol_state.c */
void gen7_upload_3dstate_so_decl_list(struct brw_context *brw,
- const struct brw_vue_map *vue_map);
+ const struct brw_vue_map *vue_map,
+ bool active);
/* gen8_surface_state.c */
void gen8_init_vtable_surface_functions(struct brw_context *brw);
diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index eccd5a5..e2eb334 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
@@ -36,7 +36,7 @@
#include "main/transformfeedback.h"
static void
-upload_3dstate_so_buffers(struct brw_context *brw)
+upload_3dstate_so_buffers(struct brw_context *brw, bool active)
{
struct gl_context *ctx = &brw->ctx;
/* BRW_NEW_TRANSFORM_FEEDBACK */
@@ -56,7 +56,7 @@ upload_3dstate_so_buffers(struct brw_context *brw)
uint32_t start, end;
uint32_t stride;
- if (!xfb_obj->Buffers[i]) {
+ if (!xfb_obj->Buffers[i] || !active) {
/* The pitch of 0 in this command indicates that the buffer is
* unbound and won't be written to.
*/
@@ -96,10 +96,28 @@ upload_3dstate_so_buffers(struct brw_context *brw)
*/
void
gen7_upload_3dstate_so_decl_list(struct brw_context *brw,
- const struct brw_vue_map *vue_map)
+ const struct brw_vue_map *vue_map,
+ bool active)
{
- struct gl_context *ctx = &brw->ctx;
+ if (!active) {
+ /* If inactive, disable all SO outputs.
+ *
+ * From the Ivybridge PRM, Volume 2, Part 1, page 202
+ * (3DSTATE_SO_DECL_LIST packet definition), DWord 1, bits 3:0:
+ * "Note: For 'inactive' streams, software must program this field to
+ * all zero (no buffers written to) and the corresponding Num Entries
+ * field to zero (no valid SO_DECLs)."
+ */
+ BEGIN_BATCH(3);
+ OUT_BATCH(_3DSTATE_SO_DECL_LIST << 16 | (3 - 2));
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ return;
+ }
+
/* BRW_NEW_TRANSFORM_FEEDBACK */
+ struct gl_context *ctx = &brw->ctx;
struct gl_transform_feedback_object *xfb_obj =
ctx->TransformFeedback.CurrentObject;
const struct gl_transform_feedback_info *linked_xfb_info =
@@ -289,11 +307,9 @@ upload_sol_state(struct brw_context *brw)
/* BRW_NEW_TRANSFORM_FEEDBACK */
bool active = _mesa_is_xfb_active_and_unpaused(ctx);
- if (active) {
- upload_3dstate_so_buffers(brw);
- /* BRW_NEW_VUE_MAP_GEOM_OUT */
- gen7_upload_3dstate_so_decl_list(brw, &brw->vue_map_geom_out);
- }
+ upload_3dstate_so_buffers(brw, active);
+ /* BRW_NEW_VUE_MAP_GEOM_OUT */
+ gen7_upload_3dstate_so_decl_list(brw, &brw->vue_map_geom_out, active);
/* Finally, set up the SOL stage. This command must always follow updates
to
* the nonpipelined SOL state (3DSTATE_SO_BUFFER, 3DSTATE_SO_DECL_LIST) or
diff --git a/src/mesa/drivers/dri/i965/gen8_sol_state.c
b/src/mesa/drivers/dri/i965/gen8_sol_state.c
index ebcdaf8..ff85bf2 100644
--- a/src/mesa/drivers/dri/i965/gen8_sol_state.c
+++ b
Re: [Mesa-dev] [PATCH 1/4] glsl/glcpp: Alphabetize lists of start conditions
On Tuesday, July 01, 2014 03:25:49 PM Carl Worth wrote:
> There is no behavioral change here. It's just easier to verify that lists
> of start conditions include all expected conditions when they appear in a
> consistent order.
>
> The state is special, so it appears first in all lists. All others
> appear in alphabetical order.
> ---
> src/glsl/glcpp/glcpp-lex.l | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
> index 539b46c..e82b85d 100644
> --- a/src/glsl/glcpp/glcpp-lex.l
> +++ b/src/glsl/glcpp/glcpp-lex.l
> @@ -165,7 +165,7 @@ glcpp_lex_update_state_per_token (glcpp_parser_t
*parser, int token)
>* update the "Internal compiler error" catch-all rule near the end of
>* this file. */
>
> -%x DONE COMMENT HASH UNREACHABLE DEFINE NEWLINE_CATCHUP
> +%x COMMENT DEFINE DONE HASH NEWLINE_CATCHUP UNREACHABLE
>
> SPACE[[:space:]]
> NONSPACE [^[:space:]]
> @@ -253,7 +253,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
> }
>
> /* Multi-line comments */
> -"/*" { yy_push_state(COMMENT, yyscanner); }
> +"/*" { yy_push_state(COMMENT, yyscanner); }
> [^*\r\n]*
> [^*\r\n]*[\r\n]{ yylineno++; yycolumn = 0; parser-
>commented_newlines++; }
> "*"+[^*/\r\n]*
> @@ -542,7 +542,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
>* rule, then we have made a mistake above and need to fix one or more
>* of the preceding patterns to match that input. */
>
> -. {
> +. {
> glcpp_error(yylloc, yyextra, "Internal compiler error: Unexpected
character: %s", yytext);
> }
>
>
This four part series is:
Reviewed-by: Kenneth Graunke
krh - nice find on the %option warn nodefault! That's really useful.
Carl - thanks for doing this!
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] texstore: Add a generic implementation of GL_ARB_clear_texture
On Tue, Jul 1, 2014 at 2:06 PM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
>>> +static void
>>> +clear_image_to_zero(GLubyte *dstMap, GLint dstRowStride,
>>> +GLsizei width, GLsizei height,
>>> +GLsizei clearValueSize)
>>> +{
>>> + while (height-- > 0) {
>>> + memset(dstMap, 0, clearValueSize * width);
>>> + dstMap += dstRowStride;
>>> + }
>>> +}
>>>
>>
>> Technically, this should always work, but you might want to throw in a
>> comment about floating-point textures.
>
> I'm not sure what you mean here. Are you saying that hypothetically
> floating-point textures might not represent 0 as zero bytes?
Not entirely sure how to interpret what the spec says, but something
to potentially consider is MESA_ycbcr_texture (supported by swrast).
RGBA 0 (black) != 0 in ycbcr... all 0's there are a green color.
Also probably not _too_ important to worry too much about, just wanted
to point it out.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] glsl/glcpp: Allow single-line comments immediately after #define
We were already correctly supporting single-line comments in case like:
#define FOO bar // comment here...
The new support added here is simply for the none-too-useful:
#define // comment instead of macro name
With this commit, this line will now give the expected "#define without
macro name" error message instead of the lexer just going off into the
weeds.
---
src/glsl/glcpp/glcpp-lex.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index 8b4be64..09dba35 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -251,7 +251,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
}
/* Single-line comments */
-"//"[^\r\n]* {
+"//"[^\r\n]* {
}
/* Multi-line comments */
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] glsl/glcpp: Add tests for #define followed by comments
This simply tests the previous commit, (that #define followed by a comment will still generate the expected "#define without macro name" error message). --- src/glsl/glcpp/tests/139-define-without-macro-name.c | 5 - src/glsl/glcpp/tests/139-define-without-macro-name.c.expected | 5 - 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/glsl/glcpp/tests/139-define-without-macro-name.c b/src/glsl/glcpp/tests/139-define-without-macro-name.c index de3ed98..30e128d 100644 --- a/src/glsl/glcpp/tests/139-define-without-macro-name.c +++ b/src/glsl/glcpp/tests/139-define-without-macro-name.c @@ -1,2 +1,5 @@ #define -Error expected because no macro name is ever given! +#define +#define /*...*/ +#define //... +Errors expected because no macro name is ever given! diff --git a/src/glsl/glcpp/tests/139-define-without-macro-name.c.expected b/src/glsl/glcpp/tests/139-define-without-macro-name.c.expected index 000aeaf..42b02d1 100644 --- a/src/glsl/glcpp/tests/139-define-without-macro-name.c.expected +++ b/src/glsl/glcpp/tests/139-define-without-macro-name.c.expected @@ -1,2 +1,5 @@ 0:1(1): preprocessor error: #define without macro name -Error expected because no macro name is ever given! +0:2(1): preprocessor error: #define without macro name +0:3(1): preprocessor error: #define without macro name +0:4(1): preprocessor error: #define without macro name +Errors expected because no macro name is ever given! -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] glsl/glcpp: Add testing for null directives with spaces and comments
This new "make check" test stresses out the support from the last two commits, (to esnure that '#' is correctly interpreted as the null directives, regardless of any whitespace or comments on the same line). --- src/glsl/glcpp/tests/138-null-directive.c | 9 + src/glsl/glcpp/tests/138-null-directive.c.expected | 9 + 2 files changed, 18 insertions(+) create mode 100644 src/glsl/glcpp/tests/138-null-directive.c create mode 100644 src/glsl/glcpp/tests/138-null-directive.c.expected diff --git a/src/glsl/glcpp/tests/138-null-directive.c b/src/glsl/glcpp/tests/138-null-directive.c new file mode 100644 index 000..1dcb26e --- /dev/null +++ b/src/glsl/glcpp/tests/138-null-directive.c @@ -0,0 +1,9 @@ +/* GLSL accepts a null directive. Let's test that in several variations: */ +# +# +/**/#/**/ + /*..*/ # /*..*/ +#//... +# //... +/**/#/**///.. + /*..*/ # /**/ // diff --git a/src/glsl/glcpp/tests/138-null-directive.c.expected b/src/glsl/glcpp/tests/138-null-directive.c.expected new file mode 100644 index 000..fa103f6 --- /dev/null +++ b/src/glsl/glcpp/tests/138-null-directive.c.expected @@ -0,0 +1,9 @@ + + + + + + + + + -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] glsl/glcpp: Fix null directive when followed by whitespace
We accidentally had support for null directives, (that is, a line with "#" and
nothing else) in two places: the lexer and the parser.
The support in the lexer was broken, (expecting the '#' to be followed
immediately by a newline), so it caused failures if the '#' was followed
immediately by whitespace before the newline.
So all we have to do here is to remove the rule from the lexer so that the
parser's correct rule can actuall see and handle the null directive.
---
src/glsl/glcpp/glcpp-lex.l | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index 09dba35..1537694 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -381,11 +381,6 @@ HEXADECIMAL_INTEGER0[xX][0-9a-fA-F]+[uU]?
RETURN_TOKEN (UNDEF);
}
-{NEWLINE} {
- BEGIN INITIAL;
- RETURN_TOKEN (HASH_TOKEN);
-}
-
{HSPACE}+ {
/* Nothing to do here. Importantly, don't leave the
* start condition, since it's legal to have space between the
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] glsl/glcpp: Add test for "#define without macro name"
This ensures that the previous commit indeed generates the expected error message when a "#define" directive is not followed by anything except for a newline. --- src/glsl/glcpp/tests/139-define-without-macro-name.c | 2 ++ src/glsl/glcpp/tests/139-define-without-macro-name.c.expected | 2 ++ 2 files changed, 4 insertions(+) create mode 100644 src/glsl/glcpp/tests/139-define-without-macro-name.c create mode 100644 src/glsl/glcpp/tests/139-define-without-macro-name.c.expected diff --git a/src/glsl/glcpp/tests/139-define-without-macro-name.c b/src/glsl/glcpp/tests/139-define-without-macro-name.c new file mode 100644 index 000..de3ed98 --- /dev/null +++ b/src/glsl/glcpp/tests/139-define-without-macro-name.c @@ -0,0 +1,2 @@ +#define +Error expected because no macro name is ever given! diff --git a/src/glsl/glcpp/tests/139-define-without-macro-name.c.expected b/src/glsl/glcpp/tests/139-define-without-macro-name.c.expected new file mode 100644 index 000..000aeaf --- /dev/null +++ b/src/glsl/glcpp/tests/139-define-without-macro-name.c.expected @@ -0,0 +1,2 @@ +0:1(1): preprocessor error: #define without macro name +Error expected because no macro name is ever given! -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] glsl/glcpp: Fix NULL directives when followed by a single-line comment
This is the fix for the following line:
# // comment to ignore here
According to the translation-phase rules, the comment should be removed before
the preprocessor looks to interpret the null directive.
So in our implementation we must explicitly look for single-line comments in
the start condition as well.
This commit fixes the following Khronos GLES3 CTS tests:
null_directive_vertex
null_directive_fragment
---
src/glsl/glcpp/glcpp-lex.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index 1537694..0f5371f 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -251,7 +251,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
}
/* Single-line comments */
-"//"[^\r\n]* {
+"//"[^\r\n]* {
}
/* Multi-line comments */
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: allow viewport index/layer to be sent to fs
On 02.07.2014 01:25, Marek Olšák wrote: > If the tests pass, the patch can be merged. And if the patch causes no piglit regressions. -- 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 v2] r600g: allow viewport index/layer to be sent to fs
On Tue, Jul 1, 2014 at 9:23 PM, Michel Dänzer wrote: > On 02.07.2014 01:25, Marek Olšák wrote: >> If the tests pass, the patch can be merged. > > And if the patch causes no piglit regressions. I can't vouch for that. I have a report that the ARB_fragment_layer_viewport-specific tests pass on a card covered by r600g (evergreen iirc). I've put that Tested-by tag in my commit description. Besides an ATI Rage128 sitting on my shelf, I have no ATI/AMD hardware to test with myself, and I don't want to go around soliciting people running piglit for me since (a) extracting glxinfos out of people is hard enough, getting someone to do a piglit run seems way harder, and (b) piglit runs can kill the system, most users aren't too happy about things like that. TBH, I don't really care whether r600g gets this feature or not, but it would be nice if all the other drivers that have ARB_viewport_array could get it. Basically... do I need to add a CAP for this or not? I don't really care either way, but it would be really nice to get a definitive answer. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: pass in per-sample interpolation qualifier
Signed-off-by: Ilia Mirkin
---
Not sure if this is the right approach or if I should combine it with Centroid
more directly. More modifications will be required wrt per-sample shading
since we'll need to distinguish the min samples case where everything is
per-sample-interpolated vs this case where only some inputs are to be
sample-interpolated but the min samples would still be > 1. (Perhaps that case
should be handled by instead manually annotating each input as
per-sample-interpolated and sticking the overall per-sample-shading into a
variant key. This is roughly what i965 does.)
But I thought I'd send this out to get some early feedback.
src/gallium/auxiliary/tgsi/tgsi_dump.c | 4
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 12 +---
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 7 ---
src/gallium/include/pipe/p_shader_tokens.h | 3 ++-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 +-
src/mesa/state_tracker/st_glsl_to_tgsi.h | 1 +
src/mesa/state_tracker/st_program.c| 5 +
7 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index 8e09bac..cce7858 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_dump.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c
@@ -353,6 +353,10 @@ iter_declaration(
TXT( ", CENTROID" );
}
+ if (decl->Interp.Sample) {
+ TXT( ", SAMPLE" );
+ }
+
if (decl->Interp.CylindricalWrap) {
TXT(", CYLWRAP_");
if (decl->Interp.CylindricalWrap & TGSI_CYLINDRICAL_WRAP_X) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index bd0a3f7..b21339e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -104,6 +104,7 @@ struct ureg_program
unsigned interp;
unsigned char cylindrical_wrap;
unsigned char centroid;
+ unsigned char sample;
} fs_input[UREG_MAX_INPUT];
unsigned nr_fs_inputs;
@@ -345,7 +346,8 @@ ureg_DECL_fs_input_cyl_centroid(struct ureg_program *ureg,
unsigned semantic_index,
unsigned interp_mode,
unsigned cylindrical_wrap,
- unsigned centroid)
+ unsigned centroid,
+ unsigned sample)
{
unsigned i;
@@ -362,6 +364,7 @@ ureg_DECL_fs_input_cyl_centroid(struct ureg_program *ureg,
ureg->fs_input[i].interp = interp_mode;
ureg->fs_input[i].cylindrical_wrap = cylindrical_wrap;
ureg->fs_input[i].centroid = centroid;
+ ureg->fs_input[i].sample = sample;
ureg->nr_fs_inputs++;
} else {
set_bad(ureg);
@@ -1288,7 +1291,8 @@ emit_decl_fs(struct ureg_program *ureg,
unsigned semantic_index,
unsigned interpolate,
unsigned cylindrical_wrap,
- unsigned centroid)
+ unsigned centroid,
+ unsigned sample)
{
union tgsi_any_token *out = get_tokens(ureg, DOMAIN_DECL, 4);
@@ -1308,6 +1312,7 @@ emit_decl_fs(struct ureg_program *ureg,
out[2].decl_interp.Interpolate = interpolate;
out[2].decl_interp.CylindricalWrap = cylindrical_wrap;
out[2].decl_interp.Centroid = centroid;
+ out[2].decl_interp.Sample = sample;
out[3].value = 0;
out[3].decl_semantic.Name = semantic_name;
@@ -1539,7 +1544,8 @@ static void emit_decls( struct ureg_program *ureg )
ureg->fs_input[i].semantic_index,
ureg->fs_input[i].interp,
ureg->fs_input[i].cylindrical_wrap,
- ureg->fs_input[i].centroid);
+ ureg->fs_input[i].centroid,
+ ureg->fs_input[i].sample);
}
} else {
for (i = 0; i < ureg->nr_gs_inputs; i++) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index 28edea6..d1f37e0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -199,7 +199,8 @@ ureg_DECL_fs_input_cyl_centroid(struct ureg_program *,
unsigned semantic_index,
unsigned interp_mode,
unsigned cylindrical_wrap,
- unsigned centroid);
+ unsigned centroid,
+ unsigned sample);
static INLINE struct ureg_src
ureg_DECL_fs_input_cyl(struct ureg_program *ureg,
@@ -213,7 +214,7 @@ ureg_DECL_fs_input_cyl(struct ureg_program *ureg,
semantic_index,
interp_mode,
cylindrical_wrap,
- 0);
+ 0, 0);
}
static INLINE struct ureg_src
@@ -226,7 +227,7 @@ ureg_DECL_fs_input(struct ureg_program *ureg,
semantic_name,
Re: [Mesa-dev] Mesa (master): st/mesa: fix incorrect size of UBO declarations
On 02.07.2014 00:43, Brian Paul wrote:
> Module: Mesa
> Branch: master
> Commit: f4b0ab7afd83c811329211eae8167c9bf238870c
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f4b0ab7afd83c811329211eae8167c9bf238870c
>
> Author: Brian Paul
> Date: Tue Jul 1 08:17:09 2014 -0600
>
> st/mesa: fix incorrect size of UBO declarations
>
> UniformBufferSize is in bytes so we need to divide by 16 to get the
> number of constant buffer slots. Also, the ureg_DECL_constant2D()
> function takes first..last parameters so we need to subtract one
> for the last value.
This change broke the GLSL uniform_buffer fs/vs/gs-struct-pad piglit
tests with radeonsi:
../../../../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:306:lp_build_emit_fetch:
Assertion `reg->Register.Index <=
bld_base->info->file_max[reg->Register.File]' failed.
AFAICT reg->Register.Index is 2, and the new code calls
ureg_DECL_constant2D() with last=1. This is the TGSI code:
FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL OUT[0], COLOR
DCL CONST[1][0..1]
DCL TEMP[0], LOCAL
IMM[0] UINT32 {0, 16, 32, 0}
0: MOV TEMP[0].x, CONST[1][0].
1: MOV TEMP[0].y, CONST[1][1].
2: MOV TEMP[0].z, CONST[1][2].
3: MOV TEMP[0].w, CONST[1][2].
4: MOV OUT[0], TEMP[0]
5: END
which results from this GLSL code:
#version 140
struct S1 {
float r;
};
struct S2 {
float g;
float b;
float a;
};
struct S {
S1 s1;
S2 s2;
};
uniform ubo1 {
S s;
};
void main()
{
gl_FragColor = vec4(s.s1.r, s.s2.g, s.s2.b, s.s2.a);
}
Something doesn't seem to add up, but I'm not sure where exactly the
problem is or how to fix it.
--
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 2/2] i965: Disable SOL buffers and decls when not doing transform feedback.
Should this be i965/gen7? (Seems to be a no-op for gen8.)
Series Reviewed-by: Jordan Justen
Speaking of xfb and gen8, I rebased a ~week old branch today, and saw
two regressions:
spec/EXT_transform_feedback/primgen-query transform-feedback-disabled: pass fail
spec/ARB_transform_feedback2/counting with pause: pass fail
-Jordan
On Tue, Jul 1, 2014 at 5:25 PM, Kenneth Graunke wrote:
> Previously, we only emitted 3DSTATE_SO_BUFFER and 3DSTATE_SO_DECL_LIST
> when transform feedback was active. When it was inactive, we disabled
> the SOL stage in 3DSTATE_SOL so the other state would be ignored.
>
> In commit 3178d2474ae5bdd1102fb3d76a60d1d63c961ff5, Iago enabled the SOL
> stage universally, so we could implement the GL_PRIMITIVES_GENERATED
> statistics counter. This caused every Piglit test to trigger assertions
> in the simulator, and apparently caused GPU hangs for some users.
>
> Apparently, we're supposed to program 3DSTATE_SO_DECL_LIST to zero when
> output streams are inactive, but we hadn't been doing so. Now that SOL
> is on, we need to do that properly.
>
> Experimentally, it looks like we also need to program 3DSTATE_SO_BUFFER
> to zero as well, or else I get many GPU hangs on Haswell.
>
> Signed-off-by: Kenneth Graunke
> Cc: Iago Toral Quiroga
> Cc: Chris Forbes
> Cc: Steven Newbury
> ---
> src/mesa/drivers/dri/i965/brw_state.h | 3 ++-
> src/mesa/drivers/dri/i965/gen7_sol_state.c | 34
> ++
> src/mesa/drivers/dri/i965/gen8_sol_state.c | 2 +-
> 3 files changed, 28 insertions(+), 11 deletions(-)
>
> Iago,
>
> I noticed that pretty much every Piglit test broke in our simulation
> environment after your patch to turn on SOL by default. Something about
> SO_DECLs not being right. This patch seems to fix the issue. Does it
> look reasonable to you?
>
> Steven,
>
> Does this fix your GPU hangs on Ivybridge?
>
> Thanks!
> --Ken
>
> diff --git a/src/mesa/drivers/dri/i965/brw_state.h
> b/src/mesa/drivers/dri/i965/brw_state.h
> index c52a977..2c1fc87 100644
> --- a/src/mesa/drivers/dri/i965/brw_state.h
> +++ b/src/mesa/drivers/dri/i965/brw_state.h
> @@ -237,7 +237,8 @@ void gen7_init_vtable_surface_functions(struct
> brw_context *brw);
>
> /* gen7_sol_state.c */
> void gen7_upload_3dstate_so_decl_list(struct brw_context *brw,
> - const struct brw_vue_map *vue_map);
> + const struct brw_vue_map *vue_map,
> + bool active);
>
> /* gen8_surface_state.c */
> void gen8_init_vtable_surface_functions(struct brw_context *brw);
> diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
> b/src/mesa/drivers/dri/i965/gen7_sol_state.c
> index eccd5a5..e2eb334 100644
> --- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
> @@ -36,7 +36,7 @@
> #include "main/transformfeedback.h"
>
> static void
> -upload_3dstate_so_buffers(struct brw_context *brw)
> +upload_3dstate_so_buffers(struct brw_context *brw, bool active)
> {
> struct gl_context *ctx = &brw->ctx;
> /* BRW_NEW_TRANSFORM_FEEDBACK */
> @@ -56,7 +56,7 @@ upload_3dstate_so_buffers(struct brw_context *brw)
>uint32_t start, end;
>uint32_t stride;
>
> - if (!xfb_obj->Buffers[i]) {
> + if (!xfb_obj->Buffers[i] || !active) {
> /* The pitch of 0 in this command indicates that the buffer is
> * unbound and won't be written to.
> */
> @@ -96,10 +96,28 @@ upload_3dstate_so_buffers(struct brw_context *brw)
> */
> void
> gen7_upload_3dstate_so_decl_list(struct brw_context *brw,
> - const struct brw_vue_map *vue_map)
> + const struct brw_vue_map *vue_map,
> + bool active)
> {
> - struct gl_context *ctx = &brw->ctx;
> + if (!active) {
> + /* If inactive, disable all SO outputs.
> + *
> + * From the Ivybridge PRM, Volume 2, Part 1, page 202
> + * (3DSTATE_SO_DECL_LIST packet definition), DWord 1, bits 3:0:
> + * "Note: For 'inactive' streams, software must program this field to
> + * all zero (no buffers written to) and the corresponding Num Entries
> + * field to zero (no valid SO_DECLs)."
> + */
> + BEGIN_BATCH(3);
> + OUT_BATCH(_3DSTATE_SO_DECL_LIST << 16 | (3 - 2));
> + OUT_BATCH(0);
> + OUT_BATCH(0);
> + ADVANCE_BATCH();
> + return;
> + }
> +
> /* BRW_NEW_TRANSFORM_FEEDBACK */
> + struct gl_context *ctx = &brw->ctx;
> struct gl_transform_feedback_object *xfb_obj =
>ctx->TransformFeedback.CurrentObject;
> const struct gl_transform_feedback_info *linked_xfb_info =
> @@ -289,11 +307,9 @@ upload_sol_state(struct brw_context *brw)
> /* BRW_NEW_TRANSFORM_FEEDBACK */
> bool active = _mesa_is_xfb_active_and_unpaused(ctx);
>
> - if (active) {
> - upload_3dstate_so_buffers(brw);
> - /* BR
Re: [Mesa-dev] [PATCH 2/2] i965: Disable SOL buffers and decls when not doing transform feedback.
On Tuesday, July 01, 2014 08:26:48 PM Jordan Justen wrote: > Should this be i965/gen7? (Seems to be a no-op for gen8.) > > Series Reviewed-by: Jordan Justen > > Speaking of xfb and gen8, I rebased a ~week old branch today, and saw > two regressions: > spec/EXT_transform_feedback/primgen-query transform-feedback-disabled: pass fail > spec/ARB_transform_feedback2/counting with pause: pass fail > > -Jordan Yeah, we need to port Iago's changes to gen8_sol_state.c as well. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: allow viewport index/layer to be sent to fs
Hi, I did a piglit run with the gpu.py profile with and without the patch. There were some switches from pass->fail and fail->pass in spec/glsl-1.50/execution/geometry/end-primitive but these seem to not be stable, because after a second with and without a patch different tests from this category pass/fail (in both cases with and without the patch). I also ran these without "-fbo -auto" and there was no visible difference in the images but the test still failed. This was also discusses in IRC #dri- devel. Other than that I also ran the newly added piglit tests for ARB_fragment_layer_viewport-specific and they all pass or skip. This was all done with a Evergreen/Juniper card. Tobias Am Di, 1. Juli 2014, 21:38:10 schrieb Ilia Mirkin: > On Tue, Jul 1, 2014 at 9:23 PM, Michel Dänzer wrote: > > On 02.07.2014 01:25, Marek Olšák wrote: > >> If the tests pass, the patch can be merged. > > > > And if the patch causes no piglit regressions. > > I can't vouch for that. I have a report that the > ARB_fragment_layer_viewport-specific tests pass on a card covered by > r600g (evergreen iirc). I've put that Tested-by tag in my commit > description. Besides an ATI Rage128 sitting on my shelf, I have no > ATI/AMD hardware to test with myself, and I don't want to go around > soliciting people running piglit for me since (a) extracting glxinfos > out of people is hard enough, getting someone to do a piglit run seems > way harder, and (b) piglit runs can kill the system, most users aren't > too happy about things like that. > > TBH, I don't really care whether r600g gets this feature or not, but > it would be nice if all the other drivers that have ARB_viewport_array > could get it. Basically... do I need to add a CAP for this or not? I > don't really care either way, but it would be really nice to get a > definitive answer. > > Cheers, > > -ilia > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
