[Mesa-dev] [PATCH] st/glsl_to_nir: fix next_stage gathering

[Timothy Arceri]

ffs() just returns the bit that is set, we need to know what
stage that bit represents so use u_bit_scan() instead.

Fixes: 2ca5d9548fc4 ("st/glsl_to_nir: gather next_stage in shader_info")
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 24776f7f9c4..18d5d308900 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -373,7 +373,7 @@ st_glsl_to_nir(struct st_context *st, struct gl_program 
*prog,
  ~prev_stages & shader_program->data->linked_stages;
 
   nir->info.next_stage = stages_mask ?
- (gl_shader_stage) ffs(stages_mask) : MESA_SHADER_FRAGMENT;
+ (gl_shader_stage) u_bit_scan(_mask) : MESA_SHADER_FRAGMENT;
} else {
   nir->info.next_stage = MESA_SHADER_FRAGMENT;
}
-- 
2.17.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel/compiler: Change src1 reg type to unsigned doubleword

[Sagar Ghuge]

To have uniform behavior while disassembling send(c) instruction use
register type of unsigned doubleword for src1 when message descriptor is
immediate value. Bspec does not specifiy anything for src1 immediate
default type.

Signed-off-by: Sagar Ghuge 
---
 src/intel/compiler/brw_eu_emit.c| 2 +-
 src/intel/compiler/brw_fs_generator.cpp | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 0cbc682ebc..4630b83b1a 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -371,7 +371,7 @@ brw_set_desc_ex(struct brw_codegen *p, brw_inst *inst,
assert(brw_inst_opcode(devinfo, inst) == BRW_OPCODE_SEND ||
   brw_inst_opcode(devinfo, inst) == BRW_OPCODE_SENDC);
brw_inst_set_src1_file_type(devinfo, inst,
-   BRW_IMMEDIATE_VALUE, BRW_REGISTER_TYPE_D);
+   BRW_IMMEDIATE_VALUE, BRW_REGISTER_TYPE_UD);
brw_inst_set_send_desc(devinfo, inst, desc);
if (devinfo->gen >= 9)
   brw_inst_set_send_ex_desc(devinfo, inst, ex_desc);
diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index cb402cd4e7..08dd83dded 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -630,7 +630,7 @@ fs_generator::generate_urb_write(fs_inst *inst, struct 
brw_reg payload)
 
brw_set_dest(p, insn, brw_null_reg());
brw_set_src0(p, insn, payload);
-   brw_set_src1(p, insn, brw_imm_d(0));
+   brw_set_src1(p, insn, brw_imm_ud(0u));
 
brw_inst_set_sfid(p->devinfo, insn, BRW_SFID_URB);
brw_inst_set_urb_opcode(p->devinfo, insn, GEN8_URB_OPCODE_SIMD8_WRITE);
@@ -659,7 +659,7 @@ fs_generator::generate_cs_terminate(fs_inst *inst, struct 
brw_reg payload)
 
brw_set_dest(p, insn, retype(brw_null_reg(), BRW_REGISTER_TYPE_UW));
brw_set_src0(p, insn, retype(payload, BRW_REGISTER_TYPE_UW));
-   brw_set_src1(p, insn, brw_imm_d(0));
+   brw_set_src1(p, insn, brw_imm_ud(0u));
 
/* Terminate a compute shader by sending a message to the thread spawner.
 */
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107457] [Tracker] Mesa 18.2 release tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107457
Bug 107457 depends on bug 107510, which changed state.

Bug 107510 Summary: [GEN8+] up to 10% perf drop on several 3D benchmarks
https://bugs.freedesktop.org/show_bug.cgi?id=107510

   What|Removed |Added

 Status|VERIFIED|REOPENED
 Resolution|FIXED   |---

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] ac: Introduce ac_build_expand()

[Bas Nieuwenhuizen]

On Fri, Oct 19, 2018 at 11:09 PM Marek Olšák  wrote:
>
> On Thu, Oct 18, 2018 at 10:13 AM Connor Abbott  wrote:
>>
>> And implement ac_bulid_expand_to_vec4() on top of it.
>>
>> Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for 16bit 
>> buffer loads")
>> ---
>>  src/amd/common/ac_llvm_build.c | 40 ++
>>  src/amd/common/ac_llvm_build.h |  3 +++
>>  2 files changed, 29 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
>> index 2d78ca1b52a..c54a50dcd86 100644
>> --- a/src/amd/common/ac_llvm_build.c
>> +++ b/src/amd/common/ac_llvm_build.c
>> @@ -523,39 +523,51 @@ ac_build_gather_values(struct ac_llvm_context *ctx,
>> return ac_build_gather_values_extended(ctx, values, value_count, 1, 
>> false, false);
>>  }
>>
>> -/* Expand a scalar or vector to <4 x type> by filling the remaining channels
>> - * with undef. Extract at most num_channels components from the input.
>> +/* Expand a scalar or vector to  by filling the 
>> remaining
>> + * channels with undef. Extract at most src_channels components from the 
>> input.
>>   */
>> -LLVMValueRef ac_build_expand_to_vec4(struct ac_llvm_context *ctx,
>> -LLVMValueRef value,
>> -unsigned num_channels)
>> +LLVMValueRef ac_build_expand(struct ac_llvm_context *ctx,
>> +LLVMValueRef value,
>> +unsigned src_channels,
>> +unsigned dst_channels)
>>  {
>> LLVMTypeRef elemtype;
>> -   LLVMValueRef chan[4];
>> +   LLVMValueRef chan[dst_channels];
>
>
> That doesn't look like a valid syntax. dst_channel is not a compile-time 
> constant. What was wrong with 4?

Isn't that just c99 variable length arrays?

Reviewed-by: Bas Nieuwenhuizen 

for the series.
>
> Other than that, this patch is:
>
> Reviewed-by: Marek Olšák 
>
> Marek
>
> ___
> 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] st/mesa: Record shader access qualifiers for images

[Marek Olšák]

On Mon, Oct 15, 2018 at 6:35 PM Kenneth Graunke 
wrote:

> From: Jason Ekstrand 
>
> They're not required to be the same as the access flag on the image
> unit.  For hardware that does shader image lowering based on the
> qualifier (Intel), it may be required for state setup.
> ---
>  src/gallium/include/pipe/p_state.h |  1 +
>  src/mesa/state_tracker/st_atom_image.c | 27 ++
>  src/mesa/state_tracker/st_cb_texture.c |  2 +-
>  src/mesa/state_tracker/st_texture.c|  2 +-
>  src/mesa/state_tracker/st_texture.h|  5 +++--
>  5 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index a58d91fb3dd..331417b1d7f 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -485,6 +485,7 @@ struct pipe_image_view
> struct pipe_resource *resource; /**< resource into which this is a
> view  */
> enum pipe_format format;  /**< typed PIPE_FORMAT_x */
> unsigned access;  /**< PIPE_IMAGE_ACCESS_x */
> +   unsigned shader_access;   /**< PIPE_IMAGE_ACCESS_x */
>

Can you use uint16_t for both access masks? Other than that:

Reviewed-by: Marek Olšák 

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] nir/drawpix: add missing samplers for draw pixel lowering.

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Sun, Oct 14, 2018 at 8:48 PM Dave Airlie  wrote:

> From: Dave Airlie 
>
> The drawpixel lowering references undeclared samplers, but also
> missing a texture handle.
> ---
>  src/compiler/nir/nir_lower_drawpixels.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/src/compiler/nir/nir_lower_drawpixels.c
> b/src/compiler/nir/nir_lower_drawpixels.c
> index 462b9c308b2..3e86cc08470 100644
> --- a/src/compiler/nir/nir_lower_drawpixels.c
> +++ b/src/compiler/nir/nir_lower_drawpixels.c
> @@ -66,6 +66,24 @@ get_texcoord(lower_drawpixels_state *state)
> return nir_load_var(>b, state->texcoord);
>  }
>
> +static void
> +add_samplers(lower_drawpixels_state *state)
> +{
> +   nir_variable *sampler = nir_variable_create(state->shader,
> +   nir_var_uniform,
> +
>  glsl_sampler_type(GLSL_SAMPLER_DIM_2D, false, false, GLSL_TYPE_FLOAT),
> +   "s_drawpix");
> +   sampler->data.location = state->options->drawpix_sampler;
> +
> +   if (state->options->pixel_maps) {
> +  nir_variable *sampler = nir_variable_create(state->shader,
> +  nir_var_uniform,
> +
> glsl_sampler_type(GLSL_SAMPLER_DIM_2D, false, false, GLSL_TYPE_FLOAT),
> +  "s_pixelmap");
> +  sampler->data.location = state->options->pixelmap_sampler;
> +   }
> +}
> +
>  static nir_variable *
>  create_uniform(nir_shader *shader, const char *name,
> const gl_state_index16 state_tokens[STATE_LENGTH])
> @@ -123,6 +141,7 @@ lower_color(lower_drawpixels_state *state,
> nir_intrinsic_instr *intr)
>
> b->cursor = nir_before_instr(>instr);
>
> +   add_samplers(state);
> texcoord = get_texcoord(state);
>
> /* replace load_var(gl_Color) w/ texture sample:
> @@ -175,6 +194,7 @@ lower_color(lower_drawpixels_state *state,
> nir_intrinsic_instr *intr)
>tex->sampler_dim = GLSL_SAMPLER_DIM_2D;
>tex->coord_components = 2;
>tex->sampler_index = state->options->pixelmap_sampler;
> +  tex->texture_index = state->options->pixelmap_sampler;
>tex->dest_type = nir_type_float;
>tex->src[0].src_type = nir_tex_src_coord;
>tex->src[0].src = nir_src_for_ssa(nir_channels(b, def, 0xc));
> --
> 2.17.2
>
> ___
> 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] scons: Remove gles option.

[Jose Fonseca]

> Jose, does it make more sense to just make gles on windows an error 
in meson?



I don't mind if there are options for other things, but the default for 
the unsuspicious user should be to create a single self-contained 
opengl32.dll, as that is what's generally most useful (it can be used 
with unmodified windows applications by putting on the same dir.)



Jose



*From:* Dylan Baker 
*Sent:* Friday, October 19, 2018 18:04
*To:* mesa-dev@lists.freedesktop.org; Brian Paul; Jose Fonseca; Liviu 
Prodea; Roland Scheidegger

*Subject:* Re: [Mesa-dev] [PATCH] scons: Remove gles option.
That's not quite right. GLES needs shared glapi, but shared glapi 
doesn't need
gles. meson and autoconf have separate toggles for shared-glapi and 
gles, they

both happen to default to "on" currently.

If you want to uses GLES with mesa on Windows your best bet is probably 
to use
ARB_ES_compatibility (replace  with 1, 2, 3, 3_1, or 3_2 as 
needed) from a

GL Core Context like you would using the Nvidia or Intel driver on windows.
Don't try to go down the EGL on windows madness that the proprietary AMD 
driver

requires.

Meson will likely continue to support shared glapi on windows because every
other platform that mesa supports needs shared-glapi. I have in my 
latest spin
default gles off on windows with meson. Jose, does it make more sense to 
just

make gles on windows an error in meson?

Dylan

Quoting Liviu Prodea (2018-10-19 08:04:28)
>
>
>
> I think I found autotools build equivalent for gles=y. It is 
--enable-shared-glapi. And the docs say it is needed to support 
applications that mix OpenGL and OpenGL ES:

>
> https://www.mesa3d.org/egl.html
>
> 
-

>
>
> On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul 
 wrote:

>
>
>
>
>
> Reviewed-by: Brian Paul 
>
> On 10/19/2018 06:33 AM, Jose Fonseca wrote:
> > It's broken, and WGL state tracker is always built with GLES support
> > noawadays.
> > ---
> >  common.py | 2 --
> >  src/SConscript                              | 7 ---
> >  src/gallium/state_trackers/osmesa/SConscript | 4 +---
> >  src/gallium/state_trackers/wgl/SConscript | 4 +---
> >  src/gallium/targets/libgl-gdi/SConscript    | 6 --
> >  src/gallium/targets/libgl-xlib/SConscript | 6 --
> >  src/mapi/glapi/SConscript | 6 +-
> >  src/mapi/shared-glapi/SConscript            | 9 +
> >  src/mesa/SConscript | 4 +---
> >  src/mesa/drivers/osmesa/SConscript          | 4 +---
> >  10 files changed, 6 insertions(+), 46 deletions(-)
> >
> > diff --git a/common.py b/common.py
> > index 113fc7f5c12..f4f2bb44c1c 100644
> > --- a/common.py
> > +++ b/common.py
> > @@ -99,8 +99,6 @@ def AddOptions(opts):
> >                          'enable static code analysis where 
available', 'no'))

> >      opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
> >      opts.Add('toolchain', 'compiler toolchain', default_toolchain)
> > -    opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES 
support',

> > -                        'no'))
> >      opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
> >      opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with 
openmp (swrast)',

> >                          'no'))
> > diff --git a/src/SConscript b/src/SConscript
> > index 95ea061c4bb..54350a9cdcc 100644
> > --- a/src/SConscript
> > +++ b/src/SConscript
> > @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
> >  if env['platform'] != 'windows':
> >      SConscript('loader/SConscript')
> >
> > -# When env['gles'] is set, the targets defined in 
mapi/glapi/SConscript are not
> > -# used.  libgl-xlib and libgl-gdi adapt themselves to use the 
targets defined
> > -# in mapi/glapi-shared/SConscript. mesa/SConscript also adapts 
itself to

> > -# enable OpenGL ES support.
> >  SConscript('mapi/glapi/gen/SConscript')
> >  SConscript('mapi/glapi/SConscript')
> >
> > @@ -61,8 +57,5 @@ if not env['embedded']:
> >      if env['platform'] == 'haiku':
> >          SConscript('egl/SConscript')
> >
> > -    if env['gles']:
> > - SConscript('mapi/shared-glapi/SConscript')
> > -
> >  SConscript('gallium/SConscript')
> >
> > diff --git a/src/gallium/state_trackers/osmesa/SConscript 
b/src/gallium/state_trackers/osmesa/SConscript

> > index f5519f13762..be67d0fe739 100644
> > --- a/src/gallium/state_trackers/osmesa/SConscript
> > +++ b/src/gallium/state_trackers/osmesa/SConscript
> > @@ -14,10 +14,8 @@ if env['platform'] == 'windows':
> >      env.AppendUnique(CPPDEFINES = [
> >          'BUILD_GL32', # declare gl* as __declspec(dllexport) in 
Mesa headers
> >          'WIN32_LEAN_AND_MEAN', # 
http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx 

> > +        '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being 
declared 

Re: [Mesa-dev] [PATCH 2/3] ac: Fix loading a dvec3 from an SSBO

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Thu, Oct 18, 2018 at 10:13 AM Connor Abbott  wrote:

> The comment was wrong, since the loop above casts to a type with the
> correct bitsize already.
>
> Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for
> 16bit buffer loads")
> ---
>  src/amd/common/ac_nir_to_llvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 402cf2d6655..ee75e2890dd 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1685,8 +1685,8 @@ static LLVMValueRef visit_load_buffer(struct
> ac_nir_context *ctx,
> };
>
> if (num_bytes > 16 && num_components == 3) {
> -   /* we end up with a v4f32 and v2f32 but shuffle
> fails on that */
> -   results[1] = ac_build_expand_to_vec4(>ac,
> results[1], 2);
> +   /* we end up with a v2i64 and i64 but shuffle
> fails on that */
> +   results[1] = ac_build_expand(>ac, results[1],
> 1, 2);
> }
>
> LLVMValueRef swizzle = LLVMConstVector(masks,
> num_components);
> --
> 2.17.2
>
> ___
> 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/3] ac: Introduce ac_build_expand()

[Marek Olšák]

On Thu, Oct 18, 2018 at 10:13 AM Connor Abbott  wrote:

> And implement ac_bulid_expand_to_vec4() on top of it.
>
> Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for
> 16bit buffer loads")
> ---
>  src/amd/common/ac_llvm_build.c | 40 ++
>  src/amd/common/ac_llvm_build.h |  3 +++
>  2 files changed, 29 insertions(+), 14 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c
> b/src/amd/common/ac_llvm_build.c
> index 2d78ca1b52a..c54a50dcd86 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -523,39 +523,51 @@ ac_build_gather_values(struct ac_llvm_context *ctx,
> return ac_build_gather_values_extended(ctx, values, value_count,
> 1, false, false);
>  }
>
> -/* Expand a scalar or vector to <4 x type> by filling the remaining
> channels
> - * with undef. Extract at most num_channels components from the input.
> +/* Expand a scalar or vector to  by filling the
> remaining
> + * channels with undef. Extract at most src_channels components from the
> input.
>   */
> -LLVMValueRef ac_build_expand_to_vec4(struct ac_llvm_context *ctx,
> -LLVMValueRef value,
> -unsigned num_channels)
> +LLVMValueRef ac_build_expand(struct ac_llvm_context *ctx,
> +LLVMValueRef value,
> +unsigned src_channels,
> +unsigned dst_channels)
>  {
> LLVMTypeRef elemtype;
> -   LLVMValueRef chan[4];
> +   LLVMValueRef chan[dst_channels];
>

That doesn't look like a valid syntax. dst_channel is not a compile-time
constant. What was wrong with 4?

Other than that, this patch is:

Reviewed-by: Marek Olšák 

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: fix int-to-pointer-cast warnings on 32bit

[Grazvydas Ignotas]

Trivial.
---
 src/amd/vulkan/radv_debug.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index 08fc80c12ab..e81b9cccb57 100644
--- a/src/amd/vulkan/radv_debug.c
+++ b/src/amd/vulkan/radv_debug.c
@@ -320,11 +320,11 @@ radv_dump_descriptors(struct radv_pipeline *pipeline, 
FILE *f)
int i;
 
fprintf(f, "List of descriptors:\n");
for (i = 0; i < MAX_SETS; i++) {
struct radv_descriptor_set *set =
-   (struct radv_descriptor_set *)ptr[i + 3];
+   (struct radv_descriptor_set *)(uintptr_t)ptr[i + 3];
 
radv_dump_descriptor_set(chip_class, set, i, f);
}
 }
 
@@ -565,19 +565,19 @@ radv_dump_compute_state(struct radv_pipeline 
*compute_pipeline, FILE *f)
 static struct radv_pipeline *
 radv_get_saved_graphics_pipeline(struct radv_device *device)
 {
uint64_t *ptr = (uint64_t *)device->trace_id_ptr;
 
-   return (struct radv_pipeline *)ptr[1];
+   return (struct radv_pipeline *)(uintptr_t)ptr[1];
 }
 
 static struct radv_pipeline *
 radv_get_saved_compute_pipeline(struct radv_device *device)
 {
uint64_t *ptr = (uint64_t *)device->trace_id_ptr;
 
-   return (struct radv_pipeline *)ptr[2];
+   return (struct radv_pipeline *)(uintptr_t)ptr[2];
 }
 
 static void
 radv_dump_dmesg(FILE *f)
 {
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4] radeonsi: Disable clear_state with radeon kernel driver

[Marek Olšák]

Pushed, thanks!

Marek

On Fri, Oct 19, 2018 at 3:56 PM Jiang, Sonny  wrote:

> Signed-off-by: Sonny Jiang 
> Tested-by: Michel Dänzer 
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c  | 6 --
>  src/gallium/drivers/radeonsi/si_state.c | 5 +++--
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 46cf37567f..e285b056db 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -993,8 +993,10 @@ struct pipe_screen *radeonsi_screen_create(struct
> radeon_winsys *ws,
> }
>
> /* The mere presense of CLEAR_STATE in the IB causes random GPU
> hangs
> -* on SI. */
> -   sscreen->has_clear_state = sscreen->info.chip_class >= CIK;
> +* on SI. Some CLEAR_STATE cause asic hang on radeon kernel, etc.
> +* SPI_VS_OUT_CONFIG. So only enable CI CLEAR_STATE on amdgpu
> kernel.*/
> +   sscreen->has_clear_state = sscreen->info.chip_class >= CIK &&
> +  sscreen->info.drm_major == 3;
>
> sscreen->has_distributed_tess =
> sscreen->info.chip_class >= VI &&
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index 176ec74914..2977474130 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -4899,8 +4899,9 @@ static void si_init_config(struct si_context *sctx)
> bool has_clear_state = sscreen->has_clear_state;
> struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
>
> -   /* Only SI can disable CLEAR_STATE for now. */
> -   assert(has_clear_state || sscreen->info.chip_class == SI);
> +   /* SI, radeon kernel disabled CLEAR_STATE. */
> +   assert(has_clear_state || sscreen->info.chip_class == SI ||
> +  sscreen->info.drm_major != 3);
>
> if (!pm4)
> return;
> --
> 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] [PATCH v4] radeonsi: Disable clear_state with radeon kernel driver

[Jiang, Sonny]

Signed-off-by: Sonny Jiang 
Tested-by: Michel Dänzer 
---
 src/gallium/drivers/radeonsi/si_pipe.c  | 6 --
 src/gallium/drivers/radeonsi/si_state.c | 5 +++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 46cf37567f..e285b056db 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -993,8 +993,10 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
}
 
/* The mere presense of CLEAR_STATE in the IB causes random GPU hangs
-* on SI. */
-   sscreen->has_clear_state = sscreen->info.chip_class >= CIK;
+* on SI. Some CLEAR_STATE cause asic hang on radeon kernel, etc.
+* SPI_VS_OUT_CONFIG. So only enable CI CLEAR_STATE on amdgpu kernel.*/
+   sscreen->has_clear_state = sscreen->info.chip_class >= CIK &&
+  sscreen->info.drm_major == 3;
 
sscreen->has_distributed_tess =
sscreen->info.chip_class >= VI &&
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 176ec74914..2977474130 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -4899,8 +4899,9 @@ static void si_init_config(struct si_context *sctx)
bool has_clear_state = sscreen->has_clear_state;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
 
-   /* Only SI can disable CLEAR_STATE for now. */
-   assert(has_clear_state || sscreen->info.chip_class == SI);
+   /* SI, radeon kernel disabled CLEAR_STATE. */
+   assert(has_clear_state || sscreen->info.chip_class == SI ||
+  sscreen->info.drm_major != 3);
 
if (!pm4)
return;
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] docs: Add a copyright.c template we can copy when making new files.

[Chris Wilson]

Quoting Kenneth Graunke (2018-10-19 18:51:36)
> Usually when making a new file, people copy some random other file
> to get the copyright header comments.  Unfortunately, some of them
> are commented in a decades-old style, are word wrapped poorly, or
> worse, have a few subtle variations in the text.  While we've tried
> to clean those up, we're not going to get every copy to be perfect.
> 
> Instead, this commit adds docs/copyright.c, which contains a copy of
> the license header which is well-formatted and has the correct text.
> The idea is that you can start from this when making a new file, which
> should help with consistency.
> ---
>  docs/copyright.c | 22 ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 docs/copyright.c
> 
> Hey all,
> 
> I noticed when writing my new Iris driver that I had a couple subtle
> variations of copyright headers creep in, even in a brand new project.
> Mostly word wrapping differences.  To combat that, I made a copyright.c
> and made sure to use it when I created new files.  It seemed to help.
> 
> So, the thinking is to just actually put that in the project under docs.
> Maybe it helps other people as well?

May I suggest spdx.org and in particular using a format such as

/* SPDX: MIT */

with a toplevel description of what the link means. From a dev point of
view, it's much quicker to see what licence variant is being used and
even harder for mistakes to creep in.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] radeonsi: Disable clear_state with radeon kernel driver

[Jiang, Sonny]

Signed-off-by: Sonny Jiang 
Tested-by: Michel Dänzer 
---
 src/gallium/drivers/radeonsi/si_pipe.c  | 6 --
 src/gallium/drivers/radeonsi/si_state.c | 5 +++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9d25748df4..a82171c2dc 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -991,8 +991,10 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
}
 
/* The mere presense of CLEAR_STATE in the IB causes random GPU hangs
-* on SI. */
-   sscreen->has_clear_state = sscreen->info.chip_class >= CIK;
+* on SI. Some CLEAR_STATE cause asic hang on radeon kernel, etc.
+* SPI_VS_OUT_CONFIG. So only enable CI CLEAR_STATE on amdgpu kernel.*/
+   sscreen->has_clear_state = sscreen->info.chip_class >= CIK &&
+  sscreen->info.drm_major == 3;
 
sscreen->has_distributed_tess =
sscreen->info.chip_class >= VI &&
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 8b2e6e57f4..cd43276b50 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -4899,8 +4899,9 @@ static void si_init_config(struct si_context *sctx)
bool has_clear_state = sscreen->has_clear_state;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
 
-   /* Only SI can disable CLEAR_STATE for now. */
-   assert(has_clear_state || sscreen->info.chip_class == SI);
+   /* SI, radeon kernel disabled CLEAR_STATE. */
+   assert(has_clear_state || sscreen->info.chip_class == SI ||
+  sscreen->info.drm_major != 3);
 
if (!pm4)
return;
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] docs: Add a copyright.c template we can copy when making new files.

[Nanley Chery]

On Fri, Oct 19, 2018 at 10:51:36AM -0700, Kenneth Graunke wrote:
> Usually when making a new file, people copy some random other file
> to get the copyright header comments.  Unfortunately, some of them
> are commented in a decades-old style, are word wrapped poorly, or
> worse, have a few subtle variations in the text.  While we've tried
> to clean those up, we're not going to get every copy to be perfect.
> 
> Instead, this commit adds docs/copyright.c, which contains a copy of
> the license header which is well-formatted and has the correct text.
> The idea is that you can start from this when making a new file, which
> should help with consistency.
> ---
>  docs/copyright.c | 22 ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 docs/copyright.c
> 
> Hey all,
> 
> I noticed when writing my new Iris driver that I had a couple subtle
> variations of copyright headers creep in, even in a brand new project.
> Mostly word wrapping differences.  To combat that, I made a copyright.c
> and made sure to use it when I created new files.  It seemed to help.
> 
> So, the thinking is to just actually put that in the project under docs.
> Maybe it helps other people as well?
> 

Should we let people know about this file by adding a note in
docs/devinfo.html?

To help people who don't always keep up w/ the documentation, I was
initially thinking we could add a git hook. I think that'd cause
problems when importing code from elsewhere, though.

>  --Ken
> 
> diff --git a/docs/copyright.c b/docs/copyright.c
> new file mode 100644
> index 000..db92f27e641
> --- /dev/null
> +++ b/docs/copyright.c
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright © 2018 
   ^
?

-Nanley

> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included
> + * in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> -- 
> 2.19.0
> 
> ___
> 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 v3 2/3] mesa/st: enable EXT_sRGB_write_control for drivers that support it

[Ilia Mirkin]

On Fri, Oct 19, 2018 at 12:45 PM Gert Wollny  wrote:
>
> Am Freitag, den 19.10.2018, 08:25 -0400 schrieb Ilia Mirkin:
> > I don't think a PIPE_CAP is the answer here... I think you're on the
> > right track with format checks and whatnot.
>
> The problem is that with an GLES host, the checked sRGB format might be
> supported by virgl, but not EXT_sRGB_write_control, so the guest will

Perhaps virglrenderer should not expose e.g. PIPE_DISPLAY_TARGET for
srgb if it doesn't support EXT_sRGB_write_control. The extensions
exposed should be a function of what the driver supports. What is so
special about EXT_sRGB_write_control that each driver must determine
individually for just that one extension that can't be derived from
the supported formats and bind flags?

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] docs: Add a copyright.c template we can copy when making new files.

[Matt Turner]

Sounds like a good idea to me.

Acked-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] meson: Add -Werror=return-type when supported.

[Kenneth Graunke]

On Friday, October 19, 2018 10:17:29 AM PDT Matt Turner wrote:
> On Thu, Oct 18, 2018 at 6:06 PM Kenneth Graunke  wrote:
> >
> > This warning detects non-void functions with a missing return statement,
> > return statements with a value in void functions, and functions with an
> > bogus return type that ends up defaulting to int.  It's already enabled
> > by default with -Wall.  Generally, these are fairly serious bugs in the
> > code, which developers would like to notice and fix immediately.  This
> > patch promotes it from a warning to an error, to help developers catch
> > such mistakes early.
> >
> > I would not expect this warning to change much based on the compiler
> > version, so hopefully it won't become a problem for packagers/builders.
> >
> > See the GCC documentation or 'man gcc' for more details:
> > https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Warning-Options.html#index-Wreturn-type
> 
> I'm curious what prompted this. Did we actually have a bug that would
> have been caught by this?
> 

Never committed, but I broke some things in iris a long while back.
I think I had botched includes which made some type not exist, which
made it default to an int type, which wasn't at all what I wanted.

I think it may have been something that led to GPU hangs or something
awful.  Spent a while debugging it, then asked "why doesn't the
compiler just disallow this?".  At the time I still had a fair amount
of warnings about unused things I hadn't finished hooking up, so I
missed the warning.

Hmm, but now I guess you have to patch this out for Gentoo by policy?
I'm adamantly against -Werror, but I figured this very narrow subset
could be useful while not breaking unless there are real bugs.

If people really don't want it, feel free to revert.

--Ken


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

[Mesa-dev] [Bug 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

--- Comment #7 from Karl  ---
Thanks for the quick fix

-- 
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

[Mesa-dev] [RFC] docs: Add a copyright.c template we can copy when making new files.

[Kenneth Graunke]

Usually when making a new file, people copy some random other file
to get the copyright header comments.  Unfortunately, some of them
are commented in a decades-old style, are word wrapped poorly, or
worse, have a few subtle variations in the text.  While we've tried
to clean those up, we're not going to get every copy to be perfect.

Instead, this commit adds docs/copyright.c, which contains a copy of
the license header which is well-formatted and has the correct text.
The idea is that you can start from this when making a new file, which
should help with consistency.
---
 docs/copyright.c | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 docs/copyright.c

Hey all,

I noticed when writing my new Iris driver that I had a couple subtle
variations of copyright headers creep in, even in a brand new project.
Mostly word wrapping differences.  To combat that, I made a copyright.c
and made sure to use it when I created new files.  It seemed to help.

So, the thinking is to just actually put that in the project under docs.
Maybe it helps other people as well?

 --Ken

diff --git a/docs/copyright.c b/docs/copyright.c
new file mode 100644
index 000..db92f27e641
--- /dev/null
+++ b/docs/copyright.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright © 2018 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
-- 
2.19.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nv50/ir: fix ConstantFolding::createMul for 64 bit muls

[Karol Herbst]

Fixes: 2f52925f5c60c72c9389bfdc122c3d5f8e15b25f
   "nv50/ir: move a * b -> a << log2(b) code into createMul()"

Reviewed-by: Rhys Perry 
Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index d851cf3c37c..8767e5efb99 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -965,7 +965,7 @@ ConstantFolding::createMul(DataType ty, Value *def, Value 
*a, int64_t b, Value *
if (b >= 0 && util_is_power_of_two_or_zero64(b)) {
   int shl = util_logbase2_64(b);
 
-  Value *res = c ? bld.getSSA() : def;
+  Value *res = c ? bld.getSSA(typeSizeof(ty)) : def;
   bld.mkOp2(OP_SHL, ty, res, a, bld.mkImm(shl));
   if (c)
  bld.mkOp2(OP_ADD, ty, def, res, c);
-- 
2.17.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] meson: Add -Werror=return-type when supported.

[Matt Turner]

On Thu, Oct 18, 2018 at 6:06 PM Kenneth Graunke  wrote:
>
> This warning detects non-void functions with a missing return statement,
> return statements with a value in void functions, and functions with an
> bogus return type that ends up defaulting to int.  It's already enabled
> by default with -Wall.  Generally, these are fairly serious bugs in the
> code, which developers would like to notice and fix immediately.  This
> patch promotes it from a warning to an error, to help developers catch
> such mistakes early.
>
> I would not expect this warning to change much based on the compiler
> version, so hopefully it won't become a problem for packagers/builders.
>
> See the GCC documentation or 'man gcc' for more details:
> https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Warning-Options.html#index-Wreturn-type

I'm curious what prompted this. Did we actually have a bug that would
have been caught by this?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

[Dylan Baker]

That's not quite right. GLES needs shared glapi, but shared glapi doesn't need
gles. meson and autoconf have separate toggles for shared-glapi and gles, they
both happen to default to "on" currently.

If you want to uses GLES with mesa on Windows your best bet is probably to use
ARB_ES_compatibility (replace  with 1, 2, 3, 3_1, or 3_2 as needed) from a
GL Core Context like you would using the Nvidia or Intel driver on windows.
Don't try to go down the EGL on windows madness that the proprietary AMD driver
requires.

Meson will likely continue to support shared glapi on windows because every
other platform that mesa supports needs shared-glapi. I have in my latest spin
default gles off on windows with meson. Jose, does it make more sense to just
make gles on windows an error in meson?

Dylan

Quoting Liviu Prodea (2018-10-19 08:04:28)
> 
> 
> 
> I think I found autotools build equivalent for gles=y. It is 
> --enable-shared-glapi. And the docs say it is needed to support applications 
> that mix OpenGL and OpenGL ES:
> 
> https://www.mesa3d.org/egl.html
> 
> -
> 
> 
> On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul  
> wrote: 
> 
> 
> 
> 
> 
> Reviewed-by: Brian Paul 
> 
> On 10/19/2018 06:33 AM, Jose Fonseca wrote:
> > It's broken, and WGL state tracker is always built with GLES support
> > noawadays.
> > ---
> >  common.py                                    | 2 --
> >  src/SConscript                              | 7 ---
> >  src/gallium/state_trackers/osmesa/SConscript | 4 +---
> >  src/gallium/state_trackers/wgl/SConscript    | 4 +---
> >  src/gallium/targets/libgl-gdi/SConscript    | 6 --
> >  src/gallium/targets/libgl-xlib/SConscript    | 6 --
> >  src/mapi/glapi/SConscript                    | 6 +-
> >  src/mapi/shared-glapi/SConscript            | 9 +
> >  src/mesa/SConscript                          | 4 +---
> >  src/mesa/drivers/osmesa/SConscript          | 4 +---
> >  10 files changed, 6 insertions(+), 46 deletions(-)
> > 
> > diff --git a/common.py b/common.py
> > index 113fc7f5c12..f4f2bb44c1c 100644
> > --- a/common.py
> > +++ b/common.py
> > @@ -99,8 +99,6 @@ def AddOptions(opts):
> >                          'enable static code analysis where available', 
> >'no'))
> >      opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
> >      opts.Add('toolchain', 'compiler toolchain', default_toolchain)
> > -    opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
> > -                        'no'))
> >      opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
> >      opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
> >(swrast)',
> >                          'no'))
> > diff --git a/src/SConscript b/src/SConscript
> > index 95ea061c4bb..54350a9cdcc 100644
> > --- a/src/SConscript
> > +++ b/src/SConscript
> > @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
> >  if env['platform'] != 'windows':
> >      SConscript('loader/SConscript')
> >  
> > -# When env['gles'] is set, the targets defined in mapi/glapi/SConscript 
> > are not
> > -# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets 
> > defined
> > -# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
> > -# enable OpenGL ES support.
> >  SConscript('mapi/glapi/gen/SConscript')
> >  SConscript('mapi/glapi/SConscript')
> >  
> > @@ -61,8 +57,5 @@ if not env['embedded']:
> >      if env['platform'] == 'haiku':
> >          SConscript('egl/SConscript')
> >  
> > -    if env['gles']:
> > -        SConscript('mapi/shared-glapi/SConscript')
> > -
> >  SConscript('gallium/SConscript')
> >  
> > diff --git a/src/gallium/state_trackers/osmesa/SConscript 
> > b/src/gallium/state_trackers/osmesa/SConscript
> > index f5519f13762..be67d0fe739 100644
> > --- a/src/gallium/state_trackers/osmesa/SConscript
> > +++ b/src/gallium/state_trackers/osmesa/SConscript
> > @@ -14,10 +14,8 @@ if env['platform'] == 'windows':
> >      env.AppendUnique(CPPDEFINES = [
> >          'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa 
> >headers
> >          'WIN32_LEAN_AND_MEAN', # 
> >http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> > +        '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> > __declspec(dllimport)
> >      ])
> > -    if not env['gles']:
> > -        # prevent _glapi_* from being declared __declspec(dllimport)
> > -        env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
> >  
> >  st_osmesa = env.ConvenienceLibrary(
> >      target ='st_osmesa',
> > diff --git a/src/gallium/state_trackers/wgl/SConscript 
> > b/src/gallium/state_trackers/wgl/SConscript
> > index a7fbb07a89a..bbf5ebd9764 100644
> > --- a/src/gallium/state_trackers/wgl/SConscript
> > +++ b/src/gallium/state_trackers/wgl/SConscript
> > @@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [
> >      

Re: [Mesa-dev] [PATCH v6 4/5] loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property

[Kazlauskas, Nicholas]

On 10/19/2018 12:49 PM, Michel Dänzer wrote:
> On 2018-10-19 6:41 p.m., Nicholas Kazlauskas wrote:
>> The DDX driver can be notified of adaptive sync suitability by
>> flagging the application's window with the _VARIABLE_REFRESH property.
>>
>> This property is set on the first swap the application performs
>> when adaptive_sync is set to true in the drirc.
>>
>> It's performed here instead of when the loader is initialized for
>> two reasons:
>>
>> (1) The window's drawable can be missing during loader init.
>>  This can be observed during the Unigine Superposition benchmark.
>>
>> (2) Adaptive sync will only be enabled closer to when the application
>>  actually begins rendering.
>>
>> If adaptive_sync is false then the _VARIABLE_REFRESH property
>> is deleted on loader init.
>>
>> The property is only managed on the glx DRI3 backend for now. This
>> should cover most common applications and games on modern hardware.
>>
>> Vulkan support can be implemented in a similar manner but would likely
>> require splitting the function out into a common helper function.
>>
>> Signed-off-by: Nicholas Kazlauskas 
>>
>> [...]
>>   
>> @@ -318,6 +344,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
>>  xcb_get_geometry_reply_t *reply;
>>  xcb_generic_error_t *error;
>>  GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
>> +   unsigned char adaptive_sync;
>>  int swap_interval;
>>   
>>  draw->conn = conn;
>> @@ -331,16 +358,28 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
>>  draw->have_back = 0;
>>  draw->have_fake_front = 0;
>>  draw->first_init = true;
>> +   draw->adaptive_sync = false;
>> +   draw->adaptive_sync_active = false;
>>   
>>  draw->cur_blit_source = -1;
>>  draw->back_format = __DRI_IMAGE_FORMAT_NONE;
>>  mtx_init(>mtx, mtx_plain);
>>  cnd_init(>event_cnd);
>>   
>> -   if (draw->ext->config)
>> +   if (draw->ext->config) {
>> draw->ext->config->configQueryi(draw->dri_screen,
>> "vblank_mode", _mode);
>>   
>> +  draw->ext->config->configQueryb(draw->dri_screen,
>> +  "adaptive_sync",
>> +  _sync);
>> +
>> +  draw->adaptive_sync = adaptive_sync;
>> +   }
>> +
>> +   if (!adaptive_sync)
>> +  set_adaptive_sync_property(conn, draw->drawable, false);
> 
> If !draw->ext->config, the local variable adaptive_sync is uninitialized
> here. There are multiple ways to solve this, but I think the cleanest
> might be to move its definition inside the block, and test
> draw->adaptive_sync outside of it.
> 
> 

Not sure how I missed this. Guess it got lost with the other warnings 
when building.

Thanks.

Nicholas Kazlauskas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [ANNOUNCE] mesa 18.2.3

[Juan A. Suarez Romero]

Mesa 18.2.3 is now available.

In this release we have:


Different patches for the DirectX9 and DRI state trackers.

Several fixes and workarounds for different games, inlcuding RAGE, Yakuza and
The Evil Within, Wolfenstein The Old Blood ARMA 3, or No Mans Sky.

A bunch of fixes for different drivers, including r600, nouveau, radeonsi, anv,
radv, virgl, i965, nvc0 or nv50. Worth to mention a fix for GPU hangs in
Radeonsi.

State Trackers also get different fixes and corrections.

Finally, fixes for GLSL and NIR are also in this queue.


Boyuan Zhang (1):
  st/va: use provided sizes and coords for vlVaGetImage

Dave Airlie (1):
  anv: add missing unlock in error path.

Dylan Baker (1):
  meson: Don't allow building EGL on Windows or MacOS

Emil Velikov (5):
  st/nine: do not double-close the fd on teardown
  egl: make eglSwapInterval a no-op for !window surfaces
  egl: make eglSwapBuffers* a no-op for !window surfaces
  vl/dri3: do full teardown on screen_destroy
  Revert "mesa: remove unnecessary 'sort by year' for the GL extensions"

Eric Engestrom (1):
  radv: add missing meson c++ visibility arguments

Fritz Koenig (1):
  i965: Replace checks for rb->Name with FlipY (v2)

Gert Wollny (1):
  virgl, vtest: Correct the transfer size calculation

Ilia Mirkin (4):
  glsl: fix array assignments of a swizzled vector
  nv50,nvc0: mark RGBX_UINT formats as renderable
  nv50,nvc0: guard against zero-size blits
  nvc0: fix blitting red to srgb8_alpha

Jason Ekstrand (7):
  nir/cf: Remove phi sources if needed in nir_handle_add_jump
  anv: Use separate MOCS settings for external BOs
  intel/fs: Fix a typo in need_matching_subreg_offset
  nir/from_ssa: Don't rewrite derefs destinations to registers
  anv/batch_chain: Don't start a new BO just for BATCH_BUFFER_START
  nir/alu_to_scalar: Use ssa_for_alu_src in hand-rolled expansions
  intel: Don't propagate conditional modifiers if a UD source is negated

Juan A. Suarez Romero (3):
  docs: add sha256 checksums for 18.2.2
  Update version to 18.2.3
  docs: add release notes for 18.2.3

Józef Kucia (1):
  radeonsi: avoid sending GS_EMIT in shaders without outputs

Marek Olšák (1):
  drirc: add a workaround for ARMA 3

Samuel Pitoiset (1):
  radv: add a workaround for a VGT hang with prim restart and strips

Tapani Pälli (1):
  glsl: do not attempt assignment if operand type not parsed correctly

Timothy Arceri (11):
  glsl: ignore trailing whitespace when define redefined
  util: disable cache if we have no build-id and timestamp is zero
  util: rename timestamp param in disk_cache_create()
  util: add disk_cache_get_function_identifier()
  radeonsi: use build-id when available for disk cache
  nouveau: use build-id when available for disk cache
  r600: use build-id when available for disk cache
  mesa/st: add force_compat_profile option to driconfig
  util: use force_compat_profile for Wolfenstein The Old Blood
  util: better handle program names from wine
  util: add drirc workarounds for RAGE

Vinson Lee (1):
  r600/sb: Fix constant-logical-operand warning.

git tag: mesa-18.2.3

https://mesa.freedesktop.org/archive/mesa-18.2.3.tar.gz
MD5:  2eb263f86eadc36d385932a6f325a696  mesa-18.2.3.tar.gz
SHA1: 8ab4a04420e63d4346ac222a30c42170b366fd4c  mesa-18.2.3.tar.gz
SHA256: 0e13e2342eae74d8848df23595c4bb4b2f8874c9e1213b8466b1fbfa7ef99375  
mesa-18.2.3.tar.gz
SHA512: 
aa66da605b7b1b1fd8ce18de365fe3c8cca87152b30164f9be604c74c32e8d79e3413b534b283ae0f378c49c075658ce77e926c98d12e487831ef4b737a96efd
  mesa-18.2.3.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.2.3.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-18.2.3.tar.xz
MD5:  3ad402144c2da93f09910dd2e0fc4017  mesa-18.2.3.tar.xz
SHA1: 84c037e8ac53c210e3d74ae010241f781251b72c  mesa-18.2.3.tar.xz
SHA256: e2bf83c17e1abdecb1ee81af22652e27e9aa38f963e95e60f34275cc0376304f  
mesa-18.2.3.tar.xz
SHA512: 
20f512b1f3835b1c78b1f05f2e2125dc3437b61b8857e7ec62e0f9ac3be2ccb5b7ebe7e18f444da1117bc100d75e4b03cd2a0180f0f0b1cf760714b43bc7a664
  mesa-18.2.3.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.2.3.tar.xz.sig



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 v6 4/5] loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property

[Michel Dänzer]

On 2018-10-19 6:41 p.m., Nicholas Kazlauskas wrote:
> The DDX driver can be notified of adaptive sync suitability by
> flagging the application's window with the _VARIABLE_REFRESH property.
> 
> This property is set on the first swap the application performs
> when adaptive_sync is set to true in the drirc.
> 
> It's performed here instead of when the loader is initialized for
> two reasons:
> 
> (1) The window's drawable can be missing during loader init.
> This can be observed during the Unigine Superposition benchmark.
> 
> (2) Adaptive sync will only be enabled closer to when the application
> actually begins rendering.
> 
> If adaptive_sync is false then the _VARIABLE_REFRESH property
> is deleted on loader init.
> 
> The property is only managed on the glx DRI3 backend for now. This
> should cover most common applications and games on modern hardware.
> 
> Vulkan support can be implemented in a similar manner but would likely
> require splitting the function out into a common helper function.
> 
> Signed-off-by: Nicholas Kazlauskas 
> 
> [...]
>  
> @@ -318,6 +344,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
> xcb_get_geometry_reply_t *reply;
> xcb_generic_error_t *error;
> GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
> +   unsigned char adaptive_sync;
> int swap_interval;
>  
> draw->conn = conn;
> @@ -331,16 +358,28 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
> draw->have_back = 0;
> draw->have_fake_front = 0;
> draw->first_init = true;
> +   draw->adaptive_sync = false;
> +   draw->adaptive_sync_active = false;
>  
> draw->cur_blit_source = -1;
> draw->back_format = __DRI_IMAGE_FORMAT_NONE;
> mtx_init(>mtx, mtx_plain);
> cnd_init(>event_cnd);
>  
> -   if (draw->ext->config)
> +   if (draw->ext->config) {
>draw->ext->config->configQueryi(draw->dri_screen,
>"vblank_mode", _mode);
>  
> +  draw->ext->config->configQueryb(draw->dri_screen,
> +  "adaptive_sync",
> +  _sync);
> +
> +  draw->adaptive_sync = adaptive_sync;
> +   }
> +
> +   if (!adaptive_sync)
> +  set_adaptive_sync_property(conn, draw->drawable, false);

If !draw->ext->config, the local variable adaptive_sync is uninitialized
here. There are multiple ways to solve this, but I think the cleanest
might be to move its definition inside the block, and test
draw->adaptive_sync outside of it.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/3] mesa/st: enable EXT_sRGB_write_control for drivers that support it

[Gert Wollny]

Am Freitag, den 19.10.2018, 08:25 -0400 schrieb Ilia Mirkin:
> I don't think a PIPE_CAP is the answer here... I think you're on the
> right track with format checks and whatnot.

The problem is that with an GLES host, the checked sRGB format might be
supported by virgl, but not EXT_sRGB_write_control, so the guest will
still expose the extension, but then one of the dEQP tests fails. If I
use host caps in this case to disable the the extension in the guest I
can avoid exposing the not properly working extension, and for this I
need the caps. 

I will dig a bit to figure out whether this is actually problem in
virglrenderer, or how Gallium handles enabling and disabling
FRAMEBUFFER_SRGB, but I'm not that optimistic. 

Best, 
Gert



> On Fri, Oct 19, 2018 at 2:54 AM Gert Wollny
>  wrote:
> > 
> > Considering how virgl has to deal with host capabilities the
> > extension should be enabled via a CAP, so I'll rework this patch
> > another time.
> > 
> > Sorry for being so noisy,
> > Gert
> > 
> > 
> > Am Donnerstag, den 18.10.2018, 18:39 +0200 schrieb Gert Wollny:
> > > From: Gert Wollny 
> > > 
> > > With this patch the extension EXT_sRGB_write_control is enabled
> > > for
> > > gallium drivers that support sRGB formats as render targets.
> > > 
> > > Tested (and pass) on r600 (evergreen) and softpipe:
> > > 
> > >   dEQP-
> > > GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled
> > > *
> > > 
> > > with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check
> > > for
> > > this), and
> > > 
> > >   dEQP-
> > > GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsuppo
> > > rted
> > > _enum
> > > 
> > > when extension is manually disabled via MESA_EXTENSION_OVERRIDE
> > > 
> > > v2: - always enable the extension when sRGB is supported (Ilia
> > > Mirkin).
> > > - Correct handling by moving extension initialization to the
> > >   place where gallium/st actually takes care of this. This
> > > also
> > >   fixes properly disabling the extension via
> > > MESA_EXTENSION_OVERRIDE
> > > - reinstate check for desktop GL and add check for the
> > > extension
> > >   when creating the framebuffer
> > > 
> > > v3: Only create sRGB renderbuffers based on Visual.srgbCapable
> > > when
> > > on desktop GL.
> > > 
> > > Signed-off-by: Gert Wollny 
> > > ---
> > >  src/mesa/state_tracker/st_extensions.c |  6 +
> > >  src/mesa/state_tracker/st_manager.c| 37 --
> > > 
> > > 
> > >  2 files changed, 29 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/src/mesa/state_tracker/st_extensions.c
> > > b/src/mesa/state_tracker/st_extensions.c
> > > index 798ee60875..401609d728 100644
> > > --- a/src/mesa/state_tracker/st_extensions.c
> > > +++ b/src/mesa/state_tracker/st_extensions.c
> > > @@ -1169,6 +1169,12 @@ void st_init_extensions(struct pipe_screen
> > > *screen,
> > >   void_formats, 32,
> > >   PIPE_BIND_RENDER_TARGET);
> > > 
> > > +  extensions->EXT_sRGB_write_control =
> > > + screen->is_format_supported(screen,
> > > PIPE_FORMAT_R8G8B8A8_SRGB,
> > > + PIPE_TEXTURE_2D, 0, 0,
> > > + (PIPE_BIND_DISPLAY_TARGET |
> > > +  PIPE_BIND_RENDER_TARGET));
> > > +
> > >if (extensions->AMD_framebuffer_multisample_advanced) {
> > >   /* AMD_framebuffer_multisample_advanced */
> > >   /* This can be greater than storage samples. */
> > > diff --git a/src/mesa/state_tracker/st_manager.c
> > > b/src/mesa/state_tracker/st_manager.c
> > > index ceb48dd490..df898beb23 100644
> > > --- a/src/mesa/state_tracker/st_manager.c
> > > +++ b/src/mesa/state_tracker/st_manager.c
> > > @@ -295,7 +295,7 @@ st_framebuffer_update_attachments(struct
> > > st_framebuffer *stfb)
> > >   */
> > >  static boolean
> > >  st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
> > > -gl_buffer_index idx)
> > > +gl_buffer_index idx, bool
> > > prefer_srgb)
> > >  {
> > > struct gl_renderbuffer *rb;
> > > enum pipe_format format;
> > > @@ -318,7 +318,7 @@ st_framebuffer_add_renderbuffer(struct
> > > st_framebuffer *stfb,
> > >break;
> > > default:
> > >format = stfb->iface->visual->color_format;
> > > -  if (stfb->Base.Visual.sRGBCapable)
> > > +  if (prefer_srgb)
> > >   format = util_format_srgb(format);
> > >sw = FALSE;
> > >break;
> > > @@ -436,6 +436,7 @@ st_framebuffer_create(struct st_context *st,
> > > struct st_framebuffer *stfb;
> > > struct gl_config mode;
> > > gl_buffer_index idx;
> > > +   bool prefer_srgb = false;
> > > 
> > > if (!stfbi)
> > >return NULL;
> > > @@ -457,14 +458,15 @@ st_framebuffer_create(struct st_context
> > > *st,
> > >  * format such that 

[Mesa-dev] [PATCH v6 5/5] radeonsi: Enable adaptive_sync by default for radeon

[Nicholas Kazlauskas]

It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.

Signed-off-by: Nicholas Kazlauskas 
---
 src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h 
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..cbf3bb01fb 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
 // DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+DRI_CONF_ADAPTIVE_SYNC("true")
+DRI_CONF_SECTION_END
+
 DRI_CONF_SECTION_PERFORMANCE
 DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
 DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v6 4/5] loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property

[Nicholas Kazlauskas]

The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.

This property is set on the first swap the application performs
when adaptive_sync is set to true in the drirc.

It's performed here instead of when the loader is initialized for
two reasons:

(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.

(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering.

If adaptive_sync is false then the _VARIABLE_REFRESH property
is deleted on loader init.

The property is only managed on the glx DRI3 backend for now. This
should cover most common applications and games on modern hardware.

Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.

Signed-off-by: Nicholas Kazlauskas 
---
 src/loader/loader_dri3_helper.c | 47 -
 src/loader/loader_dri3_helper.h |  2 ++
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 1981b5f051..7d225e1a9d 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -101,6 +101,32 @@ get_xcb_visualtype_for_depth(struct loader_dri3_drawable 
*draw, int depth)
return NULL;
 }
 
+/* Sets the adaptive sync window property state. */
+static void
+set_adaptive_sync_property(xcb_connection_t *conn, xcb_drawable_t drawable,
+   uint32_t state)
+{
+   static char const name[] = "_VARIABLE_REFRESH";
+   xcb_intern_atom_cookie_t cookie;
+   xcb_intern_atom_reply_t* reply;
+   xcb_void_cookie_t check;
+
+   cookie = xcb_intern_atom(conn, 0, sizeof(name), name);
+   reply = xcb_intern_atom_reply(conn, cookie, NULL);
+   if (reply == NULL)
+  return;
+
+   if (state)
+  check = xcb_change_property_checked(conn, XCB_PROP_MODE_REPLACE,
+  drawable, reply->atom,
+  XCB_ATOM_CARDINAL, 32, 1, );
+   else
+  check = xcb_delete_property_checked(conn, drawable, reply->atom);
+
+   xcb_discard_reply(conn, check.sequence);
+   free(reply);
+}
+
 /* Get red channel mask for given drawable at given depth. */
 static unsigned int
 dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
@@ -318,6 +344,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
xcb_get_geometry_reply_t *reply;
xcb_generic_error_t *error;
GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
+   unsigned char adaptive_sync;
int swap_interval;
 
draw->conn = conn;
@@ -331,16 +358,28 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_back = 0;
draw->have_fake_front = 0;
draw->first_init = true;
+   draw->adaptive_sync = false;
+   draw->adaptive_sync_active = false;
 
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
 
-   if (draw->ext->config)
+   if (draw->ext->config) {
   draw->ext->config->configQueryi(draw->dri_screen,
   "vblank_mode", _mode);
 
+  draw->ext->config->configQueryb(draw->dri_screen,
+  "adaptive_sync",
+  _sync);
+
+  draw->adaptive_sync = adaptive_sync;
+   }
+
+   if (!adaptive_sync)
+  set_adaptive_sync_property(conn, draw->drawable, false);
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +918,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
back = dri3_find_back_alloc(draw);
 
mtx_lock(>mtx);
+
+   if (draw->adaptive_sync && !draw->adaptive_sync_active) {
+  set_adaptive_sync_property(draw->conn, draw->drawable, true);
+  draw->adaptive_sync_active = true;
+   }
+
if (draw->is_different_gpu && back) {
   /* Update the linear buffer before presenting the pixmap */
   (void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..663ce3c0e2 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,8 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
 
bool first_init;
+   bool adaptive_sync;
+   bool adaptive_sync_active;
int swap_interval;
 
struct loader_dri3_extensions *ext;
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v6 3/5] drirc: Initial blacklist for adaptive sync

[Nicholas Kazlauskas]

Applications that don't present at a predictable rate (ie. not games)
shouldn't have adapative sync enabled. This list covers some of the
common desktop compositors, web browsers and video players.

Signed-off-by: Nicholas Kazlauskas 
---
 src/util/00-mesa-defaults.conf | 82 ++
 1 file changed, 82 insertions(+)

diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index a937c46d05..8e9a87d603 100644
--- a/src/util/00-mesa-defaults.conf
+++ b/src/util/00-mesa-defaults.conf
@@ -21,6 +21,8 @@ Application bugs worked around in this file:
   built-ins (specifically gl_VertexID), which causes the vertex shaders to fail
   to compile.
 
+* Applications that are not suitable for adapative sync are blacklisted here.
+
 TODO: document the other workarounds.
 
 -->
@@ -314,6 +316,86 @@ TODO: document the other workarounds.
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v6 1/5] util: Get program name based on path when possible

[Nicholas Kazlauskas]

Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.

This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.

Signed-off-by: Nicholas Kazlauskas 
---
 src/util/u_process.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
 __getProgramName()
 {
char * arg = strrchr(program_invocation_name, '/');
-   if (arg)
+   if (arg) {
+  /* If the / character was found this is likely a linux path or
+   * an invocation path for a 64-bit wine program.
+   *
+   * However, some programs pass command line arguments into argv[0].
+   * Strip these arguments out by using the realpath only if it was
+   * a prefix of the invocation name.
+   */
+  static char *path;
+
+  if (!path)
+ path = realpath("/proc/self/exe", NULL);
+
+  if (path && strncmp(path, program_invocation_name, strlen(path)) == 0) {
+ /* This shouldn't be null because path is a a prefix,
+  * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+return name + 1;
+  }
+
   return arg+1;
+   }
 
/* If there was no '/' at all we likely have a windows like path from
 * a wine application.
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v6 2/5] util: Add adaptive_sync driconf option

[Nicholas Kazlauskas]

This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.

It's off by default.

Signed-off-by: Nicholas Kazlauskas 
---
 src/util/xmlpool/t_options.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index e0a30f5fd1..80ddf0e203 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -210,6 +210,11 @@ DRI_CONF_OPT_BEGIN_V(vblank_mode,enum,def,"0:3") \
 DRI_CONF_DESC_END \
 DRI_CONF_OPT_END
 
+#define DRI_CONF_ADAPTIVE_SYNC(def) \
+DRI_CONF_OPT_BEGIN_B(adaptive_sync,def) \
+DRI_CONF_DESC(en,gettext("Adapt the monitor sync to the application 
performance (when possible)")) \
+DRI_CONF_OPT_END
+
 #define DRI_CONF_MESA_GLTHREAD(def) \
 DRI_CONF_OPT_BEGIN_B(mesa_glthread, def) \
 DRI_CONF_DESC(en,gettext("Enable offloading GL driver work to a 
separate thread")) \
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v6 0/5] Mesa integration for DRM variable refresh rate API

[Nicholas Kazlauskas]

These patches are part of a proposed new interface for supporting variable 
refresh rate via DRM properties.

It adds a new option for supporting adaptive sync to drirc along with the 
implementation of notifying the window manager/DDX of the support via a window 
property.

The option is enabled by default for radeonsi so included is an initial 
blacklist of applications that shouldn't have this option enabled.

Program name detection needed an additional patch to work for a few of the 
applications on the initial blacklist.

=== Changes from v5 ===

* Variable refresh property is now deleted when draw->ext->config is NULL

=== Changes from v4 ===

* "adaptive_sync_enable" shortened to now "adaptive_sync"
* Reordered patches for more logical bisection
* Replaced suspicious pointer arithmetic in get program name path to better 
clarify intent
* Errors are now discarded when setting/destroying variable refresh property
* Updated formatting in dri3 loader patch

=== Changes from v3 ===

* Blacklist updated to include more desktop environments
* Variable refresh property is now deleted when adaptive_sync_enable is false 
during loader init - this should resolve a potential issue with reusing windows 
with blacklisted applications.

=== Changes from v2 ===

* A patch to add the option to the drirc was missing from the v2 patchset. That 
patch is now included in v3.
* The method to fix program name detection for Chromium based applications for 
the drirc was modified to not break detection for 32-bit/64-bit WINE 
applications.

=== Adaptive sync and variable refresh rate ===

Adaptive sync is part of the DisplayPort specification and allows for graphics 
adapters to drive displays with varying frame timings.

Variable refresh rate (VRR) is essentially the same, but defined for HDMI.

=== Use cases for variable refresh rate ===

Variable frame (flip) timings don't align well with fixed refresh rate 
displays. This results in stuttering, tearing and/or input lag. By adjusting 
the display refresh rate dynamically these issues can be reduced or eliminated.

However, not all content is suitable for dynamic refresh adaptation. The user 
may experience "flickering" from differences in panel luminance at different 
refresh rates. Content that flips at an infrequent rate or demand is more 
likely to cause large changes in refresh rate that result in flickering.

Userland needs a way to let the driver know when the screen content is suitable 
for variable refresh rates.

=== DRM API to support variable refresh rates ===

This patch introduces a new API via atomic properties on the DRM connector and 
CRTC.

The drm_connector has one new optional boolean property:

* bool vrr_capable - set by the driver if the hardware is capable of supporting 
variable refresh rates

The drm_crtc has one new default boolean property:

* bool vrr_enabled - set by userspace indicating that variable refresh rate 
should be enabled

== Overview for DRM driver developers ===

Driver developers can attach the "vrr_capable" property by calling 
drm_connector_attach_vrr_capable_property(). This should be done on connectors 
that could be capable of supporting variable refresh rates (such as DP or HDMI).

The "vrr_capable" can then be updated accordingly by calling 
drm_connector_set_vrr_capable_property().

The "vrr_enabled" property can be checked from the drm_crtc_state object.

=== Overview for Userland developers ==

The "vrr_enabled" property on the CRTC should be set to true when the CRTC is 
suitable for variable refresh rates.

To demonstrate the suitability of the API for variable refresh and dynamic 
adaptation there are additional patches using this API that implement adaptive 
variable refresh across kernel and userland projects:

* DRM (dri-devel)
* amdgpu DRM kernel driver (amd-gfx)
* xf86-video-amdgpu 
(https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu)
* mesa (mesa-dev)

These patches enable adaptive variable refresh on X for AMD hardware. Support 
for variable refresh is disabled by default in xf86-video-amdgpu and will 
require additional user configuration.

The patches have been tested as working on upstream userland with the GNOME 
desktop environment under a single monitor setup. They also work on KDE in a 
single monitor setup with the compositor disabled.

The patches require that suitable applications flip via the Present extension 
to xf86-video-amdgpu for the entire Screen. Some compositors may interfere with 
this if they are unable to unredirect the window.

Full implementation details for these changes can be reviewed in their 
respective mailing lists and the xf86-video-amdgpu GitLab.

=== Previous discussions ===

These patches are based upon feedback from previous threads on the subject. 
These are linked below for reference:

https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html
https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html

Re: [Mesa-dev] [PATCH v2] radeonsi: fix a radeon kernel clear state error

[Michel Dänzer]

On 2018-10-19 4:45 p.m., Jiang, Sonny wrote:
> Signed-off-by: Sonny Jiang 

Something like

radeonsi: Disable clear state with radeon kernel driver

might be a better shortlog. Also, please add

Fixes: f243980f2c1e "radeonsi:optimizing SET_CONTEXT_REG for shaders VS"

to the commit log.


> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 9d25748df4..a82171c2dc 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -991,8 +991,10 @@ struct pipe_screen *radeonsi_screen_create(struct 
> radeon_winsys *ws,
>   }
>  
>   /* The mere presense of CLEAR_STATE in the IB causes random GPU hangs
> -  * on SI. */
> - sscreen->has_clear_state = sscreen->info.chip_class >= CIK;
> +  * on SI. Some CLEAR_STATE cause asic hang on radeon kernel, etc.
> +  * SPI_VS_OUT_CONFIG. So only enable CI CLEAR_STATE on amdgpu kernel.*/

"SPI_VS_OUT_CONFIG." looks like a leftover.


Anyway,

Tested-by: Michel Dänzer 

Thanks!


-- 
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] scons: Remove gles option.

[Jose Fonseca]

SCons never had parity with autoconf.  It never gained enough traction 
to replace autoconf, so it become this thing which is mostly use by 
VMware and others who care about Windows.


Maybe one day meson will replace SCons.  But I certainly have no plans 
to have scons replace anything anymore.


Jose

On 19/10/18 16:28, Liviu Prodea wrote:








On Friday, October 19, 2018, 6:04:28 PM GMT+3, Liviu Prodea 
 wrote:








I think I found autotools build equivalent for gles=y. It is 
--enable-shared-glapi. And the docs say it is needed to support applications 
that mix OpenGL and OpenGL ES:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mesa3d.org%2Fegl.htmldata=02%7C01%7Cjfonseca%40vmware.com%7C94ebe6edaed045e7fbc008d635d77afe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636755596930665492sdata=tjgrqRqwIRY8wcfCaaV3v3lsP8kbnjlb%2B2WG%2FxfE3Sk%3Dreserved=0

and Meson equivalent is shared-glapi:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fblob%2Fmaster%2Fmeson_options.txtdata=02%7C01%7Cjfonseca%40vmware.com%7C94ebe6edaed045e7fbc008d635d77afe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636755596930665492sdata=pBeisAPjw5OWraF36VHD%2FHStVKFJDuznhc%2BoNKLQ8tg%3Dreserved=0

Apparently Scons is the only build system that has gles=no default. The other 2 
actively maintained build systems have both equivalent options default to true.
-


On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul  
wrote:





Reviewed-by: Brian Paul 

On 10/19/2018 06:33 AM, Jose Fonseca wrote:

It's broken, and WGL state tracker is always built with GLES support
noawadays.
---
   common.py                                    | 2 --
   src/SConscript                              | 7 ---
   src/gallium/state_trackers/osmesa/SConscript | 4 +---
   src/gallium/state_trackers/wgl/SConscript    | 4 +---
   src/gallium/targets/libgl-gdi/SConscript    | 6 --
   src/gallium/targets/libgl-xlib/SConscript    | 6 --
   src/mapi/glapi/SConscript                    | 6 +-
   src/mapi/shared-glapi/SConscript            | 9 +
   src/mesa/SConscript                          | 4 +---
   src/mesa/drivers/osmesa/SConscript          | 4 +---
   10 files changed, 6 insertions(+), 46 deletions(-)

diff --git a/common.py b/common.py
index 113fc7f5c12..f4f2bb44c1c 100644
--- a/common.py
+++ b/common.py
@@ -99,8 +99,6 @@ def AddOptions(opts):
                           'enable static code analysis where available', 'no'))
       opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
       opts.Add('toolchain', 'compiler toolchain', default_toolchain)
-    opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
-                        'no'))
       opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
       opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
(swrast)',
                           'no'))
diff --git a/src/SConscript b/src/SConscript
index 95ea061c4bb..54350a9cdcc 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
   if env['platform'] != 'windows':
       SConscript('loader/SConscript')
   
-# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are not

-# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
-# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
-# enable OpenGL ES support.
   SConscript('mapi/glapi/gen/SConscript')
   SConscript('mapi/glapi/SConscript')
   
@@ -61,8 +57,5 @@ if not env['embedded']:

       if env['platform'] == 'haiku':
           SConscript('egl/SConscript')
   
-    if env['gles']:

-        SConscript('mapi/shared-glapi/SConscript')
-
   SConscript('gallium/SConscript')
   
diff --git a/src/gallium/state_trackers/osmesa/SConscript b/src/gallium/state_trackers/osmesa/SConscript

index f5519f13762..be67d0fe739 100644
--- a/src/gallium/state_trackers/osmesa/SConscript
+++ b/src/gallium/state_trackers/osmesa/SConscript
@@ -14,10 +14,8 @@ if env['platform'] == 'windows':
       env.AppendUnique(CPPDEFINES = [
           'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
           'WIN32_LEAN_AND_MEAN', # 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmsdn2.microsoft.com%2Fen-us%2Flibrary%2F6dwk3a1z.aspxdata=02%7C01%7Cjfonseca%40vmware.com%7C94ebe6edaed045e7fbc008d635d77afe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636755596930665492sdata=keOzo6Ret8LKwXsSFEWGZlrBf0I6UsfjTbMDh12ujaw%3Dreserved=0
+        '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
__declspec(dllimport)
       ])
-    if not env['gles']:
-        # prevent _glapi_* from being declared __declspec(dllimport)
-        env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
   
   st_osmesa = 

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

[Roland Scheidegger]

Looks alright to me, if it's broken anyway.

Reviewed-by: Roland Scheidegger 

Am 19.10.18 um 14:33 schrieb Jose Fonseca:
> It's broken, and WGL state tracker is always built with GLES support
> noawadays.
> ---
>  common.py| 2 --
>  src/SConscript   | 7 ---
>  src/gallium/state_trackers/osmesa/SConscript | 4 +---
>  src/gallium/state_trackers/wgl/SConscript| 4 +---
>  src/gallium/targets/libgl-gdi/SConscript | 6 --
>  src/gallium/targets/libgl-xlib/SConscript| 6 --
>  src/mapi/glapi/SConscript| 6 +-
>  src/mapi/shared-glapi/SConscript | 9 +
>  src/mesa/SConscript  | 4 +---
>  src/mesa/drivers/osmesa/SConscript   | 4 +---
>  10 files changed, 6 insertions(+), 46 deletions(-)
> 
> diff --git a/common.py b/common.py
> index 113fc7f5c12..f4f2bb44c1c 100644
> --- a/common.py
> +++ b/common.py
> @@ -99,8 +99,6 @@ def AddOptions(opts):
>  'enable static code analysis where available', 'no'))
>  opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
>  opts.Add('toolchain', 'compiler toolchain', default_toolchain)
> -opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
> -'no'))
>  opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
>  opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
> (swrast)',
>  'no'))
> diff --git a/src/SConscript b/src/SConscript
> index 95ea061c4bb..54350a9cdcc 100644
> --- a/src/SConscript
> +++ b/src/SConscript
> @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
>  if env['platform'] != 'windows':
>  SConscript('loader/SConscript')
>  
> -# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are 
> not
> -# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
> -# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
> -# enable OpenGL ES support.
>  SConscript('mapi/glapi/gen/SConscript')
>  SConscript('mapi/glapi/SConscript')
>  
> @@ -61,8 +57,5 @@ if not env['embedded']:
>  if env['platform'] == 'haiku':
>  SConscript('egl/SConscript')
>  
> -if env['gles']:
> -SConscript('mapi/shared-glapi/SConscript')
> -
>  SConscript('gallium/SConscript')
>  
> diff --git a/src/gallium/state_trackers/osmesa/SConscript 
> b/src/gallium/state_trackers/osmesa/SConscript
> index f5519f13762..be67d0fe739 100644
> --- a/src/gallium/state_trackers/osmesa/SConscript
> +++ b/src/gallium/state_trackers/osmesa/SConscript
> @@ -14,10 +14,8 @@ if env['platform'] == 'windows':
>  env.AppendUnique(CPPDEFINES = [
>  'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>  'WIN32_LEAN_AND_MEAN', # 
> http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>  ])
> -if not env['gles']:
> -# prevent _glapi_* from being declared __declspec(dllimport)
> -env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>  
>  st_osmesa = env.ConvenienceLibrary(
>  target ='st_osmesa',
> diff --git a/src/gallium/state_trackers/wgl/SConscript 
> b/src/gallium/state_trackers/wgl/SConscript
> index a7fbb07a89a..bbf5ebd9764 100644
> --- a/src/gallium/state_trackers/wgl/SConscript
> +++ b/src/gallium/state_trackers/wgl/SConscript
> @@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [
>  '_GDI32_', # prevent wgl* being declared __declspec(dllimport)
>  'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>  'WIN32_LEAN_AND_MEAN', # 
> http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>  ])
> -if not env['gles']:
> -# prevent _glapi_* from being declared __declspec(dllimport)
> -env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>  
>  wgl = env.ConvenienceLibrary(
>  target ='wgl',
> diff --git a/src/gallium/targets/libgl-gdi/SConscript 
> b/src/gallium/targets/libgl-gdi/SConscript
> index 132cb73358d..94feca24ef3 100644
> --- a/src/gallium/targets/libgl-gdi/SConscript
> +++ b/src/gallium/targets/libgl-gdi/SConscript
> @@ -48,12 +48,6 @@ else:
>  
>  env['no_import_lib'] = 1
>  
> -# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and
> -# shared_glapi respectively
> -if env['gles']:
> -env.Prepend(LIBPATH = [shared_glapi.dir])
> -glapi = [bridge_glapi, 'libglapi']
> -
>  opengl32 = env.SharedLibrary(
>  target ='opengl32',
>  source = sources,
> diff --git a/src/gallium/targets/libgl-xlib/SConscript 
> b/src/gallium/targets/libgl-xlib/SConscript
> index fb7a0ce50e3..b49b4e6fe2a 100644
> --- a/src/gallium/targets/libgl-xlib/SConscript
> +++ b/src/gallium/targets/libgl-xlib/SConscript
> @@ -18,12 +18,6 @@ env.Append(CPPDEFINES = 

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

[Liviu Prodea]

On Friday, October 19, 2018, 6:04:28 PM GMT+3, Liviu Prodea 
 wrote: 








I think I found autotools build equivalent for gles=y. It is 
--enable-shared-glapi. And the docs say it is needed to support applications 
that mix OpenGL and OpenGL ES:

https://www.mesa3d.org/egl.html

and Meson equivalent is shared-glapi:

https://gitlab.freedesktop.org/mesa/mesa/blob/master/meson_options.txt

Apparently Scons is the only build system that has gles=no default. The other 2 
actively maintained build systems have both equivalent options default to true. 
-


On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul  
wrote: 





Reviewed-by: Brian Paul 

On 10/19/2018 06:33 AM, Jose Fonseca wrote:
> It's broken, and WGL state tracker is always built with GLES support
> noawadays.
> ---
>  common.py                                    | 2 --
>  src/SConscript                              | 7 ---
>  src/gallium/state_trackers/osmesa/SConscript | 4 +---
>  src/gallium/state_trackers/wgl/SConscript    | 4 +---
>  src/gallium/targets/libgl-gdi/SConscript    | 6 --
>  src/gallium/targets/libgl-xlib/SConscript    | 6 --
>  src/mapi/glapi/SConscript                    | 6 +-
>  src/mapi/shared-glapi/SConscript            | 9 +
>  src/mesa/SConscript                          | 4 +---
>  src/mesa/drivers/osmesa/SConscript          | 4 +---
>  10 files changed, 6 insertions(+), 46 deletions(-)
> 
> diff --git a/common.py b/common.py
> index 113fc7f5c12..f4f2bb44c1c 100644
> --- a/common.py
> +++ b/common.py
> @@ -99,8 +99,6 @@ def AddOptions(opts):
>                          'enable static code analysis where available', 'no'))
>      opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
>      opts.Add('toolchain', 'compiler toolchain', default_toolchain)
> -    opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
> -                        'no'))
>      opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
>      opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
>(swrast)',
>                          'no'))
> diff --git a/src/SConscript b/src/SConscript
> index 95ea061c4bb..54350a9cdcc 100644
> --- a/src/SConscript
> +++ b/src/SConscript
> @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
>  if env['platform'] != 'windows':
>      SConscript('loader/SConscript')
>  
> -# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are 
> not
> -# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
> -# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
> -# enable OpenGL ES support.
>  SConscript('mapi/glapi/gen/SConscript')
>  SConscript('mapi/glapi/SConscript')
>  
> @@ -61,8 +57,5 @@ if not env['embedded']:
>      if env['platform'] == 'haiku':
>          SConscript('egl/SConscript')
>  
> -    if env['gles']:
> -        SConscript('mapi/shared-glapi/SConscript')
> -
>  SConscript('gallium/SConscript')
>  
> diff --git a/src/gallium/state_trackers/osmesa/SConscript 
> b/src/gallium/state_trackers/osmesa/SConscript
> index f5519f13762..be67d0fe739 100644
> --- a/src/gallium/state_trackers/osmesa/SConscript
> +++ b/src/gallium/state_trackers/osmesa/SConscript
> @@ -14,10 +14,8 @@ if env['platform'] == 'windows':
>      env.AppendUnique(CPPDEFINES = [
>          'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>          'WIN32_LEAN_AND_MEAN', # 
>http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +        '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>      ])
> -    if not env['gles']:
> -        # prevent _glapi_* from being declared __declspec(dllimport)
> -        env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>  
>  st_osmesa = env.ConvenienceLibrary(
>      target ='st_osmesa',
> diff --git a/src/gallium/state_trackers/wgl/SConscript 
> b/src/gallium/state_trackers/wgl/SConscript
> index a7fbb07a89a..bbf5ebd9764 100644
> --- a/src/gallium/state_trackers/wgl/SConscript
> +++ b/src/gallium/state_trackers/wgl/SConscript
> @@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [
>      '_GDI32_', # prevent wgl* being declared __declspec(dllimport)
>      'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>      'WIN32_LEAN_AND_MEAN', # 
>http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +    '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>  ])
> -if not env['gles']:
> -    # prevent _glapi_* from being declared __declspec(dllimport)
> -    env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>  
>  wgl = env.ConvenienceLibrary(
>      target ='wgl',
> diff --git a/src/gallium/targets/libgl-gdi/SConscript 
> b/src/gallium/targets/libgl-gdi/SConscript
> index 132cb73358d..94feca24ef3 100644
> --- 

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

[Liviu Prodea]

I think I found autotools build equivalent for gles=y. It is 
--enable-shared-glapi. And the docs say it is needed to support applications 
that mix OpenGL and OpenGL ES:

https://www.mesa3d.org/egl.html

-


On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul  
wrote: 





Reviewed-by: Brian Paul 

On 10/19/2018 06:33 AM, Jose Fonseca wrote:
> It's broken, and WGL state tracker is always built with GLES support
> noawadays.
> ---
>  common.py                                    | 2 --
>  src/SConscript                              | 7 ---
>  src/gallium/state_trackers/osmesa/SConscript | 4 +---
>  src/gallium/state_trackers/wgl/SConscript    | 4 +---
>  src/gallium/targets/libgl-gdi/SConscript    | 6 --
>  src/gallium/targets/libgl-xlib/SConscript    | 6 --
>  src/mapi/glapi/SConscript                    | 6 +-
>  src/mapi/shared-glapi/SConscript            | 9 +
>  src/mesa/SConscript                          | 4 +---
>  src/mesa/drivers/osmesa/SConscript          | 4 +---
>  10 files changed, 6 insertions(+), 46 deletions(-)
> 
> diff --git a/common.py b/common.py
> index 113fc7f5c12..f4f2bb44c1c 100644
> --- a/common.py
> +++ b/common.py
> @@ -99,8 +99,6 @@ def AddOptions(opts):
>                          'enable static code analysis where available', 'no'))
>      opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
>      opts.Add('toolchain', 'compiler toolchain', default_toolchain)
> -    opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
> -                        'no'))
>      opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
>      opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
>(swrast)',
>                          'no'))
> diff --git a/src/SConscript b/src/SConscript
> index 95ea061c4bb..54350a9cdcc 100644
> --- a/src/SConscript
> +++ b/src/SConscript
> @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
>  if env['platform'] != 'windows':
>      SConscript('loader/SConscript')
>  
> -# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are 
> not
> -# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
> -# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
> -# enable OpenGL ES support.
>  SConscript('mapi/glapi/gen/SConscript')
>  SConscript('mapi/glapi/SConscript')
>  
> @@ -61,8 +57,5 @@ if not env['embedded']:
>      if env['platform'] == 'haiku':
>          SConscript('egl/SConscript')
>  
> -    if env['gles']:
> -        SConscript('mapi/shared-glapi/SConscript')
> -
>  SConscript('gallium/SConscript')
>  
> diff --git a/src/gallium/state_trackers/osmesa/SConscript 
> b/src/gallium/state_trackers/osmesa/SConscript
> index f5519f13762..be67d0fe739 100644
> --- a/src/gallium/state_trackers/osmesa/SConscript
> +++ b/src/gallium/state_trackers/osmesa/SConscript
> @@ -14,10 +14,8 @@ if env['platform'] == 'windows':
>      env.AppendUnique(CPPDEFINES = [
>          'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>          'WIN32_LEAN_AND_MEAN', # 
>http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +        '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>      ])
> -    if not env['gles']:
> -        # prevent _glapi_* from being declared __declspec(dllimport)
> -        env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>  
>  st_osmesa = env.ConvenienceLibrary(
>      target ='st_osmesa',
> diff --git a/src/gallium/state_trackers/wgl/SConscript 
> b/src/gallium/state_trackers/wgl/SConscript
> index a7fbb07a89a..bbf5ebd9764 100644
> --- a/src/gallium/state_trackers/wgl/SConscript
> +++ b/src/gallium/state_trackers/wgl/SConscript
> @@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [
>      '_GDI32_', # prevent wgl* being declared __declspec(dllimport)
>      'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>      'WIN32_LEAN_AND_MEAN', # 
>http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +    '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>  ])
> -if not env['gles']:
> -    # prevent _glapi_* from being declared __declspec(dllimport)
> -    env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>  
>  wgl = env.ConvenienceLibrary(
>      target ='wgl',
> diff --git a/src/gallium/targets/libgl-gdi/SConscript 
> b/src/gallium/targets/libgl-gdi/SConscript
> index 132cb73358d..94feca24ef3 100644
> --- a/src/gallium/targets/libgl-gdi/SConscript
> +++ b/src/gallium/targets/libgl-gdi/SConscript
> @@ -48,12 +48,6 @@ else:
>  
>  env['no_import_lib'] = 1
>  
> -# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and
> -# shared_glapi respectively
> -if env['gles']:
> -    env.Prepend(LIBPATH = [shared_glapi.dir])
> -    glapi = [bridge_glapi, 'libglapi']
> -
>  opengl32 = 

[Mesa-dev] [PATCH v2] radeonsi: fix a radeon kernel clear state error

[Jiang, Sonny]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_pipe.c  | 6 --
 src/gallium/drivers/radeonsi/si_state.c | 5 +++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9d25748df4..a82171c2dc 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -991,8 +991,10 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
}
 
/* The mere presense of CLEAR_STATE in the IB causes random GPU hangs
-* on SI. */
-   sscreen->has_clear_state = sscreen->info.chip_class >= CIK;
+* on SI. Some CLEAR_STATE cause asic hang on radeon kernel, etc.
+* SPI_VS_OUT_CONFIG. So only enable CI CLEAR_STATE on amdgpu kernel.*/
+   sscreen->has_clear_state = sscreen->info.chip_class >= CIK &&
+  sscreen->info.drm_major == 3;
 
sscreen->has_distributed_tess =
sscreen->info.chip_class >= VI &&
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 8b2e6e57f4..cd43276b50 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -4899,8 +4899,9 @@ static void si_init_config(struct si_context *sctx)
bool has_clear_state = sscreen->has_clear_state;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
 
-   /* Only SI can disable CLEAR_STATE for now. */
-   assert(has_clear_state || sscreen->info.chip_class == SI);
+   /* SI, radeon kernel disabled CLEAR_STATE. */
+   assert(has_clear_state || sscreen->info.chip_class == SI ||
+  sscreen->info.drm_major != 3);
 
if (!pm4)
return;
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108498] ir_dereference_record nullptr segfault in radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108498

--- Comment #3 from cla...@mathr.co.uk ---
Created attachment 142096
  --> https://bugs.freedesktop.org/attachment.cgi?id=142096=edit
processed fragment shader than glslangValidator doesn't complain about

-- 
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

[Mesa-dev] [Bug 108498] ir_dereference_record nullptr segfault in radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108498

--- Comment #2 from cla...@mathr.co.uk ---
I managed to use glslangValidator to debug the issue.  The cause was
referencing a non-existent "position" field in struct Ray (the V variable in
those functions). Replacing it with the correct field name, "origin", stopped
it crashing.  A different struct Surface has a "position" field of type vec3,
the same type as the "origin" field of struct Ray.

-- 
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] [PATCH 3/3] anv: Define trampolines as the weak functions

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 15/10/2018 04:47, Jason Ekstrand wrote:

Instead of having weak references to the anv functions and separate
trampoline functions with their own dispatch table, just make the
trampoline functions weak.  This gets rid of a dispatch table and
potentially lets the compiler delete the unused weak function.  The
end result is a reduction in the .text section of 5.7K and a reduction
in the .data section of 1.4K.

Before:

text   data bss dec hex filename
3190329  2822328960 3481521  351fb1 _install/lib64/libvulkan_intel.so

After:

text   data bss dec hex filename
3184548  2807928960 3474300  35037c _install/lib64/libvulkan_intel.so
---
  src/intel/vulkan/anv_device.c   |  5 +-
  src/intel/vulkan/anv_entrypoints_gen.py | 65 -
  2 files changed, 21 insertions(+), 49 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index a2551452eb1..f68226217b4 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -653,12 +653,9 @@ VkResult anv_CreateInstance(
if (!anv_device_entrypoint_is_enabled(i, instance->app_info.api_version,
  >enabled_extensions, 
NULL)) {
   instance->device_dispatch.entrypoints[i] = NULL;
-  } else if (anv_device_dispatch_table.entrypoints[i] != NULL) {
- instance->device_dispatch.entrypoints[i] =
-anv_device_dispatch_table.entrypoints[i];
} else {
   instance->device_dispatch.entrypoints[i] =
-anv_tramp_device_dispatch_table.entrypoints[i];
+anv_device_dispatch_table.entrypoints[i];
}
 }
  
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py b/src/intel/vulkan/anv_entrypoints_gen.py

index 25a532fd706..792e3b6c90c 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -92,7 +92,6 @@ extern const struct anv_instance_dispatch_table 
anv_instance_dispatch_table;
  %for layer in LAYERS:
  extern const struct anv_device_dispatch_table ${layer}_device_dispatch_table;
  %endfor
-extern const struct anv_device_dispatch_table anv_tramp_device_dispatch_table;
  
  % for e in instance_entrypoints:

% if e.alias:
@@ -247,7 +246,26 @@ const struct anv_instance_dispatch_table 
anv_instance_dispatch_table = {
  % if e.guard is not None:
  #ifdef ${e.guard}
  % endif
-${e.return_type} ${e.prefixed_name(layer)}(${e.decl_params()}) 
__attribute__ ((weak));
+% if layer == 'anv':
+  ${e.return_type} __attribute__ ((weak))
+  ${e.prefixed_name('anv')}(${e.decl_params()})
+  {
+% if e.params[0].type == 'VkDevice':
+  ANV_FROM_HANDLE(anv_device, anv_device, ${e.params[0].name});
+  return anv_device->dispatch.${e.name}(${e.call_params()});
+% elif e.params[0].type == 'VkCommandBuffer':
+  ANV_FROM_HANDLE(anv_cmd_buffer, anv_cmd_buffer, ${e.params[0].name});
+  return 
anv_cmd_buffer->device->dispatch.${e.name}(${e.call_params()});
+% elif e.params[0].type == 'VkQueue':
+  ANV_FROM_HANDLE(anv_queue, anv_queue, ${e.params[0].name});
+  return anv_queue->device->dispatch.${e.name}(${e.call_params()});
+% else:
+  assert(!"Unhandled device child trampoline case: 
${e.params[0].type}");
+% endif
+  }
+% else:
+  ${e.return_type} ${e.prefixed_name(layer)}(${e.decl_params()}) 
__attribute__ ((weak));
+% endif
  % if e.guard is not None:
  #endif // ${e.guard}
  % endif
@@ -267,49 +285,6 @@ const struct anv_instance_dispatch_table 
anv_instance_dispatch_table = {
  % endfor
  
  
-/** Trampoline entrypoints for all device functions */

-
-% for e in device_entrypoints:
-  % if e.alias:
-<% continue %>
-  % endif
-  % if e.guard is not None:
-#ifdef ${e.guard}
-  % endif
-  static ${e.return_type}
-  ${e.prefixed_name('anv_tramp')}(${e.decl_params()})
-  {
-% if e.params[0].type == 'VkDevice':
-  ANV_FROM_HANDLE(anv_device, anv_device, ${e.params[0].name});
-  return anv_device->dispatch.${e.name}(${e.call_params()});
-% elif e.params[0].type == 'VkCommandBuffer':
-  ANV_FROM_HANDLE(anv_cmd_buffer, anv_cmd_buffer, ${e.params[0].name});
-  return anv_cmd_buffer->device->dispatch.${e.name}(${e.call_params()});
-% elif e.params[0].type == 'VkQueue':
-  ANV_FROM_HANDLE(anv_queue, anv_queue, ${e.params[0].name});
-  return anv_queue->device->dispatch.${e.name}(${e.call_params()});
-% else:
-  assert(!"Unhandled device child trampoline case: ${e.params[0].type}");
-% endif
-  }
-  % if e.guard is not None:
-#endif // ${e.guard}
-  % endif
-% endfor
-
-const struct anv_device_dispatch_table anv_tramp_device_dispatch_table = {
-% for e in device_entrypoints:
-  % if e.guard is not None:
-#ifdef ${e.guard}
-  % endif
-.${e.name} = ${e.prefixed_name('anv_tramp')},
-  % 

[Mesa-dev] [Bug 108498] ir_dereference_record nullptr segfault in radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108498

Danylo  changed:

   What|Removed |Added

 CC||danylo.pilia...@gmail.com

--- Comment #1 from Danylo  ---
It is probably an issue described and fixed in commit
https://gitlab.freedesktop.org/mesa/mesa/commit/6f3c7374b11299c21d829db794fad3b756af60fb

The shaders in the tarball require some post-processing so I cannot quickly
test it to confirm.

-- 
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

[Mesa-dev] [Bug 108498] ir_dereference_record nullptr segfault in radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108498

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org
  Component|Drivers/Gallium/radeonsi|glsl-compiler
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
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] [PATCH] scons: Remove gles option.

[Brian Paul]

Reviewed-by: Brian Paul 

On 10/19/2018 06:33 AM, Jose Fonseca wrote:
> It's broken, and WGL state tracker is always built with GLES support
> noawadays.
> ---
>   common.py| 2 --
>   src/SConscript   | 7 ---
>   src/gallium/state_trackers/osmesa/SConscript | 4 +---
>   src/gallium/state_trackers/wgl/SConscript| 4 +---
>   src/gallium/targets/libgl-gdi/SConscript | 6 --
>   src/gallium/targets/libgl-xlib/SConscript| 6 --
>   src/mapi/glapi/SConscript| 6 +-
>   src/mapi/shared-glapi/SConscript | 9 +
>   src/mesa/SConscript  | 4 +---
>   src/mesa/drivers/osmesa/SConscript   | 4 +---
>   10 files changed, 6 insertions(+), 46 deletions(-)
> 
> diff --git a/common.py b/common.py
> index 113fc7f5c12..f4f2bb44c1c 100644
> --- a/common.py
> +++ b/common.py
> @@ -99,8 +99,6 @@ def AddOptions(opts):
>   'enable static code analysis where available', 
> 'no'))
>   opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
>   opts.Add('toolchain', 'compiler toolchain', default_toolchain)
> -opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
> -'no'))
>   opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
>   opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
> (swrast)',
>   'no'))
> diff --git a/src/SConscript b/src/SConscript
> index 95ea061c4bb..54350a9cdcc 100644
> --- a/src/SConscript
> +++ b/src/SConscript
> @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
>   if env['platform'] != 'windows':
>   SConscript('loader/SConscript')
>   
> -# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are 
> not
> -# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
> -# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
> -# enable OpenGL ES support.
>   SConscript('mapi/glapi/gen/SConscript')
>   SConscript('mapi/glapi/SConscript')
>   
> @@ -61,8 +57,5 @@ if not env['embedded']:
>   if env['platform'] == 'haiku':
>   SConscript('egl/SConscript')
>   
> -if env['gles']:
> -SConscript('mapi/shared-glapi/SConscript')
> -
>   SConscript('gallium/SConscript')
>   
> diff --git a/src/gallium/state_trackers/osmesa/SConscript 
> b/src/gallium/state_trackers/osmesa/SConscript
> index f5519f13762..be67d0fe739 100644
> --- a/src/gallium/state_trackers/osmesa/SConscript
> +++ b/src/gallium/state_trackers/osmesa/SConscript
> @@ -14,10 +14,8 @@ if env['platform'] == 'windows':
>   env.AppendUnique(CPPDEFINES = [
>   'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>   'WIN32_LEAN_AND_MEAN', # 
> http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>   ])
> -if not env['gles']:
> -# prevent _glapi_* from being declared __declspec(dllimport)
> -env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>   
>   st_osmesa = env.ConvenienceLibrary(
>   target ='st_osmesa',
> diff --git a/src/gallium/state_trackers/wgl/SConscript 
> b/src/gallium/state_trackers/wgl/SConscript
> index a7fbb07a89a..bbf5ebd9764 100644
> --- a/src/gallium/state_trackers/wgl/SConscript
> +++ b/src/gallium/state_trackers/wgl/SConscript
> @@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [
>   '_GDI32_', # prevent wgl* being declared __declspec(dllimport)
>   'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
>   'WIN32_LEAN_AND_MEAN', # 
> http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
> +'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
> __declspec(dllimport)
>   ])
> -if not env['gles']:
> -# prevent _glapi_* from being declared __declspec(dllimport)
> -env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
>   
>   wgl = env.ConvenienceLibrary(
>   target ='wgl',
> diff --git a/src/gallium/targets/libgl-gdi/SConscript 
> b/src/gallium/targets/libgl-gdi/SConscript
> index 132cb73358d..94feca24ef3 100644
> --- a/src/gallium/targets/libgl-gdi/SConscript
> +++ b/src/gallium/targets/libgl-gdi/SConscript
> @@ -48,12 +48,6 @@ else:
>   
>   env['no_import_lib'] = 1
>   
> -# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and
> -# shared_glapi respectively
> -if env['gles']:
> -env.Prepend(LIBPATH = [shared_glapi.dir])
> -glapi = [bridge_glapi, 'libglapi']
> -
>   opengl32 = env.SharedLibrary(
>   target ='opengl32',
>   source = sources,
> diff --git a/src/gallium/targets/libgl-xlib/SConscript 
> b/src/gallium/targets/libgl-xlib/SConscript
> index fb7a0ce50e3..b49b4e6fe2a 100644
> --- a/src/gallium/targets/libgl-xlib/SConscript
> +++ b/src/gallium/targets/libgl-xlib/SConscript
> @@ -18,12 +18,6 @@ env.Append(CPPDEFINES = 

Re: [Mesa-dev] [PATCH] radv: Fix WSI & PCI bus info initialization order.

[Jason Ekstrand]

Rb

On October 19, 2018 04:54:14 Bas Nieuwenhuizen  wrote:


Trying to access the bus info before it is initialized is not going
to work.

Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
---
src/amd/vulkan/radv_device.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index e7d511bdb97..cf1132098d2 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -379,6 +379,15 @@ radv_physical_device_init(struct radv_physical_device 
*device,

radv_physical_device_init_mem_types(device);
radv_fill_device_extension_table(device, >supported_extensions);

+   device->bus_info = *drm_device->businfo.pci;
+
+   if ((device->instance->debug_flags & RADV_DEBUG_INFO))
+   ac_print_gpu_info(>rad_info);
+
+   /* The WSI is structured as a layer on top of the driver, so this has
+* to be the last part of initialization (at least until we get other
+* semi-layers).
+*/
result = radv_init_wsi(device);
if (result != VK_SUCCESS) {
device->ws->destroy(device->ws);
@@ -386,10 +395,6 @@ radv_physical_device_init(struct radv_physical_device 
*device,

goto fail;
}

-   if ((device->instance->debug_flags & RADV_DEBUG_INFO))
-   ac_print_gpu_info(>rad_info);
-
-   device->bus_info = *drm_device->businfo.pci;
return VK_SUCCESS;

fail:
--
2.19.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 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Bas Nieuwenhuizen  ---
Fixed:

commit 68c7833540fabea3d7af8eb470522e6403354e20
Author: Bas Nieuwenhuizen 
Date:   Fri Oct 19 11:51:47 2018 +0200

radv: Fix WSI & PCI bus info initialization order.

Trying to access the bus info before it is initialized is not going
to work.

Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd
matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
Reviewed-by: Samuel Pitoiset 
Tested-by: Andre Heider 

-- 
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

[Mesa-dev] [PATCH] scons: Remove gles option.

[Jose Fonseca]

It's broken, and WGL state tracker is always built with GLES support
noawadays.
---
 common.py| 2 --
 src/SConscript   | 7 ---
 src/gallium/state_trackers/osmesa/SConscript | 4 +---
 src/gallium/state_trackers/wgl/SConscript| 4 +---
 src/gallium/targets/libgl-gdi/SConscript | 6 --
 src/gallium/targets/libgl-xlib/SConscript| 6 --
 src/mapi/glapi/SConscript| 6 +-
 src/mapi/shared-glapi/SConscript | 9 +
 src/mesa/SConscript  | 4 +---
 src/mesa/drivers/osmesa/SConscript   | 4 +---
 10 files changed, 6 insertions(+), 46 deletions(-)

diff --git a/common.py b/common.py
index 113fc7f5c12..f4f2bb44c1c 100644
--- a/common.py
+++ b/common.py
@@ -99,8 +99,6 @@ def AddOptions(opts):
 'enable static code analysis where available', 'no'))
 opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
 opts.Add('toolchain', 'compiler toolchain', default_toolchain)
-opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
-'no'))
 opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
 opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp (swrast)',
 'no'))
diff --git a/src/SConscript b/src/SConscript
index 95ea061c4bb..54350a9cdcc 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
 if env['platform'] != 'windows':
 SConscript('loader/SConscript')
 
-# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are not
-# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
-# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
-# enable OpenGL ES support.
 SConscript('mapi/glapi/gen/SConscript')
 SConscript('mapi/glapi/SConscript')
 
@@ -61,8 +57,5 @@ if not env['embedded']:
 if env['platform'] == 'haiku':
 SConscript('egl/SConscript')
 
-if env['gles']:
-SConscript('mapi/shared-glapi/SConscript')
-
 SConscript('gallium/SConscript')
 
diff --git a/src/gallium/state_trackers/osmesa/SConscript 
b/src/gallium/state_trackers/osmesa/SConscript
index f5519f13762..be67d0fe739 100644
--- a/src/gallium/state_trackers/osmesa/SConscript
+++ b/src/gallium/state_trackers/osmesa/SConscript
@@ -14,10 +14,8 @@ if env['platform'] == 'windows':
 env.AppendUnique(CPPDEFINES = [
 'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
 'WIN32_LEAN_AND_MEAN', # 
http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
+'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
__declspec(dllimport)
 ])
-if not env['gles']:
-# prevent _glapi_* from being declared __declspec(dllimport)
-env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
 
 st_osmesa = env.ConvenienceLibrary(
 target ='st_osmesa',
diff --git a/src/gallium/state_trackers/wgl/SConscript 
b/src/gallium/state_trackers/wgl/SConscript
index a7fbb07a89a..bbf5ebd9764 100644
--- a/src/gallium/state_trackers/wgl/SConscript
+++ b/src/gallium/state_trackers/wgl/SConscript
@@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [
 '_GDI32_', # prevent wgl* being declared __declspec(dllimport)
 'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
 'WIN32_LEAN_AND_MEAN', # 
http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
+'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
__declspec(dllimport)
 ])
-if not env['gles']:
-# prevent _glapi_* from being declared __declspec(dllimport)
-env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
 
 wgl = env.ConvenienceLibrary(
 target ='wgl',
diff --git a/src/gallium/targets/libgl-gdi/SConscript 
b/src/gallium/targets/libgl-gdi/SConscript
index 132cb73358d..94feca24ef3 100644
--- a/src/gallium/targets/libgl-gdi/SConscript
+++ b/src/gallium/targets/libgl-gdi/SConscript
@@ -48,12 +48,6 @@ else:
 
 env['no_import_lib'] = 1
 
-# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and
-# shared_glapi respectively
-if env['gles']:
-env.Prepend(LIBPATH = [shared_glapi.dir])
-glapi = [bridge_glapi, 'libglapi']
-
 opengl32 = env.SharedLibrary(
 target ='opengl32',
 source = sources,
diff --git a/src/gallium/targets/libgl-xlib/SConscript 
b/src/gallium/targets/libgl-xlib/SConscript
index fb7a0ce50e3..b49b4e6fe2a 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -18,12 +18,6 @@ env.Append(CPPDEFINES = ['USE_XSHM'])
 env.Prepend(LIBS = env['X11_LIBS'])
 env.Prepend(LIBPATH = env['X11_LIBPATH'])
 
-# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and
-# shared_glapi respectively
-if env['gles']:
-env.Prepend(LIBPATH = [shared_glapi.dir])
-glapi = [bridge_glapi, 'glapi']
-
 env.Prepend(LIBS = [
 st_xlib,
 ws_xlib,
diff --git 

Re: [Mesa-dev] [PATCH v3 2/3] mesa/st: enable EXT_sRGB_write_control for drivers that support it

[Ilia Mirkin]

I don't think a PIPE_CAP is the answer here... I think you're on the
right track with format checks and whatnot.
On Fri, Oct 19, 2018 at 2:54 AM Gert Wollny  wrote:
>
> Considering how virgl has to deal with host capabilities the extension
> should be enabled via a CAP, so I'll rework this patch another time.
>
> Sorry for being so noisy,
> Gert
>
>
> Am Donnerstag, den 18.10.2018, 18:39 +0200 schrieb Gert Wollny:
> > From: Gert Wollny 
> >
> > With this patch the extension EXT_sRGB_write_control is enabled for
> > gallium drivers that support sRGB formats as render targets.
> >
> > Tested (and pass) on r600 (evergreen) and softpipe:
> >
> >   dEQP-
> > GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
> >
> > with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for
> > this), and
> >
> >   dEQP-
> > GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported
> > _enum
> >
> > when extension is manually disabled via MESA_EXTENSION_OVERRIDE
> >
> > v2: - always enable the extension when sRGB is supported (Ilia
> > Mirkin).
> > - Correct handling by moving extension initialization to the
> >   place where gallium/st actually takes care of this. This also
> >   fixes properly disabling the extension via
> > MESA_EXTENSION_OVERRIDE
> > - reinstate check for desktop GL and add check for the extension
> >   when creating the framebuffer
> >
> > v3: Only create sRGB renderbuffers based on Visual.srgbCapable when
> > on desktop GL.
> >
> > Signed-off-by: Gert Wollny 
> > ---
> >  src/mesa/state_tracker/st_extensions.c |  6 +
> >  src/mesa/state_tracker/st_manager.c| 37 --
> > 
> >  2 files changed, 29 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c
> > b/src/mesa/state_tracker/st_extensions.c
> > index 798ee60875..401609d728 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -1169,6 +1169,12 @@ void st_init_extensions(struct pipe_screen
> > *screen,
> >   void_formats, 32,
> >   PIPE_BIND_RENDER_TARGET);
> >
> > +  extensions->EXT_sRGB_write_control =
> > + screen->is_format_supported(screen,
> > PIPE_FORMAT_R8G8B8A8_SRGB,
> > + PIPE_TEXTURE_2D, 0, 0,
> > + (PIPE_BIND_DISPLAY_TARGET |
> > +  PIPE_BIND_RENDER_TARGET));
> > +
> >if (extensions->AMD_framebuffer_multisample_advanced) {
> >   /* AMD_framebuffer_multisample_advanced */
> >   /* This can be greater than storage samples. */
> > diff --git a/src/mesa/state_tracker/st_manager.c
> > b/src/mesa/state_tracker/st_manager.c
> > index ceb48dd490..df898beb23 100644
> > --- a/src/mesa/state_tracker/st_manager.c
> > +++ b/src/mesa/state_tracker/st_manager.c
> > @@ -295,7 +295,7 @@ st_framebuffer_update_attachments(struct
> > st_framebuffer *stfb)
> >   */
> >  static boolean
> >  st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
> > -gl_buffer_index idx)
> > +gl_buffer_index idx, bool
> > prefer_srgb)
> >  {
> > struct gl_renderbuffer *rb;
> > enum pipe_format format;
> > @@ -318,7 +318,7 @@ st_framebuffer_add_renderbuffer(struct
> > st_framebuffer *stfb,
> >break;
> > default:
> >format = stfb->iface->visual->color_format;
> > -  if (stfb->Base.Visual.sRGBCapable)
> > +  if (prefer_srgb)
> >   format = util_format_srgb(format);
> >sw = FALSE;
> >break;
> > @@ -436,6 +436,7 @@ st_framebuffer_create(struct st_context *st,
> > struct st_framebuffer *stfb;
> > struct gl_config mode;
> > gl_buffer_index idx;
> > +   bool prefer_srgb = false;
> >
> > if (!stfbi)
> >return NULL;
> > @@ -457,14 +458,15 @@ st_framebuffer_create(struct st_context *st,
> >  * format such that util_format_srgb(visual->color_format) can be
> > supported
> >  * by the pipe driver.  We still need to advertise the capability
> > here.
> >  *
> > -* For GLES, however, sRGB framebuffer write is controlled only
> > by the
> > -* capability of the framebuffer.  There is
> > GL_EXT_sRGB_write_control to
> > -* give applications the control back, but sRGB write is still
> > enabled by
> > -* default.  To avoid unexpected results, we should not advertise
> > the
> > -* capability.  This could change when we add support for
> > -* EGL_KHR_gl_colorspace.
> > +* For GLES, however, sRGB framebuffer write is initially only
> > controlled
> > +* by the capability of the framebuffer, with
> > GL_EXT_sRGB_write_control
> > +* control is given back to the applications, but
> > GL_FRAMEBUFFER_SRGB is
> > +* still enabled by default since this is the behaviour when
> > +* EXT_sRGB_write_control 

Re: [Mesa-dev] [PATCH] nv50, nvc0: warn on not-explicitly-handled caps

[Ilia Mirkin]

On Fri, Oct 19, 2018 at 6:32 AM Gert Wollny  wrote:
>
> Am Donnerstag, den 06.09.2018, 22:36 -0400 schrieb Ilia Mirkin:
> > Not handling caps explicitly means that we're likely getting
> > incorrect values -- these need to be reviewed and set appropriately.
> >
> > While we're at it, add in some missing caps, and set all the subpixel
> > stuff to 8 as that seems to be what the blob reports.
> >
> > Signed-off-by: Ilia Mirkin 
> > ---
> >  src/gallium/drivers/nouveau/nv50/nv50_screen.c | 16 +++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 24 +++-
> > 
> >  2 files changed, 26 insertions(+), 14 deletions(-)
> >
> >
> [...]
> > @@ -341,6 +346,7 @@ nvc0_screen_get_param(struct pipe_screen
> > *pscreen, enum pipe_cap param)
> > case PIPE_CAP_UMA:
> >return 0;
> > default:
> > +  debug_printf("%s: unhandled cap %d\n", __func__, param);
> >return u_pipe_screen_get_param_defaults(pscreen, param);
> > }
> >  }
>
> I understand your reasoning here, because with each new cap introduced
> one should check for each driver whether the default is appropriate, or
> whether a special handling is needed, but then it might be better to
> remove the "default:" statement and move the call to
> u_pipe_screen_get_param_defaults after the switch statement. This way
> you will get a warning about the unhandled switch case at compile time
> and see that you have to handle this without having to run some program
> that happens to trigger the cap (You could also keep the debug
> statement before this if you deem it necessary).

People got annoyed by having to edit every driver. The default
statement takes care of that.

I wanted to be notified when new caps were added so I could evaluate
how they needed to be set on nouveau.

I think the current situation works out nicely...

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nv50, nvc0: warn on not-explicitly-handled caps

[Gert Wollny]

Am Donnerstag, den 06.09.2018, 22:36 -0400 schrieb Ilia Mirkin:
> Not handling caps explicitly means that we're likely getting
> incorrect values -- these need to be reviewed and set appropriately.
> 
> While we're at it, add in some missing caps, and set all the subpixel
> stuff to 8 as that seems to be what the blob reports.
> 
> Signed-off-by: Ilia Mirkin 
> ---
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c | 16 +++-
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 24 +++-
> 
>  2 files changed, 26 insertions(+), 14 deletions(-)
> 
> 
[...]
> @@ -341,6 +346,7 @@ nvc0_screen_get_param(struct pipe_screen
> *pscreen, enum pipe_cap param)
> case PIPE_CAP_UMA:
>return 0;
> default:
> +  debug_printf("%s: unhandled cap %d\n", __func__, param);
>return u_pipe_screen_get_param_defaults(pscreen, param);
> }
>  }

I understand your reasoning here, because with each new cap introduced
one should check for each driver whether the default is appropriate, or
whether a special handling is needed, but then it might be better to
remove the "default:" statement and move the call to 
u_pipe_screen_get_param_defaults after the switch statement. This way
you will get a warning about the unhandled switch case at compile time
and see that you have to handle this without having to run some program
that happens to trigger the cap (You could also keep the debug
statement before this if you deem it necessary). 

Best, 
Gert 




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Fix WSI & PCI bus info initialization order.

[Andre Heider]

Hi,

On 19/10/2018 11:53, Bas Nieuwenhuizen wrote:

Trying to access the bus info before it is initialized is not going
to work.

Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491


confirmed, fixes the issue I've been seeing:
Tested-by: Andre Heider 

Thanks for the quick fix,
Andre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[Kenneth Graunke]

On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote:
> On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
> > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com wrote:
> > > From: Andrii Simiklit 
> > > 
> > > I guess that when we calculating the width0, height0, depth0
> > > to use for function 'intel_miptree_create' we need to consider
> > > the 'base level' like it is done in the 
> > > 'intel_miptree_create_for_teximage'
> > > function.
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
> > > Signed-off-by: Andrii Simiklit 
> > > ---
> > >  .../drivers/dri/i965/intel_tex_validate.c | 26 ++-
> > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > 
> > I believe this patch is correct - we're assembling things into a new
> > miptree, which we start at level 0 - so we need the sizes for level 0.
> > 
> > Alternatively, we might be able to pass validate_first_level instead
> > of 0 when calling intel_miptree_create, to make one that's only good
> > up until the new base...and have to re-assemble it the next time they
> > change the base.  It would save memory potentially.  But more copies.
> > I don't have a strong preference which is better.
> > 
> > Please do make a Piglit or dEQP test for this.
> > 
> > Reviewed-by: Kenneth Graunke 
> 
> Sorry, withdrawing my review. :(  Chris Forbes pointed out on IRC that
> your reproducer case is backwards:
> 
> miplevel 0 - 1x1
> miplevel 1 - 2x2
> miplevel 2 - 4x4
> 
> That's upside down.  A proper miptree would have the base be largest:
> 
> miplevel 0 - 4x4
> miplevel 1 - 2x2
> miplevel 2 - 1x1
> 
> So, yes, I could see this tripping an assert...but such a crazy texture
> will never be mipmap complete.  If they're expecting mipmapping, then
> it seems like they should get a fallback black texture (which normally
> happens for incomplete textures).  If not, maybe they should get a
> single miplevel?  Either way, seems like we should detect insanity and
> bail, rather than change size calculations for the normal sane case.
> 

So...looked at this again.  I'm not sure why upside-down matters.

At DrawArrays time, we have a single miplevel (base = 2), and are trying
to put that single miplevel's image into a miptree.  We do properly
ignore levels 0..1 as they're beyond the base.

We appear to use level 0 as the actual base, and want to store our
single level at level 2.  Other places (TexImage) seem to work that way
too.

But, we're creating the miplevel with level 0 as the base, but where
level 0 has the dimensions of level 2.  This doesn't work.  And your
patch fixes that.

I tried making the actual base of the unified tree be level 2, rather
than level 0...so that the BaseLevel is the actual base...but tons of
things broke.

So, back to Reviewed-by.  I think once we get a Piglit test, I'm happy
to land this patch.

--Ken


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] radv: Fix WSI & PCI bus info initialization order.

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/19/18 11:53 AM, Bas Nieuwenhuizen wrote:

Trying to access the bus info before it is initialized is not going
to work.

Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
---
  src/amd/vulkan/radv_device.c | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index e7d511bdb97..cf1132098d2 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -379,6 +379,15 @@ radv_physical_device_init(struct radv_physical_device 
*device,
radv_physical_device_init_mem_types(device);
radv_fill_device_extension_table(device, >supported_extensions);
  
+	device->bus_info = *drm_device->businfo.pci;

+
+   if ((device->instance->debug_flags & RADV_DEBUG_INFO))
+   ac_print_gpu_info(>rad_info);
+
+   /* The WSI is structured as a layer on top of the driver, so this has
+* to be the last part of initialization (at least until we get other
+* semi-layers).
+*/
result = radv_init_wsi(device);
if (result != VK_SUCCESS) {
device->ws->destroy(device->ws);
@@ -386,10 +395,6 @@ radv_physical_device_init(struct radv_physical_device 
*device,
goto fail;
}
  
-	if ((device->instance->debug_flags & RADV_DEBUG_INFO))

-   ac_print_gpu_info(>rad_info);
-
-   device->bus_info = *drm_device->businfo.pci;
return VK_SUCCESS;
  
  fail:



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] meson: Add -Werror=return-type when supported.

[Eric Engestrom]

On Thursday, 2018-10-18 18:05:13 -0700, Kenneth Graunke wrote:
> This warning detects non-void functions with a missing return statement,
> return statements with a value in void functions, and functions with an
> bogus return type that ends up defaulting to int.  It's already enabled
> by default with -Wall.  Generally, these are fairly serious bugs in the
> code, which developers would like to notice and fix immediately.  This
> patch promotes it from a warning to an error, to help developers catch
> such mistakes early.
> 
> I would not expect this warning to change much based on the compiler
> version, so hopefully it won't become a problem for packagers/builders.
> 
> See the GCC documentation or 'man gcc' for more details:
> https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Warning-Options.html#index-Wreturn-type

Reviewed-by: Eric Engestrom 

> ---
>  meson.build | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 505cc6c79bd..0dfe09858bf 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -788,7 +788,8 @@ endif
>  # Check for generic C arguments
>  c_args = []
>  foreach a : ['-Wall', '-Werror=implicit-function-declaration',
> - '-Werror=missing-prototypes', '-fno-math-errno',
> + '-Werror=missing-prototypes', '-Werror=return-type',
> + '-fno-math-errno',
>   '-fno-trapping-math', '-Qunused-arguments']
>if cc.has_argument(a)
>  c_args += a
> @@ -808,7 +809,8 @@ endif
>  
>  # Check for generic C++ arguments
>  cpp_args = []
> -foreach a : ['-Wall', '-fno-math-errno', '-fno-trapping-math',
> +foreach a : ['-Wall', '-Werror=return-type',
> + '-fno-math-errno', '-fno-trapping-math',
>   '-Qunused-arguments']
>if cpp.has_argument(a)
>  cpp_args += a
> -- 
> 2.19.0
> 
> ___
> 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 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

--- Comment #5 from Bas Nieuwenhuizen  ---
Okay it looks like this fails for radv, because the wsi gets initialized before
the PCI bus info.

This should be fixed by 

https://lists.freedesktop.org/archives/mesa-dev/2018-October/207311.html

(sorry, no patchwork link as patchwork seems to be down for me)

-- 
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

[Mesa-dev] [PATCH] radv: Fix WSI & PCI bus info initialization order.

[Bas Nieuwenhuizen]

Trying to access the bus info before it is initialized is not going
to work.

Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
---
 src/amd/vulkan/radv_device.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index e7d511bdb97..cf1132098d2 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -379,6 +379,15 @@ radv_physical_device_init(struct radv_physical_device 
*device,
radv_physical_device_init_mem_types(device);
radv_fill_device_extension_table(device, >supported_extensions);
 
+   device->bus_info = *drm_device->businfo.pci;
+
+   if ((device->instance->debug_flags & RADV_DEBUG_INFO))
+   ac_print_gpu_info(>rad_info);
+
+   /* The WSI is structured as a layer on top of the driver, so this has
+* to be the last part of initialization (at least until we get other
+* semi-layers).
+*/
result = radv_init_wsi(device);
if (result != VK_SUCCESS) {
device->ws->destroy(device->ws);
@@ -386,10 +395,6 @@ radv_physical_device_init(struct radv_physical_device 
*device,
goto fail;
}
 
-   if ((device->instance->debug_flags & RADV_DEBUG_INFO))
-   ac_print_gpu_info(>rad_info);
-
-   device->bus_info = *drm_device->businfo.pci;
return VK_SUCCESS;
 
 fail:
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

--- Comment #4 from Andre Heider  ---
Not here, just one gpu and one display

-- 
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] vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching

[Andre Heider]

Hi,

On 18/10/2018 17:13, Jason Ekstrand wrote:

This lets us avoid passing the DRM fd around all over the place and gets
us closer to layer utopia.
---
  src/amd/vulkan/radv_wsi.c   |  3 --
  src/amd/vulkan/radv_wsi_x11.c   |  4 +--
  src/intel/vulkan/anv_wsi.c  |  4 +--
  src/intel/vulkan/anv_wsi_x11.c  |  4 +--
  src/vulkan/wsi/wsi_common.c | 45 +
  src/vulkan/wsi/wsi_common.h |  5 ++--
  src/vulkan/wsi/wsi_common_display.c | 22 +-
  src/vulkan/wsi/wsi_common_private.h |  6 ++--
  src/vulkan/wsi/wsi_common_wayland.c |  3 --
  src/vulkan/wsi/wsi_common_x11.c | 34 +++---
  src/vulkan/wsi/wsi_common_x11.h |  1 -
  11 files changed, 61 insertions(+), 70 deletions(-)


unfortunately this regresses radv, see
https://bugs.freedesktop.org/show_bug.cgi?id=108491

Thanks,
Andre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

--- Comment #3 from Bas Nieuwenhuizen  ---
Are any of you using a different GPU to display vs running the game? (e.g.
prime)

-- 
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

[Mesa-dev] [Bug 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

--- Comment #2 from Andre Heider  ---
Same here with wine/dxvk/radv on tonga.

The fps seems unaffected, but it looks like every n'th displayed frame is an
older one.

Reverting the commit on master fixes the issue.

-- 
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

[Mesa-dev] [Bug 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

Bug ID: 108491
   Summary: Commit baa38c14 causes output issues on my VEGA with
RADV
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mithran...@mailbox.org
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 142089
  --> https://bugs.freedesktop.org/attachment.cgi?id=142089=edit
Tomb Raider

With commit
https://gitlab.freedesktop.org/mesa/mesa/commit/baa38c144f6ab544bccabff3739631bab33e4cd7
the frame outbut is glitched on my VEGA56

-- 
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

[Mesa-dev] [Bug 108491] Commit baa38c14 causes output issues on my VEGA with RADV

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108491

--- Comment #1 from Karl  ---
Created attachment 142090
  --> https://bugs.freedesktop.org/attachment.cgi?id=142090=edit
DXVK

-- 
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] Scons/GLES: shared_glapi and osmesa link failure

[Liviu Prodea]

 I agree on the fact it is suspicious that libglapi,dll was asked for 
considering glapi is built as a static library part of opengl32.dll by default. 
If I understood correctly what gles variable does, it turns glapi into a shared 
library and that's all there is to it and probably as a side effect GLESv1 and 
GLESv2 are forced to become shared libraries too. 

I don't know what this guy did in Blender3D to trigger that, it is mostly 
suspicious. I asked him what he did to trigger it here
https://github.com/pal1000/mesa-dist-win/issues/8#issuecomment-394626971
but he actually never answered to it. The conversation sidetracked and the 
trigger was never mentioned. I wasn't able to replicate the error he 
encountered but as soon as I built glapi as a shared library he said everything 
was "fine".
I looked at Mesa code and I found these interactions between osmesa, gles build 
variable and glapi in Scons build:
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/osmesa/SConscript#L32
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/state_trackers/osmesa/SConscript#L18
---

On Friday, October 19, 2018, 12:33:21 AM GMT+3, Jose Fonseca 
 wrote:  
 
 I still can't make much sense of that github issue thread.

Applications on Windows use opengl32.dll for acceleration, not 
libEGL/libGLESv1/libGLESv2 as these are not provided by the OS.  The 
only place you see these DLLs are things like GLES -> D3D11/GL 
translators like Angle.

So the "missing glapi.dll" is a red herring IMO: the solution is not to 
somehow the build the glapi.dll but rather build mesa so it's never 
needed.  Which is what scons does by default.

What Meson does or not by default I don't know.  It might provide all 
those DLLs, but that doesn't change the fact that windows applications 
will target opengl32.dll for accelleration.


Jose

On 18/10/18 15:46, Liviu Prodea wrote:
> Well, all this started in that Github issue thread. That guy @elkhalafy 
> was using llvmpipe to get Blender 2.80 to work on his system with 
> unsupported (too old) iGPU. I don't know what he did but it resulted in 
> Blender failing with missing libglapi.dll. So I researched about how to 
> build it and it led me to this build variable gles of type boolean. When 
> set to true it builds glapi as a shared library named libglapi.dll. It 
> is also a requirement to build libGLESv1_CM.dll and libGLESv2.dll which 
> only get build when selecting all build targets or probably I wasn't 
> able to find the right target(s).
> 
> A Meson build approximation is -Dgles1=true -Dgles2=true which builds 
> all 3 DLLs and it is default unlike in Scons case,
> 
> On Thursday, October 18, 2018, 3:08:11 PM GMT+3, Jose Fonseca 
>  wrote:
> 
> 
> I don't know what gles=y entails anymore, but if it's broken we should
> simply remove it.
> 
> That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile
> extension, even without gles=y option.
> 
> So what exactly are you looking for here?
> 
> Jose
> 
> On 18/10/18 13:02, Liviu Prodea wrote:
>  > scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa
>  >
>  > Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and
>  > object build\windows-x86\mesa\drivers\osmesa\osmesa.exp
>  > osmesa.obj : error LNK2001: unresolved external symbol
>  > __imp___glapi_check_multithread
>  > osmesa.obj : error LNK2001: unresolved external symbol
>  > __imp___glapi_get_proc_address
>  > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_set_context
>  > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_set_dispatch
>  > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_set_nop_handler
>  > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_new_nop_table
>  > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_Context
>  > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_get_dispatch_table_size
>  > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_get_context
>  > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_add_dispatch
>  > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_get_dispatch
>  > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_Dispatch
>  > build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120:
>  > 12 unresolved externals
>  > scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120
>  > st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_get_proc_address
>  > mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol
>  > __imp___glapi_check_multithread
>  > mesa.lib(vbo_exec_api.obj) : 

[Mesa-dev] [Bug 108355] Civilization VI - Artifacts in mouse cursor

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108355

Michel Dänzer  changed:

   What|Removed |Added

Product|Mesa|xorg
 QA Contact|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
   |org |
  Component|Drivers/Gallium/swr |Driver/AMDgpu
   Assignee|mesa-dev@lists.freedesktop. |xorg-driver-...@lists.x.org
   |org |
Version|18.2|git

-- 
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

[Mesa-dev] [Bug 108355] Civilization VI - Artifacts in mouse cursor

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108355

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #142083|text/x-log  |text/plain
  mime type||

-- 
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 v3 2/3] mesa/st: enable EXT_sRGB_write_control for drivers that support it

[Gert Wollny]

Considering how virgl has to deal with host capabilities the extension
should be enabled via a CAP, so I'll rework this patch another time. 

Sorry for being so noisy,
Gert 


Am Donnerstag, den 18.10.2018, 18:39 +0200 schrieb Gert Wollny:
> From: Gert Wollny 
> 
> With this patch the extension EXT_sRGB_write_control is enabled for
> gallium drivers that support sRGB formats as render targets.
> 
> Tested (and pass) on r600 (evergreen) and softpipe:
> 
>   dEQP-
> GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
> 
> with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for
> this), and
> 
>   dEQP-
> GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported
> _enum
> 
> when extension is manually disabled via MESA_EXTENSION_OVERRIDE
> 
> v2: - always enable the extension when sRGB is supported (Ilia
> Mirkin).
> - Correct handling by moving extension initialization to the
>   place where gallium/st actually takes care of this. This also
>   fixes properly disabling the extension via
> MESA_EXTENSION_OVERRIDE
> - reinstate check for desktop GL and add check for the extension
>   when creating the framebuffer
> 
> v3: Only create sRGB renderbuffers based on Visual.srgbCapable when
> on desktop GL.
> 
> Signed-off-by: Gert Wollny 
> ---
>  src/mesa/state_tracker/st_extensions.c |  6 +
>  src/mesa/state_tracker/st_manager.c| 37 --
> 
>  2 files changed, 29 insertions(+), 14 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 798ee60875..401609d728 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1169,6 +1169,12 @@ void st_init_extensions(struct pipe_screen
> *screen,
>   void_formats, 32,
>   PIPE_BIND_RENDER_TARGET);
>  
> +  extensions->EXT_sRGB_write_control =
> + screen->is_format_supported(screen,
> PIPE_FORMAT_R8G8B8A8_SRGB,
> + PIPE_TEXTURE_2D, 0, 0,
> + (PIPE_BIND_DISPLAY_TARGET |
> +  PIPE_BIND_RENDER_TARGET));
> +
>if (extensions->AMD_framebuffer_multisample_advanced) {
>   /* AMD_framebuffer_multisample_advanced */
>   /* This can be greater than storage samples. */
> diff --git a/src/mesa/state_tracker/st_manager.c
> b/src/mesa/state_tracker/st_manager.c
> index ceb48dd490..df898beb23 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -295,7 +295,7 @@ st_framebuffer_update_attachments(struct
> st_framebuffer *stfb)
>   */
>  static boolean
>  st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
> -gl_buffer_index idx)
> +gl_buffer_index idx, bool
> prefer_srgb)
>  {
> struct gl_renderbuffer *rb;
> enum pipe_format format;
> @@ -318,7 +318,7 @@ st_framebuffer_add_renderbuffer(struct
> st_framebuffer *stfb,
>break;
> default:
>format = stfb->iface->visual->color_format;
> -  if (stfb->Base.Visual.sRGBCapable)
> +  if (prefer_srgb)
>   format = util_format_srgb(format);
>sw = FALSE;
>break;
> @@ -436,6 +436,7 @@ st_framebuffer_create(struct st_context *st,
> struct st_framebuffer *stfb;
> struct gl_config mode;
> gl_buffer_index idx;
> +   bool prefer_srgb = false;
>  
> if (!stfbi)
>return NULL;
> @@ -457,14 +458,15 @@ st_framebuffer_create(struct st_context *st,
>  * format such that util_format_srgb(visual->color_format) can be
> supported
>  * by the pipe driver.  We still need to advertise the capability
> here.
>  *
> -* For GLES, however, sRGB framebuffer write is controlled only
> by the
> -* capability of the framebuffer.  There is
> GL_EXT_sRGB_write_control to
> -* give applications the control back, but sRGB write is still
> enabled by
> -* default.  To avoid unexpected results, we should not advertise
> the
> -* capability.  This could change when we add support for
> -* EGL_KHR_gl_colorspace.
> +* For GLES, however, sRGB framebuffer write is initially only
> controlled
> +* by the capability of the framebuffer, with
> GL_EXT_sRGB_write_control
> +* control is given back to the applications, but
> GL_FRAMEBUFFER_SRGB is
> +* still enabled by default since this is the behaviour when
> +* EXT_sRGB_write_control is not available.
>  */
> -   if (_mesa_is_desktop_gl(st->ctx)) {
> +   if (_mesa_is_desktop_gl(st->ctx) ||
> +   st->ctx->Extensions.EXT_sRGB_write_control)
> +   {
>struct pipe_screen *screen = st->pipe->screen;
>const enum pipe_format srgb_format =
>   util_format_srgb(stfbi->visual->color_format);
> @@ -475,8 +477,14 @@ st_framebuffer_create(struct 

Re: [Mesa-dev] [PATCH] radv: fix check for perftest options size

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/18/18 9:40 PM, Andres Rodriguez wrote:

It was using the debug options array size.

CC: mesa-sta...@lists.freedesktop.org
Reviewed-by: Bas Nieuwenhuizen 
---
  src/amd/vulkan/radv_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 429d47325a3..976c42c98f1 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -484,7 +484,7 @@ static const struct debug_control radv_perftest_options[] = 
{
  const char *
  radv_get_perftest_option_name(int id)
  {
-   assert(id < ARRAY_SIZE(radv_debug_options) - 1);
+   assert(id < ARRAY_SIZE(radv_perftest_options) - 1);
return radv_perftest_options[id].string;
  }
  


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev