Thanks,
Randy
> -Original Message-
> From: Palli, Tapani
> Sent: Monday, March 20, 2017 2:34 PM
> To: Xu, Randy ; Emil Velikov
> ; Landwerlin, Lionel G
>
> Cc: ML mesa-dev ; x...@freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] Vulkan: Solve the vkCmdClearColorImage
> crash issue
>
On 03/20/2017 02:35 AM, Xu, Randy wrote:
-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Sunday, March 19, 2017 11:39 PM
To: Landwerlin, Lionel G
Cc: Xu, Randy ; ML mesa-dev ; x...@freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Vulkan: Solve the vkCmdCl
Series is:
Reviewed-by: Samuel Iglesias Gonsálvez
On Sun, 2017-03-19 at 20:28 -0700, Kenneth Graunke wrote:
> In commit d2590eb65ff28a9cbd592353d15d7e6cbd2c6fc6 I enabled GL 4.5
> on Haswell...but failed to check if we could do indirect compute
> shader dispatch...and query buffer objects.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=100275
--- Comment #2 from Johnny Stenback ---
Ok, thanks for the pointers. I did some more testing around here looking at
your recommendations. I unfortunately can not reproduce exactly what I was
seeing with the specific versions I mentioned in my or
On 17 March 2017 at 14:18, Jason Ekstrand wrote:
> Since we already do fabs on the one source, we're guaranteed to get
> positive infinity if we get any infinity at all. Since +inf only has
> one IEEE 754 representation, we can use an integer comparison and avoid
> all of the ordered/unordered is
In commit d2590eb65ff28a9cbd592353d15d7e6cbd2c6fc6 I enabled GL 4.5
on Haswell...but failed to check if we could do indirect compute
shader dispatch...and query buffer objects.
Indirect compute shader dispatch requires command parser version 5
(kernel commit 7b9748cb513a6bef4af87b79f0da3ff7e8b56cd
2017-03-20 9:33 GMT+08:00 Rob Herring :
> Any users of KitKat are likely using an older version of Mesa and
> KitKat support adds complexity to the make files. Dropping support
> allows removing the MESA_LOLLIPOP_BUILD make variable in various make
> files.
>
> Signed-off-by: Rob Herring
> ---
>
This is a series of clean-ups and fixes to get Mesa master building on
AOSP master again. AOSP master recently changed from X.Y.Z versioning to
just the letter commonly used. Primarily, dropping KitKat and earlier
support removes most of the version number dependencies and fixes the
build.
Als
The host libmesa_util is never used for Android builds, so remove it.
Signed-off-by: Rob Herring
---
src/util/Android.mk | 35 ---
1 file changed, 35 deletions(-)
diff --git a/src/util/Android.mk b/src/util/Android.mk
index a39185ae49e0..64aafbe2ee15 100644
--- a
Commit 6facb0c08fa1 ("android: fix libz dynamic library dependencies")
added libz as a dependency, but this breaks host targets as the host
dependency is libz-host. As no host lib needs libz, just remove the
dependency for them.
Fixes: 6facb0c08fa1 "android: fix libz dynamic library dependencies"
The Android version defines are only needed for versions less than 4.2
which aren't really supported or tested.
Signed-off-by: Rob Herring
---
Android.common.mk | 2 --
Android.mk | 1 -
src/egl/Android.mk | 5 +
src/
LLVM enabled builds are broken with AOSP master. If building all targets
using "mmma external/mesa3d", the libmesa_amd_common will get built and
fail due to LLVM dependencies. Fix this by making it dependent on
MESA_ENABLE_LLVM.
Signed-off-by: Rob Herring
---
src/amd/Android.mk | 2 ++
1 file ch
Any users of KitKat are likely using an older version of Mesa and
KitKat support adds complexity to the make files. Dropping support
allows removing the MESA_LOLLIPOP_BUILD make variable in various make
files.
Signed-off-by: Rob Herring
---
Android.common.mk | 19 +++
On Thu, Mar 16, 2017 at 8:34 AM, Emil Velikov wrote:
> On 13 March 2017 at 22:36, Mauro Rossi wrote:
>> 2017-03-13 14:00 GMT+01:00 Emil Velikov :
>>>
>>> On 12 March 2017 at 23:01, Mauro Rossi wrote:
>>> > Automake generation rules are replicated for android.
>>> > $* macro was expected to retur
> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Sunday, March 19, 2017 11:39 PM
> To: Landwerlin, Lionel G
> Cc: Xu, Randy ; ML mesa-dev d...@lists.freedesktop.org>; x...@freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] Vulkan: Solve the vkCmdClearCol
Reviewed-by: Bas Nieuwenhuizen
On Mon, Mar 20, 2017 at 12:03 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> The current code evaluated to always true, we only want to flush
> on the first submit. Rename the variable to do_flush, and only
> emit on the first iteration.
>
> Signed-off-by: Dave Ai
https://bugs.freedesktop.org/show_bug.cgi?id=100075
gurkirpal...@gmail.com changed:
What|Removed |Added
Attachment #130082|0 |1
is obsolete|
From: Dave Airlie
The current code evaluated to always true, we only want to flush
on the first submit. Rename the variable to do_flush, and only
emit on the first iteration.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_device.c | 16
1 file changed, 8 insertions(+), 8 d
https://bugs.freedesktop.org/show_bug.cgi?id=100275
--- Comment #1 from Emil Velikov ---
Hi Johnny, can you track down if it's the GLVND patches that broke things -
you'll need to revert to 17.0.1-1 and bring back the "libglx.xorg" hunk in
xorg-server - see [1]. In other words - you'll need to re
https://bugs.freedesktop.org/show_bug.cgi?id=100275
Johnny Stenback changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
Version|uns
On 19 March 2017 at 22:16, Miklós Máté wrote:
> On 19/03/17 22:13, Emil Velikov wrote:
>>
>> Hi Miklós,
>>
>> On 19 March 2017 at 12:28, Miklós Máté wrote:
>>>
>>> After this series the build goes further, but eventually stops with:
>>> scons: Building targets ...
>>> Archiving build\windows-
On 19 March 2017 at 21:48, Grazvydas Ignotas wrote:
> On Sun, Mar 19, 2017 at 11:27 PM, Emil Velikov
> wrote:
>> On 19 March 2017 at 16:32, Grazvydas Ignotas wrote:
>>
>>> With that, it's picking the earlier installed
>>> /opt/xorg/include/vulkan/vulkan_intel.h instead of
>>> ../../include/vulk
On 19/03/17 22:13, Emil Velikov wrote:
Hi Miklós,
On 19 March 2017 at 12:28, Miklós Máté wrote:
After this series the build goes further, but eventually stops with:
scons: Building targets ...
Archiving build\windows-x86-debug\gallium\auxiliary\libgallium.a ...
Installing build\windows-x
On Sun, Mar 19, 2017 at 11:27 PM, Emil Velikov wrote:
> On 19 March 2017 at 16:32, Grazvydas Ignotas wrote:
>
>> With that, it's picking the earlier installed
>> /opt/xorg/include/vulkan/vulkan_intel.h instead of
>> ../../include/vulkan/vulkan_intel.h , and that one has:
>>
>> #include "vulkan.h"
On 17/03/17 18:38, Michel Dänzer wrote:
On 17/03/17 09:02 AM, Timothy Arceri wrote:
Fixes a bunch of piglit crashes that hit an assert() when trying
to delete the framebuffer. The assert() was triggered because
WinSysDrawBuffer was set to NULL before glDeleteFramebuffers()
was called.
Tested-b
On Sun, Mar 19, 2017 at 11:21 PM, Emil Velikov wrote:
> On 19 March 2017 at 19:30, Jason Ekstrand wrote:
>> On March 19, 2017 9:33:02 AM Grazvydas Ignotas wrote:
>>
>>> On Sun, Mar 19, 2017 at 3:03 PM, Emil Velikov
>>> wrote:
Hi Grazvydas,
On 17 March 2017 at 22:05, Grazvyda
On 19 March 2017 at 16:32, Grazvydas Ignotas wrote:
> With that, it's picking the earlier installed
> /opt/xorg/include/vulkan/vulkan_intel.h instead of
> ../../include/vulkan/vulkan_intel.h , and that one has:
>
> #include "vulkan.h"
>
I'm wondering if that one should be although I'm not
an exp
On 19/03/17 07:58, Grazvydas Ignotas wrote:
At the time of target file check, .tmp file is already created and file
lock is held, so we should remove the .tmp, like in other error paths.
With this, piglit no longer leaves large amount of empty .tmp files
behind, which waste directory entries and
On 19 March 2017 at 19:30, Jason Ekstrand wrote:
> On March 19, 2017 9:33:02 AM Grazvydas Ignotas wrote:
>
>> On Sun, Mar 19, 2017 at 3:03 PM, Emil Velikov
>> wrote:
>>>
>>> Hi Grazvydas,
>>>
>>> On 17 March 2017 at 22:05, Grazvydas Ignotas wrote:
Fixes build without vulkan.h installe
On 19/03/17 09:46, Grazvydas Ignotas wrote:
It seems there is a bug because:
- 20 bytes are compared, but only 1 byte stored_keys step is used
- entries can overlap each other by 19 bytes
- index_mmap is ~1.3M in size, but only first 64K is used
With this fix for Deus Ex:
- startup time (from la
Hi Miklós,
On 19 March 2017 at 12:28, Miklós Máté wrote:
> After this series the build goes further, but eventually stops with:
> scons: Building targets ...
> Archiving build\windows-x86-debug\gallium\auxiliary\libgallium.a ...
> Installing build\windows-x86-debug\bin\u_atomic_test.exe ...
>
On Sun, Mar 19, 2017 at 9:30 PM, Jason Ekstrand wrote:
> On March 19, 2017 9:33:02 AM Grazvydas Ignotas wrote:
>
>> On Sun, Mar 19, 2017 at 3:03 PM, Emil Velikov
>> wrote:
>>>
>>> Hi Grazvydas,
>>>
>>> On 17 March 2017 at 22:05, Grazvydas Ignotas wrote:
Fixes build without vulkan.h in
https://bugs.freedesktop.org/show_bug.cgi?id=97260
--- Comment #67 from tarp...@gmx.de ---
Created attachment 130317
--> https://bugs.freedesktop.org/attachment.cgi?id=130317&action=edit
bisect log leading to 7050c6ef5f0e9bc5e6bf9eb035320b70f731b919
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=97260
--- Comment #66 from tarp...@gmx.de ---
Okay. I bisected the issue today already:
7050c6ef5f0e9bc5e6bf9eb035320b70f731b919 is the first bad commit
commit 7050c6ef5f0e9bc5e6bf9eb035320b70f731b919
Author: Arindam Nath
Date: Wed Apr 6 15:33:51 20
On March 19, 2017 9:33:02 AM Grazvydas Ignotas wrote:
On Sun, Mar 19, 2017 at 3:03 PM, Emil Velikov wrote:
Hi Grazvydas,
On 17 March 2017 at 22:05, Grazvydas Ignotas wrote:
Fixes build without vulkan.h installed in system header locations:
CC vulkan/vulkan_libvulkan_intel_la-anv_ge
On Sun, Mar 19, 2017 at 3:03 PM, Emil Velikov wrote:
> Hi Grazvydas,
>
> On 17 March 2017 at 22:05, Grazvydas Ignotas wrote:
>> Fixes build without vulkan.h installed in system header locations:
>> CC vulkan/vulkan_libvulkan_intel_la-anv_gem.lo
>> In file included from vulkan/anv_private.
On Sunday, 2017-03-19 10:50:37 -0300, Fabio Estevam wrote:
> Hi Emil,
>
> On Sun, Mar 19, 2017 at 7:57 AM, Emil Velikov
> wrote:
> > On 18 March 2017 at 21:47, Fabio Estevam wrote:
> >> There is no need to use brackets for single line if statements,
> >> so simply remove them.
> >>
> >> Signed-
Hi,
sorry I'm late to the party, now I'll try to answer some of the
questions raised in this thread.
On 11/03/17 12:51, Federico Dossena wrote:
In the last week I've been trying to bring an "old" game back to life,
Star Wars Knights of the old republic (KOTOR, for short). It's from
2003 and
On 18 March 2017 at 12:21, Lionel Landwerlin
wrote:
> Also, we want this in Cc for stable :)
>
That would be a good idea, imho.
Randy, for future patches please check with `git log' for the patch
prefix - "anv: " is the one you want here.
If you can drop the non-existing x...@freedesktop.org emai
On 19 March 2017 at 15:07, Eric Engestrom wrote:
> On Friday, 2017-03-17 13:19:38 +, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> At the moment we look for generator script(s) in builddir while they
>> are in srcdir, and we proceed to generate the tests and expected output
>> in srcdir, wh
On Sunday, 2017-03-19 13:44:30 +, Jan Beich wrote:
> Vinson Lee writes:
>
> > --e 's/[[[:space:]]]+-DNDEBUG\>//g' \
> > --e 's/[[[:space:]]]+-D_GNU_SOURCE\>//g' \
> > --e 's/[[[:space:]]]+-pedantic\>//g' \
> > +-e 's/[[[:space:]]]+-DNDEBUG[[[:space:]]]//g' \
>
On Friday, 2017-03-17 13:19:38 +, Emil Velikov wrote:
> From: Emil Velikov
>
> At the moment we look for generator script(s) in builddir while they
> are in srcdir, and we proceed to generate the tests and expected output
> in srcdir, which is not allowed.
>
> To untangle:
> - look for the
I suggest to keep it simple from a driver perspective and require
applications to use vaSyncSurface
Currently our vaSyncSurface doesn't really do what the name suggests.
All what we do is flushing the command buffers and that for good reasons.
That the application waits for all decoding to comp
On 19 March 2017 at 11:57, Eric Engestrom wrote:
> On Saturday, 2017-03-18 05:18:17 +, Vinson Lee wrote:
>> Fixes: fe56c745b8cb ("Convert sed(1) syntax to be compatible with FreeBSD
>> and OpenBSD")
>
> I'm not sure about that Fixes: tag… you may have seen this issue after
> this commit, but
On Friday, 2017-03-17 13:19:27 +, Emil Velikov wrote:
> From: Emil Velikov
>
> With later commits we'll fix the generators to produce the files in the
> correct location. That in itself will cause an issue since the files
> will be left dangling and make distcheck will fail.
>
> Cc: Matt Tur
On 19 March 2017 at 13:26, Eric Engestrom wrote:
> On Friday, 2017-03-17 13:19:29 +, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> ... or non-executable, in particular.
>
> You'll want to add `-x` if you want to test that too.
>
Since I've dropped the execute bit I should have dropped this
What do you think?
In general that it might work, but basic problem is the API design once
more.
While with VDPAU the steps where applications asks OpenGL to interop
with VDPAU and the two APIs can do all the handshaking internally.
With VA-API we have Application exporting buffers from VA-A
Signed-off-by: Constantine Kharlamov
---
src/gallium/drivers/r600/sb/notes.markdown | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/notes.markdown
b/src/gallium/drivers/r600/sb/notes.markdown
index 056497754a..63c010883d 100644
--- a/src/g
The second check in the old code looked pretty much unreachable, esp.
because it's not obvious that "max_entries" could be zero. To find out
that it was intentional I had to run some checks, and to dig into
the old versions of the file.
So, rewrite the check to make the intention clear.
Signed-of
Hi Emil,
On Sun, Mar 19, 2017 at 7:57 AM, Emil Velikov wrote:
> On 18 March 2017 at 21:47, Fabio Estevam wrote:
>> There is no need to use brackets for single line if statements,
>> so simply remove them.
>>
>> Signed-off-by: Fabio Estevam
> R-b and pushed to master.
>
> I'm wondering if piping
Hi Peter,
Adding Michel and Marek for the Mesa interop side and Harry for the
display side.
How do you want us to display the decoded surfaces?
Well to make a long story short: I don't have the slightest idea.
Ideally we would of the same handling as Intel so that you guys don't
have anythi
Vinson Lee writes:
> --e 's/[[[:space:]]]+-DNDEBUG\>//g' \
> --e 's/[[[:space:]]]+-D_GNU_SOURCE\>//g' \
> --e 's/[[[:space:]]]+-pedantic\>//g' \
> +-e 's/[[[:space:]]]+-DNDEBUG[[[:space:]]]//g' \
> +-e 's/[[[:space:]]]+-D_GNU_SOURCE[[[:space:]]]//g' \
> +
On Friday, 2017-03-17 13:19:29 +, Emil Velikov wrote:
> From: Emil Velikov
>
> ... or non-executable, in particular.
You'll want to add `-x` if you want to test that too.
>
> Signed-off-by: Emil Velikov
> ---
> src/compiler/glsl/tests/warnings-test.sh | 5 +
> 1 file changed, 5 inser
On Friday, 2017-03-17 13:19:37 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Bail out early if the script is not where we expect it to be.
>
> v2: use -f instead of -e. latter returns true on folder(s)
>
> Signed-off-by: Emil Velikov
> ---
> Eric, -r does not distinguish between files an
On Friday, 2017-03-17 18:17:14 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Things should just work (tm) with the default options.
This! ^
> Plus the one we pass is already the default, so just drop it.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom
> ---
> docs/releas
Hi Grazvydas,
On 17 March 2017 at 22:05, Grazvydas Ignotas wrote:
> Fixes build without vulkan.h installed in system header locations:
> CC vulkan/vulkan_libvulkan_intel_la-anv_gem.lo
> In file included from vulkan/anv_private.h:66:0,
> from vulkan/anv_gem.c:31:
> /opt/xo
unused, and mingw doesn't have GetThreadId()
Signed-off-by: Miklós Máté
---
include/c11/threads_win32.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/c11/threads_win32.h b/include/c11/threads_win32.h
index 649baa1ee8..83ecce24f3 100644
--- a/include/c11/threads_win32.h
+++ b/incl
uintprt_t needs this
Signed-off-by: Miklós Máté
---
include/c11/threads_win32.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/c11/threads_win32.h b/include/c11/threads_win32.h
index d017c31c34..649baa1ee8 100644
--- a/include/c11/threads_win32.h
+++ b/include/c11/threads_win32.h
@@
After this series the build goes further, but eventually stops with:
scons: Building targets ...
Archiving build\windows-x86-debug\gallium\auxiliary\libgallium.a ...
Installing build\windows-x86-debug\bin\u_atomic_test.exe ...
Compiling src\gallium\tests\unit\u_format_compatible_test.c ...
The
On Saturday, 2017-03-18 05:18:17 +, Vinson Lee wrote:
> Fixes: fe56c745b8cb ("Convert sed(1) syntax to be compatible with FreeBSD and
> OpenBSD")
I'm not sure about that Fixes: tag… you may have seen this issue after
this commit, but it's unrelated, code-wise.
I don't really care though, and
> -Original Message-
> From: Landwerlin, Lionel G
> Sent: Saturday, March 18, 2017 8:21 PM
> To: Xu, Randy ; mesa-dev@lists.freedesktop.org
> Cc: x...@freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] Vulkan: Solve the vkCmdClearColorImage
> crash issue
>
> Thanks Randy!
Welcome, it's my
On 18 March 2017 at 21:47, Fabio Estevam wrote:
> There is no need to use brackets for single line if statements,
> so simply remove them.
>
> Signed-off-by: Fabio Estevam
R-b and pushed to master.
I'm wondering if piping the whole kmscube repo through something like
[the kernel's] checkpatch wo
Reviewed-by: Bas Nieuwenhuizen
On Sun, Mar 19, 2017 at 5:18 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This was meant to be checking the index type to get the correct
> index not the last emitted one. This fixes:
> dEQP-VK.pipeline.input_assembly.primitive_restart.index_type_uint32.triangle
From: Dave Airlie
This is an instance property not a device one.
Fixes:
dEQP-VK.api.info.device.extensions
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv
On Sun, Mar 19, 2017 at 10:45:59AM +0200, Pohjolainen, Topi wrote:
> On Thu, Mar 16, 2017 at 01:02:00PM -0700, Francisco Jerez wrote:
> > Jason Ekstrand writes:
> >
> > > Thanks for tracking this down!
> > >
> > > Reviewed-by: Jason Ekstrand
> > >
> > > I'm not sure how we missed this when CS wa
On Thu, Mar 16, 2017 at 01:02:00PM -0700, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
> > Thanks for tracking this down!
> >
> > Reviewed-by: Jason Ekstrand
> >
> > I'm not sure how we missed this when CS was brought up. Oh well.
> >
>
> I don't think we did. The hardware docs are somew
From: Dave Airlie
The ordering NIR gives us is correct for the hw, this fixes:
dEQP-VK.glsl.texture_functions.texturegrad.* (mainly trigged
on isampler/usampler 3d textures.).
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
67 matches
Mail list logo
