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
---
src/intel/Android.vulk
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 th
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 b
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&action=edit
set larger alignment for tmp buffer offset
Does this patch work as an alternate?
--
You are receiving this m
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 changed,
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 could
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 1082d6c91cf..77
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 nir_op
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 STATE_B
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 sa
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 +-
> src/intel/vulkan/anv_image
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 su
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 XF
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: Jord
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 a/src
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
> ---
> src/intel/vulkan
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
>
> ---
> src/mesa/drivers/dri/i965/brw_misc_stat
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 c3a7
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
b/src/mesa/drivers/dri/
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
b/src/mesa/drivers/dr
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 ass
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 chang
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 d
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 pas
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 input
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 vai
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 11:1
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 s
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 on
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
b/src/mesa/drivers/dri/i965
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 b
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 allo
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 impor
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 so
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 wi
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 ch
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 t
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 b/src/amd/vul
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 deletions(
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&action=edit
zero-vector-rotate.trace.tar.gz
--
You are receiving this mail because:
You are the QA Contact for the
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&action=edit
Mesa_zero-vector-rotate.png
--
You are receiving this mail because:
You are the assignee for the bug.
Y
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/
Apitra
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
i
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:
> Spe
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 patch
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 bug.___
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
comp
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
Signed-off-by
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 va
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 co
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 varyings
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
On
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 uts
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.___
mesa-dev
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 one
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
69 matches
Mail list logo
