[Mesa-dev] [PATCH] aubinator: Multiply count by 4 to compute buffer sizes

[Jason Ekstrand]

The count field is in terms of dwords and not bytes.
---
 src/intel/tools/aubinator_error_decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/aubinator_error_decode.c 
b/src/intel/tools/aubinator_error_decode.c
index 01c6a7a..2ef6595 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -390,7 +390,7 @@ get_gen_batch_bo(void *user_data, uint64_t address)
  return (struct gen_batch_decode_bo) {
 .addr = sections[s].gtt_offset,
 .map = sections[s].data,
-.size = sections[s].count,
+.size = sections[s].count * 4,
  };
   }
}
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH 00/21] anv: Follow the rules for vkGet*ProcAddr

[Samuel Iglesias Gonsálvez]

I have comments on patch 2 and 18 (below). For the rest,

Reviewed-by: Samuel Iglesias Gonsálvez 

On 20/01/18 20:11, Jason Ekstrand wrote:
> Our previous scheme for Get*ProcAddr was to just return what we could and
> not care about the details.  This meant that GetInstanceProcAddr returned
> all anv_ entrypoints and GetDeviceProcAddr would return the per-gen
> entrypoint and fall back to anv_.  We figured that this was a perfectly
> reasonable and Vulkan thing to do and that the loader could sort out the
> nasty details.  We were wrong.
>
> The Vulkan spec has some very specific rules about what vkGet*ProcAddr is
> supposed to do in various cases.  In particular, you're supposed to return
> NULL for any extension entrypoints which have not explicitly been enabled.
> Also, vkGetInstanceProcAddr is supposed to return entrypoints for device
> functionality even if they have to be trampoline entrypoints.  In 99% of
> case, the loader takes care of all these details for us.  However, what I
> hear from the loader people is that they can't do it all and that the
> drivers should also follow the rules.
>
> On the upside, this means that our driver, short of exposing a few symbols,
> is now a completely stand-alone Vulkan implementation and doesn't require a
> loader.
>
> Cc: Samuel Iglesias Gonsálvez 
>
> Jason Ekstrand (21):
>   anv/meson: Make anv_entrypoints_gen.py depend on anv_extensions.py
>   anv: Split anv_extensions.py into two files
>   anv/meson: Simplify some dependency and flag tracking
>   anv/extensions: Generate a header file with extension tables
>   anv: Use tables for instance extension wrangling
>   anv: Add a per-instance table of enabled extensions
>   anv: Use tables for device extension wrangling
>   anv: Add a per-device table of enabled extensions
>   anv/entrypoints: Add an Entrypoint class
>   anv/entrypoints: Add a LAYERS helper variable
>   anv/entrypoints: Split entrypoint index lookup into its own function
>   anv/entrypoints: Expose the different dispatch tables
>   anv/entrypoints: Parse entrypoints before extensions/features
>   anv/extensions: Fix VkVersion::c_vk_version for patch == None
>   anv: Properly NULL for GetInstanceProcAddr with a null instance
>   anv: Add a per-instance dispatch table
>   anv: Add a per-device dispatch table
>   anv: Only advertise enabled entrypoints

In this patch (patch 18), I think there is an error in
anv_entrypoint_is_enabled() :

+ return !device || device->${e.extension.name[3:]};

As it is expected anv_entrypoint_is_enabled() to return false for
disabled extensions, I think this should be: return device &&
device->${e.extension.name[3:]};

Am I missing something?

Sam

>   anv/entrypoints: Use an named tuple for params
>   anv: Return trampoline entrypoints from GetInstanceProcAddr
>   HACK: Return instance entrypoints from GetDeviceProcAddr
>
>  src/intel/Makefile.sources  |   3 +-
>  src/intel/Makefile.vulkan.am|  15 +-
>  src/intel/vulkan/anv_device.c   | 174 ++-
>  src/intel/vulkan/anv_entrypoints_gen.py | 297 
> +++-
>  src/intel/vulkan/anv_extensions.py  | 157 +
>  src/intel/vulkan/anv_extensions_gen.py  | 202 ++
>  src/intel/vulkan/anv_private.h  |  16 +-
>  src/intel/vulkan/meson.build|  50 --
>  8 files changed, 653 insertions(+), 261 deletions(-)
>  create mode 100644 src/intel/vulkan/anv_extensions_gen.py
>



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 00/22] Introducing SPIR-V support to clover

[Karol Herbst]

Patches 1-2, 8-10, 14-19, 21 are Reviewed-by Karol Herbst 

For Patches 16-22 I looked inside your repository.

regarding all Patches modifying the headers: shouldn't we just update
those headers? I personally don't care much, because nobody will use
mesa as the system OpenCL implementation and just go with ocl-icd or
something more mature than clover anyway.

On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  wrote:
> Hello,
>
> Here is the second version of my initial series for adding SPIR-V support to
> clover, after the RFC back in May 2017.
>
> For recap, the focus of this series is to let clover accept SPIR-V binaries
> through the cl_khr_il_program extension (from OpenCL 1.2 and on), as well as
> through some core features (since OpenCL 2.1). Even if OpenCL 2.1 support in
> clover is some way off, there is another motivation for supporting SPIR-V in
> clover, as multiple drivers are interested in adding OpenCL support by
> converting SPIR-V to NIR.
>
> Note: the series is based on master + Karol’s patch “clover: add functions up
> to 2.2 to ICD dispatch table”.
>
>
> The various patches can be split in different categories:
>
> * Patches 1 through 7: some clover clean-up, adding and moving some
>   functionalities around to make the implementation easier in the rest of the
>   series.
>
> * Patches 8 through 13: define SPIR-V as a new IR, add a new frontend to 
> clover
>   to deal with SPIR-V, and edit compile and link operations to handle SPIR-V 
> as
>   well.
>
> * Patches 14 through 19: implement cl_khr_il_program
>
> * Patches 20 through 22: implement OpenCL 2.1 support on top of
>   cl_khr_il_program
>
>
> Changes since the RFC
> -
>
> * Most SPIR-V utilities were dropped, and the remaining ones have been moved 
> to
>   the clover SPIR-V frontend rather than sitting in 
> src/gallium/auxiliary/spirv.
>
> * The SPIR-V linker has been completely dropped from this series and instead
>   merge in SPIRV-Tools [1].
>
> * Since SPIRV-Tools now exports a pkgconfig .pc file, use it for detecting the
>   library.
>
> * Integrate the series with Meson.
>
> * Use pipe_llvm_program_header to pass in the size of the SPIR-V module, 
> rather
>   than adding a new attribute to pipe_compute_state, as suggested by Francisco
>   Jerez.
>
> * Check that the device supports the capabilities defined in the SPIR-V 
> binary.
>
> * Check that the platform/device supports the extensions used in the SPIR-V
>   binary.
>
> * Fix the implementation responsible for filling up the symbols of the clover
>   module based on the input SPIR-V binary.
>
> * No longer raw SPIR-V binaries through clCreateProgramWithBinary, but instead
>   keep the current de-serialisation of the clover module, which may contain a
>   SPIR-V binary.
>
> * Track whether a library was created with the --enable-link-options flag or
>   not. This is currently not useful as the linker ignores most link options,
>   but it will become useful when the linker handles those options.
>
> * Implement cl_khr_il_program.
>
> * Most of patches 1 through 8 (apart from patch 2).
>
>
> Discussions
> ---
>
> * Before, when linking different modules together, you knew that all modules
>   would use the same IR, as all were created using clCreateProgramWithSource,
>   therefore the linker could just call the linking function corresponding to
>   the target’s preferred IR. But with the introduction of
>   clCreateProgramWithIL(KHR)?, we can now end up in a case where we try to 
> link
>   a module using NIR as IR (created through clCreateProgramWithSource, 
> assuming
>   that is the driver’s preferred IR), with another module using SPIR-V as IR
>   (created through clCreateProgramWithIL). How do we handle such a case: 
> should
>   we translate the SPIR-V to NIR and use a NIR linker on them, or convert NIR
>   to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be handled
>   relatively easily, but what about TGSI?
>
> * In that regard, is anyone using the TGSI frontend in clover? If not, is
>   anyone planning to use it? And if still not, shouldn’t we just remove it?
>
> * In the same vein as the linking discussion just above, what should happen
>   when the driver’s preferred IR is one of the IRs not currently supported by
>   clover, like NIR for example? Should `compile()` generate a SPIR-V binary
>   which is directly translated to NIR, or should we keep everything in SPIR-V
>   until the very last moment, right before sending the IR to the driver?  If
>   all the drivers supporting compute through clover support an IR that can be
>   translated from SPIR-V, it might be easier to keep everything inside clover
>   as SPIR-V binaries, until we need to pass the program to the driver, in 
> which
>   case we convert it on the fly.
>
>
> (Still) missing
> ---
>
> * As there is no upstream version of LLVM which can produce SPIR-V out of
>   OpenCL code, clCreateProgramWithSource 

Re: [Mesa-dev] [PATCH 02/21] anv: Split anv_extensions.py into two files

[Samuel Iglesias Gonsálvez]

On 20/01/18 20:11, Jason Ekstrand wrote:
> The new anv_extensions_gen.py is the code generator while the old
> anv_extensions.py file is purely declarative.
> ---
>  src/intel/Makefile.vulkan.am   |   3 +-
>  src/intel/vulkan/anv_extensions.py | 154 ---
>  src/intel/vulkan/anv_extensions_gen.py | 184 
> +
>  src/intel/vulkan/meson.build   |   3 +-
>  4 files changed, 188 insertions(+), 156 deletions(-)
>  create mode 100644 src/intel/vulkan/anv_extensions_gen.py
>
> diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
> index 811faab..cacd049 100644
> --- a/src/intel/Makefile.vulkan.am
> +++ b/src/intel/Makefile.vulkan.am
> @@ -36,7 +36,8 @@ vulkan/anv_entrypoints.c: vulkan/anv_entrypoints_gen.py \
>   --outdir $(builddir)/vulkan
>  vulkan/anv_entrypoints.h: vulkan/anv_entrypoints.c
>  
> -vulkan/anv_extensions.c: vulkan/anv_extensions.py \
> +vulkan/anv_extensions.c: vulkan/anv_extensions_gen.py \
> +  vulkan/anv_extensions.py \
>$(vulkan_api_xml) \
>$(vk_android_native_buffer_xml)
>   $(MKDIR_GEN)

There is a bug in the autotools build, it is needed to update the
command to generate the files:

diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 7157772062c..7823b608804 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -41,7 +41,7 @@ vulkan/anv_extensions.c: vulkan/anv_extensions_gen.py \
 $(vulkan_api_xml) \
 $(vk_android_native_buffer_xml)
    $(MKDIR_GEN)
-   $(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_extensions.py \
+   $(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_extensions_gen.py \
    --xml $(vulkan_api_xml) \
    --xml $(vk_android_native_buffer_xml) \
    --out-c $@
@@ -51,7 +51,7 @@ vulkan/anv_extensions.h: vulkan/anv_extensions_gen.py \
 $(vulkan_api_xml) \
 $(vk_android_native_buffer_xml)
    $(MKDIR_GEN)
-   $(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_extensions.py \
+   $(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_extensions_gen.py \
    --xml $(vulkan_api_xml) \
    --xml $(vk_android_native_buffer_xml) \
    --out-h $@

Sam

> diff --git a/src/intel/vulkan/anv_extensions.py 
> b/src/intel/vulkan/anv_extensions.py
> index adfebca..ae30ec9 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -130,157 +130,3 @@ class VkVersion:
>  return self.__int_ver().__cmp__(other.__int_ver())
>  
>  MAX_API_VERSION = VkVersion(MAX_API_VERSION)
> -
> -def _init_exts_from_xml(xml):
> -""" Walk the Vulkan XML and fill out extra extension information. """
> -
> -xml = et.parse(xml)
> -
> -ext_name_map = {}
> -for ext in EXTENSIONS:
> -ext_name_map[ext.name] = ext
> -
> -for ext_elem in xml.findall('.extensions/extension'):
> -ext_name = ext_elem.attrib['name']
> -if ext_name not in ext_name_map:
> -continue
> -
> -# Workaround for VK_ANDROID_native_buffer. Its  element in
> -# vk.xml lists it as supported="disabled" and provides only a stub
> -# definition.  Its  element in Mesa's custom
> -# vk_android_native_buffer.xml, though, lists it as
> -# supported='android-vendor' and fully defines the extension. We want
> -# to skip the  element in vk.xml.
> -if ext_elem.attrib['supported'] == 'disabled':
> -assert ext_name == 'VK_ANDROID_native_buffer'
> -continue
> -
> -ext = ext_name_map[ext_name]
> -ext.type = ext_elem.attrib['type']
> -
> -_TEMPLATE = COPYRIGHT + """
> -#include "anv_private.h"
> -
> -#include "vk_util.h"
> -
> -/* Convert the VK_USE_PLATFORM_* defines to booleans */
> -%for platform in ['ANDROID', 'WAYLAND', 'XCB', 'XLIB']:
> -#ifdef VK_USE_PLATFORM_${platform}_KHR
> -#   undef VK_USE_PLATFORM_${platform}_KHR
> -#   define VK_USE_PLATFORM_${platform}_KHR true
> -#else
> -#   define VK_USE_PLATFORM_${platform}_KHR false
> -#endif
> -%endfor
> -
> -/* And ANDROID too */
> -#ifdef ANDROID
> -#   undef ANDROID
> -#   define ANDROID true
> -#else
> -#   define ANDROID false
> -#endif
> -
> -#define ANV_HAS_SURFACE (VK_USE_PLATFORM_WAYLAND_KHR || \\
> - VK_USE_PLATFORM_XCB_KHR || \\
> - VK_USE_PLATFORM_XLIB_KHR)
> -
> -bool
> -anv_instance_extension_supported(const char *name)
> -{
> -%for ext in instance_extensions:
> -if (strcmp(name, "${ext.name}") == 0)
> -return ${ext.enable};
> -%endfor
> -return false;
> -}
> -
> -VkResult anv_EnumerateInstanceExtensionProperties(
> -const char* pLayerName,
> -uint32_t*   pPropertyCount,
> -

Re: [Mesa-dev] [PATCH v2 13/22] clover: Handle the case when linking SPIR-V binaries together

[Karol Herbst]

On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  wrote:
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/core/program.cpp | 22 
> +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
> b/src/gallium/state_trackers/clover/core/program.cpp
> index 15d559cd93..976213ef95 100644
> --- a/src/gallium/state_trackers/clover/core/program.cpp
> +++ b/src/gallium/state_trackers/clover/core/program.cpp
> @@ -22,6 +22,7 @@
>
>  #include "core/program.hpp"
>  #include "llvm/invocation.hpp"
> +#include "spirv/invocation.hpp"
>  #include "tgsi/invocation.hpp"
>
>  using namespace clover;
> @@ -80,11 +81,22 @@ program::link(const ref_vector , const 
> std::string ,
>std::string log = _builds[].log;
>
>try {
> - const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
> -   tgsi::link_program(ms) :
> -   llvm::link_program(ms, dev.ir_format(),
> -  dev.ir_target(), opts, log));
> - _builds[] = { m, opts, log };
> + switch (dev.ir_format()) {
> + case PIPE_SHADER_IR_TGSI:
> +_builds[] = { tgsi::link_program(ms), opts, log };
> +break;
> + case PIPE_SHADER_IR_LLVM:
> + case PIPE_SHADER_IR_NATIVE:
> + case PIPE_SHADER_IR_NIR:

is adding NIR here actually want to do? I am not aware of any path
that would allow any NIR driver to support llvm at all.

> +_builds[] = { llvm::link_program(ms, dev.ir_format(),
> + dev.ir_target(), opts, log),
> +  opts, log };
> +break;
> + case PIPE_SHADER_IR_SPIRV:
> +_builds[] = { clover::spirv::link_program(ms, opts, log), 
> opts,
> +  log };
> +break;
> + }
>} catch (...) {
>   _builds[] = { module(), opts, log };
>   throw;
> --
> 2.16.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 12/22] clover: Refuse to compile source code to SPIR-V

[Karol Herbst]

On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  wrote:
> Creating a program using clCreateProgramWithSource to SPIR-V requires a
> non-upstreamed version of LLVM and clang, therefore it is currently not
> supported.
>
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/core/program.cpp | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
> b/src/gallium/state_trackers/clover/core/program.cpp
> index ae4b50a879..15d559cd93 100644
> --- a/src/gallium/state_trackers/clover/core/program.cpp
> +++ b/src/gallium/state_trackers/clover/core/program.cpp
> @@ -51,6 +51,10 @@ program::compile(const ref_vector , const 
> std::string ,
>   std::string log;
>
>   try {
> +if (dev.ir_format() == PIPE_SHADER_IR_SPIRV) {
> +   log = "Compiling from source to SPIR-V is not supported 
> yet\n";
> +   throw error(CL_INVALID_DEVICE);
> +}

this fails whenever the preferred IR is NIR, because clover ends up
using llvm then. We need much a better way on handling this in general
like stated in my reply to the cover letter.

>  const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
>tgsi::compile_program(_source, log) :
>llvm::compile_program(_source, headers,
> --
> 2.16.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 00/22] Introducing SPIR-V support to clover

[Karol Herbst]

there seem to be some patches missing?

On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  wrote:
> Hello,
>
> Here is the second version of my initial series for adding SPIR-V support to
> clover, after the RFC back in May 2017.
>
> For recap, the focus of this series is to let clover accept SPIR-V binaries
> through the cl_khr_il_program extension (from OpenCL 1.2 and on), as well as
> through some core features (since OpenCL 2.1). Even if OpenCL 2.1 support in
> clover is some way off, there is another motivation for supporting SPIR-V in
> clover, as multiple drivers are interested in adding OpenCL support by
> converting SPIR-V to NIR.
>
> Note: the series is based on master + Karol’s patch “clover: add functions up
> to 2.2 to ICD dispatch table”.
>
>
> The various patches can be split in different categories:
>
> * Patches 1 through 7: some clover clean-up, adding and moving some
>   functionalities around to make the implementation easier in the rest of the
>   series.
>
> * Patches 8 through 13: define SPIR-V as a new IR, add a new frontend to 
> clover
>   to deal with SPIR-V, and edit compile and link operations to handle SPIR-V 
> as
>   well.
>
> * Patches 14 through 19: implement cl_khr_il_program
>
> * Patches 20 through 22: implement OpenCL 2.1 support on top of
>   cl_khr_il_program
>
>
> Changes since the RFC
> -
>
> * Most SPIR-V utilities were dropped, and the remaining ones have been moved 
> to
>   the clover SPIR-V frontend rather than sitting in 
> src/gallium/auxiliary/spirv.
>
> * The SPIR-V linker has been completely dropped from this series and instead
>   merge in SPIRV-Tools [1].
>
> * Since SPIRV-Tools now exports a pkgconfig .pc file, use it for detecting the
>   library.
>
> * Integrate the series with Meson.
>
> * Use pipe_llvm_program_header to pass in the size of the SPIR-V module, 
> rather
>   than adding a new attribute to pipe_compute_state, as suggested by Francisco
>   Jerez.
>
> * Check that the device supports the capabilities defined in the SPIR-V 
> binary.
>
> * Check that the platform/device supports the extensions used in the SPIR-V
>   binary.
>
> * Fix the implementation responsible for filling up the symbols of the clover
>   module based on the input SPIR-V binary.
>
> * No longer raw SPIR-V binaries through clCreateProgramWithBinary, but instead
>   keep the current de-serialisation of the clover module, which may contain a
>   SPIR-V binary.
>
> * Track whether a library was created with the --enable-link-options flag or
>   not. This is currently not useful as the linker ignores most link options,
>   but it will become useful when the linker handles those options.
>
> * Implement cl_khr_il_program.
>
> * Most of patches 1 through 8 (apart from patch 2).
>
>
> Discussions
> ---
>
> * Before, when linking different modules together, you knew that all modules
>   would use the same IR, as all were created using clCreateProgramWithSource,
>   therefore the linker could just call the linking function corresponding to
>   the target’s preferred IR. But with the introduction of
>   clCreateProgramWithIL(KHR)?, we can now end up in a case where we try to 
> link
>   a module using NIR as IR (created through clCreateProgramWithSource, 
> assuming
>   that is the driver’s preferred IR), with another module using SPIR-V as IR
>   (created through clCreateProgramWithIL). How do we handle such a case: 
> should
>   we translate the SPIR-V to NIR and use a NIR linker on them, or convert NIR
>   to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be handled
>   relatively easily, but what about TGSI?
>

I think we will never be able to convert all IRs into any other IR, so
that I would suggest to leave those IRs unconverted until they get
linked together and there the code can decide on a common IR for
linking. So if we get source code, we can parse it to llvm IR and
leave it like that until it gets linked. Converting back and forth
would require us to write all those conversion paths and I am assume
this wouldn't be worth the trouble.

> * In that regard, is anyone using the TGSI frontend in clover? If not, is
>   anyone planning to use it? And if still not, shouldn’t we just remove it?
>
> * In the same vein as the linking discussion just above, what should happen
>   when the driver’s preferred IR is one of the IRs not currently supported by
>   clover, like NIR for example? Should `compile()` generate a SPIR-V binary
>   which is directly translated to NIR, or should we keep everything in SPIR-V
>   until the very last moment, right before sending the IR to the driver?  If
>   all the drivers supporting compute through clover support an IR that can be
>   translated from SPIR-V, it might be easier to keep everything inside clover
>   as SPIR-V binaries, until we need to pass the program to the driver, in 
> which
>   case we convert it on the fly.
>

don't rely on the preferred IR inside clover. It should 

Re: [Mesa-dev] [PATCH v3 3/3] anv: implement VK_EXT_global_priority extension

[Tapani Pälli]

On 01/22/2018 09:01 PM, Jason Ekstrand wrote:
On Mon, Jan 22, 2018 at 4:29 AM, Tapani Pälli > wrote:


v2: add ANV_CONTEXT_REALTIME_PRIORITY (Chris)
     use unreachable with unknown priority (Samuel)

v3: add stubs in gem_stubs.c (Emil)
     use priority defines from gen_defines.h

Signed-off-by: Tapani Pälli >
Reviewed-by: Samuel Iglesias Gonsálvez > (v2)
Reviewed-by: Chris Wilson > (v2)
---
  src/intel/vulkan/anv_device.c      | 25 +++
  src/intel/vulkan/anv_extensions.py |  2 ++
  src/intel/vulkan/anv_gem.c         | 51
++
  src/intel/vulkan/anv_gem_stubs.c   | 10 
  src/intel/vulkan/anv_private.h     |  3 +++
  5 files changed, 91 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c
b/src/intel/vulkan/anv_device.c
index 777abd8757..42ebc19f2b 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -369,6 +369,9 @@ anv_physical_device_init(struct
anv_physical_device *device,
     device->has_syncobj_wait = device->has_syncobj &&
                                anv_gem_supports_syncobj_wait(fd);

+   if (anv_gem_has_context_priority(fd))
+      device->has_context_priority = true;
+
     bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);

     /* Starting with Gen10, the timestamp frequency of the command
streamer may
@@ -1205,6 +1208,15 @@ VkResult anv_CreateDevice(
        }
     }

+   /* Check if client specified queue priority. */
+   const VkDeviceQueueGlobalPriorityCreateInfoEXT *queue_priority =
+      vk_find_struct_const(pCreateInfo->pQueueCreateInfos[0].pNext,
+ 
  DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT);

+
+   VkQueueGlobalPriorityEXT priority =
+      queue_priority ? queue_priority->globalPriority :
+         VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT;
+
     device = vk_alloc2(_device->instance->alloc, pAllocator,
                         sizeof(*device), 8,
                         VK_SYSTEM_ALLOCATION_SCOPE_DEVICE);
@@ -1234,6 +1246,19 @@ VkResult anv_CreateDevice(
        goto fail_fd;
     }

+   /* As per spec, the driver implementation may deny requests to
acquire
+    * a priority above the default priority (MEDIUM) if the caller
does not
+    * have sufficient privileges. In this scenario
VK_ERROR_NOT_PERMITTED_EXT
+    * is returned.
+    */
+   if (physical_device->has_context_priority) {
+      int err = anv_gem_set_context_priority(device, priority);
+      if (err != 0 && priority > VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT) {
+         result = vk_error(VK_ERROR_NOT_PERMITTED_EXT);
+         goto fail_fd;
+      }
+   }
+
     device->info = physical_device->info;
     device->isl_dev = physical_device->isl_dev;

diff --git a/src/intel/vulkan/anv_extensions.py
b/src/intel/vulkan/anv_extensions.py
index adfebca985..aacf39248f 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -86,6 +86,8 @@ EXTENSIONS = [
      Extension('VK_KHX_multiview',                         1, True),
      Extension('VK_EXT_debug_report',                      8, True),
      Extension('VK_EXT_external_memory_dma_buf',           1, True),
+    Extension('VK_EXT_global_priority',                   1,
+              'device->has_context_priority'),
  ]

  class VkVersion:
diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 34c0989108..7f83820429 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -30,6 +30,7 @@
  #include 

  #include "anv_private.h"
+#include "common/gen_defines.h"

  static int
  anv_ioctl(int fd, unsigned long request, void *arg)
@@ -302,6 +303,56 @@ close_and_return:
     return swizzled;
  }

+static int
+vk_priority_to_anv(int priority)
+{
+   switch (priority) {
+   case VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT:
+      return GEN_CONTEXT_LOW_PRIORITY;
+   case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT:
+      return GEN_CONTEXT_MEDIUM_PRIORITY;
+   case VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT:
+      return GEN_CONTEXT_HIGH_PRIORITY;
+   case VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT:
+      return GEN_CONTEXT_REALTIME_PRIORITY;
+   default:
+      unreachable("Invalid priority");
+   }
+}


I think I'd rather have the conversion in anv_device.c and just make the 
anv_gem functions take an i915 priority.


ok will change that


Other than 

[Mesa-dev] [PATCH] radv: don't use hw resolves for r16g16 norm formats.

[Dave Airlie]

From: Dave Airlie 

radeonsi has a workaround for this, but it uses a R16A16 format,
which vulkan doesn't have, we could probably come up with a work
around but for now just avoid hw resolves.

Fixes:
dEQP-VK.renderpass.suballocation.multisample.r16g16_*norm*

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta_resolve.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_meta_resolve.c 
b/src/amd/vulkan/radv_meta_resolve.c
index d2b9c3c..4f989ee 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -353,7 +353,10 @@ static void radv_pick_resolve_method_images(struct 
radv_image *src_image,
   
cmd_buffer->queue_family_index,
   
cmd_buffer->queue_family_index);
 
-   if (vk_format_is_int(src_image->vk_format))
+   if (src_image->vk_format == VK_FORMAT_R16G16_UNORM ||
+   src_image->vk_format == VK_FORMAT_R16G16_SNORM)
+   *method = RESOLVE_COMPUTE;
+   else if (vk_format_is_int(src_image->vk_format))
*method = RESOLVE_COMPUTE;

if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
queue_mask)) {
-- 
2.9.5

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

[Mesa-dev] [PATCH 2/2] radv: don't use hw resolve for integer image formats

[Dave Airlie]

From: Dave Airlie 

From reading AMDVLK it currently never uses hw resolve paths.

This patch takes from radeonsi which doesn't use hw resolve
for integer formats, and does the same for radv.

This fixes:
dEQP-VK.renderpass.suballocation.multisample*uint tests.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta_resolve.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/amd/vulkan/radv_meta_resolve.c 
b/src/amd/vulkan/radv_meta_resolve.c
index d44e16e..d2b9c3c 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -26,6 +26,7 @@
 
 #include "radv_meta.h"
 #include "radv_private.h"
+#include "vk_format.h"
 #include "nir/nir_builder.h"
 #include "sid.h"
 
@@ -351,6 +352,10 @@ static void radv_pick_resolve_method_images(struct 
radv_image *src_image,
uint32_t queue_mask = radv_image_queue_family_mask(dest_image,
   
cmd_buffer->queue_family_index,
   
cmd_buffer->queue_family_index);
+
+   if (vk_format_is_int(src_image->vk_format))
+   *method = RESOLVE_COMPUTE;
+   
if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
queue_mask)) {
*method = RESOLVE_FRAGMENT;
} else if (dest_image->surface.micro_tile_mode != 
src_image->surface.micro_tile_mode) {
-- 
2.9.5

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

[Mesa-dev] [PATCH 1/2] radv: add fs_key meta format support to resolve passes.

[Dave Airlie]

From: Dave Airlie 

Some of the hw resolve passes need the SPI color format setup
correctly.

This fixes lots of 16-bit and 32-bit format tests in
dEQP-VK.renderpass.suballocation.multisample*

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta_resolve.c | 87 ++
 src/amd/vulkan/radv_private.h  |  4 +-
 2 files changed, 61 insertions(+), 30 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_resolve.c 
b/src/amd/vulkan/radv_meta_resolve.c
index 49326fe..d44e16e 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -50,7 +50,7 @@ build_nir_fs(void)
 }
 
 static VkResult
-create_pass(struct radv_device *device)
+create_pass(struct radv_device *device, VkFormat vk_format, VkRenderPass *pass)
 {
VkResult result;
VkDevice device_h = radv_device_to_handle(device);
@@ -59,7 +59,7 @@ create_pass(struct radv_device *device)
int i;
 
for (i = 0; i < 2; i++) {
-   attachments[i].format = VK_FORMAT_UNDEFINED;
+   attachments[i].format = vk_format;
attachments[i].samples = 1;
attachments[i].loadOp = VK_ATTACHMENT_LOAD_OP_LOAD;
attachments[i].storeOp = VK_ATTACHMENT_STORE_OP_STORE;
@@ -99,14 +99,16 @@ create_pass(struct radv_device *device)

.dependencyCount = 0,
 },
   alloc,
-  >meta_state.resolve.pass);
+  pass);
 
return result;
 }
 
 static VkResult
 create_pipeline(struct radv_device *device,
-VkShaderModule vs_module_h)
+VkShaderModule vs_module_h,
+VkPipeline *pipeline,
+VkRenderPass pass)
 {
VkResult result;
VkDevice device_h = radv_device_to_handle(device);
@@ -129,12 +131,14 @@ create_pipeline(struct radv_device *device,
.pPushConstantRanges = NULL,
};
 
-   result = radv_CreatePipelineLayout(radv_device_to_handle(device),
-  _create_info,
-  >meta_state.alloc,
-  
>meta_state.resolve.p_layout);
-   if (result != VK_SUCCESS)
-   goto cleanup;
+   if (!device->meta_state.resolve.p_layout) {
+   result = 
radv_CreatePipelineLayout(radv_device_to_handle(device),
+  _create_info,
+  >meta_state.alloc,
+  
>meta_state.resolve.p_layout);
+   if (result != VK_SUCCESS)
+   goto cleanup;
+   }
 
result = radv_graphics_pipeline_create(device_h,
   
radv_pipeline_cache_to_handle(>meta_state.cache),
@@ -212,15 +216,14 @@ create_pipeline(struct radv_device *device,
},
},
.layout = 
device->meta_state.resolve.p_layout,
-   
   .renderPass = 
device->meta_state.resolve.pass,
+   .renderPass = pass,

   .subpass = 0,

   },
   &(struct 
radv_graphics_pipeline_create_info) {
   .use_rectlist = true,
   .custom_blend_mode = 
V_028808_CB_RESOLVE,
   },
-  >meta_state.alloc,
-  
>meta_state.resolve.pipeline);
+  >meta_state.alloc, 
pipeline);
if (result != VK_SUCCESS)
goto cleanup;
 
@@ -236,19 +239,37 @@ radv_device_finish_meta_resolve_state(struct radv_device 
*device)
 {
struct radv_meta_state *state = >meta_state;
 
-   radv_DestroyRenderPass(radv_device_to_handle(device),
-  state->resolve.pass, >alloc);
+   for (uint32_t j = 0; j < NUM_DEPTH_CLEAR_PIPELINES; j++) {
+   radv_DestroyRenderPass(radv_device_to_handle(device),
+  

[Mesa-dev] [PATCH] radv: don't use hw resolve for certain image formats. (v2)

[Dave Airlie]

From: Dave Airlie 

From reading AMDVLK it currently never uses hw resolve paths.

This patch limits the paths we used the hw resolve for,
and fixes a larger number of the:
dEQP-VK.renderpass.suballocation.multisample* tests.

radeonsi actually has the no-int and no-depth rules
already so port those.

I've also added a >= 16 color format component bit size,
to avoid what radeonsi says is buggy behaviour. I wonder
if we should be doing meta format key for resolves.

This still leaves depth resolves and 16-bit formats at 8-bit
samples failing.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta_resolve.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/amd/vulkan/radv_meta_resolve.c 
b/src/amd/vulkan/radv_meta_resolve.c
index 49326fe..4c74027 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -26,6 +26,7 @@
 
 #include "radv_meta.h"
 #include "radv_private.h"
+#include "vk_format.h"
 #include "nir/nir_builder.h"
 #include "sid.h"
 
@@ -323,6 +324,12 @@ static void radv_pick_resolve_method_images(struct 
radv_image *src_image,
uint32_t queue_mask = radv_image_queue_family_mask(dest_image,
   
cmd_buffer->queue_family_index,
   
cmd_buffer->queue_family_index);
+
+   if (vk_format_is_int(src_image->vk_format) ||
+   vk_format_is_depth_or_stencil(src_image->vk_format) ||
+   vk_format_get_component_bits(src_image->vk_format, 
VK_FORMAT_COLORSPACE_RGB, 0) >= 16)
+   *method = RESOLVE_COMPUTE;
+   
if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
queue_mask)) {
*method = RESOLVE_FRAGMENT;
} else if (dest_image->surface.micro_tile_mode != 
src_image->surface.micro_tile_mode) {
-- 
2.9.5

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

[Mesa-dev] [PATCH] r600: increase number of samplers/views from 16 to 18 on eg

[sroland]

From: Roland Scheidegger 

Some apps are known to require more than 16. Albeit they probably still won't
run with 18 (since all new hw/drivers support 32) it shouldn't hurt to at
least support 18 (seemingly the hw limit on all r600-ni chips - the blob also
supports 18, at least for eg+ by the looks of it).

Unfortunately border colors do not work for the last 2 units. The reg guide
says there is a 5 bit index for setting border colors, but this is a lie.
piglit max-samplers shows that indeed setting border color for units 16/17
(per stage) will simply overwrite the border color for units 0/1, and sampling
will consequently also use those border color values for sampling on units
16/17. (For eg - no idea about ni.)
This will cause piglit max-samplers border to fail, but meh... border colors
are more or less totally busted (sampler swizzling...) on that hw anyway.
Border colors should still work if not both units 0 and 16 (or units 1 and 17)
use a border color simultaneously.

Setting border color values on r600/r700 is different, and I have no idea
if the hw would also wrap-around when trying to use border colors or do
something crazy (like locking up...) so don't increase the limit there (since
the blob doesn't do it I'm not sure if it would be safe).
---
 src/gallium/drivers/r600/evergreen_state.c   | 7 +++
 src/gallium/drivers/r600/r600_pipe.c | 6 +-
 src/gallium/drivers/r600/r600_pipe.h | 8 
 src/gallium/drivers/r600/r600_state_common.c | 2 +-
 4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index fb1de9cbf4..55a460053c 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2372,6 +2372,13 @@ static void evergreen_emit_sampler_states(struct 
r600_context *rctx,
radeon_emit(cs, (resource_id_base + i) * 3);
radeon_emit_array(cs, rstate->tex_sampler_words, 3);
 
+   /*
+* Note for sampler 16/17 this will overwrite border color
+* on sampler 0/1. As long as border color isn't used on
+* both units 0 and 16 (or 1 and 17) it should actually work
+* since the sampler also appears to remap those border color
+* values the same way.
+*/
if (rstate->border_color_use) {
radeon_set_config_reg_seq(cs, border_index_reg, 5);
radeon_emit(cs, i);
diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index 95aa2e5383..7f9500ad4b 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -595,7 +595,11 @@ static int r600_get_shader_param(struct pipe_screen* 
pscreen,
return 1;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
-   return 16;
+   /*
+* There is potentially even more trouble with border colors
+* for units 16/17 on r600/r700, so only enable 18 on eg+
+*/
+   return rscreen->b.family >= CHIP_CEDAR ? R600_NUM_TEX_UNITS : 
16;
 case PIPE_SHADER_CAP_PREFERRED_IR:
if (shader == PIPE_SHADER_COMPUTE) {
return PIPE_SHADER_IR_NATIVE;
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index 112b5cbb83..e2bd7b0a99 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -366,7 +366,7 @@ struct r600_pipe_sampler_state {
 };
 
 /* needed for blitter save */
-#define NUM_TEX_UNITS 16
+#define R600_NUM_TEX_UNITS 18
 
 struct r600_seamless_cube_map {
struct r600_atomatom;
@@ -375,7 +375,7 @@ struct r600_seamless_cube_map {
 
 struct r600_samplerview_state {
struct r600_atomatom;
-   struct r600_pipe_sampler_view   *views[NUM_TEX_UNITS];
+   struct r600_pipe_sampler_view   *views[R600_NUM_TEX_UNITS];
uint32_tenabled_mask;
uint32_tdirty_mask;
uint32_tcompressed_depthtex_mask; /* which 
textures are depth */
@@ -385,7 +385,7 @@ struct r600_samplerview_state {
 
 struct r600_sampler_states {
struct r600_atomatom;
-   struct r600_pipe_sampler_state  *states[NUM_TEX_UNITS];
+   struct r600_pipe_sampler_state  *states[R600_NUM_TEX_UNITS];
uint32_tenabled_mask;
uint32_tdirty_mask;
uint32_thas_bordercolor_mask; /* which states 
contain the border color */
@@ -394,7 +394,7 @@ struct r600_sampler_states {
 struct r600_textures_info {
struct r600_samplerview_state   views;
struct 

[Mesa-dev] [PATCH] radv: don't use hw resolve for certain image formats.

[Dave Airlie]

From: Dave Airlie 

From reading AMDVLK it currently never uses hw resolve paths.

This patch limits the paths we used the hw resolve for,
and fixes a larger number of the:
dEQP-VK.renderpass.suballocation.multisample* tests.

It currently doesn't do hw resolves for integer or >= 16-bit
formats.

This still leaves depth resolves and 16-bit formats at 8-bit
samples failing.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta_resolve.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/amd/vulkan/radv_meta_resolve.c 
b/src/amd/vulkan/radv_meta_resolve.c
index 49326fe..66d5fe4 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -26,6 +26,7 @@
 
 #include "radv_meta.h"
 #include "radv_private.h"
+#include "vk_format.h"
 #include "nir/nir_builder.h"
 #include "sid.h"
 
@@ -323,6 +324,11 @@ static void radv_pick_resolve_method_images(struct 
radv_image *src_image,
uint32_t queue_mask = radv_image_queue_family_mask(dest_image,
   
cmd_buffer->queue_family_index,
   
cmd_buffer->queue_family_index);
+
+   if (vk_format_is_int(src_image->vk_format) ||
+   vk_format_get_component_bits(src_image->vk_format, 
VK_FORMAT_COLORSPACE_RGB, 0) >= 16)
+   *method = RESOLVE_COMPUTE;
+   
if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
queue_mask)) {
*method = RESOLVE_FRAGMENT;
} else if (dest_image->surface.micro_tile_mode != 
src_image->surface.micro_tile_mode) {
-- 
2.9.5

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

[Mesa-dev] [PATCH] radv: fix sample_mask_in loading. (v2)

[Dave Airlie]

From: Dave Airlie 

This is ported from radeonsi and fixes:
dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.bit_*

v2: don't call this path for radeonsi, it does it in the epilog.
use the radeonsi code path.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 29 -
 src/amd/common/ac_nir_to_llvm.h |  2 ++
 src/amd/vulkan/radv_pipeline.c  | 28 +++-
 src/amd/vulkan/radv_private.h   |  2 ++
 4 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 214fb14..668cd50 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4046,6 +4046,30 @@ static LLVMValueRef load_sample_pos(struct 
ac_nir_context *ctx)
return ac_build_gather_values(>ac, values, 2);
 }
 
+static LLVMValueRef load_sample_mask_in(struct ac_nir_context *ctx)
+{
+   uint8_t log2_ps_iter_samples = 
ctx->nctx->shader_info->info.ps.force_persample ? 
ctx->nctx->options->key.fs.log2_num_samples : 
ctx->nctx->options->key.fs.log2_ps_iter_samples;
+
+   /* The bit pattern matches that used by fixed function fragment
+* processing. */
+   static const uint16_t ps_iter_masks[] = {
+   0x, /* not used */
+   0x,
+   0x,
+   0x0101,
+   0x0001,
+   };
+   assert(log2_ps_iter_samples < ARRAY_SIZE(ps_iter_masks));
+
+   uint32_t ps_iter_mask = ps_iter_masks[log2_ps_iter_samples];
+
+   LLVMValueRef result, sample_id;
+   sample_id = unpack_param(>ac, ctx->abi->ancillary, 8, 4);
+   sample_id = LLVMBuildShl(ctx->ac.builder, LLVMConstInt(ctx->ac.i32, 
ps_iter_mask, false), sample_id, "");
+   result = LLVMBuildAnd(ctx->ac.builder, sample_id, 
ctx->abi->sample_coverage, "");
+   return result;
+}
+
 static LLVMValueRef visit_interp(struct nir_to_llvm_context *ctx,
 const nir_intrinsic_instr *instr)
 {
@@ -4350,7 +4374,10 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
result = load_sample_pos(ctx);
break;
case nir_intrinsic_load_sample_mask_in:
-   result = ctx->abi->sample_coverage;
+   if (ctx->nctx)
+   result = load_sample_mask_in(ctx);
+   else
+   result = ctx->abi->sample_coverage;
break;
case nir_intrinsic_load_frag_coord: {
LLVMValueRef values[4] = {
diff --git a/src/amd/common/ac_nir_to_llvm.h b/src/amd/common/ac_nir_to_llvm.h
index 62ea38b..1656289 100644
--- a/src/amd/common/ac_nir_to_llvm.h
+++ b/src/amd/common/ac_nir_to_llvm.h
@@ -60,6 +60,8 @@ struct ac_tcs_variant_key {
 
 struct ac_fs_variant_key {
uint32_t col_format;
+   uint8_t log2_ps_iter_samples;
+   uint8_t log2_num_samples;
uint32_t is_int8;
uint32_t is_int10;
uint32_t multisample : 1;
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index f29c88e..98d1eca 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -798,6 +798,18 @@ radv_pipeline_init_raster_state(struct radv_pipeline 
*pipeline,
 
 }
 
+static uint8_t radv_pipeline_get_ps_iter_samples(const 
VkGraphicsPipelineCreateInfo *pCreateInfo)
+{
+   uint32_t num_samples = 
pCreateInfo->pMultisampleState->rasterizationSamples;
+   uint32_t ps_iter_samples = num_samples;
+
+   if (pCreateInfo->pMultisampleState->sampleShadingEnable) {
+   ps_iter_samples = 
ceil(pCreateInfo->pMultisampleState->minSampleShading * num_samples);
+   ps_iter_samples = util_next_power_of_two(ps_iter_samples);
+   }
+   return ps_iter_samples;
+}
+
 static void
 radv_pipeline_init_multisample_state(struct radv_pipeline *pipeline,
 const VkGraphicsPipelineCreateInfo 
*pCreateInfo)
@@ -813,9 +825,8 @@ radv_pipeline_init_multisample_state(struct radv_pipeline 
*pipeline,
else
ms->num_samples = 1;
 
-   if (vkms && vkms->sampleShadingEnable) {
-   ps_iter_samples = ceil(vkms->minSampleShading * 
ms->num_samples);
-   } else if 
(pipeline->shaders[MESA_SHADER_FRAGMENT]->info.info.ps.force_persample) {
+   ps_iter_samples = radv_pipeline_get_ps_iter_samples(pCreateInfo);
+   if (vkms && !vkms->sampleShadingEnable && 
pipeline->shaders[MESA_SHADER_FRAGMENT]->info.info.ps.force_persample) {
ps_iter_samples = ms->num_samples;
}
 
@@ -838,7 +849,7 @@ radv_pipeline_init_multisample_state(struct radv_pipeline 
*pipeline,
 
if (ms->num_samples > 1) {
unsigned log_samples = util_logbase2(ms->num_samples);
-   unsigned log_ps_iter_samples = 
util_logbase2(util_next_power_of_two(ps_iter_samples));
+   unsigned log_ps_iter_samples = 

Re: [Mesa-dev] [PATCH v2 09/24] anv/cmd_buffer: Generalize transition_color_buffer

[Jason Ekstrand]

On Mon, Jan 22, 2018 at 5:50 PM, Jason Ekstrand 
wrote:

> On Mon, Jan 22, 2018 at 11:31 AM, Nanley Chery 
> wrote:
>
>> On Fri, Jan 19, 2018 at 03:47:26PM -0800, Jason Ekstrand wrote:
>> > This moves it to being based on layout_to_aux_usage instead of being
>> > hard-coded based on bits of a priori knowledge of how transitions
>> > interact with layouts.  This conceptually simplifies things because
>> > we're now using layout_to_aux_usage and layout_supports_fast_clear to
>> > make resolve decisions so changes to those functions will do what one
>> > expects.
>> >
>> > This fixes a potential bug with window system integration on gen9+ where
>> ^
>> This patch still doesn't fix the bug.
>>
>
> Yup.  I've changed this paragraph to:
>
> There is a potential bug with window system integration on gen9+ where
> we wouldn't do a resolve when transitioning to the PRESENT_SRC layout
> because we just assume that everything that handles CCS_E can handle it
> all the time.  When handing a CCS_E image off to the window system, we
> may need to do a full resolve if the window system does not support the
> CCS_E modifier.  The only reason why this hasn't been a problem yet is
> because we don't support modifiers in Vulkan WSI and so we always get X
> tiling which implies no CCS on gen9+.  This patch doesn't actually fix
> that bug yet but it takes us the first step in that direction by making
> us actually pick the correct resolve op.  In order to handle all of the
> cases, we need more detailed aux tracking.
>
>
>> > we wouldn't do a resolve when transitioning to the PRESENT_SRC layout
>> > because we just assume that everything that handles CCS_E can handle it
>> > all the time.  When handing a CCS_E image off to the window system, we
>> > may need to do a full resolve if the window system does not support the
>> > CCS_E modifier.  The only reason why this hasn't been a problem yet is
>> > because we don't support modifiers in Vulkan WSI and so we always get X
>> > tiling which implies no CCS on gen9+.
>> >
>> > v2 (Jason Ekstrand):
>> >  - Make a few more things const
>> >  - Use the anv_fast_clear_support enum
>> >
>> > Reviewed-by: Topi Pohjolainen 
>> > ---
>> >  src/intel/vulkan/genX_cmd_buffer.c | 56 ++
>> 
>> >  1 file changed, 44 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
>> b/src/intel/vulkan/genX_cmd_buffer.c
>> > index 6a6d8b2..fd27463 100644
>> > --- a/src/intel/vulkan/genX_cmd_buffer.c
>> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
>> > @@ -593,6 +593,7 @@ transition_color_buffer(struct anv_cmd_buffer
>> *cmd_buffer,
>> >  VkImageLayout initial_layout,
>> >  VkImageLayout final_layout)
>> >  {
>> > +   const struct gen_device_info *devinfo = _buffer->device->info;
>> > /* Validate the inputs. */
>> > assert(cmd_buffer);
>> > assert(image && image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_
>> ANV);
>> > @@ -733,17 +734,51 @@ transition_color_buffer(struct anv_cmd_buffer
>> *cmd_buffer,
>> >   VK_IMAGE_LAYOUT_COLOR_ATTACHM
>> ENT_OPTIMAL,
>> >   final_layout);
>> >}
>> > -   } else if (initial_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL)
>> {
>> > -  /* Resolves are only necessary if the subresource may contain
>> blocks
>> > -   * fast-cleared to values unsupported in other layouts. This
>> only occurs
>> > -   * if the initial layout is COLOR_ATTACHMENT_OPTIMAL.
>> > -   */
>> > -  return;
>> > -   } else if (image->samples > 1) {
>> > -  /* MCS buffers don't need resolving. */
>> >return;
>> > }
>> >
>> > +   /* If initial aux usage is NONE, there is nothing to resolve */
>> > +   const enum isl_aux_usage initial_aux_usage =
>> > +  anv_layout_to_aux_usage(devinfo, image, aspect, initial_layout);
>> > +   if (initial_aux_usage == ISL_AUX_USAGE_NONE)
>> > +  return;
>> > +
>> > +   enum isl_aux_op resolve_op = ISL_AUX_OP_NONE;
>> > +
>> > +   /* If the initial layout supports more fast clear than the final
>> layout
>> > +* then we need at least a partial resolve.
>> > +*/
>> > +   const enum anv_fast_clear_type initial_fast_clear =
>> > +  anv_layout_to_fast_clear_type(devinfo, image, aspect,
>> initial_layout);
>> > +   const enum anv_fast_clear_type final_fast_clear =
>> > +  anv_layout_to_fast_clear_type(devinfo, image, aspect,
>> final_layout);
>> > +   if (final_fast_clear < initial_fast_clear)
>> > +  resolve_op = ISL_AUX_OP_PARTIAL_RESOLVE;
>> > +
>> > +   const enum isl_aux_usage final_aux_usage =
>> > +  anv_layout_to_aux_usage(devinfo, image, aspect, final_layout);
>> > +   if (initial_aux_usage == ISL_AUX_USAGE_CCS_E &&
>> > +   final_aux_usage != ISL_AUX_USAGE_CCS_E)
>> > +  

[Mesa-dev] [Bug 104749] rasterizer/jitter/JitManager.cpp:252:91: error: no matching function for call to ‘llvm::DIBuilder::createBasicType(const char [8], int, llvm::dwarf::TypeKind)’

[bugzilla-daemon]

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

Bug ID: 104749
   Summary: rasterizer/jitter/JitManager.cpp:252:91: error: no
matching function for call to
‘llvm::DIBuilder::createBasicType(const char [8], int,
llvm::dwarf::TypeKind)’
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: george.kyria...@intel.com

Build error with llvm-3.9.

  CXX  rasterizer/jitter/libmesaswr_la-JitManager.lo
rasterizer/jitter/JitManager.cpp: In member function ‘llvm::DIType*
JitManager::GetDebugType(llvm::Type*)’:
rasterizer/jitter/JitManager.cpp:252:91: error: no matching function for call
to ‘llvm::DIBuilder::createBasicType(const char [8], int,
llvm::dwarf::TypeKind)’
 case Type::HalfTyID: return builder.createBasicType("float16", 16,
dwarf::DW_ATE_float); break;
   
   ^

-- 
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 v2 09/24] anv/cmd_buffer: Generalize transition_color_buffer

[Jason Ekstrand]

On Mon, Jan 22, 2018 at 11:31 AM, Nanley Chery 
wrote:

> On Fri, Jan 19, 2018 at 03:47:26PM -0800, Jason Ekstrand wrote:
> > This moves it to being based on layout_to_aux_usage instead of being
> > hard-coded based on bits of a priori knowledge of how transitions
> > interact with layouts.  This conceptually simplifies things because
> > we're now using layout_to_aux_usage and layout_supports_fast_clear to
> > make resolve decisions so changes to those functions will do what one
> > expects.
> >
> > This fixes a potential bug with window system integration on gen9+ where
> ^
> This patch still doesn't fix the bug.
>

Yup.  I've changed this paragraph to:

There is a potential bug with window system integration on gen9+ where
we wouldn't do a resolve when transitioning to the PRESENT_SRC layout
because we just assume that everything that handles CCS_E can handle it
all the time.  When handing a CCS_E image off to the window system, we
may need to do a full resolve if the window system does not support the
CCS_E modifier.  The only reason why this hasn't been a problem yet is
because we don't support modifiers in Vulkan WSI and so we always get X
tiling which implies no CCS on gen9+.  This patch doesn't actually fix
that bug yet but it takes us the first step in that direction by making
us actually pick the correct resolve op.  In order to handle all of the
cases, we need more detailed aux tracking.


> > we wouldn't do a resolve when transitioning to the PRESENT_SRC layout
> > because we just assume that everything that handles CCS_E can handle it
> > all the time.  When handing a CCS_E image off to the window system, we
> > may need to do a full resolve if the window system does not support the
> > CCS_E modifier.  The only reason why this hasn't been a problem yet is
> > because we don't support modifiers in Vulkan WSI and so we always get X
> > tiling which implies no CCS on gen9+.
> >
> > v2 (Jason Ekstrand):
> >  - Make a few more things const
> >  - Use the anv_fast_clear_support enum
> >
> > Reviewed-by: Topi Pohjolainen 
> > ---
> >  src/intel/vulkan/genX_cmd_buffer.c | 56 ++
> 
> >  1 file changed, 44 insertions(+), 12 deletions(-)
> >
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index 6a6d8b2..fd27463 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -593,6 +593,7 @@ transition_color_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> >  VkImageLayout initial_layout,
> >  VkImageLayout final_layout)
> >  {
> > +   const struct gen_device_info *devinfo = _buffer->device->info;
> > /* Validate the inputs. */
> > assert(cmd_buffer);
> > assert(image && image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> > @@ -733,17 +734,51 @@ transition_color_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> >   VK_IMAGE_LAYOUT_COLOR_
> ATTACHMENT_OPTIMAL,
> >   final_layout);
> >}
> > -   } else if (initial_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL)
> {
> > -  /* Resolves are only necessary if the subresource may contain
> blocks
> > -   * fast-cleared to values unsupported in other layouts. This only
> occurs
> > -   * if the initial layout is COLOR_ATTACHMENT_OPTIMAL.
> > -   */
> > -  return;
> > -   } else if (image->samples > 1) {
> > -  /* MCS buffers don't need resolving. */
> >return;
> > }
> >
> > +   /* If initial aux usage is NONE, there is nothing to resolve */
> > +   const enum isl_aux_usage initial_aux_usage =
> > +  anv_layout_to_aux_usage(devinfo, image, aspect, initial_layout);
> > +   if (initial_aux_usage == ISL_AUX_USAGE_NONE)
> > +  return;
> > +
> > +   enum isl_aux_op resolve_op = ISL_AUX_OP_NONE;
> > +
> > +   /* If the initial layout supports more fast clear than the final
> layout
> > +* then we need at least a partial resolve.
> > +*/
> > +   const enum anv_fast_clear_type initial_fast_clear =
> > +  anv_layout_to_fast_clear_type(devinfo, image, aspect,
> initial_layout);
> > +   const enum anv_fast_clear_type final_fast_clear =
> > +  anv_layout_to_fast_clear_type(devinfo, image, aspect,
> final_layout);
> > +   if (final_fast_clear < initial_fast_clear)
> > +  resolve_op = ISL_AUX_OP_PARTIAL_RESOLVE;
> > +
> > +   const enum isl_aux_usage final_aux_usage =
> > +  anv_layout_to_aux_usage(devinfo, image, aspect, final_layout);
> > +   if (initial_aux_usage == ISL_AUX_USAGE_CCS_E &&
> > +   final_aux_usage != ISL_AUX_USAGE_CCS_E)
> > +  resolve_op = ISL_AUX_OP_FULL_RESOLVE;
> > +
> > +   /* CCS_D only supports full resolves and BLORP will assert on us if
> we try
> > +* to do a partial resolve on a CCS_D surface.
> > +*/
> > +   if 

Re: [Mesa-dev] [PATCH] radv: fix sample_mask_in loading.

[Timothy Arceri]

This breaks some piglit tests on radeonsi e.g.

R600_DEBUG=nir ./bin/arb_sample_shading-samplemask 2 all all -auto -fbo

On 23/01/18 12:08, Dave Airlie wrote:

From: Dave Airlie 

This is ported from amdvlk, and fixes:
dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.bit_*

Signed-off-by: Dave Airlie 
---
  src/amd/common/ac_nir_to_llvm.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 214fb14..876c7ce 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4046,6 +4046,16 @@ static LLVMValueRef load_sample_pos(struct 
ac_nir_context *ctx)
return ac_build_gather_values(>ac, values, 2);
  }
  
+static LLVMValueRef load_sample_mask_in(struct ac_nir_context *ctx)

+{
+   LLVMValueRef result, sample_id;
+   sample_id = unpack_param(>ac, ctx->abi->ancillary, 8, 4);
+
+   sample_id = LLVMBuildShl(ctx->ac.builder, ctx->ac.i32_1, sample_id, "");
+   result = LLVMBuildAnd(ctx->ac.builder, sample_id, ctx->abi->sample_coverage, 
"");
+   return result;
+}
+
  static LLVMValueRef visit_interp(struct nir_to_llvm_context *ctx,
 const nir_intrinsic_instr *instr)
  {
@@ -4350,7 +4360,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
result = load_sample_pos(ctx);
break;
case nir_intrinsic_load_sample_mask_in:
-   result = ctx->abi->sample_coverage;
+   result = load_sample_mask_in(ctx);
break;
case nir_intrinsic_load_frag_coord: {
LLVMValueRef values[4] = {


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

Re: [Mesa-dev] [PATCH v2 12/24] anv/cmd_buffer: Add a mark_image_written helper

[Jason Ekstrand]

On Mon, Jan 22, 2018 at 3:22 PM, Nanley Chery  wrote:

> On Fri, Jan 19, 2018 at 03:47:29PM -0800, Jason Ekstrand wrote:
> > Currently, this helper does nothing but we call it every place where an
> > image is written through the render pipeline.  This will allow us to
> > properly mark the aux state so that we can handle resolves correctly.
> > ---
> >  src/intel/vulkan/anv_blorp.c   | 44 ++
> +++-
> >  src/intel/vulkan/anv_cmd_buffer.c  | 15 +
> >  src/intel/vulkan/anv_genX.h|  8 +++
> >  src/intel/vulkan/anv_private.h |  9 
> >  src/intel/vulkan/genX_cmd_buffer.c | 44 ++
> 
> >  5 files changed, 119 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index e4e4135..05efc6d 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -283,6 +283,10 @@ void anv_CmdCopyImage(
> >  get_blorp_surf_for_anv_image(cmd_buffer->device,
> >   dst_image, 1UL << aspect_bit,
> >   ANV_AUX_USAGE_DEFAULT,
> _surf);
> > +anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> > +  1UL << aspect_bit,
> > +  dst_surf.aux_usage,
> dst_level,
> > +  dst_base_layer,
> layer_count);
> >
> >  for (unsigned i = 0; i < layer_count; i++) {
> > blorp_copy(, _surf, src_level, src_base_layer
> + i,
> > @@ -298,6 +302,9 @@ void anv_CmdCopyImage(
> >ANV_AUX_USAGE_DEFAULT, _surf);
> >   get_blorp_surf_for_anv_image(cmd_buffer->device, dst_image,
> dst_mask,
> >ANV_AUX_USAGE_DEFAULT, _surf);
> > + anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> dst_mask,
> > +   dst_surf.aux_usage,
> dst_level,
> > +   dst_base_layer, layer_count);
> >
> >   for (unsigned i = 0; i < layer_count; i++) {
> >  blorp_copy(, _surf, src_level, src_base_layer + i,
> > @@ -386,6 +393,13 @@ copy_buffer_to_image(struct anv_cmd_buffer
> *cmd_buffer,
> >  buffer_row_pitch, buffer_format,
> >  , _isl_surf);
> >
> > +  if ( == dst) {
> > + anv_cmd_buffer_mark_image_written(cmd_buffer, anv_image,
> > +   aspect, dst->surf.aux_usage,
> > +   dst->level,
> > +   dst->offset.z, extent.depth);
> > +  }
> > +
> >for (unsigned z = 0; z < extent.depth; z++) {
> >   blorp_copy(, >surf, src->level, src->offset.z,
> >  >surf, dst->level, dst->offset.z,
> > @@ -545,6 +559,12 @@ void anv_CmdBlitImage(
> >bool flip_y = flip_coords(_y0, _y1, _y0, _y1);
> >
> >const unsigned num_layers = dst_end - dst_start;
> > +  anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> > +dst_res->aspectMask,
> > +dst.aux_usage,
> > +dst_res->mipLevel,
> > +dst_start, num_layers);
> > +
> >for (unsigned i = 0; i < num_layers; i++) {
> >   unsigned dst_z = dst_start + i;
> >   unsigned src_z = src_start + i * src_z_step;
> > @@ -558,7 +578,6 @@ void anv_CmdBlitImage(
> >  dst_x0, dst_y0, dst_x1, dst_y1,
> >  gl_filter, flip_x, flip_y);
> >}
> > -
>
>   ^
> Random line deletion? Not a big deal.
>

Yup.  Rebase fail. Dropped.


> > }
> >
> > blorp_batch_finish();
> > @@ -818,6 +837,11 @@ void anv_CmdClearColorImage(
> >  layer_count = anv_minify(image->extent.depth, level);
> >   }
> >
> > + anv_cmd_buffer_mark_image_written(cmd_buffer, image,
> > +   pRanges[r].aspectMask,
> > +   surf.aux_usage, level,
> > +   base_layer, layer_count);
> > +
> >   blorp_clear(, ,
> >   src_format.isl_format, src_format.swizzle,
> >   level, base_layer, layer_count,
> > @@ -1215,6 +1239,13 @@ anv_cmd_buffer_clear_subpass(struct
> anv_cmd_buffer *cmd_buffer)
> >  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT |
> ANV_PIPE_CS_STALL_BIT;
> >} else {
> >   assert(image->n_planes == 1);
> > + anv_cmd_buffer_mark_image_written(cmd_buffer, image,
> > +   VK_IMAGE_ASPECT_COLOR_BIT,
> 

[Mesa-dev] [Bug 104746] [swrast] piglit attribs regression

[bugzilla-daemon]

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

Bug ID: 104746
   Summary: [swrast] piglit attribs regression
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: bri...@vmware.com, i...@freedesktop.org

$ ./bin/attribs -auto
Testing GL2

Testing glColor3b(), vertex arrays
Testing glColor3d(), vertex arrays
Testing glColor3f(), vertex arrays
Testing glColor3i(), vertex arrays
Testing glColor3s(), vertex arrays
Testing glColor3ub(), vertex arrays
Testing glColor3ui(), vertex arrays
Testing glColor3ui(), vertex arrays
Testing glColor3us(), vertex arrays
Testing glColor4b(), vertex arrays
Testing glColor4d(), vertex arrays
Testing glColor4f(), vertex arrays
Testing glColor4i(), vertex arrays
Testing glColor4s(), vertex arrays
Testing glColor4ub(), vertex arrays
Testing glColor4ui(), vertex arrays
Testing glColor4us(), vertex arrays
Testing glVertexAttrib1d(), vertex arrays
Testing glVertexAttrib1d(), vertex arrays
Testing glVertexAttrib1f(), vertex arrays
Testing glVertexAttrib1s(), vertex arrays
Testing glVertexAttrib2d(), vertex arrays
Testing glVertexAttrib2f(), vertex arrays
Testing glVertexAttrib2s(), vertex arrays
Testing glVertexAttrib3d(), vertex arrays
Testing glVertexAttrib3f(), vertex arrays
Testing glVertexAttrib3s(), vertex arrays
Testing glVertexAttrib4Nub(), vertex arrays
Testing glVertexAttrib4d(), vertex arrays
Testing glVertexAttrib4f(), vertex arrays
Testing glVertexAttrib4s(), vertex arrays

Testing glColor3b(), immediate mode
Testing glColor3d(), immediate mode
Testing glColor3f(), immediate mode
Testing glColor3i(), immediate mode
Testing glColor3s(), immediate mode
Testing glColor3ub(), immediate mode
Testing glColor3ui(), immediate mode
Testing glColor3ui(), immediate mode
Testing glColor3us(), immediate mode
Testing glColor4b(), immediate mode
Testing glColor4d(), immediate mode
Testing glColor4f(), immediate mode
Testing glColor4i(), immediate mode
Testing glColor4s(), immediate mode
Testing glColor4ub(), immediate mode
Testing glColor4ui(), immediate mode
Testing glColor4us(), immediate mode
Testing glVertexAttrib1d(), immediate mode
Testing glVertexAttrib1d(), immediate mode
Testing glVertexAttrib1f(), immediate mode
Testing glVertexAttrib1s(), immediate mode
Testing glVertexAttrib2d(), immediate mode
Testing glVertexAttrib2f(), immediate mode
Testing glVertexAttrib2s(), immediate mode
Testing glVertexAttrib3d(), immediate mode
Testing glVertexAttrib3f(), immediate mode
Testing glVertexAttrib3s(), immediate mode
Testing glVertexAttrib4Nub(), immediate mode
Testing glVertexAttrib4d(), immediate mode
Testing glVertexAttrib4f(), immediate mode
Testing glVertexAttrib4s(), immediate mode

Testing glColor3b(), display list
Probe color at (95,105)
  Expected: 0.00 1.00 0.00 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (105,105)
  Expected: 0.50 0.30 0.90 0.50
  Observed: 0.20 0.20 0.20 1.00
Testing glColor3d(), display list
Probe color at (125,105)
  Expected: 0.20 0.40 0.60 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (135,105)
  Expected: 0.00 1.00 0.00 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (145,105)
  Expected: 0.50 0.30 0.90 0.50
  Observed: 0.20 0.20 0.20 1.00
Testing glColor3f(), display list
Testing glColor3i(), display list
Probe color at (205,105)
  Expected: 0.20 0.40 0.60 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (215,105)
  Expected: 0.00 1.00 0.00 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (225,105)
  Expected: 0.50 0.30 0.90 0.50
  Observed: 0.20 0.20 0.20 1.00
Testing glColor3s(), display list
Probe color at (245,105)
  Expected: 0.20 0.40 0.60 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (255,105)
  Expected: 0.00 1.00 0.00 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (265,105)
  Expected: 0.50 0.30 0.90 0.50
  Observed: 0.20 0.20 0.20 1.00
Testing glColor3ub(), display list
Probe color at (285,105)
  Expected: 0.20 0.40 0.60 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (295,105)
  Expected: 0.00 1.00 0.00 0.50
  Observed: 0.20 0.20 0.20 1.00
Probe color at (305,105)
  Expected: 0.50 0.30 0.90 0.50
  Observed: 0.20 0.20 0.20 1.00
Testing glColor3ui(), display list
Probe 

Re: [Mesa-dev] [PATCH v2 19/24] anv/cmd_buffer: Move the mi_alu helper higher up

[Jason Ekstrand]

On Mon, Jan 22, 2018 at 2:24 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Jan 19, 2018 at 03:47:36PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/genX_cmd_buffer.c | 34 +++---
> 
> >  1 file changed, 19 insertions(+), 15 deletions(-)
> >
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index 9e2eba3..15e805f 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -431,6 +431,25 @@ genX(set_image_needs_resolve)(struct
> anv_cmd_buffer *cmd_buffer,
> > }
> >  }
> >
> > +#if GEN_IS_HASWELL || GEN_GEN >= 8
> > +static inline uint32_t
> > +mi_alu(uint32_t opcode, uint32_t operand1, uint32_t operand2)
> > +{
> > +   struct GENX(MI_MATH_ALU_INSTRUCTION) instr = {
> > +  .ALUOpcode = opcode,
> > +  .Operand1 = operand1,
> > +  .Operand2 = operand2,
> > +   };
> > +
> > +   uint32_t dw;
> > +   GENX(MI_MATH_ALU_INSTRUCTION_pack)(NULL, , );
> > +
> > +   return dw;
> > +}
> > +#endif
> > +
> > +#define CS_GPR(n) (0x2600 + (n) * 8)
> > +
> >  static void
> >  genX(load_needs_resolve_predicate)(struct anv_cmd_buffer *cmd_buffer,
> > const struct anv_image *image,
> > @@ -2312,21 +2331,6 @@ void genX(CmdDrawIndexed)(
> >  /* MI_MATH only exists on Haswell+ */
> >  #if GEN_IS_HASWELL || GEN_GEN >= 8
> >
> > -static uint32_t
> > -mi_alu(uint32_t opcode, uint32_t op1, uint32_t op2)
> > -{
> > -   struct GENX(MI_MATH_ALU_INSTRUCTION) instr = {
> > -  .ALUOpcode = opcode,
> > -  .Operand1 = op1,
> > -  .Operand2 = op2,
> > -   };
> > -
> > -   uint32_t dw;
> > -   GENX(MI_MATH_ALU_INSTRUCTION_pack)(NULL, , );
> > -
> > -   return dw;
> > -}
> > -
> >  #define CS_GPR(n) (0x2600 + (n) * 8)
>
> This needs to be removed as well. With that:
>

Done.


> Reviewed-by: Topi Pohjolainen 
>
> >
> >  /* Emit dwords to multiply GPR0 by N */
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 17/24] anv: Use blorp_ccs_ambiguate instead of fast-clears

[Jason Ekstrand]

On Mon, Jan 22, 2018 at 2:18 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Jan 19, 2018 at 03:47:34PM -0800, Jason Ekstrand wrote:
> > Even though the blorp pass looks a bit on the sketchy side, the end
> > result in the Vulkan driver is very nice.  Instead of having this weird
> > case where you do a fast clear and then maybe have to resolve, we just
> > do the ambiguate and are done with it.  The ambiguate does exactly what
> > we want of setting all the CCS values to 0 which puts it inot the
> > pass-through state.
> >
> > This should also improve performance a bit in certain cases.  For
> > instance, if we did a transition from UNDEFINED to GENERAL for a surface
> > that doesn't have CCS enabled all the time, we would end up doing a
> > fast-clear and then a full resolve which ends up touching every byte in
> > the main surface as well as the CCS.  With the ambiguate pass, that
> > transition only touches the CCS.
> > ---
> >  src/intel/vulkan/anv_blorp.c   |  5 
> >  src/intel/vulkan/genX_cmd_buffer.c | 54 +-
> 
> >  2 files changed, 17 insertions(+), 42 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index 05efc6d..3698543 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1792,6 +1792,11 @@ anv_image_ccs_op(struct anv_cmd_buffer
> *cmd_buffer,
> >  surf.surf->format, isl_to_blorp_fast_clear_op(
> ccs_op));
> >break;
> > case ISL_AUX_OP_AMBIGUATE:
> > +  for (uint32_t a = 0; a < layer_count; a++) {
> > + const uint32_t layer = base_layer + a;
> > + blorp_ccs_ambiguate(, , level, layer);
> > +  }
> > +  break;
> > default:
> >unreachable("Unsupported CCS operation");
> > }
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index 77fdadf..9e2eba3 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -486,15 +486,6 @@ init_fast_clear_state_entry(struct anv_cmd_buffer
> *cmd_buffer,
> > uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> > enum isl_aux_usage aux_usage = image->planes[plane].aux_usage;
> >
> > -   /* The resolve flag should updated to signify that
> fast-clear/compression
> > -* data needs to be removed when leaving the undefined layout. Such
> data
> > -* may need to be removed if it would cause accesses to the color
> buffer
> > -* to return incorrect data. The fast clear data in CCS_D buffers
> should
> > -* be removed because CCS_D isn't enabled all the time.
> > -*/
> > -   genX(set_image_needs_resolve)(cmd_buffer, image, aspect, level,
> > - aux_usage == ISL_AUX_USAGE_NONE);
> > -
> > /* The fast clear value dword(s) will be copied into a surface state
> object.
> >  * Ensure that the restrictions of the fields in the dword(s) are
> followed.
> >  *
> > @@ -677,10 +668,9 @@ transition_color_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> >for (unsigned level = base_level; level < last_level_num; level++)
> >   init_fast_clear_state_entry(cmd_buffer, image, aspect, level);
> >
> > -  /* Initialize the aux buffers to enable correct rendering. This
> operation
> > -   * requires up to two steps: one to rid the aux buffer of data
> that may
> > -   * cause GPU hangs, and another to ensure that writes done
> without aux
> > -   * will be visible to reads done with aux.
> > +  /* Initialize the aux buffers to enable correct rendering.  In
> order to
> > +   * ensure that things such as storage images work correctly, aux
> buffers
> > +   * are initialized to the pass-through state.
> > *
> > * Having an aux buffer with invalid data is possible for CCS
> buffers
> > * SKL+ and for MCS buffers with certain sample counts (2x and
> 8x). One
> > @@ -692,16 +682,18 @@ transition_color_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> > * We don't have any data to show that this is a problem, but we
> want to
> > * avoid causing difficult-to-debug problems.
> > */
> > -  if (GEN_GEN >= 9 && image->samples == 1) {
> > +  if (image->samples == 1) {
> >   for (uint32_t l = 0; l < level_count; l++) {
> >  const uint32_t level = base_level + l;
> >  const uint32_t level_layer_count =
> > MIN2(layer_count, anv_image_aux_layers(image, aspect,
> level));
> >  anv_image_ccs_op(cmd_buffer, image, aspect, level,
> >   base_layer, level_layer_count,
> > - ISL_AUX_OP_FAST_CLEAR, false);
> > + ISL_AUX_OP_AMBIGUATE, false);
> > +genX(set_image_needs_resolve)(cmd_buffer, image,
> > +  aspect, level, false);
> 

[Mesa-dev] [PATCH] radv: fix sample_mask_in loading.

[Dave Airlie]

From: Dave Airlie 

This is ported from amdvlk, and fixes:
dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.bit_*

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 214fb14..876c7ce 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4046,6 +4046,16 @@ static LLVMValueRef load_sample_pos(struct 
ac_nir_context *ctx)
return ac_build_gather_values(>ac, values, 2);
 }
 
+static LLVMValueRef load_sample_mask_in(struct ac_nir_context *ctx)
+{
+   LLVMValueRef result, sample_id;
+   sample_id = unpack_param(>ac, ctx->abi->ancillary, 8, 4);
+
+   sample_id = LLVMBuildShl(ctx->ac.builder, ctx->ac.i32_1, sample_id, "");
+   result = LLVMBuildAnd(ctx->ac.builder, sample_id, 
ctx->abi->sample_coverage, "");
+   return result;
+}
+
 static LLVMValueRef visit_interp(struct nir_to_llvm_context *ctx,
 const nir_intrinsic_instr *instr)
 {
@@ -4350,7 +4360,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
result = load_sample_pos(ctx);
break;
case nir_intrinsic_load_sample_mask_in:
-   result = ctx->abi->sample_coverage;
+   result = load_sample_mask_in(ctx);
break;
case nir_intrinsic_load_frag_coord: {
LLVMValueRef values[4] = {
-- 
2.9.5

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

[Mesa-dev] [PATCH v2 06/22] clover: Move device extensions definitions to core/device.cpp

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/device.cpp  | 11 +--
 src/gallium/state_trackers/clover/core/device.cpp | 14 ++
 src/gallium/state_trackers/clover/core/device.hpp |  1 +
 3 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index 576555a9af..4e274c5005 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -330,16 +330,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_EXTENSIONS:
-  buf.as_string() =
- "cl_khr_byte_addressable_store"
- " cl_khr_global_int32_base_atomics"
- " cl_khr_global_int32_extended_atomics"
- " cl_khr_local_int32_base_atomics"
- " cl_khr_local_int32_extended_atomics"
- + std::string(dev.has_int64_atomics() ? " cl_khr_int64_base_atomics" 
: "")
- + std::string(dev.has_int64_atomics() ? " 
cl_khr_int64_extended_atomics" : "")
- + std::string(dev.has_doubles() ? " cl_khr_fp64" : "")
- + std::string(dev.has_halves() ? " cl_khr_fp16" : "");
+  buf.as_string() = dev.supported_extensions();
   break;
 
case CL_DEVICE_PLATFORM:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index 7eaa0ca2cb..9fb233aa72 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -279,3 +279,17 @@ bool
 device::supports_ir(cl_uint ir) const {
return supported_irs() & (1 << ir);
 }
+
+std::string
+device::supported_extensions() const {
+   return
+  "cl_khr_byte_addressable_store"
+  " cl_khr_global_int32_base_atomics"
+  " cl_khr_global_int32_extended_atomics"
+  " cl_khr_local_int32_base_atomics"
+  " cl_khr_local_int32_extended_atomics"
+  + std::string(has_int64_atomics() ? " cl_khr_int64_base_atomics" : "")
+  + std::string(has_int64_atomics() ? " cl_khr_int64_extended_atomics" : 
"")
+  + std::string(has_doubles() ? " cl_khr_fp64" : "")
+  + std::string(has_halves() ? " cl_khr_fp16" : "");
+}
diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
b/src/gallium/state_trackers/clover/core/device.hpp
index eed644e919..98b9637ace 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -83,6 +83,7 @@ namespace clover {
   cl_uint supported_irs() const;
   std::string ir_target() const;
   enum pipe_endian endianness() const;
+  std::string supported_extensions() const;
 
   bool supports_ir(cl_uint ir) const;
 
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 07/22] clover: Move platform extensions definitions to clover/platform.cpp

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/platform.cpp  | 4 ++--
 src/gallium/state_trackers/clover/core/platform.cpp | 5 +
 src/gallium/state_trackers/clover/core/platform.hpp | 2 ++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
b/src/gallium/state_trackers/clover/api/platform.cpp
index ed86163311..887dfd0a22 100644
--- a/src/gallium/state_trackers/clover/api/platform.cpp
+++ b/src/gallium/state_trackers/clover/api/platform.cpp
@@ -50,7 +50,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
cl_platform_info param,
 size_t size, void *r_buf, size_t *r_size) try {
property_buffer buf { r_buf, size, r_size };
 
-   obj(d_platform);
+   auto  = obj(d_platform);
 
switch (param) {
case CL_PLATFORM_PROFILE:
@@ -74,7 +74,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
cl_platform_info param,
   break;
 
case CL_PLATFORM_EXTENSIONS:
-  buf.as_string() = "cl_khr_icd";
+  buf.as_string() = platform.supported_extensions();
   break;
 
case CL_PLATFORM_ICD_SUFFIX_KHR:
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp 
b/src/gallium/state_trackers/clover/core/platform.cpp
index 489e8dc5a8..ddd63fc5a0 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -39,3 +39,8 @@ platform::platform() : adaptor_range(evals(), devs) {
   }
}
 }
+
+std::string
+platform::supported_extensions() const {
+   return "cl_khr_icd";
+}
diff --git a/src/gallium/state_trackers/clover/core/platform.hpp 
b/src/gallium/state_trackers/clover/core/platform.hpp
index e849645bbe..b94434c983 100644
--- a/src/gallium/state_trackers/clover/core/platform.hpp
+++ b/src/gallium/state_trackers/clover/core/platform.hpp
@@ -40,6 +40,8 @@ namespace clover {
   platform &
   operator=(const platform ) = delete;
 
+  std::string supported_extensions() const;
+
protected:
   std::vector devs;
};
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 09/22] configure.ac, meson: Check for SPIRV-Tools

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 configure.ac | 5 +
 meson.build  | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/configure.ac b/configure.ac
index 7c1fbe0ed1..8c50ea6792 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2373,6 +2373,11 @@ AM_CONDITIONAL(HAVE_CLOVER_ICD, test 
"x$enable_opencl_icd" = xyes)
 AC_SUBST([OPENCL_LIBNAME])
 AC_SUBST([CLANG_RESOURCE_DIR])
 
+AS_IF([test "x$enable_opencl" = xyes], [
+PKG_CHECK_MODULES([SPIRV_TOOLS], [SPIRV-Tools >= 2017.3])])
+AC_SUBST([SPIRV_TOOLS_CFLAGS])
+AC_SUBST([SPIRV_TOOLS_LIBS])
+
 dnl
 dnl Gallium configuration
 dnl
diff --git a/meson.build b/meson.build
index f3179c3806..78315020fa 100644
--- a/meson.build
+++ b/meson.build
@@ -596,10 +596,12 @@ if _opencl != 'disabled'
 
   # TODO: alitvec?
   dep_clc = dependency('libclc')
+  dep_spirv_tools = dependency('SPIRV-Tools', version : '>= 2017.3')
   with_gallium_opencl = true
   with_opencl_icd = _opencl == 'icd'
 else
   dep_clc = []
+  dep_spirv_tools = []
   with_gallium_opencl = false
   with_gallium_icd = false
 endif
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 10/22] clover/spirv: Import spirv.hpp11 version 1.0 (rev 12)

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 .../state_trackers/clover/spirv/spirv.hpp11| 997 +
 1 file changed, 997 insertions(+)
 create mode 100644 src/gallium/state_trackers/clover/spirv/spirv.hpp11

diff --git a/src/gallium/state_trackers/clover/spirv/spirv.hpp11 
b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
new file mode 100644
index 00..792eeb1aa0
--- /dev/null
+++ b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
@@ -0,0 +1,997 @@
+// Copyright (c) 2014-2017 The Khronos Group Inc.
+// 
+// Permission is hereby granted, free of charge, to any person obtaining a copy
+// of this software and/or associated documentation files (the "Materials"),
+// to deal in the Materials without restriction, including without limitation
+// the rights to use, copy, modify, merge, publish, distribute, sublicense,
+// and/or sell copies of the Materials, and to permit persons to whom the
+// Materials are furnished to do so, subject to the following conditions:
+// 
+// The above copyright notice and this permission notice shall be included in
+// all copies or substantial portions of the Materials.
+// 
+// MODIFICATIONS TO THIS FILE MAY MEAN IT NO LONGER ACCURATELY REFLECTS KHRONOS
+// STANDARDS. THE UNMODIFIED, NORMATIVE VERSIONS OF KHRONOS SPECIFICATIONS AND
+// HEADER INFORMATION ARE LOCATED AT https://www.khronos.org/registry/ 
+// 
+// THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+// OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+// FROM,OUT OF OR IN CONNECTION WITH THE MATERIALS OR THE USE OR OTHER DEALINGS
+// IN THE MATERIALS.
+
+// This header is automatically generated by the same tool that creates
+// the Binary Section of the SPIR-V specification.
+
+// Enumeration tokens for SPIR-V, in various styles:
+//   C, C++, C++11, JSON, Lua, Python
+// 
+// - C will have tokens with a "Spv" prefix, e.g.: SpvSourceLanguageGLSL
+// - C++ will have tokens in the "spv" name space, e.g.: 
spv::SourceLanguageGLSL
+// - C++11 will use enum classes in the spv namespace, e.g.: 
spv::SourceLanguage::GLSL
+// - Lua will use tables, e.g.: spv.SourceLanguage.GLSL
+// - Python will use dictionaries, e.g.: spv['SourceLanguage']['GLSL']
+// 
+// Some tokens act like mask values, which can be OR'd together,
+// while others are mutually exclusive.  The mask-like ones have
+// "Mask" in their name, and a parallel enum that has the shift
+// amount (1 << x) for each corresponding enumerant.
+
+#ifndef spirv_HPP
+#define spirv_HPP
+
+namespace spv {
+
+typedef unsigned int Id;
+
+#define SPV_VERSION 0x1
+#define SPV_REVISION 12
+
+static const unsigned int MagicNumber = 0x07230203;
+static const unsigned int Version = 0x0001;
+static const unsigned int Revision = 12;
+static const unsigned int OpCodeMask = 0x;
+static const unsigned int WordCountShift = 16;
+
+enum class SourceLanguage : unsigned {
+Unknown = 0,
+ESSL = 1,
+GLSL = 2,
+OpenCL_C = 3,
+OpenCL_CPP = 4,
+HLSL = 5,
+Max = 0x7fff,
+};
+
+enum class ExecutionModel : unsigned {
+Vertex = 0,
+TessellationControl = 1,
+TessellationEvaluation = 2,
+Geometry = 3,
+Fragment = 4,
+GLCompute = 5,
+Kernel = 6,
+Max = 0x7fff,
+};
+
+enum class AddressingModel : unsigned {
+Logical = 0,
+Physical32 = 1,
+Physical64 = 2,
+Max = 0x7fff,
+};
+
+enum class MemoryModel : unsigned {
+Simple = 0,
+GLSL450 = 1,
+OpenCL = 2,
+Max = 0x7fff,
+};
+
+enum class ExecutionMode : unsigned {
+Invocations = 0,
+SpacingEqual = 1,
+SpacingFractionalEven = 2,
+SpacingFractionalOdd = 3,
+VertexOrderCw = 4,
+VertexOrderCcw = 5,
+PixelCenterInteger = 6,
+OriginUpperLeft = 7,
+OriginLowerLeft = 8,
+EarlyFragmentTests = 9,
+PointMode = 10,
+Xfb = 11,
+DepthReplacing = 12,
+DepthGreater = 14,
+DepthLess = 15,
+DepthUnchanged = 16,
+LocalSize = 17,
+LocalSizeHint = 18,
+InputPoints = 19,
+InputLines = 20,
+InputLinesAdjacency = 21,
+Triangles = 22,
+InputTrianglesAdjacency = 23,
+Quads = 24,
+Isolines = 25,
+OutputVertices = 26,
+OutputPoints = 27,
+OutputLineStrip = 28,
+OutputTriangleStrip = 29,
+VecTypeHint = 30,
+ContractionOff = 31,
+PostDepthCoverage = 4446,
+StencilRefReplacingEXT = 5027,
+Max = 0x7fff,
+};
+
+enum class StorageClass : unsigned {
+UniformConstant = 0,
+Input = 1,
+Uniform = 2,
+Output = 3,
+Workgroup = 4,
+CrossWorkgroup = 5,
+Private = 6,
+Function = 7,
+Generic = 8,
+PushConstant = 9,
+AtomicCounter = 10,
+Image = 11,
+StorageBuffer 

[Mesa-dev] [PATCH v2 08/22] include/pipe: Define SPIRV as an IR

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/include/pipe/p_defines.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index b34e7a8570..082d4c4d87 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -896,6 +896,7 @@ enum pipe_shader_ir
PIPE_SHADER_IR_LLVM,
PIPE_SHADER_IR_NATIVE,
PIPE_SHADER_IR_NIR,
+   PIPE_SHADER_IR_SPIRV
 };
 
 /**
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 15/22] include/CL: Add cl_khr_il_program

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 include/CL/cl_ext.h | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/include/CL/cl_ext.h b/include/CL/cl_ext.h
index 710bea8837..2e4845d27d 100644
--- a/include/CL/cl_ext.h
+++ b/include/CL/cl_ext.h
@@ -308,6 +308,40 @@ typedef struct _cl_mem_ion_host_ptr
 
 #endif /* CL_VERSION_1_1 */
 
+
+/***
+ * cl_khr_il_program extension *
+ ***/
+
+#ifndef cl_khr_il_program
+#define cl_khr_il_program 1
+
+/* New property to clGetDeviceInfo for retrieving supported intermediate
+ * languages
+ */
+#define CL_DEVICE_IL_VERSION_KHR0x105B
+
+/* New property to clGetProgramInfo for retrieving for retrieving the IL of a
+ * program
+ */
+#define CL_PROGRAM_IL_KHR   0x1169
+
+extern CL_API_ENTRY cl_program
+  CL_API_CALL clCreateProgramWithILKHR(
+  cl_context /* context */,
+  const void * /* il */,
+  size_t /* length */,
+  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
+
+typedef CL_API_ENTRY cl_program
+  (CL_API_CALL *clCreateProgramWithILKHR_fn)(
+  cl_context /* context */,
+  const void * /* il */,
+  size_t /* length */,
+  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
+
+#endif /* cl_khr_il_program */
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 14/22] clover: Add a pointer property to return ILs

[Pierre Moreau]

OpenCL 2.1, and cl_khr_il_program, gives the ability to query for a
program’s IL, which is returned as a pointer.

Signed-off-by: Pierre Moreau 
---
 .../state_trackers/clover/core/property.hpp| 39 ++
 1 file changed, 39 insertions(+)

diff --git a/src/gallium/state_trackers/clover/core/property.hpp 
b/src/gallium/state_trackers/clover/core/property.hpp
index 7f8e17684d..5beac372e7 100644
--- a/src/gallium/state_trackers/clover/core/property.hpp
+++ b/src/gallium/state_trackers/clover/core/property.hpp
@@ -23,6 +23,7 @@
 #ifndef CLOVER_CORE_PROPERTY_HPP
 #define CLOVER_CORE_PROPERTY_HPP
 
+#include 
 #include 
 
 #include "util/range.hpp"
@@ -84,6 +85,19 @@ namespace clover {
   private:
  property_buffer 
   };
+
+  template
+  class property_pointer {
+  public:
+ property_pointer(property_buffer ) : buf(buf) {
+ }
+
+ inline property_pointer &
+ operator=(const std::pair );
+
+  private:
+ property_buffer 
+  };
};
 
///
@@ -118,6 +132,12 @@ namespace clover {
  return { *this };
   }
 
+  template
+  detail::property_pointer
+  as_pointer() {
+ return { *this };
+  }
+
   template
   iterator_range
   allocate(size_t n) {
@@ -133,6 +153,17 @@ namespace clover {
 return { };
   }
 
+  void
+  allocate_raw(const void *v, size_t n) {
+ if (r_buf && size < n)
+throw error(CL_INVALID_VALUE);
+
+ if (r_size)
+*r_size = n;
+
+ std::memcpy(r_buf, v, n);
+  }
+
private:
   void *const r_buf;
   const size_t size;
@@ -178,6 +209,14 @@ namespace clover {
  return *this;
   }
 
+  template
+  inline property_pointer &
+  property_pointer::operator=(const std::pair ) {
+ buf.allocate_raw(v.first, v.second);
+
+ return *this;
+  }
+
   inline property_string &
   property_string::operator=(const std::string ) {
  auto r = buf.allocate(v.size() + 1);
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 05/22] clover: Track flags per module section

[Pierre Moreau]

One flag that needs to be tracked is whether a library is allowed to
received mathematics optimisations or not, as the authorisation is given
when creating the library while the optimisations are specified when
creating the executable.

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/core/module.cpp  |  1 +
 src/gallium/state_trackers/clover/core/module.hpp  | 13 +
 src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp |  3 ++-
 src/gallium/state_trackers/clover/llvm/codegen/common.cpp  |  2 +-
 src/gallium/state_trackers/clover/tgsi/compiler.cpp|  3 ++-
 5 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/clover/core/module.cpp 
b/src/gallium/state_trackers/clover/core/module.cpp
index a6c5b98d8e..0e11506d0d 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -163,6 +163,7 @@ namespace {
   proc(S , QT ) {
  _proc(s, x.id);
  _proc(s, x.type);
+ _proc(s, x.flags);
  _proc(s, x.size);
  _proc(s, x.data);
   }
diff --git a/src/gallium/state_trackers/clover/core/module.hpp 
b/src/gallium/state_trackers/clover/core/module.hpp
index 2ddd26426f..ff7e9b6234 100644
--- a/src/gallium/state_trackers/clover/core/module.hpp
+++ b/src/gallium/state_trackers/clover/core/module.hpp
@@ -41,14 +41,19 @@ namespace clover {
 data_local,
 data_private
  };
+ enum class flags_t {
+none,
+allow_link_options
+ };
 
- section(resource_id id, enum type type, size_t size,
- const std::vector ) :
- id(id), type(type), size(size), data(data) { }
- section() : id(0), type(text_intermediate), size(0), data() { }
+ section(resource_id id, enum type type, flags_t flags,
+ size_t size, const std::vector ) :
+ id(id), type(type), flags(flags), size(size), data(data) { }
+ section() : id(0), type(text_intermediate), flags(flags_t::none), 
size(0), data() { }
 
  resource_id id;
  type type;
+ flags_t flags;
  size_t size;
  std::vector data;
   };
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 6737f7af0a..5dbaebf640 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -90,7 +90,8 @@ clover::llvm::build_module_library(const ::llvm::Module ,
enum module::section::type section_type) {
module m;
const auto code = emit_code(mod);
-   m.secs.emplace_back(0, section_type, code.size(), code);
+   m.secs.emplace_back(0, section_type, module::section::flags_t::none,
+   code.size(), code);
return m;
 }
 
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index ddf2083f37..3a08f11fcc 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
@@ -179,7 +179,7 @@ namespace {
make_text_section(const std::vector ) {
   const pipe_llvm_program_header header { uint32_t(code.size()) };
   module::section text { 0, module::section::text_executable,
- header.num_bytes, {} };
+ module::section::flags_t::none, header.num_bytes, 
{} };
 
   text.data.insert(text.data.end(), reinterpret_cast(),
reinterpret_cast() + 
sizeof(header));
diff --git a/src/gallium/state_trackers/clover/tgsi/compiler.cpp 
b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
index e165311fa4..bbe55825a0 100644
--- a/src/gallium/state_trackers/clover/tgsi/compiler.cpp
+++ b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
@@ -91,7 +91,8 @@ namespace {
 
   unsigned sz = tgsi_num_tokens(prog) * sizeof(tgsi_token);
   std::vector data( (char *)prog, (char *)prog + sz );
-  m.secs.push_back({ 0, module::section::text_executable, sz, data });
+  m.secs.push_back({ 0, module::section::text_executable,
+module::section::flags_t::none, sz, data });
}
 }
 
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 04/22] clover: Disallow creating libraries from other libraries

[Pierre Moreau]

If creating a library, do not allow non-compiled object in it, as
executables are not allowed, and libraries would make it really hard to
enforce the "-enable-link-options" flag.

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/program.cpp | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index 6044179587..8f0b103a4d 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -251,9 +251,13 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
 namespace {
ref_vector
validate_link_devices(const ref_vector ,
- const ref_vector _devs) {
+ const ref_vector _devs,
+ const std::string ) {
   std::vector devs;
 
+  const std::string flag = "-create-library";
+  const bool create_library = opts.find("-create-library") != 
std::string::npos;
+
   for (auto  : all_devs) {
  const auto has_binary = [&](const program ) {
 const auto t = prog.build(dev).binary_type();
@@ -261,10 +265,19 @@ namespace {
t == CL_PROGRAM_BINARY_TYPE_LIBRARY;
  };
 
+ // If creating a library, do not allow non-compiled object in it, as
+ // executables are not allowed, and libraries would make it really
+ // hard to enforce the "-enable-link-options".
+ if (create_library && any_of([&](const program ) {
+  const auto t = prog.build(dev).binary_type();
+  return t != CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT;
+   }, progs))
+throw error(CL_INVALID_OPERATION);
+
  // According to the CL 1.2 spec, when "all programs specified [..]
  // contain a compiled binary or library for the device [..] a link is
  // performed",
- if (all_of(has_binary, progs))
+ else if (all_of(has_binary, progs))
 devs.push_back();
 
  // otherwise if "none of the programs contain a compiled binary or
@@ -290,7 +303,7 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, const 
cl_device_id *d_devs,
auto prog = create(ctx);
auto devs = validate_link_devices(progs,
  (d_devs ? objs(d_devs, num_devs) :
-  ref_vector(ctx.devices(;
+  ref_vector(ctx.devices())), 
opts);
 
validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
 
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 03/22] clover/api: Fail if trying to build a non-executable binary

[Pierre Moreau]

From the OpenCL 1.2 Specification, Section 5.6.2 (about clBuildProgram:

> If program is created with clCreateProgramWithBinary, then the
> program binary must be an executable binary (not a compiled binary or
> library).

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/program.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index 9d59668f8f..6044179587 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -186,6 +186,14 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
if (prog.has_source) {
   prog.compile(devs, opts);
   prog.link(devs, opts, { prog });
+   } else if (any_of([&](const device ){
+ return prog.build(dev).binary_type() != 
CL_PROGRAM_BINARY_TYPE_EXECUTABLE;
+ }, objs(d_devs, num_devs))) {
+  // OpenCL 1.2 Specification, Section 5.6.2:
+  // > If program is created with clCreateProgramWithBinary, then the
+  // > program binary must be an executable binary (not a compiled binary 
or
+  // > library).
+  throw error(CL_INVALID_BINARY);
}
 
return CL_SUCCESS;
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 02/22] clover: Add additional functions to query supported IRs

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/core/device.cpp | 11 +++
 src/gallium/state_trackers/clover/core/device.hpp |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index 9dd7eed3f1..7eaa0ca2cb 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -247,6 +247,12 @@ device::ir_format() const {
   pipe, PIPE_SHADER_COMPUTE, PIPE_SHADER_CAP_PREFERRED_IR);
 }
 
+cl_uint
+device::supported_irs() const {
+   return (enum pipe_shader_ir) pipe->get_shader_param(
+  pipe, PIPE_SHADER_COMPUTE, PIPE_SHADER_CAP_SUPPORTED_IRS);
+}
+
 std::string
 device::ir_target() const {
std::vector target = get_compute_param(
@@ -268,3 +274,8 @@ std::string
 device::device_clc_version() const {
 return "1.1";
 }
+
+bool
+device::supports_ir(cl_uint ir) const {
+   return supported_irs() & (1 << ir);
+}
diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
b/src/gallium/state_trackers/clover/core/device.hpp
index 85cd031676..eed644e919 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -80,9 +80,12 @@ namespace clover {
   std::string device_version() const;
   std::string device_clc_version() const;
   enum pipe_shader_ir ir_format() const;
+  cl_uint supported_irs() const;
   std::string ir_target() const;
   enum pipe_endian endianness() const;
 
+  bool supports_ir(cl_uint ir) const;
+
   friend class command_queue;
   friend class root_resource;
   friend class hard_event;
-- 
2.16.0

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

[Mesa-dev] [PATCH v2 00/22] Introducing SPIR-V support to clover

[Pierre Moreau]

Hello,

Here is the second version of my initial series for adding SPIR-V support to
clover, after the RFC back in May 2017.

For recap, the focus of this series is to let clover accept SPIR-V binaries
through the cl_khr_il_program extension (from OpenCL 1.2 and on), as well as
through some core features (since OpenCL 2.1). Even if OpenCL 2.1 support in
clover is some way off, there is another motivation for supporting SPIR-V in
clover, as multiple drivers are interested in adding OpenCL support by
converting SPIR-V to NIR.

Note: the series is based on master + Karol’s patch “clover: add functions up
to 2.2 to ICD dispatch table”.


The various patches can be split in different categories:

* Patches 1 through 7: some clover clean-up, adding and moving some
  functionalities around to make the implementation easier in the rest of the
  series.

* Patches 8 through 13: define SPIR-V as a new IR, add a new frontend to clover
  to deal with SPIR-V, and edit compile and link operations to handle SPIR-V as
  well.

* Patches 14 through 19: implement cl_khr_il_program

* Patches 20 through 22: implement OpenCL 2.1 support on top of
  cl_khr_il_program


Changes since the RFC
-

* Most SPIR-V utilities were dropped, and the remaining ones have been moved to
  the clover SPIR-V frontend rather than sitting in src/gallium/auxiliary/spirv.

* The SPIR-V linker has been completely dropped from this series and instead
  merge in SPIRV-Tools [1].

* Since SPIRV-Tools now exports a pkgconfig .pc file, use it for detecting the
  library.

* Integrate the series with Meson.

* Use pipe_llvm_program_header to pass in the size of the SPIR-V module, rather
  than adding a new attribute to pipe_compute_state, as suggested by Francisco
  Jerez.

* Check that the device supports the capabilities defined in the SPIR-V binary.

* Check that the platform/device supports the extensions used in the SPIR-V
  binary.

* Fix the implementation responsible for filling up the symbols of the clover
  module based on the input SPIR-V binary.

* No longer raw SPIR-V binaries through clCreateProgramWithBinary, but instead
  keep the current de-serialisation of the clover module, which may contain a
  SPIR-V binary.

* Track whether a library was created with the --enable-link-options flag or
  not. This is currently not useful as the linker ignores most link options,
  but it will become useful when the linker handles those options.

* Implement cl_khr_il_program.

* Most of patches 1 through 8 (apart from patch 2).


Discussions
---

* Before, when linking different modules together, you knew that all modules
  would use the same IR, as all were created using clCreateProgramWithSource,
  therefore the linker could just call the linking function corresponding to
  the target’s preferred IR. But with the introduction of
  clCreateProgramWithIL(KHR)?, we can now end up in a case where we try to link
  a module using NIR as IR (created through clCreateProgramWithSource, assuming
  that is the driver’s preferred IR), with another module using SPIR-V as IR
  (created through clCreateProgramWithIL). How do we handle such a case: should
  we translate the SPIR-V to NIR and use a NIR linker on them, or convert NIR
  to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be handled
  relatively easily, but what about TGSI?

* In that regard, is anyone using the TGSI frontend in clover? If not, is
  anyone planning to use it? And if still not, shouldn’t we just remove it?

* In the same vein as the linking discussion just above, what should happen
  when the driver’s preferred IR is one of the IRs not currently supported by
  clover, like NIR for example? Should `compile()` generate a SPIR-V binary
  which is directly translated to NIR, or should we keep everything in SPIR-V
  until the very last moment, right before sending the IR to the driver?  If
  all the drivers supporting compute through clover support an IR that can be
  translated from SPIR-V, it might be easier to keep everything inside clover
  as SPIR-V binaries, until we need to pass the program to the driver, in which
  case we convert it on the fly.


(Still) missing
---

* As there is no upstream version of LLVM which can produce SPIR-V out of
  OpenCL code, clCreateProgramWithSource will refuse to work if the target’s
  preferred IR is SPIR-V, for now.

* Optimisation linking options are ignored for now as SPIRV-Tools’ linker does
  not supported them yet.


Thank you in advance for reviewing/commenting,
Pierre

[1]: https://github.com/KhronosGroup/SPIRV-Tools/


Pierre Moreau (22):
  clover/api: Fix tab indentation to spaces
  clover: Add additional functions to query supported IRs
  clover/api: Fail if trying to build a non-executable binary
  clover: Disallow creating libraries from other libraries
  clover: Track flags per module section
  clover: Move device extensions definitions to core/device.cpp
  clover: Move platform extensions 

[Mesa-dev] [PATCH v2 01/22] clover/api: Fix tab indentation to spaces

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/device.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index 3572bb0c92..576555a9af 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -326,7 +326,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
 #ifdef MESA_GIT_SHA1
 " (" MESA_GIT_SHA1 ")"
 #endif
-   ;
+;
   break;
 
case CL_DEVICE_EXTENSIONS:
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Kyriazis, George]

Chuck,

Change verified on my end; check-in coming coming up soon.

George

On Jan 22, 2018, at 2:11 PM, Kyriazis, George 
> wrote:


On Jan 22, 2018, at 12:02 PM, Chuck Atkins 
> wrote:

Hi Emil,

Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")

It doesn't fix anything that was broken from that commit.  The issues with 
error handling were already present before then, it's just that the changes in 
a4be2bcee2f were substantial so this commit works off the result of the 
previous.  So really it would be "Depends on: " rather than "Fixes: ".


Right this cleans up after the following commit - please include the tag.
Don't bother re-sending.

Not sure how I would go about that since I don't have push access.  The ML is 
really the only mechanism I have to send commits to the git repo.  Given that 
I've been submitting patches from time to time for the past two years or so 
(not often, but every few months I have a handful), should I go ahead and apply 
for an account now?

Chuck,

Don’t worry about it, I will check in this change, and include the tag while 
checking in.  I’ll do that after I finish my testing.  You can, of course, 
apply for an account; that’s completely orthogonal.

Which bring up the question, Emil, when does the branch happen?  I haven’t seen 
any new branches/tags in mesa/master.

Thanks,

George

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

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

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

Re: [Mesa-dev] [PATCH v2 12/24] anv/cmd_buffer: Add a mark_image_written helper

[Nanley Chery]

On Fri, Jan 19, 2018 at 03:47:29PM -0800, Jason Ekstrand wrote:
> Currently, this helper does nothing but we call it every place where an
> image is written through the render pipeline.  This will allow us to
> properly mark the aux state so that we can handle resolves correctly.
> ---
>  src/intel/vulkan/anv_blorp.c   | 44 
> +-
>  src/intel/vulkan/anv_cmd_buffer.c  | 15 +
>  src/intel/vulkan/anv_genX.h|  8 +++
>  src/intel/vulkan/anv_private.h |  9 
>  src/intel/vulkan/genX_cmd_buffer.c | 44 
> ++
>  5 files changed, 119 insertions(+), 1 deletion(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index e4e4135..05efc6d 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -283,6 +283,10 @@ void anv_CmdCopyImage(
>  get_blorp_surf_for_anv_image(cmd_buffer->device,
>   dst_image, 1UL << aspect_bit,
>   ANV_AUX_USAGE_DEFAULT, _surf);
> +anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> +  1UL << aspect_bit,
> +  dst_surf.aux_usage, dst_level,
> +  dst_base_layer, layer_count);
>  
>  for (unsigned i = 0; i < layer_count; i++) {
> blorp_copy(, _surf, src_level, src_base_layer + i,
> @@ -298,6 +302,9 @@ void anv_CmdCopyImage(
>ANV_AUX_USAGE_DEFAULT, _surf);
>   get_blorp_surf_for_anv_image(cmd_buffer->device, dst_image, 
> dst_mask,
>ANV_AUX_USAGE_DEFAULT, _surf);
> + anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image, dst_mask,
> +   dst_surf.aux_usage, dst_level,
> +   dst_base_layer, layer_count);
>  
>   for (unsigned i = 0; i < layer_count; i++) {
>  blorp_copy(, _surf, src_level, src_base_layer + i,
> @@ -386,6 +393,13 @@ copy_buffer_to_image(struct anv_cmd_buffer *cmd_buffer,
>  buffer_row_pitch, buffer_format,
>  , _isl_surf);
>  
> +  if ( == dst) {
> + anv_cmd_buffer_mark_image_written(cmd_buffer, anv_image,
> +   aspect, dst->surf.aux_usage,
> +   dst->level,
> +   dst->offset.z, extent.depth);
> +  }
> +
>for (unsigned z = 0; z < extent.depth; z++) {
>   blorp_copy(, >surf, src->level, src->offset.z,
>  >surf, dst->level, dst->offset.z,
> @@ -545,6 +559,12 @@ void anv_CmdBlitImage(
>bool flip_y = flip_coords(_y0, _y1, _y0, _y1);
>  
>const unsigned num_layers = dst_end - dst_start;
> +  anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> +dst_res->aspectMask,
> +dst.aux_usage,
> +dst_res->mipLevel,
> +dst_start, num_layers);
> +
>for (unsigned i = 0; i < num_layers; i++) {
>   unsigned dst_z = dst_start + i;
>   unsigned src_z = src_start + i * src_z_step;
> @@ -558,7 +578,6 @@ void anv_CmdBlitImage(
>  dst_x0, dst_y0, dst_x1, dst_y1,
>  gl_filter, flip_x, flip_y);
>}
> -

  ^
Random line deletion? Not a big deal.

> }
>  
> blorp_batch_finish();
> @@ -818,6 +837,11 @@ void anv_CmdClearColorImage(
>  layer_count = anv_minify(image->extent.depth, level);
>   }
>  
> + anv_cmd_buffer_mark_image_written(cmd_buffer, image,
> +   pRanges[r].aspectMask,
> +   surf.aux_usage, level,
> +   base_layer, layer_count);
> +
>   blorp_clear(, ,
>   src_format.isl_format, src_format.swizzle,
>   level, base_layer, layer_count,
> @@ -1215,6 +1239,13 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
> *cmd_buffer)
>  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
>} else {
>   assert(image->n_planes == 1);
> + anv_cmd_buffer_mark_image_written(cmd_buffer, image,
> +   VK_IMAGE_ASPECT_COLOR_BIT,
> +   att_state->aux_usage,
> +   iview->planes[0].isl.base_level,
> +   
> iview->planes[0].isl.base_array_layer,
> +   fb->layers);
> +

[Mesa-dev] [PATCH] anv: correct a duplicate check in an assert

[Grazvydas Ignotas]

Looks like checking both sources was intended, instead of the first one
twice. Found with Coccinelle, coccinellery/xand/xand.cocci semantic patch.

Signed-off-by: Grazvydas Ignotas 
---
 src/intel/vulkan/anv_nir_apply_pipeline_layout.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c 
b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
index 978a8a5..6775f9b 100644
--- a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
+++ b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
@@ -145,11 +145,11 @@ lower_res_reindex_intrinsic(nir_intrinsic_instr *intrin,
 
/* For us, the resource indices are just indices into the binding table and
 * array elements are sequential.  A resource_reindex just turns into an
 * add of the two indices.
 */
-   assert(intrin->src[0].is_ssa && intrin->src[0].is_ssa);
+   assert(intrin->src[0].is_ssa && intrin->src[1].is_ssa);
nir_ssa_def *new_index = nir_iadd(b, intrin->src[0].ssa,
 intrin->src[1].ssa);
 
assert(intrin->dest.is_ssa);
nir_ssa_def_rewrite_uses(>dest.ssa, nir_src_for_ssa(new_index));
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] radeonsi: don't ignore pitch for imported textures

[Marek Olšák]

On Mon, Jan 22, 2018 at 2:09 PM, Nicolai Hähnle  wrote:
> On 10.01.2018 20:49, Marek Olšák wrote:
>>
>> From: Marek Olšák 
>
>
> Please add a bug report or reference to what fails without it.

There is no bug report. I just noticed this in the code.

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

[Mesa-dev] [Bug 104742] [swrast] piglit gl-1.4-dlist-multidrawarrays regression

[bugzilla-daemon]

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

Bug ID: 104742
   Summary: [swrast] piglit gl-1.4-dlist-multidrawarrays
regression
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: bri...@vmware.com, i...@freedesktop.org

$ ./bin/gl-1.4-dlist-multidrawarrays -auto
Probe color at (0,0)
  Expected: 255 255 255
  Observed: 0 0 0
Calling glMultiDrawArrays in display list failed for GL_COMPILE_AND_EXECUTE
mode
Probe color at (0,0)
  Expected: 255 255 255
  Observed: 0 0 0
Calling glMultiDrawElements in display list failed for GL_COMPILE mode
Probe color at (0,0)
  Expected: 255 255 255
  Observed: 0 0 0
Calling glMultiDrawElements in display list failed for GL_COMPILE_AND_EXECUTE
mode
Probe color at (0,0)
  Expected: 255 255 255
  Observed: 0 0 0
Calling glMultiModeDrawArraysIBM in display list failed for GL_COMPILE mode
Probe color at (0,0)
  Expected: 255 255 255
  Observed: 0 0 0
Calling glMultiModeDrawArraysIBM in display list failed for
GL_COMPILE_AND_EXECUTE mode
Probe color at (0,0)
  Expected: 255 255 255
  Observed: 0 0 0
Calling glMultiModeDrawElementsIBM in display list failed for GL_COMPILE mode
Probe color at (0,0)
  Expected: 255 255 255
  Observed: 0 0 0
Calling glMultiModeDrawElementsIBM in display list failed for
GL_COMPILE_AND_EXECUTE mode
PIGLIT: {"result": "fail" }


8e4efdc895eacca931b94a0c1fa01aae5c34463b is the first bad commit
commit 8e4efdc895eacca931b94a0c1fa01aae5c34463b
Author: Brian Paul 
Date:   Fri Jan 12 13:18:25 2018 -0700

vbo: optimize some display list drawing (v2)

The vbo_save_vertex_list structure records one or more glBegin/End
primitives which all have the same vertex format.

To draw these primitives, we setup the vertex array state, then
issue the drawing command.  Before, the 'start' vertex was typically
zero and we used the vertex array pointer to indicate where the
vertex data starts.

This patch checks if the vertex buffer offset is an exact multiple of
the vertex size.  If so, that means we can use zero-based vertex array
pointers and use the draw's start value to indicate where the vertex
data starts.

This means a series of display list drawing commands may have
identical vertex array state.  This will get filtered out by the
Gallium CSO module so we can issue a tight series of drawing commands
without state changes to the device.

Note that this also works for a series of glCallList commands (not
just one list that contains multiple glBegin/End pairs).

No Piglit or conform changes.

v2: minor fixes suggested by Ian.

Reviewed-by: Ian Romanick 

:04 04 0757be5a58241cc12ce136e700a08e8dcd3071e5
ca3edf842285f642bc07a5126dd6a23d5b0cbc3c M  src
bisect run success

-- 
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] gallium/u_threaded: don't run out of memory with staging uploads

[Marek Olšák]

On Mon, Jan 22, 2018 at 2:07 PM, Nicolai Hähnle  wrote:
> On 10.01.2018 20:49, Marek Olšák wrote:
>>
>> From: Marek Olšák 
>>
>> Cc: 17.2 17.3 
>> ---
>>   src/gallium/auxiliary/util/u_threaded_context.c | 13 +
>>   src/gallium/auxiliary/util/u_threaded_context.h |  8 
>>   2 files changed, 21 insertions(+)
>>
>> diff --git a/src/gallium/auxiliary/util/u_threaded_context.c
>> b/src/gallium/auxiliary/util/u_threaded_context.c
>> index ffa8247..7bd13cf 100644
>> --- a/src/gallium/auxiliary/util/u_threaded_context.c
>> +++ b/src/gallium/auxiliary/util/u_threaded_context.c
>> @@ -1508,35 +1508,47 @@ struct tc_resource_copy_region {
>>   };
>> static void
>>   tc_resource_copy_region(struct pipe_context *_pipe,
>>   struct pipe_resource *dst, unsigned dst_level,
>>   unsigned dstx, unsigned dsty, unsigned dstz,
>>   struct pipe_resource *src, unsigned src_level,
>>   const struct pipe_box *src_box);
>> static void
>> +tc_notify_staging_upload_done(struct threaded_context *tc, unsigned size)
>> +{
>> +   tc->unflushed_transfer_size += size;
>> +
>> +   if (tc->unflushed_transfer_size >
>> TC_MAX_UNFLUSHED_STAGING_UPLOAD_SIZE) {
>> +  tc->base.flush(>base, NULL, PIPE_FLUSH_ASYNC);
>> +  tc->unflushed_transfer_size = 0;
>> +   }
>> +}
>> +
>> +static void
>>   tc_buffer_do_flush_region(struct threaded_context *tc,
>> struct threaded_transfer *ttrans,
>> const struct pipe_box *box)
>>   {
>>  struct threaded_resource *tres =
>> threaded_resource(ttrans->b.resource);
>>if (ttrans->staging) {
>> struct pipe_box src_box;
>>   u_box_1d(ttrans->offset + box->x % tc->map_buffer_alignment,
>>  box->width, _box);
>>   /* Copy the staging buffer into the original one. */
>> tc_resource_copy_region(>base, ttrans->b.resource, 0, box->x,
>> 0, 0,
>> ttrans->staging, 0, _box);
>> +  tc_notify_staging_upload_done(tc, box->width);
>>  }
>>util_range_add(tres->base_valid_buffer_range, box->x, box->x +
>> box->width);
>>   }
>> static void
>>   tc_transfer_flush_region(struct pipe_context *_pipe,
>>struct pipe_transfer *transfer,
>>const struct pipe_box *rel_box)
>>   {
>> @@ -1653,20 +1665,21 @@ tc_buffer_subdata(struct pipe_context *_pipe,
>>/* The upload is small. Enqueue it. */
>>  struct tc_buffer_subdata *p =
>> tc_add_slot_based_call(tc, TC_CALL_buffer_subdata,
>> tc_buffer_subdata, size);
>>tc_set_resource_reference(>resource, resource);
>>  p->usage = usage;
>>  p->offset = offset;
>>  p->size = size;
>>  memcpy(p->slot, data, size);
>> +   tc_notify_staging_upload_done(tc, size);
>>   }
>> struct tc_texture_subdata {
>>  struct pipe_resource *resource;
>>  unsigned level, usage, stride, layer_stride;
>>  struct pipe_box box;
>>  char slot[0]; /* more will be allocated if needed */
>>   };
>> static void
>> diff --git a/src/gallium/auxiliary/util/u_threaded_context.h
>> b/src/gallium/auxiliary/util/u_threaded_context.h
>> index 53c5a7e..295464a 100644
>> --- a/src/gallium/auxiliary/util/u_threaded_context.h
>> +++ b/src/gallium/auxiliary/util/u_threaded_context.h
>> @@ -225,20 +225,27 @@ struct tc_unflushed_batch_token;
>>   /* Threshold for when to use the queue or sync. */
>>   #define TC_MAX_STRING_MARKER_BYTES  512
>> /* Threshold for when to enqueue buffer/texture_subdata as-is.
>>* If the upload size is greater than this, it will do instead:
>>* - for buffers: DISCARD_RANGE is done by the threaded context
>>* - for textures: sync and call the driver directly
>>*/
>>   #define TC_MAX_SUBDATA_BYTES320
>>   +/* Every staging upload allocates memory. If we have too many uploads
>> + * in a row without flushes, we might run out of memory. This limit
>> controls
>> + * how many bytes of queued uploads we can have at a time. If we go over,
>> + * the threaded context triggers a context flush.
>> + */
>> +#define TC_MAX_UNFLUSHED_STAGING_UPLOAD_SIZE (512 * 1024 * 1024)
>
>
> This seems very aggressive. In reality, this should probably scale with free
> space in GART, but we don't know that here. Can you reduce it to something
> like 64MB? Unless there's concrete evidence that having it higher is
> beneficial, of course.

Well the current limit is infinite. I think 64MB is too low. I would
expect games to use 2-4GB of VRAM per IB. 512MB seems reasonable for a
GTT upload limit. 512MB might not be great for small APUs, but it's
definitely not very high for mid-sized dGPUs, and context flushes can
be bad for perf.

I know that Metro 2033 is slower if I decrease the limit a lot, but I
don't remember what size I 

[Mesa-dev] [PATCH 1/2] svga: fix context alloc error handling

[Grazvydas Ignotas]

'cleanup' path is dereferencing 'svga' a lot, 'done' is a better choice.
Found by Coccinelle.

Signed-off-by: Grazvydas Ignotas 
---
 src/gallium/drivers/svga/svga_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index af16a99..7b3e9e8 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -132,11 +132,11 @@ svga_context_create(struct pipe_screen *screen, void 
*priv, unsigned flags)
 
SVGA_STATS_TIME_PUSH(svgascreen->sws, SVGA_STATS_TIME_CREATECONTEXT);
 
svga = CALLOC_STRUCT(svga_context);
if (!svga)
-  goto cleanup;
+  goto done;
 
LIST_INITHEAD(>dirty_buffers);
 
svga->pipe.screen = screen;
svga->pipe.priv = priv;
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/2] winsys/svga: check correct member after create

[Grazvydas Ignotas]

.mob_fenced was already checked, probably a copy-paste bug.
Found by Coccinelle.

Signed-off-by: Grazvydas Ignotas 
---
 src/gallium/winsys/svga/drm/vmw_screen_pools.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_pools.c 
b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
index 48c95e5..29cdc69 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
@@ -148,11 +148,11 @@ vmw_mob_pools_init(struct vmw_winsys_screen *vws)
   goto out_no_mob_shader_slab;
 
vws->pools.mob_shader_slab_fenced =
   simple_fenced_bufmgr_create(vws->pools.mob_shader_slab,
  vws->fence_ops);
-   if(!vws->pools.mob_fenced)
+   if(!vws->pools.mob_shader_slab_fenced)
   goto out_no_mob_shader_slab_fenced;
 
return TRUE;
 
  out_no_mob_shader_slab_fenced:
-- 
2.7.4

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

[Mesa-dev] [Bug 103526] Mesa 13.0.6/13.0.4 llvmpipe software rasterizer on PowerPC. Unexpected format PIPE_FORMAT_A8B8G8R8_UNORM in st_new_renderbuffer_fb

[bugzilla-daemon]

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

--- Comment #4 from Ben Crocker  ---
Yes, please try Mesa 17.2.4 or later; Mesa 17.2.x is up to 17.2.8.
OR you could try Mesa 17.3.1 or 17.3.2.

In late 2016 to mid-2017, Roland Scheidegger, Ray Strode, and I solved
a number of problems in the LLVM software pipeline.  Please see

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

for our lengthy discussion.

We would like to close this bug as RESOLVED in light of the
successful resolution of 100613.

-- 
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] u_thread: Use pthread_setname_np on linux only

[Jose Fonseca]

On 22/01/18 21:04, Samuel Thibault wrote:

Hello,

Jose Fonseca, on lun. 15 janv. 2018 12:29:39 +, wrote:

On 13/01/18 11:33, Samuel Thibault wrote:

pthread_setname_np was added in glibc 2.12 for the Linux port only, other
ports do not necessarily have it.
---
   src/util/u_thread.h | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index 26cc0b093..8c6e0bdc5 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -62,7 +62,8 @@ static inline void u_thread_setname( const char *name )
   {
   #if defined(HAVE_PTHREAD)
   #  if defined(__GNU_LIBRARY__) && defined(__GLIBC__) && defined(__GLIBC_MINOR__) 
&& \
-  (__GLIBC__ >= 3 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 12))
+  (__GLIBC__ >= 3 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 12)) && \
+  defined(__linux__)
  pthread_setname_np(pthread_self(), name);
   #  endif
   #endif



Looks good to me.

Reviewed-by: Jose Fonseca 


Could somebody commit this?

Thanks,
Samuel


Pushed.  Thanks.

Jose

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

Re: [Mesa-dev] [PATCH] svga: Prevent use after free.

[Jose Fonseca]

On 22/01/18 15:44, Emil Velikov wrote:

On 22 January 2018 at 15:13, Jose Fonseca  wrote:

Courtesy of clang static analyzer.

I was hunting for potential sources of memory corruption using Mesa with
a GL trace, and happened to find this (unrelated) issue.
---
  src/gallium/drivers/svga/svga_context.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 546b9f48b1..af16a99b72 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -327,6 +327,7 @@ cleanup:
 util_bitmask_destroy(svga->stream_output_id_bm);
 util_bitmask_destroy(svga->query_id_bm);
 FREE(svga);
+   svga = NULL;

  done:
 SVGA_STATS_TIME_POP(svgascreen->sws);


Seems like the most important line is just outside of context. Namely:

return svga ? >pipe:NULL;


yep.


Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Emil Velikov 


thanks.

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

Re: [Mesa-dev] [AppVeyor] mesa master #6655 failed

[Jose Fonseca]

I suspect it's an infrastructure problem.  I appeared frequently a while 
back, then went away, now's comming again.


I think the consensus is to move this jobs out of fdo into 
https://github.com/mesa3d but I got no reply from Daniel Stone, so I'm 
not sure how to move that forward.


Jose

On 19/01/18 23:10, Bas Nieuwenhuizen wrote:

Does not seem like a build issue:

Build started
git clone -q --depth=100 --branch=master
git://anongit.freedesktop.org/mesa/mesa C:\projects\mesa
remote: error: Could not read 6bc54a6fc26d022b77e72f7498aa427aa2544062
remote: fatal: bad tree object 6bc54a6fc26d022b77e72f7498aa427aa2544062
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
Command exited with code 128

Interesting though that it finds a revision when it can't even clone.

On Fri, Jan 19, 2018 at 11:37 PM, AppVeyor  wrote:

Build mesa 6655 failed

Commit 61a790409e by Bas Nieuwenhuizen on 1/16/2018 1:08 AM:
radv: Always re-emit the sample position offset user SGPR.\n\nThe user SGPR
location can change between pipelines, so we need to\nemit it again to the
pottentially changed SGPR index.\n\nReviewed-by: Samuel Pitoiset


Configure your notification preferences


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


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



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

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Kyriazis, George]

On Jan 22, 2018, at 12:02 PM, Chuck Atkins 
> wrote:

Hi Emil,

Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")

It doesn't fix anything that was broken from that commit.  The issues with 
error handling were already present before then, it's just that the changes in 
a4be2bcee2f were substantial so this commit works off the result of the 
previous.  So really it would be "Depends on: " rather than "Fixes: ".


Right this cleans up after the following commit - please include the tag.
Don't bother re-sending.

Not sure how I would go about that since I don't have push access.  The ML is 
really the only mechanism I have to send commits to the git repo.  Given that 
I've been submitting patches from time to time for the past two years or so 
(not often, but every few months I have a handful), should I go ahead and apply 
for an account now?

Chuck,

Don’t worry about it, I will check in this change, and include the tag while 
checking in.  I’ll do that after I finish my testing.  You can, of course, 
apply for an account; that’s completely orthogonal.

Which bring up the question, Emil, when does the branch happen?  I haven’t seen 
any new branches/tags in mesa/master.

Thanks,

George

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

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

Re: [Mesa-dev] [PATCH v3 06/24] anv/image: Add a helper for determining when fast clears are supported

[Nanley Chery]

On Mon, Jan 22, 2018 at 12:19:33AM -0800, Jason Ekstrand wrote:
> v2 (Jason Ekstrand):
>  - Return an enum instead of a boolean
> 
> v3 (Jason Ekstrand):
>  - Return ANV_FAST_CLEAR_NONE instead of false (Topi)
>  - Rename ANV_FAST_CLEAR_ANY to ANV_FAST_CLEAR_DEFAULT_VALUE
>  - Add documentation for the enum values
> 
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/intel/vulkan/anv_image.c   | 71 
> ++
>  src/intel/vulkan/anv_private.h | 16 ++
>  2 files changed, 87 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index 0aa8cd9..4cd4fe1 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -861,6 +861,77 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
> const devinfo,
> unreachable("layout is not a VkImageLayout enumeration member.");
>  }
>  
> +/**
> + * This function returns the level of unresolved fast-clear support of the
> + * given image in the given VkImageLayout.
> + *
> + * @param devinfo The device information of the Intel GPU.
> + * @param image The image that may contain a collection of buffers.
> + * @param aspect The aspect of the image to be accessed.
> + * @param layout The current layout of the image aspect(s).
> + */
> +enum anv_fast_clear_type
> +anv_layout_to_fast_clear_type(const struct gen_device_info * const devinfo,
> +  const struct anv_image * const image,
> +  const VkImageAspectFlagBits aspect,
> +  const VkImageLayout layout)
> +{
> +   /* The aspect must be exactly one of the image aspects. */
> +   assert(_mesa_bitcount(aspect) == 1 && (aspect & image->aspects));
> +
> +   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> +
> +   /* If there is no auxiliary surface allocated, there are no fast-clears */
> +   if (image->planes[plane].aux_surface.isl.size == 0)
> +  return ANV_FAST_CLEAR_NONE;
> +
> +   /* All images that use an auxiliary surface are required to be tiled. */
> +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> +
> +   /* Stencil has no aux */
> +   assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
> +
> +   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
> +  /* For depth images (with HiZ), the layout supports fast-clears if and
> +   * only if it supports HiZ.  However, we only support fast-clears to 
> the
> +   * default depth value.
> +   */
> +  enum isl_aux_usage aux_usage =
> + anv_layout_to_aux_usage(devinfo, image, aspect, layout);
> +  return aux_usage == ISL_AUX_USAGE_HIZ ?
> + ANV_FAST_CLEAR_DEFAULT_VALUE : ANV_FAST_CLEAR_NONE;
> +   }
> +
> +   assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> +
> +   /* Multisample fast-clear is not yet supported. */
> +   if (image->samples > 1)
> +  return ANV_FAST_CLEAR_NONE;
> +
> +   /* The only layout which actually supports fast-clears today is
> +* VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.  Some day in the future
> +* this may change if our ability to track clear colors improves.
> +*/

With this comment removed, this patch is
Reviewed-by: Nanley Chery 

> +   switch (layout) {
> +   case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
> +  return ANV_FAST_CLEAR_ANY;
> +
> +   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
> +  return ANV_FAST_CLEAR_NONE;
> +
> +   default:
> +  /* If the image has CCS_E enabled all the time then we can use
> +   * fast-clear as long as the clear color is the default value of zero
> +   * since this is the default value we program into every surface state
> +   * used for texturing.
> +   */
> +  if (image->planes[plane].aux_usage == ISL_AUX_USAGE_CCS_E)
> + return ANV_FAST_CLEAR_DEFAULT_VALUE;
> +  else
> + return ANV_FAST_CLEAR_NONE;
> +   }
> +}
> +
>  
>  static struct anv_state
>  alloc_surface_state(struct anv_device *device)
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index cf82196..b96895b 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2423,6 +2423,16 @@ struct anv_image {
> } planes[3];
>  };
>  
> +/* The ordering of this enum is important */
> +enum anv_fast_clear_type {
> +   /** Image does not have/support any fast-clear blocks */
> +   ANV_FAST_CLEAR_NONE = 0,
> +   /** Image has/supports fast-clear but only to the default value */
> +   ANV_FAST_CLEAR_DEFAULT_VALUE = 1,
> +   /** Image has/supports fast-clear with an arbitrary fast-clear value */
> +   ANV_FAST_CLEAR_ANY = 2,
> +};
> +
>  /* Returns the number of auxiliary buffer levels attached to an image. */
>  static inline uint8_t
>  anv_image_aux_levels(const struct anv_image * const image,
> @@ -2545,6 +2555,12 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
> const devinfo,
>  const 

Re: [Mesa-dev] [PATCH v2 11/24] anv/blorp: Add src/dst_level helper variables in CmdCopyImage

[Nanley Chery]

On Fri, Jan 19, 2018 at 03:47:28PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/anv_blorp.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index ccb9d18..e4e4135 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -247,6 +247,7 @@ void anv_CmdCopyImage(
>VkExtent3D extent =
>   anv_sanitize_image_extent(src_image->type, pRegions[r].extent);
>  
> +  const uint32_t dst_level = pRegions[r].dstSubresource.mipLevel;
>unsigned dst_base_layer, layer_count;
>if (dst_image->type == VK_IMAGE_TYPE_3D) {
>   dst_base_layer = pRegions[r].dstOffset.z;
> @@ -257,6 +258,7 @@ void anv_CmdCopyImage(
>  anv_get_layerCount(dst_image, [r].dstSubresource);
>}
>  
> +  const uint32_t src_level = pRegions[r].srcSubresource.mipLevel;
>unsigned src_base_layer;
>if (src_image->type == VK_IMAGE_TYPE_3D) {
>   src_base_layer = pRegions[r].srcOffset.z;
> @@ -283,10 +285,8 @@ void anv_CmdCopyImage(
>   ANV_AUX_USAGE_DEFAULT, _surf);
>  
>  for (unsigned i = 0; i < layer_count; i++) {
> -   blorp_copy(, _surf, 
> pRegions[r].srcSubresource.mipLevel,
> -  src_base_layer + i,
> -  _surf, pRegions[r].dstSubresource.mipLevel,
> -  dst_base_layer + i,
> +   blorp_copy(, _surf, src_level, src_base_layer + i,
> +  _surf, dst_level, dst_base_layer + i,
>srcOffset.x, srcOffset.y,
>dstOffset.x, dstOffset.y,
>extent.width, extent.height);
> @@ -300,10 +300,8 @@ void anv_CmdCopyImage(
>ANV_AUX_USAGE_DEFAULT, _surf);
>  
>   for (unsigned i = 0; i < layer_count; i++) {
> -blorp_copy(, _surf, 
> pRegions[r].srcSubresource.mipLevel,
> -   src_base_layer + i,
> -   _surf, pRegions[r].dstSubresource.mipLevel,
> -   dst_base_layer + i,
> +blorp_copy(, _surf, src_level, src_base_layer + i,
> +   _surf, dst_level, dst_base_layer + i,
> srcOffset.x, srcOffset.y,
> dstOffset.x, dstOffset.y,
> extent.width, extent.height);
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 06/24] anv/image: Add a helper for determining when fast clears are supported

[Nanley Chery]

On Mon, Jan 22, 2018 at 11:03:07AM -0800, Jason Ekstrand wrote:
> On Mon, Jan 22, 2018 at 10:48 AM, Nanley Chery 
> wrote:
> 
> > On Fri, Jan 19, 2018 at 03:47:23PM -0800, Jason Ekstrand wrote:
> > > v2 (Jason Ekstrand):
> > >  - Return an enum instead of a boolean
> > >
> > > Reviewed-by: Topi Pohjolainen 
> > > ---
> > >  src/intel/vulkan/anv_image.c   | 70 ++
> > 
> > >  src/intel/vulkan/anv_private.h | 13 
> > >  2 files changed, 83 insertions(+)
> > >
> > > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> > > index 1218c00..84e4b96 100644
> > > --- a/src/intel/vulkan/anv_image.c
> > > +++ b/src/intel/vulkan/anv_image.c
> > > @@ -863,6 +863,76 @@ anv_layout_to_aux_usage(const struct
> > gen_device_info * const devinfo,
> > > unreachable("layout is not a VkImageLayout enumeration member.");
> > >  }
> > >
> > > +/**
> > > + * This function returns the level of unresolved fast-clear support of
> > the
> > > + * given image in the given VkImageLayout.
> > > + *
> > > + * @param devinfo The device information of the Intel GPU.
> > > + * @param image The image that may contain a collection of buffers.
> > > + * @param aspect The aspect of the image to be accessed.
> > > + * @param layout The current layout of the image aspect(s).
> > > + */
> > > +enum anv_fast_clear_type
> > > +anv_layout_to_fast_clear_type(const struct gen_device_info * const
> > devinfo,
> > > +  const struct anv_image * const image,
> > > +  const VkImageAspectFlagBits aspect,
> > > +  const VkImageLayout layout)
> > > +{
> > > +   /* The aspect must be exactly one of the image aspects. */
> > > +   assert(_mesa_bitcount(aspect) == 1 && (aspect & image->aspects));
> > > +
> > > +   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> > > +
> > > +   /* If there is no auxiliary surface allocated, there are no
> > fast-clears */
> > > +   if (image->planes[plane].aux_surface.isl.size == 0)
> > > +  return false;
> > > +
> > > +   /* All images that use an auxiliary surface are required to be
> > tiled. */
> > > +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> > > +
> > > +   /* Stencil has no aux */
> > > +   assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
> > > +
> > > +   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
> > > +  /* For depth images (with HiZ), the layout supports fast-clears
> > if and
> > > +   * only if it supports HiZ.
> > > +   */
> > > +  enum isl_aux_usage aux_usage =
> > > + anv_layout_to_aux_usage(devinfo, image, aspect, layout);
> > > +  return aux_usage == ISL_AUX_USAGE_HIZ ?
> > > + ANV_FAST_CLEAR_ANY : ANV_FAST_CLEAR_NONE;
> > > +   }
> > > +
> > > +   assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> > > +
> > > +   /* Multisample fast-clear is not yet supported. */
> > > +   if (image->samples > 1)
> > > +  return false;
> > > +
> > > +   /* The only layout which actually supports fast-clears today is
> > > +* VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.  Some day in the future
> > > +* this may change if our ability to track clear colors improves.
> > > +*/
> >
> > Stale comment.
> >
> 
> Removed locally.  I think the switch and the one comment below are probably
> documentation enough.
> 
> --Jason
> 
> 

Agreed. 

-Nanley

> > -Nanley
> >
> > > +   switch (layout) {
> > > +   case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
> > > +  return ANV_FAST_CLEAR_ANY;
> > > +
> > > +   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
> > > +  return ANV_FAST_CLEAR_NONE;
> > > +
> > > +   default:
> > > +  /* If the image has CCS_E enabled all the time then we can use
> > > +   * fast-clear as long as the clear color is zero since this is the
> > > +   * default value we program into every surface state used for
> > > +   * texturing.
> > > +   */
> > > +  if (image->planes[plane].aux_usage == ISL_AUX_USAGE_CCS_E)
> > > + return ANV_FAST_CLEAR_ZERO_ONLY;
> > > +  else
> > > + return ANV_FAST_CLEAR_NONE;
> > > +   }
> > > +}
> > > +
> > >
> > >  static struct anv_state
> > >  alloc_surface_state(struct anv_device *device)
> > > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > private.h
> > > index a837860..f81f8e1 100644
> > > --- a/src/intel/vulkan/anv_private.h
> > > +++ b/src/intel/vulkan/anv_private.h
> > > @@ -2443,6 +2443,13 @@ struct anv_image {
> > > } planes[3];
> > >  };
> > >
> > > +/* The ordering of this enum is important */
> > > +enum anv_fast_clear_type {
> > > +   ANV_FAST_CLEAR_NONE = 0,
> > > +   ANV_FAST_CLEAR_ZERO_ONLY = 1,
> > > +   ANV_FAST_CLEAR_ANY = 2,
> > > +};
> > > +
> > >  /* Returns the number of auxiliary buffer levels attached to an image.
> > */
> > >  static inline uint8_t
> > >  anv_image_aux_levels(const struct 

Re: [Mesa-dev] [PATCH v2 09/24] anv/cmd_buffer: Generalize transition_color_buffer

[Nanley Chery]

On Fri, Jan 19, 2018 at 03:47:26PM -0800, Jason Ekstrand wrote:
> This moves it to being based on layout_to_aux_usage instead of being
> hard-coded based on bits of a priori knowledge of how transitions
> interact with layouts.  This conceptually simplifies things because
> we're now using layout_to_aux_usage and layout_supports_fast_clear to
> make resolve decisions so changes to those functions will do what one
> expects.
> 
> This fixes a potential bug with window system integration on gen9+ where
^
This patch still doesn't fix the bug.

> we wouldn't do a resolve when transitioning to the PRESENT_SRC layout
> because we just assume that everything that handles CCS_E can handle it
> all the time.  When handing a CCS_E image off to the window system, we
> may need to do a full resolve if the window system does not support the
> CCS_E modifier.  The only reason why this hasn't been a problem yet is
> because we don't support modifiers in Vulkan WSI and so we always get X
> tiling which implies no CCS on gen9+.
> 
> v2 (Jason Ekstrand):
>  - Make a few more things const
>  - Use the anv_fast_clear_support enum
> 
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 56 
> ++
>  1 file changed, 44 insertions(+), 12 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 6a6d8b2..fd27463 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -593,6 +593,7 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
>  VkImageLayout initial_layout,
>  VkImageLayout final_layout)
>  {
> +   const struct gen_device_info *devinfo = _buffer->device->info;
> /* Validate the inputs. */
> assert(cmd_buffer);
> assert(image && image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> @@ -733,17 +734,51 @@ transition_color_buffer(struct anv_cmd_buffer 
> *cmd_buffer,
>   VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
>   final_layout);
>}
> -   } else if (initial_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) {
> -  /* Resolves are only necessary if the subresource may contain blocks
> -   * fast-cleared to values unsupported in other layouts. This only 
> occurs
> -   * if the initial layout is COLOR_ATTACHMENT_OPTIMAL.
> -   */
> -  return;
> -   } else if (image->samples > 1) {
> -  /* MCS buffers don't need resolving. */
>return;
> }
>  
> +   /* If initial aux usage is NONE, there is nothing to resolve */
> +   const enum isl_aux_usage initial_aux_usage =
> +  anv_layout_to_aux_usage(devinfo, image, aspect, initial_layout);
> +   if (initial_aux_usage == ISL_AUX_USAGE_NONE)
> +  return;
> +
> +   enum isl_aux_op resolve_op = ISL_AUX_OP_NONE;
> +
> +   /* If the initial layout supports more fast clear than the final layout
> +* then we need at least a partial resolve.
> +*/
> +   const enum anv_fast_clear_type initial_fast_clear =
> +  anv_layout_to_fast_clear_type(devinfo, image, aspect, initial_layout);
> +   const enum anv_fast_clear_type final_fast_clear =
> +  anv_layout_to_fast_clear_type(devinfo, image, aspect, final_layout);
> +   if (final_fast_clear < initial_fast_clear)
> +  resolve_op = ISL_AUX_OP_PARTIAL_RESOLVE;
> +
> +   const enum isl_aux_usage final_aux_usage =
> +  anv_layout_to_aux_usage(devinfo, image, aspect, final_layout);
> +   if (initial_aux_usage == ISL_AUX_USAGE_CCS_E &&
> +   final_aux_usage != ISL_AUX_USAGE_CCS_E)
> +  resolve_op = ISL_AUX_OP_FULL_RESOLVE;
> +
> +   /* CCS_D only supports full resolves and BLORP will assert on us if we try
> +* to do a partial resolve on a CCS_D surface.
> +*/
> +   if (resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE &&
> +   initial_aux_usage == ISL_AUX_USAGE_CCS_D)
> +  resolve_op = ISL_AUX_OP_FULL_RESOLVE;
> +
> +   if (resolve_op == ISL_AUX_OP_NONE)
> +  return;
> +
> +   /* Even though the above code can theoretically handle multiple resolve
> +* types such as CCS_D -> CCS_E, the predication code below can't.  We 
> only
> +* really handle a couple of cases.
> +*/
> +   assert(initial_aux_usage == ISL_AUX_USAGE_NONE ||
> +  final_aux_usage == ISL_AUX_USAGE_NONE ||
> +  initial_aux_usage == final_aux_usage);
> +

I'm finding this assertion and comment confusing. The comment says that
the predication code below can't handle CCS_D -> CCS_E (which requires a
no-op resolve), but the assertion below it allows initial_aux_usage to
be NONE (which would lead to a no-op resolve), and initial_aux_usage ==
final_aux_usage which (may lead to a no-op resolve).

As far as I can tell, the only problematic case this assertion would catch 
is a CCS_E -> CCS_D transition. This transition requires a FULL_RESOLVE. If
the CCS_E 

Re: [Mesa-dev] [PATCH v2 06/24] anv/image: Add a helper for determining when fast clears are supported

[Jason Ekstrand]

On Mon, Jan 22, 2018 at 10:48 AM, Nanley Chery 
wrote:

> On Fri, Jan 19, 2018 at 03:47:23PM -0800, Jason Ekstrand wrote:
> > v2 (Jason Ekstrand):
> >  - Return an enum instead of a boolean
> >
> > Reviewed-by: Topi Pohjolainen 
> > ---
> >  src/intel/vulkan/anv_image.c   | 70 ++
> 
> >  src/intel/vulkan/anv_private.h | 13 
> >  2 files changed, 83 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> > index 1218c00..84e4b96 100644
> > --- a/src/intel/vulkan/anv_image.c
> > +++ b/src/intel/vulkan/anv_image.c
> > @@ -863,6 +863,76 @@ anv_layout_to_aux_usage(const struct
> gen_device_info * const devinfo,
> > unreachable("layout is not a VkImageLayout enumeration member.");
> >  }
> >
> > +/**
> > + * This function returns the level of unresolved fast-clear support of
> the
> > + * given image in the given VkImageLayout.
> > + *
> > + * @param devinfo The device information of the Intel GPU.
> > + * @param image The image that may contain a collection of buffers.
> > + * @param aspect The aspect of the image to be accessed.
> > + * @param layout The current layout of the image aspect(s).
> > + */
> > +enum anv_fast_clear_type
> > +anv_layout_to_fast_clear_type(const struct gen_device_info * const
> devinfo,
> > +  const struct anv_image * const image,
> > +  const VkImageAspectFlagBits aspect,
> > +  const VkImageLayout layout)
> > +{
> > +   /* The aspect must be exactly one of the image aspects. */
> > +   assert(_mesa_bitcount(aspect) == 1 && (aspect & image->aspects));
> > +
> > +   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> > +
> > +   /* If there is no auxiliary surface allocated, there are no
> fast-clears */
> > +   if (image->planes[plane].aux_surface.isl.size == 0)
> > +  return false;
> > +
> > +   /* All images that use an auxiliary surface are required to be
> tiled. */
> > +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> > +
> > +   /* Stencil has no aux */
> > +   assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
> > +
> > +   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
> > +  /* For depth images (with HiZ), the layout supports fast-clears
> if and
> > +   * only if it supports HiZ.
> > +   */
> > +  enum isl_aux_usage aux_usage =
> > + anv_layout_to_aux_usage(devinfo, image, aspect, layout);
> > +  return aux_usage == ISL_AUX_USAGE_HIZ ?
> > + ANV_FAST_CLEAR_ANY : ANV_FAST_CLEAR_NONE;
> > +   }
> > +
> > +   assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> > +
> > +   /* Multisample fast-clear is not yet supported. */
> > +   if (image->samples > 1)
> > +  return false;
> > +
> > +   /* The only layout which actually supports fast-clears today is
> > +* VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.  Some day in the future
> > +* this may change if our ability to track clear colors improves.
> > +*/
>
> Stale comment.
>

Removed locally.  I think the switch and the one comment below are probably
documentation enough.

--Jason


> -Nanley
>
> > +   switch (layout) {
> > +   case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
> > +  return ANV_FAST_CLEAR_ANY;
> > +
> > +   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
> > +  return ANV_FAST_CLEAR_NONE;
> > +
> > +   default:
> > +  /* If the image has CCS_E enabled all the time then we can use
> > +   * fast-clear as long as the clear color is zero since this is the
> > +   * default value we program into every surface state used for
> > +   * texturing.
> > +   */
> > +  if (image->planes[plane].aux_usage == ISL_AUX_USAGE_CCS_E)
> > + return ANV_FAST_CLEAR_ZERO_ONLY;
> > +  else
> > + return ANV_FAST_CLEAR_NONE;
> > +   }
> > +}
> > +
> >
> >  static struct anv_state
> >  alloc_surface_state(struct anv_device *device)
> > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> > index a837860..f81f8e1 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -2443,6 +2443,13 @@ struct anv_image {
> > } planes[3];
> >  };
> >
> > +/* The ordering of this enum is important */
> > +enum anv_fast_clear_type {
> > +   ANV_FAST_CLEAR_NONE = 0,
> > +   ANV_FAST_CLEAR_ZERO_ONLY = 1,
> > +   ANV_FAST_CLEAR_ANY = 2,
> > +};
> > +
> >  /* Returns the number of auxiliary buffer levels attached to an image.
> */
> >  static inline uint8_t
> >  anv_image_aux_levels(const struct anv_image * const image,
> > @@ -2565,6 +2572,12 @@ anv_layout_to_aux_usage(const struct
> gen_device_info * const devinfo,
> >  const VkImageAspectFlagBits aspect,
> >  const VkImageLayout layout);
> >
> > +enum anv_fast_clear_type
> > +anv_layout_to_fast_clear_type(const struct gen_device_info * const
> 

Re: [Mesa-dev] [PATCH v3 3/3] anv: implement VK_EXT_global_priority extension

[Jason Ekstrand]

On Mon, Jan 22, 2018 at 4:29 AM, Tapani Pälli 
wrote:

> v2: add ANV_CONTEXT_REALTIME_PRIORITY (Chris)
> use unreachable with unknown priority (Samuel)
>
> v3: add stubs in gem_stubs.c (Emil)
> use priority defines from gen_defines.h
>
> Signed-off-by: Tapani Pälli 
> Reviewed-by: Samuel Iglesias Gonsálvez  (v2)
> Reviewed-by: Chris Wilson  (v2)
> ---
>  src/intel/vulkan/anv_device.c  | 25 +++
>  src/intel/vulkan/anv_extensions.py |  2 ++
>  src/intel/vulkan/anv_gem.c | 51 ++
> 
>  src/intel/vulkan/anv_gem_stubs.c   | 10 
>  src/intel/vulkan/anv_private.h |  3 +++
>  5 files changed, 91 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 777abd8757..42ebc19f2b 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -369,6 +369,9 @@ anv_physical_device_init(struct anv_physical_device
> *device,
> device->has_syncobj_wait = device->has_syncobj &&
>anv_gem_supports_syncobj_wait(fd);
>
> +   if (anv_gem_has_context_priority(fd))
> +  device->has_context_priority = true;
> +
> bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
>
> /* Starting with Gen10, the timestamp frequency of the command
> streamer may
> @@ -1205,6 +1208,15 @@ VkResult anv_CreateDevice(
>}
> }
>
> +   /* Check if client specified queue priority. */
> +   const VkDeviceQueueGlobalPriorityCreateInfoEXT *queue_priority =
> +  vk_find_struct_const(pCreateInfo->pQueueCreateInfos[0].pNext,
> +   DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT);
> +
> +   VkQueueGlobalPriorityEXT priority =
> +  queue_priority ? queue_priority->globalPriority :
> + VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT;
> +
> device = vk_alloc2(_device->instance->alloc, pAllocator,
> sizeof(*device), 8,
> VK_SYSTEM_ALLOCATION_SCOPE_DEVICE);
> @@ -1234,6 +1246,19 @@ VkResult anv_CreateDevice(
>goto fail_fd;
> }
>
> +   /* As per spec, the driver implementation may deny requests to acquire
> +* a priority above the default priority (MEDIUM) if the caller does
> not
> +* have sufficient privileges. In this scenario
> VK_ERROR_NOT_PERMITTED_EXT
> +* is returned.
> +*/
> +   if (physical_device->has_context_priority) {
> +  int err = anv_gem_set_context_priority(device, priority);
> +  if (err != 0 && priority > VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT) {
> + result = vk_error(VK_ERROR_NOT_PERMITTED_EXT);
> + goto fail_fd;
> +  }
> +   }
> +
> device->info = physical_device->info;
> device->isl_dev = physical_device->isl_dev;
>
> diff --git a/src/intel/vulkan/anv_extensions.py b/src/intel/vulkan/anv_
> extensions.py
> index adfebca985..aacf39248f 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -86,6 +86,8 @@ EXTENSIONS = [
>  Extension('VK_KHX_multiview', 1, True),
>  Extension('VK_EXT_debug_report',  8, True),
>  Extension('VK_EXT_external_memory_dma_buf',   1, True),
> +Extension('VK_EXT_global_priority',   1,
> +  'device->has_context_priority'),
>  ]
>
>  class VkVersion:
> diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
> index 34c0989108..7f83820429 100644
> --- a/src/intel/vulkan/anv_gem.c
> +++ b/src/intel/vulkan/anv_gem.c
> @@ -30,6 +30,7 @@
>  #include 
>
>  #include "anv_private.h"
> +#include "common/gen_defines.h"
>
>  static int
>  anv_ioctl(int fd, unsigned long request, void *arg)
> @@ -302,6 +303,56 @@ close_and_return:
> return swizzled;
>  }
>
> +static int
> +vk_priority_to_anv(int priority)
> +{
> +   switch (priority) {
> +   case VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT:
> +  return GEN_CONTEXT_LOW_PRIORITY;
> +   case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT:
> +  return GEN_CONTEXT_MEDIUM_PRIORITY;
> +   case VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT:
> +  return GEN_CONTEXT_HIGH_PRIORITY;
> +   case VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT:
> +  return GEN_CONTEXT_REALTIME_PRIORITY;
> +   default:
> +  unreachable("Invalid priority");
> +   }
> +}
>

I think I'd rather have the conversion in anv_device.c and just make the
anv_gem functions take an i915 priority.

Other than that, and a couple other nits, this looks good to me.

One other question, do we have tests?  I quickly searched the piglit list
and didn't see any.  Writing a crucible test shouldn't be that hard.  You
just have to submit a bunch of command buffers and show that they get
re-ordered to favor the higher-priority context.  You could do that with a
bunch of compute shader invocations that "take a number" from a shared
atomic or something like that.

The 

Re: [Mesa-dev] [PATCH v2 06/24] anv/image: Add a helper for determining when fast clears are supported

[Nanley Chery]

On Fri, Jan 19, 2018 at 03:47:23PM -0800, Jason Ekstrand wrote:
> v2 (Jason Ekstrand):
>  - Return an enum instead of a boolean
> 
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/intel/vulkan/anv_image.c   | 70 
> ++
>  src/intel/vulkan/anv_private.h | 13 
>  2 files changed, 83 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index 1218c00..84e4b96 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -863,6 +863,76 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
> const devinfo,
> unreachable("layout is not a VkImageLayout enumeration member.");
>  }
>  
> +/**
> + * This function returns the level of unresolved fast-clear support of the
> + * given image in the given VkImageLayout.
> + *
> + * @param devinfo The device information of the Intel GPU.
> + * @param image The image that may contain a collection of buffers.
> + * @param aspect The aspect of the image to be accessed.
> + * @param layout The current layout of the image aspect(s).
> + */
> +enum anv_fast_clear_type
> +anv_layout_to_fast_clear_type(const struct gen_device_info * const devinfo,
> +  const struct anv_image * const image,
> +  const VkImageAspectFlagBits aspect,
> +  const VkImageLayout layout)
> +{
> +   /* The aspect must be exactly one of the image aspects. */
> +   assert(_mesa_bitcount(aspect) == 1 && (aspect & image->aspects));
> +
> +   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> +
> +   /* If there is no auxiliary surface allocated, there are no fast-clears */
> +   if (image->planes[plane].aux_surface.isl.size == 0)
> +  return false;
> +
> +   /* All images that use an auxiliary surface are required to be tiled. */
> +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> +
> +   /* Stencil has no aux */
> +   assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
> +
> +   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
> +  /* For depth images (with HiZ), the layout supports fast-clears if and
> +   * only if it supports HiZ.
> +   */
> +  enum isl_aux_usage aux_usage =
> + anv_layout_to_aux_usage(devinfo, image, aspect, layout);
> +  return aux_usage == ISL_AUX_USAGE_HIZ ?
> + ANV_FAST_CLEAR_ANY : ANV_FAST_CLEAR_NONE;
> +   }
> +
> +   assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> +
> +   /* Multisample fast-clear is not yet supported. */
> +   if (image->samples > 1)
> +  return false;
> +
> +   /* The only layout which actually supports fast-clears today is
> +* VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.  Some day in the future
> +* this may change if our ability to track clear colors improves.
> +*/

Stale comment.

-Nanley

> +   switch (layout) {
> +   case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
> +  return ANV_FAST_CLEAR_ANY;
> +
> +   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
> +  return ANV_FAST_CLEAR_NONE;
> +
> +   default:
> +  /* If the image has CCS_E enabled all the time then we can use
> +   * fast-clear as long as the clear color is zero since this is the
> +   * default value we program into every surface state used for
> +   * texturing.
> +   */
> +  if (image->planes[plane].aux_usage == ISL_AUX_USAGE_CCS_E)
> + return ANV_FAST_CLEAR_ZERO_ONLY;
> +  else
> + return ANV_FAST_CLEAR_NONE;
> +   }
> +}
> +
>  
>  static struct anv_state
>  alloc_surface_state(struct anv_device *device)
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index a837860..f81f8e1 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2443,6 +2443,13 @@ struct anv_image {
> } planes[3];
>  };
>  
> +/* The ordering of this enum is important */
> +enum anv_fast_clear_type {
> +   ANV_FAST_CLEAR_NONE = 0,
> +   ANV_FAST_CLEAR_ZERO_ONLY = 1,
> +   ANV_FAST_CLEAR_ANY = 2,
> +};
> +
>  /* Returns the number of auxiliary buffer levels attached to an image. */
>  static inline uint8_t
>  anv_image_aux_levels(const struct anv_image * const image,
> @@ -2565,6 +2572,12 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
> const devinfo,
>  const VkImageAspectFlagBits aspect,
>  const VkImageLayout layout);
>  
> +enum anv_fast_clear_type
> +anv_layout_to_fast_clear_type(const struct gen_device_info * const devinfo,
> +  const struct anv_image * const image,
> +  const VkImageAspectFlagBits aspect,
> +  const VkImageLayout layout);
> +
>  /* This is defined as a macro so that it works for both
>   * VkImageSubresourceRange and VkImageSubresourceLayers
>   */
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev 

Re: [Mesa-dev] [PATCH] i965: Drop render_target_start from binding table struct.

[Kenneth Graunke]

On Thursday, January 18, 2018 11:47:33 PM PST Iago Toral wrote:
> On Thu, 2018-01-18 at 15:49 -0800, Kenneth Graunke wrote:
> > We have to start render targets at binding table index 0 in order to
> > use
> > headerless FB write messages, and in fact already assume this in a
> > bunch
> > of places in the code.  Let's finish that off, and not bother storing
> > 0
> > in a struct to pretend to add it in a few places.
> > ---
> >  src/intel/blorp/blorp.c | 1 -
> >  src/intel/compiler/brw_compiler.h   | 1 -
> >  src/intel/compiler/brw_fs_generator.cpp | 6 ++
> >  src/mesa/drivers/dri/i965/brw_wm.c  | 1 -
> >  4 files changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> > index e8a2c6135f5..b7238306eb1 100644
> > --- a/src/intel/blorp/blorp.c
> > +++ b/src/intel/blorp/blorp.c
> > @@ -177,7 +177,6 @@ blorp_compile_fs(struct blorp_context *blorp,
> > void *mem_ctx,
> > wm_prog_data->base.param = NULL;
> >  
> > /* BLORP always just uses the first two binding table entries */
> > -   wm_prog_data->biable.render_target_start =
> > BLORP_RENDERBUFFER_BT_INDEX;
> > wm_prog_data->base.binding_table.texture_start =
> > BLORP_TEXTURE_BT_INDEX;
> 
> Since the comment says that blorp uses the first two entries but it
> then only assigns one, maybe it would be nice to update the comment
> above to state that we assume render targets start at binding table
> index 0.

Thanks, updated to:

   /* BLORP always uses the first two binding table entries:
* - Surface 0 is the render target (which always start from 0)
* - Surface 1 is the source texture
*/

> > nir = brw_preprocess
> > Wouldn't it be better to keep the assert? We still needs
> > render_target_start to be 0_nir(compiler, nir);
> > diff --git a/src/intel/compiler/brw_compiler.h
> > b/src/intel/compiler/brw_compiler.h
> > index 0060c381c0d..b1086bbcee5 100644
> > --- a/src/intel/compiler/brw_compiler.h
> > +++ b/src/intel/compiler/brw_compiler.h
> > @@ -681,7 +681,6 @@ struct brw_wm_prog_data {
> >/** @{
> > * surface indices the WM-specific surfaces
> > */
> > -  uint32_t render_target_start;
> >uint32_t render_target_read_start;
> >/** @} */
> > } binding_table;
> > diff --git a/src/intel/compiler/brw_fs_generator.cpp
> > b/src/intel/compiler/brw_fs_generator.cpp
> > index 91bf0643084..cd5be054f69 100644
> > --- a/src/intel/compiler/brw_fs_generator.cpp
> > +++ b/src/intel/compiler/brw_fs_generator.cpp
> > @@ -287,8 +287,6 @@ fs_generator::fire_fb_write(fs_inst *inst,
> >  * messages set "Render Target Index" to 0.  Using a different
> > binding
> >  * table index would make it impossible to use headerless
> > messages.
> >  */
> > -   assert(prog_data->binding_table.render_target_start == 0);
> > -
> > const uint32_t surf_index = inst->target;
> >  
> > bool last_render_target = inst->eot ||
> > @@ -427,8 +425,8 @@ fs_generator::generate_fb_read(fs_inst *inst,
> > struct brw_reg dst,
> >  {
> > assert(inst->size_written % REG_SIZE == 0);
> > struct brw_wm_prog_data *prog_data = brw_wm_prog_data(this-
> > >prog_data);
> > -   const unsigned surf_index =
> > -  prog_data->binding_table.render_target_start + inst->target;
> > +   /* We assume that render targets start at binding table index 0.
> > */
> > +   const unsigned surf_index = inst->target;
> >  
> > gen9_fb_READ(p, dst, payload, surf_index,
> >  inst->header_size, inst->size_written / REG_SIZE,
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
> > b/src/mesa/drivers/dri/i965/brw_wm.c
> > index 08bacebd571..755a76eec71 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm.c
> > @@ -51,7 +51,6 @@ assign_fs_binding_table_offsets(const struct
> > gen_device_info *devinfo,
> > /* If there are no color regions, we still perform an FB write to
> > a null
> >  * renderbuffer, which we place at surface index 0.
> >  */
> > -   prog_data->binding_table.render_target_start =
> > next_binding_table_offset;
> > next_binding_table_offset += MAX2(key->nr_color_regions, 1);
> 
> Since we are no longer assigning next_binding_table_offset with value
> of  0, we might as well drop the initialization to that value (or just
> initialize the variable directly to the value right after the line you
> remove here).
> 
> Either way:
> Reviewed-by: Iago Toral Quiroga 

Good call, updated to:

   /* Render targets implicitly start at surface index 0.  Even if there are
* no color regions, we still perform an FB write to a null render target,
* which will be surface 0.
*/
   uint32_t next_binding_table_offset = MAX2(key->nr_color_regions, 1);

and pushed:

To ssh://git.freedesktop.org/git/mesa/mesa
   a9bb067e27c..60f15477dad  master -> master



signature.asc
Description: This is a digitally signed message part.

Re: [Mesa-dev] [PATCH v2 04/24] anv/blorp: Rework HiZ ops to look like MCS and CCS

[Nanley Chery]

On Fri, Jan 19, 2018 at 03:47:21PM -0800, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/intel/vulkan/anv_blorp.c   | 38 
> ++
>  src/intel/vulkan/anv_private.h |  9 +
>  src/intel/vulkan/genX_cmd_buffer.c | 13 +++--
>  3 files changed, 34 insertions(+), 26 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 229d87e..ccb9d18 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1570,26 +1570,30 @@ anv_image_copy_to_shadow(struct anv_cmd_buffer 
> *cmd_buffer,
> blorp_batch_finish();
>  }
>  
> -void
> -anv_gen8_hiz_op_resolve(struct anv_cmd_buffer *cmd_buffer,
> -const struct anv_image *image,
> -enum blorp_hiz_op op)
> +static enum blorp_hiz_op
> +isl_to_blorp_hiz_op(enum isl_aux_op isl_op)
>  {
> -   assert(image);
> +   switch (isl_op) {
> +   case ISL_AUX_OP_FAST_CLEAR:   return BLORP_HIZ_OP_DEPTH_CLEAR;
> +   case ISL_AUX_OP_FULL_RESOLVE: return BLORP_HIZ_OP_DEPTH_RESOLVE;
> +   case ISL_AUX_OP_AMBIGUATE:return BLORP_HIZ_OP_HIZ_RESOLVE;
> +   default:
> +  unreachable("Unsupported HiZ aux op");
> +   }
> +}
>  
> +void
> +anv_image_hiz_op(struct anv_cmd_buffer *cmd_buffer,
> + const struct anv_image *image,
> + VkImageAspectFlagBits aspect, uint32_t level,
> + uint32_t base_layer, uint32_t layer_count,
> + enum isl_aux_op hiz_op)
> +{
> +   assert(aspect == VK_IMAGE_ASPECT_DEPTH_BIT);
> +   assert(base_layer + layer_count <= anv_image_aux_layers(image, aspect, 
> level));
> assert(anv_image_aspect_to_plane(image->aspects,
>  VK_IMAGE_ASPECT_DEPTH_BIT) == 0);
>  
> -   /* Don't resolve depth buffers without an auxiliary HiZ buffer and
> -* don't perform such a resolve on gens that don't support it.
> -*/
> -   if (cmd_buffer->device->info.gen < 8 ||
> -   image->planes[0].aux_usage != ISL_AUX_USAGE_HIZ)
> -  return;
> -
> -   assert(op == BLORP_HIZ_OP_HIZ_RESOLVE ||
> -  op == BLORP_HIZ_OP_DEPTH_RESOLVE);
> -
> struct blorp_batch batch;
> blorp_batch_init(_buffer->device->blorp, , cmd_buffer, 0);
>  
> @@ -1599,7 +1603,9 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer 
> *cmd_buffer,
>  ISL_AUX_USAGE_HIZ, );
> surf.clear_color.f32[0] = ANV_HZ_FC_VAL;
>  
> -   blorp_hiz_op(, , 0, 0, 1, op);
> +   blorp_hiz_op(, , level, base_layer, layer_count,
> +isl_to_blorp_hiz_op(hiz_op));
> +
> blorp_batch_finish();
>  }
>  
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index f93c114..a837860 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2535,10 +2535,11 @@ anv_can_sample_with_hiz(const struct gen_device_info 
> * const devinfo,
>  }
>  
>  void
> -anv_gen8_hiz_op_resolve(struct anv_cmd_buffer *cmd_buffer,
> -const struct anv_image *image,
> -enum blorp_hiz_op op);
> -
> +anv_image_hiz_op(struct anv_cmd_buffer *cmd_buffer,
> + const struct anv_image *image,
> + VkImageAspectFlagBits aspect, uint32_t level,
> + uint32_t base_layer, uint32_t layer_count,
> + enum isl_aux_op hiz_op);
>  void
>  anv_image_mcs_op(struct anv_cmd_buffer *cmd_buffer,
>   const struct anv_image *image,
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 939f3fa..be263f8 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -388,19 +388,20 @@ transition_depth_buffer(struct anv_cmd_buffer 
> *cmd_buffer,
>anv_layout_to_aux_usage(_buffer->device->info, image,
>VK_IMAGE_ASPECT_DEPTH_BIT, final_layout);
>  
> -   enum blorp_hiz_op hiz_op;
> +   enum isl_aux_op hiz_op;
> if (hiz_enabled && !enable_hiz) {
> -  hiz_op = BLORP_HIZ_OP_DEPTH_RESOLVE;
> +  hiz_op = ISL_AUX_OP_FULL_RESOLVE;
> } else if (!hiz_enabled && enable_hiz) {
> -  hiz_op = BLORP_HIZ_OP_HIZ_RESOLVE;
> +  hiz_op = ISL_AUX_OP_AMBIGUATE;
> } else {
>assert(hiz_enabled == enable_hiz);
>/* If the same buffer will be used, no resolves are necessary. */
> -  hiz_op = BLORP_HIZ_OP_NONE;
> +  hiz_op = ISL_AUX_OP_NONE;
> }
>  
> -   if (hiz_op != BLORP_HIZ_OP_NONE)
> -  anv_gen8_hiz_op_resolve(cmd_buffer, image, hiz_op);
> +   if (hiz_op != ISL_AUX_OP_NONE)
> +  anv_image_hiz_op(cmd_buffer, image, VK_IMAGE_ASPECT_DEPTH_BIT,
> +   0, 0, 1, hiz_op);
>  }
>  
>  #define MI_PREDICATE_SRC0  0x2400
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 

Re: [Mesa-dev] [PATCH 1/2] i965/bufmgr: Add a create_from_prime_tiled function

[Kristian Høgsberg]

On Sun, Jan 21, 2018 at 8:05 PM, Jason Ekstrand  wrote:
> This new function is an import and a set tiling in one go.
> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c | 41 
> ++
>  src/mesa/drivers/dri/i965/brw_bufmgr.h |  4 
>  2 files changed, 36 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 469895e..889350c 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -1133,8 +1133,9 @@ brw_bo_get_tiling(struct brw_bo *bo, uint32_t 
> *tiling_mode,
> return 0;
>  }
>
> -struct brw_bo *
> -brw_bo_gem_create_from_prime(struct brw_bufmgr *bufmgr, int prime_fd)
> +static struct brw_bo *
> +brw_bo_gem_create_from_prime_internal(struct brw_bufmgr *bufmgr, int 
> prime_fd,
> +  int tiling_mode, uint32_t stride)
>  {
> int ret;
> uint32_t handle;
> @@ -1185,14 +1186,18 @@ brw_bo_gem_create_from_prime(struct brw_bufmgr 
> *bufmgr, int prime_fd)
> bo->reusable = false;
> bo->external = true;
>
> -   memclear(get_tiling);
> -   get_tiling.handle = bo->gem_handle;
> -   if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_GET_TILING, _tiling))
> -  goto err;
> +   if (tiling_mode < 0) {
> +  memclear(get_tiling);
> +  get_tiling.handle = bo->gem_handle;
> +  if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_GET_TILING, _tiling))
> + goto err;
>
> -   bo->tiling_mode = get_tiling.tiling_mode;
> -   bo->swizzle_mode = get_tiling.swizzle_mode;
> -   /* XXX stride is unknown */
> +  bo->tiling_mode = get_tiling.tiling_mode;
> +  bo->swizzle_mode = get_tiling.swizzle_mode;
> +  /* XXX stride is unknown */
> +   } else {
> +  bo_set_tiling_internal(bo, tiling_mode, stride);
> +   }

Since most of this logic is specific to the tiling == -1 case, maybe
move the get_tiling path to brw_bo_gem_create_from_prime(). Either
move bo_set_tiling() to brw_bo_gem_create_from_prime_tiled() or call
it from here when stride > 0.

Either way,

Reviewed-by: Kristian H. Kristensen 

>
>  out:
> mtx_unlock(>lock);
> @@ -1204,6 +1209,24 @@ err:
> return NULL;
>  }
>
> +struct brw_bo *
> +brw_bo_gem_create_from_prime(struct brw_bufmgr *bufmgr, int prime_fd)
> +{
> +   return brw_bo_gem_create_from_prime_internal(bufmgr, prime_fd, -1, 0);
> +}
> +
> +struct brw_bo *
> +brw_bo_gem_create_from_prime_tiled(struct brw_bufmgr *bufmgr, int prime_fd,
> +   uint32_t tiling_mode, uint32_t stride)
> +{
> +   assert(tiling_mode == I915_TILING_NONE ||
> +  tiling_mode == I915_TILING_X ||
> +  tiling_mode == I915_TILING_Y);
> +
> +   return brw_bo_gem_create_from_prime_internal(bufmgr, prime_fd,
> +tiling_mode, stride);
> +}
> +
>  static void
>  brw_bo_make_external(struct brw_bo *bo)
>  {
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> index 8bfb0e4..6811e78 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> @@ -339,6 +339,10 @@ void brw_destroy_hw_context(struct brw_bufmgr *bufmgr, 
> uint32_t ctx_id);
>  int brw_bo_gem_export_to_prime(struct brw_bo *bo, int *prime_fd);
>  struct brw_bo *brw_bo_gem_create_from_prime(struct brw_bufmgr *bufmgr,
>  int prime_fd);
> +struct brw_bo *brw_bo_gem_create_from_prime_tiled(struct brw_bufmgr *bufmgr,
> +  int prime_fd,
> +  uint32_t tiling_mode,
> +  uint32_t stride);
>
>  uint32_t brw_bo_export_gem_handle(struct brw_bo *bo);
>
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 2/2] i965: Set tiling on BOs imported with modifiers

[Kristian Høgsberg]

On Mon, Jan 22, 2018 at 10:03 AM, Jason Ekstrand  wrote:
> On January 22, 2018 09:10:52 Kristian Høgsberg  wrote:
>
>> On Sun, Jan 21, 2018 at 8:05 PM, Jason Ekstrand 
>> wrote:
>>>
>>> We need this to ensure that GTT maps work on buffers we get from Vulkan
>>> on the off chance that someone does a readpixels or something.  Soon, we
>>> will be removing GTT maps from i965 entirely and this can be reverted.
>>> None the less, it's needed for stable.
>>>
>>> Cc: mesa-sta...@lists.freedesktop.org
>>> Cc: Kenneth Graunke 
>>> ---
>>>  src/mesa/drivers/dri/i965/intel_screen.c | 11 ++-
>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>>> b/src/mesa/drivers/dri/i965/intel_screen.c
>>> index b563bbf..e877f93 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>>> @@ -1043,7 +1043,16 @@ intel_create_image_from_fds_common(__DRIscreen
>>> *dri_screen,
>>>
>>> image->planar_format = f;
>>>
>>> -   image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
>>> +   if (modifier != DRM_FORMAT_MOD_INVALID) {
>>> +  const struct isl_drm_modifier_info *mod_info =
>>> + isl_drm_modifier_get_info(modifier);
>>
>>
>> You need to handle mod_info == NULL for unknown modifiers.
>
>
> The code above this checks that the modifier is supported and bails if it
> isn't.

So it does. Looking forward to our bright future without gtt maps. In
the interim, thanks for fixing this.

Reviewed-by: Kristian H. Kristensen 

Kristian

>
>
>> Kristian
>>
>>> +  uint32_t tiling = isl_tiling_to_i915_tiling(mod_info->tiling);
>>> +  image->bo = brw_bo_gem_create_from_prime_tiled(screen->bufmgr,
>>> fds[0],
>>> + tiling,
>>> strides[0]);
>>> +   } else {
>>> +  image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
>>> +   }
>>> +
>>> if (image->bo == NULL) {
>>>free(image);
>>>return NULL;
>>> --
>>> 2.5.0.400.gff86faf
>>>
>>> ___
>>> 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 2/2] i965: Set tiling on BOs imported with modifiers

[Jason Ekstrand]

On January 22, 2018 09:10:52 Kristian Høgsberg  wrote:


On Sun, Jan 21, 2018 at 8:05 PM, Jason Ekstrand  wrote:

We need this to ensure that GTT maps work on buffers we get from Vulkan
on the off chance that someone does a readpixels or something.  Soon, we
will be removing GTT maps from i965 entirely and this can be reverted.
None the less, it's needed for stable.

Cc: mesa-sta...@lists.freedesktop.org
Cc: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c

index b563bbf..e877f93 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1043,7 +1043,16 @@ intel_create_image_from_fds_common(__DRIscreen 
*dri_screen,


image->planar_format = f;

-   image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
+   if (modifier != DRM_FORMAT_MOD_INVALID) {
+  const struct isl_drm_modifier_info *mod_info =
+ isl_drm_modifier_get_info(modifier);


You need to handle mod_info == NULL for unknown modifiers.


The code above this checks that the modifier is supported and bails if it 
isn't.



Kristian


+  uint32_t tiling = isl_tiling_to_i915_tiling(mod_info->tiling);
+  image->bo = brw_bo_gem_create_from_prime_tiled(screen->bufmgr, fds[0],
+ tiling, strides[0]);
+   } else {
+  image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
+   }
+
if (image->bo == NULL) {
   free(image);
   return NULL;
--
2.5.0.400.gff86faf

___
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] swr: refactor swr_create_screen to allow for proper cleanup on error

[Chuck Atkins]

Hi Emil,

Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")
>

It doesn't fix anything that was broken from that commit.  The issues with
error handling were already present before then, it's just that the changes
in a4be2bcee2f were substantial so this commit works off the result of the
previous.  So really it would be "Depends on: " rather than "Fixes: ".



> Right this cleans up after the following commit - please include the tag.
> Don't bother re-sending.
>

Not sure how I would go about that since I don't have push access.  The ML
is really the only mechanism I have to send commits to the git repo.  Given
that I've been submitting patches from time to time for the past two years
or so (not often, but every few months I have a handful), should I go ahead
and apply for an account now?

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

[Mesa-dev] [Bug 104732] [radv] Binding descriptor sets disturbs other pipeline bindings

[bugzilla-daemon]

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

Bug ID: 104732
   Summary: [radv] Binding descriptor sets disturbs other pipeline
bindings
   Product: Mesa
   Version: git
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: joseph.ku...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Binding descriptors sets for the compute pipeline should not disturb bindings
for the graphics pipeline and vice versa.

The Vulkan spec states:
"pipelineBindPoint is a VkPipelineBindPoint indicating whether the descriptors
will be used by graphics pipelines or compute pipelines. There is a separate
set of bind points for each of graphics and compute, so binding one does not
disturb the other."

Test case:
https://cgit.freedesktop.org/mesa/crucible/commit/?id=0a52673d71b444df81828d75138377b082855d03

How to reproduce: ./bin/crucible run func.bind-points

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

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Emil Velikov]

On 22 January 2018 at 17:03, Chuck Atkins  wrote:
> Hi Emil,
>
>> Please include your follow-up reply/context as commit message.
>
>
> Will do.
>
>
>> > +// cleanup for failed screen creation
>> > +PUBLIC void swr_destroy_screen_internal(struct swr_screen **screen);
>>
>> I'm fairly sure you don't need to make this function public. It's used
>> within the same binary - libmesaswr.la. Regardless if built-in or
>> separate DSO's are used.
>
>
> You are, of course, correct.  I was conflating static with not public and
> thinking that since it's not in the same translation unit then it can't be
> static so it must be public, which is certainly not the case.
>
Hmm not your fault really - swr_create_screen_internal should have
lost it's PUBLIC notation.
Will send a patch for it in a moment.

>
>> With the above two suggestions:
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>
>
> I purposely left this out of mesa-stable since it requires the previous two
> commits that initially refactored swr_create_screen to allow for builtin
> arch, which were not part of stable.
>
Right this cleans up after the following commit - please include the tag.
Don't bother re-sending.

Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")

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

[Mesa-dev] [PATCH] swr: don't export swr_create_screen_internal

[Emil Velikov]

From: Emil Velikov 

With earlier rework the user and provider of the symbol are within the
same binary. Thus there's no point in exporting the function.

Spotted while reviewing patch from Chuck, that nearly added another
unneeded PUBLIC function.

Cc: Chuck Atkins 
Cc: Tim Rowley 
Fixes: f50aa21456d "(swr: build driver proper separate from rasterizer")
Signed-off-by: Emil Velikov 
---
The comment might need updating as well, although I'm short on
suggestions.
---
 src/gallium/drivers/swr/swr_public.h   | 2 +-
 src/gallium/drivers/swr/swr_screen.cpp | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_public.h 
b/src/gallium/drivers/swr/swr_public.h
index 4b150705cd7..cb205479a91 100644
--- a/src/gallium/drivers/swr/swr_public.h
+++ b/src/gallium/drivers/swr/swr_public.h
@@ -36,7 +36,7 @@ extern "C" {
 struct pipe_screen *swr_create_screen(struct sw_winsys *winsys);
 
 // arch-specific dll entry point
-PUBLIC struct pipe_screen *swr_create_screen_internal(struct sw_winsys 
*winsys);
+struct pipe_screen *swr_create_screen_internal(struct sw_winsys *winsys);
 
 #ifdef _WIN32
 void swr_gdi_swap(struct pipe_screen *screen,
diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index b67ac25ac89..10b7e891aca 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -1114,7 +1114,6 @@ swr_validate_env_options(struct swr_screen *screen)
 }
 
 
-PUBLIC
 struct pipe_screen *
 swr_create_screen_internal(struct sw_winsys *winsys)
 {
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH 0/7] EGL_ANDROID_blob_cache

[Tapani Pälli]

On 22.01.2018 15:16, Nicolai Hähnle wrote:

On 19.01.2018 07:05, Tapani Pälli wrote:



On 01/18/2018 05:49 PM, Nicolai Hähnle wrote:

On 17.01.2018 17:10, Tapani Pälli wrote:



On 17.01.2018 13:34, Nicolai Hähnle wrote:

On 15.01.2018 13:31, Tapani Pälli wrote:

Hello;

Here's a refactored series of EGL_ANDROID_blob_cache. Now cache
functions are stored in disk_cache struct and the functionality
called within existing disk_cache put/get code. Problems/errors
that existed with earlier series are gone.

On Android cache index file is created to MESA_GLSL_CACHE_DIR
and blobs are  generated under '/data/user_de/0' in application
specific paths:


Can't we let the "cache index" be managed by the ANDROID_blob_cache 
as well? That seems to me more in the spirit of what that extension 
is about, and would avoid polluting stuff like /sdcard.


The cache index file is used for two purposes:

- Keeping track of the size of the cache. This use is obsoleted 
enterely by ANDROID_blob_cache.


- Keeping track of keys where only their presence is relevant and 
no data is associated. These could easily be treated as empty (0 
byte sized) blobs.


I guess it could be possible, for every app we would create index 
when disk_cache gets created. I guess only issue could be that 
Android might go and remove the index from cache when it decides to 
resize it and then we would loose it even though there would be 
items in cache. I can try how this would work.


Entries can be kicked out of the on-disk index (which is really a bit 
of a misnomer) as well if there's a hash collision.


I believe this functionality is only used as a marker to indicate 
that the GLSL compile step can be skipped. So losing an entry in 
there shouldn't cause any damage.


What I meant is that if we would store index by using set() function, 
the index itself would be just another entry for Android's cache, it 
can decide to remove it when it manages cache size.


Not sure if we're talking about the same thing, then? What I meant was 
that every call to disk_cache_put_key becomes a call to the 
Android-provided set() function, and every call to disk_cache_has_key 
becomes a call to the get() function.


Sorry for the confusion, this is how I implemented it now for the 
current new set I sent.


Although storing the index itself in the blob cache is also an 
interesting idea.


Cheers,
Nicolai





Cheers,
Nicolai






Cheers,
Nicolai





androidia_64:/ # find /data/user_de/0/ -name *shader*
/data/user_de/0/com.android.settings/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.android.gallery3d/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.android.systemui/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.rovio.angrybirdsspace.ads/code_cache/com.android.opengl.shaders_cache 



(this part is managed by Android but may be interesting to know).

Also SurfaceFlinger manages its own cache as seen in the log output:
01-15 07:40:26.329  2129  2129 D SurfaceFlinger: shader cache 
generated - 24 shaders in 57.687504 ms


I'm not sure if /sdcard is sane default but I've tried everything
else (/cache, /data/cache) and failed because of permission errors.

Thanks;

Tapani Pälli (7):
   dri: add interface for EGL_ANDROID_blob_cache extension
   egl: add support for EGL_ANDROID_blob_cache
   disk cache: add callback functionality
   disk cache: support setting MESA_GLSL_CACHE_DIR at compile time
   i965: add __DRI2_BLOB support and set cache functions
   android: ignore MESA_GLSL_CACHE_DISABLE setting
   android: set '/sdcard/' as MESA_GLSL_CACHE_DIR by default

  Android.common.mk  |  1 +
  include/GL/internal/dri_interface.h    | 26 +-
  src/egl/drivers/dri2/egl_dri2.c    | 43 


  src/egl/drivers/dri2/egl_dri2.h    |  4 +++
  src/egl/main/eglapi.c  | 29 
  src/egl/main/eglapi.h  |  4 +++
  src/egl/main/egldisplay.h  |  3 ++
  src/egl/main/eglentrypoint.h   |  1 +
  src/mesa/drivers/dri/i965/brw_disk_cache.c |  2 ++
  src/mesa/drivers/dri/i965/intel_screen.c   | 21 
  src/util/disk_cache.c  | 54 
+-

  src/util/disk_cache.h  | 19 +++
  12 files changed, 205 insertions(+), 2 deletions(-)











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

Re: [Mesa-dev] [PATCH 2/2] i965: Set tiling on BOs imported with modifiers

[Kristian Høgsberg]

On Sun, Jan 21, 2018 at 8:05 PM, Jason Ekstrand  wrote:
> We need this to ensure that GTT maps work on buffers we get from Vulkan
> on the off chance that someone does a readpixels or something.  Soon, we
> will be removing GTT maps from i965 entirely and this can be reverted.
> None the less, it's needed for stable.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index b563bbf..e877f93 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1043,7 +1043,16 @@ intel_create_image_from_fds_common(__DRIscreen 
> *dri_screen,
>
> image->planar_format = f;
>
> -   image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
> +   if (modifier != DRM_FORMAT_MOD_INVALID) {
> +  const struct isl_drm_modifier_info *mod_info =
> + isl_drm_modifier_get_info(modifier);

You need to handle mod_info == NULL for unknown modifiers.

Kristian

> +  uint32_t tiling = isl_tiling_to_i915_tiling(mod_info->tiling);
> +  image->bo = brw_bo_gem_create_from_prime_tiled(screen->bufmgr, fds[0],
> + tiling, strides[0]);
> +   } else {
> +  image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
> +   }
> +
> if (image->bo == NULL) {
>free(image);
>return NULL;
> --
> 2.5.0.400.gff86faf
>
> ___
> 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] swr: refactor swr_create_screen to allow for proper cleanup on error

[Chuck Atkins]

This makes the following changes to address cleanup issues:
- Error conditions now return NULL instead of calling exit()
- swr_creen is now freed upon error, rather than leak.
- Library handle from dlopen is now closed upon swr_screen destruction

v2: Added additional context in commit msg and remove unnecessary "PUBLIC"
v3: Fix typo in commit message.

Signed-off-by: Chuck Atkins 
Reviewed-by: Emil Velikov 
Cc: Bruce Cherniak 
Cc: Tim Rowley 
---
 src/gallium/drivers/swr/swr_loader.cpp | 100 +
 src/gallium/drivers/swr/swr_public.h   |   6 +-
 src/gallium/drivers/swr/swr_screen.cpp |  26 +++--
 src/gallium/drivers/swr/swr_screen.h   |   3 +
 4 files changed, 79 insertions(+), 56 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_loader.cpp 
b/src/gallium/drivers/swr/swr_loader.cpp
index 7f28bdb536..01b9804646 100644
--- a/src/gallium/drivers/swr/swr_loader.cpp
+++ b/src/gallium/drivers/swr/swr_loader.cpp
@@ -29,96 +29,98 @@
 #include 
 
 // Helper function to resolve the backend filename based on architecture
-inline void get_swr_arch_filename(const char arch[], char filename[])
+static bool
+swr_initialize_screen_interface(struct swr_screen *screen, const char arch[])
 {
 #ifdef HAVE_SWR_BUILTIN
-   strcpy(filename , "builtin");
+   screen->pLibrary = NULL;
+   screen->pfnSwrGetInterface = SwrGetInterface;
+   fprintf(stderr, "(using: builtin).\n");
 #else
+   char filename[256] = { 0 };
sprintf(filename, "%sswr%s%s", UTIL_DL_PREFIX, arch, UTIL_DL_EXT);
+
+   screen->pLibrary = util_dl_open(filename);
+   if (!screen->pLibrary) {
+  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
+  return false;
+   }
+
+   util_dl_proc pApiProc = util_dl_get_proc_address(screen->pLibrary,
+  "SwrGetInterface");
+   if (!pApiProc) {
+  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
+  util_dl_close(screen->pLibrary);
+  screen->pLibrary = NULL;
+  return false;
+   }
+
+   screen->pfnSwrGetInterface = (PFNSwrGetInterface)pApiProc;
+   fprintf(stderr, "(using: %s).\n", filename);
 #endif
+   return true;
 }
 
+
 struct pipe_screen *
 swr_create_screen(struct sw_winsys *winsys)
 {
-   char filename[256] = { 0 };
-   bool found = false;
-   bool is_knl = false;
-   PFNSwrGetInterface pfnSwrGetInterface = nullptr;
+   struct pipe_screen *p_screen = swr_create_screen_internal(winsys);
+   if (!p_screen) {
+  return NULL;
+   }
+
+   struct swr_screen *screen = swr_screen(p_screen);
+   screen->is_knl = false;
 
util_cpu_detect();
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
   fprintf(stderr, "SWR detected KNL instruction support ");
 #ifndef HAVE_SWR_KNL
-  fprintf(stderr, "(skipping not built).\n");
+  fprintf(stderr, "(skipping: not built).\n");
 #else
-  get_swr_arch_filename("KNL", filename);
-  found = true;
-  is_knl = true;
+  if (swr_initialize_screen_interface(screen, "KNL")) {
+ screen->is_knl = true;
+ return p_screen;
+  }
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
   fprintf(stderr, "SWR detected SKX instruction support ");
 #ifndef HAVE_SWR_SKX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("SKX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "SKX"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx2) {
+   if (util_cpu_caps.has_avx2) {
   fprintf(stderr, "SWR detected AVX2 instruction support ");
 #ifndef HAVE_SWR_AVX2
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX2", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX2"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx) {
+   if (util_cpu_caps.has_avx) {
   fprintf(stderr, "SWR detected AVX instruction support ");
 #ifndef HAVE_SWR_AVX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX"))
+ return p_screen;
 #endif
}
 
-   if (!found) {
-  fprintf(stderr, "SWR could not detect a supported CPU architecture.\n");
-  exit(-1);
-   }
-
-   fprintf(stderr, "(using %s).\n", filename);
-
-#ifdef HAVE_SWR_BUILTIN
-   pfnSwrGetInterface = SwrGetInterface;
-#else
-   util_dl_library *pLibrary = util_dl_open(filename);
-   if (!pLibrary) {
-  fprintf(stderr, "SWR library load failure: %s\n", util_dl_error());
-  exit(-1);
-   }
-
-   util_dl_proc pApiProc = util_dl_get_proc_address(pLibrary, 
"SwrGetInterface");
-   if 

[Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Chuck Atkins]

This makes the followingt changes to address cleanup issues:
- Error conditions now return null instead of calling exit()
- swr_creen is now freed upon error, rather than leak.
- Library handle from dlopen is now closed upon swr_screen destruction

v2: Added additional context in commit msg and remove unnecessary "PUBLIC"

Signed-off-by: Chuck Atkins 
Reviewed-by: Emil Velikov 
Cc: Bruce Cherniak 
Cc: Tim Rowley 
---
 src/gallium/drivers/swr/swr_loader.cpp | 100 +
 src/gallium/drivers/swr/swr_public.h   |   6 +-
 src/gallium/drivers/swr/swr_screen.cpp |  26 +++--
 src/gallium/drivers/swr/swr_screen.h   |   3 +
 4 files changed, 79 insertions(+), 56 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_loader.cpp 
b/src/gallium/drivers/swr/swr_loader.cpp
index 7f28bdb536..01b9804646 100644
--- a/src/gallium/drivers/swr/swr_loader.cpp
+++ b/src/gallium/drivers/swr/swr_loader.cpp
@@ -29,96 +29,98 @@
 #include 
 
 // Helper function to resolve the backend filename based on architecture
-inline void get_swr_arch_filename(const char arch[], char filename[])
+static bool
+swr_initialize_screen_interface(struct swr_screen *screen, const char arch[])
 {
 #ifdef HAVE_SWR_BUILTIN
-   strcpy(filename , "builtin");
+   screen->pLibrary = NULL;
+   screen->pfnSwrGetInterface = SwrGetInterface;
+   fprintf(stderr, "(using: builtin).\n");
 #else
+   char filename[256] = { 0 };
sprintf(filename, "%sswr%s%s", UTIL_DL_PREFIX, arch, UTIL_DL_EXT);
+
+   screen->pLibrary = util_dl_open(filename);
+   if (!screen->pLibrary) {
+  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
+  return false;
+   }
+
+   util_dl_proc pApiProc = util_dl_get_proc_address(screen->pLibrary,
+  "SwrGetInterface");
+   if (!pApiProc) {
+  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
+  util_dl_close(screen->pLibrary);
+  screen->pLibrary = NULL;
+  return false;
+   }
+
+   screen->pfnSwrGetInterface = (PFNSwrGetInterface)pApiProc;
+   fprintf(stderr, "(using: %s).\n", filename);
 #endif
+   return true;
 }
 
+
 struct pipe_screen *
 swr_create_screen(struct sw_winsys *winsys)
 {
-   char filename[256] = { 0 };
-   bool found = false;
-   bool is_knl = false;
-   PFNSwrGetInterface pfnSwrGetInterface = nullptr;
+   struct pipe_screen *p_screen = swr_create_screen_internal(winsys);
+   if (!p_screen) {
+  return NULL;
+   }
+
+   struct swr_screen *screen = swr_screen(p_screen);
+   screen->is_knl = false;
 
util_cpu_detect();
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
   fprintf(stderr, "SWR detected KNL instruction support ");
 #ifndef HAVE_SWR_KNL
-  fprintf(stderr, "(skipping not built).\n");
+  fprintf(stderr, "(skipping: not built).\n");
 #else
-  get_swr_arch_filename("KNL", filename);
-  found = true;
-  is_knl = true;
+  if (swr_initialize_screen_interface(screen, "KNL")) {
+ screen->is_knl = true;
+ return p_screen;
+  }
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
   fprintf(stderr, "SWR detected SKX instruction support ");
 #ifndef HAVE_SWR_SKX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("SKX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "SKX"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx2) {
+   if (util_cpu_caps.has_avx2) {
   fprintf(stderr, "SWR detected AVX2 instruction support ");
 #ifndef HAVE_SWR_AVX2
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX2", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX2"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx) {
+   if (util_cpu_caps.has_avx) {
   fprintf(stderr, "SWR detected AVX instruction support ");
 #ifndef HAVE_SWR_AVX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX"))
+ return p_screen;
 #endif
}
 
-   if (!found) {
-  fprintf(stderr, "SWR could not detect a supported CPU architecture.\n");
-  exit(-1);
-   }
-
-   fprintf(stderr, "(using %s).\n", filename);
-
-#ifdef HAVE_SWR_BUILTIN
-   pfnSwrGetInterface = SwrGetInterface;
-#else
-   util_dl_library *pLibrary = util_dl_open(filename);
-   if (!pLibrary) {
-  fprintf(stderr, "SWR library load failure: %s\n", util_dl_error());
-  exit(-1);
-   }
-
-   util_dl_proc pApiProc = util_dl_get_proc_address(pLibrary, 
"SwrGetInterface");
-   if (!pApiProc) {
-  

[Mesa-dev] [Bug 103543] meson targets which link libgallium.a have unresolved symbol llvm::RTDyldMemoryManager

[bugzilla-daemon]

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

--- Comment #8 from Vedran Miletić  ---
Created attachment 136898
  --> https://bugs.freedesktop.org/attachment.cgi?id=136898=edit
build errors

-- 
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 103543] meson targets which link libgallium.a have unresolved symbol llvm::RTDyldMemoryManager

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW
 CC||ved...@miletic.net

--- Comment #7 from Vedran Miletić  ---
I can reproduce on Fedora 27 and Fedora 28 (rawhide) with various LLVM versions
from 3.9 onwards. What info could be helpful?

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

Re: [Mesa-dev] [PATCH 1/3] intel: add new common header gen_defines.h

[Tapani Pälli]

On 22.01.2018 17:10, Emil Velikov wrote:

On 22 January 2018 at 12:29, Tapani Pälli  wrote:

Signed-off-by: Tapani Pälli 
---
  src/intel/common/gen_defines.h | 52 ++
  1 file changed, 52 insertions(+)
  create mode 100644 src/intel/common/gen_defines.h


Please add the file to the src/intel/Makefile.sources COMMON_FILES list.


ok




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

#include "i915_drm.h"

^^ is where the I915_CONTEXT*PRIORITY symbols are defined, so let's
include that.


Will do, thanks Emil!


With the two nitpicks, the series is:
Reviewed-by: Emil Velikov 

-Emil



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

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Chuck Atkins]

Hi Emil,

Please include your follow-up reply/context as commit message.
>

Will do.


> +// cleanup for failed screen creation
> > +PUBLIC void swr_destroy_screen_internal(struct swr_screen **screen);
>
> I'm fairly sure you don't need to make this function public. It's used
> within the same binary - libmesaswr.la. Regardless if built-in or
> separate DSO's are used.
>

You are, of course, correct.  I was conflating static with not public and
thinking that since it's not in the same translation unit then it can't be
static so it must be public, which is certainly not the case.


With the above two suggestions:
>
> Cc: mesa-sta...@lists.freedesktop.org


I purposely left this out of mesa-stable since it requires the previous two
commits that initially refactored swr_create_screen to allow for builtin
arch, which were not part of stable.

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

[bugzilla-daemon]

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

--- Comment #4 from Kristian Høgsberg  ---
Can you really claim it's "known broken" when nobody told the maintainer?

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

Re: [Mesa-dev] [PATCH] mesa: Only require independent blending for GLES 3.2.

[Roland Scheidegger]

Am 22.01.2018 um 08:16 schrieb Tapani Pälli:
> 
> 
> On 01/22/2018 08:48 AM, Ilia Mirkin wrote:
>> What es3 does require, though, is mrt. Maybe add something that
>> ensures that mrt is supported?
> 
> I guess that would be EXT_draw_buffers? That is currently enabled with
> 'dummy_true'.
But only because it allows a dummy implementation - minimum of
MaxDrawBuffers allowed is 1 as per the extension spec.
GLES 3.0-3.2 would require 4, GL 3.0-4.6 would require 8 at a quick
glance...
I guess adding a check wouldn't hurt, but I suppose all drivers
currently exposing the affected gl/gles versions would already meet the
limit.

Roland

> 
> 
>> On Jan 19, 2018 08:39, "Eric Anholt" > > wrote:
>>
>>     We've been requiring this since GLES 3.0 was introduced, but the
>>     GLES 3.2
>>     spec is the one that has "Supporting blending on a per-draw-buffer
>>     basis"
>>     in the new features.  V3D 3.3 would require lowering blending to
>> shader
>>     code to implement independent blending.
>>     ---
>>   src/mesa/main/version.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>     diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
>>     index 68079f4ebbba..1fce8fe7ca9c 100644
>>     --- a/src/mesa/main/version.c
>>     +++ b/src/mesa/main/version.c
>>     @@ -516,7 +516,6 @@ compute_version_es2(const struct gl_extensions
>>     *extensions,
>>                            extensions->ARB_texture_float &&
>>                            extensions->ARB_texture_rg &&
>>                            extensions->ARB_depth_buffer_float &&
>>     -                         extensions->EXT_draw_buffers2 &&
>>                            /* extensions->ARB_framebuffer_object
>> && */
>>                            extensions->EXT_framebuffer_sRGB &&
>>                            extensions->EXT_packed_float &&
>>     @@ -546,6 +545,7 @@ compute_version_es2(const struct gl_extensions
>>     *extensions,
>>                            extensions->ARB_gpu_shader5 &&
>>                            extensions->EXT_shader_integer_mix);
>>      const bool ver_3_2 = (ver_3_1 &&
>>     +                         extensions->EXT_draw_buffers2 &&
>>                            extensions->KHR_blend_equation_advanced &&
>>                            extensions->KHR_robustness &&
>>      
>> extensions->KHR_texture_compression_astc_ldr &&
>>     --
>>     2.15.0
>>
>>     ___
>>     mesa-dev mailing list
>>     mesa-dev@lists.freedesktop.org
>> 
>>     https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>     
>>
>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> ___
> mesa-dev 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] i965: make brw_context::num_samples unsigned int

[Emil Velikov]

On 21 January 2018 at 16:15, Jason Ekstrand  wrote:
> Fair enough.  I wasn't sure what you meant.
>
> Reviewed-by: Jason Ekstrand 
>
Thanks, tweaked a bit and pushed to master.

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

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Emil Velikov]

On 22 January 2018 at 15:12, Chuck Atkins  wrote:
> Signed-off-by: Chuck Atkins 
Please include your follow-up reply/context as commit message.

>  // arch-specific dll entry point
>  PUBLIC struct pipe_screen *swr_create_screen_internal(struct sw_winsys 
> *winsys);
>
> +// cleanup for failed screen creation
> +PUBLIC void swr_destroy_screen_internal(struct swr_screen **screen);
> +

I'm fairly sure you don't need to make this function public. It's used
within the same binary - libmesaswr.la. Regardless if built-in or
separate DSO's are used.

With the above two suggestions:

Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH] svga: Prevent use after free.

[Emil Velikov]

On 22 January 2018 at 15:13, Jose Fonseca  wrote:
> Courtesy of clang static analyzer.
>
> I was hunting for potential sources of memory corruption using Mesa with
> a GL trace, and happened to find this (unrelated) issue.
> ---
>  src/gallium/drivers/svga/svga_context.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/svga/svga_context.c 
> b/src/gallium/drivers/svga/svga_context.c
> index 546b9f48b1..af16a99b72 100644
> --- a/src/gallium/drivers/svga/svga_context.c
> +++ b/src/gallium/drivers/svga/svga_context.c
> @@ -327,6 +327,7 @@ cleanup:
> util_bitmask_destroy(svga->stream_output_id_bm);
> util_bitmask_destroy(svga->query_id_bm);
> FREE(svga);
> +   svga = NULL;
>
>  done:
> SVGA_STATS_TIME_POP(svgascreen->sws);

Seems like the most important line is just outside of context. Namely:

return svga ? >pipe:NULL;

Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Emil Velikov 

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

[Mesa-dev] [PATCH] spirv/nir: Fix the stream ID when emitting a primitive or vertex

[Neil Roberts]

According to the SPIR-V spec:

“Stream must be an  of a constant instruction with a scalar
 integer type. That constant is the output-primitive stream number.”

The previous code was treating it as an integer literal.
---

This is part of the GL SPIR-V branch to enable streams for transform
feedback but seeing as it is a standalone fix for existing code I
thought it might be worth posting seperately.

 src/compiler/spirv/spirv_to_nir.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index c6df764682e..c71ed51e4cf 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2983,8 +2983,12 @@ vtn_handle_barrier(struct vtn_builder *b, SpvOp opcode,
nir_intrinsic_instr *intrin =
   nir_intrinsic_instr_create(b->shader, intrinsic_op);
 
-   if (opcode == SpvOpEmitStreamVertex || opcode == SpvOpEndStreamPrimitive)
-  nir_intrinsic_set_stream_id(intrin, w[1]);
+   if (opcode == SpvOpEmitStreamVertex || opcode == SpvOpEndStreamPrimitive) {
+  struct vtn_value *stream_value =
+ vtn_value(b, w[1], vtn_value_type_constant);
+  unsigned stream = stream_value->constant->values[0].u32[0];
+  nir_intrinsic_set_stream_id(intrin, stream);
+   }
 
nir_builder_instr_insert(>nb, >instr);
 }
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Chuck Atkins]

For context, without this, the library handle from dlopen never get's
closed, even under successful operation, and the swr_screen created never
get's freed on error.  Also error conditions resulted in exit() rather than
NULL return.

- Chuck

On Mon, Jan 22, 2018 at 10:12 AM, Chuck Atkins 
wrote:

> Signed-off-by: Chuck Atkins 
> ---
>  src/gallium/drivers/swr/swr_loader.cpp | 100
> +
>  src/gallium/drivers/swr/swr_public.h   |   6 +-
>  src/gallium/drivers/swr/swr_screen.cpp |  26 +++--
>  src/gallium/drivers/swr/swr_screen.h   |   3 +
>  4 files changed, 79 insertions(+), 56 deletions(-)
>
> diff --git a/src/gallium/drivers/swr/swr_loader.cpp
> b/src/gallium/drivers/swr/swr_loader.cpp
> index 7f28bdb536..01b9804646 100644
> --- a/src/gallium/drivers/swr/swr_loader.cpp
> +++ b/src/gallium/drivers/swr/swr_loader.cpp
> @@ -29,96 +29,98 @@
>  #include 
>
>  // Helper function to resolve the backend filename based on architecture
> -inline void get_swr_arch_filename(const char arch[], char filename[])
> +static bool
> +swr_initialize_screen_interface(struct swr_screen *screen, const char
> arch[])
>  {
>  #ifdef HAVE_SWR_BUILTIN
> -   strcpy(filename , "builtin");
> +   screen->pLibrary = NULL;
> +   screen->pfnSwrGetInterface = SwrGetInterface;
> +   fprintf(stderr, "(using: builtin).\n");
>  #else
> +   char filename[256] = { 0 };
> sprintf(filename, "%sswr%s%s", UTIL_DL_PREFIX, arch, UTIL_DL_EXT);
> +
> +   screen->pLibrary = util_dl_open(filename);
> +   if (!screen->pLibrary) {
> +  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
> +  return false;
> +   }
> +
> +   util_dl_proc pApiProc = util_dl_get_proc_address(screen->pLibrary,
> +  "SwrGetInterface");
> +   if (!pApiProc) {
> +  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
> +  util_dl_close(screen->pLibrary);
> +  screen->pLibrary = NULL;
> +  return false;
> +   }
> +
> +   screen->pfnSwrGetInterface = (PFNSwrGetInterface)pApiProc;
> +   fprintf(stderr, "(using: %s).\n", filename);
>  #endif
> +   return true;
>  }
>
> +
>  struct pipe_screen *
>  swr_create_screen(struct sw_winsys *winsys)
>  {
> -   char filename[256] = { 0 };
> -   bool found = false;
> -   bool is_knl = false;
> -   PFNSwrGetInterface pfnSwrGetInterface = nullptr;
> +   struct pipe_screen *p_screen = swr_create_screen_internal(winsys);
> +   if (!p_screen) {
> +  return NULL;
> +   }
> +
> +   struct swr_screen *screen = swr_screen(p_screen);
> +   screen->is_knl = false;
>
> util_cpu_detect();
>
> -   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er)
> {
> +   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
>fprintf(stderr, "SWR detected KNL instruction support ");
>  #ifndef HAVE_SWR_KNL
> -  fprintf(stderr, "(skipping not built).\n");
> +  fprintf(stderr, "(skipping: not built).\n");
>  #else
> -  get_swr_arch_filename("KNL", filename);
> -  found = true;
> -  is_knl = true;
> +  if (swr_initialize_screen_interface(screen, "KNL")) {
> + screen->is_knl = true;
> + return p_screen;
> +  }
>  #endif
> }
>
> -   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw)
> {
> +   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
>fprintf(stderr, "SWR detected SKX instruction support ");
>  #ifndef HAVE_SWR_SKX
>fprintf(stderr, "(skipping not built).\n");
>  #else
> -  get_swr_arch_filename("SKX", filename);
> -  found = true;
> +  if (swr_initialize_screen_interface(screen, "SKX"))
> + return p_screen;
>  #endif
> }
>
> -   if (!found && util_cpu_caps.has_avx2) {
> +   if (util_cpu_caps.has_avx2) {
>fprintf(stderr, "SWR detected AVX2 instruction support ");
>  #ifndef HAVE_SWR_AVX2
>fprintf(stderr, "(skipping not built).\n");
>  #else
> -  get_swr_arch_filename("AVX2", filename);
> -  found = true;
> +  if (swr_initialize_screen_interface(screen, "AVX2"))
> + return p_screen;
>  #endif
> }
>
> -   if (!found && util_cpu_caps.has_avx) {
> +   if (util_cpu_caps.has_avx) {
>fprintf(stderr, "SWR detected AVX instruction support ");
>  #ifndef HAVE_SWR_AVX
>fprintf(stderr, "(skipping not built).\n");
>  #else
> -  get_swr_arch_filename("AVX", filename);
> -  found = true;
> +  if (swr_initialize_screen_interface(screen, "AVX"))
> + return p_screen;
>  #endif
> }
>
> -   if (!found) {
> -  fprintf(stderr, "SWR could not detect a supported CPU
> architecture.\n");
> -  exit(-1);
> -   }
> -
> -   fprintf(stderr, "(using %s).\n", filename);
> -
> -#ifdef HAVE_SWR_BUILTIN
> -   pfnSwrGetInterface = SwrGetInterface;
> -#else
> -   util_dl_library *pLibrary = util_dl_open(filename);
> -   if (!pLibrary) {
> -  fprintf(stderr, "SWR library load failure: %s\n", util_dl_error());
> -  exit(-1);
> -   

[Mesa-dev] [PATCH] svga: Prevent use after free.

[Jose Fonseca]

Courtesy of clang static analyzer.

I was hunting for potential sources of memory corruption using Mesa with
a GL trace, and happened to find this (unrelated) issue.
---
 src/gallium/drivers/svga/svga_context.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 546b9f48b1..af16a99b72 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -327,6 +327,7 @@ cleanup:
util_bitmask_destroy(svga->stream_output_id_bm);
util_bitmask_destroy(svga->query_id_bm);
FREE(svga);
+   svga = NULL;
 
 done:
SVGA_STATS_TIME_POP(svgascreen->sws);
-- 
2.14.1

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

[Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Chuck Atkins]

Signed-off-by: Chuck Atkins 
---
 src/gallium/drivers/swr/swr_loader.cpp | 100 +
 src/gallium/drivers/swr/swr_public.h   |   6 +-
 src/gallium/drivers/swr/swr_screen.cpp |  26 +++--
 src/gallium/drivers/swr/swr_screen.h   |   3 +
 4 files changed, 79 insertions(+), 56 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_loader.cpp 
b/src/gallium/drivers/swr/swr_loader.cpp
index 7f28bdb536..01b9804646 100644
--- a/src/gallium/drivers/swr/swr_loader.cpp
+++ b/src/gallium/drivers/swr/swr_loader.cpp
@@ -29,96 +29,98 @@
 #include 
 
 // Helper function to resolve the backend filename based on architecture
-inline void get_swr_arch_filename(const char arch[], char filename[])
+static bool
+swr_initialize_screen_interface(struct swr_screen *screen, const char arch[])
 {
 #ifdef HAVE_SWR_BUILTIN
-   strcpy(filename , "builtin");
+   screen->pLibrary = NULL;
+   screen->pfnSwrGetInterface = SwrGetInterface;
+   fprintf(stderr, "(using: builtin).\n");
 #else
+   char filename[256] = { 0 };
sprintf(filename, "%sswr%s%s", UTIL_DL_PREFIX, arch, UTIL_DL_EXT);
+
+   screen->pLibrary = util_dl_open(filename);
+   if (!screen->pLibrary) {
+  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
+  return false;
+   }
+
+   util_dl_proc pApiProc = util_dl_get_proc_address(screen->pLibrary,
+  "SwrGetInterface");
+   if (!pApiProc) {
+  fprintf(stderr, "(skipping: %s).\n", util_dl_error());
+  util_dl_close(screen->pLibrary);
+  screen->pLibrary = NULL;
+  return false;
+   }
+
+   screen->pfnSwrGetInterface = (PFNSwrGetInterface)pApiProc;
+   fprintf(stderr, "(using: %s).\n", filename);
 #endif
+   return true;
 }
 
+
 struct pipe_screen *
 swr_create_screen(struct sw_winsys *winsys)
 {
-   char filename[256] = { 0 };
-   bool found = false;
-   bool is_knl = false;
-   PFNSwrGetInterface pfnSwrGetInterface = nullptr;
+   struct pipe_screen *p_screen = swr_create_screen_internal(winsys);
+   if (!p_screen) {
+  return NULL;
+   }
+
+   struct swr_screen *screen = swr_screen(p_screen);
+   screen->is_knl = false;
 
util_cpu_detect();
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
   fprintf(stderr, "SWR detected KNL instruction support ");
 #ifndef HAVE_SWR_KNL
-  fprintf(stderr, "(skipping not built).\n");
+  fprintf(stderr, "(skipping: not built).\n");
 #else
-  get_swr_arch_filename("KNL", filename);
-  found = true;
-  is_knl = true;
+  if (swr_initialize_screen_interface(screen, "KNL")) {
+ screen->is_knl = true;
+ return p_screen;
+  }
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
   fprintf(stderr, "SWR detected SKX instruction support ");
 #ifndef HAVE_SWR_SKX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("SKX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "SKX"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx2) {
+   if (util_cpu_caps.has_avx2) {
   fprintf(stderr, "SWR detected AVX2 instruction support ");
 #ifndef HAVE_SWR_AVX2
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX2", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX2"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx) {
+   if (util_cpu_caps.has_avx) {
   fprintf(stderr, "SWR detected AVX instruction support ");
 #ifndef HAVE_SWR_AVX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX"))
+ return p_screen;
 #endif
}
 
-   if (!found) {
-  fprintf(stderr, "SWR could not detect a supported CPU architecture.\n");
-  exit(-1);
-   }
-
-   fprintf(stderr, "(using %s).\n", filename);
-
-#ifdef HAVE_SWR_BUILTIN
-   pfnSwrGetInterface = SwrGetInterface;
-#else
-   util_dl_library *pLibrary = util_dl_open(filename);
-   if (!pLibrary) {
-  fprintf(stderr, "SWR library load failure: %s\n", util_dl_error());
-  exit(-1);
-   }
-
-   util_dl_proc pApiProc = util_dl_get_proc_address(pLibrary, 
"SwrGetInterface");
-   if (!pApiProc) {
-  fprintf(stderr, "SWR library search failure: %s\n", util_dl_error());
-  exit(-1);
-   }
-
-   pfnSwrGetInterface = (PFNSwrGetInterface)pApiProc;
-#endif
-
-   struct pipe_screen *screen = swr_create_screen_internal(winsys);
-   swr_screen(screen)->is_knl = is_knl;
-   swr_screen(screen)->pfnSwrGetInterface = pfnSwrGetInterface;
+   fprintf(stderr, "SWR could not initialize a supported CPU architecture.\n");
+   swr_destroy_screen_internal();
 
-   return screen;
+   

[Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Chuck Atkins]

Signed-off-by: Chuck Atkins 
---
 src/gallium/drivers/swr/swr_loader.cpp | 100 +
 src/gallium/drivers/swr/swr_public.h   |   6 +-
 src/gallium/drivers/swr/swr_screen.cpp |  26 +++--
 src/gallium/drivers/swr/swr_screen.h   |   3 +
 4 files changed, 79 insertions(+), 56 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_loader.cpp 
b/src/gallium/drivers/swr/swr_loader.cpp
index 7f28bdb536..1ebfaa8392 100644
--- a/src/gallium/drivers/swr/swr_loader.cpp
+++ b/src/gallium/drivers/swr/swr_loader.cpp
@@ -29,96 +29,98 @@
 #include 
 
 // Helper function to resolve the backend filename based on architecture
-inline void get_swr_arch_filename(const char arch[], char filename[])
+static bool
+swr_initialize_screen_interface(struct swr_screen *screen, const char arch[])
 {
 #ifdef HAVE_SWR_BUILTIN
-   strcpy(filename , "builtin");
+   screen->pLibrary = NULL;
+   screen->pfnSwrGetInterface = SwrGetInterface;
+   fprintf(stderr, "(using: builtin).\n");
 #else
+   char filename[256] = { 0 };
sprintf(filename, "%sswr%s%s", UTIL_DL_PREFIX, arch, UTIL_DL_EXT);
+
+   screen->pLibrary = util_dl_open(filename);
+   if (!screen->pLibrary) {
+  fprintf(stderr, "(skipping: %s)\n", util_dl_error());
+  return false;
+   }
+
+   util_dl_proc pApiProc = util_dl_get_proc_address(screen->pLibrary,
+  "SwrGetInterface");
+   if (!pApiProc) {
+  fprintf(stderr, "(skipping: %s)\n", util_dl_error());
+  util_dl_close(screen->pLibrary);
+  screen->pLibrary = NULL;
+  return false;
+   }
+
+   screen->pfnSwrGetInterface = (PFNSwrGetInterface)pApiProc;
+   fprintf(stderr, "(using: %s).\n", filename);
 #endif
+   return true;
 }
 
+
 struct pipe_screen *
 swr_create_screen(struct sw_winsys *winsys)
 {
-   char filename[256] = { 0 };
-   bool found = false;
-   bool is_knl = false;
-   PFNSwrGetInterface pfnSwrGetInterface = nullptr;
+   struct pipe_screen *p_screen = swr_create_screen_internal(winsys);
+   if (!p_screen) {
+  return NULL;
+   }
+
+   struct swr_screen *screen = swr_screen(p_screen);
+   screen->is_knl = false;
 
util_cpu_detect();
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
   fprintf(stderr, "SWR detected KNL instruction support ");
 #ifndef HAVE_SWR_KNL
-  fprintf(stderr, "(skipping not built).\n");
+  fprintf(stderr, "(skipping: not built).\n");
 #else
-  get_swr_arch_filename("KNL", filename);
-  found = true;
-  is_knl = true;
+  if (swr_initialize_screen_interface(screen, "KNL")) {
+ screen->is_knl = true;
+ return p_screen;
+  }
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
+   if (util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
   fprintf(stderr, "SWR detected SKX instruction support ");
 #ifndef HAVE_SWR_SKX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("SKX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "SKX"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx2) {
+   if (util_cpu_caps.has_avx2) {
   fprintf(stderr, "SWR detected AVX2 instruction support ");
 #ifndef HAVE_SWR_AVX2
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX2", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX2"))
+ return p_screen;
 #endif
}
 
-   if (!found && util_cpu_caps.has_avx) {
+   if (util_cpu_caps.has_avx) {
   fprintf(stderr, "SWR detected AVX instruction support ");
 #ifndef HAVE_SWR_AVX
   fprintf(stderr, "(skipping not built).\n");
 #else
-  get_swr_arch_filename("AVX", filename);
-  found = true;
+  if (swr_initialize_screen_interface(screen, "AVX"))
+ return p_screen;
 #endif
}
 
-   if (!found) {
-  fprintf(stderr, "SWR could not detect a supported CPU architecture.\n");
-  exit(-1);
-   }
-
-   fprintf(stderr, "(using %s).\n", filename);
-
-#ifdef HAVE_SWR_BUILTIN
-   pfnSwrGetInterface = SwrGetInterface;
-#else
-   util_dl_library *pLibrary = util_dl_open(filename);
-   if (!pLibrary) {
-  fprintf(stderr, "SWR library load failure: %s\n", util_dl_error());
-  exit(-1);
-   }
-
-   util_dl_proc pApiProc = util_dl_get_proc_address(pLibrary, 
"SwrGetInterface");
-   if (!pApiProc) {
-  fprintf(stderr, "SWR library search failure: %s\n", util_dl_error());
-  exit(-1);
-   }
-
-   pfnSwrGetInterface = (PFNSwrGetInterface)pApiProc;
-#endif
-
-   struct pipe_screen *screen = swr_create_screen_internal(winsys);
-   swr_screen(screen)->is_knl = is_knl;
-   swr_screen(screen)->pfnSwrGetInterface = pfnSwrGetInterface;
+   fprintf(stderr, "SWR could not initialize a supported CPU architecture.\n");
+   swr_destroy_screen_internal();
 
-   return screen;
+   return 

Re: [Mesa-dev] [PATCH 1/3] intel: add new common header gen_defines.h

[Emil Velikov]

On 22 January 2018 at 12:29, Tapani Pälli  wrote:
> Signed-off-by: Tapani Pälli 
> ---
>  src/intel/common/gen_defines.h | 52 
> ++
>  1 file changed, 52 insertions(+)
>  create mode 100644 src/intel/common/gen_defines.h
>
Please add the file to the src/intel/Makefile.sources COMMON_FILES list.


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

^^ is where the I915_CONTEXT*PRIORITY symbols are defined, so let's
include that.

With the two nitpicks, the series is:
Reviewed-by: Emil Velikov 

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

[Mesa-dev] [Bug 104553] mat4: m[i][j] incorrect result with row_major UBO

[bugzilla-daemon]

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

--- Comment #8 from Ilia Mirkin  ---
FYI idr had a separate script to reduce the giant test cases to the
smallest that would still fail. It should be in one of his piglit branches
in his personal fd.o git repo. (I'm on the go, hence no specific URL.)

On Jan 22, 2018 09:02,  wrote:

> florian.w...@googlemail.com changed bug 104553
> 
> What Removed Added
> Attachment #136630 is obsolete   1
>
> *Comment # 7  on
> bug 104553  from
> florian.w...@googlemail.com  *
>
> Created attachment 136878 
>  [details] 
>  [review] 
> 
> Changes to piglit UBO test generator
>
> I have now extended the random UBO piglit test generator python script (in a
> hackish way) to generate SSBO tests as well, and added std430 packing rules to
> generate std430 SSBO tests. My changes are in the attached patch file, but I'd
> say it's not suitable for piglit git (too ugly).
>
> It was helpful to validate the mesa patch I've attached to this bug report
> earlier. Using mesa git master, 391 out of the 540 generated UBO tests
> fail. After applying my patch, only a few tests (3-7) fail. The failing tests
> are always very huge test files (some have more than 10k lines and sometimes 
> up
> to 5MB shader_test files). Apparently they hit something like an internal size
> limit for vertex shaders, because the tests pass when commenting out one half
> of the test conditions in the vertex shader, and they still pass when
> commenting out the other half of the vertex shader.
>
> So I'm now fairly confident that my patch improves the SSBO / UBO buffer 
> access
> behaviour when reading from SSBOs and UBOs.
>
> Is there anything else that should be tested? Or any comments about the patch
> by someone who knows the lower_buffer_access code better than I do?
>
> --
> 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
>
>

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

Re: [Mesa-dev] [PATCH v2 23/24] intel/blorp: Use isl_aux_op instead of blorp_hiz_op

[Pohjolainen, Topi]

On Fri, Jan 19, 2018 at 03:47:40PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/blorp/blorp.c   |  2 +-
>  src/intel/blorp/blorp.h   | 19 +
>  src/intel/blorp/blorp_clear.c |  2 +-
>  src/intel/blorp/blorp_genX_exec.h | 39 
> ++-
>  src/intel/blorp/blorp_priv.h  |  2 +-
>  src/intel/vulkan/anv_blorp.c  | 15 +--
>  src/mesa/drivers/dri/i965/brw_blorp.c | 16 +--
>  src/mesa/drivers/dri/i965/brw_blorp.h |  2 +-
>  src/mesa/drivers/dri/i965/brw_clear.c |  4 +--
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 14 +-
>  10 files changed, 44 insertions(+), 71 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> index e8a2c61..f067515 100644
> --- a/src/intel/blorp/blorp.c
> +++ b/src/intel/blorp/blorp.c
> @@ -293,7 +293,7 @@ blorp_ensure_sf_program(struct blorp_context *blorp,
>  void
>  blorp_hiz_op(struct blorp_batch *batch, struct blorp_surf *surf,
>   uint32_t level, uint32_t start_layer, uint32_t num_layers,
> - enum blorp_hiz_op op)
> + enum isl_aux_op op)
>  {
> struct blorp_params params;
> blorp_params_init();
> diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
> index f1be12b..ce3762c 100644
> --- a/src/intel/blorp/blorp.h
> +++ b/src/intel/blorp/blorp.h
> @@ -207,27 +207,10 @@ blorp_mcs_partial_resolve(struct blorp_batch *batch,
>enum isl_format format,
>uint32_t start_layer, uint32_t num_layers);
>  
> -/**
> - * For an overview of the HiZ operations, see the following sections of the
> - * Sandy Bridge PRM, Volume 1, Part2:
> - *   - 7.5.3.1 Depth Buffer Clear
> - *   - 7.5.3.2 Depth Buffer Resolve
> - *   - 7.5.3.3 Hierarchical Depth Buffer Resolve
> - *
> - * Of these, two get entered in the resolve map as needing to be done to the
> - * buffer: depth resolve and hiz resolve.
> - */
> -enum blorp_hiz_op {
> -   BLORP_HIZ_OP_NONE,
> -   BLORP_HIZ_OP_DEPTH_CLEAR,
> -   BLORP_HIZ_OP_DEPTH_RESOLVE,
> -   BLORP_HIZ_OP_HIZ_RESOLVE,
> -};
> -
>  void
>  blorp_hiz_op(struct blorp_batch *batch, struct blorp_surf *surf,
>   uint32_t level, uint32_t start_layer, uint32_t num_layers,
> - enum blorp_hiz_op op);
> + enum isl_aux_op op);
>  
>  #ifdef __cplusplus
>  } /* end extern "C" */
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index 8b7c5a8..e9f5463 100644
> --- a/src/intel/blorp/blorp_clear.c
> +++ b/src/intel/blorp/blorp_clear.c
> @@ -630,7 +630,7 @@ blorp_gen8_hiz_clear_attachments(struct blorp_batch 
> *batch,
> struct blorp_params params;
> blorp_params_init();
> params.num_layers = 1;
> -   params.hiz_op = BLORP_HIZ_OP_DEPTH_CLEAR;
> +   params.hiz_op = ISL_AUX_OP_FAST_CLEAR;
> params.x0 = x0;
> params.y0 = y0;
> params.x1 = x1;
> diff --git a/src/intel/blorp/blorp_genX_exec.h 
> b/src/intel/blorp/blorp_genX_exec.h
> index 8d007b8..5e1312a 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -787,16 +787,16 @@ blorp_emit_ps_config(struct blorp_batch *batch,
>  
> blorp_emit(batch, GENX(3DSTATE_WM), wm) {
>switch (params->hiz_op) {
> -  case BLORP_HIZ_OP_DEPTH_CLEAR:
> +  case ISL_AUX_OP_FAST_CLEAR:
>   wm.DepthBufferClear = true;
>   break;
> -  case BLORP_HIZ_OP_DEPTH_RESOLVE:
> +  case ISL_AUX_OP_FULL_RESOLVE:
>   wm.DepthBufferResolveEnable = true;
>   break;
> -  case BLORP_HIZ_OP_HIZ_RESOLVE:
> +  case ISL_AUX_OP_AMBIGUATE:
>   wm.HierarchicalDepthBufferResolveEnable = true;
>   break;
> -  case BLORP_HIZ_OP_NONE:
> +  case ISL_AUX_OP_NONE:
>   break;
>default:
>   unreachable("not reached");
> @@ -872,16 +872,16 @@ blorp_emit_ps_config(struct blorp_batch *batch,
>   batch->blorp->isl_dev->info->max_wm_threads - 1;
>  
>switch (params->hiz_op) {
> -  case BLORP_HIZ_OP_DEPTH_CLEAR:
> +  case ISL_AUX_OP_FAST_CLEAR:
>   wm.DepthBufferClear = true;
>   break;
> -  case BLORP_HIZ_OP_DEPTH_RESOLVE:
> +  case ISL_AUX_OP_FULL_RESOLVE:
>   wm.DepthBufferResolveEnable = true;
>   break;
> -  case BLORP_HIZ_OP_HIZ_RESOLVE:
> +  case ISL_AUX_OP_AMBIGUATE:
>   wm.HierarchicalDepthBufferResolveEnable = true;
>   break;
> -  case BLORP_HIZ_OP_NONE:
> +  case ISL_AUX_OP_NONE:
>   break;
>default:
>   unreachable("not reached");
> @@ -1014,7 +1014,7 @@ blorp_emit_depth_stencil_state(struct blorp_batch 
> *batch,
>ds.DepthBufferWriteEnable = true;
>  
>switch (params->hiz_op) {
> -  case BLORP_HIZ_OP_NONE:
> +  case ISL_AUX_OP_NONE:
> 

Re: [Mesa-dev] [PATCH 1/3] ac: add stream handling to visit_end_primitive()

[Timothy Arceri]

On 22/01/18 23:37, Nicolai Hähnle wrote:
Why hasn't this been noticed before? 


I knew it was broken but the state tracker needed to be fixed first 
which I hadn't gotten to, fortunately Rob fixed it for me :) [1]



[1] 
https://cgit.freedesktop.org/mesa/mesa/commit/?id=4c69961daf45a6a64970e5831bd362307dca0cb2 




Does Vulkan not have multiple streams?


Vulkan does not have transform feedback.



Anyway, series is:

Reviewed-by: Nicolai Hähnle 



On 18.01.2018 23:26, Timothy Arceri wrote:

---
  src/amd/common/ac_nir_to_llvm.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c 
b/src/amd/common/ac_nir_to_llvm.c

index 12353943a5..9709514532 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4206,10 +4206,9 @@ visit_emit_vertex(struct ac_shader_abi *abi, 
unsigned stream, LLVMValueRef *addr

  }
  static void
-visit_end_primitive(struct nir_to_llvm_context *ctx,
-    const nir_intrinsic_instr *instr)
+visit_end_primitive(struct nir_to_llvm_context *ctx, unsigned stream)
  {
-    ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_CUT | AC_SENDMSG_GS | 
(0 << 8), ctx->gs_wave_id);
+    ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_CUT | AC_SENDMSG_GS | 
(stream << 8), ctx->gs_wave_id);

  }
  static LLVMValueRef
@@ -4420,7 +4419,7 @@ static void visit_intrinsic(struct 
ac_nir_context *ctx,

  ctx->abi->emit_vertex(ctx->abi, 0, ctx->outputs);
  break;
  case nir_intrinsic_end_primitive:
-    visit_end_primitive(ctx->nctx, instr);
+    visit_end_primitive(ctx->nctx, nir_intrinsic_stream_id(instr));
  break;
  case nir_intrinsic_load_tess_coord: {
  LLVMTypeRef type = ctx->nctx ?





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

Re: [Mesa-dev] [PATCH v2 22/24] intel/blorp: Use isl_aux_op instead of blorp_fast_clear_op

[Pohjolainen, Topi]

On Fri, Jan 19, 2018 at 03:47:39PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/blorp/blorp.h   |  9 +--
>  src/intel/blorp/blorp_clear.c | 10 
>  src/intel/blorp/blorp_genX_exec.h | 16 ++--
>  src/intel/blorp/blorp_priv.h  |  2 +-
>  src/intel/vulkan/anv_blorp.c  | 14 +--
>  src/mesa/drivers/dri/i965/brw_blorp.c |  2 +-
>  src/mesa/drivers/dri/i965/brw_blorp.h |  2 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 36 
> +--
>  8 files changed, 36 insertions(+), 55 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
> index 478a9af..f1be12b 100644
> --- a/src/intel/blorp/blorp.h
> +++ b/src/intel/blorp/blorp.h
> @@ -189,19 +189,12 @@ blorp_clear_attachments(struct blorp_batch *batch,
>  bool clear_depth, float depth_value,
>  uint8_t stencil_mask, uint8_t stencil_value);
>  
> -enum blorp_fast_clear_op {
> -   BLORP_FAST_CLEAR_OP_NONE = 0,
> -   BLORP_FAST_CLEAR_OP_CLEAR,
> -   BLORP_FAST_CLEAR_OP_RESOLVE_PARTIAL,
> -   BLORP_FAST_CLEAR_OP_RESOLVE_FULL,
> -};
> -
>  void
>  blorp_ccs_resolve(struct blorp_batch *batch,
>struct blorp_surf *surf, uint32_t level,
>uint32_t start_layer, uint32_t num_layers,
>enum isl_format format,
> -  enum blorp_fast_clear_op resolve_op);
> +  enum isl_aux_op resolve_op);
>  
>  void
>  blorp_ccs_ambiguate(struct blorp_batch *batch,
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index fa2abd9..8b7c5a8 100644
> --- a/src/intel/blorp/blorp_clear.c
> +++ b/src/intel/blorp/blorp_clear.c
> @@ -322,7 +322,7 @@ blorp_fast_clear(struct blorp_batch *batch,
> params.y1 = y1;
>  
> memset(_inputs.clear_color, 0xff, 4*sizeof(float));
> -   params.fast_clear_op = BLORP_FAST_CLEAR_OP_CLEAR;
> +   params.fast_clear_op = ISL_AUX_OP_FAST_CLEAR;
>  
> get_fast_clear_rect(batch->blorp->isl_dev, surf->aux_surf,
> , , , );
> @@ -720,7 +720,7 @@ blorp_ccs_resolve(struct blorp_batch *batch,
>struct blorp_surf *surf, uint32_t level,
>uint32_t start_layer, uint32_t num_layers,
>enum isl_format format,
> -  enum blorp_fast_clear_op resolve_op)
> +  enum isl_aux_op resolve_op)
>  {
> struct blorp_params params;
>  
> @@ -759,11 +759,11 @@ blorp_ccs_resolve(struct blorp_batch *batch,
> params.y1 = ALIGN(params.y1, y_scaledown) / y_scaledown;
>  
> if (batch->blorp->isl_dev->info->gen >= 9) {
> -  assert(resolve_op == BLORP_FAST_CLEAR_OP_RESOLVE_FULL ||
> - resolve_op == BLORP_FAST_CLEAR_OP_RESOLVE_PARTIAL);
> +  assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
> + resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE);
> } else {
>/* Broadwell and earlier do not have a partial resolve */
> -  assert(resolve_op == BLORP_FAST_CLEAR_OP_RESOLVE_FULL);
> +  assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE);
> }
> params.fast_clear_op = resolve_op;
> params.num_layers = num_layers;
> diff --git a/src/intel/blorp/blorp_genX_exec.h 
> b/src/intel/blorp/blorp_genX_exec.h
> index 1968460..8d007b8 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -750,21 +750,21 @@ blorp_emit_ps_config(struct blorp_batch *batch,
>   ps.MaximumNumberofThreadsPerPSD = 64 - 2;
>  
>switch (params->fast_clear_op) {
> -  case BLORP_FAST_CLEAR_OP_NONE:
> +  case ISL_AUX_OP_NONE:
>   break;
>  #if GEN_GEN >= 9
> -  case BLORP_FAST_CLEAR_OP_RESOLVE_PARTIAL:
> +  case ISL_AUX_OP_PARTIAL_RESOLVE:
>   ps.RenderTargetResolveType = RESOLVE_PARTIAL;
>   break;
> -  case BLORP_FAST_CLEAR_OP_RESOLVE_FULL:
> +  case ISL_AUX_OP_FULL_RESOLVE:
>   ps.RenderTargetResolveType = RESOLVE_FULL;
>   break;
>  #else
> -  case BLORP_FAST_CLEAR_OP_RESOLVE_FULL:
> +  case ISL_AUX_OP_FULL_RESOLVE:
>   ps.RenderTargetResolveEnable = true;
>   break;
>  #endif
> -  case BLORP_FAST_CLEAR_OP_CLEAR:
> +  case ISL_AUX_OP_FAST_CLEAR:
>   ps.RenderTargetFastClearEnable = true;
>   break;
>default:
> @@ -852,12 +852,12 @@ blorp_emit_ps_config(struct blorp_batch *batch,
>   ps.SamplerCount = 1; /* Up to 4 samplers */
>  
>switch (params->fast_clear_op) {
> -  case BLORP_FAST_CLEAR_OP_NONE:
> +  case ISL_AUX_OP_NONE:
>   break;
> -  case BLORP_FAST_CLEAR_OP_RESOLVE_FULL:
> +  case ISL_AUX_OP_FULL_RESOLVE:
>   ps.RenderTargetResolveEnable = true;
>   break;
> -  case BLORP_FAST_CLEAR_OP_CLEAR:
> +  case ISL_AUX_OP_FAST_CLEAR:
>   

Re: [Mesa-dev] [PATCH] radeonsi/nir: fix fs output index

[Timothy Arceri]

On 22/01/18 23:45, Nicolai Hähnle wrote:

On 22.01.2018 04:57, Timothy Arceri wrote:

Fixes the following piglit tests:

arb_blend_func_extended-fbo-extended-blend
arb_blend_func_extended-fbo-extended-blend-explicit
arb_blend_func_extended-fbo-extended-blend-explicit_gles3
arb_blend_func_extended-fbo-extended-blend-pattern
arb_blend_func_extended-fbo-extended-blend-pattern_gles2
arb_blend_func_extended-fbo-extended-blend-pattern_gles3
arb_blend_func_extended-fbo-extended-blend_gles3
ext_framebuffer_multisample/alpha-to-coverage-dual-src-blend
ext_framebuffer_multisample/alpha-to-one-dual-src-blend
---
  src/gallium/drivers/radeonsi/si_shader_nir.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c

index 5b941da949..81cf503d60 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -378,6 +378,10 @@ void si_nir_scan_shader(const struct nir_shader 
*nir,

  if (nir->info.stage == MESA_SHADER_FRAGMENT) {
  tgsi_get_gl_frag_result_semantic(variable->data.location,
  _name, _index);
+
+    if (variable->data.index > 0) {
+    semantic_index++;


Just to understand this correctly, variable->data.index == 1 indicates 
the second source in a dual source blend, and index values > 1 do not 
occur, right?


I believe so, the variable->data.index > 0 was just a copy and paste 
from the glsl to tgsi state tracker.




Could you please add a comment /* Adjust for dual source blending */ or 
similar?


Will do.



With that:

Reviewed-by: Nicolai Hähnle 



+    }
  } else {
  tgsi_get_gl_varying_semantic(variable->data.location, true,
   _name, _index);





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

Re: [Mesa-dev] [PATCH v2 21/24] anv: Allow fast-clearing the first slice of a multi-slice image

[Pohjolainen, Topi]

On Fri, Jan 19, 2018 at 03:47:38PM -0800, Jason Ekstrand wrote:
> Now that we're tracking aux properly per-slice, we can enable this for
> applications which actually care.
> ---
>  src/intel/vulkan/anv_blorp.c   | 22 +++---
>  src/intel/vulkan/genX_cmd_buffer.c | 13 +
>  2 files changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 594b0d8..73a44fd 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1205,9 +1205,16 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
> *cmd_buffer)
> image, VK_IMAGE_ASPECT_COLOR_BIT,
> att_state->aux_usage, );
>  
> +  uint32_t base_layer = iview->planes[0].isl.base_array_layer;
> +  uint32_t layer_count = fb->layers;
> +
>if (att_state->fast_clear) {
>   surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
>  
> + /* We only support fast-clears on the first layer */
> + assert(iview->planes[0].isl.base_level == 0);
> + assert(iview->planes[0].isl.base_array_layer == 0);
> +

Before reading to the end of the patch I was wondering how this assumption
holds. Then I realized the logic in color_attachment_compute_aux_usage(). In
other words, if "att_state->fast_clear == true" then the view covers also the
very first slice.

>   /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
>*
>*"After Render target fast clear, pipe-control with color cache
> @@ -1229,27 +1236,28 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
> *cmd_buffer)
>  
>   assert(image->n_planes == 1);
>   blorp_fast_clear(, , iview->planes[0].isl.format,
> -  iview->planes[0].isl.base_level,
> -  iview->planes[0].isl.base_array_layer, fb->layers,
> +  iview->planes[0].isl.base_level, base_layer, 1,

Given the design for "first slice only" and as there are the asserts earlier
I was expecting to see "0, 0, 1," here. Not a big deal though.

Reviewed-by: Topi Pohjolainen 

>render_area.offset.x, render_area.offset.y,
>render_area.offset.x + render_area.extent.width,
>render_area.offset.y + render_area.extent.height);
> + base_layer++;
> + layer_count--;
>  
>   cmd_buffer->state.pending_pipe_bits |=
>  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> -  } else {
> +  }
> +
> +  if (layer_count > 0) {
>   assert(image->n_planes == 1);
>   anv_cmd_buffer_mark_image_written(cmd_buffer, image,
> VK_IMAGE_ASPECT_COLOR_BIT,
> att_state->aux_usage,
> iview->planes[0].isl.base_level,
> -   
> iview->planes[0].isl.base_array_layer,
> -   fb->layers);
> +   base_layer, layer_count);
>  
>   blorp_clear(, , iview->planes[0].isl.format,
>   anv_swizzle_for_render(iview->planes[0].isl.swizzle),
> - iview->planes[0].isl.base_level,
> - iview->planes[0].isl.base_array_layer, fb->layers,
> + iview->planes[0].isl.base_level, base_layer, 
> layer_count,
>   render_area.offset.x, render_area.offset.y,
>   render_area.offset.x + render_area.extent.width,
>   render_area.offset.y + render_area.extent.height,
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 4c83a5c..484246d 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -329,12 +329,17 @@ color_attachment_compute_aux_usage(struct anv_device * 
> device,
> */
>if (att_state->fast_clear &&
>(iview->planes[0].isl.base_level > 0 ||
> -   iview->image->type == VK_IMAGE_TYPE_3D ||
> -   iview->image->array_size > 0)) {
> +   iview->planes[0].isl.base_array_layer > 0 ||
> +   cmd_state->framebuffer->layers > 1)) {
>   anv_perf_warn(device->instance, iview->image,
> "Rendering to a multi-LOD or multi-layer framebuffer "
> -   "with LOAD_OP_CLEAR.  Not fast-clearing");
> - att_state->fast_clear = false;
> +   "with LOAD_OP_CLEAR.  Only fast-clearing the first "
> +   "slice");
> +
> + /* Leave fast_clear enabled if we are clearing the first slice. */
> + if (iview->planes[0].isl.base_level > 0 ||
> + 

Re: [Mesa-dev] [PATCH 2/7] egl: add support for EGL_ANDROID_blob_cache

[Emil Velikov]

On 19 January 2018 at 06:53, Tapani Pälli  wrote:
>
>
> On 01/18/2018 04:55 PM, Emil Velikov wrote:
>>
>> On 17 January 2018 at 16:11, Tapani Pälli  wrote:
>>>
>>>
>>>
>>> On 17.01.2018 13:28, Nicolai Hähnle wrote:


 On 16.01.2018 18:45, Emil Velikov wrote:
>
>
> Hi Tapani,
>
> On 15 January 2018 at 12:31, Tapani Pälli 
> wrote:
>
>> +static void
>> +update_blob_cache_functions(struct dri2_egl_display *dri2_dpy,
>> +struct dri2_egl_context *dri2_ctx)
>> +{
>> +   if (!dri2_dpy || !dri2_ctx)
>> +  return;
>
>
> AFAICT dri2_dpy can never be NULL.
>
>> +
>> +   /* No blob support. */
>> +   if (!dri2_dpy->blob)
>> +  return;
>> +
>> +   /* No functions to set. */
>> +   if (!dri2_dpy->blob_cache_set)
>> +  return;
>> +
>> +   dri2_dpy->blob->set_cache_funcs(dri2_ctx->dri_context,
>> +   dri2_dpy->blob_cache_set,
>> +   dri2_dpy->blob_cache_get);
>> +}
>> +
>
>
> I'm wondering why you opted to make set_cache_funcs dri_context
> specific as opposed to dri_screen.
> The latter seems to align better to EGLDisplay.
>
> Plus doing so will simplify the existing code - no hunk in
> dri2_make_current, no dri2_dpy->blob/blob_cache_set checks, etc.



 Yes, please make it a screen thing. It just makes more sense, and
 there's
 precedent in Gallium, where the disk-cache is a per-pipe_screen object
 as
 well.
>>>
>>>
>>>
>>> I chose context because eventually I need to access disk_cache which is
>>> part
>>> of gl_context. I'm not sure how would I propagate the set/get there from
>>> dri_screen?
>>>
>> Gallium does the following during create_context. I'm not sure if
>> there's any particular reason why i965 cannot do the same.
>> Tim, you've worked a fair bit in the area do you see any drawbacks?
>>
>> ctx->Cache = pipe->screen->det_dist_shader_cache(pipe->screen);
>>
>
> One problem is that client might set the callbacks only after context
> creation so we need to be able to do this during set_cache_funcs(). Now it
> works fine because we pass context there.
>
I don't see why that would be an issue. Both ctx::cache and
screen::cache are pointer to a single instance.
Hence, as we deref. screen::cache and update the callbacks, everything
will be fine from ctx POV - no need to update for each make_current
call/etc.

Am I having a dull moment here?

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

Re: [Mesa-dev] [PATCH v2 20/24] anv/cmd_buffer: Rework aux tracking

[Pohjolainen, Topi]

I read this thru a few times, and found just two typos:

Reviewed-by: Topi Pohjolainen 

There are a lot of details that could go wrong and another set of eyes
on it would be really good.

On Fri, Jan 19, 2018 at 03:47:37PM -0800, Jason Ekstrand wrote:
> This commit completely reworks aux tracking.  This includes a number of
> somewhat distinct changes:
> 
>  1) Since we are no longer fast-clearing multiple slices, we only need
> to track one fast clear color and one fast clear type.
> 
>  2) We store two bits for fast clear instead of one to let us
> distinguish between zero and non-zero fast clear colors.  This is
> needed so that we can do full resolves when transitioning to
> PRESENT_SRC_KHR with gen9 CCS images where we allow zero clear
> values in all sorts of places wouldn't normally.
> 
>  3) We now track compression state as a boolean separate from fast clear
> type and this is tracked on a per-slice granularity.
> 
> The previous scheme had some issues when it came to individual slices of
> a multi-LOD images.  In particular, we only tracked "needs resolve"
> per-LOD but you could do a vkCmdPipelineBarrier that would only resolve
> a portion of the image and would set "needs resolve" to false anyway.
> Also, any transition from an undefined layout would reset the clear
> color for the entire LOD regardless of whether or not there was some
> clear color on some other slice.
> 
> As far as full/partial resolves go, he assumptions of the previous

  the

> scheme held because the one case where we do need a full resolve when
> CCS_E is enabled is for window-system images.  Since we only ever
> allowed X-tiled window-system images, CCS was entirely disabled on gen9+
> and we never got CCS_E.  With the advent of Y-tiled window-system
> buffers, we now need to properly support doing a full resolve of images
> marked CCS_E.
> ---
>  src/intel/vulkan/anv_blorp.c   |   3 +-
>  src/intel/vulkan/anv_image.c   |  96 ++-
>  src/intel/vulkan/anv_private.h |  53 +++---
>  src/intel/vulkan/genX_cmd_buffer.c | 340 
> +++--
>  4 files changed, 331 insertions(+), 161 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 3698543..594b0d8 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1757,8 +1757,7 @@ anv_image_ccs_op(struct anv_cmd_buffer *cmd_buffer,
> * particular value and don't care about format or clear value.
> */
>const struct anv_address clear_color_addr =
> - anv_image_get_clear_color_addr(cmd_buffer->device, image,
> -aspect, level);
> + anv_image_get_clear_color_addr(cmd_buffer->device, image, aspect);
>surf.clear_color_addr = anv_to_blorp_address(clear_color_addr);
> }
>  
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index 94b9ecb..d5f8dcf 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -190,46 +190,54 @@ all_formats_ccs_e_compatible(const struct 
> gen_device_info *devinfo,
>   * fast-clear values in non-trivial cases (e.g., outside of a render pass in
>   * which a fast clear has occurred).
>   *
> - * For the purpose of discoverability, the algorithm used to manage this 
> buffer
> - * is described here. A clear value in this buffer is updated when a fast 
> clear
> - * is performed on a subresource. One of two synchronization operations is
> - * performed in order for a following memory access to use the fast-clear
> - * value:
> - *a. Copy the value from the buffer to the surface state object used for
> - *   reading. This is done implicitly when the value is the clear value
> - *   predetermined to be the default in other surface state objects. This
> - *   is currently only done explicitly for the operation below.
> - *b. Do (a) and use the surface state object to resolve the subresource.
> - *   This is only done during layout transitions for decent performance.
> + * In order to avoid having multiple clear colors for a single plane of an
> + * image (hence a single RENDER_SURFACE_STATE), we only allow fast-clears on
> + * the first slice (level 0, layer 0).  At the time of our testing (Jan 17,
> + * 2018), there were known applications which would benefit from 
> fast-clearing

s/known/no known/ ?

> + * more than just the first slice.
>   *
> - * With the above scheme, we can fast-clear whenever the hardware allows 
> except
> - * for two cases in which synchronization becomes impossible or undesirable:
> - ** The subresource is in the GENERAL layout and is cleared to a value
> - *  other than the special default value.
> + * The fast clear portion of the image is laid out in the following order:
>   *
> - *  Performing a synchronization operation in order to read from the
> - 

Re: [Mesa-dev] [PATCH] ac: fix image load store for GLSL_SAMPLER_DIM_3D

[Kai Wasserbäch]

Hey,
Nicolai Hähnle wrote on 22.01.2018 14:18:
> On 20.01.2018 04:11, Timothy Arceri wrote:
>> Fixes the following piglit tests:
>>
>> arb_shader_image_load_store/layer/image3d/layered binding test
>> arb_shader_image_load_store/max-size/image3d max size test/2048x8x8x1
>> arb_shader_image_load_store/max-size/image3d max size test/8x2048x8x1
>> arb_shader_image_load_store/max-size/image3d max size test/8x8x2048x1
>> arb_shader_image_load_store/semantics/imageload/vertex shader/rgba32f/image3d
>> test
> 
> Reviewed-by: Nicolai Hähnle 
> 
> 
>> ---
>>   src/amd/common/ac_nir_to_llvm.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c 
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 781e4a905b..ac3a949bd3 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -3634,6 +3634,7 @@ static LLVMValueRef visit_image_load(struct
>> ac_nir_context *ctx,
>>   } else {
>>   bool is_da = glsl_sampler_type_is_array(type) ||
>>    glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE ||
>> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D ||
>>    glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_SUBPASS ||
>>    glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_SUBPASS_MS;
>>   LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
>> @@ -3692,7 +3693,8 @@ static void visit_image_store(struct ac_nir_context 
>> *ctx,
>>  params, 6, 0);
>>   } else {
>>   bool is_da = glsl_sampler_type_is_array(type) ||
>> - glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
>> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE ||
>> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
>>   LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
>>   LLVMValueRef slc = ctx->ac.i1false;

just a note: if this patch goes in before my patch
(), assuming it'll be accepted,
I'd need to do a v2 patch, which applies cleanly on top of this change. The same
applies the other way around.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] ac: remove arrays when when querying sampler info

[Nicolai Hähnle]

On 19.01.2018 06:07, Timothy Arceri wrote:

Fixes the following ARB_arrays_of_arrays piglit tests:

basic-imagestore-const-uniform-index
basic-imagestore-mixed-const-non-const-uniform-index
basic-imagestore-mixed-const-non-const-uniform-index2
basic-imagestore-non-const-uniform-index


Reviewed-by: Nicolai Hähnle 



---
  src/amd/common/ac_nir_to_llvm.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 4f240db4ac..e88f64fb3b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3516,9 +3516,7 @@ static LLVMValueRef 
adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
  static LLVMValueRef get_image_coords(struct ac_nir_context *ctx,
 const nir_intrinsic_instr *instr)
  {
-   const struct glsl_type *type = instr->variables[0]->var->type;
-   if(instr->variables[0]->deref.child)
-   type = instr->variables[0]->deref.child->type;
+   const struct glsl_type *type = 
glsl_without_array(instr->variables[0]->var->type);
  
  	LLVMValueRef src0 = get_src(ctx, instr->src[0]);

LLVMValueRef coords[4];




--
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] ac: fix ac_build_varying_gather_values() for packed layouts

[Nicolai Hähnle]

On 19.01.2018 06:50, Timothy Arceri wrote:

This fixes a segfault for varyings not starting at component 0.


Reviewed-by: Nicolai Hähnle 



---
  src/amd/common/ac_llvm_build.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 3467bba693..6615a269f8 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -413,7 +413,7 @@ ac_build_varying_gather_values(struct ac_llvm_context *ctx, 
LLVMValueRef *values
for (unsigned i = component; i < value_count + component; i++) {
LLVMValueRef value = values[i];
  
-		if (!i)

+   if (i == component)
vec = LLVMGetUndef( LLVMVectorType(LLVMTypeOf(value), 
value_count));
LLVMValueRef index = LLVMConstInt(ctx->i32, i - component, 
false);
vec = LLVMBuildInsertElement(ctx->builder, vec, value, index, 
"");




--
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 v2] ac: fix emit vertex stream parameter

[Nicolai Hähnle]

On 20.01.2018 02:38, Timothy Arceri wrote:

Fixes the following piglit test on radeonsi:

./bin/arb_enhanced_layouts-gs-stream-location-aliasing


Reviewed-by: Nicolai Hähnle 



---
  src/amd/common/ac_nir_to_llvm.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 3741b74dc5..781e4a905b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4160,6 +4160,8 @@ visit_emit_vertex(struct ac_shader_abi *abi, unsigned 
stream, LLVMValueRef *addr
int idx;
struct nir_to_llvm_context *ctx = nir_to_llvm_context_from_abi(abi);
  
+	assert(stream == 0);

+
/* Write vertex attribute values to GSVS ring */
gs_next_vertex = LLVMBuildLoad(ctx->builder,
   ctx->gs_next_vertex,
@@ -4429,8 +4431,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
result = visit_interp(ctx, instr);
break;
case nir_intrinsic_emit_vertex:
-   assert(instr->const_index[0] == 0);
-   ctx->abi->emit_vertex(ctx->abi, 0, ctx->outputs);
+   ctx->abi->emit_vertex(ctx->abi, nir_intrinsic_stream_id(instr), 
ctx->outputs);
break;
case nir_intrinsic_end_primitive:
ctx->abi->emit_primitive(ctx->abi, 
nir_intrinsic_stream_id(instr));




--
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] ac: fix image load store for GLSL_SAMPLER_DIM_3D

[Nicolai Hähnle]

On 20.01.2018 04:11, Timothy Arceri wrote:

Fixes the following piglit tests:

arb_shader_image_load_store/layer/image3d/layered binding test
arb_shader_image_load_store/max-size/image3d max size test/2048x8x8x1
arb_shader_image_load_store/max-size/image3d max size test/8x2048x8x1
arb_shader_image_load_store/max-size/image3d max size test/8x8x2048x1
arb_shader_image_load_store/semantics/imageload/vertex shader/rgba32f/image3d 
test


Reviewed-by: Nicolai Hähnle 



---
  src/amd/common/ac_nir_to_llvm.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 781e4a905b..ac3a949bd3 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3634,6 +3634,7 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
 glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
+glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D 
||
 glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS ||
 glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS_MS;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
@@ -3692,7 +3693,8 @@ static void visit_image_store(struct ac_nir_context *ctx,
   params, 6, 0);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE;
+glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
+glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
  




--
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/7] EGL_ANDROID_blob_cache

[Nicolai Hähnle]

On 19.01.2018 07:05, Tapani Pälli wrote:



On 01/18/2018 05:49 PM, Nicolai Hähnle wrote:

On 17.01.2018 17:10, Tapani Pälli wrote:



On 17.01.2018 13:34, Nicolai Hähnle wrote:

On 15.01.2018 13:31, Tapani Pälli wrote:

Hello;

Here's a refactored series of EGL_ANDROID_blob_cache. Now cache
functions are stored in disk_cache struct and the functionality
called within existing disk_cache put/get code. Problems/errors
that existed with earlier series are gone.

On Android cache index file is created to MESA_GLSL_CACHE_DIR
and blobs are  generated under '/data/user_de/0' in application
specific paths:


Can't we let the "cache index" be managed by the ANDROID_blob_cache 
as well? That seems to me more in the spirit of what that extension 
is about, and would avoid polluting stuff like /sdcard.


The cache index file is used for two purposes:

- Keeping track of the size of the cache. This use is obsoleted 
enterely by ANDROID_blob_cache.


- Keeping track of keys where only their presence is relevant and no 
data is associated. These could easily be treated as empty (0 byte 
sized) blobs.


I guess it could be possible, for every app we would create index 
when disk_cache gets created. I guess only issue could be that 
Android might go and remove the index from cache when it decides to 
resize it and then we would loose it even though there would be items 
in cache. I can try how this would work.


Entries can be kicked out of the on-disk index (which is really a bit 
of a misnomer) as well if there's a hash collision.


I believe this functionality is only used as a marker to indicate that 
the GLSL compile step can be skipped. So losing an entry in there 
shouldn't cause any damage.


What I meant is that if we would store index by using set() function, 
the index itself would be just another entry for Android's cache, it can 
decide to remove it when it manages cache size.


Not sure if we're talking about the same thing, then? What I meant was 
that every call to disk_cache_put_key becomes a call to the 
Android-provided set() function, and every call to disk_cache_has_key 
becomes a call to the get() function.


Although storing the index itself in the blob cache is also an 
interesting idea.


Cheers,
Nicolai





Cheers,
Nicolai






Cheers,
Nicolai





androidia_64:/ # find /data/user_de/0/ -name *shader*
/data/user_de/0/com.android.settings/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.android.gallery3d/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.android.systemui/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.rovio.angrybirdsspace.ads/code_cache/com.android.opengl.shaders_cache 



(this part is managed by Android but may be interesting to know).

Also SurfaceFlinger manages its own cache as seen in the log output:
01-15 07:40:26.329  2129  2129 D SurfaceFlinger: shader cache 
generated - 24 shaders in 57.687504 ms


I'm not sure if /sdcard is sane default but I've tried everything
else (/cache, /data/cache) and failed because of permission errors.

Thanks;

Tapani Pälli (7):
   dri: add interface for EGL_ANDROID_blob_cache extension
   egl: add support for EGL_ANDROID_blob_cache
   disk cache: add callback functionality
   disk cache: support setting MESA_GLSL_CACHE_DIR at compile time
   i965: add __DRI2_BLOB support and set cache functions
   android: ignore MESA_GLSL_CACHE_DISABLE setting
   android: set '/sdcard/' as MESA_GLSL_CACHE_DIR by default

  Android.common.mk  |  1 +
  include/GL/internal/dri_interface.h    | 26 +-
  src/egl/drivers/dri2/egl_dri2.c    | 43 


  src/egl/drivers/dri2/egl_dri2.h    |  4 +++
  src/egl/main/eglapi.c  | 29 
  src/egl/main/eglapi.h  |  4 +++
  src/egl/main/egldisplay.h  |  3 ++
  src/egl/main/eglentrypoint.h   |  1 +
  src/mesa/drivers/dri/i965/brw_disk_cache.c |  2 ++
  src/mesa/drivers/dri/i965/intel_screen.c   | 21 
  src/util/disk_cache.c  | 54 
+-

  src/util/disk_cache.h  | 19 +++
  12 files changed, 205 insertions(+), 2 deletions(-)










--
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] radeonsi/nir: add primitive id to inputs scan

[Nicolai Hähnle]

On 19.01.2018 12:46, Timothy Arceri wrote:

Fixes the following piglit tests:

arb_tessellation_shader/fs-primitiveid-instanced
glsl-1.50/primitive-id-no-gs
glsl-1.50/primitive-id-no-gs-first-vertex
glsl-1.50/primitive-id-no-gs-instanced
glsl-1.50/primitive-id-no-gs-strip
glsl-1.50/primitive-id-no-gs-strip-first-vertex


Reviewed-by: Nicolai Hähnle 



---
  src/gallium/drivers/radeonsi/si_shader_nir.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 4455322392..2f19bae813 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -315,6 +315,9 @@ void si_nir_scan_shader(const struct nir_shader *nir,
info->input_semantic_name[i] = semantic_name;
info->input_semantic_index[i] = semantic_index;
  
+			if (semantic_name == TGSI_SEMANTIC_PRIMID)

+   info->uses_primid = true;
+
if (variable->data.sample)
info->input_interpolate_loc[i] = 
TGSI_INTERPOLATE_LOC_SAMPLE;
else if (variable->data.centroid)




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