Re: [Mesa-dev] [PATCH mesa] i965/tex: add missing include

2017-09-09 Thread Jason Ekstrand 
This one has been bugging me too.  Just not enough to actually fix it. :-P

Reviewed-by: Jason Ekstrand 

On Sat, Sep 9, 2017 at 3:35 PM, Eric Engestrom  wrote:

> src/mesa/drivers/dri/i965/intel_tex.h:52:40: warning: ‘enum
> intel_miptree_create_flags’ declared inside parameter list will not be
> visible outside of this definition or declaration
>  enum intel_miptree_create_flags flags);
>   ^~
>
> Fixes: cadcd89278edcda8aba2 "i965/tex: Change the flags type on
>  create_for_teximage"
> Signed-off-by: Eric Engestrom 
> ---
>  src/mesa/drivers/dri/i965/intel_tex.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_tex.h
> b/src/mesa/drivers/dri/i965/intel_tex.h
> index beefc4b61b..f1b55c706e 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex.h
> +++ b/src/mesa/drivers/dri/i965/intel_tex.h
> @@ -29,6 +29,7 @@
>  #include "main/mtypes.h"
>  #include "main/formats.h"
>  #include "brw_context.h"
> +#include "intel_mipmap_tree.h"
>
>  void intelInitTextureFuncs(struct dd_function_table *functions);
>
> --
> Cheers,
>   Eric
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 102639] BadLength (poly request too large or internal Xlib length erro

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102639

Bug ID: 102639
   Summary: BadLength (poly request too large or internal Xlib
length erro
   Product: Mesa
   Version: 17.2
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: doctorkaed...@yahoo.com
QA Contact: mesa-dev@lists.freedesktop.org

This error has returned after maybe five years.

I tested 17.1.8, 17.1.9, and 17.2.0 in i686 and x86_64.
The app that crashes is the gtk2 color changer and pixpbuf demos.
I tried no other gtk apps. Glxgears works. The demos crash at startup.
What should have happened: color-chooser should appear or pixbuf demo should
appear. To reproduce: run gtk-demos (gtk2) and select those demos.

The program 'gtk2-demo-64' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 2460 error_code 16 request_code 72 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

The serial number changes, but the rest is the same.

config for mesa:

OpenGL:  yes (ES1: yes ES2: yes)

OSMesa:  libOSMesa

DRI platform:drm
DRI drivers: i915 i965 nouveau r200 radeon swrast
DRI driver dir:  ${libdir}/dri
GLX: DRI-based

EGL: yes
EGL drivers: builtin:egl_dri2 builtin:egl_dri3
GBM: yes
EGL/Vulkan/VL platforms:   drm x11 wayland surfaceless

Vulkan drivers:  no

llvm:no

Gallium drivers: i915 nouveau r600 svga swrast virgl
Gallium st:  mesa xa xvmc vdpau

HUD extra stats: no
HUD lmsensors:   no


Shared libs: yes
Static libs: no
Shared-glapi:yes

CFLAGS:  -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
 -fno-math-errno -fno-trapping-math
CXXFLAGS:-O2 -Wall -fno-math-errno -fno-trapping-math
LDFLAGS:
Macros:  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -D_GNU_SOURCE
 -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DNDEBUG -DTEXTURE_FLOAT_ENABLED
-DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -D
HAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN
-DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_I
NDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_DRM_PLATFORM
-DHAVE_X11_PLATFORM -DHAVE_WAYLAN
D_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRI3 -DENABLE_SHADER_CACHE
-DHAVE_MINCORE -DHAVE_ST_VDPAU

PYTHON2: python2.7

The config for gtk2 is vanilla.

BTW, mesa 17.2.0 fails one test (no failures in 17.1.8, 17.1.9):

FAIL: main-test

Testsuite summary for Mesa 17.2.0

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See src/mesa/main/tests/test-suite.log
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa


-- 
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 08/10] drirc: Don't expose 10 bpc visuals/configs to gnome-shell.

2017-09-09 Thread Marek Olšák 
Yes, that's what I mean - no workaround in Mesa.

Marek

On Sat, Sep 9, 2017 at 12:07 PM, Mario Kleiner
 wrote:
> On 09/08/2017 05:21 AM, Michel Dänzer wrote:
>>
>> On 08/09/17 12:26 AM, Marek Olšák wrote:
>>>
>>> [+ Dave]
>>>
>>> We can also ignore gnome-shell in Mesa for now and let the gnome-shell
>>> maintainers fix the issue in gnome-shell.
>>
>>
>> Indeed, that would be better.
>>
>
> [+ Jonas Adahl] probably a good person to ping wrt. this?
>
> You mean we shouldn't provide the driconf workaround for gnome-shell?
>
> That would make g-s wayland pretty much unusable in a very colorful way
> until it's fixed. On X11 g-s works perfectly fine at Screen DefaultDepth 24,
> but on wayland we'd probably get lots bug reports by users which try out the
> latest Mesa from some repo, e.g., Ubuntu's padoka ppa's.
>
>> IIUC, with this workaround, all content composited by gnome-shell will
>> effectively use only 8 bits per component, even when Xorg runs at depth
>> 30.
>>
>>
>
> Yes, just confirmed with photometer. However, unredirected fullscreen
> windows (page-flipped) still work with 30 bit precision says the photometer,
> so there's still some use on g-s x11.
>
> Tapani is right, the clutter picking code uses color coded drawing into some
> fb, translating ui element ("actor") id's to rgb color codes and back during
> hit testing / picking. That code has some clever logic to deal with fb's of
> different bit depths, but was last updated 9 years ago to deal with problems
> in low precision modes (rgb565 i guess), so probably never tested on any
> depth 30 fb's and only handling < 8 bpc, not more.
>
> The stuff is in clutter/clutter-main.c, (_clutter_id_to_color() and
> _clutter_pixel_to_id()) but apparently there are separate clutter trees for
> the mutter and clutter repos, ie. mutter includes its own copy of clutter.
>
> -mario
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] i965/tex: add missing include

2017-09-09 Thread Eric Engestrom 
src/mesa/drivers/dri/i965/intel_tex.h:52:40: warning: ‘enum 
intel_miptree_create_flags’ declared inside parameter list will not be visible 
outside of this definition or declaration
 enum intel_miptree_create_flags flags);
  ^~

Fixes: cadcd89278edcda8aba2 "i965/tex: Change the flags type on
 create_for_teximage"
Signed-off-by: Eric Engestrom 
---
 src/mesa/drivers/dri/i965/intel_tex.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex.h 
b/src/mesa/drivers/dri/i965/intel_tex.h
index beefc4b61b..f1b55c706e 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.h
+++ b/src/mesa/drivers/dri/i965/intel_tex.h
@@ -29,6 +29,7 @@
 #include "main/mtypes.h"
 #include "main/formats.h"
 #include "brw_context.h"
+#include "intel_mipmap_tree.h"
 
 void intelInitTextureFuncs(struct dd_function_table *functions);
 
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH] intel/fs: Restrict live intervals to the subset possibly reachable from any definition.

2017-09-09 Thread Francisco Jerez 
Chema Casanova  writes:

> El 08/09/17 a las 11:06, Alejandro Piñeiro escribió:
>> On 08/09/17 02:50, Francisco Jerez wrote:
>>> Currently the liveness analysis pass would extend a live interval up
>>> to the top of the program when no unconditional and complete
>>> definition of the variable is found that dominates all of its uses.
>>>
>>> This can lead to a serious performance problem in shaders containing
>>> many partial writes, like scalar arithmetic, FP64 and soon FP16
>>> operations.  
>> Just tested with the VK_KHR_16bit_storage implementation. Works really
>> fine with the most problematic tests, so we can drop the "i965/fs: Add
>> reuse_16bit_conversions_register optimization" patch (that was already
>> NAKed by both you and Connor).
>>
>> My test was limited to that extension CTS tests, but in case it helps:
>> Tested-by: Alejandro Piñeiro 
>
> I've seen one regression on a full VK-CTS run with this patch over the
> VK_KHR_16bit_storage branch, but I can reproduce the same regression
> applying it on master.
>
> Failing test is:
> dEQP-VK.glsl.return.return_in_dynamic_loop_dynamic_vertex
>

Good finding!  I've been digging into this regression some more and it
looks like the inaccuracy of the liveness analysis pass was protecting
us from a long-standing bug of the dataflow analysis code related to
cross-channel variable interference in non-uniformly executed loops.

I had been ranting about exactly this problem for years, but never
bothered to fix it.  Of course it had to come back to bite me as if
destiny wanted to teach me some sort of distasteful lesson.  :P

I'm amazed that *none* of the GL CTS, dEQP or Piglit test suite managed
to expose this issue, and that the one dEQP-VK test that could have
triggered the problem was passing basically by luck (with a small,
seemingly harmless change to the source code of the test case it would
have exploded regardless of this patch).

Anyway, will come back with a fix, probably next week.

>>> The number of oversize live intervals in such workloads
>>> can cause the compilation time of the shader to explode because of the
>>> worse than quadratic behavior of the register allocator and scheduler
>>> when running out of registers, and it can also cause the running time
>>> of the shader to explode due to the amount of spilling it leads to,
>>> which is orders of magnitude slower than GRF memory.
>>>
>>> This patch fixes it by computing the intersection of our current live
>>> intervals with the subset of the program that can possibly be reached
>>> from any definition of the variable.  Extending the storage allocation
>>> of the variable beyond that is pretty useless because its value is
>>> guaranteed to be undefined at a point that cannot be reached from any
>>> definition.
>>>
>>> No significant change in the running time of shader-db (with 5%
>>> statistical significance).
>>>
>>> shader-db results on IVB:
>>>
>>>   total cycles in shared programs: 61108780 -> 60932856 (-0.29%)
>>>   cycles in affected programs: 16335482 -> 16159558 (-1.08%)
>>>   helped: 5121
>>>   HURT: 4347
>>>
>>>   total spills in shared programs: 1309 -> 1288 (-1.60%)
>>>   spills in affected programs: 249 -> 228 (-8.43%)
>>>   helped: 3
>>>   HURT: 0
>>>
>>>   total fills in shared programs: 1652 -> 1597 (-3.33%)
>>>   fills in affected programs: 262 -> 207 (-20.99%)
>>>   helped: 4
>>>   HURT: 0
>>>
>>>   LOST:   2
>>>   GAINED: 209
>>>
>>> shader-db results on BDW:
>>>
>>>   total cycles in shared programs: 67617262 -> 67361220 (-0.38%)
>>>   cycles in affected programs: 23397142 -> 23141100 (-1.09%)
>>>   helped: 8045
>>>   HURT: 6488
>>>
>>>   total spills in shared programs: 1456 -> 1252 (-14.01%)
>>>   spills in affected programs: 465 -> 261 (-43.87%)
>>>   helped: 3
>>>   HURT: 0
>>>
>>>   total fills in shared programs: 1720 -> 1465 (-14.83%)
>>>   fills in affected programs: 471 -> 216 (-54.14%)
>>>   helped: 4
>>>   HURT: 0
>>>
>>>   LOST:   2
>>>   GAINED: 162
>>>
>>> shader-db results on SKL:
>>>
>>>   total cycles in shared programs: 65436248 -> 65245186 (-0.29%)
>>>   cycles in affected programs: 22560936 -> 22369874 (-0.85%)
>>>   helped: 8457
>>>   HURT: 6247
>>>
>>>   total spills in shared programs: 437 -> 437 (0.00%)
>>>   spills in affected programs: 0 -> 0
>>>   helped: 0
>>>   HURT: 0
>>>
>>>   total fills in shared programs: 870 -> 854 (-1.84%)
>>>   fills in affected programs: 16 -> 0
>>>   helped: 1
>>>   HURT: 0
>>>
>>>   LOST:   0
>>>   GAINED: 107
>>> ---
>>>  src/intel/compiler/brw_fs_live_variables.cpp | 34 
>>> 
>>>  src/intel/compiler/brw_fs_live_variables.h   | 12 ++
>>>  2 files changed, 42 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/intel/compiler/brw_fs_live_variables.cpp 
>>> b/src/intel/compiler/brw_fs_live_variables.cpp
>>> index c449672a519..059f076fa51 100644
>>> --- a/src/intel/compiler/brw_fs_live_variables.cpp
>>> +++

[Mesa-dev] [Bug 102634] 0 Color write masks with multiple render targets redirects color outputs to wrong attachment

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102634

--- Comment #2 from mais...@archlinux.us ---
Actually, this seems to work in Mesa 17.2

-- 
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 102571] vulkaninfo fails with "trap divide error"

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102571

danielr...@gmail.com changed:

   What|Removed |Added

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

--- Comment #3 from danielr...@gmail.com ---
Strangely, I can no longer reproduce the original error. This is true even when
booting the exact system configuration (same kernel, mesa, and all other
libraries and executables tracked by NixOS). This is surprising given how
consistently well the bisect seemed to be working a few days ago. In fact, I'm
even able to finally run steamvr with my 390x.

I'll go ahead and close this issue. I'll reopen in the future if I ever am able
to consistently reproduce this again. Thanks anyway.

-- 
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] Android: fix undeclared identifier 'gfx9d_reg_table'

2017-09-09 Thread Chih-Wei Huang 
Since commit 552aaa11 the compiler complains:

external/mesa/src/amd/common/ac_debug.c:124:51: error: use of undeclared 
identifier 'gfx9d_reg_table'; did you mean 'sid_reg_table'?
reg = find_register(gfx9d_reg_table, 
ARRAY_SIZE(gfx9d_reg_table), offset);
^~~
sid_reg_table

It's because the commit ef97cc0c ("radeonsi/gfx9: add IB parser support")
add gfx9d.h as a recipe of sid_tables.h. But the corresponding Android.mk
was not updated. However, it's not spotted since gfx9d_reg_table is not
really used until commit 552aaa11 was landed.

Fixes: 552aaa11 (ac/debug: take ASIC generation into account when printing 
registers)

Signed-off-by: Chih-Wei Huang 
---
 src/amd/Android.common.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/Android.common.mk b/src/amd/Android.common.mk
index 4e2d0f9..4ef7f17 100644
--- a/src/amd/Android.common.mk
+++ b/src/amd/Android.common.mk
@@ -44,7 +44,7 @@ LOCAL_GENERATED_SOURCES := $(addprefix $(intermediates)/, 
$(AMD_GENERATED_FILES)
 $(LOCAL_GENERATED_SOURCES): PRIVATE_PYTHON := $(MESA_PYTHON2)
 $(LOCAL_GENERATED_SOURCES): PRIVATE_CUSTOM_TOOL = $(PRIVATE_PYTHON) $^ > $@
 
-$(intermediates)/common/sid_tables.h: $(LOCAL_PATH)/common/sid_tables.py 
$(MESA_TOP)/src/amd/common/sid.h
+$(intermediates)/common/sid_tables.h: $(LOCAL_PATH)/common/sid_tables.py 
$(LOCAL_PATH)/common/sid.h $(LOCAL_PATH)/common/gfx9d.h
$(transform-generated-source)
 
 LOCAL_C_INCLUDES := \
-- 
1.9.1

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

[Mesa-dev] [PATCH v2] glsl: disallow mixed varying types within a location

2017-09-09 Thread Ilia Mirkin 
The enhanced layouts spec has all kinds of restrictions about what can
and cannot be mixed in a location. Integer/float(/presumably double)
can't occupy a single location, interpolation has to be the same, as
well as auxiliary storage (including patch!).

The implication of this is ... don't specify explicit locations/components
if you want better packing, since the auto-packer doesn't care at all
about most of these restrictions. Sad. (Auto-packer, of course, also
can't always do its magic, e.g. SSO.)

This fixes:

KHR-GL45.enhanced_layouts.varying_location_aliasing_with_mixed_types
KHR-GL45.enhanced_layouts.varying_location_aliasing_with_mixed_interpolation
KHR-GL45.enhanced_layouts.varying_location_aliasing_with_mixed_auxiliary_storage

See https://github.com/KhronosGroup/OpenGL-API/issues/13 for some more
info, where I asked about patch vs non-patch locations.

Signed-off-by: Ilia Mirkin 
---

v1 -> v2: move to link_varyings.cpp, per tarceri

 src/compiler/glsl/link_varyings.cpp | 90 +
 1 file changed, 90 insertions(+)

diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index 528506fd0eb..0aab083010e 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -2438,6 +2438,87 @@ check_against_input_limit(struct gl_context *ctx,
return true;
 }
 
+static void
+check_location_mixing(struct gl_shader_program *prog,
+  struct gl_linked_shader *shader)
+{
+   struct data_type {
+  // 0: unused, 1: float, 2: int, 3: 64-bit
+  unsigned var_type:2;
+  unsigned interpolation:2;
+  bool centroid:1;
+  bool sample:1;
+  bool patch:1;
+   } data_types[2][MAX_VARYING] = {};
+
+   foreach_in_list(ir_instruction, node, shader->ir) {
+  ir_variable *var = node->as_variable();
+  if (!var || !var->data.explicit_location)
+ continue;
+
+  if (var->data.mode != ir_var_shader_in &&
+  var->data.mode != ir_var_shader_out)
+ continue;
+
+  bool output = var->data.mode == ir_var_shader_out;
+  int var_slot;
+  if (!output && shader->Stage == MESA_SHADER_VERTEX) {
+ var_slot = var->data.location - VERT_ATTRIB_GENERIC0;
+ if (var_slot >= VERT_ATTRIB_GENERIC_MAX)
+continue;
+  } else if (var->data.patch) {
+ var_slot = var->data.location - VARYING_SLOT_PATCH0;
+ if (var_slot >= MAX_VARYING)
+continue;
+  } else {
+ var_slot = var->data.location - VARYING_SLOT_VAR0;
+ if (var_slot >= MAX_VARYING)
+continue;
+  }
+
+  if (var_slot < 0)
+ continue;
+
+  const glsl_type *type = get_varying_type(var, shader->Stage);
+  const glsl_type *type_without_array = type->without_array();
+  unsigned num_elements = type->count_attribute_slots(false);
+  unsigned var_type;
+  if (glsl_base_type_is_64bit(type_without_array->base_type))
+ var_type = 3;
+  else if (glsl_base_type_is_integer(type_without_array->base_type))
+ var_type = 2;
+  else
+ var_type = 1;
+
+  const char *var_dir = output ? "out" : "in";
+
+  for (unsigned i = 0; i < num_elements; i++, var_slot++) {
+ data_type& existing = data_types[output][var_slot];
+
+ if (existing.var_type) {
+if (existing.var_type != var_type)
+   linker_error(prog, "Mismatching %s varying types at 
location=%d",
+var_dir, var_slot);
+if (existing.interpolation != var->data.interpolation)
+   linker_error(prog, "Mismatching %s varying interpolation at 
location=%d",
+var_dir, var_slot);
+if (existing.centroid != var->data.centroid ||
+existing.sample != var->data.sample ||
+existing.patch != var->data.patch)
+   linker_error(prog, "Mismatching %s varying auxiliary storage at 
location=%d",
+var_dir, var_slot);
+ } else {
+existing.var_type = var_type;
+existing.interpolation = var->data.interpolation;
+existing.centroid = var->data.centroid;
+existing.sample = var->data.sample;
+existing.patch = var->data.patch;
+ }
+  }
+   }
+}
+
+
 bool
 link_varyings(struct gl_shader_program *prog, unsigned first, unsigned last,
   struct gl_context *ctx, void *mem_ctx)
@@ -2447,6 +2528,15 @@ link_varyings(struct gl_shader_program *prog, unsigned 
first, unsigned last,
char **varying_names = NULL;
tfeedback_decl *tfeedback_decls = NULL;
 
+   /* Ensure that no illegal type/interp/storage mixing exists within
+* explicitly-specified varying/attribute locations.
+*/
+   for (int i = MESA_SHADER_FRAGMENT - 1; i >= 0; i--)
+  if (prog->_LinkedShaders[i] != NULL)
+ check_location_mixing(prog,

Re: [Mesa-dev] [PATCH 0/5] radeonsi: enable out-of-order rasterization

2017-09-09 Thread Nicolai Hähnle 

On 09.09.2017 13:26, Bas Nieuwenhuizen wrote:

Out of curiosity, don't SI and CIK also support the out of order bits?
Why only enable it on VI?


According to internal docs, there's a lock-up bug on older chips.



(and would enabling it on 1 SE chips hurt anything?)


I don't think so, except for the added CPU overhead of evaluating the 
enable conditions.


Cheers,
Nicolai




On Sat, Sep 9, 2017 at 12:43 PM, Nicolai Hähnle  wrote:

Hi all,

This is my attempt at restructuring the logic for out-of-order
rasterization, including commutative blending cases. Tested on
Tonga and Polaris so far.

The series adds some new options:

R600_DEBUG=nooutoforder --> disable entirely

drirc options:

radeonsi_assume_no_z_fights --> as the name says, assume that
no geometry has equal Z values

radeonsi_commutative_blend_add --> treat additive blending as
commutative despite small, non-deterministic changes due to
different rounding

The whole series is here:
https://cgit.freedesktop.org/~nh/mesa/log/?h=out-of-order

Please review!

Thanks,
Nicolai
--
  src/amd/common/ac_surface.c  |   2 +
  src/amd/common/ac_surface.h  |   1 +
  src/amd/vulkan/radv_device.c |   6 +-
  src/gallium/drivers/r600/evergreen_state.c   |   2 +-
  src/gallium/drivers/r600/r600_blit.c |   2 +-
  src/gallium/drivers/r600/r600_state_common.c |   6 +-
  .../drivers/radeon/r600_pipe_common.c|   1 +
  .../drivers/radeon/r600_pipe_common.h|   6 +-
  src/gallium/drivers/radeon/r600_query.c  |   3 +-
  src/gallium/drivers/radeon/r600_texture.c|   4 +-
  .../drivers/radeonsi/driinfo_radeonsi.h  |   2 +
  src/gallium/drivers/radeonsi/si_blit.c   |   2 +-
  src/gallium/drivers/radeonsi/si_pipe.c   |   7 +
  src/gallium/drivers/radeonsi/si_pipe.h   |   3 +
  src/gallium/drivers/radeonsi/si_state.c  | 228 -
  src/gallium/drivers/radeonsi/si_state.h  |  29 ++-
  .../drivers/radeonsi/si_state_binning.c  |   2 +-
  .../drivers/radeonsi/si_state_shaders.c  |   7 +
  .../winsys/radeon/drm/radeon_drm_surface.c   |   1 +
  src/util/xmlpool/t_options.h |  10 +
  20 files changed, 300 insertions(+), 24 deletions(-)

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



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 95346, which changed state.

Bug 95346 Summary: Stellaris - Black/super dark planets
https://bugs.freedesktop.org/show_bug.cgi?id=95346

   What|Removed |Added

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

-- 
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 95346] Stellaris - Black/super dark planets

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=95346

Kai  changed:

   What|Removed |Added

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

--- Comment #28 from Kai  ---
Since nobody spoke up after comment #25 from Gert, comment #26 by myself and
I'm seeing good rendering with the stack detailed below, I'm closing this as
"fixed". If somebody still sees this with a current game version and driver
stack, they can reopen.

The stack used (fully updated Debian testing as a base) was:
Game version: Stellaris 1.6.2 (d7ec)
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/57a341b0a9
libdrm: 2.4.82-1
LLVM: SVN:trunk/r312707 (6.0 devel)
X.Org: 2:1.19.3-2
Linux: 4.13.0
Firmware (firmware-amd-graphics): 20170823-1
libclc: Git:master/7331b0a1fa
DDX (xserver-xorg-video-amdgpu): 1.3.0-1

-- 
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 102571] vulkaninfo fails with "trap divide error"

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102571

--- Comment #2 from Bas Nieuwenhuizen  ---
I can't reproduce. Can you do a crashing run with
RADV_DEBUG=shaders,shaderstats  and then upload the stdout+stderr?

if num_vgprs is really 0, I'd think something is really wrong.

-- 
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 99591] Segmentation fault when running vulkaninfo with RADV Radeon Vulkan driver

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99591

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

-- 
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 98406] [vulkan, radv] with Intel iGPU and AMD dGPU coruptions on display

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98406

Bas Nieuwenhuizen  changed:

   What|Removed |Added

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

--- Comment #4 from Bas Nieuwenhuizen  ---
This should be fixed now that we have copying to linear textures for different
GPUs implemented. Please reopen if that does not fix it for you.

-- 
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 98842] mesa 13.0.1 build broken under debian8

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98842

Bas Nieuwenhuizen  changed:

   What|Removed |Added

  Component|Drivers/Vulkan/radeon   |Mesa core

-- 
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 98714] Weird whitish spots and green stuff mostly on black.

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98714

Bas Nieuwenhuizen  changed:

   What|Removed |Added

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

--- Comment #7 from Bas Nieuwenhuizen  ---
The issue with cities skylines should be different, since AFAIU it is not using
vulkan. If you still have issues with that please file a new bug.

-- 
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 99319] godot engine poor performance

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99319

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Component|Drivers/Vulkan/radeon   |Drivers/Gallium/radeonsi
 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
 Status|NEW |RESOLVED
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

--- Comment #10 from Bas Nieuwenhuizen  ---
I think this was actually the rework Marek did to not use the gallium shared
vbo format preprocessing, which caused this. IIRC that is not really small
enough for backporting, besides 17.0 not getting releases anymore.

-- 
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 100951] vkcube fails with vkMapMemory failed

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100951

--- Comment #3 from Fabian Maurer  ---
(In reply to Bas Nieuwenhuizen from comment #2)
> vkcube is known broken, it allocates memory from a non-mappable memory type
> and then tries to map it.

Well, that was unexpected. Thanks for explaining, can confirm it work fine with
the samples from https://github.com/SaschaWillems/Vulkan !

-- 
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 100951] vkcube fails with vkMapMemory failed

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100951

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #2 from Bas Nieuwenhuizen  ---
vkcube is known broken, it allocates memory from a non-mappable memory type and
then tries to map it.

-- 
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 01/10] i965/screen: Add basic support for rendering 10 bpc/depth 30 framebuffers.

2017-09-09 Thread Mario Kleiner 



On 09/07/2017 04:27 PM, Emil Velikov wrote:

Hi Mario,

On 5 September 2017 at 06:01, Mario Kleiner  wrote:

Expose formats which are supported at least back to Gen 5 Ironlake,
possibly further. Allow creation of 10 bpc winsys buffers for drawables.

glxinfo now lists new RGBA 10 10 10 2/0 formats.
Works correctly under DRI2 without compositing.


In all fairness I did not expect apps to _not_ get confused by the
extra config(s).
Barring g-s (workaround in 8/10), have you seen any other apps that
exhibit problems?


So far not. DE's work, glxgears/es2gears, weston demos, my app, glmark 
are fine.



Say any steam games or SDL based apps?


I don't have access to any Steam games. neverball/neverputt is Opengl 
SDL-2 based and those work, both on X11 and Weston. I can nicely see 
color gradients in neverputt becoming smooth in 30 bit mode when they 
have some steps in 24 bit mode.





Signed-off-by: Mario Kleiner 
---
  src/mesa/drivers/dri/i965/intel_screen.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index d39509b..47008b5 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1486,7 +1486,13 @@ intelCreateBuffer(__DRIscreen *dri_screen,
fb->Visual.samples = num_samples;
 }

-   if (mesaVis->redBits == 5) {
+   if (mesaVis->redBits == 10 && mesaVis->alphaBits > 0) {
+  rgbFormat = mesaVis->redMask == 0x3ff0 ? 
MESA_FORMAT_B10G10R10A2_UNORM
+ : 
MESA_FORMAT_R10G10B10A2_UNORM;
+   } else if (mesaVis->redBits == 10) {
+  rgbFormat = mesaVis->redMask == 0x3ff0 ? 
MESA_FORMAT_B10G10R10X2_UNORM
+ : 
MESA_FORMAT_R10G10B10X2_UNORM;
+   } else if (mesaVis->redBits == 5) {
rgbFormat = mesaVis->redMask == 0x1f ? MESA_FORMAT_R5G6B5_UNORM
 : MESA_FORMAT_B5G6R5_UNORM;

Unrelated: At some point we should flesh this out to a helper.



 } else if (mesaVis->sRGBCapable) {
@@ -1874,6 +1880,10 @@ intel_screen_make_configs(__DRIscreen *dri_screen)

/* Required by Android, for HAL_PIXEL_FORMAT_RGBX_. */
MESA_FORMAT_R8G8B8X8_UNORM,
+
+  /* For 10 bpc, 30 bit depth framebuffers */
+  MESA_FORMAT_B10G10R10A2_UNORM,
+  MESA_FORMAT_B10G10R10X2_UNORM,

Please make sure these are before the Android RGB* ones. The


Fixed.


ARRAY_SIZE() further down, will need a tweak.


This i don't understand? ARRAY_SIZE seems to be generic enough to not 
need tweaks based on the arrays content?


-mario



-Emil


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

Re: [Mesa-dev] [PATCH 1/2] util: add util_vasprintf() for Windows

2017-09-09 Thread Nicolai Hähnle 

On 09.09.2017 00:55, Brian Paul wrote:

We don't have vasprintf() on Windows so we need to implement it ourselves.
Since we don't know the length of the final string, take a guess at 1
chars.
---
  src/util/u_string.h | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/src/util/u_string.h b/src/util/u_string.h
index e88e13f..d787cd3 100644
--- a/src/util/u_string.h
+++ b/src/util/u_string.h
@@ -110,6 +110,16 @@ util_sprintf(char *str, const char *format, ...)
 va_end(ap);
  }
  
+static inline int

+util_vasprintf(char **ret, const char *format, va_list ap)
+{
+   /* Just allocate 1 bytes as a guess */

> +   *ret = (char *) malloc(1);

I'd suggest something like the following instead (untested):

   va_list ap_copy;
   va_copy(ap_copy, ap);
   int r = util_vsnprintf(NULL, 0, format, ap);
   va_end(ap_copy);

   if (r < 0)
  return -1;

   *ret = (char *) malloc(r + 1);
   if (!ret)
  return -1;

   return util_vsnprintf(*ret, r + 1, format, ap);

Cheers,
Nicolai


+   if (!ret)
+  return -1;
+   return util_vsnprintf(*ret, 1, format, ap);
+}
+
  static inline char *
  util_strchr(const char *s, char c)
  {
@@ -186,6 +196,7 @@ util_strstr(const char *haystack, const char *needle)
  #define util_vsnprintf vsnprintf
  #define util_snprintf snprintf
  #define util_vsprintf vsprintf
+#define util_vasprintf vasprintf
  #define util_sprintf sprintf
  #define util_strchr strchr
  #define util_strcmp strcmp




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/5] radeonsi: enable out-of-order rasterization

2017-09-09 Thread Bas Nieuwenhuizen 
Out of curiosity, don't SI and CIK also support the out of order bits?
Why only enable it on VI?

(and would enabling it on 1 SE chips hurt anything?)

On Sat, Sep 9, 2017 at 12:43 PM, Nicolai Hähnle  wrote:
> Hi all,
>
> This is my attempt at restructuring the logic for out-of-order
> rasterization, including commutative blending cases. Tested on
> Tonga and Polaris so far.
>
> The series adds some new options:
>
> R600_DEBUG=nooutoforder --> disable entirely
>
> drirc options:
>
> radeonsi_assume_no_z_fights --> as the name says, assume that
> no geometry has equal Z values
>
> radeonsi_commutative_blend_add --> treat additive blending as
> commutative despite small, non-deterministic changes due to
> different rounding
>
> The whole series is here:
> https://cgit.freedesktop.org/~nh/mesa/log/?h=out-of-order
>
> Please review!
>
> Thanks,
> Nicolai
> --
>  src/amd/common/ac_surface.c  |   2 +
>  src/amd/common/ac_surface.h  |   1 +
>  src/amd/vulkan/radv_device.c |   6 +-
>  src/gallium/drivers/r600/evergreen_state.c   |   2 +-
>  src/gallium/drivers/r600/r600_blit.c |   2 +-
>  src/gallium/drivers/r600/r600_state_common.c |   6 +-
>  .../drivers/radeon/r600_pipe_common.c|   1 +
>  .../drivers/radeon/r600_pipe_common.h|   6 +-
>  src/gallium/drivers/radeon/r600_query.c  |   3 +-
>  src/gallium/drivers/radeon/r600_texture.c|   4 +-
>  .../drivers/radeonsi/driinfo_radeonsi.h  |   2 +
>  src/gallium/drivers/radeonsi/si_blit.c   |   2 +-
>  src/gallium/drivers/radeonsi/si_pipe.c   |   7 +
>  src/gallium/drivers/radeonsi/si_pipe.h   |   3 +
>  src/gallium/drivers/radeonsi/si_state.c  | 228 -
>  src/gallium/drivers/radeonsi/si_state.h  |  29 ++-
>  .../drivers/radeonsi/si_state_binning.c  |   2 +-
>  .../drivers/radeonsi/si_state_shaders.c  |   7 +
>  .../winsys/radeon/drm/radeon_drm_surface.c   |   1 +
>  src/util/xmlpool/t_options.h |  10 +
>  20 files changed, 300 insertions(+), 24 deletions(-)
>
> ___
> 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 5/5] radeonsi: allow out-of-order rasterization in commutative blending cases

2017-09-09 Thread Nicolai Hähnle 
From: Nicolai Hähnle 

We do not enable this by default for additive blending, since it slightly
breaks OpenGL invariance guarantees due to non-determinism.

Still, there may be some applications can benefit from white-listing
via the radeonsi_commutative_blend_add drirc setting without any real
visible artifacts.
---
 src/gallium/drivers/radeonsi/driinfo_radeonsi.h |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c  |  2 +
 src/gallium/drivers/radeonsi/si_pipe.h  |  1 +
 src/gallium/drivers/radeonsi/si_state.c | 67 +++--
 src/gallium/drivers/radeonsi/si_state.h |  1 +
 src/util/xmlpool/t_options.h|  5 ++
 6 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h 
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8be85289a0c..989e5175cc0 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,5 +1,6 @@
 // DriConf options specific to radeonsi
 DRI_CONF_SECTION_PERFORMANCE
 DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
 DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
+DRI_CONF_RADEONSI_COMMUTATIVE_BLEND_ADD("false")
 DRI_CONF_SECTION_END
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index b4972be739c..c44ea3be740 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -1043,20 +1043,22 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
(sscreen->b.chip_class == SI &&
 sscreen->b.info.pfp_fw_version >= 79 &&
 sscreen->b.info.me_fw_version >= 142);
 
sscreen->has_ds_bpermute = sscreen->b.chip_class >= VI;
sscreen->has_out_of_order_rast = sscreen->b.chip_class >= VI &&
 sscreen->b.info.max_se >= 2 &&
 !(sscreen->b.debug_flags & 
DBG_NO_OUT_OF_ORDER);
sscreen->assume_no_z_fights =
driQueryOptionb(config->options, "radeonsi_assume_no_z_fights");
+   sscreen->commutative_blend_add =
+   driQueryOptionb(config->options, 
"radeonsi_commutative_blend_add");
sscreen->has_msaa_sample_loc_bug = (sscreen->b.family >= CHIP_POLARIS10 
&&
sscreen->b.family <= 
CHIP_POLARIS12) ||
   sscreen->b.family == CHIP_VEGA10 ||
   sscreen->b.family == CHIP_RAVEN;
sscreen->dpbb_allowed = sscreen->b.chip_class >= GFX9 &&
!(sscreen->b.debug_flags & DBG_NO_DPBB);
sscreen->dfsm_allowed = sscreen->dpbb_allowed &&
!(sscreen->b.debug_flags & DBG_NO_DFSM);
 
/* While it would be nice not to have this flag, we are constrained
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index d200c9f571f..27e2bc81172 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -90,20 +90,21 @@ struct u_suballocator;
 struct si_screen {
struct r600_common_screen   b;
unsignedgs_table_depth;
unsignedtess_offchip_block_dw_size;
boolhas_clear_state;
boolhas_distributed_tess;
boolhas_draw_indirect_multi;
boolhas_ds_bpermute;
boolhas_out_of_order_rast;
boolassume_no_z_fights;
+   boolcommutative_blend_add;
boolhas_msaa_sample_loc_bug;
booldpbb_allowed;
booldfsm_allowed;
boolllvm_has_working_vgpr_indexing;
 
/* Whether shaders are monolithic (1-part) or separate (3-part). */
booluse_monolithic_shaders;
boolrecord_llvm_ir;
 
mtx_t   shader_parts_mutex;
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index a8af5752771..6a063e7f7a6 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -370,20 +370,62 @@ static uint32_t si_translate_blend_opt_factor(int 
blend_fact, bool is_alpha)
case PIPE_BLENDFACTOR_INV_SRC_ALPHA:
return V_028760_BLEND_OPT_PRESERVE_A0_IGNORE_A1;
case PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE:
return is_alpha ? V_028760_BLEND_OPT_PRESERVE_ALL_IGNORE_NONE
: V_028760_BLEND_OPT_PRESERVE_NONE_IGNORE_A0;

[Mesa-dev] [PATCH 0/5] radeonsi: enable out-of-order rasterization

2017-09-09 Thread Nicolai Hähnle 
Hi all,

This is my attempt at restructuring the logic for out-of-order
rasterization, including commutative blending cases. Tested on
Tonga and Polaris so far.

The series adds some new options:

R600_DEBUG=nooutoforder --> disable entirely

drirc options:

radeonsi_assume_no_z_fights --> as the name says, assume that
no geometry has equal Z values

radeonsi_commutative_blend_add --> treat additive blending as
commutative despite small, non-deterministic changes due to
different rounding

The whole series is here:
https://cgit.freedesktop.org/~nh/mesa/log/?h=out-of-order

Please review!

Thanks,
Nicolai
--
 src/amd/common/ac_surface.c  |   2 +
 src/amd/common/ac_surface.h  |   1 +
 src/amd/vulkan/radv_device.c |   6 +-
 src/gallium/drivers/r600/evergreen_state.c   |   2 +-
 src/gallium/drivers/r600/r600_blit.c |   2 +-
 src/gallium/drivers/r600/r600_state_common.c |   6 +-
 .../drivers/radeon/r600_pipe_common.c|   1 +
 .../drivers/radeon/r600_pipe_common.h|   6 +-
 src/gallium/drivers/radeon/r600_query.c  |   3 +-
 src/gallium/drivers/radeon/r600_texture.c|   4 +-
 .../drivers/radeonsi/driinfo_radeonsi.h  |   2 +
 src/gallium/drivers/radeonsi/si_blit.c   |   2 +-
 src/gallium/drivers/radeonsi/si_pipe.c   |   7 +
 src/gallium/drivers/radeonsi/si_pipe.h   |   3 +
 src/gallium/drivers/radeonsi/si_state.c  | 228 -
 src/gallium/drivers/radeonsi/si_state.h  |  29 ++-
 .../drivers/radeonsi/si_state_binning.c  |   2 +-
 .../drivers/radeonsi/si_state_shaders.c  |   7 +
 .../winsys/radeon/drm/radeon_drm_surface.c   |   1 +
 src/util/xmlpool/t_options.h |  10 +
 20 files changed, 300 insertions(+), 24 deletions(-)

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

[Mesa-dev] [PATCH 3/5] radeonsi: enable out-of-order rasterization when possible on VI and GFX9 dGPUs

2017-09-09 Thread Nicolai Hähnle 
From: Nicolai Hähnle 

This does not take commutative blending into account yet.

R600_DEBUG=nooutoforder disables it.
---
 src/gallium/drivers/radeon/r600_pipe_common.c   |   1 +
 src/gallium/drivers/radeon/r600_pipe_common.h   |   2 +-
 src/gallium/drivers/radeonsi/si_pipe.c  |   3 +
 src/gallium/drivers/radeonsi/si_pipe.h  |   1 +
 src/gallium/drivers/radeonsi/si_state.c | 157 +++-
 src/gallium/drivers/radeonsi/si_state.h |  28 -
 src/gallium/drivers/radeonsi/si_state_shaders.c |   7 ++
 7 files changed, 193 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 1302e112c03..64851c615b0 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -818,20 +818,21 @@ static const struct debug_named_value 
common_debug_options[] = {
{ "check_vm", DBG_CHECK_VM, "Check VM faults and dump debug info." },
{ "nodcc", DBG_NO_DCC, "Disable DCC." },
{ "nodccclear", DBG_NO_DCC_CLEAR, "Disable DCC fast clear." },
{ "norbplus", DBG_NO_RB_PLUS, "Disable RB+." },
{ "sisched", DBG_SI_SCHED, "Enable LLVM SI Machine Instruction 
Scheduler." },
{ "mono", DBG_MONOLITHIC_SHADERS, "Use old-style monolithic shaders 
compiled on demand" },
{ "unsafemath", DBG_UNSAFE_MATH, "Enable unsafe math shader 
optimizations" },
{ "nodccfb", DBG_NO_DCC_FB, "Disable separate DCC on the main 
framebuffer" },
{ "nodpbb", DBG_NO_DPBB, "Disable DPBB." },
{ "nodfsm", DBG_NO_DFSM, "Disable DFSM." },
+   { "nooutoforder", DBG_NO_OUT_OF_ORDER, "Disable out-of-order 
rasterization" },
 
DEBUG_NAMED_VALUE_END /* must be last */
 };
 
 static const char* r600_get_vendor(struct pipe_screen* pscreen)
 {
return "X.Org";
 }
 
 static const char* r600_get_device_vendor(struct pipe_screen* pscreen)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ed93d99669f..6074f4d440e 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -103,21 +103,21 @@ struct u_log_context;
 #define DBG_FORCE_DMA  (1ull << 38)
 #define DBG_PRECOMPILE (1ull << 39)
 #define DBG_INFO   (1ull << 40)
 #define DBG_NO_WC  (1ull << 41)
 #define DBG_CHECK_VM   (1ull << 42)
 #define DBG_NO_DCC (1ull << 43)
 #define DBG_NO_DCC_CLEAR   (1ull << 44)
 #define DBG_NO_RB_PLUS (1ull << 45)
 #define DBG_SI_SCHED   (1ull << 46)
 #define DBG_MONOLITHIC_SHADERS (1ull << 47)
-/* gap */
+#define DBG_NO_OUT_OF_ORDER(1ull << 48)
 #define DBG_UNSAFE_MATH(1ull << 49)
 #define DBG_NO_DCC_FB  (1ull << 50)
 #define DBG_TEST_VMFAULT_CP(1ull << 51)
 #define DBG_TEST_VMFAULT_SDMA  (1ull << 52)
 #define DBG_TEST_VMFAULT_SHADER(1ull << 53)
 #define DBG_NO_DPBB(1ull << 54)
 #define DBG_NO_DFSM(1ull << 55)
 
 #define R600_MAP_BUFFER_ALIGNMENT 64
 #define R600_MAX_VIEWPORTS16
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index ca2e055a90e..9f3651f2526 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -1038,20 +1038,23 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
 sscreen->b.info.pfp_fw_version >= 121 &&
 sscreen->b.info.me_fw_version >= 87) ||
(sscreen->b.chip_class == CIK &&
 sscreen->b.info.pfp_fw_version >= 211 &&
 sscreen->b.info.me_fw_version >= 173) ||
(sscreen->b.chip_class == SI &&
 sscreen->b.info.pfp_fw_version >= 79 &&
 sscreen->b.info.me_fw_version >= 142);
 
sscreen->has_ds_bpermute = sscreen->b.chip_class >= VI;
+   sscreen->has_out_of_order_rast = sscreen->b.chip_class >= VI &&
+sscreen->b.info.max_se >= 2 &&
+!(sscreen->b.debug_flags & 
DBG_NO_OUT_OF_ORDER);
sscreen->has_msaa_sample_loc_bug = (sscreen->b.family >= CHIP_POLARIS10 
&&
sscreen->b.family <= 
CHIP_POLARIS12) ||
   sscreen->b.family == CHIP_VEGA10 ||
   sscreen->b.family == CHIP_RAVEN;
sscreen->dpbb_allowed = sscreen->b.chip_class >= GFX9 &&
!(sscreen->b.debug_flags & DBG_NO_DPBB);
sscreen->dfsm_allowed = sscreen->dpbb_allowed &&
!(sscreen->b.debug_flags & DBG_NO_DFSM);
 
/* While it would be nice not to have this flag, we are constrained
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h

[Mesa-dev] [PATCH 1/5] ac/surface: add radeon_surf::has_stencil for convenience

2017-09-09 Thread Nicolai Hähnle 
From: Marek Olšák 

Reviewed-by: Nicolai Hähnle 
---
 src/amd/common/ac_surface.c| 2 ++
 src/amd/common/ac_surface.h| 1 +
 src/amd/vulkan/radv_device.c   | 6 +++---
 src/gallium/drivers/r600/evergreen_state.c | 2 +-
 src/gallium/drivers/r600/r600_blit.c   | 2 +-
 src/gallium/drivers/r600/r600_state_common.c   | 2 +-
 src/gallium/drivers/radeon/r600_texture.c  | 4 ++--
 src/gallium/drivers/radeonsi/si_blit.c | 2 +-
 src/gallium/drivers/radeonsi/si_state.c| 8 
 src/gallium/drivers/radeonsi/si_state_binning.c| 2 +-
 src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 1 +
 11 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 4edefc7c40a..c6ff57362f7 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -648,20 +648,21 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
if (AddrSurfInfoIn.tileType == ADDR_DISPLAYABLE)
AddrSurfInfoIn.tileIndex = 10; /* 2D 
displayable */
else
AddrSurfInfoIn.tileIndex = 14; /* 2D 
non-displayable */
 
/* Addrlib doesn't set this if tileIndex is forced like 
above. */
AddrSurfInfoOut.macroModeIndex = 
cik_get_macro_tile_index(surf);
}
}
 
+   surf->has_stencil = !!(surf->flags & RADEON_SURF_SBUFFER);
surf->num_dcc_levels = 0;
surf->surf_size = 0;
surf->dcc_size = 0;
surf->dcc_alignment = 1;
surf->htile_size = 0;
surf->htile_slice_size = 0;
surf->htile_alignment = 1;
 
const bool only_stencil = (surf->flags & RADEON_SURF_SBUFFER) &&
  !(surf->flags & RADEON_SURF_ZBUFFER);
@@ -1070,20 +1071,21 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,

);
if (r)
return r;
break;
 
default:
assert(0);
}
 
surf->u.gfx9.resource_type = AddrSurfInfoIn.resourceType;
+   surf->has_stencil = !!(surf->flags & RADEON_SURF_SBUFFER);
 
surf->num_dcc_levels = 0;
surf->surf_size = 0;
surf->dcc_size = 0;
surf->htile_size = 0;
surf->htile_slice_size = 0;
surf->u.gfx9.surf_offset = 0;
surf->u.gfx9.stencil_offset = 0;
surf->u.gfx9.fmask_size = 0;
surf->u.gfx9.cmask_size = 0;
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 3b993860773..96138b968ab 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -153,20 +153,21 @@ struct radeon_surf {
 /* Format properties. */
 unsignedblk_w:4;
 unsignedblk_h:4;
 unsignedbpe:5;
 /* Number of mipmap levels where DCC is enabled starting from level 0.
  * Non-zero levels may be disabled due to alignment constraints, but not
  * the first level.
  */
 unsignednum_dcc_levels:4;
 unsignedis_linear:1;
+unsignedhas_stencil:1;
 /* Displayable, thin, depth, rotated. AKA D,S,Z,R swizzle modes. */
 unsignedmicro_tile_mode:3;
 uint32_tflags;
 
 /* These are return values. Some of them can be set by the caller, but
  * they will be treated as hints (e.g. bankw, bankh) and might be
  * changed by the calculator.
  */
 
 /* Tile swizzle can be OR'd with low bits of the BASE_256B address.
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 7c218b14783..b64a02380d6 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -3134,21 +3134,21 @@ radv_initialise_ds_surface(struct radv_device *device,
ds->offset_scale = 1.0f;
break;
case VK_FORMAT_S8_UINT:
stencil_only = true;
break;
default:
break;
}
 
format = radv_translate_dbformat(iview->image->vk_format);
-   stencil_format = iview->image->surface.flags & RADEON_SURF_SBUFFER ?
+   stencil_format = iview->image->surface.has_stencil ?
V_028044_STENCIL_8 : V_028044_STENCIL_INVALID;
 
uint32_t max_slice = radv_surface_layer_count(iview);
ds->db_depth_view = S_028008_SLICE_START(iview->base_layer) |
S_028008_SLICE_MAX(iview->base_layer + max_slice - 1);
 
ds->db_htile_data_base = 0;
ds->db_htile_surface = 0;
 
va = device->ws->buffer_get_va(iview->bo) + iview->image->offset;
@@ -3169,21 +3169,21 @@ radv_initialise_ds_surface(struct

[Mesa-dev] [PATCH 4/5] radeonsi: add drirc option "radeonsi_assume_no_z_fights"

2017-09-09 Thread Nicolai Hähnle 
From: Nicolai Hähnle 

This option enables a performance optimization where typical non-blending
draws with depth buffer may be rasterized out-of-order (on VI+, multi-SE
chips).

This optimization can lead to incorrect results when an applications
renders multiple objects with the same Z value at the same pixel, so we
will never enable it by default. But there may be applications that could
benefit from white-listing.
---
 src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 1 +
 src/gallium/drivers/radeonsi/si_pipe.c  | 2 ++
 src/gallium/drivers/radeonsi/si_pipe.h  | 1 +
 src/gallium/drivers/radeonsi/si_state.c | 8 
 src/util/xmlpool/t_options.h| 5 +
 5 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h 
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index af6284a7787..8be85289a0c 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,5 @@
 // DriConf options specific to radeonsi
 DRI_CONF_SECTION_PERFORMANCE
 DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
+DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
 DRI_CONF_SECTION_END
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9f3651f2526..b4972be739c 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -1041,20 +1041,22 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
 sscreen->b.info.pfp_fw_version >= 211 &&
 sscreen->b.info.me_fw_version >= 173) ||
(sscreen->b.chip_class == SI &&
 sscreen->b.info.pfp_fw_version >= 79 &&
 sscreen->b.info.me_fw_version >= 142);
 
sscreen->has_ds_bpermute = sscreen->b.chip_class >= VI;
sscreen->has_out_of_order_rast = sscreen->b.chip_class >= VI &&
 sscreen->b.info.max_se >= 2 &&
 !(sscreen->b.debug_flags & 
DBG_NO_OUT_OF_ORDER);
+   sscreen->assume_no_z_fights =
+   driQueryOptionb(config->options, "radeonsi_assume_no_z_fights");
sscreen->has_msaa_sample_loc_bug = (sscreen->b.family >= CHIP_POLARIS10 
&&
sscreen->b.family <= 
CHIP_POLARIS12) ||
   sscreen->b.family == CHIP_VEGA10 ||
   sscreen->b.family == CHIP_RAVEN;
sscreen->dpbb_allowed = sscreen->b.chip_class >= GFX9 &&
!(sscreen->b.debug_flags & DBG_NO_DPBB);
sscreen->dfsm_allowed = sscreen->dpbb_allowed &&
!(sscreen->b.debug_flags & DBG_NO_DFSM);
 
/* While it would be nice not to have this flag, we are constrained
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index b8073ce9c09..d200c9f571f 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -89,20 +89,21 @@ struct u_suballocator;
 
 struct si_screen {
struct r600_common_screen   b;
unsignedgs_table_depth;
unsignedtess_offchip_block_dw_size;
boolhas_clear_state;
boolhas_distributed_tess;
boolhas_draw_indirect_multi;
boolhas_ds_bpermute;
boolhas_out_of_order_rast;
+   boolassume_no_z_fights;
boolhas_msaa_sample_loc_bug;
booldpbb_allowed;
booldfsm_allowed;
boolllvm_has_working_vgpr_indexing;
 
/* Whether shaders are monolithic (1-part) or separate (3-part). */
booluse_monolithic_shaders;
boolrecord_llvm_ir;
 
mtx_t   shader_parts_mutex;
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 06f86aaf92a..a8af5752771 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1087,20 +1087,21 @@ static bool si_order_invariant_stencil_state(const 
struct pipe_stencil_state *st
   (state->func == PIPE_FUNC_ALWAYS &&
si_order_invariant_stencil_op(state->zpass_op) &&
si_order_invariant_stencil_op(state->zfail_op)) ||
   (state->func == PIPE_FUNC_NEVER &&
si_order_invariant_stencil_op(state->fail_op));
 }
 
 static void *si_create_dsa_state(struct pipe_context *ctx,
 const struct

[Mesa-dev] [PATCH 2/5] gallium/radeon: pass old_(perfect_)enable to set_occlusion_query_state

2017-09-09 Thread Nicolai Hähnle 
From: Nicolai Hähnle 

The callee can derive the current enable state itself.
---
 src/gallium/drivers/r600/r600_state_common.c  | 4 +++-
 src/gallium/drivers/radeon/r600_pipe_common.h | 4 +++-
 src/gallium/drivers/radeon/r600_query.c   | 3 ++-
 src/gallium/drivers/radeonsi/si_state.c   | 4 +++-
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index c1bce8304b2..d9b47299b6e 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -2903,21 +2903,23 @@ static void r600_set_active_query_state(struct 
pipe_context *ctx, boolean enable
rctx->b.flags |= R600_CONTEXT_STOP_PIPELINE_STATS;
}
 
/* Occlusion queries. */
if (rctx->db_misc_state.occlusion_queries_disabled != !enable) {
rctx->db_misc_state.occlusion_queries_disabled = !enable;
r600_mark_atom_dirty(rctx, >db_misc_state.atom);
}
 }
 
-static void r600_set_occlusion_query_state(struct pipe_context *ctx, bool 
enable)
+static void r600_set_occlusion_query_state(struct pipe_context *ctx,
+  bool old_enable,
+  bool old_perfect_enable)
 {
struct r600_context *rctx = (struct r600_context*)ctx;
 
r600_mark_atom_dirty(rctx, >db_misc_state.atom);
 }
 
 static void r600_need_gfx_cs_space(struct pipe_context *ctx, unsigned num_dw,
bool include_draw_vbo)
 {
r600_need_cs_space((struct r600_context*)ctx, num_dw, include_draw_vbo);
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 42480ec84b0..ed93d99669f 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -697,21 +697,23 @@ struct r600_common_context {
 * the buffer is bound, including all resource descriptors. */
void (*invalidate_buffer)(struct pipe_context *ctx, struct 
pipe_resource *buf);
 
/* Update all resource bindings where the buffer is bound, including
 * all resource descriptors. This is invalidate_buffer without
 * the invalidation. */
void (*rebind_buffer)(struct pipe_context *ctx, struct pipe_resource 
*buf,
  uint64_t old_gpu_address);
 
/* Enable or disable occlusion queries. */
-   void (*set_occlusion_query_state)(struct pipe_context *ctx, bool 
enable);
+   void (*set_occlusion_query_state)(struct pipe_context *ctx,
+ bool old_enable,
+ bool old_perfect_enable);
 
void (*save_qbo_state)(struct pipe_context *ctx, struct r600_qbo_state 
*st);
 
/* This ensures there is enough space in the command stream. */
void (*need_gfx_cs_space)(struct pipe_context *ctx, unsigned num_dw,
  bool include_draw_vbo);
 
void (*set_atom_dirty)(struct r600_common_context *ctx,
   struct r600_atom *atom, bool dirty);
 
diff --git a/src/gallium/drivers/radeon/r600_query.c 
b/src/gallium/drivers/radeon/r600_query.c
index 03ff1018a71..8c2efda356f 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -703,21 +703,22 @@ static void r600_update_occlusion_query_state(struct 
r600_common_context *rctx,
 
if (type == PIPE_QUERY_OCCLUSION_COUNTER) {
rctx->num_perfect_occlusion_queries += diff;
assert(rctx->num_perfect_occlusion_queries >= 0);
}
 
enable = rctx->num_occlusion_queries != 0;
perfect_enable = rctx->num_perfect_occlusion_queries != 0;
 
if (enable != old_enable || perfect_enable != 
old_perfect_enable) {
-   rctx->set_occlusion_query_state(>b, enable);
+   rctx->set_occlusion_query_state(>b, old_enable,
+   old_perfect_enable);
}
}
 }
 
 static unsigned event_type_for_stream(unsigned stream)
 {
switch (stream) {
default:
case 0: return EVENT_TYPE_SAMPLE_STREAMOUTSTATS;
case 1: return EVENT_TYPE_SAMPLE_STREAMOUTSTATS1;
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index ee070107fd5..6978c6ca9a2 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1184,21 +1184,23 @@ static void si_set_active_query_state(struct 
pipe_context *ctx, boolean enable)
sctx->b.flags |= R600_CONTEXT_STOP_PIPELINE_STATS;
}
 
/* Occlusion queries. */
if (sctx->occlusion_queries_disabled != !enable)

Re: [Mesa-dev] [PATCH 06/10] dri/common: Add option to disable exposure of 10 bpc color configs.

2017-09-09 Thread Mario Kleiner 

On 09/07/2017 04:33 PM, Emil Velikov wrote:

On 5 September 2017 at 06:01, Mario Kleiner  wrote:

A few clients don't like RGB10X2 and RGB10A2 fbconfigs and
visuals. Add a new driconf option 'expose_rgb10_configs' to
allow per application enable/disable.

The option defaults to enabled.


Most configs tends to be called "force.." or "allow...". How about we
use the allow here?



Yes, makes sense. I wonder if we should call it more generally 
allow_deep_color or something like that, as a general switch for any 
format with more than the usual rgb888 precision? Assuming any client 
that has trouble with 1010102 would also have the same kind of trouble 
with future higher bit depths?



Signed-off-by: Mario Kleiner 
---
  src/mesa/drivers/dri/common/dri_util.c | 11 +++
  src/util/xmlpool/t_options.h   |  5 +
  2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index 31a3040..972a1a4 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -55,6 +55,10 @@ const char __dri2ConfigOptions[] =
DRI_CONF_SECTION_PERFORMANCE
   DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_1)
DRI_CONF_SECTION_END
+
+  DRI_CONF_SECTION_MISCELLANEOUS
+ DRI_CONF_EXPOSE_RGB10_CONFIGS("true")
+  DRI_CONF_SECTION_END
 DRI_CONF_END;

  /*/
@@ -144,6 +148,9 @@ driCreateNewScreen2(int scrn, int fd,
  psp->fd = fd;
  psp->myNum = scrn;

+driParseOptionInfo(>optionInfo, __dri2ConfigOptions);
+driParseConfigFiles(>optionCache, >optionInfo, psp->myNum, 
"dri2");
+

Please add a note why drirc should be parsed before InitScreen.
Otherwise someone might unintentionally move it.



Will do.
-mario



-Emil


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

Re: [Mesa-dev] [PATCH 09/10] egl/x11: Match depth 30 RGB visuals to 32-bit RGBA EGLConfigs.

2017-09-09 Thread Mario Kleiner 



On 09/07/2017 04:38 PM, Emil Velikov wrote:

On 7 September 2017 at 01:51, Mario Kleiner  wrote:

On 09/06/2017 03:18 PM, Eric Engestrom wrote:


On Tuesday, 2017-09-05 07:01:13 +0200, Mario Kleiner wrote:


Similar to the matching of 24 bit RGB visuals to 32-bit
RGBA EGLConfigs.

Fixes failure of piglit egl tests to select ARGB2101010
visuals via eglChooseConfig() with EGL_ALPHA_BITS 2 on
a depth 30 X-Screen.

Signed-off-by: Mario Kleiner 
---
   src/egl/drivers/dri2/platform_x11.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index 062c8a4..df768ab 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -781,13 +781,14 @@ dri2_x11_add_configs_for_visuals(struct
dri2_egl_display *dri2_dpy,
 config_count++;
 /* Allow a 24-bit RGB visual to match a 32-bit RGBA
EGLConfig.
+ * Ditto for 30-bit RGB visuals to match a 32-bit RGBA
EGLConfig.
* Otherwise it will only match a 32-bit RGBA visual.  On a
* composited window manager on X11, this will make all of
the
* EGLConfigs with destination alpha get blended by the
* compositor.  This is probably not what the application
* wants... especially on drivers that only have 32-bit
RGBA
* EGLConfigs! */
-if (d.data->depth == 24) {
+if (d.data->depth == 24 || d.data->depth == 30) {
  rgba_masks[3] =
 ~(rgba_masks[0] | rgba_masks[1] | rgba_masks[2]);
  dri2_conf = dri2_add_config(disp, config, config_count +
1,
--
2.7.4



Haven't looked into it in details, but I feel like the two switches in
swrastCreateDrawable() and dri2_create_image_khr_pixmap() would need
updating as well, don't they? (probably as a separate patch though)



Thanks for the feedback. Will check this and do so in some add-on patches.


I added some handling to the swrastCreateDrawable, which seems to work 
fine. I also think most egl platforms (surfaceless, drm/gbm, wayland 
confirmed via testing) should be fine. Android would still need to be 
extended if it already has some HAL formats with 10 bits? Not sure if i 
should do this, as atm. it only exposes 8 bpc formats to clients, which 
it handles.


For the x11/egl backend, the dri2_create_image_khr_pixmap() and 
dri3_create_image_khr_pixmap() are a bit of a problem. They derive the 
format from the drawables depth, which i think is ambiguous for depth 32 
(argb or argb2101010). This is used for compositing under x11/egl, 
e.g., by KDE Plasma's optional EGL+OpenGL compositing method (GLX+OpenGL 
is the default under X11). I added a case 30: --> XRGB2101010, and 
testing, also with photometer, shows clients get properly composited 
with 30 bit depth. Depth 32 drawables - still mapping to argb, 
magically also work without visual artifacts, although i don't know why?


The currently used xcb requests to the server don't carry info about the 
true color format of pixmaps.




Can you please check that workloads as mentioned in commit
11a955aef42730ab009490f03c03c54ed07db666 still work.



These work. I used apitrace quite a bit during testing, so the retracers 
work fine.



Thanks
Emil


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

[Mesa-dev] [Bug 102634] 0 Color write masks with multiple render targets redirects color outputs to wrong attachment

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102634

--- Comment #1 from mais...@archlinux.us ---
Created attachment 134108
  --> https://bugs.freedesktop.org/attachment.cgi?id=134108=edit
Wrong output when WORKAROUND_RADV = 0

-- 
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 102634] 0 Color write masks with multiple render targets redirects color outputs to wrong attachment

2017-09-09 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102634

Bug ID: 102634
   Summary: 0 Color write masks with multiple render targets
redirects color outputs to wrong attachment
   Product: Mesa
   Version: 17.1
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mais...@archlinux.us
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 134107
  --> https://bugs.freedesktop.org/attachment.cgi?id=134107=edit
Expected output

Hardware: RX 470
Mesa: 17.1.8
OS: Arch Linux

I have a deferred shader which emits color data to 4 attachments. When
colorWriteMask of all attachments are 0xf, this works as expected, but when I
try to mask out writes to layout(location = 0), it is almost as if all the
attachments are reshuffled so that location = 1 writes to attachment 0,
location = 2 writes to attachment = 1 ... and so on.

Here is the current workaround I must apply:
https://github.com/Themaister/Granite/blob/master/assets/shaders/inc/render_target.h#L8

The scenario which fails:
- 4 color attachments in a subpass
- Color masks are {0, 0xf, 0xf, 0xf}
- The shader does not declare layout(location = 0) output

To reproduce:
Build Granite: https://github.com/Themaister/Granite
Run Suzanne model: ./granite/tests/gltf-viewer
~/git/glTF-Sample-Models/2.0/Suzanne/glTF/Suzanne.gltf

Fiddle with WORKAROUND_RADV define mentioned above:

-- 
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 10/10] egl/dri2: Add Wayland+EGL support for RGB10 winsys buffers.

2017-09-09 Thread Mario Kleiner 

On 09/07/2017 04:45 PM, Emil Velikov wrote:

Hi Mario,



Hi Emil, and thanks for all the feedback.


On 5 September 2017 at 06:01, Mario Kleiner  wrote:

Successfully tested under Weston 3.0, both with the new
(experimental) dmabuf+modifiers path, and the old buffer
import path. Photometer confirms 10 rgb bits from rendering
to display.


Can you split the patch in to wl_drm and wl_dmabuf ones, please?
It will be easier to check if we haven't missed anything.



Will do.


While there, please consistently insert the new format handling.
Currently it's at the top, in the middle or at the end, wrt the other formats.



Will try. I tried to follow the order that was there: If order was low 
precision rgb565 first, then higher precision rgb888 further down i 
tried to add rgb101010 below, otherwise above. But maybe i missed some 
instances.


-mario


Thanks
Emil


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

Re: [Mesa-dev] [PATCH 08/10] drirc: Don't expose 10 bpc visuals/configs to gnome-shell.

2017-09-09 Thread Mario Kleiner 

On 09/08/2017 05:21 AM, Michel Dänzer wrote:

On 08/09/17 12:26 AM, Marek Olšák wrote:

[+ Dave]

We can also ignore gnome-shell in Mesa for now and let the gnome-shell
maintainers fix the issue in gnome-shell.


Indeed, that would be better.



[+ Jonas Adahl] probably a good person to ping wrt. this?

You mean we shouldn't provide the driconf workaround for gnome-shell?

That would make g-s wayland pretty much unusable in a very colorful way 
until it's fixed. On X11 g-s works perfectly fine at Screen DefaultDepth 
24, but on wayland we'd probably get lots bug reports by users which try 
out the latest Mesa from some repo, e.g., Ubuntu's padoka ppa's.



IIUC, with this workaround, all content composited by gnome-shell will
effectively use only 8 bits per component, even when Xorg runs at depth 30.




Yes, just confirmed with photometer. However, unredirected fullscreen 
windows (page-flipped) still work with 30 bit precision says the 
photometer, so there's still some use on g-s x11.


Tapani is right, the clutter picking code uses color coded drawing into 
some fb, translating ui element ("actor") id's to rgb color codes and 
back during hit testing / picking. That code has some clever logic to 
deal with fb's of different bit depths, but was last updated 9 years ago 
to deal with problems in low precision modes (rgb565 i guess), so 
probably never tested on any depth 30 fb's and only handling < 8 bpc, 
not more.


The stuff is in clutter/clutter-main.c, (_clutter_id_to_color() and 
_clutter_pixel_to_id()) but apparently there are separate clutter trees 
for the mutter and clutter repos, ie. mutter includes its own copy of 
clutter.


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