On 08/21/2018 09:28 PM, Marek Olšák wrote:
> On Tue, Aug 21, 2018 at 8:02 PM Sagar Ghuge wrote:
>>
>> _mesa_set_enable() and _mesa_IsEnabled() extended to accept new two
>> tokens GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD.
>>
>> Signed-off-by: Sagar Ghuge
>> ---
>> src/mesa/main/enable.
On 21.08.2018 11:27, Tapani Pälli wrote:
v2: have separate memory properties for android, set usage
flags for buffers correctly
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_formats.c | 71 +-
1 file changed, 70 insertions(+), 1 deletion(
In a separate email, Rob wrote:
> so, it was earlier discussed that
> glXGetScreenDriver()/glXGetDriverConfig() equivalents could be lumped
> into this extension, which is I guess not what you have done.
I'm fairly agnostic on this, but if you do lump it into one extension,
please make the GetD
Hi all,
On Tue, Aug 21, 2018 at 2:49 PM Emil Velikov
wrote:
> HI all,
>
> On 20 August 2018 at 20:01, Rob Clark wrote:
> > +Emil since he had some interest in this extension too
> >
> >
> Bth since I did not hear anything last week, so I sat down and wrote
> the spec, implementation and tests o
https://bugs.freedesktop.org/show_bug.cgi?id=107654
--- Comment #1 from Kevin Rogovin ---
Created attachment 141235
--> https://bugs.freedesktop.org/attachment.cgi?id=141235&action=edit
pgp-key
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact fo
https://bugs.freedesktop.org/show_bug.cgi?id=107654
Bug ID: 107654
Summary: Account request Kevin Rogovin
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
P
Ville,
On Monday, 20 August 2018 15:57:07 CEST Ville Syrjälä wrote:
> Seems to. Thanks for tracking it down.
>
> Tested-by: Ville Syrjälä
Thanks for finding out how to reproduce and testing.
best
Mathias
___
mesa-dev mailing list
mesa-dev@lists.fr
From: Mathias Fröhlich
Hi Ville, Brian,
The below patch fixes the regression to tnl drivers that Ville reported
a hand full weeks ago.
Please review!
best
Mathias
Fix an other regression of patch 64d2a2048054
mesa: Make gl_vertex_array contain pointers to first order VAO members.
The regressi
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 21, 2018 at 8:02 PM Sagar Ghuge wrote:
>
> Signed-off-by: Sagar Ghuge
> Reviewed-by: Ian Romanick
> ---
> src/mesa/main/get.c | 1 +
> src/mesa/main/get_hash_params.py | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/src/me
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 21, 2018 at 8:02 PM Sagar Ghuge wrote:
>
> Signed-off-by: Sagar Ghuge
> Reviewed-by: Ian Romanick
> ---
> src/mapi/glapi/gen/AMD_depth_clamp_separate.xml | 15 +++
> src/mapi/glapi/gen/Makefile.am | 1 +
> src/mapi/glapi
On Tue, Aug 21, 2018 at 8:02 PM Sagar Ghuge wrote:
>
> _mesa_set_enable() and _mesa_IsEnabled() extended to accept new two
> tokens GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD.
>
> Signed-off-by: Sagar Ghuge
> ---
> src/mesa/main/enable.c | 36
> 1 fil
On Tue, Aug 21, 2018 at 8:02 PM Sagar Ghuge wrote:
>
> Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle
> GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens.
>
> Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it,
> as suggested by Marek Olsak.
>
> Driver that en
On Tue, Aug 21, 2018 at 6:00 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> > diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> > index 96ad77c3906..5e9da9e1ef2 100644
> > --- a/src/intel/compiler/brw_nir.c
> > +++ b/src/intel/compiler/brw_nir.c
> >
The Vulkan 1.1.81 spec says:
"It is legal for offset.x + extent.width or offset.y + extent.height
to exceed the dimensions of the framebuffer - the scissor test still
applies as defined above. Rasterization does not produce fragments
outside of the framebuffer, so such fragments ne
Some of the bits of VERTEX_BUFFER_STATE such as access type, instance
data step rate, and pitch come from the pipeline.
Cc: mesa-sta...@lists.freedesktop.org
---
src/intel/vulkan/genX_cmd_buffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/inte
I have no idea if I'm correct about what's going wrong or if this is the
correct fix. However, in my multiple weeks of banging my head on this
hang, a VUE reference counting bug seems to match all the symptoms and
it definitely fixes the hang.
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https
Known to fix nothing whatsoever but it's in the docs.
---
src/intel/vulkan/genX_cmd_buffer.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 18f80e8d1bd..75b3dd54275 100644
--- a/src/intel/vulkan/genX_cmd_b
Reviewed-by: Marek Olšák
Marek
On Fri, Aug 10, 2018 at 9:22 PM Eric Anholt wrote:
>
> One of the pains of implementing a gallium driver is filling in a million
> pipe caps you don't know about yet when you're just starting out. One of
> the pains of working on gallium is copy-and-pasting your n
You can also update release notes of 18.3 for i965. (not needed to be reviewed)
Marek
On Tue, Aug 21, 2018 at 8:02 PM Sagar Ghuge wrote:
>
> This patch series implements AMD_depth_clamp_separate extension.
> Previously I sent patches for comments and based on Ian and Marek's
> suggestions, I did
https://bugs.freedesktop.org/show_bug.cgi?id=107653
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=106231
Roland Scheidegger changed:
What|Removed |Added
CC||v...@freedesktop.org
--- Comment #
On Tue, Aug 21, 2018 at 8:02 PM Sagar Ghuge wrote:
>
> Add some basic types and storage for the AMD_depth_clamp_separate
> extension.
>
> Signed-off-by: Sagar Ghuge
> ---
> include/GL/glcorearb.h | 2 ++
> src/mesa/main/extensions_table.h | 1 +
> src/mesa/main/mtypes.h | 3 +
From: Marek Olšák
---
src/amd/common/ac_llvm_build.h| 6 ++
src/amd/common/ac_nir_to_llvm.c | 4
src/gallium/drivers/radeonsi/si_shader_internal.h | 5 -
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/amd/common/ac_llvm_build
Get you send me a "git fetch" line that I can use to download your patches?
Thanks,
Marek
On Tue, Aug 21, 2018 at 11:30 AM Kai Wasserbäch
wrote:
>
> Hey Marek,
> Marek Olšák wrote on 8/21/18 2:23 AM:
> > I've sent comments on patches 3 & 4. With those addressed, patches 1-5 are:
> >
> > Reviewed-
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 21, 2018 at 11:25 AM Kai Wasserbäch
wrote:
>
> Only used, when asserts are enabled.
>
> Fixes an unused-variable warning with GCC 8:
> ../../../src/amd/addrlib/r800/egbaddrlib.cpp: In member function 'int
> Addr::V1::EgBasedLib::SanityCheckMacroTiled(
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 21, 2018 at 11:25 AM Kai Wasserbäch
wrote:
>
> Only used, when asserts are enabled.
>
> Fixes an unused-variable warning with GCC 8:
> ../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp: In member function
> 'ADDR_E_RETURNCODE Addr::V2::Gfx9Lib::ComputeSte
On Tue, Aug 21, 2018 at 06:15:20PM -0500, Jason Ekstrand wrote:
> On Tue, Aug 21, 2018 at 5:55 PM Caio Marcelo de Oliveira Filho <
> caio.olive...@intel.com> wrote:
>
> > Hi,
> >
> > On Sat, Jul 28, 2018 at 10:44:39PM -0700, Jason Ekstrand wrote:
> > > This pass looks for variables with vector or
Yeah, I can do that.
Marek
On Tue, Aug 21, 2018 at 3:00 AM Samuel Pitoiset
wrote:
>
> Can you also fix ac? How about moving those constants inside a header
> and prefix them with AC_?
>
> On 8/21/18 5:23 AM, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > ---
> > src/gallium/drivers/radeonsi/
On Sat, Jul 28, 2018 at 10:44:41PM -0700, Jason Ekstrand wrote:
> This peephole optimization looks for a series of load/store_deref or
> copy_deref instructions that copy an array from one variable to another
> and turns it into a copy_deref that copies the entire array. The
> pattern it looks for
https://bugs.freedesktop.org/show_bug.cgi?id=107653
Bug ID: 107653
Summary: lp_test_blend fails with llvm-8.0svn
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: All
Status: NEW
Keywords: bisected,
Signed-off-by: Sagar Ghuge
Reviewed-by: Ian Romanick
---
src/mesa/main/get.c | 1 +
src/mesa/main/get_hash_params.py | 5 +
2 files changed, 6 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 6b2e3637e6..92020e29a9 100644
--- a/src/mesa/main/get.c
+++
Gen >= 9 have ability to control clamping of depth values separately at
near and far plane.
z_w is clamped to the range [min(n,f), 0] if clamping at near plane is
enabled, [0, max(n,f)] if clamping at far plane is enabled and [min(n,f)
max(n,f)] if clamping at both plane is enabled.
Signed-off-by
This patch series implements AMD_depth_clamp_separate extension.
Previously I sent patches for comments and based on Ian and Marek's
suggestions, I did some changes.
1) Get rid of DepthClamp as DepthClampNear + DepthClampFar replaces it
(Marek Olsak & Ian Romanick)
2) Make sure that patch series
Add some basic types and storage for the AMD_depth_clamp_separate
extension.
Signed-off-by: Sagar Ghuge
---
include/GL/glcorearb.h | 2 ++
src/mesa/main/extensions_table.h | 1 +
src/mesa/main/mtypes.h | 3 +++
3 files changed, 6 insertions(+)
diff --git a/include/GL/glcorea
Signed-off-by: Sagar Ghuge
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index f1c3aeff13..f07d3ab601 100644
--- a/src/mesa/drivers/dri/i965/intel_ex
Signed-off-by: Sagar Ghuge
Reviewed-by: Ian Romanick
---
src/mapi/glapi/gen/AMD_depth_clamp_separate.xml | 15 +++
src/mapi/glapi/gen/Makefile.am | 1 +
src/mapi/glapi/gen/gl_API.xml | 3 +++
src/mapi/glapi/gen/meson.build | 1 +
Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle
GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens.
Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it,
as suggested by Marek Olsak.
Driver that enables AMD_depth_clamp_separate will only ever look at
DepthClampNe
_mesa_set_enable() and _mesa_IsEnabled() extended to accept new two
tokens GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD.
Signed-off-by: Sagar Ghuge
---
src/mesa/main/enable.c | 36
1 file changed, 36 insertions(+)
diff --git a/src/mesa/main/enable.c b/
On Tue, Aug 21, 2018 at 5:55 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Hi,
>
> On Sat, Jul 28, 2018 at 10:44:39PM -0700, Jason Ekstrand wrote:
> > This pass looks for variables with vector or array-of-vector types and
> > narrows the type to only the components used.
>
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 96ad77c3906..5e9da9e1ef2 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -542,6 +542,7 @@ brw_nir_optimize(nir_shader *nir, const struct
> brw_compiler *compiler,
> do {
>
Hi,
On Sat, Jul 28, 2018 at 10:44:39PM -0700, Jason Ekstrand wrote:
> This pass looks for variables with vector or array-of-vector types and
> narrows the type to only the components used.
> ---
> src/compiler/nir/nir.h| 1 +
> src/compiler/nir/nir_split_vars.c | 694 +++
https://bugs.freedesktop.org/show_bug.cgi?id=107610
--- Comment #6 from Christopher Snowhill ---
Okay, here you go, I was still able to reproduce the effect on AMD:
https://f.losno.co/delfino-plaza-amd.tar.xz
--
You are receiving this mail because:
You are the assignee for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=107610
--- Comment #5 from Christopher Snowhill ---
And I can't report it on AMD because I removed the card. I can reinstall it if
it's absolutely necessary. I really hate constantly swapping my video card out.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=107594
--- Comment #2 from Gluzskiy Alexandr ---
it solve problem building on x86_64 for x86
--
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lis
Jose Maria Casanova Crespo writes:
> We use the information of the registers read/write patterns
> to improve variable liveness analysis avoiding extending the
> liveness range of a variable to the beginning of the block so
> it always reaches the beginning of the shader.
>
> This optimization an
Reviewed-by: Lionel Landwerlin
On 21/08/2018 18:38, Rafael Antognolli wrote:
It looks like we can't rely on the simulator to always translate virtual
addresses to physical ones correctly. So let's use physical everywhere.
Since our current GGTT maps virtual to physical addresses in a 1:1 way,
Reviewed-by: Lionel Landwerlin
On 21/08/2018 18:38, Rafael Antognolli wrote:
Hopefully it's a little more descriptive, and more accurate.
Cc: Lionel Landwerlin
---
src/intel/tools/aub_write.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/tools/aub_write.c b/
On Tue, Aug 21, 2018 at 2:26 PM Andres Rodriguez wrote:
>
>
>
> On 2018-08-21 01:54 PM, Marek Olšák wrote:
> > Note that WAVES_PER_SH should be 0x3ff on the compute ring for the
> > ring priorities to be applied.
>
> Correct, we would need to set WAVES_PER_SH during pipeline creation.
>
> > I don'
Jose Maria Casanova Crespo writes:
> These new methods return for a instruction register source/destination
> the read/write byte pattern of the 32-byte GRF as an unsigned int.
>
> The returned pattern takes into account the exec_size of the instruction,
> the type bitsize, the register stride an
From: Dave Airlie
This fixes some hangs with the arb_shader_image_load_store-atomicity tests
on evergreen/cayman GPUs.
I'm not 100% sure why (VPM hurts my brain), I'm running some piglit
runs to see if it has any bad side effects.
v2: only set the vpm flags when an atomic operation is done.
---
Hi all,
We received an overwhelming response for this CFP - 35+ proposals (and
still some latecomers trickling in), for only 18 slots.
What we didn't much get (and the CFP failed to make it clear that
we're looking for this) is proposals for the workshop/discussion track
in the 2nd room. In the p
On 2018-08-21 01:54 PM, Marek Olšák wrote:
Note that WAVES_PER_SH should be 0x3ff on the compute ring for the
ring priorities to be applied.
Correct, we would need to set WAVES_PER_SH during pipeline creation.
I don't know if you need to do the same
thing for the gfx ring. You can ask Andre
Note that WAVES_PER_SH should be 0x3ff on the compute ring for the
ring priorities to be applied. I don't know if you need to do the same
thing for the gfx ring. You can ask Andres for more info.
Marek
On Tue, Aug 14, 2018 at 12:10 PM Samuel Pitoiset
wrote:
>
> The last parameter of radeon_set_sh
On Tue, Aug 21, 2018 at 3:36 AM Samuel Pitoiset
wrote:
>
>
>
> On 8/21/18 9:36 AM, Samuel Pitoiset wrote:
> > Why don't you set cs_max_waves_per_sh? Did you miss something?
>
> Nevermind, it's used in the next patch.
Yes, this patch just adds the state. The state is always applied, so
it doesn't
Hopefully it's a little more descriptive, and more accurate.
Cc: Lionel Landwerlin
---
src/intel/tools/aub_write.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/tools/aub_write.c b/src/intel/tools/aub_write.c
index e92bdaf5ed4..5d59b4ef28a 100644
--- a/src/intel/t
It looks like we can't rely on the simulator to always translate virtual
addresses to physical ones correctly. So let's use physical everywhere.
Since our current GGTT maps virtual to physical addresses in a 1:1 way,
no further changes are required.
Additionally, we have other address spaces not
https://bugs.freedesktop.org/show_bug.cgi?id=99014
Jan Vesely changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.freed
On 08/21/2018 06:10 AM, Axel Davy wrote:
> On 23/06/2018 07:03, Ian Romanick wrote:
>> I initially started implementing support for NV_shader_atomic_float. I
>> had misunderstood the hardware specs, and Intel hardware cannot actually
>> do that extension. It does have some floating-point atomic s
On Tuesday, 2018-08-21 12:35:15 +0200, Juan A. Suarez Romero wrote:
> Cc: Dylan Baker
> Cc: Eric Engestrom
Fixes: 0cef0cccf51fc20d797e "swr: bump minimum supported LLVM version to 6.0"
Acked-by: Eric Engestrom
> ---
> .travis.yml | 24 ++--
> 1 file changed, 10 insertions(
Hey Marek,
Marek Olšák wrote on 8/21/18 2:23 AM:
> I've sent comments on patches 3 & 4. With those addressed, patches 1-5 are:
>
> Reviewed-by: Marek Olšák
thanks for the review! I've just sent updated versions of patches 3 and 4. (Just
as a side note: I only reindented the other variable defini
Only used, when asserts are enabled.
Fixes an unused-variable warning with GCC 8:
../../../src/amd/addrlib/r800/egbaddrlib.cpp: In member function 'int
Addr::V1::EgBasedLib::SanityCheckMacroTiled(ADDR_TILEINFO*) const':
../../../src/amd/addrlib/r800/egbaddrlib.cpp:982:13: warning: unused variab
Only used, when asserts are enabled.
Fixes an unused-variable warning with GCC 8:
../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp: In member function
'ADDR_E_RETURNCODE Addr::V2::Gfx9Lib::ComputeStereoInfo(const
ADDR2_COMPUTE_SURFACE_INFO_INPUT*, ADDR2_COMPUTE_SURFACE_INFO_OUTPUT*, unsigned
int*
Hi Emil,
On Mon, Aug 20, 2018 at 10:47 PM Emil Velikov wrote:
>
> On 13 August 2018 at 17:18, Tomasz Figa wrote:
> > On Tue, Aug 14, 2018 at 1:09 AM Emil Velikov
> > wrote:
> >>
> >> On 13 August 2018 at 16:43, Tomasz Figa wrote:
> >> > On Tue, Aug 14, 2018 at 12:35 AM Emil Velikov
> >> > w
Hi Emil,
On Tue, Aug 14, 2018 at 2:05 AM Emil Velikov wrote:
>
> From: Emil Velikov
>
> Unlike the other platforms, here we aim do guess if the device that we
> somewhat arbitrarily picked, is supported or not.
>
> It seems a bit fiddly, but considering EGL_EXT_explicit_device and
> EGL_MESA_que
On 23/06/2018 07:03, Ian Romanick wrote:
I initially started implementing support for NV_shader_atomic_float. I
had misunderstood the hardware specs, and Intel hardware cannot actually
do that extension. It does have some floating-point atomic support, so
I decided to create an extension based
On 21 August 2018 at 13:04, Eric Engestrom wrote:
> This file is regenerated at build time anyway, so this would just get
> overwritten anyway. No reason to ship it in the tarball.
>
> Fixes: 44df06211cf2c301f6ef "autotools: include git_sha1.h in dist tarball"
> Fixes: 471f708ed6f4787813d0 "git_sh
On Tue, 2018-08-21 at 13:04 +0100, Eric Engestrom wrote:
> This file is regenerated at build time anyway, so this would just get
> overwritten anyway. No reason to ship it in the tarball.
>
> Fixes: 44df06211cf2c301f6ef "autotools: include git_sha1.h in dist tarball"
> Fixes: 471f708ed6f4787813d0
This file is regenerated at build time anyway, so this would just get
overwritten anyway. No reason to ship it in the tarball.
Fixes: 44df06211cf2c301f6ef "autotools: include git_sha1.h in dist tarball"
Fixes: 471f708ed6f4787813d0 "git_sha1: simplify logic"
Cc: Juan A. Suarez Romero
Signed-off-by
Hi all,
The bug for this issue was created:
https://bugs.freedesktop.org/show_bug.cgi?id=107626
Regards,
Andrii.
On Mon, Aug 20, 2018 at 5:43 PM, wrote:
> From: Andrii Simiklit
>
> If we restore the 'new batch' using 'intel_batchbuffer_reset_to_saved'
> function we must restore the default s
Cc: Dylan Baker
Cc: Eric Engestrom
---
.travis.yml | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 32cd8602e6f..f51ff026e9d 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -98,10 +98,8 @@ matrix:
- BUILD=make
Signed-off-by: Rhys Perry
Cc: 18.2:
---
docs/relnotes/18.2.0.html | 3 +++
1 file changed, 3 insertions(+)
diff --git a/docs/relnotes/18.2.0.html b/docs/relnotes/18.2.0.html
index fb7a12f285..8afcb59d16 100644
--- a/docs/relnotes/18.2.0.html
+++ b/docs/relnotes/18.2.0.html
@@ -59,6 +59,9 @@ Not
On 18 August 2018 at 13:57, Eric Engestrom wrote:
> The original issue spotted was an upcast done after a bitwise ops, but
> since the same logic is done in multiple place, Emil suggested adding
> a helper to avoid mistakes.
>
Thank you.
> Signed-off-by: Eric Engestrom
> ---
> src/egl/drivers/d
Hi Timothy, Alejandro,
Thanks for the review comments!
I'd just like to mention that the same approach is already used
in link_varyings.cpp file in function cross_validate_outputs_to_inputs().
Here is a code snippet:
if (*input->data.used *&& !input->get_interface_type() &&
!input
Hi Kevin,
On 20 August 2018 at 15:11, Kevin Rogovin wrote:
> Hi Plamena,
>
> Thankyou for the fast review. Can you push it or have someone push it? (I
> do not have push rights)
>
You have contributed a number of good patches in Mesa, always
listening to feedback.
I would welcome if you're given
Hi Eric,
On Sat, 18 Aug 2018 at 13:58, Eric Engestrom wrote:
> The original issue spotted was an upcast done after a bitwise ops, but
> since the same logic is done in multiple place, Emil suggested adding
> a helper to avoid mistakes.
Works for me. The original issue we had was not so much with
Sure thing!
-Pam
On Mon, Aug 20, 2018 at 3:25 PM, Kevin Rogovin
wrote:
> Hi Plamena,
>
> Thankyou for the fast review. Can you push it or have someone push it? (I
> do not have push rights)
>
> -Keviv
>
> On Mon, Aug 20, 2018 at 2:50 PM, Manolova, Plamena <
> plamena.manol...@intel.com> wrote:
On 21/08/18 03:02, Timothy Arceri wrote:
> On 20/08/18 23:31, vadym.shovkoplias wrote:
>> From Section 4.3.4 (Inputs) of the GLSL 1.50 spec:
>>
>> "Only the input variables that are actually read need to be written
>> by the previous stage; it is allowed to have superfluous
>> dec
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_extensions.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_extensions.py
b/src/intel/vulkan/anv_extensions.py
index cafb6060c6b..f5d126edf6b 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv
When adding YUV support, we need to figure out implementation-defined
external format identifier.
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_android.c | 99 ++
1 file changed, 99 insertions(+)
diff --git a/src/intel/vulkan/anv_android.c b/src/in
These will be utilized later when we need to set usage flags for
android hardware buffers correctly based both on image usage flags
and it's creation flags.
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_image.c | 1 +
src/intel/vulkan/anv_private.h | 1 +
2 files changed, 2 insertions(+
Hi;
I finally got dEQP happy with this so not RFC anymore but I consider
this ready for proper review. It was mainly lacking proper handling
of usage flags in vkGetPhysicalDeviceImageFormatProperties2 and when
creating exportable memory in vkAllocateMemory.
Any comments appreciated!
// Tapani
T
Since we don't know the exact format at creation time, some initialization
is done only when bound with memory in vkBindImageMemory.
v2: demand dedicated allocation in vkGetImageMemoryRequirements2 if
image has external format
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_android.c |
v2: add support for non-image buffers (AHARDWAREBUFFER_FORMAT_BLOB)
v3: properly handle usage bits when creating from image
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_android.c | 149 +
src/intel/vulkan/anv_device.c | 46 -
src/inte
This will be utilized later by GetAndroidHardwareBufferPropertiesANDROID.
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_formats.c | 22 +++---
src/intel/vulkan/anv_private.h | 5 +
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/src/intel/vulkan/anv_f
v2: have separate memory properties for android, set usage
flags for buffers correctly
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_formats.c | 71 +-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_formats.c
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/vk_format_info.h | 43 +++
1 file changed, 43 insertions(+)
diff --git a/src/intel/vulkan/vk_format_info.h
b/src/intel/vulkan/vk_format_info.h
index a1cc6952c8f..0ae0a2d43ee 100644
--- a/src/intel/vulkan/vk_for
The patch seems to be safe, so yes, thanks.
On 8/21/18 1:17 AM, Andres Gomez wrote:
Danylo, should we also include this in the stable queues ?
On Mon, 2018-06-18 at 15:50 +0300, Danylo Piliaiev wrote:
We use floating-points for viewport bounds so VIEWPORT_SUBPIXEL_BITS
should reflect this.
B
https://bugs.freedesktop.org/show_bug.cgi?id=106958
soredake changed:
What|Removed |Added
CC||fds...@krutt.org
--
You are receiving this
Hey Andres,
Yes, it should. Sorry I missed the Cc stable in the patch.
Thanks for paying attention :)
-
Lionel
On 20/08/2018 23:17, Andres Gomez wrote:
Danylo, should we also include this in the stable queues ?
On Mon, 2018-06-18 at 15:50 +0300, Danylo Piliaiev wrote:
We use floating-point
https://bugs.freedesktop.org/show_bug.cgi?id=107477
--- Comment #2 from Samuel Pitoiset ---
Can you try to reproduce the crash with RADV_DEBUG=shaders,preoptir and upload
the output somewhere?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for t
Reviewed-by: Bas Nieuwenhuizen
On Tue, Aug 21, 2018 at 9:49 AM, Samuel Pitoiset
wrote:
> This should be applied on top of "ac: add imad & fmad helpers".
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 24
> 1 file changed, 8 insertions(+)
This should be applied on top of "ac: add imad & fmad helpers".
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.
hi,
On Thu, Aug 16, 2018, 4:48 PM Lepton Wu wrote:
>
> Does https://patchwork.freedesktop.org/patch/238931/ already fix this?
> What's the advantage to use MAP_FAILED instead of NULL?
yea that patch should work fine, i didnt see it go by.
the advantage of MAP_FAILED is it's more fault tolerant.
Hi Plamena,
Thankyou for the fast review. Can you push it or have someone push it? (I
do not have push rights)
-Keviv
On Mon, Aug 20, 2018 at 2:50 PM, Manolova, Plamena <
plamena.manol...@intel.com> wrote:
> Hi Kevin,
> This looks good to me :)
>
> Reviewed-by: Plamena Manolova
>
> On Wed, Au
On 8/21/18 9:36 AM, Samuel Pitoiset wrote:
Why don't you set cs_max_waves_per_sh? Did you miss something?
Nevermind, it's used in the next patch.
On 8/21/18 7:50 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_compute.c | 8
src/gallium/drivers/r
Why don't you set cs_max_waves_per_sh? Did you miss something?
On 8/21/18 7:50 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_compute.c | 8
src/gallium/drivers/radeonsi/si_pipe.h| 1 +
2 files changed, 9 insertions(+)
diff --git a/src/gallium/dr
Patches 3-9 are:
Reviewed-by: Samuel Pitoiset
On 8/21/18 5:23 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/amd/common/ac_nir_to_llvm.c | 14 +++
src/gallium/drivers/radeonsi/si_shader.c | 8 +++---
.../drivers/radeonsi/si_shader_tgsi_mem.c | 25 +++
Reviewed-by: Samuel Pitoiset
On 8/21/18 5:23 AM, Marek Olšák wrote:
From: Marek Olšák
it causes corruption on several different GPU generations.
Cc: 18.2
---
src/amd/common/ac_llvm_util.c | 7 ++-
src/amd/common/ac_llvm_util.h | 1 -
src/gallium/drivers/radeonsi/si
Can you also fix ac? How about moving those constants inside a header
and prefix them with AC_?
On 8/21/18 5:23 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader_internal.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gal
99 matches
Mail list logo