Re: [Mesa-dev] [PATCH v2 7/8] i965: Drop _NEW_TRANSFORM from 3DSTATE_VS atom on Gen7.

[Jason Ekstrand]

rb

On Mon, Oct 3, 2016 at 9:41 PM, Kenneth Graunke 
wrote:

> The atom that uploads push constants listens to _NEW_TRANSFORM for
> legacy clip plane handling.  On Sandybridge, the gen6_vs_state atom
> emits 3DSTATE_CONSTANT_VS as well as 3DSTATE_VS, so it needs to listen
> to the same set of conditions.
>
> However, it looks like Gen7 doesn't need this.  The push constant atom
> emits 3DSTATE_CONSTANT_VS directly, and the gen7_vs_state atom that
> emits 3DSTATE_VS doesn't have a dependency on ctx->Transform.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/gen7_vs_state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Whoops :( I meant to remove it from gen6_vs_state, not the push constant
> atom...and frankly, even that's not right.  Thanks for catching that.
>
> Here's a v2 that just changes Ivybridge.
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> index 57e0419..cfd535e 100644
> --- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> @@ -75,7 +75,7 @@ upload_vs_state(struct brw_context *brw)
>
>  const struct brw_tracked_state gen7_vs_state = {
> .dirty = {
> -  .mesa  = _NEW_TRANSFORM,
> +  .mesa  = 0,
>.brw   = BRW_NEW_BATCH |
> BRW_NEW_BLORP |
> BRW_NEW_CONTEXT |
> --
> 2.10.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] [PATCH v2 7/8] i965: Drop _NEW_TRANSFORM from 3DSTATE_VS atom on Gen7.

[Kenneth Graunke]

The atom that uploads push constants listens to _NEW_TRANSFORM for
legacy clip plane handling.  On Sandybridge, the gen6_vs_state atom
emits 3DSTATE_CONSTANT_VS as well as 3DSTATE_VS, so it needs to listen
to the same set of conditions.

However, it looks like Gen7 doesn't need this.  The push constant atom
emits 3DSTATE_CONSTANT_VS directly, and the gen7_vs_state atom that
emits 3DSTATE_VS doesn't have a dependency on ctx->Transform.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/gen7_vs_state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Whoops :( I meant to remove it from gen6_vs_state, not the push constant
atom...and frankly, even that's not right.  Thanks for catching that.

Here's a v2 that just changes Ivybridge.

diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c 
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 57e0419..cfd535e 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -75,7 +75,7 @@ upload_vs_state(struct brw_context *brw)
 
 const struct brw_tracked_state gen7_vs_state = {
.dirty = {
-  .mesa  = _NEW_TRANSFORM,
+  .mesa  = 0,
   .brw   = BRW_NEW_BATCH |
BRW_NEW_BLORP |
BRW_NEW_CONTEXT |
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH 6/8] i965: Add missing BRW_CS_PROG_DATA to CS work group surface atom.

[Jason Ekstrand]

1-6 are

Reviewed-by: Jason Ekstrand 

I think Nanley had a typo fix on 1 that you should probably take care of.

On Wed, Sep 21, 2016 at 10:31 PM, Kenneth Graunke 
wrote:

> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 7b5e380..834e8f2 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -1840,10 +1840,12 @@ brw_upload_cs_work_groups_surface(struct
> brw_context *brw)
> /* _NEW_PROGRAM */
> struct gl_shader_program *prog =
>ctx->_Shader->CurrentProgram[MESA_SHADER_COMPUTE];
> +   /* BRW_NEW_CS_PROG_DATA */
> +   const struct brw_cs_prog_data *cs_prog_data = brw->cs.prog_data;
>
> -   if (prog && brw->cs.prog_data->uses_num_work_groups) {
> +   if (prog && cs_prog_data->uses_num_work_groups) {
>const unsigned surf_idx =
> - brw->cs.prog_data->binding_table.work_groups_start;
> + cs_prog_data->binding_table.work_groups_start;
>uint32_t *surf_offset = >cs.base.surf_offset[surf_idx];
>drm_intel_bo *bo;
>uint32_t bo_offset;
> @@ -1872,6 +1874,7 @@ brw_upload_cs_work_groups_surface(struct
> brw_context *brw)
>  const struct brw_tracked_state brw_cs_work_groups_surface = {
> .dirty = {
>.brw = BRW_NEW_BLORP |
> + BRW_NEW_CS_PROG_DATA |
>   BRW_NEW_CS_WORK_GROUPS
> },
> .emit = brw_upload_cs_work_groups_surface,
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/8] i965: Drop _NEW_TRANSFORM from 3DSTATE_VS atom on Gen6-7.

[Jason Ekstrand]

On Wed, Sep 21, 2016 at 10:31 PM, Kenneth Graunke 
wrote:

> commit e07457d0aec96970a39a2dd1cb4e46da6107eb77 removed the last use
> of ctx->Transform on Gen6.  It looks like Gen7 never needed this, but
>

Not so much... The mentioned commit actually contains a very nice comment
specifying why NEW_TRANSFORM is needed.  On gen6, some elements of
prog_data->param may refer to user clip planes so we need to re-upload push
constants whenever we get NEW_TRANSFORM.

Not sure what the implications are for IVB.


> I copied it over when I originally ported the driver to Ivybridge.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 +--
>  src/mesa/drivers/dri/i965/gen7_vs_state.c | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c
> b/src/mesa/drivers/dri/i965/gen6_vs_state.c
> index 5446ef9..849fff9 100644
> --- a/src/mesa/drivers/dri/i965/gen6_vs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_vs_state.c
> @@ -60,8 +60,7 @@ gen6_upload_vs_push_constants(struct brw_context *brw)
>
>  const struct brw_tracked_state gen6_vs_push_constants = {
> .dirty = {
> -  .mesa  = _NEW_PROGRAM_CONSTANTS |
> -   _NEW_TRANSFORM,
> +  .mesa  = _NEW_PROGRAM_CONSTANTS,
>.brw   = BRW_NEW_BATCH |
> BRW_NEW_BLORP |
> BRW_NEW_PUSH_CONSTANT_ALLOCATION |
> diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> index 2715b37..7daa018 100644
> --- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> @@ -74,7 +74,7 @@ upload_vs_state(struct brw_context *brw)
>
>  const struct brw_tracked_state gen7_vs_state = {
> .dirty = {
> -  .mesa  = _NEW_TRANSFORM,
> +  .mesa  = 0,
>.brw   = BRW_NEW_BATCH |
> BRW_NEW_BLORP |
> BRW_NEW_CONTEXT |
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017

[Albert Freeman]

Yeah I think the value of having a date based system is to quickly
check when the release was made, dayoutofdaysthatyear isn't really
providing any extra benefit since its hard to read and that extra info
is probably rather pointless for quick fix releases since the mesa-dev
branch and a quick fix release wouldn't be syncronised (which also
could cause confusion).
I also don't think people are really going to have a problem with
skipped version numbers anyway (at least not one of concern). I think
its best to just ignore that and do what is best for the future.
So yes, dayoutofdaysthatyear is a detrimental system.
Though I also think that keeping to a quaterly release schedule is a
bad idea. Probably better to try to pick all the dates which align
best with major distros and/or release when something of major value
gets developed. What matters more: sticking to a schedule that fits
seasons of the year just because humans feel like it, or getting
features out to users as quickly as possible.
If releases only happen 3 times a year some years then it will just
create confusion if people are trying to interpret minor versions as
quaterly periods, you would have to remember which years are quaterly.
Though I am just trying to help, I personally don't care what release
system is chosen, so you need not take my opinion into consideration.

On 3 October 2016 at 09:40, Jason Ekstrand  wrote:
>
> On Oct 3, 2016 12:19 AM, "Albert Freeman"  wrote:
>>
>> year.month or year.dayoutofdaysthatyear
>
> Why are we adding more options to an already confused discussion?
>
>> dayoutoofdaysthatyear skips lots of integers quickly: reducing
>> confusion of where is release x.(y - something) and better handles
>> quick fix releases
>> but makes it harder to determine how far into the year the release is
>> although with some effort can be converted into an exact date
>
> Quick fix releases are already handled by the stable release system which I
> don't think anyone is recommending we get rid of.  Also, I haven't heard
> anyone complain that year.quarter (really, year.releaseofyear) isn't
> shipping enough integers.  I don't see what problem your suggestion is
> solving.
>
>> On 2 October 2016 at 14:22, Tobias Klausmann
>>  wrote:
>> >
>> >
>> > On 02.10.2016 13:56, Nicolai Hähnle wrote:
>> >>
>> >> On 01.10.2016 22:22, Tobias Klausmann wrote:
>> >>>
>> >>> On 01.10.2016 21:46, Marek Olšák wrote:
>> 
>>  Hi,
>> 
>>  I propose that we use versioning in the form of "year.quarter".
>> 
>>  2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
>>  quarters of the year, respectively.
>>  2018 would start with 18.0, then 18.1, 18.2, 18.3.
>> 
>>  The motivation is that you can easily tell when a specific Mesa
>>  version was released with an accuracy of 3 months.
>> 
>>  That's the only scheme that seems practical to me. Everything else
>>  seems arbitrary or random.
>> 
>>  Opinions?
>> >>>
>> >>>
>> >>> Why not just use year.month instead, would be more accurate...and
>> >>> releases happen semi random anyway and not after a given time.
>> >>
>> >>
>> >> That's fine for something like Ubuntu where they really stick to their
>> >> two
>> >> releases per year, in the same months each year. I'm not so sure that
>> >> that's
>> >> a realistic goal for Mesa, and if releases *aren't* consistently
>> >> happening
>> >> in the same months, you end up introducing a lot of confusion about
>> >> which
>> >> version numbers exist and which don't.
>> >
>> >
>> > This is true, but also holds true for year.quarter, if we miss one
>> > quarterly
>> > release (18.1, 18.2, 18.4, whoops where is 18.3).
>> >
>> >>
>> >> Time-based with YY.0 for the first release of the year, and then YY.1,
>> >> YY.2, etc. works fine.
>> >
>> >
>> > Thats allright and would help in not confuse people so much, but with it
>> > you
>> > miss the "when was it released again?" thing Marek tried to introduce.
>> >
>> > Greetings,
>> > Tobias
>> >
>> >
>> >>
>> >> Cheers,
>> >> Nicolai
>> >
>> >
>> > ___
>> > 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] spirv: replace assert() with unreachable()

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Mon, Oct 3, 2016 at 5:25 PM, Timothy Arceri  wrote:

> This fixes an uninitialized warning for is_vertex_input.
> ---
>  src/compiler/spirv/vtn_variables.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_variables.c b/src/compiler/spirv/vtn_
> variables.c
> index 43bb3bc..f431c6f 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1054,7 +1054,7 @@ var_decoration_cb(struct vtn_builder *b, struct
> vtn_value *val, int member,
>   is_vertex_input = false;
>   location += VARYING_SLOT_VAR0;
>} else {
> - assert(!"Location must be on input or output variable");
> + unreachable("Location must be on input or output variable");
>}
>
>if (vtn_var->var) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] radv: toplevel configure/make changes required to build

[Edward O'Callaghan]

Reviewed-by: Edward O'Callaghan 

On 10/04/2016 12:48 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This moves some of the llvm checks around to allow them
> to be used for non-gallium drivers as well.
> 
> radv requires llvm 3.9.0 as vulkan requires compute shaders.
> 
> Authors: Bas Nieuwenhuizen and Dave Airlie
> Signed-off-by: Dave Airlie 
> ---
>  configure.ac| 33 ++---
>  src/Makefile.am |  7 ++-
>  2 files changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 1bfac3b..634f3c3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1704,6 +1704,10 @@ if test -n "$with_vulkan_drivers"; then
>  HAVE_INTEL_VULKAN=yes;
>  
>  ;;
> +xradeon)
> +PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
> $LIBDRM_AMDGPU_REQUIRED])
> +HAVE_RADEON_VULKAN=yes;
> + ;;
>  *)
>  AC_MSG_ERROR([Vulkan driver '$driver' does not exist])
>  ;;
> @@ -2187,7 +2191,7 @@ if test "x$enable_gallium_llvm" = xauto; then
>  i*86|x86_64|amd64) enable_gallium_llvm=yes;;
>  esac
>  fi
> -if test "x$enable_gallium_llvm" = xyes; then
> +if test "x$enable_gallium_llvm" = xyes || test "x$HAVE_RADEON_VULKAN" = 
> xyes; then
>  if test -n "$llvm_prefix"; then
>  AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], 
> ["$llvm_prefix/bin"])
>  else
> @@ -2357,10 +2361,7 @@ radeon_llvm_check() {
>  else
>  amdgpu_llvm_target_name='amdgpu'
>  fi
> -if test "x$enable_gallium_llvm" != "xyes"; then
> -AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
> -fi
> -llvm_check_version_for "3" "6" "0" $1
> +llvm_check_version_for $2 $3 $4 $1
>  if test true && $LLVM_CONFIG --targets-built | grep -iqvw 
> $amdgpu_llvm_target_name ; then
>  AC_MSG_ERROR([LLVM $amdgpu_llvm_target_name not enabled in your LLVM 
> build.])
>  fi
> @@ -2371,6 +2372,13 @@ radeon_llvm_check() {
>  fi
>  }
>  
> +radeon_gallium_llvm_check() {
> +if test "x$enable_gallium_llvm" != "xyes"; then
> +AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
> +fi
> +radeon_llvm_check $*
> +}
> +
>  swr_llvm_check() {
>  gallium_require_llvm $1
>  if test ${LLVM_VERSION_INT} -lt 306; then
> @@ -2455,7 +2463,7 @@ if test -n "$with_gallium_drivers"; then
>  gallium_require_drm "Gallium R600"
>  gallium_require_drm_loader
>  if test "x$enable_opencl" = xyes; then
> -radeon_llvm_check "r600g"
> +radeon_gallium_llvm_check "r600g" "3" "6" "0"
>  LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
>  fi
>  ;;
> @@ -2465,7 +2473,7 @@ if test -n "$with_gallium_drivers"; then
>  PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
> $LIBDRM_AMDGPU_REQUIRED])
>  gallium_require_drm "radeonsi"
>  gallium_require_drm_loader
> -radeon_llvm_check "radeonsi"
> +radeon_gallium_llvm_check "radeonsi" "3" "6" "0"
>  require_egl_drm "radeonsi"
>  ;;
>  xnouveau)
> @@ -2584,6 +2592,10 @@ if test "x$MESA_LLVM" != x0; then
>  fi
>  fi
>  
> +if test "x$HAVE_RADEON_VULKAN" != "x0"; then
> +radeon_llvm_check "radv" "3" "9" "0"
> +fi
> +
>  AM_CONDITIONAL(HAVE_GALLIUM_SVGA, test "x$HAVE_GALLIUM_SVGA" = xyes)
>  AM_CONDITIONAL(HAVE_GALLIUM_I915, test "x$HAVE_GALLIUM_I915" = xyes)
>  AM_CONDITIONAL(HAVE_GALLIUM_ILO, test "x$HAVE_GALLIUM_ILO" = xyes)
> @@ -2621,8 +2633,13 @@ AM_CONDITIONAL(HAVE_R200_DRI, test x$HAVE_R200_DRI = 
> xyes)
>  AM_CONDITIONAL(HAVE_RADEON_DRI, test x$HAVE_RADEON_DRI = xyes)
>  AM_CONDITIONAL(HAVE_SWRAST_DRI, test x$HAVE_SWRAST_DRI = xyes)
>  
> +AM_CONDITIONAL(HAVE_RADEON_VULKAN, test "x$HAVE_RADEON_VULKAN" = xyes)
>  AM_CONDITIONAL(HAVE_INTEL_VULKAN, test "x$HAVE_INTEL_VULKAN" = xyes)
>  
> +AM_CONDITIONAL(HAVE_AMD_DRIVERS, test "x$HAVE_GALLIUM_R600" = xyes -o \
> +  "x$HAVE_GALLIUM_RADEONSI" = xyes -o \
> +  "x$HAVE_RADEON_VULKAN" = xyes)
> +
>  AM_CONDITIONAL(HAVE_INTEL_DRIVERS, test "x$HAVE_INTEL_VULKAN" = xyes -o \
>  "x$HAVE_I965_DRI" = xyes)
>  
> @@ -2713,6 +2730,8 @@ dnl Substitute the config
>  AC_CONFIG_FILES([Makefile
>   src/Makefile
>   src/amd/Makefile
> + src/amd/common/Makefile
> + src/amd/vulkan/Makefile
>   src/compiler/Makefile
>   src/egl/Makefile
>   src/egl/main/egl.pc
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 551f431..6a35f19 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -50,7 +50,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi
>  # include only conditionally ?
>  SUBDIRS += 

Re: [Mesa-dev] [PATCH 2/4] radv/winsys: import the amdgpu winsys for the radv vulkan driver.

[Edward O'Callaghan]

First, I just wanted to say congrats and thanks for all the hard work
put into this! The implementation is very readable and written to a
pretty high standard already.

I just did a rather 'soft' review on this patch, there is a few trivial
style comments but one thing I noticed is a miss-aligned default in a
case statment.

Hope that helpful feedback otherwise this patch is then
Acked-by: Edward O'Callaghan 

Though I will iterate a few more passes over the whole set over the next
few days.

Thanks again to you both.

Kind Regards,
Edward.

On 10/04/2016 12:48 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This just brings these files into the tree, it doesn't integrate
> them with the build system.
> 
> The radv winsys is based on the gallium one with some changes,
> due to how command buffers are built and lack of flushing behaviour.
> 
> Authors: Bas Nieuwenhuizen and Dave Airlie
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_radeon_winsys.h| 332 +
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c  | 297 
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h  |  50 ++
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c  | 778 
> +
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h  |  52 ++
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c | 523 ++
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h |  29 +
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c  | 359 ++
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h  |  32 +
>  .../winsys/amdgpu/radv_amdgpu_winsys_public.h  |  30 +
>  10 files changed, 2482 insertions(+)
>  create mode 100644 src/amd/vulkan/radv_radeon_winsys.h
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
>  create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys_public.h
> 
> diff --git a/src/amd/vulkan/radv_radeon_winsys.h 
> b/src/amd/vulkan/radv_radeon_winsys.h
> new file mode 100644
> index 000..1297583
> --- /dev/null
> +++ b/src/amd/vulkan/radv_radeon_winsys.h
> @@ -0,0 +1,332 @@
> +/*
> + * Copyright © 2016 Red Hat.
> + * Copyright © 2016 Bas Nieuwenhuizen
> + *
> + * 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 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +#pragma once
> +
> +#include 
> +#include 
> +#include 
> +#include "main/macros.h"
> +#include "ac_radeon_winsys.h"
> +
> +#define FREE(x) free(x)
> +
> +enum radeon_bo_domain { /* bitfield */
> + RADEON_DOMAIN_GTT  = 2,
> + RADEON_DOMAIN_VRAM = 4,
> + RADEON_DOMAIN_VRAM_GTT = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT
> +};
> +
> +enum radeon_bo_flag { /* bitfield */
> + RADEON_FLAG_GTT_WC =(1 << 0),
> + RADEON_FLAG_CPU_ACCESS =(1 << 1),
> + RADEON_FLAG_NO_CPU_ACCESS = (1 << 2),
> +};
> +
> +enum radeon_bo_usage { /* bitfield */
> + RADEON_USAGE_READ = 2,
> + RADEON_USAGE_WRITE = 4,
> + RADEON_USAGE_READWRITE = RADEON_USAGE_READ | RADEON_USAGE_WRITE
> +};
> +
> +enum ring_type {
> + RING_GFX = 0,
> + RING_COMPUTE,
> + RING_DMA,
> + RING_UVD,
> + RING_VCE,
> + RING_LAST,
> +};
> +
> +struct radeon_winsys_cs {
> + unsigned cdw;  /* Number of used dwords. */
> + unsigned max_dw; /* Maximum number of dwords. */
> + uint32_t *buf; /* The base pointer of the chunk. */
> +};
> +
> +struct radeon_info 

[Mesa-dev] [PATCH 2/4] radv/winsys: import the amdgpu winsys for the radv vulkan driver.

[Dave Airlie]

From: Dave Airlie 

This just brings these files into the tree, it doesn't integrate
them with the build system.

The radv winsys is based on the gallium one with some changes,
due to how command buffers are built and lack of flushing behaviour.

Authors: Bas Nieuwenhuizen and Dave Airlie
Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_radeon_winsys.h| 332 +
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c  | 297 
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h  |  50 ++
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c  | 778 +
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h  |  52 ++
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c | 523 ++
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h |  29 +
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c  | 359 ++
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h  |  32 +
 .../winsys/amdgpu/radv_amdgpu_winsys_public.h  |  30 +
 10 files changed, 2482 insertions(+)
 create mode 100644 src/amd/vulkan/radv_radeon_winsys.h
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
 create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys_public.h

diff --git a/src/amd/vulkan/radv_radeon_winsys.h 
b/src/amd/vulkan/radv_radeon_winsys.h
new file mode 100644
index 000..1297583
--- /dev/null
+++ b/src/amd/vulkan/radv_radeon_winsys.h
@@ -0,0 +1,332 @@
+/*
+ * Copyright © 2016 Red Hat.
+ * Copyright © 2016 Bas Nieuwenhuizen
+ *
+ * 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 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+#pragma once
+
+#include 
+#include 
+#include 
+#include "main/macros.h"
+#include "ac_radeon_winsys.h"
+
+#define FREE(x) free(x)
+
+enum radeon_bo_domain { /* bitfield */
+   RADEON_DOMAIN_GTT  = 2,
+   RADEON_DOMAIN_VRAM = 4,
+   RADEON_DOMAIN_VRAM_GTT = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT
+};
+
+enum radeon_bo_flag { /* bitfield */
+   RADEON_FLAG_GTT_WC =(1 << 0),
+   RADEON_FLAG_CPU_ACCESS =(1 << 1),
+   RADEON_FLAG_NO_CPU_ACCESS = (1 << 2),
+};
+
+enum radeon_bo_usage { /* bitfield */
+   RADEON_USAGE_READ = 2,
+   RADEON_USAGE_WRITE = 4,
+   RADEON_USAGE_READWRITE = RADEON_USAGE_READ | RADEON_USAGE_WRITE
+};
+
+enum ring_type {
+   RING_GFX = 0,
+   RING_COMPUTE,
+   RING_DMA,
+   RING_UVD,
+   RING_VCE,
+   RING_LAST,
+};
+
+struct radeon_winsys_cs {
+   unsigned cdw;  /* Number of used dwords. */
+   unsigned max_dw; /* Maximum number of dwords. */
+   uint32_t *buf; /* The base pointer of the chunk. */
+};
+
+struct radeon_info {
+   /* PCI info: domain:bus:dev:func */
+   uint32_tpci_domain;
+   uint32_tpci_bus;
+   uint32_tpci_dev;
+   uint32_tpci_func;
+
+   /* Device info. */
+   uint32_tpci_id;
+   enum radeon_family  family;
+   const char  *name;
+   enum chip_class chip_class;
+   uint32_tgart_page_size;
+   uint64_tgart_size;
+   uint64_tvram_size;
+   boolhas_dedicated_vram;
+   bool has_virtual_memory;
+   boolgfx_ib_pad_with_type2;
+   bool has_sdma;
+   

[Mesa-dev] [PATCH 4/4] radv: toplevel configure/make changes required to build

[Dave Airlie]

From: Dave Airlie 

This moves some of the llvm checks around to allow them
to be used for non-gallium drivers as well.

radv requires llvm 3.9.0 as vulkan requires compute shaders.

Authors: Bas Nieuwenhuizen and Dave Airlie
Signed-off-by: Dave Airlie 
---
 configure.ac| 33 ++---
 src/Makefile.am |  7 ++-
 2 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1bfac3b..634f3c3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1704,6 +1704,10 @@ if test -n "$with_vulkan_drivers"; then
 HAVE_INTEL_VULKAN=yes;
 
 ;;
+xradeon)
+PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
$LIBDRM_AMDGPU_REQUIRED])
+HAVE_RADEON_VULKAN=yes;
+   ;;
 *)
 AC_MSG_ERROR([Vulkan driver '$driver' does not exist])
 ;;
@@ -2187,7 +2191,7 @@ if test "x$enable_gallium_llvm" = xauto; then
 i*86|x86_64|amd64) enable_gallium_llvm=yes;;
 esac
 fi
-if test "x$enable_gallium_llvm" = xyes; then
+if test "x$enable_gallium_llvm" = xyes || test "x$HAVE_RADEON_VULKAN" = xyes; 
then
 if test -n "$llvm_prefix"; then
 AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], ["$llvm_prefix/bin"])
 else
@@ -2357,10 +2361,7 @@ radeon_llvm_check() {
 else
 amdgpu_llvm_target_name='amdgpu'
 fi
-if test "x$enable_gallium_llvm" != "xyes"; then
-AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
-fi
-llvm_check_version_for "3" "6" "0" $1
+llvm_check_version_for $2 $3 $4 $1
 if test true && $LLVM_CONFIG --targets-built | grep -iqvw 
$amdgpu_llvm_target_name ; then
 AC_MSG_ERROR([LLVM $amdgpu_llvm_target_name not enabled in your LLVM 
build.])
 fi
@@ -2371,6 +2372,13 @@ radeon_llvm_check() {
 fi
 }
 
+radeon_gallium_llvm_check() {
+if test "x$enable_gallium_llvm" != "xyes"; then
+AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
+fi
+radeon_llvm_check $*
+}
+
 swr_llvm_check() {
 gallium_require_llvm $1
 if test ${LLVM_VERSION_INT} -lt 306; then
@@ -2455,7 +2463,7 @@ if test -n "$with_gallium_drivers"; then
 gallium_require_drm "Gallium R600"
 gallium_require_drm_loader
 if test "x$enable_opencl" = xyes; then
-radeon_llvm_check "r600g"
+radeon_gallium_llvm_check "r600g" "3" "6" "0"
 LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
 fi
 ;;
@@ -2465,7 +2473,7 @@ if test -n "$with_gallium_drivers"; then
 PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
$LIBDRM_AMDGPU_REQUIRED])
 gallium_require_drm "radeonsi"
 gallium_require_drm_loader
-radeon_llvm_check "radeonsi"
+radeon_gallium_llvm_check "radeonsi" "3" "6" "0"
 require_egl_drm "radeonsi"
 ;;
 xnouveau)
@@ -2584,6 +2592,10 @@ if test "x$MESA_LLVM" != x0; then
 fi
 fi
 
+if test "x$HAVE_RADEON_VULKAN" != "x0"; then
+radeon_llvm_check "radv" "3" "9" "0"
+fi
+
 AM_CONDITIONAL(HAVE_GALLIUM_SVGA, test "x$HAVE_GALLIUM_SVGA" = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_I915, test "x$HAVE_GALLIUM_I915" = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_ILO, test "x$HAVE_GALLIUM_ILO" = xyes)
@@ -2621,8 +2633,13 @@ AM_CONDITIONAL(HAVE_R200_DRI, test x$HAVE_R200_DRI = 
xyes)
 AM_CONDITIONAL(HAVE_RADEON_DRI, test x$HAVE_RADEON_DRI = xyes)
 AM_CONDITIONAL(HAVE_SWRAST_DRI, test x$HAVE_SWRAST_DRI = xyes)
 
+AM_CONDITIONAL(HAVE_RADEON_VULKAN, test "x$HAVE_RADEON_VULKAN" = xyes)
 AM_CONDITIONAL(HAVE_INTEL_VULKAN, test "x$HAVE_INTEL_VULKAN" = xyes)
 
+AM_CONDITIONAL(HAVE_AMD_DRIVERS, test "x$HAVE_GALLIUM_R600" = xyes -o \
+  "x$HAVE_GALLIUM_RADEONSI" = xyes -o \
+  "x$HAVE_RADEON_VULKAN" = xyes)
+
 AM_CONDITIONAL(HAVE_INTEL_DRIVERS, test "x$HAVE_INTEL_VULKAN" = xyes -o \
 "x$HAVE_I965_DRI" = xyes)
 
@@ -2713,6 +2730,8 @@ dnl Substitute the config
 AC_CONFIG_FILES([Makefile
src/Makefile
src/amd/Makefile
+   src/amd/common/Makefile
+   src/amd/vulkan/Makefile
src/compiler/Makefile
src/egl/Makefile
src/egl/main/egl.pc
diff --git a/src/Makefile.am b/src/Makefile.am
index 551f431..6a35f19 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -50,7 +50,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi
 # include only conditionally ?
 SUBDIRS += compiler
 
-if HAVE_GALLIUM_RADEON_COMMON
+if HAVE_AMD_DRIVERS
 SUBDIRS += amd
 endif
 
@@ -96,6 +96,11 @@ if HAVE_INTEL_VULKAN
 SUBDIRS += intel/vulkan
 endif
 
+if HAVE_RADEON_VULKAN
+SUBDIRS += amd/common
+SUBDIRS += amd/vulkan
+endif
+
 if HAVE_GALLIUM
 SUBDIRS += gallium
 endif
-- 
2.5.5

___
mesa-dev 

[Mesa-dev] radv initial submission

[Dave Airlie]

Hi all,

I fully expect this won't make it to the list in one piece due to size.
I've pushed the same patchset to
https://github.com/airlied/mesa/tree/radv-submit

This is an initial submission of the open source radv vulkan driver
for AMD GPUs supported by the amdgpu driver. It is a project Bas and I
started some months ago as an interesting learning experience and it's
been great to see it get this far in such a short time.

This driver is in no way to be considered conformant or called such.
It has NOT passed the vulkan conformance suite or ever been submitted
to Khronos. It prints a big warning on startup to this effect.

In saying that, it runs quite well with Dota 2, Talos Principle and
vkQuake in our testing so far.

Future plans are to add support for various hw speedups (fast clears),
missing things like spilling, and multiple queues along with finishing
out things like geom/tess shaders. Also trying to reuse code between
this and the radeonsi driver where possible. radv already reuses
the LLVM compiler backend and the addrlib code.

I've split things out into 4 patches, 3 just add code files to various
places and number 4 intergrates the build system changes so they
are easier to review.

Regards,
Dave (and on behalf of Bas).

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

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Roland Scheidegger]

Am 04.10.2016 um 03:16 schrieb Michel Dänzer:
> On 04/10/16 01:53 AM, Roland Scheidegger wrote:
>> In an ideal world everybody would zero-intialize the template I suppose
>> - then it would easily survive such interface changes.
> 
> As long as there are no fields where 0 isn't a safe value...
That's true, but for interface additions you can usually design them
around 0 being a safe value. (Of course, how this usually works is these
fields are interpreted by the drivers, and in this case just about
anything is usually safe, as long as the driver actually doesn't
implement a new feature.)

> 
> What's needed is an explicit definition of whether it's the caller's or
> callee's responsibility to initialize the next field (in particular, and
> any other fields in general). Are there any cases where the
> resource_create caller needs to pass in a non-NULL next field value?
> 
> Note that with the original problem I fixed in radeon, the caller wasn't
> in state tracker code but in driver internal code.
> 

I suppose it's never necessary to pass a non-NULL value there (there
isn't really a definition how a driver should create such a resource).
Still, passing explicitly bogus values there in the template just irks
me. But if it's easier, doing it in the driver ought to be ok...

Roland


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

Re: [Mesa-dev] [PATCH 2/2] radv: Add new flag for LLVM dependecies with vulkan

[Tobias Droste]

I was looking at a per driver check for vulkan, but then this can't reuse the 
existing functions to check llvm version.

The LLVM version checks are also the reason this is done is such a weird way 
for gallium. It doesn't make sense there too and should be per driver too.

This patch was just the way of the least resistance by reusing as much as 
possible and make it actually work. 
If you have something better, I don't mind if you ignore this :-)

Tobias

Am Dienstag, 4. Oktober 2016, 10:25:38 CEST schrieb Dave Airlie:
> On 3 October 2016 at 05:45, Tobias Droste  wrote:
> > This reuse the same logic gallium uses to determine if LLVM is needed or
> > not:
> > --enable-vulkan-llvm is set to yes if at least one vulkan driver is
> > active and the host is i3*6 or x86_64.
> > To build vulkan drivers without LLVM (e.g. intel) one has to add
> > --disable-vulkan-llvm.
> > 
> > In order to make this all work the vulkan driver check has to move
> > either diretcly below or directly above the gallium driver checks.
> > Move them below the gallium driver stuff.
> 
> I don't think basing this on gallium is correct, as gallium is used across
> dirvers, the vulkan drivers are pretty separate at this point, so it should
> just be a per driver check for llvm, not a vulkan level one.
> 
> I'll try and clean things up today in there before proposing for master.
> 
> Dave.


-- 
Mit freundlichen Grüßen
Tobias Droste
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 10/11] genX/cmd_buffer: Enable fast depth clears

[Jason Ekstrand]

On Mon, Oct 3, 2016 at 6:11 PM, Jason Ekstrand  wrote:

> On Tue, Sep 27, 2016 at 3:23 PM, Nanley Chery 
> wrote:
>
>> On Tue, Sep 27, 2016 at 03:12:17PM -0700, Chad Versace wrote:
>> > On Tue 27 Sep 2016, Nanley Chery wrote:
>> > > On Tue, Sep 27, 2016 at 11:00:21AM -0700, Chad Versace wrote:
>> >
>> > > > As a consequence of that reasoning, we should set
>> 3DSTATE_CLEAR_PARAMS.DepthClearValueValid = 1
>> > > > whenever hiz is enabled, even if we don't care about the actual
>> clear value.
>>
>
> The logic seems to imply that we can't trust the context to save/restore
> our depth clear value so we have to set it every time.  At the very least,
> once per batch?  In any case, I doubt there's all that much cost involved
> in emitting 3DSTATE_CLEAR_PARAMS so I don't think re-emitting it is that
> big of a deal.
>

Thinking about it a bit more...

We only set up dept/stencil packets once per subpass and we only do clears
once per subpass so... I don't think we're actually saving anything by
emitting it at clear time rather than at depth/stencil setup time.  It is a
bit more convenient because the clear values may be more accessible at
clear time.

As far as "should we emit 3DSTATE_CLEAR_PARAMS all the time?"  Let's not go
to any heroics to try and avoid re-emitting it.  Once per subpass is not a
big deal at all.

--Jason


> > >
>> > > In the V3, I plan to emit that packet once at device initialization
>> time
>> > > HSW+, and to always emit it (in the expected location) for IVB/BYT.
>> Only
>> > > the latter platforms have the restriction that it must always be
>> > > programmed with the other depth/stencil commands.
>> >
>> > Is there any benefit to emitting it multiple times on ivb/byt? Does
>> > emitting once during initialization, as for hsw, also work for ivb/byt?
>> > If so, the code is cleaner if the two gens share the same workaround
>> > code.
>>
>> The benefit for emitting it multiple times on IVB/BYT is that we're
>> (possibly) following the oddly-worded programming note for the packet:
>>
>>From the IVB PRM Vol2P1, 11.5.5.4 3DSTATE_CLEAR_PARAMS:
>>
>>   3DSTATE_CLEAR_PARAMS must always be programmed in the along with
>>   the other Depth/Stencil state commands(i.e.  3DSTATE_DEPTH_BUFFER,
>>   3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER)
>>
>> HSW+ doesn't have this restriction, so we're free to only do it once.
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Michel Dänzer]

On 04/10/16 01:53 AM, Roland Scheidegger wrote:
> In an ideal world everybody would zero-intialize the template I suppose
> - then it would easily survive such interface changes.

As long as there are no fields where 0 isn't a safe value...

What's needed is an explicit definition of whether it's the caller's or
callee's responsibility to initialize the next field (in particular, and
any other fields in general). Are there any cases where the
resource_create caller needs to pass in a non-NULL next field value?

Note that with the original problem I fixed in radeon, the caller wasn't
in state tracker code but in driver internal code.


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

Re: [Mesa-dev] [PATCH V2 00/11] anv: Implement HiZ for basic cases

[Jason Ekstrand]

The whole thing is

Reviewed-by: Jason Ekstrand 

I'm still a little concerned about CLEAR_PARAMS in patch 10, but once
chad's happy, I'll be happy.

On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery  wrote:

> This series is the second revision of the series found here:
> https://lists.freedesktop.org/archives/mesa-dev/2016-September/127687.html
>
> Comments from the first were addressed and the code was rebased onto
> the upstream master.
>
> Cc: Chad Versace 
> Cc: Jason Ekstrand 
>
> Chad Versace (4):
>   anv: Add anv_image::hiz_surface
>   anv: Add func anv_image_has_hiz()
>   anv: Allocate hiz surface
>   genX/cmd_buffer: Enable rendering to HiZ
>
> Jason Ekstrand (2):
>   anv: Move BindImageMemory to anv_image.c
>   anv/image: Memset hiz surfaces to 0 when binding memory
>
> Nanley Chery (5):
>   isl: Correct a comment in the isl_format enum
>   isl: Update isl_surf_get_hiz_surf()
>   anv/cmd_buffer: Add code for performing HZ operations
>   genX/cmd_buffer: Enable fast depth clears
>   anv/TODO: Update the HiZ task
>
>  src/intel/isl/isl.c|  39 ++--
>  src/intel/isl/isl.h|   2 +-
>  src/intel/vulkan/TODO  |   2 +-
>  src/intel/vulkan/anv_device.c  |  20 -
>  src/intel/vulkan/anv_genX.h|   3 +
>  src/intel/vulkan/anv_image.c   |  88 +-
>  src/intel/vulkan/anv_pass.c|  13 +++
>  src/intel/vulkan/anv_private.h |  12 +++
>  src/intel/vulkan/gen7_cmd_buffer.c |   6 ++
>  src/intel/vulkan/gen8_cmd_buffer.c | 177 ++
> +++
>  src/intel/vulkan/genX_cmd_buffer.c |  47 --
>  11 files changed, 371 insertions(+), 38 deletions(-)
>
> --
> 2.10.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 10/11] genX/cmd_buffer: Enable fast depth clears

[Jason Ekstrand]

On Tue, Sep 27, 2016 at 3:23 PM, Nanley Chery  wrote:

> On Tue, Sep 27, 2016 at 03:12:17PM -0700, Chad Versace wrote:
> > On Tue 27 Sep 2016, Nanley Chery wrote:
> > > On Tue, Sep 27, 2016 at 11:00:21AM -0700, Chad Versace wrote:
> >
> > > > As a consequence of that reasoning, we should set
> 3DSTATE_CLEAR_PARAMS.DepthClearValueValid = 1
> > > > whenever hiz is enabled, even if we don't care about the actual
> clear value.
>

The logic seems to imply that we can't trust the context to save/restore
our depth clear value so we have to set it every time.  At the very least,
once per batch?  In any case, I doubt there's all that much cost involved
in emitting 3DSTATE_CLEAR_PARAMS so I don't think re-emitting it is that
big of a deal.


> > >
> > > In the V3, I plan to emit that packet once at device initialization
> time
> > > HSW+, and to always emit it (in the expected location) for IVB/BYT.
> Only
> > > the latter platforms have the restriction that it must always be
> > > programmed with the other depth/stencil commands.
> >
> > Is there any benefit to emitting it multiple times on ivb/byt? Does
> > emitting once during initialization, as for hsw, also work for ivb/byt?
> > If so, the code is cleaner if the two gens share the same workaround
> > code.
>
> The benefit for emitting it multiple times on IVB/BYT is that we're
> (possibly) following the oddly-worded programming note for the packet:
>
>From the IVB PRM Vol2P1, 11.5.5.4 3DSTATE_CLEAR_PARAMS:
>
>   3DSTATE_CLEAR_PARAMS must always be programmed in the along with
>   the other Depth/Stencil state commands(i.e.  3DSTATE_DEPTH_BUFFER,
>   3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER)
>
> HSW+ doesn't have this restriction, so we're free to only do it once.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?)

[Rob Clark]

On Thu, Sep 29, 2016 at 10:56 AM, Emil Velikov  wrote:
> On 28 September 2016 at 19:53, Marek Olšák  wrote:
>> Hi,
>>
>> It's been almost 4 months since the 12.0 branch was created, and soon
>> it will have been 3 months since Mesa 12.0 was released.
>>
>> Is there any reason we haven't created the stable branch yet?
>>
>> Ideally, we would time the release so that it's 1-2 months before fall
>> distribution releases.
>>
>
> Thanks Marek !
>
> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
> 12.1. With the topic of which would be 'the default' Vulkan driver for
> ATI/AMD hardware to be considered at a later stage.

btw, I pushed libdrm release that I think etnaviv was waiting for..
not sure what else is needed before merging etnaviv gallium driver,
but if at all possible, it would be nice to land that before the
branch point too.

BR,
-R

> That said here are the tentative dates:
>
> Oct 7/14 2016 - Feature freeze/Release candidate 1
> Oct 14/21 2016 - Release candidate 2
> Oct 21/28 2016 - Release candidate 3/final release
>
> Fwiw I'm still in favour of getting RADV in even if it's not
> perfect/feature complete. Devs, let me know if there's a "must have"
> feature that we want in 12.1.
>
> Thanks
> Emil
> ___
> 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: Only emit 1 viewport when possible.

[Ian Romanick]

Reviewed-by: Ian Romanick 

On 09/26/2016 11:23 AM, Kenneth Graunke wrote:
> In core profile, we support up to 16 viewports.  However, in the
> majority of cases, only 1 of them is actually used - we only need
> the others if the last shader stage prior to the rasterizer writes
> gl_ViewportIndex.
> 
> Processing all 16 viewports adds additional CPU overhead, which hurts
> CPU-intensive workloads such as Glamor.  This meant that switching to
> core profile actually penalized Glamor to an extent, which is
> unfortunate.
> 
> This patch tracks the number of relevant viewports, switching between
> 1 and ctx->Const.MaxViewports if gl_ViewportIndex is written.  A new
> BRW_NEW_VIEWPORT_COUNT flag tracks this.  This could mean re-emitting
> viewport state when switching, but hopefully this is offset by doing
> 1/16th of the work in the common case.  The new flag is also lighter
> weight than BRW_NEW_VUE_MAP_GEOM_OUT, which we were using in one case.
> 
> According to Eric Anholt, this reduces the CPU overhead of scissor and
> viewport state changes n Glamor from 2.5% or so to .8% or so.
> 
> Cc: Eric Anholt 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_cc.c  | 10 +++---
>  src/mesa/drivers/dri/i965/brw_context.c |  1 +
>  src/mesa/drivers/dri/i965/brw_context.h |  9 +
>  src/mesa/drivers/dri/i965/brw_gs_state.c|  6 --
>  src/mesa/drivers/dri/i965/brw_state_upload.c| 11 +++
>  src/mesa/drivers/dri/i965/gen6_clip_state.c | 16 +++-
>  src/mesa/drivers/dri/i965/gen6_scissor_state.c  | 10 +++---
>  src/mesa/drivers/dri/i965/gen6_viewport_state.c | 22 +++---
>  src/mesa/drivers/dri/i965/gen7_viewport_state.c | 10 +++---
>  src/mesa/drivers/dri/i965/gen8_viewport_state.c | 10 +++---
>  10 files changed, 75 insertions(+), 30 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_cc.c 
> b/src/mesa/drivers/dri/i965/brw_cc.c
> index 5c58b44..b11d7c8 100644
> --- a/src/mesa/drivers/dri/i965/brw_cc.c
> +++ b/src/mesa/drivers/dri/i965/brw_cc.c
> @@ -44,12 +44,15 @@ brw_upload_cc_vp(struct brw_context *brw)
> struct gl_context *ctx = >ctx;
> struct brw_cc_viewport *ccv;
>  
> +   /* BRW_NEW_VIEWPORT_COUNT */
> +   const unsigned viewport_count = brw->clip.viewport_count;
> +
> ccv = brw_state_batch(brw, AUB_TRACE_CC_VP_STATE,
> -  sizeof(*ccv) * ctx->Const.MaxViewports, 32,
> +  sizeof(*ccv) * viewport_count, 32,
>   >cc.vp_offset);
>  
> /* _NEW_TRANSFORM */
> -   for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
> +   for (unsigned i = 0; i < viewport_count; i++) {
>if (ctx->Transform.DepthClamp) {
>   /* _NEW_VIEWPORT */
>   ccv[i].min_depth = MIN2(ctx->ViewportArray[i].Near,
> @@ -77,7 +80,8 @@ const struct brw_tracked_state brw_cc_vp = {
>.mesa = _NEW_TRANSFORM |
>_NEW_VIEWPORT,
>.brw = BRW_NEW_BATCH |
> - BRW_NEW_BLORP,
> + BRW_NEW_BLORP |
> + BRW_NEW_VIEWPORT_COUNT,
> },
> .emit = brw_upload_cc_vp
>  };
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 6efad78..b0eec16 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -1085,6 +1085,7 @@ brwCreateContext(gl_api api,
> brw->prim_restart.enable_cut_index = false;
> brw->gs.enabled = false;
> brw->sf.viewport_transform_enable = true;
> +   brw->clip.viewport_count = 1;
>  
> brw->predicate.state = BRW_PREDICATE_STATE_RENDER;
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 00f0adc..b27fe51 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -226,6 +226,7 @@ enum brw_state_id {
> BRW_STATE_URB_SIZE,
> BRW_STATE_CC_STATE,
> BRW_STATE_BLORP,
> +   BRW_STATE_VIEWPORT_COUNT,
> BRW_NUM_STATE_BITS
>  };
>  
> @@ -294,6 +295,7 @@ enum brw_state_id {
>  #define BRW_NEW_PROGRAM_CACHE   (1ull << BRW_STATE_PROGRAM_CACHE)
>  #define BRW_NEW_STATE_BASE_ADDRESS  (1ull << 
> BRW_STATE_STATE_BASE_ADDRESS)
>  #define BRW_NEW_VUE_MAP_GEOM_OUT(1ull << BRW_STATE_VUE_MAP_GEOM_OUT)
> +#define BRW_NEW_VIEWPORT_COUNT  (1ull << BRW_STATE_VIEWPORT_COUNT)
>  #define BRW_NEW_TRANSFORM_FEEDBACK  (1ull << 
> BRW_STATE_TRANSFORM_FEEDBACK)
>  #define BRW_NEW_RASTERIZER_DISCARD  (1ull << 
> BRW_STATE_RASTERIZER_DISCARD)
>  #define BRW_NEW_STATS_WM(1ull << BRW_STATE_STATS_WM)
> @@ -1160,6 +1162,13 @@ struct brw_context
> * instead of vp_bo.
> */
>uint32_t vp_offset;
> +
> +  /**
> +   * The number of viewports to use.  If gl_ViewportIndex is written,
> +   * we can have 

[Mesa-dev] [PATCH] intel: use the correct format specifier for printing uint64_t

[Timothy Arceri]

Fixes a bunch of warnings in 32-bit builds.
---
 src/intel/tools/aubinator.c | 17 +
 src/intel/tools/decoder.c   |  7 ---
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index a31dcb2..9b32e5b 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -96,7 +97,7 @@ print_dword_val(struct gen_field_iterator *iter, uint64_t 
offset,
const int dword = f->start / 32;
 
if (*dword_num != dword) {
-  printf("0x%08lx:  0x%08x : Dword %d\n",
+  printf("0x%08"PRIx64":  0x%08x : Dword %d\n",
  offset + 4 * dword,  iter->p[dword], dword);
   *dword_num = dword;
}
@@ -296,10 +297,10 @@ handle_media_interface_descriptor_load(struct gen_spec 
*spec, uint32_t *p)
 
   start = instruction_base + descriptors[0];
   if (!valid_offset(start)) {
- printf("kernel: %08lx \n", start);
+ printf("kernel: %08"PRIx64" \n", start);
  continue;
   } else {
- printf("kernel: %08lx\n", start);
+ printf("kernel: %08"PRIx64"\n", start);
   }
 
   insns = (struct brw_instruction *) (gtt + start);
@@ -397,7 +398,7 @@ handle_3dstate_vs(struct gen_spec *spec, uint32_t *p)
}
 
if (vs_enable) {
-  printf("instruction_base %08lx, start %08lx\n",
+  printf("instruction_base %08"PRIx64", start %08"PRIx64"\n",
  instruction_base, start);
 
   insns = (struct brw_instruction *) (gtt + instruction_base + start);
@@ -421,7 +422,7 @@ handle_3dstate_hs(struct gen_spec *spec, uint32_t *p)
hs_enable = p[2] & 0x8000;
 
if (hs_enable) {
-  printf("instruction_base %08lx, start %08lx\n",
+  printf("instruction_base %08"PRIx64", start %08"PRIx64"\n",
  instruction_base, start);
 
   insns = (struct brw_instruction *) (gtt + instruction_base + start);
@@ -739,7 +740,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int 
size, int engine)
   else
  offset = 0;
 
-  printf("%s0x%08lx:  0x%08x:  %s%s\n",
+  printf("%s0x%08"PRIx64":  0x%08x:  %s%s\n",
  color, offset, p[0],
  gen_group_get_name(inst), reset_color);
 
@@ -754,7 +755,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int 
size, int engine)
 if (dword_num > 0)
 token = print_iterator_values(, );
 if (token != NULL) {
-printf("0x%08lx:  0x%08x : Dword %d\n",
+printf("0x%08"PRIx64":  0x%08x : Dword %d\n",
offset + 4 * idx, p[idx], idx);
 handle_struct_decode(spec,token, [idx]);
 token = NULL;
@@ -971,7 +972,7 @@ aub_file_decode_batch(struct aub_file *file, struct 
gen_spec *spec)
   break;
case MAKE_HEADER(TYPE_AUB, OPCODE_NEW_AUB, SUBOPCODE_MEM_WRITE):
   printf("memory write block (dwords %d):\n", h & 0x);
-  printf("  address 0x%lx\n", *(uint64_t *) [1]);
+  printf("  address 0x%"PRIx64"\n", *(uint64_t *) [1]);
   data_type = (p[3] >> 20) & 0xff;
   if (data_type != 0)
  printf("  data type 0x%x\n", data_type);
diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
index be3558b..4cbaab2 100644
--- a/src/intel/tools/decoder.c
+++ b/src/intel/tools/decoder.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -529,11 +530,11 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
case GEN_TYPE_UNKNOWN:
case GEN_TYPE_INT:
   snprintf(iter->value, sizeof(iter->value),
-   "%ld", field(v.qw, f->start, f->end));
+   "%"PRId64, field(v.qw, f->start, f->end));
   break;
case GEN_TYPE_UINT:
   snprintf(iter->value, sizeof(iter->value),
-   "%lu", field(v.qw, f->start, f->end));
+   "%"PRIu64, field(v.qw, f->start, f->end));
   break;
case GEN_TYPE_BOOL:
   snprintf(iter->value, sizeof(iter->value),
@@ -545,7 +546,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
case GEN_TYPE_ADDRESS:
case GEN_TYPE_OFFSET:
   snprintf(iter->value, sizeof(iter->value),
-   "0x%08lx", field_address(v.qw, f->start, f->end));
+   "0x%08"PRIx64, field_address(v.qw, f->start, f->end));
   break;
case GEN_TYPE_STRUCT:
   snprintf(iter->value, sizeof(iter->value),
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH V2 09/11] genX/cmd_buffer: Enable rendering to HiZ

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery  wrote:

> From: Chad Versace 
>
> Nanley Chery:
> (rebase)
>  - Resolve conflicts with new anv_batch_emit macro
> (amend)
>  - Handle a QPitch TODO
>  - Emit 3DSTATE_HIER_DEPTH_BUFFER on pre-BDW systems
>  - Only use HiZ for single-subpass renderpasses
>  - Emit the HiZ instruction before the stencil instruction to follow the
>optimized clear sequence specified in the PRMs
>  - Don't modify clear params
>  - Enable resolves when a HiZ buffer is used to ensure depth buffer
> validity
>
> Provides an FPS increase of ~15% on the Sascha triangle and multisampling
> demos.
>
> Signed-off-by: Nanley Chery 
>
> ---
>
> v2: Emit zero'ed 3DSTATE_HIER_DEPTH_BUFFER when hiz is disabled
> (Jason, Chad)
>
>  src/intel/vulkan/gen8_cmd_buffer.c |  4 
>  src/intel/vulkan/genX_cmd_buffer.c | 43 ++
> 
>  2 files changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> b/src/intel/vulkan/gen8_cmd_buffer.c
> index a13413c..14e6a7b 100644
> --- a/src/intel/vulkan/gen8_cmd_buffer.c
> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> @@ -417,6 +417,10 @@ genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer
> *cmd_buffer,
> if (iview == NULL || !anv_image_has_hiz(iview->image))
>return;
>
> +   /* FIXME: Implement multi-subpass HiZ */
> +   if (cmd_buffer->state.pass->subpass_count > 1)
> +  return;
> +
> const uint32_t ds = cmd_state->subpass->depth_stencil_attachment;
> const bool full_surface_op =
>   cmd_state->render_area.extent.width == iview->extent.width
> &&
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 6a84383..2cb1539 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -1199,6 +1199,7 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer
> *cmd_buffer)
>anv_cmd_buffer_get_depth_stencil_view(cmd_buffer);
> const struct anv_image *image = iview ? iview->image : NULL;
> const bool has_depth = image && (image->aspects &
> VK_IMAGE_ASPECT_DEPTH_BIT);
> +   const bool has_hiz = image != NULL && anv_image_has_hiz(image);
> const bool has_stencil =
>image && (image->aspects & VK_IMAGE_ASPECT_STENCIL_BIT);
>
> @@ -1211,7 +1212,12 @@ cmd_buffer_emit_depth_stencil(struct
> anv_cmd_buffer *cmd_buffer)
>   db.SurfaceType   = SURFTYPE_2D;
>   db.DepthWriteEnable  = true;
>   db.StencilWriteEnable= has_stencil;
> - db.HierarchicalDepthBufferEnable = false;
> +
> + if (cmd_buffer->state.pass->subpass_count == 1) {
> +db.HierarchicalDepthBufferEnable = has_hiz;
> + } else {
> +anv_finishme("Multiple-subpass HiZ not implemented");
> + }
>
>   db.SurfaceFormat = isl_surf_get_depth_format(>isl_dev,
>
>  >depth_surface.isl);
> @@ -1263,6 +1269,36 @@ cmd_buffer_emit_depth_stencil(struct
> anv_cmd_buffer *cmd_buffer)
>}
> }
>
> +   if (has_hiz) {
> +  anv_batch_emit(_buffer->batch, GENX(3DSTATE_HIER_DEPTH_BUFFER),
> hdb) {
> + hdb.HierarchicalDepthBufferObjectControlState = GENX(MOCS);
> + hdb.SurfacePitch = image->hiz_surface.isl.row_pitch - 1;
> + hdb.SurfaceBaseAddress = (struct anv_address) {
> +.bo = image->bo,
> +.offset = image->offset + image->hiz_surface.offset,
> + };
> +#if GEN_GEN >= 8
> + /* From the SKL PRM Vol2a:
> +  *
> +  *The interpretation of this field is dependent on Surface
> Type
> +  *as follows:
> +  *- SURFTYPE_1D: distance in pixels between array slices
> +  *- SURFTYPE_2D/CUBE: distance in rows between array slices
> +  *- SURFTYPE_3D: distance in rows between R - slices
> +  *
> +  * ISL implements HiZ surfaces for 1D depth buffers as 2D.
> Therefore
> +  * the depth buffer needs to be checked for the dimension.
> +  */
> + hdb.SurfaceQPitch =
> +image->depth_surface.isl.dim == ISL_SURF_DIM_1D ?
> +   isl_surf_get_array_pitch_el(>hiz_surface.isl) >> 2
> :
> +   isl_surf_get_array_pitch_el_rows(>hiz_surface.isl)
> >> 2;
> +#endif
> +  }
> +   } else {
> +  anv_batch_emit(_buffer->batch, GENX(3DSTATE_HIER_DEPTH_BUFFER),
> hdb);
> +   }
> +
> /* Emit 3DSTATE_STENCIL_BUFFER */
> if (has_stencil) {
>anv_batch_emit(_buffer->batch, GENX(3DSTATE_STENCIL_BUFFER),
> sb) {
> @@ -1285,9 +1321,6 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer
> *cmd_buffer)
>anv_batch_emit(_buffer->batch, GENX(3DSTATE_STENCIL_BUFFER),
> sb);
> }
>
> -   /* Disable hierarchial depth buffers. */
> -   anv_batch_emit(_buffer->batch, 

[Mesa-dev] [PATCH] aubinator: Use less -RS instead of -r for the implicit pager.

[Kenneth Graunke]

From the less man page:

   "Warning: when the -r option is used, less cannot keep track of the
actual appearance  of  the screen (since this depends  on  how the
screen responds to each type of control character).  Thus, various
display problems may result, such as long lines being split in the
wrong place."

Lines which are too long to fit in the terminal would be word wrapped,
but unfortunately less would get confused about which line it was on,
and text would be drawn on top of other text.  The most noticable case
was shader assembly, which is frequently too wide for an 80 character
terminal, and thus would be drawn on top of the following state packets,
making them completely unreadable.

Using -R instead of -r fixes this problem by only allowing color escape
sequences.  (Notably, Git's implicit pager invocation uses -R.)
Unfortunately, it means our "clear to the end of the line" hack for
extending the blue bar headers won't work anymore.

Word wrapping usually isn't terribly readable, anyway, so we also add
the -S option (chop long lines) to restrict it to the terminal width.
(You can hit the left and right arrow keys to scroll sideways.)

Then, for a new blue bar hack, we can use a printf specifier to pad
the command packet names to be 80 characters long (arbitrarily), which
extends them "far enough" to look good, and doesn't require us to use
ioctls to determine the terminal width.

Signed-off-by: Kenneth Graunke 
---
 src/intel/tools/aubinator.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index a31dcb2..5666fe3 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -48,7 +48,6 @@
 #define CSI "\e["
 #define HEADER CSI "37;44m"
 #define NORMAL CSI "0m"
-#define CLEAR_TO_EOL CSI "0K"
 
 /* options */
 
@@ -721,7 +720,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int 
size, int engine)
   }
   length = gen_group_get_length(inst, p);
 
-  const char *color, *reset_color = CLEAR_TO_EOL NORMAL;
+  const char *color, *reset_color = NORMAL;
   uint64_t offset;
 
   if (option_full_decode)
@@ -739,7 +738,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int 
size, int engine)
   else
  offset = 0;
 
-  printf("%s0x%08lx:  0x%08x:  %s%s\n",
+  printf("%s0x%08lx:  0x%08x:  %-80s%s\n",
  color, offset, p[0],
  gen_group_get_name(inst), reset_color);
 
@@ -1013,7 +1012,7 @@ setup_pager(void)
if (pid == 0) {
   close(fds[1]);
   dup2(fds[0], 0);
-  execlp("less", "less", "-rFi", NULL);
+  execlp("less", "less", "-FRSi", NULL);
}
 
close(fds[0]);
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH 2/2] radv: Add new flag for LLVM dependecies with vulkan

[Dave Airlie]

On 3 October 2016 at 05:45, Tobias Droste  wrote:
> This reuse the same logic gallium uses to determine if LLVM is needed or
> not:
> --enable-vulkan-llvm is set to yes if at least one vulkan driver is
> active and the host is i3*6 or x86_64.
> To build vulkan drivers without LLVM (e.g. intel) one has to add
> --disable-vulkan-llvm.
>
> In order to make this all work the vulkan driver check has to move
> either diretcly below or directly above the gallium driver checks.
> Move them below the gallium driver stuff.

I don't think basing this on gallium is correct, as gallium is used across
dirvers, the vulkan drivers are pretty separate at this point, so it should
just be a per driver check for llvm, not a vulkan level one.

I'll try and clean things up today in there before proposing for master.

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

[Mesa-dev] [PATCH] spirv: replace assert() with unreachable()

[Timothy Arceri]

This fixes an uninitialized warning for is_vertex_input.
---
 src/compiler/spirv/vtn_variables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 43bb3bc..f431c6f 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1054,7 +1054,7 @@ var_decoration_cb(struct vtn_builder *b, struct vtn_value 
*val, int member,
  is_vertex_input = false;
  location += VARYING_SLOT_VAR0;
   } else {
- assert(!"Location must be on input or output variable");
+ unreachable("Location must be on input or output variable");
   }
 
   if (vtn_var->var) {
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH V2 08/11] anv/cmd_buffer: Add code for performing HZ operations

[Jason Ekstrand]

On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery  wrote:

> Create a function that performs one of three HiZ operations -
> depth/stencil clears, HiZ resolve, and depth resolves.
>
> Signed-off-by: Nanley Chery 
>
> ---
>
> v2. Add documentation
> Fix the alignment check
> Don't minify clear rectangle (Jason)
> Use blorp enums (Jason)
> Enable depth stalls and flushes
> Use full RT rectangle for resolve ops
> Add stencil clear todo
>
>  src/intel/vulkan/anv_genX.h|   3 +
>  src/intel/vulkan/gen7_cmd_buffer.c |   6 ++
>  src/intel/vulkan/gen8_cmd_buffer.c | 167 ++
> +++
>  3 files changed, 176 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> index 02e79c2..ad3bec9 100644
> --- a/src/intel/vulkan/anv_genX.h
> +++ b/src/intel/vulkan/anv_genX.h
> @@ -58,6 +58,9 @@ genX(emit_urb_setup)(struct anv_device *device, struct
> anv_batch *batch,
>   unsigned vs_entry_size, unsigned gs_entry_size,
>   const struct gen_l3_config *l3_config);
>
> +void genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer *cmd_buffer,
> +   enum blorp_hiz_op op);
> +
>  VkResult
>  genX(graphics_pipeline_create)(VkDevice _device,
> struct anv_pipeline_cache *cache,
> diff --git a/src/intel/vulkan/gen7_cmd_buffer.c
> b/src/intel/vulkan/gen7_cmd_buffer.c
> index b627ef0..78b5ac7 100644
> --- a/src/intel/vulkan/gen7_cmd_buffer.c
> +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> @@ -323,6 +323,12 @@ genX(cmd_buffer_flush_dynamic_state)(struct
> anv_cmd_buffer *cmd_buffer)
> cmd_buffer->state.dirty = 0;
>  }
>
> +void
> +genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer *cmd_buffer,
> +  enum blorp_hiz_op op)
> +{
>

This should have an anv_finishme in it.


> +}
> +
>  void genX(CmdSetEvent)(
>  VkCommandBuffer commandBuffer,
>  VkEvent event,
> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> b/src/intel/vulkan/gen8_cmd_buffer.c
> index 7058608..a13413c 100644
> --- a/src/intel/vulkan/gen8_cmd_buffer.c
> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> @@ -399,6 +399,173 @@ genX(cmd_buffer_flush_compute_state)(struct
> anv_cmd_buffer *cmd_buffer)
> genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
>  }
>
> +
> +/**
> + * Emit the HZ_OP packet in the sequence specified by the BDW PRM section
> + * entitled: "Optimized Depth Buffer Clear and/or Stencil Buffer Clear."
> + *
> + * \todo Enable Stencil Buffer-only clears
> + */
> +void
> +genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer *cmd_buffer,
> +  enum blorp_hiz_op op)
> +{
> +   struct anv_cmd_state *cmd_state = _buffer->state;
> +   const struct anv_image_view *iview =
> +  anv_cmd_buffer_get_depth_stencil_view(cmd_buffer);
> +
> +   if (iview == NULL || !anv_image_has_hiz(iview->image))
> +  return;
> +
> +   const uint32_t ds = cmd_state->subpass->depth_stencil_attachment;
> +   const bool full_surface_op =
> + cmd_state->render_area.extent.width == iview->extent.width
> &&
> + cmd_state->render_area.extent.height ==
> iview->extent.height;
>

It's probably a bit redundant, but we might as well check
render_area.offset == 0.  I realize that, from API requirements, if the
extents match then offset must be 0, but it's not incredibly obvious and
the check won't hurt that much.


> +
> +   /* Validate that we can perform the HZ operation and that it's
> necessary. */
> +   switch (op) {
> +   case BLORP_HIZ_OP_DEPTH_CLEAR:
> +  if (cmd_buffer->state.pass->attachments[ds].load_op !=
> +  VK_ATTACHMENT_LOAD_OP_CLEAR)
> + return;
> +
> +  /* Apply alignment restrictions. Despite the BDW PRM mentioning
> this is
> +   * only needed for a depth buffer surface type of D16_UNORM, testing
> +   * showed it to be necessary for other depth formats as well
> +   * (e.g., D32_FLOAT).
> +   */
> +  if (!full_surface_op) {
> +
> + struct isl_extent2d px_dim;
>

Would it be better to call this hiz_block_size_px?  That follows the ISL
naming convention a bit better.


> +#if GEN_GEN == 8
>

Mind making this <= 8?  I know it's in a gen8+ file, but <= 8 makes it
clear that the else case is >= 9 and not != 8.


> + /* Pre-SKL, HiZ has an 8x4 sample block. As the number of samples
> +  * increases, the number of pixels representable by this block
> +  * decreases by a factor of the sample dimensions. Sample
> dimensions
> +  * scale following the MSAA interleaved pattern.
> +  *
> +  * Sample|Sample|Pixel
> +  * Count |Dim   |Dim
> +  * ===
> +  *1  | 1x1  | 8x4
> +  *2  | 2x1  | 4x4
> +  *4  | 2x2  | 4x2
> +  *8  | 4x2  | 2x2
> +  *   16 

[Mesa-dev] [PATCH 3/5] i965: wrap unused function in #ifndef NDEBUG

[Timothy Arceri]

This function is only ever used by an assert() this fixes an
unused function warning in release builds.
---
 src/mesa/drivers/dri/i965/gen8_draw_upload.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/gen8_draw_upload.c 
b/src/mesa/drivers/dri/i965/gen8_draw_upload.c
index d2c7853..7196266 100644
--- a/src/mesa/drivers/dri/i965/gen8_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/gen8_draw_upload.c
@@ -34,6 +34,7 @@
 #include "intel_batchbuffer.h"
 #include "intel_buffer_objects.h"
 
+#ifndef NDEBUG
 static bool
 is_passthru_format(uint32_t format)
 {
@@ -47,6 +48,7 @@ is_passthru_format(uint32_t format)
   return false;
}
 }
+#endif
 
 static void
 gen8_emit_vertices(struct brw_context *brw)
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/5] i965: wrap unused variable in #ifndef NDEBUG

[Timothy Arceri]

Fixes unused variable warning in release build.
---
 src/mesa/drivers/dri/i965/brw_tcs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c 
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 1f1b1a5..01500e0 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -364,9 +364,11 @@ brw_upload_tcs_prog(struct brw_context *brw)
/* BRW_NEW_TESS_PROGRAMS */
struct brw_tess_ctrl_program *tcp =
   (struct brw_tess_ctrl_program *) brw->tess_ctrl_program;
+#ifndef NDEBUG
struct brw_tess_eval_program *tep =
   (struct brw_tess_eval_program *) brw->tess_eval_program;
assert(tep);
+#endif
 
if (!brw_state_dirty(brw,
 _NEW_TEXTURE,
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/5] i965: fix unused variable warning in gen7_block_read_scratch()

[Timothy Arceri]

---
 src/mesa/drivers/dri/i965/brw_eu_emit.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index c98867a..cfb3fa0 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2262,9 +2262,8 @@ gen7_block_read_scratch(struct brw_codegen *p,
 int num_regs,
 unsigned offset)
 {
-   const struct gen_device_info *devinfo = p->devinfo;
brw_inst *insn = next_insn(p, BRW_OPCODE_SEND);
-   assert(brw_inst_pred_control(devinfo, insn) == BRW_PREDICATE_NONE);
+   assert(brw_inst_pred_control(p->devinfo, insn) == BRW_PREDICATE_NONE);
 
brw_set_dest(p, insn, retype(dest, BRW_REGISTER_TYPE_UW));
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/5] i965: wrap assert param in #ifndef NDEBUG

[Timothy Arceri]

This fixes an unused variable warning on release builds.
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index dc000d9..ccf311d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -5866,7 +5866,9 @@ fs_visitor::allocate_registers(bool allow_spilling)
schedule_instructions(SCHEDULE_POST);
 
if (last_scratch > 0) {
+#ifndef NDEBUG
   unsigned max_scratch_size = 2 * 1024 * 1024;
+#endif
 
   prog_data->total_scratch = brw_get_scratch_size(last_scratch);
 
@@ -5884,7 +5886,9 @@ fs_visitor::allocate_registers(bool allow_spilling)
  * size linearly with a range of [1kB, 12kB] and 1kB granularity.
  */
 prog_data->total_scratch = ALIGN(last_scratch, 1024);
+#ifndef NDEBUG
 max_scratch_size = 12 * 1024;
+#endif
  }
   }
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/5] i965: fix unused variable warning in brw_emit_gpgpu_walker()

[Timothy Arceri]

---
 src/mesa/drivers/dri/i965/brw_compute.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compute.c 
b/src/mesa/drivers/dri/i965/brw_compute.c
index cde3bad..d1d39d3 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -116,7 +116,6 @@ static void
 brw_emit_gpgpu_walker(struct brw_context *brw)
 {
const struct brw_cs_prog_data *prog_data = brw->cs.prog_data;
-   const struct gen_device_info *devinfo = >screen->devinfo;
 
const GLuint *num_groups = brw->compute.num_work_groups;
uint32_t indirect_flag;
@@ -149,7 +148,7 @@ brw_emit_gpgpu_walker(struct brw_context *brw)
   OUT_BATCH(0); /* Indirect Data Length */
   OUT_BATCH(0); /* Indirect Data Start Address */
}
-   assert(thread_width_max <= devinfo->max_cs_threads);
+   assert(thread_width_max <= brw->screen->devinfo.max_cs_threads);
OUT_BATCH(SET_FIELD(simd_size / 16, GPGPU_WALKER_SIMD_SIZE) |
  SET_FIELD(thread_width_max - 1, GPGPU_WALKER_THREAD_WIDTH_MAX));
OUT_BATCH(0);/* Thread Group ID Starting X */
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Roland Scheidegger]

The reason I don't like this isn't really the number of callers, rather
that the driver is going actively against what the state tracker told it
to do. But I'm not strongly opposed to this, since effectively
restricting the next field to be only valid if the resource is created
externally might be a good idea on its own...
Albeit zero-initializing in the state tracker has the advantage that if
resource struct is going to be extended again it would work too.
(Technically, there's no need that the template and the actual resource
struct being the same it just makes things easier - with d3d10 in the
driver interface you basically only have the templates since the drivers
just return pointers to void.)

Roland

Am 04.10.2016 um 01:55 schrieb Marek Olšák:
> BTW, I think fixing this in drivers is better, because the number of
> resource_create implementations is limited and they are easy to find.
> 
> Marek
> 
> On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger  wrote:
>> Sounds reasonable to me.
>>
>> Roland
>>
>> Am 04.10.2016 um 01:44 schrieb Rob Clark:
>>> There are a lot of callers for ->resource_create() and friends..
>>> although I suspect it is a small subset that don't zero-init.  But
>>> I'll have to go through all the call sites and check, but I didn't yet
>>> find time yet to do that today..
>>>
>>> I don't want to annoy too many folks w/ broken piglits, so if anyone
>>> is impatient I can push the current patch, and then squash a revert
>>> into a patch that fixes up the ->resource_create()/etc callers if that
>>> turns out to be the more reasonable thing..
>>>
>>> BR,
>>> -R
>>>
>>> On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger  
>>> wrote:
 In an ideal world everybody would zero-intialize the template I suppose
 - then it would easily survive such interface changes.
 I thought though there shouldn't be many callers but I might have been
 wrong about this...

 Roland


 Am 03.10.2016 um 18:48 schrieb Rob Clark:
> the interface is a bit hand-wavey, ie. w/ things like prsc->screen
> overwriten by driver..  I guess I can try to track down the
> screen->resource_create() callers that aren't zero-init'ing the templ,
> although the # of callers seemed much higher than # of drivers
>
> BR,
> -R
>
> On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger  
> wrote:
>> I don't think that's really a good idea. Zero-initializing things is one
>> thing, but explicitly overwrite things which were given to the driver by
>> the st is something else.
>> (I'm not even sure how it works if the driver always overwrites this to
>> zero no matter what. Well I suppose those are the consequences of an
>> interface hack.)
>>
>> I'd say state trackers should be fixed up and call it a day.
>>
>> Roland
>>
>>
>> Am 03.10.2016 um 18:07 schrieb Rob Clark:
>>> Fix potential issues if state-tracker passes in garbage in templ->next
>>> ptr.
>>>
>>> See:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns=
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
>>>  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
>>>  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
>>>  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
>>>  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
>>>  src/gallium/drivers/noop/noop_pipe.c   | 1 +
>>>  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
>>>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
>>>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
>>>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
>>>  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
>>>  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
>>>  src/gallium/drivers/rbug/rbug_objects.c| 1 +
>>>  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
>>>  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
>>>  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
>>>  src/gallium/drivers/swr/swr_screen.cpp | 1 +
>>>  src/gallium/drivers/trace/tr_texture.c | 1 +
>>>  src/gallium/drivers/vc4/vc4_resource.c | 1 +
>>>  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
>>>  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
>>>  21 files changed, 30 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Rob Clark]

I know we do at least have an etnaviv gallium driver hanging out there
waiting to be merged, and don't want to cause them unnecessary rebase
pain.. so if $num_of_callsites_to_fix < $num_of_gallium_drivers, I
don't mind fixing it at the call sites.. but I'll have to audit a
whole bunch of call-sites first to know..

BR,
-R

On Mon, Oct 3, 2016 at 7:55 PM, Marek Olšák  wrote:
> BTW, I think fixing this in drivers is better, because the number of
> resource_create implementations is limited and they are easy to find.
>
> Marek
>
> On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger  wrote:
>> Sounds reasonable to me.
>>
>> Roland
>>
>> Am 04.10.2016 um 01:44 schrieb Rob Clark:
>>> There are a lot of callers for ->resource_create() and friends..
>>> although I suspect it is a small subset that don't zero-init.  But
>>> I'll have to go through all the call sites and check, but I didn't yet
>>> find time yet to do that today..
>>>
>>> I don't want to annoy too many folks w/ broken piglits, so if anyone
>>> is impatient I can push the current patch, and then squash a revert
>>> into a patch that fixes up the ->resource_create()/etc callers if that
>>> turns out to be the more reasonable thing..
>>>
>>> BR,
>>> -R
>>>
>>> On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger  
>>> wrote:
 In an ideal world everybody would zero-intialize the template I suppose
 - then it would easily survive such interface changes.
 I thought though there shouldn't be many callers but I might have been
 wrong about this...

 Roland


 Am 03.10.2016 um 18:48 schrieb Rob Clark:
> the interface is a bit hand-wavey, ie. w/ things like prsc->screen
> overwriten by driver..  I guess I can try to track down the
> screen->resource_create() callers that aren't zero-init'ing the templ,
> although the # of callers seemed much higher than # of drivers
>
> BR,
> -R
>
> On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger  
> wrote:
>> I don't think that's really a good idea. Zero-initializing things is one
>> thing, but explicitly overwrite things which were given to the driver by
>> the st is something else.
>> (I'm not even sure how it works if the driver always overwrites this to
>> zero no matter what. Well I suppose those are the consequences of an
>> interface hack.)
>>
>> I'd say state trackers should be fixed up and call it a day.
>>
>> Roland
>>
>>
>> Am 03.10.2016 um 18:07 schrieb Rob Clark:
>>> Fix potential issues if state-tracker passes in garbage in templ->next
>>> ptr.
>>>
>>> See:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns=
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
>>>  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
>>>  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
>>>  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
>>>  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
>>>  src/gallium/drivers/noop/noop_pipe.c   | 1 +
>>>  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
>>>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
>>>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
>>>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
>>>  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
>>>  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
>>>  src/gallium/drivers/rbug/rbug_objects.c| 1 +
>>>  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
>>>  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
>>>  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
>>>  src/gallium/drivers/swr/swr_screen.cpp | 1 +
>>>  src/gallium/drivers/trace/tr_texture.c | 1 +
>>>  src/gallium/drivers/vc4/vc4_resource.c | 1 +
>>>  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
>>>  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
>>>  21 files changed, 30 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
>>> b/src/gallium/drivers/freedreno/freedreno_resource.c
>>> index 1874271..2f37fae 100644
>>> --- a/src/gallium/drivers/freedreno/freedreno_resource.c
>>> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
>>> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
>>>   return NULL;
>>>
>>>   

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Marek Olšák]

BTW, I think fixing this in drivers is better, because the number of
resource_create implementations is limited and they are easy to find.

Marek

On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger  wrote:
> Sounds reasonable to me.
>
> Roland
>
> Am 04.10.2016 um 01:44 schrieb Rob Clark:
>> There are a lot of callers for ->resource_create() and friends..
>> although I suspect it is a small subset that don't zero-init.  But
>> I'll have to go through all the call sites and check, but I didn't yet
>> find time yet to do that today..
>>
>> I don't want to annoy too many folks w/ broken piglits, so if anyone
>> is impatient I can push the current patch, and then squash a revert
>> into a patch that fixes up the ->resource_create()/etc callers if that
>> turns out to be the more reasonable thing..
>>
>> BR,
>> -R
>>
>> On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger  
>> wrote:
>>> In an ideal world everybody would zero-intialize the template I suppose
>>> - then it would easily survive such interface changes.
>>> I thought though there shouldn't be many callers but I might have been
>>> wrong about this...
>>>
>>> Roland
>>>
>>>
>>> Am 03.10.2016 um 18:48 schrieb Rob Clark:
 the interface is a bit hand-wavey, ie. w/ things like prsc->screen
 overwriten by driver..  I guess I can try to track down the
 screen->resource_create() callers that aren't zero-init'ing the templ,
 although the # of callers seemed much higher than # of drivers

 BR,
 -R

 On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger  
 wrote:
> I don't think that's really a good idea. Zero-initializing things is one
> thing, but explicitly overwrite things which were given to the driver by
> the st is something else.
> (I'm not even sure how it works if the driver always overwrites this to
> zero no matter what. Well I suppose those are the consequences of an
> interface hack.)
>
> I'd say state trackers should be fixed up and call it a day.
>
> Roland
>
>
> Am 03.10.2016 um 18:07 schrieb Rob Clark:
>> Fix potential issues if state-tracker passes in garbage in templ->next
>> ptr.
>>
>> See:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns=
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
>>  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
>>  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
>>  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
>>  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
>>  src/gallium/drivers/noop/noop_pipe.c   | 1 +
>>  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
>>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
>>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
>>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
>>  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
>>  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
>>  src/gallium/drivers/rbug/rbug_objects.c| 1 +
>>  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
>>  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
>>  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
>>  src/gallium/drivers/swr/swr_screen.cpp | 1 +
>>  src/gallium/drivers/trace/tr_texture.c | 1 +
>>  src/gallium/drivers/vc4/vc4_resource.c | 1 +
>>  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
>>  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
>>  21 files changed, 30 insertions(+)
>>
>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
>> b/src/gallium/drivers/freedreno/freedreno_resource.c
>> index 1874271..2f37fae 100644
>> --- a/src/gallium/drivers/freedreno/freedreno_resource.c
>> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
>> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
>>   return NULL;
>>
>>   *prsc = *tmpl;
>> + prsc->next = NULL;
>>
>>   pipe_reference_init(>reference, 1);
>>
>> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
>>   return NULL;
>>
>>   *prsc = *tmpl;
>> + prsc->next = NULL;
>>
>>   pipe_reference_init(>reference, 1);
>>
>> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c 
>> b/src/gallium/drivers/i915/i915_resource_buffer.c
>> index 

Re: [Mesa-dev] [PATCH 2/2] mesa: Raise INVALID_ENUM in FramebufferTexture*D for unknown textargets.

[Timothy Arceri]

Both are:

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

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Roland Scheidegger]

Sounds reasonable to me.

Roland

Am 04.10.2016 um 01:44 schrieb Rob Clark:
> There are a lot of callers for ->resource_create() and friends..
> although I suspect it is a small subset that don't zero-init.  But
> I'll have to go through all the call sites and check, but I didn't yet
> find time yet to do that today..
> 
> I don't want to annoy too many folks w/ broken piglits, so if anyone
> is impatient I can push the current patch, and then squash a revert
> into a patch that fixes up the ->resource_create()/etc callers if that
> turns out to be the more reasonable thing..
> 
> BR,
> -R
> 
> On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger  
> wrote:
>> In an ideal world everybody would zero-intialize the template I suppose
>> - then it would easily survive such interface changes.
>> I thought though there shouldn't be many callers but I might have been
>> wrong about this...
>>
>> Roland
>>
>>
>> Am 03.10.2016 um 18:48 schrieb Rob Clark:
>>> the interface is a bit hand-wavey, ie. w/ things like prsc->screen
>>> overwriten by driver..  I guess I can try to track down the
>>> screen->resource_create() callers that aren't zero-init'ing the templ,
>>> although the # of callers seemed much higher than # of drivers
>>>
>>> BR,
>>> -R
>>>
>>> On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger  
>>> wrote:
 I don't think that's really a good idea. Zero-initializing things is one
 thing, but explicitly overwrite things which were given to the driver by
 the st is something else.
 (I'm not even sure how it works if the driver always overwrites this to
 zero no matter what. Well I suppose those are the consequences of an
 interface hack.)

 I'd say state trackers should be fixed up and call it a day.

 Roland


 Am 03.10.2016 um 18:07 schrieb Rob Clark:
> Fix potential issues if state-tracker passes in garbage in templ->next
> ptr.
>
> See:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns=
>
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
>  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
>  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
>  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
>  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
>  src/gallium/drivers/noop/noop_pipe.c   | 1 +
>  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
>  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
>  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
>  src/gallium/drivers/rbug/rbug_objects.c| 1 +
>  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
>  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
>  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
>  src/gallium/drivers/swr/swr_screen.cpp | 1 +
>  src/gallium/drivers/trace/tr_texture.c | 1 +
>  src/gallium/drivers/vc4/vc4_resource.c | 1 +
>  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
>  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
>  21 files changed, 30 insertions(+)
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
> b/src/gallium/drivers/freedreno/freedreno_resource.c
> index 1874271..2f37fae 100644
> --- a/src/gallium/drivers/freedreno/freedreno_resource.c
> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
>   return NULL;
>
>   *prsc = *tmpl;
> + prsc->next = NULL;
>
>   pipe_reference_init(>reference, 1);
>
> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
>   return NULL;
>
>   *prsc = *tmpl;
> + prsc->next = NULL;
>
>   pipe_reference_init(>reference, 1);
>
> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c 
> b/src/gallium/drivers/i915/i915_resource_buffer.c
> index 2572fc4..038b1bb 100644
> --- a/src/gallium/drivers/i915/i915_resource_buffer.c
> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
> @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen,
>return NULL;
>
> buf->b.b = *template;
> +   buf->b.b.next = NULL;
> buf->b.vtbl = 

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Rob Clark]

There are a lot of callers for ->resource_create() and friends..
although I suspect it is a small subset that don't zero-init.  But
I'll have to go through all the call sites and check, but I didn't yet
find time yet to do that today..

I don't want to annoy too many folks w/ broken piglits, so if anyone
is impatient I can push the current patch, and then squash a revert
into a patch that fixes up the ->resource_create()/etc callers if that
turns out to be the more reasonable thing..

BR,
-R

On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger  wrote:
> In an ideal world everybody would zero-intialize the template I suppose
> - then it would easily survive such interface changes.
> I thought though there shouldn't be many callers but I might have been
> wrong about this...
>
> Roland
>
>
> Am 03.10.2016 um 18:48 schrieb Rob Clark:
>> the interface is a bit hand-wavey, ie. w/ things like prsc->screen
>> overwriten by driver..  I guess I can try to track down the
>> screen->resource_create() callers that aren't zero-init'ing the templ,
>> although the # of callers seemed much higher than # of drivers
>>
>> BR,
>> -R
>>
>> On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger  
>> wrote:
>>> I don't think that's really a good idea. Zero-initializing things is one
>>> thing, but explicitly overwrite things which were given to the driver by
>>> the st is something else.
>>> (I'm not even sure how it works if the driver always overwrites this to
>>> zero no matter what. Well I suppose those are the consequences of an
>>> interface hack.)
>>>
>>> I'd say state trackers should be fixed up and call it a day.
>>>
>>> Roland
>>>
>>>
>>> Am 03.10.2016 um 18:07 schrieb Rob Clark:
 Fix potential issues if state-tracker passes in garbage in templ->next
 ptr.

 See:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns=

 Signed-off-by: Rob Clark 
 ---
  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
  src/gallium/drivers/noop/noop_pipe.c   | 1 +
  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
  src/gallium/drivers/rbug/rbug_objects.c| 1 +
  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
  src/gallium/drivers/swr/swr_screen.cpp | 1 +
  src/gallium/drivers/trace/tr_texture.c | 1 +
  src/gallium/drivers/vc4/vc4_resource.c | 1 +
  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
  21 files changed, 30 insertions(+)

 diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
 b/src/gallium/drivers/freedreno/freedreno_resource.c
 index 1874271..2f37fae 100644
 --- a/src/gallium/drivers/freedreno/freedreno_resource.c
 +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
 @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
   return NULL;

   *prsc = *tmpl;
 + prsc->next = NULL;

   pipe_reference_init(>reference, 1);

 @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
   return NULL;

   *prsc = *tmpl;
 + prsc->next = NULL;

   pipe_reference_init(>reference, 1);

 diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c 
 b/src/gallium/drivers/i915/i915_resource_buffer.c
 index 2572fc4..038b1bb 100644
 --- a/src/gallium/drivers/i915/i915_resource_buffer.c
 +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
 @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen,
return NULL;

 buf->b.b = *template;
 +   buf->b.b.next = NULL;
 buf->b.vtbl = _buffer_vtbl;
 pipe_reference_init(>b.b.reference, 1);
 buf->b.b.screen = screen;
 diff --git a/src/gallium/drivers/i915/i915_resource_texture.c 
 

[Mesa-dev] [PATCH 1/2] mesa: Reorganize check_textarget().

[Kenneth Graunke]

Having one top-level switch statement covering all known texture targets
will make the next change easier to implement.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/main/fbobject.c | 80 ++--
 1 file changed, 37 insertions(+), 43 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 09da6b7..f8899e6 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2991,54 +2991,48 @@ check_textarget(struct gl_context *ctx, int dims, 
GLenum target,
 {
bool err = false;
 
-   switch (dims) {
-   case 1:
-  switch (textarget) {
-  case GL_TEXTURE_1D:
- break;
-  case GL_TEXTURE_1D_ARRAY:
- err = !ctx->Extensions.EXT_texture_array;
- break;
-  default:
- err = true;
-  }
+   switch (textarget) {
+   case GL_TEXTURE_1D:
+  err = dims != 1;
   break;
-   case 2:
-  switch (textarget) {
-  case GL_TEXTURE_2D:
- break;
-  case GL_TEXTURE_RECTANGLE:
- err = _mesa_is_gles(ctx)
-|| !ctx->Extensions.NV_texture_rectangle;
- break;
-  case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
-  case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
-  case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
-  case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
-  case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
-  case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
- err = !ctx->Extensions.ARB_texture_cube_map;
- break;
-  case GL_TEXTURE_2D_ARRAY:
- err = (_mesa_is_gles(ctx) && ctx->Version < 30)
-   || !ctx->Extensions.EXT_texture_array;
- break;
-  case GL_TEXTURE_2D_MULTISAMPLE:
-  case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
- err = (_mesa_is_gles(ctx) ||
-!ctx->Extensions.ARB_texture_multisample) &&
-   !_mesa_is_gles31(ctx);
- break;
-  default:
- err = true;
-  }
+   case GL_TEXTURE_1D_ARRAY:
+  err = dims != 1 || !ctx->Extensions.EXT_texture_array;
   break;
-   case 3:
-  if (textarget != GL_TEXTURE_3D)
- err = true;
+   case GL_TEXTURE_2D:
+  err = dims != 2;
+  break;
+   case GL_TEXTURE_2D_ARRAY:
+  err = dims != 2 || !ctx->Extensions.EXT_texture_array ||
+(_mesa_is_gles(ctx) && ctx->Version < 30);
+  break;
+   case GL_TEXTURE_2D_MULTISAMPLE:
+   case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+  err = dims != 2 ||
+!ctx->Extensions.ARB_texture_multisample ||
+(_mesa_is_gles(ctx) && ctx->Version < 31);
+  break;
+   case GL_TEXTURE_RECTANGLE:
+  err = dims != 2 || _mesa_is_gles(ctx) ||
+!ctx->Extensions.NV_texture_rectangle;
+  break;
+   case GL_TEXTURE_CUBE_MAP:
+   case GL_TEXTURE_CUBE_MAP_ARRAY:
+  err = true;
+  break;
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
+  err = dims != 2 || !ctx->Extensions.ARB_texture_cube_map;
+  break;
+   case GL_TEXTURE_3D:
+  err = dims != 3;
   break;
default:
   err = true;
+  break;
}
 
if (err) {
-- 
2.10.0

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

[Mesa-dev] [PATCH 2/2] mesa: Raise INVALID_ENUM in FramebufferTexture*D for unknown textargets.

[Kenneth Graunke]

ES3-CTS.functional.negative_api.buffer.framebuffer_texture2d expects
glFramebufferTexture[123]D to raise GL_INVALID_ENUM when
supplied a completely bogus textarget parameter (i.e. 0x).

This is at odds with the spec.  GLES 3.1 says:

   "An INVALID_OPERATION error is generated if texture is not zero and
textarget is not one of TEXTURE_2D, TEXTURE_2D_MULTISAMPLE, or one
of the cube map face targets from table 8.21."

(and GLES 3.0 and GL 4.5 both have similar text).  However, GL has a
general guideline that says:

   "If a command that requires an enumerated value is passed a symbolic
constant that is not one of those specified as allowable for that
command, an INVALID_ENUM error is generated."

Apparently other vendors reconcile these two rules as follows: GL should
raise INVALID_OPERATION for actual texture target enumeration values
which are not allowed for this particular glFramebufferTexture*D call.
Any value that is not a texture target should result in GL_INVALID_ENUM.

For example, glFramebufferTexture2D with GL_TEXTURE_1D would result in
INVALID_OPERATION because it is a real texture target, but not allowed
for the 2D version of the function.  But calling it with GL_FRONT would
result in INVALID_ENUM, as that isn't even a texture target.

Fixes:
- {ES3-CTS,dEQP-GLES3}.functional.negative_api.buffer.framebuffer_texture2d
- 
{ES31-CTS,ES32-CTS,dEQP-GLES31}.functional.debug.negative_coverage.get_error.buffer.framebuffer_texture2d

References: https://gitlab.khronos.org/opengl/cts/merge_requests/387
Signed-off-by: Kenneth Graunke 
---
 src/mesa/main/fbobject.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index f8899e6..3b55e79 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -3031,8 +3031,9 @@ check_textarget(struct gl_context *ctx, int dims, GLenum 
target,
   err = dims != 3;
   break;
default:
-  err = true;
-  break;
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  "%s(unknown textarget 0x%x)", caller, textarget);
+  return false;
}
 
if (err) {
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH V2 07/11] anv/image: Memset hiz surfaces to 0 when binding memory

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Tue, Sep 27, 2016 at 10:59 AM, Chad Versace 
wrote:

> On Mon 26 Sep 2016, Nanley Chery wrote:
> > From: Jason Ekstrand 
> >
> > Nanley Chery (amend):
> >  - Change memset value from 0xff to 0 (a defined value for HiZ).
> >
> > Signed-off-by: Nanley Chery 
> >
> > ---
> >
> > v2. Add asserts (Jason)
> > Handle NULL return value of the mmap
>
> Reviewed-by: Chad Versace 
> ___
> 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 05/11] anv: Allocate hiz surface

[Jason Ekstrand]

On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery  wrote:

> From: Chad Versace 
>
> Nanley Chery:
> (rebase)
>  - Use isl_surf_get_hiz_surf()
> (amend)
>  - Only add a HiZ surface onto a depth/stencil attachment
>  - Add comment above HiZ surface addition
>  - Hide HiZ behind INTEL_VK_HIZ prior to BDW
>  - Disable HiZ for untested cases
>  - Remove DISABLE_AUX_BIT instead of preventing it from being added
>
> Signed-off-by: Nanley Chery 
> Reviewed-by: Jason Ekstrand 
> Reviewed-by: Chad Versace  (v1)
>
> ---
>
> v2: Disable certain HiZ cases here (Jason)
>
>  src/intel/vulkan/anv_image.c | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index f6e8672..d408819 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -28,6 +28,7 @@
>  #include 
>
>  #include "anv_private.h"
> +#include "util/debug.h"
>
>  #include "vk_format_info.h"
>
> @@ -60,6 +61,7 @@ choose_isl_surf_usage(VkImageUsageFlags vk_usage,
>default:
>   unreachable("bad VkImageAspect");
>case VK_IMAGE_ASPECT_DEPTH_BIT:
> + isl_usage &= ~ISL_SURF_USAGE_DISABLE_AUX_BIT;
>   isl_usage |= ISL_SURF_USAGE_DEPTH_BIT;
>   break;
>case VK_IMAGE_ASPECT_STENCIL_BIT:
> @@ -99,6 +101,16 @@ get_surface(struct anv_image *image,
> VkImageAspectFlags aspect)
> }
>  }
>
> +static void
> +add_surface(struct anv_image *image, struct anv_surface *surf)
> +{
> +   assert(surf->isl.size > 0); /* isl surface must be initialized */
> +
> +   surf->offset = align_u32(image->size, surf->isl.alignment);
> +   image->size = surf->offset + surf->isl.size;
> +   image->alignment = MAX(image->alignment, surf->isl.alignment);
> +}
> +
>  /**
>   * Initialize the anv_image::*_surface selected by \a aspect. Then update
> the
>   * image's memory requirements (that is, the image's size and alignment).
> @@ -160,9 +172,30 @@ make_surface(const struct anv_device *dev,
>  */
> assert(ok);
>
> -   anv_surf->offset = align_u32(image->size, anv_surf->isl.alignment);
> -   image->size = anv_surf->offset + anv_surf->isl.size;
> -   image->alignment = MAX(image->alignment, anv_surf->isl.alignment);
> +   add_surface(image, anv_surf);
>

In my CCS series, I split this in two and had a precursor patch that added
the add_surface helper.  Do with that information what you will.  I'm fine
with having it all in one patch.


> +
> +   /* Allow the user to control HiZ enabling. Disable by default on gen7
> +* because resolves are not currently implemented pre-BDW.
> +*/
> +   if (!env_var_as_boolean("INTEL_VK_HIZ", dev->info.gen >= 8)) {
> +  anv_finishme("Implement gen7 HiZ");
> +  return VK_SUCCESS;
> +   } else if (vk_info->mipLevels > 1) {
> +  anv_finishme("Test multi-LOD HiZ");
> +  return VK_SUCCESS;
> +   } else if (dev->info.gen == 8 && vk_info->samples > 1) {
> +  anv_finishme("Test gen8 multisampled HiZ");
> +  return VK_SUCCESS;
> +   }
>

It may be better to pull this (and the usage check below) into an
image_supports_hiz helper.  The early returns work for now but as soon as
we have multiple kinds of aux surfaces, we'll have to do that refactor
anyway.


> +
> +   /* Add a HiZ surface to a depth buffer that will be used for rendering.
> +*/
> +   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT &&
> +   (image->usage & VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT)) {
> +  isl_surf_get_hiz_surf(>isl_dev, >depth_surface.isl,
> +>hiz_surface.isl);
> +  add_surface(image, >hiz_surface);
> +   }
>
> return VK_SUCCESS;
>  }
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] nir: Add a nop intrinsic

[Kenneth Graunke]

On Thursday, September 15, 2016 9:16:04 PM PDT Jason Ekstrand wrote:
> This intrinsic has no destination, no sources, no variables, and can be
> eliminated.  In other words, it does nothing and will always get deleted by
> dead code elimination.  However, it does provide a quick-and-easy way to
> temporarily tag a particular location in a NIR shader.
> 
> Signed-off-by: Jason Ekstrand 
> ---
>  src/compiler/nir/nir_intrinsics.h | 3 +++
>  1 file changed, 3 insertions(+)

These two are:
Reviewed-by: Kenneth Graunke 

I understand that Connor may not be a fan of this code, but it's been
several weeks and we don't have a better proposal.  We need to unblock
RADV.

I agree with Connor that we shouldn't be relying on the details of how
the NIR control flow decides to split/join blocks...and inserting or
removing a control flow node does tend to split/join blocks all over
the place, making some set of your block pointers invalid.

I like the approach of adding a nop instruction to hold the current
position.  The nop will end up somewhere, and you can just resume from
wherever it is, and you don't have to assume anything about how NIR
decided to split/join blocks.


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Revert "mesa_glinterop: remove inclusion of GLX header"

[Vinson Lee]

This reverts commit 8472045b16b3e4621553fe451a20a9ba9f0d44b6.

Conflicts:

include/GL/mesa_glinterop.h

This patch fixes this build error with GCC 4.4.

  Compiling src/glx/dri_common_interop.c ...
In file included from src/glx/dri_common_interop.c:33:
include/GL/mesa_glinterop.h:62: error: redefinition of typedef ‘GLXContext’
include/GL/glx.h:165: note: previous declaration of ‘GLXContext’ was here

Fixes: 8472045b16b3 ("mesa_glinterop: remove inclusion of GLX header")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96770
Signed-off-by: Vinson Lee 
---
 include/GL/mesa_glinterop.h |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
index 383d7f9..c6a967e 100644
--- a/include/GL/mesa_glinterop.h
+++ b/include/GL/mesa_glinterop.h
@@ -52,15 +52,12 @@
 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
-/* Forward declarations to avoid inclusion of GL/glx.h */
-typedef struct _XDisplay Display;
-typedef struct __GLXcontextRec *GLXContext;
-
 /* Forward declarations to avoid inclusion of EGL/egl.h */
 typedef void *EGLDisplay;
 typedef void *EGLContext;
-- 
1.7.1

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

Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface

[Andy Furniss]

Zhang, Boyuan wrote:

Hi Andy,

Thanks for the testings.

Regarding to the inconsistencies, the current Vaapi dual instances
encoding behaviour is random. Whether or not the dual instances is
being used depends on how early the player calls sync_surface
function according to the current gstreamer-vaapi's mechanism. e.g.
if the player calls sync_surface too early, then we don't have
enough time to receive and process the 2nd frame and we can only end
up with single instance encoding for this frame as a result. And the
random player behaviours depends on the current environment, for
example cpufreq might be one factor. As a result, we don't guarantee
the consistency especially when rate control is enabled for dual
instances Vaapi encoding, since the randomness could result
different calculations.


OK, I guess OMX is less dependent on player, because I can't reproduce
with that and speed suggests I get dual instance.

So far I can only get the low bitrate files with vbr. cbr always at
least seems to come out the correct size.

cpq is also affected by the issue = different md5sums and sometimes out
of order.


For the corruption/wrong frame order issue, could you please provide
more detailed information for reproduction? e.g. the clips and
commands that can reproduce the issue. Does this issue only happen
after enabling dual instance patch?


The corruption I mentioned was due to low bitrate sometimes for vbr.

The out of order seems quite easy to produce with 1080p input.
I tend to use raw video, but transcoding can also reproduce (just I
prefer raw as at least I know it's the enc rather that the dec).

Resetting mesa onto this commit (+applying patch 2 and later fix patch +
firmware patch) reproduces the issue. I also previously tested last
firmware (md5sum only) and it had the issue.

Resetting mesa on the commit before or just disabling dual instance on
head does not have the issue.

The exact command for this test was -

for x in $(seq 1 20); do gst-launch-1.0 -f filesrc 
location=/mnt/ramdisk/raw-1000f-1080p.nv12 blocksize=3110400 ! 
video/x-raw,format=NV12,width=1920,height=1080,framerate=50/1 ! queue ! 
vaapih264enc ! video/x-h264, profile=baseline ! filesink 
location=/mnt/ramdisk/out-$x.264; done


Not all of these will have the reversal and the 5fd5c
match single inst but here's a bad one out of this run
reversal and some corruption.

out-2.264 - 
https://drive.google.com/file/d/0BxP5-S1t9VEENjFkME1WTktiSUE/view?usp=sharing



 md5sum /mnt/ramdisk/out-*
80430ea3dc361dd9fe57a8c7746b  /mnt/ramdisk/out-10.264
a68f7218e81a6cdf9f3d20eaaf57a48a  /mnt/ramdisk/out-11.264
68d6de4f53f73c72f48f42a08b56a78b  /mnt/ramdisk/out-12.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-1.264
6be1f7bcea99194f59d7feaf827fe4e2  /mnt/ramdisk/out-13.264
d8a184f149f59ab308f0deec9bc9f53c  /mnt/ramdisk/out-14.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-15.264
4a4b2dbeef4a6ef2e6327b455f7c8b87  /mnt/ramdisk/out-16.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-17.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-18.264
20f53e73ba5bc47f05531ddef7e9a849  /mnt/ramdisk/out-19.264
c1f6df236900bece57853dbec54718d1  /mnt/ramdisk/out-20.264
e61428d61ff5673dbed8f11a4c347ac7  /mnt/ramdisk/out-2.264
3106e03284b9dbf687f9a46a1c526ba7  /mnt/ramdisk/out-3.264
53c104d68ddd90e9414ca9be4dc47c40  /mnt/ramdisk/out-4.264
dae66f3dfea8edec2c6862782b007a0e  /mnt/ramdisk/out-5.264
910cdc32770ce3c78e84300fa851986a  /mnt/ramdisk/out-6.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-7.264
700112ae272d52985948052efe345245  /mnt/ramdisk/out-8.264
03857eddbabfc4747cd6450d58350548  /mnt/ramdisk/out-9.264

Before dual inst

md5sum /mnt/ramdisk/out-*
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-10.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-11.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-12.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-1.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-13.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-14.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-15.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-16.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-17.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-18.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-19.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-20.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-2.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-3.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-4.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-5.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-6.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-7.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-8.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-9.264

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH] anv/gen7_pipeline: Fix typo in semicolon

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Mon, Oct 3, 2016 at 10:44 AM, Anuj Phogat  wrote:

> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_
> pipeline.c
> index bafee28..c9d1f64 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -238,7 +238,7 @@ genX(graphics_pipeline_create)(
>  wm_prog_data->base.dispatch_grf_start_reg,
>   ps.DispatchGRFStartRegisterforConstantSetupData1 = 0,
>   ps.DispatchGRFStartRegisterforConstantSetupData2 =
> -wm_prog_data->dispatch_grf_start_reg_2,
> +wm_prog_data->dispatch_grf_start_reg_2;
>
>   /* Haswell requires the sample mask to be set in this packet as
> well as
>* in 3DSTATE_SAMPLE_MASK; the values should match. */
> --
> 2.5.5
>
> ___
> 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 v2 01/13] anv: Use blorp for VkCmdFillBuffer

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
---
 src/intel/vulkan/anv_blorp.c  | 106 +
 src/intel/vulkan/anv_meta_clear.c | 120 --
 2 files changed, 96 insertions(+), 130 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index cb61070..f149f84 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -480,6 +480,20 @@ void anv_CmdBlitImage(
blorp_batch_finish();
 }
 
+static enum isl_format
+isl_format_for_size(unsigned size_B)
+{
+   switch (size_B) {
+   case 1:  return ISL_FORMAT_R8_UINT;
+   case 2:  return ISL_FORMAT_R8G8_UINT;
+   case 4:  return ISL_FORMAT_R8G8B8A8_UINT;
+   case 8:  return ISL_FORMAT_R16G16B16A16_UINT;
+   case 16: return ISL_FORMAT_R32G32B32A32_UINT;
+   default:
+  unreachable("Not a power-of-two format size");
+   }
+}
+
 static void
 do_buffer_copy(struct blorp_batch *batch,
struct anv_bo *src, uint64_t src_offset,
@@ -491,16 +505,7 @@ do_buffer_copy(struct blorp_batch *batch,
/* The actual format we pick doesn't matter as blorp will throw it away.
 * The only thing that actually matters is the size.
 */
-   enum isl_format format;
-   switch (block_size) {
-   case 1:  format = ISL_FORMAT_R8_UINT;  break;
-   case 2:  format = ISL_FORMAT_R8G8_UINT;break;
-   case 4:  format = ISL_FORMAT_R8G8B8A8_UNORM;   break;
-   case 8:  format = ISL_FORMAT_R16G16B16A16_UNORM;   break;
-   case 16: format = ISL_FORMAT_R32G32B32A32_UINT;break;
-   default:
-  unreachable("Not a power-of-two format size");
-   }
+   enum isl_format format = isl_format_for_size(block_size);
 
struct isl_surf surf;
isl_surf_init(>isl_dev, ,
@@ -667,6 +672,87 @@ void anv_CmdUpdateBuffer(
blorp_batch_finish();
 }
 
+void anv_CmdFillBuffer(
+VkCommandBuffer commandBuffer,
+VkBufferdstBuffer,
+VkDeviceSizedstOffset,
+VkDeviceSizefillSize,
+uint32_tdata)
+{
+   ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
+   ANV_FROM_HANDLE(anv_buffer, dst_buffer, dstBuffer);
+   struct blorp_surf surf;
+   struct isl_surf isl_surf;
+
+   struct blorp_batch batch;
+   blorp_batch_init(_buffer->device->blorp, , cmd_buffer);
+
+   if (fillSize == VK_WHOLE_SIZE) {
+  fillSize = dst_buffer->size - dstOffset;
+  /* Make sure fillSize is a multiple of 4 */
+  fillSize &= ~3ull;
+   }
+
+   /* First, we compute the biggest format that can be used with the
+* given offsets and size.
+*/
+   int bs = 16;
+   bs = gcd_pow2_u64(bs, dstOffset);
+   bs = gcd_pow2_u64(bs, fillSize);
+   enum isl_format isl_format = isl_format_for_size(bs);
+
+   union isl_color_value color = {
+  .u32 = { data, data, data, data },
+   };
+
+   const uint64_t max_fill_size = MAX_SURFACE_DIM * MAX_SURFACE_DIM * bs;
+   while (fillSize >= max_fill_size) {
+  get_blorp_surf_for_anv_buffer(cmd_buffer->device,
+dst_buffer, dstOffset,
+MAX_SURFACE_DIM, MAX_SURFACE_DIM,
+MAX_SURFACE_DIM * bs, isl_format,
+, _surf);
+
+  blorp_clear(, , isl_format, ISL_SWIZZLE_IDENTITY,
+  0, 0, 1, 0, 0, MAX_SURFACE_DIM, MAX_SURFACE_DIM,
+  color, NULL);
+  fillSize -= max_fill_size;
+  dstOffset += max_fill_size;
+   }
+
+   uint64_t height = fillSize / (MAX_SURFACE_DIM * bs);
+   assert(height < MAX_SURFACE_DIM);
+   if (height != 0) {
+  const uint64_t rect_fill_size = height * MAX_SURFACE_DIM * bs;
+  get_blorp_surf_for_anv_buffer(cmd_buffer->device,
+dst_buffer, dstOffset,
+MAX_SURFACE_DIM, height,
+MAX_SURFACE_DIM * bs, isl_format,
+, _surf);
+
+  blorp_clear(, , isl_format, ISL_SWIZZLE_IDENTITY,
+  0, 0, 1, 0, 0, MAX_SURFACE_DIM, height,
+  color, NULL);
+  fillSize -= rect_fill_size;
+  dstOffset += rect_fill_size;
+   }
+
+   if (fillSize != 0) {
+  const uint32_t width = fillSize / bs;
+  get_blorp_surf_for_anv_buffer(cmd_buffer->device,
+dst_buffer, dstOffset,
+width, 1,
+width * bs, isl_format,
+, _surf);
+
+  blorp_clear(, , isl_format, ISL_SWIZZLE_IDENTITY,
+  0, 0, 1, 0, 0, width, 1,
+  color, NULL);
+   }
+
+   blorp_batch_finish();
+}
+
 void anv_CmdClearColorImage(
 VkCommandBuffer commandBuffer,
 VkImage   

Re: [Mesa-dev] [PATCH V2 8/9] anv/gen7_pipeline: Set sample mask field in 3DSTATE_PS

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Mon, Oct 3, 2016 at 10:13 AM, Anuj Phogat  wrote:

> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_
> pipeline.c
> index 9411631..bafee28 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -243,6 +243,9 @@ genX(graphics_pipeline_create)(
>   /* Haswell requires the sample mask to be set in this packet as
> well as
>* in 3DSTATE_SAMPLE_MASK; the values should match. */
>   /* _NEW_BUFFERS, _NEW_MULTISAMPLE */
> +#if GEN_IS_HASWELL
> + ps.SampleMask= 0xff;
> +#endif
>}
>
>uint32_t samples = pCreateInfo->pMultisampleState ?
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97542] mesa-12.0.1 with llvm-3.9.0_rc3 - src/gallium/state_trackers/clover/llvm/invocation.cpp:212:75: error: no matching function for call to clang::CompilerInvocation::setLangDefault

[bugzilla-daemon]

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

Clément Guérin  changed:

   What|Removed |Added

 CC||geecko@free.fr

-- 
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] [Request for Testing] i965: import prime buffers in the current context, not screen

[Kristian Høgsberg]

On Thu, Sep 29, 2016 at 7:33 AM Martin Peres 
wrote:

> On 02/09/16 10:08, Martin Peres wrote:
> >
> >
> > On 25/08/16 21:49, Kristian Høgsberg wrote:
> >> On Thu, Aug 25, 2016 at 11:38 AM, Chad Versace
> >>  wrote:
> >>> On Thu 25 Aug 2016, Martin Peres wrote:
>  This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
>  fixes many applications when using DRI3:
>   - Totem with libva on hw-accelerated decoding
>   - obs-studio, using Window Capture (Xcomposite) as a Source
>   - gstreamer with VAAPI
> 
>  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
>  Signed-off-by: Martin Peres 
>  ---
> 
>  This patch supposedly prevents gnome from running for one Arch Linux
>  maintainer. Kenneth Graunke  and I failed to reproduce it so I am
>  asking for your help/comments on this.
> 
>   src/mesa/drivers/dri/i965/intel_screen.c | 24
> ++--
>   1 file changed, 22 insertions(+), 2 deletions(-)
> 
>  diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>  b/src/mesa/drivers/dri/i965/intel_screen.c
>  index 7876652..5c0d300 100644
>  --- a/src/mesa/drivers/dri/i965/intel_screen.c
>  +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>  @@ -698,8 +698,11 @@ intel_create_image_from_fds(__DRIscreen *screen,
>   int *fds, int num_fds, int *strides,
>  int *offsets,
>   void *loaderPrivate)
>   {
>  +   GET_CURRENT_CONTEXT(ctx);
>  struct intel_screen *intelScreen = screen->driverPrivate;
>  +   struct brw_context *brw = brw_context(ctx);
>  struct intel_image_format *f;
>  +   dri_bufmgr *bufmgr;
>  __DRIimage *image;
>  int i, index;
> 
>  @@ -740,8 +743,25 @@ intel_create_image_from_fds(__DRIscreen *screen,
>    size = end;
>  }
> 
>  -   image->bo =
> drm_intel_bo_gem_create_from_prime(intelScreen->bufmgr,
>  -  fds[0], size);
>  +   /* Let's import the buffer into the current context instead of
>  the current
>  +* screen as some applications like gstreamer, totem, or obs
>  create multiple
>  +* X connections which end up creating multiple screens and thus
>  multiple
>  +* buffer managers. They then proceed to use a different X
>  connection to call
>  +* GLXBindTexImageExt() which should import the buffer in the
>  current thread
>  +* bound and not the current screen. This is done properly
>  upstairs for
>  +* texture management so we need to mirror this behaviour if we
>  don't want
>  +* the kernel rejecting our pushbuffers as the buffers have not
>  been imported
>  +* by the same bufmgr that sent the pushbuffer.
>  +*
>  +* If there is no context currently bound, then revert to using
>  the screen's
>  +* buffer manager and hope for the best...
> >>>
> >>> Nope. This patch breaks EGL_EXT_image_dma_buf_import.
> >>>
> >>> When the user calls eglCreateImageKHR(EGLDisplay, EGLContext, ...) with
> >>> image type EGL_LINUX_DMA_BUF_EXT, then the spec requires that context
> be
> >>> NULL. The EGLDisplay parameter determines the namespace of the newly
> >>> created
> >>> EGLImage. By design, the currently bound context (and its display) DO
> >>> NOT affect
> >>> eglCreateImage.
> >>>
> >>>   Problem Example:
> >>> eglMakeCurrent(dpyA, ..., ctxA);
> >>> img = eglCreateImage(dpyB, EGL_NO_CONTEXT, ...);
> >
> > I see, that may explain the issue Ionut found with gnome. Thanks Chad!
> >
> >>
> >> The difference between DRI2 and DRI3 is that for DRI2 we'd get a
> >> DRI2Buffer back from getBuffers, and then open the flink name inside
> >> the driver with the current context's bufmgr. In the DRI3 world, we go
> >> from prime fd to drm_bo in dri3_get_pixmap_buffer() with the screen
> >> that's associated with the current drawable.
> >
> > Yes, that is the problem indeed.
> >
> >>
> >> I think the fix we're looking for is to make
> >> draw->vtable->get_dri_context() also return the __DRIscreen, then use
> >> that in dri3_get_pixmap_buffer() to get the right __DRIscreen to pass
> >> to loader_dri3_create_image().
> >
> > Seems sensible and wouldn't require changing the world! Thanks Kristian!
> > I will get to it when I come back from vacation!
>
> Hey,
>
> I am finally trying your approach but then I am not sure I understand
> what you are saying.
>
> My patch was changing the import to always happen in the currently-bound
> screen, and you said it violates the spec of EGL_EXT_image_dma_buf_import.
>
> eglCreateImage's dpy is passed all the way down to
> intel_create_image_from_fds, which is what the spec mandates.
>

The problem isn't eglCreateImage, it's when the DRI 

[Mesa-dev] [Bug 97542] mesa-12.0.1 with llvm-3.9.0_rc3 - src/gallium/state_trackers/clover/llvm/invocation.cpp:212:75: error: no matching function for call to clang::CompilerInvocation::setLangDefault

[bugzilla-daemon]

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

--- Comment #11 from Clément Guérin  ---
Hello, I built mesa 12.0.3 against llvm 3.9.0 on arch linux. Rocket League and
Portal were working properly, however Tomb Raider was crashing right before the
Feral logo.

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

[Mesa-dev] [PATCH v2 10/30] egl/dri2: rework dri2_make_current code flow

[Emil Velikov]

From: Emil Velikov 

Fold duplicate conditional blocks and add a few extra comments ;-)

v2: Bring back the explicit "unbind" logic (Eric), remove NULL derefs.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/egl_dri2.c | 72 -
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 96fef52..378ee5c 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1260,11 +1260,11 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
_EGLContext *old_ctx;
+   _EGLDisplay *old_disp = NULL;
_EGLSurface *old_dsurf, *old_rsurf;
_EGLSurface *tmp_dsurf, *tmp_rsurf;
__DRIdrawable *ddraw, *rdraw;
__DRIcontext *cctx;
-   EGLBoolean unbind;
 
if (!dri2_dpy)
   return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent");
@@ -1275,55 +1275,55 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
   return EGL_FALSE;
}
 
-   /* flush before context switch */
-   if (old_ctx)
-  dri2_drv->glFlush();
-
ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
 
if (old_ctx) {
   __DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
+
+  /* flush before context switch */
+  dri2_drv->glFlush();
   dri2_dpy->core->unbindContext(old_cctx);
+
+  /* Keep track of the old dpy as we'll need it for resource cleanup */
+  old_disp = old_ctx->Resource.Display;
}
 
-   unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);
+   /* Bind if at least one of the primitives is valid ... */
+   if (cctx || ddraw || rdraw) {
+  if (dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
+ /* undo the previous _eglBindContext */
+ _eglBindContext(old_ctx, old_dsurf, old_rsurf, , _dsurf, 
_rsurf);
+ assert(_ctx->base == ctx &&
+tmp_dsurf == dsurf &&
+tmp_rsurf == rsurf);
+
+ _eglPutSurface(dsurf);
+ _eglPutSurface(rsurf);
+ _eglPutContext(ctx);
 
-   if (unbind || dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
-  dri2_destroy_surface(drv, disp, old_dsurf);
-  dri2_destroy_surface(drv, disp, old_rsurf);
+ _eglPutSurface(old_dsurf);
+ _eglPutSurface(old_rsurf);
+ _eglPutContext(old_ctx);
 
-  if (!unbind)
- dri2_dpy->ref_count++;
-  if (old_ctx) {
- EGLDisplay old_disp = _eglGetDisplayHandle(old_ctx->Resource.Display);
- dri2_destroy_context(drv, disp, old_ctx);
- dri2_display_release(old_disp);
+ /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, 
but
+  * setting the error to EGL_BAD_MATCH is surely better than leaving it
+  * as EGL_SUCCESS.
+  */
+ return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
   }
 
-  return EGL_TRUE;
-   } else {
-  /* undo the previous _eglBindContext */
-  _eglBindContext(old_ctx, old_dsurf, old_rsurf, , _dsurf, 
_rsurf);
-  assert(_ctx->base == ctx &&
- tmp_dsurf == dsurf &&
- tmp_rsurf == rsurf);
-
-  _eglPutSurface(dsurf);
-  _eglPutSurface(rsurf);
-  _eglPutContext(ctx);
-
-  _eglPutSurface(old_dsurf);
-  _eglPutSurface(old_rsurf);
-  _eglPutContext(old_ctx);
-
-  /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, but
-   * setting the error to EGL_BAD_MATCH is surely better than leaving it
-   * as EGL_SUCCESS.
-   */
-  return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
+  /* ... and refcount the dpy when successful. */
+  dri2_dpy->ref_count++;
}
+
+   dri2_destroy_surface(drv, disp, old_dsurf);
+   dri2_destroy_surface(drv, disp, old_rsurf);
+   dri2_destroy_context(drv, disp, old_ctx);
+   dri2_display_release(old_disp);
+
+   return EGL_TRUE;
 }
 
 __DRIdrawable *
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH 10/30] egl/dri2: rework dri2_make_current code flow

[Emil Velikov]

On 25 September 2016 at 04:24, Eric Engestrom  wrote:
> On Thu, Aug 25, 2016 at 05:18:32PM +0100, Emil Velikov wrote:
>> From: Emil Velikov 
>>
>> Duplicate a few lines at the expense of making the code-flow clearer
>> while adding a few extra comments ;-)
>>
>> Signed-off-by: Emil Velikov 
>> ---
>>
>> It makes things clearer the way on this end, but if people have better
>> suggestions I would love to hear them.
>>
>> Emil
>> ---
>>  src/egl/drivers/dri2/egl_dri2.c | 43 
>> ++---
>>  1 file changed, 23 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/egl_dri2.c 
>> b/src/egl/drivers/dri2/egl_dri2.c
>> index a481236..d53c9b9 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.c
>> +++ b/src/egl/drivers/dri2/egl_dri2.c
>> @@ -1248,11 +1248,12 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay 
>> *disp, _EGLSurface *dsurf,
>> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>> struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
>> _EGLContext *old_ctx;
>> +   _EGLDisplay *old_disp = NULL;
>> _EGLSurface *old_dsurf, *old_rsurf;
>> _EGLSurface *tmp_dsurf, *tmp_rsurf;
>> -   __DRIdrawable *ddraw, *rdraw;
>> -   __DRIcontext *cctx;
>> -   EGLBoolean unbind;
>> +   __DRIdrawable *ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) 
>> : NULL;
>> +   __DRIdrawable *rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) 
>> : NULL;
>> +   __DRIcontext *cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
>>
>> if (!dri2_dpy)
>>return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent");
>> @@ -1263,32 +1264,34 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay 
>> *disp, _EGLSurface *dsurf,
>>return EGL_FALSE;
>> }
>>
>> -   /* flush before context switch */
>> -   if (old_ctx)
>> -  dri2_drv->glFlush();
>> -
>> -   ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
>> -   rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
>> -   cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
>> -
>> if (old_ctx) {
>>__DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
>> +
>> +  /* flush before context switch */
>> +  dri2_drv->glFlush();
>>dri2_dpy->core->unbindContext(old_cctx);
>> +
>> +  /* Keep track of the old dpy as we'll need it for resource cleanup */
>> +  old_disp = old_ctx->Resource.Display;
>> }
>>
>> -   unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);
>> +/* There's no new ctx to bind, so just destroy the old resources */
>> +   if (cctx == NULL) {
>> +  dri2_destroy_surface(drv, disp, old_dsurf);
>> +  dri2_destroy_surface(drv, disp, old_rsurf);
>> +  dri2_destroy_context(drv, disp, old_ctx);
>> +  dri2_display_release(old_disp);
>>
>> -   if (unbind || dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
>> +  return EGL_TRUE;
>> +   }
>> +   if (dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
>
> I'm pretty sure dropping `unbind` changes the behaviour, which means
> this isn't just a refactor.
>
IIRC there was a bunch of hidden assumptions which made the "unbind"
part identical. Then again as-is it's not clear, so adding the
ddraw/rdraw check is better.

> (Also, nit: the grouping on that diff would have been better if you had
> left an empty line between the two `if` :)
>
>>dri2_destroy_surface(drv, disp, old_dsurf);
>>dri2_destroy_surface(drv, disp, old_rsurf);
>> +  dri2_destroy_context(drv, disp, old_ctx);
>> +  dri2_display_release(old_disp);
>
> I think `dri2_display_release()` needs to be in an `if (old_disp)` (or
> `if (old_ctx)`, they're equivalent at this point), as it will
> dereference old_disp.
>
Patch 5/30 should cover that ?

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

[Mesa-dev] [PATCH] anv/gen7_pipeline: Fix typo in semicolon

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index bafee28..c9d1f64 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -238,7 +238,7 @@ genX(graphics_pipeline_create)(
 wm_prog_data->base.dispatch_grf_start_reg,
  ps.DispatchGRFStartRegisterforConstantSetupData1 = 0,
  ps.DispatchGRFStartRegisterforConstantSetupData2 =
-wm_prog_data->dispatch_grf_start_reg_2,
+wm_prog_data->dispatch_grf_start_reg_2;
 
  /* Haswell requires the sample mask to be set in this packet as well 
as
   * in 3DSTATE_SAMPLE_MASK; the values should match. */
-- 
2.5.5

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

Re: [Mesa-dev] [PATCH 0/2] clover: clEnqueueMigrateMemObjects

[Serge Martin]

Ping

On Saturday 12 September 2015 21:08:20 Serge Martin wrote:
> Now that mem object can be move back to the host, I think we should latter
> come with a way to optimize read mapping for such objets. For the moment if
> they are mapped for reading after been moved to the host, they will be send
> back to the device...
> 
> Serge Martin (2):
>   clover: clEnqueueMigrateMemObjects (device)
>   clover: clEnqueueMigrateMemObjects (host)
> 
>  src/gallium/state_trackers/clover/api/transfer.cpp | 51
> ++ src/gallium/state_trackers/clover/core/memory.cpp  |
> 38 +--- src/gallium/state_trackers/clover/core/memory.hpp  | 16
> +--
>  .../state_trackers/clover/core/resource.cpp|  5 ++-
>  .../state_trackers/clover/core/resource.hpp|  3 +-
>  5 files changed, 92 insertions(+), 21 deletions(-)

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

Re: [Mesa-dev] [PATCH 8/9] anv/gen7_pipeline: Set few missing fields in 3DSTATE_PS

[Anuj Phogat]

On Fri, Sep 30, 2016 at 5:02 PM, Jason Ekstrand 
wrote:
> On Sep 30, 2016 3:34 PM, "Anuj Phogat"  wrote:
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/vulkan/gen7_pipeline.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/intel/vulkan/gen7_pipeline.c
>> b/src/intel/vulkan/gen7_pipeline.c
>> index 9411631..4bab0bc 100644
>> --- a/src/intel/vulkan/gen7_pipeline.c
>> +++ b/src/intel/vulkan/gen7_pipeline.c
>> @@ -243,6 +243,10 @@ genX(graphics_pipeline_create)(
>>   /* Haswell requires the sample mask to be set in this packet as
>> well as
>>* in 3DSTATE_SAMPLE_MASK; the values should match. */
>>   /* _NEW_BUFFERS, _NEW_MULTISAMPLE */
>> +#if (GEN_IS_HASWELL)
>
> There is some code that uses this #if style but I think the "official"
style
> is to not indent and not use the parens.
>
>> + ps.SampleMask= 0xff;
>> +#endif
>> + ps.SamplerCount  = 1;
>
> Of we're going to add code to set sampler count, it should be accurate.
> It's probably best to drop this line and have a later patch which actually
> sets it correctly.
>
>>}
>>
>>uint32_t samples = pCreateInfo->pMultisampleState ?
>> --
>> 2.5.5
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

I sent out the V2:
https://patchwork.freedesktop.org/patch/113460/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 9/9] anv/gen7_pipeline: Check for ksp0 when setting BarycentricInterpolationMode in 3DSTATE_WM

[Anuj Phogat]

On Fri, Sep 30, 2016 at 5:03 PM, Jason Ekstrand  wrote:
> On Sep 30, 2016 3:34 PM, "Anuj Phogat"  wrote:
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/vulkan/gen7_pipeline.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/intel/vulkan/gen7_pipeline.c
>> b/src/intel/vulkan/gen7_pipeline.c
>> index 4bab0bc..e804002 100644
>> --- a/src/intel/vulkan/gen7_pipeline.c
>> +++ b/src/intel/vulkan/gen7_pipeline.c
>> @@ -273,7 +273,8 @@ genX(graphics_pipeline_create)(
>>  wm.EarlyDepthStencilControl = EDSC_NORMAL;
>>   }
>>
>> - wm.BarycentricInterpolationMode=
>> wm_prog_data->barycentric_interp_modes;
>> + wm.BarycentricInterpolationMode= pipeline->ps_ksp0 ==
>> NO_KERNEL ?
>> +  0 :
>> wm_prog_data->barycentric_interp_modes;
>
> I believe this code is in a block that is already protected.
True, I'll drop this patch.

>
>>
>>   wm.MultisampleRasterizationMode= samples > 1 ?
>>MSRASTMODE_ON_PATTERN :
>> MSRASTMODE_OFF_PIXEL;
>> --
>> 2.5.5
>>
>> ___
>> 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 V2 8/9] anv/gen7_pipeline: Set sample mask field in 3DSTATE_PS

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 9411631..bafee28 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -243,6 +243,9 @@ genX(graphics_pipeline_create)(
  /* Haswell requires the sample mask to be set in this packet as well 
as
   * in 3DSTATE_SAMPLE_MASK; the values should match. */
  /* _NEW_BUFFERS, _NEW_MULTISAMPLE */
+#if GEN_IS_HASWELL
+ ps.SampleMask= 0xff;
+#endif
   }
 
   uint32_t samples = pCreateInfo->pMultisampleState ?
-- 
2.5.5

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

Re: [Mesa-dev] [PATCH] nv50/ra: let simplify return an error and handle that

[Samuel Pitoiset]

On 10/03/2016 06:55 PM, Karol Herbst wrote:

fixes a crash in the case simplify reports an error

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 2d3486b..7e64f7c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -771,7 +771,7 @@ private:
bool coalesce(ArrayList&);
bool doCoalesce(ArrayList&, unsigned int mask);
void calculateSpillWeights();
-   void simplify();
+   bool simplify();
bool selectRegisters();
void cleanup(const bool success);

@@ -1305,7 +1305,7 @@ GCRA::simplifyNode(RIG_Node *node)
 (node->degree < node->degreeLimit) ? "" : "(spill)");
 }

-void
+bool
 GCRA::simplify()
 {
for (;;) {
@@ -1330,11 +1330,11 @@ GCRA::simplify()
  }
  if (isinf(bestScore)) {
 ERROR("no viable spill candidates left\n");
-break;
+return false;
  }
  simplifyNode(best);
   } else {
- break;
+ return true;


I would suggest to move the "return true;" outside of the while(1) and 
keep the break as-is, but your call (purely cosmetic).



   }
}
 }
@@ -1493,7 +1493,9 @@ GCRA::allocateRegisters(ArrayList& insns)

buildRIG(insns);
calculateSpillWeights();
-   simplify();
+   ret = simplify();
+   if (!ret)
+  goto out;

ret = selectRegisters();
if (!ret) {


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

Re: [Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs

[Emil Velikov]

On 30 September 2016 at 19:37, Chuck Atkins  wrote:
> This fixes a problem where GL headers would only get installed if
> glx was enabled.  So if osmesa was enabled but not glx, then the
> GL headers required by osmesa would be missing from the install.
>
> Signed-off-by: Chuck Atkins 
> ---
>  configure.ac|  2 ++
>  src/Makefile.am | 30 ++
>  src/gallium/Makefile.am |  2 ++
>  src/mesa/Makefile.am| 12 ++--
>  4 files changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1bfac3b..c7be735 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2641,6 +2641,8 @@ fi
>  AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
>  AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
>  AM_CONDITIONAL(HAVE_GALLIUM_OSMESA, test "x$enable_gallium_osmesa" = xyes)
> +AM_CONDITIONAL(HAVE_COMMON_OSMESA, test "x$enable_osmesa" = xyes -o \
> +"x$enable_gallium_osmesa" = xyes)
>
Maybe we won't need this hunk, see below.

>  AM_CONDITIONAL(HAVE_X86_ASM, test "x$asm_arch" = xx86 -o "x$asm_arch" = 
> xx86_64)
>  AM_CONDITIONAL(HAVE_X86_64_ASM, test "x$asm_arch" = xx86_64)
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 551f431..c04ee1b 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -47,6 +47,36 @@ CLEANFILES = $(BUILT_SOURCES)
>
>  SUBDIRS = . gtest util mapi/glapi/gen mapi
>
> +if HAVE_OPENGL
> +gldir = $(includedir)/GL
> +gl_HEADERS = \
> +  $(top_srcdir)/include/GL/gl.h \
> +  $(top_srcdir)/include/GL/glext.h \
> +  $(top_srcdir)/include/GL/glcorearb.h \
> +  $(top_srcdir)/include/GL/gl_mangle.h
> +endif
> +
> +if HAVE_GLX
> +glxdir = $(includedir)/GL
> +glx_HEADERS = \
> +  $(top_srcdir)/include/GL/glx.h \
> +  $(top_srcdir)/include/GL/glxext.h \
> +  $(top_srcdir)/include/GL/glx_mangle.h \
> +  $(top_srcdir)/include/GL/mesa_glinterop.h
> +pkgconfigdir = $(libdir)/pkgconfig
> +pkgconfig_DATA = mesa/gl.pc
> +else
> +if HAVE_EGL
> +eglinteropdir = $(includedir)/GL
> +eglinterop_HEADERS = $(top_srcdir)/include/GL/mesa_glinterop.h
IIRC Marek was pretty clear that this header should not be installed.
Then again looking at our current wildcard installing ... seems like
it was.

Please drop this file from the install stage ?

> +endif
> +endif
> +
> +if HAVE_COMMON_OSMESA
> +osmesadir = $(includedir)/GL
> +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
> +endif
> +
Why do we have this hunk, considering each target is handled explicitly ?

IMHO we should drop either this or the similar ones in
src/{mesa,gallium}/Makefile.am. The latter might be better ?

Regards,
Emil
P.S. Thank for the poke.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nv50/ra: let simplify return an error and handle that

[Ilia Mirkin]

Of course this only helps shader-db, right? Pretty sure you'll hit an
assert if you try to draw... Either way, that can be fixed later. This
is

Reviewed-by: Ilia Mirkin 

On Mon, Oct 3, 2016 at 12:55 PM, Karol Herbst  wrote:
> fixes a crash in the case simplify reports an error
>
> Signed-off-by: Karol Herbst 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> index 2d3486b..7e64f7c 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> @@ -771,7 +771,7 @@ private:
> bool coalesce(ArrayList&);
> bool doCoalesce(ArrayList&, unsigned int mask);
> void calculateSpillWeights();
> -   void simplify();
> +   bool simplify();
> bool selectRegisters();
> void cleanup(const bool success);
>
> @@ -1305,7 +1305,7 @@ GCRA::simplifyNode(RIG_Node *node)
>  (node->degree < node->degreeLimit) ? "" : "(spill)");
>  }
>
> -void
> +bool
>  GCRA::simplify()
>  {
> for (;;) {
> @@ -1330,11 +1330,11 @@ GCRA::simplify()
>   }
>   if (isinf(bestScore)) {
>  ERROR("no viable spill candidates left\n");
> -break;
> +return false;
>   }
>   simplifyNode(best);
>} else {
> - break;
> + return true;
>}
> }
>  }
> @@ -1493,7 +1493,9 @@ GCRA::allocateRegisters(ArrayList& insns)
>
> buildRIG(insns);
> calculateSpillWeights();
> -   simplify();
> +   ret = simplify();
> +   if (!ret)
> +  goto out;
>
> ret = selectRegisters();
> if (!ret) {
> --
> 2.10.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] [PATCH] nv50/ra: let simplify return an error and handle that

[Karol Herbst]

fixes a crash in the case simplify reports an error

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 2d3486b..7e64f7c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -771,7 +771,7 @@ private:
bool coalesce(ArrayList&);
bool doCoalesce(ArrayList&, unsigned int mask);
void calculateSpillWeights();
-   void simplify();
+   bool simplify();
bool selectRegisters();
void cleanup(const bool success);
 
@@ -1305,7 +1305,7 @@ GCRA::simplifyNode(RIG_Node *node)
 (node->degree < node->degreeLimit) ? "" : "(spill)");
 }
 
-void
+bool
 GCRA::simplify()
 {
for (;;) {
@@ -1330,11 +1330,11 @@ GCRA::simplify()
  }
  if (isinf(bestScore)) {
 ERROR("no viable spill candidates left\n");
-break;
+return false;
  }
  simplifyNode(best);
   } else {
- break;
+ return true;
   }
}
 }
@@ -1493,7 +1493,9 @@ GCRA::allocateRegisters(ArrayList& insns)
 
buildRIG(insns);
calculateSpillWeights();
-   simplify();
+   ret = simplify();
+   if (!ret)
+  goto out;
 
ret = selectRegisters();
if (!ret) {
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH] vl/dri3: fix warning about incompatible pointer type

[Leo Liu]

Reviewed and Pushed.

On 10/01/2016 01:22 AM, Nayan Deshmukh wrote:

Signed-off-by: Nayan Deshmukh 
---
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 191a64b..2929928 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -85,7 +85,7 @@ struct vl_dri3_screen
 int64_t last_ust, ns_frame, last_msc, next_msc;
  
 bool flushed;

-   bool is_different_gpu;
+   int is_different_gpu;
  };
  
  static void


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

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Roland Scheidegger]

In an ideal world everybody would zero-intialize the template I suppose
- then it would easily survive such interface changes.
I thought though there shouldn't be many callers but I might have been
wrong about this...

Roland


Am 03.10.2016 um 18:48 schrieb Rob Clark:
> the interface is a bit hand-wavey, ie. w/ things like prsc->screen
> overwriten by driver..  I guess I can try to track down the
> screen->resource_create() callers that aren't zero-init'ing the templ,
> although the # of callers seemed much higher than # of drivers
> 
> BR,
> -R
> 
> On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger  
> wrote:
>> I don't think that's really a good idea. Zero-initializing things is one
>> thing, but explicitly overwrite things which were given to the driver by
>> the st is something else.
>> (I'm not even sure how it works if the driver always overwrites this to
>> zero no matter what. Well I suppose those are the consequences of an
>> interface hack.)
>>
>> I'd say state trackers should be fixed up and call it a day.
>>
>> Roland
>>
>>
>> Am 03.10.2016 um 18:07 schrieb Rob Clark:
>>> Fix potential issues if state-tracker passes in garbage in templ->next
>>> ptr.
>>>
>>> See:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns=
>>>  
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
>>>  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
>>>  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
>>>  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
>>>  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
>>>  src/gallium/drivers/noop/noop_pipe.c   | 1 +
>>>  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
>>>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
>>>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
>>>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
>>>  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
>>>  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
>>>  src/gallium/drivers/rbug/rbug_objects.c| 1 +
>>>  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
>>>  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
>>>  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
>>>  src/gallium/drivers/swr/swr_screen.cpp | 1 +
>>>  src/gallium/drivers/trace/tr_texture.c | 1 +
>>>  src/gallium/drivers/vc4/vc4_resource.c | 1 +
>>>  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
>>>  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
>>>  21 files changed, 30 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
>>> b/src/gallium/drivers/freedreno/freedreno_resource.c
>>> index 1874271..2f37fae 100644
>>> --- a/src/gallium/drivers/freedreno/freedreno_resource.c
>>> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
>>> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
>>>   return NULL;
>>>
>>>   *prsc = *tmpl;
>>> + prsc->next = NULL;
>>>
>>>   pipe_reference_init(>reference, 1);
>>>
>>> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
>>>   return NULL;
>>>
>>>   *prsc = *tmpl;
>>> + prsc->next = NULL;
>>>
>>>   pipe_reference_init(>reference, 1);
>>>
>>> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c 
>>> b/src/gallium/drivers/i915/i915_resource_buffer.c
>>> index 2572fc4..038b1bb 100644
>>> --- a/src/gallium/drivers/i915/i915_resource_buffer.c
>>> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
>>> @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen,
>>>return NULL;
>>>
>>> buf->b.b = *template;
>>> +   buf->b.b.next = NULL;
>>> buf->b.vtbl = _buffer_vtbl;
>>> pipe_reference_init(>b.b.reference, 1);
>>> buf->b.b.screen = screen;
>>> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c 
>>> b/src/gallium/drivers/i915/i915_resource_texture.c
>>> index 4ade04f..a5e2f50 100644
>>> --- a/src/gallium/drivers/i915/i915_resource_texture.c
>>> +++ b/src/gallium/drivers/i915/i915_resource_texture.c
>>> @@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen,
>>>return NULL;
>>>
>>> tex->b.b = *template;
>>> +   tex->b.b.next = NULL;
>>> tex->b.vtbl = _texture_vtbl;
>>> pipe_reference_init(>b.b.reference, 1);
>>> tex->b.b.screen = screen;
>>> @@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen,
>>>return NULL;
>>>
>>> tex->b.b = *template;
>>> +   tex->b.b.next = NULL;
>>> tex->b.vtbl = _texture_vtbl;
>>> 

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Rob Clark]

the interface is a bit hand-wavey, ie. w/ things like prsc->screen
overwriten by driver..  I guess I can try to track down the
screen->resource_create() callers that aren't zero-init'ing the templ,
although the # of callers seemed much higher than # of drivers

BR,
-R

On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger  wrote:
> I don't think that's really a good idea. Zero-initializing things is one
> thing, but explicitly overwrite things which were given to the driver by
> the st is something else.
> (I'm not even sure how it works if the driver always overwrites this to
> zero no matter what. Well I suppose those are the consequences of an
> interface hack.)
>
> I'd say state trackers should be fixed up and call it a day.
>
> Roland
>
>
> Am 03.10.2016 um 18:07 schrieb Rob Clark:
>> Fix potential issues if state-tracker passes in garbage in templ->next
>> ptr.
>>
>> See:
>> https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
>>  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
>>  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
>>  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
>>  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
>>  src/gallium/drivers/noop/noop_pipe.c   | 1 +
>>  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
>>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
>>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
>>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
>>  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
>>  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
>>  src/gallium/drivers/rbug/rbug_objects.c| 1 +
>>  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
>>  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
>>  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
>>  src/gallium/drivers/swr/swr_screen.cpp | 1 +
>>  src/gallium/drivers/trace/tr_texture.c | 1 +
>>  src/gallium/drivers/vc4/vc4_resource.c | 1 +
>>  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
>>  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
>>  21 files changed, 30 insertions(+)
>>
>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
>> b/src/gallium/drivers/freedreno/freedreno_resource.c
>> index 1874271..2f37fae 100644
>> --- a/src/gallium/drivers/freedreno/freedreno_resource.c
>> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
>> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
>>   return NULL;
>>
>>   *prsc = *tmpl;
>> + prsc->next = NULL;
>>
>>   pipe_reference_init(>reference, 1);
>>
>> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
>>   return NULL;
>>
>>   *prsc = *tmpl;
>> + prsc->next = NULL;
>>
>>   pipe_reference_init(>reference, 1);
>>
>> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c 
>> b/src/gallium/drivers/i915/i915_resource_buffer.c
>> index 2572fc4..038b1bb 100644
>> --- a/src/gallium/drivers/i915/i915_resource_buffer.c
>> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
>> @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen,
>>return NULL;
>>
>> buf->b.b = *template;
>> +   buf->b.b.next = NULL;
>> buf->b.vtbl = _buffer_vtbl;
>> pipe_reference_init(>b.b.reference, 1);
>> buf->b.b.screen = screen;
>> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c 
>> b/src/gallium/drivers/i915/i915_resource_texture.c
>> index 4ade04f..a5e2f50 100644
>> --- a/src/gallium/drivers/i915/i915_resource_texture.c
>> +++ b/src/gallium/drivers/i915/i915_resource_texture.c
>> @@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen,
>>return NULL;
>>
>> tex->b.b = *template;
>> +   tex->b.b.next = NULL;
>> tex->b.vtbl = _texture_vtbl;
>> pipe_reference_init(>b.b.reference, 1);
>> tex->b.b.screen = screen;
>> @@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen,
>>return NULL;
>>
>> tex->b.b = *template;
>> +   tex->b.b.next = NULL;
>> tex->b.vtbl = _texture_vtbl;
>> pipe_reference_init(>b.b.reference, 1);
>> tex->b.b.screen = screen;
>> diff --git a/src/gallium/drivers/ilo/ilo_resource.c 
>> b/src/gallium/drivers/ilo/ilo_resource.c
>> index 5ca7e1b..fb294fb 100644
>> --- a/src/gallium/drivers/ilo/ilo_resource.c
>> +++ b/src/gallium/drivers/ilo/ilo_resource.c
>> @@ -555,6 +555,7 @@ tex_create(struct pipe_screen *screen,
>>return NULL;
>>
>> tex->base = *templ;
>> +   tex->base.next = NULL;
>> tex->base.screen = screen;
>> pipe_reference_init(>base.reference, 1);
>>
>> @@ -629,6 +630,7 @@ buf_create(struct pipe_screen *screen, const struct 
>> pipe_resource *templ)
>>

Re: [Mesa-dev] [PATCH 4/9] anv/gen8_pipeline: Use Alternate floating point mode when use_alt_mode is set in prog_data

[Anuj Phogat]

On Sun, Oct 2, 2016 at 1:59 PM, Kenneth Graunke  wrote:
> On Friday, September 30, 2016 3:33:12 PM PDT Anuj Phogat wrote:
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/vulkan/gen8_pipeline.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/intel/vulkan/gen8_pipeline.c 
>> b/src/intel/vulkan/gen8_pipeline.c
>> index 1abb97c..7a9a3cf 100644
>> --- a/src/intel/vulkan/gen8_pipeline.c
>> +++ b/src/intel/vulkan/gen8_pipeline.c
>> @@ -197,7 +197,8 @@ genX(graphics_pipeline_create)(
>>  vs_prog_data->base.base.binding_table.size_bytes / 4;
>>
>>   vs.ThreadDispatchPriority= false;
>> - vs.FloatingPointMode = IEEE754;
>> + vs.FloatingPointMode = 
>> vs_prog_data->base.base.use_alt_mode ?
>> +Alternate : IEEE754;
>>   vs.IllegalOpcodeExceptionEnable  = false;
>>   vs.AccessesUAV   = false;
>>   vs.SoftwareExceptionEnable   = false;
>>
>
> I don't think we need this.  The only reason we use ALT mode is to make
> the POW opcode match the ARB_fragment_program rules for 0^0.  Otherwise,
> we always use IEEE-754.  We should always use IEEE for SPIR-V programs.
> So, adding the condition just adds a tiny bit of CPU overhead.
>
> How about we instead do:
>
>assert(!vs_prog_data->base.base.use_alt_mode);
This sounds good to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs

[Chuck Atkins]

Ping?

On Sep 30, 2016 2:37 PM, "Chuck Atkins"  wrote:

> This fixes a problem where GL headers would only get installed if
> glx was enabled.  So if osmesa was enabled but not glx, then the
> GL headers required by osmesa would be missing from the install.
>
> Signed-off-by: Chuck Atkins 
> ---
>  configure.ac|  2 ++
>  src/Makefile.am | 30 ++
>  src/gallium/Makefile.am |  2 ++
>  src/mesa/Makefile.am| 12 ++--
>  4 files changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1bfac3b..c7be735 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2641,6 +2641,8 @@ fi
>  AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
>  AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
>  AM_CONDITIONAL(HAVE_GALLIUM_OSMESA, test "x$enable_gallium_osmesa" =
> xyes)
> +AM_CONDITIONAL(HAVE_COMMON_OSMESA, test "x$enable_osmesa" = xyes -o \
> +"x$enable_gallium_osmesa" = xyes)
>
>  AM_CONDITIONAL(HAVE_X86_ASM, test "x$asm_arch" = xx86 -o "x$asm_arch" =
> xx86_64)
>  AM_CONDITIONAL(HAVE_X86_64_ASM, test "x$asm_arch" = xx86_64)
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 551f431..c04ee1b 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -47,6 +47,36 @@ CLEANFILES = $(BUILT_SOURCES)
>
>  SUBDIRS = . gtest util mapi/glapi/gen mapi
>
> +if HAVE_OPENGL
> +gldir = $(includedir)/GL
> +gl_HEADERS = \
> +  $(top_srcdir)/include/GL/gl.h \
> +  $(top_srcdir)/include/GL/glext.h \
> +  $(top_srcdir)/include/GL/glcorearb.h \
> +  $(top_srcdir)/include/GL/gl_mangle.h
> +endif
> +
> +if HAVE_GLX
> +glxdir = $(includedir)/GL
> +glx_HEADERS = \
> +  $(top_srcdir)/include/GL/glx.h \
> +  $(top_srcdir)/include/GL/glxext.h \
> +  $(top_srcdir)/include/GL/glx_mangle.h \
> +  $(top_srcdir)/include/GL/mesa_glinterop.h
> +pkgconfigdir = $(libdir)/pkgconfig
> +pkgconfig_DATA = mesa/gl.pc
> +else
> +if HAVE_EGL
> +eglinteropdir = $(includedir)/GL
> +eglinterop_HEADERS = $(top_srcdir)/include/GL/mesa_glinterop.h
> +endif
> +endif
> +
> +if HAVE_COMMON_OSMESA
> +osmesadir = $(includedir)/GL
> +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
> +endif
> +
>  # include only conditionally ?
>  SUBDIRS += compiler
>
> diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
> index 34671ca..caf5fd8 100644
> --- a/src/gallium/Makefile.am
> +++ b/src/gallium/Makefile.am
> @@ -148,6 +148,8 @@ endif
>
>  if HAVE_GALLIUM_OSMESA
>  SUBDIRS += state_trackers/osmesa targets/osmesa
> +osmesadir = $(includedir)/GL
> +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
>  endif
>
>  if HAVE_ST_VA
> diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
> index 037384a..22db400 100644
> --- a/src/mesa/Makefile.am
> +++ b/src/mesa/Makefile.am
> @@ -31,11 +31,8 @@ endif
>
>  if HAVE_OSMESA
>  SUBDIRS += drivers/osmesa
> -endif
> -
> -if HAVE_GLX
> -gldir = $(includedir)/GL
> -gl_HEADERS = $(top_srcdir)/include/GL/*.h
> +osmesadir = $(includedir)/GL
> +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
>  endif
>
>  include Makefile.sources
> @@ -161,11 +158,6 @@ libmesa_sse41_la_SOURCES = \
>
>  libmesa_sse41_la_CFLAGS = $(AM_CFLAGS) $(SSE41_CFLAGS)
>
> -if HAVE_GLX
> -pkgconfigdir = $(libdir)/pkgconfig
> -pkgconfig_DATA = gl.pc
> -endif
> -
>  MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
>  YACC_GEN = $(AM_V_GEN)$(YACC) $(YFLAGS)
>  LEX_GEN = $(AM_V_GEN)$(LEX) $(LFLAGS)
> --
> 2.7.4
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Roland Scheidegger]

I don't think that's really a good idea. Zero-initializing things is one
thing, but explicitly overwrite things which were given to the driver by
the st is something else.
(I'm not even sure how it works if the driver always overwrites this to
zero no matter what. Well I suppose those are the consequences of an
interface hack.)

I'd say state trackers should be fixed up and call it a day.

Roland


Am 03.10.2016 um 18:07 schrieb Rob Clark:
> Fix potential issues if state-tracker passes in garbage in templ->next
> ptr.
> 
> See:
> https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html
> 
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
>  src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
>  src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
>  src/gallium/drivers/ilo/ilo_resource.c | 2 ++
>  src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
>  src/gallium/drivers/noop/noop_pipe.c   | 1 +
>  src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
>  src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
>  src/gallium/drivers/r600/evergreen_compute.c   | 1 +
>  src/gallium/drivers/rbug/rbug_objects.c| 1 +
>  src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
>  src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
>  src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
>  src/gallium/drivers/swr/swr_screen.cpp | 1 +
>  src/gallium/drivers/trace/tr_texture.c | 1 +
>  src/gallium/drivers/vc4/vc4_resource.c | 1 +
>  src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
>  src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
>  21 files changed, 30 insertions(+)
> 
> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
> b/src/gallium/drivers/freedreno/freedreno_resource.c
> index 1874271..2f37fae 100644
> --- a/src/gallium/drivers/freedreno/freedreno_resource.c
> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
>   return NULL;
>  
>   *prsc = *tmpl;
> + prsc->next = NULL;
>  
>   pipe_reference_init(>reference, 1);
>  
> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
>   return NULL;
>  
>   *prsc = *tmpl;
> + prsc->next = NULL;
>  
>   pipe_reference_init(>reference, 1);
>  
> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c 
> b/src/gallium/drivers/i915/i915_resource_buffer.c
> index 2572fc4..038b1bb 100644
> --- a/src/gallium/drivers/i915/i915_resource_buffer.c
> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c
> @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen,
>return NULL;
>  
> buf->b.b = *template;
> +   buf->b.b.next = NULL;
> buf->b.vtbl = _buffer_vtbl;
> pipe_reference_init(>b.b.reference, 1);
> buf->b.b.screen = screen;
> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c 
> b/src/gallium/drivers/i915/i915_resource_texture.c
> index 4ade04f..a5e2f50 100644
> --- a/src/gallium/drivers/i915/i915_resource_texture.c
> +++ b/src/gallium/drivers/i915/i915_resource_texture.c
> @@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen,
>return NULL;
>  
> tex->b.b = *template;
> +   tex->b.b.next = NULL;
> tex->b.vtbl = _texture_vtbl;
> pipe_reference_init(>b.b.reference, 1);
> tex->b.b.screen = screen;
> @@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen,
>return NULL;
>  
> tex->b.b = *template;
> +   tex->b.b.next = NULL;
> tex->b.vtbl = _texture_vtbl;
> pipe_reference_init(>b.b.reference, 1);
> tex->b.b.screen = screen;
> diff --git a/src/gallium/drivers/ilo/ilo_resource.c 
> b/src/gallium/drivers/ilo/ilo_resource.c
> index 5ca7e1b..fb294fb 100644
> --- a/src/gallium/drivers/ilo/ilo_resource.c
> +++ b/src/gallium/drivers/ilo/ilo_resource.c
> @@ -555,6 +555,7 @@ tex_create(struct pipe_screen *screen,
>return NULL;
>  
> tex->base = *templ;
> +   tex->base.next = NULL;
> tex->base.screen = screen;
> pipe_reference_init(>base.reference, 1);
>  
> @@ -629,6 +630,7 @@ buf_create(struct pipe_screen *screen, const struct 
> pipe_resource *templ)
>return NULL;
>  
> buf->base = *templ;
> +   buf->base.next = NULL;
> buf->base.screen = screen;
> pipe_reference_init(>base.reference, 1);
>  
> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
> b/src/gallium/drivers/llvmpipe/lp_texture.c
> index 733253b..49d9c2f 100644
> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
> @@ -247,6 +247,7 @@ 

[Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

[Rob Clark]

Fix potential issues if state-tracker passes in garbage in templ->next
ptr.

See:
https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html

Signed-off-by: Rob Clark 
---
 src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
 src/gallium/drivers/i915/i915_resource_buffer.c| 1 +
 src/gallium/drivers/i915/i915_resource_texture.c   | 2 ++
 src/gallium/drivers/ilo/ilo_resource.c | 2 ++
 src/gallium/drivers/llvmpipe/lp_texture.c  | 2 ++
 src/gallium/drivers/noop/noop_pipe.c   | 1 +
 src/gallium/drivers/nouveau/nouveau_buffer.c   | 1 +
 src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 +
 src/gallium/drivers/r300/r300_screen_buffer.c  | 1 +
 src/gallium/drivers/r600/evergreen_compute.c   | 1 +
 src/gallium/drivers/rbug/rbug_objects.c| 1 +
 src/gallium/drivers/softpipe/sp_texture.c  | 2 ++
 src/gallium/drivers/svga/svga_resource_buffer.c| 1 +
 src/gallium/drivers/svga/svga_resource_texture.c   | 2 ++
 src/gallium/drivers/swr/swr_screen.cpp | 1 +
 src/gallium/drivers/trace/tr_texture.c | 1 +
 src/gallium/drivers/vc4/vc4_resource.c | 1 +
 src/gallium/drivers/virgl/virgl_buffer.c   | 1 +
 src/gallium/drivers/virgl/virgl_texture.c  | 2 ++
 21 files changed, 30 insertions(+)

diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
b/src/gallium/drivers/freedreno/freedreno_resource.c
index 1874271..2f37fae 100644
--- a/src/gallium/drivers/freedreno/freedreno_resource.c
+++ b/src/gallium/drivers/freedreno/freedreno_resource.c
@@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen,
return NULL;
 
*prsc = *tmpl;
+   prsc->next = NULL;
 
pipe_reference_init(>reference, 1);
 
@@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
return NULL;
 
*prsc = *tmpl;
+   prsc->next = NULL;
 
pipe_reference_init(>reference, 1);
 
diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c 
b/src/gallium/drivers/i915/i915_resource_buffer.c
index 2572fc4..038b1bb 100644
--- a/src/gallium/drivers/i915/i915_resource_buffer.c
+++ b/src/gallium/drivers/i915/i915_resource_buffer.c
@@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen,
   return NULL;
 
buf->b.b = *template;
+   buf->b.b.next = NULL;
buf->b.vtbl = _buffer_vtbl;
pipe_reference_init(>b.b.reference, 1);
buf->b.b.screen = screen;
diff --git a/src/gallium/drivers/i915/i915_resource_texture.c 
b/src/gallium/drivers/i915/i915_resource_texture.c
index 4ade04f..a5e2f50 100644
--- a/src/gallium/drivers/i915/i915_resource_texture.c
+++ b/src/gallium/drivers/i915/i915_resource_texture.c
@@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen,
   return NULL;
 
tex->b.b = *template;
+   tex->b.b.next = NULL;
tex->b.vtbl = _texture_vtbl;
pipe_reference_init(>b.b.reference, 1);
tex->b.b.screen = screen;
@@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen,
   return NULL;
 
tex->b.b = *template;
+   tex->b.b.next = NULL;
tex->b.vtbl = _texture_vtbl;
pipe_reference_init(>b.b.reference, 1);
tex->b.b.screen = screen;
diff --git a/src/gallium/drivers/ilo/ilo_resource.c 
b/src/gallium/drivers/ilo/ilo_resource.c
index 5ca7e1b..fb294fb 100644
--- a/src/gallium/drivers/ilo/ilo_resource.c
+++ b/src/gallium/drivers/ilo/ilo_resource.c
@@ -555,6 +555,7 @@ tex_create(struct pipe_screen *screen,
   return NULL;
 
tex->base = *templ;
+   tex->base.next = NULL;
tex->base.screen = screen;
pipe_reference_init(>base.reference, 1);
 
@@ -629,6 +630,7 @@ buf_create(struct pipe_screen *screen, const struct 
pipe_resource *templ)
   return NULL;
 
buf->base = *templ;
+   buf->base.next = NULL;
buf->base.screen = screen;
pipe_reference_init(>base.reference, 1);
 
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 733253b..49d9c2f 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -247,6 +247,7 @@ llvmpipe_resource_create_front(struct pipe_screen *_screen,
   return NULL;
 
lpr->base = *templat;
+   lpr->base.next = NULL;
pipe_reference_init(>base.reference, 1);
lpr->base.screen = >base;
 
@@ -448,6 +449,7 @@ llvmpipe_resource_from_handle(struct pipe_screen *screen,
}
 
lpr->base = *template;
+   lpr->base.next = NULL;
pipe_reference_init(>base.reference, 1);
lpr->base.screen = screen;
 
diff --git a/src/gallium/drivers/noop/noop_pipe.c 
b/src/gallium/drivers/noop/noop_pipe.c
index 3013019..0cbc370 100644
--- a/src/gallium/drivers/noop/noop_pipe.c
+++ b/src/gallium/drivers/noop/noop_pipe.c
@@ -107,6 +107,7 @@ static struct pipe_resource 

Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface

[Zhang, Boyuan]

Hi Andy,

Thanks for the testings.

Regarding to the inconsistencies, the current Vaapi dual instances encoding 
behaviour is random. Whether or not the dual instances is being used depends on 
how early the player calls sync_surface function according to the current 
gstreamer-vaapi's mechanism. e.g. if the player calls sync_surface too early, 
then we don't have enough time to receive and process the 2nd frame and we can 
only end up with single instance encoding for this frame as a result. And the 
random player behaviours depends on the current environment, for example 
cpufreq might be one factor. As a result, we don't guarantee the consistency 
especially when rate control is enabled for dual instances Vaapi encoding, 
since the randomness could result different calculations.

For the corruption/wrong frame order issue, could you please provide more 
detailed information for reproduction? e.g. the clips and commands that can 
reproduce the issue. Does this issue only happen after enabling dual instance 
patch?

Regards,
Boyuan

-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com] 
Sent: October-03-16 7:35 AM
To: Zhang, Boyuan; mesa-dev@lists.freedesktop.org
Cc: deathsim...@vodafone.de
Subject: Re: [PATCH 1/2] st/va: enable dual instances encode by sync surface

Boyuan Zhang wrote:
> This patch improves the performance of Vaapi Encode by enabling dual 
> instances encoding. flush function is not called after each end_frame 
> call. radeon/vce will do flush whenever 2 frames are submitted for 
> encoding. Implement sync surface function to flush only if the frame 
> hasn't been flushed yet.

I filed a bug about this, pinging here as I couldn't add Boyuan to the cc on 
bugzilla.

https://bugs.freedesktop.org/show_bug.cgi?id=98005
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] st/mesa: move all sampler view code into new st_sampler_view.[ch] files

[Brian Paul]

Actually, I just need to bracket some of the assertions with the test 
for GL_TEXTURE_BUFFER.  I'll make that change and re-test before 
pushing.  I suspect I did my piglit run w/ a release build on Windows.


Thanks for reviewing.

-Brian

On 10/02/2016 02:53 PM, Marek Olšák wrote:

One more fix for TBOs is needed:

diff --git a/src/mesa/state_tracker/st_sampler_view.c
b/src/mesa/state_tracker/st_sampler_view.c
index da1df86..a0bea46 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -459,7 +459,7 @@ st_get_texture_sampler_view_from_stobj(struct
st_context *st,

 sv = st_texture_get_sampler_view(st, stObj);

-   if (*sv) {
+   if (*sv && stObj->base.Target != GL_TEXTURE_BUFFER) {
/* Debug check: make sure that the sampler view's parameters are
 * what they're supposed to be.
 */

If fixes this assertion failure:
arb_texture_buffer_range-ranges: state_tracker/st_sampler_view.c:472:
st_get_texture_sampler_view_from_stobj: Assertion `last_level(stObj)
== view->u.tex.last_level' failed.

Marek


On Sun, Oct 2, 2016 at 10:31 PM, Marek Olšák  wrote:

FYI, the series breaks this test:

piglit/bin/glsl-resource-not-bound Buffer -auto -fbo
glsl-resource-not-bound: state_tracker/st_sampler_view.c:456:
st_get_texture_sampler_view_from_stobj: Assertion `stObj->pt' failed.
Aborted

Removing the assertion fixes it. Note that empty TBO slots are NULL.

Marek



On Sun, Oct 2, 2016 at 2:29 PM, Marek Olšák  wrote:

You also need this:

diff --git a/src/mesa/state_tracker/st_vdpau.c
b/src/mesa/state_tracker/st_vdpau.c
index 4f599dd..cafbd3d 100644
--- a/src/mesa/state_tracker/st_vdpau.c
+++ b/src/mesa/state_tracker/st_vdpau.c
@@ -44,6 +44,7 @@
  #include "st_vdpau.h"
  #include "st_context.h"
  #include "st_texture.h"
+#include "st_sampler_view.h"
  #include "st_format.h"
  #include "st_cb_flush.h"

With that fixed, the series is:

Reviewed-by: Marek Olšák 

Marek



On Sat, Oct 1, 2016 at 12:53 AM, Brian Paul  wrote:

Previously, the sampler view code was scattered across several different
files.

Note, the previous REALLOC(), FREE() for st_texture_object::sampler_views
are replaced by realloc(), free() to avoid conflicting macros in Mesa vs.
Gallium.
---
  src/mesa/Makefile.sources  |   2 +
  src/mesa/state_tracker/st_atom_pixeltransfer.c |   1 +
  src/mesa/state_tracker/st_atom_texture.c   | 358 +-
  src/mesa/state_tracker/st_cb_bitmap.c  |   1 +
  src/mesa/state_tracker/st_cb_drawpixels.c  |   1 +
  src/mesa/state_tracker/st_cb_eglimage.c|   2 +
  src/mesa/state_tracker/st_cb_texture.c |   1 +
  src/mesa/state_tracker/st_context.c|   1 +
  src/mesa/state_tracker/st_sampler_view.c   | 487 +
  src/mesa/state_tracker/st_sampler_view.h   |  83 +
  src/mesa/state_tracker/st_texture.c|  93 -
  src/mesa/state_tracker/st_texture.h|  34 --
  12 files changed, 580 insertions(+), 484 deletions(-)
  create mode 100644 src/mesa/state_tracker/st_sampler_view.c
  create mode 100644 src/mesa/state_tracker/st_sampler_view.h

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index fbe5861..410a61a 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -510,6 +510,8 @@ STATETRACKER_FILES = \
 state_tracker/st_pbo.h \
 state_tracker/st_program.c \
 state_tracker/st_program.h \
+   state_tracker/st_sampler_view.c \
+   state_tracker/st_sampler_view.h \
 state_tracker/st_scissor.c \
 state_tracker/st_scissor.h \
 state_tracker/st_texture.c \
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c 
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index 26d8ade..a2951a1 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -30,6 +30,7 @@
   */

  #include "st_context.h"
+#include "st_sampler_view.h"
  #include "st_texture.h"

  #include "util/u_inlines.h"
diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index e5574bd..c8ae62c 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -42,6 +42,7 @@

  #include "st_context.h"
  #include "st_atom.h"
+#include "st_sampler_view.h"
  #include "st_texture.h"
  #include "st_format.h"
  #include "st_cb_texture.h"
@@ -51,363 +52,6 @@
  #include "cso_cache/cso_context.h"


-/**
- * Return swizzle1(swizzle2)
- */
-static unsigned
-swizzle_swizzle(unsigned swizzle1, unsigned swizzle2)
-{
-   unsigned i, swz[4];
-
-   if (swizzle1 == SWIZZLE_XYZW) {
-  /* identity swizzle, no change to swizzle2 */
-  return swizzle2;
-   }
-
-   for (i = 0; i < 4; i++) {
-  unsigned s = GET_SWZ(swizzle1, i);
-  switch (s) {
-  case SWIZZLE_X:
-  case 

Re: [Mesa-dev] [PATCH] anv/formats: Fix build on gcc-4 and earlier

[Ville Syrjälä]

On Fri, Sep 30, 2016 at 04:11:51PM -0700, Jason Ekstrand wrote:
> I remember the first tone you fixed this but when I was going the
> ISL_SWIZZLE stuff,

Wasn't me, or at least I can't recall doing anything of the sort :)

> I couldn't find it in the git log so I went ahead and
> pushed the change. Thanks for fixing it again.
> 
> Reviewed-by: Jason Ekstrand 

Thanks. Pushed.

> 
> On Sep 30, 2016 1:00 PM,  wrote:
> 
> > From: Ville Syrjälä 
> >
> > gcc-4 and earlier don't allow compound literals where a constant
> > is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
> > when populating the anv_formats[] array. There are a few ways around
> > it: First one would be -std=c89/gnu89, but the rest of the code
> > depends on c99 so it's not really an option. The second option
> > would be to upgrade to gcc-5+ where the compiler behaviour was relaxed
> > a bit [1]. And the third option is just to avoid using compound
> > literals. I chose the last option since it keeps gcc-4 and earlier
> > working.
> >
> > [1] https://gcc.gnu.org/gcc-5/porting_to.html
> >
> > Cc: Jason Ekstrand 
> > Cc: Topi Pohjolainen 
> > Fixes: 7ddb21708c80 ("intel/isl: Add an isl_swizzle structure and use it
> > for isl_view swizzles")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  src/intel/vulkan/anv_formats.c | 23 +++
> >  1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_
> > formats.c
> > index 7341d725cd0a..f6915540fb3d 100644
> > --- a/src/intel/vulkan/anv_formats.c
> > +++ b/src/intel/vulkan/anv_formats.c
> > @@ -24,9 +24,24 @@
> >  #include "anv_private.h"
> >  #include "vk_format_info.h"
> >
> > -#define RGBA ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
> > -#define BGRA ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
> > -#define RGB1 ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
> > +/*
> > + * gcc-4 and earlier don't allow compound literals where a constant
> > + * is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
> > + * here. -std=c89/gnu89 would allow it, but we depend on c99 features
> > + * so using -std=c89/gnu89 is not an option. Starting from gcc-5
> > + * compound literals can also be considered constant in -std=c99/gnu99
> > + * mode.
> > + */
> > +#define _ISL_SWIZZLE(r, g, b, a) { \
> > +  ISL_CHANNEL_SELECT_##r, \
> > +  ISL_CHANNEL_SELECT_##g, \
> > +  ISL_CHANNEL_SELECT_##b, \
> > +  ISL_CHANNEL_SELECT_##a, \
> > +}
> > +
> > +#define RGBA _ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
> > +#define BGRA _ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
> > +#define RGB1 _ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
> >
> >  #define swiz_fmt(__vk_fmt, __hw_fmt, __swizzle) \
> > [__vk_fmt] = { \
> > @@ -276,7 +291,7 @@ anv_get_format(const struct gen_device_info *devinfo,
> > VkFormat vk_format,
> >   format.isl_format = rgbx;
> >} else {
> >   format.isl_format = isl_format_rgb_to_rgba(format.isl_format);
> > - format.swizzle = RGB1;
> > + format.swizzle = ISL_SWIZZLE(RED, GREEN, BLUE, ONE);
> >}
> > }
> >
> > --
> > 2.7.4
> >
> >

-- 
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] glsl: optimize copy_propagation_elements pass

[Tapani Pälli]

Ah now I get what you meant and these changes make sense to me, this is 
easier to read. I did not spot regressions in CI run.


On 09/30/2016 06:12 PM, Ian Romanick wrote:

From: Tapani Pälli 

Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.

v2 (idr): Formatting / whitespace fixes.  Embed the acp_ref in the
acp_entry.

v3 (idr): Delete unused copy constructor.  Use while(pop_head) instead
of foreach() { remove }.

Signed-off-by: Tapani Pälli 
Signed-off-by: Ian Romanick 
---
Ugh... I had these uncommitted changes sitting in my tree when I sent
the other patch out.  Sorry for the chaos.

 .../glsl/opt_copy_propagation_elements.cpp | 198 +++--
 1 file changed, 148 insertions(+), 50 deletions(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index e4237cc..be89116 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -46,15 +46,32 @@
 #include "ir_basic_block.h"
 #include "ir_optimization.h"
 #include "compiler/glsl_types.h"
+#include "util/hash_table.h"

 static bool debug = false;

 namespace {

+class acp_entry;
+
+/* Class that refers to acp_entry in another exec_list. Used
+ * when making removals based on rhs.
+ */
+class acp_ref : public exec_node
+{
+public:
+   acp_ref(acp_entry *e)
+   {
+  entry = e;
+   }
+   acp_entry *entry;
+};
+
 class acp_entry : public exec_node
 {
 public:
acp_entry(ir_variable *lhs, ir_variable *rhs, int write_mask, int 
swizzle[4])
+  : rhs_node(this)
{
   this->lhs = lhs;
   this->rhs = rhs;
@@ -62,18 +79,11 @@ public:
   memcpy(this->swizzle, swizzle, sizeof(this->swizzle));
}

-   acp_entry(acp_entry *a)
-   {
-  this->lhs = a->lhs;
-  this->rhs = a->rhs;
-  this->write_mask = a->write_mask;
-  memcpy(this->swizzle, a->swizzle, sizeof(this->swizzle));
-   }
-
ir_variable *lhs;
ir_variable *rhs;
unsigned int write_mask;
int swizzle[4];
+   acp_ref rhs_node;
 };


@@ -98,14 +108,42 @@ public:
   this->killed_all = false;
   this->mem_ctx = ralloc_context(NULL);
   this->shader_mem_ctx = NULL;
-  this->acp = new(mem_ctx) exec_list;
   this->kills = new(mem_ctx) exec_list;
+
+  create_acp();
}
~ir_copy_propagation_elements_visitor()
{
   ralloc_free(mem_ctx);
}

+   void create_acp()
+   {
+  lhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+  rhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+   }
+
+   void destroy_acp()
+   {
+  _mesa_hash_table_destroy(lhs_ht, NULL);
+  _mesa_hash_table_destroy(rhs_ht, NULL);
+   }
+
+   void populate_acp(hash_table *lhs, hash_table *rhs)
+   {
+  struct hash_entry *entry;
+
+  hash_table_foreach(lhs, entry) {
+ _mesa_hash_table_insert(lhs_ht, entry->key, entry->data);
+  }
+
+  hash_table_foreach(rhs, entry) {
+ _mesa_hash_table_insert(rhs_ht, entry->key, entry->data);
+  }
+   }
+
void handle_loop(ir_loop *, bool keep_acp);
virtual ir_visitor_status visit_enter(class ir_loop *);
virtual ir_visitor_status visit_enter(class ir_function_signature *);
@@ -120,8 +158,10 @@ public:
void kill(kill_entry *k);
void handle_if_block(exec_list *instructions);

-   /** List of acp_entry: The available copies to propagate */
-   exec_list *acp;
+   /** Hash of acp_entry: The available copies to propagate */
+   hash_table *lhs_ht;
+   hash_table *rhs_ht;
+
/**
 * List of kill_entry: The variables whose values were killed in this
 * block.
@@ -147,23 +187,29 @@ 
ir_copy_propagation_elements_visitor::visit_enter(ir_function_signature *ir)
 * block.  Any instructions at global scope will be shuffled into
 * main() at link time, so they're irrelevant to us.
 */
-   exec_list *orig_acp = this->acp;
exec_list *orig_kills = this->kills;
bool orig_killed_all = this->killed_all;

-   this->acp = new(mem_ctx) exec_list;
+   hash_table *orig_lhs_ht = lhs_ht;
+   hash_table *orig_rhs_ht = rhs_ht;
+
this->kills = new(mem_ctx) exec_list;
this->killed_all = false;

+   create_acp();
+
visit_list_elements(this, >body);

-   ralloc_free(this->acp);
ralloc_free(this->kills);

+   destroy_acp();
+
this->kills = orig_kills;
-   this->acp = orig_acp;
this->killed_all = orig_killed_all;

+   lhs_ht = orig_lhs_ht;
+   rhs_ht = orig_rhs_ht;
+
return visit_continue_with_parent;
 }

@@ -249,17 +295,19 @@ 
ir_copy_propagation_elements_visitor::handle_rvalue(ir_rvalue **ir)
/* Try to find ACP 

Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface

[Andy Furniss]

Boyuan Zhang wrote:

This patch improves the performance of Vaapi Encode by enabling dual
instances encoding. flush function is not called after each end_frame
call. radeon/vce will do flush whenever 2 frames are submitted for
encoding. Implement sync surface function to flush only if the frame
hasn't been flushed yet.


I filed a bug about this, pinging here as I couldn't add Boyuan to the
cc on bugzilla.

https://bugs.freedesktop.org/show_bug.cgi?id=98005
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017

[Jason Ekstrand]

On Oct 3, 2016 12:19 AM, "Albert Freeman"  wrote:
>
> year.month or year.dayoutofdaysthatyear

Why are we adding more options to an already confused discussion?

> dayoutoofdaysthatyear skips lots of integers quickly: reducing
> confusion of where is release x.(y - something) and better handles
> quick fix releases
> but makes it harder to determine how far into the year the release is
> although with some effort can be converted into an exact date

Quick fix releases are already handled by the stable release system which I
don't think anyone is recommending we get rid of.  Also, I haven't heard
anyone complain that year.quarter (really, year.releaseofyear) isn't
shipping enough integers.  I don't see what problem your suggestion is
solving.

> On 2 October 2016 at 14:22, Tobias Klausmann
>  wrote:
> >
> >
> > On 02.10.2016 13:56, Nicolai Hähnle wrote:
> >>
> >> On 01.10.2016 22:22, Tobias Klausmann wrote:
> >>>
> >>> On 01.10.2016 21:46, Marek Olšák wrote:
> 
>  Hi,
> 
>  I propose that we use versioning in the form of "year.quarter".
> 
>  2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
>  quarters of the year, respectively.
>  2018 would start with 18.0, then 18.1, 18.2, 18.3.
> 
>  The motivation is that you can easily tell when a specific Mesa
>  version was released with an accuracy of 3 months.
> 
>  That's the only scheme that seems practical to me. Everything else
>  seems arbitrary or random.
> 
>  Opinions?
> >>>
> >>>
> >>> Why not just use year.month instead, would be more accurate...and
> >>> releases happen semi random anyway and not after a given time.
> >>
> >>
> >> That's fine for something like Ubuntu where they really stick to their
two
> >> releases per year, in the same months each year. I'm not so sure that
that's
> >> a realistic goal for Mesa, and if releases *aren't* consistently
happening
> >> in the same months, you end up introducing a lot of confusion about
which
> >> version numbers exist and which don't.
> >
> >
> > This is true, but also holds true for year.quarter, if we miss one
quarterly
> > release (18.1, 18.2, 18.4, whoops where is 18.3).
> >
> >>
> >> Time-based with YY.0 for the first release of the year, and then YY.1,
> >> YY.2, etc. works fine.
> >
> >
> > Thats allright and would help in not confuse people so much, but with
it you
> > miss the "when was it released again?" thing Marek tried to introduce.
> >
> > Greetings,
> > Tobias
> >
> >
> >>
> >> Cheers,
> >> Nicolai
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97230] MATLAB hangs if DRI3 enabled with intel driver

[bugzilla-daemon]

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

--- Comment #7 from Eero Tamminen  ---
(In reply to sergio.callegari from comment #6)
> Number of threads is very very large... anything that can be grepped?

It's better to see the whole output.  If the output is long, just add it as
attachment instead of as comment.

-- 
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 97230] MATLAB hangs if DRI3 enabled with intel driver

[bugzilla-daemon]

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

--- Comment #6 from sergio.calleg...@gmail.com ---
Number of threads is very very large... anything that can be grepped?

-- 
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] intel: fix compilation warning on gen_get_device_info

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 03/10/16 07:32, Tapani Pälli wrote:

(warning: 'const' type qualifier on return type has no effect)

Signed-off-by: Tapani Pälli 
---
  src/intel/common/gen_device_info.c | 2 +-
  src/intel/common/gen_device_info.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_device_info.c 
b/src/intel/common/gen_device_info.c
index 98669b3..30df0b2 100644
--- a/src/intel/common/gen_device_info.c
+++ b/src/intel/common/gen_device_info.c
@@ -487,7 +487,7 @@ static const struct gen_device_info gen_device_info_kbl_gt4 
= {
 .num_slices = 3,
  };
  
-const bool

+bool
  gen_get_device_info(int devid, struct gen_device_info *devinfo)
  {
 switch (devid) {
diff --git a/src/intel/common/gen_device_info.h 
b/src/intel/common/gen_device_info.h
index 964e429..7347db5 100644
--- a/src/intel/common/gen_device_info.h
+++ b/src/intel/common/gen_device_info.h
@@ -143,5 +143,5 @@ struct gen_device_info
 /** @} */
  };
  
-const bool gen_get_device_info(int devid, struct gen_device_info *devinfo);

+bool gen_get_device_info(int devid, struct gen_device_info *devinfo);
  const char *gen_get_device_name(int devid);



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

Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017

[Albert Freeman]

year.month or year.dayoutofdaysthatyear

dayoutoofdaysthatyear skips lots of integers quickly: reducing
confusion of where is release x.(y - something) and better handles
quick fix releases
but makes it harder to determine how far into the year the release is
although with some effort can be converted into an exact date

On 2 October 2016 at 14:22, Tobias Klausmann
 wrote:
>
>
> On 02.10.2016 13:56, Nicolai Hähnle wrote:
>>
>> On 01.10.2016 22:22, Tobias Klausmann wrote:
>>>
>>> On 01.10.2016 21:46, Marek Olšák wrote:

 Hi,

 I propose that we use versioning in the form of "year.quarter".

 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
 quarters of the year, respectively.
 2018 would start with 18.0, then 18.1, 18.2, 18.3.

 The motivation is that you can easily tell when a specific Mesa
 version was released with an accuracy of 3 months.

 That's the only scheme that seems practical to me. Everything else
 seems arbitrary or random.

 Opinions?
>>>
>>>
>>> Why not just use year.month instead, would be more accurate...and
>>> releases happen semi random anyway and not after a given time.
>>
>>
>> That's fine for something like Ubuntu where they really stick to their two
>> releases per year, in the same months each year. I'm not so sure that that's
>> a realistic goal for Mesa, and if releases *aren't* consistently happening
>> in the same months, you end up introducing a lot of confusion about which
>> version numbers exist and which don't.
>
>
> This is true, but also holds true for year.quarter, if we miss one quarterly
> release (18.1, 18.2, 18.4, whoops where is 18.3).
>
>>
>> Time-based with YY.0 for the first release of the year, and then YY.1,
>> YY.2, etc. works fine.
>
>
> Thats allright and would help in not confuse people so much, but with it you
> miss the "when was it released again?" thing Marek tried to introduce.
>
> Greetings,
> Tobias
>
>
>>
>> Cheers,
>> Nicolai
>
>
> ___
> 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] mesa/llvmpipe select alpha visual

[Thomas Søndergaard]

On 1 October 2016 at 02:46, Roland Scheidegger  wrote:

> I'm not familiar with this code but presumably the xlib code is less
> tested than dri one, so if it differs there changing it probably
> wouldn't hurt.
> IIRC in the past there were actually apps which were quite sensitive to
> this stuff (for instance, things like not requesting depth buffer and
> still expecting one and similar), albeit the apps were buggy in this case.
> I'm not actually even sure that even with visual which has alpha this
> should actually be visible in the end? Totally not my area of expertise,
> unfortunately...
>

Not mine either. I am not doing anything further to pursue this, but now
the information is out there if other developers run into the same problem.

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

Re: [Mesa-dev] Error when trying to compile RADV

[Michel Dänzer]

On 02/10/16 08:28 PM, Jakub Hlusička wrote:
> I ended up having to use `env LLVM_CONFIG=llvm-config-3.9` in order to
> get it to compile.

FWIW, passing --with-llvm-prefix=/usr/lib/llvm-3.9 to the configure
script might do the trick as well. That'll be recorded in the
config.status file (not sure about that wrt LLVM_CONFIG).


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

[Mesa-dev] [PATCH] intel: fix compilation warning on gen_get_device_info

[Tapani Pälli]

(warning: 'const' type qualifier on return type has no effect)

Signed-off-by: Tapani Pälli 
---
 src/intel/common/gen_device_info.c | 2 +-
 src/intel/common/gen_device_info.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_device_info.c 
b/src/intel/common/gen_device_info.c
index 98669b3..30df0b2 100644
--- a/src/intel/common/gen_device_info.c
+++ b/src/intel/common/gen_device_info.c
@@ -487,7 +487,7 @@ static const struct gen_device_info gen_device_info_kbl_gt4 
= {
.num_slices = 3,
 };
 
-const bool
+bool
 gen_get_device_info(int devid, struct gen_device_info *devinfo)
 {
switch (devid) {
diff --git a/src/intel/common/gen_device_info.h 
b/src/intel/common/gen_device_info.h
index 964e429..7347db5 100644
--- a/src/intel/common/gen_device_info.h
+++ b/src/intel/common/gen_device_info.h
@@ -143,5 +143,5 @@ struct gen_device_info
/** @} */
 };
 
-const bool gen_get_device_info(int devid, struct gen_device_info *devinfo);
+bool gen_get_device_info(int devid, struct gen_device_info *devinfo);
 const char *gen_get_device_name(int devid);
-- 
2.7.4

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

[Mesa-dev] [PATCH 76/77] glsl: create separate 32bit and 64bit versions of shader cache objects

[Timothy Arceri]

Pointers will have different lengths so we simply create a different
sha1 for each platform.

In theory we should be able to share cached shaders as we cache all
pointer as uint64_t however if a pointer is ever added to one of the
structs we write to file with blob_write_bytes() we run the risk of
introducing a bug that would be difficult to reproduce or report from
a user point of veiw. It's also very unlikely that Mesa developers will
regularly regression test the interaction of cache sharing between
platforms.
---
 src/compiler/glsl/shader_cache.cpp | 2 +-
 src/compiler/glsl/shader_cache.h   | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index af053a9..a899d58 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1315,7 +1315,7 @@ shader_cache_read_program_metadata(struct gl_context *ctx,
/* Include bindings when creating sha1. These bindings change the resulting
 * binary so they are just as important as the shader source.
 */
-   char *bindings_str = ralloc_strdup(NULL, "vb: ");
+   char *bindings_str = ralloc_strdup(NULL, CACHED_PROGRAM"\n vb: ");
prog->AttributeBindings->iterate(create_binding_str, _str);
ralloc_strcat(_str, "fb: ");
prog->FragDataBindings->iterate(create_binding_str, _str);
diff --git a/src/compiler/glsl/shader_cache.h b/src/compiler/glsl/shader_cache.h
index ae055ac..e35fa8f 100644
--- a/src/compiler/glsl/shader_cache.h
+++ b/src/compiler/glsl/shader_cache.h
@@ -27,6 +27,12 @@
 
 #include "cache.h"
 
+#if __x86_64__
+#define CACHED_PROGRAM "program64:"
+#else
+#define CACHED_PROGRAM "program32:"
+#endif
+
 static uint64_t inline
 ptr_to_uint64_t(void *ptr)
 {
-- 
2.7.4

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

[Mesa-dev] [PATCH 70/77] util: make string_to_uint_map hash table public

[Timothy Arceri]

This will allow us to make use of the hash_table_call_foreach()
function from outside the object.
---
 src/util/string_to_uint_map.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/util/string_to_uint_map.h b/src/util/string_to_uint_map.h
index e0533ec..18f5166 100644
--- a/src/util/string_to_uint_map.h
+++ b/src/util/string_to_uint_map.h
@@ -150,6 +150,8 @@ public:
  free(dup_key);
}
 
+   struct hash_table *ht;
+
 private:
static void delete_key(const void *key, void *data, void *closure)
{
@@ -169,8 +171,6 @@ private:
 
   wrapper->callback((const char *) key, value, wrapper->closure);
}
-
-   struct hash_table *ht;
 };
 
 #endif /* __cplusplus */
-- 
2.7.4

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

[Mesa-dev] [PATCH 69/77] glsl/i965: make a copy of the shader source and use it at fallback

[Timothy Arceri]

A number of things can happen that change the shader source after it is
compiled or linked.

For example:
- Source changed after it is first compiled
- Source changed after linking
- Shader detached after linking

In order to be able to fallback to a full rebuild on a cache miss we
make a copy of the shader source it into the new FallbackShaders
field when linking.
---
 src/compiler/glsl/linker.cpp | 27 +++---
 src/compiler/glsl/shader_cache.cpp   | 29 
 src/mesa/drivers/dri/i965/brw_shader_cache.c | 26 +++--
 src/mesa/main/mtypes.h   |  3 +++
 src/mesa/main/shaderobj.c|  6 ++
 src/mesa/program/ir_to_mesa.cpp  | 16 +++
 6 files changed, 86 insertions(+), 21 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 6e05cad..fca65cb 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -4623,7 +4623,9 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
 * fixed-function.  This applies to the case where all stages are
 * missing.
 */
-   if (prog->NumShaders == 0) {
+   unsigned shader_count = is_cache_fallback ?
+  prog->NumFallbackShaders : prog->NumShaders;
+   if (shader_count == 0) {
   if (ctx->API != API_OPENGL_COMPAT)
  linker_error(prog, "no shaders attached to the program\n");
   return;
@@ -4665,44 +4667,47 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
struct gl_shader **shader_list[MESA_SHADER_STAGES];
unsigned num_shaders[MESA_SHADER_STAGES];
 
+   struct gl_shader **shaders = is_cache_fallback ?
+  prog->FallbackShaders : prog->Shaders;
+
for (int i = 0; i < MESA_SHADER_STAGES; i++) {
   shader_list[i] = (struct gl_shader **)
- calloc(prog->NumShaders, sizeof(struct gl_shader *));
+ calloc(shader_count, sizeof(struct gl_shader *));
   num_shaders[i] = 0;
}
 
unsigned min_version = UINT_MAX;
unsigned max_version = 0;
-   for (unsigned i = 0; i < prog->NumShaders; i++) {
-  min_version = MIN2(min_version, prog->Shaders[i]->Version);
-  max_version = MAX2(max_version, prog->Shaders[i]->Version);
+   for (unsigned i = 0; i < shader_count; i++) {
+  min_version = MIN2(min_version, shaders[i]->Version);
+  max_version = MAX2(max_version, shaders[i]->Version);
 
-  if (prog->Shaders[i]->IsES != prog->Shaders[0]->IsES) {
+  if (shaders[i]->IsES != shaders[0]->IsES) {
  linker_error(prog, "all shaders must use same shading "
   "language version\n");
  goto done;
   }
 
-  if (prog->Shaders[i]->info.ARB_fragment_coord_conventions_enable) {
+  if (shaders[i]->info.ARB_fragment_coord_conventions_enable) {
  prog->ARB_fragment_coord_conventions_enable = true;
   }
 
-  gl_shader_stage shader_type = prog->Shaders[i]->Stage;
-  shader_list[shader_type][num_shaders[shader_type]] = prog->Shaders[i];
+  gl_shader_stage shader_type = shaders[i]->Stage;
+  shader_list[shader_type][num_shaders[shader_type]] = shaders[i];
   num_shaders[shader_type]++;
}
 
/* In desktop GLSL, different shader versions may be linked together.  In
 * GLSL ES, all shader versions must be the same.
 */
-   if (prog->Shaders[0]->IsES && min_version != max_version) {
+   if (shaders[0]->IsES && min_version != max_version) {
   linker_error(prog, "all shaders must use same shading "
"language version\n");
   goto done;
}
 
prog->Version = max_version;
-   prog->IsES = prog->Shaders[0]->IsES;
+   prog->IsES = shaders[0]->IsES;
 
/* Some shaders have to be linked with some other shaders present.
 */
diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index 18a338c..95e932a 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1265,6 +1265,35 @@ shader_cache_read_program_metadata(struct gl_context 
*ctx,
if (!cache)
   return false;
 
+   /* Free previous fallback information */
+   if (prog->FallbackShaders == NULL) {
+  prog->NumFallbackShaders = 0;
+  for (unsigned i = 0; i < prog->NumFallbackShaders; i++) {
+ ralloc_free(prog->FallbackShaders);
+ prog->FallbackShaders = NULL;
+  }
+   }
+
+   /* Shaders could be recompiled using different source code after linking,
+* or the shader could be detached from the program so store some
+* information about the shader to be used in case of fallback.
+*/
+   prog->NumFallbackShaders = prog->NumShaders;
+   prog->FallbackShaders = (struct gl_shader **)
+  reralloc(NULL, prog->FallbackShaders, struct gl_shader *,
+   prog->NumShaders);
+   for (unsigned i = 0; i < prog->NumShaders; i++) {
+  prog->FallbackShaders[i] = rzalloc(prog->FallbackShaders,
+   

[Mesa-dev] [PATCH 74/77] i965: add an env var to force cache fallback

[Timothy Arceri]

There are a number of reasons we can get to the program upload stage
and have neither IR nor a valid cached binary. For example the binary
may have been randomly evicted from the cache to make room or the
binary may have been created with an old version of Mesa.

This environment variable enabled us to force the fallback path that
would be taken in these cases and makes it easier to debug these
otherwise hard to reproduce scenarios.
---
 docs/envvars.html| 1 +
 src/mesa/drivers/dri/i965/brw_shader_cache.c | 4 
 src/mesa/drivers/dri/i965/intel_debug.c  | 1 +
 src/mesa/drivers/dri/i965/intel_debug.h  | 1 +
 4 files changed, 7 insertions(+)

diff --git a/docs/envvars.html b/docs/envvars.html
index f0f18b3..8b10682 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -161,6 +161,7 @@ See the Xlib software driver 
page for details.
miptree - emit messages about miptrees
perf - emit messages about performance issues
perfmon - emit messages about AMD_performance_monitor
+   cache_fb - force cached shader to be ignored and do a full recompile 
via the fallback path
bat - emit batch information
pix - emit messages about pixel operations
buf - emit messages about buffer objects
diff --git a/src/mesa/drivers/dri/i965/brw_shader_cache.c 
b/src/mesa/drivers/dri/i965/brw_shader_cache.c
index 7d0e8a0..e4b764f 100644
--- a/src/mesa/drivers/dri/i965/brw_shader_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_shader_cache.c
@@ -469,6 +469,10 @@ upload_cached_program(struct brw_context *brw, 
gl_shader_stage stage)
if (prog->TransformFeedback.NumVarying > 0 || prog->SeparateShader)
   return;
 
+   /* Force the cache to fallback to a full recompile */
+   if (INTEL_DEBUG & DEBUG_CACHE_FALLBACK)
+  goto FAIL;
+
if (!read_and_upload(brw, cache, , prog, stage))
   goto FAIL;
 
diff --git a/src/mesa/drivers/dri/i965/intel_debug.c 
b/src/mesa/drivers/dri/i965/intel_debug.c
index 33e8402..dc0799a 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.c
+++ b/src/mesa/drivers/dri/i965/intel_debug.c
@@ -81,6 +81,7 @@ static const struct debug_control debug_control[] = {
{ "l3",  DEBUG_L3 },
{ "do32",DEBUG_DO32 },
{ "norbc",   DEBUG_NO_RBC },
+   { "cache_fb",DEBUG_CACHE_FALLBACK },
{ NULL,0 }
 };
 
diff --git a/src/mesa/drivers/dri/i965/intel_debug.h 
b/src/mesa/drivers/dri/i965/intel_debug.h
index f407b6a..756b552 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.h
+++ b/src/mesa/drivers/dri/i965/intel_debug.h
@@ -74,6 +74,7 @@ extern uint64_t INTEL_DEBUG;
 #define DEBUG_L3  (1ull << 38)
 #define DEBUG_DO32(1ull << 39)
 #define DEBUG_NO_RBC  (1ull << 40)
+#define DEBUG_CACHE_FALLBACK  (1ull << 41)
 
 #ifdef HAVE_ANDROID_PLATFORM
 #define LOG_TAG "INTEL-MESA"
-- 
2.7.4

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

[Mesa-dev] [PATCH 67/77] glsl: cache more fragment shader state

[Timothy Arceri]

---
 src/compiler/glsl/shader_cache.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index 304f80e..c4ead81 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1061,6 +1061,10 @@ write_shader_metadata(struct blob *metadata, 
gl_linked_shader *shader)
 (struct gl_fragment_program *) glprog;
  blob_write_bytes(metadata, fprog->InterpQualifier,
   sizeof(fprog->InterpQualifier));
+ blob_write_uint32(metadata, fprog->IsCentroid);
+ blob_write_uint32(metadata, fprog->IsSample);
+ blob_write_uint32(metadata, fprog->UsesDFdy);
+ blob_write_uint32(metadata, fprog->UsesKill);
   }
 
   write_shader_parameters(metadata, glprog->Parameters);
@@ -1137,6 +1141,10 @@ read_shader_metadata(struct blob_reader *metadata,
 (struct gl_fragment_program *) glprog;
  blob_copy_bytes(metadata, (uint8_t *) fprog->InterpQualifier,
  sizeof(fprog->InterpQualifier));
+ fprog->IsCentroid = blob_read_uint32(metadata);
+ fprog->IsSample = blob_read_uint32(metadata);
+ fprog->UsesDFdy = blob_read_uint32(metadata);
+ fprog->UsesKill = blob_read_uint32(metadata);
   }
 
   glprog->Parameters = _mesa_new_parameter_list();
-- 
2.7.4

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

[Mesa-dev] [PATCH 77/77] i965: create separate 32bit and 64bit versions of shader cache objects

[Timothy Arceri]

Pointers will have different lengths so we simply create a different
sha1 for each platform.

In theory we should be able to share cached shaders as we cache all
pointer as uint64_t however if a pointer is ever added to one of the
structs we write to file with blob_write_bytes() we run the risk of
introducing a bug that would be difficult to reproduce or report from
a user point of veiw. It's also very unlikely that Mesa developers will
regularly regression test the interaction of cache sharing between
platforms.
---
 src/mesa/drivers/dri/i965/brw_shader_cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_shader_cache.c 
b/src/mesa/drivers/dri/i965/brw_shader_cache.c
index e4b764f..daaf3ff 100644
--- a/src/mesa/drivers/dri/i965/brw_shader_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_shader_cache.c
@@ -69,7 +69,7 @@ gen_shader_sha1(struct brw_context *brw, struct 
gl_shader_program *prog,
char manifest[256];
int offset = 0;
 
-   offset += snprintf(manifest, sizeof(manifest), "program: %s\n",
+   offset += snprintf(manifest, sizeof(manifest), CACHED_PROGRAM" %s\n",
   _mesa_sha1_format(sha1_buf, prog->sha1));
 
_mesa_sha1_compute(key, key_size(stage), sha1);
-- 
2.7.4

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

[Mesa-dev] [PATCH 68/77] glsl: cache tess control shader VerticesOut

[Timothy Arceri]

---
 src/compiler/glsl/shader_cache.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index c4ead81..18a338c 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1042,6 +1042,10 @@ write_shader_metadata(struct blob *metadata, 
gl_linked_shader *shader)
   blob_write_bytes(metadata, shader->ImageUnits,
sizeof(shader->ImageUnits));
 
+  if (shader->Stage == MESA_SHADER_TESS_CTRL) {
+ blob_write_uint32(metadata, shader->info.TessCtrl.VerticesOut);
+  }
+
   if (shader->Stage == MESA_SHADER_TESS_EVAL) {
  blob_write_uint32(metadata, shader->info.TessEval.PrimitiveMode);
  blob_write_uint32(metadata, shader->info.TessEval.Spacing);
@@ -1113,6 +1117,10 @@ read_shader_metadata(struct blob_reader *metadata,
   blob_copy_bytes(metadata, (uint8_t *) linked->ImageUnits,
   sizeof(linked->ImageUnits));
 
+  if (linked->Stage == MESA_SHADER_TESS_CTRL) {
+ linked->info.TessCtrl.VerticesOut = blob_read_uint32(metadata);
+  }
+
   /* Here we load values into both structs. The program struct is used by
* backends for codegen and the shader struct is used for api queries.
*/
-- 
2.7.4

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

[Mesa-dev] [PATCH 73/77] glsl: don't lose sampler or image units when cache falls back

[Timothy Arceri]

The old linked shader is deleted so we need to make sure we hold onto
these values.
---
 src/compiler/glsl/linker.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index df02198..ecdf7ef 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -4767,6 +4767,7 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
"type of shader\n");
}
 
+   unsigned char img_units[MAX_IMAGE_UNIFORMS];
gl_uniform_block **ubos[MESA_SHADER_STAGES];
gl_uniform_block **ssbos[MESA_SHADER_STAGES];
unsigned num_ubos[MESA_SHADER_STAGES];
@@ -4782,6 +4783,8 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
 ssbos[i] = prog->_LinkedShaders[i]->ShaderStorageBlocks;
 num_ubos[i] = prog->_LinkedShaders[i]->NumUniformBlocks;
 num_ssbos[i] = prog->_LinkedShaders[i]->NumShaderStorageBlocks;
+memcpy(img_units, prog->_LinkedShaders[i]->ImageUnits,
+   sizeof(img_units));
  }
 
  _mesa_delete_linked_shader(ctx, prog->_LinkedShaders[i]);
@@ -4834,6 +4837,11 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
 prog->_LinkedShaders[stage]->NumUniformBlocks = num_ubos[stage];
 prog->_LinkedShaders[stage]->NumShaderStorageBlocks =
num_ssbos[stage];
+memcpy(prog->_LinkedShaders[stage]->ImageUnits, img_units,
+   sizeof(img_units));
+memcpy(prog->_LinkedShaders[stage]->SamplerUnits,
+   prog->cache_progs[stage]->SamplerUnits,
+   sizeof(prog->_LinkedShaders[stage]->SamplerUnits));
  }
   }
}
-- 
2.7.4

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

[Mesa-dev] [PATCH 72/77] glsl: retain buffer block state on cache fallback

[Timothy Arceri]

---
 src/compiler/glsl/linker.cpp | 70 
 1 file changed, 45 insertions(+), 25 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index ac03283..df02198 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2054,7 +2054,7 @@ link_intrastage_shaders(void *mem_ctx,
 struct gl_context *ctx,
 struct gl_shader_program *prog,
 struct gl_shader **shader_list,
-unsigned num_shaders)
+unsigned num_shaders, bool is_cache_fallback)
 {
struct gl_uniform_block *ubo_blocks = NULL;
struct gl_uniform_block *ssbo_blocks = NULL;
@@ -2186,32 +2186,34 @@ link_intrastage_shaders(void *mem_ctx,
v.run(linked->ir);
v.fixup_unnamed_interface_types();
 
-   /* Link up uniform blocks defined within this stage. */
-   link_uniform_blocks(mem_ctx, ctx, prog, linked, _blocks,
-   _ubo_blocks, _blocks, _ssbo_blocks);
+   if (!is_cache_fallback) {
+  /* Link up uniform blocks defined within this stage. */
+  link_uniform_blocks(mem_ctx, ctx, prog, linked, _blocks,
+  _ubo_blocks, _blocks, _ssbo_blocks);
 
-   if (!prog->LinkStatus) {
-  _mesa_delete_linked_shader(ctx, linked);
-  return NULL;
-   }
-
-   /* Copy ubo blocks to linked shader list */
-   linked->UniformBlocks =
-  ralloc_array(linked, gl_uniform_block *, num_ubo_blocks);
-   ralloc_steal(linked, ubo_blocks);
-   for (unsigned i = 0; i < num_ubo_blocks; i++) {
-  linked->UniformBlocks[i] = _blocks[i];
-   }
-   linked->NumUniformBlocks = num_ubo_blocks;
+  if (!prog->LinkStatus) {
+ _mesa_delete_linked_shader(ctx, linked);
+ return NULL;
+  }
 
-   /* Copy ssbo blocks to linked shader list */
-   linked->ShaderStorageBlocks =
-  ralloc_array(linked, gl_uniform_block *, num_ssbo_blocks);
-   ralloc_steal(linked, ssbo_blocks);
-   for (unsigned i = 0; i < num_ssbo_blocks; i++) {
-  linked->ShaderStorageBlocks[i] = _blocks[i];
+  /* Copy ubo blocks to linked shader list */
+  linked->UniformBlocks =
+ ralloc_array(linked, gl_uniform_block *, num_ubo_blocks);
+  ralloc_steal(linked, ubo_blocks);
+  for (unsigned i = 0; i < num_ubo_blocks; i++) {
+ linked->UniformBlocks[i] = _blocks[i];
+  }
+  linked->NumUniformBlocks = num_ubo_blocks;
+
+  /* Copy ssbo blocks to linked shader list */
+  linked->ShaderStorageBlocks =
+ ralloc_array(linked, gl_uniform_block *, num_ssbo_blocks);
+  ralloc_steal(linked, ssbo_blocks);
+  for (unsigned i = 0; i < num_ssbo_blocks; i++) {
+ linked->ShaderStorageBlocks[i] = _blocks[i];
+  }
+  linked->NumShaderStorageBlocks = num_ssbo_blocks;
}
-   linked->NumShaderStorageBlocks = num_ssbo_blocks;
 
/* At this point linked should contain all of the linked IR, so
 * validate it to make sure nothing went wrong.
@@ -4765,10 +4767,21 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
"type of shader\n");
}
 
+   gl_uniform_block **ubos[MESA_SHADER_STAGES];
+   gl_uniform_block **ssbos[MESA_SHADER_STAGES];
+   unsigned num_ubos[MESA_SHADER_STAGES];
+   unsigned num_ssbos[MESA_SHADER_STAGES];
for (unsigned int i = 0; i < MESA_SHADER_STAGES; i++) {
   if (prog->_LinkedShaders[i] != NULL) {
+ /* Before deleting shader store anything we don't want to lose if we
+  * are here because of a shader cache miss.
+  */
  if (is_cache_fallback) {
 prog->cache_progs[i] = prog->_LinkedShaders[i]->Program;
+ubos[i] = prog->_LinkedShaders[i]->UniformBlocks;
+ssbos[i] = prog->_LinkedShaders[i]->ShaderStorageBlocks;
+num_ubos[i] = prog->_LinkedShaders[i]->NumUniformBlocks;
+num_ssbos[i] = prog->_LinkedShaders[i]->NumShaderStorageBlocks;
  }
 
  _mesa_delete_linked_shader(ctx, prog->_LinkedShaders[i]);
@@ -4783,7 +4796,7 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
   if (num_shaders[stage] > 0) {
  gl_linked_shader *const sh =
 link_intrastage_shaders(mem_ctx, ctx, prog, shader_list[stage],
-num_shaders[stage]);
+num_shaders[stage], is_cache_fallback);
 
  if (!prog->LinkStatus) {
 if (sh)
@@ -4815,6 +4828,13 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
  }
 
  prog->_LinkedShaders[stage] = sh;
+ if (is_cache_fallback) {
+prog->_LinkedShaders[stage]->UniformBlocks = ubos[stage];
+prog->_LinkedShaders[stage]->ShaderStorageBlocks = ssbos[stage];
+prog->_LinkedShaders[stage]->NumUniformBlocks = num_ubos[stage];
+

[Mesa-dev] [PATCH 64/77] glsl: enable shader cache for tess stages

[Timothy Arceri]

---
 src/compiler/glsl/shader_cache.cpp | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index fdd1b98..304f80e 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1186,12 +1186,8 @@ shader_cache_write_program_metadata(struct gl_context 
*ctx,
if (!cache)
   return;
 
-   /* We should be able to serialize any valid combinations of shaders, but
-* for now we only support vs and fs.
-*/
-   if (prog->_LinkedShaders[MESA_SHADER_TESS_EVAL] ||
-   prog->_LinkedShaders[MESA_SHADER_TESS_CTRL] ||
-   prog->_LinkedShaders[MESA_SHADER_COMPUTE])
+   /* Currently we don't support caching compute shaders. */
+   if (prog->_LinkedShaders[MESA_SHADER_COMPUTE])
   return;
 
metadata = blob_create(NULL);
@@ -1254,9 +1250,7 @@ shader_cache_read_program_metadata(struct gl_context *ctx,
   return false;
 
for (unsigned i = 0; i < prog->NumShaders; i++) {
-  if (prog->Shaders[i]->Stage != MESA_SHADER_VERTEX &&
-  prog->Shaders[i]->Stage != MESA_SHADER_GEOMETRY &&
-  prog->Shaders[i]->Stage != MESA_SHADER_FRAGMENT) {
+  if (prog->Shaders[i]->Stage == MESA_SHADER_COMPUTE) {
  compile_shaders(ctx, prog);
  return false;
   }
-- 
2.7.4

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

[Mesa-dev] [PATCH 65/77] i965: add shader cache support for tess stages

[Timothy Arceri]

---
 src/mesa/drivers/dri/i965/brw_compiler.h |  4 ++
 src/mesa/drivers/dri/i965/brw_shader_cache.c | 66 
 src/mesa/drivers/dri/i965/brw_tcs.c  | 24 --
 src/mesa/drivers/dri/i965/brw_tes.c  | 23 --
 4 files changed, 109 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 41e9ebc..7cab880 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -656,6 +656,8 @@ struct brw_tcs_prog_data
 
/** Number vertices in output patch */
int instances;
+
+   unsigned program_size;
 };
 
 
@@ -666,6 +668,8 @@ struct brw_tes_prog_data
enum brw_tess_partitioning partitioning;
enum brw_tess_output_topology output_topology;
enum brw_tess_domain domain;
+
+   unsigned program_size;
 };
 
 struct brw_gs_prog_data
diff --git a/src/mesa/drivers/dri/i965/brw_shader_cache.c 
b/src/mesa/drivers/dri/i965/brw_shader_cache.c
index 6b75303..c4ef567 100644
--- a/src/mesa/drivers/dri/i965/brw_shader_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_shader_cache.c
@@ -99,12 +99,20 @@ fallback_to_full_recompile(struct brw_context *brw,
 
   struct gl_program *vp =
  shProg->_LinkedShaders[MESA_SHADER_VERTEX]->Program;
+  struct gl_program *tcp = shProg->_LinkedShaders[MESA_SHADER_TESS_CTRL] ?
+ shProg->_LinkedShaders[MESA_SHADER_TESS_CTRL]->Program : NULL;
+  struct gl_program *tep = shProg->_LinkedShaders[MESA_SHADER_TESS_EVAL] ?
+ shProg->_LinkedShaders[MESA_SHADER_TESS_EVAL]->Program : NULL;
   struct gl_program *gp = shProg->_LinkedShaders[MESA_SHADER_GEOMETRY] ?
  shProg->_LinkedShaders[MESA_SHADER_GEOMETRY]->Program : NULL;
   struct gl_program *fp = shProg->_LinkedShaders[MESA_SHADER_FRAGMENT] ?
  shProg->_LinkedShaders[MESA_SHADER_FRAGMENT]->Program : NULL;
 
   vp->cache_fallback = true;
+  if (tcp)
+ tcp->cache_fallback = true;
+  if (tep)
+ tep->cache_fallback = true;
   if (gp)
  gp->cache_fallback = true;
   if (fp)
@@ -117,6 +125,10 @@ fallback_to_full_recompile(struct brw_context *brw,
   _mesa_glsl_link_shader(>ctx, shProg, true);
 
   vp->cache_fallback = false;
+  if (tcp)
+ tcp->cache_fallback = true;
+  if (tep)
+ tep->cache_fallback = true;
   if (gp)
  gp->cache_fallback = false;
   if (fp)
@@ -296,6 +308,8 @@ read_and_upload(struct brw_context *brw, struct 
program_cache *cache,
 
struct brw_stage_prog_data *prog_data;
struct brw_wm_prog_key wm_key;
+   struct brw_tcs_prog_key tcs_key;
+   struct brw_tes_prog_key tes_key;
struct brw_gs_prog_key gs_key;
struct brw_vs_prog_key vs_key;
struct brw_stage_state *stage_state;
@@ -316,6 +330,16 @@ read_and_upload(struct brw_context *brw, struct 
program_cache *cache,
case MESA_SHADER_VERTEX:
   gen_shader_sha1(brw, prog, stage, _key, binary_sha1);
   break;
+   case MESA_SHADER_TESS_CTRL:
+  brw_tcs_populate_key(brw, _key);
+  tcs_key.program_string_id = 0;
+  gen_shader_sha1(brw, prog, stage, _key, binary_sha1);
+  break;
+   case MESA_SHADER_TESS_EVAL:
+  brw_tes_populate_key(brw, _key);
+  tes_key.program_string_id = 0;
+  gen_shader_sha1(brw, prog, stage, _key, binary_sha1);
+  break;
case MESA_SHADER_GEOMETRY:
   brw_gs_populate_key(brw, _key);
   gs_key.program_string_id = 0;
@@ -369,6 +393,18 @@ read_and_upload(struct brw_context *brw, struct 
program_cache *cache,
   SET_UPLOAD_PRAMS(vs, VS, vp, base.base)
   break;
}
+   case MESA_SHADER_TESS_CTRL: {
+  struct brw_tess_ctrl_program *tcp =
+ (struct brw_tess_ctrl_program *)brw->tess_ctrl_program;
+  SET_UPLOAD_PRAMS(tcs, TCS, tcp, base.base)
+  break;
+   }
+   case MESA_SHADER_TESS_EVAL: {
+  struct brw_tess_eval_program *tep =
+ (struct brw_tess_eval_program *)brw->tess_eval_program;
+  SET_UPLOAD_PRAMS(tes, TES, tep, base.base)
+  break;
+   }
case MESA_SHADER_GEOMETRY: {
   struct brw_geometry_program *gp =
  (struct brw_geometry_program *)brw->geometry_program;
@@ -576,6 +612,36 @@ write_cached_program(struct brw_context *brw)
   }
}
 
+   if (prog->_LinkedShaders[MESA_SHADER_TESS_CTRL]) {
+  struct brw_tcs_prog_key tcs_key;
+  brw_tcs_populate_key(brw, _key);
+  tcs_key.program_string_id = 0;
+
+  if (!write_program_data(brw, prog, _key,
+  >tcs.prog_data->base.base,
+  brw->tcs.prog_data->program_size,
+  brw->tcs.prog_data, sizeof *brw->tcs.prog_data,
+  brw->tcs.base.prog_offset, cache,
+  MESA_SHADER_TESS_CTRL)) {
+ return;
+  }
+   }
+
+   if (prog->_LinkedShaders[MESA_SHADER_TESS_EVAL]) {
+  struct brw_tes_prog_key tes_key;
+  

[Mesa-dev] [PATCH 75/77] i965: pad out brw_stage_prog_data pointers to 64bits

[Timothy Arceri]

In order for this struct to have the same size on 64bit and 32bit
platforms we uses unions to make sure the pointers always take up
at least 64bits. This is useful for making sure we always write
the same size data to disk in the shader cache.
---
 src/mesa/drivers/dri/i965/brw_compiler.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 7cab880..5240609 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -361,11 +361,11 @@ struct brw_stage_prog_data {
/* Pointers to tracked values (only valid once
 * _mesa_load_state_parameters has been called at runtime).
 */
-   const union gl_constant_value **param;
-   const union gl_constant_value **pull_param;
+   union { const union gl_constant_value **param; uint64_t pv; };
+   union { const union gl_constant_value **pull_param; uint64_t ppv; };
 
/** Image metadata passed to the shader as uniforms. */
-   struct brw_image_param *image_param;
+   union { struct brw_image_param *image_param; uint64_t ipv; };
 };
 
 /* Data about a particular attempt to compile a program.  Note that
-- 
2.7.4

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

[Mesa-dev] [PATCH 71/77] glsl/mesa: make a copy of attribute bindings in case of cache fallback

[Timothy Arceri]

If the shader cache falls back to doing a compile and link we need the
original attribute bindings as they could have changed after the program
was first linked.
---
 src/compiler/glsl/linker.cpp   |  5 -
 src/compiler/glsl/shader_cache.cpp | 11 +++
 src/mesa/main/mtypes.h |  7 +++
 src/mesa/main/shaderobj.c  |  6 ++
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index fca65cb..ac03283 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2520,7 +2520,10 @@ assign_attribute_or_color_locations(void *mem_ctx,
   } else if (target_index == MESA_SHADER_VERTEX) {
  unsigned binding;
 
- if (prog->AttributeBindings->get(binding, var->name)) {
+ bool has_binding = sh->Program && sh->Program->cache_fallback ?
+prog->FallbackAttributeBindings->get(binding, var->name) :
+prog->AttributeBindings->get(binding, var->name);
+ if (has_binding) {
 assert(binding >= VERT_ATTRIB_GENERIC0);
 var->data.location = binding;
 var->data.is_unmatched_generic_inout = 0;
diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index 95e932a..af053a9 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -726,9 +726,18 @@ read_hash_table(struct blob_reader *metadata, struct 
string_to_uint_map *hash)
 }
 
 static void
+copy_hash_entry(const void *key, void *data, void *closure)
+{
+   struct string_to_uint_map *ht = (struct string_to_uint_map *) closure;
+   ht->put((intptr_t) data, strdup((const char *) key));
+}
+
+static void
 write_hash_tables(struct blob *metadata, struct gl_shader_program *prog)
 {
write_hash_table(metadata, prog->AttributeBindings);
+   hash_table_call_foreach(prog->AttributeBindings->ht, copy_hash_entry,
+   prog->FallbackAttributeBindings);
write_hash_table(metadata, prog->FragDataBindings);
write_hash_table(metadata, prog->FragDataIndexBindings);
 }
@@ -737,6 +746,8 @@ static void
 read_hash_tables(struct blob_reader *metadata, struct gl_shader_program *prog)
 {
read_hash_table(metadata, prog->AttributeBindings);
+   hash_table_call_foreach(prog->AttributeBindings->ht, copy_hash_entry,
+   prog->FallbackAttributeBindings);
read_hash_table(metadata, prog->FragDataBindings);
read_hash_table(metadata, prog->FragDataIndexBindings);
 }
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 0b2e5ec..efcd50e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2747,6 +2747,13 @@ struct gl_shader_program
struct string_to_uint_map *AttributeBindings;
 
/**
+* If the shader cache falls back to doing a compile and link we need the
+* original attribute bindings as they could have changed after the program
+* was first linked.
+*/
+   struct string_to_uint_map *FallbackAttributeBindings;
+
+   /**
 * User-defined fragment data bindings
 *
 * These are set via \c glBindFragDataLocation and are used to direct the
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 005756a..f95f423 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -257,6 +257,7 @@ init_shader_program(struct gl_shader_program *prog)
prog->RefCount = 1;
 
prog->AttributeBindings = string_to_uint_map_ctor();
+   prog->FallbackAttributeBindings = string_to_uint_map_ctor();
prog->FragDataBindings = string_to_uint_map_ctor();
prog->FragDataIndexBindings = string_to_uint_map_ctor();
 
@@ -362,6 +363,11 @@ _mesa_free_shader_program_data(struct gl_context *ctx,
   shProg->AttributeBindings = NULL;
}
 
+   if (shProg->FallbackAttributeBindings) {
+  string_to_uint_map_dtor(shProg->FallbackAttributeBindings);
+  shProg->FallbackAttributeBindings = NULL;
+   }
+
if (shProg->FragDataBindings) {
   string_to_uint_map_dtor(shProg->FragDataBindings);
   shProg->FragDataBindings = NULL;
-- 
2.7.4

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

[Mesa-dev] [PATCH 66/77] glsl: don't reprocess or clear UBOs on cache fallback

[Timothy Arceri]

---
 src/compiler/glsl/linker.cpp | 14 --
 src/mesa/main/shaderobj.c| 16 +---
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 1b4a87a..6e05cad 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -4904,13 +4904,15 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
if (prog->SeparateShader)
   disable_varying_optimizations_for_sso(prog);
 
-   /* Process UBOs */
-   if (!interstage_cross_validate_uniform_blocks(prog, false))
-  goto done;
+   if (create_program_metadata) {
+  /* Process UBOs */
+  if (!interstage_cross_validate_uniform_blocks(prog, false))
+ goto done;
 
-   /* Process SSBOs */
-   if (!interstage_cross_validate_uniform_blocks(prog, true))
-  goto done;
+  /* Process SSBOs */
+  if (!interstage_cross_validate_uniform_blocks(prog, true))
+ goto done;
+   }
 
/* Do common optimization before assigning storage for attributes,
 * uniforms, and varyings.  Later optimization could possibly make
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 98f7b9e..7f94c1c 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -318,13 +318,15 @@ _mesa_clear_shader_program_data(struct gl_shader_program 
*shProg,
ralloc_free(shProg->InfoLog);
shProg->InfoLog = ralloc_strdup(shProg, "");
 
-   ralloc_free(shProg->UniformBlocks);
-   shProg->UniformBlocks = NULL;
-   shProg->NumUniformBlocks = 0;
-
-   ralloc_free(shProg->ShaderStorageBlocks);
-   shProg->ShaderStorageBlocks = NULL;
-   shProg->NumShaderStorageBlocks = 0;
+   if (!is_cache_fallback) {
+  ralloc_free(shProg->UniformBlocks);
+  shProg->UniformBlocks = NULL;
+  shProg->NumUniformBlocks = 0;
+
+  ralloc_free(shProg->ShaderStorageBlocks);
+  shProg->ShaderStorageBlocks = NULL;
+  shProg->NumShaderStorageBlocks = 0;
+   }
 
if (shProg->AtomicBuffers && !is_cache_fallback) {
   ralloc_free(shProg->AtomicBuffers);
-- 
2.7.4

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

[Mesa-dev] [PATCH 63/77] glsl: cache tes layout qualifiers

[Timothy Arceri]

---
 src/compiler/glsl/shader_cache.cpp | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index 002b8c3..fdd1b98 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1042,6 +1042,13 @@ write_shader_metadata(struct blob *metadata, 
gl_linked_shader *shader)
   blob_write_bytes(metadata, shader->ImageUnits,
sizeof(shader->ImageUnits));
 
+  if (shader->Stage == MESA_SHADER_TESS_EVAL) {
+ blob_write_uint32(metadata, shader->info.TessEval.PrimitiveMode);
+ blob_write_uint32(metadata, shader->info.TessEval.Spacing);
+ blob_write_uint32(metadata, shader->info.TessEval.VertexOrder);
+ blob_write_uint32(metadata, shader->info.TessEval.PointMode);
+  }
+
   if (shader->Stage == MESA_SHADER_GEOMETRY) {
  blob_write_uint32(metadata, shader->info.Geom.VerticesOut);
  blob_write_uint32(metadata, shader->info.Geom.Invocations);
@@ -1102,6 +1109,22 @@ read_shader_metadata(struct blob_reader *metadata,
   blob_copy_bytes(metadata, (uint8_t *) linked->ImageUnits,
   sizeof(linked->ImageUnits));
 
+  /* Here we load values into both structs. The program struct is used by
+   * backends for codegen and the shader struct is used for api queries.
+   */
+  if (linked->Stage == MESA_SHADER_TESS_EVAL) {
+ struct gl_tess_eval_program *tep =
+(struct gl_tess_eval_program *) glprog;
+ linked->info.TessEval.PrimitiveMode = blob_read_uint32(metadata);
+ tep->PrimitiveMode = linked->info.TessEval.PrimitiveMode;
+ linked->info.TessEval.Spacing = blob_read_uint32(metadata);
+ tep->Spacing = linked->info.TessEval.Spacing;
+ linked->info.TessEval.VertexOrder = blob_read_uint32(metadata);
+ tep->VertexOrder = linked->info.TessEval.VertexOrder;
+ linked->info.TessEval.PointMode = blob_read_uint32(metadata);
+ tep->PointMode = linked->info.TessEval.PointMode;
+  }
+
   if (linked->Stage == MESA_SHADER_GEOMETRY) {
  linked->info.Geom.VerticesOut = blob_read_uint32(metadata);
  linked->info.Geom.Invocations = blob_read_uint32(metadata);
-- 
2.7.4

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

[Mesa-dev] [PATCH 59/77] glsl: add shader cache support for geometry shaders

[Timothy Arceri]

---
 src/compiler/glsl/shader_cache.cpp | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index 9b37155..c26974c 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -1040,6 +1040,13 @@ write_shader_metadata(struct blob *metadata, 
gl_linked_shader *shader)
   blob_write_bytes(metadata, shader->ImageUnits,
sizeof(shader->ImageUnits));
 
+  if (shader->Stage == MESA_SHADER_GEOMETRY) {
+ blob_write_uint32(metadata, shader->info.Geom.VerticesOut);
+ blob_write_uint32(metadata, shader->info.Geom.Invocations);
+ blob_write_uint32(metadata, shader->info.Geom.InputType);
+ blob_write_uint32(metadata, shader->info.Geom.OutputType);
+  }
+
   if (shader->Stage == MESA_SHADER_FRAGMENT) {
  struct gl_fragment_program *fprog =
 (struct gl_fragment_program *) glprog;
@@ -1091,6 +1098,13 @@ read_shader_metadata(struct blob_reader *metadata,
   blob_copy_bytes(metadata, (uint8_t *) linked->ImageUnits,
   sizeof(linked->ImageUnits));
 
+  if (linked->Stage == MESA_SHADER_GEOMETRY) {
+ linked->info.Geom.VerticesOut = blob_read_uint32(metadata);
+ linked->info.Geom.Invocations = blob_read_uint32(metadata);
+ linked->info.Geom.InputType = blob_read_uint32(metadata);
+ linked->info.Geom.OutputType = blob_read_uint32(metadata);
+  }
+
   if (linked->Stage == MESA_SHADER_FRAGMENT) {
  struct gl_fragment_program *fprog =
 (struct gl_fragment_program *) glprog;
@@ -1148,8 +1162,7 @@ shader_cache_write_program_metadata(struct gl_context 
*ctx,
/* We should be able to serialize any valid combinations of shaders, but
 * for now we only support vs and fs.
 */
-   if (prog->_LinkedShaders[MESA_SHADER_GEOMETRY] ||
-   prog->_LinkedShaders[MESA_SHADER_TESS_EVAL] ||
+   if (prog->_LinkedShaders[MESA_SHADER_TESS_EVAL] ||
prog->_LinkedShaders[MESA_SHADER_TESS_CTRL] ||
prog->_LinkedShaders[MESA_SHADER_COMPUTE])
   return;
@@ -1215,6 +1228,7 @@ shader_cache_read_program_metadata(struct gl_context *ctx,
 
for (unsigned i = 0; i < prog->NumShaders; i++) {
   if (prog->Shaders[i]->Stage != MESA_SHADER_VERTEX &&
+  prog->Shaders[i]->Stage != MESA_SHADER_GEOMETRY &&
   prog->Shaders[i]->Stage != MESA_SHADER_FRAGMENT) {
  compile_shaders(ctx, prog);
  return false;
-- 
2.7.4

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

[Mesa-dev] [PATCH 57/77] i965: don't recreate program struct on cache fallback

[Timothy Arceri]

We already have the struct and paramlist we don't want to recreate
them as this is unnecessary and would mean we would need to remap
anything using the old paramlist to the addresses of the new one.
---
 src/compiler/glsl/linker.cpp |  5 
 src/mesa/drivers/dri/i965/brw_link.cpp   | 44 
 src/mesa/drivers/dri/i965/brw_shader_cache.c | 28 +++---
 src/mesa/main/mtypes.h   |  5 
 src/mesa/main/shaderobj.c|  3 +-
 5 files changed, 55 insertions(+), 30 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index a32b3cd..1b4a87a 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -72,6 +72,7 @@
 #include "ir.h"
 #include "program.h"
 #include "program/prog_instruction.h"
+#include "program/program.h"
 #include "util/set.h"
 #include "util/string_to_uint_map.h"
 #include "linker.h"
@@ -4758,6 +4759,10 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog,
 
for (unsigned int i = 0; i < MESA_SHADER_STAGES; i++) {
   if (prog->_LinkedShaders[i] != NULL) {
+ if (is_cache_fallback) {
+prog->cache_progs[i] = prog->_LinkedShaders[i]->Program;
+ }
+
  _mesa_delete_linked_shader(ctx, prog->_LinkedShaders[i]);
   }
 
diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 6c236b6..7a7ac26 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -223,24 +223,31 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg,
   if (!shader)
  continue;
 
-  struct gl_program *prog =
- ctx->Driver.NewProgram(ctx, _mesa_shader_stage_to_program(stage),
-0);
+  struct gl_program *prog;
+  if (!is_cache_fallback) {
+ prog =
+ctx->Driver.NewProgram(ctx, _mesa_shader_stage_to_program(stage),
+   0);
+  } else {
+ prog = shProg->cache_progs[stage];
+  }
+
   if (!prog)
 return false;
 
-  _mesa_copy_linked_program_data((gl_shader_stage) stage, shProg, prog);
-
   process_glsl_ir(brw, shProg, shader);
 
-  /* Make a pass over the IR to add state references for any built-in
-   * uniforms that are used.  This has to be done now (during linking).
-   * Code generation doesn't happen until the first time this shader is
-   * used for rendering.  Waiting until then to generate the parameters is
-   * too late.  At that point, the values for the built-in uniforms won't
-   * get sent to the shader.
-   */
   if (!is_cache_fallback) {
+ _mesa_copy_linked_program_data((gl_shader_stage) stage, shProg,
+prog);
+
+ /* Make a pass over the IR to add state references for any built-in
+  * uniforms that are used.  This has to be done now (during linking).
+  * Code generation doesn't happen until the first time this shader is
+  * used for rendering.  Waiting until then to generate the parameters
+  * is too late.  At that point, the values for the built-in uniforms
+  * won't get sent to the shader.
+  */
  prog->Parameters = _mesa_new_parameter_list();
  foreach_in_list(ir_instruction, node, shader->ir) {
 ir_variable *var = node->as_variable();
@@ -257,18 +264,17 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg,
  (gl_state_index *) slots[i].tokens);
 }
  }
-  }
 
-  do_set_program_inouts(shader->ir, prog, shader->Stage);
+ do_set_program_inouts(shader->ir, prog, shader->Stage);
 
-  prog->SamplersUsed = shader->active_samplers;
-  prog->ShadowSamplers = shader->shadow_samplers;
-  _mesa_update_shader_textures_used(shProg, prog);
+ prog->SamplersUsed = shader->active_samplers;
+ prog->ShadowSamplers = shader->shadow_samplers;
+ _mesa_update_shader_textures_used(shProg, prog);
+ brw_add_texrect_params(prog);
+  }
 
   _mesa_reference_program(ctx, >Program, prog);
 
-  brw_add_texrect_params(prog);
-
   prog->nir = brw_create_nir(brw, shProg, prog, (gl_shader_stage) stage,
  compiler->scalar_stage[stage]);
 
diff --git a/src/mesa/drivers/dri/i965/brw_shader_cache.c 
b/src/mesa/drivers/dri/i965/brw_shader_cache.c
index 12b3db2..e326195 100644
--- a/src/mesa/drivers/dri/i965/brw_shader_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_shader_cache.c
@@ -96,34 +96,42 @@ fallback_to_full_recompile(struct brw_context *brw,
   struct gl_shader_program *shProg =
  brw->ctx._Shader->CurrentProgram[MESA_SHADER_VERTEX];
 
+  struct gl_program *vp =
+ shProg->_LinkedShaders[MESA_SHADER_VERTEX]->Program;
+   

[Mesa-dev] [PATCH 60/77] i965: add shader cache support for geometry shaders

[Timothy Arceri]

---
 src/mesa/drivers/dri/i965/brw_compiler.h |  2 ++
 src/mesa/drivers/dri/i965/brw_gs.c   | 23 ++
 src/mesa/drivers/dri/i965/brw_shader_cache.c | 29 +++-
 3 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 9a78c72..41e9ebc 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -733,6 +733,8 @@ struct brw_gs_prog_data
 * binding table entry.
 */
unsigned char transform_feedback_swizzles[64 /* BRW_MAX_SOL_BINDINGS */];
+
+   unsigned program_size;
 };
 
 
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c 
b/src/mesa/drivers/dri/i965/brw_gs.c
index 7b668ba..464b27e 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -194,6 +194,8 @@ brw_codegen_gs_prog(struct brw_context *brw,
 _state->prog_offset, >gs.prog_data, gp);
ralloc_free(mem_ctx);
 
+   brw->gs.prog_data->program_size = program_size;
+
return true;
 }
 
@@ -259,10 +261,23 @@ brw_upload_gs_prog(struct brw_context *brw)
if (!brw_search_cache(>cache, BRW_CACHE_GS_PROG,
  , sizeof(key),
  _state->prog_offset, >gs.prog_data)) {
-  bool success = brw_codegen_gs_prog(brw, current[MESA_SHADER_GEOMETRY],
- gp, );
-  assert(success);
-  (void)success;
+#ifdef ENABLE_SHADER_CACHE
+  upload_cached_program(brw, MESA_SHADER_GEOMETRY);
+
+  /* If upload from disk cache failed call codegen */
+  if (!current[MESA_SHADER_GEOMETRY] ||
+  !current[MESA_SHADER_GEOMETRY]->program_written_to_cache) {
+ gp = (struct brw_geometry_program *) brw->geometry_program;
+ gp->id = key.program_string_id;
+#endif
+ bool success = brw_codegen_gs_prog(brw,
+current[MESA_SHADER_GEOMETRY], gp,
+);
+ assert(success);
+ (void)success;
+#ifdef ENABLE_SHADER_CACHE
+  }
+#endif
}
brw->gs.base.prog_data = >gs.prog_data->base.base;
 }
diff --git a/src/mesa/drivers/dri/i965/brw_shader_cache.c 
b/src/mesa/drivers/dri/i965/brw_shader_cache.c
index 280d117..3d06c2b 100644
--- a/src/mesa/drivers/dri/i965/brw_shader_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_shader_cache.c
@@ -34,6 +34,7 @@
 #include 
 
 #include "brw_context.h"
+#include "brw_gs.h"
 #include "brw_state.h"
 #include "brw_vs.h"
 #include "brw_wm.h"
@@ -289,6 +290,7 @@ read_and_upload(struct brw_context *brw, struct 
program_cache *cache,
 
struct brw_stage_prog_data *prog_data;
struct brw_wm_prog_key wm_key;
+   struct brw_gs_prog_key gs_key;
struct brw_vs_prog_key vs_key;
struct brw_stage_state *stage_state;
 
@@ -308,6 +310,11 @@ read_and_upload(struct brw_context *brw, struct 
program_cache *cache,
case MESA_SHADER_VERTEX:
   gen_shader_sha1(brw, prog, stage, _key, binary_sha1);
   break;
+   case MESA_SHADER_GEOMETRY:
+  brw_gs_populate_key(brw, _key);
+  gs_key.program_string_id = 0;
+  gen_shader_sha1(brw, prog, stage, _key, binary_sha1);
+  break;
case MESA_SHADER_FRAGMENT:
   brw_wm_populate_key(brw, _key);
   gen_shader_sha1(brw, prog, stage, _key, binary_sha1);
@@ -356,6 +363,12 @@ read_and_upload(struct brw_context *brw, struct 
program_cache *cache,
   SET_UPLOAD_PRAMS(vs, VS, vp, base.base)
   break;
}
+   case MESA_SHADER_GEOMETRY: {
+  struct brw_geometry_program *gp =
+ (struct brw_geometry_program *)brw->geometry_program;
+  SET_UPLOAD_PRAMS(gs, GS, gp, base.base)
+  break;
+   }
case MESA_SHADER_FRAGMENT: {
   struct brw_fragment_program *wp =
  (struct brw_fragment_program *)brw->fragment_program;
@@ -464,7 +477,6 @@ write_program_data(struct brw_context *brw, struct 
gl_shader_program *prog,
struct program_cache *cache, gl_shader_stage stage)
 {
unsigned char sha1[20];
-   char buf[41];
 
struct blob *binary = blob_create (NULL);
if (binary == NULL)
@@ -558,6 +570,21 @@ write_cached_program(struct brw_context *brw)
   }
}
 
+   if (prog->_LinkedShaders[MESA_SHADER_GEOMETRY]) {
+  struct brw_gs_prog_key gs_key;
+  brw_gs_populate_key(brw, _key);
+  gs_key.program_string_id = 0;
+
+  if (!write_program_data(brw, prog, _key,
+  >gs.prog_data->base.base,
+  brw->gs.prog_data->program_size,
+  brw->gs.prog_data, sizeof *brw->gs.prog_data,
+  brw->gs.base.prog_offset, cache,
+  MESA_SHADER_GEOMETRY)) {
+ return;
+  }
+   }
+
if (prog->_LinkedShaders[MESA_SHADER_FRAGMENT]) {
   struct brw_wm_prog_key wm_key;
   brw_wm_populate_key(brw, _key);
-- 
2.7.4

[Mesa-dev] [PATCH 53/77] glsl: don't try to load/store buffer object values in the cache

[Timothy Arceri]

Also add an assert to catch buffer overflows.
---
 src/compiler/glsl/shader_cache.cpp | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/shader_cache.cpp 
b/src/compiler/glsl/shader_cache.cpp
index a8ca719..fe553df 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -488,6 +488,7 @@ write_uniforms(struct blob *metadata, struct 
gl_shader_program *prog)
   blob_write_uint32(metadata, prog->UniformStorage[i].offset);
   blob_write_uint32(metadata, prog->UniformStorage[i].array_stride);
   blob_write_uint32(metadata, prog->UniformStorage[i].hidden);
+  blob_write_uint32(metadata, prog->UniformStorage[i].is_shader_storage);
   blob_write_uint32(metadata, prog->UniformStorage[i].matrix_stride);
   blob_write_uint32(metadata, prog->UniformStorage[i].row_major);
   blob_write_uint32(metadata,
@@ -507,7 +508,9 @@ write_uniforms(struct blob *metadata, struct 
gl_shader_program *prog)
 */
blob_write_uint32(metadata, prog->NumHiddenUniforms);
for (i = 0; i < prog->NumUniformStorage; i++) {
-  if (!prog->UniformStorage[i].builtin) {
+  if (!prog->UniformStorage[i].builtin &&
+  !prog->UniformStorage[i].is_shader_storage &&
+  prog->UniformStorage[i].block_index == -1) {
  unsigned vec_size = values_for_type(prog->UniformStorage[i].type) *
 MAX2(prog->UniformStorage[i].array_elements, 1);
  blob_write_bytes(metadata, prog->UniformStorage[i].storage,
@@ -549,6 +552,7 @@ read_uniforms(struct blob_reader *metadata, struct 
gl_shader_program *prog)
   uniforms[i].offset = blob_read_uint32(metadata);
   uniforms[i].array_stride = blob_read_uint32(metadata);
   uniforms[i].hidden = blob_read_uint32(metadata);
+  uniforms[i].is_shader_storage = blob_read_uint32(metadata);
   uniforms[i].matrix_stride = blob_read_uint32(metadata);
   uniforms[i].row_major = blob_read_uint32(metadata);
   uniforms[i].num_compatible_subroutines = blob_read_uint32(metadata);
@@ -564,12 +568,17 @@ read_uniforms(struct blob_reader *metadata, struct 
gl_shader_program *prog)
/* Restore uniform values. */
prog->NumHiddenUniforms = blob_read_uint32(metadata);
for (i = 0; i < prog->NumUniformStorage; i++) {
-  if (!prog->UniformStorage[i].builtin) {
+  if (!prog->UniformStorage[i].builtin &&
+  !prog->UniformStorage[i].is_shader_storage &&
+  prog->UniformStorage[i].block_index == -1) {
  unsigned vec_size = values_for_type(prog->UniformStorage[i].type) *
 MAX2(prog->UniformStorage[i].array_elements, 1);
  blob_copy_bytes(metadata,
  (uint8_t *) prog->UniformStorage[i].storage,
  sizeof(union gl_constant_value) * vec_size);
+
+assert(vec_size + prog->UniformStorage[i].storage <=
+   data +  prog->NumUniformDataSlots);
   }
}
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH 56/77] i965: don't rebuild param list after cache miss

[Timothy Arceri]

Previously we ended up with the same param list but in a different
location, which will mess up the pointers stored in the new cache
object if all stages were not fully rebuilt e.g. after a fragment
program cache miss.

This also stops the list from being leaked on fallback.
---
 src/mesa/drivers/dri/i965/brw_link.cpp | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 9acbaa3..6c236b6 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -228,7 +228,6 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg,
 0);
   if (!prog)
 return false;
-  prog->Parameters = _mesa_new_parameter_list();
 
   _mesa_copy_linked_program_data((gl_shader_stage) stage, shProg, prog);
 
@@ -241,19 +240,22 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg,
* too late.  At that point, the values for the built-in uniforms won't
* get sent to the shader.
*/
-  foreach_in_list(ir_instruction, node, shader->ir) {
- ir_variable *var = node->as_variable();
-
- if ((var == NULL) || (var->data.mode != ir_var_uniform)
- || (strncmp(var->name, "gl_", 3) != 0))
-continue;
-
- const ir_state_slot *const slots = var->get_state_slots();
- assert(slots != NULL);
-
- for (unsigned int i = 0; i < var->get_num_state_slots(); i++) {
-_mesa_add_state_reference(prog->Parameters,
-  (gl_state_index *) slots[i].tokens);
+  if (!is_cache_fallback) {
+ prog->Parameters = _mesa_new_parameter_list();
+ foreach_in_list(ir_instruction, node, shader->ir) {
+ir_variable *var = node->as_variable();
+
+if ((var == NULL) || (var->data.mode != ir_var_uniform)
+|| (strncmp(var->name, "gl_", 3) != 0))
+   continue;
+
+const ir_state_slot *const slots = var->get_state_slots();
+assert(slots != NULL);
+
+for (unsigned int i = 0; i < var->get_num_state_slots(); i++) {
+   _mesa_add_state_reference(prog->Parameters,
+ (gl_state_index *) slots[i].tokens);
+}
  }
   }
 
-- 
2.7.4

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