Re: [Mesa-dev] [PATCH] glsl/dead_builin_varyings: Fix gl_FragData array lowering
On Mon, 2015-11-30 at 09:56 +0200, Tapani Pälli wrote:
> Hi;
>
> On 11/27/2015 02:14 PM, Iago Toral Quiroga wrote:
> > The current implementation looks for array dereferences on gl_FragData and
> > immediately then proceeds to lower them, however this is not enough because
> > we can have array access on vector variables too, like in this code:
> >
> > out vec4 color;
> > void main()
> > {
> > int i;
> > for (i = 0; i < 4; i++)
> >color[i] = 1.0;
> > }
> >
> > Fix it by making sure that the actual variable being dereferenced is an
> > array.
> >
> > Fixes a crash in:
> > spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-ldexp-dvec4.shader_test
>
> Instead of asserting in IR validation now we assert in backend because
> array 'should have been lowered' .. is there some other patches that
> should be bundled together with this to make it work?
Yes, notice that this is a fp64 test, which is not implemented in i965
yet. There is a development branch here if you want to try it:
https://github.com/Igalia/mesa/tree/i965-fp64-v5-testing
and with that branch (which includes this patch) the test does not crash
any more (it still fails though).
Iago
> > ---
> > src/glsl/opt_dead_builtin_varyings.cpp | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/glsl/opt_dead_builtin_varyings.cpp
> > b/src/glsl/opt_dead_builtin_varyings.cpp
> > index 68b70ee..5387113 100644
> > --- a/src/glsl/opt_dead_builtin_varyings.cpp
> > +++ b/src/glsl/opt_dead_builtin_varyings.cpp
> > @@ -85,7 +85,7 @@ public:
> > {
> > ir_variable *var = ir->variable_referenced();
> >
> > - if (!var || var->data.mode != this->mode)
> > + if (!var || var->data.mode != this->mode || !var->type->is_array())
> >return visit_continue;
> >
> > if (this->find_frag_outputs && var->data.location ==
> > FRAG_RESULT_DATA0) {
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 28/42] i965/fs: Handle nir shared variable store intrinsic function
On 2015-11-25 03:07:42, Iago Toral wrote:
> On Tue, 2015-11-17 at 21:55 -0800, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen
> > ---
> > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 54
> >
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > index e9336fd..c8c6370 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > @@ -2330,6 +2330,60 @@ fs_visitor::nir_emit_intrinsic(const fs_builder
> > &bld, nir_intrinsic_instr *instr
> >break;
> > }
> >
> > + case nir_intrinsic_store_shared_indirect:
> > + has_indirect = true;
> > + /* fallthrough */
> > + case nir_intrinsic_store_shared: {
> > + assert(devinfo->gen >= 7);
> > +
> > + /* Block index */
> > + fs_reg surf_index;
> > + unsigned index = BRW_SLM_SURFACE_INDEX;
> > + surf_index = fs_reg(index);
>
> We don't need the index variable here. Also, this needs to be rebased on
> top of Matt's changes, so you can just do:
>
> fs_reg surf_index = brw_imm_ud(BRW_SLM_SURFACE_INDEX);
>
> Also, you need to do the same in the previous patch.
Yeah, I had to fix this up after rebasing on Matt's patches.
>
> > + /* Offset */
> > + fs_reg offset_reg = vgrf(glsl_type::uint_type);
> > + unsigned const_offset_bytes = 0;
> > + if (has_indirect) {
> > + bld.MOV(offset_reg, get_nir_src(instr->src[1]));
> > + } else {
> > + const_offset_bytes = instr->const_index[0];
> > + bld.MOV(offset_reg, fs_reg(const_offset_bytes));
> > + }
> > +
> > + /* Value */
> > + fs_reg val_reg = get_nir_src(instr->src[0]);
> > +
> > + /* Writemask */
> > + unsigned writemask = instr->const_index[1];
> > +
> > + /* Write each component present in the writemask */
>
> The loop below is exactly the same I wrote in the initial implementation
> of ssbo stores, but Kristian optimized it later so we can group
> consecutive enabled channels in a single write message. See
> 0cb7d7b4b7c32246. I believe we should do the same here.
I have this implemented in my cs branch, but it was triggering the CTS
to be 'unable to find a register to spill'.
Hopefully based on your "Improve emitted code for copies of large
buffer-backed variables" series, I should be able to put this
optimization back. (And, I'll need to do the same for shared
variables...)
Thanks,
-Jordan
>
> > + unsigned skipped_channels = 0;
> > + for (int i = 0; i < instr->num_components; i++) {
> > + int component_mask = 1 << i;
> > + if (writemask & component_mask) {
> > +if (skipped_channels) {
> > + if (!has_indirect) {
> > + const_offset_bytes += 4 * skipped_channels;
> > + bld.MOV(offset_reg, fs_reg(const_offset_bytes));
> > + } else {
> > + bld.ADD(offset_reg, offset_reg,
> > + brw_imm_ud(4 * skipped_channels));
> > + }
> > + skipped_channels = 0;
> > +}
> > +
> > +emit_untyped_write(bld, surf_index, offset_reg,
> > + offset(val_reg, bld, i),
> > + 1 /* dims */, 1 /* size */,
> > + BRW_PREDICATE_NONE);
> > + }
> > +
> > + skipped_channels++;
> > + }
> > + break;
> > + }
> > +
> > case nir_intrinsic_load_input_indirect:
> >has_indirect = true;
> >/* fallthrough */
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Check the return value of pipe_loader_probe() when probing for devices
Hi,
On 29-11-15 17:14, Samuel Pitoiset wrote:
This patch fixes the issue for me (eg.
https://bugs.freedesktop.org/show_bug.cgi?id=93091#c8).
Thanks Tom.
Tested-by: Samuel Pitoiset
I'm seeing a similar crash, but for me the problem is caused by
pipe_loader_sw_probe returning 1, but not filling in the devs
pointer. In which case this fix does not help.
I've been using the following fix locally (I've not gotten
around to submitting this upstream yet, sorry about that):
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -222,7 +222,7 @@ pipe_loader_sw_probe(struct pipe_loader_device **devs, int n
{
int i = 1;
- if (i < ndev) {
+ if (ndev) {
if (!pipe_loader_sw_probe_null(devs)) {
i--;
}
The problem is that if pipe_loader_sw_probe gets called with
ndev=1 it will not set devs, but will still return 1, leading
to ... (continued below)
On 11/28/2015 03:52 AM, Tom Stellard wrote:
When probing for devices, clover will call pipe_loader_probe() twice.
The first time to retrieve the number of devices, and then second time
to retrieve the device structures.
We currently assume that the return value of both calls will be the
same, but this will not be the case if a device happens to disappear
between the two calls.
This patch removes this assumption and checks the return value of the
second pipe_loader_probe() call to ensure it does not try to initialize
devices that no longer exits.
CC:
---
src/gallium/state_trackers/clover/core/platform.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
b/src/gallium/state_trackers/clover/core/platform.cpp
index 328b71c..689d692 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -28,9 +28,10 @@ platform::platform() : adaptor_range(evals(), devs) {
int n = pipe_loader_probe(NULL, 0);
std::vector ldevs(n);
- pipe_loader_probe(&ldevs.front(), n);
+ n = pipe_loader_probe(&ldevs.front(), n);
- for (pipe_loader_device *ldev : ldevs) {
+ for (int i = 0; i < n; ++i) {
+ pipe_loader_device *ldev = ldevs[i];
try {
devs.push_back(create(*this, ldev));
create getting called with a ldev value of NULL here.
Regards,
Hans
} catch (error &) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: remove unused fs_reg offset
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 640e047..68f2548 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -748,7 +748,6 @@ fs_visitor::emit_urb_writes(const fs_reg &gs_vertex_count)
const int output_vertex_size_owords =
gs_prog_data->output_vertex_size_hwords * 2;
- fs_reg offset;
if (gs_vertex_count.file == IMM) {
per_slot_offsets = brw_imm_ud(output_vertex_size_owords *
gs_vertex_count.ud);
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl/dead_builin_varyings: Fix gl_FragData array lowering
On 11/30/2015 10:14 AM, Iago Toral wrote:
On Mon, 2015-11-30 at 09:56 +0200, Tapani Pälli wrote:
Hi;
On 11/27/2015 02:14 PM, Iago Toral Quiroga wrote:
The current implementation looks for array dereferences on gl_FragData and
immediately then proceeds to lower them, however this is not enough because
we can have array access on vector variables too, like in this code:
out vec4 color;
void main()
{
int i;
for (i = 0; i < 4; i++)
color[i] = 1.0;
}
Fix it by making sure that the actual variable being dereferenced is an array.
Fixes a crash in:
spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-ldexp-dvec4.shader_test
Instead of asserting in IR validation now we assert in backend because
array 'should have been lowered' .. is there some other patches that
should be bundled together with this to make it work?
Yes, notice that this is a fp64 test, which is not implemented in i965
yet. There is a development branch here if you want to try it:
https://github.com/Igalia/mesa/tree/i965-fp64-v5-testing
and with that branch (which includes this patch) the test does not crash
any more (it still fails though).
Right, I wanted to make sure we don't assert because of this change but
something else as this patch disables the pass to happen for such case
also without fp64 functionality. Now I realize the assert I get is from
some IR op not lowered which would happen anyway without this change as
it's not implemented yet. All fine!
Reviewed-by: Tapani Pälli
Iago
---
src/glsl/opt_dead_builtin_varyings.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/opt_dead_builtin_varyings.cpp
b/src/glsl/opt_dead_builtin_varyings.cpp
index 68b70ee..5387113 100644
--- a/src/glsl/opt_dead_builtin_varyings.cpp
+++ b/src/glsl/opt_dead_builtin_varyings.cpp
@@ -85,7 +85,7 @@ public:
{
ir_variable *var = ir->variable_referenced();
- if (!var || var->data.mode != this->mode)
+ if (!var || var->data.mode != this->mode || !var->type->is_array())
return visit_continue;
if (this->find_frag_outputs && var->data.location ==
FRAG_RESULT_DATA0) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 29/42] i965: Enable shared local memory for CS shared variables
On 2015-11-25 03:24:38, Iago Toral wrote:
> On Tue, 2015-11-17 at 21:55 -0800, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen
> > ---
> > src/mesa/drivers/dri/i965/brw_cs.c| 2 ++
> > src/mesa/drivers/dri/i965/brw_defines.h | 2 ++
> > src/mesa/drivers/dri/i965/gen7_cs_state.c | 12
> > 3 files changed, 16 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
> > b/src/mesa/drivers/dri/i965/brw_cs.c
> > index 263d224..704b00d 100644
> > --- a/src/mesa/drivers/dri/i965/brw_cs.c
> > +++ b/src/mesa/drivers/dri/i965/brw_cs.c
> > @@ -69,6 +69,8 @@ brw_codegen_cs_prog(struct brw_context *brw,
> >
> > memset(&prog_data, 0, sizeof(prog_data));
> >
> > + prog_data.base.total_shared = prog->Comp.SharedSize;
> > +
> > assign_cs_binding_table_offsets(brw->intelScreen->devinfo, prog,
> > &cp->program.Base, &prog_data);
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> > b/src/mesa/drivers/dri/i965/brw_defines.h
> > index 8189c08..ca5378a 100644
> > --- a/src/mesa/drivers/dri/i965/brw_defines.h
> > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> > @@ -2846,6 +2846,8 @@ enum brw_wm_barycentric_interp_mode {
> > /* GEN7 DW5, GEN8+ DW6 */
> > # define MEDIA_BARRIER_ENABLE_SHIFT 21
> > # define MEDIA_BARRIER_ENABLE_MASK INTEL_MASK(21, 21)
> > +# define MEDIA_SHARED_LOCAL_MEMORY_SIZE_SHIFT 16
> > +# define MEDIA_SHARED_LOCAL_MEMORY_SIZE_MASKINTEL_MASK(20, 16)
> > # define MEDIA_GPGPU_THREAD_COUNT_SHIFT 0
> > # define MEDIA_GPGPU_THREAD_COUNT_MASK INTEL_MASK(7, 0)
> > # define GEN8_MEDIA_GPGPU_THREAD_COUNT_SHIFT0
> > diff --git a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > index 2d7c04f..344ea5a 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > @@ -164,8 +164,20 @@ brw_upload_cs_state(struct brw_context *brw)
> >SET_FIELD(threads, GEN8_MEDIA_GPGPU_THREAD_COUNT) :
> >SET_FIELD(threads, MEDIA_GPGPU_THREAD_COUNT);
> > assert(threads <= brw->max_cs_threads);
> > +
> > + assert(prog_data->total_shared <= 64 * 1024);
> > + uint32_t slm_size = 0;
> > + if (prog_data->total_shared > 0) {
> > + /* slm_size is in 4k increments, but must be a power of 2. */
> > + slm_size = 4 * 1024;
> > + while (slm_size < 64 * 1024 && slm_size < prog_data->total_shared)
>
> total_shared is guaranteed to be <= 64KB because of the assert above so
> we should not need the "slm_size < 64 * 1024" part of the condition
> here.
Well, in release builds, the assert won't help.
This does point out that I ought to be checking this in
brw_codegen_cs_prog, and refusing to generate a program if the size is
more than 64KB. With that change, I agree that I don't need to check
for 64KB in the while loop.
Thanks,
-Jordan
>
> Reviewed-by: Iago Toral Quiroga
>
> > + slm_size <<= 1;
> > + slm_size /= 4 * 1024;
> > + }
> > +
> > desc[dw++] =
> >SET_FIELD(cs_prog_data->uses_barrier, MEDIA_BARRIER_ENABLE) |
> > + SET_FIELD(slm_size, MEDIA_SHARED_LOCAL_MEMORY_SIZE) |
> >media_threads;
> >
> > BEGIN_BATCH(4);
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 29/42] i965: Enable shared local memory for CS shared variables
On Mon, 2015-11-30 at 00:43 -0800, Jordan Justen wrote:
> On 2015-11-25 03:24:38, Iago Toral wrote:
> > On Tue, 2015-11-17 at 21:55 -0800, Jordan Justen wrote:
> > > Signed-off-by: Jordan Justen
> > > ---
> > > src/mesa/drivers/dri/i965/brw_cs.c| 2 ++
> > > src/mesa/drivers/dri/i965/brw_defines.h | 2 ++
> > > src/mesa/drivers/dri/i965/gen7_cs_state.c | 12
> > > 3 files changed, 16 insertions(+)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
> > > b/src/mesa/drivers/dri/i965/brw_cs.c
> > > index 263d224..704b00d 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_cs.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_cs.c
> > > @@ -69,6 +69,8 @@ brw_codegen_cs_prog(struct brw_context *brw,
> > >
> > > memset(&prog_data, 0, sizeof(prog_data));
> > >
> > > + prog_data.base.total_shared = prog->Comp.SharedSize;
> > > +
> > > assign_cs_binding_table_offsets(brw->intelScreen->devinfo, prog,
> > > &cp->program.Base, &prog_data);
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> > > b/src/mesa/drivers/dri/i965/brw_defines.h
> > > index 8189c08..ca5378a 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_defines.h
> > > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> > > @@ -2846,6 +2846,8 @@ enum brw_wm_barycentric_interp_mode {
> > > /* GEN7 DW5, GEN8+ DW6 */
> > > # define MEDIA_BARRIER_ENABLE_SHIFT 21
> > > # define MEDIA_BARRIER_ENABLE_MASK INTEL_MASK(21, 21)
> > > +# define MEDIA_SHARED_LOCAL_MEMORY_SIZE_SHIFT 16
> > > +# define MEDIA_SHARED_LOCAL_MEMORY_SIZE_MASKINTEL_MASK(20, 16)
> > > # define MEDIA_GPGPU_THREAD_COUNT_SHIFT 0
> > > # define MEDIA_GPGPU_THREAD_COUNT_MASK INTEL_MASK(7, 0)
> > > # define GEN8_MEDIA_GPGPU_THREAD_COUNT_SHIFT0
> > > diff --git a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > > b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > > index 2d7c04f..344ea5a 100644
> > > --- a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > > +++ b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> > > @@ -164,8 +164,20 @@ brw_upload_cs_state(struct brw_context *brw)
> > >SET_FIELD(threads, GEN8_MEDIA_GPGPU_THREAD_COUNT) :
> > >SET_FIELD(threads, MEDIA_GPGPU_THREAD_COUNT);
> > > assert(threads <= brw->max_cs_threads);
> > > +
> > > + assert(prog_data->total_shared <= 64 * 1024);
> > > + uint32_t slm_size = 0;
> > > + if (prog_data->total_shared > 0) {
> > > + /* slm_size is in 4k increments, but must be a power of 2. */
> > > + slm_size = 4 * 1024;
> > > + while (slm_size < 64 * 1024 && slm_size < prog_data->total_shared)
> >
> > total_shared is guaranteed to be <= 64KB because of the assert above so
> > we should not need the "slm_size < 64 * 1024" part of the condition
> > here.
>
> Well, in release builds, the assert won't help.
That's true
> This does point out that I ought to be checking this in
> brw_codegen_cs_prog, and refusing to generate a program if the size is
> more than 64KB. With that change, I agree that I don't need to check
> for 64KB in the while loop.
Yes, that sounds like a better idea.
> Thanks,
>
> -Jordan
>
> >
> > Reviewed-by: Iago Toral Quiroga
> >
> > > + slm_size <<= 1;
> > > + slm_size /= 4 * 1024;
> > > + }
> > > +
> > > desc[dw++] =
> > >SET_FIELD(cs_prog_data->uses_barrier, MEDIA_BARRIER_ENABLE) |
> > > + SET_FIELD(slm_size, MEDIA_SHARED_LOCAL_MEMORY_SIZE) |
> > >media_threads;
> > >
> > > BEGIN_BATCH(4);
> >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/53] r600/shader: split address get out to a function.
On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote:
>
> From: Dave Airlie
>
> This will be used in the tess shaders.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/r600_shader.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c
> b/src/gallium/drivers/r600/r600_shader.c
> index d25fc3b..6233753 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -598,6 +598,11 @@ static int select_twoside_color(struct r600_shader_ctx
> *ctx, int front, int back
> return 0;
> }
>
> +static inline int get_address_file_reg(struct r600_shader_ctx *ctx, int
> index)
> +{
> + return index > 0 ? ctx->bc->index_reg[index - 1] : ctx->bc->ar_reg;
> +}
> +
> static int vs_add_primid_output(struct r600_shader_ctx *ctx, int prim_id_sid)
> {
> int i;
> @@ -7188,7 +7193,7 @@ static int tgsi_eg_arl(struct r600_shader_ctx *ctx)
> struct r600_bytecode_alu alu;
> int r;
> int i, lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
> - unsigned reg = inst->Dst[0].Register.Index > 0 ?
> ctx->bc->index_reg[inst->Dst[0].Register.Index - 1] : ctx->bc->ar_reg;
> + unsigned reg = get_address_file_reg(ctx, inst->Dst[0].Register.Index);
>
> assert(inst->Dst[0].Register.Index < 3);
> memset(&alu, 0, sizeof(struct r600_bytecode_alu));
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Oded Gabbay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/fs: remove unused fs_reg offset
On 11/30/2015 10:31 AM, Samuel Iglesias Gonsálvez wrote:
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 640e047..68f2548 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -748,7 +748,6 @@ fs_visitor::emit_urb_writes(const fs_reg &gs_vertex_count)
>const int output_vertex_size_owords =
> gs_prog_data->output_vertex_size_hwords * 2;
>
> - fs_reg offset;
>if (gs_vertex_count.file == IMM) {
> per_slot_offsets = brw_imm_ud(output_vertex_size_owords *
> gs_vertex_count.ud);
>
Reviewed-by: Abdiel Janulgue
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Check the return value of pipe_loader_probe() when probing for devices
Hi Hans,
I think your mesa is not up-to-date.
Emil pushed a fix for that one
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f6235171882d18d0b4d11a3d564c6aa3b22af9d1
Maybe this will help for your issue, but surprisingly, it doesn't fix mine.
On 11/30/2015 09:29 AM, Hans de Goede wrote:
Hi,
On 29-11-15 17:14, Samuel Pitoiset wrote:
This patch fixes the issue for me (eg.
https://bugs.freedesktop.org/show_bug.cgi?id=93091#c8).
Thanks Tom.
Tested-by: Samuel Pitoiset
I'm seeing a similar crash, but for me the problem is caused by
pipe_loader_sw_probe returning 1, but not filling in the devs
pointer. In which case this fix does not help.
I've been using the following fix locally (I've not gotten
around to submitting this upstream yet, sorry about that):
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -222,7 +222,7 @@ pipe_loader_sw_probe(struct pipe_loader_device
**devs, int n
{
int i = 1;
- if (i < ndev) {
+ if (ndev) {
if (!pipe_loader_sw_probe_null(devs)) {
i--;
}
The problem is that if pipe_loader_sw_probe gets called with
ndev=1 it will not set devs, but will still return 1, leading
to ... (continued below)
On 11/28/2015 03:52 AM, Tom Stellard wrote:
When probing for devices, clover will call pipe_loader_probe() twice.
The first time to retrieve the number of devices, and then second time
to retrieve the device structures.
We currently assume that the return value of both calls will be the
same, but this will not be the case if a device happens to disappear
between the two calls.
This patch removes this assumption and checks the return value of the
second pipe_loader_probe() call to ensure it does not try to initialize
devices that no longer exits.
CC:
---
src/gallium/state_trackers/clover/core/platform.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
b/src/gallium/state_trackers/clover/core/platform.cpp
index 328b71c..689d692 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -28,9 +28,10 @@ platform::platform() : adaptor_range(evals(), devs) {
int n = pipe_loader_probe(NULL, 0);
std::vector ldevs(n);
- pipe_loader_probe(&ldevs.front(), n);
+ n = pipe_loader_probe(&ldevs.front(), n);
- for (pipe_loader_device *ldev : ldevs) {
+ for (int i = 0; i < n; ++i) {
+ pipe_loader_device *ldev = ldevs[i];
try {
devs.push_back(create(*this, ldev));
create getting called with a ldev value of NULL here.
Regards,
Hans
} catch (error &) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
-Samuel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/va: ensure linear memory for dmabuf
On 29 November 2015 at 17:26, Emil Velikov wrote:
> On 27 November 2015 at 08:57, Julien Isorce wrote:
> > In order to do zero-copy between two different devices
> > the memory should not be tiled.
> >
> > This is currently no way to set pipe_resource template's flag
> > from pipe_video_buffer template. So disabled_tiling is added.
> >
> > Choosed "disable" prefix so that CALLOC keeps tiling enabled
> > by default.
> >
> > Tested with GStreamer on a laptop that has 2 GPUs:
> > 1- gstvaapidecode:
> >HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
> > 2- glimagesink:
> >EGLImage imports dmabuf on Intel GPU.
> >
> > Note that tiling is working if 1 and 2 are done on the same GPU.
> > So it is up to the application to set or not the flag:
> > VA_SURFACE_EXTBUF_DESC_ENABLE_TILING
> >
> > Signed-off-by: Julien Isorce
> > ---
> > src/gallium/auxiliary/vl/vl_video_buffer.c | 3 +++
> > src/gallium/include/pipe/p_video_codec.h | 1 +
> > src/gallium/state_trackers/va/surface.c| 5 +
> > 3 files changed, 9 insertions(+)
> >
> > diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
> b/src/gallium/auxiliary/vl/vl_video_buffer.c
> > index 6cd2557..62f4aa9 100644
> > --- a/src/gallium/auxiliary/vl/vl_video_buffer.c
> > +++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
> > @@ -253,6 +253,9 @@ vl_video_buffer_template(struct pipe_resource *templ,
> > templ->bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
> > templ->usage = usage;
> >
> > + if (tmpl->disable_tiling)
> > + templ->bind |= PIPE_BIND_LINEAR;
> > +
> > if (plane > 0) {
> >if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_420) {
> > templ->width0 /= 2;
> > diff --git a/src/gallium/include/pipe/p_video_codec.h
> b/src/gallium/include/pipe/p_video_codec.h
> > index 196d00b..dbfffd9 100644
> > --- a/src/gallium/include/pipe/p_video_codec.h
> > +++ b/src/gallium/include/pipe/p_video_codec.h
> > @@ -125,6 +125,7 @@ struct pipe_video_buffer
> > enum pipe_video_chroma_format chroma_format;
> > unsigned width;
> > unsigned height;
> > + bool disable_tiling;
> > bool interlaced;
> >
> > /**
> > diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> > index c052c8f..f7043ad 100644
> > --- a/src/gallium/state_trackers/va/surface.c
> > +++ b/src/gallium/state_trackers/va/surface.c
> > @@ -616,6 +616,11 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned
> int format,
> >
> >switch (memory_type) {
> >case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
> > + /* The application will clear the TILING flag when the surface
> is
> > + * intended to be exported as dmabuf. */
> > + templat.disable_tiling = memory_attibute &&
> > +!(memory_attibute->flags &
> VA_SURFACE_EXTBUF_DESC_ENABLE_TILING);
> The condition seems to be flipped, no ? Currently it's doing
> "disable_tiling = ENABLE_TILING_BIT_SET"
>
Hi Emil, thx for the review. I do not think it is flipped but maybe I
missing something.
>
> Other than that, the idea is ok imho, although I'd appreciate
> Christian and others' feedback.
>
> A few things worth mentioning while looking around for this:
> - suface_from_external_memory should (must) also know about
> disable_tiling.
>
Ack
> - missing R in function name ^^ suRface_ ...
>
Ack
> - sometimes radeon (see r600_video_buffer_create) completely
> overwrites the existing flags, as opposed to just set the linear bit.
> Bug, intentional, worth adding a comment ?
> - in many cases nouveau won't create a linear surface as it's not
> using the above vl helper (hint, earlier suggesting about
> reworking/cleaning things up a bit, hint)
>
It is actually only useful to set it linear when it hits vl helper. For
nouveau, for NV12, it uses a special layout (
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#n290)
and also vaAcquireBufferHandle (dmabuf export) is not practicable since it
requires the memory to be contiguous. So hence not useful to optionally set
it linear (linear flag will be ignored with existing code as you noticed)
Cheers
Julien
>
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/va: ensure linear memory for dmabuf
Hi Christian,
I can try to move the bind flags to pipe_video_buffer.
Thx
Julien
On 29 November 2015 at 19:04, Christian König
wrote:
> On 29.11.2015 18:26, Emil Velikov wrote:
>
>> On 27 November 2015 at 08:57, Julien Isorce wrote:
>>
>>> In order to do zero-copy between two different devices
>>> the memory should not be tiled.
>>>
>>> This is currently no way to set pipe_resource template's flag
>>> from pipe_video_buffer template. So disabled_tiling is added.
>>>
>>> Choosed "disable" prefix so that CALLOC keeps tiling enabled
>>> by default.
>>>
>>> Tested with GStreamer on a laptop that has 2 GPUs:
>>> 1- gstvaapidecode:
>>> HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
>>> 2- glimagesink:
>>> EGLImage imports dmabuf on Intel GPU.
>>>
>>> Note that tiling is working if 1 and 2 are done on the same GPU.
>>> So it is up to the application to set or not the flag:
>>> VA_SURFACE_EXTBUF_DESC_ENABLE_TILING
>>>
>>> Signed-off-by: Julien Isorce
>>> ---
>>> src/gallium/auxiliary/vl/vl_video_buffer.c | 3 +++
>>> src/gallium/include/pipe/p_video_codec.h | 1 +
>>> src/gallium/state_trackers/va/surface.c| 5 +
>>> 3 files changed, 9 insertions(+)
>>>
>>> diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
>>> b/src/gallium/auxiliary/vl/vl_video_buffer.c
>>> index 6cd2557..62f4aa9 100644
>>> --- a/src/gallium/auxiliary/vl/vl_video_buffer.c
>>> +++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
>>> @@ -253,6 +253,9 @@ vl_video_buffer_template(struct pipe_resource *templ,
>>> templ->bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
>>> templ->usage = usage;
>>>
>>> + if (tmpl->disable_tiling)
>>> + templ->bind |= PIPE_BIND_LINEAR;
>>> +
>>> if (plane > 0) {
>>> if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_420) {
>>>templ->width0 /= 2;
>>> diff --git a/src/gallium/include/pipe/p_video_codec.h
>>> b/src/gallium/include/pipe/p_video_codec.h
>>> index 196d00b..dbfffd9 100644
>>> --- a/src/gallium/include/pipe/p_video_codec.h
>>> +++ b/src/gallium/include/pipe/p_video_codec.h
>>> @@ -125,6 +125,7 @@ struct pipe_video_buffer
>>> enum pipe_video_chroma_format chroma_format;
>>> unsigned width;
>>> unsigned height;
>>> + bool disable_tiling;
>>> bool interlaced;
>>>
>>> /**
>>> diff --git a/src/gallium/state_trackers/va/surface.c
>>> b/src/gallium/state_trackers/va/surface.c
>>> index c052c8f..f7043ad 100644
>>> --- a/src/gallium/state_trackers/va/surface.c
>>> +++ b/src/gallium/state_trackers/va/surface.c
>>> @@ -616,6 +616,11 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned
>>> int format,
>>>
>>> switch (memory_type) {
>>> case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
>>> + /* The application will clear the TILING flag when the surface
>>> is
>>> + * intended to be exported as dmabuf. */
>>> + templat.disable_tiling = memory_attibute &&
>>> +!(memory_attibute->flags &
>>> VA_SURFACE_EXTBUF_DESC_ENABLE_TILING);
>>>
>> The condition seems to be flipped, no ? Currently it's doing
>> "disable_tiling = ENABLE_TILING_BIT_SET"
>>
>> Other than that, the idea is ok imho, although I'd appreciate
>> Christian and others' feedback.
>>
>> A few things worth mentioning while looking around for this:
>> - suface_from_external_memory should (must) also know about
>> disable_tiling.
>> - missing R in function name ^^ suRface_ ...
>> - sometimes radeon (see r600_video_buffer_create) completely
>> overwrites the existing flags, as opposed to just set the linear bit.
>> Bug, intentional, worth adding a comment ?
>> - in many cases nouveau won't create a linear surface as it's not
>> using the above vl helper (hint, earlier suggesting about
>> reworking/cleaning things up a bit, hint)
>>
>
> Yeah, agree deduplicating that code would probably be a good idea.
>
> I would also prefer to have all the bind flags in the pipe_video_buffer as
> well.
>
> Regards,
> Christian.
>
>
>
>> Thanks
>> Emil
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/53] r600: make adjust_gprs use hw stages.
On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This changes the r600 specific GPR adjustment code
> to use the stage defines, and arrays.
>
> This is prep work for the tess changes later.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/r600_pipe.h | 2 +-
> src/gallium/drivers/r600/r600_state.c | 117
> ++
> 2 files changed, 64 insertions(+), 55 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> b/src/gallium/drivers/r600/r600_pipe.h
> index 36fa1c9..0e57efe 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -432,7 +432,7 @@ struct r600_context {
> /* Hardware info. */
> boolean has_vertex_cache;
> boolean keep_tiling_flags;
> - unsigneddefault_ps_gprs, default_vs_gprs;
> + unsigneddefault_gprs[EG_NUM_HW_STAGES];
> unsignedr6xx_num_clause_temp_gprs;
>
> /* Miscellaneous state objects. */
> diff --git a/src/gallium/drivers/r600/r600_state.c
> b/src/gallium/drivers/r600/r600_state.c
> index c2d4abc..a16d4bd 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2044,57 +2044,62 @@ static void r600_emit_gs_rings(struct r600_context
> *rctx, struct r600_atom *a)
> /* Adjust GPR allocation on R6xx/R7xx */
> bool r600_adjust_gprs(struct r600_context *rctx)
> {
> - unsigned num_ps_gprs = rctx->ps_shader->current->shader.bc.ngpr;
> - unsigned num_vs_gprs, num_es_gprs, num_gs_gprs;
> - unsigned new_num_ps_gprs = num_ps_gprs;
> - unsigned new_num_vs_gprs, new_num_es_gprs, new_num_gs_gprs;
> - unsigned cur_num_ps_gprs =
> G_008C04_NUM_PS_GPRS(rctx->config_state.sq_gpr_resource_mgmt_1);
> - unsigned cur_num_vs_gprs =
> G_008C04_NUM_VS_GPRS(rctx->config_state.sq_gpr_resource_mgmt_1);
> - unsigned cur_num_gs_gprs =
> G_008C08_NUM_GS_GPRS(rctx->config_state.sq_gpr_resource_mgmt_2);
> - unsigned cur_num_es_gprs =
> G_008C08_NUM_ES_GPRS(rctx->config_state.sq_gpr_resource_mgmt_2);
> - unsigned def_num_ps_gprs = rctx->default_ps_gprs;
> - unsigned def_num_vs_gprs = rctx->default_vs_gprs;
> - unsigned def_num_gs_gprs = 0;
> - unsigned def_num_es_gprs = 0;
> + unsigned num_gprs[R600_NUM_HW_STAGES];
> + unsigned new_gprs[R600_NUM_HW_STAGES];
> + unsigned cur_gprs[R600_NUM_HW_STAGES];
> + unsigned def_gprs[R600_NUM_HW_STAGES];
> unsigned def_num_clause_temp_gprs = rctx->r6xx_num_clause_temp_gprs;
> - /* hardware will reserve twice num_clause_temp_gprs */
> - unsigned max_gprs = def_num_gs_gprs + def_num_es_gprs +
> def_num_ps_gprs + def_num_vs_gprs + def_num_clause_temp_gprs * 2;
> + unsigned max_gprs;
> unsigned tmp, tmp2;
> + unsigned i;
> + bool need_recalc = false, use_default = true;
> +
> + /* hardware will reserve twice num_clause_temp_gprs */
> + max_gprs = def_num_clause_temp_gprs * 2;
> + for (i = 0; i < R600_NUM_HW_STAGES; i++) {
> + def_gprs[i] = rctx->default_gprs[i];
> + max_gprs += def_gprs[i];
> + }
>
> + cur_gprs[R600_HW_STAGE_PS] =
> G_008C04_NUM_PS_GPRS(rctx->config_state.sq_gpr_resource_mgmt_1);
> + cur_gprs[R600_HW_STAGE_VS] =
> G_008C04_NUM_VS_GPRS(rctx->config_state.sq_gpr_resource_mgmt_1);
> + cur_gprs[R600_HW_STAGE_GS] =
> G_008C08_NUM_GS_GPRS(rctx->config_state.sq_gpr_resource_mgmt_2);
> + cur_gprs[R600_HW_STAGE_ES] =
> G_008C08_NUM_ES_GPRS(rctx->config_state.sq_gpr_resource_mgmt_2);
> +
> + num_gprs[R600_HW_STAGE_PS] = rctx->ps_shader->current->shader.bc.ngpr;
> if (rctx->gs_shader) {
> - num_es_gprs = rctx->vs_shader->current->shader.bc.ngpr;
> - num_gs_gprs = rctx->gs_shader->current->shader.bc.ngpr;
> - num_vs_gprs =
> rctx->gs_shader->current->gs_copy_shader->shader.bc.ngpr;
> + num_gprs[R600_HW_STAGE_ES] =
> rctx->vs_shader->current->shader.bc.ngpr;
> + num_gprs[R600_HW_STAGE_GS] =
> rctx->gs_shader->current->shader.bc.ngpr;
> + num_gprs[R600_HW_STAGE_VS] =
> rctx->gs_shader->current->gs_copy_shader->shader.bc.ngpr;
> } else {
> - num_es_gprs = 0;
> - num_gs_gprs = 0;
> - num_vs_gprs = rctx->vs_shader->current->shader.bc.ngpr;
> + num_gprs[R600_HW_STAGE_ES] = 0;
> + num_gprs[R600_HW_STAGE_GS] = 0;
> + num_gprs[R600_HW_STAGE_VS] =
> rctx->vs_shader->current->shader.bc.ngpr;
> + }
> +
> + for (i = 0; i < R600_NUM_HW_STAGES; i++) {
> + new_gprs[i] = num_gprs[i];
> + if (new_gprs[i] > cur_gprs[i])
> + need_recalc = true;
> + if (new_gprs[
Re: [Mesa-dev] [PATCH 02/53] r600: introduce HW shader stage defines
On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote: > From: Dave Airlie > > Add a list of defines for the HW stages. > > We will use this for GPR calculations amongst other things. > > Signed-off-by: Dave Airlie > --- > src/gallium/drivers/r600/r600_pipe.h | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/src/gallium/drivers/r600/r600_pipe.h > b/src/gallium/drivers/r600/r600_pipe.h > index bbb55ad..36fa1c9 100644 > --- a/src/gallium/drivers/r600/r600_pipe.h > +++ b/src/gallium/drivers/r600/r600_pipe.h > @@ -81,6 +81,17 @@ > */ > #define R600_MAX_CONST_BUFFER_SIZE (4096 * sizeof(float[4])) > > +/* HW stages */ > +#define R600_HW_STAGE_PS 0 > +#define R600_HW_STAGE_VS 1 > +#define R600_HW_STAGE_GS 2 > +#define R600_HW_STAGE_ES 3 > +#define EG_HW_STAGE_LS 4 > +#define EG_HW_STAGE_HS 5 > + > +#define R600_NUM_HW_STAGES 4 > +#define EG_NUM_HW_STAGES 6 > + > #ifdef PIPE_ARCH_BIG_ENDIAN > #define R600_BIG_ENDIAN 1 > #else > -- > 2.5.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev Reviewed-by: Oded Gabbay ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] st/va: delay decoder creation until max_references is known
On 26.11.2015 09:45, Julien Isorce wrote:
In general max_references cannot be based on num_render_targets.
This patch allows to allocate buffers with an accurate size.
I.e. no more than necessary. For other codecs it is a fixed
value 2.
This is similar behaviour as vaapi/vdpau-driver.
For now HEVC case defaults to num_render_targets as before.
But it could also benefits this change by setting a more
accurate max_references number in handlePictureParameterBuffer.
Signed-off-by: Julien Isorce
Reviewed-by: Christian König
---
src/gallium/state_trackers/va/context.c | 48 +--
src/gallium/state_trackers/va/picture.c | 49 +++-
src/gallium/state_trackers/va/picture_h264.c | 4 +++
src/gallium/state_trackers/va/va_private.h | 2 +-
4 files changed, 69 insertions(+), 34 deletions(-)
diff --git a/src/gallium/state_trackers/va/context.c
b/src/gallium/state_trackers/va/context.c
index f0051e5..192794f 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -187,7 +187,6 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
config_id, int picture_width,
int picture_height, int flag, VASurfaceID *render_targets,
int num_render_targets, VAContextID *context_id)
{
- struct pipe_video_codec templat = {};
vlVaDriver *drv;
vlVaContext *context;
int is_vpp;
@@ -213,27 +212,22 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
config_id, int picture_width,
return VA_STATUS_ERROR_INVALID_CONTEXT;
}
} else {
- templat.profile = config_id;
- templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
- templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
- templat.width = picture_width;
- templat.height = picture_height;
- templat.max_references = num_render_targets;
- templat.expect_chunked_decode = true;
-
- if (u_reduce_video_profile(templat.profile) ==
-PIPE_VIDEO_FORMAT_MPEG4_AVC)
-templat.level = u_get_h264_level(templat.width, templat.height,
- &templat.max_references);
-
- context->decoder = drv->pipe->create_video_codec(drv->pipe, &templat);
- if (!context->decoder) {
- FREE(context);
- return VA_STATUS_ERROR_ALLOCATION_FAILED;
- }
-
- if (u_reduce_video_profile(context->decoder->profile) ==
- PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+ context->templat.profile = config_id;
+ context->templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
+ context->templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
+ context->templat.width = picture_width;
+ context->templat.height = picture_height;
+ context->templat.expect_chunked_decode = true;
+
+ switch (u_reduce_video_profile(context->templat.profile)) {
+ case PIPE_VIDEO_FORMAT_MPEG12:
+ case PIPE_VIDEO_FORMAT_VC1:
+ case PIPE_VIDEO_FORMAT_MPEG4:
+ context->templat.max_references = 2;
+ break;
+
+ case PIPE_VIDEO_FORMAT_MPEG4_AVC:
+ context->templat.max_references = 0;
context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
if (!context->desc.h264.pps) {
FREE(context);
@@ -245,10 +239,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
config_id, int picture_width,
FREE(context);
return VA_STATUS_ERROR_ALLOCATION_FAILED;
}
- }
+ break;
- if (u_reduce_video_profile(context->decoder->profile) ==
-PIPE_VIDEO_FORMAT_HEVC) {
+ case PIPE_VIDEO_FORMAT_HEVC:
+ context->templat.max_references = num_render_targets;
context->desc.h265.pps = CALLOC_STRUCT(pipe_h265_pps);
if (!context->desc.h265.pps) {
FREE(context);
@@ -260,6 +254,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
config_id, int picture_width,
FREE(context);
return VA_STATUS_ERROR_ALLOCATION_FAILED;
}
+ break;
+
+ default:
+ break;
}
}
diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c
index 25d2940..8d938f4 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -59,14 +59,17 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
context_id, VASurfaceID rende
return VA_STATUS_ERROR_INVALID_SURFACE;
context->target = surf->buffer;
+
if (!context->decoder) {
/* VPP */
- if ((context->target->buffer_format != PIPE_FORMAT_B8G8R8A8_UNORM &&
+ if (context->templat.profile == PIPE_VIDEO_PROFILE_UNKNOWN &&
+ ((context->target->buffer_format != PIPE_FORMAT_B8G8R8A8_UNORM &&
context->target->buffer_format != PIPE_FORMAT_R8G8B8A8_UNORM &&
context->target->buffer_format != PIPE_FORMAT_B8G8R8X8_UNORM &&
context->tar
Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support
On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote: > Hi, > > Patchbomb time, this set of patches is a first pass at add adding > ARB_tessellation_shader support to the r600g driver. Only Evergreen > and newer GPUs support tessellation. On any of the GPUs that support > native FP64, this will enable OpenGL 4.1 on them. > > The first bunch of patches are a bit of a driver rework to get > things in better shape for tessellation, they shouldn't cause > any regressions. > > This runs heaven on cayman and should pass all the piglits > unless I've done something wrong. > > Development hit two HW programming fun times, one with tess and > dynamic GPR interaction requiring disabling dynamic GPRs, and > one with programming of some SIMD registers to block TESS shaders > on one unit. These fixed most of the hangs we saw during development. > > This doesn't contain SB support yet, Glenn has started working on it. > > Currently tested hw: > working: CAYMAN, REDWOOD, BARTS, TURKS > hangs on any tessellation: CAYMAN > hangs differently at least with heaven: SUMO You listed CAYMAN twice, so does it hang or not? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 11.1.0 release candidate 2
The second release candidate for Mesa 11.1.0 is now available.
Boyuan Zhang (1):
radeon/uvd: uv pitch separation for stoney
Dave Airlie (1):
texgetimage: consolidate 1D array handling code.
Emil Velikov (12):
pipe-loader: link against libloader regardless of libdrm presence
loader: unconditionally add AM_CPPFLAGS to libloader_la_CPPFLAGS
configure.ac: default to disabled dri3 when --disable-dri is set
pipe-loader: fix off-by one error
target-hepers: add non inline sw helpers
targets: use the non-inline sw helpers
pipe-loader: check if winsys.name is non-null prior to strcmp
st/dri: fd management cleanups
st/xa: fd management cleanups
auxiliary/vl/drm: fd management cleanups
auxiliary/vl/dri: fd management cleanups
Update version to 11.1.0-rc2
Eric Anholt (2):
vc4: Just put USE_VC4_SIMULATOR in DEFINES.
vc4: Take precedence over ilo when in simulator mode.
Ian Romanick (23):
mesa: Make bind_vertex_buffer avilable outside varray.c
mesa: Refactor update_array_format to make
_mesa_update_array_format_public
mesa: Refactor enable_vertex_array_attrib to make
_mesa_enable_vertex_array_attrib
i965: Pass brw_context instead of gl_context to brw_draw_rectlist
i965: Use DSA functions for VBOs in brw_meta_fast_clear
i965: Use internal functions for buffer object access
i965: Don't pollute the buffer object namespace in brw_meta_fast_clear
meta: Use DSA functions for PBO in create_texture_for_pbo
meta: Use _mesa_NamedBufferData and _mesa_NamedBufferSubData for users of
_mesa_meta_setup_vertex_objects
i965: Use _mesa_NamedBufferSubData for users of
_mesa_meta_setup_vertex_objects
meta: Don't leave the VBO bound after _mesa_meta_setup_vertex_objects
meta: Track VBO using gl_buffer_object instead of GL API object handle
meta: Use DSA functions for VBOs in _mesa_meta_setup_vertex_objects
meta: Use internal functions for buffer object and VAO access
meta: Don't pollute the buffer object namespace in
_mesa_meta_setup_vertex_objects
meta: Partially convert _mesa_meta_DrawTex to DSA
meta: Track VBO using gl_buffer_object instead of GL API object handle in
_mesa_meta_DrawTex
meta: Use internal functions for buffer object and VAO access in
_mesa_meta_DrawTex
meta: Don't pollute the buffer object namespace in _mesa_meta_DrawTex
meta/TexSubImage: Don't pollute the buffer object namespace
meta: Don't save or restore the VBO binding
meta: Don't save or restore the active client texture
docs: add missed i965 feature to relnotes
Igor Gnatenko (1):
virgl: pipe_virgl_create_screen is not static
Ilia Mirkin (10):
freedreno/a4xx: only align slices in non-layer_first textures
freedreno/a4xx: fix 3d texture setup
freedreno/a4xx: fix independent blend
freedreno/a4xx: disable blending and alphatest for integer rt0
nouveau: use the buffer usage to determine placement when no binding
nv50,nvc0: properly handle buffer storage invalidation on dsa buffer
nv50/ir: fix (un)spilling of 3-wide results
freedreno/a4xx: use a factor of 32767 for snorm8 blending
docs: add missed freedreno features to relnotes
mesa: support GL_RED/GL_RG in ES2 contexts when driver support exists
Kenneth Graunke (2):
i965: Fix fragment shader struct inputs.
i965: Fix scalar vertex shader struct outputs.
Leo Liu (1):
radeon/vce: disable Stoney VCE for 11.0
Nanley Chery (2):
mesa/extensions: Enable overriding permanently enabled extensions
mesa/teximage: Fix S3TC regression due to ASTC interaction
Neil Roberts (1):
i965: Handle lum, intensity and missing components in the fast clear
Nicolai Hähnle (1):
radeon: only suspend queries on flush if they haven't been suspended yet
Timothy Arceri (2):
Revert "mesa: return initial value for VALIDATE_STATUS if pipe not bound"
glsl: implement recent spec update to SSO validation
Tom Stellard (2):
radeonsi: Rename si_shader::ls_rsrc{1,2} to si_shader::rsrc{1,2}
radeonsi/compute: Use the compiler's COMPUTE_PGM_RSRC* register values
git tag: mesa-11.1.0-rc2
ftp://ftp.freedesktop.org/pub/mesa/11.1.0/mesa-11.1.0-rc2.tar.gz
MD5: 6fb0e43f5f0e5e14e9c76ca0c70acbf5 mesa-11.1.0-rc2.tar.gz
SHA1: 499f76bd3b1f21c19ceffdd39a082e87b2b4d636 mesa-11.1.0-rc2.tar.gz
SHA256: c342a338f58fda81c274ce319b190b34e48bd7539247bd2bf24347223bb5bad9
mesa-11.1.0-rc2.tar.gz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.1.0/mesa-11.1.0-rc2.tar.gz.sig
ftp://ftp.freedesktop.org/pub/mesa/11.1.0/mesa-11.1.0-rc2.tar.xz
MD5: c19ec4fda3d6a172cb979d9dc556c7ef mesa-11.1.0-rc2.tar.xz
SHA1: 36bf8302901770515cb064687e44f4984c597086 mesa-11.1.0-rc2.tar.xz
SHA256: c778002b2690fa34220d3704b91c540e4686fe31a5e170885016026ca4f34f22
mesa-11.1.0-rc2.tar.xz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.1.
Re: [Mesa-dev] [PATCH 1/2] st/va: ensure linear memory for dmabuf
On 30 November 2015 at 09:23, Julien Isorce wrote:
> On 29 November 2015 at 17:26, Emil Velikov wrote:
>> On 27 November 2015 at 08:57, Julien Isorce wrote:
>> > In order to do zero-copy between two different devices
>> > the memory should not be tiled.
>> >
>> > This is currently no way to set pipe_resource template's flag
>> > from pipe_video_buffer template. So disabled_tiling is added.
>> >
>> > Choosed "disable" prefix so that CALLOC keeps tiling enabled
>> > by default.
>> >
>> > Tested with GStreamer on a laptop that has 2 GPUs:
>> > 1- gstvaapidecode:
>> >HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
>> > 2- glimagesink:
>> >EGLImage imports dmabuf on Intel GPU.
>> >
>> > Note that tiling is working if 1 and 2 are done on the same GPU.
>> > So it is up to the application to set or not the flag:
>> > VA_SURFACE_EXTBUF_DESC_ENABLE_TILING
>> >
>> > Signed-off-by: Julien Isorce
>> > ---
>> > src/gallium/auxiliary/vl/vl_video_buffer.c | 3 +++
>> > src/gallium/include/pipe/p_video_codec.h | 1 +
>> > src/gallium/state_trackers/va/surface.c| 5 +
>> > 3 files changed, 9 insertions(+)
>> >
>> > diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
>> > b/src/gallium/auxiliary/vl/vl_video_buffer.c
>> > index 6cd2557..62f4aa9 100644
>> > --- a/src/gallium/auxiliary/vl/vl_video_buffer.c
>> > +++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
>> > @@ -253,6 +253,9 @@ vl_video_buffer_template(struct pipe_resource
>> > *templ,
>> > templ->bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
>> > templ->usage = usage;
>> >
>> > + if (tmpl->disable_tiling)
>> > + templ->bind |= PIPE_BIND_LINEAR;
>> > +
>> > if (plane > 0) {
>> >if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_420) {
>> > templ->width0 /= 2;
>> > diff --git a/src/gallium/include/pipe/p_video_codec.h
>> > b/src/gallium/include/pipe/p_video_codec.h
>> > index 196d00b..dbfffd9 100644
>> > --- a/src/gallium/include/pipe/p_video_codec.h
>> > +++ b/src/gallium/include/pipe/p_video_codec.h
>> > @@ -125,6 +125,7 @@ struct pipe_video_buffer
>> > enum pipe_video_chroma_format chroma_format;
>> > unsigned width;
>> > unsigned height;
>> > + bool disable_tiling;
>> > bool interlaced;
>> >
>> > /**
>> > diff --git a/src/gallium/state_trackers/va/surface.c
>> > b/src/gallium/state_trackers/va/surface.c
>> > index c052c8f..f7043ad 100644
>> > --- a/src/gallium/state_trackers/va/surface.c
>> > +++ b/src/gallium/state_trackers/va/surface.c
>> > @@ -616,6 +616,11 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned
>> > int format,
>> >
>> >switch (memory_type) {
>> >case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
>> > + /* The application will clear the TILING flag when the surface
>> > is
>> > + * intended to be exported as dmabuf. */
>> > + templat.disable_tiling = memory_attibute &&
>> > +!(memory_attibute->flags &
>> > VA_SURFACE_EXTBUF_DESC_ENABLE_TILING);
>> The condition seems to be flipped, no ? Currently it's doing
>> "disable_tiling = ENABLE_TILING_BIT_SET"
>
>
> Hi Emil, thx for the review. I do not think it is flipped but maybe I
> missing something.
>
Condition is fine. Had a bit of a brain fart.
>>
>>
>> Other than that, the idea is ok imho, although I'd appreciate
>> Christian and others' feedback.
>>
>> A few things worth mentioning while looking around for this:
>> - suface_from_external_memory should (must) also know about
>> disable_tiling.
>
> Ack
>>
>> - missing R in function name ^^ suRface_ ...
>
> Ack
>>
>> - sometimes radeon (see r600_video_buffer_create) completely
>> overwrites the existing flags, as opposed to just set the linear bit.
>> Bug, intentional, worth adding a comment ?
>> - in many cases nouveau won't create a linear surface as it's not
>> using the above vl helper (hint, earlier suggesting about
>> reworking/cleaning things up a bit, hint)
>
>
> It is actually only useful to set it linear when it hits vl helper. For
> nouveau, for NV12, it uses a special layout
> (http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#n290)
> and also vaAcquireBufferHandle (dmabuf export) is not practicable since it
> requires the memory to be contiguous. So hence not useful to optionally set
> it linear (linear flag will be ignored with existing code as you noticed)
>
I was wondering about a better way to handle this case - i.e. driver
cannot work with the specific requirements, while at the same time the
ST allows the functionality. The can think of the following 1) force
use of VL or 2) use getparam (or alike) to query if the driver and the
specific format, etc is capable and bail out accordingly.
I'm leaning towards the latter, as the driver can fall-back to VL
where appropriate.
Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/6] glapi: add GL_OES_geometry_shader extension
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Friday, November 27, 2015 7:23 PM
> To: Marta Lofstedt
> Cc: ML mesa-dev
> Subject: Re: [Mesa-dev] [PATCH v2 2/6] glapi: add
> GL_OES_geometry_shader extension
>
> Hello Marta,
>
> On 27 November 2015 at 14:31, Marta Lofstedt
> wrote:
> > From: Marta Lofstedt
> >
> > Add xml definitions for the GL_OES_geometry_shader extension and
> > expose the extension for OpenGL ES 3.1.
> >
> > Signed-off-by: Marta Lofstedt
> > ---
> > src/mapi/glapi/gen/apiexec.py | 2 +-
> > src/mapi/glapi/gen/es_EXT.xml | 43
> +
> > src/mesa/main/extensions_table.h| 1 +
> > src/mesa/main/mtypes.h | 1 +
> > src/mesa/main/tests/dispatch_sanity.cpp | 3 +++
> > 5 files changed, 49 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mapi/glapi/gen/apiexec.py
> > b/src/mapi/glapi/gen/apiexec.py index 58ec08b..fa046fa 100644
> > --- a/src/mapi/glapi/gen/apiexec.py
> > +++ b/src/mapi/glapi/gen/apiexec.py
> > @@ -72,7 +72,7 @@ functions = {
> >
> > # OpenGL 3.2 / GL_ARB_geometry_shader4. Mesa does not support
> > # GL_ARB_geometry_shader4, so OpenGL 3.2 is required.
> > -"FramebufferTexture": exec_info(core=32),
> > +"FramebufferTexture": exec_info(core=32, es2=31),
> >
> Please update the comment as well.
>
> > # OpenGL 4.0 / GL_ARB_shader_subroutines. Mesa only exposes this
> > # extension with core profile.
> > diff --git a/src/mapi/glapi/gen/es_EXT.xml
> > b/src/mapi/glapi/gen/es_EXT.xml index 577d825..f6c49c2 100644
> > --- a/src/mapi/glapi/gen/es_EXT.xml
> > +++ b/src/mapi/glapi/gen/es_EXT.xml
> > @@ -940,4 +940,47 @@
> >
> >
> >
> > +
> > +
> > +
> > + value="0x8DD9"/>
> > + value="0x0004"/>
> > + value="0x8916"/>
> > + value="0x8917"/>
> > + value="0x8918"/>
> > + value="0x887F"/>
> > + value="0x825E"/>
> > + value="0x8A2C"/>
> > + name="MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS_OES"
> value="0x8A32"/>
> > + value="0x9123"/>
> > + value="0x9124"/>
> > + value="0x8DE0"/>
> > + name="MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_OES"
> value="0x8DE1"/>
> > + value="0x8E5A"/>
> > + value="0x8C29"/>
> > + value="0x92CF"/>
> > + value="0x92D5"/>
> > + value="0x90CD"/>
> > + value="0x90D7"/>
> > + value="0x8E4D"/>
> > + value="0x8E4E"/>
> > + value="0x8260"/>
> > + value="0x8C87"/>
> > + > value="0xA"/>
> > + value="0xB"/>
> > + value="0xC"/>
> > + value="0xD"/>
> > + value="0x9312"/>
> > + value="0x9317"/>
> > + value="0x8DA8"/>
> > + value="0x8DA7"/>
> > + value="0x9309"/>
> > +
> Wondering if Eric's recent patches don't make these obsolete. Haven't look
> closely at them yet, have you ?
No, I haven't looked to closely at them either. Do you think I should wait with
this util Erics stuff has landed?
>
> Cheers,
> Emil
> ___
> 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] [RFC] r600g: evergreen/cayman tessellation support
Am 30.11.2015 um 10:51 schrieb Marek Olšák: >> Currently tested hw: >> working: CAYMAN, REDWOOD, BARTS, TURKS >> hangs on any tessellation: CAYMAN >> hangs differently at least with heaven: SUMO > > You listed CAYMAN twice, so does it hang or not? Based on the comments from patch 53 I'm guessing that it hangs on Caicos: > From: Dave Airlie > > This enables tessellation for evergreen/cayman, > > This will need changes before committing depending > on what hw works etc. > Currently known broken are SUMO/CAICOS > working are CAYMAN/REDWOOD/BARTS/TURKS. Felix ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91888] EGL Wayland software rendering no longer work after regression
https://bugs.freedesktop.org/show_bug.cgi?id=91888 --- Comment #11 from Daniel Stone --- strictly:~/src/misc/SDL/test% LIBGL_ALWAYS_SOFTWARE=1 ./testgl2 INFO: Screen BPP: 0 INFO: Swap Interval : 0 INFO: Window Size : 640,480 INFO: Draw Size : 640,480 INFO: INFO: Vendor: VMware, Inc. INFO: Renderer : Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits) INFO: Version : 3.0 Mesa 11.1.0-devel (git-f4f30ad) [...] ^CINFO: 189.75 frames per second Do I need any special configure flags or anything ... ? -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91888] EGL Wayland software rendering no longer work after regression
https://bugs.freedesktop.org/show_bug.cgi?id=91888 --- Comment #12 from Daniel Stone --- (Testing with an ES2-only build of SDL still worked as well, in the sense that both accelerated and software-only gave me a black window and consumed a lot of resources whilst failing to render anything. But initialisation worked fine.) -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/53] r600: add shader key entries for tcs and tes.
On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> with tessellation vs can now run on ls, and tes can
> run on vs or es, tcs runs on hs.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/r600_hw_context.c | 4
> src/gallium/drivers/r600/r600_pipe.h | 4
> src/gallium/drivers/r600/r600_shader.c | 13 +++--
> src/gallium/drivers/r600/r600_shader.h | 20
> src/gallium/drivers/r600/r600_state_common.c | 11 ++-
> 5 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_hw_context.c
> b/src/gallium/drivers/r600/r600_hw_context.c
> index 13b6918..b7845b5 100644
> --- a/src/gallium/drivers/r600/r600_hw_context.c
> +++ b/src/gallium/drivers/r600/r600_hw_context.c
> @@ -321,6 +321,10 @@ void r600_begin_new_cs(struct r600_context *ctx)
> r600_mark_atom_dirty(ctx,
> &ctx->hw_shader_stages[R600_HW_STAGE_GS].atom);
> r600_mark_atom_dirty(ctx, &ctx->gs_rings.atom);
> }
> + if (ctx->tes_shader) {
> + r600_mark_atom_dirty(ctx,
> &ctx->hw_shader_stages[EG_HW_STAGE_HS].atom);
> + r600_mark_atom_dirty(ctx,
> &ctx->hw_shader_stages[EG_HW_STAGE_LS].atom);
> + }
If tes_shader is temporarily NULL, this will cause that HS+LS won't be
set. I think this should be done unconditionally.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 1/1] i965: Do not overwrite optimizer dumps
When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk,
in a separate file.
But as fs_visitor::optimize() and vec4_visitor::run() are called more
than once, it ends up overwriting the files already on disk, loosing
then previous optimizer steps.
To avoid this, add a new static variable that tracks the global
iteration across the entire life of the program running.
v2: use atomic_inc() for the static variable (Jason).
v3: define local variable as const (Jason).
v4: undo empty line removal (Jason).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
src/mesa/drivers/dri/i965/brw_vec4.cpp | 12
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index d2881b2..586991e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -39,6 +39,7 @@
#include "brw_program.h"
#include "brw_dead_control_flow.h"
#include "glsl/nir/glsl_types.h"
+#include "util/u_atomic.h"
using namespace brw;
@@ -5013,6 +5014,9 @@ fs_visitor::calculate_register_pressure()
void
fs_visitor::optimize()
{
+ static int global_iteration_atomic = 0;
+ const int global_iteration = p_atomic_inc_return(&global_iteration_atomic);
+
/* Start by validating the shader we currently have. */
validate();
@@ -5043,8 +5047,9 @@ fs_visitor::optimize()
\
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) { \
char filename[64]; \
- snprintf(filename, 64, "%s%d-%s-%02d-%02d-" #pass, \
- stage_abbrev, dispatch_width, nir->info.name, iteration,
pass_num); \
+ snprintf(filename, 64, "%s%d-%s-%02d-%02d-%02d-" #pass,\
+ stage_abbrev, dispatch_width, nir->info.name, \
+ global_iteration, iteration, pass_num); \
\
backend_shader::dump_instructions(filename); \
} \
@@ -5057,8 +5062,8 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
char filename[64];
- snprintf(filename, 64, "%s%d-%s-00-start",
- stage_abbrev, dispatch_width, nir->info.name);
+ snprintf(filename, 64, "%s%d-%s-%02d-00-00-start",
+ stage_abbrev, dispatch_width, nir->info.name, global_iteration);
backend_shader::dump_instructions(filename);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index a697bdf..0cb620d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -29,6 +29,7 @@
#include "brw_vec4_live_variables.h"
#include "brw_dead_control_flow.h"
#include "program/prog_parameter.h"
+#include "util/u_atomic.h"
#define MAX_INSTRUCTION (1 << 30)
@@ -1808,6 +1809,9 @@ vec4_visitor::convert_to_hw_regs()
bool
vec4_visitor::run()
{
+ static int global_iteration_atomic = 0;
+ const int global_iteration = p_atomic_inc_return(&global_iteration_atomic);
+
if (shader_time_index >= 0)
emit_shader_time_begin();
@@ -1841,8 +1845,8 @@ vec4_visitor::run()
\
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) { \
char filename[64];\
- snprintf(filename, 64, "%s-%s-%02d-%02d-" #pass, \
- stage_abbrev, nir->info.name, iteration, pass_num); \
+ snprintf(filename, 64, "%s-%s-%02d-%02d-%02d-" #pass, \
+ stage_abbrev, nir->info.name, global_iteration, iteration,
pass_num); \
\
backend_shader::dump_instructions(filename); \
}\
@@ -1854,8 +1858,8 @@ vec4_visitor::run()
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
char filename[64];
- snprintf(filename, 64, "%s-%s-00-start",
- stage_abbrev, nir->info.name);
+ snprintf(filename, 64, "%s-%s-%02d-00-00-start",
+ stage_abbrev, nir->info.name, global_iteration);
backend_shader::dump_instructions(filename);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] st/va: delay decoder creation until max_references is known
On 26 November 2015 at 08:45, Julien Isorce wrote:
> --- a/src/gallium/state_trackers/va/picture.c
> +++ b/src/gallium/state_trackers/va/picture.c
> @@ -113,12 +118,37 @@ handlePictureParameterBuffer(vlVaDriver *drv,
> vlVaContext *context, vlVaBuffer *
> default:
>break;
> }
> +
> + /* Create the decoder once max_references is known. */
> + if (!context->decoder) {
> + if (!context->target)
> + return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> + if (context->templat.max_references == 0)
> + return VA_STATUS_ERROR_INVALID_BUFFER;
> +
> + if (u_reduce_video_profile(context->templat.profile) !=
> + PIPE_VIDEO_FORMAT_MPEG4_AVC)
> + context->templat.level = u_get_h264_level(context->templat.width,
> +context->templat.height, &context->templat.max_references);
Erm shouldn't this one be "if profile == h264 { get_h264_level(...) }" ?
With the above fixed
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/53] r600/sb: add support for GDS to the sb decoder/dump.
On Mon, 30 Nov 2015 07:20:20 +0100, Dave Airlie wrote:
From: Dave Airlie
This just adds support to the decoder, not actual SB support.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_bc.h | 6 ++--
src/gallium/drivers/r600/sb/sb_bc_decoder.cpp | 43 ++-
src/gallium/drivers/r600/sb/sb_bc_dump.cpp| 24 +--
src/gallium/drivers/r600/sb/sb_bc_fmt_def.inc | 28 +
4 files changed, 89 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_bc.h
b/src/gallium/drivers/r600/sb/sb_bc.h
index 9c2a917..5b1bbbd 100644
--- a/src/gallium/drivers/r600/sb/sb_bc.h
+++ b/src/gallium/drivers/r600/sb/sb_bc.h
@@ -535,11 +535,11 @@ struct bc_fetch {
unsigned resource_id:8;
unsigned src_gpr:7;
- unsigned src_rel:1;
+ unsigned src_rel:2; /* GDS expands to 2 bits */
SB interprets src_rel set as the src_gpr using relative indexing which isn't
true for
REL_GLOBAL, so I think we want separate bits for this. The only modes we will
use are
REL_NONE and REL_GLOBAL for GDS ops since we don't use the loop register in the
driver, so one bit should be enough.
unsigned src_sel[4];
unsigned dst_gpr:7;
- unsigned dst_rel:1;
+ unsigned dst_rel:2; /* GDS expands to 2 bits */
Same as for src_rel.
unsigned dst_sel[4];
unsigned alt_const:1;
@@ -573,6 +573,7 @@ struct bc_fetch {
unsigned endian_swap:2;
unsigned mega_fetch:1;
+ unsigned src2_gpr:7; /* for GDS */
void set_op(unsigned op) { this->op = op; op_ptr = r600_isa_fetch(op); }
};
@@ -739,6 +740,7 @@ private:
int decode_cf_mem(unsigned &i, bc_cf &bc);
int decode_fetch_vtx(unsigned &i, bc_fetch &bc);
+ int decode_fetch_gds(unsigned &i, bc_fetch &bc);
};
// bytecode format definition
diff --git a/src/gallium/drivers/r600/sb/sb_bc_decoder.cpp
b/src/gallium/drivers/r600/sb/sb_bc_decoder.cpp
index 5fe8f50..7626920 100644
--- a/src/gallium/drivers/r600/sb/sb_bc_decoder.cpp
+++ b/src/gallium/drivers/r600/sb/sb_bc_decoder.cpp
@@ -373,7 +373,20 @@ int bc_decoder::decode_fetch(unsigned & i, bc_fetch& bc) {
unsigned fetch_opcode = dw0 & 0x1F;
- bc.set_op(r600_isa_fetch_by_opcode(ctx.isa, fetch_opcode));
+ if (fetch_opcode == 2) { // MEM_INST_MEM
+ unsigned mem_op = (dw0 >> 8) & 0x7;
+ unsigned gds_op;
+ if (mem_op == 4) {
+ gds_op = (dw1 >> 9) & 0x1f;
+ fetch_opcode = FETCH_OP_GDS_ADD + gds_op;
+ } else if (mem_op == 5)
+ fetch_opcode = FETCH_OP_TF_WRITE;
+ bc.set_op(fetch_opcode);
+ } else
+ bc.set_op(r600_isa_fetch_by_opcode(ctx.isa, fetch_opcode));
+
+ if (bc.op_ptr->flags & FF_GDS)
+ return decode_fetch_gds(i, bc);
if (bc.op_ptr->flags & FF_VTX)
return decode_fetch_vtx(i, bc);
@@ -439,6 +452,34 @@ int bc_decoder::decode_fetch(unsigned & i, bc_fetch& bc) {
return r;
}
+int bc_decoder::decode_fetch_gds(unsigned & i, bc_fetch& bc) {
+ int r = 0;
+ uint32_t dw0 = dw[i];
+ uint32_t dw1 = dw[i+1];
+ uint32_t dw2 = dw[i+2];
+ i+= 4;
I'd probably add a note the instruction is padded to 128 bits since the +=4
looks like a typo otherwise.
+ assert(i <= ndw);
+
+ MEM_GDS_WORD0_EGCM w0(dw0);
+ bc.src_gpr = w0.get_SRC_GPR();
+ bc.src_rel = w0.get_SRC_REL();
+ bc.src_sel[0] = w0.get_SRC_SEL_X();
+ bc.src_sel[1] = w0.get_SRC_SEL_Y();
+ bc.src_sel[2] = w0.get_SRC_SEL_Z();
+
+ MEM_GDS_WORD1_EGCM w1(dw1);
+ bc.dst_gpr = w1.get_DST_GPR();
+ bc.dst_rel = w1.get_DST_REL();
+ bc.src2_gpr = w1.get_SRC_GPR();
+
+ MEM_GDS_WORD2_EGCM w2(dw2);
+ bc.dst_sel[0] = w2.get_DST_SEL_X();
+ bc.dst_sel[1] = w2.get_DST_SEL_Y();
+ bc.dst_sel[2] = w2.get_DST_SEL_Z();
+ bc.dst_sel[3] = w2.get_DST_SEL_W();
+ return r;
+}
+
int bc_decoder::decode_fetch_vtx(unsigned & i, bc_fetch& bc) {
int r = 0;
uint32_t dw0 = dw[i];
diff --git a/src/gallium/drivers/r600/sb/sb_bc_dump.cpp
b/src/gallium/drivers/r600/sb/sb_bc_dump.cpp
index 3c70ea7..3c051ad 100644
--- a/src/gallium/drivers/r600/sb/sb_bc_dump.cpp
+++ b/src/gallium/drivers/r600/sb/sb_bc_dump.cpp
@@ -425,23 +425,26 @@ bc_dump::bc_dump(shader& s, bytecode* bc) :
void bc_dump::dump(fetch_node& n) {
sb_ostringstream s;
static const char * fetch_type[] = {"VERTEX", "INSTANCE", ""};
+ unsigned gds = n.bc.op_ptr->flags & FF_GDS;
s << n.bc.op_ptr->name;
fill_to(s, 20);
- s << "R";
- print_sel(s, n.bc.dst_gpr, n.bc.dst_rel, INDEX_LOOP, 0);
- s << ".";
- for (int k = 0; k < 4; ++k)
- s << chans[n.bc.dst_sel[k]];
- s << ", ";
+ if (!gds) {
+ s << "R";
+ print_sel(s, n.bc.ds
Re: [Mesa-dev] [PATCH 04/53] r600: move to using hw stages array for hw stage atoms
On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves to using an array of hw stages for the atoms.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/evergreen_state.c | 8 +++-
> src/gallium/drivers/r600/r600_hw_context.c | 8
> src/gallium/drivers/r600/r600_pipe.h | 7 ++-
> src/gallium/drivers/r600/r600_state.c| 8 +++-
> src/gallium/drivers/r600/r600_state_common.c | 25 -
> 5 files changed, 24 insertions(+), 32 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c
> index 5333761..fd4c8b5 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3496,7 +3496,7 @@ fallback:
> void evergreen_init_state_functions(struct r600_context *rctx)
> {
> unsigned id = 1;
> -
> + unsigned i;
> /* !!!
> * To avoid GPU lockup registers must be emited in a specific order
> * (no kidding ...). The order below is important and have been
> @@ -3555,10 +3555,8 @@ void evergreen_init_state_functions(struct
> r600_context *rctx)
> r600_add_atom(rctx, &rctx->b.render_cond_atom, id++);
> r600_add_atom(rctx, &rctx->b.streamout.begin_atom, id++);
> r600_add_atom(rctx, &rctx->b.streamout.enable_atom, id++);
> - r600_init_atom(rctx, &rctx->vertex_shader.atom, id++,
> r600_emit_shader, 23);
> - r600_init_atom(rctx, &rctx->pixel_shader.atom, id++,
> r600_emit_shader, 0);
> - r600_init_atom(rctx, &rctx->geometry_shader.atom, id++,
> r600_emit_shader, 0);
> - r600_init_atom(rctx, &rctx->export_shader.atom, id++,
> r600_emit_shader, 0);
> + for (i = 0; i < EG_NUM_HW_STAGES; i++)
> + r600_init_atom(rctx, &rctx->hw_shader_stages[i].atom, id++,
> r600_emit_shader, 0);
In the original code, the vertex shader init atom call was with 23 as num_dw.
Your loop makes it 0 for all shaders.
Is that intentional ?
> r600_init_atom(rctx, &rctx->shader_stages.atom, id++,
> evergreen_emit_shader_stages, 6);
> r600_init_atom(rctx, &rctx->gs_rings.atom, id++,
> evergreen_emit_gs_rings, 26);
>
> diff --git a/src/gallium/drivers/r600/r600_hw_context.c
> b/src/gallium/drivers/r600/r600_hw_context.c
> index 6409f0b..13b6918 100644
> --- a/src/gallium/drivers/r600/r600_hw_context.c
> +++ b/src/gallium/drivers/r600/r600_hw_context.c
> @@ -300,7 +300,7 @@ void r600_begin_new_cs(struct r600_context *ctx)
> r600_mark_atom_dirty(ctx, &ctx->db_misc_state.atom);
> r600_mark_atom_dirty(ctx, &ctx->db_state.atom);
> r600_mark_atom_dirty(ctx, &ctx->framebuffer.atom);
> - r600_mark_atom_dirty(ctx, &ctx->pixel_shader.atom);
> + r600_mark_atom_dirty(ctx,
> &ctx->hw_shader_stages[R600_HW_STAGE_PS].atom);
> r600_mark_atom_dirty(ctx, &ctx->poly_offset_state.atom);
> r600_mark_atom_dirty(ctx, &ctx->vgt_state.atom);
> r600_mark_atom_dirty(ctx, &ctx->sample_mask.atom);
> @@ -315,13 +315,13 @@ void r600_begin_new_cs(struct r600_context *ctx)
> }
> r600_mark_atom_dirty(ctx, &ctx->stencil_ref.atom);
> r600_mark_atom_dirty(ctx, &ctx->vertex_fetch_shader.atom);
> - r600_mark_atom_dirty(ctx, &ctx->export_shader.atom);
> + r600_mark_atom_dirty(ctx,
> &ctx->hw_shader_stages[R600_HW_STAGE_ES].atom);
> r600_mark_atom_dirty(ctx, &ctx->shader_stages.atom);
> if (ctx->gs_shader) {
> - r600_mark_atom_dirty(ctx, &ctx->geometry_shader.atom);
> + r600_mark_atom_dirty(ctx,
> &ctx->hw_shader_stages[R600_HW_STAGE_GS].atom);
> r600_mark_atom_dirty(ctx, &ctx->gs_rings.atom);
> }
> - r600_mark_atom_dirty(ctx, &ctx->vertex_shader.atom);
> + r600_mark_atom_dirty(ctx,
> &ctx->hw_shader_stages[R600_HW_STAGE_VS].atom);
> r600_mark_atom_dirty(ctx, &ctx->b.streamout.enable_atom);
> r600_mark_atom_dirty(ctx, &ctx->b.render_cond_atom);
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> b/src/gallium/drivers/r600/r600_pipe.h
> index 0e57efe..0ca4052 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -38,7 +38,7 @@
>
> #include "tgsi/tgsi_scan.h"
>
> -#define R600_NUM_ATOMS 43
> +#define R600_NUM_ATOMS 45
>
> #define R600_MAX_VIEWPORTS 16
>
> @@ -481,10 +481,7 @@ struct r600_context {
> struct r600_viewport_state viewport;
> /* Shaders and shader resources. */
> struct r600_cso_state vertex_fetch_shader;
> - struct r600_shader_statevertex_shader;
> - struct r600_shader_statepixel_shader;
> - struct r600_shader_stategeometry_shader;
> - struct r600_shader_stateexport_shader;
> + struct r600_shader_statehw_shader_stages[EG_NUM_HW_STAGES];
> struct r600_cs_shader_state c
Re: [Mesa-dev] [PATCH 05/53] r600: use a macro to remove common shader selection code.
On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This function is going to get a lot messier with tessellation
> so I'm going to use some macros to try and clean some bits
> of common code up.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/r600_state_common.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r600/r600_state_common.c
> index b544abb..b6d739d 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -1288,6 +1288,11 @@ static void r600_update_clip_state(struct r600_context
> *rctx,
> r600_mark_atom_dirty(rctx,
> &rctx->clip_misc_state.atom);
> }
> }
> +#define SELECT_SHADER_OR_FAIL(x) do { \
> + r600_shader_select(ctx, rctx->x##_shader, &x##_dirty); \
> + if (unlikely(!rctx->x##_shader))\
Isn't the above statement missing the "->current" reference ?
> + return false; \
> + } while(0)
>
> static bool r600_update_derived_state(struct r600_context *rctx)
> {
> @@ -1310,16 +1315,12 @@ static bool r600_update_derived_state(struct
> r600_context *rctx)
> }
> }
>
> - r600_shader_select(ctx, rctx->ps_shader, &ps_dirty);
> - if (unlikely(!rctx->ps_shader->current))
> - return false;
> + SELECT_SHADER_OR_FAIL(ps);
>
> update_gs_block_state(rctx, rctx->gs_shader != NULL);
>
> if (rctx->gs_shader) {
> - r600_shader_select(ctx, rctx->gs_shader, &gs_dirty);
> - if (unlikely(!rctx->gs_shader->current))
> - return false;
> + SELECT_SHADER_OR_FAIL(gs);
>
> if (!rctx->shader_stages.geom_enable) {
> rctx->shader_stages.geom_enable = true;
> @@ -1335,9 +1336,7 @@ static bool r600_update_derived_state(struct
> r600_context *rctx)
> rctx->b.streamout.enabled_stream_buffers_mask =
> rctx->gs_shader->current->gs_copy_shader->enabled_stream_buffers_mask;
> }
>
> - r600_shader_select(ctx, rctx->vs_shader, &vs_dirty);
> - if (unlikely(!rctx->vs_shader->current))
> - return false;
> + SELECT_SHADER_OR_FAIL(vs);
>
> /* vs_shader is used as ES */
> if (unlikely(vs_dirty ||
> rctx->hw_shader_stages[R600_HW_STAGE_ES].shader != rctx->vs_shader->current))
> {
> @@ -1351,9 +1350,7 @@ static bool r600_update_derived_state(struct
> r600_context *rctx)
> r600_mark_atom_dirty(rctx, &rctx->shader_stages.atom);
> }
>
> - r600_shader_select(ctx, rctx->vs_shader, &vs_dirty);
> - if (unlikely(!rctx->vs_shader->current))
> - return false;
> + SELECT_SHADER_OR_FAIL(vs);
>
> if (unlikely(vs_dirty ||
> rctx->hw_shader_stages[R600_HW_STAGE_VS].shader != rctx->vs_shader->current))
> {
> update_shader_atom(ctx,
> &rctx->hw_shader_stages[R600_HW_STAGE_VS], rctx->vs_shader->current);
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/53] r600/sb: add LS/HS hw shader types.
On Mon, 30 Nov 2015 07:20:29 +0100, Dave Airlie wrote:
From: Dave Airlie
This just adds printing for the hw shader types, and hooks it up.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_bc.h | 2 ++
src/gallium/drivers/r600/sb/sb_bc_parser.cpp | 6 --
src/gallium/drivers/r600/sb/sb_shader.cpp| 4 +++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_bc.h
b/src/gallium/drivers/r600/sb/sb_bc.h
index d2e8da0..34e1e58 100644
--- a/src/gallium/drivers/r600/sb/sb_bc.h
+++ b/src/gallium/drivers/r600/sb/sb_bc.h
@@ -174,6 +174,8 @@ enum shader_target
TARGET_GS_COPY,
TARGET_COMPUTE,
TARGET_FETCH,
+ TARGET_HS,
+ TARGET_LS,
TARGET_NUM
};
diff --git a/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
b/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
index 28ebfa2..65aa801 100644
--- a/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
+++ b/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
@@ -58,10 +58,12 @@ int bc_parser::decode() {
switch (bc->type) {
case TGSI_PROCESSOR_FRAGMENT: t = TARGET_PS; break;
case TGSI_PROCESSOR_VERTEX:
- t = pshader->vs_as_es ? TARGET_ES : TARGET_VS;
+ t = pshader->vs_as_ls ? TARGET_LS : (pshader->vs_as_es
? TARGET_ES : TARGET_VS);
break;
case TGSI_PROCESSOR_GEOMETRY: t = TARGET_GS; break;
case TGSI_PROCESSOR_COMPUTE: t = TARGET_COMPUTE; break;
+ case TGSI_PROCESSOR_TESS_CTRL: t = TARGET_HS; break;
+ case TGSI_PROCESSOR_TESS_EVAL: t = pshader->tes_as_es ?
TARGET_ES : TARGET_VS; break;
default: assert(!"unknown shader target"); return -1; break;
}
} else {
@@ -146,7 +148,7 @@ int bc_parser::parse_decls() {
}
}
- if (sh->target == TARGET_VS || sh->target == TARGET_ES)
+ if (sh->target == TARGET_VS || sh->target == TARGET_ES || sh->target ==
TARGET_HS)
sh->add_input(0, 1, 0x0F);
else if (sh->target == TARGET_GS) {
sh->add_input(0, 1, 0x0F);
diff --git a/src/gallium/drivers/r600/sb/sb_shader.cpp
b/src/gallium/drivers/r600/sb/sb_shader.cpp
index 87e28e9..8c7b39b 100644
--- a/src/gallium/drivers/r600/sb/sb_shader.cpp
+++ b/src/gallium/drivers/r600/sb/sb_shader.cpp
@@ -215,7 +215,7 @@ void shader::init() {
void shader::init_call_fs(cf_node* cf) {
unsigned gpr = 0;
- assert(target == TARGET_VS || target == TARGET_ES);
+ assert(target == TARGET_LS || target == TARGET_VS || target ==
TARGET_ES);
for(inputs_vec::const_iterator I = inputs.begin(),
E = inputs.end(); I != E; ++I, ++gpr) {
@@ -436,6 +436,8 @@ const char* shader::get_shader_target_name() {
case TARGET_ES: return "ES";
case TARGET_PS: return "PS";
case TARGET_GS: return "GS";
+ case TARGET_HS: return "HS";
+ case TARGET_LS: return "LS";
case TARGET_COMPUTE: return "COMPUTE";
case TARGET_FETCH: return "FETCH";
default:
Reviewed-by: Glenn Kennard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] glsl: add always_active_io attribute to ir_variable
Reviewed-by: Tapani Pälli
(some typos and tiny code nit noted below)
On 11/25/2015 11:54 AM, Timothy Arceri wrote:
From: Gregory Hainaut
The value will be set in separate-shader program when an input/output
must remains active. e.g. when deadcode removal isn't allowed because
it will create interface location/name-matching mismatch.
v3:
* Rename the attribute
* Use ir_variable directly instead of ir_variable_refcount_visitor
* Move the foreach IR code in the linker file
v4:
* Fix variable name in assert
v5 (by Timothy Arceri):
* Rename functions and reword comments
* Don't set alway active on builtins
alway -> always
Signed-off-by: Gregory Hainaut
Reviewed-by: Timothy Arceri
---
src/glsl/ir.cpp | 1 +
src/glsl/ir.h | 7 +
src/glsl/linker.cpp | 74 +
3 files changed, 82 insertions(+)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index ca520f5..f989e9b 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1669,6 +1669,7 @@ ir_variable::ir_variable(const struct glsl_type *type,
const char *name,
this->data.pixel_center_integer = false;
this->data.depth_layout = ir_depth_layout_none;
this->data.used = false;
+ this->data.always_active_io = false;
this->data.read_only = false;
this->data.centroid = false;
this->data.sample = false;
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 20c94a1..717b036 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -659,6 +659,13 @@ public:
unsigned assigned:1;
/**
+ * When separate shader programs are enabled, only input/outputs between
+ * the stages of a multi-stage separate program can be safely removed
+ * from the shader interface. Other input/outputs must remains active.
+ */
+ unsigned always_active_io:1;
+
+ /**
* Enum indicating how the variable was declared. See
* ir_var_declaration_type.
*
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 930b585..4745e86 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -3988,6 +3988,77 @@ split_ubos_and_ssbos(void *mem_ctx,
assert(*num_ubos + *num_ssbos == num_blocks);
}
+static void
+set_always_active_io(exec_list *ir, ir_variable_mode io_mode)
+{
+ assert(io_mode == ir_var_shader_in || io_mode == ir_var_shader_out);
+
+ foreach_in_list(ir_instruction, node, ir) {
+ ir_variable *const var = node->as_variable();
+
+ if (var == NULL || var->data.mode != io_mode)
+ continue;
+
+ /* Don't set alway active on builtins that haven't been redeclared */
alway -> always
+ if(var->data.how_declared == ir_var_declared_implicitly)
space after if
+ continue;
+
+ var->data.always_active_io = true;
+ }
+}
+
+/**
+ * When separate shader programs are enabled, only input/outputs between
+ * the stages of a multi-stage separate program can be safely removed
+ * from the shader interface. Other input/outputs must remains active.
input -> inputs
remains -> remain
+ */
+static void
+disable_varying_optimizations_for_sso(struct gl_shader_program *prog)
+{
+ unsigned first, last;
+ assert(prog->SeparateShader);
+
+ first = MESA_SHADER_STAGES;
+ last = 0;
+
+ /* Determine first and last stage. Excluding the compute stage */
+ for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
+ if (!prog->_LinkedShaders[i])
+ continue;
+ if (first == MESA_SHADER_STAGES)
+ first = i;
+ last = i;
+ }
+
+ if (first == MESA_SHADER_STAGES)
+ return;
+
+ for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
+ gl_shader *sh = prog->_LinkedShaders[stage];
+ if (!sh)
+ continue;
+
+ if (first == last) {
+ /* For a single shader program only allow inputs to the vertex shader
+ * and outputs from the fragment shader to be removed.
+ */
+ if (stage != MESA_SHADER_VERTEX)
+set_always_active_io(sh->ir, ir_var_shader_in);
+ if (stage != MESA_SHADER_FRAGMENT)
+set_always_active_io(sh->ir, ir_var_shader_out);
+ } else {
+ /* For multi-stage separate shader programs only allow inputs and
+ * outputs between the shader stages to be removed as well as inputs
+ * to the vertex shader and outputs from the fragment shader.
+ */
+ if (stage == first && stage != MESA_SHADER_VERTEX)
+set_always_active_io(sh->ir, ir_var_shader_in);
+ else if (stage == last && stage != MESA_SHADER_FRAGMENT)
+set_always_active_io(sh->ir, ir_var_shader_out);
+ }
+ }
+}
+
void
link_shaders(struct gl_context *ctx, struct gl_shader_program *prog)
{
@@ -4255,6 +4326,9 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
}
}
+ if (prog->SeparateShader)
+ disable_varying_optimizations_for_sso(prog);
+
if (!interstage_cross_validate_uniform_blocks(p
Re: [Mesa-dev] [PATCH 2/6] glsl: copy how_declared when lowering interface blocks
Reviewed-by: Tapani Pälli On 11/25/2015 11:54 AM, Timothy Arceri wrote: Cc: Gregory Hainaut --- src/glsl/lower_named_interface_blocks.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glsl/lower_named_interface_blocks.cpp b/src/glsl/lower_named_interface_blocks.cpp index 114bb58..f29eba4 100644 --- a/src/glsl/lower_named_interface_blocks.cpp +++ b/src/glsl/lower_named_interface_blocks.cpp @@ -187,6 +187,7 @@ flatten_named_interface_blocks_declarations::run(exec_list *instructions) new_var->data.sample = iface_t->fields.structure[i].sample; new_var->data.patch = iface_t->fields.structure[i].patch; new_var->data.stream = var->data.stream; +new_var->data.how_declared = var->data.how_declared; new_var->init_interface_type(iface_t); hash_table_insert(interface_namespace, new_var, ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] glsl: don't dead code remove SSO varyings marked as active
On 11/25/2015 11:54 AM, Timothy Arceri wrote:
From: Gregory Hainaut
GL_ARB_separate_shader_objects allow matching by name variable or block
interface. Input varyings can't be removed because it is will impact the
location assignment.
This fixes the bug 79783 and likely any application that uses
GL_ARB_separate_shader_objects extension.
V2 (by Timothy Arceri):
* simplify now that builtins are not set as always active
Signed-off-by: Gregory Hainaut
Reviewed-by: Timothy Arceri
https://bugs.freedesktop.org/show_bug.cgi?id=79783
---
src/glsl/opt_dead_code.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index c5be166..d2316bc 100644
--- a/src/glsl/opt_dead_code.cpp
+++ b/src/glsl/opt_dead_code.cpp
@@ -75,6 +75,22 @@ do_dead_code(exec_list *instructions, bool
uniform_locations_assigned)
|| !entry->declaration)
continue;
+ /* Section 7.4.1 (Shader Interface Matching) of the OpenGL 4.5
+ * (Core Profile) spec says:
+ *
+ *"With separable program objects, interfaces between shader
+ *stages may involve the outputs from one program object and the
+ *inputs from a second program object. For such interfaces, it is
+ *not possible to detect mismatches at link time, because the
+ *programs are linked separately. When each such program is
+ *linked, all inputs or outputs interfacing with another program
+ *stage are treated as active."
+ */
+ if (entry->var->data.always_active_io &&
+ (entry->var->data.mode == ir_var_shader_in ||
+ entry->var->data.mode == ir_var_shader_out))
always_active_io is only set for inputs and outputs so this check can be
changed to just that;
Reviewed-by: Tapani Pälli
+ continue;
+
if (!entry->assign_list.is_empty()) {
/* Remove all the dead assignments to the variable we found.
* Don't do so if it's a shader or function output, though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 30/53] r600: create LDS info constants buffer and write LDS registers.
On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This creates a constant buffer with the information about
> the layout of the LDS memory that is given to the vertex, tess
> control and tess evaluation shaders.
>
> This also programs the LDS size and the LS_HS_CONFIG registers,
> on evergreen only.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/evergreen_state.c | 128
> +++
> src/gallium/drivers/r600/r600_pipe.h | 24 -
> src/gallium/drivers/r600/r600_state_common.c | 13 +++
> 3 files changed, 162 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c
> index c01e8e3..edc6f28 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3763,3 +3763,131 @@ void evergreen_init_state_functions(struct
> r600_context *rctx)
>
> evergreen_init_compute_state_functions(rctx);
> }
> +
> +/**
> + * This calculates the LDS size for tessellation shaders (VS, TCS, TES).
> + *
> + * The information about LDS and other non-compile-time parameters is then
> + * written to the const buffer.
> +
> + * const buffer contains -
> + * uint32_t input_patch_size
> + * uint32_t input_vertex_size
> + * uint32_t num_tcs_input_cp
> + * uint32_t num_tcs_output_cp;
> + * uint32_t output_patch_size
> + * uint32_t output_vertex_size
> + * uint32_t output_patch0_offset
> + * uint32_t perpatch_output_offset
> + * and the same constbuf is bound to LS/HS/VS(ES).
> + */
> +void evergreen_setup_tess_constants(struct r600_context *rctx, const struct
> pipe_draw_info *info, unsigned *num_patches, uint32_t *lds_alloc)
> +{
> + struct pipe_constant_buffer constbuf = {0};
> + struct r600_pipe_shader_selector *tcs = rctx->tcs_shader ?
> rctx->tcs_shader : rctx->tes_shader;
> + struct r600_pipe_shader_selector *ls = rctx->vs_shader;
> + unsigned num_tcs_input_cp = info->vertices_per_patch;
> + unsigned num_tcs_outputs;
> + unsigned num_tcs_output_cp;
> + unsigned num_tcs_patch_outputs;
> + unsigned num_tcs_inputs;
> + unsigned input_vertex_size, output_vertex_size;
> + unsigned input_patch_size, pervertex_output_patch_size,
> output_patch_size;
> + unsigned output_patch0_offset, perpatch_output_offset, lds_size;
> + uint32_t values[16];
> + uint32_t tmp;
> +
> + if (!rctx->tes_shader)
> + return;
> +
> + *num_patches = 1;
num_patches should be set before returning.
> +
> + num_tcs_inputs = util_last_bit64(ls->lds_outputs_written_mask);
> +
> + if (rctx->tcs_shader) {
> + num_tcs_outputs =
> util_last_bit64(tcs->lds_outputs_written_mask);
> + num_tcs_output_cp =
> tcs->info.properties[TGSI_PROPERTY_TCS_VERTICES_OUT];
> + num_tcs_patch_outputs =
> util_last_bit64(tcs->lds_patch_outputs_written_mask);
> + } else {
> + num_tcs_outputs = num_tcs_inputs;
> + num_tcs_output_cp = num_tcs_input_cp;
> + num_tcs_patch_outputs = 2; /* TESSINNER + TESSOUTER */
> + }
> +
> + /* size in bytes */
> + input_vertex_size = num_tcs_inputs * 16;
> + output_vertex_size = num_tcs_outputs * 16;
> +
> + input_patch_size = num_tcs_input_cp * input_vertex_size;
> +
> + pervertex_output_patch_size = num_tcs_output_cp * output_vertex_size;
> + output_patch_size = pervertex_output_patch_size +
> num_tcs_patch_outputs * 16;
> +
> + output_patch0_offset = rctx->tcs_shader ? input_patch_size *
> *num_patches : 0;
> + perpatch_output_offset = output_patch0_offset +
> pervertex_output_patch_size;
> +
> + lds_size = output_patch0_offset + output_patch_size * *num_patches;
> +
> + values[0] = input_patch_size;
> + values[1] = input_vertex_size;
> + values[2] = num_tcs_input_cp;
> + values[3] = num_tcs_output_cp;
> +
> + values[4] = output_patch_size;
> + values[5] = output_vertex_size;
> + values[6] = output_patch0_offset;
> + values[7] = perpatch_output_offset;
> +
> + /* docs say HS_NUM_WAVES - CEIL((LS_HS_CONFIG.NUM_PATCHES *
> + LS_HS_CONFIG.HS_NUM_OUTPUT_CP) / (NUM_GOOD_PIPES * 16)) */
> + tmp = (lds_size | (1 << 14)); /* TODO */
If I understand this correctly, num_good_pipes can be between 1 and 4.
Assume the worst case, which is 1. This gives us:
ceil(NUM_PATCHES * NUM_OUTPUT_CP / 16)
That equals 2 if NUM_OUTPUT_CP > 16 and NUM_PATCHES = 1.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] glsl: don't sort varying in separate shader mode
Reviewed-by: Tapani Pälli
On 11/25/2015 11:54 AM, Timothy Arceri wrote:
From: Gregory Hainaut
This fixes an issue where the addition of the FLAT qualifier in
varying_matches::record() can break the expected varying order.
It also avoids a future issue with the relaxing of interpolation
qualifier matching constraints in GLSL 4.50.
V2: (by Timothy Arceri)
* reworked comment slightly
Signed-off-by: Gregory Hainaut
Reviewed-by: Timothy Arceri
---
src/glsl/link_varyings.cpp | 38 --
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index ac2755f..71750d1 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -766,7 +766,7 @@ public:
gl_shader_stage consumer_stage);
~varying_matches();
void record(ir_variable *producer_var, ir_variable *consumer_var);
- unsigned assign_locations(uint64_t reserved_slots);
+ unsigned assign_locations(uint64_t reserved_slots, bool separate_shader);
void store_locations() const;
private:
@@ -988,11 +988,36 @@ varying_matches::record(ir_variable *producer_var,
ir_variable *consumer_var)
* passed to varying_matches::record().
*/
unsigned
-varying_matches::assign_locations(uint64_t reserved_slots)
+varying_matches::assign_locations(uint64_t reserved_slots, bool
separate_shader)
{
- /* Sort varying matches into an order that makes them easy to pack. */
- qsort(this->matches, this->num_matches, sizeof(*this->matches),
- &varying_matches::match_comparator);
+ /* We disable varying sorting for separate shader programs for the
+* following reasons:
+*
+* 1/ All programs must sort the code in the same order to guarantee the
+*interface matching. However varying_matches::record() will change the
+*interpolation qualifier of some stages.
+*
+* 2/ GLSL version 4.50 removes the matching constrain on the interpolation
+*qualifier.
+*
+* From Section 4.5 (Interpolation Qualifiers) of the GLSL 4.40 spec:
+*
+*"The type and presence of interpolation qualifiers of variables with
+*the same name declared in all linked shaders for the same cross-stage
+*interface must match, otherwise the link command will fail.
+*
+*When comparing an output from one stage to an input of a subsequent
+*stage, the input and output don't match if their interpolation
+*qualifiers (or lack thereof) are not the same."
+*
+*"It is a link-time error if, within the same stage, the interpolation
+*qualifiers of variables of the same name do not match."
+*/
+ if (!separate_shader) {
+ /* Sort varying matches into an order that makes them easy to pack. */
+ qsort(this->matches, this->num_matches, sizeof(*this->matches),
+&varying_matches::match_comparator);
+ }
unsigned generic_location = 0;
unsigned generic_patch_location = MAX_VARYING*4;
@@ -1592,7 +1617,8 @@ assign_varying_locations(struct gl_context *ctx,
reserved_varying_slot(producer, ir_var_shader_out) |
reserved_varying_slot(consumer, ir_var_shader_in);
- const unsigned slots_used = matches.assign_locations(reserved_slots);
+ const unsigned slots_used = matches.assign_locations(reserved_slots,
+prog->SeparateShader);
matches.store_locations();
for (unsigned i = 0; i < num_tfeedback_decls; ++i) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/53] r600: move selecting shaders into earlier code.
On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> select the ps/gs/vs in that order then process the results.
Is there a chance the statements executed inside the "if
(rctx->gs_shader) {" may affect the result of r600_shader_select (and
hence SELECT_SHADER_OR_FAIL) ?
If so, then moving the macro before the if might be problematic.
Oded
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/r600_state_common.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r600/r600_state_common.c
> index b6d739d..6042976 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -1319,9 +1319,12 @@ static bool r600_update_derived_state(struct
> r600_context *rctx)
>
> update_gs_block_state(rctx, rctx->gs_shader != NULL);
>
> - if (rctx->gs_shader) {
> + if (rctx->gs_shader)
> SELECT_SHADER_OR_FAIL(gs);
>
> + SELECT_SHADER_OR_FAIL(vs);
> +
> + if (rctx->gs_shader) {
> if (!rctx->shader_stages.geom_enable) {
> rctx->shader_stages.geom_enable = true;
> r600_mark_atom_dirty(rctx, &rctx->shader_stages.atom);
> @@ -1336,8 +1339,6 @@ static bool r600_update_derived_state(struct
> r600_context *rctx)
> rctx->b.streamout.enabled_stream_buffers_mask =
> rctx->gs_shader->current->gs_copy_shader->enabled_stream_buffers_mask;
> }
>
> - SELECT_SHADER_OR_FAIL(vs);
> -
> /* vs_shader is used as ES */
> if (unlikely(vs_dirty ||
> rctx->hw_shader_stages[R600_HW_STAGE_ES].shader != rctx->vs_shader->current))
> {
> update_shader_atom(ctx,
> &rctx->hw_shader_stages[R600_HW_STAGE_ES], rctx->vs_shader->current);
> @@ -1350,8 +1351,6 @@ static bool r600_update_derived_state(struct
> r600_context *rctx)
> r600_mark_atom_dirty(rctx, &rctx->shader_stages.atom);
> }
>
> - SELECT_SHADER_OR_FAIL(vs);
> -
> if (unlikely(vs_dirty ||
> rctx->hw_shader_stages[R600_HW_STAGE_VS].shader != rctx->vs_shader->current))
> {
> update_shader_atom(ctx,
> &rctx->hw_shader_stages[R600_HW_STAGE_VS], rctx->vs_shader->current);
>
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91888] EGL Wayland software rendering no longer work after regression
https://bugs.freedesktop.org/show_bug.cgi?id=91888 --- Comment #13 from nerdopol...@verizon.net --- I compiled SDL master (well default, since it's an HG repo) ./autogen.sh ./configure --prefix=$INSTALLDIR --libdir=$INSTALLDIR/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH) I also ran it under Wayland with export SDL_VIDEODRIVER=wayland but it does seem that the SDL issue might have been caused by something later than b2c5986ea1c8e66c4e0a05bcacbcf28c27f5b183, so it could be a separate issue, but I'm not sure what SDL doing to know what to report? -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glsl: optimise inputs/outputs with explicit locations
Reviewed-by: Tapani Pälli
Some tiny nitpicking below;
On 11/25/2015 11:54 AM, Timothy Arceri wrote:
This change allows used defined inputs/outputs with explicit locations
to be removed if they are detected to not be used between shaders
at link time.
To enable this we change the is_unmatched_generic_inout field to be
flagged when we have a user defined varying. Previously
explicit_location was assumed to be set only in builtins however SSO
allows the user to set an explicit location.
We then add a function to match explicit locations between shaders.
V2: call match_explicit_outputs_to_inputs() after
is_unmatched_generic_inout has been initialised.
Cc: Gregory Hainaut
---
src/glsl/link_varyings.cpp | 6 ++--
src/glsl/linker.cpp| 82 +++---
2 files changed, 74 insertions(+), 14 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index c0b4b3e..ac2755f 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -896,8 +896,10 @@ varying_matches::record(ir_variable *producer_var,
ir_variable *consumer_var)
{
assert(producer_var != NULL || consumer_var != NULL);
- if ((producer_var && !producer_var->data.is_unmatched_generic_inout)
- || (consumer_var && !consumer_var->data.is_unmatched_generic_inout)) {
+ if ((producer_var && (!producer_var->data.is_unmatched_generic_inout ||
+ producer_var->data.explicit_location)) ||
+ (consumer_var && (!consumer_var->data.is_unmatched_generic_inout ||
+ consumer_var->data.explicit_location))) {
/* Either a location already exists for this variable (since it is part
* of fixed functionality), or it has already been recorded as part of a
* previous match.
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 5ff433c..930b585 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -631,20 +631,12 @@ link_invalidate_variable_locations(exec_list *ir)
/* ir_variable::is_unmatched_generic_inout is used by the linker while
* connecting outputs from one stage to inputs of the next stage.
- *
- * There are two implicit assumptions here. First, we assume that any
- * built-in variable (i.e., non-generic in or out) will have
- * explicit_location set. Second, we assume that any generic in or out
- * will not have explicit_location set.
- *
- * This second assumption will only be valid until
- * GL_ARB_separate_shader_objects is supported. When that extension is
- * implemented, this function will need some modifications.
*/
- if (!var->data.explicit_location) {
- var->data.is_unmatched_generic_inout = 1;
- } else {
+ if (var->data.explicit_location &&
+ var->data.location < VARYING_SLOT_VAR0) {
var->data.is_unmatched_generic_inout = 0;
+ } else {
+ var->data.is_unmatched_generic_inout = 1;
}
}
}
@@ -2421,6 +2413,7 @@ assign_attribute_or_color_locations(gl_shader_program
*prog,
continue;
if (var->data.explicit_location) {
+ var->data.is_unmatched_generic_inout = 0;
if ((var->data.location >= (int)(max_index + generic_base))
|| (var->data.location < 0)) {
linker_error(prog,
@@ -2690,6 +2683,61 @@ assign_attribute_or_color_locations(gl_shader_program
*prog,
return true;
}
+/**
+ * Match explicit locations of outputs to inputs and deactivate the
+ * unmatch flag if found so we don't optimise them alway.
alway -> away
+ */
+void
+match_explicit_outputs_to_inputs(struct gl_shader_program *prog,
+ gl_shader *producer,
+ gl_shader *consumer)
+{
+ glsl_symbol_table parameters;
+ ir_variable *explicit_locations[MAX_VARYING] = { NULL, };
No need for ',' in the initializer.
+
+ /* Find all shader outputs in the "producer" stage.
+*/
+ foreach_in_list(ir_instruction, node, producer->ir) {
+ ir_variable *const var = node->as_variable();
+
+ if ((var == NULL) || (var->data.mode != ir_var_shader_out))
+continue;
different indent used here
+
+ /* Mark output as matched if separte shader with no linked consumer */
separte -> separate
+ if (consumer == NULL)
+ var->data.is_unmatched_generic_inout = 0;
+
+ if (var->data.explicit_location &&
+ var->data.location >= VARYING_SLOT_VAR0) {
+ const unsigned idx = var->data.location - VARYING_SLOT_VAR0;
+ if (explicit_locations[idx] == NULL)
+explicit_locations[idx] = var;
+ }
+ }
+
+ /* Match inputs to outputs */
+ foreach_in_list(ir_instruction, node, consumer->ir) {
+ ir_variable *const input = node->as_variable();
+
+ if ((input == NULL) || (input->data.mode != ir_var_shader_in))
+continue;
different indent used here
+
+ /* Mark input as matched if sep
Re: [Mesa-dev] [PATCH v2 2/6] glapi: add GL_OES_geometry_shader extension
On 30 November 2015 at 10:53, Lofstedt, Marta wrote: > > No, I haven't looked to closely at them either. Do you think I should wait > with this util Erics stuff has landed? > From a quick look he seems to be covering different area (despite that things may be extended to cover this as well). So unless someone objects I'd stick with your original plan. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision: 32120
On Fri, Nov 27, 2015 at 1:37 PM, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 1:35 PM, Emil Velikov
> wrote:
>> On 27 November 2015 at 17:50, Ilia Mirkin wrote:
>>> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
>>> wrote:
From: Marta Lofstedt
This is needed to be able to implement the accepted OES
extensions.
Signed-off-by: Marta Lofstedt
---
include/GLES2/gl2ext.h | 940
-
1 file changed, 934 insertions(+), 6 deletions(-)
diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
index 2b67c6e..2d05596 100644
--- a/include/GLES2/gl2ext.h
+++ b/include/GLES2/gl2ext.h
@@ -6,7 +6,7 @@ extern "C" {
#endif
/*
-** Copyright (c) 2013-2014 The Khronos Group Inc.
+** Copyright (c) 2013-2015 The Khronos Group Inc.
**
** Permission is hereby granted, free of charge, to any person obtaining a
** copy of this software and/or associated documentation files (the
@@ -33,14 +33,14 @@ extern "C" {
** used to make the header, and the header can be found at
** http://www.opengl.org/registry/
**
-** Khronos $Revision: 28335 $ on $Date: 2014-09-26 18:55:45 -0700 (Fri,
26 Sep 2014) $
+** Khronos $Revision: 32120 $ on $Date: 2015-10-15 04:27:13 -0700 (Thu,
15 Oct 2015) $
*/
>>>
>>> What is this header used for? Do we ship it, or is it purely internal
>>> to mesa? If we ship it, might need to cc this to stable... e.g. buffer
>>> storage and a couple other things are in here that we expose in 11.1.
>>
>> We ship it. Although everyone (distributions?) can freely grab them
>> from the Khronos public section.
>
> OK, then we need to get this into 11.1 since we added
> GL_EXT_blend_func_extended there (and GL_EXT_buffer_storage, but that
> one's a bit more theoretical since there's no ES 3.1 support yet).
Not sure why this got checked in with a cc to 11.0 stable, but this
should really just go to 11.1, unless I'm missing something.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision: 32120
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Ilia Mirkin
> Sent: Monday, November 30, 2015 2:55 PM
> To: Emil Velikov
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision:
> 32120
>
> On Fri, Nov 27, 2015 at 1:37 PM, Ilia Mirkin wrote:
> > On Fri, Nov 27, 2015 at 1:35 PM, Emil Velikov
> wrote:
> >> On 27 November 2015 at 17:50, Ilia Mirkin wrote:
> >>> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
> >>> wrote:
> From: Marta Lofstedt
>
> This is needed to be able to implement the accepted OES extensions.
>
> Signed-off-by: Marta Lofstedt
> ---
> include/GLES2/gl2ext.h | 940
> -
> 1 file changed, 934 insertions(+), 6 deletions(-)
>
> diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h index
> 2b67c6e..2d05596 100644
> --- a/include/GLES2/gl2ext.h
> +++ b/include/GLES2/gl2ext.h
> @@ -6,7 +6,7 @@ extern "C" {
> #endif
>
> /*
> -** Copyright (c) 2013-2014 The Khronos Group Inc.
> +** Copyright (c) 2013-2015 The Khronos Group Inc.
> **
> ** Permission is hereby granted, free of charge, to any person
> obtaining a
> ** copy of this software and/or associated documentation files
> (the @@ -33,14 +33,14 @@ extern "C" {
> ** used to make the header, and the header can be found at
> ** http://www.opengl.org/registry/
> **
> -** Khronos $Revision: 28335 $ on $Date: 2014-09-26 18:55:45 -0700
> (Fri, 26 Sep 2014) $
> +** Khronos $Revision: 32120 $ on $Date: 2015-10-15 04:27:13 -0700
> +(Thu, 15 Oct 2015) $
> */
> >>>
> >>> What is this header used for? Do we ship it, or is it purely
> >>> internal to mesa? If we ship it, might need to cc this to stable...
> >>> e.g. buffer storage and a couple other things are in here that we expose
> in 11.1.
> >>
> >> We ship it. Although everyone (distributions?) can freely grab them
> >> from the Khronos public section.
> >
> > OK, then we need to get this into 11.1 since we added
> > GL_EXT_blend_func_extended there (and GL_EXT_buffer_storage, but
> that
> > one's a bit more theoretical since there's no ES 3.1 support yet).
>
> Not sure why this got checked in with a cc to 11.0 stable, but this should
> really
> just go to 11.1, unless I'm missing something.
>
I
My bad.
> -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 11.1.0 release candidate 2
On Mon, Nov 30, 2015 at 09:58:28AM +, Emil Velikov wrote:
> The second release candidate for Mesa 11.1.0 is now available.
>
Hi Emil,
Can we make sure not to do the 11.1.0 release until we have a
fix for the pipe loader bug in clover? clover is completely
broken in -rc2
-Tom
>
> Boyuan Zhang (1):
> radeon/uvd: uv pitch separation for stoney
>
> Dave Airlie (1):
> texgetimage: consolidate 1D array handling code.
>
> Emil Velikov (12):
> pipe-loader: link against libloader regardless of libdrm presence
> loader: unconditionally add AM_CPPFLAGS to libloader_la_CPPFLAGS
> configure.ac: default to disabled dri3 when --disable-dri is set
> pipe-loader: fix off-by one error
> target-hepers: add non inline sw helpers
> targets: use the non-inline sw helpers
> pipe-loader: check if winsys.name is non-null prior to strcmp
> st/dri: fd management cleanups
> st/xa: fd management cleanups
> auxiliary/vl/drm: fd management cleanups
> auxiliary/vl/dri: fd management cleanups
> Update version to 11.1.0-rc2
>
> Eric Anholt (2):
> vc4: Just put USE_VC4_SIMULATOR in DEFINES.
> vc4: Take precedence over ilo when in simulator mode.
>
> Ian Romanick (23):
> mesa: Make bind_vertex_buffer avilable outside varray.c
> mesa: Refactor update_array_format to make
> _mesa_update_array_format_public
> mesa: Refactor enable_vertex_array_attrib to make
> _mesa_enable_vertex_array_attrib
> i965: Pass brw_context instead of gl_context to brw_draw_rectlist
> i965: Use DSA functions for VBOs in brw_meta_fast_clear
> i965: Use internal functions for buffer object access
> i965: Don't pollute the buffer object namespace in brw_meta_fast_clear
> meta: Use DSA functions for PBO in create_texture_for_pbo
> meta: Use _mesa_NamedBufferData and _mesa_NamedBufferSubData for users
> of _mesa_meta_setup_vertex_objects
> i965: Use _mesa_NamedBufferSubData for users of
> _mesa_meta_setup_vertex_objects
> meta: Don't leave the VBO bound after _mesa_meta_setup_vertex_objects
> meta: Track VBO using gl_buffer_object instead of GL API object handle
> meta: Use DSA functions for VBOs in _mesa_meta_setup_vertex_objects
> meta: Use internal functions for buffer object and VAO access
> meta: Don't pollute the buffer object namespace in
> _mesa_meta_setup_vertex_objects
> meta: Partially convert _mesa_meta_DrawTex to DSA
> meta: Track VBO using gl_buffer_object instead of GL API object handle
> in _mesa_meta_DrawTex
> meta: Use internal functions for buffer object and VAO access in
> _mesa_meta_DrawTex
> meta: Don't pollute the buffer object namespace in _mesa_meta_DrawTex
> meta/TexSubImage: Don't pollute the buffer object namespace
> meta: Don't save or restore the VBO binding
> meta: Don't save or restore the active client texture
> docs: add missed i965 feature to relnotes
>
> Igor Gnatenko (1):
> virgl: pipe_virgl_create_screen is not static
>
> Ilia Mirkin (10):
> freedreno/a4xx: only align slices in non-layer_first textures
> freedreno/a4xx: fix 3d texture setup
> freedreno/a4xx: fix independent blend
> freedreno/a4xx: disable blending and alphatest for integer rt0
> nouveau: use the buffer usage to determine placement when no binding
> nv50,nvc0: properly handle buffer storage invalidation on dsa buffer
> nv50/ir: fix (un)spilling of 3-wide results
> freedreno/a4xx: use a factor of 32767 for snorm8 blending
> docs: add missed freedreno features to relnotes
> mesa: support GL_RED/GL_RG in ES2 contexts when driver support exists
>
> Kenneth Graunke (2):
> i965: Fix fragment shader struct inputs.
> i965: Fix scalar vertex shader struct outputs.
>
> Leo Liu (1):
> radeon/vce: disable Stoney VCE for 11.0
>
> Nanley Chery (2):
> mesa/extensions: Enable overriding permanently enabled extensions
> mesa/teximage: Fix S3TC regression due to ASTC interaction
>
> Neil Roberts (1):
> i965: Handle lum, intensity and missing components in the fast clear
>
> Nicolai Hähnle (1):
> radeon: only suspend queries on flush if they haven't been suspended yet
>
> Timothy Arceri (2):
> Revert "mesa: return initial value for VALIDATE_STATUS if pipe not
> bound"
> glsl: implement recent spec update to SSO validation
>
> Tom Stellard (2):
> radeonsi: Rename si_shader::ls_rsrc{1,2} to si_shader::rsrc{1,2}
> radeonsi/compute: Use the compiler's COMPUTE_PGM_RSRC* register values
>
>
> git tag: mesa-11.1.0-rc2
>
> ftp://ftp.freedesktop.org/pub/mesa/11.1.0/mesa-11.1.0-rc2.tar.gz
> MD5: 6fb0e43f5f0e5e14e9c76ca0c70acbf5 mesa-11.1.0-rc2.tar.gz
> SHA1: 499f76bd3b1f21c19ceffdd39a082e87b2b4d636 mesa-11.1.0-rc2.tar.gz
> SHA256: c342a338f58fda81c274ce319b190b34e48bd7539247bd2bf24347223bb5bad9
> mesa
[Mesa-dev] [Bug 91888] EGL Wayland software rendering no longer work after regression
https://bugs.freedesktop.org/show_bug.cgi?id=91888 --- Comment #14 from Daniel Stone --- Ugh, so I think I'm using the same options, and I can't see what's going wrong with either big GL or GLES. To be honest, I'm at a total loss ... can you break on _mesa_error when running SDL to see where it's triggered? -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] egl/dri2: Unify the style of function pointer calls in structs
On Wed, Nov 25, 2015 at 12:27 AM, Boyan Ding wrote:
> Signed-off-by: Boyan Ding
I don't have a strong opinion on the style. Patches are:
Acked-by: Alex Deucher
> ---
> src/egl/drivers/dri2/egl_dri2.c | 10 --
> src/egl/drivers/dri2/platform_android.c | 8
> src/egl/drivers/dri2/platform_drm.c | 14 +++---
> src/egl/drivers/dri2/platform_wayland.c | 14 +++---
> src/egl/drivers/dri2/platform_x11.c | 16
> 5 files changed, 30 insertions(+), 32 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index d34b161..3a9c925 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1440,9 +1440,8 @@ dri2_bind_tex_image(_EGLDriver *drv,
>assert(!"Unexpected texture target in dri2_bind_tex_image()");
> }
>
> - (*dri2_dpy->tex_buffer->setTexBuffer2)(dri2_ctx->dri_context,
> - target, format,
> - dri_drawable);
> + dri2_dpy->tex_buffer->setTexBuffer2(dri2_ctx->dri_context,
> + target, format, dri_drawable);
>
> return EGL_TRUE;
> }
> @@ -1473,9 +1472,8 @@ dri2_release_tex_image(_EGLDriver *drv,
>
> if (dri2_dpy->tex_buffer->base.version >= 3 &&
> dri2_dpy->tex_buffer->releaseTexBuffer != NULL) {
> - (*dri2_dpy->tex_buffer->releaseTexBuffer)(dri2_ctx->dri_context,
> -target,
> -dri_drawable);
> + dri2_dpy->tex_buffer->releaseTexBuffer(dri2_ctx->dri_context,
> + target, dri_drawable);
> }
>
> return EGL_TRUE;
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_android.c
> index 8f3abcb..24f9873 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -235,8 +235,8 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp,
> EGLint type,
> dri2_surf->base.GLColorspace);
>
> dri2_surf->dri_drawable =
> - (*dri2_dpy->dri2->createNewDrawable)(dri2_dpy->dri_screen, config,
> - dri2_surf);
> + dri2_dpy->dri2->createNewDrawable(dri2_dpy->dri_screen, config,
> +dri2_surf);
> if (dri2_surf->dri_drawable == NULL) {
>_eglError(EGL_BAD_ALLOC, "dri2->createNewDrawable");
>goto cleanup_surface;
> @@ -290,7 +290,7 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *surf)
>dri2_surf->window->common.decRef(&dri2_surf->window->common);
> }
>
> - (*dri2_dpy->core->destroyDrawable)(dri2_surf->dri_drawable);
> + dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);
>
> free(dri2_surf);
>
> @@ -319,7 +319,7 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *draw)
> if (dri2_surf->buffer)
>droid_window_enqueue_buffer(dri2_surf);
>
> - (*dri2_dpy->flush->invalidate)(dri2_surf->dri_drawable);
> + dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
>
> return EGL_TRUE;
> }
> diff --git a/src/egl/drivers/dri2/platform_drm.c
> b/src/egl/drivers/dri2/platform_drm.c
> index 3f4f7e7..bc2e470 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -136,15 +136,15 @@ dri2_drm_create_surface(_EGLDriver *drv, _EGLDisplay
> *disp, EGLint type,
>
> if (dri2_dpy->dri2) {
>dri2_surf->dri_drawable =
> - (*dri2_dpy->dri2->createNewDrawable)(dri2_dpy->dri_screen, config,
> - dri2_surf->gbm_surf);
> + dri2_dpy->dri2->createNewDrawable(dri2_dpy->dri_screen, config,
> + dri2_surf->gbm_surf);
>
> } else {
>assert(dri2_dpy->swrast != NULL);
>
>dri2_surf->dri_drawable =
> - (*dri2_dpy->swrast->createNewDrawable)(dri2_dpy->dri_screen, config,
> -dri2_surf->gbm_surf);
> + dri2_dpy->swrast->createNewDrawable(dri2_dpy->dri_screen, config,
> + dri2_surf->gbm_surf);
>
> }
> if (dri2_surf->dri_drawable == NULL) {
> @@ -194,7 +194,7 @@ dri2_drm_destroy_surface(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf)
> if (!_eglPutSurface(surf))
>return EGL_TRUE;
>
> - (*dri2_dpy->core->destroyDrawable)(dri2_surf->dri_drawable);
> + dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);
>
> for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
>if (dri2_surf->color_buffers[i].bo)
> @@ -417,7 +417,7 @@ dri2_drm_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *draw)
> unsigned i;
>
> if (dri2_dpy->swrast) {
> - (*dri2_dpy->core->swapBuffe
[Mesa-dev] [PATCH] clover: Handle NULL pipe_loader_device returned by pipe_loader_probe()
pipe_loader_probe() may initalize an entry in the device list to NULL,
while still counting this device in the number of devices that it
returns, so we need to handle this situation.
---
This is the most simple fix possible to get clover working again. We can
discuss fixing the other issues in clover in a follow on patch.
src/gallium/state_trackers/clover/core/platform.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
b/src/gallium/state_trackers/clover/core/platform.cpp
index 328b71c..871b90e 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -31,6 +31,9 @@ platform::platform() : adaptor_range(evals(), devs) {
pipe_loader_probe(&ldevs.front(), n);
for (pipe_loader_device *ldev : ldevs) {
+ if (!ldev) {
+ continue;
+ }
try {
devs.push_back(create(*this, ldev));
} catch (error &) {
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: run brw_vec4 optimizations in loop
On Thu, Nov 26, 2015 at 7:57 AM, Juan A. Suarez Romero wrote: > On Wed, 2015-11-25 at 16:16 -0800, Matt Turner wrote: >> In the piglit test you cited, opt_vector_float() does this to the >> relevant code: >> >> cmp.nz.f0.0 null:F, vgrf6.xyzz:F, vgrf14.xyzz:F >> -mov vgrf2.0.x:D, 0D >> (+f0.0.any4h) mov vgrf2.0.x:D, -1D >> -mov vgrf2.0.yzw:D, 0D >> +mov vgrf2.0:F, [0F, 0F, 0F, 0F] >> cmp.nz.f0.0 null:D, vgrf2.xyzw:D, 0D >> > > > Now that you point to this change, is it correct? > > Before the change, vgrf2.0.x is initialized to 0, and if the previous > cmp success then assigned -1. > > > But after the change, the value is initialized to 0 *after* the > conditional check, so it ends up always with 0 (-1D is never assigned). > > So seems opt_vector_float() is doing something wrong (probably not > checking if the component can be assigned in a conditional). > > Am I missing something? I believe you're exactly right. I suspect we should reset last_reg to -1 in opt_vector_float() if we see a read of last_reg. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Handle NULL pipe_loader_device returned by pipe_loader_probe()
Tom Stellard writes:
> pipe_loader_probe() may initalize an entry in the device list to NULL,
> while still counting this device in the number of devices that it
> returns, so we need to handle this situation.
If this is related to the patch you sent last Saturday
(1448679128-20276-1-git-send-email-thomas.stell...@amd.com), I don't
think that's what happens. What happens is that pipe_loader_sw_probe()
returns an incorrect device count the first time around (one regardless
of whether the software null device is actually available), so Clover
allocates and zero-initializes a pointer in the ldevs array for a device
which is never returned by pipe-loader, and then crashes.
Please mention in the commit message that this is actually working
around a pipe-loader bug, but it makes sense to do it anyway because it
fixes the theoretical race condition you pointed out in your last patch.
> ---
>
> This is the most simple fix possible to get clover working again. We can
> discuss fixing the other issues in clover in a follow on patch.
>
> src/gallium/state_trackers/clover/core/platform.cpp | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
> b/src/gallium/state_trackers/clover/core/platform.cpp
> index 328b71c..871b90e 100644
> --- a/src/gallium/state_trackers/clover/core/platform.cpp
> +++ b/src/gallium/state_trackers/clover/core/platform.cpp
> @@ -31,6 +31,9 @@ platform::platform() : adaptor_range(evals(), devs) {
> pipe_loader_probe(&ldevs.front(), n);
>
> for (pipe_loader_device *ldev : ldevs) {
> + if (!ldev) {
> + continue;
> + }
>try {
Just nitpicking now, but I'd prefer to simplify this even more by doing
the following here:
+if (ldev)
> devs.push_back(create(*this, ldev));
>} catch (error &) {
> --
> 2.0.4
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Handle NULL pipe_loader_device returned by pipe_loader_probe()
On Mon, Nov 30, 2015 at 07:57:32PM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > pipe_loader_probe() may initalize an entry in the device list to NULL,
> > while still counting this device in the number of devices that it
> > returns, so we need to handle this situation.
>
> If this is related to the patch you sent last Saturday
> (1448679128-20276-1-git-send-email-thomas.stell...@amd.com), I don't
> think that's what happens. What happens is that pipe_loader_sw_probe()
> returns an incorrect device count the first time around (one regardless
> of whether the software null device is actually available), so Clover
> allocates and zero-initializes a pointer in the ldevs array for a device
> which is never returned by pipe-loader, and then crashes.
>
> Please mention in the commit message that this is actually working
> around a pipe-loader bug, but it makes sense to do it anyway because it
> fixes the theoretical race condition you pointed out in your last patch.
>
Sorry, please disregard this. I got branches mixed up while working on
this and I thought that this was required in addition to
1448679128-20276-1-git-send-email-thomas.stell...@amd.com.
-Tom
> > ---
> >
> > This is the most simple fix possible to get clover working again. We can
> > discuss fixing the other issues in clover in a follow on patch.
> >
> > src/gallium/state_trackers/clover/core/platform.cpp | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
> > b/src/gallium/state_trackers/clover/core/platform.cpp
> > index 328b71c..871b90e 100644
> > --- a/src/gallium/state_trackers/clover/core/platform.cpp
> > +++ b/src/gallium/state_trackers/clover/core/platform.cpp
> > @@ -31,6 +31,9 @@ platform::platform() : adaptor_range(evals(), devs) {
> > pipe_loader_probe(&ldevs.front(), n);
> >
> > for (pipe_loader_device *ldev : ldevs) {
> > + if (!ldev) {
> > + continue;
> > + }
> >try {
>
> Just nitpicking now, but I'd prefer to simplify this even more by doing
> the following here:
>
> +if (ldev)
>
> > devs.push_back(create(*this, ldev));
> >} catch (error &) {
> > --
> > 2.0.4
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: Check the return value of pipe_loader_probe() when probing for devices v2
When probing for devices, clover will call pipe_loader_probe() twice.
The first time to retrieve the number of devices, and then second time
to retrieve the device structures.
We currently assume that the return value of both calls will be the
same, but this will not be the case if a device happens to disappear
between the two calls.
This patch removes this assumption and checks the return value of the
second pipe_loader_probe() call to ensure it does not try to initialize
devices that no longer exits.
CC:
v2:
- Keep range for loop
---
src/gallium/state_trackers/clover/core/platform.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
b/src/gallium/state_trackers/clover/core/platform.cpp
index 328b71c..489e8dc 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -32,7 +32,8 @@ platform::platform() : adaptor_range(evals(), devs) {
for (pipe_loader_device *ldev : ldevs) {
try {
- devs.push_back(create(*this, ldev));
+ if (ldev)
+devs.push_back(create(*this, ldev));
} catch (error &) {
pipe_loader_release(&ldev, 1);
}
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] mesa: remove ARB_geometry_shader4
On 11/29/2015 03:20 PM, Kenneth Graunke wrote:
> On Sunday, November 29, 2015 02:17:06 PM Ian Romanick wrote:
>> On 11/25/2015 03:16 AM, Marta Lofstedt wrote:
>>> From: Marta Lofstedt
>>>
>>> No drivers currently implement ARB_geometry_shader4, nor are there
>>> any plans to implement it. We only support the version of geometry
>>> shaders that was incorporated into OpenGL 3.2 / GLSL 1.50.
>>>
>>> Signed-off-by: Marta Lofstedt
>>> ---
>>> src/mapi/glapi/gen/ARB_geometry_shader4.xml | 57
>>> -
>>> src/mapi/glapi/gen/Makefile.am | 1 -
>>> src/mapi/glapi/gen/gl_API.xml | 2 +-
>>> src/mesa/main/api_validate.c| 2 +-
>>> src/mesa/main/config.h | 2 +-
>>> src/mesa/main/context.h | 3 +-
>>> src/mesa/main/dlist.c | 55
>>>
>>> src/mesa/main/get.c | 7
>>> src/mesa/main/get_hash_params.py| 12 ++
>>> src/mesa/main/mtypes.h | 3 +-
>>> src/mesa/main/tests/enum_strings.cpp| 6 ---
>>> 11 files changed, 9 insertions(+), 141 deletions(-)
>>> delete mode 100644 src/mapi/glapi/gen/ARB_geometry_shader4.xml
>>>
>>> diff --git a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
>>> b/src/mapi/glapi/gen/ARB_geometry_shader4.xml
>>> deleted file mode 100644
>>> index 280e7a0..000
>>> --- a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
>>> +++ /dev/null
>>> @@ -1,57 +0,0 @@
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> ->> alias="FramebufferTextureLayer">
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
>>> index a5a26a6..40b0e65 100644
>>> --- a/src/mapi/glapi/gen/Makefile.am
>>> +++ b/src/mapi/glapi/gen/Makefile.am
>>> @@ -133,7 +133,6 @@ API_XML = \
>>> ARB_ES3_compatibility.xml \
>>> ARB_framebuffer_no_attachments.xml \
>>> ARB_framebuffer_object.xml \
>>> - ARB_geometry_shader4.xml \
>>> ARB_get_program_binary.xml \
>>> ARB_get_texture_sub_image.xml \
>>> ARB_gpu_shader_fp64.xml \
>>> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
>>> index ec83cd4..6243bdd 100644
>>> --- a/src/mapi/glapi/gen/gl_API.xml
>>> +++ b/src/mapi/glapi/gen/gl_API.xml
>>> @@ -7975,7 +7975,7 @@
>>>
>>>
>>>
>>> ->> xmlns:xi="http://www.w3.org/2001/XInclude"/>
>>> +
>>>
>>>
>>>
>>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>>> index a490189..cbfb6b5 100644
>>> --- a/src/mesa/main/api_validate.c
>>> +++ b/src/mesa/main/api_validate.c
>>> @@ -170,7 +170,7 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum
>>> mode, const char *name)
>>>return GL_FALSE;
>>> }
>>>
>>> - /* From the ARB_geometry_shader4 spec:
>>> + /* From the OpenGL 4.5 specification, section 11.3.1:
>>> *
>>> * The error INVALID_OPERATION is generated if Begin, or any command
>>> that
>>> * implicitly calls Begin, is called when a geometry shader is active
>>> and:
>>> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
>>> index f29de5f..2d53e2f 100644
>>> --- a/src/mesa/main/config.h
>>> +++ b/src/mesa/main/config.h
>>> @@ -246,7 +246,7 @@
>>> #define MAX_FEEDBACK_BUFFERS 4
>>> #define MAX_FEEDBACK_ATTRIBS 32
>>>
>>> -/** For GL_ARB_geometry_shader4 */
>>> +/** For geometry shader */
>>> /*@{*/
>>> #define MAX_GEOMETRY_UNIFORM_COMPONENTS 512
>>> #define MAX_GEOMETRY_OUTPUT_VERTICES 256
>>> diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
>>> index 4798b1f..8b64f45 100644
>>> --- a/src/mesa/main/context.h
>>> +++ b/src/mesa/main/context.h
>>> @@ -330,8 +330,7 @@ _mesa_is_gles31(const struct gl_context *ctx)
>>> static inline bool
>>> _mesa_has_geometry_shaders(const struct gl_context *ctx)
>>> {
>>> - return _mesa_is_desktop_gl(ctx) &&
>>> - (ctx->Version >= 32 || ctx->Extensions.ARB_geometry_shader4);
>>> + return _mesa_is_desktop_gl(ctx) && ctx->Version >= 32;
>>> }
>>>
>>>
>>> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
>>> index 2b65b2e..ba2e670 100644
>>> --- a/src/mesa/main/dlist.c
>>> +++ b/src/mesa/main/dlist.c
>>> @@ -457,11 +457,6 @@ typedef enum
>>> OPCODE_SAMPLER_PARAMETERIIV,
>>> OPCODE_SAMPLER_PARAMETERUIV,
>>>
>>> - /* GL_ARB_geometry_shader4 */
>>> - OPCODE_PROGRAM_PARAMETERI,
>>> - OPCODE_FRAMEBUFFER_TEXTURE,
>>> -
Re: [Mesa-dev] [PATCH v2] mesa: remove ARB_geometry_shader4
Also... this patch is
Reviewed-by: Ian Romanick
On 11/30/2015 11:21 AM, Ian Romanick wrote:
> On 11/29/2015 03:20 PM, Kenneth Graunke wrote:
>> On Sunday, November 29, 2015 02:17:06 PM Ian Romanick wrote:
>>> On 11/25/2015 03:16 AM, Marta Lofstedt wrote:
From: Marta Lofstedt
No drivers currently implement ARB_geometry_shader4, nor are there
any plans to implement it. We only support the version of geometry
shaders that was incorporated into OpenGL 3.2 / GLSL 1.50.
Signed-off-by: Marta Lofstedt
---
src/mapi/glapi/gen/ARB_geometry_shader4.xml | 57
-
src/mapi/glapi/gen/Makefile.am | 1 -
src/mapi/glapi/gen/gl_API.xml | 2 +-
src/mesa/main/api_validate.c| 2 +-
src/mesa/main/config.h | 2 +-
src/mesa/main/context.h | 3 +-
src/mesa/main/dlist.c | 55
src/mesa/main/get.c | 7
src/mesa/main/get_hash_params.py| 12 ++
src/mesa/main/mtypes.h | 3 +-
src/mesa/main/tests/enum_strings.cpp| 6 ---
11 files changed, 9 insertions(+), 141 deletions(-)
delete mode 100644 src/mapi/glapi/gen/ARB_geometry_shader4.xml
diff --git a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
b/src/mapi/glapi/gen/ARB_geometry_shader4.xml
deleted file mode 100644
index 280e7a0..000
--- a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
+++ /dev/null
@@ -1,57 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
->>> alias="FramebufferTextureLayer">
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/src/mapi/glapi/gen/Makefile.am
b/src/mapi/glapi/gen/Makefile.am
index a5a26a6..40b0e65 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -133,7 +133,6 @@ API_XML = \
ARB_ES3_compatibility.xml \
ARB_framebuffer_no_attachments.xml \
ARB_framebuffer_object.xml \
- ARB_geometry_shader4.xml \
ARB_get_program_binary.xml \
ARB_get_texture_sub_image.xml \
ARB_gpu_shader_fp64.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index ec83cd4..6243bdd 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -7975,7 +7975,7 @@
->>> xmlns:xi="http://www.w3.org/2001/XInclude"/>
+
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index a490189..cbfb6b5 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -170,7 +170,7 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum
mode, const char *name)
return GL_FALSE;
}
- /* From the ARB_geometry_shader4 spec:
+ /* From the OpenGL 4.5 specification, section 11.3.1:
*
* The error INVALID_OPERATION is generated if Begin, or any command
that
* implicitly calls Begin, is called when a geometry shader is active
and:
diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index f29de5f..2d53e2f 100644
--- a/src/mesa/main/config.h
+++ b/src/mesa/main/config.h
@@ -246,7 +246,7 @@
#define MAX_FEEDBACK_BUFFERS 4
#define MAX_FEEDBACK_ATTRIBS 32
-/** For GL_ARB_geometry_shader4 */
+/** For geometry shader */
/*@{*/
#define MAX_GEOMETRY_UNIFORM_COMPONENTS 512
#define MAX_GEOMETRY_OUTPUT_VERTICES 256
diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index 4798b1f..8b64f45 100644
--- a/src/mesa/main/context.h
+++ b/src/mesa/main/context.h
@@ -330,8 +330,7 @@ _mesa_is_gles31(const struct gl_context *ctx)
static inline bool
_mesa_has_geometry_shaders(const struct gl_context *ctx)
{
- return _mesa_is_desktop_gl(ctx) &&
- (ctx->Version >= 32 || ctx->Extensions.ARB_geometry_shader4);
+ return _mesa_is_desktop_gl(ctx) && ctx->Version >= 32;
}
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 2b65b2e..ba2e670 100644
--- a/src/mesa/main/dlist.c
++
Re: [Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision: 32120
On 11/30/2015 05:54 AM, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 1:37 PM, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 1:35 PM, Emil Velikov
>> wrote:
>>> On 27 November 2015 at 17:50, Ilia Mirkin wrote:
On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> This is needed to be able to implement the accepted OES
> extensions.
>
> Signed-off-by: Marta Lofstedt
> ---
> include/GLES2/gl2ext.h | 940
> -
> 1 file changed, 934 insertions(+), 6 deletions(-)
>
> diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
> index 2b67c6e..2d05596 100644
> --- a/include/GLES2/gl2ext.h
> +++ b/include/GLES2/gl2ext.h
> @@ -6,7 +6,7 @@ extern "C" {
> #endif
>
> /*
> -** Copyright (c) 2013-2014 The Khronos Group Inc.
> +** Copyright (c) 2013-2015 The Khronos Group Inc.
> **
> ** Permission is hereby granted, free of charge, to any person obtaining
> a
> ** copy of this software and/or associated documentation files (the
> @@ -33,14 +33,14 @@ extern "C" {
> ** used to make the header, and the header can be found at
> ** http://www.opengl.org/registry/
> **
> -** Khronos $Revision: 28335 $ on $Date: 2014-09-26 18:55:45 -0700 (Fri,
> 26 Sep 2014) $
> +** Khronos $Revision: 32120 $ on $Date: 2015-10-15 04:27:13 -0700 (Thu,
> 15 Oct 2015) $
> */
What is this header used for? Do we ship it, or is it purely internal
to mesa? If we ship it, might need to cc this to stable... e.g. buffer
storage and a couple other things are in here that we expose in 11.1.
>>>
>>> We ship it. Although everyone (distributions?) can freely grab them
>>> from the Khronos public section.
>>
>> OK, then we need to get this into 11.1 since we added
>> GL_EXT_blend_func_extended there (and GL_EXT_buffer_storage, but that
>> one's a bit more theoretical since there's no ES 3.1 support yet).
>
> Not sure why this got checked in with a cc to 11.0 stable, but this
> should really just go to 11.1, unless I'm missing something.
It doesn't need to go in 11.0, but it won't hurt anything either.
> -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/6] glapi: add GL_OES_geometry_shader extension
On 11/27/2015 09:58 AM, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> Add xml definitions for the GL_OES_geometry_shader extension
>> and expose the extension for OpenGL ES 3.1.
>>
>> Signed-off-by: Marta Lofstedt
>> ---
>> src/mapi/glapi/gen/apiexec.py | 2 +-
>> src/mapi/glapi/gen/es_EXT.xml | 43
>> +
>> src/mesa/main/extensions_table.h| 1 +
>> src/mesa/main/mtypes.h | 1 +
>> src/mesa/main/tests/dispatch_sanity.cpp | 3 +++
>> 5 files changed, 49 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
>> index 58ec08b..fa046fa 100644
>> --- a/src/mapi/glapi/gen/apiexec.py
>> +++ b/src/mapi/glapi/gen/apiexec.py
>> @@ -72,7 +72,7 @@ functions = {
>>
>> # OpenGL 3.2 / GL_ARB_geometry_shader4. Mesa does not support
>> # GL_ARB_geometry_shader4, so OpenGL 3.2 is required.
>> -"FramebufferTexture": exec_info(core=32),
>> +"FramebufferTexture": exec_info(core=32, es2=31),
>>
>> # OpenGL 4.0 / GL_ARB_shader_subroutines. Mesa only exposes this
>> # extension with core profile.
>> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
>> index 577d825..f6c49c2 100644
>> --- a/src/mapi/glapi/gen/es_EXT.xml
>> +++ b/src/mapi/glapi/gen/es_EXT.xml
>> @@ -940,4 +940,47 @@
>>
>>
>>
>> +
>> +
>> +
>> +> value="0x8DD9"/>
>> +> value="0x0004"/>
>> +> value="0x8916"/>
>> +> value="0x8917"/>
>> +> value="0x8918"/>
>> +> value="0x887F"/>
>> +> value="0x825E"/>
>> +> value="0x8A2C"/>
>> +> value="0x8A32"/>
>> +> value="0x9123"/>
>> +> value="0x9124"/>
>> +> value="0x8DE0"/>
>> +> value="0x8DE1"/>
>> +> value="0x8E5A"/>
>> +> value="0x8C29"/>
>> +> value="0x92CF"/>
>> +> value="0x92D5"/>
>> +> value="0x90CD"/>
>> +> value="0x90D7"/>
>> +> value="0x8E4D"/>
>> +> value="0x8E4E"/>
>> +> value="0x8260"/>
>> +> value="0x8C87"/>
>> +> value="0xA"/>
>> +> value="0xB"/>
>> +> value="0xC"/>
>> +> value="0xD"/>
>> +> value="0x9312"/>
>> +> value="0x9317"/>
>> +> value="0x8DA8"/>
>> +> value="0x8DA7"/>
>> +> value="0x9309"/>
>> +
>> +> es2="3.1">
>> +
>> +
>> +
>> +
>> +
>> +
>>
>> diff --git a/src/mesa/main/extensions_table.h
>> b/src/mesa/main/extensions_table.h
>> index 051d69a..d3cbb25 100644
>> --- a/src/mesa/main/extensions_table.h
>> +++ b/src/mesa/main/extensions_table.h
>> @@ -307,6 +307,7 @@ EXT(OES_element_index_uint , dummy_true
>> EXT(OES_fbo_render_mipmap , dummy_true
>> , x , x , ES1, ES2, 2005)
>> EXT(OES_fixed_point , dummy_true
>> , x , x , ES1, x , 2002)
>> EXT(OES_framebuffer_object , dummy_true
>> , x , x , ES1, x , 2005)
>> +EXT(OES_geometry_shader , dummy_true
>> , x , x , x , 31, 2015)
>
> This should surely depend on OES_geometry_shader, not dummy_true...
I was going to make the same comment. I was also going to pose the
question: do we expect that every Mesa implementer of GLES3.1 will also
support GL_OES_geometry_shader out-of-the-box? If that's the case, then
we can use dummy_true and gl_extensions::OES_geometry_shader (below)
should be removed.
> Not a huge fan of adding the extra entry to gl_extensions, but I don't
> see a great way around it. It'll all be hidden behind
> _mesa_has_geometry_shaders anyways, so it shouldn't be too bad.
>
>> EXT(OES_get_program_binary , dummy_true
>> , x , x , x , ES2, 2008)
>> EXT(OES_mapbuffer , dummy_true
>> , x , x , ES1, ES2, 2005)
>> EXT(OES_packed_depth_stencil, dummy_true
>> , x , x , ES1, ES2, 2007)
>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>> index c1b18a4..bff355e 100644
>> --- a/src/mesa/main/mtypes.h
>> +++ b/src/mesa/main/mtypes.h
>> @@ -3818,6 +3818,7 @@ struct gl_extensions
>> GLboolean OES_texture_half_float;
>> GLboolean OES_texture_half_float_linear;
>> GLboolean OES_compressed_ETC1_RGB8_texture;
>> + GLboolean OES_geometry_shader;
>> GLboolean extension_sentinel;
>> /** The extension string */
>> const GLubyte *String;
>> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
>> b/src/mesa/main/tests/dispatch_sanity.cpp
>> index 97f81f9..b5b8c8b 100644
>> --- a/src/mesa/main/tests/dispatch_sanity.cpp
>> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
>> @@ -2517,5 +2517,8 @@ const struct function gles31_functions_possible[] = {
>> /* GL_EXT_blend_func_extended */
>> { "glGetProgramResourceLocat
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On 11/27/2015 06:31 AM, Marta Lofstedt wrote:
> From: Marta Lofstedt
>
> This adds glsl support of GL_OES_geometry_shader for
> OpenGL ES 3.1.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/glsl/builtin_variables.cpp | 17 +
> src/glsl/glsl_parser.yy | 4 ++--
> src/glsl/glsl_parser_extras.cpp | 1 +
> src/glsl/glsl_parser_extras.h | 2 ++
> 4 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
> index e8eab80..6a53789 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying * 4);
> }
>
> - if (state->is_version(150, 0)) {
> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
I think it would be better to have a separate patch that adds a
_mesa_glsl_parse_state::has_geometry_shader() method. This patch would
then (mostly) just update that function to know about the new OES extension.
I'm suggesting this because I think there are some apps that use the EXT
version, so we may want to add support for that later. It also makes
the code less cluttered.
>add_const("gl_MaxVertexOutputComponents",
> state->Const.MaxVertexOutputComponents);
>add_const("gl_MaxGeometryInputComponents",
> @@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
> state->Const.MaxCombinedAtomicCounters);
>add_const("gl_MaxAtomicCounterBindings",
> state->Const.MaxAtomicBufferBindings);
> -
> - /* When Mesa adds support for GL_OES_geometry_shader and
> - * GL_OES_tessellation_shader, this will need to change.
> - */
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxGeometryAtomicCounters",
> state->Const.MaxGeometryAtomicCounters);
> add_const("gl_MaxTessControlAtomicCounters",
> @@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxAtomicCounterBufferSize",
> state->Const.MaxAtomicCounterBufferSize);
>
> - /* When Mesa adds support for GL_OES_geometry_shader and
> - * GL_OES_tessellation_shader, this will need to change.
> - */
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxGeometryAtomicCounterBuffers",
> state->Const.MaxGeometryAtomicCounterBuffers);
> add_const("gl_MaxTessControlAtomicCounterBuffers",
> @@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxCombinedImageUniforms",
> state->Const.MaxCombinedImageUniforms);
>
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
> state->Const.MaxCombinedShaderOutputResources);
> add_const("gl_MaxImageSamples",
> @@ -1057,7 +1050,7 @@ builtin_variable_generator::generate_fs_special_vars()
> if (state->is_version(120, 100))
>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>
> - if (state->is_version(150, 0)) {
> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
>var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
>var->data.interpolation = INTERP_QUALIFIER_FLAT;
> }
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index 5a8f980..fae6d0b 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -1262,7 +1262,7 @@ layout_qualifier_id:
> }
> }
>
> - if ($$.flags.i && !state->is_version(150, 0)) {
> + if ($$.flags.i && !state->is_version(150, 320) &&
> !state->OES_geometry_shader_enable) {
> _mesa_glsl_error(& @1, state, "#version 150 layout "
> "qualifier `%s' used", $1);
> }
> @@ -1499,7 +1499,7 @@ layout_qualifier_id:
>if (match_layout_qualifier("max_vertices", $1, state) == 0) {
> $$.flags.q.max_vertices = 1;
> $$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
> - if (!state->is_version(150, 0)) {
> + if (!state->is_version(150, 310)) {
> _mesa_glsl_error(& @3, state,
> "#version 150 max_vertices qualifier "
> "specified", $3);
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index 7138925..193cc2a 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -635,6 +635,7 @@ static const _mesa_glsl_extension
> _mesa_glsl_supported_extensions[] = {
> /* O
Re: [Mesa-dev] [PATCH 1/3] radeon: whitespace cleanup
Patch 1 and patch 2 are Reviewed-by: Ian Romanick On 11/28/2015 07:43 AM, Giuseppe Bilotta wrote: > Signed-off-by: Giuseppe Bilotta > --- > src/mesa/drivers/dri/radeon/radeon_swtcl.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/drivers/dri/radeon/radeon_swtcl.c > b/src/mesa/drivers/dri/radeon/radeon_swtcl.c > index 1e19cf7..ed6b25c 100644 > --- a/src/mesa/drivers/dri/radeon/radeon_swtcl.c > +++ b/src/mesa/drivers/dri/radeon/radeon_swtcl.c > @@ -417,9 +417,9 @@ static GLboolean radeon_run_render( struct gl_context > *ctx, > tnl_render_func *tab = TAG(render_tab_verts); > GLuint i; > > - if (rmesa->radeon.swtcl.RenderIndex != 0 || > + if (rmesa->radeon.swtcl.RenderIndex != 0 || > !radeon_dma_validate_render( ctx, VB )) > - return GL_TRUE; > + return GL_TRUE; > > radeon_prepare_render(&rmesa->radeon); > if (rmesa->radeon.NewGLState) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] misc janitorial
On 11/29/2015 07:21 AM, Emil Velikov wrote: > Hi Giuseppe, > > On 28 November 2015 at 15:43, Giuseppe Bilotta > wrote: >> The second and third patches are mostly aimed at removing non-spurious >> compiler warnings. The first one is just minor whitespace cleanup in the >> general area of code touched by the second patch. >> >> Giuseppe Bilotta (3): >> radeon: whitespace cleanup >> radeon: const correctness >> xvmc: force assertion in XvMC tests >> > With the small comment in patch 3 addressed the series is > Reviewed-by: Emil Velikov > > If you're looking for an easy task - there is one in radeon/r200. > Currently we have a lot of nasty in-tree symlinks, symbol duplication > and hacks to get around it. Let me know if you'd like more info/tips > on how to tackle it. This is something that has been annoying me a bit lately. What do you think the right solution is? The Intel driver used to have a common src/mesa/drivers/dri/intel directory that was compiled once and shared by i915 and i965. The code paths started to diverge quite a lot, so we copied the shared files into each directory... and became non-shared. Note that we didn't rename any of the function names, so we still have the ugly hacks to get around the symbol duplication. > Thanks > Emil > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: support GL_RED/GL_RG in ES2 contexts when driver support exists
On Sat, Nov 28, 2015 at 05:17:22PM -0500, Ilia Mirkin wrote:
> On Sat, Nov 28, 2015 at 1:14 PM, Eduardo Lima Mitev wrote:
> > Patch is:
> >
> > Reviewed-by: Eduardo Lima Mitev
>
> Thanks! I realized that this should also return invalid for GLES 1...
> I'm adding ctx->API == API_OPENGLES and pushing.
>
For future reference, you could use !_mesa_has_EXT_texture_rg(ctx).
-Nanley
> >
> > On 11/26/2015 04:57 PM, Ilia Mirkin wrote:
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93126
> >> Signed-off-by: Ilia Mirkin
> >> Cc: "11.0 11.1"
> >> ---
> >> src/mesa/main/glformats.c | 8 +++-
> >> src/mesa/main/glformats.h | 3 ++-
> >> src/mesa/main/readpix.c | 2 +-
> >> src/mesa/main/teximage.c | 2 +-
> >> 4 files changed, 11 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> >> index 2ed42ea..7b264eb 100644
> >> --- a/src/mesa/main/glformats.c
> >> +++ b/src/mesa/main/glformats.c
> >> @@ -2077,12 +2077,18 @@ _mesa_error_check_format_and_type(const struct
> >> gl_context *ctx,
> >> * \return error code, or GL_NO_ERROR.
> >> */
> >> GLenum
> >> -_mesa_es_error_check_format_and_type(GLenum format, GLenum type,
> >> +_mesa_es_error_check_format_and_type(const struct gl_context *ctx,
> >> + GLenum format, GLenum type,
> >> unsigned dimensions)
> >> {
> >> GLboolean type_valid = GL_TRUE;
> >>
> >> switch (format) {
> >> + case GL_RED:
> >> + case GL_RG:
> >> + if (!ctx->Extensions.ARB_texture_rg)
> >> + return GL_INVALID_VALUE;
> >> + /* fallthrough */
> >> case GL_ALPHA:
> >> case GL_LUMINANCE:
> >> case GL_LUMINANCE_ALPHA:
> >> diff --git a/src/mesa/main/glformats.h b/src/mesa/main/glformats.h
> >> index 92f4bc6..b366855 100644
> >> --- a/src/mesa/main/glformats.h
> >> +++ b/src/mesa/main/glformats.h
> >> @@ -127,7 +127,8 @@ _mesa_error_check_format_and_type(const struct
> >> gl_context *ctx,
> >>GLenum format, GLenum type);
> >>
> >> extern GLenum
> >> -_mesa_es_error_check_format_and_type(GLenum format, GLenum type,
> >> +_mesa_es_error_check_format_and_type(const struct gl_context *ctx,
> >> + GLenum format, GLenum type,
> >> unsigned dimensions);
> >>
> >> extern GLenum
> >> diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
> >> index 81bb912..8cdc9fe 100644
> >> --- a/src/mesa/main/readpix.c
> >> +++ b/src/mesa/main/readpix.c
> >> @@ -1043,7 +1043,7 @@ _mesa_ReadnPixelsARB( GLint x, GLint y, GLsizei
> >> width, GLsizei height,
> >>_mesa_get_color_read_type(ctx) == type) {
> >> err = GL_NO_ERROR;
> >>} else if (ctx->Version < 30) {
> >> - err = _mesa_es_error_check_format_and_type(format, type, 2);
> >> + err = _mesa_es_error_check_format_and_type(ctx, format, type, 2);
> >> if (err == GL_NO_ERROR) {
> >> if (type == GL_FLOAT || type == GL_HALF_FLOAT_OES) {
> >> err = GL_INVALID_OPERATION;
> >> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> >> index ac7599f..37dbe26 100644
> >> --- a/src/mesa/main/teximage.c
> >> +++ b/src/mesa/main/teximage.c
> >> @@ -1699,7 +1699,7 @@ texture_format_error_check_gles(struct gl_context
> >> *ctx, GLenum format,
> >>}
> >> }
> >> else {
> >> - err = _mesa_es_error_check_format_and_type(format, type,
> >> dimensions);
> >> + err = _mesa_es_error_check_format_and_type(ctx, format, type,
> >> dimensions);
> >>if (err != GL_NO_ERROR) {
> >> _mesa_error(ctx, err, "%s(format = %s, type = %s)",
> >> callerName, _mesa_enum_to_string(format),
> >>
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] misc janitorial
On 30 November 2015 at 20:00, Ian Romanick wrote:
> On 11/29/2015 07:21 AM, Emil Velikov wrote:
>> Hi Giuseppe,
>>
>> On 28 November 2015 at 15:43, Giuseppe Bilotta
>> wrote:
>>> The second and third patches are mostly aimed at removing non-spurious
>>> compiler warnings. The first one is just minor whitespace cleanup in the
>>> general area of code touched by the second patch.
>>>
>>> Giuseppe Bilotta (3):
>>> radeon: whitespace cleanup
>>> radeon: const correctness
>>> xvmc: force assertion in XvMC tests
>>>
>> With the small comment in patch 3 addressed the series is
>> Reviewed-by: Emil Velikov
>>
>> If you're looking for an easy task - there is one in radeon/r200.
>> Currently we have a lot of nasty in-tree symlinks, symbol duplication
>> and hacks to get around it. Let me know if you'd like more info/tips
>> on how to tackle it.
>
> This is something that has been annoying me a bit lately. What do you
> think the right solution is? The Intel driver used to have a common
> src/mesa/drivers/dri/intel directory that was compiled once and shared
> by i915 and i965. The code paths started to diverge quite a lot, so we
> copied the shared files into each directory... and became non-shared.
> Note that we didn't rename any of the function names, so we still have
> the ugly hacks to get around the symbol duplication.
>
I'm not sure about "right and wrong" but the possible solution I was
thinking is the one you mentioned - have a common place where that
code is built once.
The long version:
1. Grep for RADEON_R{1,2}00 and look at the guarded code
1.1 Some guards can just be dropped (CHIP_FAMILY_*, get_chip_family_name),
1.2 Other hunks of code can be split/moved into the respective
r100/r200 codebase (radeonTexBufferExtension and
r200TexBufferExtension).
1.3 Or folded into the vtbl dispatch - get_depth_z32/16 or the
respective callers, depending on the overhead (neither one is likely
to be noticeable).
2. Copy/pasta an existing radeon Makefile to radeon_common. Tweak to
produce an empty library and get it into the final mega_dri_drivers.so
2.1 With most/all of the RADEON_R*00 guards gone, one should be able
to just git mv the files into the new location. (alongside dropping
the symlinks)
2.2 Remove the symbol redefinition hack.
It's a lengthy task, yet relatively easy. As long one tries to divide
and concur, rather than understand, in depth, how the driver/autohell
buildsystem works :-)
I'm more than willing to help out on the lot (esp. the latter), just
shout when you get confused/stuck.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Do dead-code elimination in a single pass.
The first pass marked dead instructions as opcode = NOP, and a second
pass deleted those instructions so that the live ranges used in the
first pass wouldn't change.
But since we're walking the instructions in reverse order, we can just
do everything in one pass. The only thing we have to do is walk the
blocks in reverse as well.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 3 +++
.../drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 21 ++---
.../dri/i965/brw_vec4_dead_code_eliminate.cpp | 21 +++--
3 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 69e39e8..405020b 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -314,6 +314,9 @@ struct cfg_t {
#define foreach_block_safe(__block, __cfg) \
foreach_list_typed_safe (bblock_t, __block, link, &(__cfg)->block_list)
+#define foreach_block_reverse_safe(__block, __cfg) \
+ foreach_list_typed_reverse_safe (bblock_t, __block, link,
&(__cfg)->block_list)
+
#define foreach_inst_in_block(__type, __inst, __block) \
foreach_in_list(__type, __inst, &(__block)->instructions)
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 6b4b602..bd57e09 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
@@ -45,13 +45,13 @@ fs_visitor::dead_code_eliminate()
BITSET_WORD *live = ralloc_array(NULL, BITSET_WORD, BITSET_WORDS(num_vars));
BITSET_WORD *flag_live = ralloc_array(NULL, BITSET_WORD, 1);
- foreach_block (block, cfg) {
+ foreach_block_reverse_safe(block, cfg) {
memcpy(live, live_intervals->block_data[block->num].liveout,
sizeof(BITSET_WORD) * BITSET_WORDS(num_vars));
memcpy(flag_live, live_intervals->block_data[block->num].flag_liveout,
sizeof(BITSET_WORD));
- foreach_inst_in_block_reverse(fs_inst, inst, block) {
+ foreach_inst_in_block_reverse_safe(fs_inst, inst, block) {
if (inst->dst.file == VGRF && !inst->has_side_effects()) {
bool result_live = false;
@@ -72,7 +72,6 @@ fs_visitor::dead_code_eliminate()
inst->dst = fs_reg(retype(brw_null_reg(), inst->dst.type));
} else {
inst->opcode = BRW_OPCODE_NOP;
- continue;
}
}
}
@@ -81,7 +80,6 @@ fs_visitor::dead_code_eliminate()
if (!BITSET_TEST(flag_live, inst->flag_subreg)) {
inst->opcode = BRW_OPCODE_NOP;
progress = true;
- continue;
}
}
@@ -93,7 +91,6 @@ fs_visitor::dead_code_eliminate()
!inst->writes_accumulator) {
inst->opcode = BRW_OPCODE_NOP;
progress = true;
-continue;
}
if (inst->dst.file == VGRF) {
@@ -109,9 +106,10 @@ fs_visitor::dead_code_eliminate()
BITSET_CLEAR(flag_live, inst->flag_subreg);
}
- /* Don't mark dead instructions' sources as live */
- if (inst->opcode == BRW_OPCODE_NOP)
+ if (inst->opcode == BRW_OPCODE_NOP) {
+inst->remove(block);
continue;
+ }
for (int i = 0; i < inst->sources; i++) {
if (inst->src[i].file == VGRF) {
@@ -132,15 +130,8 @@ fs_visitor::dead_code_eliminate()
ralloc_free(live);
ralloc_free(flag_live);
- if (progress) {
- foreach_block_and_inst_safe (block, backend_instruction, inst, cfg) {
- if (inst->opcode == BRW_OPCODE_NOP) {
-inst->remove(block);
- }
- }
-
+ if (progress)
invalidate_live_intervals();
- }
return progress;
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
index 369941b..2d0722a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
@@ -71,13 +71,13 @@ vec4_visitor::dead_code_eliminate()
BITSET_WORD *live = ralloc_array(NULL, BITSET_WORD, BITSET_WORDS(num_vars));
BITSET_WORD *flag_live = ralloc_array(NULL, BITSET_WORD, 1);
- foreach_block(block, cfg) {
+ foreach_block_reverse_safe(block, cfg) {
memcpy(live, live_intervals->block_data[block->num].liveout,
sizeof(BITSET_WORD) * BITSET_WORDS(num_vars));
memcpy(flag_live, live_intervals->block_data[block->num].flag_liveout,
sizeof(BITSET_WORD));
- foreach_inst_in_block_reverse(vec4_instruction, inst, block) {
+ foreach_inst_in_block_reverse_safe(vec4_instruction, inst, block) {
if ((inst->dst.file == VGRF && !inst->has_side_effects()) ||
(i
[Mesa-dev] [PATCH 1/2] glsl: Rename safe_reverse -> reverse_safe.
To match existing foreach_in_list_reverse_safe.
---
src/glsl/list.h| 2 +-
src/glsl/nir/nir.c | 8
src/glsl/nir/nir.h | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 15fcd4a..a1c4d82 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -688,7 +688,7 @@ inline void exec_node::insert_before(exec_list *before)
__node = __next, __next = \
exec_node_data(__type, (__next)->__field.next, __field))
-#define foreach_list_typed_safe_reverse(__type, __node, __field, __list) \
+#define foreach_list_typed_reverse_safe(__type, __node, __field, __list) \
for (__type * __node = \
exec_node_data(__type, (__list)->tail_pred, __field), \
* __prev = \
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index bfec11e..35fc1de 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -1376,13 +1376,13 @@ static inline bool
foreach_if(nir_if *if_stmt, nir_foreach_block_cb cb, bool reverse, void *state)
{
if (reverse) {
- foreach_list_typed_safe_reverse(nir_cf_node, node, node,
+ foreach_list_typed_reverse_safe(nir_cf_node, node, node,
&if_stmt->else_list) {
if (!foreach_cf_node(node, cb, reverse, state))
return false;
}
- foreach_list_typed_safe_reverse(nir_cf_node, node, node,
+ foreach_list_typed_reverse_safe(nir_cf_node, node, node,
&if_stmt->then_list) {
if (!foreach_cf_node(node, cb, reverse, state))
return false;
@@ -1406,7 +1406,7 @@ static inline bool
foreach_loop(nir_loop *loop, nir_foreach_block_cb cb, bool reverse, void
*state)
{
if (reverse) {
- foreach_list_typed_safe_reverse(nir_cf_node, node, node, &loop->body) {
+ foreach_list_typed_reverse_safe(nir_cf_node, node, node, &loop->body) {
if (!foreach_cf_node(node, cb, reverse, state))
return false;
}
@@ -1466,7 +1466,7 @@ nir_foreach_block_reverse(nir_function_impl *impl,
nir_foreach_block_cb cb,
if (!cb(impl->end_block, state))
return false;
- foreach_list_typed_safe_reverse(nir_cf_node, node, node, &impl->body) {
+ foreach_list_typed_reverse_safe(nir_cf_node, node, node, &impl->body) {
if (!foreach_cf_node(node, cb, true, state))
return false;
}
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 524717a..e161b70 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -1276,8 +1276,8 @@ nir_block_last_instr(nir_block *block)
foreach_list_typed_reverse(nir_instr, instr, node, &(block)->instr_list)
#define nir_foreach_instr_safe(block, instr) \
foreach_list_typed_safe(nir_instr, instr, node, &(block)->instr_list)
-#define nir_foreach_instr_safe_reverse(block, instr) \
- foreach_list_typed_safe_reverse(nir_instr, instr, node,
&(block)->instr_list)
+#define nir_foreach_instr_reverse_safe(block, instr) \
+ foreach_list_typed_reverse_safe(nir_instr, instr, node,
&(block)->instr_list)
typedef struct nir_if {
nir_cf_node cf_node;
--
2.4.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] misc janitorial
On 1 December 2015 at 07:18, Emil Velikov wrote:
> On 30 November 2015 at 20:00, Ian Romanick wrote:
>> On 11/29/2015 07:21 AM, Emil Velikov wrote:
>>> Hi Giuseppe,
>>>
>>> On 28 November 2015 at 15:43, Giuseppe Bilotta
>>> wrote:
The second and third patches are mostly aimed at removing non-spurious
compiler warnings. The first one is just minor whitespace cleanup in the
general area of code touched by the second patch.
Giuseppe Bilotta (3):
radeon: whitespace cleanup
radeon: const correctness
xvmc: force assertion in XvMC tests
>>> With the small comment in patch 3 addressed the series is
>>> Reviewed-by: Emil Velikov
>>>
>>> If you're looking for an easy task - there is one in radeon/r200.
>>> Currently we have a lot of nasty in-tree symlinks, symbol duplication
>>> and hacks to get around it. Let me know if you'd like more info/tips
>>> on how to tackle it.
>>
>> This is something that has been annoying me a bit lately. What do you
>> think the right solution is? The Intel driver used to have a common
>> src/mesa/drivers/dri/intel directory that was compiled once and shared
>> by i915 and i965. The code paths started to diverge quite a lot, so we
>> copied the shared files into each directory... and became non-shared.
>> Note that we didn't rename any of the function names, so we still have
>> the ugly hacks to get around the symbol duplication.
>>
> I'm not sure about "right and wrong" but the possible solution I was
> thinking is the one you mentioned - have a common place where that
> code is built once.
>
> The long version:
> 1. Grep for RADEON_R{1,2}00 and look at the guarded code
> 1.1 Some guards can just be dropped (CHIP_FAMILY_*, get_chip_family_name),
> 1.2 Other hunks of code can be split/moved into the respective
> r100/r200 codebase (radeonTexBufferExtension and
> r200TexBufferExtension).
> 1.3 Or folded into the vtbl dispatch - get_depth_z32/16 or the
> respective callers, depending on the overhead (neither one is likely
> to be noticeable).
> 2. Copy/pasta an existing radeon Makefile to radeon_common. Tweak to
> produce an empty library and get it into the final mega_dri_drivers.so
> 2.1 With most/all of the RADEON_R*00 guards gone, one should be able
> to just git mv the files into the new location. (alongside dropping
> the symlinks)
> 2.2 Remove the symbol redefinition hack.
>
> It's a lengthy task, yet relatively easy. As long one tries to divide
> and concur, rather than understand, in depth, how the driver/autohell
> buildsystem works :-)
> I'm more than willing to help out on the lot (esp. the latter), just
> shout when you get confused/stuck.
But why bother?
Getting someone with r100/r200 hardware to test is the fun part,
We've already seen that changes in this area untested mostly break stuff,
rather than help, and go unnoticed for whole releases at a time.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support
On 30 November 2015 at 19:51, Marek Olšák wrote: > On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote: >> Hi, >> >> Patchbomb time, this set of patches is a first pass at add adding >> ARB_tessellation_shader support to the r600g driver. Only Evergreen >> and newer GPUs support tessellation. On any of the GPUs that support >> native FP64, this will enable OpenGL 4.1 on them. >> >> The first bunch of patches are a bit of a driver rework to get >> things in better shape for tessellation, they shouldn't cause >> any regressions. >> >> This runs heaven on cayman and should pass all the piglits >> unless I've done something wrong. >> >> Development hit two HW programming fun times, one with tess and >> dynamic GPR interaction requiring disabling dynamic GPRs, and >> one with programming of some SIMD registers to block TESS shaders >> on one unit. These fixed most of the hangs we saw during development. >> >> This doesn't contain SB support yet, Glenn has started working on it. >> >> Currently tested hw: >> working: CAYMAN, REDWOOD, BARTS, TURKS >> hangs on any tessellation: CAYMAN >> hangs differently at least with heaven: SUMO > > You listed CAYMAN twice, so does it hang or not? oops CAICOS I meant. I have some fglrx traces from it, I just haven't had time to dig into it yet. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] st/va: delay decoder creation until max_references is known
On 30 November 2015 at 12:03, Emil Velikov wrote:
> On 26 November 2015 at 08:45, Julien Isorce
> wrote:
>
> > --- a/src/gallium/state_trackers/va/picture.c
> > +++ b/src/gallium/state_trackers/va/picture.c
>
> > @@ -113,12 +118,37 @@ handlePictureParameterBuffer(vlVaDriver *drv,
> vlVaContext *context, vlVaBuffer *
> > default:
> >break;
> > }
> > +
> > + /* Create the decoder once max_references is known. */
> > + if (!context->decoder) {
> > + if (!context->target)
> > + return VA_STATUS_ERROR_INVALID_CONTEXT;
> > +
> > + if (context->templat.max_references == 0)
> > + return VA_STATUS_ERROR_INVALID_BUFFER;
> > +
> > + if (u_reduce_video_profile(context->templat.profile) !=
> > + PIPE_VIDEO_FORMAT_MPEG4_AVC)
> > + context->templat.level =
> u_get_h264_level(context->templat.width,
> > +context->templat.height, &context->templat.max_references);
>
> Erm shouldn't this one be "if profile == h264 { get_h264_level(...) }" ?
>
Indeed :) Thx Emil.
>
> With the above fixed
> Reviewed-by: Emil Velikov
>
> -Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support
On Mon, Nov 30, 2015 at 5:06 PM, Dave Airlie wrote: > On 30 November 2015 at 19:51, Marek Olšák wrote: >> On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote: >>> Hi, >>> >>> Patchbomb time, this set of patches is a first pass at add adding >>> ARB_tessellation_shader support to the r600g driver. Only Evergreen >>> and newer GPUs support tessellation. On any of the GPUs that support >>> native FP64, this will enable OpenGL 4.1 on them. >>> >>> The first bunch of patches are a bit of a driver rework to get >>> things in better shape for tessellation, they shouldn't cause >>> any regressions. >>> >>> This runs heaven on cayman and should pass all the piglits >>> unless I've done something wrong. >>> >>> Development hit two HW programming fun times, one with tess and >>> dynamic GPR interaction requiring disabling dynamic GPRs, and >>> one with programming of some SIMD registers to block TESS shaders >>> on one unit. These fixed most of the hangs we saw during development. >>> >>> This doesn't contain SB support yet, Glenn has started working on it. >>> >>> Currently tested hw: >>> working: CAYMAN, REDWOOD, BARTS, TURKS >>> hangs on any tessellation: CAYMAN >>> hangs differently at least with heaven: SUMO >> >> You listed CAYMAN twice, so does it hang or not? > > oops CAICOS I meant. > > I have some fglrx traces from it, I just haven't had time to dig into it yet. The smaller parts have different numbers of gprs, etc. compared to the bigger parts. Might try tweaking the gpr allocations. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/12] mesa: Drop the blacklisting of new GL enums.
Ilia Mirkin writes:
> On Wed, Nov 25, 2015 at 10:10 PM, Eric Anholt wrote:
>> index bff425a..4c89849 100644
>> --- a/src/mesa/main/tests/enum_strings.cpp
>> +++ b/src/mesa/main/tests/enum_strings.cpp
>> @@ -71,7 +71,7 @@ const struct enum_info everything[] = {
>> * see go farther. Disabled for the moment since Mesa doesn't have the
>> XML
>> * for it yet.
>> */
>> - /* { 0x80a1, "GL_1PASS_EXT" }, */
>> + { 0x80a1, "GL_1PASS_EXT" },
>
> Does the comment above this need to go? At least the bit about disabling?
Fixed. Thanks!
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93053] GL_PROGRAM_BINARY_LENGTH always reports 0
https://bugs.freedesktop.org/show_bug.cgi?id=93053 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #3 from Ian Romanick --- The extension is supported, but there are no binary formats supported. Since there is no binary format, there is no data in any binary format. It's a bit of a dirty trick, but it is what it is. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 92757] GL_ARB_sync objects are not properly synchronized across threads
https://bugs.freedesktop.org/show_bug.cgi?id=92757 Ian Romanick changed: What|Removed |Added CC||i...@freedesktop.org, ||matts...@gmail.com --- Comment #2 from Ian Romanick --- I think there are quite a few kinds of GL objects that suffer from this problem. I recall Matt sending out some patches a few months ago that changed some of the locking around objects. I noticed this pre-existing problem while reviewing his code. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Ian Romanick changed: What|Removed |Added Depends on||92557 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 92124] shader_query.cpp:841:34: error: ‘strndup’ was not declared in this scope
https://bugs.freedesktop.org/show_bug.cgi?id=92124 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89773] "builtin_functions.cpp", line 3218: Error: INFINITY is not defined.
https://bugs.freedesktop.org/show_bug.cgi?id=89773 Ian Romanick changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Ian Romanick --- Does this problem still exist? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89773] "builtin_functions.cpp", line 3218: Error: INFINITY is not defined.
https://bugs.freedesktop.org/show_bug.cgi?id=89773 Ian Romanick changed: What|Removed |Added CC||alan.coopersm...@oracle.com --- Comment #2 from Ian Romanick --- Adding Alan to CC in case he has a suggestion. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).
---
src/glsl/builtin_functions.cpp | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 88f9a71..2f21ffc 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -538,6 +538,7 @@ private:
ir_variable *in_var(const glsl_type *type, const char *name);
ir_variable *out_var(const glsl_type *type, const char *name);
ir_constant *imm(float f, unsigned vector_elements=1);
+ ir_constant *imm(bool b, unsigned vector_elements=1);
ir_constant *imm(int i, unsigned vector_elements=1);
ir_constant *imm(unsigned u, unsigned vector_elements=1);
ir_constant *imm(double d, unsigned vector_elements=1);
@@ -3000,6 +3001,12 @@ builtin_builder::out_var(const glsl_type *type, const
char *name)
}
ir_constant *
+builtin_builder::imm(bool b, unsigned vector_elements)
+{
+ return new(mem_ctx) ir_constant(b, vector_elements);
+}
+
+ir_constant *
builtin_builder::imm(float f, unsigned vector_elements)
{
return new(mem_ctx) ir_constant(f, vector_elements);
@@ -4358,7 +4365,13 @@ builtin_builder::_notEqual(builtin_available_predicate
avail,
ir_function_signature *
builtin_builder::_any(const glsl_type *type)
{
- return unop(always_available, ir_unop_any, glsl_type::bool_type, type);
+ ir_variable *v = in_var(type, "v");
+ MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
+
+ const unsigned vec_elem = v->type->vector_elements;
+ body.emit(ret(expr(ir_binop_any_nequal, v, imm(false, vec_elem;
+
+ return sig;
}
ir_function_signature *
--
2.4.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] glsl: Switch opcode and avail parameters to binop().
To make it match unop().
---
src/glsl/builtin_functions.cpp | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index c5489b7..88f9a71 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -606,8 +606,8 @@ private:
ir_expression_operation opcode,
const glsl_type *return_type,
const glsl_type *param_type);
- ir_function_signature *binop(ir_expression_operation opcode,
-builtin_available_predicate avail,
+ ir_function_signature *binop(builtin_available_predicate avail,
+ir_expression_operation opcode,
const glsl_type *return_type,
const glsl_type *param0_type,
const glsl_type *param1_type);
@@ -3114,8 +3114,8 @@ builtin_builder::_##NAME(builtin_available_predicate
avail, const glsl_type *typ
}
ir_function_signature *
-builtin_builder::binop(ir_expression_operation opcode,
- builtin_available_predicate avail,
+builtin_builder::binop(builtin_available_predicate avail,
+ ir_expression_operation opcode,
const glsl_type *return_type,
const glsl_type *param0_type,
const glsl_type *param1_type)
@@ -3411,7 +3411,7 @@ builtin_builder::_atanh(const glsl_type *type)
ir_function_signature *
builtin_builder::_pow(const glsl_type *type)
{
- return binop(ir_binop_pow, always_available, type, type, type);
+ return binop(always_available, ir_binop_pow, type, type, type);
}
UNOP(exp, ir_unop_exp, always_available)
@@ -3435,7 +3435,7 @@ UNOPA(fract, ir_unop_fract)
ir_function_signature *
builtin_builder::_mod(const glsl_type *x_type, const glsl_type *y_type)
{
- return binop(ir_binop_mod, always_available, x_type, x_type, y_type);
+ return binop(always_available, ir_binop_mod, x_type, x_type, y_type);
}
ir_function_signature *
@@ -3457,14 +3457,14 @@ ir_function_signature *
builtin_builder::_min(builtin_available_predicate avail,
const glsl_type *x_type, const glsl_type *y_type)
{
- return binop(ir_binop_min, avail, x_type, x_type, y_type);
+ return binop(avail, ir_binop_min, x_type, x_type, y_type);
}
ir_function_signature *
builtin_builder::_max(builtin_available_predicate avail,
const glsl_type *x_type, const glsl_type *y_type)
{
- return binop(ir_binop_max, avail, x_type, x_type, y_type);
+ return binop(avail, ir_binop_max, x_type, x_type, y_type);
}
ir_function_signature *
@@ -3793,9 +3793,9 @@ ir_function_signature *
builtin_builder::_dot(builtin_available_predicate avail, const glsl_type *type)
{
if (type->vector_elements == 1)
- return binop(ir_binop_mul, avail, type, type, type);
+ return binop(avail, ir_binop_mul, type, type, type);
- return binop(ir_binop_dot, avail,
+ return binop(avail, ir_binop_dot,
type->get_base_type(), type, type);
}
@@ -4311,7 +4311,7 @@ ir_function_signature *
builtin_builder::_lessThan(builtin_available_predicate avail,
const glsl_type *type)
{
- return binop(ir_binop_less, avail,
+ return binop(avail, ir_binop_less,
glsl_type::bvec(type->vector_elements), type, type);
}
@@ -4319,7 +4319,7 @@ ir_function_signature *
builtin_builder::_lessThanEqual(builtin_available_predicate avail,
const glsl_type *type)
{
- return binop(ir_binop_lequal, avail,
+ return binop(avail, ir_binop_lequal,
glsl_type::bvec(type->vector_elements), type, type);
}
@@ -4327,7 +4327,7 @@ ir_function_signature *
builtin_builder::_greaterThan(builtin_available_predicate avail,
const glsl_type *type)
{
- return binop(ir_binop_greater, avail,
+ return binop(avail, ir_binop_greater,
glsl_type::bvec(type->vector_elements), type, type);
}
@@ -4335,7 +4335,7 @@ ir_function_signature *
builtin_builder::_greaterThanEqual(builtin_available_predicate avail,
const glsl_type *type)
{
- return binop(ir_binop_gequal, avail,
+ return binop(avail, ir_binop_gequal,
glsl_type::bvec(type->vector_elements), type, type);
}
@@ -4343,7 +4343,7 @@ ir_function_signature *
builtin_builder::_equal(builtin_available_predicate avail,
const glsl_type *type)
{
- return binop(ir_binop_equal, avail,
+ return binop(avail, ir_binop_equal,
glsl_type::bvec(type->vector_elements), type, type);
}
@@ -4351,7 +4351,7 @@ ir_function_signature *
builtin_builder::_notEqual(builtin_available_predicate avail,
[Mesa-dev] [PATCH 6/6] i965/vec4: Optimize predicate handling for any/all.
For a select whose condition is any(v), instead of emitting
cmp.nz.f0(8)null<1>Dg1<0,4,1>D 0D
mov(8) g7<1>.xUD 0xUD
(+f0.any4h) mov(8) g7<1>.xUD0xUD
cmp.nz.f0(8)null<1>Dg7<4,4,1>.xD0D
(+f0) sel(8)g8<1>UD g4<4,4,1>UD g3<4,4,1>UD
we now emit
cmp.nz.f0(8)null<1>Dg1<0,4,1>D 0D
(+f0.any4h) sel(8) g9<1>UD g4<4,4,1>UD g3<4,4,1>UD
---
src/mesa/drivers/dri/i965/brw_vec4.h | 2 +
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 96 --
2 files changed, 80 insertions(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 25b1139..ae98325 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -313,6 +313,8 @@ public:
bool is_high_sampler(src_reg sampler);
+ bool optimize_predicate(nir_alu_instr *instr, enum brw_predicate
*predicate);
+
virtual void emit_nir_code();
virtual void nir_setup_inputs();
virtual void nir_setup_uniforms();
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 457..f734171 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -928,6 +928,62 @@ brw_conditional_for_nir_comparison(nir_op op)
}
}
+bool
+vec4_visitor::optimize_predicate(nir_alu_instr *instr,
+ enum brw_predicate *predicate)
+{
+ if (!instr->src[0].src.is_ssa ||
+ !instr->src[0].src.ssa->parent_instr)
+ return false;
+
+ if (instr->src[0].src.ssa->parent_instr->type != nir_instr_type_alu)
+ return false;
+
+ nir_alu_instr *cmp_instr =
+ nir_instr_as_alu(instr->src[0].src.ssa->parent_instr);
+
+ switch (cmp_instr->op) {
+ case nir_op_bany_fnequal2:
+ case nir_op_bany_inequal2:
+ case nir_op_bany_fnequal3:
+ case nir_op_bany_inequal3:
+ case nir_op_bany_fnequal4:
+ case nir_op_bany_inequal4:
+ *predicate = BRW_PREDICATE_ALIGN16_ANY4H;
+ break;
+ case nir_op_ball_fequal2:
+ case nir_op_ball_iequal2:
+ case nir_op_ball_fequal3:
+ case nir_op_ball_iequal3:
+ case nir_op_ball_fequal4:
+ case nir_op_ball_iequal4:
+ *predicate = BRW_PREDICATE_ALIGN16_ALL4H;
+ break;
+ default:
+ return false;
+ }
+
+ unsigned size_swizzle =
+ brw_swizzle_for_size(nir_op_infos[cmp_instr->op].input_sizes[0]);
+
+ src_reg op[2];
+ assert(nir_op_infos[cmp_instr->op].num_inputs == 2);
+ for (unsigned i = 0; i < 2; i++) {
+ op[i] = get_nir_src(cmp_instr->src[i].src,
+ nir_op_infos[cmp_instr->op].input_types[i], 4);
+ unsigned base_swizzle =
+ brw_swizzle_for_nir_swizzle(cmp_instr->src[i].swizzle);
+ op[i].swizzle = brw_compose_swizzle(size_swizzle, base_swizzle);
+ op[i].abs = cmp_instr->src[i].abs;
+ op[i].negate = cmp_instr->src[i].negate;
+ }
+
+ emit(CMP(dst_null_d(), op[0], op[1],
+brw_conditional_for_nir_comparison(cmp_instr->op)));
+
+ return true;
+}
+
void
vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
{
@@ -1418,25 +1474,29 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
break;
case nir_op_bcsel:
- emit(CMP(dst_null_d(), op[0], brw_imm_d(0), BRW_CONDITIONAL_NZ));
- inst = emit(BRW_OPCODE_SEL, dst, op[1], op[2]);
- switch (dst.writemask) {
- case WRITEMASK_X:
- inst->predicate = BRW_PREDICATE_ALIGN16_REPLICATE_X;
- break;
- case WRITEMASK_Y:
- inst->predicate = BRW_PREDICATE_ALIGN16_REPLICATE_Y;
- break;
- case WRITEMASK_Z:
- inst->predicate = BRW_PREDICATE_ALIGN16_REPLICATE_Z;
- break;
- case WRITEMASK_W:
- inst->predicate = BRW_PREDICATE_ALIGN16_REPLICATE_W;
- break;
- default:
- inst->predicate = BRW_PREDICATE_NORMAL;
- break;
+ enum brw_predicate predicate;
+ if (!optimize_predicate(instr, &predicate)) {
+ emit(CMP(dst_null_d(), op[0], brw_imm_d(0), BRW_CONDITIONAL_NZ));
+ switch (dst.writemask) {
+ case WRITEMASK_X:
+predicate = BRW_PREDICATE_ALIGN16_REPLICATE_X;
+break;
+ case WRITEMASK_Y:
+predicate = BRW_PREDICATE_ALIGN16_REPLICATE_Y;
+break;
+ case WRITEMASK_Z:
+predicate = BRW_PREDICATE_ALIGN16_REPLICATE_Z;
+break;
+ case WRITEMASK_W:
+predicate = BRW_PREDICATE_ALIGN16_REPLICATE_W;
+break;
+ default:
+predicate = BRW_PREDICATE_NORMAL;
+break;
+ }
}
+ inst = emit(BRW_OPCODE_SEL, dst, op[1], op[2]);
+ inst->predicate = predicate;
break;
case nir_op_fdot_replicated2:
--
2.4.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lis
[Mesa-dev] [PATCH 5/6] nir: Delete bany, ball, fany, fall.
As in the previous patches, these can be implemented as
any(v) -> any_nequal(v, false)
all(v) -> all_equal(v, true)
and their removal simplifies the code in the next patch.
---
src/gallium/auxiliary/nir/tgsi_to_nir.c| 4 +++-
src/glsl/nir/nir_lower_alu_to_scalar.c | 4
src/glsl/nir/nir_opcodes.py| 7 ---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 6 --
.../drivers/dri/i965/brw_nir_analyze_boolean_resolves.c| 3 ---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 14 --
src/mesa/program/prog_to_nir.c | 4 ++--
7 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 86c2ffa..87d702d 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1062,7 +1062,9 @@ ttn_kill(nir_builder *b, nir_op op, nir_alu_dest dest,
nir_ssa_def **src)
static void
ttn_kill_if(nir_builder *b, nir_op op, nir_alu_dest dest, nir_ssa_def **src)
{
- nir_ssa_def *cmp = nir_bany4(b, nir_flt(b, src[0], nir_imm_float(b, 0.0)));
+ nir_ssa_def *cmp = nir_bany_inequal4(b, nir_flt(b, src[0],
+ nir_imm_float(b, 0.0)),
+nir_imm_int(b, 0));
nir_intrinsic_instr *discard =
nir_intrinsic_instr_create(b->shader, nir_intrinsic_discard_if);
discard->src[0] = nir_src_for_ssa(cmp);
diff --git a/src/glsl/nir/nir_lower_alu_to_scalar.c
b/src/glsl/nir/nir_lower_alu_to_scalar.c
index 9313fc0..d267ca3 100644
--- a/src/glsl/nir/nir_lower_alu_to_scalar.c
+++ b/src/glsl/nir/nir_lower_alu_to_scalar.c
@@ -137,10 +137,6 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder
*b)
LOWER_REDUCTION(nir_op_bany_inequal, nir_op_ine, nir_op_ior);
LOWER_REDUCTION(nir_op_fall_equal, nir_op_seq, nir_op_fand);
LOWER_REDUCTION(nir_op_fany_nequal, nir_op_sne, nir_op_for);
- LOWER_REDUCTION(nir_op_ball, nir_op_imov, nir_op_iand);
- LOWER_REDUCTION(nir_op_bany, nir_op_imov, nir_op_ior);
- LOWER_REDUCTION(nir_op_fall, nir_op_fmov, nir_op_fand);
- LOWER_REDUCTION(nir_op_fany, nir_op_fmov, nir_op_for);
default:
break;
diff --git a/src/glsl/nir/nir_opcodes.py b/src/glsl/nir/nir_opcodes.py
index 37d3dfc..1cd01a4 100644
--- a/src/glsl/nir/nir_opcodes.py
+++ b/src/glsl/nir/nir_opcodes.py
@@ -167,13 +167,6 @@ unop_convert("i2b", tint, tbool, "src0 != 0")
unop_convert("b2i", tbool, tint, "src0 ? 1 : 0") # Boolean-to-int conversion
unop_convert("u2f", tuint, tfloat, "src0") # Unsigned-to-float conversion.
-unop_reduce("bany", 1, tbool, tbool, "{src}", "{src0} || {src1}", "{src}")
-unop_reduce("ball", 1, tbool, tbool, "{src}", "{src0} && {src1}", "{src}")
-unop_reduce("fany", 1, tfloat, tfloat, "{src} != 0.0f", "{src0} || {src1}",
-"{src} ? 1.0f : 0.0f")
-unop_reduce("fall", 1, tfloat, tfloat, "{src} != 0.0f", "{src0} && {src1}",
-"{src} ? 1.0f : 0.0f")
-
# Unary floating-point rounding operations.
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 9b50e4e..f5b203d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -841,12 +841,6 @@ fs_visitor::nir_emit_alu(const fs_builder &bld,
nir_alu_instr *instr)
case nir_op_fdot2:
case nir_op_fdot3:
case nir_op_fdot4:
- case nir_op_bany2:
- case nir_op_bany3:
- case nir_op_bany4:
- case nir_op_ball2:
- case nir_op_ball3:
- case nir_op_ball4:
case nir_op_ball_fequal2:
case nir_op_ball_iequal2:
case nir_op_ball_fequal3:
diff --git a/src/mesa/drivers/dri/i965/brw_nir_analyze_boolean_resolves.c
b/src/mesa/drivers/dri/i965/brw_nir_analyze_boolean_resolves.c
index c995d2b..f4d23d8 100644
--- a/src/mesa/drivers/dri/i965/brw_nir_analyze_boolean_resolves.c
+++ b/src/mesa/drivers/dri/i965/brw_nir_analyze_boolean_resolves.c
@@ -109,9 +109,6 @@ analyze_boolean_resolves_block(nir_block *block, void
*void_state)
uint8_t resolve_status;
nir_alu_instr *alu = nir_instr_as_alu(instr);
switch (alu->op) {
- case nir_op_bany2:
- case nir_op_bany3:
- case nir_op_bany4:
case nir_op_ball_fequal2:
case nir_op_ball_iequal2:
case nir_op_ball_fequal3:
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 4aed60e..457 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -1459,20 +1459,6 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
inst->saturate = instr->dest.saturate;
break;
- case nir_op_bany2:
- case nir_op_bany3:
- case nir_op_bany4: {
- unsigned swiz =
- brw_swizzle_for_size(nir_op_infos
[Mesa-dev] [PATCH 4/6] glsl: Implement all(v) as all_equal(v, true).
---
src/glsl/builtin_functions.cpp | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 2f21ffc..fb8ddee 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -4380,20 +4380,8 @@ builtin_builder::_all(const glsl_type *type)
ir_variable *v = in_var(type, "v");
MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
- switch (type->vector_elements) {
- case 2:
- body.emit(ret(logic_and(swizzle_x(v), swizzle_y(v;
- break;
- case 3:
- body.emit(ret(logic_and(logic_and(swizzle_x(v), swizzle_y(v)),
- swizzle_z(v;
- break;
- case 4:
- body.emit(ret(logic_and(logic_and(logic_and(swizzle_x(v), swizzle_y(v)),
-swizzle_z(v)),
- swizzle_w(v;
- break;
- }
+ const unsigned vec_elem = v->type->vector_elements;
+ body.emit(ret(expr(ir_binop_all_equal, v, imm(true, vec_elem;
return sig;
}
--
2.4.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] glsl: Remove ir_unop_any.
The GLSL IR to TGSI/Mesa IR paths for any_nequal have the same
optimizations the ir_unop_any paths had.
---
src/glsl/ir.cpp| 5 --
src/glsl/ir.h | 2 -
src/glsl/ir_constant_expression.cpp| 8 ---
src/glsl/ir_validate.cpp | 5 --
src/glsl/lower_mat_op_to_vec.cpp | 6 +-
src/glsl/nir/glsl_to_nir.cpp | 18 -
.../dri/i965/brw_fs_channel_expressions.cpp| 17 -
src/mesa/program/ir_to_mesa.cpp| 26 ---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 83 --
9 files changed, 5 insertions(+), 165 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index ca520f5..5a8bbc8 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -307,10 +307,6 @@ ir_expression::ir_expression(int op, ir_rvalue *op0)
this->type = glsl_type::uvec2_type;
break;
- case ir_unop_any:
- this->type = glsl_type::bool_type;
- break;
-
case ir_unop_pack_snorm_2x16:
case ir_unop_pack_snorm_4x8:
case ir_unop_pack_unorm_2x16:
@@ -538,7 +534,6 @@ static const char *const operator_strs[] = {
"bitcast_f2i",
"bitcast_u2f",
"bitcast_f2u",
- "any",
"trunc",
"ceil",
"floor",
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index e1109ee..cd84039 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -1348,7 +1348,6 @@ enum ir_expression_operation {
ir_unop_bitcast_f2i, /**< Bit-identical float-to-int "conversion" */
ir_unop_bitcast_u2f, /**< Bit-identical uint-to-float "conversion" */
ir_unop_bitcast_f2u, /**< Bit-identical float-to-uint "conversion" */
- ir_unop_any,
/**
* \name Unary floating-point rounding operations.
@@ -1719,7 +1718,6 @@ public:
{
return operation == ir_binop_all_equal ||
operation == ir_binop_any_nequal ||
- operation == ir_unop_any ||
operation == ir_binop_dot ||
operation == ir_quadop_vector;
}
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index 67ed360..1b32d55 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -656,14 +656,6 @@ ir_expression::constant_expression_value(struct hash_table
*variable_context)
data.u[c] = bitcast_f2u(op[0]->value.f[c]);
}
break;
- case ir_unop_any:
- assert(op[0]->type->is_boolean());
- data.b[0] = false;
- for (unsigned c = 0; c < op[0]->type->components(); c++) {
-if (op[0]->value.b[c])
- data.b[0] = true;
- }
- break;
case ir_unop_d2f:
assert(op[0]->type->base_type == GLSL_TYPE_DOUBLE);
for (unsigned c = 0; c < op[0]->type->components(); c++) {
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index e63b5c3..dcc079c 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -320,11 +320,6 @@ ir_validate::visit_leave(ir_expression *ir)
assert(ir->type->base_type == GLSL_TYPE_UINT);
break;
- case ir_unop_any:
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_BOOL);
- assert(ir->type == glsl_type::bool_type);
- break;
-
case ir_unop_trunc:
case ir_unop_round_even:
case ir_unop_ceil:
diff --git a/src/glsl/lower_mat_op_to_vec.cpp b/src/glsl/lower_mat_op_to_vec.cpp
index dda754f..e96cda2 100644
--- a/src/glsl/lower_mat_op_to_vec.cpp
+++ b/src/glsl/lower_mat_op_to_vec.cpp
@@ -277,7 +277,11 @@ ir_mat_op_to_vec_visitor::do_equal_mat_mat(ir_dereference
*result,
}
ir_rvalue *const val = new(this->mem_ctx) ir_dereference_variable(tmp_bvec);
- ir_expression *any = new(this->mem_ctx) ir_expression(ir_unop_any, val);
+ uint8_t vec_elems = val->type->vector_elements;
+ ir_expression *any =
+ new(this->mem_ctx) ir_expression(ir_binop_any_nequal, val,
+ new(this->mem_ctx) ir_constant(false,
+
vec_elems));
if (test_equal)
any = new(this->mem_ctx) ir_expression(ir_unop_logic_not, any);
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 45d045c..5d5233b 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -1340,24 +1340,6 @@ nir_visitor::visit(ir_expression *ir)
/* no-op */
result = nir_imov(&b, srcs[0]);
break;
- case ir_unop_any:
- switch (ir->operands[0]->type->vector_elements) {
- case 2:
- result = supports_ints ? nir_bany2(&b, srcs[0])
-: nir_fany2(&b, srcs[0]);
- break;
- case 3:
- result = supports_ints ? nir_bany3(&b, srcs[0])
-: nir_fany3(&b, srcs[0]);
- break;
- case 4:
- result = supports_ints ? nir_bany4(&b, srcs[0])
-:
Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).
On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner wrote:
> ---
> src/glsl/builtin_functions.cpp | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
> index 88f9a71..2f21ffc 100644
> --- a/src/glsl/builtin_functions.cpp
> +++ b/src/glsl/builtin_functions.cpp
> @@ -538,6 +538,7 @@ private:
> ir_variable *in_var(const glsl_type *type, const char *name);
> ir_variable *out_var(const glsl_type *type, const char *name);
> ir_constant *imm(float f, unsigned vector_elements=1);
> + ir_constant *imm(bool b, unsigned vector_elements=1);
> ir_constant *imm(int i, unsigned vector_elements=1);
> ir_constant *imm(unsigned u, unsigned vector_elements=1);
> ir_constant *imm(double d, unsigned vector_elements=1);
> @@ -3000,6 +3001,12 @@ builtin_builder::out_var(const glsl_type *type, const
> char *name)
> }
>
> ir_constant *
> +builtin_builder::imm(bool b, unsigned vector_elements)
> +{
> + return new(mem_ctx) ir_constant(b, vector_elements);
> +}
> +
> +ir_constant *
> builtin_builder::imm(float f, unsigned vector_elements)
> {
> return new(mem_ctx) ir_constant(f, vector_elements);
> @@ -4358,7 +4365,13 @@ builtin_builder::_notEqual(builtin_available_predicate
> avail,
> ir_function_signature *
> builtin_builder::_any(const glsl_type *type)
> {
> - return unop(always_available, ir_unop_any, glsl_type::bool_type, type);
> + ir_variable *v = in_var(type, "v");
> + MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
> +
> + const unsigned vec_elem = v->type->vector_elements;
> + body.emit(ret(expr(ir_binop_any_nequal, v, imm(false, vec_elem;
This results in an extra comparison generated by the st_glsl_to_tgsi
code, which can be annoying to get rid of... Why do you need to do
this?
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83382] /usr/include/string.h:82:1: error: unknown type name '__extern_always_inline'
https://bugs.freedesktop.org/show_bug.cgi?id=83382 Ian Romanick changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Ian Romanick --- This bug is quite old... does this problem still occur? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93089] mesa fails to check for gcc atomic primitives before using them
https://bugs.freedesktop.org/show_bug.cgi?id=93089 Ian Romanick changed: What|Removed |Added CC||matts...@gmail.com --- Comment #1 from Ian Romanick --- Matt: I know you're an Alpha fan. Suggestions? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).
On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin wrote:
> On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner wrote:
>> ---
>> src/glsl/builtin_functions.cpp | 15 ++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
>> index 88f9a71..2f21ffc 100644
>> --- a/src/glsl/builtin_functions.cpp
>> +++ b/src/glsl/builtin_functions.cpp
>> @@ -538,6 +538,7 @@ private:
>> ir_variable *in_var(const glsl_type *type, const char *name);
>> ir_variable *out_var(const glsl_type *type, const char *name);
>> ir_constant *imm(float f, unsigned vector_elements=1);
>> + ir_constant *imm(bool b, unsigned vector_elements=1);
>> ir_constant *imm(int i, unsigned vector_elements=1);
>> ir_constant *imm(unsigned u, unsigned vector_elements=1);
>> ir_constant *imm(double d, unsigned vector_elements=1);
>> @@ -3000,6 +3001,12 @@ builtin_builder::out_var(const glsl_type *type, const
>> char *name)
>> }
>>
>> ir_constant *
>> +builtin_builder::imm(bool b, unsigned vector_elements)
>> +{
>> + return new(mem_ctx) ir_constant(b, vector_elements);
>> +}
>> +
>> +ir_constant *
>> builtin_builder::imm(float f, unsigned vector_elements)
>> {
>> return new(mem_ctx) ir_constant(f, vector_elements);
>> @@ -4358,7 +4365,13 @@
>> builtin_builder::_notEqual(builtin_available_predicate avail,
>> ir_function_signature *
>> builtin_builder::_any(const glsl_type *type)
>> {
>> - return unop(always_available, ir_unop_any, glsl_type::bool_type, type);
>> + ir_variable *v = in_var(type, "v");
>> + MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
>> +
>> + const unsigned vec_elem = v->type->vector_elements;
>> + body.emit(ret(expr(ir_binop_any_nequal, v, imm(false, vec_elem;
>
> This results in an extra comparison generated by the st_glsl_to_tgsi
> code, which can be annoying to get rid of... Why do you need to do
> this?
Couldn't we fix the st_glsl_to_tgsi to handle that better? I wouldn't
be surprised to find such a thing in the wild.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 30/53] r600: create LDS info constants buffer and write LDS registers.
On Mon, Nov 30, 2015 at 1:30 PM, Marek Olšák wrote:
> On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This creates a constant buffer with the information about
>> the layout of the LDS memory that is given to the vertex, tess
>> control and tess evaluation shaders.
>>
>> This also programs the LDS size and the LS_HS_CONFIG registers,
>> on evergreen only.
>>
>> Signed-off-by: Dave Airlie
>> ---
>> src/gallium/drivers/r600/evergreen_state.c | 128
>> +++
>> src/gallium/drivers/r600/r600_pipe.h | 24 -
>> src/gallium/drivers/r600/r600_state_common.c | 13 +++
>> 3 files changed, 162 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/evergreen_state.c
>> b/src/gallium/drivers/r600/evergreen_state.c
>> index c01e8e3..edc6f28 100644
>> --- a/src/gallium/drivers/r600/evergreen_state.c
>> +++ b/src/gallium/drivers/r600/evergreen_state.c
>> @@ -3763,3 +3763,131 @@ void evergreen_init_state_functions(struct
>> r600_context *rctx)
>>
>> evergreen_init_compute_state_functions(rctx);
>> }
>> +
>> +/**
>> + * This calculates the LDS size for tessellation shaders (VS, TCS, TES).
>> + *
>> + * The information about LDS and other non-compile-time parameters is then
>> + * written to the const buffer.
>> +
>> + * const buffer contains -
>> + * uint32_t input_patch_size
>> + * uint32_t input_vertex_size
>> + * uint32_t num_tcs_input_cp
>> + * uint32_t num_tcs_output_cp;
>> + * uint32_t output_patch_size
>> + * uint32_t output_vertex_size
>> + * uint32_t output_patch0_offset
>> + * uint32_t perpatch_output_offset
>> + * and the same constbuf is bound to LS/HS/VS(ES).
>> + */
>> +void evergreen_setup_tess_constants(struct r600_context *rctx, const struct
>> pipe_draw_info *info, unsigned *num_patches, uint32_t *lds_alloc)
>> +{
>> + struct pipe_constant_buffer constbuf = {0};
>> + struct r600_pipe_shader_selector *tcs = rctx->tcs_shader ?
>> rctx->tcs_shader : rctx->tes_shader;
>> + struct r600_pipe_shader_selector *ls = rctx->vs_shader;
>> + unsigned num_tcs_input_cp = info->vertices_per_patch;
>> + unsigned num_tcs_outputs;
>> + unsigned num_tcs_output_cp;
>> + unsigned num_tcs_patch_outputs;
>> + unsigned num_tcs_inputs;
>> + unsigned input_vertex_size, output_vertex_size;
>> + unsigned input_patch_size, pervertex_output_patch_size,
>> output_patch_size;
>> + unsigned output_patch0_offset, perpatch_output_offset, lds_size;
>> + uint32_t values[16];
>> + uint32_t tmp;
>> +
>> + if (!rctx->tes_shader)
>> + return;
>> +
>> + *num_patches = 1;
>
> num_patches should be set before returning.
>
>> +
>> + num_tcs_inputs = util_last_bit64(ls->lds_outputs_written_mask);
>> +
>> + if (rctx->tcs_shader) {
>> + num_tcs_outputs =
>> util_last_bit64(tcs->lds_outputs_written_mask);
>> + num_tcs_output_cp =
>> tcs->info.properties[TGSI_PROPERTY_TCS_VERTICES_OUT];
>> + num_tcs_patch_outputs =
>> util_last_bit64(tcs->lds_patch_outputs_written_mask);
>> + } else {
>> + num_tcs_outputs = num_tcs_inputs;
>> + num_tcs_output_cp = num_tcs_input_cp;
>> + num_tcs_patch_outputs = 2; /* TESSINNER + TESSOUTER */
>> + }
>> +
>> + /* size in bytes */
>> + input_vertex_size = num_tcs_inputs * 16;
>> + output_vertex_size = num_tcs_outputs * 16;
>> +
>> + input_patch_size = num_tcs_input_cp * input_vertex_size;
>> +
>> + pervertex_output_patch_size = num_tcs_output_cp * output_vertex_size;
>> + output_patch_size = pervertex_output_patch_size +
>> num_tcs_patch_outputs * 16;
>> +
>> + output_patch0_offset = rctx->tcs_shader ? input_patch_size *
>> *num_patches : 0;
>> + perpatch_output_offset = output_patch0_offset +
>> pervertex_output_patch_size;
>> +
>> + lds_size = output_patch0_offset + output_patch_size * *num_patches;
>> +
>> + values[0] = input_patch_size;
>> + values[1] = input_vertex_size;
>> + values[2] = num_tcs_input_cp;
>> + values[3] = num_tcs_output_cp;
>> +
>> + values[4] = output_patch_size;
>> + values[5] = output_vertex_size;
>> + values[6] = output_patch0_offset;
>> + values[7] = perpatch_output_offset;
>> +
>> + /* docs say HS_NUM_WAVES - CEIL((LS_HS_CONFIG.NUM_PATCHES *
>> + LS_HS_CONFIG.HS_NUM_OUTPUT_CP) / (NUM_GOOD_PIPES * 16)) */
>> + tmp = (lds_size | (1 << 14)); /* TODO */
>
> If I understand this correctly, num_good_pipes can be between 1 and 4.
> Assume the worst case, which is 1. This gives us:
> ceil(NUM_PATCHES * NUM_OUTPUT_CP / 16)
>
> That equals 2 if NUM_OUTPUT_CP > 16 and NUM_PATCHES = 1.
BTW, HS_NUM_WAVES means how many waves share the same LDS memory.
1 pipe = 16 threads per wave, (GCN always has 4 pipes = 64 threads per
wave). That's where "16" in the equation comes fro
[Mesa-dev] [Bug 6954] Compile fails on Solaris 10 x86
https://bugs.freedesktop.org/show_bug.cgi?id=6954 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED CC||v...@freedesktop.org Resolution|--- |FIXED --- Comment #20 from Ian Romanick --- I'm going to close this (very old bug). I know that Mesa has built on Solaris since 2006. I believe that there are other build problems, and those are tracked by other bugs (submitted by Vinson Lee). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 6938] build errors of Mesa (CVS version) with Function Name Mangling on Solaris
https://bugs.freedesktop.org/show_bug.cgi?id=6938 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED CC||v...@freedesktop.org Resolution|--- |FIXED --- Comment #2 from Ian Romanick --- I'm going to close this (very old bug). I know that Mesa has built on Solaris since 2006. I believe that there are other build problems, and those are tracked by other bugs (submitted by Vinson Lee). -- 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 16/53] r600: add shader key entries for tcs and tes.
On 30 November 2015 at 21:20, Marek Olšák wrote:
> On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> with tessellation vs can now run on ls, and tes can
>> run on vs or es, tcs runs on hs.
>>
>> Signed-off-by: Dave Airlie
>> ---
>> src/gallium/drivers/r600/r600_hw_context.c | 4
>> src/gallium/drivers/r600/r600_pipe.h | 4
>> src/gallium/drivers/r600/r600_shader.c | 13 +++--
>> src/gallium/drivers/r600/r600_shader.h | 20
>> src/gallium/drivers/r600/r600_state_common.c | 11 ++-
>> 5 files changed, 49 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_hw_context.c
>> b/src/gallium/drivers/r600/r600_hw_context.c
>> index 13b6918..b7845b5 100644
>> --- a/src/gallium/drivers/r600/r600_hw_context.c
>> +++ b/src/gallium/drivers/r600/r600_hw_context.c
>> @@ -321,6 +321,10 @@ void r600_begin_new_cs(struct r600_context *ctx)
>> r600_mark_atom_dirty(ctx,
>> &ctx->hw_shader_stages[R600_HW_STAGE_GS].atom);
>> r600_mark_atom_dirty(ctx, &ctx->gs_rings.atom);
>> }
>> + if (ctx->tes_shader) {
>> + r600_mark_atom_dirty(ctx,
>> &ctx->hw_shader_stages[EG_HW_STAGE_HS].atom);
>> + r600_mark_atom_dirty(ctx,
>> &ctx->hw_shader_stages[EG_HW_STAGE_LS].atom);
>> + }
>
> If tes_shader is temporarily NULL, this will cause that HS+LS won't be
> set. I think this should be done unconditionally.
Why is that different from the geom shader case above it?
It isn't a big problem to make this unconditional at least on evergreen.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 6936] Undefined symbols in 6.4.2 if using -DUSE_MGL_NAMESPACE in sunos5-gcc on Solaris
https://bugs.freedesktop.org/show_bug.cgi?id=6936 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED CC||v...@freedesktop.org Resolution|--- |FIXED --- Comment #7 from Ian Romanick --- I'm going to close this (very old bug). I know that Mesa has built on Solaris since 2006. I believe that there are other build problems, and those are tracked by other bugs (submitted by Vinson Lee). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 3485] unable to compile mesa on solaris 10/amd64
https://bugs.freedesktop.org/show_bug.cgi?id=3485 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED CC||v...@freedesktop.org Resolution|--- |FIXED --- Comment #12 from Ian Romanick --- I'm going to close this (very old bug). I know that Mesa has built on Solaris since 2006. I believe that there are other build problems, and those are tracked by other bugs (submitted by Vinson Lee). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 19303] Mesa 6.2.1 implementation error: Trying to enable unknown extension: GL_ATI_fragment_shader
https://bugs.freedesktop.org/show_bug.cgi?id=19303 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Romanick --- The infrastructure for enabling extensions has completely changed since 2008, so this particular issue can no longer occur. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).
On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote:
> On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin wrote:
>> On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner wrote:
>>> ---
>>> src/glsl/builtin_functions.cpp | 15 ++-
>>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
>>> index 88f9a71..2f21ffc 100644
>>> --- a/src/glsl/builtin_functions.cpp
>>> +++ b/src/glsl/builtin_functions.cpp
>>> @@ -538,6 +538,7 @@ private:
>>> ir_variable *in_var(const glsl_type *type, const char *name);
>>> ir_variable *out_var(const glsl_type *type, const char *name);
>>> ir_constant *imm(float f, unsigned vector_elements=1);
>>> + ir_constant *imm(bool b, unsigned vector_elements=1);
>>> ir_constant *imm(int i, unsigned vector_elements=1);
>>> ir_constant *imm(unsigned u, unsigned vector_elements=1);
>>> ir_constant *imm(double d, unsigned vector_elements=1);
>>> @@ -3000,6 +3001,12 @@ builtin_builder::out_var(const glsl_type *type,
>>> const char *name)
>>> }
>>>
>>> ir_constant *
>>> +builtin_builder::imm(bool b, unsigned vector_elements)
>>> +{
>>> + return new(mem_ctx) ir_constant(b, vector_elements);
>>> +}
>>> +
>>> +ir_constant *
>>> builtin_builder::imm(float f, unsigned vector_elements)
>>> {
>>> return new(mem_ctx) ir_constant(f, vector_elements);
>>> @@ -4358,7 +4365,13 @@
>>> builtin_builder::_notEqual(builtin_available_predicate avail,
>>> ir_function_signature *
>>> builtin_builder::_any(const glsl_type *type)
>>> {
>>> - return unop(always_available, ir_unop_any, glsl_type::bool_type, type);
>>> + ir_variable *v = in_var(type, "v");
>>> + MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
>>> +
>>> + const unsigned vec_elem = v->type->vector_elements;
>>> + body.emit(ret(expr(ir_binop_any_nequal, v, imm(false, vec_elem;
>>
>> This results in an extra comparison generated by the st_glsl_to_tgsi
>> code, which can be annoying to get rid of... Why do you need to do
>> this?
>
> Couldn't we fix the st_glsl_to_tgsi to handle that better? I wouldn't
> be surprised to find such a thing in the wild.
I guess it could special-case the exact IR generated there? The thing
is that it just OR's everything together (when you have native integer
support... which everything does outside of r300/nv30), which you can
only do in a few select cases. If you'd like to implement that, I
wouldn't object. As-is, it's a pessimization though.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27841] Implement GL_EXT_discard_framebuffer
https://bugs.freedesktop.org/show_bug.cgi?id=27841 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Ian Romanick --- I'm going to close this bug as fixed. There are several extensions in Mesa that enable various related bits of sub-buffer swapping. If more functionality is needed, please open a new feature request. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30490] mesa requires g++ to build but configure does not check for it
https://bugs.freedesktop.org/show_bug.cgi?id=30490 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Romanick --- I believe this was fixed ages ago. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34947] Gentoo QA warning: media-libs/mesa-7.9.1: shaderobj.h:111: warning: implicit declaration of function ‘ASSERT’
https://bugs.freedesktop.org/show_bug.cgi?id=34947 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED CC||matts...@gmail.com Resolution|--- |FIXED --- Comment #1 from Ian Romanick --- Pretty sure Mesa builds on Gentoo. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39821] HEAD won't compile without X11 headers
https://bugs.freedesktop.org/show_bug.cgi?id=39821 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Romanick --- Please reopen if this is still a problem. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89773] "builtin_functions.cpp", line 3218: Error: INFINITY is not defined.
https://bugs.freedesktop.org/show_bug.cgi?id=89773 --- Comment #3 from Alan Coopersmith --- Sorry, I don't have enough context here, but on Solaris, INFINITY is defined via math.h headers, but wrapped in: #if defined(_STDC_C99) || _XOPEN_SOURCE - 0 >= 600 || defined(__C99FEATURES__) but as C++ is pure evil, I don't know if it corrupts this somehow. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] misc janitorial
On 11/30/2015 02:06 PM, Dave Airlie wrote:
> On 1 December 2015 at 07:18, Emil Velikov wrote:
>> On 30 November 2015 at 20:00, Ian Romanick wrote:
>>> On 11/29/2015 07:21 AM, Emil Velikov wrote:
Hi Giuseppe,
On 28 November 2015 at 15:43, Giuseppe Bilotta
wrote:
> The second and third patches are mostly aimed at removing non-spurious
> compiler warnings. The first one is just minor whitespace cleanup in the
> general area of code touched by the second patch.
>
> Giuseppe Bilotta (3):
> radeon: whitespace cleanup
> radeon: const correctness
> xvmc: force assertion in XvMC tests
>
With the small comment in patch 3 addressed the series is
Reviewed-by: Emil Velikov
If you're looking for an easy task - there is one in radeon/r200.
Currently we have a lot of nasty in-tree symlinks, symbol duplication
and hacks to get around it. Let me know if you'd like more info/tips
on how to tackle it.
>>>
>>> This is something that has been annoying me a bit lately. What do you
>>> think the right solution is? The Intel driver used to have a common
>>> src/mesa/drivers/dri/intel directory that was compiled once and shared
>>> by i915 and i965. The code paths started to diverge quite a lot, so we
>>> copied the shared files into each directory... and became non-shared.
>>> Note that we didn't rename any of the function names, so we still have
>>> the ugly hacks to get around the symbol duplication.
>>>
>> I'm not sure about "right and wrong" but the possible solution I was
>> thinking is the one you mentioned - have a common place where that
>> code is built once.
>>
>> The long version:
>> 1. Grep for RADEON_R{1,2}00 and look at the guarded code
>> 1.1 Some guards can just be dropped (CHIP_FAMILY_*, get_chip_family_name),
>> 1.2 Other hunks of code can be split/moved into the respective
>> r100/r200 codebase (radeonTexBufferExtension and
>> r200TexBufferExtension).
>> 1.3 Or folded into the vtbl dispatch - get_depth_z32/16 or the
>> respective callers, depending on the overhead (neither one is likely
>> to be noticeable).
>> 2. Copy/pasta an existing radeon Makefile to radeon_common. Tweak to
>> produce an empty library and get it into the final mega_dri_drivers.so
>> 2.1 With most/all of the RADEON_R*00 guards gone, one should be able
>> to just git mv the files into the new location. (alongside dropping
>> the symlinks)
>> 2.2 Remove the symbol redefinition hack.
>>
>> It's a lengthy task, yet relatively easy. As long one tries to divide
>> and concur, rather than understand, in depth, how the driver/autohell
>> buildsystem works :-)
>> I'm more than willing to help out on the lot (esp. the latter), just
>> shout when you get confused/stuck.
>
> But why bother?
>
> Getting someone with r100/r200 hardware to test is the fun part,
>
> We've already seen that changes in this area untested mostly break stuff,
> rather than help, and go unnoticed for whole releases at a time.
I'm putting together some systems to run piglit from time to time. If
someone is willing to do some work, I can run tests... but I agree that
this is pretty low priority stuff.
> Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: always re-validate program pipeline
Just because the validation passed the last time is was called doesn't
automatically mean it will pass again the next time its called.
Cc: "11.1"
https://bugs.freedesktop.org/show_bug.cgi?id=93180
---
src/mesa/main/context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index be542dd..11747d9 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -2030,7 +2030,7 @@ _mesa_valid_to_render(struct gl_context *ctx, const char
*where)
}
/* A pipeline object is bound */
- if (ctx->_Shader->Name && !ctx->_Shader->Validated) {
+ if (ctx->_Shader->Name) {
/* Error message will be printed inside _mesa_validate_program_pipeline.
*/
if (!_mesa_validate_program_pipeline(ctx, ctx->_Shader, GL_TRUE)) {
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).
On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin wrote:
> On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote:
>> On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin wrote:
>>> On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner wrote:
---
src/glsl/builtin_functions.cpp | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp
b/src/glsl/builtin_functions.cpp
index 88f9a71..2f21ffc 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -538,6 +538,7 @@ private:
ir_variable *in_var(const glsl_type *type, const char *name);
ir_variable *out_var(const glsl_type *type, const char *name);
ir_constant *imm(float f, unsigned vector_elements=1);
+ ir_constant *imm(bool b, unsigned vector_elements=1);
ir_constant *imm(int i, unsigned vector_elements=1);
ir_constant *imm(unsigned u, unsigned vector_elements=1);
ir_constant *imm(double d, unsigned vector_elements=1);
@@ -3000,6 +3001,12 @@ builtin_builder::out_var(const glsl_type *type,
const char *name)
}
ir_constant *
+builtin_builder::imm(bool b, unsigned vector_elements)
+{
+ return new(mem_ctx) ir_constant(b, vector_elements);
+}
+
+ir_constant *
builtin_builder::imm(float f, unsigned vector_elements)
{
return new(mem_ctx) ir_constant(f, vector_elements);
@@ -4358,7 +4365,13 @@
builtin_builder::_notEqual(builtin_available_predicate avail,
ir_function_signature *
builtin_builder::_any(const glsl_type *type)
{
- return unop(always_available, ir_unop_any, glsl_type::bool_type, type);
+ ir_variable *v = in_var(type, "v");
+ MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
+
+ const unsigned vec_elem = v->type->vector_elements;
+ body.emit(ret(expr(ir_binop_any_nequal, v, imm(false, vec_elem;
>>>
>>> This results in an extra comparison generated by the st_glsl_to_tgsi
>>> code, which can be annoying to get rid of... Why do you need to do
>>> this?
>>
>> Couldn't we fix the st_glsl_to_tgsi to handle that better? I wouldn't
>> be surprised to find such a thing in the wild.
>
> I guess it could special-case the exact IR generated there? The thing
> is that it just OR's everything together (when you have native integer
> support... which everything does outside of r300/nv30), which you can
> only do in a few select cases. If you'd like to implement that, I
> wouldn't object. As-is, it's a pessimization though.
I'm not familiar with any of this code and I don't know how to test or
debug it -- sorry.
It should be trivial to optimize if someone cares. I believe all you
need to do is skip emitting the SNE and instead copy src[0] to temp
under these circumstances:
if (ir->operands[0]->type == glsl_type::bool_type &&
ir->operands[1]->as_constant() &&
ir->operands[1]->as_constant()->is_zero())
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/53] r600: add shader key entries for tcs and tes.
On Tue, Dec 1, 2015 at 12:45 AM, Dave Airlie wrote:
> On 30 November 2015 at 21:20, Marek Olšák wrote:
>> On Mon, Nov 30, 2015 at 7:20 AM, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> with tessellation vs can now run on ls, and tes can
>>> run on vs or es, tcs runs on hs.
>>>
>>> Signed-off-by: Dave Airlie
>>> ---
>>> src/gallium/drivers/r600/r600_hw_context.c | 4
>>> src/gallium/drivers/r600/r600_pipe.h | 4
>>> src/gallium/drivers/r600/r600_shader.c | 13 +++--
>>> src/gallium/drivers/r600/r600_shader.h | 20
>>> src/gallium/drivers/r600/r600_state_common.c | 11 ++-
>>> 5 files changed, 49 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/r600/r600_hw_context.c
>>> b/src/gallium/drivers/r600/r600_hw_context.c
>>> index 13b6918..b7845b5 100644
>>> --- a/src/gallium/drivers/r600/r600_hw_context.c
>>> +++ b/src/gallium/drivers/r600/r600_hw_context.c
>>> @@ -321,6 +321,10 @@ void r600_begin_new_cs(struct r600_context *ctx)
>>> r600_mark_atom_dirty(ctx,
>>> &ctx->hw_shader_stages[R600_HW_STAGE_GS].atom);
>>> r600_mark_atom_dirty(ctx, &ctx->gs_rings.atom);
>>> }
>>> + if (ctx->tes_shader) {
>>> + r600_mark_atom_dirty(ctx,
>>> &ctx->hw_shader_stages[EG_HW_STAGE_HS].atom);
>>> + r600_mark_atom_dirty(ctx,
>>> &ctx->hw_shader_stages[EG_HW_STAGE_LS].atom);
>>> + }
>>
>> If tes_shader is temporarily NULL, this will cause that HS+LS won't be
>> set. I think this should be done unconditionally.
>
> Why is that different from the geom shader case above it?
>
> It isn't a big problem to make this unconditional at least on evergreen.
You are probably right. I need to take a closer look because I haven't
reviewed the whole series yet.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).
On Mon, Nov 30, 2015 at 7:15 PM, Matt Turner wrote:
> On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin wrote:
>> On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote:
>>> On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin wrote:
On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner wrote:
> ---
> src/glsl/builtin_functions.cpp | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/builtin_functions.cpp
> b/src/glsl/builtin_functions.cpp
> index 88f9a71..2f21ffc 100644
> --- a/src/glsl/builtin_functions.cpp
> +++ b/src/glsl/builtin_functions.cpp
> @@ -538,6 +538,7 @@ private:
> ir_variable *in_var(const glsl_type *type, const char *name);
> ir_variable *out_var(const glsl_type *type, const char *name);
> ir_constant *imm(float f, unsigned vector_elements=1);
> + ir_constant *imm(bool b, unsigned vector_elements=1);
> ir_constant *imm(int i, unsigned vector_elements=1);
> ir_constant *imm(unsigned u, unsigned vector_elements=1);
> ir_constant *imm(double d, unsigned vector_elements=1);
> @@ -3000,6 +3001,12 @@ builtin_builder::out_var(const glsl_type *type,
> const char *name)
> }
>
> ir_constant *
> +builtin_builder::imm(bool b, unsigned vector_elements)
> +{
> + return new(mem_ctx) ir_constant(b, vector_elements);
> +}
> +
> +ir_constant *
> builtin_builder::imm(float f, unsigned vector_elements)
> {
> return new(mem_ctx) ir_constant(f, vector_elements);
> @@ -4358,7 +4365,13 @@
> builtin_builder::_notEqual(builtin_available_predicate avail,
> ir_function_signature *
> builtin_builder::_any(const glsl_type *type)
> {
> - return unop(always_available, ir_unop_any, glsl_type::bool_type,
> type);
> + ir_variable *v = in_var(type, "v");
> + MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
> +
> + const unsigned vec_elem = v->type->vector_elements;
> + body.emit(ret(expr(ir_binop_any_nequal, v, imm(false, vec_elem;
This results in an extra comparison generated by the st_glsl_to_tgsi
code, which can be annoying to get rid of... Why do you need to do
this?
>>>
>>> Couldn't we fix the st_glsl_to_tgsi to handle that better? I wouldn't
>>> be surprised to find such a thing in the wild.
>>
>> I guess it could special-case the exact IR generated there? The thing
>> is that it just OR's everything together (when you have native integer
>> support... which everything does outside of r300/nv30), which you can
>> only do in a few select cases. If you'd like to implement that, I
>> wouldn't object. As-is, it's a pessimization though.
>
> I'm not familiar with any of this code and I don't know how to test or
> debug it -- sorry.
>
> It should be trivial to optimize if someone cares. I believe all you
> need to do is skip emitting the SNE and instead copy src[0] to temp
> under these circumstances:
>
>if (ir->operands[0]->type == glsl_type::bool_type &&
>ir->operands[1]->as_constant() &&
>ir->operands[1]->as_constant()->is_zero())
As long as you can build the gallium swrast (and enable debug), you
can add ST_DEBUG=tgsi to get the generated TGSI printed out.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Increase BRW_MAX_UBO to 15.
I believe that DirectX offers 16 UBOs, with one reserved for special
purposes. This means that the practical lower bound is 15, even if
OpenGL only mandates 12.
Without this, Shadow of Mordor shaders fail to work because of limit
checking around GL_MAX_UNIFORM_BUFFER_BINDINGS.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Shadow of Mordor also needs tessellation, so backporting this wouldn't
help the game any.
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index e45df46..e20082f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -414,7 +414,7 @@ struct brw_ff_gs_prog_data {
#define BRW_MAX_DRAW_BUFFERS 8
/** Max number of UBOs in a shader */
-#define BRW_MAX_UBO 12
+#define BRW_MAX_UBO 15
/** Max number of SSBOs in a shader */
#define BRW_MAX_SSBO 12
--
2.6.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/12] mesa: Drop apparently typoed GL_ALL_CLIENT_ATTRIB_BITS.
On 11/25/2015 07:10 PM, Eric Anholt wrote:
> GL_ALL_ATTRIB_BITS is a thing, and GL_CLIENT_ALL_ATTRIB_BITS, but I don't
> see GL_ALL_CLIENT_ATTRIB_BITS in my grepping of khronos XML, GL extension
> specs, GL 1.1, GL 2.2, and GL 4.4.
Hm... it is in include/GL/gl.h. git-blame says:
commit a8b07a539b42b04111f48aa145bc3b2633fd5387
Author: Brian Paul
Date: Tue Aug 28 22:49:32 2001 +
added OpenGL 1.3 tokens and prototypes
Maybe from an early version of the spec?
b
> ---
> src/mapi/glapi/gen/gl_API.xml| 1 -
> src/mesa/main/tests/enum_strings.cpp | 4 +---
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index faf9263..b87ae6e 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -3139,7 +3139,6 @@
>
> value="0x0001"/>
> value="0x0002"/>
> - value="0x"/>
> value="0x"/>
>
>
> diff --git a/src/mesa/main/tests/enum_strings.cpp
> b/src/mesa/main/tests/enum_strings.cpp
> index 48426a4..8b92026 100644
> --- a/src/mesa/main/tests/enum_strings.cpp
> +++ b/src/mesa/main/tests/enum_strings.cpp
> @@ -94,9 +94,7 @@ const struct enum_info everything[] = {
> /* A bitfield where Mesa uses a different value from Khronos. */
> { 0x000f, "GL_ALL_ATTRIB_BITS" },
>
> - /* A bitfield in the table where Mesa uses a different name from Khronos,
> -* and we fail to return its string anyway!
> -*/
> + /* A bitfield in the table, where we fail to return its string anyway! */
> { (int)0x, "0x" },
>
> { 0, NULL }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
