Re: [Mesa-dev] [PATCH] st/mesa: move, clean-up shader variant key decls/inits

2019-03-08 Thread Brian Paul

On 03/08/2019 09:53 AM, Roland Scheidegger wrote:

Am 07.03.19 um 17:20 schrieb Brian Paul:

Move the variant key declarations inside the scope they're used.
Use designated initializers instead of memset() calls.

I don't think this will always work as intended, since there's
non-explicit padding bits in the key, and AFAIK even with c11 compilers
are not required to set such padding to zero too.


Ugh, right.  New patch coming...

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

Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly

2019-03-08 Thread Christian Gmeiner
Hi Eric

> > Use u_transfer_helper_resource_create(..) instead which uses the
> > resource_create(..) function specified in u_transfer_vtbl.
>
> I would need to run this through the CTS, as the stacking in
> u_transfer_helper is fragile.  What's fixed for you by this patch?

I am playing around with u_transfer_helper stuff for etnaviv and just run over
it. I need that change for my 'lets try to use u_transfer_helper for
tile resolve blits'
but piglit is not happy about it. So if i ever get it working I will
resend this patch
within a patch series. But good to know that u_transfer_helper is fragile :)

-- 
greets
--
Christian Gmeiner, MSc

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

[Mesa-dev] [PATCH] Revert "radv: execute external subpass barriers after ending subpasses"

2019-03-08 Thread Samuel Pitoiset
This changes is actually wrong because we have to sync
before doing image layout transitions.

This fixes rendering issues in Batman, Path of Exile and
probably more titles.

This reverts commit 76c17cfd8da017ebd19be33ba6cef888957a6758.

Cc: 19.0 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 5b66930d137..d8aceb8b082 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4395,10 +4395,10 @@ void radv_CmdEndRenderPass(
 {
RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
 
-   radv_cmd_buffer_end_subpass(cmd_buffer);
-
radv_subpass_barrier(cmd_buffer, _buffer->state.pass->end_barrier);
 
+   radv_cmd_buffer_end_subpass(cmd_buffer);
+
vk_free(_buffer->pool->alloc, cmd_buffer->state.attachments);
 
cmd_buffer->state.pass = NULL;
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] nir/spirv: short-circuit when conditional branch contains end block

2019-03-08 Thread Juan A. Suarez Romero
On Thu, 2019-03-07 at 07:15 -0600, Jason Ekstrand wrote:
> Woah, is this legal SPIR-V? I think a second OpSelectionMerge is required.

I'd say it is legal. The spec does not mandate that each branch has its own
merge instruction; only that the control flow must be structured for shaders.

In section 2.11 ("Structured Control Flow"), about structured control-flow
constructs:


- A structured control-flow construct is then defined as one of:
  - a selection construct: the set of blocks dominated by a selection header,
minus the set of blocks dominated by the header’s merge block
  - [...]

- The above structured control-flow constructs must satisfy the following rules:
  - [...]
  - the only blocks in a construct that can branch outside the construct are
- a block branching to the construct’s merge block
- a block branching from one case construct to another, for the same
OpSwitch
- a back-edge block
- a continue block for the innermost loop it is nested inside of
- a break block for the innermost loop it is nested inside of
- a return block


Our selection construct, which contains the two nested conditional branches,
satisfies the rules, as both conditionals branches to the construct's merge
block.


J.A.






> 


> --Jason
> 
> 
> On March 6, 2019 05:25:26 "Juan A. Suarez Romero"  wrote:
> 
> > This fixes the case when the SPIR-V code has two nested conditional
> > branches, but only one selection merge:
> > 
> > 
> > [...]
> > %1 = OpLabel
> > OpSelectionMerge %2 None
> > OpBranchConditional %3 %4 %2
> > %4 = OpLabel
> > OpBranchConditional %3 %5 %2
> > %5 = OpLabel
> > OpBranch %2
> > %2 = OpLabel
> > [...]
> > 
> > 
> > In the second OpBranchConditional, as the else-part is the end
> > block (started in the first OpBranchConditional) we can just follow the
> > then-part.
> > 
> > 
> > This fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle
> > 
> > 
> > CC: Jason Ekstrand 
> > ---
> > src/compiler/spirv/vtn_cfg.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > 
> > diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
> > index 7868eeb60bc..f749118efbe 100644
> > --- a/src/compiler/spirv/vtn_cfg.c
> > +++ b/src/compiler/spirv/vtn_cfg.c
> > @@ -605,7 +605,16 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct 
> > list_head *cf_list,
> > }
> >  } else if (if_stmt->then_type == vtn_branch_type_none &&
> > if_stmt->else_type == vtn_branch_type_none) {
> > -/* Neither side of the if is something we can short-circuit. */
> > +/* Neither side of the if is something we can short-circuit,
> > + * unless one of the blocks is the end block. */
> > +if (then_block == end) {
> > +   block = else_block;
> > +   continue;
> > +} else if (else_block == end) {
> > +   block = then_block;
> > +   continue;
> > +}
> > +
> > vtn_assert((*block->merge & SpvOpCodeMask) == 
> > SpvOpSelectionMerge);
> > struct vtn_block *merge_block =
> >vtn_value(b, block->merge[1], vtn_value_type_block)->block;
> > --
> > 2.20.1
> 
> 
> 

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

Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly

2019-03-08 Thread Rob Clark
On Fri, Mar 1, 2019 at 10:54 AM Christian Gmeiner
 wrote:
>
> Use u_transfer_helper_resource_create(..) instead which uses the
> resource_create(..) function specified in u_transfer_vtbl.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/auxiliary/util/u_transfer_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_transfer_helper.c 
> b/src/gallium/auxiliary/util/u_transfer_helper.c
> index 14c4d56392d..a5c3c026e71 100644
> --- a/src/gallium/auxiliary/util/u_transfer_helper.c
> +++ b/src/gallium/auxiliary/util/u_transfer_helper.c
> @@ -182,7 +182,7 @@ transfer_map_msaa(struct pipe_context *pctx,
>   .depth0 = 1,
>   .array_size = 1,
> };
> -   trans->ss = pscreen->resource_create(pscreen, );
> +   trans->ss = u_transfer_helper_resource_create(pscreen, );


So I *think* the thinking here was to use pscreen->resource_create()
in case there are multiple things the transfer-helper has to deal
with, like MSAA+RGTC..

(I can't guarantee that actually works.. but that was the reasoning..)

BR,
-R


> if (!trans->ss) {
>free(trans);
>return NULL;
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Help with Meson and shared LLVM libraries

2019-03-08 Thread Brian Paul


I've spent some time on this but I'm stumped.

I've been building with -Dshared-llvm=false for a while because I can't 
get -Dshared-llvm=true to work.


I'm configuring meson with:

   meson -Dplatforms=x11 \
 -Dglx=gallium-xlib \
 -Dgallium-drivers=swrast \
 -Ddri-drivers=[] \
 -Dvulkan-drivers=[] \
 -Dbuildtype=debug \
 -Dshared-llvm=true \
 --prefix="${PWD}/${BUILD_DIR}/install" \
 "${BUILD_DIR}"

But I get tons of unresolved LLVM symbols:

ninja: Entering directory `build-meson-llvmpipe'
[1/13] Generating git_sha1.h with a custom command.
[2/2] Linking target src/gallium/targets/libgl-xlib/libGL.so.1.5.0.
FAILED: src/gallium/targets/libgl-xlib/libGL.so.1.5.0
c++  -o src/gallium/targets/libgl-xlib/libGL.so.1.5.0 
'src/gallium/targets/libgl-xlib/GL@sha/xlib.c.o' -Wl,--no-undefined 
-Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,libGL.so.1 
src/gallium/state_trackers/glx/xlib/libxlib.a 
src/gallium/winsys/sw/xlib/libws_xlib.a src/mapi/glapi/libglapi_static.a 
src/gallium/auxiliary/libgallium.a src/compiler/glsl/libglsl.a 
src/compiler/glsl/glcpp/libglcpp.a src/util/libmesa_util.a 
src/compiler/nir/libnir.a src/compiler/libcompiler.a 
src/mesa/libmesa_gallium.a src/mesa/libmesa_sse41.a 
src/mapi/shared-glapi/libglapi.so.0.0.0 
src/gallium/drivers/llvmpipe/libllvmpipe.a 
src/gallium/drivers/softpipe/libsoftpipe.a -pthread -Wl,-Bsymbolic 
-Wl,--gc-sections -Wl,--version-script 
/home/projects/Mesa-gitlab/mesa/src/gallium/targets/libgl-xlib/libgl-xlib.sym 
-lX11 -lXext -lxcb -lX11 -lXext -lxcb -ldrm -ldl -lm -Wl,--end-group -lz 
-lm -lz -lm '-Wl,-rpath,$ORIGIN/../../../mapi/shared-glapi' 
-Wl,-rpath-link,/home/projects/Mesa-gitlab/mesa/build-meson-llvmpipe/src/mapi/shared-glapi 

src/gallium/drivers/llvmpipe/libllvmpipe.a(lp_context.c.o): In function 
`llvmpipe_destroy':
/home/projects/Mesa-gitlab/mesa/build-meson-llvmpipe/../src/gallium/drivers/llvmpipe/lp_context.c:105: 
undefined reference to `LLVMContextDispose'
src/gallium/drivers/llvmpipe/libllvmpipe.a(lp_context.c.o): In function 
`llvmpipe_create_context':
/home/projects/Mesa-gitlab/mesa/build-meson-llvmpipe/../src/gallium/drivers/llvmpipe/lp_context.c:181: 
undefined reference to `LLVMContextCreate'
src/gallium/drivers/llvmpipe/libllvmpipe.a(lp_jit.c.o): In function 
`lp_jit_create_types':
/home/projects/Mesa-gitlab/mesa/build-meson-llvmpipe/../src/gallium/drivers/llvmpipe/lp_jit.c:56: 
undefined reference to `LLVMFloatTypeInContext'
/home/projects/Mesa-gitlab/mesa/build-meson-llvmpipe/../src/gallium/drivers/llvmpipe/lp_jit.c:58: 
undefined reference to `LLVMStructTypeInContext'



$ llvm-config --version
7.0.0

$ llvm-config --libdir
/home/local/lib

$ ls -aF /home/local/lib/libLLVM*
/home/local/lib/libLLVM-7.0.0.so@
/home/local/lib/libLLVM-7.so
/home/local/lib/libLLVMAArch64AsmParser.a
/home/local/lib/libLLVMAArch64AsmPrinter.a
/home/local/lib/libLLVMAArch64CodeGen.a
/home/local/lib/libLLVMAArch64Desc.a
/home/local/lib/libLLVMAArch64Disassembler.a
[...]


In the c++ link command above which builds 
src/gallium/targets/libgl-xlib/libGL.so.1.5.0 I don't see 
-L/home/local/lib -lLLVM options.


Any ideas?

-Brian

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

[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #8 from Alex Smith  ---
What LLVM version are you using and what CPU do you have? I'm unable to
reproduce this on current 19.0 branch
(8ab2fc8c963955818d6cbc1db47b76d9bffb9eb6) using LLVM 7, loading times seem as
expected to me with the disk cache cleared (on an i7 6700, a couple of minutes
to load Soviet Installation, which has the most pipelines of all levels in the
game).

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

Re: [Mesa-dev] [PATCH] docs: try to improve the Meson documentation

2019-03-08 Thread Eric Anholt
Eric Engestrom  writes:

> On 2019-03-08 at 03:42, Brian Paul  wrote:
>> Add new Introduction and Advanced Usage sections.
>> Spell out a few more details, like "ninja install".
>> Improve the layout around example commands.
>> Fix grammatical errors and tighten up the text.
>> Explain the --prefix option.
>
> Thanks! I left a couple comments below, but this is:
> Reviewed-by: Eric Engestrom 
>
>> ---
>>  docs/contents.html |   2 +-
>>  docs/meson.html| 138 
>> +++--
>>  2 files changed, 104 insertions(+), 36 deletions(-)
>> 
>> diff --git a/docs/contents.html b/docs/contents.html
>> index 6364776..619ac3d 100644
>> --- a/docs/contents.html
>> +++ b/docs/contents.html
>> @@ -42,8 +42,8 @@
>>  Downloading / Unpacking
>>  Compiling / Installing
>>
>> -Autoconf
>>  Meson
>> +Autoconf 
>> (deprecated)
>>
>>  
>>  Precompiled Libraries
>> diff --git a/docs/meson.html b/docs/meson.html
>> index f21479c..f9ae669 100644
>> --- a/docs/meson.html
>> +++ b/docs/meson.html
>> @@ -17,65 +17,98 @@
>>  Compilation and Installation using Meson
>>  
>>  
>> +  Introduction
>>Basic Usage
>> +  Advanced Usage
>>Cross-compilation and 32-bit 
>> builds
>>  
>>  
>> -1. Basic Usage
>> +1. Introduction
>>  
>> -The Meson build system is generally considered stable and ready
>> -for production
>> +For general information about Meson see the
>> +http://mesonbuild.com/;>Meson website.
>>  
>> -The meson build is tested on Linux, macOS, Cygwin and Haiku, 
>> FreeBSD,
>> +Mesa's Meson build system is generally considered stable 
>> and ready
>> +for production.
>> +
>> +The Meson build of Mesa is tested on Linux, macOS, Cygwin and 
>> Haiku, FreeBSD,
>>  DragonflyBSD, NetBSD, and should work on OpenBSD.
>>  
>> +If Meson is not already installed on your system, you can typically
>> +install it with your package installer.  For example:
>> +
>> +sudo apt-get install meson   # Ubuntu
>> +
>> +or
>> +
>> +sudo dnf install meson   # Fedora
>> +
>> +
>>  Mesa requires Meson >= 0.45.0 to build.
>>  
>>  Some older versions of meson do not check that they are too old and will 
>> error
>>  out in odd ways.
>>  
>>  
>> +You'll also need https://ninja-build.org/;>Ninja.
>> +If it's not already installed, use apt-get or dnf to install
>> +the ninja-build package.
>> +
>> +
>> +2. Basic Usage
>> +
>>  
>>  The meson program is used to configure the source directory and 
>> generates
>>  either a ninja build file or Visual Studio® build files. The latter 
>> must
>> -be enabled via the --backend switch, as ninja is the 
>> default backend on all
>> -operating systems. Meson only supports out-of-tree builds, and must be 
>> passed a
>> +be enabled via the --backend switch, as ninja is the 
>> default
>> +backend on all
>> +operating systems.
>> +
>> +
>> +
>> +Meson only supports out-of-tree builds, and must be passed a
>>  directory to put built and generated sources into. We'll call that 
>> directory
>> -"build" for examples.
>> +"build" here.
>>  
>>  
>> +Basic configuration is done with:
>> +
>>  
>> -meson build/
>> +meson build/
>>  
>>  
>>  
>> -To see a description of your options you can run meson 
>> configure
>> -along with a build directory to view the selected options for. This will 
>> show
>> -your meson global arguments and project arguments, along with their defaults
>> -and your local settings.
>> +This will create the build directory.
>> +If any dependencies are missing, you can install them, or try to remove
>> +the dependency with a Meson configuration option (see below).
>> +
>> +
>> +
>> +To review the options which Meson chose, run:
>>  
>> +
>> +meson configure build/
>> +
>>  
>>  
>> -Meson does not currently support listing options before configure a build
>> -directory, but this feature is being discussed upstream.
>> +Meson does not currently support listing configuration options before
>> +running "meson build/" but this feature is being discussed upstream.
>>  For now, we have a bin/meson-options.py script that prints
>>  the options for you.
>>  If that script doesn't work for some reason, you can always look in the
>>  meson_options.txt file at the root of the project.
>>  
>>  
>> -
>> -meson configure build/
>> -
>> -
>>  
>> -With additional arguments meson configure is used to change
>> -options on already configured build directory. All options passed to this
>> -command are in the form -D "command"="value".
>> +With additional arguments meson configure can be used to change
>> +options for a previously configured build directory.
>> +All options passed to this command are in the form
>> +-D "command"="value".
>
> I know you didn't write this bit, but can I suggest s/command/option/ ?
>
>> +For example:
>>  
>>  
>>  
>> -meson configure build/ -Dprefix=/tmp/install -Dglx=true
>> +meson configure build/ -Dprefix=/tmp/install -Dglx=true
>>  
>>  
>>  
>> @@ -88,33 +121,68 @@ and brackets to represent an empty list 

Re: [Mesa-dev] [PATCH 5/5] st/mesa: minor refactoring of texture/sampler delete code

2019-03-08 Thread Neha Bhende
Reviewed-by: Neha Bhende 

Regards,
Neha


From: Brian Paul 
Sent: Friday, March 8, 2019 7:52 AM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [PATCH 5/5] st/mesa: minor refactoring of texture/sampler delete code

Rename st_texture_free_sampler_views() to
st_delete_texture_sampler_views() to align with
st_DeleteTextureObject(), its only caller.

Move the call to st_texture_release_all_sampler_views() from
st_DeleteTextureObject() to st_delete_texture_sampler_views()
so all the sampler view clean-up code is in one place.
---
 src/mesa/state_tracker/st_cb_texture.c   |  3 +--
 src/mesa/state_tracker/st_sampler_view.c | 11 ---
 src/mesa/state_tracker/st_sampler_view.h |  3 ++-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index 47d0612..2caf61e 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -187,8 +187,7 @@ st_DeleteTextureObject(struct gl_context *ctx,
struct st_texture_object *stObj = st_texture_object(texObj);

pipe_resource_reference(>pt, NULL);
-   st_texture_release_all_sampler_views(st, stObj);
-   st_texture_free_sampler_views(stObj);
+   st_delete_texture_sampler_views(st, stObj);
simple_mtx_destroy(>validate_mutex);
_mesa_delete_texture_object(ctx, texObj);
 }
diff --git a/src/mesa/state_tracker/st_sampler_view.c 
b/src/mesa/state_tracker/st_sampler_view.c
index 17c209c..e4eaf39 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -231,15 +231,20 @@ st_texture_release_all_sampler_views(struct st_context 
*st,


 /*
- * Free the texture's st_sampler_views objects.  This should be called
- * after st_texture_release_all_sampler_views().
+ * Delete the texture's sampler views and st_sampler_views containers.
+ * This is to be called just before a texture is deleted.
  */
 void
-st_texture_free_sampler_views(struct st_texture_object *stObj)
+st_delete_texture_sampler_views(struct st_context *st,
+struct st_texture_object *stObj)
 {
+   st_texture_release_all_sampler_views(st, stObj);
+
+   /* Free the container of the current per-context sampler views */
free(stObj->sampler_views);
stObj->sampler_views = NULL;

+   /* Free old sampler view containers */
while (stObj->sampler_views_old) {
   struct st_sampler_views *views = stObj->sampler_views_old;
   stObj->sampler_views_old = views->next;
diff --git a/src/mesa/state_tracker/st_sampler_view.h 
b/src/mesa/state_tracker/st_sampler_view.h
index d7a4c0d..1bd664d 100644
--- a/src/mesa/state_tracker/st_sampler_view.h
+++ b/src/mesa/state_tracker/st_sampler_view.h
@@ -66,7 +66,8 @@ st_texture_release_all_sampler_views(struct st_context *st,
  struct st_texture_object *stObj);

 void
-st_texture_free_sampler_views(struct st_texture_object *stObj);
+st_delete_texture_sampler_views(struct st_context *st,
+struct st_texture_object *stObj);

 const struct st_sampler_view *
 st_texture_get_current_sampler_view(const struct st_context *st,
--
1.8.5.6

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

[Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not designated initializers

2019-03-08 Thread Brian Paul
Since the compiler may not zero-out padding in the object.
Add a couple comments about this to prevent misunderstandings in
the future.

Fixes: 67d96816ff5 ("st/mesa: move, clean-up shader variant key decls/inits")
---
 src/mesa/state_tracker/st_atom_shader.c |  9 +++--
 src/mesa/state_tracker/st_program.c | 13 ++---
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_shader.c 
b/src/mesa/state_tracker/st_atom_shader.c
index ac7a1a5..a4475e2 100644
--- a/src/mesa/state_tracker/st_atom_shader.c
+++ b/src/mesa/state_tracker/st_atom_shader.c
@@ -112,7 +112,10 @@ st_update_fp( struct st_context *st )
!stfp->variants->key.bitmap) {
   shader = stfp->variants->driver_shader;
} else {
-  struct st_fp_variant_key key = {0};
+  struct st_fp_variant_key key;
+
+  /* use memset, not an initializer to be sure all memory is zeroed */
+  memset(, 0, sizeof(key));
 
   key.st = st->has_shareable_shaders ? NULL : st;
 
@@ -168,7 +171,9 @@ st_update_vp( struct st_context *st )
stvp->variants->key.passthrough_edgeflags == st->vertdata_edgeflags) {
   st->vp_variant = stvp->variants;
} else {
-  struct st_vp_variant_key key = {0};
+  struct st_vp_variant_key key;
+
+  memset(, 0, sizeof(key));
 
   key.st = st->has_shareable_shaders ? NULL : st;
 
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 6d669a9..fe03070 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1807,7 +1807,10 @@ st_get_cp_variant(struct st_context *st,
 {
struct pipe_context *pipe = st->pipe;
struct st_basic_variant *v;
-   struct st_basic_variant_key key = {0};
+   struct st_basic_variant_key key;
+
+   /* use memset, not an initializer to be sure all memory is zeroed */
+   memset(, 0, sizeof(key));
 
key.st = st->has_shareable_shaders ? NULL : st;
 
@@ -2030,7 +2033,9 @@ st_precompile_shader_variant(struct st_context *st,
switch (prog->Target) {
case GL_VERTEX_PROGRAM_ARB: {
   struct st_vertex_program *p = (struct st_vertex_program *)prog;
-  struct st_vp_variant_key key = {0};
+  struct st_vp_variant_key key;
+
+  memset(, 0, sizeof(key));
 
   key.st = st->has_shareable_shaders ? NULL : st;
   st_get_vp_variant(st, p, );
@@ -2057,7 +2062,9 @@ st_precompile_shader_variant(struct st_context *st,
 
case GL_FRAGMENT_PROGRAM_ARB: {
   struct st_fragment_program *p = (struct st_fragment_program *)prog;
-  struct st_fp_variant_key key = {0};
+  struct st_fp_variant_key key;
+
+  memset(, 0, sizeof(key));
 
   key.st = st->has_shareable_shaders ? NULL : st;
   st_get_fp_variant(st, p, );
-- 
1.8.5.6

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

Re: [Mesa-dev] [PATCH v2 0/8] panfrost: Add DRM backend

2019-03-08 Thread Alyssa Rosenzweig
Patches 1-7 are Reviewed-by: Alyssa Rosenzweig 

Patch 8 I don't have time to read through right now but will get to this
evening.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/5] st/mesa: move utility functions, macros into new st_util.h file

2019-03-08 Thread Brian Paul
To de-clutter st_context.h.

Clean up remaining function prototypes in st_context.h.

The st_vp_uses_current_values() helper is only used in st_context.c
so move it there.

The st_get_active_states() function is only used in st_context.c so
remove its prototype in st_context.h
---
 src/mesa/Makefile.sources   |   1 +
 src/mesa/meson.build|   1 +
 src/mesa/state_tracker/st_atom.c|   2 +
 src/mesa/state_tracker/st_atom_framebuffer.c|   1 +
 src/mesa/state_tracker/st_atom_msaa.c   |   1 +
 src/mesa/state_tracker/st_atom_rasterizer.c |   1 +
 src/mesa/state_tracker/st_atom_scissor.c|   1 +
 src/mesa/state_tracker/st_atom_viewport.c   |   1 +
 src/mesa/state_tracker/st_cb_bitmap.c   |   1 +
 src/mesa/state_tracker/st_cb_blit.c |   1 +
 src/mesa/state_tracker/st_cb_bufferobjects.c|   1 +
 src/mesa/state_tracker/st_cb_clear.c|   1 +
 src/mesa/state_tracker/st_cb_compute.c  |   1 +
 src/mesa/state_tracker/st_cb_copyimage.c|   1 +
 src/mesa/state_tracker/st_cb_drawpixels.c   |   1 +
 src/mesa/state_tracker/st_cb_drawtex.c  |   1 +
 src/mesa/state_tracker/st_cb_fbo.c  |   1 +
 src/mesa/state_tracker/st_cb_feedback.c |   1 +
 src/mesa/state_tracker/st_cb_memoryobjects.c|   1 +
 src/mesa/state_tracker/st_cb_perfmon.c  |   1 +
 src/mesa/state_tracker/st_cb_program.c  |   1 +
 src/mesa/state_tracker/st_cb_queryobj.c |   1 +
 src/mesa/state_tracker/st_cb_rasterpos.c|   1 +
 src/mesa/state_tracker/st_cb_readpixels.c   |   2 +
 src/mesa/state_tracker/st_cb_semaphoreobjects.c |   1 +
 src/mesa/state_tracker/st_cb_texture.c  |   1 +
 src/mesa/state_tracker/st_context.c |  11 ++-
 src/mesa/state_tracker/st_context.h | 118 ++--
 src/mesa/state_tracker/st_draw.c|   1 +
 src/mesa/state_tracker/st_draw_feedback.c   |   1 +
 src/mesa/state_tracker/st_gen_mipmap.c  |   1 +
 src/mesa/state_tracker/st_shader_cache.c|   1 +
 src/mesa/state_tracker/st_util.h| 114 +++
 33 files changed, 184 insertions(+), 91 deletions(-)
 create mode 100644 src/mesa/state_tracker/st_util.h

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index d554408..89bcfe4 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -556,6 +556,7 @@ STATETRACKER_FILES = \
state_tracker/st_texture.h \
state_tracker/st_tgsi_lower_yuv.c \
state_tracker/st_tgsi_lower_yuv.h \
+   state_tracker/st_util.h \
state_tracker/st_vdpau.c \
state_tracker/st_vdpau.h
 
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index 05a8bb5..2d9b673 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -600,6 +600,7 @@ files_libmesa_gallium = files(
   'state_tracker/st_texture.h',
   'state_tracker/st_tgsi_lower_yuv.c',
   'state_tracker/st_tgsi_lower_yuv.h',
+  'state_tracker/st_util.h',
   'state_tracker/st_vdpau.c',
   'state_tracker/st_vdpau.h',
 )
diff --git a/src/mesa/state_tracker/st_atom.c b/src/mesa/state_tracker/st_atom.c
index df1a94e..49f79ad 100644
--- a/src/mesa/state_tracker/st_atom.c
+++ b/src/mesa/state_tracker/st_atom.c
@@ -36,6 +36,8 @@
 #include "st_atom.h"
 #include "st_program.h"
 #include "st_manager.h"
+#include "st_util.h"
+
 
 typedef void (*update_func_t)(struct st_context *st);
 
diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c 
b/src/mesa/state_tracker/st_atom_framebuffer.c
index a0dd0d1..f18c40d 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -38,6 +38,7 @@
 #include "st_cb_bitmap.h"
 #include "st_cb_fbo.h"
 #include "st_texture.h"
+#include "st_util.h"
 #include "pipe/p_context.h"
 #include "cso_cache/cso_context.h"
 #include "util/u_math.h"
diff --git a/src/mesa/state_tracker/st_atom_msaa.c 
b/src/mesa/state_tracker/st_atom_msaa.c
index c6affec..594e639 100644
--- a/src/mesa/state_tracker/st_atom_msaa.c
+++ b/src/mesa/state_tracker/st_atom_msaa.c
@@ -31,6 +31,7 @@
 #include "pipe/p_context.h"
 #include "st_atom.h"
 #include "st_program.h"
+#include "st_util.h"
 
 #include "cso_cache/cso_context.h"
 #include "util/u_framebuffer.h"
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c 
b/src/mesa/state_tracker/st_atom_rasterizer.c
index 2bffa68..fee992e 100644
--- a/src/mesa/state_tracker/st_atom_rasterizer.c
+++ b/src/mesa/state_tracker/st_atom_rasterizer.c
@@ -37,6 +37,7 @@
 #include "st_atom.h"
 #include "st_debug.h"
 #include "st_program.h"
+#include "st_util.h"
 #include "pipe/p_context.h"
 #include "pipe/p_defines.h"
 #include "cso_cache/cso_context.h"
diff --git a/src/mesa/state_tracker/st_atom_scissor.c 
b/src/mesa/state_tracker/st_atom_scissor.c
index a87d029..04135a3 100644
--- a/src/mesa/state_tracker/st_atom_scissor.c
+++ 

[Mesa-dev] [PATCH 3/5] st/mesa: add/improve sampler view comments

2019-03-08 Thread Brian Paul
---
 src/mesa/state_tracker/st_sampler_view.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_sampler_view.c 
b/src/mesa/state_tracker/st_sampler_view.c
index 1669de5..b22aa20 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -181,7 +181,8 @@ st_texture_get_current_sampler_view(const struct st_context 
*st,
 
 /**
  * For the given texture object, release any sampler views which belong
- * to the calling context.
+ * to the calling context.  This is used to free any sampler views
+ * which belong to the context before the context is destroyed.
  */
 void
 st_texture_release_sampler_view(struct st_context *st,
@@ -205,7 +206,8 @@ st_texture_release_sampler_view(struct st_context *st,
 
 /**
  * Release all sampler views attached to the given texture object, regardless
- * of the context.
+ * of the context.  This is called fairly frequently.  For example, whenever
+ * the texture's base level, max level or swizzle change.
  */
 void
 st_texture_release_all_sampler_views(struct st_context *st,
@@ -228,6 +230,10 @@ st_texture_release_all_sampler_views(struct st_context *st,
 }
 
 
+/*
+ * Free the texture's st_sampler_views objects.  This should be called
+ * after st_texture_release_all_sampler_views().
+ */
 void
 st_texture_free_sampler_views(struct st_texture_object *stObj)
 {
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 2/5] st/mesa: move around some code in st_context.c

2019-03-08 Thread Brian Paul
st_init_driver_functions() is only called in st_context.c so there's
no need for the prototype in st_context.h

To avoid a forward declaration of st_init_driver_functions() in
st_context.c, we need to move around several other functions.

No functional change.
---
 src/mesa/state_tracker/st_context.c | 229 ++--
 src/mesa/state_tracker/st_context.h |   9 --
 2 files changed, 116 insertions(+), 122 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 68b6ddb..f30afee 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -572,118 +572,6 @@ st_create_context_priv(struct gl_context *ctx, struct 
pipe_context *pipe,
 }
 
 
-struct st_context *
-st_create_context(gl_api api, struct pipe_context *pipe,
-  const struct gl_config *visual,
-  struct st_context *share,
-  const struct st_config_options *options,
-  bool no_error)
-{
-   struct gl_context *ctx;
-   struct gl_context *shareCtx = share ? share->ctx : NULL;
-   struct dd_function_table funcs;
-   struct st_context *st;
-
-   util_cpu_detect();
-
-   memset(, 0, sizeof(funcs));
-   st_init_driver_functions(pipe->screen, );
-
-   ctx = calloc(1, sizeof(struct gl_context));
-   if (!ctx)
-  return NULL;
-
-   if (!_mesa_initialize_context(ctx, api, visual, shareCtx, )) {
-  free(ctx);
-  return NULL;
-   }
-
-   st_debug_init();
-
-   if (pipe->screen->get_disk_shader_cache &&
-   !(ST_DEBUG & DEBUG_TGSI))
-  ctx->Cache = pipe->screen->get_disk_shader_cache(pipe->screen);
-
-   /* XXX: need a capability bit in gallium to query if the pipe
-* driver prefers DP4 or MUL/MAD for vertex transformation.
-*/
-   if (debug_get_option_mesa_mvp_dp4())
-  ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS = 
GL_TRUE;
-
-   st = st_create_context_priv(ctx, pipe, options, no_error);
-   if (!st) {
-  _mesa_destroy_context(ctx);
-   }
-
-   return st;
-}
-
-
-/**
- * Callback to release the sampler view attached to a texture object.
- * Called by _mesa_HashWalk().
- */
-static void
-destroy_tex_sampler_cb(GLuint id, void *data, void *userData)
-{
-   struct gl_texture_object *texObj = (struct gl_texture_object *) data;
-   struct st_context *st = (struct st_context *) userData;
-
-   st_texture_release_sampler_view(st, st_texture_object(texObj));
-}
-
-
-void
-st_destroy_context(struct st_context *st)
-{
-   struct gl_context *ctx = st->ctx;
-   struct st_framebuffer *stfb, *next;
-
-   GET_CURRENT_CONTEXT(curctx);
-
-   if (curctx == NULL) {
-  /* No current context, but we need one to release
-   * renderbuffer surface when we release framebuffer.
-   * So temporarily bind the context.
-   */
-  _mesa_make_current(ctx, NULL, NULL);
-   }
-
-   /* This must be called first so that glthread has a chance to finish */
-   _mesa_glthread_destroy(ctx);
-
-   _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
-
-   st_reference_fragprog(st, >fp, NULL);
-   st_reference_prog(st, >gp, NULL);
-   st_reference_vertprog(st, >vp, NULL);
-   st_reference_prog(st, >tcp, NULL);
-   st_reference_prog(st, >tep, NULL);
-   st_reference_compprog(st, >cp, NULL);
-
-   /* release framebuffer in the winsys buffers list */
-   LIST_FOR_EACH_ENTRY_SAFE_REV(stfb, next, >winsys_buffers, head) {
-  st_framebuffer_reference(, NULL);
-   }
-
-   pipe_sampler_view_reference(>pixel_xfer.pixelmap_sampler_view, NULL);
-   pipe_resource_reference(>pixel_xfer.pixelmap_texture, NULL);
-
-   _vbo_DestroyContext(ctx);
-
-   st_destroy_program_variants(st);
-
-   _mesa_free_context_data(ctx);
-
-   /* This will free the st_context too, so 'st' must not be accessed
-* afterwards. */
-   st_destroy_context_priv(st, true);
-   st = NULL;
-
-   free(ctx);
-}
-
-
 static void
 st_emit_string_marker(struct gl_context *ctx, const GLchar *string, GLsizei 
len)
 {
@@ -727,7 +615,7 @@ st_get_driver_uuid(struct gl_context *ctx, char *uuid)
 }
 
 
-void
+static void
 st_init_driver_functions(struct pipe_screen *screen,
  struct dd_function_table *functions)
 {
@@ -798,3 +686,118 @@ st_init_driver_functions(struct pipe_screen *screen,
  st_deserialise_tgsi_program;
}
 }
+
+
+struct st_context *
+st_create_context(gl_api api, struct pipe_context *pipe,
+  const struct gl_config *visual,
+  struct st_context *share,
+  const struct st_config_options *options,
+  bool no_error)
+{
+   struct gl_context *ctx;
+   struct gl_context *shareCtx = share ? share->ctx : NULL;
+   struct dd_function_table funcs;
+   struct st_context *st;
+
+   util_cpu_detect();
+
+   memset(, 0, sizeof(funcs));
+   st_init_driver_functions(pipe->screen, );
+
+   ctx = calloc(1, sizeof(struct gl_context));
+   if (!ctx)
+  return NULL;
+
+   if 

[Mesa-dev] [PATCH 4/5] st/mesa: rename st_texture_release_sampler_view()

2019-03-08 Thread Brian Paul
To st_texture_release_context_sampler_view() to be more clear
that it's context-specific.
---
 src/mesa/state_tracker/st_context.c  | 2 +-
 src/mesa/state_tracker/st_sampler_view.c | 4 ++--
 src/mesa/state_tracker/st_sampler_view.h | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index f30afee..2898279 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -748,7 +748,7 @@ destroy_tex_sampler_cb(GLuint id, void *data, void 
*userData)
struct gl_texture_object *texObj = (struct gl_texture_object *) data;
struct st_context *st = (struct st_context *) userData;
 
-   st_texture_release_sampler_view(st, st_texture_object(texObj));
+   st_texture_release_context_sampler_view(st, st_texture_object(texObj));
 }
 
 
diff --git a/src/mesa/state_tracker/st_sampler_view.c 
b/src/mesa/state_tracker/st_sampler_view.c
index b22aa20..17c209c 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -185,8 +185,8 @@ st_texture_get_current_sampler_view(const struct st_context 
*st,
  * which belong to the context before the context is destroyed.
  */
 void
-st_texture_release_sampler_view(struct st_context *st,
-struct st_texture_object *stObj)
+st_texture_release_context_sampler_view(struct st_context *st,
+struct st_texture_object *stObj)
 {
GLuint i;
 
diff --git a/src/mesa/state_tracker/st_sampler_view.h 
b/src/mesa/state_tracker/st_sampler_view.h
index 47c100d..d7a4c0d 100644
--- a/src/mesa/state_tracker/st_sampler_view.h
+++ b/src/mesa/state_tracker/st_sampler_view.h
@@ -58,8 +58,8 @@ st_create_texture_sampler_view(struct pipe_context *pipe,
 
 
 extern void
-st_texture_release_sampler_view(struct st_context *st,
-struct st_texture_object *stObj);
+st_texture_release_context_sampler_view(struct st_context *st,
+struct st_texture_object *stObj);
 
 extern void
 st_texture_release_all_sampler_views(struct st_context *st,
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 5/5] st/mesa: minor refactoring of texture/sampler delete code

2019-03-08 Thread Brian Paul
Rename st_texture_free_sampler_views() to
st_delete_texture_sampler_views() to align with
st_DeleteTextureObject(), its only caller.

Move the call to st_texture_release_all_sampler_views() from
st_DeleteTextureObject() to st_delete_texture_sampler_views()
so all the sampler view clean-up code is in one place.
---
 src/mesa/state_tracker/st_cb_texture.c   |  3 +--
 src/mesa/state_tracker/st_sampler_view.c | 11 ---
 src/mesa/state_tracker/st_sampler_view.h |  3 ++-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index 47d0612..2caf61e 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -187,8 +187,7 @@ st_DeleteTextureObject(struct gl_context *ctx,
struct st_texture_object *stObj = st_texture_object(texObj);
 
pipe_resource_reference(>pt, NULL);
-   st_texture_release_all_sampler_views(st, stObj);
-   st_texture_free_sampler_views(stObj);
+   st_delete_texture_sampler_views(st, stObj);
simple_mtx_destroy(>validate_mutex);
_mesa_delete_texture_object(ctx, texObj);
 }
diff --git a/src/mesa/state_tracker/st_sampler_view.c 
b/src/mesa/state_tracker/st_sampler_view.c
index 17c209c..e4eaf39 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -231,15 +231,20 @@ st_texture_release_all_sampler_views(struct st_context 
*st,
 
 
 /*
- * Free the texture's st_sampler_views objects.  This should be called
- * after st_texture_release_all_sampler_views().
+ * Delete the texture's sampler views and st_sampler_views containers.
+ * This is to be called just before a texture is deleted.
  */
 void
-st_texture_free_sampler_views(struct st_texture_object *stObj)
+st_delete_texture_sampler_views(struct st_context *st,
+struct st_texture_object *stObj)
 {
+   st_texture_release_all_sampler_views(st, stObj);
+
+   /* Free the container of the current per-context sampler views */
free(stObj->sampler_views);
stObj->sampler_views = NULL;
 
+   /* Free old sampler view containers */
while (stObj->sampler_views_old) {
   struct st_sampler_views *views = stObj->sampler_views_old;
   stObj->sampler_views_old = views->next;
diff --git a/src/mesa/state_tracker/st_sampler_view.h 
b/src/mesa/state_tracker/st_sampler_view.h
index d7a4c0d..1bd664d 100644
--- a/src/mesa/state_tracker/st_sampler_view.h
+++ b/src/mesa/state_tracker/st_sampler_view.h
@@ -66,7 +66,8 @@ st_texture_release_all_sampler_views(struct st_context *st,
  struct st_texture_object *stObj);
 
 void
-st_texture_free_sampler_views(struct st_texture_object *stObj);
+st_delete_texture_sampler_views(struct st_context *st,
+struct st_texture_object *stObj);
 
 const struct st_sampler_view *
 st_texture_get_current_sampler_view(const struct st_context *st,
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 2/2] intel/compiler: silence unitialized variable warning in opt_vector_float()

2019-03-08 Thread Brian Paul
---
 src/intel/compiler/brw_vec4.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index fe36851..2e9de29 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -414,7 +414,7 @@ vec4_visitor::opt_vector_float()
 
   foreach_inst_in_block_safe(vec4_instruction, inst, block) {
  int vf = -1;
- enum brw_reg_type need_type;
+ enum brw_reg_type need_type = BRW_REGISTER_TYPE_LAST;
 
  /* Look for unconditional MOVs from an immediate with a partial
   * writemask.  Skip type-conversion MOVs other than integer 0,
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 1/2] intel/decoders: silence uninitialized variable warnings in gen_print_batch()

2019-03-08 Thread Brian Paul
---
 src/intel/common/gen_batch_decoder.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index ff898d8..5cac983 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -874,9 +874,9 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
   }
 
   if (strcmp(inst_name, "MI_BATCH_BUFFER_START") == 0) {
- uint64_t next_batch_addr;
+ uint64_t next_batch_addr = 0;
  bool ppgtt = false;
- bool second_level;
+ bool second_level = false;
  struct gen_field_iterator iter;
  gen_field_iterator_init(, inst, p, 0, false);
  while (gen_field_iterator_next()) {
-- 
1.8.5.6

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

[Mesa-dev] [AppVeyor] mesa master #10318 failed

2019-03-08 Thread AppVeyor



Build mesa 10318 failed


Commit d4381cf593 by Brian Paul on 3/7/2019 11:14 PM:

svga: remove SVGA_RELOC_READ flag in SVGA3D_BindGBSurface()\n\nThis fixes a rendering issue where UBO updates aren't always picked\nup by drawing calls.  This issue effected the Webots robotics\nsimulator.  VMware bug 2175527.\n\nTesting Done: Webots replay, piglit, misc Linux games\n\nReviewed-by: Thomas Hellstrom 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH v2 2/8] panfrost: Detect GPU version at runtime

2019-03-08 Thread Rob Herring
On Fri, Mar 8, 2019 at 3:27 AM Tomeu Vizoso  wrote:
>
> Also use the raw GPU ID value to decide whether to use SFD or MFD.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>  src/gallium/drivers/panfrost/pan_context.c | 66 ++
>  src/gallium/drivers/panfrost/pan_context.h | 10 
>  src/gallium/drivers/panfrost/pan_screen.h  |  1 +
>  3 files changed, 41 insertions(+), 36 deletions(-)

> @@ -2724,8 +2712,14 @@ struct pipe_context *
>  panfrost_create_context(struct pipe_screen *screen, void *priv, unsigned 
> flags)
>  {
>  struct panfrost_context *ctx = CALLOC_STRUCT(panfrost_context);
> +struct panfrost_screen *pscreen = pan_screen(screen);
>  memset(ctx, 0, sizeof(*ctx));
>  struct pipe_context *gallium = (struct pipe_context *) ctx;
> +unsigned gpu_id;
> +
> +gpu_id = pscreen->driver->query_gpu_version(pscreen);
> +ctx->is_t6xx = gpu_id <= 0x0750; /* For now, this flag means t76x or 
> less */

This doesn't work for t604 which has a special version of 0x6???. That
helpfully also collides with bifrost versions. We could fix this up in
the kernel to expose it as 0x0600. Then an 'is_bifrost' would be an
easy (gpu_id & 0xf000).

Why isn't this 'is_t8xx' instead as you are touching it everywhere or
this needs to be t8xx and bifrost? If not you could just do ((gpu_id &
0xff00) == 0x0800).

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

Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly

2019-03-08 Thread Eric Anholt
Christian Gmeiner  writes:

> Use u_transfer_helper_resource_create(..) instead which uses the
> resource_create(..) function specified in u_transfer_vtbl.

I would need to run this through the CTS, as the stacking in
u_transfer_helper is fragile.  What's fixed for you by this patch?


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

[Mesa-dev] [PATCH] docs: try to improve the Meson documentation (v2)

2019-03-08 Thread Brian Paul
Add new Introduction and Advanced Usage sections.
Spell out a few more details, like "ninja install".
Improve the layout around example commands.
Fix grammatical errors and tighten up the text.
Explain the --prefix option.

v2: Remove language about 'ninja clean' and move link to Meson
information about separate build directories earlier in the page.

Reviewed-by: Eric Engestrom 
---
 docs/contents.html |   2 +-
 docs/meson.html| 144 ++---
 2 files changed, 106 insertions(+), 40 deletions(-)

diff --git a/docs/contents.html b/docs/contents.html
index 6364776..619ac3d 100644
--- a/docs/contents.html
+++ b/docs/contents.html
@@ -42,8 +42,8 @@
 Downloading / Unpacking
 Compiling / Installing
   
-Autoconf
 Meson
+Autoconf (deprecated)
   
 
 Precompiled Libraries
diff --git a/docs/meson.html b/docs/meson.html
index f21479c..7ffef81 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -17,65 +17,105 @@
 Compilation and Installation using Meson
 
 
+  Introduction
   Basic Usage
+  Advanced Usage
   Cross-compilation and 32-bit builds
 
 
-1. Basic Usage
+1. Introduction
 
-The Meson build system is generally considered stable and ready
-for production
+For general information about Meson see the
+http://mesonbuild.com/;>Meson website.
 
-The meson build is tested on Linux, macOS, Cygwin and Haiku, FreeBSD,
+Mesa's Meson build system is generally considered stable and ready
+for production.
+
+The Meson build of Mesa is tested on Linux, macOS, Cygwin and Haiku, 
FreeBSD,
 DragonflyBSD, NetBSD, and should work on OpenBSD.
 
+If Meson is not already installed on your system, you can typically
+install it with your package installer.  For example:
+
+sudo apt-get install meson   # Ubuntu
+
+or
+
+sudo dnf install meson   # Fedora
+
+
 Mesa requires Meson >= 0.45.0 to build.
 
 Some older versions of meson do not check that they are too old and will error
 out in odd ways.
 
 
+You'll also need https://ninja-build.org/;>Ninja.
+If it's not already installed, use apt-get or dnf to install
+the ninja-build package.
+
+
+2. Basic Usage
+
 
 The meson program is used to configure the source directory and generates
 either a ninja build file or Visual Studio® build files. The latter must
-be enabled via the --backend switch, as ninja is the default 
backend on all
-operating systems. Meson only supports out-of-tree builds, and must be passed a
+be enabled via the --backend switch, as ninja is the default
+backend on all
+operating systems.
+
+
+
+Meson only supports out-of-tree builds, and must be passed a
 directory to put built and generated sources into. We'll call that directory
-"build" for examples.
+"build" here.
+It's recommended to create a
+http://mesonbuild.com/Using-multiple-build-directories.html;>
+separate build directory for each configuration you might want to use.
+
+
+
+
 
 
+Basic configuration is done with:
+
 
-meson build/
+meson build/
 
 
 
-To see a description of your options you can run meson configure
-along with a build directory to view the selected options for. This will show
-your meson global arguments and project arguments, along with their defaults
-and your local settings.
+This will create the build directory.
+If any dependencies are missing, you can install them, or try to remove
+the dependency with a Meson configuration option (see below).
+
+
+
+To review the options which Meson chose, run:
 
+
+meson configure build/
+
 
 
-Meson does not currently support listing options before configure a build
-directory, but this feature is being discussed upstream.
+Meson does not currently support listing configuration options before
+running "meson build/" but this feature is being discussed upstream.
 For now, we have a bin/meson-options.py script that prints
 the options for you.
 If that script doesn't work for some reason, you can always look in the
 meson_options.txt file at the root of the project.
 
 
-
-meson configure build/
-
-
 
-With additional arguments meson configure is used to change
-options on already configured build directory. All options passed to this
-command are in the form -D "command"="value".
+With additional arguments meson configure can be used to change
+options for a previously configured build directory.
+All options passed to this command are in the form
+-D "option"="value".
+For example:
 
 
 
-meson configure build/ -Dprefix=/tmp/install -Dglx=true
+meson configure build/ -Dprefix=/tmp/install -Dglx=true
 
 
 
@@ -88,33 +128,59 @@ and brackets to represent an empty list (-D 
platforms=[]).
 
 
 Once you've run the initial meson command successfully you can use
-your configured backend to build the project. With ninja, the -C option can be
-be used to point at a directory to build.
+your configured backend to build the project in your build directory:
 
 
 
-ninja -C build/
+ninja -C build/
 
 
 
-Without arguments, it will produce libGL.so and/or several other libraries

Re: [Mesa-dev] [PATCH] Revert "radv: execute external subpass barriers after ending subpasses"

2019-03-08 Thread Bas Nieuwenhuizen
I actually think it is partially right, but lets indeed revert for now

Reviewed-by: Bas Nieuwenhuizen 

On Fri, Mar 8, 2019 at 2:48 PM Samuel Pitoiset
 wrote:
>
> This changes is actually wrong because we have to sync
> before doing image layout transitions.
>
> This fixes rendering issues in Batman, Path of Exile and
> probably more titles.
>
> This reverts commit 76c17cfd8da017ebd19be33ba6cef888957a6758.
>
> Cc: 19.0 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 5b66930d137..d8aceb8b082 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -4395,10 +4395,10 @@ void radv_CmdEndRenderPass(
>  {
> RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
>
> -   radv_cmd_buffer_end_subpass(cmd_buffer);
> -
> radv_subpass_barrier(cmd_buffer, 
> _buffer->state.pass->end_barrier);
>
> +   radv_cmd_buffer_end_subpass(cmd_buffer);
> +
> vk_free(_buffer->pool->alloc, cmd_buffer->state.attachments);
>
> cmd_buffer->state.pass = NULL;
> --
> 2.21.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] Revert "radv: execute external subpass barriers after ending subpasses"

2019-03-08 Thread Bas Nieuwenhuizen
oh, also add a Fixes tag please.

On Fri, Mar 8, 2019 at 2:50 PM Bas Nieuwenhuizen
 wrote:
>
> I actually think it is partially right, but lets indeed revert for now
>
> Reviewed-by: Bas Nieuwenhuizen 
>
> On Fri, Mar 8, 2019 at 2:48 PM Samuel Pitoiset
>  wrote:
> >
> > This changes is actually wrong because we have to sync
> > before doing image layout transitions.
> >
> > This fixes rendering issues in Batman, Path of Exile and
> > probably more titles.
> >
> > This reverts commit 76c17cfd8da017ebd19be33ba6cef888957a6758.
> >
> > Cc: 19.0 
> > Signed-off-by: Samuel Pitoiset 
> > ---
> >  src/amd/vulkan/radv_cmd_buffer.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> > b/src/amd/vulkan/radv_cmd_buffer.c
> > index 5b66930d137..d8aceb8b082 100644
> > --- a/src/amd/vulkan/radv_cmd_buffer.c
> > +++ b/src/amd/vulkan/radv_cmd_buffer.c
> > @@ -4395,10 +4395,10 @@ void radv_CmdEndRenderPass(
> >  {
> > RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
> >
> > -   radv_cmd_buffer_end_subpass(cmd_buffer);
> > -
> > radv_subpass_barrier(cmd_buffer, 
> > _buffer->state.pass->end_barrier);
> >
> > +   radv_cmd_buffer_end_subpass(cmd_buffer);
> > +
> > vk_free(_buffer->pool->alloc, cmd_buffer->state.attachments);
> >
> > cmd_buffer->state.pass = NULL;
> > --
> > 2.21.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] svga: remove SVGA_RELOC_READ flag in SVGA3D_BindGBSurface()

2019-03-08 Thread Neha Bhende
Reviewed-by: Neha Bhende 

Regards,
Neha


From: mesa-dev  on behalf of Brian Paul 

Sent: Thursday, March 7, 2019 6:45 PM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende; Deepak Singh Rawat
Subject: [Mesa-dev] [PATCH] svga: remove SVGA_RELOC_READ flag in 
SVGA3D_BindGBSurface()

This fixes a rendering issue where UBO updates aren't always picked
up by drawing calls.  This issue effected the Webots robotics
simulator.  VMware bug 2175527.

Testing Done: Webots replay, piglit, misc Linux games
---
 src/gallium/drivers/svga/svga_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_cmd.c 
b/src/gallium/drivers/svga/svga_cmd.c
index 5557d20..6577c83 100644
--- a/src/gallium/drivers/svga/svga_cmd.c
+++ b/src/gallium/drivers/svga/svga_cmd.c
@@ -1693,7 +1693,7 @@ SVGA3D_BindGBSurface(struct svga_winsys_context *swc,
   return PIPE_ERROR_OUT_OF_MEMORY;

swc->surface_relocation(swc, >sid, >mobid, surface,
-   SVGA_RELOC_READ | SVGA_RELOC_INTERNAL);
+   SVGA_RELOC_READ);

swc->commit(swc);

--
1.8.5.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cbhenden%40vmware.com%7Cf11994e465a1400ada3708d6a37020df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636876099321425712sdata=CDWeq6zQkh%2FC1c1l5Amgf0DgyYUVYCdBHUrw0a6GWUA%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not designated initializers

2019-03-08 Thread Roland Scheidegger
Reviewed-by: Roland Scheidegger 

Am 08.03.19 um 18:14 schrieb Brian Paul:
> Since the compiler may not zero-out padding in the object.
> Add a couple comments about this to prevent misunderstandings in
> the future.
> 
> Fixes: 67d96816ff5 ("st/mesa: move, clean-up shader variant key decls/inits")
> ---
>  src/mesa/state_tracker/st_atom_shader.c |  9 +++--
>  src/mesa/state_tracker/st_program.c | 13 ++---
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_atom_shader.c 
> b/src/mesa/state_tracker/st_atom_shader.c
> index ac7a1a5..a4475e2 100644
> --- a/src/mesa/state_tracker/st_atom_shader.c
> +++ b/src/mesa/state_tracker/st_atom_shader.c
> @@ -112,7 +112,10 @@ st_update_fp( struct st_context *st )
> !stfp->variants->key.bitmap) {
>shader = stfp->variants->driver_shader;
> } else {
> -  struct st_fp_variant_key key = {0};
> +  struct st_fp_variant_key key;
> +
> +  /* use memset, not an initializer to be sure all memory is zeroed */
> +  memset(, 0, sizeof(key));
>  
>key.st = st->has_shareable_shaders ? NULL : st;
>  
> @@ -168,7 +171,9 @@ st_update_vp( struct st_context *st )
> stvp->variants->key.passthrough_edgeflags == st->vertdata_edgeflags) {
>st->vp_variant = stvp->variants;
> } else {
> -  struct st_vp_variant_key key = {0};
> +  struct st_vp_variant_key key;
> +
> +  memset(, 0, sizeof(key));
>  
>key.st = st->has_shareable_shaders ? NULL : st;
>  
> diff --git a/src/mesa/state_tracker/st_program.c 
> b/src/mesa/state_tracker/st_program.c
> index 6d669a9..fe03070 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -1807,7 +1807,10 @@ st_get_cp_variant(struct st_context *st,
>  {
> struct pipe_context *pipe = st->pipe;
> struct st_basic_variant *v;
> -   struct st_basic_variant_key key = {0};
> +   struct st_basic_variant_key key;
> +
> +   /* use memset, not an initializer to be sure all memory is zeroed */
> +   memset(, 0, sizeof(key));
>  
> key.st = st->has_shareable_shaders ? NULL : st;
>  
> @@ -2030,7 +2033,9 @@ st_precompile_shader_variant(struct st_context *st,
> switch (prog->Target) {
> case GL_VERTEX_PROGRAM_ARB: {
>struct st_vertex_program *p = (struct st_vertex_program *)prog;
> -  struct st_vp_variant_key key = {0};
> +  struct st_vp_variant_key key;
> +
> +  memset(, 0, sizeof(key));
>  
>key.st = st->has_shareable_shaders ? NULL : st;
>st_get_vp_variant(st, p, );
> @@ -2057,7 +2062,9 @@ st_precompile_shader_variant(struct st_context *st,
>  
> case GL_FRAGMENT_PROGRAM_ARB: {
>struct st_fragment_program *p = (struct st_fragment_program *)prog;
> -  struct st_fp_variant_key key = {0};
> +  struct st_fp_variant_key key;
> +
> +  memset(, 0, sizeof(key));
>  
>key.st = st->has_shareable_shaders ? NULL : st;
>st_get_fp_variant(st, p, );
> 

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

[Mesa-dev] [Bug 109944] [bisected] Android build test fails with: utils.c: error: use of undeclared identifier 'PACKAGE_VERSION'

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109944

Eric Engestrom  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Eric Engestrom  ---
commit f67c8701799ec29083f40373f74027f9b1d6dbc6
Author: Eric Engestrom 
Date:   Fri Mar 8 20:56:38 2019 +

android: fix missing backspace for line continuation

Reported-by: Clayton Craft 
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109944
Fixes: e1d81decf7a093867f05 "build: make passing an incorrect pointer type
a hard error"
Signed-off-by: Eric Engestrom 

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

Re: [Mesa-dev] [PATCH v2 8/8] panfrost: Add backend targeting the DRM driver

2019-03-08 Thread Alyssa Rosenzweig
> +/**
> + * struct drm_panfrost_wait_bo - ioctl argument for waiting for
> + * completion of the last DRM_PANFROST_SUBMIT_CL on a BO.

Nit: Should be plain DRM_PANFROST_SUBMIT, there is no CL for us.

> + __s64 timeout_ns;   /* absolute */

Erm, why is this signed? Semantically, what does a negative timestamp
mean? Seems suspect. The comment /* absolute */ seems to underscore that
we really do want an unsigned value, perhaps ascribing a special meaning
to 0/~0 for "nonblocking" and "block indefinitely" if needed. Of course,
"(2^64)-1 ns" is essentially indefinite, so the latter need not be a
special case.

* It's 585 years, according to a back of the envelope calculation.
  Panfrost will be obsolete many times over by the time that timeout
  elapses ;)

> + struct drm_panfrost_mmap_bo mmap_bo = {0,};

Nit: "{0,} is confusing.

General nit: Spacing is all over the place in pan_drm.h. I'm not one to
particularly care (I think I use 8-space indents...), but it's
inconsistent from line to line which is a little distracting. If you use
vim, I have set:

au BufNewFile,BufRead */mesa/* set expandtab tabstop=8 softtabstop=3 
shiftwidth=3
au BufNewFile,BufRead */panfrost/* set expandtab tabstop=8 shiftwidth=8 
softtabstop=8

which generally does the right thing. Translating to $EDITOR left as an
exercise to the reader.

---

Overall, this looks really great. I haven't gotten the chance to test
this personally yet, but I think I can nevertheless push at least the
other 7 patches tonight :)

Keep up the awesome work!

Alyssa


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

Re: [Mesa-dev] [PATCH v2 2/8] panfrost: Detect GPU version at runtime

2019-03-08 Thread Alyssa Rosenzweig
> This doesn't work for t604 which has a special version of 0x6???. That
> helpfully also collides with bifrost versions. We could fix this up in
> the kernel to expose it as 0x0600. Then an 'is_bifrost' would be an
> easy (gpu_id & 0xf000).

I think there's a fundamental question here, do we want kernelspace to
process versions or just sort it out in userspace? (Knowing that we'll
have to _also_ sort it out in kernelspace for feature/issue detection
there too...) I think given it's between doing it on "kernel" or "kernel
*and* userspace", it makes sense to normalize in kernelspace, but still
maintaining the hardware scheme (to avoid passing around a second set of
arbitrary version #define's).

> Why isn't this 'is_t8xx' instead as you are touching it everywhere or
> this needs to be t8xx and bifrost? If not you could just do ((gpu_id &
> 0xff00) == 0x0800).

I think that's a reasonable +1 for normalizing in kernelspace. But we're
not actually sure what is_t8xx turns off/on; it's a catch-all for magic
values we know are different between a T6XX I tested on originally (with
values that work on T760 as well) and the T860 I've been using more
recently (with values that work on T820 as well, but not T760). We'll
_want_ to have much more fine-grained granularity, of course, but
userspace is kind of ignorant on what means what...

-Alyssa


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

Re: [Mesa-dev] [PATCH] docs: try to improve the Meson documentation

2019-03-08 Thread Brian Paul
On Thu, Mar 7, 2019 at 11:51 PM Eric Engestrom  wrote:

> On 2019-03-08 at 03:42, Brian Paul  wrote:
> > Add new Introduction and Advanced Usage sections.
> > Spell out a few more details, like "ninja install".
> > Improve the layout around example commands.
> > Fix grammatical errors and tighten up the text.
> > Explain the --prefix option.
>
> Thanks! I left a couple comments below, but this is:
> Reviewed-by: Eric Engestrom 
>
> > ---
> >  docs/contents.html |   2 +-
> >  docs/meson.html| 138
> +++--
> >  2 files changed, 104 insertions(+), 36 deletions(-)
> >
> > diff --git a/docs/contents.html b/docs/contents.html
> > index 6364776..619ac3d 100644
> > --- a/docs/contents.html
> > +++ b/docs/contents.html
> > @@ -42,8 +42,8 @@
> >  Downloading / Unpacking
> >  Compiling / Installing
> >
> > -Autoconf
> >  Meson
> > +Autoconf
> (deprecated)
> >
> >  
> >  Precompiled
> Libraries
> > diff --git a/docs/meson.html b/docs/meson.html
> > index f21479c..f9ae669 100644
> > --- a/docs/meson.html
> > +++ b/docs/meson.html
> > @@ -17,65 +17,98 @@
> >  Compilation and Installation using Meson
> >
> >  
> > +  Introduction
> >Basic Usage
> > +  Advanced Usage
> >Cross-compilation and 32-bit
> builds
> >  
> >
> > -1. Basic Usage
> > +1. Introduction
> >
> > -The Meson build system is generally considered stable and
> ready
> > -for production
> > +For general information about Meson see the
> > +http://mesonbuild.com/;>Meson website.
> >
> > -The meson build is tested on Linux, macOS, Cygwin and Haiku,
> > FreeBSD,
> > +Mesa's Meson build system is generally considered stable
> > and ready
> > +for production.
> > +
> > +The Meson build of Mesa is tested on Linux, macOS, Cygwin and
> > Haiku, FreeBSD,
> >  DragonflyBSD, NetBSD, and should work on OpenBSD.
> >
> > +If Meson is not already installed on your system, you can typically
> > +install it with your package installer.  For example:
> > +
> > +sudo apt-get install meson   # Ubuntu
> > +
> > +or
> > +
> > +sudo dnf install meson   # Fedora
> > +
> > +
> >  Mesa requires Meson >= 0.45.0 to build.
> >
> >  Some older versions of meson do not check that they are too old and
> will error
> >  out in odd ways.
> >  
> >
> > +You'll also need https://ninja-build.org/;>Ninja.
> > +If it's not already installed, use apt-get or dnf to install
> > +the ninja-build package.
> > +
> > +
> > +2. Basic Usage
> > +
> >  
> >  The meson program is used to configure the source directory and
> > generates
> >  either a ninja build file or Visual Studio® build files. The latter
> > must
> > -be enabled via the --backend switch, as ninja is the
> > default backend on all
> > -operating systems. Meson only supports out-of-tree builds, and must be
> > passed a
> > +be enabled via the --backend switch, as ninja is the
> > default
> > +backend on all
> > +operating systems.
> > +
> > +
> > +
> > +Meson only supports out-of-tree builds, and must be passed a
> >  directory to put built and generated sources into. We'll call that
> > directory
> > -"build" for examples.
> > +"build" here.
> >  
> >
> > +Basic configuration is done with:
> > +
> >  
> > -meson build/
> > +meson build/
> >  
> >
> >  
> > -To see a description of your options you can run meson
> configure
> > -along with a build directory to view the selected options for. This
> will show
> > -your meson global arguments and project arguments, along with their
> defaults
> > -and your local settings.
> > +This will create the build directory.
> > +If any dependencies are missing, you can install them, or try to remove
> > +the dependency with a Meson configuration option (see below).
> > +
> > +
> > +
> > +To review the options which Meson chose, run:
> >  
> > +
> > +meson configure build/
> > +
> >
> >  
> > -Meson does not currently support listing options before configure a
> build
> > -directory, but this feature is being discussed upstream.
> > +Meson does not currently support listing configuration options before
> > +running "meson build/" but this feature is being discussed upstream.
> >  For now, we have a bin/meson-options.py script that prints
> >  the options for you.
> >  If that script doesn't work for some reason, you can always look in the
> >  meson_options.txt file at the root of the project.
> >  
> >
> > -
> > -meson configure build/
> > -
> > -
> >  
> > -With additional arguments meson configure is used to change
> > -options on already configured build directory. All options passed to
> this
> > -command are in the form -D "command"="value".
> > +With additional arguments meson configure can be used to
> change
> > +options for a previously configured build directory.
> > +All options passed to this command are in the form
> > +-D "command"="value".
>
> I know you didn't write this bit, but can I suggest s/command/option/ ?
>

Done.



> > +For example:
> >  
> >
> >  
> > -meson configure build/ 

Re: [Mesa-dev] [PATCH 2/2] intel/compiler: silence unitialized variable warning in opt_vector_float()

2019-03-08 Thread Lionel Landwerlin

Reviewed-by: Lionel Landwerlin 

Thanks!

On 08/03/2019 15:52, Brian Paul wrote:

---
  src/intel/compiler/brw_vec4.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index fe36851..2e9de29 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -414,7 +414,7 @@ vec4_visitor::opt_vector_float()
  
foreach_inst_in_block_safe(vec4_instruction, inst, block) {

   int vf = -1;
- enum brw_reg_type need_type;
+ enum brw_reg_type need_type = BRW_REGISTER_TYPE_LAST;
  
   /* Look for unconditional MOVs from an immediate with a partial

* writemask.  Skip type-conversion MOVs other than integer 0,



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

Re: [Mesa-dev] [PATCH 1/2] intel/decoders: silence uninitialized variable warnings in gen_print_batch()

2019-03-08 Thread Lionel Landwerlin

Reviewed-by: Lionel Landwerlin 

On 08/03/2019 15:52, Brian Paul wrote:

---
  src/intel/common/gen_batch_decoder.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index ff898d8..5cac983 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -874,9 +874,9 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
}
  
if (strcmp(inst_name, "MI_BATCH_BUFFER_START") == 0) {

- uint64_t next_batch_addr;
+ uint64_t next_batch_addr = 0;
   bool ppgtt = false;
- bool second_level;
+ bool second_level = false;
   struct gen_field_iterator iter;
   gen_field_iterator_init(, inst, p, 0, false);
   while (gen_field_iterator_next()) {



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

Re: [Mesa-dev] [PATCH] st/mesa: move, clean-up shader variant key decls/inits

2019-03-08 Thread Roland Scheidegger
Am 07.03.19 um 17:20 schrieb Brian Paul:
> Move the variant key declarations inside the scope they're used.
> Use designated initializers instead of memset() calls.
I don't think this will always work as intended, since there's
non-explicit padding bits in the key, and AFAIK even with c11 compilers
are not required to set such padding to zero too.

Roland



> ---
>  src/mesa/state_tracker/st_atom_shader.c | 8 
>  src/mesa/state_tracker/st_program.c | 9 +++--
>  2 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_atom_shader.c 
> b/src/mesa/state_tracker/st_atom_shader.c
> index c6faa3f..ac7a1a5 100644
> --- a/src/mesa/state_tracker/st_atom_shader.c
> +++ b/src/mesa/state_tracker/st_atom_shader.c
> @@ -97,7 +97,6 @@ void
>  st_update_fp( struct st_context *st )
>  {
> struct st_fragment_program *stfp;
> -   struct st_fp_variant_key key;
>  
> assert(st->ctx->FragmentProgram._Current);
> stfp = st_fragment_program(st->ctx->FragmentProgram._Current);
> @@ -113,7 +112,8 @@ st_update_fp( struct st_context *st )
> !stfp->variants->key.bitmap) {
>shader = stfp->variants->driver_shader;
> } else {
> -  memset(, 0, sizeof(key));
> +  struct st_fp_variant_key key = {0};
> +
>key.st = st->has_shareable_shaders ? NULL : st;
>  
>/* _NEW_FRAG_CLAMP */
> @@ -155,7 +155,6 @@ void
>  st_update_vp( struct st_context *st )
>  {
> struct st_vertex_program *stvp;
> -   struct st_vp_variant_key key;
>  
> /* find active shader and params -- Should be covered by
>  * ST_NEW_VERTEX_PROGRAM
> @@ -169,7 +168,8 @@ st_update_vp( struct st_context *st )
> stvp->variants->key.passthrough_edgeflags == st->vertdata_edgeflags) {
>st->vp_variant = stvp->variants;
> } else {
> -  memset(, 0, sizeof key);
> +  struct st_vp_variant_key key = {0};
> +
>key.st = st->has_shareable_shaders ? NULL : st;
>  
>/* When this is true, we will add an extra input to the vertex
> diff --git a/src/mesa/state_tracker/st_program.c 
> b/src/mesa/state_tracker/st_program.c
> index c2daa4d..5e43a2e 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -1772,9 +1772,8 @@ st_get_cp_variant(struct st_context *st,
>  {
> struct pipe_context *pipe = st->pipe;
> struct st_basic_variant *v;
> -   struct st_basic_variant_key key;
> +   struct st_basic_variant_key key = {0};
>  
> -   memset(, 0, sizeof(key));
> key.st = st->has_shareable_shaders ? NULL : st;
>  
> /* Search for existing variant */
> @@ -1996,9 +1995,8 @@ st_precompile_shader_variant(struct st_context *st,
> switch (prog->Target) {
> case GL_VERTEX_PROGRAM_ARB: {
>struct st_vertex_program *p = (struct st_vertex_program *)prog;
> -  struct st_vp_variant_key key;
> +  struct st_vp_variant_key key = {0};
>  
> -  memset(, 0, sizeof(key));
>key.st = st->has_shareable_shaders ? NULL : st;
>st_get_vp_variant(st, p, );
>break;
> @@ -2024,9 +2022,8 @@ st_precompile_shader_variant(struct st_context *st,
>  
> case GL_FRAGMENT_PROGRAM_ARB: {
>struct st_fragment_program *p = (struct st_fragment_program *)prog;
> -  struct st_fp_variant_key key;
> +  struct st_fp_variant_key key = {0};
>  
> -  memset(, 0, sizeof(key));
>key.st = st->has_shareable_shaders ? NULL : st;
>st_get_fp_variant(st, p, );
>break;
> 

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

Re: [Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not designated initializers

2019-03-08 Thread Neha Bhende
Reviewed-by: Neha Bhende 

Regards,
Neha


From: mesa-dev  on behalf of Brian Paul 

Sent: Friday, March 8, 2019 9:14 AM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not 
designated initializers

Since the compiler may not zero-out padding in the object.
Add a couple comments about this to prevent misunderstandings in
the future.

Fixes: 67d96816ff5 ("st/mesa: move, clean-up shader variant key decls/inits")
---
 src/mesa/state_tracker/st_atom_shader.c |  9 +++--
 src/mesa/state_tracker/st_program.c | 13 ++---
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_shader.c 
b/src/mesa/state_tracker/st_atom_shader.c
index ac7a1a5..a4475e2 100644
--- a/src/mesa/state_tracker/st_atom_shader.c
+++ b/src/mesa/state_tracker/st_atom_shader.c
@@ -112,7 +112,10 @@ st_update_fp( struct st_context *st )
!stfp->variants->key.bitmap) {
   shader = stfp->variants->driver_shader;
} else {
-  struct st_fp_variant_key key = {0};
+  struct st_fp_variant_key key;
+
+  /* use memset, not an initializer to be sure all memory is zeroed */
+  memset(, 0, sizeof(key));

   key.st = st->has_shareable_shaders ? NULL : st;

@@ -168,7 +171,9 @@ st_update_vp( struct st_context *st )
stvp->variants->key.passthrough_edgeflags == st->vertdata_edgeflags) {
   st->vp_variant = stvp->variants;
} else {
-  struct st_vp_variant_key key = {0};
+  struct st_vp_variant_key key;
+
+  memset(, 0, sizeof(key));

   key.st = st->has_shareable_shaders ? NULL : st;

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 6d669a9..fe03070 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1807,7 +1807,10 @@ st_get_cp_variant(struct st_context *st,
 {
struct pipe_context *pipe = st->pipe;
struct st_basic_variant *v;
-   struct st_basic_variant_key key = {0};
+   struct st_basic_variant_key key;
+
+   /* use memset, not an initializer to be sure all memory is zeroed */
+   memset(, 0, sizeof(key));

key.st = st->has_shareable_shaders ? NULL : st;

@@ -2030,7 +2033,9 @@ st_precompile_shader_variant(struct st_context *st,
switch (prog->Target) {
case GL_VERTEX_PROGRAM_ARB: {
   struct st_vertex_program *p = (struct st_vertex_program *)prog;
-  struct st_vp_variant_key key = {0};
+  struct st_vp_variant_key key;
+
+  memset(, 0, sizeof(key));

   key.st = st->has_shareable_shaders ? NULL : st;
   st_get_vp_variant(st, p, );
@@ -2057,7 +2062,9 @@ st_precompile_shader_variant(struct st_context *st,

case GL_FRAGMENT_PROGRAM_ARB: {
   struct st_fragment_program *p = (struct st_fragment_program *)prog;
-  struct st_fp_variant_key key = {0};
+  struct st_fp_variant_key key;
+
+  memset(, 0, sizeof(key));

   key.st = st->has_shareable_shaders ? NULL : st;
   st_get_fp_variant(st, p, );
--
1.8.5.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cbhenden%40vmware.com%7C773d52000a58466ac0d508d6a3e98df6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636876620836813700sdata=pyvSVyPLzF8JXaiMptIRwvddQX2Hh7rm%2FAV%2BivL%2FOOE%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109944] [bisected] Android build test fails with: utils.c: error: use of undeclared identifier 'PACKAGE_VERSION'

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109944

Bug ID: 109944
   Summary: [bisected] Android build test fails with: utils.c:
error: use of undeclared identifier 'PACKAGE_VERSION'
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Keywords: bisected
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: fdo-b...@engestrom.ch
  Reporter: clayton.a.cr...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

[ 39% 1228/3101] target  C: libmesa_dri_common_32 <=
vendor/intel/external/project-celadon/mesa/src/mesa/drivers/dri/common/utils.c
FAILED:
out/target/product/cel_apl/obj_x86/STATIC_LIBRARIES/libmesa_dri_common_intermediates/utils.o
/bin/bash -c "PWD=/proc/self/cwd 
prebuilts/clang/host/linux-x86/clang-4691093/bin/clang-I
vendor/intel/external/project-celadon/mesa/include -I
vendor/intel/external/project-celadon/mesa/src/egl/drivers/dri -I
vendor/intel/external/project-celadon/mesa/src/egl/main -I
vendor/intel/external/project-celadon/mesa/src/mapi -I
vendor/intel/external/project-celadon/mesa/src/mesa -I
vendor/intel/external/project-celadon/mesa/src/mesa/drivers/dri/common -I
vendor/intel/external/project-celadon/mesa/src/util -I
vendor/intel/external/project-celadon/mesa/src/gallium/include -I
vendor/intel/external/project-celadon/mesa/src/gallium/auxiliary -I
external/expat/lib -I vendor/intel/external/project-celadon/mesa/src -I
vendor/intel/external/project-celadon/mesa/include -I
vendor/intel/external/project-celadon/mesa/src/mesa/drivers/dri/common -I
out/target/product/cel_apl/obj_x86/STATIC_LIBRARIES/libmesa_dri_common_intermediates
-I
out/target/product/cel_apl/gen/STATIC_LIBRARIES/libmesa_dri_common_intermediates
\$(cat
out/target/product/cel_apl/obj_x86/STATIC_LIBRARIES/libmesa_dri_common_intermediates/import_includes)
  -isystem out/target/product/cel_apl/obj/include -c  -msse3 -mstackrealign
-DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith
-no-canonical-prefixes -DNDEBUG -UDEBUG -fno-exceptions -Wno-multichar -O2 -g
-fno-strict-aliasing -fdebug-prefix-map=/proc/self/cwd=
-D__compiler_offsetof=__builtin_offsetof -Werror=int-conversion
-Wno-reserved-id-macro -Wno-format-pedantic -Wno-unused-command-line-argument
-fcolor-diagnostics -Wno-expansion-to-defined
-Wno-zero-as-null-pointer-constant -fdebug-prefix-map=\$PWD/=
-ffunction-sections -fdata-sections -fno-short-enums -funwind-tables
-fstack-protector-strong -Wa,--noexecstack -D_FORTIFY_SOURCE=2
-Wstrict-aliasing=2 -Werror=return-type -Werror=non-virtual-dtor
-Werror=address -Werror=sequence-point -Werror=date-time
-Werror=format-security -nostdlibinc -m32 -march=prescott -target
i686-linux-android
-Bprebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin
  -std=gnu99-Wno-error -Werror=incompatible-pointer-types
-DANDROID_API_LEVEL=28 -DENABLE_SHADER_CACHE -D__STDC_CONSTANT_MACROS
-D__STDC_LIMIT_MACROS -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS
-DHAVE___BUILTIN_FFSLL -DHAVE_DLFCN_H -DHAVE_FUNC_ATTRIBUTE_FLATTEN
-DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_ALIAS
-DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE___BUILTIN_CTZ
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_CLZ
-DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE_PTHREAD=1
-DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H
-DHAVE_ZLIB -DMAJOR_IN_SYSMACROS -DVK_USE_PLATFORM_ANDROID_KHR
-fvisibility=hidden -fno-math-errno -fno-trapping-math -Wno-sign-compare
-Wno-self-assign -Wno-constant-logical-operand -Wno-format
-Wno-incompatible-pointer-types -Wno-enum-conversion -DHAVE_LIBDRM
-D__ANDROID_API__=28 -D__ANDROID_VNDK__ -fPIC
-DDEFAULT_DRIVER_DIR=\\\"/vendor/lib/dri\\\" -D_USING_LIBCXX -DANDROID_STRICT
-std=c99  -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast
-Werror=address-of-temporary -Werror=return-type
-Wno-tautological-constant-compare -Wno-null-pointer-arithmetic
-Wno-enum-compare -Wno-enum-compare-switch -MD -MF
out/target/product/cel_apl/obj_x86/STATIC_LIBRARIES/libmesa_dri_common_intermediates/utils.d
-o
out/target/product/cel_apl/obj_x86/STATIC_LIBRARIES/libmesa_dri_common_intermediates/utils.o
vendor/intel/external/project-celadon/mesa/src/mesa/drivers/dri/common/utils.c"
vendor/intel/external/project-celadon/mesa/src/mesa/drivers/dri/common/utils.c:534:38:
error: use of undeclared identifier 'PACKAGE_VERSION'


Bisected to this commit:

commit e1d81decf7a093867f051786a5d7f6ce4d827ff1
Author: Eric Engestrom 
Date:   Tue Nov 20 12:32:18 2018 +

build: make passing an incorrect pointer type a hard error

More or less any of this issue pointed out by the compiler is
a coding error. Make sure we flag it and bail 

[Mesa-dev] [Bug 109944] [bisected] Android build test fails with: utils.c: error: use of undeclared identifier 'PACKAGE_VERSION'

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109944

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Eric Engestrom  ---
Oh FFS, I forgot a backslash at the end of the line I added in
Android.common.mk… :facepalm:

Pushing a fix in a minute.

-- 
You are receiving this mail because:
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 109535] [Tracker] Mesa 19.0 release tracker

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Bug 109535 depends on bug 109505, which changed state.

Bug 109505 Summary: [GEN9+] 2% perf drop in Unigine Heaven, 1% in Valley
https://bugs.freedesktop.org/show_bug.cgi?id=109505

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

-- 
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 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109929

Vinson Lee  changed:

   What|Removed |Added

   Keywords||bisected
 CC||ven...@msn.com

--- Comment #3 from Vinson Lee  ---
./autogen.sh --enable-autotools --enable-opencl --with-dri-drivers=
--with-gallium-drivers=freedreno

9a834447d652ea50864bb6c32f4ff99ac10d39bf is the first bad commit
commit 9a834447d652ea50864bb6c32f4ff99ac10d39bf
Author: Timur Kristóf 
Date:   Tue Mar 5 18:59:47 2019 +0100

tgsi_to_nir: Produce optimized NIR for a given pipe_screen.

With this patch, tgsi_to_nir will output NIR that is tailored to
the given pipe, by reading its capabilities and adjusting the NIR code
to those capabilities similarly to how glsl_to_nir works.

It also adds an optimization loop that brings the output NIR in line
with what glsl_to_nir outputs. This is necessary for the same reason
why glsl_to_nir has its own optimization loop: currently not every
driver does these optimizations yet.

For uses which cannot pass a pipe_screen we also keep a variant
called tgsi_to_nir_noscreen which keeps the old behavior.

Signed-Off-By: Timur Kristóf 
Tested-by: Andre Heider 
Tested-by: Rob Clark 
Acked-By: Eric Anholt 

:04 04 8a3cea38b8872254f1dcf139a50ec76317167923
650d8da3884a85bac808914967ab9ce8db72bed9 M  src
bisect run success

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

[Mesa-dev] [PATCH 5/6] i915g: remove calls to pipe_sampler_view_release()

2019-03-08 Thread Brian Paul
As with previous patches for svga, llvmpipe, swr drivers.
Compile tested only.
---
 src/gallium/drivers/i915/i915_state.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/i915/i915_state.c 
b/src/gallium/drivers/i915/i915_state.c
index ddc2709..03d218e 100644
--- a/src/gallium/drivers/i915/i915_state.c
+++ b/src/gallium/drivers/i915/i915_state.c
@@ -745,17 +745,11 @@ static void i915_set_fragment_sampler_views(struct 
pipe_context *pipe,
   return;
 
for (i = 0; i < num; i++) {
-  /* Note: we're using pipe_sampler_view_release() here to work around
-   * a possible crash when the old view belongs to another context that
-   * was already destroyed.
-   */
-  pipe_sampler_view_release(pipe, >fragment_sampler_views[i]);
-  pipe_sampler_view_reference(>fragment_sampler_views[i],
-  views[i]);
+  pipe_sampler_view_reference(>fragment_sampler_views[i], views[i]);
}
 
for (i = num; i < i915->num_fragment_sampler_views; i++)
-  pipe_sampler_view_release(pipe, >fragment_sampler_views[i]);
+  pipe_sampler_view_reference(>fragment_sampler_views[i], NULL);
 
i915->num_fragment_sampler_views = num;
 
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 2/6] svga: stop using pipe_sampler_view_release()

2019-03-08 Thread Brian Paul
This function was used in the past to avoid deleting a sampler view
for a context that no longer exists.  But the Mesa state tracker
ensures that cannot happen.  Use the standard refcounting function
instead.

Testing Done: google chrome, variety of GL demos/games
---
 src/gallium/drivers/svga/svga_pipe_sampler.c | 12 
 src/gallium/drivers/svga/svga_state_tss.c|  4 ++--
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_pipe_sampler.c 
b/src/gallium/drivers/svga/svga_pipe_sampler.c
index b32bb09..429f072 100644
--- a/src/gallium/drivers/svga/svga_pipe_sampler.c
+++ b/src/gallium/drivers/svga/svga_pipe_sampler.c
@@ -465,7 +465,8 @@ svga_set_sampler_views(struct pipe_context *pipe,
 */
if (start == 0 && num == 0 && svga->curr.num_sampler_views[shader] > 0) {
   for (i = 0; i < svga->curr.num_sampler_views[shader]; i++) {
- pipe_sampler_view_release(pipe, >curr.sampler_views[shader][i]);
+ pipe_sampler_view_reference(>curr.sampler_views[shader][i],
+ NULL);
   }
   any_change = TRUE;
}
@@ -474,11 +475,6 @@ svga_set_sampler_views(struct pipe_context *pipe,
   enum pipe_texture_target target;
 
   if (svga->curr.sampler_views[shader][start + i] != views[i]) {
- /* Note: we're using pipe_sampler_view_release() here to work around
-  * a possible crash when the old view belongs to another context that
-  * was already destroyed.
-  */
- pipe_sampler_view_release(pipe, 
>curr.sampler_views[shader][start + i]);
  pipe_sampler_view_reference(>curr.sampler_views[shader][start + 
i],
  views[i]);
  any_change = TRUE;
@@ -552,8 +548,8 @@ svga_cleanup_sampler_state(struct svga_context *svga)
   unsigned i;
 
   for (i = 0; i < svga->state.hw_draw.num_sampler_views[shader]; i++) {
- pipe_sampler_view_release(>pipe,
-   
>state.hw_draw.sampler_views[shader][i]);
+ 
pipe_sampler_view_reference(>state.hw_draw.sampler_views[shader][i],
+ NULL);
   }
}

diff --git a/src/gallium/drivers/svga/svga_state_tss.c 
b/src/gallium/drivers/svga/svga_state_tss.c
index d598d23..95b1a9e 100644
--- a/src/gallium/drivers/svga/svga_state_tss.c
+++ b/src/gallium/drivers/svga/svga_state_tss.c
@@ -50,8 +50,8 @@ svga_cleanup_tss_binding(struct svga_context *svga)
   struct svga_hw_view_state *view = >state.hw_draw.views[i];
   if (view) {
  svga_sampler_view_reference(>v, NULL);
- pipe_sampler_view_release(>pipe,
-   >curr.sampler_views[shader][i]);
+ pipe_sampler_view_reference(>curr.sampler_views[shader][i],
+ NULL);
  pipe_resource_reference(>texture, NULL);
  view->dirty = TRUE;
   }
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 1/6] st/mesa: fix sampler view context mismatch issue

2019-03-08 Thread Brian Paul
After a while of running google-chrome and viewing Bing maps, we'd see
"context mismatch in svga_sampler_view_destroy()" messages and
eventually crash because we leaked too many sampler views (the kernel
module would have too many sampler views).

When a texture object is being deleted, we call
st_texture_release_all_sampler_views() to release all the sampler
views.  In the list, there may sampler views which were created from
other contexts.

Previously, we called pipe_sampler_view_release(pipe, view) which would
use the given pipe context to destroy the view if the refcount hit
zero.  The svga error was triggered because we were calling
pipe->sampler_view_destroy(pipe, view) and the pipe context didn't
match the view's parent context.

Instead, call pipe_sampler_reference(, NULL).  That way, if
the refcount hits zero, we'll use the view's parent context to
destroy the view.  That's what we want.

The pipe_sampler_view_release() function was introduced years ago to
avoid freeing a sampler view with a context that was already deleted.

But since then we've improved sampler view and context tracking.
When a context is destroyed, the state tracker walks over all
texture objects and frees all sampler views which belong to that
context.  So, we should never end up deleting a sampler view after
its context is deleted.

After this, we can remove all calls to pipe_sampler_view_release()
in the drivers.

Finally, it appears that we need to implement a similar tear-down
mechanism for shaders and programs since we may generate per-context
shader variants.

Testing done: google chrome, misc GL demos, games
---
 src/mesa/state_tracker/st_context.c  | 3 +--
 src/mesa/state_tracker/st_sampler_view.c | 8 
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 2898279..a7464fd 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -278,8 +278,7 @@ st_destroy_context_priv(struct st_context *st, bool 
destroy_pipe)
st_destroy_bound_image_handles(st);
 
for (i = 0; i < ARRAY_SIZE(st->state.frag_sampler_views); i++) {
-  pipe_sampler_view_release(st->pipe,
->state.frag_sampler_views[i]);
+  pipe_sampler_view_reference(>state.frag_sampler_views[i], NULL);
}
 
/* free glReadPixels cache data */
diff --git a/src/mesa/state_tracker/st_sampler_view.c 
b/src/mesa/state_tracker/st_sampler_view.c
index e4eaf39..650a2b0 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -74,7 +74,7 @@ st_texture_set_sampler_view(struct st_context *st,
   if (sv->view) {
  /* check if the context matches */
  if (sv->view->context == st->pipe) {
-pipe_sampler_view_release(st->pipe, >view);
+pipe_sampler_view_reference(>view, NULL);
 goto found;
  }
   } else {
@@ -94,13 +94,13 @@ st_texture_set_sampler_view(struct st_context *st,
 
  if (new_max < views->max ||
  new_max > (UINT_MAX - sizeof(*views)) / sizeof(views->views[0])) {
-pipe_sampler_view_release(st->pipe, );
+pipe_sampler_view_reference(, NULL);
 goto out;
  }
 
  struct st_sampler_views *new_views = malloc(new_size);
  if (!new_views) {
-pipe_sampler_view_release(st->pipe, );
+pipe_sampler_view_reference(, NULL);
 goto out;
  }
 
@@ -225,7 +225,7 @@ st_texture_release_all_sampler_views(struct st_context *st,
simple_mtx_lock(>validate_mutex);
struct st_sampler_views *views = stObj->sampler_views;
for (i = 0; i < views->count; ++i)
-  pipe_sampler_view_release(st->pipe, >views[i].view);
+  pipe_sampler_view_reference(>views[i].view, NULL);
simple_mtx_unlock(>validate_mutex);
 }
 
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 4/6] swr: remove call to pipe_sampler_view_release()

2019-03-08 Thread Brian Paul
As with svga, llvmpipe drivers in previous patches.
Compile tested only.
---
 src/gallium/drivers/swr/swr_state.cpp | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index d7baa71..42d196f 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -302,11 +302,6 @@ swr_set_sampler_views(struct pipe_context *pipe,
/* set the new sampler views */
ctx->num_sampler_views[shader] = num;
for (i = 0; i < num; i++) {
-  /* Note: we're using pipe_sampler_view_release() here to work around
-   * a possible crash when the old view belongs to another context that
-   * was already destroyed.
-   */
-  pipe_sampler_view_release(pipe, >sampler_views[shader][start + i]);
   pipe_sampler_view_reference(>sampler_views[shader][start + i],
   views[i]);
}
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 6/6] gallium/util: remove pipe_sampler_view_release()

2019-03-08 Thread Brian Paul
It's no longer used.
---
 src/gallium/auxiliary/util/u_inlines.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_inlines.h 
b/src/gallium/auxiliary/util/u_inlines.h
index fa1e920..567d3d0 100644
--- a/src/gallium/auxiliary/util/u_inlines.h
+++ b/src/gallium/auxiliary/util/u_inlines.h
@@ -192,26 +192,6 @@ pipe_sampler_view_reference(struct pipe_sampler_view **dst,
*dst = src;
 }
 
-/**
- * Similar to pipe_sampler_view_reference() but always set the pointer to
- * NULL and pass in the current context explicitly.
- *
- * If *ptr is non-NULL, it may refer to a view that was created in a different
- * context (however, that context must still be alive).
- */
-static inline void
-pipe_sampler_view_release(struct pipe_context *ctx,
-  struct pipe_sampler_view **ptr)
-{
-   struct pipe_sampler_view *old_view = *ptr;
-
-   if (pipe_reference_described(_view->reference, NULL,
-(debug_reference_descriptor)debug_describe_sampler_view)) {
-  ctx->sampler_view_destroy(ctx, old_view);
-   }
-   *ptr = NULL;
-}
-
 static inline void
 pipe_so_target_reference(struct pipe_stream_output_target **dst,
  struct pipe_stream_output_target *src)
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 3/6] llvmpipe: stop using pipe_sampler_view_release()

2019-03-08 Thread Brian Paul
This was used to avoid freeing a sampler view which was created by a
context that was already deleted.  But the state tracker does not
allow that.
---
 src/gallium/drivers/llvmpipe/lp_state_sampler.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c 
b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
index c9aba1a..72823e4 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
@@ -123,12 +123,6 @@ llvmpipe_set_sampler_views(struct pipe_context *pipe,
 
/* set the new sampler views */
for (i = 0; i < num; i++) {
-  /* Note: we're using pipe_sampler_view_release() here to work around
-   * a possible crash when the old view belongs to another context that
-   * was already destroyed.
-   */
-  pipe_sampler_view_release(pipe,
->sampler_views[shader][start + i]);
   /*
* Warn if someone tries to set a view created in a different context
* (which is why we need the hack above in the first place).
-- 
1.8.5.6

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

Re: [Mesa-dev] [PATCH] nir/spirv: short-circuit when conditional branch contains end block

2019-03-08 Thread Jason Ekstrand
On Fri, Mar 8, 2019 at 9:30 AM Juan A. Suarez Romero 
wrote:

> On Thu, 2019-03-07 at 07:15 -0600, Jason Ekstrand wrote:
> > Woah, is this legal SPIR-V? I think a second OpSelectionMerge is
> required.
>
> I'd say it is legal. The spec does not mandate that each branch has its own
> merge instruction; only that the control flow must be structured for
> shaders.
>

That's exactly the problem.  It says how merge instructions work and how
they have to be nested but never that or where you have to use them. :-(
This is a spec bug.  The closest I can find is this line from the
structured control flow section: "These explicitly declare a header block

before the control flow diverges and a merge block

where control flow subsequently converges."  If you read that as "you must
declare divergence" then it would imply that every OpBranchConditional must
be preceded by an OpSelectionMerge.  If we don't require this, there are
lots of weird cases where you can get into diamond patters and other things
that aren't trivially structurizable.

--Jason


> In section 2.11 ("Structured Control Flow"), about structured control-flow
> constructs:
>
>
> - A structured control-flow construct is then defined as one of:
>   - a selection construct: the set of blocks dominated by a selection
> header,
> minus the set of blocks dominated by the header’s merge block
>   - [...]
>
> - The above structured control-flow constructs must satisfy the following
> rules:
>   - [...]
>   - the only blocks in a construct that can branch outside the construct
> are
> - a block branching to the construct’s merge block
> - a block branching from one case construct to another, for the same
> OpSwitch
> - a back-edge block
> - a continue block for the innermost loop it is nested inside of
> - a break block for the innermost loop it is nested inside of
> - a return block
>
>
> Our selection construct, which contains the two nested conditional
> branches,
> satisfies the rules, as both conditionals branches to the construct's merge
> block.
>
>
> J.A.
>
>
>
>
>
>
> >
>
>
> > --Jason
> >
> >
> > On March 6, 2019 05:25:26 "Juan A. Suarez Romero" 
> wrote:
> >
> > > This fixes the case when the SPIR-V code has two nested conditional
> > > branches, but only one selection merge:
> > >
> > >
> > > [...]
> > > %1 = OpLabel
> > > OpSelectionMerge %2 None
> > > OpBranchConditional %3 %4 %2
> > > %4 = OpLabel
> > > OpBranchConditional %3 %5 %2
> > > %5 = OpLabel
> > > OpBranch %2
> > > %2 = OpLabel
> > > [...]
> > >
> > >
> > > In the second OpBranchConditional, as the else-part is the end
> > > block (started in the first OpBranchConditional) we can just follow the
> > > then-part.
> > >
> > >
> > > This fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle
> > >
> > >
> > > CC: Jason Ekstrand 
> > > ---
> > > src/compiler/spirv/vtn_cfg.c | 11 ++-
> > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > >
> > > diff --git a/src/compiler/spirv/vtn_cfg.c
> b/src/compiler/spirv/vtn_cfg.c
> > > index 7868eeb60bc..f749118efbe 100644
> > > --- a/src/compiler/spirv/vtn_cfg.c
> > > +++ b/src/compiler/spirv/vtn_cfg.c
> > > @@ -605,7 +605,16 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct
> > > list_head *cf_list,
> > > }
> > >  } else if (if_stmt->then_type == vtn_branch_type_none &&
> > > if_stmt->else_type == vtn_branch_type_none) {
> > > -/* Neither side of the if is something we can
> short-circuit. */
> > > +/* Neither side of the if is something we can
> short-circuit,
> > > + * unless one of the blocks is the end block. */
> > > +if (then_block == end) {
> > > +   block = else_block;
> > > +   continue;
> > > +} else if (else_block == end) {
> > > +   block = then_block;
> > > +   continue;
> > > +}
> > > +
> > > vtn_assert((*block->merge & SpvOpCodeMask) ==
> SpvOpSelectionMerge);
> > > struct vtn_block *merge_block =
> > >vtn_value(b, block->merge[1],
> vtn_value_type_block)->block;
> > > --
> > > 2.20.1
> >
> >
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] docs: document Meson -Dc_args and -Dcpp_args

2019-03-08 Thread Brian Paul
---
 docs/meson.html | 13 +
 1 file changed, 13 insertions(+)

diff --git a/docs/meson.html b/docs/meson.html
index 7ffef81..43090aa 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -274,6 +274,19 @@ on the system. This environment variable is used to 
control the search path for
 PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig will search for package
 metadata in /usr/X11R6 before the standard directories.
 
+
+
+Extra Compiler Flags
+
+
+If you need to pass additional flags to the C/C++ compiler, one can use
+the -Dc_args or -Dcpp_args options.  For example:
+
+
+meson builddir/ -Dc_args=-fmax-errors=10 -Dcpp_args=-DMAGIC=123
+
+
+
 
 
 
-- 
1.8.5.6

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

[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #9 from fin4...@hotmail.com ---
The Rise of the Tomb Raider game works fine with my
System:
  Host: ryzenpc Kernel: 5.0.0 x86_64 bits: 64 Desktop: Xfce 4.13.2 
  Distro: Debian GNU/Linux buster/sid 
Machine:
  Type: Desktop Mobo: ASUSTeK model: PRIME B350M-K v: Rev X.0x 
  serial:  UEFI [Legacy]: American Megatrends v: 4207 
  date: 12/07/2018 
CPU:
  6-Core: AMD Ryzen 5 1600 type: MT MCP speed: 2967 MHz 
Graphics:
  Device-1: AMD Ellesmere [Radeon RX 470/480] driver: amdgpu v: kernel 
  Display: x11 server: X.Org 1.20.4 driver: amdgpu 
  resolution: 3840x2160~60Hz 
  OpenGL: 
  renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 5.0.0 LLVM 9.0.0) 
  v: 4.5 Mesa 19.1.0-devel - padoka PPA

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

Re: [Mesa-dev] [PATCH] docs: document Meson -Dc_args and -Dcpp_args

2019-03-08 Thread Eric Engestrom
On Friday, 2019-03-08 15:54:37 -0700, Brian Paul wrote:
> ---
>  docs/meson.html | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/docs/meson.html b/docs/meson.html
> index 7ffef81..43090aa 100644
> --- a/docs/meson.html
> +++ b/docs/meson.html
> @@ -274,6 +274,19 @@ on the system. This environment variable is used to 
> control the search path for
>  PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig will search for package
>  metadata in /usr/X11R6 before the standard directories.
>  
> +
> +
> +Extra Compiler Flags
> +
> +
> +If you need to pass additional flags to the C/C++ compiler, one can use
> +the -Dc_args or -Dcpp_args options.  For example:
> +
> +
> +meson builddir/ -Dc_args=-fmax-errors=10 -Dcpp_args=-DMAGIC=123
> +
> +

This is already explained in the "Environment Variables" section on this
page. Perhaps it should be rephrased instead, if it didn't have the
information you were looking for, or wasn't clear?
("env var" is an accident of how autotools used to do it, and might not
be the best title for it in meson, for instance)

> +
>  
>  
>  
> -- 
> 1.8.5.6
> 
> ___
> 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 1/2] drisw: fix incomplete type compilation failure

2019-03-08 Thread Brian Paul
Fixes:
../src/gallium/winsys/sw/dri/dri_sw_winsys.c: In function 
‘dri_sw_displaytarget_display’:
../src/gallium/winsys/sw/dri/dri_sw_winsys.c:255:39: error: dereferencing 
pointer to incomplete type ‘struct pipe_box’
   offset = dri_sw_dt->stride * box->y;
   ^
---
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c 
b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
index c0200f9..3273813 100644
--- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
@@ -35,6 +35,7 @@
 
 #include "pipe/p_compiler.h"
 #include "pipe/p_format.h"
+#include "pipe/p_state.h"
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 #include "util/u_math.h"
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 2/2] gallium/winsys/kms: fix incomplete type compilation failure

2019-03-08 Thread Brian Paul
Fixes:
../src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c: In function 
‘kms_sw_displaytarget_from_handle’:
../src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c:402:60: error: 
dereferencing pointer to incomplete type ‘const struct pipe_resource’
   templ->format,
^
---
 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index 9564d94..6401f55 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -43,6 +43,7 @@
 
 #include "pipe/p_compiler.h"
 #include "pipe/p_format.h"
+#include "pipe/p_state.h"
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 #include "util/u_math.h"
-- 
1.8.5.6

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

[Mesa-dev] [Bug 109945] pan_assemble.c:51:46: error: passing argument 2 of ‘tgsi_to_nir’ from incompatible pointer type [-Werror=incompatible-pointer-types]

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109945

Bug ID: 109945
   Summary: pan_assemble.c:51:46: error: passing argument 2 of
‘tgsi_to_nir’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org

../src/gallium/drivers/panfrost/pan_assemble.c: In function
‘panfrost_shader_compile’:
../src/gallium/drivers/panfrost/pan_assemble.c:51:46: error: passing argument 2
of ‘tgsi_to_nir’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
 s = tgsi_to_nir(cso->tokens, >base.screen);
  ^
In file included from ../src/gallium/drivers/panfrost/pan_assemble.c:31:
../src/gallium/auxiliary/nir/tgsi_to_nir.h:28:1: note: expected ‘struct
pipe_screen *’ but argument is of type ‘struct pipe_screen **’
 tgsi_to_nir(const void *tgsi_tokens,
 ^~~

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

[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

Bug ID: 109939
   Summary: After upgrade mesa to 19.0.0 stop working the game
Rise of the Tomb Raider
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 143585
  --> https://bugs.freedesktop.org/attachment.cgi?id=143585=edit
htop screenshot

After game menu when I select continue.
The splash screen show infinitely loading.
In task manager `CBackgroundWork` threads eat all CPU cores.

-- 
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 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 143586
  --> https://bugs.freedesktop.org/attachment.cgi?id=143586=edit
for i in {1..10}; do gdb --batch --ex "t a a bt" -pid=`pidof
RiseOfTheTombRaider` &>bt$i.txt; sleep 0.1; done

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

[Mesa-dev] [PATCH v2 2/8] panfrost: Detect GPU version at runtime

2019-03-08 Thread Tomeu Vizoso
Also use the raw GPU ID value to decide whether to use SFD or MFD.

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pan_context.c | 66 ++
 src/gallium/drivers/panfrost/pan_context.h | 10 
 src/gallium/drivers/panfrost/pan_screen.h  |  1 +
 3 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 4c41969fd051..2287dc6e3b54 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -57,26 +57,13 @@ extern const char *pan_counters_base;
 
 /* TODO: Sample size, etc */
 
-/* True for t6XX, false for t8xx. TODO: Run-time settable for automatic
- * hardware configuration. */
-
-static bool is_t6xx = false;
-
-/* If set, we'll require the use of single render-target framebuffer
- * descriptors (SFBD), for older hardware -- specifically, fragment_shader_core.unknown2_3, MALI_HAS_MSAA, enabled);
 SET_BIT(ctx->fragment_shader_core.unknown2_4, MALI_NO_MSAA, !enabled);
 
-if (require_sfbd) {
+if (ctx->require_sfbd) {
 SET_BIT(ctx->fragment_sfbd.format, MALI_FRAMEBUFFER_MSAA_A | 
MALI_FRAMEBUFFER_MSAA_B, enabled);
 } else {
 SET_BIT(ctx->fragment_rts[0].format.flags, 
MALI_MFBD_FORMAT_MSAA, enabled);
@@ -97,7 +84,7 @@ panfrost_set_framebuffer_msaa(struct panfrost_context *ctx, 
bool enabled)
 static void
 panfrost_enable_afbc(struct panfrost_context *ctx, struct panfrost_resource 
*rsrc, bool ds)
 {
-if (require_sfbd) {
+if (ctx->require_sfbd) {
 printf("AFBC not supported yet on SFBD\n");
 assert(0);
 }
@@ -156,7 +143,7 @@ panfrost_set_fragment_afbc(struct panfrost_context *ctx)
 if (!rsrc->bo->has_afbc)
 continue;
 
-if (require_sfbd) {
+if (ctx->require_sfbd) {
 fprintf(stderr, "Color AFBC not supported on SFBD\n");
 assert(0);
 }
@@ -180,7 +167,7 @@ panfrost_set_fragment_afbc(struct panfrost_context *ctx)
 struct panfrost_resource *rsrc = (struct panfrost_resource *) 
ctx->pipe_framebuffer.zsbuf->texture;
 
 if (rsrc->bo->has_afbc) {
-if (require_sfbd) {
+if (ctx->require_sfbd) {
 fprintf(stderr, "Depth AFBC not supported on 
SFBD\n");
 assert(0);
 }
@@ -204,7 +191,7 @@ panfrost_set_fragment_afbc(struct panfrost_context *ctx)
 /* For the special case of a depth-only FBO, we need to attach a dummy 
render target */
 
 if (ctx->pipe_framebuffer.nr_cbufs == 0) {
-if (require_sfbd) {
+if (ctx->require_sfbd) {
 fprintf(stderr, "Depth-only FBO not supported on 
SFBD\n");
 assert(0);
 }
@@ -364,7 +351,7 @@ panfrost_new_frag_framebuffer(struct panfrost_context *ctx)
 stride = -stride;
 }
 
-if (require_sfbd) {
+if (ctx->require_sfbd) {
 struct mali_single_framebuffer fb = panfrost_emit_sfbd(ctx);
 
 fb.framebuffer = framebuffer;
@@ -562,7 +549,7 @@ panfrost_attach_vt_sfbd(struct panfrost_context *ctx)
 static void
 panfrost_attach_vt_framebuffer(struct panfrost_context *ctx)
 {
-mali_ptr framebuffer = require_sfbd ?
+mali_ptr framebuffer = ctx->require_sfbd ?
 panfrost_attach_vt_sfbd(ctx) :
 panfrost_attach_vt_mfbd(ctx);
 
@@ -616,7 +603,7 @@ panfrost_invalidate_frame(struct panfrost_context *ctx)
 if ((++ctx->cmdstream_i) == (sizeof(ctx->transient_pools) / 
sizeof(ctx->transient_pools[0])))
 ctx->cmdstream_i = 0;
 
-if (require_sfbd)
+if (ctx->require_sfbd)
 ctx->vt_framebuffer_sfbd = panfrost_emit_sfbd(ctx);
 else
 ctx->vt_framebuffer_mfbd = panfrost_emit_mfbd(ctx);
@@ -655,7 +642,7 @@ panfrost_emit_vertex_payload(struct panfrost_context *ctx)
 .workgroups_x_shift_2 = 0x2,
 .workgroups_x_shift_3 = 0x5,
 },
-   .gl_enables = 0x4 | (is_t6xx ? 0 : 0x2),
+   .gl_enables = 0x4 | (ctx->is_t6xx ? 0 : 0x2),
 };
 
 memcpy(>payload_vertex, , sizeof(payload));
@@ -847,7 +834,7 @@ panfrost_default_shader_backend(struct panfrost_context 
*ctx)
 .unknown2_4 = MALI_NO_MSAA | 0x4e0,
 };
 
-   if (is_t6xx) {
+   if (ctx->is_t6xx) {
 shader.unknown2_4 |= 0x10;
}
 
@@ -957,7 +944,7 @@ panfrost_fragment_job(struct panfrost_context *ctx)
 /* Actualize the clear late; TODO: Fix order dependency between clear
  * and afbc */
 
-if (require_sfbd) {
+ 

[Mesa-dev] [PATCH v2 6/8] panfrost: Free context BOs

2019-03-08 Thread Tomeu Vizoso
Signed-off-by: Tomeu Vizoso 
Reviewed-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index fdb3aa7ccdc2..3c8a483b8f58 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2586,9 +2586,16 @@ static void
 panfrost_destroy(struct pipe_context *pipe)
 {
 struct panfrost_context *panfrost = pan_context(pipe);
+struct panfrost_screen *screen = pan_screen(pipe->screen);
 
 if (panfrost->blitter)
 util_blitter_destroy(panfrost->blitter);
+
+screen->driver->free_slab(screen, >scratchpad);
+screen->driver->free_slab(screen, >varying_mem);
+screen->driver->free_slab(screen, >shaders);
+screen->driver->free_slab(screen, >tiler_heap);
+screen->driver->free_slab(screen, >misc_0);
 }
 
 static struct pipe_query *
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 8/8] panfrost: Add backend targeting the DRM driver

2019-03-08 Thread Tomeu Vizoso
This backend interacts with the new DRM driver for Midgard GPUs which is
currently in development.

When using this backend, Panfrost has roughly on-par functionality as
when using the non-DRM driver from Arm.

Signed-off-by: Tomeu Vizoso 

---

v2: - Adapt to changes in the UAPI, mostly one atom per job.
- Mmap imported buffers, needed for kmscube -M rgba
---
 include/drm-uapi/panfrost_drm.h| 141 ++
 src/gallium/drivers/panfrost/pan_drm.c | 363 +
 2 files changed, 504 insertions(+)
 create mode 100644 include/drm-uapi/panfrost_drm.h

diff --git a/include/drm-uapi/panfrost_drm.h b/include/drm-uapi/panfrost_drm.h
new file mode 100644
index ..7618f14f9e26
--- /dev/null
+++ b/include/drm-uapi/panfrost_drm.h
@@ -0,0 +1,141 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2014-2018 Broadcom
+ * Copyright © 2019 Collabora ltd.
+ */
+#ifndef _PANFROST_DRM_H_
+#define _PANFROST_DRM_H_
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+#define DRM_PANFROST_SUBMIT0x00
+#define DRM_PANFROST_WAIT_BO   0x01
+#define DRM_PANFROST_CREATE_BO 0x02
+#define DRM_PANFROST_MMAP_BO   0x03
+#define DRM_PANFROST_GET_PARAM 0x04
+#define DRM_PANFROST_GET_BO_OFFSET 0x05
+
+#define DRM_IOCTL_PANFROST_SUBMIT  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_PANFROST_SUBMIT, struct drm_panfrost_submit)
+#define DRM_IOCTL_PANFROST_WAIT_BO DRM_IOWR(DRM_COMMAND_BASE + 
DRM_PANFROST_WAIT_BO, struct drm_panfrost_wait_bo)
+#define DRM_IOCTL_PANFROST_CREATE_BO   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_PANFROST_CREATE_BO, struct drm_panfrost_create_bo)
+#define DRM_IOCTL_PANFROST_MMAP_BO DRM_IOWR(DRM_COMMAND_BASE + 
DRM_PANFROST_MMAP_BO, struct drm_panfrost_mmap_bo)
+#define DRM_IOCTL_PANFROST_GET_PARAM   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_PANFROST_GET_PARAM, struct drm_panfrost_get_param)
+#define DRM_IOCTL_PANFROST_GET_BO_OFFSET   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_PANFROST_GET_BO_OFFSET, struct drm_panfrost_get_bo_offset)
+
+#define PANFROST_JD_REQ_FS (1 << 0)
+
+/**
+ * struct drm_panfrost_submit - ioctl argument for submitting commands to the 
3D
+ * engine.
+ *
+ * This asks the kernel to have the GPU execute a render command list.
+ */
+struct drm_panfrost_submit {
+
+   /** Address to GPU mapping of job descriptor */
+   __u64 jc;
+
+   /** An optional array of sync objects to wait on before starting this 
job. */
+   __u64 in_syncs;
+
+   /** Number of sync objects to wait on before starting this job. */
+   __u32 in_sync_count;
+
+   /** An optional sync object to place the completion fence in. */
+   __u32 out_sync;
+
+   /** Pointer to a u32 array of the BOs that are referenced by the job. */
+   __u64 bo_handles;
+
+   /** Number of BO handles passed in (size is that times 4). */
+   __u32 bo_handle_count;
+
+   /** A combination of PANFROST_JD_REQ_* */
+   __u32 requirements;
+};
+
+/**
+ * struct drm_panfrost_wait_bo - ioctl argument for waiting for
+ * completion of the last DRM_PANFROST_SUBMIT_CL on a BO.
+ *
+ * This is useful for cases where multiple processes might be
+ * rendering to a BO and you want to wait for all rendering to be
+ * completed.
+ */
+struct drm_panfrost_wait_bo {
+   __u32 handle;
+   __u32 pad;
+   __s64 timeout_ns;   /* absolute */
+};
+
+/**
+ * struct drm_panfrost_create_bo - ioctl argument for creating Panfrost BOs.
+ *
+ * There are currently no values for the flags argument, but it may be
+ * used in a future extension.
+ */
+struct drm_panfrost_create_bo {
+   __u32 size;
+   __u32 flags;
+   /** Returned GEM handle for the BO. */
+   __u32 handle;
+   /**
+* Returned offset for the BO in the GPU address space.  This offset
+* is private to the DRM fd and is valid for the lifetime of the GEM
+* handle.
+*
+* This offset value will always be nonzero, since various HW
+* units treat 0 specially.
+*/
+   __u64 offset;
+};
+
+/**
+ * struct drm_panfrost_mmap_bo - ioctl argument for mapping Panfrost BOs.
+ *
+ * This doesn't actually perform an mmap.  Instead, it returns the
+ * offset you need to use in an mmap on the DRM device node.  This
+ * means that tools like valgrind end up knowing about the mapped
+ * memory.
+ *
+ * There are currently no values for the flags argument, but it may be
+ * used in a future extension.
+ */
+struct drm_panfrost_mmap_bo {
+   /** Handle for the object being mapped. */
+   __u32 handle;
+   __u32 flags;
+   /** offset into the drm node to use for subsequent mmap call. */
+   __u64 offset;
+};
+
+enum drm_panfrost_param {
+   DRM_PANFROST_PARAM_GPU_ID,
+};
+
+struct drm_panfrost_get_param {
+   __u32 param;
+   __u32 pad;
+   __u64 value;
+};
+
+/**
+ * Returns the 

[Mesa-dev] [PATCH v2 5/8] panfrost: Store GEM handle of AFBC BOs

2019-03-08 Thread Tomeu Vizoso
Signed-off-by: Tomeu Vizoso 
Reviewed-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 51c2ded48fe4..fdb3aa7ccdc2 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -107,6 +107,7 @@ panfrost_enable_afbc(struct panfrost_context *ctx, struct 
panfrost_resource *rsr
true, 0, 0, 0);
 
 rsrc->bo->has_afbc = true;
+rsrc->bo->gem_handle = rsrc->bo->afbc_slab.gem_handle;
 
 /* Compressed textured reads use a tagged pointer to the metadata */
 
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 1/8] panfrost: Add gem_handle to panfrost_memory and panfrost_bo

2019-03-08 Thread Tomeu Vizoso
It will be used by the DRM backend to store GEM handles from the kernel.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_allocate.h | 1 +
 src/gallium/drivers/panfrost/pan_resource.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_allocate.h 
b/src/gallium/drivers/panfrost/pan_allocate.h
index 2084a3395521..5bbb1e4b078d 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.h
+++ b/src/gallium/drivers/panfrost/pan_allocate.h
@@ -67,6 +67,7 @@ struct panfrost_memory {
 mali_ptr gpu;
 int stack_bottom;
 size_t size;
+int gem_handle;
 };
 
 /* Slab entry sizes range from 2^min to 2^max. In this case, we range from 1k
diff --git a/src/gallium/drivers/panfrost/pan_resource.h 
b/src/gallium/drivers/panfrost/pan_resource.h
index b0b5cc15a0c5..633f185ab5b9 100644
--- a/src/gallium/drivers/panfrost/pan_resource.h
+++ b/src/gallium/drivers/panfrost/pan_resource.h
@@ -69,6 +69,8 @@ struct panfrost_bo {
 bool has_checksum;
 struct panfrost_memory checksum_slab;
 int checksum_stride;
+
+int gem_handle;
 };
 
 struct panfrost_resource {
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 3/8] panfrost: Remove use of duplicate function panfrost_screen

2019-03-08 Thread Tomeu Vizoso
Signed-off-by: Tomeu Vizoso 
Reviewed-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_allocate.c  | 4 ++--
 src/gallium/drivers/panfrost/pan_resource.c  | 2 +-
 src/gallium/drivers/panfrost/pan_screen.h| 6 --
 src/gallium/drivers/panfrost/pan_wallpaper.c | 2 +-
 4 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_allocate.c 
b/src/gallium/drivers/panfrost/pan_allocate.c
index 3732d253978a..91ace74d0e43 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.c
+++ b/src/gallium/drivers/panfrost/pan_allocate.c
@@ -41,7 +41,7 @@ panfrost_allocate_chunk(struct panfrost_context *ctx, size_t 
size, unsigned heap
 size = ALIGN(size, ALIGNMENT);
 
 struct pipe_context *gallium = (struct pipe_context *) ctx;
-struct panfrost_screen *screen = panfrost_screen(gallium->screen);
+struct panfrost_screen *screen = pan_screen(gallium->screen);
 
 struct pb_slab_entry *entry = pb_slab_alloc(>slabs, size, 
heap_id);
 struct panfrost_memory_entry *p_entry = (struct panfrost_memory_entry 
*) entry;
@@ -81,7 +81,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx, 
size_t sz)
 if (pool->entry_index >= pool->entry_count) {
 /* Don't overflow the pool -- allocate a new one */
 struct pipe_context *gallium = (struct pipe_context *) 
ctx;
-struct panfrost_screen *screen = 
panfrost_screen(gallium->screen);
+struct panfrost_screen *screen = 
pan_screen(gallium->screen);
 struct pb_slab_entry *entry = 
pb_slab_alloc(>slabs, pool->entry_size, HEAP_TRANSIENT);
 
 pool->entry_count++;
diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index f26f33db96b6..a64814902573 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -322,7 +322,7 @@ static void
 panfrost_resource_destroy(struct pipe_screen *screen,
   struct pipe_resource *pt)
 {
-struct panfrost_screen *pscreen = panfrost_screen(screen);
+struct panfrost_screen *pscreen = pan_screen(screen);
 struct panfrost_resource *rsrc = (struct panfrost_resource *) pt;
 
if (rsrc->scanout)
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 002c430cacbc..576dca11dc7b 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -86,10 +86,4 @@ struct panfrost_screen {
int last_fragment_flushed;
 };
 
-static inline struct panfrost_screen *
-panfrost_screen( struct pipe_screen *pipe )
-{
-return (struct panfrost_screen *)pipe;
-}
-
 #endif /* PAN_SCREEN_H */
diff --git a/src/gallium/drivers/panfrost/pan_wallpaper.c 
b/src/gallium/drivers/panfrost/pan_wallpaper.c
index 735524a49c9c..48418012fe84 100644
--- a/src/gallium/drivers/panfrost/pan_wallpaper.c
+++ b/src/gallium/drivers/panfrost/pan_wallpaper.c
@@ -181,7 +181,7 @@ panfrost_draw_wallpaper(struct pipe_context *pipe)
 .normalized_coords = 1
 };
 
-struct pipe_resource *rsrc = 
panfrost_screen(pipe->screen)->display_target;
+struct pipe_resource *rsrc = pan_screen(pipe->screen)->display_target;
 struct pipe_sampler_state *sampler_state = 
pipe->create_sampler_state(pipe, );
 struct pipe_sampler_view *sampler_view = 
pipe->create_sampler_view(pipe, rsrc, );
 
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 0/8] panfrost: Add DRM backend

2019-03-08 Thread Tomeu Vizoso
The corresponding change to the kernel can be seen here:

https://gitlab.freedesktop.org/tomeu/linux/commits/panfrost-5.0

Thanks,

Tomeu


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

[Mesa-dev] [PATCH v2 7/8] panfrost: Fix BO import and export

2019-03-08 Thread Tomeu Vizoso
Implement resource_get_handle for non-scanout cases.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_resource.c | 37 +++--
 src/gallium/drivers/panfrost/pan_screen.h   |  1 +
 2 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index a64814902573..abef927ada55 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -68,6 +68,12 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
 
rsc->bo = screen->driver->import_bo(screen, whandle);
 
+   if (screen->ro) {
+   rsc->scanout =
+   renderonly_create_gpu_import_for_resource(prsc, 
screen->ro, NULL);
+   /* failure is expected in some cases.. */
+   }
+
 return prsc;
 }
 
@@ -87,17 +93,15 @@ panfrost_resource_get_handle(struct pipe_screen *pscreen,
 handle->stride = stride;
 handle->modifier = DRM_FORMAT_MOD_INVALID;
 
-if (handle->type == WINSYS_HANDLE_TYPE_SHARED) {
-printf("Missed shared handle\n");
-return FALSE;
-} else if (handle->type == WINSYS_HANDLE_TYPE_KMS) {
-if (renderonly_get_handle(scanout, handle)) {
-return TRUE;
-} else {
-printf("Missed nonrenderonly KMS handle for resource 
%p with scanout %p\n", pt, scanout);
-return FALSE;
-}
-} else if (handle->type == WINSYS_HANDLE_TYPE_FD) {
+   if (handle->type == WINSYS_HANDLE_TYPE_SHARED) {
+   return FALSE;
+   } else if (handle->type == WINSYS_HANDLE_TYPE_KMS) {
+   if (renderonly_get_handle(scanout, handle))
+   return TRUE;
+
+   handle->handle = rsrc->bo->gem_handle;
+   return TRUE;
+   } else if (handle->type == WINSYS_HANDLE_TYPE_FD) {
 if (scanout) {
 struct drm_prime_handle args = {
 .handle = scanout->handle,
@@ -111,14 +115,11 @@ panfrost_resource_get_handle(struct pipe_screen *pscreen,
 handle->handle = args.fd;
 
 return TRUE;
-} else {
-printf("Missed nonscanout FD handle\n");
-assert(0);
-return FALSE;
-}
-}
+} else
+   return screen->driver->export_bo(screen, 
rsrc->bo->gem_handle, handle);
+   }
 
-return FALSE;
+   return FALSE;
 }
 
 static void
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index f109df857c7b..882611e93e3e 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -49,6 +49,7 @@ struct panfrost_screen;
 
 struct panfrost_driver {
struct panfrost_bo * (*import_bo) (struct panfrost_screen *screen, 
struct winsys_handle *whandle);
+   int (*export_bo) (struct panfrost_screen *screen, int gem_handle, 
struct winsys_handle *whandle);
 
int (*submit_vs_fs_job) (struct panfrost_context *ctx, bool has_draws, 
bool is_scanout);
void (*force_flush_fragment) (struct panfrost_context *ctx,
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 4/8] panfrost: Pass the fence down when flushing

2019-03-08 Thread Tomeu Vizoso
Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pan_context.c | 11 +++
 src/gallium/drivers/panfrost/pan_context.h |  7 +++
 src/gallium/drivers/panfrost/pan_screen.c  | 11 ++-
 src/gallium/drivers/panfrost/pan_screen.h  | 11 ++-
 4 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 2287dc6e3b54..51c2ded48fe4 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1521,7 +1521,8 @@ panfrost_link_jobs(struct panfrost_context *ctx)
 /* The entire frame is in memory -- send it off to the kernel! */
 
 static void
-panfrost_submit_frame(struct panfrost_context *ctx, bool flush_immediate)
+panfrost_submit_frame(struct panfrost_context *ctx, bool flush_immediate,
+ struct pipe_fence_handle **fence)
 {
 struct pipe_context *gallium = (struct pipe_context *) ctx;
 struct panfrost_screen *screen = pan_screen(gallium->screen);
@@ -1548,14 +1549,14 @@ panfrost_submit_frame(struct panfrost_context *ctx, 
bool flush_immediate)
 /* If visual, we can stall a frame */
 
 if (!flush_immediate)
-screen->driver->force_flush_fragment(ctx);
+screen->driver->force_flush_fragment(ctx, fence);
 
 screen->last_fragment_id = fragment_id;
 screen->last_fragment_flushed = false;
 
 /* If readback, flush now (hurts the pipelined performance) */
 if (flush_immediate)
-screen->driver->force_flush_fragment(ctx);
+screen->driver->force_flush_fragment(ctx, fence);
 
 if (screen->driver->dump_counters && pan_counters_base) {
 screen->driver->dump_counters(screen);
@@ -1586,7 +1587,7 @@ panfrost_flush(
 bool flush_immediate = flags & PIPE_FLUSH_END_OF_FRAME;
 
 /* Submit the frame itself */
-panfrost_submit_frame(ctx, flush_immediate);
+panfrost_submit_frame(ctx, flush_immediate, fence);
 
 /* Prepare for the next frame */
 panfrost_invalidate_frame(ctx);
@@ -2786,6 +2787,8 @@ panfrost_create_context(struct pipe_screen *screen, void 
*priv, unsigned flags)
 
 panfrost_resource_context_init(gallium);
 
+pscreen->driver->init_context(ctx);
+
 panfrost_setup_hardware(ctx);
 
 /* XXX: leaks */
diff --git a/src/gallium/drivers/panfrost/pan_context.h 
b/src/gallium/drivers/panfrost/pan_context.h
index e3de1b1e792c..091d9988698a 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -74,6 +74,11 @@ struct panfrost_query {
 struct panfrost_transfer transfer;
 };
 
+struct panfrost_fence {
+struct pipe_reference reference;
+int fd;
+};
+
 #define PANFROST_MAX_TRANSIENT_ENTRIES 64
 
 struct panfrost_transient_pool {
@@ -218,6 +223,8 @@ struct panfrost_context {
  * for SFBD, and in theory we could flip between them on a per-RT 
basis, but
  * there's no real advantage to doing so */
 bool require_sfbd;
+
+   uint32_t out_sync;
 };
 
 /* Corresponds to the CSO */
diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index f77bb11ffda4..3d13c3e924d2 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -503,21 +503,22 @@ panfrost_get_timestamp(struct pipe_screen *_screen)
 }
 
 static void
-panfrost_fence_reference(struct pipe_screen *screen,
+panfrost_fence_reference(struct pipe_screen *pscreen,
  struct pipe_fence_handle **ptr,
  struct pipe_fence_handle *fence)
 {
-*ptr = fence;
+struct panfrost_screen *screen = pan_screen(pscreen);
+screen->driver->fence_reference(pscreen, ptr, fence);
 }
 
 static boolean
-panfrost_fence_finish(struct pipe_screen *screen,
+panfrost_fence_finish(struct pipe_screen *pscreen,
   struct pipe_context *ctx,
   struct pipe_fence_handle *fence,
   uint64_t timeout)
 {
-assert(fence);
-return TRUE;
+struct panfrost_screen *screen = pan_screen(pscreen);
+return screen->driver->fence_finish(pscreen, ctx, fence, timeout);
 }
 
 static const void *
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 576dca11dc7b..f109df857c7b 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -51,7 +51,8 @@ struct panfrost_driver {
struct panfrost_bo * (*import_bo) (struct panfrost_screen *screen, 
struct winsys_handle *whandle);
 
int (*submit_vs_fs_job) (struct panfrost_context *ctx, bool has_draws, 
bool is_scanout);
-   void (*force_flush_fragment) (struct panfrost_context *ctx);
+   void 

[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #2 from Timothy Arceri  ---
Mesa 19.0 has not been released yet. You need to provide more detail on what
exactly you are testing with.

-- 
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 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
I am tested versions rc1 - rc6

-- 
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 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109929

--- Comment #1 from Timur Kristóf  ---
This is my mistake, forgot to add the autotools equivalent when I wrote the
meson part:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225/diffs?commit_id=9a834447d652ea50864bb6c32f4ff99ac10d39bf#6749efedc0ac7001e9a35e66fa0e8dfb6e4ff8d3_537_537

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

[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #4 from mikhail.v.gavri...@gmail.com ---
PS Yet another native Linux Vulkan game "F1 2017" that's made by Feral is
works, but first time the game starts too long around of 10 minutes, but it not
consuming all CPU cores.

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

[Mesa-dev] [Bug 109920] "NIR validation failed in internal shader" abort with all Vulkan test-cases

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109920

Samuel Pitoiset  changed:

   What|Removed |Added

 Status|VERIFIED|RESOLVED

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

[Mesa-dev] [Bug 109927] Xorg segfault when a web browser is opened

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109927

--- Comment #5 from Michel Dänzer  ---
Weirdly, the backtrace of the crash doesn't look directly related to Mesa.

Maybe there's memory corruption, in which case running Xorg in valgrind might
give a clue. (Make sure debugging symbols are available for /usr/lib/xorg/Xorg
and radeonsi_dri.so at least)

Other than that, bisecting Mesa is probably the best way to make progress.

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

Re: [Mesa-dev] [PATCH v4 34/40] intel/compiler: validate region restrictions for half-float conversions

2019-03-08 Thread Iago Toral
On Wed, 2019-03-06 at 09:21 +0100, Iago Toral wrote:
> On Tue, 2019-03-05 at 07:35 +0100, Iago Toral wrote:
> > On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wrote:
> > > Iago Toral  writes:
> > > 
> > > > On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
> > > > > Iago Toral  writes:
> > > > > 
> > > > > > On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
> > > > > > > Iago Toral  writes:
> > > > > > > 
> > > > > > > > On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez
> > > > > > > > wrote:
> > > > > > > > > Iago Toral  writes:
> > > > > > > > > 
> > > > > > > > > > On Tue, 2019-02-26 at 14:54 -0800, Francisco Jerez
> > > > > > > > > > wrote:
> > > > > > > > > > > Iago Toral Quiroga  writes:
> > > > > > > > > > > 
> > > > > > > > > > > > ---
> > > > > > > > > > > >  src/intel/compiler/brw_eu_validate.c|  64
> > > > > > > > > > > > -
> > > > > > > > > > > >  src/intel/compiler/test_eu_validate.cpp | 122
> > > > > > > > > > > > 
> > > > > > > > > > > >  2 files changed, 185 insertions(+), 1
> > > > > > > > > > > > deletion(-
> > > > > > > > > > > > )
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > > > b/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > > > index 000a05cb6ac..203641fecb9 100644
> > > > > > > > > > > > --- a/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > > > +++ b/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > > > @@ -531,7 +531,69 @@
> > > > > > > > > > > > general_restrictions_based_on_operand_types(con
> > > > > > > > > > > > st
> > > > > > > > > > > > struct
> > > > > > > > > > > > gen_device_info *devinf
> > > > > > > > > > > > exec_type_size == 8 && dst_type_size ==
> > > > > > > > > > > > 4)
> > > > > > > > > > > >dst_type_size = 8;
> > > > > > > > > > > >  
> > > > > > > > > > > > -   if (exec_type_size > dst_type_size) {
> > > > > > > > > > > > +   /* From the BDW+ PRM:
> > > > > > > > > > > > +*
> > > > > > > > > > > > +*"There is no direct conversion from
> > > > > > > > > > > > HF
> > > > > > > > > > > > to
> > > > > > > > > > > > DF
> > > > > > > > > > > > or
> > > > > > > > > > > > DF to
> > > > > > > > > > > > HF.
> > > > > > > > > > > > +* There is no direct conversion from
> > > > > > > > > > > > HF
> > > > > > > > > > > > to
> > > > > > > > > > > > Q/UQ or
> > > > > > > > > > > > Q/UQ to
> > > > > > > > > > > > HF."
> > > > > > > > > > > > +*/
> > > > > > > > > > > > +   enum brw_reg_type src0_type =
> > > > > > > > > > > > brw_inst_src0_type(devinfo,
> > > > > > > > > > > > inst);
> > > > > > > > > > > > +   ERROR_IF(brw_inst_opcode(devinfo, inst) ==
> > > > > > > > > > > > BRW_OPCODE_MOV
> > > > > > > > > > > > &&
> > > > > > > > > > > 
> > > > > > > > > > > Why is only the MOV instruction handled here and
> > > > > > > > > > > below?  Aren't
> > > > > > > > > > > other
> > > > > > > > > > > instructions able to do implicit
> > > > > > > > > > > conversions?  Probably
> > > > > > > > > > > means
> > > > > > > > > > > you
> > > > > > > > > > > need
> > > > > > > > > > > to deal with two sources rather than one.
> > > > > > > > > > 
> > > > > > > > > > This comes from the programming notes of the MOV
> > > > > > > > > > instruction
> > > > > > > > > > (Volume
> > > > > > > > > > 2a, Command Reference - Instructions - MOV), so it
> > > > > > > > > > is
> > > > > > > > > > described
> > > > > > > > > > specifically for the MOV instruction. I should
> > > > > > > > > > probably
> > > > > > > > > > have
> > > > > > > > > > made
> > > > > > > > > > this
> > > > > > > > > > clear in the comment.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Maybe the one above is specified in the MOV page
> > > > > > > > > only,
> > > > > > > > > probably
> > > > > > > > > due
> > > > > > > > > to
> > > > > > > > > an oversight (If these restrictions were really
> > > > > > > > > specific
> > > > > > > > > to
> > > > > > > > > the
> > > > > > > > > MOV
> > > > > > > > > instruction, what would prevent you from implementing
> > > > > > > > > such
> > > > > > > > > conversions
> > > > > > > > > through a different instruction?  E.g. "ADD dst:df,
> > > > > > > > > src:hf,
> > > > > > > > > 0"
> > > > > > > > > which
> > > > > > > > > would be substantially more efficient than what
> > > > > > > > > you're
> > > > > > > > > doing
> > > > > > > > > in
> > > > > > > > > PATCH
> > > > > > > > > 02)
> > > > > > > > 
> > > > > > > > Instructions that take HF can only be strictly HF or
> > > > > > > > mix
> > > > > > > > F
> > > > > > > > and
> > > > > > > > HF
> > > > > > > > (mixed mode float), with MOV being the only exception.
> > > > > > > > That
> > > > > > > > means
> > > > > > > > that
> > > > > > > > any instruction like the one you use above are invalid.
> > > > > > > > Maybe
> > > > > > > > we
> > > > > > > > should
> > > > > > > > validate explicitly that 

Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly

2019-03-08 Thread Kenneth Graunke
On Friday, March 1, 2019 7:55:18 AM PST Christian Gmeiner wrote:
> Use u_transfer_helper_resource_create(..) instead which uses the
> resource_create(..) function specified in u_transfer_vtbl.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/auxiliary/util/u_transfer_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_transfer_helper.c 
> b/src/gallium/auxiliary/util/u_transfer_helper.c
> index 14c4d56392d..a5c3c026e71 100644
> --- a/src/gallium/auxiliary/util/u_transfer_helper.c
> +++ b/src/gallium/auxiliary/util/u_transfer_helper.c
> @@ -182,7 +182,7 @@ transfer_map_msaa(struct pipe_context *pctx,
>   .depth0 = 1,
>   .array_size = 1,
> };
> -   trans->ss = pscreen->resource_create(pscreen, );
> +   trans->ss = u_transfer_helper_resource_create(pscreen, );
> if (!trans->ss) {
>free(trans);
>return NULL;
> 

Reviewed-by: Kenneth Graunke 


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

[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #5 from Timur Kristóf  ---
Mikhail, are you sure this is a mesa issue? It could be a bug in the game. On
my machine (RX 570, with mesa 18.3 RADV) Rise of the Tomb Raider can spend a
lot of time (sometimes 10-15 minutes) on the loading screen, but it loads
eventually.

Could we ask someone from Feral to look into this?

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

[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

--- Comment #6 from Alex Smith  ---
The loading screen will block for a while on pipeline creation for the level
that you are loading (that's what the CBackgroundWork threads are doing). If
you see much faster loading times on an older version, that sounds like there
has been some regression in pipeline creation times.

-- 
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 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109929

--- Comment #2 from Timur Kristóf  ---
Vinson, can you give me some more details on how to reproduce this, such as
what commands you used to configure and build mesa?

I tried the following:

./autogen.sh --enable-autotools --enable-debug --enable-gallium-osmesa
--disable-gles1 --enable-gles2 --disable-xvmc
--with-platforms=x11,drm,surfaceless,wayland --enable-shared-glapi --enable-gbm
--enable-llvm --enable-llvm-shared-libs --with-dri-drivers=
--with-gallium-drivers=radeonsi,swrast --with-vulkan-drivers= --enable-nine
make -j8

And it builds without issues.

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

[Mesa-dev] [Bug 109401] [DXVK] Project Cars rendering problems

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109401

--- Comment #5 from Samuel Pitoiset  ---
Does RADV_DEBUG=zerovram help?

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

Re: [Mesa-dev] [PATCH] nir/serialize: Make preserving names optional

2019-03-08 Thread apinheiro

Reviewed-by: Alejandro Piñeiro 

Out of curiosity: right now it is always used as true (so maintain 
current behaviour). How it is intended to be used? With an envvar?


On 7/3/19 22:38, Jason Ekstrand wrote:

---
  src/compiler/nir/nir_serialize.c  | 56 ---
  src/compiler/nir/nir_serialize.h  |  3 +-
  .../drivers/radeonsi/si_state_shaders.c   |  2 +-
  src/intel/vulkan/anv_pipeline_cache.c |  2 +-
  .../drivers/dri/i965/brw_program_binary.c |  2 +-
  src/mesa/state_tracker/st_shader_cache.c  |  2 +-
  6 files changed, 42 insertions(+), 25 deletions(-)

diff --git a/src/compiler/nir/nir_serialize.c b/src/compiler/nir/nir_serialize.c
index 743eeaed3d5..ad094beb1f4 100644
--- a/src/compiler/nir/nir_serialize.c
+++ b/src/compiler/nir/nir_serialize.c
@@ -42,6 +42,9 @@ typedef struct {
 /* the next index to assign to a NIR in-memory object */
 uintptr_t next_idx;
  
+   /* Whether or not to preserve variable and SSA def names */

+   bool preserve_names;
+
 /* Array of write_phi_fixup structs representing phi sources that need to
  * be resolved in the second pass.
  */
@@ -136,9 +139,13 @@ write_variable(write_ctx *ctx, const nir_variable *var)
  {
 write_add_object(ctx, var);
 encode_type_to_blob(ctx->blob, var->type);
-   blob_write_uint32(ctx->blob, !!(var->name));
-   if (var->name)
-  blob_write_string(ctx->blob, var->name);
+   if (ctx->preserve_names) {
+  blob_write_uint32(ctx->blob, !!(var->name));
+  if (var->name)
+ blob_write_string(ctx->blob, var->name);
+   } else {
+  blob_write_uint32(ctx->blob, 0);
+   }
 blob_write_bytes(ctx->blob, (uint8_t *) >data, sizeof(var->data));
 blob_write_uint32(ctx->blob, var->num_state_slots);
 blob_write_bytes(ctx->blob, (uint8_t *) var->state_slots,
@@ -224,9 +231,13 @@ write_register(write_ctx *ctx, const nir_register *reg)
 blob_write_uint32(ctx->blob, reg->bit_size);
 blob_write_uint32(ctx->blob, reg->num_array_elems);
 blob_write_uint32(ctx->blob, reg->index);
-   blob_write_uint32(ctx->blob, !!(reg->name));
-   if (reg->name)
-  blob_write_string(ctx->blob, reg->name);
+   if (ctx->preserve_names) {
+  blob_write_uint32(ctx->blob, !!(reg->name));
+  if (reg->name)
+ blob_write_string(ctx->blob, reg->name);
+   } else {
+  blob_write_uint32(ctx->blob, 0);
+   }
 blob_write_uint32(ctx->blob, reg->is_global << 1 | reg->is_packed);
  }
  
@@ -327,7 +338,7 @@ write_dest(write_ctx *ctx, const nir_dest *dst)

  {
 uint32_t val = dst->is_ssa;
 if (dst->is_ssa) {
-  val |= !!(dst->ssa.name) << 1;
+  val |= (ctx->preserve_names && dst->ssa.name) << 1;
val |= dst->ssa.num_components << 2;
val |= dst->ssa.bit_size << 5;
 } else {
@@ -336,7 +347,7 @@ write_dest(write_ctx *ctx, const nir_dest *dst)
 blob_write_uint32(ctx->blob, val);
 if (dst->is_ssa) {
write_add_object(ctx, >ssa);
-  if (dst->ssa.name)
+  if (ctx->preserve_names && dst->ssa.name)
   blob_write_string(ctx->blob, dst->ssa.name);
 } else {
blob_write_intptr(ctx->blob, write_lookup_object(ctx, dst->reg.reg));
@@ -1079,28 +1090,33 @@ read_function(read_ctx *ctx)
  }
  
  void

-nir_serialize(struct blob *blob, const nir_shader *nir)
+nir_serialize(struct blob *blob, const nir_shader *nir, bool preserve_names)
  {
 write_ctx ctx;
 ctx.remap_table = _mesa_pointer_hash_table_create(NULL);
 ctx.next_idx = 0;
 ctx.blob = blob;
 ctx.nir = nir;
+   ctx.preserve_names = preserve_names;
 util_dynarray_init(_fixups, NULL);
  
 size_t idx_size_offset = blob_reserve_intptr(blob);
  
 struct shader_info info = nir->info;

-   uint32_t strings = 0;
-   if (info.name)
-  strings |= 0x1;
-   if (info.label)
-  strings |= 0x2;
-   blob_write_uint32(blob, strings);
-   if (info.name)
-  blob_write_string(blob, info.name);
-   if (info.label)
-  blob_write_string(blob, info.label);
+   if (ctx.preserve_names) {
+  uint32_t strings = 0;
+  if (info.name)
+ strings |= 0x1;
+  if (info.label)
+ strings |= 0x2;
+  blob_write_uint32(blob, strings);
+  if (info.name)
+ blob_write_string(blob, info.name);
+  if (info.label)
+ blob_write_string(blob, info.label);
+   } else {
+  blob_write_uint32(blob, 0);
+   }
 info.name = info.label = NULL;
 blob_write_bytes(blob, (uint8_t *) , sizeof(info));
  
@@ -1204,7 +1220,7 @@ nir_shader_serialize_deserialize(void *mem_ctx, nir_shader *s)
  
 struct blob writer;

 blob_init();
-   nir_serialize(, s);
+   nir_serialize(, s, true);
 ralloc_free(s);
  
 struct blob_reader reader;

diff --git a/src/compiler/nir/nir_serialize.h b/src/compiler/nir/nir_serialize.h
index f77d8e367ff..22e5fa88ee1 100644
--- a/src/compiler/nir/nir_serialize.h
+++ b/src/compiler/nir/nir_serialize.h
@@ -31,7 +31,8 @@
  extern "C" {
  #endif
  

[Mesa-dev] [Bug 109401] [DXVK] Project Cars rendering problems

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109401

--- Comment #6 from Samuel Pitoiset  ---
Created attachment 143587
  --> https://bugs.freedesktop.org/attachment.cgi?id=143587=edit
hack reflection issue

Can you try this hack too?

-- 
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 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider

2019-03-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109939

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #7 from Mike Lothian  ---
Out of interest, if you wait long enough does it eventually complete and it it
faster the next time you load if you get it to complete

Might be that you're relying on caching and each time you install a newer RC
you have to rebuild the cache

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