ping ... this fixes Android build as anv_device.c started to include
"git_sha1.h" but build does not currently pass the path to this header.
On 10/3/18 1:46 PM, Tapani Pälli wrote:
Fixes: e4538b9 "anv: Implement VK_KHR_driver_properties"
Signed-off-by: Tapani Pälli
---
https://bugs.freedesktop.org/show_bug.cgi?id=108311
--- Comment #3 from Andrew Wesie ---
(In reply to Andrew Wesie from comment #2)
> (In reply to Dave Airlie from comment #1)
> > Created attachment 141989 [details] [review] [review]
> > set larger alignment for tmp buffer offset
> >
> > Does
https://bugs.freedesktop.org/show_bug.cgi?id=108311
--- Comment #2 from Andrew Wesie ---
(In reply to Dave Airlie from comment #1)
> Created attachment 141989 [details] [review]
> set larger alignment for tmp buffer offset
>
> Does this patch work as an alternate?
It looks like it should work
https://bugs.freedesktop.org/show_bug.cgi?id=108311
--- Comment #1 from Dave Airlie ---
Created attachment 141989
--> https://bugs.freedesktop.org/attachment.cgi?id=141989=edit
set larger alignment for tmp buffer offset
Does this patch work as an alternate?
--
You are receiving this mail
Assuming there were no CI failures, this patch is
Reviewed-by: Ian Romanick
On 10/10/2018 05:25 PM, Timothy Arceri wrote:
> The es check is already covered by the is_version() check.
> ---
> src/compiler/glsl/ast_to_hir.cpp | 4
> src/compiler/glsl_types.cpp | 2 +-
> 2 files
On 10/10/2018 05:17 PM, Jason Ekstrand wrote:
> Do we need a fix for vec4?
I had expected that we would, and I even wrote a patch for that. It
seems that the Atom GPUs that use the vec4 backend don't have the same
restriction. There weren't any failures on BYT caused by a68dd47b911,
and I
The es check is already covered by the is_version() check.
---
src/compiler/glsl/ast_to_hir.cpp | 4
src/compiler/glsl_types.cpp | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index
Do we need a fix for vec4?
On October 10, 2018 17:17:17 "Ian Romanick" wrote:
From: Jason Ekstrand
Several of the Atom GPUs have additional restrictions on alignment when
moving < 64-bit source to a 64-bit destination. All of the nir_op_*2*64
code generation paths respected this, but
On 2018-10-10 14:38:23, Rafael Antognolli wrote:
> On Wed, Oct 10, 2018 at 02:04:11PM -0700, Jordan Justen wrote:
> > On 2018-10-10 13:45:13, Rafael Antognolli wrote:
> > > On Wed, Oct 10, 2018 at 01:39:25PM -0700, Jordan Justen wrote:
> > > > Ref: 263b584d5e4 "i965/skl: Emit extra zeros in
This is basically a port of commit,
3ade766684933ac84e41634429fb693f85353c11
("i965: Disable 3DSTATE_WM_HZ_OP fields.")
The BDW+ docs describe how to use the 3DSTATE_WM_HZ_OP instruction in
the section titled, "Optimized Depth Buffer Clear and/or Stencil Buffer
Clear." It mentions that the packet
ISL_AUX_USAGE_NONE happens to be the same as "false", but let's do the
right thing and use the enum.
v2: fix intel_miptree_finish_depth too (Caio)
Reviewed-by: Dylan Baker
Reviewed-by: Caio Marcelo de Oliveira Filho
Reviewed-by: Jason Ekstrand
---
I just added the finish_depth() fix in the
From: Jason Ekstrand
Several of the Atom GPUs have additional restrictions on alignment when
moving < 64-bit source to a 64-bit destination. All of the nir_op_*2*64
code generation paths respected this, but nir_op_b2[fi] did not.
Previous to commit a68dd47b911 it was not possible to generate
On Mon 01 Oct 2018, Jason Ekstrand wrote:
> The DRM format modifiers extension adds a TILING_DRM_FORMAT_MODIFIER
> which will be used for modifiers so we can no longer use OPTIMAL to
> indicate tiled inside the driver.
> ---
> src/intel/vulkan/anv_formats.c | 2 +-
>
On 11/10/18 1:46 am, Samuel Pitoiset wrote:
We shouldn't try to compact any varyings known as always
active IO, especially XFB outputs. For example, if one
component of an xfb output is also used as input varying
in the next stage, it shouldn't be compacted.
This small helper just marks all
On Wed, Oct 10, 2018 at 02:04:11PM -0700, Jordan Justen wrote:
> On 2018-10-10 13:45:13, Rafael Antognolli wrote:
> > On Wed, Oct 10, 2018 at 01:39:25PM -0700, Jordan Justen wrote:
> > > Ref: 263b584d5e4 "i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on
> > > Skylake."
> > > Signed-off-by:
On 2018-09-12 09:05:44, wrote:
> From: Andrii Simiklit
>
> There's no point reverting to the last saved point if that save point is
> the empty batch, we will just repeat ourselves.
>
> CC: Chris Wilson
> Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
>
On 2018-10-10 13:45:13, Rafael Antognolli wrote:
> On Wed, Oct 10, 2018 at 01:39:25PM -0700, Jordan Justen wrote:
> > Ref: 263b584d5e4 "i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on
> > Skylake."
> > Signed-off-by: Jordan Justen
> > ---
> > src/intel/vulkan/genX_cmd_buffer.c | 12
On Wed, Oct 10, 2018 at 01:39:26PM -0700, Jordan Justen wrote:
> Ref: 263b584d5e4 "i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on
> Skylake."
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_misc_state.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
>
On Wed, Oct 10, 2018 at 01:39:25PM -0700, Jordan Justen wrote:
> Ref: 263b584d5e4 "i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on
> Skylake."
> Signed-off-by: Jordan Justen
> ---
> src/intel/vulkan/genX_cmd_buffer.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
Do we need to set the enable bits? If not, just extending the struct in
genxml should be sufficient.
On Wed, Oct 10, 2018 at 3:39 PM Jordan Justen
wrote:
> Ref: 263b584d5e4 "i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on
> Skylake."
> Signed-off-by: Jordan Justen
> ---
>
Please ignore this patch, Jordan's version is the correct one.
On Wed, Oct 10, 2018 at 01:30:52PM -0700, Rafael Antognolli wrote:
> Starting in gen11, we have 3 more dwords used for Bindless Sampler State
> pointer and size.
>
> Cc: Anuj Phogat
>
> ---
>
Ref: 263b584d5e4 "i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on Skylake."
Signed-off-by: Jordan Justen
---
src/intel/vulkan/genX_cmd_buffer.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index
Ref: 263b584d5e4 "i965/skl: Emit extra zeros in STATE_BASE_ADDRESS on Skylake."
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
Starting in gen11, we have 3 more dwords used for Bindless Sampler State
pointer and size.
Cc: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
On Sat, Sep 15, 2018 at 12:45 AM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Calls are not used yet (functions are inlined), but since new code is
> already taking them into account, do it here too. The convention here
> and in other places is that no writable memory is
On Sat, Sep 15, 2018 at 12:46 AM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Also tests for removal of redundant loads, that we currently handle as
> part of the copy propagation.
> ---
> src/compiler/nir/tests/vars_tests.cpp | 300 ++
> 1 file
6-8 are
Reviewed-by: Jason Ekstrand
On Sat, Sep 15, 2018 at 12:45 AM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> These are covered by another pass now.
> ---
> src/compiler/nir/nir_opt_copy_prop_vars.c | 84 +++
> 1 file changed, 8 insertions(+), 76
On Sat, Sep 15, 2018 at 12:46 AM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Instead of doing this as part of the existing copy_prop_vars pass.
>
> Separation makes easier to expand the scope of both passes to be more
> than per-block. For copy propagation, the information
Acked-by: Christian König
Am 10.10.2018 um 21:18 schrieb Ilia Mirkin:
Reviewed-by: Ilia Mirkin
On Wed, Oct 10, 2018 at 3:12 PM wrote:
From: Boyuan Zhang
vlVaGetImage should respect the width, height, and coordinates x and y that
passed in. Therefore, pipe_box should be created with the
Reviewed-by: Ilia Mirkin
On Wed, Oct 10, 2018 at 3:12 PM wrote:
>
> From: Boyuan Zhang
>
> vlVaGetImage should respect the width, height, and coordinates x and y that
> passed in. Therefore, pipe_box should be created with the passed in values
> instead of surface width/height.
>
> v2: add
From: Boyuan Zhang
vlVaGetImage should respect the width, height, and coordinates x and y that
passed in. Therefore, pipe_box should be created with the passed in values
instead of surface width/height.
v2: add input size check, return error when size out of bounds
v3: fix the size check for
Oops... My bad.
Reviewed-by: Jason Ekstrand
On Wed, Oct 10, 2018 at 12:42 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> ISL_AUX_USAGE_NONE happens to be the same as "false", but let's do the
> right thing and use the enum.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h |
I just landed the first 6 patches as well as a fix for one intel compiler
bug uncovered by the series. You can go ahead and rebase your former
series. If you feel the need for a separate 32-bit version of
compute_fast_udiv_info, I'll happily reivew the patch.
--Jason
On Mon, Oct 8, 2018 at
On Wed, Oct 10, 2018 at 10:41:43AM -0700, Rafael Antognolli wrote:
> ISL_AUX_USAGE_NONE happens to be the same as "false", but let's do the
> right thing and use the enum.
> ---
Reviewed-by: Caio Marcelo de Oliveira Filho
I think intel_miptree_finish_depth() in intel_mipmap_tree.c might need
a
Reviewed-by: Dylan Baker
Quoting Rafael Antognolli (2018-10-10 10:41:43)
> ISL_AUX_USAGE_NONE happens to be the same as "false", but let's do the
> right thing and use the enum.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Quoting Eric Engestrom (2018-10-10 10:15:35)
> On Wednesday, 2018-10-10 09:22:46 -0700, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-10-04 07:54:07)
> > > On Wednesday, 2018-10-03 11:05:36 -0700, Dylan Baker wrote:
> > > > Quoting Dylan Baker (2018-10-03 10:35:45)
> > > > > Currently mesa
ISL_AUX_USAGE_NONE happens to be the same as "false", but let's do the
right thing and use the enum.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
On Wednesday, 2018-10-10 09:22:46 -0700, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-10-04 07:54:07)
> > On Wednesday, 2018-10-03 11:05:36 -0700, Dylan Baker wrote:
> > > Quoting Dylan Baker (2018-10-03 10:35:45)
> > > > Currently mesa only supports EGL on Unix like systems, cygwin, and
> >
Quoting Eric Engestrom (2018-10-04 07:54:07)
> On Wednesday, 2018-10-03 11:05:36 -0700, Dylan Baker wrote:
> > Quoting Dylan Baker (2018-10-03 10:35:45)
> > > Currently mesa only supports EGL on Unix like systems, cygwin, and
> > > haiku. Meson should actually enforce this. This fixes the default
On Wed, Oct 10, 2018 at 9:47 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Oh dear...
>
> Reviewed-by: Lionel Landwerlin
>
> Eric, Jason : Could it be the wsi CTS test you've seen locking up forever?
>
I don't think so. It blocks in a different place. In any case, good catch!
Looks good to me.
On Wed, Oct 10, 2018 at 10:52 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> On 10/10/2018 16:34, Juan A. Suarez Romero wrote:
> > On Tue, 2018-10-02 at 16:11 -0500, Jason Ekstrand wrote:
> >> On Broadwell and above, we have to use different MOCS settings to
On 10/10/2018 16:34, Juan A. Suarez Romero wrote:
On Tue, 2018-10-02 at 16:11 -0500, Jason Ekstrand wrote:
On Broadwell and above, we have to use different MOCS settings to allow
the kernel to take over and disable caching when needed for external
buffers. On Broadwell, this is especially
On Wed, 2018-10-10 at 11:03 +1100, Timothy Arceri wrote:
> The Nvidia/AMD binary drivers allow this, as does GCC.
>
> This fixes shader compilation issues in the latest update of
> No Mans Sky.
>
> Cc: mesa-sta...@lists.freedesktop.org
This patch landed in upstream without the CC: mesa-stable.
On Tue, 2018-10-02 at 16:11 -0500, Jason Ekstrand wrote:
> On Broadwell and above, we have to use different MOCS settings to allow
> the kernel to take over and disable caching when needed for external
> buffers. On Broadwell, this is especially important because the kernel
> can't disable eLLC
https://bugs.freedesktop.org/show_bug.cgi?id=108312
--- Comment #1 from Bas Vermeulen ---
I've tracked it down to src/gallium/drivers/radeonsi/si_compute.c, functions
si_switch_compute_shader and/or si_launch_grid, where amd_kernel_code_t is
available in just little endian. A big endian system
Oh dear...
Reviewed-by: Lionel Landwerlin
Eric, Jason : Could it be the wsi CTS test you've seen locking up forever?
On 05/10/2018 01:00, Dave Airlie wrote:
From: Dave Airlie
Not going to matter, but be consistent.
Found by coverity
---
src/intel/vulkan/anv_allocator.c | 1 +
1 file
We shouldn't try to compact any varyings known as always
active IO, especially XFB outputs. For example, if one
component of an xfb output is also used as input varying
in the next stage, it shouldn't be compacted.
This small helper just marks all XFB varyings as always_active_io
in the consumer
Otherwise, Yakuza and The Evil Within hang the GPU with DXVK.
Suggested by Marek.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/amd/vulkan/radv_pipeline.c
Reviewed-by: Tapani Pälli
On 10/9/18 7:09 PM, Vadym Shovkoplias wrote:
Adding compile time check for subroutine functions with
the same names. Similar check for intrastage linking was already
landed in commit 5f0567a4f60.
From Section 6.1.2 (Subroutines) of the GLSL 4.00 specification
Reviewed-by: Tapani Pälli
On 10/10/18 1:51 PM, Vadym Shovkoplias wrote:
Also there is no "OpenGL ES Shading Language 4.00" spec,
so change it to GLSL 4.00 spec.
Signed-off-by: Vadym Shovkoplias
---
src/compiler/glsl/linker.cpp | 11 +--
1 file changed, 5 insertions(+), 6
https://bugs.freedesktop.org/show_bug.cgi?id=100960
--- Comment #16 from Sergii Romantsov ---
Created attachment 141974
--> https://bugs.freedesktop.org/attachment.cgi?id=141974=edit
zero-vector-rotate.trace.tar.gz
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100960
--- Comment #15 from Sergii Romantsov ---
Created attachment 141973
--> https://bugs.freedesktop.org/attachment.cgi?id=141973=edit
Mesa_zero-vector-rotate.png
--
You are receiving this mail because:
You are the assignee for the bug.
You are
https://bugs.freedesktop.org/show_bug.cgi?id=100960
--- Comment #14 from Sergii Romantsov ---
Thanks, Fabian. Your image looks the same as mesa with patch
https://patchwork.freedesktop.org/patch/249043/ v3
Proposed additionally piglit-test:
https://patchwork.freedesktop.org/patch/255629/
Also there is no "OpenGL ES Shading Language 4.00" spec,
so change it to GLSL 4.00 spec.
Signed-off-by: Vadym Shovkoplias
---
src/compiler/glsl/linker.cpp | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
Hello,
i've updated a test for the latest version of mesa-patch:
https://patchwork.freedesktop.org/patch/255629/
The image should looks for any driver (Windows, Nvidia, mesa) like this:
[image: Screenshot from 2018-10-10 13-47-56.png]
On Fri, Sep 21, 2018 at 4:21 PM Sergii Romantsov
wrote:
>
After the experience of using it, and reading it, the patch LGTM. I
still have some issues while trying to use this pass, but they are
mostly glslang bugs, or things that I suspect is a problem on a
different pass or on our linking code, that are better to talk in a
different thread.
So this
https://bugs.freedesktop.org/show_bug.cgi?id=108245
--- Comment #3 from Samuel Pitoiset ---
I can confirm that vega fails. I will try to look at it today.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
On 10/10/18 10:34 AM, Timothy Arceri wrote:
On 10/10/18 7:25 pm, Samuel Pitoiset wrote:
On 10/10/18 10:14 AM, Timothy Arceri wrote:
On 10/10/18 6:44 pm, Samuel Pitoiset wrote:
We shouldn't try to compact any varyings known as always
active IO, especially XFB outputs. For example, if one
v2: - change how the access qualifiers are accumulated
v3: - duplicate members in struct_member_decoration_cb()
- handle access qualifiers on variables
- remove access qualifiers handling in _vtn_variable_load_store()
- fix setting access qualifiers on type->array_element
On 10/10/18 7:25 pm, Samuel Pitoiset wrote:
On 10/10/18 10:14 AM, Timothy Arceri wrote:
On 10/10/18 6:44 pm, Samuel Pitoiset wrote:
We shouldn't try to compact any varyings known as always
active IO, especially XFB outputs. For example, if one
component of an xfb output is also used as input
On 10/10/18 10:14 AM, Timothy Arceri wrote:
On 10/10/18 6:44 pm, Samuel Pitoiset wrote:
We shouldn't try to compact any varyings known as always
active IO, especially XFB outputs. For example, if one
component of an xfb output is also used as input varying
in the next stage, it shouldn't be
On 10/10/18 6:44 pm, Samuel Pitoiset wrote:
We shouldn't try to compact any varyings known as always
active IO, especially XFB outputs. For example, if one
component of an xfb output is also used as input varying
in the next stage, it shouldn't be compacted.
Because we look at the input
I'm aware of the Offset decoration discussions, but I'm fine with that
pass for now anyway. It does the job and RADV can use it.
Having the offset explicitely declared is the way to go in my opinion,
and that doesn't require extra compiler work. So, patch is:
Reviewed-by: Samuel Pitoiset
Quoting Ian Romanick (2018-10-10 00:24:00)
> On 10/09/2018 06:24 AM, Chris Wilson wrote:
> > The userspace driver does not exist in isolation and occasionally
> > depends on kernel uapi, and so it is useful in bug reports to include
> > that information. (radeonsi, r600 and radv already include
https://bugs.freedesktop.org/show_bug.cgi?id=108109
--- Comment #3 from vadym ---
Additional check to compiler added:
https://patchwork.freedesktop.org/patch/255542/
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108312
Bas Vermeulen changed:
What|Removed |Added
OS|All |Linux (All)
Hardware|Other
https://bugs.freedesktop.org/show_bug.cgi?id=108312
Bug ID: 108312
Summary: Failed to allocate buffer on big endian machine -
buffer size not byte swapped
Product: Mesa
Version: 18.2
Hardware: Other
OS: All
We shouldn't try to compact any varyings known as always
active IO, especially XFB outputs. For example, if one
component of an xfb output is also used as input varying
in the next stage, it shouldn't be compacted.
Because we look at the input varyings from the consumer
stage, we don't know if
https://bugs.freedesktop.org/show_bug.cgi?id=108245
--- Comment #2 from Alex Smith ---
This also seems to be sometimes causing VM faults - I get a bunch of faults in
the game that's affected by this bug, which go away if I skip
vkCmdCopyBufferToImage calls which would get corrupted.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=108311
Andrew Wesie changed:
What|Removed |Added
CC||mesa-dev@lists.freedesktop.
70 matches
Mail list logo
