Re: [Mesa-dev] [PATCH 07/12] nir: Add an array splitting pass
On Mon, Jul 30, 2018 at 12:00 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> > > > +static int
> > > > +num_arrays_in_type(const struct glsl_type *type)
> > > > +{
> > > > + int num_arrays = 0;
> > > > + while (true) {
> > > > + if (glsl_type_is_array(type) || glsl_type_is_matrix(type)) {
> > > > + num_arrays++;
> > > > + type = glsl_get_array_element(type);
> > > > + } else if (glsl_type_is_vector_or_scalar(type)) {
> > > > + return num_arrays;
> > > > + } else {
> > > > + /* Unknown type */
> > > > + return -1;
> > >
> > > "Unknown" seems misleading, maybe "Unsupported"? The pass uses this to
> > > rule out variables that have structs in the hiearchy.
> > >
> >
> > How about just "Not an array of vectors". I've also changed the name of
> > the helper to "num_arrays_in_array_of_vectors_type"
>
> Sounds good. Thanks.
>
>
>
> > > > +struct elem {
> > > > + struct elem *parent;
> > > > +
> > > > + const struct glsl_type *type;
> > > > +
> > > > + nir_variable *var;
> > > > + struct elem *ind_child;
> > > > + struct elem *children;
> > >
> > > A small note about what ind_child and children store would be helpful.
> > >
> >
> > I've completely reworked this data structure in v2.
>
> Ok. I'll check out v2.
>
> (...)
>
>
> > > > + bool has_global_splits = false;
> > > > + if (modes & nir_var_global) {
> > > > + has_global_splits = split_var_list_arrays(shader, NULL,
> > > > + >globals,
> > > > + var_indirect_map,
> > > > + var_elem_map,
> mem_ctx);
> > >
> > > Optional: remove the extra space in some of the lines above.
> > >
> >
> > Do you mean the blank lines? I'm happy to do so, I just don't know what
> > way of breaking things up you'd prefer.
>
> The breaking is fine (no strong preferences here).
>
> After the line "has_global_splits ...", there are three lines that
> seem to have an extra space. Not really important, is just elsewhere
> in the code these are aligned so that those lines would start right
> after the '('.
>
> func(arg1,
> arg2,
> arg3);
>
> vs.
>
> func(arg1,
> arg2,
> arg3);
>
Right. That appears to be fixed in the latest version.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: fix get_image_coords() for radeonsi
On 31/07/18 16:52, Bas Nieuwenhuizen wrote:
On Fri, Jul 27, 2018 at 11:40 AM, Timothy Arceri wrote:
On 27/07/18 19:10, Bas Nieuwenhuizen wrote:
On Fri, Jul 27, 2018 at 7:32 AM, Timothy Arceri
wrote:
Because this was setting image to true we would end up calling
si_load_image_desc() when we sould be calling
si_load_sampler_desc().
Since the descriptor is part of an image, not a sampler,
get_image_descriptor looks like the right thing to me?
What assertion are you getting?
LLVMValueRef si_load_image_desc(struct si_shader_context *ctx,
LLVMValueRef list, LLVMValueRef index,
enum ac_descriptor_type desc_type, bool
dcc_off)
{
LLVMBuilderRef builder = ctx->ac.builder;
LLVMValueRef rsrc;
if (desc_type == AC_DESC_BUFFER) {
index = LLVMBuildMul(builder, index,
LLVMConstInt(ctx->i32, 2, 0), "");
index = LLVMBuildAdd(builder, index,
ctx->i32_1, "");
list = LLVMBuildPointerCast(builder, list,
ac_array_in_const32_addr_space(ctx->v4i32), "");
} else {
assert(desc_type == AC_DESC_IMAGE);
}
rsrc = ac_build_load_to_sgpr(>ac, list, index);
if (desc_type == AC_DESC_IMAGE && dcc_off)
rsrc = force_dcc_off(ctx, rsrc);
return rsrc;
}
vs
LLVMValueRef si_load_sampler_desc(struct si_shader_context *ctx,
LLVMValueRef list, LLVMValueRef index,
enum ac_descriptor_type type)
{
LLVMBuilderRef builder = ctx->ac.builder;
switch (type) {
case AC_DESC_IMAGE:
/* The image is at [0:7]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
2, 0), "");
break;
case AC_DESC_BUFFER:
/* The buffer is in [4:7]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
4, 0), "");
index = LLVMBuildAdd(builder, index, ctx->i32_1, "");
list = LLVMBuildPointerCast(builder, list,
ac_array_in_const32_addr_space(ctx->v4i32), "");
break;
case AC_DESC_FMASK:
/* The FMASK is at [8:15]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
2, 0), "");
index = LLVMBuildAdd(builder, index, ctx->i32_1, "");
break;
case AC_DESC_SAMPLER:
/* The sampler state is at [12:15]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
4, 0), "");
index = LLVMBuildAdd(builder, index, LLVMConstInt(ctx->i32,
3, 0), "");
list = LLVMBuildPointerCast(builder, list,
ac_array_in_const32_addr_space(ctx->v4i32), "");
break;
}
return ac_build_load_to_sgpr(>ac, list, index);
}
I think we should fix the image path to get an fmask descriptor
though. If you look one level up the bounding of dynamic indices is
different for textures and images:
static LLVMValueRef
si_nir_load_sampler_desc(struct ac_shader_abi *abi,
unsigned descriptor_set, unsigned base_index,
unsigned constant_index, LLVMValueRef dynamic_index,
enum ac_descriptor_type desc_type, bool image,
bool write, bool bindless)
{
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
LLVMBuilderRef builder = ctx->ac.builder;
LLVMValueRef list = LLVMGetParam(ctx->main_fn,
ctx->param_samplers_and_images);
LLVMValueRef index;
assert(!descriptor_set);
dynamic_index = dynamic_index ? dynamic_index : ctx->ac.i32_0;
index = LLVMBuildAdd(builder, dynamic_index,
LLVMConstInt(ctx->ac.i32, base_index + constant_index, false),
"");
if (image) {
assert(desc_type == AC_DESC_IMAGE || desc_type == AC_DESC_BUFFER);
assert(base_index + constant_index < ctx->num_images);
if (dynamic_index)
index = si_llvm_bound_index(ctx, index, ctx->num_images);
index = LLVMBuildSub(ctx->ac.builder,
LLVMConstInt(ctx->i32, SI_NUM_IMAGES - 1, 0),
index, "");
/* TODO: be smarter about when we use dcc_off */
return si_load_image_desc(ctx, list, index, desc_type, write);
}
assert(base_index + constant_index < ctx->num_samplers);
if (dynamic_index)
index = si_llvm_bound_index(ctx, index, ctx->num_samplers);
index = LLVMBuildAdd(ctx->ac.builder, index,
LLVMConstInt(ctx->i32, SI_NUM_IMAGES / 2, 0), "");
return si_load_sampler_desc(ctx, list, index, desc_type);
}
Right but that looks consistent with the dynamic index used in radeonsi
see tex_fetch_ptrs()
Re: [Mesa-dev] [PATCH v3 1/8] nir: evaluate if condition uses inside the if branches
On 01/08/18 13:09, Dieter Nützel wrote: Am 31.07.2018 13:34, schrieb Timothy Arceri: On 31/07/18 13:50, Dieter Nützel wrote: Am 30.07.2018 05:24, schrieb Dieter Nützel: For the series Tested-by: Dieter Nützel with glmark2, glxgears, UH, UV, Blender 2.79 and FreeCAD 0.17 on RX 580. With UH I saw some small light blue triangles spreading around. Have to bisect which patch set was the culprit. (If I have some time.) Tried your's above configure-bump-libdrm-for-AMDGPU-to-2.4.92.mbox (Samuel) ASTC-texture-compression-for-all-Gallium-drivers.mbox (Marek) Dieter It has something to do with tessellation. If I disable it (F3) all small light blue triangles are _gone_. Are you able to bisect? In short, it has _nothing_ to do with _this_ series. Tested on e6ff5ac446. So my tb stands. After some sleep (Nothern Germany is _very_ hot and _dry_ this year) I'll do my very best... ;-) hehe. Yes I've experienced a "heat wave" in Northern Europe before, but some of us have very different definitions of _very_ hot and _dry_ :P Regards, Dieter Am 28.07.2018 03:07, schrieb Timothy Arceri: On 28/07/18 11:06, Timothy Arceri wrote: Since we know what side of the branch we ended up on we can just replace the use with a constant. All the spill changes in shader-db are from Dolphin uber shaders, despite some small regressions the change is clearly positive. V2: insert new constant after any phis in the use->parent_instr->type == nir_instr_type_phi path. Meh this was meant to be V3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/4] intel/nir: Split IO arrays into elements
On Tue, Jul 31, 2018 at 3:00 PM Jason Ekstrand wrote:
> On July 31, 2018 14:54:54 Kenneth Graunke wrote:
>
> > On Tuesday, July 31, 2018 12:22:02 PM PDT Jason Ekstrand wrote:
> >> The NIR nir_lower_io_arrays_to_elements pass attempts to split I/O
> >> variables which are arrays or matrices into a sequence of separate
> >> variables. This can help link-time optimization by allowing us to
> >> remove varyings at a more granular level.
> >>
> >> Shader-db results on Kaby Lake:
> >>
> >> total instructions in shared programs: 15177645 -> 15168494 (-0.06%)
> >> instructions in affected programs: 79857 -> 70706 (-11.46%)
> >> helped: 392
> >> HURT: 0
> >> ---
> >> src/intel/compiler/brw_nir.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> >> index 17ccfa48af6..29ad68fdb2a 100644
> >> --- a/src/intel/compiler/brw_nir.c
> >> +++ b/src/intel/compiler/brw_nir.c
> >> @@ -709,6 +709,10 @@ void
> >> brw_nir_link_shaders(const struct brw_compiler *compiler,
> >> nir_shader **producer, nir_shader **consumer)
> >> {
> >> + nir_lower_io_arrays_to_elements(*producer, *consumer);
> >> + nir_validate_shader(*producer);
> >> + nir_validate_shader(*consumer);
> >> +
> >> NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
> >> NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
> >
> > This actually passes the test suite? That's strange. When I was
> > playing with this earlier, it was demoting gl_ClipDistance[1] from
> > a float[1] compact array to a single float variable...but leaving it
> > marked compact. var->data.compact = true makes no sense for non-arrays.
> >
> > I think our clip/cull distance handling assumes that it's an array,
> > though. So...not sure whether the pass should unset compact, or skip
> > over compact arrays...
>
> Yes, it passes just fine. I'm not sure exactly how it interacts with clip
> distance lowering though.
>
Back at my computer finally. I did a bit of digging and the
lower_io_arrays_to_elements pass ignores everything that isn't
VARYING_SLOT_VARX. Clip distances are ignored since they're
VARYING_SLOT_CLIP_DIST0/1. Hope that clears it up. :-)
--Jason
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #8479 completed
Build mesa 8479 completed Commit 157c6e8195 by Marek Olšák on 8/1/2018 2:50 AM: util: don't use __builtin_clz unconditionally\n\nThis fixes the build if __builtin_clz is unsupported.\n\nReviewed-by: Roland Scheidegger Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] virgl: add initial ARB_compute_shader support
This series is:
Reviewed-by: Gurchetan Singh
On Tue, Jul 31, 2018 at 3:29 PM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This hooks up compute shader creation and launch grid support.
> ---
> src/gallium/drivers/virgl/virgl_context.c | 55 ++--
> src/gallium/drivers/virgl/virgl_encode.c | 25 -
> src/gallium/drivers/virgl/virgl_encode.h | 3 ++
> src/gallium/drivers/virgl/virgl_hw.h | 5 +++
> src/gallium/drivers/virgl/virgl_protocol.h | 11 ++
> src/gallium/drivers/virgl/virgl_screen.c | 59
> --
> src/gallium/drivers/virgl/virgl_winsys.h | 2 +
> 7 files changed, 153 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c
> b/src/gallium/drivers/virgl/virgl_context.c
> index d224b68cfcd..ae1da337994 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -506,7 +506,7 @@ static void *virgl_shader_encoder(struct pipe_context
> *ctx,
> handle = virgl_object_assign_handle();
> /* encode VS state */
> ret = virgl_encode_shader_state(vctx, handle, type,
> - >stream_output,
> + >stream_output, 0,
> new_tokens);
> if (ret) {
>return NULL;
> @@ -961,7 +961,7 @@ static void virgl_set_shader_buffers(struct pipe_context
> *ctx,
>pipe_resource_reference(>ssbos[shader][idx], NULL);
> }
>
> - uint32_t max_shader_buffer = shader == PIPE_SHADER_FRAGMENT ?
> + uint32_t max_shader_buffer = (shader == PIPE_SHADER_FRAGMENT || shader ==
> PIPE_SHADER_COMPUTE) ?
>rs->caps.caps.v2.max_shader_buffer_frag_compute :
>rs->caps.caps.v2.max_shader_buffer_other_stages;
> if (!max_shader_buffer)
> @@ -989,7 +989,7 @@ static void virgl_set_shader_images(struct pipe_context
> *ctx,
>pipe_resource_reference(>images[shader][idx], NULL);
> }
>
> - uint32_t max_shader_images = shader == PIPE_SHADER_FRAGMENT ?
> + uint32_t max_shader_images = (shader == PIPE_SHADER_FRAGMENT || shader ==
> PIPE_SHADER_COMPUTE) ?
> rs->caps.caps.v2.max_shader_image_frag_compute :
> rs->caps.caps.v2.max_shader_image_other_stages;
> if (!max_shader_images)
> @@ -1008,6 +1008,50 @@ static void virgl_memory_barrier(struct pipe_context
> *ctx,
> virgl_encode_memory_barrier(vctx, flags);
> }
>
> +static void *virgl_create_compute_state(struct pipe_context *ctx,
> +const struct pipe_compute_state
> *state)
> +{
> + struct virgl_context *vctx = virgl_context(ctx);
> + uint32_t handle;
> + const struct tgsi_token *new_tokens = state->prog;
> + struct pipe_stream_output_info so_info = {};
> + int ret;
> +
> + handle = virgl_object_assign_handle();
> + ret = virgl_encode_shader_state(vctx, handle, PIPE_SHADER_COMPUTE,
> + _info,
> + state->req_local_mem,
> + new_tokens);
> + if (ret) {
> + return NULL;
> + }
> +
> + return (void *)(unsigned long)handle;
> +}
> +
> +static void virgl_bind_compute_state(struct pipe_context *ctx, void *state)
> +{
> + uint32_t handle = (unsigned long)state;
> + struct virgl_context *vctx = virgl_context(ctx);
> +
> + virgl_encode_bind_shader(vctx, handle, PIPE_SHADER_COMPUTE);
> +}
> +
> +static void virgl_delete_compute_state(struct pipe_context *ctx, void *state)
> +{
> + uint32_t handle = (unsigned long)state;
> + struct virgl_context *vctx = virgl_context(ctx);
> +
> + virgl_encode_delete_object(vctx, handle, VIRGL_OBJECT_SHADER);
> +}
> +
> +static void virgl_launch_grid(struct pipe_context *ctx,
> + const struct pipe_grid_info *info)
> +{
> + struct virgl_context *vctx = virgl_context(ctx);
> + virgl_encode_launch_grid(vctx, info);
> +}
> +
> static void
> virgl_context_destroy( struct pipe_context *ctx )
> {
> @@ -1118,6 +1162,11 @@ struct pipe_context *virgl_context_create(struct
> pipe_screen *pscreen,
> vctx->base.delete_gs_state = virgl_delete_gs_state;
> vctx->base.delete_fs_state = virgl_delete_fs_state;
>
> + vctx->base.create_compute_state = virgl_create_compute_state;
> + vctx->base.bind_compute_state = virgl_bind_compute_state;
> + vctx->base.delete_compute_state = virgl_delete_compute_state;
> + vctx->base.launch_grid = virgl_launch_grid;
> +
> vctx->base.clear = virgl_clear;
> vctx->base.draw_vbo = virgl_draw_vbo;
> vctx->base.flush = virgl_flush_from_st;
> diff --git a/src/gallium/drivers/virgl/virgl_encode.c
> b/src/gallium/drivers/virgl/virgl_encode.c
> index 1d193ae6c7f..0cb5184d193 100644
> --- a/src/gallium/drivers/virgl/virgl_encode.c
> +++ b/src/gallium/drivers/virgl/virgl_encode.c
> @@ -241,6 +241,7 @@ int virgl_encode_shader_state(struct virgl_context *ctx,
>
Re: [Mesa-dev] [PATCH] util: don't use __builtin_clz unconditionally
Am 01.08.2018 um 04:54 schrieb Marek Olšák:
> From: Marek Olšák
>
> This fixes the build if __builtin_clz is unsupported.
> ---
> src/util/half_float.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/half_float.c b/src/util/half_float.c
> index 588f050d924..2eff2c84f51 100644
> --- a/src/util/half_float.c
> +++ b/src/util/half_float.c
> @@ -208,21 +208,31 @@ uint8_t _mesa_half_to_unorm8(uint16_t val)
>* Takes a uint16_t, divides by 65536, converts the infinite-precision
>* result to fp16 with round-to-zero. Used by the ASTC decoder.
>*/
> uint16_t _mesa_uint16_div_64k_to_half(uint16_t v)
> {
> /* Zero or subnormal. Set the mantissa to (v << 8) and return. */
> if (v < 4)
>return v << 8;
>
> /* Count the leading 0s in the uint16_t */
> - int n = __builtin_clz(v) - (sizeof(unsigned int) - sizeof(uint16_t)) * 8;
> +#ifdef HAVE___BUILTIN_CLZ
> + int n = __builtin_clz(v) - 16;
> +#else
> + int n = 16;
> + for (int i = 15; i >= 0; i--) {
> + if (v & (1 << i)) {
> + n = 15 - i;
> + break;
> + }
> + }
> +#endif
Not sure why you're not just using util_last_bit (I think it's best to
keep such bit scan hackery in separate util files), but whatever fixes
the compile error, so
Reviewed-by: Roland Scheidegger
>
> /* Shift the mantissa up so bit 16 is the hidden 1 bit,
> * mask it off, then shift back down to 10 bits
> */
> int m = ( ((uint32_t)v << (n + 1)) & 0x ) >> 6;
>
> /* (0{n} 1 X{15-n}) * 2^-16
> * = 1.X * 2^(15-n-16)
> * = 1.X * 2^(14-n - 15)
> * which is the FP16 form with e = 14 - n
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] radv: hardcode shader WAVE_LIMIT to the maximum value
On Fri, Oct 20, 2017 at 4:34 PM, Andres Rodriguez wrote: > When WAVE_LIMIT is set, a submission will opt-in for SPI based resource > scheduling. Because this mechanism is cooperative, we must ensure that > all submissions have this field set, otherwise they will bypass resource > arbitration. > > We always hardcode the field to its maximum value, instead of > attempting to calculate an approximate usage. In testing, there were no > benefits to using anything other than the maximum. > > Signed-off-by: Andres Rodriguez > --- > src/amd/vulkan/si_cmd_buffer.c | 27 ++- > src/gallium/drivers/radeonsi/si_state.c | 21 ++--- > 2 files changed, 32 insertions(+), 16 deletions(-) > > diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c > index de3b388..ac3dff8 100644 > --- a/src/amd/vulkan/si_cmd_buffer.c > +++ b/src/amd/vulkan/si_cmd_buffer.c > @@ -179,7 +179,8 @@ si_emit_compute(struct radv_physical_device > *physical_device, > radeon_emit(cs, 0); > radeon_emit(cs, 0); > > - radeon_set_sh_reg_seq(cs, R_00B854_COMPUTE_RESOURCE_LIMITS, 3); > + radeon_set_sh_reg_seq(cs, R_00B854_COMPUTE_RESOURCE_LIMITS, > + S_00B854_WAVES_PER_SH(0x3)); This part doesn't set WAVES_PER_SH. Also, the number 3 would be wrong for it. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/8] nir: evaluate if condition uses inside the if branches
Am 31.07.2018 13:34, schrieb Timothy Arceri: On 31/07/18 13:50, Dieter Nützel wrote: Am 30.07.2018 05:24, schrieb Dieter Nützel: For the series Tested-by: Dieter Nützel with glmark2, glxgears, UH, UV, Blender 2.79 and FreeCAD 0.17 on RX 580. With UH I saw some small light blue triangles spreading around. Have to bisect which patch set was the culprit. (If I have some time.) Tried your's above configure-bump-libdrm-for-AMDGPU-to-2.4.92.mbox (Samuel) ASTC-texture-compression-for-all-Gallium-drivers.mbox (Marek) Dieter It has something to do with tessellation. If I disable it (F3) all small light blue triangles are _gone_. Are you able to bisect? In short, it has _nothing_ to do with _this_ series. Tested on e6ff5ac446. So my tb stands. After some sleep (Nothern Germany is _very_ hot and _dry_ this year) I'll do my very best... ;-) Regards, Dieter Am 28.07.2018 03:07, schrieb Timothy Arceri: On 28/07/18 11:06, Timothy Arceri wrote: Since we know what side of the branch we ended up on we can just replace the use with a constant. All the spill changes in shader-db are from Dolphin uber shaders, despite some small regressions the change is clearly positive. V2: insert new constant after any phis in the use->parent_instr->type == nir_instr_type_phi path. Meh this was meant to be V3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: don't use __builtin_clz unconditionally
From: Marek Olšák
This fixes the build if __builtin_clz is unsupported.
---
src/util/half_float.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/util/half_float.c b/src/util/half_float.c
index 588f050d924..2eff2c84f51 100644
--- a/src/util/half_float.c
+++ b/src/util/half_float.c
@@ -208,21 +208,31 @@ uint8_t _mesa_half_to_unorm8(uint16_t val)
* Takes a uint16_t, divides by 65536, converts the infinite-precision
* result to fp16 with round-to-zero. Used by the ASTC decoder.
*/
uint16_t _mesa_uint16_div_64k_to_half(uint16_t v)
{
/* Zero or subnormal. Set the mantissa to (v << 8) and return. */
if (v < 4)
return v << 8;
/* Count the leading 0s in the uint16_t */
- int n = __builtin_clz(v) - (sizeof(unsigned int) - sizeof(uint16_t)) * 8;
+#ifdef HAVE___BUILTIN_CLZ
+ int n = __builtin_clz(v) - 16;
+#else
+ int n = 16;
+ for (int i = 15; i >= 0; i--) {
+ if (v & (1 << i)) {
+ n = 15 - i;
+ break;
+ }
+ }
+#endif
/* Shift the mantissa up so bit 16 is the hidden 1 bit,
* mask it off, then shift back down to 10 bits
*/
int m = ( ((uint32_t)v << (n + 1)) & 0x ) >> 6;
/* (0{n} 1 X{15-n}) * 2^-16
* = 1.X * 2^(15-n-16)
* = 1.X * 2^(14-n - 15)
* which is the FP16 form with e = 14 - n
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver
So you mean like the xorg way (priority low -> high): /usr/share/drirc.d/xxx.conf /etc/drirc.d/xxx.conf /etc/drirc ~/.drirc OK, I'll add this for the ease of driver config. Regards, Qiang From: Adam Jackson Sent: Wednesday, August 1, 2018 2:08:54 AM To: Yu, Qiang; mesa-dev@lists.freedesktop.org Cc: Emil Velikov Subject: Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver On Tue, 2018-07-31 at 08:03 +, Yu, Qiang wrote: > Seems the mesa driconf infrastructure is just what I need: > https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ > > So I can reference the loader_get_dri_config_device_id implementation > for adding loader driver override functionality in /etc/drirc: > > > > > > > Thoughts? If you're going to go down this route, please also teach Mesa to look for drirc (or drirc.d) under /usr/share first, then /etc. /etc really is for per-machine configuration, Mesa and driver defaults properly belong in /usr/share. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver
Good idea. But adding a new device attribute seems over-kill, how about just use the driver attribute and prefix a "k:" for kernel driver like this: ? Regards, Qiang From: Michel Dänzer Sent: Tuesday, July 31, 2018 9:35:09 PM To: Yu, Qiang Cc: mesa-dev@lists.freedesktop.org; Emil Velikov Subject: Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver On 2018-07-31 10:03 AM, Yu, Qiang wrote: > > Seems the mesa driconf infrastructure is just what I need: > https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ > > So I can reference the loader_get_dri_config_device_id implementation > for adding loader driver override functionality in /etc/drirc: > > > > > > > Thoughts? Using the driconf infrastructure is definitely better than creating a new mechanism. It'll even allow configuring the driver per application. :) Grepping for device_id in src/util/xmlpool/t_options.h and src/loader/loader.c might be useful. Here's an example of how I imagine general and per-application driver configuration could work: -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107439] mesa defines likely/unlikely and these are C++20 keywords
https://bugs.freedesktop.org/show_bug.cgi?id=107439 Bug ID: 107439 Summary: mesa defines likely/unlikely and these are C++20 keywords Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: brucedaw...@chromium.org QA Contact: mesa-dev@lists.freedesktop.org In util/macros.h mesa #defines likely and unlikely. This used to be a reasonable and legal thing to do but with the advent of C++20 this is no longer legal. C++20 treats likely and unlikely as reserved keywords for use as attributes. https://en.cppreference.com/w/cpp/language/attributes/likely This means that a conforming C++20 implementation may reject code that includes mesa's util/macros.h: https://cgit.freedesktop.org/mesa/mesa/tree/src/util/macros.h#n50 The concrete manifestation of this problem is that future versions of VC++ (unknown release date) will treat definitions of likely and unlikely as hard errors. These errors can temporarily be avoided by using _ALLOW_KEYWORD_MACROS but that is clearly a temporary hack. So, mesa should switch from likely/unlikely to LIKELY/UNLIKELY or some other variant. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vc4: Fix automake linking error.
"Juan A. Suarez Romero" writes:
> CXXLDgallium_dri.la
> ../../../../src/gallium/drivers/vc4/.libs/libvc4.a(vc4_cl_dump.o): In
> function `vc4_dump_cl':
> src/gallium/drivers/vc4/vc4_cl_dump.c:45: undefined reference to
> `clif_dump_init'
> src/gallium/drivers/vc4/vc4_cl_dump.c:82: undefined reference to
> `clif_dump_destroy'
> ../../../../src/broadcom/cle/.libs/libbroadcom_cle.a(cle_libbroadcom_cle_la-v3d_decoder.o):
> In function `v3d_field_iterator_next':
> src/broadcom/cle/v3d_decoder.c:902: undefined reference to `clif_lookup_bo'
>
> Fixes: e92959c4e0 ("v3d: Pass the whole clif_dump structure to
> v3d_print_group().")
> CC: Eric Anholt
I tried to come up with something yesterday, but automake was already
busted for me on both x86_64 simulator and ARM cross compiles, so I
didn't get far. While I can't test your patch, it's got my ack.
I can't wait for us to delete this build system.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/4] intel/nir: Use the correct scalar stage for consumers when linking
I guess you guys may want to look into Ken's comments on patch 3. But otherwise the series looks good to me and is: Reviewed-by: Timothy Arceri On 01/08/18 05:22, Jason Ekstrand wrote: --- src/intel/compiler/brw_nir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c index 5990427b731..17ccfa48af6 100644 --- a/src/intel/compiler/brw_nir.c +++ b/src/intel/compiler/brw_nir.c @@ -730,7 +730,7 @@ brw_nir_link_shaders(const struct brw_compiler *compiler, *producer = brw_nir_optimize(*producer, compiler, p_is_scalar); const bool c_is_scalar = - compiler->scalar_stage[(*producer)->info.stage]; + compiler->scalar_stage[(*consumer)->info.stage]; *consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar); } } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa: add ASTC 2D LDR decoder
On Mon, 2018-07-23 at 19:52 -0400, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/Makefile.sources |2 +
> src/mesa/main/formats.c| 42 +
> src/mesa/main/formats.h|3 +
> src/mesa/main/texcompress_astc.cpp | 1871
> src/mesa/main/texcompress_astc.h | 47 +
> src/util/half_float.c | 59 +
> src/util/half_float.h |5 +
> 7 files changed, 2029 insertions(+)
> create mode 100644 src/mesa/main/texcompress_astc.cpp
> create mode 100644 src/mesa/main/texcompress_astc.h
>
...
> diff --git a/src/util/half_float.c b/src/util/half_float.c
> index 4df64c2ccf9..588f050d924 100644
> --- a/src/util/half_float.c
> +++ b/src/util/half_float.c
> @@ -1,14 +1,16 @@
...
> +
> +/**
> + * Takes a uint16_t, divides by 65536, converts the infinite-precision
> + * result to fp16 with round-to-zero. Used by the ASTC decoder.
> + */
> +uint16_t _mesa_uint16_div_64k_to_half(uint16_t v)
> +{
> + /* Zero or subnormal. Set the mantissa to (v << 8) and return. */
> + if (v < 4)
> + return v << 8;
> +
> + /* Count the leading 0s in the uint16_t */
> + int n = __builtin_clz(v) - (sizeof(unsigned int) - sizeof(uint16_t)) * 8;
Marek, this seems to have broken the AppVeyor Windows build:
https://ci.appveyor.com/project/mesa3d/mesa/build/8475
It looks like you need some guards for __builtin_clz, as in:
https://cgit.freedesktop.org/mesa/mesa/tree/src/util/bitscan.h#n210
--
Br,
Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa: add ASTC 2D LDR decoder
Am 24.07.2018 um 01:52 schrieb Marek Olšák:
> From: Marek Olšák
>
> +uint16_t _mesa_uint16_div_64k_to_half(uint16_t v)
> +{
> + /* Zero or subnormal. Set the mantissa to (v << 8) and return. */
> + if (v < 4)
> + return v << 8;
> +
> + /* Count the leading 0s in the uint16_t */
> + int n = __builtin_clz(v) - (sizeof(unsigned int) - sizeof(uint16_t)) * 8;
This broke the windows build.
I think either use util_last_bit and some arithmetic or define some new
util function...
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] virgl: add initial ARB_compute_shader support
From: Dave Airlie
This hooks up compute shader creation and launch grid support.
---
src/gallium/drivers/virgl/virgl_context.c | 55 ++--
src/gallium/drivers/virgl/virgl_encode.c | 25 -
src/gallium/drivers/virgl/virgl_encode.h | 3 ++
src/gallium/drivers/virgl/virgl_hw.h | 5 +++
src/gallium/drivers/virgl/virgl_protocol.h | 11 ++
src/gallium/drivers/virgl/virgl_screen.c | 59 --
src/gallium/drivers/virgl/virgl_winsys.h | 2 +
7 files changed, 153 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/virgl/virgl_context.c
b/src/gallium/drivers/virgl/virgl_context.c
index d224b68cfcd..ae1da337994 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -506,7 +506,7 @@ static void *virgl_shader_encoder(struct pipe_context *ctx,
handle = virgl_object_assign_handle();
/* encode VS state */
ret = virgl_encode_shader_state(vctx, handle, type,
- >stream_output,
+ >stream_output, 0,
new_tokens);
if (ret) {
return NULL;
@@ -961,7 +961,7 @@ static void virgl_set_shader_buffers(struct pipe_context
*ctx,
pipe_resource_reference(>ssbos[shader][idx], NULL);
}
- uint32_t max_shader_buffer = shader == PIPE_SHADER_FRAGMENT ?
+ uint32_t max_shader_buffer = (shader == PIPE_SHADER_FRAGMENT || shader ==
PIPE_SHADER_COMPUTE) ?
rs->caps.caps.v2.max_shader_buffer_frag_compute :
rs->caps.caps.v2.max_shader_buffer_other_stages;
if (!max_shader_buffer)
@@ -989,7 +989,7 @@ static void virgl_set_shader_images(struct pipe_context
*ctx,
pipe_resource_reference(>images[shader][idx], NULL);
}
- uint32_t max_shader_images = shader == PIPE_SHADER_FRAGMENT ?
+ uint32_t max_shader_images = (shader == PIPE_SHADER_FRAGMENT || shader ==
PIPE_SHADER_COMPUTE) ?
rs->caps.caps.v2.max_shader_image_frag_compute :
rs->caps.caps.v2.max_shader_image_other_stages;
if (!max_shader_images)
@@ -1008,6 +1008,50 @@ static void virgl_memory_barrier(struct pipe_context
*ctx,
virgl_encode_memory_barrier(vctx, flags);
}
+static void *virgl_create_compute_state(struct pipe_context *ctx,
+const struct pipe_compute_state *state)
+{
+ struct virgl_context *vctx = virgl_context(ctx);
+ uint32_t handle;
+ const struct tgsi_token *new_tokens = state->prog;
+ struct pipe_stream_output_info so_info = {};
+ int ret;
+
+ handle = virgl_object_assign_handle();
+ ret = virgl_encode_shader_state(vctx, handle, PIPE_SHADER_COMPUTE,
+ _info,
+ state->req_local_mem,
+ new_tokens);
+ if (ret) {
+ return NULL;
+ }
+
+ return (void *)(unsigned long)handle;
+}
+
+static void virgl_bind_compute_state(struct pipe_context *ctx, void *state)
+{
+ uint32_t handle = (unsigned long)state;
+ struct virgl_context *vctx = virgl_context(ctx);
+
+ virgl_encode_bind_shader(vctx, handle, PIPE_SHADER_COMPUTE);
+}
+
+static void virgl_delete_compute_state(struct pipe_context *ctx, void *state)
+{
+ uint32_t handle = (unsigned long)state;
+ struct virgl_context *vctx = virgl_context(ctx);
+
+ virgl_encode_delete_object(vctx, handle, VIRGL_OBJECT_SHADER);
+}
+
+static void virgl_launch_grid(struct pipe_context *ctx,
+ const struct pipe_grid_info *info)
+{
+ struct virgl_context *vctx = virgl_context(ctx);
+ virgl_encode_launch_grid(vctx, info);
+}
+
static void
virgl_context_destroy( struct pipe_context *ctx )
{
@@ -1118,6 +1162,11 @@ struct pipe_context *virgl_context_create(struct
pipe_screen *pscreen,
vctx->base.delete_gs_state = virgl_delete_gs_state;
vctx->base.delete_fs_state = virgl_delete_fs_state;
+ vctx->base.create_compute_state = virgl_create_compute_state;
+ vctx->base.bind_compute_state = virgl_bind_compute_state;
+ vctx->base.delete_compute_state = virgl_delete_compute_state;
+ vctx->base.launch_grid = virgl_launch_grid;
+
vctx->base.clear = virgl_clear;
vctx->base.draw_vbo = virgl_draw_vbo;
vctx->base.flush = virgl_flush_from_st;
diff --git a/src/gallium/drivers/virgl/virgl_encode.c
b/src/gallium/drivers/virgl/virgl_encode.c
index 1d193ae6c7f..0cb5184d193 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -241,6 +241,7 @@ int virgl_encode_shader_state(struct virgl_context *ctx,
uint32_t handle,
uint32_t type,
const struct pipe_stream_output_info *so_info,
+ uint32_t cs_req_local_mem,
const struct tgsi_token *tokens)
{
char *str, *sptr;
@@ -298,7 +299,10 @@ int
[Mesa-dev] [PATCH 3/3] virgl: enable robustness if the host exposes GLSL 4.30
From: Dave Airlie
We enable this if the host exposes glsl 430 since that indicates
the host side has robustness support.
---
src/gallium/drivers/virgl/virgl_hw.h | 1 +
src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/virgl/virgl_hw.h
b/src/gallium/drivers/virgl/virgl_hw.h
index 3ccc979ac8c..487cbd67824 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -208,6 +208,7 @@ enum virgl_formats {
#define VIRGL_CAP_MEMORY_BARRIER (1 << 6)
#define VIRGL_CAP_COMPUTE_SHADER (1 << 7)
#define VIRGL_CAP_FB_NO_ATTACH (1 << 8)
+#define VIRGL_CAP_ROBUST_BUFFER_ACCESS (1 << 9)
#define VIRGL_BIND_DEPTH_STENCIL (1 << 0)
#define VIRGL_BIND_RENDER_TARGET (1 << 1)
diff --git a/src/gallium/drivers/virgl/virgl_screen.c
b/src/gallium/drivers/virgl/virgl_screen.c
index 9063ccd133e..b0a0d6b274d 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -227,6 +227,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap
param)
return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_TXQS;
case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_FB_NO_ATTACH;
+ case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
+ return vscreen->caps.caps.v2.capability_bits &
VIRGL_CAP_ROBUST_BUFFER_ACCESS;
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_FAKE_SW_MSAA:
@@ -258,7 +260,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap
param)
case PIPE_CAP_PCI_BUS:
case PIPE_CAP_PCI_DEVICE:
case PIPE_CAP_PCI_FUNCTION:
- case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
case PIPE_CAP_TGSI_VOTE:
case PIPE_CAP_MAX_WINDOW_RECTANGLES:
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] virgl: Support ARB_framebuffer_no_attachments
From: Dave Airlie
This uses new protocol to send the default sizes to the host.
---
src/gallium/drivers/virgl/virgl_encode.c | 6 ++
src/gallium/drivers/virgl/virgl_hw.h | 1 +
src/gallium/drivers/virgl/virgl_protocol.h | 10 ++
src/gallium/drivers/virgl/virgl_screen.c | 7 ++-
4 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/virgl/virgl_encode.c
b/src/gallium/drivers/virgl/virgl_encode.c
index 0cb5184d193..670c5fe6c3d 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -350,6 +350,12 @@ int virgl_encoder_set_framebuffer_state(struct
virgl_context *ctx,
virgl_encoder_write_dword(ctx->cbuf, surf ? surf->handle : 0);
}
+ struct virgl_screen *rs = virgl_screen(ctx->base.screen);
+ if (rs->caps.caps.v2.capability_bits & VIRGL_CAP_FB_NO_ATTACH) {
+ virgl_encoder_write_cmd_dword(ctx,
VIRGL_CMD0(VIRGL_CCMD_SET_FRAMEBUFFER_STATE_NO_ATTACH, 0,
VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_SIZE));
+ virgl_encoder_write_dword(ctx->cbuf, state->width | (state->height <<
16));
+ virgl_encoder_write_dword(ctx->cbuf, state->layers | (state->samples <<
16));
+ }
return 0;
}
diff --git a/src/gallium/drivers/virgl/virgl_hw.h
b/src/gallium/drivers/virgl/virgl_hw.h
index d58b347020b..3ccc979ac8c 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -207,6 +207,7 @@ enum virgl_formats {
#define VIRGL_CAP_TXQS (1 << 5)
#define VIRGL_CAP_MEMORY_BARRIER (1 << 6)
#define VIRGL_CAP_COMPUTE_SHADER (1 << 7)
+#define VIRGL_CAP_FB_NO_ATTACH (1 << 8)
#define VIRGL_BIND_DEPTH_STENCIL (1 << 0)
#define VIRGL_BIND_RENDER_TARGET (1 << 1)
diff --git a/src/gallium/drivers/virgl/virgl_protocol.h
b/src/gallium/drivers/virgl/virgl_protocol.h
index b94b7528c0c..982bc5c8c2b 100644
--- a/src/gallium/drivers/virgl/virgl_protocol.h
+++ b/src/gallium/drivers/virgl/virgl_protocol.h
@@ -90,6 +90,7 @@ enum virgl_context_cmd {
VIRGL_CCMD_SET_SHADER_IMAGES,
VIRGL_CCMD_MEMORY_BARRIER,
VIRGL_CCMD_LAUNCH_GRID,
+ VIRGL_CCMD_SET_FRAMEBUFFER_STATE_NO_ATTACH,
};
/*
@@ -529,4 +530,13 @@ enum virgl_context_cmd {
#define VIRGL_LAUNCH_INDIRECT_HANDLE 7
#define VIRGL_LAUNCH_INDIRECT_OFFSET 8
+/* framebuffer state no attachment */
+#define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_SIZE 2
+#define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_WIDTH_HEIGHT 1
+#define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_WIDTH(x) (x & 0x)
+#define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_HEIGHT(x) ((x >> 16) & 0x)
+#define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_LAYERS_SAMPLES 2
+#define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_LAYERS(x) (x & 0x)
+#define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_SAMPLES(x) ((x >> 16) & 0xff)
+
#endif
diff --git a/src/gallium/drivers/virgl/virgl_screen.c
b/src/gallium/drivers/virgl/virgl_screen.c
index be21a35bf08..9063ccd133e 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -225,6 +225,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap
param)
return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_COPY_IMAGE;
case PIPE_CAP_TGSI_TXQS:
return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_TXQS;
+ case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
+ return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_FB_NO_ATTACH;
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_FAKE_SW_MSAA:
@@ -256,7 +258,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap
param)
case PIPE_CAP_PCI_BUS:
case PIPE_CAP_PCI_DEVICE:
case PIPE_CAP_PCI_FUNCTION:
- case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
case PIPE_CAP_TGSI_VOTE:
@@ -574,6 +575,10 @@ virgl_is_format_supported( struct pipe_screen *screen,
return FALSE;
if (bind & PIPE_BIND_RENDER_TARGET) {
+ /* For ARB_framebuffer_no_attachments. */
+ if (format == PIPE_FORMAT_NONE)
+ return TRUE;
+
if (format_desc->colorspace == UTIL_FORMAT_COLORSPACE_ZS)
return FALSE;
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #8475 failed
Build mesa 8475 failed Commit 55d56dd859 by Marek Olšák on 7/24/2018 12:07 AM: docs: update radeonsi features and release notes Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/4] intel/nir: Split IO arrays into elements
On July 31, 2018 14:54:54 Kenneth Graunke wrote:
On Tuesday, July 31, 2018 12:22:02 PM PDT Jason Ekstrand wrote:
The NIR nir_lower_io_arrays_to_elements pass attempts to split I/O
variables which are arrays or matrices into a sequence of separate
variables. This can help link-time optimization by allowing us to
remove varyings at a more granular level.
Shader-db results on Kaby Lake:
total instructions in shared programs: 15177645 -> 15168494 (-0.06%)
instructions in affected programs: 79857 -> 70706 (-11.46%)
helped: 392
HURT: 0
---
src/intel/compiler/brw_nir.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 17ccfa48af6..29ad68fdb2a 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -709,6 +709,10 @@ void
brw_nir_link_shaders(const struct brw_compiler *compiler,
nir_shader **producer, nir_shader **consumer)
{
+ nir_lower_io_arrays_to_elements(*producer, *consumer);
+ nir_validate_shader(*producer);
+ nir_validate_shader(*consumer);
+
NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
This actually passes the test suite? That's strange. When I was
playing with this earlier, it was demoting gl_ClipDistance[1] from
a float[1] compact array to a single float variable...but leaving it
marked compact. var->data.compact = true makes no sense for non-arrays.
I think our clip/cull distance handling assumes that it's an array,
though. So...not sure whether the pass should unset compact, or skip
over compact arrays...
Yes, it passes just fine. I'm not sure exactly how it interacts with clip
distance lowering though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/4] intel/nir: Split IO arrays into elements
On Tuesday, July 31, 2018 12:22:02 PM PDT Jason Ekstrand wrote:
> The NIR nir_lower_io_arrays_to_elements pass attempts to split I/O
> variables which are arrays or matrices into a sequence of separate
> variables. This can help link-time optimization by allowing us to
> remove varyings at a more granular level.
>
> Shader-db results on Kaby Lake:
>
> total instructions in shared programs: 15177645 -> 15168494 (-0.06%)
> instructions in affected programs: 79857 -> 70706 (-11.46%)
> helped: 392
> HURT: 0
> ---
> src/intel/compiler/brw_nir.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 17ccfa48af6..29ad68fdb2a 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -709,6 +709,10 @@ void
> brw_nir_link_shaders(const struct brw_compiler *compiler,
> nir_shader **producer, nir_shader **consumer)
> {
> + nir_lower_io_arrays_to_elements(*producer, *consumer);
> + nir_validate_shader(*producer);
> + nir_validate_shader(*consumer);
> +
> NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
> NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
>
>
This actually passes the test suite? That's strange. When I was
playing with this earlier, it was demoting gl_ClipDistance[1] from
a float[1] compact array to a single float variable...but leaving it
marked compact. var->data.compact = true makes no sense for non-arrays.
I think our clip/cull distance handling assumes that it's an array,
though. So...not sure whether the pass should unset compact, or skip
over compact arrays...
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/4] intel/nir: Use the correct scalar stage for consumers when linking
On Tuesday, July 31, 2018 12:22:00 PM PDT Jason Ekstrand wrote: > --- > src/intel/compiler/brw_nir.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c > index 5990427b731..17ccfa48af6 100644 > --- a/src/intel/compiler/brw_nir.c > +++ b/src/intel/compiler/brw_nir.c > @@ -730,7 +730,7 @@ brw_nir_link_shaders(const struct brw_compiler *compiler, >*producer = brw_nir_optimize(*producer, compiler, p_is_scalar); > >const bool c_is_scalar = > - compiler->scalar_stage[(*producer)->info.stage]; > + compiler->scalar_stage[(*consumer)->info.stage]; >*consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar); > } > } > Patches 1-2 are: Reviewed-by: Kenneth Graunke signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i915/swrast vertex array regression
On Tue, Jul 31, 2018 at 08:29:18AM +0200, Mathias Fröhlich wrote:
> Hi Ville,
>
> > I noticed a while back that xonotic had started to misrender the gun
> > models on i915. Yesterday I bisected it down to commit 64d2a2048054
> > ("mesa: Make gl_vertex_array contain pointers to first order VAO
> > members."). Actually that commit broke things even worse (and the
> > game would even crash after a while), but a later commit (presumably
> > 98f35ad63c23 ("vbo: Correctly handle source arrays in vbo_split_copy.")
> > fixed things a little bit. But even with current master the guns are
> > still being misrendered. I also verified that the same breakage was
> > visible with swrast, whereas llvmpipe and i965 seemed ok.
> >
> > To reproduce you can run 'xonotic-glx -benchmark
> > demos/the-big-keybench.dem'
> > and wait until the guy picks up the mortar (I think that's what its
> > called) which is maybe the third gun he picks up in that demo. The gun
> > is supposed to have some red color on it but now it has green.
>
> I tried to reproduce that problem using classic swrast.
> Some variants of last weeks git master show the exact same
> pictures than swrast using the last good commit from your bisect.
> So, basically I can't reproduce the problem here.
Looks like
"vid_gl20" "0"
is needed to reproduce the issue.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/2] intel/nir: Call nir_lower_io_to_scalar_early
On Tue, Jul 31, 2018 at 9:55 AM Nils Wallménius wrote: > Hi, sorry for the drive-by but a comment in line below > > Den tis 31 juli 2018 16:09Jason Ekstrand skrev: > >> Shader-db results on Kaby Lake: >> >> total instructions in shared programs: 15166953 -> 15073611 (-0.62%) >> instructions in affected programs: 2390284 -> 2296942 (-3.91%) >> helped: 16469 >> HURT: 505 >> >> total loops in shared programs: 4954 -> 4951 (-0.06%) >> loops in affected programs: 3 -> 0 >> helped: 3 >> HURT: 0 >> --- >> src/intel/compiler/brw_nir.c | 17 - >> 1 file changed, 12 insertions(+), 5 deletions(-) >> >> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c >> index 99ef6bec77f..a6e3e502cdd 100644 >> --- a/src/intel/compiler/brw_nir.c >> +++ b/src/intel/compiler/brw_nir.c >> @@ -713,6 +713,18 @@ brw_nir_link_shaders(const struct brw_compiler >> *compiler, >> nir_validate_shader(*producer); >> nir_validate_shader(*consumer); >> >> + const bool p_is_scalar = >> + compiler->scalar_stage[(*producer)->info.stage]; >> + const bool c_is_scalar = >> + compiler->scalar_stage[(*producer)->info.stage]; >> > > Shouldn't the above index be s/producer/consumer/ ? else both booleans are > the same. > Good catch! That's a pre-existing bug. I've fixed it the v2 I just sent. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/4] i965/fs: Flag all slots of a flat input as flat
Otherwise, only the first vec4 of a matrix or other complex type will
get marked as flat and we'll interpolate the others. This was caught by
a dEQP test which started failing because it did a SSO vs. non-SSO
comparison. Previously, we did the interpolation wrong consistently in
both versions. However, with one of Tim Arceri's NIR linkingpatches, we
started splitting the matrix input into vectors at link time in the
non-SSO version and it started getting correctly interpolated which
didn't match the broken SSO version. As of this commit, they both get
correctly interpolated.
Fixes: e61cc87c757f8bc "i965/fs: Add a flat_inputs field to prog_data"
---
src/intel/compiler/brw_fs.cpp | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 7ddbd285fe2..20b89035e1f 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -6880,14 +6880,17 @@ brw_compute_flat_inputs(struct brw_wm_prog_data
*prog_data,
prog_data->flat_inputs = 0;
nir_foreach_variable(var, >inputs) {
- int input_index = prog_data->urb_setup[var->data.location];
+ unsigned slots = glsl_count_attribute_slots(var->type, false);
+ for (unsigned s = 0; s < slots; s++) {
+ int input_index = prog_data->urb_setup[var->data.location + s];
- if (input_index < 0)
-continue;
+ if (input_index < 0)
+continue;
- /* flat shading */
- if (var->data.interpolation == INTERP_MODE_FLAT)
- prog_data->flat_inputs |= (1 << input_index);
+ /* flat shading */
+ if (var->data.interpolation == INTERP_MODE_FLAT)
+prog_data->flat_inputs |= 1 << input_index;
+ }
}
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/4] intel/nir: Split IO arrays into elements
The NIR nir_lower_io_arrays_to_elements pass attempts to split I/O
variables which are arrays or matrices into a sequence of separate
variables. This can help link-time optimization by allowing us to
remove varyings at a more granular level.
Shader-db results on Kaby Lake:
total instructions in shared programs: 15177645 -> 15168494 (-0.06%)
instructions in affected programs: 79857 -> 70706 (-11.46%)
helped: 392
HURT: 0
---
src/intel/compiler/brw_nir.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 17ccfa48af6..29ad68fdb2a 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -709,6 +709,10 @@ void
brw_nir_link_shaders(const struct brw_compiler *compiler,
nir_shader **producer, nir_shader **consumer)
{
+ nir_lower_io_arrays_to_elements(*producer, *consumer);
+ nir_validate_shader(*producer);
+ nir_validate_shader(*consumer);
+
NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/4] intel/nir: Call nir_lower_io_to_scalar_early
Shader-db results on Kaby Lake:
total instructions in shared programs: 15166953 -> 15073611 (-0.62%)
instructions in affected programs: 2390284 -> 2296942 (-3.91%)
helped: 16469
HURT: 505
total loops in shared programs: 4954 -> 4951 (-0.06%)
loops in affected programs: 3 -> 0
helped: 3
HURT: 0
---
src/intel/compiler/brw_nir.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 29ad68fdb2a..31ffbe613ec 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -713,6 +713,18 @@ brw_nir_link_shaders(const struct brw_compiler *compiler,
nir_validate_shader(*producer);
nir_validate_shader(*consumer);
+ const bool p_is_scalar =
+ compiler->scalar_stage[(*producer)->info.stage];
+ const bool c_is_scalar =
+ compiler->scalar_stage[(*consumer)->info.stage];
+
+ if (p_is_scalar && c_is_scalar) {
+ NIR_PASS_V(*producer, nir_lower_io_to_scalar_early, nir_var_shader_out);
+ NIR_PASS_V(*consumer, nir_lower_io_to_scalar_early, nir_var_shader_in);
+ *producer = brw_nir_optimize(*producer, compiler, p_is_scalar);
+ *consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar);
+ }
+
NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
@@ -729,12 +741,7 @@ brw_nir_link_shaders(const struct brw_compiler *compiler,
NIR_PASS_V(*consumer, nir_lower_indirect_derefs,
brw_nir_no_indirect_mask(compiler, (*consumer)->info.stage));
- const bool p_is_scalar =
- compiler->scalar_stage[(*producer)->info.stage];
*producer = brw_nir_optimize(*producer, compiler, p_is_scalar);
-
- const bool c_is_scalar =
- compiler->scalar_stage[(*consumer)->info.stage];
*consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar);
}
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/4] intel/nir: Use the correct scalar stage for consumers when linking
--- src/intel/compiler/brw_nir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c index 5990427b731..17ccfa48af6 100644 --- a/src/intel/compiler/brw_nir.c +++ b/src/intel/compiler/brw_nir.c @@ -730,7 +730,7 @@ brw_nir_link_shaders(const struct brw_compiler *compiler, *producer = brw_nir_optimize(*producer, compiler, p_is_scalar); const bool c_is_scalar = - compiler->scalar_stage[(*producer)->info.stage]; + compiler->scalar_stage[(*consumer)->info.stage]; *consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar); } } -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] egl: Simplify queries for EGL_RENDER_BUFFER
There exist *two* queryable EGL_RENDER_BUFFER states in EGL:
eglQuerySurface(EGL_RENDER_BUFFER) and
eglQueryContext(EGL_RENDER_BUFFER).
These changes eliminate potentially very fragile code in the upcoming
EGL_KHR_mutable_render_buffer implementation.
* eglQuerySurface(EGL_RENDER_BUFFER)
The implementation of eglQuerySurface(EGL_RENDER_BUFFER) contained
abstruse logic which required comprehending the specification
complexities of how the two EGL_RENDER_BUFFER states interact. The
function sometimes returned _EGLContext::WindowRenderBuffer, sometimes
_EGLSurface::RenderBuffer. Why? The function tried to encode the
actual logic from the EGL spec. When did the function return which
variable? Go study the EGL spec, hope you understand it, then hope
Mesa mutated the EGL_RENDER_BUFFER state in all the correct places.
Have fun.
To simplify eglQuerySurface(EGL_RENDER_BUFFER), and to improve
confidence in its correctness, flatten its indirect logic. For pixmap
and pbuffer surfaces, simply return a hard-coded literal value, as the
spec suggests. For window surfaces, simply return
_EGLSurface::RequestedRenderBuffer. Nothing difficult here.
* eglQueryContext(EGL_RENDER_BUFFER)
The implementation of this suffered from the same issues as
eglQuerySurface, and the solution is the same. confidence in its
correctness, flatten its indirect logic. For pixmap and pbuffer
surfaces, simply return a hard-coded literal value, as the spec
suggests. For window surfaces, simply return
_EGLSurface::ActiveRenderBuffer.
---
src/egl/drivers/dri2/egl_dri2.c | 6 -
src/egl/main/eglcontext.c | 40 +++--
src/egl/main/eglcontext.h | 3 ---
src/egl/main/eglsurface.c | 28 ---
src/egl/main/eglsurface.h | 28 ++-
5 files changed, 85 insertions(+), 20 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index c3024795a10..e109ad37f55 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1289,12 +1289,6 @@ dri2_create_context(_EGLDriver *drv, _EGLDisplay *disp,
_EGLConfig *conf,
dri_config = dri2_config->dri_config[1][0];
else
dri_config = dri2_config->dri_config[0][0];
-
- /* EGL_WINDOW_BIT is set only when there is a double-buffered dri_config.
- * This makes sure the back buffer will always be used.
- */
- if (conf->SurfaceType & EGL_WINDOW_BIT)
- dri2_ctx->base.WindowRenderBuffer = EGL_BACK_BUFFER;
}
else
dri_config = NULL;
diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
index 3e5d8ad97bf..ecc546e1132 100644
--- a/src/egl/main/eglcontext.c
+++ b/src/egl/main/eglcontext.c
@@ -588,7 +588,6 @@ _eglInitContext(_EGLContext *ctx, _EGLDisplay *dpy,
_EGLConfig *conf,
_eglInitResource(>Resource, sizeof(*ctx), dpy);
ctx->ClientAPI = api;
ctx->Config = conf;
- ctx->WindowRenderBuffer = EGL_NONE;
ctx->Profile = EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR;
ctx->ClientMajorVersion = 1; /* the default, per EGL spec */
@@ -620,15 +619,42 @@ static EGLint
_eglQueryContextRenderBuffer(_EGLContext *ctx)
{
_EGLSurface *surf = ctx->DrawSurface;
- EGLint rb;
+ /* From the EGL 1.5 spec:
+*
+*- If the context is not bound to a surface, then EGL_NONE will be
+* returned.
+*/
if (!surf)
return EGL_NONE;
- if (surf->Type == EGL_WINDOW_BIT && ctx->WindowRenderBuffer != EGL_NONE)
- rb = ctx->WindowRenderBuffer;
- else
- rb = surf->RenderBuffer;
- return rb;
+
+ switch (surf->Type) {
+ default:
+ unreachable("bad EGLSurface type");
+ case EGL_PIXMAP_BIT:
+ /* - If the context is bound to a pixmap surface, then EGL_SINGLE_BUFFER
+ * will be returned.
+ */
+ return EGL_SINGLE_BUFFER;
+ case EGL_PBUFFER_BIT:
+ /* - If the context is bound to a pbuffer surface, then EGL_BACK_BUFFER
+ * will be returned.
+ */
+ return EGL_BACK_BUFFER;
+ case EGL_WINDOW_BIT:
+ /* - If the context is bound to a window surface, then either
+ * EGL_BACK_BUFFER or EGL_SINGLE_BUFFER may be returned. The value
+ * returned depends on both the buffer requested by the setting of the
+ * EGL_RENDER_BUFFER property of the surface [...], and on the client
+ * API (not all client APIs support single-buffer Rendering to window
+ * surfaces). Some client APIs allow control of whether rendering goes
+ * to the front or back buffer. This client API-specific choice is not
+ * reflected in the returned value, which only describes the buffer
+ * that will be rendered to by default if not overridden by the client
+ * API.
+ */
+ return surf->ActiveRenderBuffer;
+ }
}
diff --git a/src/egl/main/eglcontext.h b/src/egl/main/eglcontext.h
index 8d97ef9eab9..deddefdcaba
[Mesa-dev] [PATCH 4/7] dri: Add param driCreateConfigs(mutable_render_buffer)
If set, then the config will have __DRI_ATTRIB_MUTABLE_RENDER_BUFFER,
which translates to EGL_MUTABLE_RENDER_BUFFER_BIT_KHR.
Not used yet.
---
src/gallium/state_trackers/dri/dri_screen.c | 4 ++--
src/mesa/drivers/dri/common/utils.c | 9 +++--
src/mesa/drivers/dri/common/utils.h | 3 ++-
src/mesa/drivers/dri/i915/intel_screen.c | 4 ++--
src/mesa/drivers/dri/i965/intel_screen.c | 6 +++---
src/mesa/drivers/dri/nouveau/nouveau_screen.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_screen.c | 2 +-
src/mesa/drivers/dri/swrast/swrast.c | 2 +-
8 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_screen.c
b/src/gallium/state_trackers/dri/dri_screen.c
index 87729c190a8..99fb9e595ca 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -274,7 +274,7 @@ dri_fill_in_modes(struct dri_screen *screen)
depth_buffer_factor, back_buffer_modes,
ARRAY_SIZE(back_buffer_modes),
msaa_modes, 1,
-GL_TRUE, !mixed_color_depth);
+GL_TRUE, !mixed_color_depth, GL_FALSE);
configs = driConcatConfigs(configs, new_configs);
/* Multi-sample configs without an accumulation buffer. */
@@ -284,7 +284,7 @@ dri_fill_in_modes(struct dri_screen *screen)
depth_buffer_factor,
back_buffer_modes,
ARRAY_SIZE(back_buffer_modes),
msaa_modes+1, num_msaa_modes-1,
- GL_FALSE, !mixed_color_depth);
+ GL_FALSE, !mixed_color_depth,
GL_FALSE);
configs = driConcatConfigs(configs, new_configs);
}
}
diff --git a/src/mesa/drivers/dri/common/utils.c
b/src/mesa/drivers/dri/common/utils.c
index 86169d5c214..88835a7add5 100644
--- a/src/mesa/drivers/dri/common/utils.c
+++ b/src/mesa/drivers/dri/common/utils.c
@@ -147,7 +147,10 @@ driGetRendererString( char * buffer, const char *
hardware_name,
* \param color_depth_match Whether the color depth must match the zs depth
* This forces 32-bit color to have 24-bit depth, and
* 16-bit color to have 16-bit depth.
- *
+ * \param mutable_render_buffer Enable __DRI_ATTRIB_MUTABLE_RENDER_BUFFER,
+ * which translates to
+ * EGL_MUTABLE_RENDER_BUFFER_BIT_KHR.
+ *
* \returns
* Pointer to any array of pointers to the \c __DRIconfig structures created
* for the specified formats. If there is an error, \c NULL is returned.
@@ -160,7 +163,8 @@ driCreateConfigs(mesa_format format,
unsigned num_depth_stencil_bits,
const GLenum * db_modes, unsigned num_db_modes,
const uint8_t * msaa_samples, unsigned num_msaa_modes,
-GLboolean enable_accum, GLboolean color_depth_match)
+GLboolean enable_accum, GLboolean color_depth_match,
+GLboolean mutable_render_buffer)
{
static const uint32_t masks_table[][4] = {
/* MESA_FORMAT_B5G6R5_UNORM */
@@ -325,6 +329,7 @@ driCreateConfigs(mesa_format format,
modes->yInverted = GL_TRUE;
modes->sRGBCapable = is_srgb;
+ modes->mutableRenderBuffer = mutable_render_buffer;
}
}
}
diff --git a/src/mesa/drivers/dri/common/utils.h
b/src/mesa/drivers/dri/common/utils.h
index 7be0465c261..7c9719f9f42 100644
--- a/src/mesa/drivers/dri/common/utils.h
+++ b/src/mesa/drivers/dri/common/utils.h
@@ -45,7 +45,8 @@ driCreateConfigs(mesa_format format,
unsigned num_depth_stencil_bits,
const GLenum * db_modes, unsigned num_db_modes,
const uint8_t * msaa_samples, unsigned num_msaa_modes,
-GLboolean enable_accum, GLboolean color_depth_match);
+GLboolean enable_accum, GLboolean color_depth_match,
+GLboolean mutable_render_buffer);
__DRIconfig **driConcatConfigs(__DRIconfig **a,
__DRIconfig **b);
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 882c498622f..27be9219e47 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -1094,7 +1094,7 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
num_depth_stencil_bits,
back_buffer_modes, 2,
singlesample_samples, 1,
- false, false);
+
[Mesa-dev] [PATCH 3/7] dri: Define DRI_MutableRenderBuffer extensions
Define extensions DRI_MutableRenderBufferDriver and
DRI_MutableRenderBufferLoader. These are the two halves for
EGL_KHR_mutable_render_buffer.
Outside the DRI code there is one additional change. Add
gl_config::mutableRenderBuffer to match
__DRI_ATTRIB_MUTABLE_RENDER_BUFFER. Neither are used yet.
---
include/GL/internal/dri_interface.h| 138 -
src/mesa/drivers/dri/common/dri_util.c | 2 +
src/mesa/drivers/dri/common/dri_util.h | 4 +
src/mesa/drivers/dri/common/utils.c| 1 +
src/mesa/main/mtypes.h | 3 +
5 files changed, 145 insertions(+), 3 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index c32cdd3767a..245c845832b 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -48,6 +48,7 @@ typedef unsigned int drm_drawable_t;
typedef struct drm_clip_rect drm_clip_rect_t;
#endif
+#include
#include
/**
@@ -746,7 +747,8 @@ struct __DRIuseInvalidateExtensionRec {
#define __DRI_ATTRIB_BIND_TO_TEXTURE_TARGETS 46
#define __DRI_ATTRIB_YINVERTED 47
#define __DRI_ATTRIB_FRAMEBUFFER_SRGB_CAPABLE 48
-#define __DRI_ATTRIB_MAX
(__DRI_ATTRIB_FRAMEBUFFER_SRGB_CAPABLE + 1)
+#define __DRI_ATTRIB_MUTABLE_RENDER_BUFFER 49 /*
EGL_MUTABLE_RENDER_BUFFER_BIT_KHR */
+#define __DRI_ATTRIB_MAX 50
/* __DRI_ATTRIB_RENDER_TYPE */
#define __DRI_ATTRIB_RGBA_BIT 0x01
@@ -1888,9 +1890,57 @@ struct __DRI2rendererQueryExtensionRec {
* Image Loader extension. Drivers use this to allocate color buffers
*/
+/**
+ * See __DRIimageLoaderExtensionRec::getBuffers::buffer_mask.
+ */
enum __DRIimageBufferMask {
__DRI_IMAGE_BUFFER_BACK = (1 << 0),
- __DRI_IMAGE_BUFFER_FRONT = (1 << 1)
+ __DRI_IMAGE_BUFFER_FRONT = (1 << 1),
+
+ /**
+* A buffer shared between application and compositor. The buffer may be
+* simultaneously accessed by each.
+*
+* A shared buffer is equivalent to an EGLSurface whose EGLConfig contains
+* EGL_MUTABLE_RENDER_BUFFER_BIT_KHR and whose active EGL_RENDER_BUFFER (as
+* opposed to any pending, requested change to EGL_RENDER_BUFFER) is
+* EGL_SINGLE_BUFFER.
+*
+* If buffer_mask contains __DRI_IMAGE_BUFFER_SHARED, then must contains no
+* other bits. As a corollary, a __DRIdrawable that has a "shared" buffer
+* has no front nor back buffer.
+*
+* The loader returns __DRI_IMAGE_BUFFER_SHARED in buffer_mask if and only
+* if:
+* - The loader supports __DRI_MUTABLE_RENDER_BUFFER_LOADER.
+* - The driver supports __DRI_MUTABLE_RENDER_BUFFER_DRIVER.
+* - The EGLConfig of the drawable EGLSurface contains
+* EGL_MUTABLE_RENDER_BUFFER_BIT_KHR.
+* - The EGLContext's EGL_RENDER_BUFFER is EGL_SINGLE_BUFFER.
+* Equivalently, the EGLSurface's active EGL_RENDER_BUFFER (as
+* opposed to any pending, requested change to EGL_RENDER_BUFFER) is
+* EGL_SINGLE_BUFFER. (See the EGL 1.5 and
+* EGL_KHR_mutable_render_buffer spec for details about "pending" vs
+* "active" EGL_RENDER_BUFFER state).
+*
+* A shared buffer is similar to a front buffer in that all rendering to the
+* buffer should appear promptly on the screen. It is different from
+* a front buffer in that its behavior is independent from the
+* GL_DRAW_BUFFER state. Specifically, if GL_DRAW_FRAMEBUFFER is 0 and the
+* __DRIdrawable's buffer_mask is __DRI_IMAGE_BUFFER_SHARED, then all
+* rendering should appear promptly on the screen if GL_DRAW_BUFFER is not
+* GL_NONE.
+*
+* The difference between a shared buffer and a front buffer is motivated
+* by the constraints of Android and OpenGL ES. OpenGL ES does not support
+* front-buffer rendering. Android's SurfaceFlinger protocol provides the
+* EGL driver only a back buffer and no front buffer. The shared buffer
+* mode introduced by EGL_KHR_mutable_render_buffer is a backdoor though
+* EGL that allows Android OpenGL ES applications to render to what is
+* effectively the front buffer, a backdoor that required no change to the
+* OpenGL ES API and little change to the SurfaceFlinger API.
+*/
+ __DRI_IMAGE_BUFFER_SHARED = (1 << 2),
};
struct __DRIimageList {
@@ -1915,7 +1965,8 @@ struct __DRIimageLoaderExtensionRec {
* \param stamp Address of variable to be updated when
* getBuffers must be called again
* \param loaderPrivate The loaderPrivate for driDrawable
-* \param buffer_maskSet of buffers to allocate
+* \param buffer_maskSet of buffers to allocate. A bitmask of
+* __DRIimageBufferMask.
* \param buffersReturned buffers
*/
int (*getBuffers)(__DRIdrawable *driDrawable,
@@ -2029,4 +2080,85 @@ struct
[Mesa-dev] [PATCH 5/7] egl/main: Add bits for EGL_KHR_mutable_render_buffer
A follow-up patch enables EGL_KHR_mutable_render_buffer for Android.
This patch is separate from the Android patch because I think it's
easier to review the platform-independent bits separately.
---
src/egl/main/eglapi.c | 1 +
src/egl/main/eglconfig.c | 3 ++
src/egl/main/egldisplay.h | 1 +
src/egl/main/eglsurface.c | 59 +--
src/egl/main/eglsurface.h | 33 +-
5 files changed, 93 insertions(+), 4 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index deb479b6d56..f10ec994fde 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -509,6 +509,7 @@ _eglCreateExtensionsString(_EGLDisplay *dpy)
_EGL_CHECK_EXTENSION(KHR_image);
_EGL_CHECK_EXTENSION(KHR_image_base);
_EGL_CHECK_EXTENSION(KHR_image_pixmap);
+ _EGL_CHECK_EXTENSION(KHR_mutable_render_buffer);
_EGL_CHECK_EXTENSION(KHR_no_config_context);
_EGL_CHECK_EXTENSION(KHR_partial_update);
_EGL_CHECK_EXTENSION(KHR_reusable_sync);
diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
index 2d3b3ddd908..67d11ec9b0b 100644
--- a/src/egl/main/eglconfig.c
+++ b/src/egl/main/eglconfig.c
@@ -272,6 +272,7 @@ static const struct {
EGLBoolean
_eglValidateConfig(const _EGLConfig *conf, EGLBoolean for_matching)
{
+ _EGLDisplay *disp = conf->Display;
EGLint i, attr, val;
EGLBoolean valid = EGL_TRUE;
@@ -340,6 +341,8 @@ _eglValidateConfig(const _EGLConfig *conf, EGLBoolean
for_matching)
EGL_VG_ALPHA_FORMAT_PRE_BIT |
EGL_MULTISAMPLE_RESOLVE_BOX_BIT |
EGL_SWAP_BEHAVIOR_PRESERVED_BIT;
+if (disp->Extensions.KHR_mutable_render_buffer)
+ mask |= EGL_MUTABLE_RENDER_BUFFER_BIT_KHR;
break;
case EGL_RENDERABLE_TYPE:
case EGL_CONFORMANT:
diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
index d7e51991a45..4a7f248e34c 100644
--- a/src/egl/main/egldisplay.h
+++ b/src/egl/main/egldisplay.h
@@ -127,6 +127,7 @@ struct _egl_extensions
EGLBoolean KHR_image;
EGLBoolean KHR_image_base;
EGLBoolean KHR_image_pixmap;
+ EGLBoolean KHR_mutable_render_buffer;
EGLBoolean KHR_no_config_context;
EGLBoolean KHR_partial_update;
EGLBoolean KHR_reusable_sync;
diff --git a/src/egl/main/eglsurface.c b/src/egl/main/eglsurface.c
index 73c31e11588..926b7ab569a 100644
--- a/src/egl/main/eglsurface.c
+++ b/src/egl/main/eglsurface.c
@@ -123,6 +123,12 @@ _eglParseSurfaceAttribList(_EGLSurface *surf, const EGLint
*attrib_list)
break;
}
surf->RequestedRenderBuffer = val;
+ if (surf->Config->SurfaceType & EGL_MUTABLE_RENDER_BUFFER_BIT_KHR) {
+/* Unlike normal EGLSurfaces, one with a mutable render buffer
+ * uses the application-chosen render buffer.
+ */
+surf->ActiveRenderBuffer = val;
+ }
break;
case EGL_POST_SUB_BUFFER_SUPPORTED_NV:
if (!dpy->Extensions.NV_post_sub_buffer ||
@@ -359,12 +365,19 @@ _eglQuerySurface(_EGLDriver *drv, _EGLDisplay *dpy,
_EGLSurface *surface,
*value = surface->SwapBehavior;
break;
case EGL_RENDER_BUFFER:
- /* From the EGL 1.5 spec (2014.08.27):
+ /* From the EGL_KHR_mutable_render_buffer spec (v12):
*
*Querying EGL_RENDER_BUFFER returns the buffer which client API
*rendering is requested to use. For a window surface, this is the
- *same attribute value specified when the surface was created. For
- *a pbuffer surface, it is always EGL_BACK_BUFFER . For a pixmap
+ *attribute value specified when the surface was created or last set
+ *via eglSurfaceAttrib.
+ *
+ * In other words, querying a window surface returns the value most
+ * recently *requested* by the user.
+ *
+ * The paragraph continues in the EGL 1.5 spec (2014.08.27):
+ *
+ *For a pbuffer surface, it is always EGL_BACK_BUFFER . For a pixmap
*surface, it is always EGL_SINGLE_BUFFER . To determine the actual
*buffer being rendered to by a context, call eglQueryContext.
*/
@@ -472,6 +485,31 @@ _eglSurfaceAttrib(_EGLDriver *drv, _EGLDisplay *dpy,
_EGLSurface *surface,
break;
surface->MultisampleResolve = value;
break;
+ case EGL_RENDER_BUFFER:
+ if (!dpy->Extensions.KHR_mutable_render_buffer) {
+ err = EGL_BAD_ATTRIBUTE;
+ break;
+ }
+
+ if (value != EGL_BACK_BUFFER && value != EGL_SINGLE_BUFFER) {
+ err = EGL_BAD_PARAMETER;
+ break;
+ }
+
+ /* From the EGL_KHR_mutable_render_buffer spec (v12):
+ *
+ *If attribute is EGL_RENDER_BUFFER, and the EGL_SURFACE_TYPE
+ *attribute of the EGLConfig used to create surface does not contain
+ *EGL_MUTABLE_RENDER_BUFFER_BIT_KHR, [...] an EGL_BAD_MATCH error is
+ *
[Mesa-dev] [PATCH 7/7] i965: Implement EGL_KHR_mutable_render_buffer
Tested with a low-latency handwriting application on Android Nougat on
the Chrome OS Pixelbook (codename Eve) with Kabylake.
---
src/mesa/drivers/dri/i965/brw_context.c | 86 +++-
src/mesa/drivers/dri/i965/brw_context.h | 12
src/mesa/drivers/dri/i965/intel_screen.c | 13 +++-
3 files changed, 107 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 968fc1d43d6..9dfd9520555 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -239,6 +239,35 @@ intel_flush_front(struct gl_context *ctx)
}
}
+static void
+brw_display_shared_buffer(struct brw_context *brw)
+{
+ __DRIcontext *dri_context = brw->driContext;
+ __DRIdrawable *dri_drawable = dri_context->driDrawablePriv;
+ __DRIscreen *dri_screen = brw->screen->driScrnPriv;
+ int fence_fd = -1;
+
+ if (!brw->is_shared_buffer_bound)
+ return;
+
+ if (!brw->is_shared_buffer_dirty)
+ return;
+
+ if (brw->screen->has_exec_fence) {
+ /* This function is always called during a flush operation, so there is
+ * no need to flush again here. But we want to provide a fence_fd to the
+ * loader, and a redundant flush is the easiest way to acquire one.
+ */
+ if (intel_batchbuffer_flush_fence(brw, -1, _fd))
+ return;
+ }
+
+ dri_screen->mutableRenderBuffer.loader
+ ->displaySharedBuffer(dri_drawable, fence_fd,
+dri_drawable->loaderPrivate);
+ brw->is_shared_buffer_dirty = false;
+}
+
static void
intel_glFlush(struct gl_context *ctx)
{
@@ -246,7 +275,7 @@ intel_glFlush(struct gl_context *ctx)
intel_batchbuffer_flush(brw);
intel_flush_front(ctx);
-
+ brw_display_shared_buffer(brw);
brw->need_flush_throttle = true;
}
@@ -1457,6 +1486,11 @@ intel_prepare_render(struct brw_context *brw)
*/
if (_mesa_is_front_buffer_drawing(ctx->DrawBuffer))
brw->front_buffer_dirty = true;
+
+ if (brw->is_shared_buffer_bound) {
+ /* Subsequent rendering will probably dirty the shared buffer. */
+ brw->is_shared_buffer_dirty = true;
+ }
}
/**
@@ -1690,8 +1724,12 @@ intel_update_image_buffer(struct brw_context *intel,
else
last_mt = rb->singlesample_mt;
- if (last_mt && last_mt->bo == buffer->bo)
+ if (last_mt && last_mt->bo == buffer->bo) {
+ if (buffer_type == __DRI_IMAGE_BUFFER_SHARED) {
+ intel_miptree_make_shareable(intel, last_mt);
+ }
return;
+ }
/* Only allow internal compression if samples == 0. For multisampled
* window system buffers, the only thing the single-sampled buffer is used
@@ -1720,6 +1758,35 @@ intel_update_image_buffer(struct brw_context *intel,
rb->Base.Base.NumSamples > 1) {
intel_renderbuffer_upsample(intel, rb);
}
+
+ if (buffer_type == __DRI_IMAGE_BUFFER_SHARED) {
+ /* The compositor and the application may access this image
+ * concurrently. The display hardware may even scanout the image while
+ * the GPU is rendering to it. Aux surfaces cause difficulty with
+ * concurrent access, so permanently disable aux for this miptree.
+ *
+ * Perhaps we could improve overall application performance by
+ * re-enabling the aux surface when EGL_RENDER_BUFFER transitions to
+ * EGL_BACK_BUFFER, then disabling it again when EGL_RENDER_BUFFER
+ * returns to EGL_SINGLE_BUFFER. I expect the wins and losses with this
+ * approach to be highly dependent on the application's GL usage.
+ *
+ * I [chadv] expect clever disabling/reenabling to be counterproductive
+ * in the use cases I care about: applications that render nearly
+ * realtime handwriting to the surface while possibly undergiong
+ * simultaneously scanout as a display plane. The app requires low
+ * render latency. Even though the app spends most of its time in
+ * shared-buffer mode, it also frequently transitions between
+ * shared-buffer (EGL_SINGLE_BUFFER) and double-buffer (EGL_BACK_BUFFER)
+ * mode. Visual sutter during the transitions should be avoided.
+ *
+ * In this case, I [chadv] believe reducing the GPU workload at
+ * shared-buffer/double-buffer transitions would offer a smoother app
+ * experience than any savings due to aux compression. But I've
+ * collected no data to prove my theory.
+ */
+ intel_miptree_make_shareable(intel, mt);
+ }
}
static void
@@ -1780,4 +1847,19 @@ intel_update_image_buffers(struct brw_context *brw,
__DRIdrawable *drawable)
images.back,
__DRI_IMAGE_BUFFER_BACK);
}
+
+ if (images.image_mask & __DRI_IMAGE_BUFFER_SHARED) {
+ assert(images.image_mask == __DRI_IMAGE_BUFFER_SHARED);
+ drawable->w = images.back->width;
+ drawable->h = images.back->height;
+
[Mesa-dev] [PATCH 6/7] egl/android: Implement EGL_KHR_mutable_render_buffer
Specifically, implement the extension DRI_MutableRenderBufferLoader.
However, the loader enables EGL_KHR_mutable_render_buffer only if the
DRI driver implements its half of the extension,
DRI_MutableRenderBufferDriver.
---
src/egl/drivers/dri2/egl_dri2.c | 38 +-
src/egl/drivers/dri2/egl_dri2.h | 7 +
src/egl/drivers/dri2/platform_android.c | 168 +++-
3 files changed, 206 insertions(+), 7 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 1208ebb3156..1a7338aa51d 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -272,7 +272,10 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig
*dri_config, int id,
_eglSetConfigKey(, EGL_MAX_PBUFFER_HEIGHT,
_EGL_MAX_PBUFFER_HEIGHT);
break;
-
+ case __DRI_ATTRIB_MUTABLE_RENDER_BUFFER:
+ if (disp->Extensions.KHR_mutable_render_buffer)
+surface_type |= EGL_MUTABLE_RENDER_BUFFER_BIT_KHR;
+ break;
default:
key = dri2_to_egl_attribute_map[attrib];
if (key != 0)
@@ -432,6 +435,7 @@ static const struct dri2_extension_match
optional_core_extensions[] = {
{ __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
{ __DRI2_FLUSH_CONTROL, 1, offsetof(struct dri2_egl_display, flush_control)
},
{ __DRI2_BLOB, 1, offsetof(struct dri2_egl_display, blob) },
+ { __DRI_MUTABLE_RENDER_BUFFER_DRIVER, 1, offsetof(struct dri2_egl_display,
mutable_render_buffer) },
{ NULL, 0, 0 }
};
@@ -1459,6 +1463,8 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
{
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
+ _EGLDisplay *old_disp = NULL;
+ struct dri2_egl_display *old_dri2_dpy = NULL;
_EGLContext *old_ctx;
_EGLSurface *old_dsurf, *old_rsurf;
_EGLSurface *tmp_dsurf, *tmp_rsurf;
@@ -1475,6 +1481,11 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
return EGL_FALSE;
}
+ if (old_ctx) {
+ old_disp = old_ctx->Resource.Display;
+ old_dri2_dpy = dri2_egl_display(old_disp);
+ }
+
/* flush before context switch */
if (old_ctx)
dri2_gl_flush();
@@ -1488,6 +1499,13 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
if (old_dsurf)
dri2_surf_update_fence_fd(old_ctx, disp, old_dsurf);
+
+ /* Disable shared buffer mode */
+ if (old_dsurf && _eglSurfaceInSharedBufferMode(old_dsurf) &&
+ old_dri2_dpy->vtbl->set_shared_buffer_mode) {
+ old_dri2_dpy->vtbl->set_shared_buffer_mode(old_disp, old_dsurf,
false);
+ }
+
dri2_dpy->core->unbindContext(old_cctx);
}
@@ -1500,6 +1518,11 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
tmp_dsurf == dsurf &&
tmp_rsurf == rsurf);
+ if (old_dsurf && _eglSurfaceInSharedBufferMode(old_dsurf) &&
+ old_dri2_dpy->vtbl->set_shared_buffer_mode) {
+ old_dri2_dpy->vtbl->set_shared_buffer_mode(old_disp, old_dsurf, true);
+ }
+
_eglPutSurface(dsurf);
_eglPutSurface(rsurf);
_eglPutContext(ctx);
@@ -1522,11 +1545,22 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
dri2_dpy->ref_count++;
if (old_ctx) {
- EGLDisplay old_disp = _eglGetDisplayHandle(old_ctx->Resource.Display);
dri2_destroy_context(drv, disp, old_ctx);
dri2_display_release(old_disp);
}
+ if (dsurf && _eglSurfaceHasMutableRenderBuffer(dsurf) &&
+ dri2_dpy->vtbl->set_shared_buffer_mode) {
+ /* Always update the shared buffer mode. This is obviously needed when
+ * the active EGL_RENDER_BUFFER is EGL_SINGLE_BUFFER. When
+ * EGL_RENDER_BUFFER is EGL_BACK_BUFFER, the update protects us in the
+ * case where external non-EGL API may have changed window's shared
+ * buffer mode since we last saw it.
+ */
+ bool mode = (dsurf->ActiveRenderBuffer == EGL_SINGLE_BUFFER);
+ dri2_dpy->vtbl->set_shared_buffer_mode(disp, dsurf, mode);
+ }
+
return EGL_TRUE;
}
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 5d8fbfa2356..d8a65be7085 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -151,6 +151,12 @@ struct dri2_egl_display_vtbl {
__DRIdrawable *(*get_dri_drawable)(_EGLSurface *surf);
void (*close_screen_notify)(_EGLDisplay *dpy);
+
+ /* Used in EGL_KHR_mutable_render_buffer to update the native window's
+* shared buffer mode.
+*/
+ bool (*set_shared_buffer_mode)(_EGLDisplay *dpy, _EGLSurface *surf,
+ bool mode);
};
struct dri2_egl_display
@@ -178,6 +184,7 @@ struct dri2_egl_display
const __DRI2blobExtension *blob;
const
[Mesa-dev] [PATCH 2/7] egl/dri2: In dri2_make_current, return early on failure
This pulls an 'else' block into the function's main body, making the
code easier to follow.
Without this change, the upcoming EGL_KHR_mutable_render_buffer patch
transforms dri2_make_current() into spaghetti.
---
src/egl/drivers/dri2/egl_dri2.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index e109ad37f55..1208ebb3156 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1493,20 +1493,7 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);
- if (unbind || dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
- dri2_destroy_surface(drv, disp, old_dsurf);
- dri2_destroy_surface(drv, disp, old_rsurf);
-
- if (!unbind)
- dri2_dpy->ref_count++;
- if (old_ctx) {
- EGLDisplay old_disp = _eglGetDisplayHandle(old_ctx->Resource.Display);
- dri2_destroy_context(drv, disp, old_ctx);
- dri2_display_release(old_disp);
- }
-
- return EGL_TRUE;
- } else {
+ if (!unbind && !dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
/* undo the previous _eglBindContext */
_eglBindContext(old_ctx, old_dsurf, old_rsurf, , _dsurf,
_rsurf);
assert(_ctx->base == ctx &&
@@ -1527,6 +1514,20 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
*/
return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
}
+
+ dri2_destroy_surface(drv, disp, old_dsurf);
+ dri2_destroy_surface(drv, disp, old_rsurf);
+
+ if (!unbind)
+ dri2_dpy->ref_count++;
+
+ if (old_ctx) {
+ EGLDisplay old_disp = _eglGetDisplayHandle(old_ctx->Resource.Display);
+ dri2_destroy_context(drv, disp, old_ctx);
+ dri2_display_release(old_disp);
+ }
+
+ return EGL_TRUE;
}
__DRIdrawable *
--
2.18.0.345.g5c9ce644c3-goog
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/7] egl, i965: Implement EGL_KHR_mutable_render_buffer
Despite the KHR, Android is the only OS that uses this extension, as far
as I know. Essentially, it allows the app to toggle
front-buffer/back-buffer rendering using EGL.
Android requires this extension if the device advertises support for
virtual reality. No Chrome OS device yet supports Android's VR software
requirements, though, and VR is not why I implemented this.
This extension enables handwriting and drawing apps on Chrome and
Android devices to achieve very low latency between touch input
and display response.
Please don't bash me for this oddly-specified Android extension.
I didn't create it. I'm just writing the code that Android requires.
* Patch 3 defines a pair of new DRI extensions,
DRI_MutableRenderBuffer{Driver,Loader}.
* Patches 1-5 add the generic code for the DRI and EGL extensions.
* Patch 6 implements DRI_MutableRenderBufferLoader for Android EGL.
* Patch 7 implements DRI_MutableRenderBufferDriver for i965.
This series is tagged at:
http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=refs/tags/chadv/review/i965-mutable-render-buffer-v01
Chad Versace (7):
egl: Simplify queries for EGL_RENDER_BUFFER
egl/dri2: In dri2_make_current, return early on failure
dri: Define DRI_MutableRenderBuffer extensions
dri: Add param driCreateConfigs(mutable_render_buffer)
egl/main: Add bits for EGL_KHR_mutable_render_buffer
egl/android: Implement EGL_KHR_mutable_render_buffer
i965: Implement EGL_KHR_mutable_render_buffer
include/GL/internal/dri_interface.h | 138 +-
src/egl/drivers/dri2/egl_dri2.c | 71 +---
src/egl/drivers/dri2/egl_dri2.h | 7 +
src/egl/drivers/dri2/platform_android.c | 168 +-
src/egl/main/eglapi.c | 1 +
src/egl/main/eglconfig.c | 3 +
src/egl/main/eglcontext.c | 40 -
src/egl/main/eglcontext.h | 3 -
src/egl/main/egldisplay.h | 1 +
src/egl/main/eglsurface.c | 81 -
src/egl/main/eglsurface.h | 59 +-
src/gallium/state_trackers/dri/dri_screen.c | 4 +-
src/mesa/drivers/dri/common/dri_util.c| 2 +
src/mesa/drivers/dri/common/dri_util.h| 4 +
src/mesa/drivers/dri/common/utils.c | 10 +-
src/mesa/drivers/dri/common/utils.h | 3 +-
src/mesa/drivers/dri/i915/intel_screen.c | 4 +-
src/mesa/drivers/dri/i965/brw_context.c | 86 -
src/mesa/drivers/dri/i965/brw_context.h | 12 ++
src/mesa/drivers/dri/i965/intel_screen.c | 17 +-
src/mesa/drivers/dri/nouveau/nouveau_screen.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_screen.c | 2 +-
src/mesa/drivers/dri/swrast/swrast.c | 2 +-
src/mesa/main/mtypes.h| 3 +
24 files changed, 664 insertions(+), 59 deletions(-)
--
2.18.0.345.g5c9ce644c3-goog
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/7] egl, i965: Implement EGL_KHR_mutable_render_buffer
Ignore this series. It's incomplete. It seems mesa-dev had hiccups last night. I'll resend now. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver
On Tue, 2018-07-31 at 08:03 +, Yu, Qiang wrote: > Seems the mesa driconf infrastructure is just what I need: > https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ > > So I can reference the loader_get_dri_config_device_id implementation > for adding loader driver override functionality in /etc/drirc: > > > > > > > Thoughts? If you're going to go down this route, please also teach Mesa to look for drirc (or drirc.d) under /usr/share first, then /etc. /etc really is for per-machine configuration, Mesa and driver defaults properly belong in /usr/share. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Make glXChooseFBConfig handle unspecified sRGB correctly
On Mon, 2018-07-30 at 12:14 -0700, Eric Anholt wrote: > Jon Turney writes: > > > Make glXChooseFBConfig properly handle the case where the only matching > > configs have the sRGB flag set, but no sRGB attribute is specified. > > > > Since 6e06e281, the sRGBcapable flag is now actually compared, using > > MATCH_DONT_CARE. > > > > 7b0f912e added defaulting of sRGBcapable to GL_FALSE in > > __glXInitializeVisualConfigFromTags(), to handle servers which don't report > > it, but this function is also used by glXChooseFBConfig(), so sRGBcapable is > > implicitly false when not explicitly specified. > > > > (This can cause e.g. glxinfo to fail to find anything matching the simple > > config it looks for if all the candidates have the sRGB flag set to true. > > I'm assuming this doesn't happen 'normally' as candidate configs with and > > without sRGB true are available) > > > > Move this defaulting to createConfigsFromProperties(), and set the default > > for glXChooseFBConfig() in init_fbconfig_for_chooser() to GLX_DONT_CARE. > > Reviewed-by: Eric Anholt This change looks sane, but I note that the extension doesn't actually specify how we're supposed to handle this attribute. I've filed a spec bug, in the vague hope that that'll be addressed someday: https://github.com/KhronosGroup/OpenGL-Registry/issues/199 Regardless, patch merged, thanks: To gitlab.freedesktop.org:mesa/mesa.git 03a61b977e1..faa29c0e244 master -> master - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] dri3: For 1.2, use root window instead of pixmap drawable
On Fri, 2018-07-27 at 16:16 +0200, Olivier Fourdan wrote:
> Hi,
>
> On Thu, 26 Jul 2018 at 19:53, Eric Anholt wrote:
> >
> > Olivier Fourdan writes:
> >
> > > get_supported_modifiers() and pixmap_from_buffers() requests both
> > > expect a window as drawable, passing a pixmap will fail as the Xserver
> > > will fail to match the given drawable to a window.
> > >
> > > That leads to dri3_alloc_render_buffer() to return NULL and breaks
> > > rendering when using GLX_DOUBLEBUFFER on pixmaps.
> > >
> > > Query the root window of the pixmap on first init, and use the root
> > > window instead of the pixmap drawable for get_supported_modifiers()
> > > and pixmap_from_buffers().
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107117
> > > Fixes: 069fdd5 ("egl/x11: Support DRI3 v1.1")
> > > Signed-off-by: Olivier Fourdan
> >
> > Looks great!
> >
> > Reviewed-by: Eric Anholt
>
> Thanks both Daniel and Eric for the reviews!
>
> If I may, could someone push that fix for me, I don't think I have
> commit rights in Mesa...
>
> (It's a regression affecting Mesa 18.1 with Xserver 1.20, would be
> great to have it fixed)
Merged, thanks:
To gitlab.freedesktop.org:mesa/mesa.git
16b5e15e918..03a61b977e1 master -> master
- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vc4: Fix automake linking error.
CXXLDgallium_dri.la
../../../../src/gallium/drivers/vc4/.libs/libvc4.a(vc4_cl_dump.o): In function
`vc4_dump_cl':
src/gallium/drivers/vc4/vc4_cl_dump.c:45: undefined reference to
`clif_dump_init'
src/gallium/drivers/vc4/vc4_cl_dump.c:82: undefined reference to
`clif_dump_destroy'
../../../../src/broadcom/cle/.libs/libbroadcom_cle.a(cle_libbroadcom_cle_la-v3d_decoder.o):
In function `v3d_field_iterator_next':
src/broadcom/cle/v3d_decoder.c:902: undefined reference to `clif_lookup_bo'
Fixes: e92959c4e0 ("v3d: Pass the whole clif_dump structure to
v3d_print_group().")
CC: Eric Anholt
---
src/gallium/drivers/vc4/Automake.inc | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/vc4/Automake.inc
b/src/gallium/drivers/vc4/Automake.inc
index b1aa9726bd6..c9afa2478e9 100644
--- a/src/gallium/drivers/vc4/Automake.inc
+++ b/src/gallium/drivers/vc4/Automake.inc
@@ -7,4 +7,11 @@ TARGET_LIB_DEPS += \
$(top_builddir)/src/gallium/drivers/vc4/libvc4.la \
$(top_builddir)/src/broadcom/cle/libbroadcom_cle.la
+if !HAVE_GALLIUM_V3D
+TARGET_LIB_DEPS += \
+ $(top_builddir)/src/broadcom/libbroadcom.la \
+ $(top_builddir)/src/broadcom/libbroadcom_v33.la \
+ $(top_builddir)/src/broadcom/libbroadcom_v41.la
+endif
+
endif
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/2] intel/nir: Call nir_lower_io_to_scalar_early
Hi, sorry for the drive-by but a comment in line below
Den tis 31 juli 2018 16:09Jason Ekstrand skrev:
> Shader-db results on Kaby Lake:
>
> total instructions in shared programs: 15166953 -> 15073611 (-0.62%)
> instructions in affected programs: 2390284 -> 2296942 (-3.91%)
> helped: 16469
> HURT: 505
>
> total loops in shared programs: 4954 -> 4951 (-0.06%)
> loops in affected programs: 3 -> 0
> helped: 3
> HURT: 0
> ---
> src/intel/compiler/brw_nir.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 99ef6bec77f..a6e3e502cdd 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -713,6 +713,18 @@ brw_nir_link_shaders(const struct brw_compiler
> *compiler,
> nir_validate_shader(*producer);
> nir_validate_shader(*consumer);
>
> + const bool p_is_scalar =
> + compiler->scalar_stage[(*producer)->info.stage];
> + const bool c_is_scalar =
> + compiler->scalar_stage[(*producer)->info.stage];
>
Shouldn't the above index be s/producer/consumer/ ? else both booleans are
the same.
BR
Nils
+
> + if (p_is_scalar && c_is_scalar) {
> + NIR_PASS_V(*producer, nir_lower_io_to_scalar_early,
> nir_var_shader_out);
> + NIR_PASS_V(*consumer, nir_lower_io_to_scalar_early,
> nir_var_shader_in);
> + *producer = brw_nir_optimize(*producer, compiler, p_is_scalar);
> + *consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar);
> + }
> +
> NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
> NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
>
> @@ -729,12 +741,7 @@ brw_nir_link_shaders(const struct brw_compiler
> *compiler,
>NIR_PASS_V(*consumer, nir_lower_indirect_derefs,
> brw_nir_no_indirect_mask(compiler,
> (*consumer)->info.stage));
>
> - const bool p_is_scalar =
> - compiler->scalar_stage[(*producer)->info.stage];
>*producer = brw_nir_optimize(*producer, compiler, p_is_scalar);
> -
> - const bool c_is_scalar =
> - compiler->scalar_stage[(*producer)->info.stage];
>*consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar);
> }
> }
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107369] "volatile" in OpenCL code not recognized when compiling with -fstack-protector
https://bugs.freedesktop.org/show_bug.cgi?id=107369 --- Comment #13 from infini...@pwned.gg --- Created attachment 140907 --> https://bugs.freedesktop.org/attachment.cgi?id=140907=edit clover debug dump Attached a dump, it's 1 out of several thousand files and compressed is 11MB. -- 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 https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/screen: MOD_FORMAT_Y_TILED is only supported by gen9+
Ok, we have a diagnosis of the real issue, thanks Jason. With that i
leave dealing with it to the experts. If some testing or light review
of the proper solution is needed on the modesetting-ddx side, happy to
do that.
-mario
On Tue, Jul 31, 2018 at 6:01 PM, Jason Ekstrand wrote:
> NAK.
>
> On SNB+, we'd like to get Y-tiling when the surface is only being used by
> the compositor and reserve X-tiling for scanout surfaces. With the
> modifiers negotiation framework, the X server should be able to figure out
> that the window is being composited (or blitted) and request Y-tiling. If
> the surface is full-screen, it should know this and either require X-tiling
> because that's all KMS advertises or not flip the buffer because it uses a
> modifier that's unsupported by the kernel. I think you have an X server
> bug.
>
> --Jason
>
> On Tue, Jul 31, 2018 at 7:54 AM Mario Kleiner
> wrote:
>>
>> At least that's what the Linux 4.18 i915 drm/kms driver
>> thinks, and the disagreement between kms and Mesa leads to
>> pageflipping failure with X-Server 1.20's dmabuf modifiers
>> enabled modesetting-ddx, at least as tested on a gen 7
>> Ivybridge system.
>>
>> Signed-off-by: Mario Kleiner
>> ---
>> src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>> b/src/mesa/drivers/dri/i965/intel_screen.c
>> index cb35741..ef04ffb 100644
>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>> @@ -309,7 +309,7 @@ static const struct {
>> } supported_modifiers[] = {
>> { .modifier = DRM_FORMAT_MOD_LINEAR , .since_gen = 1 },
>> { .modifier = I915_FORMAT_MOD_X_TILED , .since_gen = 1 },
>> - { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 6 },
>> + { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 9 },
>> { .modifier = I915_FORMAT_MOD_Y_TILED_CCS , .since_gen = 9 },
>> };
>>
>> --
>> 2.7.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/fs: Flag all slots of a flat input as flat
This patch is no good. The bug is real but this patch is insufficient.
I've got another one running through CI which I should be posting shortly.
On Tue, Jul 31, 2018 at 6:38 AM Jason Ekstrand wrote:
> Otherwise, only the first vec4 of a matrix or other complex type will
> get marked as flat and we'll interpolate the others. This was caught by
> a dEQP test which started failing because it did a SSO vs. non-SSO
> comparison. Previously, we did the interpolation wrong consistently in
> both versions. However, with one of Tim Arceri's NIR linkingpatches, we
> started splitting the matrix input into vectors at link time in the
> non-SSO version and it started getting correctly interpolated which
> didn't match the broken SSO version. As of this commit, they both get
> correctly interpolated.
>
> Fixes: e61cc87c757f8bc "i965/fs: Add a flat_inputs field to prog_data"
> ---
> src/intel/compiler/brw_fs.cpp | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 7ddbd285fe2..55cd5c6e72a 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -6886,8 +6886,10 @@ brw_compute_flat_inputs(struct brw_wm_prog_data
> *prog_data,
> continue;
>
>/* flat shading */
> - if (var->data.interpolation == INTERP_MODE_FLAT)
> - prog_data->flat_inputs |= (1 << input_index);
> + if (var->data.interpolation == INTERP_MODE_FLAT) {
> + unsigned slots = glsl_count_attribute_slots(var->type, false);
> + prog_data->flat_inputs |= (((1 << slots) - 1) << input_index);
> + }
> }
> }
>
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/screen: MOD_FORMAT_Y_TILED is only supported by gen9+
NAK.
On SNB+, we'd like to get Y-tiling when the surface is only being used by
the compositor and reserve X-tiling for scanout surfaces. With the
modifiers negotiation framework, the X server should be able to figure out
that the window is being composited (or blitted) and request Y-tiling. If
the surface is full-screen, it should know this and either require X-tiling
because that's all KMS advertises or not flip the buffer because it uses a
modifier that's unsupported by the kernel. I think you have an X server
bug.
--Jason
On Tue, Jul 31, 2018 at 7:54 AM Mario Kleiner
wrote:
> At least that's what the Linux 4.18 i915 drm/kms driver
> thinks, and the disagreement between kms and Mesa leads to
> pageflipping failure with X-Server 1.20's dmabuf modifiers
> enabled modesetting-ddx, at least as tested on a gen 7
> Ivybridge system.
>
> Signed-off-by: Mario Kleiner
> ---
> src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index cb35741..ef04ffb 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -309,7 +309,7 @@ static const struct {
> } supported_modifiers[] = {
> { .modifier = DRM_FORMAT_MOD_LINEAR , .since_gen = 1 },
> { .modifier = I915_FORMAT_MOD_X_TILED , .since_gen = 1 },
> - { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 6 },
> + { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 9 },
> { .modifier = I915_FORMAT_MOD_Y_TILED_CCS , .since_gen = 9 },
> };
>
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/screen: MOD_FORMAT_Y_TILED is only supported by gen9+
At least that's what the Linux 4.18 i915 drm/kms driver
thinks, and the disagreement between kms and Mesa leads to
pageflipping failure with X-Server 1.20's dmabuf modifiers
enabled modesetting-ddx, at least as tested on a gen 7
Ivybridge system.
Signed-off-by: Mario Kleiner
---
src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index cb35741..ef04ffb 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -309,7 +309,7 @@ static const struct {
} supported_modifiers[] = {
{ .modifier = DRM_FORMAT_MOD_LINEAR , .since_gen = 1 },
{ .modifier = I915_FORMAT_MOD_X_TILED , .since_gen = 1 },
- { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 6 },
+ { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 9 },
{ .modifier = I915_FORMAT_MOD_Y_TILED_CCS , .since_gen = 9 },
};
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 18.2.0 release plan
On Tue, Jul 31, 2018 at 2:35 PM, Andres Gomez wrote: > Hi Mario, Hi Andres, > > Given the current patches and the talk I had yesterday in IRC with > Daniel and Eric it seems best case scenario is that we could only have > the 3 first patches from: > https://patchwork.freedesktop.org/series/44671/ > I'll take what i can get ;-), thanks! > Landing before branching point. Not the 4/5 and 5/5 nor, it seems: Given that 3/5 is ok, and 229397 is exactly the same mechanism, just applied to the dri3 buffer sharing instead of eglCreateImage, maybe it would be possible to still get that one in? It would finish at least the native X11 side of "Optimus" on nouveau? And make nouveau depth 30 somewhat usable on server 1.20's modesetting ddx. In terms of immediate usefulness for nouveau, that's the favorite patch. If there aren't fundamental problems with that one, but style issues or such, i could send some cleanup patch after the branch-point, if that helps? > https://patchwork.freedesktop.org/patch/229397/ > > I could delay for a bit the branching but it seems like these patches > are going to need some more time so I think I will keep the schedule as > it is. Holding up the schedule is not worth it, i agree. But i'd need to know what is missing with the current patch set, if they need more time? I didn't get any new feedback to the last revision in 1.5 months, and i know it works well on all relevant hardware combos as far as my testing with weston and x11 goes, so if there's something i would need to change, somebody has to tell me. Or is it just lack of independent testing or time for someone to review atm.? There's also this weston branch i used for testing: None of the new deptth 30 patches there have been submitted to wayland ml yet, that would be a tbd. once mesa is done: https://github.com/kleinerm/weston/commits/westonnew10bpc > > Let me know if I can do something else. Actually, another unrelated thing that got stalled on my side the last days, sorry. X-Server 1.20 + modesetting-ddx + dmabuf_modifier support (enabled by default now iirc) causes pageflipping to fail on at least Intel Ivybridge (gen 7 hw), whereas it works with the intel-ddx, and on older (gen 5 ironlake) hardware. There is a disagreement between Mesa's i965 intel dri driver and the Linux i915 kms driver about which hardware gen supports I915_FORMAT_MOD_Y_TILED, causing the kernel to reject the flip. Kernel thinks gen >= 9, Mesa thinks gen >=6. I'll send out a patch now which would fix Mesa on current kernels up to 4.18, but haven't looked if Mesa is wrong or the kms driver is wrong. So this trivial patch would be worthwile to include if this is indeed Mesa in the wrong. thanks, -mario > > Br. > > PS: If you would like to talk directly to me, I hang out at freenode's > IRC as "tanty". You can find me in the #dri-devel room, for example. > > On Thu, 2018-07-26 at 16:42 +0200, Mario Kleiner wrote: >> Hello Andreas, >> >> the improved color depth 30 rendering support for nouveau is imho >> ready for merging since about a month: >> >> https://patchwork.freedesktop.org/project/mesa/patches/?submitter=14956 >> >> The patch series submitted at 2018-06-13, and the single patch >> "loader_dri3: Handle mismatched depth 30 formats for Prime >> renderoffload." from 2018-06-04. >> >> All patches have been successfully tested by myself on various >> permuations of intel/amd/nvidia hardware and prime combo's of >> intel+nvidia, amd+nvidia and nvidia+amd under wayland-weston and x11. >> All review comments have been addressed. >> >> Patch [4/5] egl/wayland: Allow client->server format conversion for >> PRIME offload. (v2) >> and >> Patch [5/5] egl/wayland-drm: Only announce formats via wl_drm which >> the driver supports. >> and >> Patch loader_dri3: Handle mismatched depth 30 formats for Prime >> renderoffload. >> >> still need r-b's, although 4/5 got some review from Eric Engestroem, >> but no r-b tag so far. >> >> The remaining patches should be straightforward to review, and the >> loader_dri3 patch is essentially the same as the already reviewed >> [3/5], just applied to x11+prime instead of x11+eglCreateImage(). >> Cc'ing some people who are somewhat familiar with the patches already. >> >> It would be good to get these merged for 18.2 before some changes in >> Mesa break them again, given that they involve a lot of time intense >> manual and tedious testing on lots of combos whenever i need to touch >> them again. Also, more work to do on the x-server, weston, side, but >> that needs a new baseline in Mesa before it makes sense for me to pile >> on more work. >> >> Thanks, >> -mario >> >> >> >> >> On Wed, Jul 18, 2018 at 12:55 AM, Andres Gomez wrote: >> > Hi all, >> > >> > Here is the tentative release plan for 18.2.0. >> > >> > Although the initial plan was to have the first release candidate by >> > the end of this week, a slip of mind in my side on sending this plan is >> > shifting the current schedule at mesa3d.org. We'll
[Mesa-dev] [PATCH 1/2] i965/fs: Flag all slots of a flat input as flat
Otherwise, only the first vec4 of a matrix or other complex type will
get marked as flat and we'll interpolate the others. This was caught by
a dEQP test which started failing because it did a SSO vs. non-SSO
comparison. Previously, we did the interpolation wrong consistently in
both versions. However, with one of Tim Arceri's NIR linkingpatches, we
started splitting the matrix input into vectors at link time in the
non-SSO version and it started getting correctly interpolated which
didn't match the broken SSO version. As of this commit, they both get
correctly interpolated.
Fixes: e61cc87c757f8bc "i965/fs: Add a flat_inputs field to prog_data"
---
src/intel/compiler/brw_fs.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 7ddbd285fe2..55cd5c6e72a 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -6886,8 +6886,10 @@ brw_compute_flat_inputs(struct brw_wm_prog_data
*prog_data,
continue;
/* flat shading */
- if (var->data.interpolation == INTERP_MODE_FLAT)
- prog_data->flat_inputs |= (1 << input_index);
+ if (var->data.interpolation == INTERP_MODE_FLAT) {
+ unsigned slots = glsl_count_attribute_slots(var->type, false);
+ prog_data->flat_inputs |= (((1 << slots) - 1) << input_index);
+ }
}
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/15] mesa/glspirv: Set last_vert_prog
On 30/07/18 11:23, Neil Roberts wrote: > Timothy Arceri writes: > >>> + >>> + int last_vert_stage = >>> + util_last_bit(prog->data->linked_stages & >>> +(((1 << (MESA_SHADER_GEOMETRY + 1)) - 1) ^ >>> + ((1 << MESA_SHADER_VERTEX) - 1))); >> Isn't this the same as: >> >> int last_vert_stage = >>util_last_bit(prog->data->linked_stages & >> ((1 << (MESA_SHADER_GEOMETRY + 1)) - 1)); >> >> As ((1 << MESA_SHADER_VERTEX) - 1)) == 0 >> >> If you use the above simplification this patch is: >> >> Reviewed-by: Timothy Arceri > This is based on code in link_varyings_and_uniforms which has a loop > over all of the stages from geometry down to vertex to try and find the > last vertex stage. I was trying to mimic this behaviour which is > presumably saying vertex->geometry are the vertex stages and not just > “anything up to and including geometry”. > > I don’t really mind either way whether we include the MESA_SHADER_VERTEX > part or not. I guess the cleanest way could be to add a define for the > mask in shader_enums.h to make it most likely not to break if any more > stages are added. But seeing as there is precedent for having this range > be open-coded in the code I guess we can just leave that to another > patch. Yes, I think that for now is more pragmatic to just go ahead with Timothy's suggestion. I already made the change locally. BR signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/15] compiler/spirv: add XFB and GeometryStreams capability check support
Thanks for the quick review!
Just re-checked no regressions with Intel CI. Pushed the series to master.
On 31/07/18 13:31, Timothy Arceri wrote:
> Reviewed-by: Timothy Arceri
>
> On 31/07/18 21:16, Alejandro Piñeiro wrote:
>> FWIW, this is the only patch pending to be reviewed on the series (sorry
>> Timothy, I used wrong patch numbers when I pinged you on IRC).
>>
>> BR
>>
>>
>> On 20/07/18 17:08, Alejandro Piñeiro wrote:
>>> ---
>>> src/compiler/shader_info.h | 2 ++
>>> src/compiler/spirv/spirv_to_nir.c | 10 --
>>> 2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
>>> index 3b95d5962c0..958e6bb98bf 100644
>>> --- a/src/compiler/shader_info.h
>>> +++ b/src/compiler/shader_info.h
>>> @@ -59,6 +59,8 @@ struct spirv_supported_capabilities {
>>> bool stencil_export;
>>> bool atomic_storage;
>>> bool storage_8bit;
>>> + bool transform_feedback;
>>> + bool geometry_streams;
>>> };
>>> typedef struct shader_info {
>>> diff --git a/src/compiler/spirv/spirv_to_nir.c
>>> b/src/compiler/spirv/spirv_to_nir.c
>>> index 0957efb2aa1..c8b91f068a8 100644
>>> --- a/src/compiler/spirv/spirv_to_nir.c
>>> +++ b/src/compiler/spirv/spirv_to_nir.c
>>> @@ -3424,7 +3424,6 @@ vtn_handle_preamble_instruction(struct
>>> vtn_builder *b, SpvOp opcode,
>>> case SpvCapabilityStorageImageExtendedFormats:
>>> break;
>>> - case SpvCapabilityGeometryStreams:
>>> case SpvCapabilityLinkage:
>>> case SpvCapabilityVector16:
>>> case SpvCapabilityFloat16Buffer:
>>> @@ -3434,7 +3433,6 @@ vtn_handle_preamble_instruction(struct
>>> vtn_builder *b, SpvOp opcode,
>>> case SpvCapabilityInt8:
>>> case SpvCapabilitySparseResidency:
>>> case SpvCapabilityMinLod:
>>> - case SpvCapabilityTransformFeedback:
>>> vtn_warn("Unsupported SPIR-V capability: %s",
>>> spirv_capability_to_string(cap));
>>> break;
>>> @@ -3453,6 +3451,14 @@ vtn_handle_preamble_instruction(struct
>>> vtn_builder *b, SpvOp opcode,
>>> spv_check_supported(int16, cap);
>>> break;
>>> + case SpvCapabilityTransformFeedback:
>>> + spv_check_supported(transform_feedback, cap);
>>> + break;
>>> +
>>> + case SpvCapabilityGeometryStreams:
>>> + spv_check_supported(geometry_streams, cap);
>>> + break;
>>> +
>>> case SpvCapabilityAddresses:
>>> case SpvCapabilityKernel:
>>> case SpvCapabilityImageBasic:
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] intel/nir: Split IO arrays into elements
The NIR nir_lower_io_arrays_to_elements pass attempts to split I/O
variables which are arrays or matrices into a sequence of separate
variables. This can help link-time optimization by allowing us to
remove varyings at a more granular level.
Shader-db results on Kaby Lake:
total instructions in shared programs: 15177645 -> 15168494 (-0.06%)
instructions in affected programs: 79857 -> 70706 (-11.46%)
helped: 392
HURT: 0
---
src/intel/compiler/brw_nir.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 5990427b731..99ef6bec77f 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -709,6 +709,10 @@ void
brw_nir_link_shaders(const struct brw_compiler *compiler,
nir_shader **producer, nir_shader **consumer)
{
+ nir_lower_io_arrays_to_elements(*producer, *consumer);
+ nir_validate_shader(*producer);
+ nir_validate_shader(*consumer);
+
NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/2] intel/nir: Call nir_lower_io_to_scalar_early
Shader-db results on Kaby Lake:
total instructions in shared programs: 15166953 -> 15073611 (-0.62%)
instructions in affected programs: 2390284 -> 2296942 (-3.91%)
helped: 16469
HURT: 505
total loops in shared programs: 4954 -> 4951 (-0.06%)
loops in affected programs: 3 -> 0
helped: 3
HURT: 0
---
src/intel/compiler/brw_nir.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 99ef6bec77f..a6e3e502cdd 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -713,6 +713,18 @@ brw_nir_link_shaders(const struct brw_compiler *compiler,
nir_validate_shader(*producer);
nir_validate_shader(*consumer);
+ const bool p_is_scalar =
+ compiler->scalar_stage[(*producer)->info.stage];
+ const bool c_is_scalar =
+ compiler->scalar_stage[(*producer)->info.stage];
+
+ if (p_is_scalar && c_is_scalar) {
+ NIR_PASS_V(*producer, nir_lower_io_to_scalar_early, nir_var_shader_out);
+ NIR_PASS_V(*consumer, nir_lower_io_to_scalar_early, nir_var_shader_in);
+ *producer = brw_nir_optimize(*producer, compiler, p_is_scalar);
+ *consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar);
+ }
+
NIR_PASS_V(*producer, nir_remove_dead_variables, nir_var_shader_out);
NIR_PASS_V(*consumer, nir_remove_dead_variables, nir_var_shader_in);
@@ -729,12 +741,7 @@ brw_nir_link_shaders(const struct brw_compiler *compiler,
NIR_PASS_V(*consumer, nir_lower_indirect_derefs,
brw_nir_no_indirect_mask(compiler, (*consumer)->info.stage));
- const bool p_is_scalar =
- compiler->scalar_stage[(*producer)->info.stage];
*producer = brw_nir_optimize(*producer, compiler, p_is_scalar);
-
- const bool c_is_scalar =
- compiler->scalar_stage[(*producer)->info.stage];
*consumer = brw_nir_optimize(*consumer, compiler, c_is_scalar);
}
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/15] compiler/spirv: add XFB and GeometryStreams capability check support
Reviewed-by: Timothy Arceri
On 31/07/18 21:16, Alejandro Piñeiro wrote:
FWIW, this is the only patch pending to be reviewed on the series (sorry
Timothy, I used wrong patch numbers when I pinged you on IRC).
BR
On 20/07/18 17:08, Alejandro Piñeiro wrote:
---
src/compiler/shader_info.h| 2 ++
src/compiler/spirv/spirv_to_nir.c | 10 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 3b95d5962c0..958e6bb98bf 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -59,6 +59,8 @@ struct spirv_supported_capabilities {
bool stencil_export;
bool atomic_storage;
bool storage_8bit;
+ bool transform_feedback;
+ bool geometry_streams;
};
typedef struct shader_info {
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index 0957efb2aa1..c8b91f068a8 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3424,7 +3424,6 @@ vtn_handle_preamble_instruction(struct vtn_builder *b,
SpvOp opcode,
case SpvCapabilityStorageImageExtendedFormats:
break;
- case SpvCapabilityGeometryStreams:
case SpvCapabilityLinkage:
case SpvCapabilityVector16:
case SpvCapabilityFloat16Buffer:
@@ -3434,7 +3433,6 @@ vtn_handle_preamble_instruction(struct vtn_builder *b,
SpvOp opcode,
case SpvCapabilityInt8:
case SpvCapabilitySparseResidency:
case SpvCapabilityMinLod:
- case SpvCapabilityTransformFeedback:
vtn_warn("Unsupported SPIR-V capability: %s",
spirv_capability_to_string(cap));
break;
@@ -3453,6 +3451,14 @@ vtn_handle_preamble_instruction(struct vtn_builder *b,
SpvOp opcode,
spv_check_supported(int16, cap);
break;
+ case SpvCapabilityTransformFeedback:
+ spv_check_supported(transform_feedback, cap);
+ break;
+
+ case SpvCapabilityGeometryStreams:
+ spv_check_supported(geometry_streams, cap);
+ break;
+
case SpvCapabilityAddresses:
case SpvCapabilityKernel:
case SpvCapabilityImageBasic:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 18.2.0 release plan
Hi Mario, Given the current patches and the talk I had yesterday in IRC with Daniel and Eric it seems best case scenario is that we could only have the 3 first patches from: https://patchwork.freedesktop.org/series/44671/ Landing before branching point. Not the 4/5 and 5/5 nor, it seems: https://patchwork.freedesktop.org/patch/229397/ I could delay for a bit the branching but it seems like these patches are going to need some more time so I think I will keep the schedule as it is. Let me know if I can do something else. Br. PS: If you would like to talk directly to me, I hang out at freenode's IRC as "tanty". You can find me in the #dri-devel room, for example. On Thu, 2018-07-26 at 16:42 +0200, Mario Kleiner wrote: > Hello Andreas, > > the improved color depth 30 rendering support for nouveau is imho > ready for merging since about a month: > > https://patchwork.freedesktop.org/project/mesa/patches/?submitter=14956 > > The patch series submitted at 2018-06-13, and the single patch > "loader_dri3: Handle mismatched depth 30 formats for Prime > renderoffload." from 2018-06-04. > > All patches have been successfully tested by myself on various > permuations of intel/amd/nvidia hardware and prime combo's of > intel+nvidia, amd+nvidia and nvidia+amd under wayland-weston and x11. > All review comments have been addressed. > > Patch [4/5] egl/wayland: Allow client->server format conversion for > PRIME offload. (v2) > and > Patch [5/5] egl/wayland-drm: Only announce formats via wl_drm which > the driver supports. > and > Patch loader_dri3: Handle mismatched depth 30 formats for Prime renderoffload. > > still need r-b's, although 4/5 got some review from Eric Engestroem, > but no r-b tag so far. > > The remaining patches should be straightforward to review, and the > loader_dri3 patch is essentially the same as the already reviewed > [3/5], just applied to x11+prime instead of x11+eglCreateImage(). > Cc'ing some people who are somewhat familiar with the patches already. > > It would be good to get these merged for 18.2 before some changes in > Mesa break them again, given that they involve a lot of time intense > manual and tedious testing on lots of combos whenever i need to touch > them again. Also, more work to do on the x-server, weston, side, but > that needs a new baseline in Mesa before it makes sense for me to pile > on more work. > > Thanks, > -mario > > > > > On Wed, Jul 18, 2018 at 12:55 AM, Andres Gomez wrote: > > Hi all, > > > > Here is the tentative release plan for 18.2.0. > > > > Although the initial plan was to have the first release candidate by > > the end of this week, a slip of mind in my side on sending this plan is > > shifting the current schedule at mesa3d.org. We'll update the release > > schedule there soon. > > > > Aug 01 2018 - Feature freeze/Release candidate 1 > > Aug 08 2018 - Release candidate 2 > > Aug 15 2018 - Release candidate 3 > > Aug 22 2018 - Release candidate 4/final release > > > > This gives us approximately two weeks until the branch point. > > > > Note: In the spririt of keeping things clearer and more transparent, we > > will be keeping track of any features planned for the release in > > Bugzilla [1]. > > > > Do add a separate "Depends on" for each work you have planned. > > Alternatively you can reply to this email and I'll add them for you. > > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=106156 > > > > -- > > Br, > > > > Andres > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- Br, Andres ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/7] egl, i965: Implement EGL_KHR_mutable_render_buffer
Hi;
Maybe something went wrong since patches 4,6 are missing from this series?
Functionally at least propagating mutableRenderBuffer boolean from
driver to driCreateConfigs is missing.
// Tapani
On 07/31/2018 08:00 AM, Chad Versace wrote:
Despite the KHR, Android is the only OS that uses this extension, as far
as I know. Essentially, it allows the app to toggle
front-buffer/back-buffer rendering using EGL.
Android requires this extension if the device advertises support for
virtual reality. No Chrome OS device yet supports Android's VR software
requirements, though, and VR is not why I implemented this.
This extension enables handwriting and drawing apps on Chrome and
Android devices to achieve very low latency between touch input
and display response.
Please don't bash me for this oddly-specified Android extension.
I didn't create it. I'm just writing the code that Android requires.
* Patch 3 defines a pair of new DRI extensions,
DRI_MutableRenderBuffer{Driver,Loader}.
* Patches 1-5 add the generic code for the DRI and EGL extensions.
* Patch 6 implements DRI_MutableRenderBufferLoader for Android EGL.
* Patch 7 implements DRI_MutableRenderBufferDriver for i965.
This series is tagged at:
http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=refs/tags/chadv/review/i965-mutable-render-buffer-v01
Chad Versace (7):
egl: Simplify queries for EGL_RENDER_BUFFER
egl/dri2: In dri2_make_current, return early on failure
dri: Define DRI_MutableRenderBuffer extensions
dri: Add param driCreateConfigs(mutable_render_buffer)
egl/main: Add bits for EGL_KHR_mutable_render_buffer
egl/android: Implement EGL_KHR_mutable_render_buffer
i965: Implement EGL_KHR_mutable_render_buffer
include/GL/internal/dri_interface.h | 138 +-
src/egl/drivers/dri2/egl_dri2.c | 71 +---
src/egl/drivers/dri2/egl_dri2.h | 7 +
src/egl/drivers/dri2/platform_android.c | 168 +-
src/egl/main/eglapi.c | 1 +
src/egl/main/eglconfig.c | 3 +
src/egl/main/eglcontext.c | 40 -
src/egl/main/eglcontext.h | 3 -
src/egl/main/egldisplay.h | 1 +
src/egl/main/eglsurface.c | 81 -
src/egl/main/eglsurface.h | 59 +-
src/gallium/state_trackers/dri/dri_screen.c | 4 +-
src/mesa/drivers/dri/common/dri_util.c| 2 +
src/mesa/drivers/dri/common/dri_util.h| 4 +
src/mesa/drivers/dri/common/utils.c | 10 +-
src/mesa/drivers/dri/common/utils.h | 3 +-
src/mesa/drivers/dri/i915/intel_screen.c | 4 +-
src/mesa/drivers/dri/i965/brw_context.c | 86 -
src/mesa/drivers/dri/i965/brw_context.h | 12 ++
src/mesa/drivers/dri/i965/intel_screen.c | 17 +-
src/mesa/drivers/dri/nouveau/nouveau_screen.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_screen.c | 2 +-
src/mesa/drivers/dri/swrast/swrast.c | 2 +-
src/mesa/main/mtypes.h| 3 +
24 files changed, 664 insertions(+), 59 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/8] nir: evaluate if condition uses inside the if branches
On 31/07/18 13:50, Dieter Nützel wrote: Am 30.07.2018 05:24, schrieb Dieter Nützel: For the series Tested-by: Dieter Nützel with glmark2, glxgears, UH, UV, Blender 2.79 and FreeCAD 0.17 on RX 580. With UH I saw some small light blue triangles spreading around. Have to bisect which patch set was the culprit. (If I have some time.) Tried your's above configure-bump-libdrm-for-AMDGPU-to-2.4.92.mbox (Samuel) ASTC-texture-compression-for-all-Gallium-drivers.mbox (Marek) Dieter It has something to do with tessellation. If I disable it (F3) all small light blue triangles are _gone_. Are you able to bisect? Regards, Dieter Am 28.07.2018 03:07, schrieb Timothy Arceri: On 28/07/18 11:06, Timothy Arceri wrote: Since we know what side of the branch we ended up on we can just replace the use with a constant. All the spill changes in shader-db are from Dolphin uber shaders, despite some small regressions the change is clearly positive. V2: insert new constant after any phis in the use->parent_instr->type == nir_instr_type_phi path. Meh this was meant to be V3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://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 Bug 77449 depends on bug 80018, which changed state. Bug 80018 Summary: [HSW] Ambient occlusion glitch in Planetary Annihilation on Intel HD4600 https://bugs.freedesktop.org/show_bug.cgi?id=80018 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver
On 2018-07-31 10:03 AM, Yu, Qiang wrote: > > Seems the mesa driconf infrastructure is just what I need: > https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ > > So I can reference the loader_get_dri_config_device_id implementation > for adding loader driver override functionality in /etc/drirc: > > > > > > > Thoughts? Using the driconf infrastructure is definitely better than creating a new mechanism. It'll even allow configuring the driver per application. :) Grepping for device_id in src/util/xmlpool/t_options.h and src/loader/loader.c might be useful. Here's an example of how I imagine general and per-application driver configuration could work: -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] virgl: add initial images support (v2)
Looks good, Patches 1-3
Reviwed-by: Gert Wollny
Am Dienstag, den 31.07.2018, 04:47 +1000 schrieb Dave Airlie:
> From: Dave Airlie
>
> v2: add max image samples support
> ---
> src/gallium/drivers/virgl/virgl_context.c | 44
> ++
> src/gallium/drivers/virgl/virgl_context.h | 1 +
> src/gallium/drivers/virgl/virgl_encode.c | 29
> src/gallium/drivers/virgl/virgl_encode.h | 4 +++
> src/gallium/drivers/virgl/virgl_hw.h | 3 ++
> src/gallium/drivers/virgl/virgl_protocol.h | 12
> src/gallium/drivers/virgl/virgl_screen.c | 11
> src/gallium/drivers/virgl/virgl_winsys.h | 1 +
> 8 files changed, 105 insertions(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c
> b/src/gallium/drivers/virgl/virgl_context.c
> index 74b232fe6cf..41ba853805b 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -182,6 +182,20 @@ static void
> virgl_attach_res_shader_buffers(struct virgl_context *vctx,
> }
> }
>
> +static void virgl_attach_res_shader_images(struct virgl_context
> *vctx,
> + enum pipe_shader_type
> shader_type)
> +{
> + struct virgl_winsys *vws = virgl_screen(vctx->base.screen)->vws;
> + struct virgl_resource *res;
> + unsigned i;
> + for (i = 0; i < PIPE_MAX_SHADER_IMAGES; i++) {
> + res = virgl_resource(vctx->images[shader_type][i]);
> + if (res) {
> + vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
> + }
> + }
> +}
> +
> /*
> * after flushing, the hw context still has a bunch of
> * resources bound, so we need to rebind those here.
> @@ -198,6 +212,7 @@ static void virgl_reemit_res(struct virgl_context
> *vctx)
>virgl_attach_res_sampler_views(vctx, shader_type);
>virgl_attach_res_uniform_buffers(vctx, shader_type);
>virgl_attach_res_shader_buffers(vctx, shader_type);
> + virgl_attach_res_shader_images(vctx, shader_type);
> }
> virgl_attach_res_vertex_buffers(vctx);
> virgl_attach_res_so_targets(vctx);
> @@ -954,6 +969,34 @@ static void virgl_set_shader_buffers(struct
> pipe_context *ctx,
> virgl_encode_set_shader_buffers(vctx, shader, start_slot, count,
> buffers);
> }
>
> +static void virgl_set_shader_images(struct pipe_context *ctx,
> +enum pipe_shader_type shader,
> +unsigned start_slot, unsigned
> count,
> +const struct pipe_image_view
> *images)
> +{
> + struct virgl_context *vctx = virgl_context(ctx);
> + struct virgl_screen *rs = virgl_screen(ctx->screen);
> +
> + for (unsigned i = 0; i < count; i++) {
> + unsigned idx = start_slot + i;
> +
> + if (images) {
> + if (images[i].resource) {
> +pipe_resource_reference(>images[shader][idx],
> images[i].resource);
> +continue;
> + }
> + }
> + pipe_resource_reference(>images[shader][idx], NULL);
> + }
> +
> + uint32_t max_shader_images = shader == PIPE_SHADER_FRAGMENT ?
> + rs->caps.caps.v2.max_shader_image_frag_compute :
> + rs->caps.caps.v2.max_shader_image_other_stages;
> + if (!max_shader_images)
> + return;
> + virgl_encode_set_shader_images(vctx, shader, start_slot, count,
> images);
> +}
> +
> static void
> virgl_context_destroy( struct pipe_context *ctx )
> {
> @@ -1092,6 +1135,7 @@ struct pipe_context
> *virgl_context_create(struct pipe_screen *pscreen,
> vctx->base.blit = virgl_blit;
>
> vctx->base.set_shader_buffers = virgl_set_shader_buffers;
> + vctx->base.set_shader_images = virgl_set_shader_images;
> virgl_init_context_resource_functions(>base);
> virgl_init_query_functions(vctx);
> virgl_init_so_functions(vctx);
> diff --git a/src/gallium/drivers/virgl/virgl_context.h
> b/src/gallium/drivers/virgl/virgl_context.h
> index 5747654ea82..38d1f450e17 100644
> --- a/src/gallium/drivers/virgl/virgl_context.h
> +++ b/src/gallium/drivers/virgl/virgl_context.h
> @@ -70,6 +70,7 @@ struct virgl_context {
> struct pipe_resource
> *ubos[PIPE_SHADER_TYPES][PIPE_MAX_CONSTANT_BUFFERS];
>
> struct pipe_resource
> *ssbos[PIPE_SHADER_TYPES][PIPE_MAX_SHADER_BUFFERS];
> + struct pipe_resource
> *images[PIPE_SHADER_TYPES][PIPE_MAX_SHADER_BUFFERS];
> int num_transfers;
> int num_draws;
> struct list_head to_flush_bufs;
> diff --git a/src/gallium/drivers/virgl/virgl_encode.c
> b/src/gallium/drivers/virgl/virgl_encode.c
> index b09366dcee6..88eebcbaa63 100644
> --- a/src/gallium/drivers/virgl/virgl_encode.c
> +++ b/src/gallium/drivers/virgl/virgl_encode.c
> @@ -943,3 +943,32 @@ int virgl_encode_set_shader_buffers(struct
> virgl_context *ctx,
> }
> return 0;
> }
> +
> +int virgl_encode_set_shader_images(struct virgl_context *ctx,
> + enum pipe_shader_type shader,
> +
Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver
Seems the mesa driconf infrastructure is just what I need: https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ So I can reference the loader_get_dri_config_device_id implementation for adding loader driver override functionality in /etc/drirc: Thoughts? Thanks, Qiang From: mesa-dev on behalf of Yu, Qiang Sent: Tuesday, July 31, 2018 9:51:09 AM To: mesa-dev@lists.freedesktop.org Cc: Emil Velikov Subject: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver Hi guys, As previously talked in: https://lists.freedesktop.org/archives/mesa-dev/2017-April/152055.html amdgpu-pro driver has interest to adopt the DRI interface to be compatable with the mesa libgbm. But using MESA_LOADER_DRIVER_OVERRIDE is not a good way to config OS GFX stack globally, so I'd like to introduce a /etc/driconf.d/xxx.conf config file to select/overwrite the dri driver like this: : i.e amdgpu-pro case /etc/driconf.d/amdgpu.conf amdgpu:amdgpu Any feedback on this? Thanks, Qiang ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: fix get_image_coords() for radeonsi
On Fri, Jul 27, 2018 at 11:40 AM, Timothy Arceri wrote:
>
>
> On 27/07/18 19:10, Bas Nieuwenhuizen wrote:
>>
>> On Fri, Jul 27, 2018 at 7:32 AM, Timothy Arceri
>> wrote:
>>>
>>> Because this was setting image to true we would end up calling
>>> si_load_image_desc() when we sould be calling
>>> si_load_sampler_desc().
>>
>>
>> Since the descriptor is part of an image, not a sampler,
>> get_image_descriptor looks like the right thing to me?
>>
>> What assertion are you getting?
>
>
> LLVMValueRef si_load_image_desc(struct si_shader_context *ctx,
> LLVMValueRef list, LLVMValueRef index,
> enum ac_descriptor_type desc_type, bool
> dcc_off)
> {
> LLVMBuilderRef builder = ctx->ac.builder;
> LLVMValueRef rsrc;
>
> if (desc_type == AC_DESC_BUFFER) {
> index = LLVMBuildMul(builder, index,
> LLVMConstInt(ctx->i32, 2, 0), "");
> index = LLVMBuildAdd(builder, index,
> ctx->i32_1, "");
> list = LLVMBuildPointerCast(builder, list,
>
> ac_array_in_const32_addr_space(ctx->v4i32), "");
> } else {
> assert(desc_type == AC_DESC_IMAGE);
> }
>
> rsrc = ac_build_load_to_sgpr(>ac, list, index);
> if (desc_type == AC_DESC_IMAGE && dcc_off)
> rsrc = force_dcc_off(ctx, rsrc);
> return rsrc;
> }
>
> vs
>
> LLVMValueRef si_load_sampler_desc(struct si_shader_context *ctx,
> LLVMValueRef list, LLVMValueRef index,
> enum ac_descriptor_type type)
> {
> LLVMBuilderRef builder = ctx->ac.builder;
>
> switch (type) {
> case AC_DESC_IMAGE:
> /* The image is at [0:7]. */
> index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
> 2, 0), "");
> break;
> case AC_DESC_BUFFER:
> /* The buffer is in [4:7]. */
> index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
> 4, 0), "");
> index = LLVMBuildAdd(builder, index, ctx->i32_1, "");
> list = LLVMBuildPointerCast(builder, list,
>
> ac_array_in_const32_addr_space(ctx->v4i32), "");
> break;
> case AC_DESC_FMASK:
> /* The FMASK is at [8:15]. */
> index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
> 2, 0), "");
> index = LLVMBuildAdd(builder, index, ctx->i32_1, "");
> break;
> case AC_DESC_SAMPLER:
> /* The sampler state is at [12:15]. */
> index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32,
> 4, 0), "");
> index = LLVMBuildAdd(builder, index, LLVMConstInt(ctx->i32,
> 3, 0), "");
> list = LLVMBuildPointerCast(builder, list,
>
> ac_array_in_const32_addr_space(ctx->v4i32), "");
> break;
> }
>
> return ac_build_load_to_sgpr(>ac, list, index);
>
> }
I think we should fix the image path to get an fmask descriptor
though. If you look one level up the bounding of dynamic indices is
different for textures and images:
static LLVMValueRef
si_nir_load_sampler_desc(struct ac_shader_abi *abi,
unsigned descriptor_set, unsigned base_index,
unsigned constant_index, LLVMValueRef dynamic_index,
enum ac_descriptor_type desc_type, bool image,
bool write, bool bindless)
{
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
LLVMBuilderRef builder = ctx->ac.builder;
LLVMValueRef list = LLVMGetParam(ctx->main_fn,
ctx->param_samplers_and_images);
LLVMValueRef index;
assert(!descriptor_set);
dynamic_index = dynamic_index ? dynamic_index : ctx->ac.i32_0;
index = LLVMBuildAdd(builder, dynamic_index,
LLVMConstInt(ctx->ac.i32, base_index + constant_index, false),
"");
if (image) {
assert(desc_type == AC_DESC_IMAGE || desc_type == AC_DESC_BUFFER);
assert(base_index + constant_index < ctx->num_images);
if (dynamic_index)
index = si_llvm_bound_index(ctx, index, ctx->num_images);
index = LLVMBuildSub(ctx->ac.builder,
LLVMConstInt(ctx->i32, SI_NUM_IMAGES - 1, 0),
index, "");
/* TODO: be smarter about when we use dcc_off */
return si_load_image_desc(ctx, list, index, desc_type, write);
}
assert(base_index + constant_index < ctx->num_samplers);
if (dynamic_index)
index = si_llvm_bound_index(ctx, index, ctx->num_samplers);
index = LLVMBuildAdd(ctx->ac.builder, index,
LLVMConstInt(ctx->i32, SI_NUM_IMAGES / 2, 0), "");
return si_load_sampler_desc(ctx, list, index, desc_type);
}
>>
>>
>>>
>>> This fixes an assert() in Deus Ex: MD
>>> ---
>>>
Re: [Mesa-dev] i915/swrast vertex array regression
Hi Ville,
> I noticed a while back that xonotic had started to misrender the gun
> models on i915. Yesterday I bisected it down to commit 64d2a2048054
> ("mesa: Make gl_vertex_array contain pointers to first order VAO
> members."). Actually that commit broke things even worse (and the
> game would even crash after a while), but a later commit (presumably
> 98f35ad63c23 ("vbo: Correctly handle source arrays in vbo_split_copy.")
> fixed things a little bit. But even with current master the guns are
> still being misrendered. I also verified that the same breakage was
> visible with swrast, whereas llvmpipe and i965 seemed ok.
>
> To reproduce you can run 'xonotic-glx -benchmark demos/the-big-keybench.dem'
> and wait until the guy picks up the mortar (I think that's what its
> called) which is maybe the third gun he picks up in that demo. The gun
> is supposed to have some red color on it but now it has green.
I tried to reproduce that problem using classic swrast.
Some variants of last weeks git master show the exact same
pictures than swrast using the last good commit from your bisect.
So, basically I can't reproduce the problem here.
The xonotic version I used is 0.8,2 which is the one delivered
with fedora 28.
Can you provide some more detail?
Lets start with your version of xonotic you use.
best and thanks
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
