On Mon, Jul 24, 2017 at 5:03 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Buffers should report dedicated flags as well, so report the
> same information for them as for images.
>
> (alternately we can turn dedicated off for buffers maybe?)
>
> Fixes CTS dEQP-VK.api.external.memory.opaque_fd.de
Reviewed-by: Bas Nieuwenhuizen
On Mon, Jul 24, 2017 at 4:51 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If we get an fd, we need to close it before returning.
>
> Fixes CTS test
> dEQP-VK.api.external.memory.opaque_fd.dedicated.device_only.import_multiple_times
>
> Fixes: b70829708a (radv:
Reviewed-by: Bas Nieuwenhuizen
On Mon, Jul 24, 2017 at 8:18 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> The spec says we should return VK_ERROR_FEATURE_NOT_PRESENT.
>
> Ported from anv.
>
> Fixes CTS test dEQP-VK.api.device_init.create_device_unsupported_features
>
> Signed-off-by: Dave Airl
From: Dave Airlie
The spec says we should return VK_ERROR_FEATURE_NOT_PRESENT.
Ported from anv.
Fixes CTS test dEQP-VK.api.device_init.create_device_unsupported_features
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_device.c | 13 +
1 file changed, 13 insertions(+)
diff --g
I just remembered that we never merged these. IIRC, it's about 3% on
Manhattan.
On June 14, 2017 6:54:41 PM Jason Ekstrand wrote:
We already have this little optimization for color clears. Now that
we're actually tracking whether or not a slice has any fast-clear
blocks, It's easy enough t
On Mon, Jul 24, 2017 at 1:00 PM, Tomasz Figa wrote:
> On Wed, Jul 12, 2017 at 1:34 AM, Rob Herring wrote:
>> On Tue, Jul 11, 2017 at 9:34 AM, Tomasz Figa wrote:
>>> On Tue, Jul 11, 2017 at 11:16 PM, Rob Herring wrote:
On Tue, Jul 11, 2017 at 8:27 AM, Emil Velikov
wrote:
> From:
On Wed, Jul 12, 2017 at 1:34 AM, Rob Herring wrote:
> On Tue, Jul 11, 2017 at 9:34 AM, Tomasz Figa wrote:
>> On Tue, Jul 11, 2017 at 11:16 PM, Rob Herring wrote:
>>> On Tue, Jul 11, 2017 at 8:27 AM, Emil Velikov
>>> wrote:
From: Emil Velikov
As said in the EGL_KHR_platform_andr
---
src/mesa/drivers/dri/i965/brw_context.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index d0b22d4..426adfa 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_c
Here we also make use of the UseSTD430AsDefaultPacking constant
and call the new get_internal_ifc_packing() helper.
---
src/compiler/glsl/ir_optimization.h | 2 +-
src/compiler/glsl/link_uniform_blocks.cpp | 17 +++
src/compiler/glsl/link_uniforms.cpp | 50
This is used to avoid code duplication when selecting the
packing type for shared and packed layouts.
---
src/compiler/glsl_types.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/compiler/glsl_types.h b/src/compiler/glsl_types.h
index f67465e..3c18f6c 100644
--- a/s
This will be used to enable the STD430 layout as the default for
UBOs and SSBOs with layouts of shared/packed rather than STD140.
---
src/mesa/main/mtypes.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 4970329..751ff7c 100644
--
shared (the default) and packed layouts are decided by the implementation.
Currently we just pack them using the std140 layout. This change makes it so
we use the slightly more compact std430 layout on i965.
The number of changes in patch 4 is a little unfortunate however I decided this
was better
This allows us to drop the duplicate gl_uniform_block_packing enum.
---
src/compiler/glsl/link_uniform_blocks.cpp | 11 +--
src/compiler/glsl_types.h | 9 ++---
src/compiler/shader_enums.h | 7 +++
src/mesa/main/mtypes.h| 11 +
From: Dave Airlie
Buffers should report dedicated flags as well, so report the
same information for them as for images.
(alternately we can turn dedicated off for buffers maybe?)
Fixes CTS dEQP-VK.api.external.memory.opaque_fd.dedicated.buffer.info
Fixes: b70829708a (radv: Implement VK_KHR_ext
Reciewed-by: Jason Ekstrand
On July 23, 2017 7:51:44 PM Dave Airlie wrote:
From: Dave Airlie
If we get an fd, we need to close it before returning.
Fixes CTS test
dEQP-VK.api.external.memory.opaque_fd.dedicated.device_only.import_multiple_times
Fixes: b70829708a (radv: Implement VK_KHR
From: Dave Airlie
If we get an fd, we need to close it before returning.
Fixes CTS test
dEQP-VK.api.external.memory.opaque_fd.dedicated.device_only.import_multiple_times
Fixes: b70829708a (radv: Implement VK_KHR_external_memory)
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_device.c | 4
Can you explain in the comment how/why this fixes the crash? It's not
obvious to me.
Patch looks OK, AFAICT.
Reviewed-by: Brian Paul
On 07/23/2017 05:37 PM, Charmaine Lee wrote:
With this patch, framebuffer interface hash table is created
per state tracker manager.
Fixes crash with steam
https://bugs.freedesktop.org/show_bug.cgi?id=101867
Michel Dänzer changed:
What|Removed |Added
Attachment #132819|0 |1
is obsolete|
On 24/07/17 10:44, Mike Lothian wrote:
I think you also need to provide info on how much of a speed up it
provides because some games are slower with glthread
Providing the CPU and GPU combo used for testing would also be useful so
it can be noted in the commit message. This would be useful if
please see the comment in patch 1. Otherwise 1-2 are:
Reviewed-by: Timothy Arceri
On 21/07/17 22:42, Samuel Pitoiset wrote:
This is similar to other functions that create objects.
Signed-off-by: Samuel Pitoiset
---
src/mesa/main/samplerobj.c | 16
1 file changed, 12 inser
On 21/07/17 22:42, Samuel Pitoiset wrote:
To return GL_OUT_OF_MEMORY if NewSamplerObject fails.
Signed-off-by: Samuel Pitoiset
---
src/mesa/main/samplerobj.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
38-43:
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Saturday, July 22, 2017 2:28:06 AM PDT Chris Wilson wrote:
> Considering the prevalence of sse4.1, another candidate is
> brw_get_buffer_subdata(), we could use a WC map there as well.
Your thinking is...avoid polluting the CPU cache, since we're basically
going to be reading a continuous chunk
I think you also need to provide info on how much of a speed up it provides
because some games are slower with glthread
On Mon, 24 Jul 2017 at 01:33 siyia wrote:
> sorry executable is "mb_warband_linux" start.sh or mb_warband.sh are
> local scripts to start the game so:
>
>
>
>
sorry executable is "mb_warband_linux" start.sh or mb_warband.sh are
local scripts to start the game so:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
~30% perfomance increase
name= siyia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 22/07/17 03:39, Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
---
src/mesa/main/arrayobj.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 77c0206ecf..60a24663f7 100644
--- a/s
With this patch, framebuffer interface hash table is created
per state tracker manager.
Fixes crash with steam.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101876
Fixes: 5124bf98239 ("st/mesa: add destroy_drawable interface")
Tested-by: Christoph Haag
---
src/gallium/include/state_tr
If I try and compile mesa with clang (even using ld.bfd) I get these errors:
libtool: link: clang++ -m32 -fvisibility=hidden -Werror=pointer-arith
-Werror=vla -O2 -march=native -pipe -Wall -fno-math-errno
-fno-trapping-math -Qunused-arguments -O2 -march=native -pipe -fuse-ld=bfd
-o glsl_compiler g
This is only an issue when using ld.gold, ld.bfd works fine which is
probably why no one else has seen it. It only started being a problem when
the dmabuff stuff landed and the makefiles were cleaned up
I tried playing around with the dummy.cpp but I couldn't get it to trigger
the c++ compiler
On
The image is set on Memory allocation already, but the image doesn't
have to have the BindImageMemory called yet. Luckily, we know offset
within a BO has to be 0 for dedicated allocations, so we can just
use the dummy 0 in the address calaculations.
Fixes CTS test
dEQP-VK.api.external.memory.opaq
I'll be pushing already 1/2 and keep this on hold to see whether we
favor instead:
https://lists.freedesktop.org/archives/mesa-dev/2017-July/163730.html
On Thu, 2017-07-20 at 01:44 +0300, Andres Gomez wrote:
> This fixes `make distcheck`
>
> > make[3]: *** No rule to make target
> > 'drivers/dr
On Mon, 2017-07-24 at 01:27 +0300, Andres Gomez wrote:
> This is:
>
> Reviewed-by: Andres Gomez
Mmmm ... I hit the send button too quickly.
Just wanted to mention that I share the same concerns than Daniel.
Would it be up to me, I would not be adding the generated files in the
release but I rea
This is:
Reviewed-by: Andres Gomez
On Fri, 2017-07-21 at 13:02 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> At dist/distcheck time we need to ensure that all the files and their
> respective dependencies are handled.
>
> At the moment we'll bail out as the linux-dmabuf rules are guard
This just sets them to INVALID COLOR, instead of shifting the
attachments together.
This also fixes a number of cases where we use it first and only
then check if it is VK_ATTACHMENT_UNUSED.
Signed-off-by: Bas Nieuwenhuizen
Fixes: f4e499ec791 "radv: add initial non-conformant radv vulkan driver
2017-07-23 13:24 GMT+02:00 Wladimir J. van der Laan :
> Fill the entire array instead of just a quarter. This avoids
> crashes with large shaders.
> (currently this never causes a problem because shaders larger than 2048/4
> instructions are not supported by this driver on any hardware, but it will
On Jul 23, 2017, at 1:51 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
On Sun, Jul 23, 2017 at 12:27 PM, Kyriazis, George
mailto:george.kyria...@intel.com>> wrote:
On Jul 23, 2017, at 11:21 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
On Sun, Jul 23, 2017 at 12:08 PM, George Ky
On Jul 23, 2017, at 1:42 PM, Rowley, Timothy O
mailto:timothy.o.row...@intel.com>> wrote:
On Jul 23, 2017, at 11:08 AM, George Kyriazis
mailto:george.kyria...@intel.com>> wrote:
The shader that is used to copy vertex data out of the vs/gs shaders to
the user-specified buffer (streamout os SO
On Sun, Jul 23, 2017 at 12:27 PM, Kyriazis, George
wrote:
>
> On Jul 23, 2017, at 11:21 AM, Ilia Mirkin wrote:
>
> On Sun, Jul 23, 2017 at 12:08 PM, George Kyriazis
> wrote:
>
> The shader that is used to copy vertex data out of the vs/gs shaders to
> the user-specified buffer (streamout os SO s
> On Jul 23, 2017, at 11:08 AM, George Kyriazis
> wrote:
>
> The shader that is used to copy vertex data out of the vs/gs shaders to
> the user-specified buffer (streamout os SO shader) was not using the
> correct offsets.
>
> Adjust the offsets that are used just for the SO shader:
> - Make s
This approach is generally right but implemented in the wrong place.
This "lowerPOW" happens pre-ssa. What actually needs to happen is that
this type of optimization is done at SSA time as part of
ConstantFolding. And the fallback for POW should be implemented as
part of the "legalize" step. That w
On Jul 23, 2017, at 11:21 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
On Sun, Jul 23, 2017 at 12:08 PM, George Kyriazis
mailto:george.kyria...@intel.com>> wrote:
The shader that is used to copy vertex data out of the vs/gs shaders to
the user-specified buffer (streamout os SO shader) wa
Just a small patch to save a small amount of cycles, as it would be better
to use the initialization list here.
Bare with me if I sent this wrong, I don't typically use git-send-email.
Mystro256 (1):
amdgpu/addrlib: use initialization list in addrobject
src/amd/addrlib/core/addrobject.cpp | 4
---
src/amd/addrlib/core/addrobject.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/addrlib/core/addrobject.cpp
b/src/amd/addrlib/core/addrobject.cpp
index dcdb1bf..ee2d9a9 100644
--- a/src/amd/addrlib/core/addrobject.cpp
+++ b/src/amd/addrlib/core/addrobject.c
On Sun, Jul 23, 2017 at 12:08 PM, George Kyriazis
wrote:
> The shader that is used to copy vertex data out of the vs/gs shaders to
> the user-specified buffer (streamout os SO shader) was not using the
> correct offsets.
>
> Adjust the offsets that are used just for the SO shader:
> - Make sure th
The shader that is used to copy vertex data out of the vs/gs shaders to
the user-specified buffer (streamout os SO shader) was not using the
correct offsets.
Adjust the offsets that are used just for the SO shader:
- Make sure that position is handled in the same special way
as in the vs/gs shad
Fill the entire array instead of just a quarter. This avoids
crashes with large shaders.
(currently this never causes a problem because shaders larger than 2048/4
instructions are not supported by this driver on any hardware, but it will
cause problems in the future)
Signed-off-by: Wladimir J. van
https://bugs.freedesktop.org/show_bug.cgi?id=97957
--- Comment #21 from Marcin Mielniczuk ---
Thanks for fixing! I had a similar problems when using the modesetting driver,
I'll check if it's gone when this gets into a release.
For completeness, I describe how the modesetting driver behaves wit
48 matches
Mail list logo
