This just removes the anv vector code and uses the new helper.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reproduces this commit :
commit 2213ffdb4b
Author: Kenneth Graunke <kenneth@whitecape.org>
Date: Mon Jun 6 21:37:34 2016 -0700
i965: Allocate scratch space for the maximum number of compute threads.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we were relying on the fact that VALGRIND_MEMPOOL_FREE came
later on in the function to prevent "link->bo = bo" from causing an invalid
write. However, in the case where the size requested by the user is very
small (less than sizeof(struct anv_bo)), this isn't sufficient. Instead,
we should call VALGRIND_MEMPOOL_FREE early and then use VG_NOACCESS_WRITE.
We do, however, have to call VALGRIND_MEMPOOL_FREE after reading bo_in
because it may be stored in the bo itself.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Generated by:
sed -i -e 's/brw_device_info/gen_device_info/g' src/intel/**/*.c
sed -i -e 's/brw_device_info/gen_device_info/g' src/intel/**/*.h
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.c
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.cpp
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.h
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The build systems already add this as applicable. There's no need to
have this in the source file.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
We cast he constant 0xfff values to a uintptr_t before applying a bitwise
negate to ensure that they are actually 64-bit when needed. Also, the
count variable doesn't need to be explicitly cast, it will get upcast as
needed by the "|" operation.
Previously we asserted every time you tried to pack a pointer and a counter
together. However, this wasn't really correct. In the case where you try
to grab the last element of the list, the "next elemnet" value you get may
be bogus if someonoe else got there first. This was leading to assertion
failures even though the allocator would safely fall through to the failure
case below.
