Re: [Mesa-dev] Trying to build a opencl dev env

[Jan Vesely]

On Tue, Apr 27, 2021 at 7:50 AM Luke A. Guest  wrote:

>
>
> On 27/04/2021 08:00, Pierre Moreau wrote:
> > Hello Luke,
> >
> > If you set `PKG_CONFIG_PATH=$PATH_TO_LIBCLC_INSTALL/share/pkgconfig` when
> > running meson, it should pick that version instead of the system one.
> >
> > I run it as `PKG_CONFIG_PATH=[…] meson setup […]`; it might also be
> possible to
> > pass it as an argument instead, I do not know.
>
> Thanks for that. It's because I had that var set to
> /lib/pkg-config, libclc installs to /share/pkg-config
> for some unknown reason.
>

that is intentional. as machine-independent libraries, libclc shouldn't be
in $PREFIX/lib/

Jan


> ___
> 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] clover's interface to clang

[Jan Vesely]

On Thu, 2020-11-12 at 06:37 +1000, Dave Airlie wrote:
> On Thu, 12 Nov 2020 at 06:23, Francisco Jerez  wrote:
> > I don't remember the specifics of why we ended up interfacing with Clang
> > this way.  What is technically wrong with it, specifically?  I don't
> > have any objection to switching to the Driver and Compilation interface,
> > nor to translating the "-cl-denorms-are-zero" option to whatever the
> > current option name is so the current Clang interfacing keeps working.
> 
> Currently we pass a bunch of options from the user directly to the
> clang cc1 internals. Up until recently this wasn't a problem as the
> cc1 just happened to allow this and the options matched up. But this
> was only ever a happy accident.
> 
> Now the options don't match up. What you are meant to do is pass the
> options to the clang Driver and it gives you back a cc1 job which has
> the cc1 specific arguments for what you passed to the driver.
> 
> So Driver sees "-cl-denorms-are-zero" and gives us back a compilation
> job for cc1 which has some internal -f flags in it.
> 
> Otherwise clover has to keep track of the internal cc1 flags and remap
> things itself which might not be easily discoverable moving forward.

Clover acts as a clang driver. this shielded clover from the kind of
dance that llvm/clang did around OCL; it now offers 3 different sets
of OCL headers, which might or might not agree on definitions [0], and
one of them might or might not be included by default [1] by the ocl
clang driver.
Using clang driver would reduce clover maintenance wrt clang (since
cc1 interface is unstable), but it will increase maintenance burden
elsewhere (probably libclc to sync with clangs headers, which is now
largely abandoned).

Jan

[0] https://reviews.llvm.org/D83473
[1] https://reviews.llvm.org/D78979

> 
> Dave.
> ___
> 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] [clover] Compilation of latest 'libclc git' with LLVM 11.0.0git need ROCm?! - Didn't hit that ever before.

[Jan Vesely]

On Wed, 2020-04-15 at 06:31 +0200, Dieter Nützel wrote:
> Am 15.04.2020 05:50, schrieb Jan Vesely:
> > On Wed, 2020-04-15 at 05:40 +0200, Dieter Nützel wrote:
> > > Addendum
> > > 
> > > I'm building LLVM git (llvm + SPIRV-LLVM-Translator) for X86;AMDGPU 
> > > like
> > > this:
> > 
> > there's nothing wrong with your build. rocm libs are required by clang
> > when it targets amdgcn--amdhsa target. Unless you know that you want
> > libclc for amdhsa, you probably don't want to build it.
> > 
> > nit: configure.py was dropped from libclc months ago, it's generally
> > better to build the latest git. it now comes in llvm monorepo.
> 
> Oh,
> 
> my BAD, sorry Jan.
> Is it in this path/tree, now?

sorry for the delay, my email was acting up.
yes, that's the location. the cmake build system is not yet integrated
with llvm-project (wip), and it needs a a working llvm+clang
installation (-DLLVM_CONFIG should point to installed llvm-config).
there has been couple of fixes but youprobably didn't miss much.

thanks for the README pointer I'll submit a patch to fix that.
and thanks for building and testing clover.

Jan

> 
> llvm-project/libclc> l
> insgesamt 108
> drwxr-xr-x 13 dieter users  4096 15. Apr 02:53 .
> drwxr-xr-x 22 dieter users  4096 15. Apr 02:53 ..
> drwxr-xr-x  3 dieter users  4096 15. Nov 00:55 amdgcn
> drwxr-xr-x  3 dieter users  4096 15. Nov 00:55 amdgcn-amdhsa
> lrwxrwxrwx  1 dieter users13 15. Nov 00:55 amdgcn-mesa3d -> 
> amdgcn-amdhsa
> drwxr-xr-x  3 dieter users  4096 15. Nov 00:55 amdgpu
> -rwxr-xr-x  1 dieter users   697 15. Nov 00:55 check_external_calls.sh
> drwxr-xr-x  2 dieter users  4096 15. Apr 02:53 cmake
> -rw-r--r--  1 dieter users 10537 15. Apr 02:53 CMakeLists.txt
> -rwxr-xr-x  1 dieter users   224 15. Nov 00:55 compile-test.sh
> -rw-r--r--  1 dieter users42 15. Nov 00:55 CREDITS.TXT
> drwxr-xr-x  4 dieter users  4096 15. Nov 00:55 generic
> -rw-r--r--  1 dieter users   235 15. Nov 00:55 .gitignore
> -rw-r--r--  1 dieter users   281 15. Nov 00:55 libclc.pc.in
> -rw-r--r--  1 dieter users 16469 15. Nov 00:55 LICENSE.TXT
> drwxr-xr-x  3 dieter users  4096 15. Nov 00:55 ptx
> drwxr-xr-x  3 dieter users  4096 15. Nov 00:55 ptx-nvidiacl
> drwxr-xr-x  3 dieter users  4096 15. Nov 00:55 r600
> -rw-r--r--  1 dieter users  1623 15. Nov 00:55 README.TXT
> drwxr-xr-x  2 dieter users  4096 15. Nov 00:55 test
> drwxr-xr-x  2 dieter users  4096 15. Nov 00:55 utils
> drwxr-xr-x  2 dieter users  4096 15. Nov 00:55 www
> 
> Then 'README.TXT' have to updated, too. --- configure.py...
> 
> Greetings,
> 
> Dieter
> 
> > @Matt, the -amdhsa triple was introduced by AMD. I don't think there's
> > any other user so if AMD doesn't have a use for it, we should drop it.
> > 
> > Jan
> > 
> > > /opt/llvm-project/llvm
> > > 
> > > mkdir build
> > > cd build
> > > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang"
> > > -DLLVM_TARGETS_TO_BUILD="X86;AMDGPU" -DLLVM_APPEND_VC_REV=OFF
> > > -DCMAKE_BUILD_TYPE="Release" -DLLVM_LINK_LLVM_DYLIB=ON
> > > -DLLVM_ENABLE_RTTI=ON -DLLVM_PARALLEL_COMPILE_JOBS="9" ../
> > > 
> > > -- The C compiler identification is GNU 9.3.1
> > > -- The CXX compiler identification is GNU 9.3.1
> > > -- The ASM compiler identification is GNU
> > > -- Found assembler: /usr/bin/cc
> > > -- Check for working C compiler: /usr/bin/cc
> > > -- Check for working C compiler: /usr/bin/cc - works
> > > -- Detecting C compiler ABI info
> > > -- Detecting C compiler ABI info - done
> > > -- Detecting C compile features
> > > -- Detecting C compile features - done
> > > -- Check for working CXX compiler: /usr/bin/c++
> > > -- Check for working CXX compiler: /usr/bin/c++ - works
> > > -- Detecting CXX compiler ABI info
> > > -- Detecting CXX compiler ABI info - done
> > > -- Detecting CXX compile features
> > > -- Detecting CXX compile features - done
> > > -- clang project is enabled
> > > -- clang-tools-extra project is disabled
> > > -- compiler-rt project is disabled
> > > -- debuginfo-tests project is disabled
> > > -- libc project is disabled
> > > -- libclc project is disabled
> > > -- libcxx project is disabled
> > > -- libcxxabi project is disabled
> > > -- libunwind project is disabled
> > > -- lld project is disabled
> > > -- lldb project is disabled
> > > -- mlir project is disabled
> > > -- openmp project is disabled
> > > -- parallel-libs project is 

Re: [Mesa-dev] [clover] Compilation of latest 'libclc git' with LLVM 11.0.0git need ROCm?! - Didn't hit that ever before.

[Jan Vesely]

On Wed, 2020-04-15 at 05:40 +0200, Dieter Nützel wrote:
> Addendum
> 
> I'm building LLVM git (llvm + SPIRV-LLVM-Translator) for X86;AMDGPU like 
> this:

there's nothing wrong with your build. rocm libs are required by clang
when it targets amdgcn--amdhsa target. Unless you know that you want
libclc for amdhsa, you probably don't want to build it.

nit: configure.py was dropped from libclc months ago, it's generally
better to build the latest git. it now comes in llvm monorepo.


@Matt, the -amdhsa triple was introduced by AMD. I don't think there's
any other user so if AMD doesn't have a use for it, we should drop it.

Jan

> 
> /opt/llvm-project/llvm
> 
> mkdir build
> cd build
> cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang" 
> -DLLVM_TARGETS_TO_BUILD="X86;AMDGPU" -DLLVM_APPEND_VC_REV=OFF 
> -DCMAKE_BUILD_TYPE="Release" -DLLVM_LINK_LLVM_DYLIB=ON 
> -DLLVM_ENABLE_RTTI=ON -DLLVM_PARALLEL_COMPILE_JOBS="9" ../
> 
> -- The C compiler identification is GNU 9.3.1
> -- The CXX compiler identification is GNU 9.3.1
> -- The ASM compiler identification is GNU
> -- Found assembler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc - works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ - works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- clang project is enabled
> -- clang-tools-extra project is disabled
> -- compiler-rt project is disabled
> -- debuginfo-tests project is disabled
> -- libc project is disabled
> -- libclc project is disabled
> -- libcxx project is disabled
> -- libcxxabi project is disabled
> -- libunwind project is disabled
> -- lld project is disabled
> -- lldb project is disabled
> -- mlir project is disabled
> -- openmp project is disabled
> -- parallel-libs project is disabled
> -- polly project is disabled
> -- pstl project is disabled
> -- flang project is disabled
> -- Found Z3: /usr/lib64/libz3.so (found suitable version "4.8.8", 
> minimum required is "4.7.1")
> -- Looking for dlfcn.h
> -- Looking for dlfcn.h - found
> -- Looking for errno.h
> -- Looking for errno.h - found
> -- Looking for fcntl.h
> -- Looking for fcntl.h - found
> -- Looking for link.h
> -- Looking for link.h - found
> -- Looking for malloc/malloc.h
> -- Looking for malloc/malloc.h - not found
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for signal.h
> -- Looking for signal.h - found
> -- Looking for sys/ioctl.h
> -- Looking for sys/ioctl.h - found
> -- Looking for sys/mman.h
> -- Looking for sys/mman.h - found
> -- Looking for sys/param.h
> -- Looking for sys/param.h - found
> -- Looking for sys/resource.h
> -- Looking for sys/resource.h - found
> -- Looking for sys/stat.h
> -- Looking for sys/stat.h - found
> -- Looking for sys/time.h
> -- Looking for sys/time.h - found
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for termios.h
> -- Looking for termios.h - found
> -- Looking for unistd.h
> -- Looking for unistd.h - found
> -- Looking for valgrind/valgrind.h
> -- Looking for valgrind/valgrind.h - not found
> -- Looking for zlib.h
> -- Looking for zlib.h - found
> -- Looking for fenv.h
> -- Looking for fenv.h - found
> -- Looking for FE_ALL_EXCEPT
> -- Looking for FE_ALL_EXCEPT - found
> -- Looking for FE_INEXACT
> -- Looking for FE_INEXACT - found
> -- Looking for mach/mach.h
> -- Looking for mach/mach.h - not found
> -- Looking for histedit.h
> -- Looking for histedit.h - found
> -- Looking for CrashReporterClient.h
> -- Looking for CrashReporterClient.h - not found
> -- Looking for linux/magic.h
> -- Looking for linux/magic.h - found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Looking for pthread_getspecific in pthread
> -- Looking for pthread_getspecific in pthread - found
> -- Looking for pthread_rwlock_init in pthread
> -- Looking for pthread_rwlock_init in pthread - found
> -- Looking for pthread_mutex_lock in pthread
> -- Looking for pthread_mutex_lock in pthread - found
> -- Looking for dlopen in dl
> -- Looking for dlopen in dl - found
> -- Looking for clock_gettime in rt
> -- Looking for clock_gettime in rt - found
> -- Looking for pfm_initialize in pfm
> -- Looking for pfm_initialize in pfm - not found
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE
> -- Looking for compress2 in z
> -- 

[Mesa-dev] [PATCH] clover: Fix build after llvm 1dfede3122eec

[Jan Vesely]

CodeGenFileType enum was moved to Support/CodeGen.h
Signed-off-by: Jan Vesely 
---
Tested by building and running CLOVER_DEBUG=llvm,native clinfo using
both llvm-git (10) and llvm-9

 .../state_trackers/clover/llvm/codegen/native.cpp| 10 --
 src/gallium/state_trackers/clover/llvm/compat.hpp| 12 
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index b8ed01c7289..a9809549927 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -105,7 +105,7 @@ namespace {
 
std::vector
emit_code(::llvm::Module , const target ,
- TargetMachine::CodeGenFileType ft,
+ compat::CodeGenFileType ft,
  std::string _log) {
   std::string err;
   auto t = ::llvm::TargetRegistry::lookupTarget(target.triple, err);
@@ -128,7 +128,7 @@ namespace {
 
  mod.setDataLayout(tm->createDataLayout());
  tm->Options.MCOptions.AsmVerbose =
-(ft == TargetMachine::CGFT_AssemblyFile);
+(ft == compat::CGFT_AssemblyFile);
 
  if (compat::add_passes_to_emit_file(*tm, pm, os, ft))
 fail(r_log, build_error(), "TargetMachine can't emit this file");
@@ -144,8 +144,7 @@ module
 clover::llvm::build_module_native(::llvm::Module , const target ,
   const clang::CompilerInstance ,
   std::string _log) {
-   const auto code = emit_code(mod, target,
-   TargetMachine::CGFT_ObjectFile, r_log);
+   const auto code = emit_code(mod, target, compat::CGFT_ObjectFile, r_log);
return build_module_common(mod, code, get_symbol_offsets(code, r_log), c);
 }
 
@@ -155,8 +154,7 @@ clover::llvm::print_module_native(const ::llvm::Module ,
std::string log;
try {
   std::unique_ptr< ::llvm::Module> cmod { compat::clone_module(mod) };
-  return as_string(emit_code(*cmod, target,
- TargetMachine::CGFT_AssemblyFile, log));
+  return as_string(emit_code(*cmod, target, compat::CGFT_AssemblyFile, 
log));
} catch (...) {
   return "Couldn't output native disassembly: " + log;
}
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 2015fccaf8c..4b3ac860bf1 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -70,6 +70,18 @@
 namespace clover {
namespace llvm {
   namespace compat {
+#if LLVM_VERSION_MAJOR >= 10
+using CodeGenFileType = ::llvm::CodeGenFileType;
+ const CodeGenFileType CGFT_AssemblyFile = CGFT_AssemblyFile;
+ const CodeGenFileType CGFT_ObjectFile = CGFT_ObjectFile;
+#else
+using CodeGenFileType = ::llvm::TargetMachine::CodeGenFileType;
+const CodeGenFileType CGFT_AssemblyFile =
+::llvm::TargetMachine::CGFT_AssemblyFile;
+const CodeGenFileType CGFT_ObjectFile =
+::llvm::TargetMachine::CGFT_ObjectFile;
+#endif
+
  template
  unsigned target_address_space(const T , const AS lang_as) {
 const auto  = target.getAddressSpaceMap();
-- 
2.23.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Bump number of allowed global buffers to 48 (again, for clover Blender assertion)

[Jan Vesely]

On Tue, 2019-08-06 at 23:20 -0400, Marek Olšák wrote:
> Do you know why global buffers are in the compute state and not in the
> context?

Not really. I mostly follow the existing design when it comes to mesa.
I'd assume it's a leftover from r600 which has limited number of cbufs
(and uses shared pool to accommodate global buffers).

cl global buffers are created in cl context so I think there shouldn't
be too much trouble moving it to the driver equivalent of that.

Jan

> 
> Marek
> 
> On Tue, Aug 6, 2019 at 10:50 PM Dieter Nützel  wrote:
> 
> > Am 20.06.2019 20:44, schrieb Jan Vesely:
> > > On Sat, 2019-06-15 at 07:38 +0200, Dieter Nützel wrote:
> > > > Am 14.06.2019 08:13, schrieb Jan Vesely:
> > > > > On Thu, 2019-06-13 at 21:20 +0200, Dieter Nützel wrote:
> > > > > > Blender crash as expected ;-)
> > > > > > 
> > > > > > /home/dieter> trying to save userpref at
> > > > > > /home/dieter/.config/blender/2.79/config/userpref.blend ok
> > > > > > Read blend: /data/Blender/barbershop_interior_gpu.blend
> > > > > > scripts disabled for "/data/Blender/barbershop_interior_gpu.blend",
> > > > > > skipping 'generate_customprops.py'
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > skipping driver 'var', automatic scripts are disabled
> > > > > > Device init success
> > > > > > Compiling OpenCL program split
> > > > > > Kernel compilation of split finished in 8.41s.
> > > > > > 
> > > > > > Compiling OpenCL program base
> > > > > > Kernel compilation of base finished in 4.55s.
> > > > > > 
> > > > > > Compiling OpenCL program denoising
> > > > > > Kernel compilation of denoising finished in 2.08s.
> > > > > > 
> > > > > > blender: ../src/gallium/drivers/radeonsi/si_compute.c:319:
> > > > > > si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS'
> > > > > > failed.
> > > > > > 
> > > > > > [1]Abbruch   blender (core dumped)
> > > > > 
> > > > > The number of max global buffers was bumped in 06bf56725d to fix
> > > > > similar crash in luxmark. I guess it needs another bump.
> > > > 
> > > > Hello Jan,
> > > > 
> > > > I'm so blind...
> > > > ...bumping it 48 and 64 (first try) works. 33 not ;-)
> > > > We shouldn't waste to much memory.
> > > 
> > > Feel free to post a patch. I'm not sure at which point Marek wants to
> > > switch to dynamic allocation (or if at all), but there's no limit in
> > > OCL so we might end up bumping this every time a new app pushes
> > > against the limit.
> > 
> > Hello Jan,
> > 
> > comming 'happily' from vacation and think we should've this in 19.2.
> > 
> > Marek,
> > 
> > do we need dynamic allocation, yet?
> > 
> > Sorry, please see attachment.
> > Would be nice, if someone of you could add these lines during commit:
> > 
> >  Fixes assertion failure/crash when running Blender (2.79b) on
> > clover.
> >  CC: mesa-sta...@lists.freedesktop.org<= ???
> > 
> > Greetings,
> > Dieter

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] clover: Fix build after clang r367864

[Jan Vesely]

On Tue, 2019-08-06 at 21:39 -0500, Aaron Watry wrote:
> I had come up with an almost identical patch last night, but hadn't
> gotten around to testing it before turning in.
> 
> Reviewed-by: Aaron Watry 

Thanks both to you and Dieter.
I've pushed the patch.

Jan

> 
> On Tue, Aug 6, 2019 at 12:59 PM Jan Vesely  wrote:
> > v2: Drop special case of llvm-9
> > Signed-off-by: Jan Vesely 
> > ---
> >  src/gallium/state_trackers/clover/llvm/compat.hpp | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > index 0ecf622a9af..b040902fcfe 100644
> > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > @@ -79,11 +79,17 @@ namespace clover {
> >  #endif
> >   }
> > 
> > -#if HAVE_LLVM >= 0x0500
> > +#if HAVE_LLVM >= 0x1000
> > + const clang::InputKind ik_opencl = clang::Language::OpenCL;
> > +#elif HAVE_LLVM >= 0x0500
> >   const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
> > - const clang::LangStandard::Kind lang_opencl10 = 
> > clang::LangStandard::lang_opencl10;
> >  #else
> >   const clang::InputKind ik_opencl = clang::IK_OpenCL;
> > +#endif
> > +
> > +#if HAVE_LLVM >= 0x0500
> > + const clang::LangStandard::Kind lang_opencl10 = 
> > clang::LangStandard::lang_opencl10;
> > +#else
> >   const clang::LangStandard::Kind lang_opencl10 = 
> > clang::LangStandard::lang_opencl;
> >  #endif
> > 
> > --
> > 2.21.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7C009ff6fbb5d940512d2808d71ae09bf8%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637007424321638812sdata=BjCsoj8%2Fbz7K0cymyBVVvq6Bgc2yVGdvYATF9yK4ygA%3Dreserved=0

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] clover: Fix build after clang r367864

[Jan Vesely]

v2: Drop special case of llvm-9
Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/llvm/compat.hpp | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 0ecf622a9af..b040902fcfe 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -79,11 +79,17 @@ namespace clover {
 #endif
  }
 
-#if HAVE_LLVM >= 0x0500
+#if HAVE_LLVM >= 0x1000
+ const clang::InputKind ik_opencl = clang::Language::OpenCL;
+#elif HAVE_LLVM >= 0x0500
  const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
- const clang::LangStandard::Kind lang_opencl10 = 
clang::LangStandard::lang_opencl10;
 #else
  const clang::InputKind ik_opencl = clang::IK_OpenCL;
+#endif
+
+#if HAVE_LLVM >= 0x0500
+ const clang::LangStandard::Kind lang_opencl10 = 
clang::LangStandard::lang_opencl10;
+#else
  const clang::LangStandard::Kind lang_opencl10 = 
clang::LangStandard::lang_opencl;
 #endif
 
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover: Fix build after clang r367864

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/llvm/compat.hpp | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 0ecf622a9af..b273abf75af 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -79,11 +79,19 @@ namespace clover {
 #endif
  }
 
-#if HAVE_LLVM >= 0x0500
+#if HAVE_LLVM >= 0x1000
+ const clang::InputKind ik_opencl = clang::Language::OpenCL;
+#elif HAVE_LLVM >= 0x0900
+ const clang::InputKind ik_opencl = clang::InputKind::Language::OpenCL;
+#elif HAVE_LLVM >= 0x0500
  const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
- const clang::LangStandard::Kind lang_opencl10 = 
clang::LangStandard::lang_opencl10;
 #else
  const clang::InputKind ik_opencl = clang::IK_OpenCL;
+#endif
+
+#if HAVE_LLVM >= 0x0500
+ const clang::LangStandard::Kind lang_opencl10 = 
clang::LangStandard::lang_opencl10;
+#else
  const clang::LangStandard::Kind lang_opencl10 = 
clang::LangStandard::lang_opencl;
 #endif
 
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] amd: Apply elf relocations and allow code with relocations

[Jan Vesely]

On Sat, 2019-06-15 at 07:38 +0200, Dieter Nützel wrote:
> Am 14.06.2019 08:13, schrieb Jan Vesely:
> > On Thu, 2019-06-13 at 21:20 +0200, Dieter Nützel wrote:
> > > Am 13.06.2019 07:10, schrieb Marek Olšák:
> > > > FYI, I just pushed the new linker.
> > > > 
> > > > Marek
> > > 
> > > Thank you very much Marek and _Nicolai_ for this GREAT stuff.
> > > It brings back some speed after 1/8 drop with glmark2, lately.
> > > Maybe my amd-staging-drm-next tree (5.2-rc1) didn't honor the kernel
> > > mitigation parameter right.
> > > 
> > > @Jan
> > > Go ahead with your nice relocation and image work.
> > > Send me what you have in the works.
> > 
> > The relocation work is no longer needed as the new linker handles
> > things.
> > The corruption is caused either by (still faulty) conversion builtins,
> > or incorrect buffer coherence handling. Both need fixing, but I'm not
> > sure which one is to blame in this case.
> > 
> > > Latest Mesa git (with Nicolai's new linker) let all 3 luxmark versions
> > > run.
> > > Only 'Hotel lobby' (with v3.0 and v3.1) show some corruption but do 
> > > NOT
> > > crash any longer. Numbers for 'Neumann TLM-102 SE' (medium) show 
> > > ~43000K
> > > (!!!).
> > > 
> > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.phoronix.com%2Fforums%2Fforum%2Fphoronix%2Flatest-phoronix-articles%2F1106085-linux-kernel-set-to-expose-hidden-nvidia-hda-controllers-helping-laptop-users%3Fp%3D1106199%23post1106199data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca6eda55e70a546c57cfa08d6f153b93a%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636961739242915247sdata=HK9Shj%2B8monTnuXeWu%2BgYT77EjqcXT7NOtnpoiyeQNY%3Dreserved=0
> > > 
> > > Blender crash as expected ;-)
> > > 
> > > /home/dieter> trying to save userpref at
> > > /home/dieter/.config/blender/2.79/config/userpref.blend ok
> > > Read blend: /data/Blender/barbershop_interior_gpu.blend
> > > scripts disabled for "/data/Blender/barbershop_interior_gpu.blend",
> > > skipping 'generate_customprops.py'
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > skipping driver 'var', automatic scripts are disabled
> > > Device init success
> > > Compiling OpenCL program split
> > > Kernel compilation of split finished in 8.41s.
> > > 
> > > Compiling OpenCL program base
> > > Kernel compilation of base finished in 4.55s.
> > > 
> > > Compiling OpenCL program denoising
> > > Kernel compilation of denoising finished in 2.08s.
> > > 
> > > blender: ../src/gallium/drivers/radeonsi/si_compute.c:319:
> > > si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS'
> > > failed.
> > > 
> > > [1]Abbruch   blender (core dumped)
> > 
> > The number of max global buffers was bumped in 06bf56725d to fix
> > similar crash in luxmark. I guess it needs another bump.
> 
> Hello Jan,
> 
> I'm so blind...
> ...bumping it 48 and 64 (first try) works. 33 not ;-)
> We shouldn't waste to much memory.

Feel free to post a patch. I'm not sure at which point Marek wants to
switch to dynamic allocation (or if at all), but there's no limit in
OCL so we might end up bumping this every time a new app pushes
against the limit.

> Now, let's start with the libclc work.
> Luxmark 'Hotel' is very blocky and Blender 'barbershop_interior_gpu' 
> mostly black. I have some images.
> 
> Shouldn't we better open a new ticket. Any hints for a good name?
> Or do we have one already? I can put my pictures, there.
> Simpler scenes work, but mostly gray (without colors/texture).

Feel free to create a llvm bug for libclc. The best reproducer is
probably OCL CTS convert test failures.

There are several buffer synchronization bugs reported for clover, so
I don't think we need a new one.

sorry for the delay, my day job projects require more time and
attention than usual.

Jan

> 
> Dieter

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] amd: Apply elf relocations and allow code with relocations

[Jan Vesely]

On Thu, 2019-06-13 at 21:20 +0200, Dieter Nützel wrote:
> Am 13.06.2019 07:10, schrieb Marek Olšák:
> > FYI, I just pushed the new linker.
> > 
> > Marek
> 
> Thank you very much Marek and _Nicolai_ for this GREAT stuff.
> It brings back some speed after 1/8 drop with glmark2, lately.
> Maybe my amd-staging-drm-next tree (5.2-rc1) didn't honor the kernel 
> mitigation parameter right.
> 
> @Jan
> Go ahead with your nice relocation and image work.
> Send me what you have in the works.

The relocation work is no longer needed as the new linker handles
things.
The corruption is caused either by (still faulty) conversion builtins,
or incorrect buffer coherence handling. Both need fixing, but I'm not
sure which one is to blame in this case.

> 
> Latest Mesa git (with Nicolai's new linker) let all 3 luxmark versions 
> run.
> Only 'Hotel lobby' (with v3.0 and v3.1) show some corruption but do NOT 
> crash any longer. Numbers for 'Neumann TLM-102 SE' (medium) show ~43000K 
> (!!!).
> 
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.phoronix.com%2Fforums%2Fforum%2Fphoronix%2Flatest-phoronix-articles%2F1106085-linux-kernel-set-to-expose-hidden-nvidia-hda-controllers-helping-laptop-users%3Fp%3D1106199%23post1106199data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Cae4545df023e4910433c08d6f03438a8%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636960504419864592sdata=xSOotxsWyJDb2J14lNk1NV4bK2nRK3%2FzWoxNyRj6IqU%3Dreserved=0
> 
> Blender crash as expected ;-)
> 
> /home/dieter> trying to save userpref at 
> /home/dieter/.config/blender/2.79/config/userpref.blend ok
> Read blend: /data/Blender/barbershop_interior_gpu.blend
> scripts disabled for "/data/Blender/barbershop_interior_gpu.blend", 
> skipping 'generate_customprops.py'
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> skipping driver 'var', automatic scripts are disabled
> Device init success
> Compiling OpenCL program split
> Kernel compilation of split finished in 8.41s.
> 
> Compiling OpenCL program base
> Kernel compilation of base finished in 4.55s.
> 
> Compiling OpenCL program denoising
> Kernel compilation of denoising finished in 2.08s.
> 
> blender: ../src/gallium/drivers/radeonsi/si_compute.c:319: 
> si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS' 
> failed.
> 
> [1]Abbruch   blender (core dumped)

The number of max global buffers was bumped in 06bf56725d to fix
similar crash in luxmark. I guess it needs another bump.

Jan

> 
> Gretings,
> Dieter
> 
> > On Mon, Jun 3, 2019 at 10:39 PM Jan Vesely 
> > wrote:
> > 
> > > Fixes piglits:
> > > call.cl [1]
> > > calls-larget-struct.cl [2]
> > > calls-struct.cl [3]
> > > calls-workitem-id.cl [4]
> > > realign-stack.cl [5]
> > > tail-calls.cl [6]
> > > 
> > > Cc: mesa-sta...@lists.freedesktop.org
> > > Signed-off-by: Jan Vesely 
> > > ---
> > > The piglit test now pass using llvm-7,8,git.
> > > ImageMagick works on my raven, but some test still fail on
> > > carrizo/iceland.
> > > Other workloads (like shoc) that used function calls also work ok.
> > > ocltoys work after removing static keyword from .cl files.
> > > src/amd/common/ac_binary.c| 30
> > > +++
> > > src/gallium/drivers/radeonsi/si_compute.c |  6 -
> > > 2 files changed, 30 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
> > > index 18dc72c61f0..4d152fcf1be 100644
> > > --- a/src/amd/common/ac_binary.c
> > > +++ b/src/amd/common/ac_binary.c
> > > @@ -178,6 +178,36 @@ bool ac_elf_read(const char *elf_data, unsigned
> > > elf_size,
> > > 
> > > parse_relocs(elf, relocs, symbols, symbol_sh_link, binary);
> > > 
> > > +   // Apply relocations
> > > +   for (int i = 0; i < binary->reloc_count; ++i) {
> > > +   struct ac_shader_reloc *r = >relocs[i];
> > > +   uint32_t *loc = (uint32_t*)(binary->code +
> > > r->offset);
> > > +   /* Section target relocations store symbol offsets
> > >

Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] amd: Apply elf relocations and allow code with relocations

[Jan Vesely]

On Thu, 2019-06-13 at 01:10 -0400, Marek Olšák wrote:
> FYI, I just pushed the new linker.

thanks. I've checked the handling and the current approach works for
sections as well (even if not handled explicitly).

Jan

> 
> Marek
> 
> On Mon, Jun 3, 2019 at 10:39 PM Jan Vesely  wrote:
> 
> > Fixes piglits:
> > call.cl
> > calls-larget-struct.cl
> > calls-struct.cl
> > calls-workitem-id.cl
> > realign-stack.cl
> > tail-calls.cl
> > 
> > Cc: mesa-sta...@lists.freedesktop.org
> > Signed-off-by: Jan Vesely 
> > ---
> > The piglit test now pass using llvm-7,8,git.
> > ImageMagick works on my raven, but some test still fail on
> > carrizo/iceland.
> > Other workloads (like shoc) that used function calls also work ok.
> > ocltoys work after removing static keyword from .cl files.
> >  src/amd/common/ac_binary.c| 30 +++
> >  src/gallium/drivers/radeonsi/si_compute.c |  6 -
> >  2 files changed, 30 insertions(+), 6 deletions(-)
> > 
> > diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
> > index 18dc72c61f0..4d152fcf1be 100644
> > --- a/src/amd/common/ac_binary.c
> > +++ b/src/amd/common/ac_binary.c
> > @@ -178,6 +178,36 @@ bool ac_elf_read(const char *elf_data, unsigned
> > elf_size,
> > 
> > parse_relocs(elf, relocs, symbols, symbol_sh_link, binary);
> > 
> > +   // Apply relocations
> > +   for (int i = 0; i < binary->reloc_count; ++i) {
> > +   struct ac_shader_reloc *r = >relocs[i];
> > +   uint32_t *loc = (uint32_t*)(binary->code + r->offset);
> > +   /* Section target relocations store symbol offsets as
> > +* values in reloc location. We're expected to adjust it
> > for
> > +* start of the section. However, R_AMDGPU_REL32 are
> > +* PC relative relocations, so we need to recompute the
> > +* delta between reloc locatin and the target adress.
> > +*/
> > +   if (r->target_type == 0x3) { // section relocation
> > +   uint32_t target_offset = *loc; // already adjusted
> > +   int64_t diff = target_offset - r->offset;
> > +   if (r->type == 0xa) { // R_AMDGPU_REL32_LO
> > +   // address of the 'lo' instruction is 4B
> > below
> > +   // the relocation point, but the target has
> > +   // alredy been adjusted.
> > +   *loc = (diff & 0x);
> > +   } else if (r->type == 0xb) { // R_AMDGPU_REL32_HI
> > +   // 'hi' relocation is 8B above 'lo'
> > relocation
> > +   *loc = ((diff - 8) >> 32);
> > +   } else {
> > +   success = false;
> > +   fprintf(stderr, "Unsupported section
> > relocation: type: %d, offset: %lx, value: %x\n",
> > +   r->type, r->offset, *loc);
> > +   }
> > +   } else
> > +   success = false;
> > +   }
> > +
> > if (elf){
> > elf_end(elf);
> > }
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> > b/src/gallium/drivers/radeonsi/si_compute.c
> > index b9cea00eeeb..88631369a62 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -246,12 +246,6 @@ static void *si_create_compute_state(
> > const amd_kernel_code_t *code_object =
> > si_compute_get_code_object(program, 0);
> > code_object_to_config(code_object,
> > >shader.config);
> > -   if (program->shader.binary.reloc_count != 0) {
> > -   fprintf(stderr, "Error: %d unsupported
> > relocations\n",
> > -
> >  program->shader.binary.reloc_count);
> > -   FREE(program);
> > -   return NULL;
> > -   }
> > } else {
> > 
> > si_shader_binary_read_config(>shader.binary,
> >  >shader.config, 0);
> > --
&

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3] amd: Add relocation type and relocation target type to reloc structure

[Jan Vesely]

On Tue, 2019-06-04 at 00:20 -0400, Marek Olšák wrote:
> This series will probably conflict with the new linker, which will
> also
> handle relocations and more:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F60255%2Fdata=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7C48f1da4abf674754c36208d6e8a421ea%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636952188985357253sdata=O6Z%2Ftp6JUpjDgCU%2BvPN0Tp4nlBbhyR6XWzb7uaCNYls%3Dreserved=0

It sure does. That series does not consider sections as relocation
targets, but it's just few lines to patch that in. is there an ETA for
the linker series?

Jan

> 
> Marek
> 
> On Mon, Jun 3, 2019 at 10:39 PM Jan Vesely  wrote:
> 
> > Cc: mesa-sta...@lists.freedesktop.org
> > Signed-off-by: Jan Vesely 
> > ---
> >  src/amd/common/ac_binary.c | 2 ++
> >  src/amd/common/ac_binary.h | 2 ++
> >  2 files changed, 4 insertions(+)
> > 
> > diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
> > index 8f4755ebe16..18dc72c61f0 100644
> > --- a/src/amd/common/ac_binary.c
> > +++ b/src/amd/common/ac_binary.c
> > @@ -102,6 +102,8 @@ static void parse_relocs(Elf *elf, Elf_Data *relocs,
> > Elf_Data *symbols,
> > reloc->offset = rel.r_offset;
> > strncpy(reloc->name, symbol_name, sizeof(reloc->name)-1);
> > reloc->name[sizeof(reloc->name)-1] = 0;
> > +   reloc->type = GELF_R_TYPE(rel.r_info);
> > +   reloc->target_type = GELF_ST_TYPE(symbol.st_info);
> > }
> >  }
> > 
> > diff --git a/src/amd/common/ac_binary.h b/src/amd/common/ac_binary.h
> > index 735e3932055..7541f19fb8e 100644
> > --- a/src/amd/common/ac_binary.h
> > +++ b/src/amd/common/ac_binary.h
> > @@ -34,6 +34,8 @@ extern "C" {
> >  struct ac_shader_reloc {
> > char name[32];
> > uint64_t offset;
> > +   int type;
> > +   int target_type;
> >  };
> > 
> >  struct ac_shader_binary {
> > --
> > 2.21.0
> > 
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-stabledata=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7C48f1da4abf674754c36208d6e8a421ea%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636952188985357253sdata=nzz6HTQyMlkHHqFDKOgGb8r9k55YjXtwbO7VQUBCyaU%3Dreserved=0

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] amd: Check return value from ac_elf_read

[Jan Vesely]

Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely 
---
 src/gallium/drivers/radeonsi/si_compute.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 51da06fe550..b9cea00eeeb 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -237,7 +237,11 @@ static void *si_create_compute_state(
header = cso->prog;
code = cso->prog + sizeof(struct pipe_llvm_program_header);
 
-   ac_elf_read(code, header->num_bytes, >shader.binary);
+   if (!ac_elf_read(code, header->num_bytes, 
>shader.binary)) {
+   fprintf(stderr, "Error: Failed to read shader ELF\n");
+   FREE(program);
+   return NULL;
+   }
if (program->use_code_object_v2) {
const amd_kernel_code_t *code_object =
si_compute_get_code_object(program, 0);
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] amd: Add relocation type and relocation target type to reloc structure

[Jan Vesely]

Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely 
---
 src/amd/common/ac_binary.c | 2 ++
 src/amd/common/ac_binary.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
index 8f4755ebe16..18dc72c61f0 100644
--- a/src/amd/common/ac_binary.c
+++ b/src/amd/common/ac_binary.c
@@ -102,6 +102,8 @@ static void parse_relocs(Elf *elf, Elf_Data *relocs, 
Elf_Data *symbols,
reloc->offset = rel.r_offset;
strncpy(reloc->name, symbol_name, sizeof(reloc->name)-1);
reloc->name[sizeof(reloc->name)-1] = 0;
+   reloc->type = GELF_R_TYPE(rel.r_info);
+   reloc->target_type = GELF_ST_TYPE(symbol.st_info);
}
 }
 
diff --git a/src/amd/common/ac_binary.h b/src/amd/common/ac_binary.h
index 735e3932055..7541f19fb8e 100644
--- a/src/amd/common/ac_binary.h
+++ b/src/amd/common/ac_binary.h
@@ -34,6 +34,8 @@ extern "C" {
 struct ac_shader_reloc {
char name[32];
uint64_t offset;
+   int type;
+   int target_type;
 };
 
 struct ac_shader_binary {
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] amd: Apply elf relocations and allow code with relocations

[Jan Vesely]

Fixes piglits:
call.cl
calls-larget-struct.cl
calls-struct.cl
calls-workitem-id.cl
realign-stack.cl
tail-calls.cl

Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely 
---
The piglit test now pass using llvm-7,8,git.
ImageMagick works on my raven, but some test still fail on
carrizo/iceland.
Other workloads (like shoc) that used function calls also work ok.
ocltoys work after removing static keyword from .cl files.
 src/amd/common/ac_binary.c| 30 +++
 src/gallium/drivers/radeonsi/si_compute.c |  6 -
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
index 18dc72c61f0..4d152fcf1be 100644
--- a/src/amd/common/ac_binary.c
+++ b/src/amd/common/ac_binary.c
@@ -178,6 +178,36 @@ bool ac_elf_read(const char *elf_data, unsigned elf_size,
 
parse_relocs(elf, relocs, symbols, symbol_sh_link, binary);
 
+   // Apply relocations
+   for (int i = 0; i < binary->reloc_count; ++i) {
+   struct ac_shader_reloc *r = >relocs[i];
+   uint32_t *loc = (uint32_t*)(binary->code + r->offset);
+   /* Section target relocations store symbol offsets as
+* values in reloc location. We're expected to adjust it for
+* start of the section. However, R_AMDGPU_REL32 are
+* PC relative relocations, so we need to recompute the
+* delta between reloc locatin and the target adress.
+*/
+   if (r->target_type == 0x3) { // section relocation
+   uint32_t target_offset = *loc; // already adjusted
+   int64_t diff = target_offset - r->offset;
+   if (r->type == 0xa) { // R_AMDGPU_REL32_LO
+   // address of the 'lo' instruction is 4B below
+   // the relocation point, but the target has
+   // alredy been adjusted.
+   *loc = (diff & 0x);
+   } else if (r->type == 0xb) { // R_AMDGPU_REL32_HI
+   // 'hi' relocation is 8B above 'lo' relocation
+   *loc = ((diff - 8) >> 32);
+   } else {
+   success = false;
+   fprintf(stderr, "Unsupported section 
relocation: type: %d, offset: %lx, value: %x\n",
+   r->type, r->offset, *loc);
+   }
+   } else
+   success = false;
+   }
+
if (elf){
elf_end(elf);
}
diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index b9cea00eeeb..88631369a62 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -246,12 +246,6 @@ static void *si_create_compute_state(
const amd_kernel_code_t *code_object =
si_compute_get_code_object(program, 0);
code_object_to_config(code_object, 
>shader.config);
-   if (program->shader.binary.reloc_count != 0) {
-   fprintf(stderr, "Error: %d unsupported 
relocations\n",
-   program->shader.binary.reloc_count);
-   FREE(program);
-   return NULL;
-   }
} else {
si_shader_binary_read_config(>shader.binary,
 >shader.config, 0);
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error: unsupported relocations

[Jan Vesely]

On Mon, 2019-06-03 at 11:12 +1000, Dave Airlie wrote:
> On Mon, 3 Jun 2019 at 10:58, Jan Vesely  wrote:
> > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> > > I've started a thread on the llvm mailing list.  See
> > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2F2019-June%2F132750.htmldata=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ce7c33507211c4512c6ad08d6e7c09d49%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636951211793224808sdata=lyayMkDxUbTCye%2BynlBZ8sp%2Fc4u5kS4pv%2B2MMeSegoM%3Dreserved=0
> > > 
> > > I don't know if it's needed, but if anyone has a commit in llvm that
> > > started this, that might be helpful.
> > 
> > thanks. however most LLVM developers contributing to AMDGPU backend
> > are AMD folks. The ROCm based stack can handle relocations, so it's up
> > to a volunteer to step up and post a patch (either for mesa or llvm).
> > Fewer relocations should mean faster dispatch, so you they should be
> > interested in taking the LLVM fix.
> > 
> > I've started looking, but the elf structure lists relocations against
> > a section (STT_SECTION), so I still don't know where to get target
> > address.
> 
> Jan,
> 
> this is clearly inline not working, not relocs. We never get the
> missing function to relocate it.

The imagemagick issue might be missed inlining.
I'm working on call* piglits, which mark functions as 'noinline' to
force function calls.
the code clearly expects relative function address:
s_getpc_b64 s[8:9]
s_add_u32 s8, s8, i64_func_void@rel32@lo+4
s_addc_u32 s9, s9, i64_func_void@rel32@hi+4
s_mov_b32 s32, s10
s_swappc_b64 s[30:31], s[8:9]
Inspecting the asm and symbol table, the callee functions are there.
It might be that relocations issued for amdgcn-mesa-mesa3d triple are
busted, I'd expect it to use single 4B relative pointer, but last time
I talked to Matt he said it looked correct.

Jan

> 
> Dave.

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error: unsupported relocations

[Jan Vesely]

On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> I've started a thread on the llvm mailing list.  See
> http://lists.llvm.org/pipermail/llvm-dev/2019-June/132750.html
> 
> I don't know if it's needed, but if anyone has a commit in llvm that
> started this, that might be helpful.

thanks. however most LLVM developers contributing to AMDGPU backend
are AMD folks. The ROCm based stack can handle relocations, so it's up
to a volunteer to step up and post a patch (either for mesa or llvm).
Fewer relocations should mean faster dispatch, so you they should be
interested in taking the LLVM fix.

I've started looking, but the elf structure lists relocations against
a section (STT_SECTION), so I still don't know where to get target
address.

Jan

> 
> On Sat, Jun 1, 2019 at 10:56 PM Jan Vesely  wrote:
> > Hi,
> > 
> > On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote:
> > > On Sat, Jun 1, 2019 at 6:19 PM James Harvey  
> > > wrote:
> > > > On Tue, Feb 19, 2019 at 7:52 PM james harvey  
> > > > wrote:
> > > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled
> > > > > relocations".
> > > > > 
> > > > > This has broken ImageMagick for many people using AMD graphics cards.
> > > > > See https://github.com/ImageMagick/ImageMagick/issues/1366
> > > > > 
> > > > > ImageMagick responded: "It looks like this error message is created by
> > > > > the mesa driver. I have no idea what causes this message and if there
> > > > > is anything what we could do to prevent this from happening."
> > > > > 
> > > > > And, hasn't responded back for requests for what additional
> > > > > information I could tell mesa.
> > > > > 
> > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the 
> > > > > commit.
> > > > > 
> > > > > I'm just asking what would need to be done by who to get ImageMagick
> > > > > working again, using opencl-mesa.  Using opencl-amd has been a
> > > > > workaround for some people.  Not sure if this is something mesa just
> > > > > hasn't implemented that opencl-amd has, or if it's something
> > > > > ImageMagick needs to do differently.
> > > > 
> > > > Ping?  Mesa + ImageMagick convert is broken, affecting lots of people,
> > > > but neither project is saying anything.
> > > 
> > > Sorry all, please reply to this post rather than the last.  Copy-paste
> > > failure of email addresses of people listed in mesa patch, fixed.
> > 
> > sorry I missed the previous email. The issues has been discussed at
> > [0].
> > 
> > tldr; the referenced mesa commit prevents GPU hangs/crashes caused by
> > changes in LLVM.
> > 
> > longer story:
> > AMDGPU llvm backend used to inline all function calls until llvm-6.
> > llvm-6+ uses functions calls and issues relocations for each function
> > invocation. unhandled relocations lead to GPU hangs/crashes.
> > either clover/mesa needs to handle relocations, or LLVM needs to stop
> > using relocations for internal symbols (they are not needed).
> > 
> > I've neither time, nor energy, nor access to hw, to fix things up
> > every time AMD changes break something in clover, and nobody else has
> > stepped up.
> > moreover, mesa made it clear that volunteer contributions and needs
> > are inferior to corporate stakeholders (not even worth CI cycles).
> > thus, clover on amd gpus is in damage mitigation mode; errors are
> > better than crashes, crashes are better than hangs.
> > 
> > Chances are that clover over NIR will work before the current issues
> > are fixed.
> > 
> > regards,
> > Jan
> > 
> > [0] https://bugs.freedesktop.org/show_bug.cgi?id=105113
> > 
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> > --
> > Jan Vesely 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error: unsupported relocations

[Jan Vesely]

On Mon, 2019-06-03 at 09:14 +1000, Dave Airlie wrote:
> On Mon, 3 Jun 2019 at 09:13, Dave Airlie  wrote:
> > On Sun, 2 Jun 2019 at 23:13, Jan Vesely  wrote:
> > > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote:
> > > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen
> > > >  wrote:
> > > > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey 
> > > > >  wrote:
> > > > > > So, for people running amdgpu and wanting to run ImageMagick convert
> > > > > > who get this error... Does this mean there is something ImageMagick
> > > > > > could change to prevent the error?  Or, in the meantime, is the only
> > > > > > option to install the amdgpu-pro opencl userspace driver with
> > > > > > ImageMagick?  (The pro opencl driver can be extracted from 
> > > > > > amdgpu-pro
> > > > > > as a whole, and ran on top of the free amdgpu driver., without the
> > > > > > rest of amdgpu-pro installed - see Arch Linux AUR package 
> > > > > > opencl-amd.)
> > > > > 
> > > > > So, does imagemagick actually need OpenCL? If not, you can probably
> > > > > also uninstall you mesa opencl distro package?
> > > > 
> > > > The mesa opencl package works fine on other programs for me and
> > > > others, so uninstalling isn't an option.  Not sure actually without
> > > > any OpenCL if it does it a different way or not.  ImageMagick must be
> > > > all that's trying to call something problematic.
> > > 
> > > It's basically any function call that was not inlined. It might even
> > > be in a different kernel in the same module.
> > > 
> > > Recent mesa requires some kind of ICD loader to provide opencl. if
> > > your distro uses ocl-icd package to provide ICD loader, you can use
> > > OCL_ICD_VENDORS env var to select ICD drivers.
> > > 
> > > something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than
> > > /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting
> > > 0 available platforms.
> > 
> > It looks like an llvm8 not inlining everything properly bug.
> > 
> > with llvm9 I just get a gpu hang when it does inline everything, but
> > with 8 it fails to inline applyResizeFilter.
> > 
> > llvm8 or some command line option passed to it might need a fix.
> 
> Uggh changing the original CL C code in ImageMagic to static inline "fixes" 
> it.

sounds a bit like https://reviews.llvm.org/D62707. static inline
function might be internalized/marked alwaysinline. CLOVER_DEBUG=llvm
would tell more.
I'm not sure why it'd produce GPU hangs. It might be a llvm-git bug,
my daily testing only covers CL piglits.

Jan
> 
> Dave.
> 
> > Dave.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error: unsupported relocations

[Jan Vesely]

On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote:
> On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen
>  wrote:
> > On Sun, Jun 2, 2019 at 12:41 PM James Harvey  
> > wrote:
> > > So, for people running amdgpu and wanting to run ImageMagick convert
> > > who get this error... Does this mean there is something ImageMagick
> > > could change to prevent the error?  Or, in the meantime, is the only
> > > option to install the amdgpu-pro opencl userspace driver with
> > > ImageMagick?  (The pro opencl driver can be extracted from amdgpu-pro
> > > as a whole, and ran on top of the free amdgpu driver., without the
> > > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.)
> > 
> > So, does imagemagick actually need OpenCL? If not, you can probably
> > also uninstall you mesa opencl distro package?
> 
> The mesa opencl package works fine on other programs for me and
> others, so uninstalling isn't an option.  Not sure actually without
> any OpenCL if it does it a different way or not.  ImageMagick must be
> all that's trying to call something problematic.

It's basically any function call that was not inlined. It might even
be in a different kernel in the same module.

Recent mesa requires some kind of ICD loader to provide opencl. if
your distro uses ocl-icd package to provide ICD loader, you can use
OCL_ICD_VENDORS env var to select ICD drivers.

something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than
/etc/OpenCL/vendors will do) effectively disables OpenCL by reporting
0 available platforms.

Jan
-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error: unsupported relocations

[Jan Vesely]

Hi,

On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote:
> On Sat, Jun 1, 2019 at 6:19 PM James Harvey  wrote:
> > On Tue, Feb 19, 2019 at 7:52 PM james harvey  
> > wrote:
> > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled
> > > relocations".
> > > 
> > > This has broken ImageMagick for many people using AMD graphics cards.
> > > See https://github.com/ImageMagick/ImageMagick/issues/1366
> > > 
> > > ImageMagick responded: "It looks like this error message is created by
> > > the mesa driver. I have no idea what causes this message and if there
> > > is anything what we could do to prevent this from happening."
> > > 
> > > And, hasn't responded back for requests for what additional
> > > information I could tell mesa.
> > > 
> > > I see the mesa commit is to prevent GPU hangs, so I'm all for the commit.
> > > 
> > > I'm just asking what would need to be done by who to get ImageMagick
> > > working again, using opencl-mesa.  Using opencl-amd has been a
> > > workaround for some people.  Not sure if this is something mesa just
> > > hasn't implemented that opencl-amd has, or if it's something
> > > ImageMagick needs to do differently.
> > 
> > Ping?  Mesa + ImageMagick convert is broken, affecting lots of people,
> > but neither project is saying anything.
> 
> Sorry all, please reply to this post rather than the last.  Copy-paste
> failure of email addresses of people listed in mesa patch, fixed.

sorry I missed the previous email. The issues has been discussed at
[0].

tldr; the referenced mesa commit prevents GPU hangs/crashes caused by
changes in LLVM.

longer story:
AMDGPU llvm backend used to inline all function calls until llvm-6.
llvm-6+ uses functions calls and issues relocations for each function
invocation. unhandled relocations lead to GPU hangs/crashes.
either clover/mesa needs to handle relocations, or LLVM needs to stop
using relocations for internal symbols (they are not needed).

I've neither time, nor energy, nor access to hw, to fix things up
every time AMD changes break something in clover, and nobody else has
stepped up.
moreover, mesa made it clear that volunteer contributions and needs
are inferior to corporate stakeholders (not even worth CI cycles).
thus, clover on amd gpus is in damage mitigation mode; errors are
better than crashes, crashes are better than hangs.

Chances are that clover over NIR will work before the current issues
are fixed.

regards,
Jan

[0] https://bugs.freedesktop.org/show_bug.cgi?id=105113

> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix timestamp queries for compute-only contexts

[Jan Vesely]

On Mon, 2019-05-27 at 16:10 -0400, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/gallium/drivers/radeonsi/si_fence.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_fence.c 
> b/src/gallium/drivers/radeonsi/si_fence.c
> index 1d67fd87b90..6d914a1b184 100644
> --- a/src/gallium/drivers/radeonsi/si_fence.c
> +++ b/src/gallium/drivers/radeonsi/si_fence.c
> @@ -72,31 +72,33 @@ void si_cp_release_mem(struct si_context *ctx, struct 
> radeon_cmdbuf *cs,
>  struct si_resource *buf, uint64_t va,
>  uint32_t new_fence, unsigned query_type)
>  {
>   unsigned op = EVENT_TYPE(event) |
> EVENT_INDEX(event == V_028A90_CS_DONE ||
> event == V_028A90_PS_DONE ? 6 : 5) |
> event_flags;
>   unsigned sel = EOP_DST_SEL(dst_sel) |
>  EOP_INT_SEL(int_sel) |
>  EOP_DATA_SEL(data_sel);
> + bool compute_ib = !ctx->has_graphics ||
> +   cs == ctx->prim_discard_compute_cs;
>  
> - if (ctx->chip_class >= GFX9 || cs == ctx->prim_discard_compute_cs) {
> + if (ctx->chip_class >= GFX9 ||
> + (compute_ib && ctx->chip_class >= GFX7)) {
>   /* A ZPASS_DONE or PIXEL_STAT_DUMP_EVENT (of the DB occlusion
>* counters) must immediately precede every timestamp event to
>* prevent a GPU hang on GFX9.
>*
>* Occlusion queries don't need to do it here, because they
>* always do ZPASS_DONE before the timestamp.
>*/
> - if (ctx->chip_class == GFX9 &&
> - cs != ctx->prim_discard_compute_cs &&
> + if (ctx->chip_class == GFX9 && !compute_ib &&
>   query_type != PIPE_QUERY_OCCLUSION_COUNTER &&
>   query_type != PIPE_QUERY_OCCLUSION_PREDICATE &&
>   query_type != PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE) {
>   struct si_resource *scratch = ctx->eop_bug_scratch;
>  
>   assert(16 * ctx->screen->info.num_render_backends <=
>  scratch->b.b.width0);
>   radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 2, 0));
>   radeon_emit(cs, EVENT_TYPE(EVENT_TYPE_ZPASS_DONE) | 
> EVENT_INDEX(1));
>   radeon_emit(cs, scratch->gpu_address);

Fixes clover timestamp queries, at least on raven.
Tested-by: Jan Vesely 

Jan
-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: allow query functions for compute-only contexts

[Jan Vesely]

On Mon, May 13, 2019 at 6:40 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c  | 2 +-
>  src/gallium/drivers/radeonsi/si_query.c | 7 ---
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index aa7f012f071..95280675506 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -482,29 +482,29 @@ static struct pipe_context *si_create_context(struct 
> pipe_screen *screen,
> sctx->b.set_device_reset_callback = si_set_device_reset_callback;
>
> si_init_all_descriptors(sctx);
> si_init_buffer_functions(sctx);
> si_init_clear_functions(sctx);
> si_init_blit_functions(sctx);
> si_init_compute_functions(sctx);
> si_init_compute_blit_functions(sctx);
> si_init_debug_functions(sctx);
> si_init_fence_functions(sctx);
> +   si_init_query_functions(sctx);
> si_init_state_compute_functions(sctx);
>
> if (sscreen->debug_flags & DBG(FORCE_DMA))
> sctx->b.resource_copy_region = sctx->dma_copy;
>
> /* Initialize graphics-only context functions. */
> if (sctx->has_graphics) {
> si_init_context_texture_functions(sctx);
> -   si_init_query_functions(sctx);
> si_init_msaa_functions(sctx);
> si_init_shader_functions(sctx);
> si_init_state_functions(sctx);
> si_init_streamout_functions(sctx);
> si_init_viewport_functions(sctx);
>
> sctx->blitter = util_blitter_create(>b);
> if (sctx->blitter == NULL)
> goto fail;
> sctx->blitter->skip_viewport_restore = true;
> diff --git a/src/gallium/drivers/radeonsi/si_query.c 
> b/src/gallium/drivers/radeonsi/si_query.c
> index d98bea2eeb3..3e357e8b6c0 100644
> --- a/src/gallium/drivers/radeonsi/si_query.c
> +++ b/src/gallium/drivers/radeonsi/si_query.c
> @@ -1879,23 +1879,24 @@ static int si_get_driver_query_group_info(struct 
> pipe_screen *screen,
>
>  void si_init_query_functions(struct si_context *sctx)
>  {
> sctx->b.create_query = si_create_query;
> sctx->b.create_batch_query = si_create_batch_query;
> sctx->b.destroy_query = si_destroy_query;
> sctx->b.begin_query = si_begin_query;
> sctx->b.end_query = si_end_query;
> sctx->b.get_query_result = si_get_query_result;
> sctx->b.get_query_result_resource = si_get_query_result_resource;
> -   sctx->atoms.s.render_cond.emit = si_emit_query_predication;
>
> -   if (((struct si_screen*)sctx->b.screen)->info.num_render_backends > 0)
> -   sctx->b.render_condition = si_render_condition;
> +   if (sctx->has_graphics) {
> +   sctx->atoms.s.render_cond.emit = si_emit_query_predication;
> +   sctx->b.render_condition = si_render_condition;
> +   }
>
> LIST_INITHEAD(>active_queries);
>  }
>
>  void si_init_screen_query_functions(struct si_screen *sscreen)
>  {
> sscreen->b.get_driver_query_info = si_get_driver_query_info;
> sscreen->b.get_driver_query_group_info = 
> si_get_driver_query_group_info;
>  }
> --
> 2.17.1

Hi,

this patch hangs query requests (tested on carrizo and raven).

Jan

>
> ___
> 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 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)

[Jan Vesely]

+ if (sctx->chip_class >= GFX9 || !sctx->has_graphics) {
>   /* Flush caches and wait for the caches to assert idle. */
>   radeon_emit(cs, PKT3(PKT3_ACQUIRE_MEM, 5, 0));
>   radeon_emit(cs, cp_coher_cntl); /* CP_COHER_CNTL */
>   radeon_emit(cs, 0x);/* CP_COHER_SIZE */
>   radeon_emit(cs, 0xff);  /* CP_COHER_SIZE_HI */
>   radeon_emit(cs, 0); /* CP_COHER_BASE */
>   radeon_emit(cs, 0); /* CP_COHER_BASE_HI */
>   radeon_emit(cs, 0x000A);/* POLL_INTERVAL */
>   } else {
>   /* ACQUIRE_MEM is only required on a compute ring. */
> @@ -895,20 +895,32 @@ static void si_emit_surface_sync(struct si_context 
> *sctx,
>   radeon_emit(cs, 0x);  /* CP_COHER_SIZE */
>   radeon_emit(cs, 0);   /* CP_COHER_BASE */
>   radeon_emit(cs, 0x000A);  /* POLL_INTERVAL */
>   }
>  }
>  
>  void si_emit_cache_flush(struct si_context *sctx)
>  {
>   struct radeon_cmdbuf *cs = sctx->gfx_cs;
>   uint32_t flags = sctx->flags;
> +
> + if (!sctx->has_graphics) {
> + /* Only process compute flags. */
> + flags &= SI_CONTEXT_INV_ICACHE |
> +  SI_CONTEXT_INV_SMEM_L1 |
> +  SI_CONTEXT_INV_VMEM_L1 |
> +  SI_CONTEXT_INV_GLOBAL_L2 |
> +  SI_CONTEXT_WRITEBACK_GLOBAL_L2 |
> +  SI_CONTEXT_INV_L2_METADATA |
> +  SI_CONTEXT_CS_PARTIAL_FLUSH;
> + }
> +
>   uint32_t cp_coher_cntl = 0;
>   uint32_t flush_cb_db = flags & (SI_CONTEXT_FLUSH_AND_INV_CB |
>   SI_CONTEXT_FLUSH_AND_INV_DB);
>  
>   if (flags & SI_CONTEXT_FLUSH_AND_INV_CB)
>   sctx->num_cb_cache_flushes++;
>   if (flags & SI_CONTEXT_FLUSH_AND_INV_DB)
>   sctx->num_db_cache_flushes++;
>  
>   /* SI has a bug that it always flushes ICACHE and KCACHE if either
> @@ -1061,25 +1073,26 @@ void si_emit_cache_flush(struct si_context *sctx)
> EOP_DATA_SEL_VALUE_32BIT,
> sctx->wait_mem_scratch, va,
> sctx->wait_mem_number, SI_NOT_QUERY);
>   si_cp_wait_mem(sctx, cs, va, sctx->wait_mem_number, 0x,
>  WAIT_REG_MEM_EQUAL);
>   }
>  
>   /* Make sure ME is idle (it executes most packets) before continuing.
>* This prevents read-after-write hazards between PFP and ME.
>*/
> - if (cp_coher_cntl ||
> - (flags & (SI_CONTEXT_CS_PARTIAL_FLUSH |
> - SI_CONTEXT_INV_VMEM_L1 |
> - SI_CONTEXT_INV_GLOBAL_L2 |
> - SI_CONTEXT_WRITEBACK_GLOBAL_L2))) {
> + if (sctx->has_graphics &&
> + (cp_coher_cntl ||
> +  (flags & (SI_CONTEXT_CS_PARTIAL_FLUSH |
> +SI_CONTEXT_INV_VMEM_L1 |
> +SI_CONTEXT_INV_GLOBAL_L2 |
> +SI_CONTEXT_WRITEBACK_GLOBAL_L2 {
>   radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
>   radeon_emit(cs, 0);
>   }
>  
>   /* SI-CI-VI only:
>*   When one of the CP_COHER_CNTL.DEST_BASE flags is set, SURFACE_SYNC
>*   waits for idle, so it should be last. SURFACE_SYNC is done in PFP.
>*
>* cp_coher_cntl should contain all necessary flags except TC flags
>* at this point.
> diff --git a/src/gallium/drivers/radeonsi/si_texture.c 
> b/src/gallium/drivers/radeonsi/si_texture.c
> index a50088d2d8f..581f90a7b2f 100644
> --- a/src/gallium/drivers/radeonsi/si_texture.c
> +++ b/src/gallium/drivers/radeonsi/si_texture.c
> @@ -457,20 +457,23 @@ static bool si_texture_discard_dcc(struct si_screen 
> *sscreen,
>   *   compressed tiled
>   *
>   * \param sctx  the current context if you have one, or sscreen->aux_context
>   *  if you don't.
>   */
>  bool si_texture_disable_dcc(struct si_context *sctx,
>   struct si_texture *tex)
>  {
>   struct si_screen *sscreen = sctx->screen;
>  
> + if (!sctx->has_graphics)
> + return si_texture_discard_dcc(sscreen, tex);
> +
>   if (!si_can_disable_dcc(tex))
>   return false;
>  
>   if (>b == sscreen->aux_context)
>   mtx_lock(>aux_context_lock);
>  
>   /* Decompress DCC. */
>   si_decompress_dcc(sctx, tex);
>   sctx->b.flush(>b, NULL, 0);
>  

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/aux: Report error if loading of a pipe driver fails.

[Jan Vesely]

On Wed, Apr 10, 2019 at 9:33 PM Marek Olšák  wrote:
>
> Reviewed-by: Marek Olšák 

thank you. pushed.

Jan
>
> Marek
>
> On Wed, Apr 3, 2019 at 2:02 AM Jan Vesely  wrote:
>>
>> Skip over non-existent files.
>> Signed-off-by: Jan Vesely 
>> ---
>> This should help detect instances of messed up/missing symbols in the driver.
>> windows build seems OK: 
>> https://ci.appveyor.com/project/jvesely/mesa/builds/23550498#L1292
>>  .../auxiliary/pipe-loader/pipe_loader.c   |  5 +-
>>  src/gallium/auxiliary/util/u_file.h   | 58 +++
>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>  create mode 100644 src/gallium/auxiliary/util/u_file.h
>>
>> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c 
>> b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
>> index 6fd15527e53..fc8ee8e8dcd 100644
>> --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
>> +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
>> @@ -31,6 +31,7 @@
>>  #include "util/u_memory.h"
>>  #include "util/u_string.h"
>>  #include "util/u_dl.h"
>> +#include "util/u_file.h"
>>  #include "util/xmlconfig.h"
>>  #include "util/xmlpool.h"
>>
>> @@ -158,11 +159,13 @@ pipe_loader_find_module(const char *driver_name,
>>   ret = util_snprintf(path, sizeof(path), "%s%s%s",
>>   MODULE_PREFIX, driver_name, UTIL_DL_EXT);
>>
>> -  if (ret > 0 && ret < sizeof(path)) {
>> +  if (ret > 0 && ret < sizeof(path) && u_file_access(path, 0) != -1) {
>>   lib = util_dl_open(path);
>>   if (lib) {
>>  return lib;
>>   }
>> + fprintf(stderr, "ERROR: Failed to load pipe driver at `%s': %s\n",
>> + path, util_dl_error());
>>}
>> }
>>
>> diff --git a/src/gallium/auxiliary/util/u_file.h 
>> b/src/gallium/auxiliary/util/u_file.h
>> new file mode 100644
>> index 000..f337dc9761e
>> --- /dev/null
>> +++ b/src/gallium/auxiliary/util/u_file.h
>> @@ -0,0 +1,58 @@
>> +/**
>> + *
>> + * Copyright 2009 VMware, Inc.
>> + * All Rights Reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
>> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY 
>> CLAIM,
>> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
>> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial portions
>> + * of the Software.
>> + *
>> + **/
>> +
>> +
>> +#ifndef U_FILE_H_
>> +#define U_FILE_H_
>> +
>> +#if defined(PIPE_OS_UNIX)
>> +#include 
>> +#endif
>> +#if defined(PIPE_OS_WINDOWS)
>> +#include 
>> +#endif
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +static inline int
>> +u_file_access(const char *path, int mode) {
>> +#if defined(PIPE_OS_UNIX)
>> +   return access(path, mode);
>> +#elif defined(PIPE_OS_WINDOWS)
>> +   return _access(path, mode);
>> +#else
>> +   return 0;
>> +#endif
>> +}
>> +
>> +#ifdef __cplusplus
>> +}
>> +#endif
>> +
>> +#endif /* U_FILE_H_ */
>> --
>> 2.21.0
>>
>> ___
>> 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Partially revert "gallium: fix autotools build of pipe_msm.la"

[Jan Vesely]

On Tue, Apr 9, 2019 at 5:36 PM Vinson Lee  wrote:
>
> On Tue, Apr 9, 2019 at 1:29 PM Jan Vesely  wrote:
> >
> > On Sat, Apr 6, 2019 at 10:11 PM Dieter Nützel  wrote:
> > >
> > > Tested-by: Dieter Nützel 
> > > Acked-by: Dieter Nützel 
> >
> > Thanks Dieter,
> >
> > Timur, Vinson, are you OK with this temporary solution?
> >
> > Jan
> >
>
> Tested-by: Vinson Lee 

thanks to both of you. pushed.

Jan

>
> > >
> > > Thank you Jan!
> > >
> > > BTW More about 'meson' with radeonsi and Clover in some hours.
> > >
> > > Dieter
> > >
> > > Am 06.04.2019 06:43, schrieb Jan Vesely:
> > > > This partially reverts commit 356ec7a21960d77db282f67af577dcdb46966b5a.
> > > > There are missing symbols needed by libglsl, so we might as well skip
> > > > the entire library (which should be present in the mesa stat tracker).
> > > >
> > > > Signed-off-by: Jan Vesely 
> > > > ---
> > > >
> > > > Hi Timur, Vinson,
> > > >
> > > > this patch is enough to get clover working again in autotools build,
> > > > until a proper solution lands (which should reinstate -Wl,-no-undefined
> > > > for pipe drivers).
> > > > Vinson, I tested freedreno and it builds, but I don't have hw to test
> > > > anything more, let me know if things still work or you with this patch.
> > > >
> > > > regards,
> > > > Jan
> > > >
> > > >  src/gallium/targets/pipe-loader/Makefile.am | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/gallium/targets/pipe-loader/Makefile.am
> > > > b/src/gallium/targets/pipe-loader/Makefile.am
> > > > index 807a100a7d0..864ee8d50d3 100644
> > > > --- a/src/gallium/targets/pipe-loader/Makefile.am
> > > > +++ b/src/gallium/targets/pipe-loader/Makefile.am
> > > > @@ -53,7 +53,8 @@ endif
> > > >
> > > >  PIPE_LIBS += \
> > > >   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
> > > > - $(top_builddir)/src/compiler/glsl/libglsl.la \
> > > > + $(top_builddir)/src/compiler/nir/libnir.la \
> > > > + $(top_builddir)/src/util/libmesautil.la \
> > > >   $(GALLIUM_COMMON_LIB_DEPS)
> > > >
> > > >  AM_LDFLAGS = \
> > > ___
> > > 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/aux: Report error if loading of a pipe driver fails.

[Jan Vesely]

On Wed, Apr 3, 2019 at 2:02 AM Jan Vesely  wrote:
>
> Skip over non-existent files.
> Signed-off-by: Jan Vesely 
> ---
> This should help detect instances of messed up/missing symbols in the driver.
> windows build seems OK: 
> https://ci.appveyor.com/project/jvesely/mesa/builds/23550498#L1292
>  .../auxiliary/pipe-loader/pipe_loader.c   |  5 +-
>  src/gallium/auxiliary/util/u_file.h   | 58 +++
>  2 files changed, 62 insertions(+), 1 deletion(-)
>  create mode 100644 src/gallium/auxiliary/util/u_file.h
>
> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c 
> b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
> index 6fd15527e53..fc8ee8e8dcd 100644
> --- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
> +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
> @@ -31,6 +31,7 @@
>  #include "util/u_memory.h"
>  #include "util/u_string.h"
>  #include "util/u_dl.h"
> +#include "util/u_file.h"
>  #include "util/xmlconfig.h"
>  #include "util/xmlpool.h"
>
> @@ -158,11 +159,13 @@ pipe_loader_find_module(const char *driver_name,
>   ret = util_snprintf(path, sizeof(path), "%s%s%s",
>   MODULE_PREFIX, driver_name, UTIL_DL_EXT);
>
> -  if (ret > 0 && ret < sizeof(path)) {
> +  if (ret > 0 && ret < sizeof(path) && u_file_access(path, 0) != -1) {
>   lib = util_dl_open(path);
>   if (lib) {
>  return lib;
>   }
> + fprintf(stderr, "ERROR: Failed to load pipe driver at `%s': %s\n",
> + path, util_dl_error());
>}
> }
>
> diff --git a/src/gallium/auxiliary/util/u_file.h 
> b/src/gallium/auxiliary/util/u_file.h
> new file mode 100644
> index 000..f337dc9761e
> --- /dev/null
> +++ b/src/gallium/auxiliary/util/u_file.h
> @@ -0,0 +1,58 @@
> +/**
> + *
> + * Copyright 2009 VMware, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY 
> CLAIM,
> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + **/
> +
> +
> +#ifndef U_FILE_H_
> +#define U_FILE_H_
> +
> +#if defined(PIPE_OS_UNIX)
> +#include 
> +#endif
> +#if defined(PIPE_OS_WINDOWS)
> +#include 
> +#endif
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +static inline int
> +u_file_access(const char *path, int mode) {
> +#if defined(PIPE_OS_UNIX)
> +   return access(path, mode);
> +#elif defined(PIPE_OS_WINDOWS)
> +   return _access(path, mode);
> +#else
> +   return 0;
> +#endif
> +}
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* U_FILE_H_ */
> --
> 2.21.0
>

ping.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Partially revert "gallium: fix autotools build of pipe_msm.la"

[Jan Vesely]

On Sat, Apr 6, 2019 at 10:11 PM Dieter Nützel  wrote:
>
> Tested-by: Dieter Nützel 
> Acked-by: Dieter Nützel 

Thanks Dieter,

Timur, Vinson, are you OK with this temporary solution?

Jan

>
> Thank you Jan!
>
> BTW More about 'meson' with radeonsi and Clover in some hours.
>
> Dieter
>
> Am 06.04.2019 06:43, schrieb Jan Vesely:
> > This partially reverts commit 356ec7a21960d77db282f67af577dcdb46966b5a.
> > There are missing symbols needed by libglsl, so we might as well skip
> > the entire library (which should be present in the mesa stat tracker).
> >
> > Signed-off-by: Jan Vesely 
> > ---
> >
> > Hi Timur, Vinson,
> >
> > this patch is enough to get clover working again in autotools build,
> > until a proper solution lands (which should reinstate -Wl,-no-undefined
> > for pipe drivers).
> > Vinson, I tested freedreno and it builds, but I don't have hw to test
> > anything more, let me know if things still work or you with this patch.
> >
> > regards,
> > Jan
> >
> >  src/gallium/targets/pipe-loader/Makefile.am | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/targets/pipe-loader/Makefile.am
> > b/src/gallium/targets/pipe-loader/Makefile.am
> > index 807a100a7d0..864ee8d50d3 100644
> > --- a/src/gallium/targets/pipe-loader/Makefile.am
> > +++ b/src/gallium/targets/pipe-loader/Makefile.am
> > @@ -53,7 +53,8 @@ endif
> >
> >  PIPE_LIBS += \
> >   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
> > - $(top_builddir)/src/compiler/glsl/libglsl.la \
> > + $(top_builddir)/src/compiler/nir/libnir.la \
> > + $(top_builddir)/src/util/libmesautil.la \
> >   $(GALLIUM_COMMON_LIB_DEPS)
> >
> >  AM_LDFLAGS = \
> ___
> 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 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)

[Jan Vesely]

On Mon, Apr 8, 2019 at 10:46 AM Michel Dänzer  wrote:
>
> On 2019-04-02 4:00 p.m., Michel Dänzer wrote:
> > On 2019-04-02 2:57 p.m., Marek Olšák wrote:
> >> On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer  wrote:
> >>> On 2019-04-02 12:39 a.m., Marek Olšák wrote:
> >>>> On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely 
> >>> wrote:
> >>>>> On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote:
> >>>>>> Does the attached patch fix the copy-buffer test?
> >>>>>
> >>>>> it does thanks.
> >>>>> Won't the compute only context still need some synchronization?
> >>>>> Is there anything else to guarantee that the data is in place after
> >>>>> return from resource_copy_region ?
> >>>>
> >>>> The synchronization is the same on gfx and compute rings.
> >>>
> >>> BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24
> >>> ? It does indicate some kind of synchronization issue between
> >>> si_resource_copy_region using a compute ring and other operations using
> >>> a GFX ring.
> >>
> >> Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK.
> >
> > That bugzilla comment is about the GTK menu issue, not about xterm.
> > Anyway, I doubt GTK uses OpenCL either, and neither does glamor, so it
> > was probably an invalid bisect result then.
>
> Apparently not, after all:
>
> https://bugs.freedesktop.org/110355
>
> Looks like there is some issue with si_compute_copy_image, even if it
> doesn't use a compute ring.

Then there's also the old problem of SI hangs when using compute shared clears:
https://bugs.freedesktop.org/show_bug.cgi?id=108879

Jan

>
>
> --
> Earthling Michel Dänzer   |  https://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> 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] gitlab: Let's delete a buildsystem

[Jan Vesely]

Hi,

is there a release with that change planned any time soon?

thanks,
Jan

On Mon, Apr 8, 2019 at 4:23 PM Dylan Baker  wrote:
>
> As per the discussion last time around, the last feature meson needed to grow 
> to
> be able to remove autotools was support for remembering PKG_CONFIG_PATH, since
> that has landed: https://github.com/mesonbuild/meson/pull/4931, so I'm sending
> this out again.
>
> The gitlab link for the PR is here:
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/601
>
> Dylan
> ___
> 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

[Mesa-dev] [PATCH] Partially revert "gallium: fix autotools build of pipe_msm.la"

[Jan Vesely]

This partially reverts commit 356ec7a21960d77db282f67af577dcdb46966b5a.
There are missing symbols needed by libglsl, so we might as well skip the 
entire library (which should be present in the mesa stat tracker).

Signed-off-by: Jan Vesely 
---

Hi Timur, Vinson,

this patch is enough to get clover working again in autotools build,
until a proper solution lands (which should reinstate -Wl,-no-undefined
for pipe drivers).
Vinson, I tested freedreno and it builds, but I don't have hw to test
anything more, let me know if things still work or you with this patch.

regards,
Jan

 src/gallium/targets/pipe-loader/Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
b/src/gallium/targets/pipe-loader/Makefile.am
index 807a100a7d0..864ee8d50d3 100644
--- a/src/gallium/targets/pipe-loader/Makefile.am
+++ b/src/gallium/targets/pipe-loader/Makefile.am
@@ -53,7 +53,8 @@ endif
 
 PIPE_LIBS += \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
-   $(top_builddir)/src/compiler/glsl/libglsl.la \
+   $(top_builddir)/src/compiler/nir/libnir.la \
+   $(top_builddir)/src/util/libmesautil.la \
$(GALLIUM_COMMON_LIB_DEPS)
 
 AM_LDFLAGS = \
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/aux: Report error if loading of a pipe driver fails.

[Jan Vesely]

Skip over non-existent files.
Signed-off-by: Jan Vesely 
---
This should help detect instances of messed up/missing symbols in the driver.
windows build seems OK: 
https://ci.appveyor.com/project/jvesely/mesa/builds/23550498#L1292
 .../auxiliary/pipe-loader/pipe_loader.c   |  5 +-
 src/gallium/auxiliary/util/u_file.h   | 58 +++
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 src/gallium/auxiliary/util/u_file.h

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 6fd15527e53..fc8ee8e8dcd 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -31,6 +31,7 @@
 #include "util/u_memory.h"
 #include "util/u_string.h"
 #include "util/u_dl.h"
+#include "util/u_file.h"
 #include "util/xmlconfig.h"
 #include "util/xmlpool.h"
 
@@ -158,11 +159,13 @@ pipe_loader_find_module(const char *driver_name,
  ret = util_snprintf(path, sizeof(path), "%s%s%s",
  MODULE_PREFIX, driver_name, UTIL_DL_EXT);
 
-  if (ret > 0 && ret < sizeof(path)) {
+  if (ret > 0 && ret < sizeof(path) && u_file_access(path, 0) != -1) {
  lib = util_dl_open(path);
  if (lib) {
 return lib;
  }
+ fprintf(stderr, "ERROR: Failed to load pipe driver at `%s': %s\n",
+ path, util_dl_error());
   }
}
 
diff --git a/src/gallium/auxiliary/util/u_file.h 
b/src/gallium/auxiliary/util/u_file.h
new file mode 100644
index 000..f337dc9761e
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_file.h
@@ -0,0 +1,58 @@
+/**
+ *
+ * Copyright 2009 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ **/
+
+
+#ifndef U_FILE_H_
+#define U_FILE_H_
+
+#if defined(PIPE_OS_UNIX)
+#include 
+#endif
+#if defined(PIPE_OS_WINDOWS)
+#include 
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+static inline int
+u_file_access(const char *path, int mode) {
+#if defined(PIPE_OS_UNIX)
+   return access(path, mode);
+#elif defined(PIPE_OS_WINDOWS)
+   return _access(path, mode);
+#else
+   return 0;
+#endif
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* U_FILE_H_ */
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: don't use PFP_SYNC_ME with compute-only contexts

[Jan Vesely]

On Mon, 2019-04-01 at 18:37 -0400, Marek Olšák wrote:
> From: Marek Olšák 

Tested-by: Jan Vesely 

Can you add a note along the lines; "compute rings don't have PFP" or
anything more descriptive on the commit message?

thanks,
Jan

> 
> Fixes: a1378639ab1 "radeonsi: always use compute rings for clover on CI and 
> newer (v2)"
> ---
>  src/gallium/drivers/radeonsi/si_cp_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c 
> b/src/gallium/drivers/radeonsi/si_cp_dma.c
> index 5993369d2da..f349325202c 100644
> --- a/src/gallium/drivers/radeonsi/si_cp_dma.c
> +++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
> @@ -124,21 +124,21 @@ static void si_emit_cp_dma(struct si_context *sctx, 
> struct radeon_cmdbuf *cs,
>   radeon_emit(cs, dst_va);/* DST_ADDR_LO [31:0] */
>   radeon_emit(cs, (dst_va >> 32) & 0x); /* DST_ADDR_HI [15:0] 
> */
>   radeon_emit(cs, command);
>   }
>  
>   /* CP DMA is executed in ME, but index buffers are read by PFP.
>* This ensures that ME (CP DMA) is idle before PFP starts fetching
>* indices. If we wanted to execute CP DMA in PFP, this packet
>* should precede it.
>*/
> - if (flags & CP_DMA_PFP_SYNC_ME) {
> + if (sctx->has_graphics && flags & CP_DMA_PFP_SYNC_ME) {
>   radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
>   radeon_emit(cs, 0);
>   }
>  }
>  
>  void si_cp_dma_wait_for_idle(struct si_context *sctx)
>  {
>   /* Issue a dummy DMA that copies zero bytes.
>*
>* The DMA engine will see that there's no work to do and skip this

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Commit 'gallium: fix autotools build of pipe_msm.la' broke Clover - bisected

[Jan Vesely]

On Tue, 2019-04-02 at 02:37 +0200, Dieter Nützel wrote:
> Am 01.04.2019 07:43, schrieb Jan Vesely:
> > Hi,
> > 
> > On Mon, 2019-04-01 at 06:24 +0200, Dieter Nützel wrote:
> > > Hello,
> > > 
> > > commit #356ec7a2196 'gallium: fix autotools build of pipe_msm.la' 
> > > broke
> > > Clover.
> > > 
> > > biseted:
> > > 356ec7a21960d77db282f67af577dcdb46966b5a is the first bad commit
> > > commit 356ec7a21960d77db282f67af577dcdb46966b5a
> > > Author: Timur Kristóf 
> > > Date:   Thu Mar 14 15:32:37 2019 +0100
> > > 
> > >  gallium: fix autotools build of pipe_msm.la
> > > 
> > >  Signed-off-by: Vinson Lee 
> > >  Fixes: 9a834447d652 ("tgsi_to_nir: Produce optimized NIR for a 
> > > given
> > > pipe_screen.")
> > >  Bugzilla: 
> > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109929data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca161a421657d40f6011908d6b70370c0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C636897622770137680sdata=QJFTMLeoBK4TjYtc34RHvrJ7NeloOORard6nQ5eBQVQ%3Dreserved=0
> > > 
> > > :04 04 601ddeba6f98a1872a8f49667c89224601afe31b
> > > cee6467ed172beb890455d0874a2e883e6c95e14 M src
> > > 
> > > Reverting it bring Clover back.
> > 
> > I'm guessing you use autotools to build clover?
> > My digging shows that the culprit is
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F225data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca161a421657d40f6011908d6b70370c0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C636897622770137680sdata=1g%2B7aR%2FuaegKvF7fpvErlzP113xy8nsSKs4z5oudh3k%3Dreserved=0
> >  which
> > makes users of gallium/axuiliary pull in libglsl.
> > 356ec7a21 tries to fix it by adding libglsl to pipe_loader, thus
> > making pipe drivers require glsl symbols and breaking every state
> > tracker that does not provide them. I'd expect omx and vdpau state
> > trackers would fail in similar manner.
> 
> I didn't use omx (do not compile, but can try), but vdpau works with 
> 'meson build'.
> 
> > > The most annoying thing for me is, that even 'meson build' of Clover 
> > > do
> > > NOT work for me (hello Dylan? ;-)):
> > > 
> > > ../src/gallium/state_trackers/clover/api/event.cpp: In function 
> > > ‘cl_int
> > > clGetEventProfilingInfo(cl_event, cl_profiling_info, size_t, void*,
> > > size_t*)’:
> > > ../src/gallium/state_trackers/clover/api/event.cpp:256:58: error:
> > > ‘dynamic_cast’ not permitted with -fno-rtti
> > >  hard_event  = dynamic_cast(obj(d_ev));
> > >^
> > > ../src/gallium/state_trackers/clover/api/event.cpp:287:23: warning:
> > > ignoring attributes on template argument ‘cl_ulong’ {aka ‘long 
> > > unsigned
> > > int’} [-Wignored-attributes]
> > >   } catch (lazy::undefined_error ) {
> > > ^
> > > In file included from
> > > ../src/gallium/state_trackers/clover/core/event.hpp:29,
> > >   from
> > > ../src/gallium/state_trackers/clover/api/event.cpp:24:
> > > ../src/gallium/state_trackers/clover/core/object.hpp: In instantiation
> > > of ‘static void clover::detail::descriptor_traits::validate(D*)
> > > [with T = clover::soft_event; D = _cl_event]’:
> > > ../src/gallium/state_trackers/clover/core/object.hpp:148:48:   
> > > required
> > > from ‘typename clover::detail::descriptor_traits::object_type&
> > > clover::obj(D*) [with T = clover::soft_event; D = _cl_event; typename
> > > clover::detail::descriptor_traits::object_type =
> > > clover::soft_event]’
> > > ../src/gallium/state_trackers/clover/api/event.cpp:42:36:   required
> > > from here
> > > ../src/gallium/state_trackers/clover/core/object.hpp:72:18: error:
> > > ‘dynamic_cast’ not permitted with -fno-rtti
> > >   !dynamic_cast(o))
> > >^~
> > 
> > This looks like the -fno-rtti flags got there from 'llvm-config --
> > cxxflags'.
> 
> Yes.
> 
> /home/dieter> llvm-config --cxxflags
> -I/usr/local/include -std=c++11   -fno-exceptions -fno-rtti 
> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
> -D__STDC_LIMIT_MACROS
> 
> > Clover makes use of rtti(as you've found out), and I'd say
> >

Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)

[Jan Vesely]

On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote:
> Does the attached patch fix the copy-buffer test?

it does thanks.
Won't the compute only context still need some synchronization?
Is there anything else to guarantee that the data is in place after
return from resource_copy_region ?

thanks,
Jan

> 
> Thanks,
> Marek
> 
> On Sat, Mar 2, 2019 at 10:58 PM Jan Vesely  wrote:
> 
> > On Thu, 2019-02-28 at 17:48 -0500, Marek Olšák wrote:
> > > On Thu, Feb 28, 2019 at 4:44 AM Jan Vesely 
> > wrote:
> > > > On Tue, 2019-02-26 at 18:34 -0500, Marek Olšák wrote:
> > > > > I ran a simple test verifying that compute is working properly on the
> > > > > compute ring.
> > > > 
> > > > I guess this was not on raven? With his patch I no loner see gfx
> > > > timeout but the apps still hang. anyway that's a separate issue.
> > > > 
> > > 
> > > If clover hangs, gfx timeouts are now compute timeouts, which might not
> > be
> > > printed in dmesg. It's still a hang, it just doesn't always affect gfx.
> > 
> > thanks, that one has been bisected and identified [0].
> > This patch however causes hangs in cl-api-enqueue-copy-buffer on all
> > GCN hw I got to test (raven, carrizo, iceland).
> > 
> > Jan
> > 
> > [0] 
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109649data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7C76649a348e53469404b208d6b6bf74eb%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636897330772678063sdata=WqP9bVyGbJjYcY9RKOjC2AWmEZMN8px0PBocRlkGYPA%3Dreserved=0
> > 
> > > Marek
> > > 
> > > 
> > > > > When clover is using compute rings, it doesn't stall/block graphics
> > > > > operations.
> > > > 
> > > > I'd be nice to include this information in the commit message.
> > > > 
> > > > Jan
> > > > 
> > > > > Marek
> > > > > 
> > > > > On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely 
> > > > 
> > > > wrote:
> > > > > > Can you add a bit of background why clover should/should not use
> > other
> > > > > > rings?
> > > > > > 
> > > > > > I planned to test this, but my raven system can't run clover since
> > > > 
> > > > kernel
> > > > > > 4.20 release (BZ 109649), so I need to bisect that first.
> > > > > > Can this patch help address the soft lockup issue on CIK (BZ
> > 108879)?
> > > > > > presumably, it was tested using clover on CIK, right?
> > > > > > 
> > > > > > Jan
> > > > > > 
> > > > > > On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák 
> > wrote:
> > > > > > > I'll just push it.
> > > > > > > 
> > > > > > > Marek
> > > > > > > 
> > > > > > > On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel <
> > die...@nuetzel-hh.de>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > Hello Marek,
> > > > > > > > 
> > > > > > > > this series need a rebase (if you have some time).
> > > > > > > > 
> > > > > > > > Dieter
> > > > > > > > 
> > > > > > > > Am 12.02.2019 19:12, schrieb Marek Olšák:
> > > > > > > > > From: Marek Olšák 
> > > > > > > > > 
> > > > > > > > > initialize all non-compute context functions to NULL.
> > > > > > > > > 
> > > > > > > > > v2: fix SI
> > > > > > > > > ---
> > > > > > > > >  src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > > > > > > > >  src/gallium/drivers/radeonsi/si_clear.c   |  7 +-
> > > > > > > > >  src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > > > > > > > >  src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > > > > > > > >  src/gallium/drivers/radeonsi/si_gfx_cs.c  | 29 +++---
> > > > > > > > >  src/gallium/drivers/radeonsi/si_pipe.c| 95
> > > > 
> > > > +++
> > > > > > > > >  src/gallium/drivers/radeonsi/si_pipe.h|  3 +-
>

Re: [Mesa-dev] Commit 'gallium: fix autotools build of pipe_msm.la' broke Clover - bisected

[Jan Vesely]

Hi,

On Mon, 2019-04-01 at 06:24 +0200, Dieter Nützel wrote:
> Hello,
> 
> commit #356ec7a2196 'gallium: fix autotools build of pipe_msm.la' broke 
> Clover.
> 
> biseted:
> 356ec7a21960d77db282f67af577dcdb46966b5a is the first bad commit
> commit 356ec7a21960d77db282f67af577dcdb46966b5a
> Author: Timur Kristóf 
> Date:   Thu Mar 14 15:32:37 2019 +0100
> 
>  gallium: fix autotools build of pipe_msm.la
> 
>  Signed-off-by: Vinson Lee 
>  Fixes: 9a834447d652 ("tgsi_to_nir: Produce optimized NIR for a given 
> pipe_screen.")
>  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109929
> 
> :04 04 601ddeba6f98a1872a8f49667c89224601afe31b 
> cee6467ed172beb890455d0874a2e883e6c95e14 M src
> 
> Reverting it bring Clover back.

I'm guessing you use autotools to build clover?
My digging shows that the culprit is 
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225 which
makes users of gallium/axuiliary pull in libglsl.
356ec7a21 tries to fix it by adding libglsl to pipe_loader, thus
making pipe drivers require glsl symbols and breaking every state
tracker that does not provide them. I'd expect omx and vdpau state
trackers would fail in similar manner.


> The most annoying thing for me is, that even 'meson build' of Clover do 
> NOT work for me (hello Dylan? ;-)):
> 
> ../src/gallium/state_trackers/clover/api/event.cpp: In function ‘cl_int 
> clGetEventProfilingInfo(cl_event, cl_profiling_info, size_t, void*, 
> size_t*)’:
> ../src/gallium/state_trackers/clover/api/event.cpp:256:58: error: 
> ‘dynamic_cast’ not permitted with -fno-rtti
>  hard_event  = dynamic_cast(obj(d_ev));
>^
> ../src/gallium/state_trackers/clover/api/event.cpp:287:23: warning: 
> ignoring attributes on template argument ‘cl_ulong’ {aka ‘long unsigned 
> int’} [-Wignored-attributes]
>   } catch (lazy::undefined_error ) {
> ^
> In file included from 
> ../src/gallium/state_trackers/clover/core/event.hpp:29,
>   from 
> ../src/gallium/state_trackers/clover/api/event.cpp:24:
> ../src/gallium/state_trackers/clover/core/object.hpp: In instantiation 
> of ‘static void clover::detail::descriptor_traits::validate(D*) 
> [with T = clover::soft_event; D = _cl_event]’:
> ../src/gallium/state_trackers/clover/core/object.hpp:148:48:   required 
> from ‘typename clover::detail::descriptor_traits::object_type& 
> clover::obj(D*) [with T = clover::soft_event; D = _cl_event; typename 
> clover::detail::descriptor_traits::object_type = 
> clover::soft_event]’
> ../src/gallium/state_trackers/clover/api/event.cpp:42:36:   required 
> from here
> ../src/gallium/state_trackers/clover/core/object.hpp:72:18: error: 
> ‘dynamic_cast’ not permitted with -fno-rtti
>   !dynamic_cast(o))
>^~

This looks like the -fno-rtti flags got there from 'llvm-config --
cxxflags'. Clover makes use of rtti(as you've found out), and I'd say
that you need it in LLVM too. Mixing Clover/rtti and llvm/no-rtti
would probably complain about missing symbols in llvm libraries.

Jan

> 
> meson config:
> meson ../ --strip --buildtype debugoptimized -Ddri-drivers= 
> -Dplatforms=drm,x11 -Dgallium-drivers=r600,radeonsi,swrast 
> -Dvulkan-drivers=amd -Dgallium-nine=true -Dgallium-opencl=icd 
> -Dglvnd=true -Dgallium-va=false -Dgallium-xvmc=false 
> -Dgallium-omx=disabled -Dgallium-xa=false
> 
> Only -Dgallium-opencl=disabled works.
> 
> Thanks,
> Dieter
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)

[Jan Vesely]

On Thu, 2019-02-28 at 17:48 -0500, Marek Olšák wrote:
> On Thu, Feb 28, 2019 at 4:44 AM Jan Vesely  wrote:
> 
> > On Tue, 2019-02-26 at 18:34 -0500, Marek Olšák wrote:
> > > I ran a simple test verifying that compute is working properly on the
> > > compute ring.
> > 
> > I guess this was not on raven? With his patch I no loner see gfx
> > timeout but the apps still hang. anyway that's a separate issue.
> > 
> 
> If clover hangs, gfx timeouts are now compute timeouts, which might not be
> printed in dmesg. It's still a hang, it just doesn't always affect gfx.

thanks, that one has been bisected and identified [0].
This patch however causes hangs in cl-api-enqueue-copy-buffer on all
GCN hw I got to test (raven, carrizo, iceland).

Jan

[0] https://bugs.freedesktop.org/show_bug.cgi?id=109649

> 
> Marek
> 
> 
> > 
> > > 
> > > When clover is using compute rings, it doesn't stall/block graphics
> > > operations.
> > 
> > I'd be nice to include this information in the commit message.
> > 
> > Jan
> > 
> > > 
> > > Marek
> > > 
> > > On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely 
> > 
> > wrote:
> > > 
> > > > Can you add a bit of background why clover should/should not use other
> > > > rings?
> > > > 
> > > > I planned to test this, but my raven system can't run clover since
> > 
> > kernel
> > > > 4.20 release (BZ 109649), so I need to bisect that first.
> > > > Can this patch help address the soft lockup issue on CIK (BZ 108879)?
> > > > presumably, it was tested using clover on CIK, right?
> > > > 
> > > > Jan
> > > > 
> > > > On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák  wrote:
> > > > 
> > > > > I'll just push it.
> > > > > 
> > > > > Marek
> > > > > 
> > > > > On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel 
> > > > > wrote:
> > > > > 
> > > > > > Hello Marek,
> > > > > > 
> > > > > > this series need a rebase (if you have some time).
> > > > > > 
> > > > > > Dieter
> > > > > > 
> > > > > > Am 12.02.2019 19:12, schrieb Marek Olšák:
> > > > > > > From: Marek Olšák 
> > > > > > > 
> > > > > > > initialize all non-compute context functions to NULL.
> > > > > > > 
> > > > > > > v2: fix SI
> > > > > > > ---
> > > > > > >  src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > > > > > >  src/gallium/drivers/radeonsi/si_clear.c   |  7 +-
> > > > > > >  src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > > > > > >  src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > > > > > >  src/gallium/drivers/radeonsi/si_gfx_cs.c  | 29 +++---
> > > > > > >  src/gallium/drivers/radeonsi/si_pipe.c| 95
> > 
> > +++
> > > > > > >  src/gallium/drivers/radeonsi/si_pipe.h|  3 +-
> > > > > > >  src/gallium/drivers/radeonsi/si_state.c   |  3 +-
> > > > > > >  src/gallium/drivers/radeonsi/si_state.h   |  1 +
> > > > > > >  src/gallium/drivers/radeonsi/si_state_draw.c  | 25 +++--
> > > > > > >  src/gallium/drivers/radeonsi/si_texture.c |  3 +
> > > > > > >  11 files changed, 130 insertions(+), 75 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > index bb8d1cbd12d..f39cb5d143f 100644
> > > > > > > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> > > > > > > pipe_context *ctx,
> > > > > > > 
> > > > > > >   if (separate_dcc_dirty) {
> > > > > > >   tex->separate_dcc_dirty = false;
> > > > > > > 
> > 
> >  vi_separate_dcc_process_and_reset_stats(ctx,
> > > > > > 
> > > > > > tex);
> > > > > > >   }
> 

Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)

[Jan Vesely]

On Tue, 2019-02-26 at 18:34 -0500, Marek Olšák wrote:
> I ran a simple test verifying that compute is working properly on the
> compute ring.

I guess this was not on raven? With his patch I no loner see gfx
timeout but the apps still hang. anyway that's a separate issue.

> 
> When clover is using compute rings, it doesn't stall/block graphics
> operations.

I'd be nice to include this information in the commit message.

Jan

> 
> Marek
> 
> On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely  wrote:
> 
> > Can you add a bit of background why clover should/should not use other
> > rings?
> > 
> > I planned to test this, but my raven system can't run clover since kernel
> > 4.20 release (BZ 109649), so I need to bisect that first.
> > Can this patch help address the soft lockup issue on CIK (BZ 108879)?
> > presumably, it was tested using clover on CIK, right?
> > 
> > Jan
> > 
> > On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák  wrote:
> > 
> > > I'll just push it.
> > > 
> > > Marek
> > > 
> > > On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel 
> > > wrote:
> > > 
> > > > Hello Marek,
> > > > 
> > > > this series need a rebase (if you have some time).
> > > > 
> > > > Dieter
> > > > 
> > > > Am 12.02.2019 19:12, schrieb Marek Olšák:
> > > > > From: Marek Olšák 
> > > > > 
> > > > > initialize all non-compute context functions to NULL.
> > > > > 
> > > > > v2: fix SI
> > > > > ---
> > > > >  src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > > > >  src/gallium/drivers/radeonsi/si_clear.c   |  7 +-
> > > > >  src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > > > >  src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > > > >  src/gallium/drivers/radeonsi/si_gfx_cs.c  | 29 +++---
> > > > >  src/gallium/drivers/radeonsi/si_pipe.c| 95 
> > > > > +++
> > > > >  src/gallium/drivers/radeonsi/si_pipe.h|  3 +-
> > > > >  src/gallium/drivers/radeonsi/si_state.c   |  3 +-
> > > > >  src/gallium/drivers/radeonsi/si_state.h   |  1 +
> > > > >  src/gallium/drivers/radeonsi/si_state_draw.c  | 25 +++--
> > > > >  src/gallium/drivers/radeonsi/si_texture.c |  3 +
> > > > >  11 files changed, 130 insertions(+), 75 deletions(-)
> > > > > 
> > > > > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > index bb8d1cbd12d..f39cb5d143f 100644
> > > > > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> > > > > pipe_context *ctx,
> > > > > 
> > > > >   if (separate_dcc_dirty) {
> > > > >   tex->separate_dcc_dirty = false;
> > > > >   vi_separate_dcc_process_and_reset_stats(ctx,
> > > > 
> > > > tex);
> > > > >   }
> > > > >   }
> > > > >  }
> > > > > 
> > > > >  void si_decompress_dcc(struct si_context *sctx, struct si_texture
> > > > > *tex)
> > > > >  {
> > > > > - if (!tex->dcc_offset)
> > > > > + /* If graphics is disabled, we can't decompress DCC, but it
> > > > 
> > > > shouldn't
> > > > > +  * be compressed either. The caller should simply discard it.
> > > > > +  */
> > > > > + if (!tex->dcc_offset || !sctx->has_graphics)
> > > > >   return;
> > > > > 
> > > > >   si_blit_decompress_color(sctx, tex, 0,
> > > > 
> > > > tex->buffer.b.b.last_level,
> > > > >0, util_max_layer(>buffer.b.b, 0),
> > > > >true);
> > > > >  }
> > > > > 
> > > > >  void si_init_blit_functions(struct si_context *sctx)
> > > > >  {
> > > > >   sctx->b.resource_copy_region = si_resource_copy_region;
> > > > > - sctx->b.blit = si_blit;
> > > > > - sctx->b.flush_resource = si_flush_resource

Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)

[Jan Vesely]

Can you add a bit of background why clover should/should not use other
rings?

I planned to test this, but my raven system can't run clover since kernel
4.20 release (BZ 109649), so I need to bisect that first.
Can this patch help address the soft lockup issue on CIK (BZ 108879)?
presumably, it was tested using clover on CIK, right?

Jan

On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák  wrote:

> I'll just push it.
>
> Marek
>
> On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel 
> wrote:
>
>> Hello Marek,
>>
>> this series need a rebase (if you have some time).
>>
>> Dieter
>>
>> Am 12.02.2019 19:12, schrieb Marek Olšák:
>> > From: Marek Olšák 
>> >
>> > initialize all non-compute context functions to NULL.
>> >
>> > v2: fix SI
>> > ---
>> >  src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
>> >  src/gallium/drivers/radeonsi/si_clear.c   |  7 +-
>> >  src/gallium/drivers/radeonsi/si_compute.c | 15 +--
>> >  src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
>> >  src/gallium/drivers/radeonsi/si_gfx_cs.c  | 29 +++---
>> >  src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
>> >  src/gallium/drivers/radeonsi/si_pipe.h|  3 +-
>> >  src/gallium/drivers/radeonsi/si_state.c   |  3 +-
>> >  src/gallium/drivers/radeonsi/si_state.h   |  1 +
>> >  src/gallium/drivers/radeonsi/si_state_draw.c  | 25 +++--
>> >  src/gallium/drivers/radeonsi/si_texture.c |  3 +
>> >  11 files changed, 130 insertions(+), 75 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
>> > b/src/gallium/drivers/radeonsi/si_blit.c
>> > index bb8d1cbd12d..f39cb5d143f 100644
>> > --- a/src/gallium/drivers/radeonsi/si_blit.c
>> > +++ b/src/gallium/drivers/radeonsi/si_blit.c
>> > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
>> > pipe_context *ctx,
>> >
>> >   if (separate_dcc_dirty) {
>> >   tex->separate_dcc_dirty = false;
>> >   vi_separate_dcc_process_and_reset_stats(ctx, tex);
>> >   }
>> >   }
>> >  }
>> >
>> >  void si_decompress_dcc(struct si_context *sctx, struct si_texture
>> > *tex)
>> >  {
>> > - if (!tex->dcc_offset)
>> > + /* If graphics is disabled, we can't decompress DCC, but it
>> shouldn't
>> > +  * be compressed either. The caller should simply discard it.
>> > +  */
>> > + if (!tex->dcc_offset || !sctx->has_graphics)
>> >   return;
>> >
>> >   si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
>> >0, util_max_layer(>buffer.b.b, 0),
>> >true);
>> >  }
>> >
>> >  void si_init_blit_functions(struct si_context *sctx)
>> >  {
>> >   sctx->b.resource_copy_region = si_resource_copy_region;
>> > - sctx->b.blit = si_blit;
>> > - sctx->b.flush_resource = si_flush_resource;
>> > - sctx->b.generate_mipmap = si_generate_mipmap;
>> > +
>> > + if (sctx->has_graphics) {
>> > + sctx->b.blit = si_blit;
>> > + sctx->b.flush_resource = si_flush_resource;
>> > + sctx->b.generate_mipmap = si_generate_mipmap;
>> > + }
>> >  }
>> > diff --git a/src/gallium/drivers/radeonsi/si_clear.c
>> > b/src/gallium/drivers/radeonsi/si_clear.c
>> > index 9a00bb73b94..e1805f2a1c9 100644
>> > --- a/src/gallium/drivers/radeonsi/si_clear.c
>> > +++ b/src/gallium/drivers/radeonsi/si_clear.c
>> > @@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
>> > *pipe,
>> >   util_clear_render_target(pipe, sf, ,
>> >box->x, box->y,
>> >box->width, box->height);
>> >   }
>> >   }
>> >   pipe_surface_reference(, NULL);
>> >  }
>> >
>> >  void si_init_clear_functions(struct si_context *sctx)
>> >  {
>> > - sctx->b.clear = si_clear;
>> >   sctx->b.clear_render_target = si_clear_render_target;
>> > - sctx->b.clear_depth_stencil = si_clear_depth_stencil;
>> >   sctx->b.clear_texture = si_clear_texture;
>> > +
>> > + if (sctx->has_graphics) {
>> > + sctx->b.clear = si_clear;
>> > + sctx->b.clear_depth_stencil = si_clear_depth_stencil;
>> > + }
>> >  }
>> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> > b/src/gallium/drivers/radeonsi/si_compute.c
>> > index 1a62b3e0844..87addd53976 100644
>> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> > @@ -880,26 +880,28 @@ static void si_launch_grid(
>> >   info->block[0] * info->block[1] * info->block[2] > 256;
>> >
>> >   if (cs_regalloc_hang)
>> >   sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
>> >SI_CONTEXT_CS_PARTIAL_FLUSH;
>> >
>> >   if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
>> >   program->shader.compilation_failed)
>> >   return;
>> >
>> > - if 

Re: [Mesa-dev] mesa git break nvidia opencl

[Jan Vesely]

Hi,

I don't know what "mesa card" means. You mentioned nvidia GPU, if you
want to use nvidia binary drivers, you can't use mesa provided
libOpenCL.so.
The output you posted looks like you're trying to use mesa to load
other ICD drivers, that won't work.
This is not a change in git. Unless you have a recent AMD GPU you
shouldn't build opencl, or at least configure with --enable-opencl-
icd.

Jan

On Sun, 2019-01-13 at 15:22 +0100, andreas.benz...@googlemail.com
wrote:
> Hello Jan,
> 
> clinfo shows a little bit of opencl info while no "mesa" card is with
> the machine. 
> 
> That's wrong:
> 
> flatpak --command=/bin/bash run online.winehub.GPUViewer 
> 
> clinfo 
> Number of platforms   1
>   Platform Name   Clover
>   Platform Vendor Mesa
>   Platform VersionOpenCL 1.1 Mesa
> 18.3.1
>   Platform ProfileFULL_PROFILE
>   Platform Extensions cl_khr_icd
>   Platform Extensions function suffix MESA
> 
>   Platform Name   Clover
> Number of devices 0
> 
> NULL platform behavior
>   clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  Clover
>   clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   
>   clCreateContext(NULL, ...) [default]No devices found in
> platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT)  No devices
> found in platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found
> in platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  No devices found
> in platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices
> found in platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices
> found in platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  No devices found
> in platform
> 
> ICD loader properties
>   ICD loader Name OpenCL ICD Loader
>   ICD loader Vendor   OCL Icd free software
>   ICD loader Version          2.2.12
>   ICD loader Profile  OpenCL 2.2
> 
> AndyBe
> Am Samstag, den 12.01.2019, 16:39 -0500 schrieb Jan Vesely:
> > Hi,
> > 
> > you're not very specific what 'break' means. Mesa libOpenCL.so does
> > not support loading additional opencl icd drivers.
> > It is, however, possible to use mesa as an icd driver
> > (libMesaOpenCL.so) which can be loaded by an icd loader, such as ocl-
> > icd, or other opencl drivers.
> > 
> > Jan
> > 
> > 
> > On Thu, 2019-01-10 at 19:58 +0100, andreas.benz...@googlemail.com
> > wrote:
> > > Hello Everyone,
> > > 
> > > at this moment I develop on freedesktop opencl. Current the mesa
> > > opencl
> > > break clinfo to read the information from nvidia when mesa opencl
> > > is
> > > available. There is no other graphic card plugged in.
> > > 
> > > The stable 18.3.1 it works.
> > >  
> > > Don't know how to analise this kind of problem.
> > > 
> > > Sincerely
> > > 
> > > AndyBe
> > > 
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesa git break nvidia opencl

[Jan Vesely]

Hi,

you're not very specific what 'break' means. Mesa libOpenCL.so does
not support loading additional opencl icd drivers.
It is, however, possible to use mesa as an icd driver
(libMesaOpenCL.so) which can be loaded by an icd loader, such as ocl-
icd, or other opencl drivers.

Jan


On Thu, 2019-01-10 at 19:58 +0100, andreas.benz...@googlemail.com
wrote:
> Hello Everyone,
> 
> at this moment I develop on freedesktop opencl. Current the mesa opencl
> break clinfo to read the information from nvidia when mesa opencl is
> available. There is no other graphic card plugged in.
> 
> The stable 18.3.1 it works.
>  
> Don't know how to analise this kind of problem.
> 
> Sincerely
> 
> AndyBe
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson, anv: Add inc_vulkan to include directories

[Jan Vesely]

On Wed, 2018-12-26 at 15:26 +, Eric Engestrom wrote:
> On Tuesday, 2018-12-25 23:09:53 +0100, Jan Vesely wrote:
> > Guess my meson-fu is still pretty weak.
> > Now I see the build failure again:
> > In file included from ../mesa/src/intel/vulkan/anv_private.h:77:0,
> >  from ../mesa/src/intel/vulkan/genX_pipeline.c:24:
> > src/../include/vulkan/vulkan_intel.h:27:10: fatal error: vulkan.h: No such
> > file or directory
> >  #include "vulkan.h"
> >   ^~
> > compilation terminated.
> > [189/1491] Compiling C++ object 'src/c...49@@glsl@sta
> > /builtin_functions.cpp.o'.
> > ninja: build stopped: subcommand failed.
> > 
> > Honestly, I've no idea how '#include "vulkan.h"' should work
> 
> It's documented here:
> http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
> 
> The bit we care about in this instance is the first paragraph:
> 
>   > By default, the preprocessor looks for header files included by the
>   > quote form of the directive `#include "file"` first relative to the
>   > directory of the current file, and then in a preconfigured list of
>   > standard system directories. For example, if /usr/include/sys/stat.h
>   > contains `#include "types.h"`, GCC looks for types.h first in
>   > /usr/include/sys, then in its usual search path.
> 
> Which means that include/vulkan/vulkan_intel.h having `#include "vulkan.h"`
> will first match include/vulkan/vulkan.h, which is exactly the correct
> path.
> 
> I'm really confused as to how you can see this failure.

OK, the problem was that I used install prefix identical with the
builddir so the files would not be in the same location:

$ ls mesa-meson-64/include/vulkan/
vulkan_intel.h

$ ls mesa/include/vulkan/
vk_android_native_buffer.h  vulkan.h  vulkan_win32.h
vk_icd.hvulkan_intel.hvulkan_xcb.h
vk_platform.h   vulkan_ios.h  vulkan_xlib.h
vulkan_android.hvulkan_macos.hvulkan_xlib_randr.h
vulkan_core.h   vulkan_vi.h   vulkan_xlib_xrandr.h
vulkan_fuchsia.hvulkan_wayland.h

although, it's a bit weird that only vulkan_intel.h got installed.

sorry for the noise,
Jan

> 
> 
> 
> > 
> > 
> > Jan
> > 
> > On Mon, Dec 24, 2018 at 10:51 AM Jan Vesely  wrote:
> > 
> > > On Sun, 2018-12-23 at 15:35 +, Eric Engestrom wrote:
> > > > On Sunday, 2018-12-23 12:31:20 +0100, Jan Vesely wrote:
> > > > > From: Jan Vesely 
> > > > > 
> > > > > intel_vulkan.h uses '#include "vulkan.h"' so the file needs to be in
> > > > > include path.
> > > > > Fixes meson build of anv
> > > > 
> > > > Hmm, that doesn't look?
> > > > 
> > > > include/vulkan/vulkan_intel.h has `#include "vulkan.h"`, which lives at
> > > > include/vulkan/vulkan.h, ie. in the same directory, so the current code
> > > > should work?
> > > > 
> > > > What failure do you see, and in what circumstance?
> > > > 
> > > > Could it be related to left over autotools files in your source dir?
> > > > Try again in a fresh clone?
> > > 
> > > hm, I can't reproduce it again after the latest pull and git clean. I
> > > guess it was an artifact of switching to meson.
> > > 
> > > sorry for the noise.
> > > thanks,
> > > Jan
> > > 
> > > > 
> > > > > 
> > > > > Signed-off-by: Jan Vesely 
> > > > > ---
> > > > >  src/intel/vulkan/meson.build | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/src/intel/vulkan/meson.build
> > > 
> > > b/src/intel/vulkan/meson.build
> > > > > index e30e922528..d1c89be0f8 100644
> > > > > --- a/src/intel/vulkan/meson.build
> > > > > +++ b/src/intel/vulkan/meson.build
> > > > > @@ -181,7 +181,7 @@ libanv_common = static_library(
> > > > >[libanv_files, anv_entrypoints, anv_extensions_c, anv_extensions_h,
> > > 
> > > sha1_h],
> > > > >include_directories : [
> > > > >  inc_common, inc_intel, inc_compiler, inc_drm_uapi,
> > > 
> > > inc_vulkan_util,
> > > > > -inc_vulkan_wsi,
> > > > > +inc_vulkan_wsi, inc_vulkan
> > > > >],
> > > > >c_args : anv_flags,
> > > > >dependencies : anv_deps,
> > > > > --
> > > > > 2.19.2
> > > > > 
> > > > > ___
> > > > > 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
> > > 
> > > --
> > > Jan Vesely 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson, anv: Add inc_vulkan to include directories

[Jan Vesely]

Guess my meson-fu is still pretty weak.
Now I see the build failure again:
In file included from ../mesa/src/intel/vulkan/anv_private.h:77:0,
 from ../mesa/src/intel/vulkan/genX_pipeline.c:24:
src/../include/vulkan/vulkan_intel.h:27:10: fatal error: vulkan.h: No such
file or directory
 #include "vulkan.h"
  ^~
compilation terminated.
[189/1491] Compiling C++ object 'src/c...49@@glsl@sta
/builtin_functions.cpp.o'.
ninja: build stopped: subcommand failed.

Honestly, I've no idea how '#include "vulkan.h"' should work


Jan

On Mon, Dec 24, 2018 at 10:51 AM Jan Vesely  wrote:

> On Sun, 2018-12-23 at 15:35 +, Eric Engestrom wrote:
> > On Sunday, 2018-12-23 12:31:20 +0100, Jan Vesely wrote:
> > > From: Jan Vesely 
> > >
> > > intel_vulkan.h uses '#include "vulkan.h"' so the file needs to be in
> > > include path.
> > > Fixes meson build of anv
> >
> > Hmm, that doesn't look?
> >
> > include/vulkan/vulkan_intel.h has `#include "vulkan.h"`, which lives at
> > include/vulkan/vulkan.h, ie. in the same directory, so the current code
> > should work?
> >
> > What failure do you see, and in what circumstance?
> >
> > Could it be related to left over autotools files in your source dir?
> > Try again in a fresh clone?
>
> hm, I can't reproduce it again after the latest pull and git clean. I
> guess it was an artifact of switching to meson.
>
> sorry for the noise.
> thanks,
> Jan
>
> >
> > >
> > > Signed-off-by: Jan Vesely 
> > > ---
> > >  src/intel/vulkan/meson.build | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/src/intel/vulkan/meson.build
> b/src/intel/vulkan/meson.build
> > > index e30e922528..d1c89be0f8 100644
> > > --- a/src/intel/vulkan/meson.build
> > > +++ b/src/intel/vulkan/meson.build
> > > @@ -181,7 +181,7 @@ libanv_common = static_library(
> > >[libanv_files, anv_entrypoints, anv_extensions_c, anv_extensions_h,
> sha1_h],
> > >include_directories : [
> > >  inc_common, inc_intel, inc_compiler, inc_drm_uapi,
> inc_vulkan_util,
> > > -inc_vulkan_wsi,
> > > +inc_vulkan_wsi, inc_vulkan
> > >],
> > >c_args : anv_flags,
> > >dependencies : anv_deps,
> > > --
> > > 2.19.2
> > >
> > > ___
> > > 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
>
> --
> Jan Vesely 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson, anv: Add inc_vulkan to include directories

[Jan Vesely]

On Sun, 2018-12-23 at 15:35 +, Eric Engestrom wrote:
> On Sunday, 2018-12-23 12:31:20 +0100, Jan Vesely wrote:
> > From: Jan Vesely 
> > 
> > intel_vulkan.h uses '#include "vulkan.h"' so the file needs to be in
> > include path.
> > Fixes meson build of anv
> 
> Hmm, that doesn't look?
> 
> include/vulkan/vulkan_intel.h has `#include "vulkan.h"`, which lives at
> include/vulkan/vulkan.h, ie. in the same directory, so the current code
> should work?
> 
> What failure do you see, and in what circumstance?
> 
> Could it be related to left over autotools files in your source dir?
> Try again in a fresh clone?

hm, I can't reproduce it again after the latest pull and git clean. I
guess it was an artifact of switching to meson.

sorry for the noise.
thanks,
Jan

> 
> > 
> > Signed-off-by: Jan Vesely 
> > ---
> >  src/intel/vulkan/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
> > index e30e922528..d1c89be0f8 100644
> > --- a/src/intel/vulkan/meson.build
> > +++ b/src/intel/vulkan/meson.build
> > @@ -181,7 +181,7 @@ libanv_common = static_library(
> >[libanv_files, anv_entrypoints, anv_extensions_c, anv_extensions_h, 
> > sha1_h],
> >include_directories : [
> >  inc_common, inc_intel, inc_compiler, inc_drm_uapi, inc_vulkan_util,
> > -inc_vulkan_wsi,
> > +inc_vulkan_wsi, inc_vulkan
> >],
> >c_args : anv_flags,
> >dependencies : anv_deps,
> > -- 
> > 2.19.2
> > 
> > ___
> > 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

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson, anv: Add inc_vulkan to include directories

[Jan Vesely]

From: Jan Vesely 

intel_vulkan.h uses '#include "vulkan.h"' so the file needs to be in
include path.
Fixes meson build of anv

Signed-off-by: Jan Vesely 
---
 src/intel/vulkan/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index e30e922528..d1c89be0f8 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -181,7 +181,7 @@ libanv_common = static_library(
   [libanv_files, anv_entrypoints, anv_extensions_c, anv_extensions_h, sha1_h],
   include_directories : [
 inc_common, inc_intel, inc_compiler, inc_drm_uapi, inc_vulkan_util,
-inc_vulkan_wsi,
+inc_vulkan_wsi, inc_vulkan
   ],
   c_args : anv_flags,
   dependencies : anv_deps,
-- 
2.19.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/1] clover: Fix build after clang r348827

[Jan Vesely]

On Sun, 2018-12-16 at 10:36 +0100, Kai Wasserbäch wrote:
> Jan Vesely wrote on 13.12.18 22:17:
> > CodeGenOptions were moved to Basic.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109039
> > Signed-off-by: Jan Vesely 
> 
> Since this is the same as my patch
> (<https://patchwork.freedesktop.org/patch/268295/>) but older than mine, you 
> can
> have my:
> 
>  Reviewed-by: Kai Wasserbäch 

Thank you both,
Jan

> 
> Cheers,
> Kai
> 
> 
> > ---
> >  src/gallium/state_trackers/clover/llvm/compat.hpp | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > index 975012cbda..b91cb95a29 100644
> > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > @@ -58,9 +58,14 @@
> >  #include 
> >  
> >  #include 
> > -#include 
> >  #include 
> >  
> > +#if HAVE_LLVM >= 0x0800
> > +#include 
> > +#else
> > +#include 
> > +#endif
> > +
> >  namespace clover {
> > namespace llvm {
> >namespace compat {
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/1] clover: Fix build after clang r348827

[Jan Vesely]

CodeGenOptions were moved to Basic.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109039
Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/llvm/compat.hpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 975012cbda..b91cb95a29 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -58,9 +58,14 @@
 #include 
 
 #include 
-#include 
 #include 
 
+#if HAVE_LLVM >= 0x0800
+#include 
+#else
+#include 
+#endif
+
 namespace clover {
namespace llvm {
   namespace compat {
-- 
2.19.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] drop autotools

[Jan Vesely]

On Mon, 2018-12-03 at 16:17 -0800, Dylan Baker wrote:
> Quoting Bas Nieuwenhuizen (2018-12-03 14:14:19)
> > On Mon, Dec 3, 2018 at 7:30 PM Jan Vesely  wrote:
> > > On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote:
> > > > Cc: Emil Velikov 
> > > > Cc: Andres Gomez 
> > > > Cc: Juan A. Suarez Romero 
> > > > Cc: Dylan Baker 
> > > > Signed-off-by: Eric Engestrom 
> > > > ---
> > > > This patch depends on the releasing procedure in docs/releasing.html to
> > > > be updated to not rely on autotools anymore.
> > > > 
> > > > I think our release managers (cc'ed) should work together and figure out
> > > > the procedure they want to go by; only once that's done can we delete
> > > > these 200+ files and 14k+ lines :)
> > > 
> > > once again, I'm going to request that this patch is delayed until meson
> > > 0.49 is more widely available (it has not been released yet!).
> > > afaik, there is currently no way to build against non-default llvm
> > > outside autotools.
> > 
> > Can't you just add the llvm-config of the non-default to the PATH (and
> > if you have a setup which instead of putting it in a different path
> > suffixes it, make a new directory, add a llvm-config symlink in there
> > and add that to the PATH)? I've been building with non-default llvm
> > for ages with meson.

It works as a backstop for scripted updates. The problem is that the
next rebuild will silently switch to system default llvm, so I'd need
to set the PATH before every ninja call.

> You can, that's what I've done as well. 0.49 just has a much nicer mechanism
> (and one that presumably distro packagers can use more easily).

I don't understand why distros are such a big focus. Don't they all
have scripts to build packages? Why would volatility of configuration
options be a problem for them?
Then again I'm not a distro maintainer ...

Jan

> 
> Dylan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] drop autotools

[Jan Vesely]

On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote:
> Cc: Emil Velikov 
> Cc: Andres Gomez 
> Cc: Juan A. Suarez Romero 
> Cc: Dylan Baker 
> Signed-off-by: Eric Engestrom 
> ---
> This patch depends on the releasing procedure in docs/releasing.html to
> be updated to not rely on autotools anymore.
> 
> I think our release managers (cc'ed) should work together and figure out
> the procedure they want to go by; only once that's done can we delete
> these 200+ files and 14k+ lines :)

once again, I'm going to request that this patch is delayed until meson
0.49 is more widely available (it has not been released yet!).
afaik, there is currently no way to build against non-default llvm
outside autotools.

Jan

> ---
>  .gitignore|   54 -
>  Makefile.am   |   92 -
>  REVIEWERS |9 -
>  autogen.sh|   14 -
>  bin/.gitignore|9 -
>  configure.ac  | 3375 -
>  docs/autoconf.html|  264 --
>  docs/contents.html|1 -
>  docs/download.html|1 -
>  docs/install.html |   21 +-
>  docs/llvmpipe.html|8 -
>  docs/mangling.html|2 +-
>  docs/meson.html   |2 +-
>  docs/relnotes/19.0.0.html |7 +-
>  doxygen/.gitignore|   19 -
>  m4/.gitignore |5 -
>  m4/ax_check_compile_flag.m4   |   79 -
>  m4/ax_check_gnu_make.m4   |   78 -
>  m4/ax_check_python_mako_module.m4 |   64 -
>  m4/ax_gcc_builtin.m4  |  168 -
>  m4/ax_gcc_func_attribute.m4   |  230 --
>  m4/ax_prog_bison.m4   |   71 -
>  m4/ax_prog_flex.m4|   63 -
>  m4/ax_pthread.m4  |  309 --
>  src/Makefile.am   |  138 -
>  src/amd/Makefile.addrlib.am   |   40 -
>  src/amd/Makefile.am   |   35 -
>  src/amd/Makefile.common.am|   71 -
>  src/amd/common/.gitignore |1 -
>  src/amd/vulkan/.gitignore |9 -
>  src/amd/vulkan/Makefile.am|  200 -
>  src/broadcom/.gitignore   |3 -
>  src/broadcom/Makefile.am  |   65 -
>  src/broadcom/Makefile.cle.am  |6 -
>  src/broadcom/Makefile.genxml.am   |   54 -
>  src/broadcom/Makefile.v3d.am  |   32 -
>  src/broadcom/qpu/tests/.gitignore |1 -
>  src/compiler/.gitignore   |6 -
>  src/compiler/Makefile.am  |   77 -
>  src/compiler/Makefile.glsl.am |  264 --
>  src/compiler/Makefile.nir.am  |  116 -
>  src/compiler/Makefile.spirv.am|   59 -
>  src/compiler/glsl/.gitignore  |   12 -
>  src/compiler/glsl/glcpp/.gitignore|6 -
>  src/compiler/glsl/glcpp/tests/.gitignore  |4 -
>  src/compiler/glsl/tests/.gitignore|6 -
>  src/compiler/glsl/tests/warnings/.gitignore   |1 -
>  src/compiler/nir/.gitignore   |7 -
>  src/compiler/nir/tests/.gitignore |1 -
>  src/compiler/spirv/.gitignore |2 -
>  src/egl/.gitignore|2 -
>  src/egl/Makefile.am   |  235 --
>  src/egl/drivers/dri2/.gitignore   |2 -
>  src/egl/wayland/wayland-drm/.gitignore|3 -
>  src/egl/wayland/wayland-drm/Makefile.am   |   37 -
>  src/freedreno/Makefile.am |   76 -
>  src/gallium/Automake.inc  |   90 -
>  src/gallium/Makefile.am   |  211 --
>  src/gallium/auxiliary/Makefile.am |  134 -
>  src/gallium/auxiliary/indices/.gitignore  |2 -
>  src/gallium/auxiliary/pipe-loader/Makefile.am |   51 -
>  src/gallium/auxiliary/util/.gitignore |2 -
>  src/gallium/drivers/etnaviv/.gitignore|1 -
>  src/gallium/drivers/etnaviv/Automake.inc  |   11 -
>  src/gallium/drivers/etnaviv/Makefile.am   |   46 -
>  src/gallium/drivers/freedreno/.gitignore  |2 -
>  src/gallium/drivers/freedreno/Automake.inc|   13 -
>  src/gallium/drivers/freedreno/Makefile.am |   23 -
>  src/gallium/drivers/i915/Automake.inc |   11 -
>  src/gallium/drivers/i915/Makefile.am  |   33 -
>  src/gallium/drivers/imx/Automake.inc  |9 -
>  src/gallium/drivers/imx/Makefile.am   |8 -
>  src/gallium/drivers/llvmpipe/.gitignore   |5 -
>  

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Wed, 2018-11-07 at 13:05 -0800, Matt Turner wrote:
> On Wed, Nov 7, 2018 at 12:53 PM Jan Vesely  wrote:
> > On Wed, 2018-11-07 at 18:51 +, Emil Velikov wrote:
> > > On Wed, 7 Nov 2018 at 18:39, Jan Vesely  wrote:
> > > > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote:
> > > > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer  wrote:
> > > > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote:
> > > > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote:
> > > > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely 
> > > > > > > >  wrote:
> > > > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
> > > > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer 
> > > > > > > > > >  wrote:
> > > > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env 
> > > > > > > > > > > > var remembered
> > > > > > > > > > > > between reconfigure (touch configure.ac; make) or do I 
> > > > > > > > > > > > need to provide
> > > > > > > > > > > > it explicitly every time configure is run?
> > > > > > > > > > > 
> > > > > > > > > > > I don't know the answer, but agree that would be a 
> > > > > > > > > > > minimum requirement
> > > > > > > > > > > for this change.
> > > > > > > > > > > 
> > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been 
> > > > > > > > > > around for
> > > > > > > > > > years, it will work for any Mesa checkout since its 
> > > > > > > > > > inception.
> > > > > > > > > > You can safely bisect Mesa and things will just work.
> > > > > > > > > 
> > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every 
> > > > > > > > > time
> > > > > > > > > bisect changes configure.ac?
> > > > > > > > > 
> > > > > > > > You can do (although there's other options if this one seems 
> > > > > > > > weird)
> > > > > > > > 
> > > > > > > > $ LLVM_CONFIG=... ../autogen.sh
> > > > > > > 
> > > > > > > That does not answer my question.
> > > > > > > 
> > > > > > > suppose the following sequence:
> > > > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config 
> > > > > > > ../mesa-src/autogen.sh
> > > > > > > ...
> > > > > > > llvm:yes
> > > > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config
> > > > > > > llvm-version:4.0.1
> > > > > > > ...
> > > > > > > $ make -j128
> > > > > > > $ touch ../mesa-src/configure.ac
> > > > > > > $ make -j128
> > > > > > > ...
> > > > > > > llvm:yes
> > > > > > > llvm-config: /usr/bin/llvm-config
> > > > > > > llvm-version:7.0.0
> > > > > > > ...
> > > > > > > 
> > > > > > > the second reconfigure silently reverted back to system default 
> > > > > > > llvm.
> > > > > > > That's a loss of capabilty for me.
> > > > > > 
> > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the
> > > > > > current form.
> > > > > > 
> > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it 
> > > > > > might
> > > > > > not be too hard to make this work with the environment variable. I 
> > > > > > don't
> > > > > > know the preferred way to do that however.
> > > > > > 
> > > > > Right, I misread the usecase :-( Sorry about that.
> > > > > The following works like a charm:
> > &

Re: [Mesa-dev] [PATCH 08/12] meson doesn't use env vars, WAS: configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Wed, 2018-11-07 at 11:34 -0800, Dylan Baker wrote:
> Quoting Jan Vesely (2018-11-07 10:39:48)
> > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote:
> > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer  wrote:
> > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote:
> > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote:
> > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely  
> > > > > > wrote:
> > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
> > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer 
> > > > > > > >  wrote:
> > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var 
> > > > > > > > > > remembered
> > > > > > > > > > between reconfigure (touch configure.ac; make) or do I need 
> > > > > > > > > > to provide
> > > > > > > > > > it explicitly every time configure is run?
> > > > > > > > > 
> > > > > > > > > I don't know the answer, but agree that would be a minimum 
> > > > > > > > > requirement
> > > > > > > > > for this change.
> > > > > > > > > 
> > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been 
> > > > > > > > around for
> > > > > > > > years, it will work for any Mesa checkout since its inception.
> > > > > > > > You can safely bisect Mesa and things will just work.
> > > > > > > 
> > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time
> > > > > > > bisect changes configure.ac?
> > > > > > > 
> > > > > > You can do (although there's other options if this one seems weird)
> > > > > > 
> > > > > > $ LLVM_CONFIG=... ../autogen.sh
> > > > > 
> > > > > That does not answer my question.
> > > > > 
> > > > > suppose the following sequence:
> > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh
> > > > > ...
> > > > > llvm:yes
> > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config
> > > > > llvm-version:4.0.1
> > > > > ...
> > > > > $ make -j128
> > > > > $ touch ../mesa-src/configure.ac
> > > > > $ make -j128
> > > > > ...
> > > > > llvm:yes
> > > > > llvm-config: /usr/bin/llvm-config
> > > > > llvm-version:7.0.0
> > > > > ...
> > > > > 
> > > > > the second reconfigure silently reverted back to system default llvm.
> > > > > That's a loss of capabilty for me.
> > > > 
> > > > Thanks for checking, Jan. That's a NAK from me for this patch in the
> > > > current form.
> > > > 
> > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might
> > > > not be too hard to make this work with the environment variable. I don't
> > > > know the preferred way to do that however.
> > > > 
> > > Right, I misread the usecase :-( Sorry about that.
> > > The following works like a charm:
> > > 
> > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/...
> > > make
> > > touch .../configure.ac
> > > make
> > 
> > ouch, that's rather ugly. What is the reason to prefer env var vs.
> > proper option (like --with-llvm-config)?
> > meson also seems to prefer env var for some reason.
> 
> Actually, we (meson) made the concious choice not to use env vars, our 
> solution
> is config files (like cross files) for native compilation. They work just like
> cross file, but for native compilation (load at initial configuration, don't
> reload change on subsequent reconfigurations):
> 
> $ cat llvm-4.0
> [binaries]
> llvm-config = /usr/local/lib/llvm-4.0/bin/llvm-config
> 
> $ meson build --native-file llvm-4.0
> 
> Hopefully this series in the in the final stretch and can land shortly, and be
> present in 0.49.0

thanks for the clarification. as long as the setting survives
reconfigure+rebuild I'm fine.
just out of curiosity. can meson combine multiple native files, or do
you need to crate a new one with the desired combination of settings?

thanks,
Jan

> 
> Dylan



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Wed, 2018-11-07 at 18:51 +, Emil Velikov wrote:
> On Wed, 7 Nov 2018 at 18:39, Jan Vesely  wrote:
> > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote:
> > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer  wrote:
> > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote:
> > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote:
> > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely  
> > > > > > wrote:
> > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
> > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer 
> > > > > > > >  wrote:
> > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var 
> > > > > > > > > > remembered
> > > > > > > > > > between reconfigure (touch configure.ac; make) or do I need 
> > > > > > > > > > to provide
> > > > > > > > > > it explicitly every time configure is run?
> > > > > > > > > 
> > > > > > > > > I don't know the answer, but agree that would be a minimum 
> > > > > > > > > requirement
> > > > > > > > > for this change.
> > > > > > > > > 
> > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been 
> > > > > > > > around for
> > > > > > > > years, it will work for any Mesa checkout since its inception.
> > > > > > > > You can safely bisect Mesa and things will just work.
> > > > > > > 
> > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time
> > > > > > > bisect changes configure.ac?
> > > > > > > 
> > > > > > You can do (although there's other options if this one seems weird)
> > > > > > 
> > > > > > $ LLVM_CONFIG=... ../autogen.sh
> > > > > 
> > > > > That does not answer my question.
> > > > > 
> > > > > suppose the following sequence:
> > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh
> > > > > ...
> > > > > llvm:yes
> > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config
> > > > > llvm-version:4.0.1
> > > > > ...
> > > > > $ make -j128
> > > > > $ touch ../mesa-src/configure.ac
> > > > > $ make -j128
> > > > > ...
> > > > > llvm:yes
> > > > > llvm-config: /usr/bin/llvm-config
> > > > > llvm-version:7.0.0
> > > > > ...
> > > > > 
> > > > > the second reconfigure silently reverted back to system default llvm.
> > > > > That's a loss of capabilty for me.
> > > > 
> > > > Thanks for checking, Jan. That's a NAK from me for this patch in the
> > > > current form.
> > > > 
> > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might
> > > > not be too hard to make this work with the environment variable. I don't
> > > > know the preferred way to do that however.
> > > > 
> > > Right, I misread the usecase :-( Sorry about that.
> > > The following works like a charm:
> > > 
> > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/...
> > > make
> > > touch .../configure.ac
> > > make
> > 
> > ouch, that's rather ugly. What is the reason to prefer env var vs.
> > proper option (like --with-llvm-config)?
> > meson also seems to prefer env var for some reason.
> > I don't mind spending the time to send out the patches, but I'd like to
> > make sure it's not a wasted effort.
> > 
> From a general distribution POV, adding llvm-config to every project
> 'feels' wasteful IMHO. Even if we ignore the "feels" part, there's the
> aspect of duplicating the same code in XX projects.
> Which with due time will result in a behavioural shift as copies diverge.
> 
> In Mesa the toggle conflicts, in some weird ways, with the existing
> --with-clang-libdir

The idea would be to have one --with-llvm-config switch that subsumes
all llvm related options (except maybe static vs. dynamic linking).

I do

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote:
> On Thu, 1 Nov 2018 at 16:13, Michel Dänzer  wrote:
> > On 2018-11-01 5:03 p.m., Jan Vesely wrote:
> > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote:
> > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely  wrote:
> > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
> > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer  
> > > > > > wrote:
> > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var 
> > > > > > > > remembered
> > > > > > > > between reconfigure (touch configure.ac; make) or do I need to 
> > > > > > > > provide
> > > > > > > > it explicitly every time configure is run?
> > > > > > > 
> > > > > > > I don't know the answer, but agree that would be a minimum 
> > > > > > > requirement
> > > > > > > for this change.
> > > > > > > 
> > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been around for
> > > > > > years, it will work for any Mesa checkout since its inception.
> > > > > > You can safely bisect Mesa and things will just work.
> > > > > 
> > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time
> > > > > bisect changes configure.ac?
> > > > > 
> > > > You can do (although there's other options if this one seems weird)
> > > > 
> > > > $ LLVM_CONFIG=... ../autogen.sh
> > > 
> > > That does not answer my question.
> > > 
> > > suppose the following sequence:
> > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh
> > > ...
> > > llvm:yes
> > > llvm-config: /usr/local/llvm-4/bin/llvm-config
> > > llvm-version:4.0.1
> > > ...
> > > $ make -j128
> > > $ touch ../mesa-src/configure.ac
> > > $ make -j128
> > > ...
> > > llvm:yes
> > > llvm-config: /usr/bin/llvm-config
> > > llvm-version:7.0.0
> > > ...
> > > 
> > > the second reconfigure silently reverted back to system default llvm.
> > > That's a loss of capabilty for me.
> > 
> > Thanks for checking, Jan. That's a NAK from me for this patch in the
> > current form.
> > 
> > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might
> > not be too hard to make this work with the environment variable. I don't
> > know the preferred way to do that however.
> > 
> Right, I misread the usecase :-( Sorry about that.
> The following works like a charm:
> 
> .../autogen.sh ac_cv_path_LLVM_CONFIG=/...
> make
> touch .../configure.ac
> make

ouch, that's rather ugly. What is the reason to prefer env var vs.
proper option (like --with-llvm-config)?
meson also seems to prefer env var for some reason.
I don't mind spending the time to send out the patches, but I'd like to
make sure it's not a wasted effort.

thanks,
Jan

> 
> > P.S. I only just now noticed the discrepancy between the commit log
> > talking about "deprecation", whereas the patch actually makes the option
> > ineffective. That's not what deprecation means. Also, I'm not sure how
> > this patch is related to the series' general theme of bumping the
> > minimum required LLVM version. Please don't bury unrelated patches in
> > large series.
> > 
> Merely following suite - see commit e2afa154e99071e8d51be88494cd1347ad113035
> The series does the following:
> - bumps the version
> - removes build-wise LLVM hacks - now dead
> - removes old LLVM codepaths - now dea
> 
> I could have split it in three, yet it seems like be a serious overkill.
> 
> That said, can we hear some directions/preferences of how to move
> things forward?
> I'm slightly worries that we may end up in the XKCD Workflow case :-(
> 
> Thanks
> Emil



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] amd: Make vgpr-spilling depend on llvm version

[Jan Vesely]

The option was removed in LLVM r345763
Signed-off-by: Jan Vesely 
---
 src/amd/common/ac_llvm_util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 69d9f7b9f3..dc9b684e9d 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -153,7 +153,8 @@ static LLVMTargetMachineRef ac_create_target_machine(enum 
radeon_family family,
LLVMTargetRef target = ac_get_llvm_target(triple);
 
snprintf(features, sizeof(features),
-
"+DumpCode,+vgpr-spilling,-fp32-denormals,+fp64-denormals%s%s%s%s",
+"+DumpCode,-fp32-denormals,+fp64-denormals%s%s%s%s%s",
+HAVE_LLVM >= 0x0800 ? "" : ",+vgpr-spilling",
 tm_options & AC_TM_SISCHED ? ",+si-scheduler" : "",
 tm_options & AC_TM_FORCE_ENABLE_XNACK ? ",+xnack" : "",
 tm_options & AC_TM_FORCE_DISABLE_XNACK ? ",-xnack" : "",
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote:
> On Wed, 31 Oct 2018 at 17:41, Jan Vesely  wrote:
> > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
> > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer  wrote:
> > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > > > On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> > > > > > From: Emil Velikov 
> > > > > > 
> > > > > > The option has been long superseded with LLVM_CONFIG.
> > > > > > Distributions have been using it for a couple of years now.
> > > > > 
> > > > > I've been using it in my configure setup.
> > > > 
> > > > Same here.
> > > > 
> > > Have you tried LLVM_CONFIG, does it not work on your setup?
> > > Alternatively can you update the your scripts, I can provide a patch
> > > if you prefer.
> > 
> > I'm testing mesa/clover for llvm-{5,6,7,git} on three machines, before
> > I start migrating all that setup I wanted to know if a capability is
> > lost and I should start rewriting the scripts or a simple reconfigure
> > in build directories is enough.
> > 
> No capability is lost here.

It is loosing capability to remember configuration. see below.

> 
> > > Even Debian (which I personally consider fairly conservative) has been
> > > using it for a minimum of two years.
> > > https://salsa.debian.org/xorg-team/lib/mesa/commit/436b3472adde14b22e9ce204820dab417cfe00c6
> > 
> > I'm sorry. This is completely irrelevant. I don't care what distros
> > use, I build from source.
> > 
> 
> 
> Hope you don't do the whole distro...
> 
> Although I guess I'm may be an exception by keeping an eye what "my"
> distro does ;-)
> 

Why the mockery? do you not build libraries you work on?
OpenCL programs can run into issues in either mesa or llvm or libclc.
The last one was/is in the relatively worst shape so most of the effort
goes there. Since distros don't offer multiple mesa packages built
against different LLVM versions I need to build from source.

> > > > > This might be a stupid question; is the LLVM_CONFIG env var remembered
> > > > > between reconfigure (touch configure.ac; make) or do I need to provide
> > > > > it explicitly every time configure is run?
> > > > 
> > > > I don't know the answer, but agree that would be a minimum requirement
> > > > for this change.
> > > > 
> > > Nope, yet it's not really a minimum. LLVM_CONFIG has been around for
> > > years, it will work for any Mesa checkout since its inception.
> > > You can safely bisect Mesa and things will just work.
> > 
> > The question is; Do I have to do "LLVM_CONFIG=..." make every time
> > bisect changes configure.ac?
> > 
> You can do (although there's other options if this one seems weird)
> 
> $ LLVM_CONFIG=... ../autogen.sh

That does not answer my question.

suppose the following sequence:
$ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh
...
llvm:yes
llvm-config: /usr/local/llvm-4/bin/llvm-config
llvm-version:4.0.1
...
$ make -j128
$ touch ../mesa-src/configure.ac
$ make -j128
...
llvm:yes
llvm-config: /usr/bin/llvm-config
llvm-version:7.0.0
...

the second reconfigure silently reverted back to system default llvm.
That's a loss of capabilty for me.
Why was it even moved to env var? what's the problem with having "
--with-llvm-config" (or with-llvm-prefix) configure option?
Why should the build system be focused on distros (with custom
packaging scripts) over those who build from source?

Jan

> HTH
> Emil

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] clover: remove pre LLVM 5.0 codepaths

[Jan Vesely]

On Wed, 2018-10-31 at 16:14 -0700, Dylan Baker wrote:
> Quoting Jan Vesely (2018-10-31 11:37:19)
> > On Wed, 2018-10-31 at 11:22 -0700, Francisco Jerez wrote:
> > > I don't object removing the pre-LLVM 5.0 paths, nor keeping them around
> > > in order to make r600 happy.  What would it take to forward-port the
> > > r600 image support code to more recent LLVM versions?
> > 
> > Converting the llvm pass to the new style of metadata passing and
> > updating libclc builtins.
> > There are things higher on my priority list wrt clover/libclc (fixing
> > rounding routines,
> > 
> > replacing the build system,
> 
> Do you have a build system in mind? I started doing a meson port for wrap
> purposes at one point, I could push it somewhere public if that interests you.

Thanks, but as an LLVM project I think cmake would be a better fit. I'm
still not sure what the place of libclc will be after LLVM converts to
git mono repo.

Jan

> 
> > adding support for
> > buffer sharing between devices). it will take some time unless someone
> > else volunteers.
> > 
> > Jan
> > 
> > > Jan Vesely  writes:
> > > 
> > > > On Wed, 2018-10-31 at 17:02 +, Emil Velikov wrote:
> > > > > On Wed, 31 Oct 2018 at 15:57, Jan Vesely  
> > > > > wrote:
> > > > > > On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> > > > > > > From: Emil Velikov 
> > > > > > > 
> > > > > > > LLVM versions earlier than 5.0.1 are no longer supported.
> > > > > > 
> > > > > > I'd prefer to keep llvm-3.9, since it's the last version that 
> > > > > > supports
> > > > > > images for r600, but I'd leave the final decision to Francisco.
> > > > > > 
> > > > > Was it just image support that was dropped or all of r600?
> > > > > I take it there's not enough interest/manpower to address that?
> > > > > 
> > > > > I'm curious how are you building/managing things:
> > > > >  - full build with LLVM 3.9
> > > > >  - r600 build with LLVM 3.9, and another for $other component using 
> > > > > newer LLVM
> > > > >  - other
> > > > 
> > > > I build only clover+r600, mostly to occasionally check that libclc
> > > > still works as expected. I don't expect mixing of LLVM versions to work
> > > > (although with versioned symbols it should).
> > > > I can always fall back to older mesa release for this, but building
> > > > from one source is nice, feel free to go ahead with Francisco's ack.
> > > > 
> > > > Jan
> > > > 
> > > > > If really needed, we could keep 3.9 solely for r600 and use 5.0.1+ 
> > > > > elsewhere.
> > > > > Considering LLVM 3.9 isn't getting new updates with last one being in
> > > > > Sep 2016 we are seriously clinging to straws.
> > > > > 
> > > > > Thanks
> > > > > Emil
> > > > 
> > > > -- 
> > > > Jan Vesely 
> > 
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] clover: remove pre LLVM 5.0 codepaths

[Jan Vesely]

On Wed, 2018-10-31 at 11:22 -0700, Francisco Jerez wrote:
> I don't object removing the pre-LLVM 5.0 paths, nor keeping them around
> in order to make r600 happy.  What would it take to forward-port the
> r600 image support code to more recent LLVM versions?

Converting the llvm pass to the new style of metadata passing and
updating libclc builtins.
There are things higher on my priority list wrt clover/libclc (fixing
rounding routines, replacing the build system, adding support for
buffer sharing between devices). it will take some time unless someone
else volunteers.

Jan

> 
> Jan Vesely  writes:
> 
> > On Wed, 2018-10-31 at 17:02 +, Emil Velikov wrote:
> > > On Wed, 31 Oct 2018 at 15:57, Jan Vesely  wrote:
> > > > On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> > > > > From: Emil Velikov 
> > > > > 
> > > > > LLVM versions earlier than 5.0.1 are no longer supported.
> > > > 
> > > > I'd prefer to keep llvm-3.9, since it's the last version that supports
> > > > images for r600, but I'd leave the final decision to Francisco.
> > > > 
> > > Was it just image support that was dropped or all of r600?
> > > I take it there's not enough interest/manpower to address that?
> > > 
> > > I'm curious how are you building/managing things:
> > >  - full build with LLVM 3.9
> > >  - r600 build with LLVM 3.9, and another for $other component using newer 
> > > LLVM
> > >  - other
> > 
> > I build only clover+r600, mostly to occasionally check that libclc
> > still works as expected. I don't expect mixing of LLVM versions to work
> > (although with versioned symbols it should).
> > I can always fall back to older mesa release for this, but building
> > from one source is nice, feel free to go ahead with Francisco's ack.
> > 
> > Jan
> > 
> > > If really needed, we could keep 3.9 solely for r600 and use 5.0.1+ 
> > > elsewhere.
> > > Considering LLVM 3.9 isn't getting new updates with last one being in
> > > Sep 2016 we are seriously clinging to straws.
> > > 
> > > Thanks
> > > Emil
> > 
> > -- 
> > Jan Vesely 



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] clover: remove pre LLVM 5.0 codepaths

[Jan Vesely]

On Wed, 2018-10-31 at 17:02 +, Emil Velikov wrote:
> On Wed, 31 Oct 2018 at 15:57, Jan Vesely  wrote:
> > On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> > > From: Emil Velikov 
> > > 
> > > LLVM versions earlier than 5.0.1 are no longer supported.
> > 
> > I'd prefer to keep llvm-3.9, since it's the last version that supports
> > images for r600, but I'd leave the final decision to Francisco.
> > 
> Was it just image support that was dropped or all of r600?
> I take it there's not enough interest/manpower to address that?
> 
> I'm curious how are you building/managing things:
>  - full build with LLVM 3.9
>  - r600 build with LLVM 3.9, and another for $other component using newer LLVM
>  - other

I build only clover+r600, mostly to occasionally check that libclc
still works as expected. I don't expect mixing of LLVM versions to work
(although with versioned symbols it should).
I can always fall back to older mesa release for this, but building
from one source is nice, feel free to go ahead with Francisco's ack.

Jan

> 
> If really needed, we could keep 3.9 solely for r600 and use 5.0.1+ elsewhere.
> Considering LLVM 3.9 isn't getting new updates with last one being in
> Sep 2016 we are seriously clinging to straws.
> 
> Thanks
> Emil

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
> On Wed, 31 Oct 2018 at 16:24, Michel Dänzer  wrote:
> > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> > > > From: Emil Velikov 
> > > > 
> > > > The option has been long superseded with LLVM_CONFIG.
> > > > Distributions have been using it for a couple of years now.
> > > 
> > > I've been using it in my configure setup.
> > 
> > Same here.
> > 
> Have you tried LLVM_CONFIG, does it not work on your setup?
> Alternatively can you update the your scripts, I can provide a patch
> if you prefer.

I'm testing mesa/clover for llvm-{5,6,7,git} on three machines, before
I start migrating all that setup I wanted to know if a capability is
lost and I should start rewriting the scripts or a simple reconfigure
in build directories is enough.

> Even Debian (which I personally consider fairly conservative) has been
> using it for a minimum of two years.
> https://salsa.debian.org/xorg-team/lib/mesa/commit/436b3472adde14b22e9ce204820dab417cfe00c6

I'm sorry. This is completely irrelevant. I don't care what distros
use, I build from source.

> > > This might be a stupid question; is the LLVM_CONFIG env var remembered
> > > between reconfigure (touch configure.ac; make) or do I need to provide
> > > it explicitly every time configure is run?
> > 
> > I don't know the answer, but agree that would be a minimum requirement
> > for this change.
> > 
> Nope, yet it's not really a minimum. LLVM_CONFIG has been around for
> years, it will work for any Mesa checkout since its inception.
> You can safely bisect Mesa and things will just work.

The question is; Do I have to do "LLVM_CONFIG=..." make every time
bisect changes configure.ac?

thanks,
Jan

> 
> Thanks
> Emil



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The option has been long superseded with LLVM_CONFIG.
> Distributions have been using it for a couple of years now.

I've been using it in my configure setup. This might be a stupid
question; is the LLVM_CONFIG env var remembered between reconfigure
(touch configure.ac; make) or do I need to provide it explicitly every
time configure is run?

Jan

> 
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f41f60d95a7..a5863022295 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1019,9 +1019,9 @@ AC_ARG_ENABLE([llvm-shared-libs],
>  
>  AC_ARG_WITH([llvm-prefix],
>  [AS_HELP_STRING([--with-llvm-prefix],
> -[Prefix for LLVM installations in non-standard locations])],
> -[llvm_prefix="$withval"],
> -[llvm_prefix=''])
> + [DEPRECATED: Use export LLVM_CONFIG=... if needed.])],
> +   [AC_MSG_ERROR([--with-llvm-prefix is deprecated. Use export 
> LLVM_CONFIG=... if needed.])],
> +   [])
>  
>  PKG_CHECK_MODULES([LIBELF], [libelf], [have_libelf=yes], [have_libelf=no])
>  if test "x$have_libelf" = xno; then
> @@ -1033,11 +1033,7 @@ if test "x$have_libelf" = xno; then
>  fi
>  
>  if test -z "$LLVM_CONFIG"; then
> -if test -n "$llvm_prefix"; then
> -AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], 
> ["$llvm_prefix/bin"])
> -else
> -AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no])
> -fi
> +AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no])
>  fi
>  
>  llvm_add_component() {



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] clover: remove pre LLVM 5.0 codepaths

[Jan Vesely]

On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> LLVM versions earlier than 5.0.1 are no longer supported.

I'd prefer to keep llvm-3.9, since it's the last version that supports
images for r600, but I'd leave the final decision to Francisco.

Jan

> 
> Cc: Jan Vesely 
> Cc: Francisco Jerez 
> Cc: Aaron Watry 
> Signed-off-by: Emil Velikov 
> ---
> I guess some of compat.hpp can be cleaned-up, but I'd suggest sticking
> with that as a follow-up.
> ---
>  .../clover/llvm/codegen/bitcode.cpp   |  4 ---
>  .../state_trackers/clover/llvm/compat.hpp | 26 
>  .../state_trackers/clover/llvm/metadata.hpp   | 30 ---
>  3 files changed, 60 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 40bb426218d..b67afb34542 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -38,12 +38,8 @@
>  #include "util/algorithm.hpp"
>  
>  #include 
> -#if HAVE_LLVM < 0x0400
> -#include 
> -#else
>  #include 
>  #include 
> -#endif
>  #include 
>  
>  using namespace clover;
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 975012cbda4..5f526ec155d 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -36,23 +36,15 @@
>  
>  #include "util/algorithm.hpp"
>  
> -#if HAVE_LLVM < 0x0400
> -#include 
> -#else
>  #include 
>  #include 
> -#endif
>  
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#if HAVE_LLVM >= 0x0400
>  #include 
> -#else
> -#include 
> -#endif
>  
>  #include 
>  #include 
> @@ -67,34 +59,21 @@ namespace clover {
>   template
>   unsigned target_address_space(const T , const AS lang_as) {
>  const auto  = target.getAddressSpaceMap();
> -#if HAVE_LLVM >= 0x0500
>  return map[static_cast(lang_as)];
> -#else
> -return map[lang_as - clang::LangAS::Offset];
> -#endif
>   }
>  
> -#if HAVE_LLVM >= 0x0500
>   const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
>   const clang::LangStandard::Kind lang_opencl10 = 
> clang::LangStandard::lang_opencl10;
> -#else
> - const clang::InputKind ik_opencl = clang::IK_OpenCL;
> - const clang::LangStandard::Kind lang_opencl10 = 
> clang::LangStandard::lang_opencl;
> -#endif
>  
>   inline void
>   add_link_bitcode_file(clang::CodeGenOptions ,
> const std::string ) {
> -#if HAVE_LLVM >= 0x0500
>  clang::CodeGenOptions::BitcodeFileToLink F;
>  
>  F.Filename = path;
>  F.PropagateAttrs = true;
>  F.LinkFlags = ::llvm::Linker::Flags::None;
>  opts.LinkBitcodeFiles.emplace_back(F);
> -#else
> -opts.LinkBitcodeFiles.emplace_back(::llvm::Linker::Flags::None, 
> path);
> -#endif
>   }
>  
>  #if HAVE_LLVM >= 0x0600
> @@ -105,15 +84,10 @@ namespace clover {
>  
>   template void
>   handle_module_error(M , const F ) {
> -#if HAVE_LLVM >= 0x0400
>  if (::llvm::Error err = mod.takeError())
> ::llvm::handleAllErrors(std::move(err), 
> [&](::llvm::ErrorInfoBase ) {
>   f(eib.message());
>});
> -#else
> -if (!mod)
> -   f(mod.getError().message());
> -#endif
>   }
>  
>  template void
> diff --git a/src/gallium/state_trackers/clover/llvm/metadata.hpp 
> b/src/gallium/state_trackers/clover/llvm/metadata.hpp
> index 825008d4974..f020e85e915 100644
> --- a/src/gallium/state_trackers/clover/llvm/metadata.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/metadata.hpp
> @@ -57,44 +57,14 @@ namespace clover {
>  
>   inline bool
>   is_kernel(const ::llvm::Function ) {
> -#if HAVE_LLVM >= 0x0309
>  return f.getMetadata("kernel_arg_type");
> -#else
> -return clover::any_of(is_kernel_node_for(f),
> -  get_kernel_nodes(*f.getParent()));
> -#endif
>   }
>  
>   inline iterator_range< ::llvm::MDNode::op_iterator>
>   get_kernel_metadata_operands(const ::llvm::Function ,
>const std::string ) {
> -#if 

Re: [Mesa-dev] [PATCH 2/3] anv: Stop generating weak references for instance entrypoints

[Jan Vesely]

Hi,

I think this patch breaks the build:
https://travis-ci.org/jvesely/mesa/jobs/443356781

Jan

On Tue, 2018-10-16 at 08:18 -0500, Jason Ekstrand wrote:
> FYI, patch 1 is required for this patch to build.  It also means this patch 
> found a nice little bug.  I'll respond to patch 1 in more detail after the 
> SI call tomorrow.
> 
> --Jason
> 
> 
> On October 16, 2018 06:49:35 Lionel Landwerlin 
>  wrote:
> 
> > Reviewed-by: Lionel Landwerlin 
> > 
> > On 15/10/2018 04:47, Jason Ekstrand wrote:
> > > We don't need weak references to instance entrypoints because we never
> > > have more than one of each so we don't need the NULL fall-back.  This
> > > also helps us avoid forgetting things because we now get link errors for
> > > missing instance entrypoints.
> > > ---
> > >   src/intel/vulkan/anv_entrypoints_gen.py | 13 -
> > >   1 file changed, 13 deletions(-)
> > > 
> > > diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
> > > b/src/intel/vulkan/anv_entrypoints_gen.py
> > > index beb658b8660..25a532fd706 100644
> > > --- a/src/intel/vulkan/anv_entrypoints_gen.py
> > > +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> > > @@ -227,19 +227,6 @@ ${strmap(device_strmap, 'device')}
> > >* either pick the correct entry point.
> > >*/
> > > 
> > > -% for e in instance_entrypoints:
> > > -  % if e.alias:
> > > -<% continue %>
> > > -  % endif
> > > -  % if e.guard is not None:
> > > -#ifdef ${e.guard}
> > > -  % endif
> > > -  ${e.return_type} ${e.prefixed_name('anv')}(${e.decl_params()}) 
> > > __attribute__ ((weak));
> > > -  % if e.guard is not None:
> > > -#endif // ${e.guard}
> > > -  % endif
> > > -% endfor
> > > -
> > >   const struct anv_instance_dispatch_table anv_instance_dispatch_table = {
> > >   % for e in instance_entrypoints:
> > > % if e.guard is not None:
> > 
> > 
> > ___
> > 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



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/1] radeonsi: Bump number of allowed global buffers to 32

[Jan Vesely]

Fixes assertion failure/crash when running luxmark/luxball on clover.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108272
CC: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely 
---
This is just a stop gap measure. OpenCL does not limit the number of
global buffers, but we can return CL_MEM_OBJECT_ALLOCATION_FAILURE in
clEnqueueNDRangeKernel. 
What would be the preferred way? Add PIPE_CAP to query this? allow
set_global_binding to fail with too many buffers?

thanks,
Jan

 src/gallium/drivers/radeonsi/si_compute.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.h 
b/src/gallium/drivers/radeonsi/si_compute.h
index 99b501673c..57c0bde4ac 100644
--- a/src/gallium/drivers/radeonsi/si_compute.h
+++ b/src/gallium/drivers/radeonsi/si_compute.h
@@ -29,7 +29,7 @@
 
 #include "si_shader.h"
 
-#define MAX_GLOBAL_BUFFERS 22
+#define MAX_GLOBAL_BUFFERS 32
 
 struct si_compute {
struct pipe_reference reference;
-- 
2.17.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] radeonsi: use compute shaders for clear_buffer & copy_buffer

[Jan Vesely]

On Thu, 2018-10-18 at 09:32 +0200, Michel Dänzer wrote:
> On 2018-10-17 6:43 p.m., Marek Olšák wrote:
> > Can you test the attached patch?
> 
> Doesn't help, unfortunately. Backtraces with the patch attached.
> 
> FWIW, this is on Bonaire.

Hi,

fwiw, I don't see this hang on my carrizo/iceland machine.

Jan

> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] .travis: Drop note about Clover builds being slow

[Jan Vesely]

On Tue, 2018-09-25 at 18:11 +0100, Emil Velikov wrote:
> On 12 September 2018 at 23:20, Jan Vesely  wrote:
> > SWR takes 17+ minutes to build. Clover builds take ~6-7 minutes.
> > 
> 
> Clover takes the same time as all the other state-trackers combined.
> Ideally we'll tweak change to something more accurate as ^^, but either way
> 
> For the series,
> Reviewed-by: Emil Velikov 

thank you. pushed.

Jan

> 
> -Emil



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] .travis: Drop note about Clover builds being slow

[Jan Vesely]

On Wed, 2018-09-19 at 11:43 -0400, Jan Vesely wrote:
> On Wed, 2018-09-12 at 18:20 -0400, Jan Vesely wrote:
> > SWR takes 17+ minutes to build. Clover builds take ~6-7 minutes.
> > 
> > Signed-off-by: Jan Vesely 
> > ---
> >  .travis.yml | 4 
> >  1 file changed, 4 deletions(-)
> > 
> > diff --git a/.travis.yml b/.travis.yml
> > index 4035a729ff..78e6d251ae 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -186,7 +186,6 @@ matrix:
> >  - libelf-dev
> >  - libunwind8-dev
> >  - env:
> > -# NOTE: Analogous to SWR above, building Clover is quite slow.
> >  - LABEL="make Gallium ST Clover LLVM-3.9"
> >  - BUILD=make
> >  - MAKEFLAGS="-j4"
> > @@ -225,7 +224,6 @@ matrix:
> >  - libelf-dev
> >  - libunwind8-dev
> >  - env:
> > -# NOTE: Analogous to SWR above, building Clover is quite slow.
> >  - LABEL="make Gallium ST Clover LLVM-4.0"
> >  - BUILD=make
> >  - MAKEFLAGS="-j4"
> > @@ -261,7 +259,6 @@ matrix:
> >  - libelf-dev
> >  - libunwind8-dev
> >  - env:
> > -# NOTE: Analogous to SWR above, building Clover is quite slow.
> >  - LABEL="make Gallium ST Clover LLVM-5.0"
> >  - BUILD=make
> >  - MAKEFLAGS="-j4"
> > @@ -297,7 +294,6 @@ matrix:
> >  - libelf-dev
> >  - libunwind8-dev
> >  - env:
> > -# NOTE: Analogous to SWR above, building Clover is quite slow.
> >  - LABEL="make Gallium ST Clover LLVM-6.0"
> >  - BUILD=make
> >  - MAKEFLAGS="-j4"
> 
> 
> ping for the series.
> LLVM-7 was released today.

ping.

Jan

> 
> Jan



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 2/6] nouveau: silence paranoid compiler's -Wclass-memaccess

[Jan Vesely]

The warning is correct. In the first case, memset tries to zero "Target"
object which has a non-trivial constructor and non-trivial
copy-constructor. The original code is broken in the way it mixes C and C++
initialization and the patch only papers over the issue.
The correct fix would be to provide a proper constructor for structs that
include instances of C++ classes.

Jan

On Sat, Sep 22, 2018 at 6:43 AM Karol Herbst  wrote:

> yeah, I agree here. Either the code was wrong in the first place,
> which means it would have to be fixed properly or the warning is
> wrong. The proper fix here is that GCC should detect itself if it's
> safe to do or not, otherwise that warning becomes a "might be a
> problem" thing which doesn't help at all. Either it is wrong, or it
> isn't. And gcc should be able to know in this case.
>
> On Sat, Sep 22, 2018 at 6:07 AM, Ilia Mirkin  wrote:
> > Based on the various fixes, warning seems bogus -- is the proper
> > solution -Wno-class-memaccess? (Or however one disables such
> > things...)
> >
> > On Fri, Sep 21, 2018 at 9:50 AM, Eric Engestrom
> >  wrote:
> >> Signed-off-by: Eric Engestrom 
> >> ---
> >>  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
> >>  src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> >> index 49425b98b9137058c986..62ebc2d24069b7b5f523 100644
> >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> >> @@ -905,7 +905,7 @@ Instruction::isCommutationLegal(const Instruction
> *i) const
> >>  TexInstruction::TexInstruction(Function *fn, operation op)
> >> : Instruction(fn, op, TYPE_F32)
> >>  {
> >> -   memset(, 0, sizeof(tex));
> >> +   memset(static_cast(), 0, sizeof(tex));
> >>
> >> tex.rIndirectSrc = -1;
> >> tex.sIndirectSrc = -1;
> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> >> index 9193a01f189874a7fb38..b6b9b42964bec670079c 100644
> >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> >> @@ -454,7 +454,7 @@ CodeEmitter::addInterp(int ipa, int reg, FixupApply
> apply)
> >>if (!fixupInfo)
> >>   return false;
> >>if (n == 0)
> >> - memset(fixupInfo, 0, sizeof(FixupInfo));
> >> + memset(static_cast(fixupInfo), 0, sizeof(FixupInfo));
> >> }
> >> ++fixupInfo->count;
> >>
> >> --
> >> Cheers,
> >>   Eric
> >>
> >> ___
> >> 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
> ___
> 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 2/2] .travis: Drop note about Clover builds being slow

[Jan Vesely]

On Wed, 2018-09-12 at 18:20 -0400, Jan Vesely wrote:
> SWR takes 17+ minutes to build. Clover builds take ~6-7 minutes.
> 
> Signed-off-by: Jan Vesely 
> ---
>  .travis.yml | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 4035a729ff..78e6d251ae 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -186,7 +186,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-3.9"
>  - BUILD=make
>  - MAKEFLAGS="-j4"
> @@ -225,7 +224,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-4.0"
>  - BUILD=make
>  - MAKEFLAGS="-j4"
> @@ -261,7 +259,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-5.0"
>  - BUILD=make
>  - MAKEFLAGS="-j4"
> @@ -297,7 +294,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-6.0"
>  - BUILD=make
>  - MAKEFLAGS="-j4"


ping for the series.
LLVM-7 was released today.

Jan


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Jan Vesely]

Hi,

On Mon, 2018-09-17 at 09:44 -0700, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is 
> there
> anything left that autotools can do that meson cannot (that we actually want 
> to
> implement)? And, what is a reasonable time-table to remove the autotools 
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt confident
> that it would work for them.

in my experience dealing with meson is a massive PITA. maybe I'm just
not familiar with the meson way of doing things. Here are the issues
I'm running into:

1.) Have the setup of building multiple instances of mesa against
different llvm versions been addressed? I'm building mesa with llvm
6/7/git using the same source, will the llvm-config location be
remembered during reconfigure? ([0] has been open without any activity
for 9 months)

2.) Is there a way to upgrade meson without having to manually
regenerate build directories of every meson project? This clashes with
automated git update/rebuild scripts and forces me to have a separate
recreate/reconfigure shell script for every meson project.

3.) Has cross-compile pkg-config issue been fixed? Last time I checked
cross file needed both "pkgconfig" and "pkg-config" variables set,
otherwise it'd either complain or not find the corresponding pkgconfig
files.

regards,
Jan

[0]https://github.com/mesonbuild/meson/issues/2887

> 
> Dylan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] .travis: Add LLVM-7 Clover build

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 .travis.yml | 33 +
 1 file changed, 33 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 895030cc1b..4035a729ff 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -329,6 +329,39 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- env:
+- LABEL="make Gallium ST Clover LLVM-7"
+- BUILD=make
+- MAKEFLAGS="-j4"
+- MAKE_CHECK_COMMAND="true"
+- LLVM_VERSION=7
+- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
+- 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:
+- sourceline: 'deb http://apt.llvm.org/trusty/ 
llvm-toolchain-trusty-7 main'
+  key_url: https://apt.llvm.org/llvm-snapshot.gpg.key
+# llvm-7 requires libstdc++4.9 which is not in main repo
+- ubuntu-toolchain-r-test
+  packages:
+- libclc-dev
+# From sources above
+- llvm-7-dev
+- clang-7
+- libclang-7-dev
+# Common
+- xz-utils
+- x11proto-xf86vidmode-dev
+- libexpat1-dev
+- libx11-xcb-dev
+- libelf-dev
+- libunwind8-dev
 - env:
 - LABEL="make Gallium ST Other"
 - BUILD=make
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] .travis: Drop note about Clover builds being slow

[Jan Vesely]

SWR takes 17+ minutes to build. Clover builds take ~6-7 minutes.

Signed-off-by: Jan Vesely 
---
 .travis.yml | 4 
 1 file changed, 4 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 4035a729ff..78e6d251ae 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -186,7 +186,6 @@ matrix:
 - libelf-dev
 - libunwind8-dev
 - env:
-# NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-3.9"
 - BUILD=make
 - MAKEFLAGS="-j4"
@@ -225,7 +224,6 @@ matrix:
 - libelf-dev
 - libunwind8-dev
 - env:
-# NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-4.0"
 - BUILD=make
 - MAKEFLAGS="-j4"
@@ -261,7 +259,6 @@ matrix:
 - libelf-dev
 - libunwind8-dev
 - env:
-# NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-5.0"
 - BUILD=make
 - MAKEFLAGS="-j4"
@@ -297,7 +294,6 @@ matrix:
 - libelf-dev
 - libunwind8-dev
 - env:
-# NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-6.0"
 - BUILD=make
 - MAKEFLAGS="-j4"
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] OpenCL Support on older AMD GPUs

[Jan Vesely]

On Thu, 2018-08-23 at 18:11 +0300, Benson Muite wrote:
> Hi,
> 
> Is there likely to be support for OpenCL on older AMD GPUs? I have tried 
> running an OpenCL benchmark 
> (https://github.com/mpicbg-scicomp/gearshifft) on an AMD A6-6420K APU 
> running Fedora 28. The code seems to partially run, but gives incorrect 
> results.
The righland APU uses VLIW4 architecture and afaik, no one with such
card has worked on clover, so bugs are expected.

was there any error during compilation or did all kernels compile OK?


> Would it be challenging to add full OpenCL 1.1 support? The GPU 
> of particular interest to me is Radeon HD 8470, caicos, which appears to 
> have WIP:
> 
> https://www.x.org/wiki/RadeonFeature
> 
> How can one help move this forward?

One immediate thing to try is to run with more up to date libclc[0].
It has seen quite a lot of activity earlier this year, and last time I
checked Fedora has not picked that up.

If that does not help, then the LLVM generates wrong code.
identifying the wrong parts and sendinng an LLVM patch (or even
reporting bug) would help there.

Contributions to LLVM would need some level of understanding the ISA
(see documents that Alex pointed to [1,2])

Jan

[0] https://git.llvm.org/git/libclc
[1] http://developer.amd.com/wordpress/media/2012/10/AMD_Evergreen-Fam
ily_Instruction_Set_Architecture.pdf
[2] http://developer.amd.com/wordpress/media/2012/10/AMD_HD_6900_Serie
s_Instruction_Set_Architecture.pdf

> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] travis: add ubuntu-toolchain-r-test

[Jan Vesely]

On Tue, Aug 7, 2018 at 12:28 PM, Juan A. Suarez Romero 
wrote:

> On Tue, 2018-08-07 at 16:12 +0100, Emil Velikov wrote:
> > On 6 August 2018 at 11:17, Juan A. Suarez Romero 
> wrote:
> > > LLVM 6.0 requires GCC 4.9, which is not available in main Travis
> > > repository.
> > >
> >
> > We're not building LLVM 6.0 here, hence the commit message is a bit
> confusing.
> > Please add more information on the topic - even a bug report if there is
> one.
> >
>
> We are using now LLVM 6.0, for "make Vulkan" and "make Gallium Drivers
> RadeonSI".
>
> Previously we were using LLVM 6.0 for "make Gallium ST Clover LLVM-6.0",
> which
> already had this ubuntu-toolchain-r-test.
>
> Without this, we get an error like in
> https://travis-ci.org/mesa3d/mesa/jobs/413159413


I think Emil's point was that we actually need libstc++4.9, because
llvm-lib link to it, rather than the gcc compiler itself.

Jan


>
>
>
>
> J.A.
>
> > With that
> > Reviewed-by: Emil Velikov 
> >
> > -Emil
> >
>
> ___
> 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] clover: Don't extend illegal integer types.

[Jan Vesely]

On Thu, 2018-07-26 at 10:51 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > It's OK to pass them in memory, which is what kernel invocation needs.
> > Fixes AMDGCN regressions since llvm r337535 ("Reapply "AMDGPU: Fix handling 
> > of alignment padding in DAG argument lowering"):
> > scalar-arithmetic-char
> > scalar-arithmetic-uchar
> > scalar-arithemtic-short
> > scalar-arithmetic-ushort
> > scalar-comparison-char
> > scalar-comparison-uchar
> > scalar-comparison-short
> > scalar-comparison-ushort
> > 
> > Signed-off-by: Jan Vesely 
> 
> Reviewed-by: Francisco Jerez 

thank you. I added cc: stable and pushed both patches.

Jan

> 
> > ---
> >  src/gallium/state_trackers/clover/llvm/codegen/common.cpp |  3 +--
> >  src/gallium/state_trackers/clover/llvm/compat.hpp | 12 
> >  2 files changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp 
> > b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> > index ddf2083f37..ca5f78940d 100644
> > --- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> > +++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> > @@ -85,8 +85,7 @@ namespace {
> >   const unsigned arg_store_size = dl.getTypeStoreSize(arg_type);
> >   const unsigned arg_api_size = dl.getTypeAllocSize(arg_type);
> >  
> > - const auto target_type = !arg_type->isIntegerTy() ? arg_type :
> > -dl.getSmallestLegalIntType(mod.getContext(), arg_store_size * 
> > 8);
> > + const auto target_type = compat::get_abi_type(arg_type, mod);
> >   const unsigned target_size = dl.getTypeStoreSize(target_type);
> >   const unsigned target_align = dl.getABITypeAlignment(target_type);
> >  
> > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > index 60270d1529..975012cbda 100644
> > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > @@ -153,6 +153,18 @@ namespace clover {
> > return tm.addPassesToEmitFile(pm, os, nullptr, ft);
> >  #else
> > return tm.addPassesToEmitFile(pm, os, ft);
> > +#endif
> > +   }
> > +
> > +   template
> > +   T get_abi_type(const T _type, const M ) {
> > +#if HAVE_LLVM >= 0x0700
> > +  return arg_type;
> > +#else
> > +  ::llvm::DataLayout dl();
> > +  const unsigned arg_store_size = dl.getTypeStoreSize(arg_type);
> > +  return !arg_type->isIntegerTy() ? arg_type :
> > +dl.getSmallestLegalIntType(mod.getContext(), arg_store_size * 
> > 8);
> >  #endif
> > }
> >}
> > -- 
> > 2.16.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] clover: Reduce wait_count in abort path.

[Jan Vesely]

Trigger waiter condition variable.
Passes 'events' CTS on carrizo and turks.
v2: reduce to 0

Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/core/event.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
b/src/gallium/state_trackers/clover/core/event.cpp
index b7eb33dbfc..3d313ce896 100644
--- a/src/gallium/state_trackers/clover/core/event.cpp
+++ b/src/gallium/state_trackers/clover/core/event.cpp
@@ -41,7 +41,7 @@ event::trigger_self() {
std::lock_guard lock(mutex);
std::vector> evs;
 
-   if (!--_wait_count)
+   if (_wait_count && !--_wait_count)
   std::swap(_chain, evs);
 
cv.notify_all();
@@ -65,8 +65,10 @@ event::abort_self(cl_int status) {
std::vector> evs;
 
_status = status;
+   _wait_count = 0;
std::swap(_chain, evs);
 
+   cv.notify_all();
return evs;
 }
 
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover: Reduce wait_count in abort path.

[Jan Vesely]

Trigger waiter condition variable.
Passes 'events' CTS on turks and carrizo.
Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/core/event.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
b/src/gallium/state_trackers/clover/core/event.cpp
index b7eb33dbfc..0de4e2b984 100644
--- a/src/gallium/state_trackers/clover/core/event.cpp
+++ b/src/gallium/state_trackers/clover/core/event.cpp
@@ -65,8 +65,10 @@ event::abort_self(cl_int status) {
std::vector> evs;
 
_status = status;
-   std::swap(_chain, evs);
+   if (!--_wait_count)
+  std::swap(_chain, evs);
 
+   cv.notify_all();
return evs;
 }
 
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover: Don't extend illegal integer types.

[Jan Vesely]

It's OK to pass them in memory, which is what kernel invocation needs.
Fixes AMDGCN regressions since llvm r337535 ("Reapply "AMDGPU: Fix handling of 
alignment padding in DAG argument lowering"):
scalar-arithmetic-char
scalar-arithmetic-uchar
scalar-arithemtic-short
scalar-arithmetic-ushort
scalar-comparison-char
scalar-comparison-uchar
scalar-comparison-short
scalar-comparison-ushort

Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/llvm/codegen/common.cpp |  3 +--
 src/gallium/state_trackers/clover/llvm/compat.hpp | 12 
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index ddf2083f37..ca5f78940d 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
@@ -85,8 +85,7 @@ namespace {
  const unsigned arg_store_size = dl.getTypeStoreSize(arg_type);
  const unsigned arg_api_size = dl.getTypeAllocSize(arg_type);
 
- const auto target_type = !arg_type->isIntegerTy() ? arg_type :
-dl.getSmallestLegalIntType(mod.getContext(), arg_store_size * 8);
+ const auto target_type = compat::get_abi_type(arg_type, mod);
  const unsigned target_size = dl.getTypeStoreSize(target_type);
  const unsigned target_align = dl.getABITypeAlignment(target_type);
 
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 60270d1529..975012cbda 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -153,6 +153,18 @@ namespace clover {
return tm.addPassesToEmitFile(pm, os, nullptr, ft);
 #else
return tm.addPassesToEmitFile(pm, os, ft);
+#endif
+   }
+
+   template
+   T get_abi_type(const T _type, const M ) {
+#if HAVE_LLVM >= 0x0700
+  return arg_type;
+#else
+  ::llvm::DataLayout dl();
+  const unsigned arg_store_size = dl.getTypeStoreSize(arg_type);
+  return !arg_type->isIntegerTy() ? arg_type :
+dl.getSmallestLegalIntType(mod.getContext(), arg_store_size * 8);
 #endif
}
   }
-- 
2.16.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] clover: Catch errors from executing event action

[Jan Vesely]

On Tue, 2018-07-17 at 15:22 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > On Tue, 2018-07-17 at 14:17 -0700, Francisco Jerez wrote:
> > > Jan Vesely  writes:
> > > 
> > > > Abort all dependent events.
> > > > Signed-off-by: Jan Vesely 
> > > > ---
> > > >  src/gallium/state_trackers/clover/core/event.cpp | 7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
> > > > b/src/gallium/state_trackers/clover/core/event.cpp
> > > > index cd5d786604..ed2b6ebdb8 100644
> > > > --- a/src/gallium/state_trackers/clover/core/event.cpp
> > > > +++ b/src/gallium/state_trackers/clover/core/event.cpp
> > > > @@ -51,7 +51,12 @@ event::trigger_self() {
> > > >  void
> > > >  event::trigger() {
> > > > if (wait_count() == 1)
> > > > -  action_ok(*this);
> > > > +  try {
> > > > + action_ok(*this);
> > > > +  } catch (error ) {
> > > > + for (event  : abort_self(e.get()))
> > > > +ev.abort(e.get());
> > > > +  }
> > > >  
> > > 
> > > Any reason not to do it like:
> > > 
> > > >   try {
> > > >  if (wait_count() == 1)
> > > > action_ok(*this);
> > > >   } catch (error ) {
> > > >  abort(e.get());
> > > >   }
> > > 
> > > That seems slightly simpler and it should make sure that the abort
> > > action of the failing event is executed as well.
> > 
> > sure. It wasn't clear to me if it's ok to execute both action_ok and
> > action_fail for the same event. My understanding was that exactly one
> > of them is called.
> > 
> > I can even do:
> >  void
> > -event::trigger() {
> > +event::trigger() try {
> > if (wait_count() == 1)
> >   action_ok(*this);
> >  
> > for (event  : trigger_self())
> >        ev.trigger();
> > +} catch (error ) {
> > +   abort(e.get())
> >  }
> 
> Yeah, that should work too.

thanks. I pushed both and added cc stable tag.

Jan

> 
> > 
> > 
> > Jan
> > 
> > > 
> > > Thanks.
> > > 
> > > > for (event  : trigger_self())
> > > >ev.trigger();
> > > > -- 
> > > > 2.16.4
> > 
> > -- 
> > Jan Vesely 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] clover: Catch errors from executing event action

[Jan Vesely]

On Tue, 2018-07-17 at 14:17 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > Abort all dependent events.
> > Signed-off-by: Jan Vesely 
> > ---
> >  src/gallium/state_trackers/clover/core/event.cpp | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
> > b/src/gallium/state_trackers/clover/core/event.cpp
> > index cd5d786604..ed2b6ebdb8 100644
> > --- a/src/gallium/state_trackers/clover/core/event.cpp
> > +++ b/src/gallium/state_trackers/clover/core/event.cpp
> > @@ -51,7 +51,12 @@ event::trigger_self() {
> >  void
> >  event::trigger() {
> > if (wait_count() == 1)
> > -  action_ok(*this);
> > +  try {
> > + action_ok(*this);
> > +  } catch (error ) {
> > + for (event  : abort_self(e.get()))
> > +ev.abort(e.get());
> > +  }
> >  
> 
> Any reason not to do it like:
> 
> >   try {
> >  if (wait_count() == 1)
> > action_ok(*this);
> >   } catch (error ) {
> >  abort(e.get());
> >   }
> 
> That seems slightly simpler and it should make sure that the abort
> action of the failing event is executed as well.

sure. It wasn't clear to me if it's ok to execute both action_ok and
action_fail for the same event. My understanding was that exactly one
of them is called.

I can even do:
 void
-event::trigger() {
+event::trigger() try {
if (wait_count() == 1)
  action_ok(*this);
 
for (event  : trigger_self())
   ev.trigger();
+} catch (error ) {
+   abort(e.get())
 }


Jan

> 
> Thanks.
> 
> > for (event  : trigger_self())
> >ev.trigger();
> > -- 
> > 2.16.4

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] clover: Catch errors from executing event action

[Jan Vesely]

On Tue, 2018-07-17 at 16:15 -0500, Aaron Watry wrote:
> Question: How'd you run across this? CTS, an application?

It's a part of the 3 patch series I posted:
1.) fail to create compute state if code has relocations
2.) throw exception if pipe driver failed to create compute state
3.) catch exception and fail kernel launch event

this fixes clover to be able to run full piglit run on GCN (since
llvm-6)

I haven't looked into what other things it might fix.

Jan

> 
> I saw this and had hoped that it finally fixed a CTS hang I've been
> experiencing when running:
>   test_conformance/events/test_events test_userevents
> 
> But at least when SSH'd into my R600-based box, it still seems to
> pause waiting for an event to trigger:
> 
> test_userevents...
> Enqueuing tasks
> Checking task status before setting user event status
> Setting user event status to complete
> Waiting for tasks to finish executing
> Checking task status after setting user event status
> Successful user event case passed.
> Enqueuing tasks
> Checking task status before setting user event status
> Setting user event status to unsuccessful result
> Waiting for tasks to finish executing
> Checking task status after setting user event status
> Unsuccessful user event case passed.
> test_userevents passed
> HUNG HERE
> 
> --Aaron
> 
> On Tue, Jul 17, 2018 at 9:38 AM, Jan Vesely  wrote:
> > Abort all dependent events.
> > Signed-off-by: Jan Vesely 
> > ---
> >  src/gallium/state_trackers/clover/core/event.cpp | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
> > b/src/gallium/state_trackers/clover/core/event.cpp
> > index cd5d786604..ed2b6ebdb8 100644
> > --- a/src/gallium/state_trackers/clover/core/event.cpp
> > +++ b/src/gallium/state_trackers/clover/core/event.cpp
> > @@ -51,7 +51,12 @@ event::trigger_self() {
> >  void
> >  event::trigger() {
> > if (wait_count() == 1)
> > -  action_ok(*this);
> > +  try {
> > + action_ok(*this);
> > +  } catch (error ) {
> > + for (event  : abort_self(e.get()))
> > +ev.abort(e.get());
> > +  }
> > 
> > for (event  : trigger_self())
> >ev.trigger();
> > --
> > 2.16.4
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] clover: Report error when pipe driver fails to create compute state

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/core/kernel.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp 
b/src/gallium/state_trackers/clover/core/kernel.cpp
index 4716705323..dab7ef8683 100644
--- a/src/gallium/state_trackers/clover/core/kernel.cpp
+++ b/src/gallium/state_trackers/clover/core/kernel.cpp
@@ -231,6 +231,10 @@ kernel::exec_context::bind(intrusive_ptr _q,
   cs.req_local_mem = mem_local;
   cs.req_input_mem = input.size();
   st = q->pipe->create_compute_state(q->pipe, );
+  if (!st) {
+unbind(); // Cleanup
+throw error(CL_OUT_OF_RESOURCES);
+  }
}
 
return st;
-- 
2.16.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] clover: Catch errors from executing event action

[Jan Vesely]

Abort all dependent events.
Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/core/event.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
b/src/gallium/state_trackers/clover/core/event.cpp
index cd5d786604..ed2b6ebdb8 100644
--- a/src/gallium/state_trackers/clover/core/event.cpp
+++ b/src/gallium/state_trackers/clover/core/event.cpp
@@ -51,7 +51,12 @@ event::trigger_self() {
 void
 event::trigger() {
if (wait_count() == 1)
-  action_ok(*this);
+  try {
+ action_ok(*this);
+  } catch (error ) {
+ for (event  : abort_self(e.get()))
+ev.abort(e.get());
+  }
 
for (event  : trigger_self())
   ev.trigger();
-- 
2.16.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: Refuse to accept code with unhandled relocations

[Jan Vesely]

They might lead to unrecoverable GPU hang.
Signed-off-by: Jan Vesely 
---
 src/gallium/drivers/radeonsi/si_compute.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 5d3341ff61..2349be9584 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -238,6 +238,12 @@ static void *si_create_compute_state(
const amd_kernel_code_t *code_object =
si_compute_get_code_object(program, 0);
code_object_to_config(code_object, 
>shader.config);
+   if (program->shader.binary.reloc_count != 0) {
+   fprintf(stderr, "Error: %d unsupported 
relocations\n",
+   program->shader.binary.reloc_count);
+   FREE(program);
+   return NULL;
+   }
} else {
si_shader_binary_read_config(>shader.binary,
 >shader.config, 0);
-- 
2.16.4

___
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

[Jan Vesely]

  addr = si_get_indirect_index(ctx, ireg, 16, idx * 4);
> > } else {
> > addr = LLVMConstInt(ctx->i32, idx * 4, 0);
> > }
> >   
> > /* Fast path when user data SGPRs point to constant buffer 0 directly. 
> > */
> > if (sel->info.const_buffers_declared == 1 &&
> > sel->info.shader_buffers_declared == 0) {
> > -
> > -   /* This enables use of s_load_dword and flat_load_dword for 
> > const buffer 0
> > -* loads, and up to x4 load opcode merging. However, it leads 
> > to horrible
> > -* code reducing SIMD wave occupancy from 8 to 2 in many cases.
> > -*
> > -* Using s_buffer_load_dword (x1) seems to be the best option 
> > right now.
> > -*
> > -* LLVM 5.0 on SI doesn't insert a required s_nop between SALU 
> > setting
> > -* a descriptor and s_buffer_load_dword using it, so we can't 
> > expand
> > -* the pointer into a full descriptor like below. We have to use
> > -* s_load_dword instead. The only case when LLVM 5.0 would 
> > select
> > -* s_buffer_load_dword (that we have to prevent) is when we use 
> > use
> > -* a literal offset where we don't need bounds checking.
> > -*/
> > -   if (ctx->screen->info.chip_class == SI && HAVE_LLVM < 0x0600 &&
> > -   !reg->Register.Indirect) {
> > -   LLVMValueRef ptr =
> > -   LLVMGetParam(ctx->main_fn, 
> > ctx->param_const_and_shader_buffers);
> > -
> > -   addr = LLVMBuildLShr(ctx->ac.builder, addr, 
> > LLVMConstInt(ctx->i32, 2, 0), "");
> > -   LLVMValueRef result = ac_build_load_invariant(>ac, 
> > ptr, addr);
> > -   return bitcast(bld_base, type, result);
> > -   }
> > -
> > LLVMValueRef desc = load_const_buffer_desc_fast_path(ctx);
> > LLVMValueRef result = buffer_load_const(ctx, desc, addr);
> > return bitcast(bld_base, type, result);
> > }
> >   
> > assert(reg->Register.Dimension);
> > buf = reg->Dimension.Index;
> >   
> > if (reg->Dimension.Indirect) {
> > LLVMValueRef ptr = LLVMGetParam(ctx->main_fn, 
> > ctx->param_const_and_shader_buffers);
> > diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
> > b/src/gallium/drivers/radeonsi/si_shader_nir.c
> > index 6eb114a..914b901 100644
> > --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> > +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> > @@ -741,27 +741,20 @@ void si_nir_scan_shader(const struct nir_shader *nir,
> > }
> >   }
> >   
> >   /**
> >* Perform "lowering" operations on the NIR that are run once when the 
> > shader
> >* selector is created.
> >*/
> >   void
> >   si_lower_nir(struct si_shader_selector* sel)
> >   {
> > -   /* Disable const buffer fast path for old LLVM versions */
> > -   if (sel->screen->info.chip_class == SI && HAVE_LLVM < 0x0600 &&
> > -   sel->info.const_buffers_declared == 1 &&
> > -   sel->info.shader_buffers_declared == 0) {
> > -   sel->info.const_buffers_declared |= 0x2;
> > -   }
> > -
> > /* Adjust the driver location of inputs and outputs. The state tracker
> >  * interprets them as slots, while the ac/nir backend interprets them
> >  * as individual components.
> >  */
> > nir_foreach_variable(variable, >nir->inputs)
> > variable->data.driver_location *= 4;
> >   
> > nir_foreach_variable(variable, >nir->outputs) {
> > variable->data.driver_location *= 4;
> >   
> > diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c 
> > b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > index 43922dc..694f934 100644
> > --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > @@ -49,25 +49,23 @@ static void kill_if_fetch_args(struct 
> > lp_build_tgsi_context *bld_base,
> > emit_data->arg_count = 1;
> > emit_data->args[0] = conds[0];
> >   }
> >   
> >   void si_llvm_emit_kill(struct ac_shader_abi *abi, LLVMValueRef visible)
> >   {
> > struct si_shader_context *ctx = si_shader_context_from_abi(abi);
> > LLVMBuilderRef builder = ctx->ac.builder;
> >   
> > if (ctx->shader->selector->force_correct_derivs_after_kill) {
> > -   /* LLVM 6.0 can kill immediately while maintaining WQM. */
> > -   if (HAVE_LLVM >= 0x0600) {
> > -   ac_build_kill_if_false(>ac,
> > -  ac_build_wqm_vote(>ac, 
> > visible));
> > -   }
> > +   /* Kill immediately while maintaining WQM. */
> > +   ac_build_kill_if_false(>ac,
> > +  ac_build_wqm_vote(>ac, visible));
> >   
> > LLVMValueRef mask = LLVMBuildLoad(builder, ctx->postponed_kill, 
> > "");
> > mask = LLVMBuildAnd(builder, mask, visible, "");
> > LLVMBuildStore(builder, mask, ctx->postponed_kill);
> > return;
> > }
> >   
> > ac_build_kill_if_false(>ac, visible);
> >   }
> >   
> > 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/1] drisw: Fix invalid pointer arithmetic

[Jan Vesely]

Use of void * in pointer arithmetic is illegal, use char * instead.
Fixes: cf54bd5e8381dba18d52fe438acda20cc1685bf3 ("drisw: use shared memory when 
possible")

Signed-off-by: Jan Vesely 
---
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c 
b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
index 8335e52200..40007200a5 100644
--- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
@@ -233,7 +233,7 @@ dri_sw_displaytarget_display(struct sw_winsys *ws,
unsigned width, height, x = 0, y = 0;
unsigned blsize = util_format_get_blocksize(dri_sw_dt->format);
unsigned offset = 0;
-   void *data = dri_sw_dt->data;
+   char *data = dri_sw_dt->data;
 
/* Set the width to 'stride / cpp'.
 *
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] clover: Fix build after llvm r332881.

[Jan Vesely]

On Thu, 2018-05-24 at 13:08 -0500, Aaron Watry wrote:
> On Tue, May 22, 2018 at 6:43 PM, Jan Vesely <jan.ves...@rutgers.edu> wrote:
> > r332881 added an extra parameter to the emit function.
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106619
> > Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
> > ---
> >  .../state_trackers/clover/llvm/codegen/native.cpp  |  3 +--
> >  src/gallium/state_trackers/clover/llvm/compat.hpp  | 10 ++
> >  2 files changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp 
> > b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
> > index 409f8ac32f..4b589ef50c 100644
> > --- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
> > +++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
> > @@ -126,13 +126,12 @@ namespace {
> >{
> >   compat::pass_manager pm;
> >   ::llvm::raw_svector_ostream os { data };
> > - compat::raw_ostream_to_emit_file fos(os);
> > 
> >   mod.setDataLayout(compat::get_data_layout(*tm));
> >   tm->Options.MCOptions.AsmVerbose =
> >  (ft == TargetMachine::CGFT_AssemblyFile);
> > 
> > - if (tm->addPassesToEmitFile(pm, fos, ft))
> > +   if (compat::add_passes_to_emit_file(*tm, pm, os, ft))
> 
> Looks like you need to add another space here to stay consistent with
> the existing indentation.
> 
> >  fail(r_log, build_error(), "TargetMachine can't emit this 
> > file");
> > 
> >   pm.run(mod);
> > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > index 2e070b2eef..96ba798970 100644
> > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > @@ -245,6 +245,16 @@ namespace clover {
> > ::llvm::WriteBitcodeToFile(mod, os);
> >  #else
> > ::llvm::WriteBitcodeToFile(, os);
> > +#endif
> > +   }
> 
> Add an empty line before this function to separate it from the previous?
> 
> With those changes, this one is Tested/Reviewed-By: Aaron Watry
> <awa...@gmail.com>
> 
> Patch 2 and 3 are Reviewed-by: Aaron Watry <awa...@gmail.com>
> 
> I've only tested patch 2 on LLVM 7 with a couple CTS tests as a smoke
> test, and patch 3 is just visually reviewed/diffed with the existing
> LLVM 5 configuration.

thanks. I've made the whitespace changes locally. I also modified patch
3 to use gcc-4.9 for build since llvm-6 package brings it in anyway
(and depends on libgcc-4.9)

Jan
> 
> --Aaron
> 
> 
> > +   template
> > +   bool add_passes_to_emit_file(TM , PM , OS , FT )
> > +   {
> > +   compat::raw_ostream_to_emit_file fos(os);
> > +#if HAVE_LLVM >= 0x0700
> > +   return tm.addPassesToEmitFile(pm, fos, nullptr, ft);
> > +#else
> > +   return tm.addPassesToEmitFile(pm, fos, ft);
> >  #endif
> > }
> >}
> > --
> > 2.17.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] travis: Add clover llvm-6.0 build

[Jan Vesely]

Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
---
 .travis.yml | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index e3471d47ac..33dcbcc8da 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -290,6 +290,41 @@ matrix:
 - 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"
+- BUILD=make
+- MAKEFLAGS="-j4"
+- MAKE_CHECK_COMMAND="true"
+- 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-6.0
+# llvm-6 depends on gcc-4.9 which is not in main repo
+- ubuntu-toolchain-r-test
+  packages:
+- libclc-dev
+# From sources above
+- 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:
 - LABEL="make Gallium ST Other"
 - BUILD=make
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] clover: Cleanup compat code for llvm < 3.9

[Jan Vesely]

Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
---
I've confirmed that simple piglits run on turks(llvm-7) and
carrizo(llvm-6,7). Travis says it builds ok for all supported llvm
versions.

 .../clover/llvm/codegen/native.cpp|   7 +-
 .../state_trackers/clover/llvm/compat.hpp | 109 +-
 .../state_trackers/clover/llvm/invocation.cpp |  25 ++--
 3 files changed, 20 insertions(+), 121 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index 4b589ef50c..a6c9ba1f52 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -114,8 +114,7 @@ namespace {
 
   std::unique_ptr tm {
  t->createTargetMachine(target.triple, target.cpu, "", {},
-compat::default_reloc_model,
-compat::default_code_model,
+::llvm::None, compat::default_code_model,
 ::llvm::CodeGenOpt::Default) };
   if (!tm)
  fail(r_log, build_error(),
@@ -124,10 +123,10 @@ namespace {
   ::llvm::SmallVector<char, 1024> data;
 
   {
- compat::pass_manager pm;
+ ::llvm::legacy::PassManager pm;
  ::llvm::raw_svector_ostream os { data };
 
- mod.setDataLayout(compat::get_data_layout(*tm));
+ mod.setDataLayout(tm->createDataLayout());
  tm->Options.MCOptions.AsmVerbose =
 (ft == TargetMachine::CGFT_AssemblyFile);
 
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 96ba798970..8f2f128048 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -54,15 +54,8 @@
 #include 
 #endif
 
-#if HAVE_LLVM >= 0x0307
 #include 
 #include 
-#else
-#include 
-#include 
-#include 
-#include 
-#endif
 
 #include 
 #include 
@@ -71,12 +64,6 @@
 namespace clover {
namespace llvm {
   namespace compat {
-#if HAVE_LLVM >= 0x0307
- typedef ::llvm::TargetLibraryInfoImpl target_library_info;
-#else
- typedef ::llvm::TargetLibraryInfo target_library_info;
-#endif
-
  template
  unsigned target_address_space(const T , const AS lang_as) {
 const auto  = target.getAddressSpaceMap();
@@ -95,19 +82,6 @@ namespace clover {
  const clang::LangStandard::Kind lang_opencl10 = 
clang::LangStandard::lang_opencl;
 #endif
 
- inline void
- set_lang_defaults(clang::CompilerInvocation ,
-   clang::LangOptions , clang::InputKind ik,
-   const ::llvm::Triple ,
-   clang::PreprocessorOptions ,
-   clang::LangStandard::Kind std) {
-#if HAVE_LLVM >= 0x0309
-inv.setLangDefaults(lopts, ik, t, ppopts, std);
-#else
-inv.setLangDefaults(lopts, ik, std);
-#endif
- }
-
  inline void
  add_link_bitcode_file(clang::CodeGenOptions ,
const std::string ) {
@@ -118,78 +92,8 @@ namespace clover {
 F.PropagateAttrs = true;
 F.LinkFlags = ::llvm::Linker::Flags::None;
 opts.LinkBitcodeFiles.emplace_back(F);
-#elif HAVE_LLVM >= 0x0308
-opts.LinkBitcodeFiles.emplace_back(::llvm::Linker::Flags::None, 
path);
-#else
-opts.LinkBitcodeFile = path;
-#endif
- }
-
-#if HAVE_LLVM >= 0x0307
- typedef ::llvm::legacy::PassManager pass_manager;
-#else
- typedef ::llvm::PassManager pass_manager;
-#endif
-
- inline void
- add_data_layout_pass(pass_manager ) {
-#if HAVE_LLVM < 0x0307
-pm.add(new ::llvm::DataLayoutPass());
-#endif
- }
-
- inline void
- add_internalize_pass(pass_manager ,
-  const std::vector ) {
-#if HAVE_LLVM >= 0x0309
-pm.add(::llvm::createInternalizePass(
-  [=](const ::llvm::GlobalValue ) {
- return std::find(names.begin(), names.end(),
-  gv.getName()) != names.end();
-  }));
 #else
-pm.add(::llvm::createInternalizePass(std::vector(
-  map(std::mem_fn(::string::data), names;
-#endif
- }
-
- inline std::unique_ptr< ::llvm::Linker>
- create_linker(::llvm::Module ) {
-#if HAVE_LLVM >= 0x0308
-return std::unique_ptr< ::llvm::Linker>(new ::llvm::Linker(mod));
-#else
-return std::unique_ptr< ::llvm::Linker>(new ::llvm::Linker());
-#endif
- }
-
- inline bool
- link_in_module(::llvm::Linker ,
-std::unique_ptr< ::llvm::Module> mod) {
-#if HAVE

[Mesa-dev] [PATCH 1/3] clover: Fix build after llvm r332881.

[Jan Vesely]

r332881 added an extra parameter to the emit function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106619
Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
---
 .../state_trackers/clover/llvm/codegen/native.cpp  |  3 +--
 src/gallium/state_trackers/clover/llvm/compat.hpp  | 10 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index 409f8ac32f..4b589ef50c 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -126,13 +126,12 @@ namespace {
   {
  compat::pass_manager pm;
  ::llvm::raw_svector_ostream os { data };
- compat::raw_ostream_to_emit_file fos(os);
 
  mod.setDataLayout(compat::get_data_layout(*tm));
  tm->Options.MCOptions.AsmVerbose =
 (ft == TargetMachine::CGFT_AssemblyFile);
 
- if (tm->addPassesToEmitFile(pm, fos, ft))
+   if (compat::add_passes_to_emit_file(*tm, pm, os, ft))
 fail(r_log, build_error(), "TargetMachine can't emit this file");
 
  pm.run(mod);
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 2e070b2eef..96ba798970 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -245,6 +245,16 @@ namespace clover {
::llvm::WriteBitcodeToFile(mod, os);
 #else
::llvm::WriteBitcodeToFile(, os);
+#endif
+   }
+   template
+   bool add_passes_to_emit_file(TM , PM , OS , FT )
+   {
+   compat::raw_ostream_to_emit_file fos(os);
+#if HAVE_LLVM >= 0x0700
+   return tm.addPassesToEmitFile(pm, fos, nullptr, ft);
+#else
+   return tm.addPassesToEmitFile(pm, fos, ft);
 #endif
}
   }
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] Replace an flock with a random filename to evade some very ugly system dependent code

[Jan Vesely]

On Sun, 2018-05-20 at 14:16 +0200, Benedikt Schemmer wrote:
> There is exactly one flock in mesa and it caused mesa not to build
> on windows when shader cache was enabled.
> 
> It should be possible to revert 9f8dc3bf03ec825bae7041858dda6ca2e9a34363
> "utils: build sha1/disk cache only with Android/Autoconf" currently
> guarding the offending code with ENABLE_SHADER_CACHE
> 
> This would allow shader cache to work on windows I think.
> 
> I dont have a test system with windows though.
> This builds on linux and is tested with Deus Ex:MD and Metro 2033 Redux
> both with cold shader cache.
> 
> Really
> Fixes: d1efa09d342bff3e5def2978a0bef748d74f9c82
> 
> CC: Tapani Pälli <tapani.pa...@intel.com>
> CC: "Marek Olšák" <mar...@gmail.com> 
> CC: Emil Velikov <emil.l.veli...@gmail.com>
> CC: Timothy Arceri <tarc...@itsqueeze.com>
> CC: Samuel Pitoiset <samuel.pitoi...@gmail.com>
> ---
> This enables the patch
> [PATCH 1/3] mesa/main/shaderapi: Use generate_sha1() unconditionally
> 
>  src/util/disk_cache.c | 48 +++-
>  1 file changed, 35 insertions(+), 13 deletions(-)
> 
> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
> index 4a762eff20..ca47bb15fb 100644
> --- a/src/util/disk_cache.c
> +++ b/src/util/disk_cache.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -848,6 +847,29 @@ struct cache_entry_file_data {
> uint32_t uncompressed_size;
>  };
>  
> +static char *
> +generate_random_string(int length) {
> +   static const char a[] = "0123456789abcdef";
> +
> +   if (length > 16)
> +  return NULL;
> +
> +   char buf[16];
> +   char *rndstr;
> +
> +   for (int i = 0; i < length - 1; ++i) {
> +   // assign a random element from the lookup table
> +   buf[i] = a[rand() % (sizeof(a) - 1)];
> +   }
> +
> +   buf[length - 1] = 0;
> +
> +   if (asprintf(, "%s", buf) == -1)
> +  return NULL;
> +
> +   return rndstr;
> +}

This looks like you're trying to reimplement mktemp (also available on
windows).

> +
>  static void
>  cache_put(void *job, int thread_index)
>  {
> @@ -855,7 +877,7 @@ cache_put(void *job, int thread_index)
>  
> int fd = -1, fd_final = -1, err, ret;
> unsigned i = 0;
> -   char *filename = NULL, *filename_tmp = NULL;
> +   char *filename = NULL, *filename_tmp = NULL, *random = NULL;
> struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *) job;
>  
> filename = get_cache_file(dc_job->cache, dc_job->key);
> @@ -873,7 +895,16 @@ cache_put(void *job, int thread_index)
>  * final destination filename, (to prevent any readers from seeing
>  * a partially written file).
>  */
> -   if (asprintf(_tmp, "%s.tmp", filename) == -1)
> +
> +   /* This next part used to be an flock(), which would prevent windows 
> systems
> +* to build. 4 hex characters should be enough to prevent filename race
> +* conditions for now.
> +   */
> +   random = generate_random_string(4);
> +   if (random == NULL)
> +  goto done;
> +
> +   if (asprintf(_tmp, "%s_%s.tmp", filename, random) == -1)
>goto done;
>  
> fd = open(filename_tmp, O_WRONLY | O_CLOEXEC | O_CREAT, 0644);
> @@ -890,16 +921,7 @@ cache_put(void *job, int thread_index)
>   goto done;
> }

you can avoid the lock if you use O_CREAT | O_EXCL. The thread that
looses race will receive EEXIST error from the open() call. It should
also work on windows.

Jan

>  
> -   /* With the temporary file open, we take an exclusive flock on
> -* it. If the flock fails, then another process still has the file
> -* open with the flock held. So just let that file be responsible
> -* for writing the file.
> -*/
> -   err = flock(fd, LOCK_EX | LOCK_NB);
> -   if (err == -1)
> -  goto done;
> -
> -   /* Now that we have the lock on the open temporary file, we can
> +   /* Now that we have the open temporary file, we can
>  * check to see if the destination file already exists. If so,
>  * another process won the race between when we saw that the file
>  * didn't exist and now. In this case, we don't do anything more,

-- 
Jan Vesely <jan.ves...@rutgers.edu>

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

[Jan Vesely]

On Fri, 2018-05-18 at 21:31 -0500, Aaron Watry wrote:
> On Fri, May 18, 2018 at 1:15 PM, Jan Vesely <jan.ves...@rutgers.edu> wrote:
> > On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote:
> > > They're not used anywhere else, so keep them private
> > > 
> > > Signed-off-by: Aaron Watry <awa...@gmail.com>
> > 
> > I'm not sure what the original purpose of the removed functions was. If
> > you recall please add it to the commit message.
> 
> I didn't really bother looking into it when I made this change (I
> didn't write this code in the first place).  This is something that
> I've had sitting in my local repo for a while, and just want to stop
> rebasing it.
> 
> It was originally found a while ago when I started looking into the
> thread-safety (or lack thereof) of the compute pool for r600. Figured
> there was no point trying to fix code that was unused.

OK, nvm then. I was just curious how we ended up with so much dead
code.

> 
> > Either way:
> > 
> > Reviewed-by: Jan Vesely <jan.ves...@rutgers.edu>
> 
> For this one, or both?

for the series.

thanks,
Jan

> 
> --Aaron
> 
> > 
> > Jan
> > 
> > > ---
> > >  .../drivers/r600/compute_memory_pool.c| 35 +++
> > >  .../drivers/r600/compute_memory_pool.h| 24 -
> > >  2 files changed, 29 insertions(+), 30 deletions(-)
> > > 
> > > diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
> > > b/src/gallium/drivers/r600/compute_memory_pool.c
> > > index d1ef25ae1e..981d944b8d 100644
> > > --- a/src/gallium/drivers/r600/compute_memory_pool.c
> > > +++ b/src/gallium/drivers/r600/compute_memory_pool.c
> > > @@ -43,6 +43,29 @@
> > >  #include 
> > > 
> > >  #define ITEM_ALIGNMENT 1024
> > > +
> > > +/* A few forward declarations of static functions */
> > > +static void compute_memory_shadow(struct compute_memory_pool* pool,
> > > + struct pipe_context *pipe, int device_to_host);
> > > +
> > > +static void compute_memory_defrag(struct compute_memory_pool *pool,
> > > + struct pipe_resource *src, struct pipe_resource *dst,
> > > + struct pipe_context *pipe);
> > > +
> > > +static int compute_memory_promote_item(struct compute_memory_pool *pool,
> > > + struct compute_memory_item *item, struct pipe_context *pipe,
> > > + int64_t allocated);
> > > +
> > > +static void compute_memory_move_item(struct compute_memory_pool *pool,
> > > + struct pipe_resource *src, struct pipe_resource *dst,
> > > + struct compute_memory_item *item, uint64_t new_start_in_dw,
> > > + struct pipe_context *pipe);
> > > +
> > > +static void compute_memory_transfer(struct compute_memory_pool* pool,
> > > + struct pipe_context * pipe, int device_to_host,
> > > + struct compute_memory_item* chunk, void* data,
> > > + int offset_in_chunk, int size);
> > > +
> > >  /**
> > >   * Creates a new pool.
> > >   */
> > > @@ -106,7 +129,7 @@ void compute_memory_pool_delete(struct 
> > > compute_memory_pool* pool)
> > >   * \returns -1 if it fails, 0 otherwise
> > >   * \see compute_memory_finalize_pending
> > >   */
> > > -int compute_memory_grow_defrag_pool(struct compute_memory_pool *pool,
> > > +static int compute_memory_grow_defrag_pool(struct compute_memory_pool 
> > > *pool,
> > >   struct pipe_context *pipe, int new_size_in_dw)
> > >  {
> > >   new_size_in_dw = align(new_size_in_dw, ITEM_ALIGNMENT);
> > > @@ -168,7 +191,7 @@ int compute_memory_grow_defrag_pool(struct 
> > > compute_memory_pool *pool,
> > >   * \param device_to_host 1 for device->host, 0 for host->device
> > >   * \see compute_memory_grow_defrag_pool
> > >   */
> > > -void compute_memory_shadow(struct compute_memory_pool* pool,
> > > +static void compute_memory_shadow(struct compute_memory_pool* pool,
> > >   struct pipe_context * pipe, int device_to_host)
> > >  {
> > >   struct compute_memory_item chunk;
> > > @@ -262,7 +285,7 @@ int compute_memory_finalize_pending(struct 
> > > compute_memory_pool* pool,
> > >   * \param dstThe destination resource
> > >   * \see compute_memory_grow_defrag_pool and 
> > > compute_memory_finalize_pending
> > >   */
> > > -void compute_memory_defrag(struct compute_memory_pool *pool,
> > > +static void com

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

[Jan Vesely]

On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote:
> They're not used anywhere else, so keep them private
> 
> Signed-off-by: Aaron Watry <awa...@gmail.com>

I'm not sure what the original purpose of the removed functions was. If
you recall please add it to the commit message.
Either way:

Reviewed-by: Jan Vesely <jan.ves...@rutgers.edu>

Jan

> ---
>  .../drivers/r600/compute_memory_pool.c| 35 +++
>  .../drivers/r600/compute_memory_pool.h| 24 -
>  2 files changed, 29 insertions(+), 30 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
> b/src/gallium/drivers/r600/compute_memory_pool.c
> index d1ef25ae1e..981d944b8d 100644
> --- a/src/gallium/drivers/r600/compute_memory_pool.c
> +++ b/src/gallium/drivers/r600/compute_memory_pool.c
> @@ -43,6 +43,29 @@
>  #include 
>  
>  #define ITEM_ALIGNMENT 1024
> +
> +/* A few forward declarations of static functions */
> +static void compute_memory_shadow(struct compute_memory_pool* pool,
> + struct pipe_context *pipe, int device_to_host);
> +
> +static void compute_memory_defrag(struct compute_memory_pool *pool,
> + struct pipe_resource *src, struct pipe_resource *dst,
> + struct pipe_context *pipe);
> +
> +static int compute_memory_promote_item(struct compute_memory_pool *pool,
> + struct compute_memory_item *item, struct pipe_context *pipe,
> + int64_t allocated);
> +
> +static void compute_memory_move_item(struct compute_memory_pool *pool,
> + struct pipe_resource *src, struct pipe_resource *dst,
> + struct compute_memory_item *item, uint64_t new_start_in_dw,
> + struct pipe_context *pipe);
> +
> +static void compute_memory_transfer(struct compute_memory_pool* pool,
> + struct pipe_context * pipe, int device_to_host,
> + struct compute_memory_item* chunk, void* data,
> + int offset_in_chunk, int size);
> +
>  /**
>   * Creates a new pool.
>   */
> @@ -106,7 +129,7 @@ void compute_memory_pool_delete(struct 
> compute_memory_pool* pool)
>   * \returns -1 if it fails, 0 otherwise
>   * \see compute_memory_finalize_pending
>   */
> -int compute_memory_grow_defrag_pool(struct compute_memory_pool *pool,
> +static int compute_memory_grow_defrag_pool(struct compute_memory_pool *pool,
>   struct pipe_context *pipe, int new_size_in_dw)
>  {
>   new_size_in_dw = align(new_size_in_dw, ITEM_ALIGNMENT);
> @@ -168,7 +191,7 @@ int compute_memory_grow_defrag_pool(struct 
> compute_memory_pool *pool,
>   * \param device_to_host 1 for device->host, 0 for host->device
>   * \see compute_memory_grow_defrag_pool
>   */
> -void compute_memory_shadow(struct compute_memory_pool* pool,
> +static void compute_memory_shadow(struct compute_memory_pool* pool,
>   struct pipe_context * pipe, int device_to_host)
>  {
>   struct compute_memory_item chunk;
> @@ -262,7 +285,7 @@ int compute_memory_finalize_pending(struct 
> compute_memory_pool* pool,
>   * \param dstThe destination resource
>   * \see compute_memory_grow_defrag_pool and compute_memory_finalize_pending
>   */
> -void compute_memory_defrag(struct compute_memory_pool *pool,
> +static void compute_memory_defrag(struct compute_memory_pool *pool,
>   struct pipe_resource *src, struct pipe_resource *dst,
>   struct pipe_context *pipe)
>  {
> @@ -292,7 +315,7 @@ void compute_memory_defrag(struct compute_memory_pool 
> *pool,
>   * \return -1 if it fails, 0 otherwise
>   * \see compute_memory_finalize_pending
>   */
> -int compute_memory_promote_item(struct compute_memory_pool *pool,
> +static int compute_memory_promote_item(struct compute_memory_pool *pool,
>   struct compute_memory_item *item, struct pipe_context *pipe,
>   int64_t start_in_dw)
>  {
> @@ -397,7 +420,7 @@ void compute_memory_demote_item(struct 
> compute_memory_pool *pool,
>   * \param new_start_in_dwThe new position of the item in \a item_list
>   * \see compute_memory_defrag
>   */
> -void compute_memory_move_item(struct compute_memory_pool *pool,
> +static void compute_memory_move_item(struct compute_memory_pool *pool,
>   struct pipe_resource *src, struct pipe_resource *dst,
>   struct compute_memory_item *item, uint64_t new_start_in_dw,
>   struct pipe_context *pipe)
> @@ -569,7 +592,7 @@ struct compute_memory_item* compute_memory_alloc(
>   * \param device_to_host 1 for device->host, 0 for host->device.
>   * \see compute_memory_shadow
>   */
> -void compute_memory_transfer(
> +static void compute_memory_transfer(
>   struct compute_memory_pool* pool,
>   struct pipe_context * pipe,
>   int device_to_host,
> diff --git a/src/gallium/driver

[Mesa-dev] [PATCH 1/1] travis: Adapt to radeonsi dropping support for LLVM 4

[Jan Vesely]

meson Vulkan, Clover, and autotools Vulkan need to be switched to llvm 5

Fixes: f9eb1ef870eba9fdacf9a8cbd815ec3bff81db05
Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
---
 .travis.yml | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index c8b68a6696..e3471d47ac 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -34,17 +34,17 @@ matrix:
 - LABEL="meson Vulkan"
 - BUILD=meson
 - MESON_OPTIONS="-Ddri-drivers= -Dgallium-drivers="
-- LLVM_VERSION=4.0
+- LLVM_VERSION=5.0
 - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
   addons:
 apt:
   sources:
-- llvm-toolchain-trusty-4.0
+- llvm-toolchain-trusty-5.0
   packages:
 # LLVM packaging is broken and misses these dependencies
 - libedit-dev
 # From sources above
-- llvm-4.0-dev
+- llvm-5.0-dev
 # Common
 - xz-utils
 - libexpat1-dev
@@ -231,7 +231,7 @@ matrix:
 - 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"
+- GALLIUM_DRIVERS="r600"
 - VULKAN_DRIVERS=""
 - LIBUNWIND_FLAGS="--enable-libunwind"
   addons:
@@ -331,7 +331,7 @@ matrix:
 - BUILD=make
 - MAKEFLAGS="-j4"
 - MAKE_CHECK_COMMAND="make -C src/gtest check && make -C src/intel 
check"
-- LLVM_VERSION=4.0
+- LLVM_VERSION=5.0
 - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
 - DRI_LOADERS="--disable-glx --disable-gbm --disable-egl 
--with-platforms=x11,wayland"
 - DRI_DRIVERS=""
@@ -342,12 +342,12 @@ matrix:
   addons:
 apt:
   sources:
-- llvm-toolchain-trusty-4.0
+- llvm-toolchain-trusty-5.0
   packages:
 # LLVM packaging is broken and misses these dependencies
 - libedit-dev
 # From sources above
-- llvm-4.0-dev
+- llvm-5.0-dev
 # Common
 - xz-utils
 - x11proto-xf86vidmode-dev
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/1] eg/compute: Use reference counting to handle compute memory pool.

[Jan Vesely]

On Wed, 2018-05-09 at 15:54 -0400, Jan Vesely wrote:
> Use pipe_refernce to release old RAT surfaces.
> RAT surface adds a reference to pool bo. So use reference counting for 
> pool->bo
> as well.
> 
> v2: Use the same pattern for both defrag paths
> Drop confusing comment
> 
> CC: <mesa-sta...@lists.freedesktop.org>
> Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
> ---

ping. This one fixes a memory corruption.

Jan

>  src/gallium/drivers/r600/compute_memory_pool.c | 16 +---
>  src/gallium/drivers/r600/evergreen_compute.c   |  3 ++-
>  2 files changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
> b/src/gallium/drivers/r600/compute_memory_pool.c
> index bcda155c71..4b0e0044f5 100644
> --- a/src/gallium/drivers/r600/compute_memory_pool.c
> +++ b/src/gallium/drivers/r600/compute_memory_pool.c
> @@ -91,10 +91,7 @@ void compute_memory_pool_delete(struct 
> compute_memory_pool* pool)
>  {
>   COMPUTE_DBG(pool->screen, "* compute_memory_pool_delete()\n");
>   free(pool->shadow);
> - if (pool->bo) {
> - pool->screen->b.b.resource_destroy((struct pipe_screen *)
> - pool->screen, (struct pipe_resource *)pool->bo);
> - }
> + pipe_resource_reference(>bo, NULL);
>   /* In theory, all of the items were freed in compute_memory_free.
>* Just delete the list heads
>*/
> @@ -213,10 +210,8 @@ int compute_memory_grow_defrag_pool(struct 
> compute_memory_pool *pool,
>  
>   compute_memory_defrag(pool, src, dst, pipe);
>  
> - pool->screen->b.b.resource_destroy(
> - (struct pipe_screen *)pool->screen,
> - src);
> -
> + /* Release the old buffer */
> + pipe_resource_reference(>bo, NULL);
>   pool->bo = temp;
>   pool->size_in_dw = new_size_in_dw;
>   }
> @@ -230,9 +225,8 @@ int compute_memory_grow_defrag_pool(struct 
> compute_memory_pool *pool,
>   return -1;
>  
>   pool->size_in_dw = new_size_in_dw;
> - pool->screen->b.b.resource_destroy(
> - (struct pipe_screen *)pool->screen,
> - (struct pipe_resource *)pool->bo);
> + /* Release the old buffer */
> + pipe_resource_reference(>bo, NULL);
>   pool->bo = r600_compute_buffer_alloc_vram(pool->screen, 
> pool->size_in_dw * 4);
>   compute_memory_shadow(pool, pipe, 0);
>  
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
> b/src/gallium/drivers/r600/evergreen_compute.c
> index 5168267d51..5070243914 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -122,7 +122,8 @@ static void evergreen_set_rat(struct r600_pipe_compute 
> *pipe,
>   rat_templ.u.tex.first_layer = 0;
>   rat_templ.u.tex.last_layer = 0;
>  
> - /* Add the RAT the list of color buffers */
> + /* Add the RAT the list of color buffers. Drop the old buffer first. */
> + pipe_surface_reference(>ctx->framebuffer.state.cbufs[id], NULL);
>   pipe->ctx->framebuffer.state.cbufs[id] = pipe->ctx->b.b.create_surface(
>   (struct pipe_context *)pipe->ctx,
>   (struct pipe_resource *)bo, _templ);

-- 
Jan Vesely <jan.ves...@rutgers.edu>

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/9] radeonsi: avoid a crash in gallivm_dispose_target_library_info

[Jan Vesely]

On Thu, 2018-05-10 at 17:10 -0400, Marek Olšák wrote:
> On Thu, May 10, 2018 at 4:39 PM, Jan Vesely <jan.ves...@rutgers.edu> wrote:
> 
> > Is this still needed for llvm-6.0.1?
> > 
> 
> Probably.

was it reproducible on non-ubuntu systems? There's still some time
until 6.0.1 is out, but I don't see any crashes on fedora (llvm-git).

Jan

> 
> Marek

-- 
Jan Vesely <jan.ves...@rutgers.edu>

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Jan Vesely]

Hi Kai,

I've pushed the patch. I've also kept the stable tag although the
policy is (afaik) to only support llvm versions available at the point
of mesa release. Don't be surprised to see some pushback from stable
maintainers.

thanks,
Jan

On Sun, 2018-05-13 at 23:19 +0200, Dieter Nützel wrote:
> Hello Jan and Kai,
> 
> would be nice if this lands (have T-b from me).
> 
> Dieter
> 
> Am 13.05.2018 19:10, schrieb Jan Vesely:
> > Hi,
> > 
> > sorry for the delay. I thought maybe Emil is on holiday. I plan to
> > push this on Monday evening (EDT) if there is no response by then.
> > 
> > Jan
> > 
> > On Sun, May 13, 2018 at 3:56 AM, Kai Wasserbäch
> > <k...@dev.carbon-project.org> wrote:
> > 
> > > Ping! Can somebody *please* commit this patch? It fixes an FTBFS,
> > > has two T-b
> > > and one A-b.
> > > 
> > > Kai Wasserbäch wrote on 07.05.2018 16:48:
> > > > Jan Vesely wrote on 02.05.2018 22:38:
> > > > > On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote:
> > > > > > [...]
> > > > > 
> > > > > Thank for looking into this. We probably need CLANG_LIBS handling
> > > > > similar to LLVM_LIBS. I agree this is the best fix for now.
> > > > > 
> > > > > Acked-by: Jan Vesely <jan.ves...@rutgers.edu>
> > > > > 
> > > > > libclang.so might be a solkution, but I'm not sure how it
> > > 
> > > interacts
> > > > > with older or static build clang. It's also weird that we are
> > > 
> > > linking
> > > > > to clang here instead of clover which actually uses clang
> > > 
> > > symbols.
> > > > > 
> > > > > @Emil, are you OK with this patch?
> > > > 
> > > > Gentle ping.
> > > > 
> > > > > > > > > > -lclangDriver \
> > > > > > > > > > -lclangSerialization \
> > > > > > > > > > -   -lclangCodeGen \
> > > > > > > > > 
> > > > > > > > > Is this change related?
> > > > > > > > 
> > > > > > > > Not really, just a minor clean-up while I was busy a few lines
> > > 
> > > above.
> > > > > > > > "clangCodeGen" is already named on the first Clang library
> > > 
> > > line.
> > > > > > > 
> > > > > > > ah, all right, maybe mention it in the commit message?
> > > > > > 
> > > > > > Do I need to resend the patch for that or can you just add a
> > > 
> > > line like "This
> > > > > > change also removes the duplicate clangCodeGen line (trivial
> > > 
> > > change)." before
> > > > > > pushing, considering, that there are two T-b tags to be added
> > > 
> > > anyway?
> > > > > 
> > > > > I'll add it on my side before pushing the patch.
> > > > 
> > > > Thanks a lot!
> > > > 
> > > > Cheers,
> > > > Kai
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > mesa-dev mailing list
> > > > mesa-dev@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev [1]
> > > > 
> > > 
> > > --
> > > 
> > > Kai Wasserbäch (Kai Wasserbaech)
> > > 
> > > E-Mail: k...@dev.carbon-project.org
> > 
> > 
> > 
> > Links:
> > --
> > [1] 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

-- 
Jan Vesely <jan.ves...@rutgers.edu>

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Jan Vesely]

Hi,

sorry for the delay. I thought maybe Emil is on holiday. I plan to push
this on Monday evening (EDT) if there is no response by then.

Jan

On Sun, May 13, 2018 at 3:56 AM, Kai Wasserbäch <k...@dev.carbon-project.org>
wrote:

> Ping! Can somebody *please* commit this patch? It fixes an FTBFS, has two
> T-b
> and one A-b.
>
>
> Kai Wasserbäch wrote on 07.05.2018 16:48:
> > Jan Vesely wrote on 02.05.2018 22:38:
> >> On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote:
> >>> [...]
> >>
> >> Thank for looking into this. We probably need CLANG_LIBS handling
> >> similar to LLVM_LIBS. I agree this is the best fix for now.
> >>
> >> Acked-by: Jan Vesely <jan.ves...@rutgers.edu>
> >>
> >> libclang.so might be a solkution, but I'm not sure how it interacts
> >> with older or static build clang. It's also weird that we are linking
> >> to clang here instead of clover which actually uses clang symbols.
> >>
> >> @Emil, are you OK with this patch?
> >
> > Gentle ping.
> >
> >>>>>>> -lclangDriver \
> >>>>>>> -lclangSerialization \
> >>>>>>> -   -lclangCodeGen \
> >>>>>>
> >>>>>> Is this change related?
> >>>>>
> >>>>> Not really, just a minor clean-up while I was busy a few lines above.
> >>>>> "clangCodeGen" is already named on the first Clang library line.
> >>>>
> >>>> ah, all right, maybe mention it in the commit message?
> >>>
> >>> Do I need to resend the patch for that or can you just add a line like
> "This
> >>> change also removes the duplicate clangCodeGen line (trivial change)."
> before
> >>> pushing, considering, that there are two T-b tags to be added anyway?
> >>
> >> I'll add it on my side before pushing the patch.
> >
> > Thanks a lot!
> >
> > Cheers,
> > Kai
> >
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
> --
>
> Kai Wasserbäch (Kai Wasserbaech)
>
> E-Mail: k...@dev.carbon-project.org
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/1] winsys/amdgpu: Destroy dev_hash table when the last winsys is removed.

[Jan Vesely]

Fixes memory leak on module unload.

CC: <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
---
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index f4bbd3e732..84d8ca6fcf 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
@@ -220,8 +220,13 @@ static bool amdgpu_winsys_unref(struct radeon_winsys *rws)
simple_mtx_lock(_tab_mutex);
 
destroy = pipe_reference(>reference, NULL);
-   if (destroy && dev_tab)
+   if (destroy && dev_tab) {
   util_hash_table_remove(dev_tab, ws->dev);
+  if (util_hash_table_count(dev_tab) == 0) {
+ util_hash_table_destroy(dev_tab);
+ dev_tab = NULL;
+  }
+   }
 
simple_mtx_unlock(_tab_mutex);
return destroy;
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/9] radeonsi: avoid a crash in gallivm_dispose_target_library_info

[Jan Vesely]

Is this still needed for llvm-6.0.1?

On Mon, Apr 16, 2018 at 8:52 PM, Marek Olšák  wrote:

> From: Marek Olšák 
>
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c b/src/gallium/drivers/
> radeonsi/si_pipe.c
> index 09b9f588a6f..490a090da87 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -157,22 +157,25 @@ static void si_init_compiler(struct si_screen
> *sscreen,
> compiler->data_layout = LLVMCopyStringRepOfTargetData(
> data_layout);
> LLVMDisposeTargetData(data_layout);
>  }
>
>  static void si_destroy_compiler(struct si_compiler *compiler)
>  {
> if (compiler->data_layout)
> LLVMDisposeMessage((char*)compiler->data_layout);
> if (compiler->passmgr)
> LLVMDisposePassManager(compiler->passmgr);
> +#if HAVE_LLVM < 0x0500 || HAVE_LLVM >= 0x0700
> +   /* This crashes on LLVM 5.0 and 6.0 and Ubuntu 18.04, so leak it
> there. */
> if (compiler->target_library_info)
> gallivm_dispose_target_library_info(compiler->target_
> library_info);
> +#endif
> if (compiler->tm)
> LLVMDisposeTargetMachine(compiler->tm);
>  }
>
>  /*
>   * pipe_context
>   */
>  static void si_destroy_context(struct pipe_context *context)
>  {
> struct si_context *sctx = (struct si_context *)context;
> --
> 2.17.0
>
> ___
> 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

[Mesa-dev] [PATCH v2 1/1] eg/compute: Use reference counting to handle compute memory pool.

[Jan Vesely]

Use pipe_refernce to release old RAT surfaces.
RAT surface adds a reference to pool bo. So use reference counting for pool->bo
as well.

v2: Use the same pattern for both defrag paths
Drop confusing comment

CC: <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Jan Vesely <jan.ves...@rutgers.edu>
---
 src/gallium/drivers/r600/compute_memory_pool.c | 16 +---
 src/gallium/drivers/r600/evergreen_compute.c   |  3 ++-
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
b/src/gallium/drivers/r600/compute_memory_pool.c
index bcda155c71..4b0e0044f5 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -91,10 +91,7 @@ void compute_memory_pool_delete(struct compute_memory_pool* 
pool)
 {
COMPUTE_DBG(pool->screen, "* compute_memory_pool_delete()\n");
free(pool->shadow);
-   if (pool->bo) {
-   pool->screen->b.b.resource_destroy((struct pipe_screen *)
-   pool->screen, (struct pipe_resource *)pool->bo);
-   }
+   pipe_resource_reference(>bo, NULL);
/* In theory, all of the items were freed in compute_memory_free.
 * Just delete the list heads
 */
@@ -213,10 +210,8 @@ int compute_memory_grow_defrag_pool(struct 
compute_memory_pool *pool,
 
compute_memory_defrag(pool, src, dst, pipe);
 
-   pool->screen->b.b.resource_destroy(
-   (struct pipe_screen *)pool->screen,
-   src);
-
+   /* Release the old buffer */
+   pipe_resource_reference(>bo, NULL);
pool->bo = temp;
pool->size_in_dw = new_size_in_dw;
}
@@ -230,9 +225,8 @@ int compute_memory_grow_defrag_pool(struct 
compute_memory_pool *pool,
return -1;
 
pool->size_in_dw = new_size_in_dw;
-   pool->screen->b.b.resource_destroy(
-   (struct pipe_screen *)pool->screen,
-   (struct pipe_resource *)pool->bo);
+   /* Release the old buffer */
+   pipe_resource_reference(>bo, NULL);
pool->bo = r600_compute_buffer_alloc_vram(pool->screen, 
pool->size_in_dw * 4);
compute_memory_shadow(pool, pipe, 0);
 
diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
b/src/gallium/drivers/r600/evergreen_compute.c
index 5168267d51..5070243914 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -122,7 +122,8 @@ static void evergreen_set_rat(struct r600_pipe_compute 
*pipe,
rat_templ.u.tex.first_layer = 0;
rat_templ.u.tex.last_layer = 0;
 
-   /* Add the RAT the list of color buffers */
+   /* Add the RAT the list of color buffers. Drop the old buffer first. */
+   pipe_surface_reference(>ctx->framebuffer.state.cbufs[id], NULL);
pipe->ctx->framebuffer.state.cbufs[id] = pipe->ctx->b.b.create_surface(
(struct pipe_context *)pipe->ctx,
(struct pipe_resource *)bo, _templ);
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev