Re: [Mesa-dev] [PATCH 1/4] anv/cmd_buffer: never shrink the push constant buffer size
On Sun, 2018-07-01 at 17:33 +0100, Lionel Landwerlin wrote:
> I reread the discussion you had with Jason in order to figure out
> why
> this change is required.
> Maybe adding a comment at the top of the function would be a good bit
> of
> documentation for future developers ;)
Sure, I will add that.
> Regardless this series is :
>
> Reviewed-by: Lionel Landwerlin
Thanks, I'll push the first 3 for now.
> Thanks!
>
> On 29/06/18 09:10, Iago Toral Quiroga wrote:
> > If we have to re-emit push constant data, we need to re-emit all
> > of it.
> > ---
> > src/intel/vulkan/anv_cmd_buffer.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_cmd_buffer.c
> > b/src/intel/vulkan/anv_cmd_buffer.c
> > index 33687920a38..3e9f000f7b8 100644
> > --- a/src/intel/vulkan/anv_cmd_buffer.c
> > +++ b/src/intel/vulkan/anv_cmd_buffer.c
> > @@ -166,6 +166,7 @@
> > anv_cmd_buffer_ensure_push_constants_size(struct anv_cmd_buffer
> > *cmd_buffer,
> >anv_batch_set_error(&cmd_buffer->batch,
> > VK_ERROR_OUT_OF_HOST_MEMORY);
> >return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
> > }
> > + (*ptr)->size = size;
> > } else if ((*ptr)->size < size) {
> > *ptr = vk_realloc(&cmd_buffer->pool->alloc, *ptr, size, 8,
> >VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
> > @@ -173,8 +174,8 @@
> > anv_cmd_buffer_ensure_push_constants_size(struct anv_cmd_buffer
> > *cmd_buffer,
> >anv_batch_set_error(&cmd_buffer->batch,
> > VK_ERROR_OUT_OF_HOST_MEMORY);
> >return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
> > }
> > + (*ptr)->size = size;
> > }
> > - (*ptr)->size = size;
> >
> > return VK_SUCCESS;
> > }
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] anv/cmd_buffer: make descriptors dirty when emitting base state address
On Sun, 2018-07-01 at 18:32 -0500, Jason Ekstrand wrote:
> 1-3 are R-b me. Should we cc stable?
Yes, I think these should go to stable.
> On June 29, 2018 03:11:00 Iago Toral Quiroga
> wrote:
>
> > Every time we emit a new state base address we will need to re-emit
> > our
> > binding tables, since they might have been emitted with a different
> > base
> > state adress.
> > ---
> > src/intel/vulkan/genX_cmd_buffer.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > b/src/intel/vulkan/genX_cmd_buffer.c
> > index 66d1ef7d786..611311904e6 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -67,6 +67,11 @@ genX(cmd_buffer_emit_state_base_address)(struct
> > anv_cmd_buffer *cmd_buffer)
> > {
> >struct anv_device *device = cmd_buffer->device;
> >
> > + /* If we are emitting a new state base address we probably need
> > to re-emit
> > +* binding tables.
> > +*/
> > + cmd_buffer->state.descriptors_dirty |= ~0;
> > +
> >/* Emit a render target cache flush.
> > *
> > * This isn't documented anywhere in the PRM. However, it seems
> > to be
> > --
> > 2.14.1
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] anv/cmd_buffer: only emit state base address if the address changes
On Sun, 2018-07-01 at 18:30 -0500, Jason Ekstrand wrote:
> On June 29, 2018 03:11:00 Iago Toral Quiroga
> wrote:
>
> > ---
> > src/intel/vulkan/anv_private.h | 5 +
> > src/intel/vulkan/genX_cmd_buffer.c | 12 +++-
> > 2 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_private.h
> > b/src/intel/vulkan/anv_private.h
> > index 510471da602..1a9ab7013f2 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -1989,6 +1989,11 @@ struct anv_cmd_state {
> > * is one of the states in render_pass_states.
> > */
> >struct anv_state null_surface_state;
> > +
> > + /**
> > +* Current state base address.
> > +*/
> > + struct
> > anv_address base_state_address;
> > };
> >
> > struct anv_cmd_pool {
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > b/src/intel/vulkan/genX_cmd_buffer.c
> > index 611311904e6..2847e0b30c9 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -67,6 +67,12 @@ genX(cmd_buffer_emit_state_base_address)(struct
> > anv_cmd_buffer *cmd_buffer)
> > {
> >struct anv_device *device = cmd_buffer->device;
> >
> > + struct anv_address new_base_address =
> > + anv_cmd_buffer_surface_base_address(cmd_buffer);
> > + if (new_base_address.bo == cmd_buffer-
> > >state.base_state_address.bo &&
> > + new_base_address.offset == cmd_buffer-
> > >state.base_state_address.offset)
> > + return;
> > +
> >/* If we are emitting a new state base address we probably need
> > to re-emit
> > * binding tables.
> > */
> > @@ -90,8 +96,7 @@ genX(cmd_buffer_emit_state_base_address)(struct
> > anv_cmd_buffer *cmd_buffer)
> > sba.GeneralStateMemoryObjectControlState = GENX(MOCS);
> > sba.GeneralStateBaseAddressModifyEnable = true;
> >
> > - sba.SurfaceStateBaseAddress =
> > - anv_cmd_buffer_surface_base_address(cmd_buffer);
> > + sba.SurfaceStateBaseAddress = new_base_address;
> > sba.SurfaceStateMemoryObjectControlState = GENX(MOCS);
> > sba.SurfaceStateBaseAddressModifyEnable = true;
> >
> > @@ -1521,9 +1526,6 @@ genX(CmdExecuteCommands)(
> >/* Each of the secondary command buffers will use its own state
> > base
> > * address. We need to re-emit state base address for the
> > primary after
> > * all of the secondaries are done.
> > -*
> > -* TODO: Maybe we want to make this a dirty bit to avoid extra
> > state base
> > -* address calls?
>
> I don't think this is correct. When a secondary executes, we have
> to
> reemit STATE_BASE_ADDRESS because the secondary used it's own and we
> need
> to set it back for the primary. The comment above was saying that we
> can
> probably avoid it if we have a bunch of ExecuteCommands calls back to
> back
> or if the last thing in the batch is a call out to a secondary.
> As is, I
> think this patch will cause problems in the case where the client
> uses a
> secondary followed by rendering in the primary. Have I missed
> something?
I shouldn't remove the comment since this patche doesn't address that
TODO, we still emit the state base address for the primary below, the
only change in here is that if the base state address of the primary is
the same as the one for the secondaries we won't actually emit the
state packet, but that should be fine. Maybe you thought I was removing
the line below?
>
> > */
> >genX(cmd_buffer_emit_state_base_address)(primary);
> > }
> > --
> > 2.14.1
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: move all LLVM module initialization into ac_create_module
On 30 June 2018 at 14:54, Marek Olšák wrote: > From: Marek Olšák > > This removes some ugly code around module initialization. Reviewed-by: Dave Airlie > --- > Dave, please rebase your code on top of this, and we don't need triple > and data_layout in ac_llvm_compiler_info. > Cool thanks, Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] From List: Check if the window is non-NULL before setting swap interval.
This fixes crash due to NULL window when swap interval is set for pbuffer surface. Jira: 61995 Test: CtsDisplayTestCases pass Signed-off-by: samiuddi --- src/egl/drivers/dri2/platform_android.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index ca8708a..b5b960a 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -485,7 +485,7 @@ droid_swap_interval(_EGLDriver *drv, _EGLDisplay *dpy, struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf); struct ANativeWindow *window = dri2_surf->window; - if (window->setSwapInterval(window, interval)) + if (window && window->setSwapInterval(window, interval)) return EGL_FALSE; surf->SwapInterval = interval; -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: winsys/amdgpu: include missing pthread.h header
Reviewed-by: Bas Nieuwenhuizen
On Mon, Jul 2, 2018 at 1:25 AM, Mauro Rossi wrote:
> pthread types are used in some files without explicitely including pthread.h.
> This leads to compile errors on Android 7.x nougat-x86
> e.g. in src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
>
> In file included from
> external/mesa/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c:31:
> In file included from
> external/mesa/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h:32:
> external/mesa/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h:52:2: error:
> unknown type name 'pthread_mutex_t'
> pthread_mutex_t global_bo_list_lock;
> ^
> 1 error generated.
>
> Including pthread.h explicitely solves the building error
>
> Signed-off-by: Mauro Rossi
> ---
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
> b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
> index d6af6052a6..40d35d557b 100644
> --- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
> +++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
> @@ -33,6 +33,7 @@
> #include "addrlib/addrinterface.h"
> #include
> #include "util/list.h"
> +#include
>
> struct radv_amdgpu_winsys {
> struct radeon_winsys base;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] amd: remove support for LLVM 5.0
Reviewed-by: Timothy Arceri
On 02/07/18 05:50, Marek Olšák wrote:
From: Marek Olšák
Users are encouraged to switch to LLVM 6.0 released in March 2018.
---
.travis.yml | 24 ++--
configure.ac | 4 +-
meson.build | 4 +-
src/amd/common/ac_llvm_build.c| 129 +-
src/amd/common/ac_llvm_helper.cpp | 4 -
src/gallium/drivers/radeonsi/si_shader.c | 24
src/gallium/drivers/radeonsi/si_shader_nir.c | 7 --
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 8 +-
8 files changed, 45 insertions(+), 159 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 012cc91..2f04747 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -118,37 +118,37 @@ matrix:
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
- LABEL="make Gallium Drivers RadeonSI"
- BUILD=make
- MAKEFLAGS="-j4"
- MAKE_CHECK_COMMAND="true"
-- LLVM_VERSION=5.0
+- LLVM_VERSION=6.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
- DRI_DRIVERS=""
- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa --disable-nine
--disable-xvmc --disable-vdpau --disable-va --disable-omx-bellagio
--disable-gallium-osmesa"
- GALLIUM_DRIVERS="radeonsi"
- VULKAN_DRIVERS=""
- LIBUNWIND_FLAGS="--enable-libunwind"
addons:
apt:
sources:
-- llvm-toolchain-trusty-5.0
+- llvm-toolchain-trusty-6.0
packages:
# LLVM packaging is broken and misses these dependencies
- libedit-dev
# From sources above
-- llvm-5.0-dev
+- llvm-6.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
- LABEL="make Gallium Drivers Other"
- BUILD=make
@@ -251,47 +251,47 @@ matrix:
- libclang-4.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
# NOTE: Analogous to SWR above, building Clover is quite slow.
-- LABEL="make Gallium ST Clover LLVM-5.0"
+- LABEL="make Gallium ST Clover LLVM-6.0"
- BUILD=make
- MAKEFLAGS="-j4"
- MAKE_CHECK_COMMAND="true"
-- LLVM_VERSION=5.0
+- LLVM_VERSION=6.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
- OVERRIDE_CC=gcc-4.8
- OVERRIDE_CXX=g++-4.8
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
- DRI_DRIVERS=""
- GALLIUM_ST="--disable-dri --enable-opencl --enable-opencl-icd
--enable-llvm --disable-xa --disable-nine --disable-xvmc --disable-vdpau --disable-va
--disable-omx-bellagio --disable-gallium-osmesa"
- GALLIUM_DRIVERS="r600,radeonsi"
- VULKAN_DRIVERS=""
- LIBUNWIND_FLAGS="--enable-libunwind"
addons:
apt:
sources:
-- llvm-toolchain-trusty-5.0
+- llvm-toolchain-trusty-6.0
packages:
- libclc-dev
# LLVM packaging is broken and misses these dependencies
- libedit-dev
- g++-4.8
# From sources above
-- llvm-5.0-dev
-- clang-5.0
-- libclang-5.0-dev
+- llvm-6.0-dev
+- clang-6.0
+- libclang-6.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
# NOTE: Analogous to SWR above, building Clover is quite slow.
- LABEL="make Gallium ST Clover LLVM-6.0"
@@ -359,37 +359,37 @@ matrix:
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
- LABEL="make Vulkan"
- BUILD=make
- MAKEFLAGS="-j4"
- MAKE_CHECK_COMMAND="make -C src/gtest check && make -C src/intel
check"
-- LLVM_VERSION=5.0
+- LLVM_VERSION=6.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl
--with-platforms=x11,wayland"
- DRI_DRIVERS=""
- GALLIUM_ST="--enable-dri --enable-dri3 --disable-opencl --dis
Re: [Mesa-dev] [PATCH 3/4] anv/cmd_buffer: make descriptors dirty when emitting base state address
1-3 are R-b me. Should we cc stable?
On June 29, 2018 03:11:00 Iago Toral Quiroga wrote:
Every time we emit a new state base address we will need to re-emit our
binding tables, since they might have been emitted with a different base
state adress.
---
src/intel/vulkan/genX_cmd_buffer.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 66d1ef7d786..611311904e6 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -67,6 +67,11 @@ genX(cmd_buffer_emit_state_base_address)(struct
anv_cmd_buffer *cmd_buffer)
{
struct anv_device *device = cmd_buffer->device;
+ /* If we are emitting a new state base address we probably need to re-emit
+* binding tables.
+*/
+ cmd_buffer->state.descriptors_dirty |= ~0;
+
/* Emit a render target cache flush.
*
* This isn't documented anywhere in the PRM. However, it seems to be
--
2.14.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] anv/cmd_buffer: only emit state base address if the address changes
On June 29, 2018 03:11:00 Iago Toral Quiroga wrote:
---
src/intel/vulkan/anv_private.h | 5 +
src/intel/vulkan/genX_cmd_buffer.c | 12 +++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 510471da602..1a9ab7013f2 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1989,6 +1989,11 @@ struct anv_cmd_state {
* is one of the states in render_pass_states.
*/
struct anv_state null_surface_state;
+
+ /**
+* Current state base address.
+*/
+ struct anv_address base_state_address;
};
struct anv_cmd_pool {
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 611311904e6..2847e0b30c9 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -67,6 +67,12 @@ genX(cmd_buffer_emit_state_base_address)(struct
anv_cmd_buffer *cmd_buffer)
{
struct anv_device *device = cmd_buffer->device;
+ struct anv_address new_base_address =
+ anv_cmd_buffer_surface_base_address(cmd_buffer);
+ if (new_base_address.bo == cmd_buffer->state.base_state_address.bo &&
+ new_base_address.offset == cmd_buffer->state.base_state_address.offset)
+ return;
+
/* If we are emitting a new state base address we probably need to re-emit
* binding tables.
*/
@@ -90,8 +96,7 @@ genX(cmd_buffer_emit_state_base_address)(struct
anv_cmd_buffer *cmd_buffer)
sba.GeneralStateMemoryObjectControlState = GENX(MOCS);
sba.GeneralStateBaseAddressModifyEnable = true;
- sba.SurfaceStateBaseAddress =
- anv_cmd_buffer_surface_base_address(cmd_buffer);
+ sba.SurfaceStateBaseAddress = new_base_address;
sba.SurfaceStateMemoryObjectControlState = GENX(MOCS);
sba.SurfaceStateBaseAddressModifyEnable = true;
@@ -1521,9 +1526,6 @@ genX(CmdExecuteCommands)(
/* Each of the secondary command buffers will use its own state base
* address. We need to re-emit state base address for the primary after
* all of the secondaries are done.
-*
-* TODO: Maybe we want to make this a dirty bit to avoid extra state base
-* address calls?
I don't think this is correct. When a secondary executes, we have to
reemit STATE_BASE_ADDRESS because the secondary used it's own and we need
to set it back for the primary. The comment above was saying that we can
probably avoid it if we have a bunch of ExecuteCommands calls back to back
or if the last thing in the batch is a call out to a secondary. As is, I
think this patch will cause problems in the case where the client uses a
secondary followed by rendering in the primary. Have I missed something?
*/
genX(cmd_buffer_emit_state_base_address)(primary);
}
--
2.14.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: winsys/amdgpu: include missing pthread.h header
pthread types are used in some files without explicitely including pthread.h.
This leads to compile errors on Android 7.x nougat-x86
e.g. in src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
In file included from
external/mesa/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c:31:
In file included from
external/mesa/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h:32:
external/mesa/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h:52:2: error:
unknown type name 'pthread_mutex_t'
pthread_mutex_t global_bo_list_lock;
^
1 error generated.
Including pthread.h explicitely solves the building error
Signed-off-by: Mauro Rossi
---
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
index d6af6052a6..40d35d557b 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
@@ -33,6 +33,7 @@
#include "addrlib/addrinterface.h"
#include
#include "util/list.h"
+#include
struct radv_amdgpu_winsys {
struct radeon_winsys base;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 4/4] gallium/llvmpipe: Enable support bptc format.
Thank you.
Best regards,
Denis.
On Sun, Jul 1, 2018, 10:44 PM Marek Olšák wrote:
> Pushed, thanks for the patches.
>
> Marek
>
> On Sun, Jul 1, 2018 at 2:25 AM, Denis Pauk wrote:
> > HI Marek,
> >
> > Thank you, could you merge commits?
> >
> > I don't have commit rights.
> >
> > On Sat, Jun 30, 2018 at 12:29 AM Marek Olšák wrote:
> >>
> >> For the series:
> >>
> >> Reviewed-by: Marek Olšák
> >>
> >> Marek
> >>
> >> On Tue, Jun 26, 2018 at 4:30 PM, Denis Pauk
> wrote:
> >> > v2: none
> >> > v3: none
> >> >
> >> > Signed-off-by: Denis Pauk
> >> > CC: Marek Olšák
> >> > CC: Rhys Perry
> >> > CC: Matt Turner
> >> > ---
> >> > src/gallium/drivers/llvmpipe/lp_screen.c | 3 +--
> >> > src/gallium/drivers/llvmpipe/lp_test_format.c | 3 +--
> >> > 2 files changed, 2 insertions(+), 4 deletions(-)
> >> >
> >> > diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
> >> > b/src/gallium/drivers/llvmpipe/lp_screen.c
> >> > index 28dbd9908f..9921a941d5 100644
> >> > --- a/src/gallium/drivers/llvmpipe/lp_screen.c
> >> > +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> >> > @@ -534,8 +534,7 @@ llvmpipe_is_format_supported( struct pipe_screen
> >> > *_screen,
> >> >}
> >> > }
> >> >
> >> > - if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
> >> > - format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
> >> > + if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
> >> >/* Software decoding is not hooked up. */
> >> >return FALSE;
> >> > }
> >> > diff --git a/src/gallium/drivers/llvmpipe/lp_test_format.c
> >> > b/src/gallium/drivers/llvmpipe/lp_test_format.c
> >> > index e9a6e01fdc..a8aa33d8ae 100644
> >> > --- a/src/gallium/drivers/llvmpipe/lp_test_format.c
> >> > +++ b/src/gallium/drivers/llvmpipe/lp_test_format.c
> >> > @@ -388,8 +388,7 @@ test_all(unsigned verbose, FILE *fp)
> >> >}
> >> >
> >> >/* missing fetch funcs */
> >> > - if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
> >> > - format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
> >> > + if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
> >> > continue;
> >> >}
> >> >
> >> > --
> >> > 2.18.0
> >> >
> >
> >
> >
> > --
> > Best regards,
> > Denis.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] amd: remove support for LLVM 5.0
From: Marek Olšák
Users are encouraged to switch to LLVM 6.0 released in March 2018.
---
.travis.yml | 24 ++--
configure.ac | 4 +-
meson.build | 4 +-
src/amd/common/ac_llvm_build.c| 129 +-
src/amd/common/ac_llvm_helper.cpp | 4 -
src/gallium/drivers/radeonsi/si_shader.c | 24
src/gallium/drivers/radeonsi/si_shader_nir.c | 7 --
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 8 +-
8 files changed, 45 insertions(+), 159 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 012cc91..2f04747 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -118,37 +118,37 @@ matrix:
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
- LABEL="make Gallium Drivers RadeonSI"
- BUILD=make
- MAKEFLAGS="-j4"
- MAKE_CHECK_COMMAND="true"
-- LLVM_VERSION=5.0
+- LLVM_VERSION=6.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
- DRI_DRIVERS=""
- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa
--disable-nine --disable-xvmc --disable-vdpau --disable-va
--disable-omx-bellagio --disable-gallium-osmesa"
- GALLIUM_DRIVERS="radeonsi"
- VULKAN_DRIVERS=""
- LIBUNWIND_FLAGS="--enable-libunwind"
addons:
apt:
sources:
-- llvm-toolchain-trusty-5.0
+- llvm-toolchain-trusty-6.0
packages:
# LLVM packaging is broken and misses these dependencies
- libedit-dev
# From sources above
-- llvm-5.0-dev
+- llvm-6.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
- LABEL="make Gallium Drivers Other"
- BUILD=make
@@ -251,47 +251,47 @@ matrix:
- libclang-4.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
# NOTE: Analogous to SWR above, building Clover is quite slow.
-- LABEL="make Gallium ST Clover LLVM-5.0"
+- LABEL="make Gallium ST Clover LLVM-6.0"
- BUILD=make
- MAKEFLAGS="-j4"
- MAKE_CHECK_COMMAND="true"
-- LLVM_VERSION=5.0
+- LLVM_VERSION=6.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
- OVERRIDE_CC=gcc-4.8
- OVERRIDE_CXX=g++-4.8
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
- DRI_DRIVERS=""
- GALLIUM_ST="--disable-dri --enable-opencl --enable-opencl-icd
--enable-llvm --disable-xa --disable-nine --disable-xvmc --disable-vdpau
--disable-va --disable-omx-bellagio --disable-gallium-osmesa"
- GALLIUM_DRIVERS="r600,radeonsi"
- VULKAN_DRIVERS=""
- LIBUNWIND_FLAGS="--enable-libunwind"
addons:
apt:
sources:
-- llvm-toolchain-trusty-5.0
+- llvm-toolchain-trusty-6.0
packages:
- libclc-dev
# LLVM packaging is broken and misses these dependencies
- libedit-dev
- g++-4.8
# From sources above
-- llvm-5.0-dev
-- clang-5.0
-- libclang-5.0-dev
+- llvm-6.0-dev
+- clang-6.0
+- libclang-6.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
# NOTE: Analogous to SWR above, building Clover is quite slow.
- LABEL="make Gallium ST Clover LLVM-6.0"
@@ -359,37 +359,37 @@ matrix:
- x11proto-xf86vidmode-dev
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
- env:
- LABEL="make Vulkan"
- BUILD=make
- MAKEFLAGS="-j4"
- MAKE_CHECK_COMMAND="make -C src/gtest check && make -C src/intel
check"
-- LLVM_VERSION=5.0
+- LLVM_VERSION=6.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl
--with-platforms=x11,wayland"
- DRI_DRIVERS=""
- GALLIUM_ST="--enable-dri --enable-dri3 --disable-opencl --disable-xa
--disable-nine --disable-xvmc --disable-vdpau --disable-va
--disable-omx-bellagio --disable-gallium-osmesa"
- GALLIUM_DRIVERS=""
- VULKAN_DR
Re: [Mesa-dev] [PATCH v3 4/4] gallium/llvmpipe: Enable support bptc format.
Pushed, thanks for the patches.
Marek
On Sun, Jul 1, 2018 at 2:25 AM, Denis Pauk wrote:
> HI Marek,
>
> Thank you, could you merge commits?
>
> I don't have commit rights.
>
> On Sat, Jun 30, 2018 at 12:29 AM Marek Olšák wrote:
>>
>> For the series:
>>
>> Reviewed-by: Marek Olšák
>>
>> Marek
>>
>> On Tue, Jun 26, 2018 at 4:30 PM, Denis Pauk wrote:
>> > v2: none
>> > v3: none
>> >
>> > Signed-off-by: Denis Pauk
>> > CC: Marek Olšák
>> > CC: Rhys Perry
>> > CC: Matt Turner
>> > ---
>> > src/gallium/drivers/llvmpipe/lp_screen.c | 3 +--
>> > src/gallium/drivers/llvmpipe/lp_test_format.c | 3 +--
>> > 2 files changed, 2 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
>> > b/src/gallium/drivers/llvmpipe/lp_screen.c
>> > index 28dbd9908f..9921a941d5 100644
>> > --- a/src/gallium/drivers/llvmpipe/lp_screen.c
>> > +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
>> > @@ -534,8 +534,7 @@ llvmpipe_is_format_supported( struct pipe_screen
>> > *_screen,
>> >}
>> > }
>> >
>> > - if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
>> > - format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
>> > + if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
>> >/* Software decoding is not hooked up. */
>> >return FALSE;
>> > }
>> > diff --git a/src/gallium/drivers/llvmpipe/lp_test_format.c
>> > b/src/gallium/drivers/llvmpipe/lp_test_format.c
>> > index e9a6e01fdc..a8aa33d8ae 100644
>> > --- a/src/gallium/drivers/llvmpipe/lp_test_format.c
>> > +++ b/src/gallium/drivers/llvmpipe/lp_test_format.c
>> > @@ -388,8 +388,7 @@ test_all(unsigned verbose, FILE *fp)
>> >}
>> >
>> >/* missing fetch funcs */
>> > - if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
>> > - format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
>> > + if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
>> > continue;
>> >}
>> >
>> > --
>> > 2.18.0
>> >
>
>
>
> --
> Best regards,
> Denis.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] r600: Add R4G4B4A4 and A1B5G5R5 to supported vertex formats
Below tests would fail with an error message
"Vertex format (R4G4B4A4|R5G5B5A1) not supported."
Add the formate to the translation routine to enable these formats.
Fixes:
dEQP-GLES3.functional.texture.specification.teximage2d_pbo.rgba4_2d
dEQP-GLES3.functional.texture.specification.teximage2d_pbo.rgba4_cube
dEQP-GLES3.functional.texture.specification.teximage2d_pbo.rgb5_a1_2d
dEQP-GLES3.functional.texture.specification.teximage2d_pbo.rgb5_a1_cube
dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgba4_2d
dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgba4_cube
dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgb5_a1_2d
dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgb5_a1_cube
dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgba4_2d_array
dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgba4_3d
dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgb5_a1_2d_array
dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgb5_a1_3d
dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgba4_2d_array
dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgba4_3d
dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgb5_a1_2d_array
dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgb5_a1_3d
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_asm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 427e7856d2..7029be24f4 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -2476,6 +2476,11 @@ void r600_vertex_data_type(enum pipe_format pformat,
return;
}
+ if (pformat == PIPE_FORMAT_A1B5G5R5_UNORM) {
+ *format = FMT_5_5_5_1;
+ return;
+ }
+
desc = util_format_description(pformat);
if (desc->layout != UTIL_FORMAT_LAYOUT_PLAIN) {
goto out_unknown;
@@ -2533,6 +2538,16 @@ void r600_vertex_data_type(enum pipe_format pformat,
/* Signed ints */
case UTIL_FORMAT_TYPE_SIGNED:
switch (desc->channel[i].size) {
+ case 4:
+ switch (desc->nr_channels) {
+ case 2:
+ *format = FMT_4_4;
+ break;
+ case 4:
+ *format = FMT_4_4_4_4;
+ break;
+ }
+ break;
case 8:
switch (desc->nr_channels) {
case 1:
--
2.16.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] r600: force LOD range to be only one value when mip.min filter is NONE
For a texture that has only one LOD defined, but for which
GL_TEXTURE_MAX_LEVEL is the default (1000) and
GL_TEXTURE_MIN_LOD != GL_TEXTURE_MAX_LOD the reading from the texture does
not properly resolve the LOD level and texture lookup might fail. Hence,
when no mipmap filter is given (indicating that no mip-mapping takes place),
force the LOD range to contain only value.
Fixes:
dEQP-GLES3.functional.shaders.texture_functions.texture*.(i|u)sampler2d*
dEQP-GLES3.functional.texture.format.sized.cube.rgb*
out of VK_GL_CTS/android/cts/master/gles3-master.txt
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/evergreen_state.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 5e5e3a0324..b6a01622e4 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -575,14 +575,22 @@ static void *evergreen_create_sampler_state(struct
pipe_context *ctx,
unsigned max_aniso = rscreen->force_aniso >= 0 ? rscreen->force_aniso
: state->max_anisotropy;
unsigned max_aniso_ratio = r600_tex_aniso_filter(max_aniso);
+ float max_lod = state->max_lod;
if (!ss) {
return NULL;
}
+ /* If the min_mip_filter is NONE, then the texture has no mipmapping and
+* MIP_FILTER will also be set to NONE. However, if more then one LOD is
+* configured, then the texture lookup seems to fail for some specific
texture
+* formats. Forcing the number of LODs to one in this case fixes it. */
+ if (state->min_mip_filter == PIPE_TEX_MIPFILTER_NONE)
+ max_lod = state->min_lod;
+
ss->border_color_use = sampler_state_needs_border_color(state);
- /* R_03C000_SQ_TEX_SAMPLER_WORD0_0 */
+/* R_03C000_SQ_TEX_SAMPLER_WORD0_0 */
ss->tex_sampler_words[0] =
S_03C000_CLAMP_X(r600_tex_wrap(state->wrap_s)) |
S_03C000_CLAMP_Y(r600_tex_wrap(state->wrap_t)) |
@@ -596,7 +604,7 @@ static void *evergreen_create_sampler_state(struct
pipe_context *ctx,
/* R_03C004_SQ_TEX_SAMPLER_WORD1_0 */
ss->tex_sampler_words[1] =
S_03C004_MIN_LOD(S_FIXED(CLAMP(state->min_lod, 0, 15), 8)) |
- S_03C004_MAX_LOD(S_FIXED(CLAMP(state->max_lod, 0, 15), 8));
+ S_03C004_MAX_LOD(S_FIXED(CLAMP(max_lod, 0, 15), 8));
/* R_03C008_SQ_TEX_SAMPLER_WORD2_0 */
ss->tex_sampler_words[2] =
S_03C008_LOD_BIAS(S_FIXED(CLAMP(state->lod_bias, -16, 16), 8)) |
--
2.16.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] r600: Fix another bunch of textureing failures
This series fixes another bunch of tests from deqp gles3 and gles31. I didn't see any regressions with piglit gpu -t texture -t gather thanks for reviewing, Gert Gert Wollny (3): r600: force LOD range to be only one value when mip.min filter is NONE r600: Add R4G4B4A4 and A1B5G5R5 to supported vertex formats r600: Scale interger valued texture border colors to float src/gallium/drivers/r600/evergreen_state.c | 78 -- src/gallium/drivers/r600/r600_asm.c| 15 ++ 2 files changed, 88 insertions(+), 5 deletions(-) -- 2.16.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] r600: Scale interger valued texture border colors to float
It seems the hardware always expects floating point border color values
[0,1] for unsigned, and [-1,1] for signed texture component, regardless
of pixel type, but the border colors are passed according to texture
component type. Hence, before submitting the border color, convert and
scale it these ranges accordingly. For some reason this doesn't seem to
work for textures with 32 bit integer components though, here, it seems that
the border color is always set to zero.
Fixes:
dEQP-GLES31.functional.texture.border_clamp.formats.compressed*
dEQP-GLES31.functional.texture.border_clamp.formats.r* (non 32 bit integer)
dEQP-GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d*
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/evergreen_state.c | 66 --
1 file changed, 63 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index b6a01622e4..34ebc73af5 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2405,14 +2405,67 @@ static void evergreen_emit_cs_sampler_views(struct
r600_context *rctx, struct r6
EG_FETCH_CONSTANTS_OFFSET_CS +
R600_MAX_CONST_BUFFERS, RADEON_CP_PACKET3_COMPUTE_MODE);
}
+/* It seems that the border color is passed in the texture format, but
+ * the hardware interprets the color always as signed or unsigned floating
+ * point value (depending on the sign of texture values). So convert the
+ * color values here. This works for channel sizes < 32 bit. It seems, however,
+ * that for 32 bit component integer textures the border color is ignored and
+ * always set to zero.
+ */
+static void evergreen_convert_border_color(union pipe_color_union *in,
+
union pipe_color_union *out,
+
enum pipe_format format)
+{
+ const struct util_format_description *d;
+ bool handle_separate = false;
+
+ if (util_format_is_float(format)) {
+ memcpy(out->f, in->f, 4 * sizeof(float));
+ return;
+ }
+
+ d = util_format_description(format);
+ for (int i = 0; i < d->nr_channels && !handle_separate; ++i) {
+
+ if (d->channel[i].pure_integer) {
+ int cs = d->channel[i].size;
+ if (d->channel[i].type == UTIL_FORMAT_TYPE_SIGNED)
+out->f[i] = (float)((double)(in->i[i]) / ((1ul << (cs - 1)) - 1));
+ else if (d->channel[i].type ==
UTIL_FORMAT_TYPE_UNSIGNED)
+ out->f[i] = (float)((double)(in->ui[i]) / ((1ul
<< cs) - 1));
+
+ } else if (d->channel[i].type != UTIL_FORMAT_TYPE_VOID || i ==
0) {
+ handle_separate = true;
+ } else {
+ /* Assume this is a X channel and just clear border
color component */
+ out->f[i] = 0;
+ }
+ }
+
+ if (handle_separate) {
+ switch (format) {
+ case PIPE_FORMAT_X24S8_UINT:
+ case PIPE_FORMAT_X32_S8X24_UINT:
+ out->f[0] = (float)(in->ui[0] / 255.0);
+ out->f[1] = out->f[2] = out->f[3] = 0.0f;
+ break;
+ default:
+ memcpy(out->f, in->f, 4 * sizeof(float));
+ }
+ }
+}
+
static void evergreen_emit_sampler_states(struct r600_context *rctx,
- struct r600_textures_info *texinfo,
+
struct r600_textures_info *texinfo,
unsigned resource_id_base,
unsigned border_index_reg,
unsigned pkt_flags)
{
struct radeon_cmdbuf *cs = rctx->b.gfx.cs;
uint32_t dirty_mask = texinfo->states.dirty_mask;
+ union pipe_color_union border_color = {{0,0,0,1}};
+ union pipe_color_union *border_color_ptr = &border_color;
+
while (dirty_mask) {
struct r600_pipe_sampler_state *rstate;
@@ -2432,7 +2485,7 @@ static void evergreen_emit_sampler_states(struct
r600_context *rctx,
*/
struct r600_pipe_sampler_view *rview =
texinfo->views.views[i];
if (rview) {
- rstate->tex_sampler_words[0] &= C_03C000_Z_FILTER;
+rstate->tex_sampler_words[0] &= C_03C000_Z_FILTER;
enum pipe_texture_target target =
rview->base.texture->target;
if (target == PIPE_TEXTURE_2D_ARRAY ||
target == PIPE_TEXTURE_CUBE_ARR
Re: [Mesa-dev] [PATCH 1/4] anv/cmd_buffer: never shrink the push constant buffer size
I reread the discussion you had with Jason in order to figure out why
this change is required.
Maybe adding a comment at the top of the function would be a good bit of
documentation for future developers ;)
Regardless this series is :
Reviewed-by: Lionel Landwerlin
Thanks!
On 29/06/18 09:10, Iago Toral Quiroga wrote:
If we have to re-emit push constant data, we need to re-emit all
of it.
---
src/intel/vulkan/anv_cmd_buffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_cmd_buffer.c
b/src/intel/vulkan/anv_cmd_buffer.c
index 33687920a38..3e9f000f7b8 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -166,6 +166,7 @@ anv_cmd_buffer_ensure_push_constants_size(struct
anv_cmd_buffer *cmd_buffer,
anv_batch_set_error(&cmd_buffer->batch, VK_ERROR_OUT_OF_HOST_MEMORY);
return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
}
+ (*ptr)->size = size;
} else if ((*ptr)->size < size) {
*ptr = vk_realloc(&cmd_buffer->pool->alloc, *ptr, size, 8,
VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
@@ -173,8 +174,8 @@ anv_cmd_buffer_ensure_push_constants_size(struct
anv_cmd_buffer *cmd_buffer,
anv_batch_set_error(&cmd_buffer->batch, VK_ERROR_OUT_OF_HOST_MEMORY);
return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
}
+ (*ptr)->size = size;
}
- (*ptr)->size = size;
return VK_SUCCESS;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600: compare structure elements instead of doing a memcmp
From: Gert Wollny
Structures might be padded by the compiler and these padding bytes remain
un-initialized which in turn makes memcmp return a difference where from
the logical point of view there is none.
Fixes valgrind:
Conditional jump or move depends on uninitialised value(s)
at 0x4C32CBA: __memcmp_sse4_1 (vg_replace_strmem.c:1099)
by 0xB8D2537: r600_set_vertex_buffers (r600_state_common.c:573)
by 0xB71D44A: u_vbuf_set_driver_vertex_buffers (u_vbuf.c:1129)
by 0xB71F7BB: u_vbuf_draw_vbo (u_vbuf.c:1153)
by 0xB3B92CB: st_draw_vbo (st_draw.c:235)
by 0xB36B1AE: vbo_draw_arrays (vbo_exec_array.c:391)
by 0xB36BB0D: vbo_exec_DrawArrays (vbo_exec_array.c:550)
by 0x10A989: piglit_display (textureSize.c:157)
by 0x4F8F174: run_test (piglit_fbo_framework.c:52)
by 0x4F7BA12: piglit_gl_test_run (piglit-framework-gl.c:229)
by 0x10A60A: main (textureSize.c:71)
Uninitialised value was created by a stack allocation
at 0xB3948FD: st_update_array (st_atom_array.c:388)
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_state_common.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 1e775e565b..939a14654e 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -570,7 +570,10 @@ static void r600_set_vertex_buffers(struct pipe_context
*ctx,
/* Set vertex buffers. */
if (input) {
for (i = 0; i < count; i++) {
- if (memcmp(&input[i], &vb[i], sizeof(struct
pipe_vertex_buffer))) {
+ if ((input[i].buffer.resource != vb[i].buffer.resource)
||
+ (vb[i].stride != input[i].stride) ||
+ (vb[i].buffer_offset != input[i].buffer_offset) ||
+ (vb[i].is_user_buffer != input[i].is_user_buffer)) {
if (input[i].buffer.resource) {
vb[i].stride = input[i].stride;
vb[i].buffer_offset =
input[i].buffer_offset;
--
2.16.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] mesa/st: draw_vbo: initialize restart_index too
From: Gert Wollny
restart_index is later always used in a comparison, so it should be
initialized properly.
Fixes valgrind warning:
Conditional jump or move depends on uninitialised value(s)
at 0xB8D682F: r600_draw_vbo (r600_state_common.c:2153)
by 0xB71F743: u_vbuf_draw_vbo (u_vbuf.c:1156)
by 0xB3B92DB: st_draw_vbo (st_draw.c:235)
by 0xB36B1AE: vbo_draw_arrays (vbo_exec_array.c:391)
by 0xB36BB0D: vbo_exec_DrawArrays (vbo_exec_array.c:550)
by 0x10A989: piglit_display (textureSize.c:157)
by 0x4F8F174: run_test (piglit_fbo_framework.c:52)
by 0x4F7BA12: piglit_gl_test_run (piglit-framework-gl.c:229)
by 0x10A60A: main (textureSize.c:71)
Uninitialised value was created by a stack allocation
at 0xB3B90B0: st_draw_vbo (st_draw.c:143)
Signed-off-by: Gert Wollny
---
src/mesa/state_tracker/st_draw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 208ea735a7..dee69783ad 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -156,6 +156,7 @@ st_draw_vbo(struct gl_context *ctx,
info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
info.indirect = NULL;
info.count_from_stream_output = NULL;
+ info.restart_index = 0;
if (ib) {
struct gl_buffer_object *bufobj = ib->obj;
--
2.16.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
