date:20170512

Re: [Mesa-dev] [PATCH] mesa: don't crash in KHR_no_error uniform variants when location == -1

2017-05-12 Thread Timothy Arceri

My commit message seems to have gone missing. By -1 is allowed so that 
inactive uniforms don't cause the app to throw an error.


On 13/05/17 16:31, Timothy Arceri wrote:

---
  src/mesa/main/uniform_query.cpp | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 0e02a76..5f38aa5 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -904,20 +904,23 @@ validate_uniform(GLint location, GLsizei count, const 
GLvoid *values,
  extern "C" void
  _mesa_uniform(GLint location, GLsizei count, const GLvoid *values,
struct gl_context *ctx, struct gl_shader_program *shProg,
enum glsl_base_type basicType, unsigned src_components)
  {
 unsigned offset;
 int size_mul = glsl_base_type_is_64bit(basicType) ? 2 : 1;
  
 struct gl_uniform_storage *uni;

 if (_mesa_is_no_error_enabled(ctx)) {
+  if (location == -1)
+ return;
+
uni = shProg->UniformRemapTable[location];
  
/* The array index specified by the uniform location is just the

 * uniform location minus the base location of of the uniform.
 */
assert(uni->array_elements > 0 || location == (int)uni->remap_location);
offset = location - uni->remap_location;
 } else {
uni = validate_uniform(location, count, values, &offset, ctx, shProg,
   basicType, src_components);


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

[Mesa-dev] [Bug 101028] Cannot run OpenGL applications on a remote XServer without +iglx

2017-05-12 Thread bugzilla-daemon

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

Bug ID: 101028
   Summary: Cannot run OpenGL applications on a remote XServer
without +iglx
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: suic...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

When I try to run glxgears on a remote Cygwin / X server I get this error 

suici@HP-Pavilion-g7:~$ LIBGL_DEBUG=verbose DISPLAY=:0 glxgears
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: Can't open configuration file /home/suici/.drirc: No such file or
directory.
libGL: Can't open configuration file /home/suici/.drirc: No such file or
directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  28
  Current serial number in output stream:  30

I'm using Windows 10 WSL but the same error also occurs if I run it from a
remote Linux machine. If I use +iglx the error goes but it only supports GL
1.4.

GPU : Radeon HD 7640G

-- 
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] mesa: don't crash in KHR_no_error uniform variants when location == -1

2017-05-12 Thread Timothy Arceri

---
 src/mesa/main/uniform_query.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 0e02a76..5f38aa5 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -904,20 +904,23 @@ validate_uniform(GLint location, GLsizei count, const 
GLvoid *values,
 extern "C" void
 _mesa_uniform(GLint location, GLsizei count, const GLvoid *values,
   struct gl_context *ctx, struct gl_shader_program *shProg,
   enum glsl_base_type basicType, unsigned src_components)
 {
unsigned offset;
int size_mul = glsl_base_type_is_64bit(basicType) ? 2 : 1;
 
struct gl_uniform_storage *uni;
if (_mesa_is_no_error_enabled(ctx)) {
+  if (location == -1)
+ return;
+
   uni = shProg->UniformRemapTable[location];
 
   /* The array index specified by the uniform location is just the
* uniform location minus the base location of of the uniform.
*/
   assert(uni->array_elements > 0 || location == (int)uni->remap_location);
   offset = location - uni->remap_location;
} else {
   uni = validate_uniform(location, count, values, &offset, ctx, shProg,
  basicType, src_components);
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH 09/11] intel/tools: Refactor gen_disasm_disassemble() to use annotations

2017-05-12 Thread Pohjolainen, Topi

On Thu, May 04, 2017 at 11:27:57AM -0700, Matt Turner wrote:
> On Tue, May 2, 2017 at 6:03 AM, Iago Toral  wrote:
> > On Mon, 2017-05-01 at 13:54 -0700, Matt Turner wrote:
> >> Which will allow us to print validation errors found in shader
> >> assembly
> >> in GPU hang error states.
> >> ---
> >>  src/intel/tools/disasm.c | 71 +-
> >> --
> >>  1 file changed, 43 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/src/intel/tools/disasm.c b/src/intel/tools/disasm.c
> >> index 62256d2..361885b 100644
> >> --- a/src/intel/tools/disasm.c
> >> +++ b/src/intel/tools/disasm.c
> >> @@ -43,52 +43,67 @@ is_send(uint32_t opcode)
> >> opcode == BRW_OPCODE_SENDSC );
> >>  }
> >>
> >> -void
> >> -gen_disasm_disassemble(struct gen_disasm *disasm, void *assembly,
> >> -   int start, FILE *out)
> >> +static int
> >> +gen_disasm_find_end(struct gen_disasm *disasm, void *assembly, int
> >> start)
> >>  {
> >> struct gen_device_info *devinfo = &disasm->devinfo;
> >> -   bool dump_hex = false;
> >> int offset = start;
> >>
> >> /* This loop exits when send-with-EOT or when opcode is 0 */
> >> while (true) {
> >>brw_inst *insn = assembly + offset;
> >> -  brw_inst uncompacted;
> >> -  bool compacted = brw_inst_cmpt_control(devinfo, insn);
> >> -  if (0)
> >> - fprintf(out, "0x%08x: ", offset);
> >> -
> >> -  if (compacted) {
> >> - brw_compact_inst *compacted = (void *)insn;
> >> - if (dump_hex) {
> >> -fprintf(out, "0x%08x 0x%08x   ",
> >> -   ((uint32_t *)insn)[1],
> >> -   ((uint32_t *)insn)[0]);
> >> - }
> >> -
> >> - brw_uncompact_instruction(devinfo, &uncompacted,
> >> compacted);
> >> - insn = &uncompacted;
> >> +
> >> +  if (brw_inst_cmpt_control(devinfo, insn)) {
> >>   offset += 8;
> >>} else {
> >> - if (dump_hex) {
> >> -fprintf(out, "0x%08x 0x%08x 0x%08x 0x%08x ",
> >> -   ((uint32_t *)insn)[3],
> >> -   ((uint32_t *)insn)[2],
> >> -   ((uint32_t *)insn)[1],
> >> -   ((uint32_t *)insn)[0]);
> >> - }
> >>   offset += 16;
> >>}
> >>
> >> -  brw_disassemble_inst(out, devinfo, insn, compacted);
> >> -
> >>/* Simplistic, but efficient way to terminate disasm */
> >>uint32_t opcode = brw_inst_opcode(devinfo, insn);
> >>if (opcode == 0 || (is_send(opcode) && brw_inst_eot(devinfo,
> >> insn))) {
> >>   break;
> >>}
> >> }
> >> +
> >> +   return offset;
> >> +}
> >> +
> >> +void
> >> +gen_disasm_disassemble(struct gen_disasm *disasm, void *assembly,
> >> +   int start, FILE *out)
> >> +{
> >> +   struct gen_device_info *devinfo = &disasm->devinfo;
> >> +   int end = gen_disasm_find_end(disasm, assembly, start);
> >> +
> >> +   /* Make a dummy annotation structure that
> >> brw_validate_instructions
> >> +* can work from.
> >> +*/
> >> +   struct annotation_info annotation_info = {
> >> +  .ann_count = 1,
> >> +  .ann_size = 2,
> >> +   };
> >> +   annotation_info.mem_ctx = ralloc_context(NULL);
> >> +   annotation_info.ann = rzalloc_array(annotation_info.mem_ctx,
> >> +   struct annotation,
> >> +   annotation_info.ann_size);
> >> +   annotation_info.ann[0].offset = start;
> >> +   annotation_info.ann[1].offset = end;
> >> +   brw_validate_instructions(devinfo, assembly, start, end,
> >> &annotation_info);
> >> +   struct annotation *annotation = annotation_info.ann;
> >> +
> >> +   for (int i = 0; i < annotation_info.ann_count; i++) {
> >> +  int start_offset = annotation[i].offset;
> >> +  int end_offset = annotation[i + 1].offset;
> >
> > I was going to say that this code seems to overflow when i
> > == annotation_info.ann_count - 1, but then I noticed that there are
> > similar loops in other parts of the code and that you initialized
> > ann_count to just 1 even though you have two initial annotations, so I
> > guess this is how this is supposed to work, right?
> 
> Yeah, exactly. I'm not sure it's a good way to handle it though. To be
> honest, I had a hard time remembering how it was supposed to work and
> I wrote the annotation system.
> 
> I think a linked list would be a lot more natural than the array/count.

Sounds like it. While not ideal I think we can live with this for now:

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

Re: [Mesa-dev] Fix __atomic* builtins detection for Clang

2017-05-12 Thread Jonathan Gray

On Sat, May 13, 2017 at 02:22:30AM +0200, Jan Beich wrote:
> "int" isn't large enough and lack of builtins only manifests at link time.
> This was breaking build on FreeBSD 11.0 i386 with Clang 3.8.0.

You should be building with -march=i586 on i386 for CX8.

The diff is wrong as it will break other architectures, ie powerpc.

commit a6a38a038bd62e6d9558905f00bef81b5e7e6fcc
Author: Grazvydas Ignotas 
Date:   Fri Mar 31 01:26:25 2017 +0300

util/u_atomic: provide 64bit atomics where they're missing

attempts to handle powerpc like situations, though not sync
builtins being missing entirely.

> 
> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
> `disk_cache_remove':
> disk_cache.c:(.text+0x763): undefined reference to `__atomic_fetch_add_8'
> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
> `cache_put':
> disk_cache.c:(.text+0xabc): undefined reference to `__atomic_fetch_add_8'
> disk_cache.c:(.text+0xec1): undefined reference to `__atomic_fetch_add_8'
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> ---
>  configure.ac | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 957d15df8c..5b11941a0c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -403,9 +403,10 @@ AM_CONDITIONAL([SSE41_SUPPORTED], [test 
> x$SSE41_SUPPORTED = x1])
>  AC_SUBST([SSE41_CFLAGS], $SSE41_CFLAGS)
>  
>  dnl Check for new-style atomic builtins
> -AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
> +AC_LINK_IFELSE([AC_LANG_SOURCE([[
> +#include 
>  int main() {
> -int n;
> +uint64_t n;
>  return __atomic_load_n(&n, __ATOMIC_ACQUIRE);
>  }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=1)
>  if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
> ___
> 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 01/11] i965: Mark shader programs for capture in the error state.

2017-05-12 Thread Pohjolainen, Topi

On Mon, May 01, 2017 at 01:54:45PM -0700, Matt Turner wrote:
> When the GPU hangs, the kernel saves some state for us. Until now it has
> not included the shader programs, which are very often the reason the
> GPU hang occurred. With the programs saved in the error state, we should
> be more capable of debugging hangs.
> 
> Thanks to Chris Wilson and Ben Widawsky who provided the kernel support
> for this feature ("drm/i915: Copy user requested buffers into the error
> state"), which will be in kernel v4.13.

Reviewed-by: Topi Pohjolainen 

> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c| 1 +
>  src/mesa/drivers/dri/i965/brw_bufmgr.h| 5 +
>  src/mesa/drivers/dri/i965/brw_program_cache.c | 4 
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
>  src/mesa/drivers/dri/i965/intel_screen.c  | 8 
>  src/mesa/drivers/dri/i965/intel_screen.h  | 7 +++
>  6 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 4b64331..2f17934 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -599,6 +599,7 @@ bo_unreference_final(struct brw_bo *bo, time_t time)
>bo->free_time = time;
>  
>bo->name = NULL;
> +  bo->kflags = 0;
>  
>list_addtail(&bo->head, &bucket->head);
> } else {
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> index 1b1790a..56ec206 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> @@ -97,6 +97,11 @@ struct brw_bo {
> int refcount;
> const char *name;
>  
> +#ifndef EXEC_OBJECT_CAPTURE
> +#define EXEC_OBJECT_CAPTURE(1<<7)
> +#endif
> +   uint64_t kflags;
> +
> /**
>  * Kenel-assigned global name for this object
>  *
> diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c 
> b/src/mesa/drivers/dri/i965/brw_program_cache.c
> index c06ee23..93eb119 100644
> --- a/src/mesa/drivers/dri/i965/brw_program_cache.c
> +++ b/src/mesa/drivers/dri/i965/brw_program_cache.c
> @@ -216,6 +216,8 @@ brw_cache_new_bo(struct brw_cache *cache, uint32_t 
> new_size)
> struct brw_bo *new_bo;
>  
> new_bo = brw_bo_alloc(brw->bufmgr, "program cache", new_size, 64);
> +   if (can_do_exec_capture(brw->screen))
> +  new_bo->kflags = EXEC_OBJECT_CAPTURE;
> if (brw->has_llc)
>brw_bo_map_unsynchronized(brw, new_bo);
>  
> @@ -407,6 +409,8 @@ brw_init_caches(struct brw_context *brw)
>calloc(cache->size, sizeof(struct brw_cache_item *));
>  
> cache->bo = brw_bo_alloc(brw->bufmgr, "program cache",  4096, 64);
> +   if (can_do_exec_capture(brw->screen))
> +  cache->bo->kflags = EXEC_OBJECT_CAPTURE;
> if (brw->has_llc)
>brw_bo_map_unsynchronized(brw, cache->bo);
>  }
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 154c095..496b492 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -530,7 +530,7 @@ add_exec_bo(struct intel_batchbuffer *batch, struct 
> brw_bo *bo)
> }
> validation_entry->alignment = bo->align;
> validation_entry->offset = bo->offset64;
> -   validation_entry->flags = 0;
> +   validation_entry->flags = bo->kflags;
> validation_entry->rsvd1 = 0;
> validation_entry->rsvd2 = 0;
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index 34a5f18..514c17e 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1994,6 +1994,14 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
>screen->cmd_parser_version = 0;
> }
>  
> +   /* Kernel 4.13 retuired for exec object capture */
> +#ifndef I915_PARAM_HAS_EXEC_CAPTURE
> +#define I915_PARAM_HAS_EXEC_CAPTURE 45
> +#endif
> +   if (intel_get_boolean(screen, I915_PARAM_HAS_EXEC_CAPTURE)) {
> +  screen->kernel_features |= KERNEL_ALLOWS_EXEC_CAPTURE;
> +   }
> +
> if (!intel_detect_pipelined_so(screen)) {
>/* We can't do anything, so the effective version is 0. */
>screen->cmd_parser_version = 0;
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
> b/src/mesa/drivers/dri/i965/intel_screen.h
> index fe0e044..f9c1db6 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.h
> +++ b/src/mesa/drivers/dri/i965/intel_screen.h
> @@ -74,6 +74,7 @@ struct intel_screen
>  #define KERNEL_ALLOWS_MI_MATH_AND_LRR   (1<<2)
>  #define KERNEL_ALLOWS_HSW_SCRATCH1_AND_ROW_CHICKEN3 (1<<3)
>  #define KERNEL_ALLOWS_COMPUTE_DISPATCH  (1<<4)
> +#define KERNEL_ALLOWS_EXEC_CAPTURE  (1<<5)
>  
> struct brw_bufmgr *bufmgr;
>  
> @@ -155,6 +156,12 @@ can_do_predicate_writes(const struct intel_screen 
> *screen)
> return screen->kernel_features & KERN

Re: [Mesa-dev] [PATCH 03/11] i965: Allow brw_eu_validate to handle compact instructions

2017-05-12 Thread Pohjolainen, Topi

On Mon, May 01, 2017 at 01:54:47PM -0700, Matt Turner wrote:
> This will allow the validator to run on shader programs we find in the
> GPU hang error state.
> ---
>  src/intel/compiler/brw_eu_validate.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/src/intel/compiler/brw_eu_validate.c 
> b/src/intel/compiler/brw_eu_validate.c
> index 39363e4..38564a4 100644
> --- a/src/intel/compiler/brw_eu_validate.c
> +++ b/src/intel/compiler/brw_eu_validate.c
> @@ -1051,6 +1051,14 @@ brw_validate_instructions(const struct gen_device_info 
> *devinfo,
> for (int src_offset = start_offset; src_offset < end_offset;) {
>struct string error_msg = { .str = NULL, .len = 0 };
>const brw_inst *inst = assembly + src_offset;
> +  bool is_compact = brw_inst_cmpt_control(devinfo, inst);

Could be const. Either way:

Reviewed-by: Topi Pohjolainen 

> +  brw_inst uncompacted;
> +
> +  if (is_compact) {
> + brw_compact_inst *compacted = (void *)inst;
> + brw_uncompact_instruction(devinfo, &uncompacted, compacted);
> + inst = &uncompacted;
> +  }
>  
>if (is_unsupported_inst(devinfo, inst)) {
>   ERROR("Instruction not supported on this Gen");
> @@ -1067,6 +1075,12 @@ brw_validate_instructions(const struct gen_device_info 
> *devinfo,
>}
>valid = valid && error_msg.len == 0;
>free(error_msg.str);
> +
> +  if (is_compact) {
> + src_offset += sizeof(brw_compact_inst);
> +  } else {
> + src_offset += sizeof(brw_inst);
> +  }
> }
>  
> return valid;
> -- 
> 2.10.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 0/2] Allow redeclaration of GLSL builtins; fixes Dying Light and Dead Island Definitive Edition

2017-05-12 Thread John Brooks

On Sat, May 13, 2017 at 10:47:17AM +1000, Timothy Arceri wrote:
> On 13/05/17 09:55, John Brooks wrote:
> >On Sat, May 13, 2017 at 09:04:05AM +1000, Timothy Arceri wrote:
> >>On 13/05/17 00:11, John Brooks wrote:
> >>>On Fri, May 12, 2017 at 03:56:26PM +0200, Samuel Pitoiset wrote:
> 
> 
> On 05/12/2017 03:39 PM, John Brooks wrote:
> >Since release, Dying Light and Dead Island Definitive Edition have been 
> >broken
> >on Mesa, producing at best only a black screen after loading. I found 
> >that the
> >root of the problem is that their vertex shaders redeclare the GLSL 
> >builtin
> >gl_VertexID, which Mesa's compiler considers to be an error:
> >
> > error: `gl_VertexID' redeclared
> >
> >These patches make the compiler more lenient so that the shaders compile.
> >Because such redeclarations are not explicitly valid in the spec, this
> >behaviour is selectively activated by the new 
> >allow_glsl_builtin_redeclaration
> >driconf option, which has been enabled for both games in the default 
> >drirc.
> >
> >With this change, both games work on Mesa and render correctly. Note 
> >that the
> >games require OpenGL 4.4+, and so it is necessary to launch them with
> >MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE set to OpenGL 
> >4.4 (GLSL
> >440) or higher.
> >
> >Contrary to popular belief, this problem actually had nothing whatsoever 
> >to do
> >with compatibility profiles. Forcing Mesa to create a higher version
> >compatibility profile with MESA_GL_VERSION_OVERRIDE=4.5COMPAT or
> >allow_higher_compat_version results in graphical glitches, so don't use 
> >that.
> 
> I wonder if there is multiple versions of Dying Light, but using
> MESA_GL_VERSION_OVERRIDE=4.4 and MESA_GLSL_VERSION_OVERRIDE=440 doesn't 
> work
> for me (game crash at launching). Also it requests some unsupported GL
> functions (compat?).
> 
> IIRC, Dying Light wants a GL 4.4 compat profile, I guess Timothy can
> confirm?
> 
> What's your steam app ID?
> 
> Btw, you probably don't need to override the GL/GLSL versions, it should 
> be
> backward compatible.
> 
> >>>
> >>>Steam App ID 239140. The use of legacy functions (such as glBegin) in 
> >>>frame 0
> >>>is SDL's doing:
> >>>
> >>>
> >>>I don't know why your game would crash on launch. My first thought would be
> >>>steam runtime issues though. Make sure Steam runtime is enabled and remove
> >>>~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6
> >>>
> >>>The version override is necessary since the game will not render at all 
> >>>with a
> >>>3.0 compat profile, which is what it gets without an override.
> >>
> >>Right but isn't that is because the game is requesting a compat profile?
> >>
> >>How do you know that the rendering issues you see when using the compat
> >>override are not because of missing compat support for higher GL versions?
> >>
> >>For example a feature/behavior supported in an eariler GL version may have
> >>been changed to be more like core and it just happens that overriding to use
> >>core makes the rendering problems go away.
> >>
> >
> >Nope, it's not requesting a compat profile or anything specific at all. I
> >checked with ltrace and the game calls SDL_GL_CreateContext without calling
> >SDL_GL_SetAttribute to specify a version or type. Thus, SDL just calls
> >glXCreateContext:
> >https://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11opengl.c#l620 >
> >The spec says nothing of what version you're supposed to get with
> >glXCreateContext, but the result with Mesa is a 3.0 compatibility profile
> >unless you override it.
> 
> That's because glXCreateContext is from a time before there was such a thing
> as compat profiles. glXCreateContextAttribsARB was introduced to solve this
> problem.
> 
> Are you suggesting other drivers don't return a compat profile in this
> scenario?
> 

No, only that it's not explicitly defined by the spec and what Mesa does is not
necessarily the same as what other drivers do. However, it is a reasonable
assumption that they also would return a compatibility profile.

The difference would be that other drivers would return a real compatibility
profile because they support it. Much has changed between OpenGL 3.0 and 4.4,
and since Mesa's implementation of the compatibility spec is strictly limited
to 3.0 (before there even was a separate compatibility spec), it's anyone's
guess what we're doing differently when presenting a faux 4.4 compatibility
profile backed by a 3.0 implementation. Maybe they use a new feature that we
implement with existing code that has a different path for 3.0 compat, but that
path isn't supposed to be used for this feature and we don't account for it
because it didn't e

Re: [Mesa-dev] [PATCH 0/2] Allow redeclaration of GLSL builtins; fixes Dying Light and Dead Island Definitive Edition

2017-05-12 Thread Timothy Arceri

On 13/05/17 09:55, John Brooks wrote:

On Sat, May 13, 2017 at 09:04:05AM +1000, Timothy Arceri wrote:

On 13/05/17 00:11, John Brooks wrote:

On Fri, May 12, 2017 at 03:56:26PM +0200, Samuel Pitoiset wrote:

On 05/12/2017 03:39 PM, John Brooks wrote:

Since release, Dying Light and Dead Island Definitive Edition have been broken
on Mesa, producing at best only a black screen after loading. I found that the
root of the problem is that their vertex shaders redeclare the GLSL builtin
gl_VertexID, which Mesa's compiler considers to be an error:

error: `gl_VertexID' redeclared

These patches make the compiler more lenient so that the shaders compile.
Because such redeclarations are not explicitly valid in the spec, this
behaviour is selectively activated by the new allow_glsl_builtin_redeclaration
driconf option, which has been enabled for both games in the default drirc.

With this change, both games work on Mesa and render correctly. Note that the
games require OpenGL 4.4+, and so it is necessary to launch them with
MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE set to OpenGL 4.4 (GLSL
440) or higher.

Contrary to popular belief, this problem actually had nothing whatsoever to do
with compatibility profiles. Forcing Mesa to create a higher version
compatibility profile with MESA_GL_VERSION_OVERRIDE=4.5COMPAT or
allow_higher_compat_version results in graphical glitches, so don't use that.

I wonder if there is multiple versions of Dying Light, but using
MESA_GL_VERSION_OVERRIDE=4.4 and MESA_GLSL_VERSION_OVERRIDE=440 doesn't work
for me (game crash at launching). Also it requests some unsupported GL
functions (compat?).

IIRC, Dying Light wants a GL 4.4 compat profile, I guess Timothy can
confirm?

What's your steam app ID?

Btw, you probably don't need to override the GL/GLSL versions, it should be
backward compatible.

Steam App ID 239140. The use of legacy functions (such as glBegin) in frame 0
is SDL's doing:

I don't know why your game would crash on launch. My first thought would be
steam runtime issues though. Make sure Steam runtime is enabled and remove
~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6

The version override is necessary since the game will not render at all with a
3.0 compat profile, which is what it gets without an override.

Right but isn't that is because the game is requesting a compat profile?

How do you know that the rendering issues you see when using the compat
override are not because of missing compat support for higher GL versions?

For example a feature/behavior supported in an eariler GL version may have
been changed to be more like core and it just happens that overriding to use
core makes the rendering problems go away.

Nope, it's not requesting a compat profile or anything specific at all. I
checked with ltrace and the game calls SDL_GL_CreateContext without calling
SDL_GL_SetAttribute to specify a version or type. Thus, SDL just calls
glXCreateContext:
https://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11opengl.c#l620 >
The spec says nothing of what version you're supposed to get with
glXCreateContext, but the result with Mesa is a 3.0 compatibility profile
unless you override it.

That's because glXCreateContext is from a time before there was such a
thing as compat profiles. glXCreateContextAttribsARB was introduced to
solve this problem.

Are you suggesting other drivers don't return a compat profile in this
scenario?

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

--
John Brooks
Frogging101 on IRC and elsewhere

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

[Mesa-dev] Fix __atomic* builtins detection for Clang

2017-05-12 Thread Jan Beich

"int" isn't large enough and lack of builtins only manifests at link time.
This was breaking build on FreeBSD 11.0 i386 with Clang 3.8.0.

glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
`disk_cache_remove':
disk_cache.c:(.text+0x763): undefined reference to `__atomic_fetch_add_8'
glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
`cache_put':
disk_cache.c:(.text+0xabc): undefined reference to `__atomic_fetch_add_8'
disk_cache.c:(.text+0xec1): undefined reference to `__atomic_fetch_add_8'
c++: error: linker command failed with exit code 1 (use -v to see invocation)
---
 configure.ac | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 957d15df8c..5b11941a0c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -403,9 +403,10 @@ AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED 
= x1])
 AC_SUBST([SSE41_CFLAGS], $SSE41_CFLAGS)
 
 dnl Check for new-style atomic builtins
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
+#include 
 int main() {
-int n;
+uint64_t n;
 return __atomic_load_n(&n, __ATOMIC_ACQUIRE);
 }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=1)
 if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] bin/get-fixes-pick-list.sh: parse just the commit message

2017-05-12 Thread Andres Gomez

We were parsing the whole diff, although the candidates were
identified only by the commit message.

Now, we only use the commit message for parsing.

Signed-off-by: Andres Gomez 
---
 bin/get-fixes-pick-list.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bin/get-fixes-pick-list.sh b/bin/get-fixes-pick-list.sh
index 81b78adc9c..f9afcc49ce 100755
--- a/bin/get-fixes-pick-list.sh
+++ b/bin/get-fixes-pick-list.sh
@@ -37,10 +37,10 @@ do
fi
 
# For each one try to extract the tag
-   fixes_count=`git show $sha | grep -i "fixes:" | wc -l`
+   fixes_count=`git show -s $sha | grep -i "fixes:" | wc -l`
warn=`(test $fixes_count -gt 1 && echo $fixes_count) || echo 0`
while [ $fixes_count -gt 0 ] ; do
-   fixes=`git show $sha | grep -i "fixes:" | tail -n $fixes_count`
+   fixes=`git show -s $sha | grep -i "fixes:" | tail -n 
$fixes_count`
fixes_count=$(($fixes_count-1))
# The following sed/cut combination is borrowed from GregKH
id=`echo ${fixes} | sed -e 's/^[ \t]*//' | cut -f 2 -d ':' | 
sed -e 's/^[ \t]*//' | cut -f 1 -d ' '`
-- 
2.11.0

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

[Mesa-dev] [PATCH 2/2] bin/get-fixes-pick-list.sh: better identify multiple "fixes:" tags

2017-05-12 Thread Andres Gomez

We were not considering as multiple fixes lines with:
Fixes: $sha_1, Fixes: $sha_2

Now, we split the lines so we will consider them individually, as in:
Fixes: $sha_1,
Fixes: $sha_2

Additionally, we try to get the SHA from split lines so:
Fixes:
$sha_1

Will be considered as:
Fixes: $sha_1

Signed-off-by: Andres Gomez 
---
 bin/get-fixes-pick-list.sh | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/bin/get-fixes-pick-list.sh b/bin/get-fixes-pick-list.sh
index f9afcc49ce..32d830cda0 100755
--- a/bin/get-fixes-pick-list.sh
+++ b/bin/get-fixes-pick-list.sh
@@ -36,14 +36,18 @@ do
continue
fi
 
+   # Place every "fixes:" tag on its own line and join with the next word
+   # on its line or a later one.
+   fixes=`git show -s $sha | tr -d "\n" | sed -e 's/fixes:/\nfixes:/Ig' | 
grep "fixes:" | sed -e 's/\(fixes:\)[[:space:]]*\([a-zA-Z0-9]*\).*$/\1\2/g'`
+
# For each one try to extract the tag
-   fixes_count=`git show -s $sha | grep -i "fixes:" | wc -l`
+   fixes_count=`echo "$fixes" | wc -l`
warn=`(test $fixes_count -gt 1 && echo $fixes_count) || echo 0`
while [ $fixes_count -gt 0 ] ; do
-   fixes=`git show -s $sha | grep -i "fixes:" | tail -n 
$fixes_count`
+   # Treat only the current line
+   fix=`echo "$fixes" | tail -n $fixes_count | head -n 1`
fixes_count=$(($fixes_count-1))
-   # The following sed/cut combination is borrowed from GregKH
-   id=`echo ${fixes} | sed -e 's/^[ \t]*//' | cut -f 2 -d ':' | 
sed -e 's/^[ \t]*//' | cut -f 1 -d ' '`
+   id=`echo "$fix" | cut -d : -f 2`
 
# Bail out if we cannot find suitable id.
# Any specific validation the $id is valid and not some junk, is
-- 
2.11.0

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

[Mesa-dev] [PATCH 0/2] Improve get-fixes-pick-list.sh

2017-05-12 Thread Andres Gomez

Some more improvements:
 - Only parse the commit messages.
 - Split "fixes:" tags on its own lines.
 - Join in a single line split lines like "fixes:\n$sha"

Andres Gomez (2):
  bin/get-fixes-pick-list.sh: parse just the commit message
  bin/get-fixes-pick-list.sh: better identify multiple "fixes:" tags

 bin/get-fixes-pick-list.sh | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

-- 
2.11.0

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

Re: [Mesa-dev] [PATCH 0/2] Allow redeclaration of GLSL builtins; fixes Dying Light and Dead Island Definitive Edition

2017-05-12 Thread John Brooks

On Sat, May 13, 2017 at 09:04:05AM +1000, Timothy Arceri wrote:
> On 13/05/17 00:11, John Brooks wrote:
> >On Fri, May 12, 2017 at 03:56:26PM +0200, Samuel Pitoiset wrote:
> >>
> >>
> >>On 05/12/2017 03:39 PM, John Brooks wrote:
> >>>Since release, Dying Light and Dead Island Definitive Edition have been 
> >>>broken
> >>>on Mesa, producing at best only a black screen after loading. I found that 
> >>>the
> >>>root of the problem is that their vertex shaders redeclare the GLSL builtin
> >>>gl_VertexID, which Mesa's compiler considers to be an error:
> >>>
> >>> error: `gl_VertexID' redeclared
> >>>
> >>>These patches make the compiler more lenient so that the shaders compile.
> >>>Because such redeclarations are not explicitly valid in the spec, this
> >>>behaviour is selectively activated by the new 
> >>>allow_glsl_builtin_redeclaration
> >>>driconf option, which has been enabled for both games in the default drirc.
> >>>
> >>>With this change, both games work on Mesa and render correctly. Note that 
> >>>the
> >>>games require OpenGL 4.4+, and so it is necessary to launch them with
> >>>MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE set to OpenGL 4.4 
> >>>(GLSL
> >>>440) or higher.
> >>>
> >>>Contrary to popular belief, this problem actually had nothing whatsoever 
> >>>to do
> >>>with compatibility profiles. Forcing Mesa to create a higher version
> >>>compatibility profile with MESA_GL_VERSION_OVERRIDE=4.5COMPAT or
> >>>allow_higher_compat_version results in graphical glitches, so don't use 
> >>>that.
> >>
> >>I wonder if there is multiple versions of Dying Light, but using
> >>MESA_GL_VERSION_OVERRIDE=4.4 and MESA_GLSL_VERSION_OVERRIDE=440 doesn't work
> >>for me (game crash at launching). Also it requests some unsupported GL
> >>functions (compat?).
> >>
> >>IIRC, Dying Light wants a GL 4.4 compat profile, I guess Timothy can
> >>confirm?
> >>
> >>What's your steam app ID?
> >>
> >>Btw, you probably don't need to override the GL/GLSL versions, it should be
> >>backward compatible.
> >>
> >
> >Steam App ID 239140. The use of legacy functions (such as glBegin) in frame 0
> >is SDL's doing:
> >
> >
> >I don't know why your game would crash on launch. My first thought would be
> >steam runtime issues though. Make sure Steam runtime is enabled and remove
> >~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6
> >
> >The version override is necessary since the game will not render at all with 
> >a
> >3.0 compat profile, which is what it gets without an override.
> 
> Right but isn't that is because the game is requesting a compat profile?
> 
> How do you know that the rendering issues you see when using the compat
> override are not because of missing compat support for higher GL versions?
> 
> For example a feature/behavior supported in an eariler GL version may have
> been changed to be more like core and it just happens that overriding to use
> core makes the rendering problems go away.
> 

Nope, it's not requesting a compat profile or anything specific at all. I
checked with ltrace and the game calls SDL_GL_CreateContext without calling
SDL_GL_SetAttribute to specify a version or type. Thus, SDL just calls
glXCreateContext:
https://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11opengl.c#l620

The spec says nothing of what version you're supposed to get with
glXCreateContext, but the result with Mesa is a 3.0 compatibility profile
unless you override it.

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

--
John Brooks
Frogging101 on IRC and elsewhere
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

94 matches

Mail list logo