[radeonsi] RUSTICL and AMD_DEBUG=useaco SIGFAULT / SIGABRT

[Dieter Nützel]

Hello List,

running clinfo under RUSTICL on my Polaris 20, RX580 explode with ACO 
compiler.


AMD_DEBUG=useaco

RUSTICL_ENABLE=radeonsi
RUSTICL_FEATURES=fp64


Greetings,
Dieter


(gdb) r
Starting program: /usr/bin/clinfo
Downloading separate debug info for system-supplied DSO at 
0x77fc7000

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Downloading separate debug info for 
/usr/local/lib64/libRusticlOpenCL.so.1

[New Thread 0x7fffebfff6c0 (LWP 2435)]
[New Thread 0x7fffeb6bd6c0 (LWP 2436)]
[New Thread 0x7fffeaebc6c0 (LWP 2437)]
[New Thread 0x7fffea6bb6c0 (LWP 2438)]
Number of platforms   1
  Platform Name   rusticl
  Platform Vendor Mesa/X.org
  Platform VersionOpenCL 3.0
  Platform ProfileFULL_PROFILE
  Platform Extensions 
cl_khr_byte_addressable_store cl_khr_create_command_queue 
cl_khr_extended_versioning cl_khr_icd cl_khr_il_program 
cl_khr_spirv_no_integer_wrap_decoration
  Platform Extensions with Version
cl_khr_byte_addressable_store
0x40 (1.0.0)
  
cl_khr_create_command_queue  
0x40 (1.0.0)
  
cl_khr_extended_versioning   
0x40 (1.0.0)
  cl_khr_icd 
  0x40 (1.0.0)
  cl_khr_il_program  
  0x40 (1.0.0)
  
cl_khr_spirv_no_integer_wrap_decoration  
0x40 (1.0.0)

  Platform Numeric Version0xc0 (3.0.0)
  Platform Extensions function suffix MESA
  Platform Host timer resolution  1ns

  Platform Name   rusticl
Number of devices 1
  Device Name AMD Radeon RX 580 
Series (polaris10, LLVM 17.0.0git, DRM 3.52, 6.4.2-1.ge2dafc9-default)

  Device Vendor   AMD
  Device Vendor ID0x1002
  Device Version  OpenCL 3.0
  Device UUID 
-0100---
  Driver UUID 
414d442d-4d45-5341-2d44-5256

  Valid Device LUID   No
  Device LUID -
  Device Node Mask0
  Device Numeric Version  0xc0 (3.0.0)
  Driver Version  23.2.0-devel 
(git-0695ead057)

  Device OpenCL C Version OpenCL C 1.2
  Device OpenCL C Numeric Version 0x402000 (1.2.0)
  Device OpenCL C all versionsOpenCL C   
  0xc0 (3.0.0)
  OpenCL C   
  0x402000 (1.2.0)
  OpenCL C   
  0x401000 (1.1.0)
  OpenCL C   
  0x40 (1.0.0)
  Device OpenCL C features
__opencl_c_integer_dot_product_input_4x8bit_packed   
0x80 (2.0.0)
  
__opencl_c_integer_dot_product_input_4x8bit  
0x80 (2.0.0)
  __opencl_c_fp64
  0x40 (1.0.0)
  __opencl_c_int64   
  0x40 (1.0.0)
  __opencl_c_images  
  0x40 (1.0.0)
  
__opencl_c_3d_image_writes   
0x40 (1.0.0)
  __opencl_c_subgroups   
  0x40 (1.0.0)

  Latest conformance test passed  v-01-01-00
  Device Type GPU
  Device PCI bus info (KHR)   PCI-E, :01:00.0
  Device Profile  EMBEDDED_PROFILE
  Device AvailableYes
  Compiler Available

Mesa | LLVM git | rustical configuration problem after meson version bump 1.0.x to 1.1.x

[Dieter Nützel]

Hello Mesa-Devel,

I need badly advise for Mesa compilation.

openSUSE TW
with LLVM git 17.0.0.0 under /usr/local for ages.

After meson distro update from

meson-1.0.0 series to
meson-1.1.1

LLVM git couldn't found any longer under

/usr/local

SPIRV is there, as always.
/usr/local/lib/pkgconfig/LLVMSPIRVLib.pc
LLVMSPIRVLib point to 17.0.0.0

custom-llvm.ini
[binaries]
llvm-config = '/usr/local/bin/llvm-config'

Do NOT help?!

Going back to meson-1.0.0-1.2 helped for some time,
but broke during the last two weeks.

Which environment variable should be set, now?
I'm lost.

Any hints are very much appreciated.

Dieter

Found CMake: /usr/bin/cmake (3.26.4)
WARNING: CMake Toolchain: Failed to determine CMake compilers state
WARNING: CMake Toolchain: Failed to determine CMake compilers state
Run-time dependency LLVM (modules: LLVM) found: YES 16.0.6
Run-time dependency spirv-tools found: YES 2023.3.1
Dependency LLVMSPIRVLib found: NO found 17.0.0.0 but need: '< 16.1' ; 
matched: '>= 8.0.1.3', '>= 16.0'

Run-time dependency llvmspirvlib found: NO (tried cmake)

../meson.build:1761:21: ERROR: Dependency lookup for LLVMSPIRVLib with 
method 'pkgconfig' failed: Invalid version, need 'LLVMSPIRVLib' ['< 
16.1'] found '17.0.0.0'.


A full log can be found at /opt/mesa/build/meson-logs/meson-log.txt

[Mesa-dev] [r600/sfn] Compilation error (and some warnings) - maybe to old LLVM git version, here?

[Dieter Nützel]

[48/179] Compiling C++ object 
src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o
FAILED: 
src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o
ccache c++ -Isrc/gallium/drivers/r600/libr600.a.p 
-Isrc/gallium/drivers/r600 -I../src/gallium/drivers/r600 -Isrc -I../src 
-Isrc/mapi -I../src/mapi -Isrc/mesa -I../src/mesa -Iinclude -I../include 
-Isrc/compiler -I../src/compiler -I../src/gallium/include 
-Isrc/gallium/auxiliary -I../src/gallium/auxiliary -Isrc/amd/common 
-I../src/amd/common -Isrc/gallium/drivers -I../src/gallium/drivers 
-Isrc/compiler/nir -I../src/compiler/nir -Isrc/util -I../src/util 
-I/usr/include/libdrm -fvisibility=hidden -fdiagnostics-color=always 
-DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-Wnon-virtual-dtor -std=c++14 -O3 -ffunction-sections -fdata-sections 
'-DPACKAGE_VERSION="21.0.0-devel"' 
'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues;' 
-DUSE_ELF_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DHAVE_XCB_PLATFORM 
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM 
-DHAVE_DRM_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 
-DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL 
-DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS 
-DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT 
-DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE 
-DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN 
-DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE 
-DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT 
-DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT 
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL 
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN 
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DUSE_SSE41 
-DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS 
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_EXECINFO_H 
-DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_STRTOF -DHAVE_MKOSTEMP 
-DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK 
-DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_PROGRAM_INVOCATION_NAME 
-DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR 
-DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_PTHREAD 
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DLLVM_AVAILABLE 
'-DMESA_LLVM_VERSION_STRING="12.0.0"' -DLLVM_IS_SHARED=1 
-DUSE_LIBGLVND=1 -DHAVE_LIBUNWIND -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS 
-DHAVE_LIBSENSORS=1 -Werror=return-type -Werror=empty-body 
-Wno-non-virtual-dtor -Wno-missing-field-initializers 
-Wno-format-truncation -fno-math-errno -fno-trapping-math 
-flifetime-dse=1 -Werror=format -Wformat-security -fPIC -pthread 
-D__STDC_FORMAT_MACROS -D_GNU_SOURCE -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -MD -MQ 
src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o -MF 
src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o.d -o 
src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o -c 
../src/gallium/drivers/r600/sfn/sfn_shader_fragment.cpp
../src/gallium/drivers/r600/sfn/sfn_shader_fragment.cpp: In function 
‘unsigned int r600::barycentric_ij_index(nir_intrinsic_instr*)’:
../src/gallium/drivers/r600/sfn/sfn_shader_fragment.cpp:102:4: error: 
control reaches end of non-void function [-Werror=return-type]

  102 |case INTERP_MODE_FLAT:
  |^~~~
cc1plus: some warnings being treated as errors
[56/179] Compiling C++ object 
src/gallium/frontends/clover/libclllvm.a.p/llvm_codegen_common.cpp.o
In file included from 
../src/gallium/frontends/clover/llvm/codegen/common.cpp:34:
../src/gallium/frontends/clover/llvm/metadata.hpp: In function 
‘std::string clover::llvm::get_type_kernel_metadata(const 
llvm::Function&, const string&)’:
../src/gallium/frontends/clover/llvm/metadata.hpp:132:86: warning: 
‘unsigned int llvm::VectorType::getNumElements() const’ is deprecated 
[-Wdeprecated-declarations]
  132 |   data += 
std::to_string(((::llvm::VectorType*)type)->getNumElements());
  |  
^

In file included from /usr/local/include/llvm/IR/DataLayout.h:26,
 from /usr/local/include/llvm/IR/Module.h:25,
 from 
../src/gallium/frontends/clover/llvm/codegen.hpp:35,
 from 
../src/gallium/frontends/clover/llvm/codegen/common.cpp:33:

/usr/local/include/llvm/IR/DerivedTypes.h:534:10: note: declared here
  534 | unsigned VectorType::getNumElements() const {
  |  ^~
[57/179] Compiling C++ object 
src/gallium/frontends/clover/libclllvm.a.p/llvm_invocation.cpp.o
In file included from 
../src/gallium/frontends/clover/llvm/invocation.cpp:55:
../src/gallium/frontends/clover/llvm/metadata.hpp: In function 
‘std::string clover::llvm::get_type_kernel_metadata(const 
llvm::Function&, const string&)’:

Re: [Mesa-dev] New Mesa3D.org website proposal

[Dieter Nützel]

GREAT work!

Now, it's working with Konqueror (20.04.1 / Frameworks 5.70.0) - even if 
without 'hovered animation'... ;-)


Greetings,
Dieter

Am 14.06.2020 17:25, schrieb Daniel Stone:

Hi,

On Fri, 29 May 2020 at 10:08, Erik Faye-Lund
 wrote:

In the light of the explanation above, do you still have objections to
this split?

Obviously, we haven't moved forward yet ;-)


Well, we have now after getting some agreement. Please enjoy your
shiny new https://www.mesa3d.org and https://docs.mesa3d.org
experience.

Brian, could you please change the DNS for mesa3d.org and
www.mesa3d.org to point to 35.227.58.183? No need to change
archive.mesa3d.org, that should still point to the old site.

Cheers,
Daniel
___
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] radv: Handle failing to create .cache dir. BISECTED - This one is broken

[Dieter Nützel]

Hello Bas,

here is something lost/broken.
Part-of: 



If you have NO
~/.cache/radv_builtin_shaders64

it wouldn't be (re)created any longer.

Reverting #cd61f5234d2 solved it.

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

[Mesa-dev] [radeonsi] Re: glthread: upload non-VBO vertices and indices for non-Indirect non-IBM draws - BISECTED

[Dieter Nützel]

Hello Marek,

this was time and nerve consuming (with all the LLVM 11 
revert/re-revert).

FreeCAD vbo rendering bugs.

Mesa-20.1-rc4 is fine (sure)

Mesa git with #2840bc3065b reverted (glthread_draw.c deleted), too.

/opt/mesa> git bisect bad
2840bc3065b9e991b2c5880a2ee02e2458a758c4 is the first bad commit
commit 2840bc3065b9e991b2c5880a2ee02e2458a758c4
Author: Marek Olšák 
Date:   Fri Mar 6 16:56:54 2020 -0500

glthread: upload non-VBO vertices and indices for non-Indirect 
non-IBM draws


This is basically the same thing u_vbuf does.

Part-of: 



 src/mapi/glapi/gen/ARB_base_instance.xml   |   9 +-
 .../glapi/gen/ARB_draw_elements_base_vertex.xml|  12 +-
 src/mapi/glapi/gen/ARB_draw_instanced.xml  |   6 +-
 src/mapi/glapi/gen/gl_API.xml  |  15 +-
 src/mesa/Makefile.sources  |   1 +
 src/mesa/main/glthread.c   |   7 +
 src/mesa/main/glthread.h   |   1 +
 src/mesa/main/glthread_draw.c  | 982 
+

 src/mesa/meson.build   |   1 +
 9 files changed, 1006 insertions(+), 28 deletions(-)
 create mode 100644 src/mesa/main/glthread_draw.c

Next 'night' I'll make an entry at gitlab, if you don't outpace me...;-)

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

Re: [Mesa-dev] Mesa git and LLVM git (11) compilation trouble - LLVMFixedVectorTypeKind now undeclared

[Dieter Nützel]

Am 19.05.2020 09:32, schrieb Michel Dänzer:

On 2020-05-19 4:19 a.m., Dieter Nützel wrote:

Hello Marek, Jan, Karol et al.,

I'm hunting a radeonsi (Polaris 20) Mesa git / LVVM 11 regression and
current LLVM git code can't compile SPIRV-LLVM-Translator any longer 
and

LLVM 11 without the former installed can't compile
src/amd/llvm/ac_nir_to_llvm.c any more...


See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5087 .


Your are my hero ;-) - Thanks!

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

[Mesa-dev] Mesa git and LLVM git (11) compilation trouble - LLVMFixedVectorTypeKind now undeclared

[Dieter Nützel]

Hello Marek, Jan, Karol et al.,

I'm hunting a radeonsi (Polaris 20) Mesa git / LVVM 11 regression and 
current LLVM git code can't compile SPIRV-LLVM-Translator any longer and 
LLVM 11 without the former installed can't compile 
src/amd/llvm/ac_nir_to_llvm.c any more...


Have to switch my devel system all back to LLVM 10 to get a good 
starting point.


Dieter

mesa/build> time nice +19 ninja
[8/521] Compiling C object 
'src/amd/llvm/ce8261c@@amd_common_llvm@sta/ac_nir_to_llvm.c.o'

FAILED: src/amd/llvm/ce8261c@@amd_common_llvm@sta/ac_nir_to_llvm.c.o
ccache cc -Isrc/amd/llvm/ce8261c@@amd_common_llvm@sta -Isrc/amd/llvm 
-I../src/amd/llvm -Iinclude -I../include -Isrc -I../src -Isrc/mapi 
-I../src/mapi -Isrc/mesa -I../src/mesa -I../src/gallium/include 
-Isrc/gallium/auxiliary -I../src/gallium/auxiliary -Isrc/compiler 
-I../src/compiler -Isrc/amd -I../src/amd -Isrc/amd/common 
-I../src/amd/common -Isrc/compiler/nir -I../src/compiler/nir 
-I/usr/local/include -I/usr/include/libdrm -fdiagnostics-color=always 
-DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 
'-DPACKAGE_VERSION="20.2.0-devel"' 
'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/issues;' 
-DUSE_ELF_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING 
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM 
-DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ 
-DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL 
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL 
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST 
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC 
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED 
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK 
-DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED 
-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_VISIBILITY 
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN 
-DHAVE_UINT128 -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM 
-DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H -DHAVE_LINUX_FUTEX_H 
-DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_EXECINFO_H -DHAVE_SYS_SHM_H 
-DHAVE_CET_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET 
-DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK -DHAVE_STRTOK_R 
-DHAVE_GETRANDOM -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_POSIX_MEMALIGN 
-DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR 
-DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_PTHREAD 
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DLLVM_AVAILABLE 
'-DMESA_LLVM_VERSION_STRING="11.0.0"' -DUSE_LIBGLVND=1 -DHAVE_LIBUNWIND 
-DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_LIBSENSORS=1 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-Werror=return-type -Werror=empty-body 
-Werror=incompatible-pointer-types -Werror=int-conversion 
-Wno-missing-field-initializers -Wno-format-truncation -fno-math-errno 
-fno-trapping-math -fno-common -Werror=format -Wformat-security -fPIC 
-pthread -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS 
-D__STDC_FORMAT_MACROS -fvisibility=hidden -MD -MQ 
'src/amd/llvm/ce8261c@@amd_common_llvm@sta/ac_nir_to_llvm.c.o' -MF 
'src/amd/llvm/ce8261c@@amd_common_llvm@sta/ac_nir_to_llvm.c.o.d' -o 
'src/amd/llvm/ce8261c@@amd_common_llvm@sta/ac_nir_to_llvm.c.o' -c 
../src/amd/llvm/ac_nir_to_llvm.c

../src/amd/llvm/ac_nir_to_llvm.c: In function ‘load_tess_varyings’:
../src/amd/llvm/ac_nir_to_llvm.c:2197:36: error: 
‘LLVMFixedVectorTypeKind’ undeclared (first use in this function); did 
you mean ‘LLVMVectorTypeKind’?

 2197 |  if (LLVMGetTypeKind(dest_type) == LLVMFixedVectorTypeKind)
  |^~~
  |LLVMVectorTypeKind
../src/amd/llvm/ac_nir_to_llvm.c:2197:36: note: each undeclared 
identifier is reported only once for each function it appears in

../src/amd/llvm/ac_nir_to_llvm.c: In function ‘visit_load_var’:
../src/amd/llvm/ac_nir_to_llvm.c:2357:40: error: 
‘LLVMFixedVectorTypeKind’ undeclared (first use in this function); did 
you mean ‘LLVMVectorTypeKind’?

 2357 |if (LLVMGetTypeKind(result_type) == LLVMFixedVectorTypeKind)
  |^~~
  |LLVMVectorTypeKind
../src/amd/llvm/ac_nir_to_llvm.c: In function ‘visit_store_var’:
../src/amd/llvm/ac_nir_to_llvm.c:2533:44: error: 
‘LLVMFixedVectorTypeKind’ undeclared (first use in this function); did 
you mean ‘LLVMVectorTypeKind’?
 2533 |if (LLVMGetTypeKind(LLVMTypeOf(val)) == 
LLVMFixedVectorTypeKind)
  |
^~~

  |LLVMVectorTypeKind
../src/amd/llvm/ac_nir_to_llvm.c: In function ‘visit_deref’:
../src/amd/llvm/ac_nir_to_llvm.c:5025:47: error: 

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

[Dieter Nützel]

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?

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 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_INE

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

[Dieter Nützel]

 Performing Test C_SUPPORTS_DELETE_NON_VIRTUAL_DTOR_FLAG
-- Performing Test C_SUPPORTS_DELETE_NON_VIRTUAL_DTOR_FLAG - Failed
-- Performing Test CXX_SUPPORTS_DELETE_NON_VIRTUAL_DTOR_FLAG
-- Performing Test CXX_SUPPORTS_DELETE_NON_VIRTUAL_DTOR_FLAG - Success
-- Performing Test C_WCOMMENT_ALLOWS_LINE_WRAP
-- Performing Test C_WCOMMENT_ALLOWS_LINE_WRAP - Failed
-- Performing Test C_SUPPORTS_STRING_CONVERSION_FLAG
-- Performing Test C_SUPPORTS_STRING_CONVERSION_FLAG - Failed
-- Performing Test CXX_SUPPORTS_STRING_CONVERSION_FLAG
-- Performing Test CXX_SUPPORTS_STRING_CONVERSION_FLAG - Failed
-- Performing Test LINKER_SUPPORTS_COLOR_DIAGNOSTICS
-- Performing Test LINKER_SUPPORTS_COLOR_DIAGNOSTICS - Failed
-- Performing Test C_SUPPORTS_FNO_FUNCTION_SECTIONS
-- Performing Test C_SUPPORTS_FNO_FUNCTION_SECTIONS - Success
-- Performing Test C_SUPPORTS_FFUNCTION_SECTIONS
-- Performing Test C_SUPPORTS_FFUNCTION_SECTIONS - Success
-- Performing Test CXX_SUPPORTS_FFUNCTION_SECTIONS
-- Performing Test CXX_SUPPORTS_FFUNCTION_SECTIONS - Success
-- Performing Test C_SUPPORTS_FDATA_SECTIONS
-- Performing Test C_SUPPORTS_FDATA_SECTIONS - Success
-- Performing Test CXX_SUPPORTS_FDATA_SECTIONS
-- Performing Test CXX_SUPPORTS_FDATA_SECTIONS - Success
-- Looking for os_signpost_interval_begin
-- Looking for os_signpost_interval_begin - not found
-- Found PythonInterp: /usr/bin/python3.8 (found version "3.8.2")
-- Constructing LLVMBuild project information
-- Found Git: /usr/bin/git (found version "2.26.0")
-- Linker detection: GNU ld
-- Targeting X86
-- Targeting AMDGPU
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.6.3")
-- Checking for one of the modules 'SPIRV-Tools'
-- Looking for sys/resource.h
-- Looking for sys/resource.h - found
-- Clang version: 11.0.0
-- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG
-- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed
-- Looking for include file sys/inotify.h
-- Looking for include file sys/inotify.h - found
-- Registering Bye as a pass plugin (static build: OFF)
-- Failed to find LLVM FileCheck
-- Version: 0.0.0
-- Performing Test HAVE_CXX_FLAG_STD_CXX11
-- Performing Test HAVE_CXX_FLAG_STD_CXX11 - Success
-- Performing Test HAVE_CXX_FLAG_WALL
-- Performing Test HAVE_CXX_FLAG_WALL - Success
-- Performing Test HAVE_CXX_FLAG_WEXTRA
-- Performing Test HAVE_CXX_FLAG_WEXTRA - Success
-- Performing Test HAVE_CXX_FLAG_WSHADOW
-- Performing Test HAVE_CXX_FLAG_WSHADOW - Success
-- Performing Test HAVE_CXX_FLAG_PEDANTIC
-- Performing Test HAVE_CXX_FLAG_PEDANTIC - Success
-- Performing Test HAVE_CXX_FLAG_PEDANTIC_ERRORS
-- Performing Test HAVE_CXX_FLAG_PEDANTIC_ERRORS - Success
-- Performing Test HAVE_CXX_FLAG_WSHORTEN_64_TO_32
-- Performing Test HAVE_CXX_FLAG_WSHORTEN_64_TO_32 - Failed
-- Performing Test HAVE_CXX_FLAG_WFLOAT_EQUAL
-- Performing Test HAVE_CXX_FLAG_WFLOAT_EQUAL - Success
-- Performing Test HAVE_CXX_FLAG_FSTRICT_ALIASING
-- Performing Test HAVE_CXX_FLAG_FSTRICT_ALIASING - Success
-- Performing Test HAVE_CXX_FLAG_FNO_EXCEPTIONS
-- Performing Test HAVE_CXX_FLAG_FNO_EXCEPTIONS - Success
-- Performing Test HAVE_CXX_FLAG_WSTRICT_ALIASING
-- Performing Test HAVE_CXX_FLAG_WSTRICT_ALIASING - Success
-- Performing Test HAVE_CXX_FLAG_WD654
-- Performing Test HAVE_CXX_FLAG_WD654 - Failed
-- Performing Test HAVE_CXX_FLAG_WTHREAD_SAFETY
-- Performing Test HAVE_CXX_FLAG_WTHREAD_SAFETY - Failed
-- Performing Test HAVE_CXX_FLAG_COVERAGE
-- Performing Test HAVE_CXX_FLAG_COVERAGE - Success
-- Performing Test HAVE_GNU_POSIX_REGEX
-- Performing Test HAVE_GNU_POSIX_REGEX
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX
-- Performing Test HAVE_POSIX_REGEX
-- Performing Test HAVE_POSIX_REGEX -- success
-- Performing Test HAVE_STEADY_CLOCK
-- Performing Test HAVE_STEADY_CLOCK
-- Performing Test HAVE_STEADY_CLOCK -- success
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/llvm-project/llvm/build

Am 15.04.2020 05:25, schrieb Dieter Nützel:

Hello Jan, hello all,

compiling latest libclc git
9aa6f35 (HEAD -> master, origin/master, origin/HEAD) travis: Add LLVM 9 
build


with LLVM 11.0.0git from today
b30246087a3 (HEAD -> master) [llvm][StringExtras] Add missing include 
of cctype


./configure.py && time nice +19 make -j8

resulted in this error:

PREPARE-BUILTINS built_libs/tahiti-amdgcn--.bc
LLVM-CC amdgcn--amdhsa/lib/workitem/get_global_size.cl.bc
clang-11: error: cannot find ROCm installation.  Provide its path via
--rocm-path, or pass -nogpulib.
make: *** [Makefile:8132:
amdgcn--amdhsa/lib/workitem/get_global_size.cl.bc] Fehler 1
242.706u 1.148s 4:03.87 99.9%   0+0k 0+177176io 0pf+0w

Since when is ROCm needed?

Thanks,

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

[Dieter Nützel]

Hello Jan, hello all,

compiling latest libclc git
9aa6f35 (HEAD -> master, origin/master, origin/HEAD) travis: Add LLVM 9 
build


with LLVM 11.0.0git from today
b30246087a3 (HEAD -> master) [llvm][StringExtras] Add missing include of 
cctype


./configure.py && time nice +19 make -j8

resulted in this error:

PREPARE-BUILTINS built_libs/tahiti-amdgcn--.bc
LLVM-CC amdgcn--amdhsa/lib/workitem/get_global_size.cl.bc
clang-11: error: cannot find ROCm installation.  Provide its path via 
--rocm-path, or pass -nogpulib.
make: *** [Makefile:8132: 
amdgcn--amdhsa/lib/workitem/get_global_size.cl.bc] Fehler 1

242.706u 1.148s 4:03.87 99.9%   0+0k 0+177176io 0pf+0w

Since when is ROCm needed?

Thanks,

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

Re: [Mesa-dev] Merging experimental r600/nir code

[Dieter Nützel]

=false:quads=5:texture=false: FPS: 13094 FrameTime: 0.076 
ms

libpng warning: iCCP: known incorrect sRGB profile
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: 
FPS: 6635 FrameTime: 0.151 ms

libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 8023 FrameTime: 0.125 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 866 FrameTime: 1.155 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: 
FPS: 1126 FrameTime: 0.888 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 939 FrameTime: 1.065 ms

[ideas] speed=duration: FPS: 4568 FrameTime: 0.219 ms
[jellyfish] : FPS: 11735 FrameTime: 0.085 ms
[terrain] : FPS: 1691 FrameTime: 0.591 ms
[shadow] : FPS: 11271 FrameTime: 0.089 ms
[refract] : FPS: 3250 FrameTime: 0.308 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 15095 FrameTime: 
0.066 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 14874 FrameTime: 
0.067 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 14918 FrameTime: 
0.067 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 14995 
FrameTime: 0.067 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 14879 
FrameTime: 0.067 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 14910 
FrameTime: 0.067 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 
14969 FrameTime: 0.067 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 14804 
FrameTime: 0.068 ms

===
  glmark2 Score: 9
===

***


On Wed, Feb 12, 2020 at 1:56 AM Dieter Nützel 
wrote:


Hello Gert,

your merge 'broke' LTO and then later on PGO compilation/linking.

I do generally compiling with
'-Dgallium-drivers=r600,radeonsi,swrast'
for testing radeonsi and (your) r600 work. ;-)

After your merge I get several warnings in 'addrlib' with LTO and
even a
compiler error (gcc (SUSE Linux) 9.2.1 20200128).

I had to disable 'r600' ('swrast' is needed for 'nine') to get a
working
LTO and even better PGO radeonsi driver.
I'm preparing GREAT LTO+PGO (the later is the greater) numbers over
the
last 2 months. I'll send my results later, today.

Summary
radeonsi is ~40% smaller and 16-20% faster with PGO (!!!).

Honza and the GCC people (Intel's ICC folks) do GREAT things.
'glmark2' numbers are better then 'vkmark'. (Hello, Marek.).

Need some sleep.

See my log, below.

Greetings and GREAT work!

-Dieter

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

Re: [Mesa-dev] Merging experimental r600/nir code

[Dieter Nützel]

Hello Gert,

your merge 'broke' LTO and then later on PGO compilation/linking.

I do generally compiling with '-Dgallium-drivers=r600,radeonsi,swrast'
for testing radeonsi and (your) r600 work. ;-)

After your merge I get several warnings in 'addrlib' with LTO and even a 
compiler error (gcc (SUSE Linux) 9.2.1 20200128).


I had to disable 'r600' ('swrast' is needed for 'nine') to get a working 
LTO and even better PGO radeonsi driver.
I'm preparing GREAT LTO+PGO (the later is the greater) numbers over the 
last 2 months. I'll send my results later, today.


Summary
radeonsi is ~40% smaller and 16-20% faster with PGO (!!!).

Honza and the GCC people (Intel's ICC folks) do GREAT things.
'glmark2' numbers are better then 'vkmark'. (Hello, Marek.).

Need some sleep.

See my log, below.

Greetings and GREAT work!

-Dieter

Am 09.02.2020 15:46, schrieb Gert Wollny:

Am Donnerstag, den 23.01.2020, 20:31 +0100 schrieb Gert Wollny:

has anybody any objections if I merge the r600/NIR code?
Without explicitely setting the debug flag it doesn't change a
thing, but it would be better to continue developing in-tree.

Okay, if nobody objects, I'll merge it Monday evening.

Best,
Gert


[1425/1433] Linking target src/gallium/targets/dri/libgallium_dri.so.
FAILED: src/gallium/targets/dri/libgallium_dri.so
c++  -o src/gallium/targets/dri/libgallium_dri.so 
'src/gallium/targets/dri/8381c20@@gallium_dri@sha/target.c.o' -flto 
-fprofile-generate -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -shared 
-fPIC -Wl,--start-group -Wl,-soname,libgallium_dri.so 
src/mesa/libmesa_gallium.a src/mesa/libmesa_common.a 
src/compiler/glsl/libglsl.a src/compiler/glsl/glcpp/libglcpp.a 
src/util/libmesa_util.a src/util/format/libmesa_format.a 
src/compiler/nir/libnir.a src/compiler/libcompiler.a 
src/mesa/libmesa_sse41.a src/mesa/drivers/dri/common/libdricommon.a 
src/mesa/drivers/dri/common/libmegadriver_stub.a 
src/gallium/state_trackers/dri/libdri.a 
src/gallium/auxiliary/libgalliumvl.a src/gallium/auxiliary/libgallium.a 
src/mapi/shared-glapi/libglapi.so.0.0.0 
src/gallium/auxiliary/pipe-loader/libpipe_loader_static.a 
src/loader/libloader.a src/util/libxmlconfig.a 
src/gallium/winsys/sw/null/libws_null.a 
src/gallium/winsys/sw/wrapper/libwsw.a 
src/gallium/winsys/sw/dri/libswdri.a 
src/gallium/winsys/sw/kms-dri/libswkmsdri.a 
src/gallium/drivers/llvmpipe/libllvmpipe.a 
src/gallium/drivers/softpipe/libsoftpipe.a 
src/gallium/drivers/r600/libr600.a 
src/gallium/winsys/radeon/drm/libradeonwinsys.a 
src/gallium/drivers/radeonsi/libradeonsi.a 
src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a 
src/amd/addrlib/libaddrlib.a src/amd/common/libamd_common.a 
src/amd/llvm/libamd_common_llvm.a -Wl,--build-id=sha1 -Wl,--gc-sections 
-Wl,--version-script /opt/mesa/src/gallium/targets/dri/dri.sym 
-Wl,--dynamic-list /opt/mesa/src/gallium/targets/dri/../dri-vdpau.dyn 
/usr/lib64/libdrm.so -L/usr/local/lib -lLLVM-10git -pthread 
/usr/lib64/libexpat.so 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libz.so -lm 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libzstd.so 
-L/usr/local/lib -lLLVM-10git /usr/lib64/libunwind.so -ldl -lsensors 
-L/usr/local/lib -lLLVM-10git /usr/lib64/libdrm_radeon.so 
/usr/lib64/libelf.so -L/usr/local/lib -lLLVM-10git -L/usr/local/lib 
-lLLVM-10git -L/usr/local/lib -lLLVM-10git /usr/lib64/libdrm_amdgpu.so 
-L/usr/local/lib -lLLVM-10git -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../../../mesa:$ORIGIN/../../../compiler/glsl:$ORIGIN/../../../compiler/glsl/glcpp:$ORIGIN/../../../util:$ORIGIN/../../../util/format:$ORIGIN/../../../compiler/nir:$ORIGIN/../../../compiler:$ORIGIN/../../../mesa/drivers/dri/common:$ORIGIN/../../state_trackers/dri:$ORIGIN/../../auxiliary:$ORIGIN/../../../mapi/shared-glapi:$ORIGIN/../../auxiliary/pipe-loader:$ORIGIN/../../../loader:$ORIGIN/../../winsys/sw/null:$ORIGIN/../../winsys/sw/wrapper:$ORIGIN/../../winsys/sw/dri:$ORIGIN/../../winsys/sw/kms-dri:$ORIGIN/../../drivers/llvmpipe:$ORIGIN/../../drivers/softpipe:$ORIGIN/../../drivers/r600:$ORIGIN/../../winsys/radeon/drm:$ORIGIN/../../drivers/radeonsi:$ORIGIN/../../winsys/amdgpu/drm:$ORIGIN/../../../amd/addrlib:$ORIGIN/../../../amd/common:$ORIGIN/../../../amd/llvm' 
-Wl,-rpath-link,/opt/mesa/build/src/mesa 
-Wl,-rpath-link,/opt/mesa/build/src/compiler/glsl 
-Wl,-rpath-link,/opt/mesa/build/src/compiler/glsl/glcpp 
-Wl,-rpath-link,/opt/mesa/build/src/util 
-Wl,-rpath-link,/opt/mesa/build/src/util/format 
-Wl,-rpath-link,/opt/mesa/build/src/compiler/nir 
-Wl,-rpath-link,/opt/mesa/build/src/compiler 
-Wl,-rpath-link,/opt/mesa/build/src/mesa/drivers/dri/common 
-Wl,-rpath-link,/opt/mesa/build/src/gallium/state_trackers/dri 
-Wl,-rpath-link,/opt/mesa/build/src/gallium/auxiliary 
-Wl,-rpath-link,/opt/mesa/build/src/mapi/shared-glapi 
-Wl,-rpath-link,/opt/mesa/build/src/gallium/auxiliary/pipe-loader 
-Wl,-rpath-link,/opt/mesa/build/src/loader 
-Wl,-rpath-link,/opt/mesa/build/src/gallium/winsys/sw/null 
-Wl,-rpath-link,/opt/mesa/build/src/gallium/winsys/sw/wrapper 

Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened

[Dieter Nützel]

Am 31.01.2020 02:44, schrieb Dieter Nützel:

Am 31.01.2020 02:33, schrieb Pierre Moreau:

On 2020-01-31 — 01:48, Dieter Nützel wrote:

@Pierre and Karol
Now I get this with 'llvmorg-10.0.0-rc1' and current 
'SPIRV-LLVM-Translator'

master:


I’m recompiling LLVM to that tag and see what I get, but it looks like 
for some

reason it forgets to link against LLVMSPIRVLib, which is surprising.

Are you building within LLVM, or out of tree? And did you set
`LLVM_SPIRV_BUILD_EXTERNAL` manually when configuring with CMake?


I'm 'trying' it since 'the beginning' in tree. ;-)


I am wondering if something might have gone wrong with
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/commit/b152e65976d7b764601cba134faf94d530f7b9b8,
though I don’t see what at first look.


I'm so 'old shool' and have to learn so much github tricks...

Currently running 'llvm_release_100' in 'llvmorg-10.0.0-rc1'.


OK. 'Ready'.
Same thing:

up.main+0x17bb): undefined reference to `SPIRV::SPIRVUseTextFormat'
collect2: error: ld returned 1 exit status

Do you think I should try the 'out of tree path' tomorrow, too?

But my aging Xeon X3470 4c/8t, 2.93 GHz (~3.2 GHz TB), 24 GB is so slow 
:-)))


Ah, not so bad...

Good night!

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened

[Dieter Nützel]

Am 31.01.2020 02:33, schrieb Pierre Moreau:

On 2020-01-31 — 01:48, Dieter Nützel wrote:

@Pierre and Karol
Now I get this with 'llvmorg-10.0.0-rc1' and current 
'SPIRV-LLVM-Translator'

master:


I’m recompiling LLVM to that tag and see what I get, but it looks like 
for some

reason it forgets to link against LLVMSPIRVLib, which is surprising.

Are you building within LLVM, or out of tree? And did you set
`LLVM_SPIRV_BUILD_EXTERNAL` manually when configuring with CMake?


I'm 'trying' it since 'the beginning' in tree. ;-)


I am wondering if something might have gone wrong with
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/commit/b152e65976d7b764601cba134faf94d530f7b9b8,
though I don’t see what at first look.


I'm so 'old shool' and have to learn so much github tricks...

Currently running 'llvm_release_100' in 'llvmorg-10.0.0-rc1'.
But my aging Xeon X3470 4c/8t, 2.93 GHz (~3.2 GHz TB), 24 GB is so slow 
:-)))


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

Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened

[Dieter Nützel]

Am 30.01.2020 14:36, schrieb Michel Dänzer:

On 2020-01-30 2:11 p.m., Dieter Nützel wrote:

Am 30.01.2020 07:51, schrieb Pierre Moreau:

On 2020-01-30 — 07:23, Dieter Nützel wrote:

Ugh, LLVM git now at 11.0...missed that.
SPIRV-LLVM-Translator choke with 11.0 git (I think it was the same
with 10.0
git), here. (See below.)
So I can't compile Mesa git (20.0) with '-Dopencl-spirv=true' since
November
(15.11.2019).


The switch to 11.0 has not occurred yet: a pull request was opened a
few days
ago for it (see
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/419)
but the build issues remain to be fixed.

I will need to check for 10.0, but SPIRV-LLVM-Traslator’s master or
llvm_release_100 branches should work against it.

Pierre


Oh, hello Pierre, forgotten to CC you in the first run, sorry!

I'll recheck against LLVM 10.0-rc in the evening.
This shouldn't stop Mesa 20.0 then any longer?!
We have 1 month for fixing.


Mesa 20.0 can't support LLVM 11 anyway.


Thanks Michel for additional info.

@Pierre and Karol
Now I get this with 'llvmorg-10.0.0-rc1' and current 
'SPIRV-LLVM-Translator' master:


[2915/3086] Linking CXX executable bin/llvm-spirv
FAILED: bin/llvm-spirv
: && /usr/bin/c++  -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long 
-Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess 
-Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor 
-Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O3 
-DNDEBUG  -Wl,-allow-shlib-undefined-Wl,-O3 -Wl,--gc-sections 
projects/SPIRV-LLVM-Translator/tools/llvm-spirv/CMakeFiles/llvm-spirv.dir/llvm-spirv.cpp.o 
 -o bin/llvm-spirv  -Wl,-rpath,/opt/llvm-project/build/lib:  
lib/libLLVM-10git.so  -lpthread && :
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
projects/SPIRV-LLVM-Translator/tools/llvm-spirv/CMakeFiles/llvm-spirv.dir/llvm-spirv.cpp.o: 
in function 
`convertSPIRV()::{lambda(std::ostream&)#1}::operator()(std::ostream&) 
const [clone .isra.0]':
llvm-spirv.cpp:(.text._ZZL12convertSPIRVvENKUlRSoE_clES_.isra.0+0x31): 
undefined reference to `SPIRV::convertSpirv(std::istream&, 
std::ostream&, std::__cxx11::basic_string, 
std::allocator >&, bool, bool)'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
projects/SPIRV-LLVM-Translator/tools/llvm-spirv/CMakeFiles/llvm-spirv.dir/llvm-spirv.cpp.o: 
in function `parseSpecConstOpt(llvm::StringRef, 
SPIRV::TranslatorOpts&)':
llvm-spirv.cpp:(.text._Z17parseSpecConstOptN4llvm9StringRefERN5SPIRV14TranslatorOptsE+0x152): 
undefined reference to `llvm::getSpecConstInfo(std::istream&, 
std::vector, 
std::allocator > >&)'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
projects/SPIRV-LLVM-Translator/tools/llvm-spirv/CMakeFiles/llvm-spirv.dir/llvm-spirv.cpp.o: 
in function `main':
llvm-spirv.cpp:(.text.startup.main+0xd1e): undefined reference to 
`llvm::regularizeLlvmForSpirv(llvm::Module*, 
std::__cxx11::basic_string, 
std::allocator >&)'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
llvm-spirv.cpp:(.text.startup.main+0xf75): undefined reference to 
`llvm::readSpirv(llvm::LLVMContext&, SPIRV::TranslatorOpts const&, 
std::istream&, llvm::Module*&, std::__cxx11::basic_stringstd::char_traits, std::allocator >&)'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
llvm-spirv.cpp:(.text.startup.main+0x11dc): undefined reference to 
`llvm::getSpecConstInfo(std::istream&, std::vectorint, unsigned int>, std::allocator 
> >&)'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
llvm-spirv.cpp:(.text.startup.main+0x1472): undefined reference to 
`llvm::writeSpirv(llvm::Module*, SPIRV::TranslatorOpts const&, 
std::ostream&, std::__cxx11::basic_string, 
std::allocator >&)'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
llvm-spirv.cpp:(.text.startup.main+0x16d1): undefined reference to 
`llvm::writeSpirv(llvm::Module*, SPIRV::TranslatorOpts const&, 
std::ostream&, std::__cxx11::basic_string, 
std::allocator >&)'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
llvm-spirv.cpp:(.text.startup.main+0x17bb): undefined reference to 
`SPIRV::SPIRVUseTextFormat'

collect2: error: ld returned 1 exit status
[2924/3086] Building CXX object 
tools/llvm-readobj/CMakeFiles/llvm-readobj.dir/ELFDumper.cpp.o

ninja: build stopped: subcommand failed.
20168.590u 885.906s 46:04.34 761.6% 0+0k 246952+3867256io 140pf+0w

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened

[Dieter Nützel]

Am 30.01.2020 07:51, schrieb Pierre Moreau:

On 2020-01-30 — 07:23, Dieter Nützel wrote:

Ugh, LLVM git now at 11.0...missed that.
SPIRV-LLVM-Translator choke with 11.0 git (I think it was the same 
with 10.0

git), here. (See below.)
So I can't compile Mesa git (20.0) with '-Dopencl-spirv=true' since 
November

(15.11.2019).


The switch to 11.0 has not occurred yet: a pull request was opened a 
few days
ago for it (see 
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/419)

but the build issues remain to be fixed.

I will need to check for 10.0, but SPIRV-LLVM-Traslator’s master or
llvm_release_100 branches should work against it.

Pierre


Oh, hello Pierre, forgotten to CC you in the first run, sorry!

I'll recheck against LLVM 10.0-rc in the evening.
This shouldn't stop Mesa 20.0 then any longer?!
We have 1 month for fixing.

Thank you!

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened

[Dieter Nützel]

Am 30.01.2020 02:59, schrieb Karol Herbst:
On Thu, Jan 30, 2020 at 2:37 AM Dieter Nützel  
wrote:


Maybe compilation with '-Dopencl-spirv=true', again.

It is broken, now.
Even LLVM 10.0 won't compile for me with SPIRV-LLVM-Translator,
currently.



do you have any more details on that? It could be that the
spirv-llvm-translator  diverged somewhere as I am only compiling
against llvm 9 right now.



Ugh, LLVM git now at 11.0...missed that.
SPIRV-LLVM-Translator choke with 11.0 git (I think it was the same with 
10.0 git), here. (See below.)
So I can't compile Mesa git (20.0) with '-Dopencl-spirv=true' since 
November (15.11.2019).


Now, need some sleep. Our son has 12th birthday ;-)

-Dieter

[1667/3104] Building CXX object 
projects/SPIRV-L...eFiles/LLVMSPIRVLib.dir/LLVMToSPIRVDbgTran.cpp.o
FAILED: 
projects/SPIRV-LLVM-Translator/lib/SPIRV/CMakeFiles/LLVMSPIRVLib.dir/LLVMToSPIRVDbgTran.cpp.o
/usr/bin/c++  -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Iprojects/SPIRV-LLVM-Translator/lib/SPIRV 
-I/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV 
-I/usr/include/libxml2 -Iinclude -I/opt/llvm-project/llvm/include 
-I/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/include 
-I/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/libSPIRV 
-I/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/Mangler 
-fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long 
-Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess 
-Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor 
-Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O3 
-DNDEBUG-fno-exceptions -std=c++14 -MD -MT 
projects/SPIRV-LLVM-Translator/lib/SPIRV/CMakeFiles/LLVMSPIRVLib.dir/LLVMToSPIRVDbgTran.cpp.o 
-MF 
projects/SPIRV-LLVM-Translator/lib/SPIRV/CMakeFiles/LLVMSPIRVLib.dir/LLVMToSPIRVDbgTran.cpp.o.d 
-o 
projects/SPIRV-LLVM-Translator/lib/SPIRV/CMakeFiles/LLVMSPIRVLib.dir/LLVMToSPIRVDbgTran.cpp.o 
-c 
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp: 
In member function ‘SPIRV::SPIRVEntry* 
SPIRV::LLVMToSPIRVDbgTran::transDbgBaseType(const llvm::DIBasicType*)’:
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp:475:43: 
error: cannot convert ‘llvm::StringRef’ to ‘const string&’ {aka ‘const 
std::__cxx11::basic_string&’}

  475 |   Ops[NameIdx] = BM->getString(BT->getName())->getId();
  |~~~^~
  |   |
  |   llvm::StringRef
In file included from 
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.h:42,
 from 
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp:38:
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/libSPIRV/SPIRVModule.h:184:53: 
note:   initializing argument 1 of ‘virtual SPIRV::SPIRVString* 
SPIRV::SPIRVModule::getString(const string&)’

  184 |   virtual SPIRVString *getString(const std::string ) = 0;
  |  ~~~^~~
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp: 
In member function ‘SPIRV::SPIRVEntry* 
SPIRV::LLVMToSPIRVDbgTran::transDbgTypeDef(const llvm::DIDerivedType*)’:
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp:538:43: 
error: cannot convert ‘llvm::StringRef’ to ‘const string&’ {aka ‘const 
std::__cxx11::basic_string&’}

  538 |   Ops[NameIdx] = BM->getString(DT->getName())->getId();
  |~~~^~
  |   |
  |   llvm::StringRef
In file included from 
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.h:42,
 from 
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp:38:
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/libSPIRV/SPIRVModule.h:184:53: 
note:   initializing argument 1 of ‘virtual SPIRV::SPIRVString* 
SPIRV::SPIRVModule::getString(const string&)’

  184 |   virtual SPIRVString *getString(const std::string ) = 0;
  |  ~~~^~~
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp: 
In member function ‘SPIRV::SPIRVEntry* 
SPIRV::LLVMToSPIRVDbgTran::transDbgEnumType(const 
llvm::DICompositeType*)’:
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/LLVMToSPIRVDbgTran.cpp:582:43: 
error: cannot convert ‘llvm:

Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened

[Dieter Nützel]

Maybe compilation with '-Dopencl-spirv=true', again.

It is broken, now.
Even LLVM 10.0 won't compile for me with SPIRV-LLVM-Translator, 
currently.


Greetings,
Dieter

Am 22.01.2020 19:27, schrieb Dylan Baker:
Hi list, due to some last minute changes in plan I'll be managing the 
20.0
release. The release calendar has been updated, but the gitlab 
milestone wasn't

opened. That has been corrected, and is here
https://gitlab.freedesktop.org/mesa/mesa/-/milestones/9, please add any 
issues

or MRs you would like to land before the branchpoint to the milestone.

Thanks,
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] [radeonsi] enable OpenGL 4.6

[Dieter Nützel]

Hello Marek and Pierre-Eric,

GREAT work but this time I'm to stupid (tired).
I only 'see' 4.5. - E.g. that R600_DEBUG/AMD_DEBUG=nir is set.
Was at the dentist yesterday...

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1142033-amd-s-radeonsi-driver-finally-enables-opengl-4-6-but-you-need-to-first-enable-nir?p=1142054#post1142054

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

Re: [Mesa-dev] LLVM + SPIRV-LLVM-Translator - compilation errors

[Dieter Nützel]

Am 15.11.2019 03:27, schrieb Karol Herbst:

might be that those definitions moved elsewhere or the headers were
never directly included.

In llvm 9 there are in llvm/InitializePasses.h, but maybe that's
changed? And if not, maybe that file needs to be included in
SPIRVLowerSPIRBlocks.cpp?


Thank you Karol for your fast reply.
I'll try tomorrow or one day after. - If no one beat me.
I need badly some sleep and on Saturday our brave daughter has her first 
end-of-course dance with us...;-)


Greetings,
Dieter

On Fri, Nov 15, 2019 at 2:34 AM Dieter Nützel  
wrote:


Hello Karol and Ilya,

do you have any hints/pointers for me to solve these LLVM +
SPIRV-LLVM-Translator - compilation errors.

llvm-project git taken 'today'.

[-]
commit 95c770fbfb14b07e1af7c2d427c16745617d9f1f (HEAD -> master,
origin/master, origin/HEAD)
Author: Davide Italiano 
Date:   Thu Nov 14 15:29:28 2019 -0800

 [Utility] Remove a dead header [PPC64LE_ehframe_Registers.h]
[-]

opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVLowerSPIRBlocks.cpp:617:1:
note: in expansion of macro ‘INITIALIZE_PASS_DEPENDENCY’
   617 | INITIALIZE_PASS_DEPENDENCY(CallGraphWrapperPass)
   | ^~
/opt/llvm-project/llvm/include/llvm/PassSupport.h:50:45: error:
‘initializeAssumptionCacheTrackerPass’ was not declared in this scope
50 | #define INITIALIZE_PASS_DEPENDENCY(
initialize##depName##Pass(Registry);
   | ^~
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVLowerSPIRBlocks.cpp:618:1:
note: in expansion of macro ‘INITIALIZE_PASS_DEPENDENCY’
   618 | INITIALIZE_PASS_DEPENDENCY(AssumptionCacheTracker)
   | ^~
/opt/llvm-project/llvm/include/llvm/PassSupport.h:50:45: error:
‘initializeAAResultsWrapperPassPass’ was not declared in this scope
50 | #define INITIALIZE_PASS_DEPENDENCY(depName)
initialize##depName##Pass(Registry);
   | ^~
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVLowerSPIRBlocks.cpp:619:1:
note: in expansion of macro ‘INITIALIZE_PASS_DEPENDENCY’
   619 | INITIALIZE_PASS_DEPENDENCY(AAResultsWrapperPass)
   | ^~


Thank you very much in advance.
Dieter


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

[Mesa-dev] LLVM + SPIRV-LLVM-Translator - compilation errors

[Dieter Nützel]

Hello Karol and Ilya,

do you have any hints/pointers for me to solve these LLVM + 
SPIRV-LLVM-Translator - compilation errors.


llvm-project git taken 'today'.

[-]
commit 95c770fbfb14b07e1af7c2d427c16745617d9f1f (HEAD -> master, 
origin/master, origin/HEAD)

Author: Davide Italiano 
Date:   Thu Nov 14 15:29:28 2019 -0800

[Utility] Remove a dead header [PPC64LE_ehframe_Registers.h]
[-]

opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVLowerSPIRBlocks.cpp:617:1: 
note: in expansion of macro ‘INITIALIZE_PASS_DEPENDENCY’

  617 | INITIALIZE_PASS_DEPENDENCY(CallGraphWrapperPass)
  | ^~
/opt/llvm-project/llvm/include/llvm/PassSupport.h:50:45: error: 
‘initializeAssumptionCacheTrackerPass’ was not declared in this scope
   50 | #define INITIALIZE_PASS_DEPENDENCY(depName) 
initialize##depName##Pass(Registry);

  | ^~
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVLowerSPIRBlocks.cpp:618:1: 
note: in expansion of macro ‘INITIALIZE_PASS_DEPENDENCY’

  618 | INITIALIZE_PASS_DEPENDENCY(AssumptionCacheTracker)
  | ^~
/opt/llvm-project/llvm/include/llvm/PassSupport.h:50:45: error: 
‘initializeAAResultsWrapperPassPass’ was not declared in this scope
   50 | #define INITIALIZE_PASS_DEPENDENCY(depName) 
initialize##depName##Pass(Registry);

  | ^~
/opt/llvm-project/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVLowerSPIRBlocks.cpp:619:1: 
note: in expansion of macro ‘INITIALIZE_PASS_DEPENDENCY’

  619 | INITIALIZE_PASS_DEPENDENCY(AAResultsWrapperPass)
  | ^~


Thank you very much in advance.
Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Is libdrm-2.4.100 released or not?

[Dieter Nützel]

Asking about this one:

ac: get tcc_harvested from the kernel
commit  9edcce2a32ed872fef3167258ad2ae4952ca4c60

[-]
-_drm_amdgpu_ver = '2.4.99'
+_drm_amdgpu_ver = '2.4.100'
[-]

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

Re: [Mesa-dev] [Nine] 'meson: add -Werror=empty-body to disallow `if(x); `' - 'broke' Nine

[Dieter Nützel]

Am 24.10.2019 16:34, schrieb Dieter Nützel:

Hello Eric,

your mentioned commit (8d43e2b2ded0fe3c82d49561cdab9f208f9e64b6) broke
building with NIne (-Dgallium-nine=true) for me.

starting with
[-]


[-]

Back on this:

Thanks guys!

All fine, now.

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

[Mesa-dev] [Nine] 'meson: add -Werror=empty-body to disallow `if(x); `' - 'broke' Nine

[Dieter Nützel]

Hello Eric,

your mentioned commit (8d43e2b2ded0fe3c82d49561cdab9f208f9e64b6) broke 
building with NIne (-Dgallium-nine=true) for me.


starting with
[-]
e_st@sta/cubetexture9.c.o' -c 
../src/gallium/state_trackers/nine/cubetexture9.c
../src/gallium/state_trackers/nine/cubetexture9.c: In function 
‘NineCubeTexture9_ctor’:
../src/gallium/state_trackers/nine/cubetexture9.c:108:43: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

  108 | "but this is unimplemented\n");
  |   ^
cc1: some warnings being treated as errors

--
Next

/surface9.c.o' -c ../src/gallium/state_trackers/nine/surface9.c
../src/gallium/state_trackers/nine/surface9.c: In function 
‘NineSurface9_GetContainer’:
../src/gallium/state_trackers/nine/surface9.c:334:40: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

  334 | DBG("QueryInterface FAILED!\n");
  |^
cc1: some warnings being treated as errors

--

@sta/swapchain9.c.o' -c ../src/gallium/state_trackers/nine/swapchain9.c
../src/gallium/state_trackers/nine/swapchain9.c: In function ‘present’:
../src/gallium/state_trackers/nine/swapchain9.c:737:51: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

  737 | pSourceRect->top, pSourceRect->bottom);
  |   ^
../src/gallium/state_trackers/nine/swapchain9.c:741:47: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

  741 | pDestRect->top, pDestRect->bottom);
  |   ^
cc1: some warnings being treated as errors

--

evice9.c.o' -c ../src/gallium/state_trackers/nine/device9.c
../src/gallium/state_trackers/nine/device9.c: In function 
‘NineDevice9_ctor’:
../src/gallium/state_trackers/nine/device9.c:296:49: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

  296 | DBG("\033[1;32mCSMT is active\033[0m\n");
  | ^
../src/gallium/state_trackers/nine/device9.c: In function 
‘create_zs_or_rt_surface’:
../src/gallium/state_trackers/nine/device9.c:1221:87: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]
 1221 |   DBG("FIXME Used shared handle! This option isn't probably 
handled correctly!\n");
  |  
 ^
../src/gallium/state_trackers/nine/device9.c: In function 
‘NineDevice9_UpdateSurface’:
../src/gallium/state_trackers/nine/device9.c:1307:53: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

 1307 | pSourceRect->right, pSourceRect->bottom);
  | ^
../src/gallium/state_trackers/nine/device9.c:1309:68: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]
 1309 | DBG("pDestPoint = (%u,%u)\n", pDestPoint->x, 
pDestPoint->y);
  |  
  ^
../src/gallium/state_trackers/nine/device9.c: In function 
‘NineDevice9_StretchRect’:
../src/gallium/state_trackers/nine/device9.c:1588:53: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

 1588 | pSourceRect->right, pSourceRect->bottom);
  | ^
../src/gallium/state_trackers/nine/device9.c:1591:49: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

 1591 | pDestRect->right, pDestRect->bottom);
  | ^
../src/gallium/state_trackers/nine/device9.c: In function 
‘NineDevice9_ColorFill’:
../src/gallium/state_trackers/nine/device9.c:1786:41: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

 1786 | pRect->right, pRect->bottom);
  | ^
../src/gallium/state_trackers/nine/device9.c: In function 
‘NineDevice9_CreateOffscreenPlainSurface’:
../src/gallium/state_trackers/nine/device9.c:1864:43: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

 1864 | DBG("Failed to create surface.\n");
  |   ^
cc1: some warnings being treated as errors

--

st@sta/nine_shader.c.o' -c 
../src/gallium/state_trackers/nine/nine_shader.c
../src/gallium/state_trackers/nine/nine_shader.c: In function 
‘tx_dst_param_as_src’:
../src/gallium/state_trackers/nine/nine_shader.c:1437:52: error: suggest 
braces around empty body in an ‘if’ statement [-Werror=empty-body]

 1437 | WARN("mask is 0, using identity swizzle\n");
  |

--
Last

ine_ff.c.o' -c ../src/gallium/state_trackers/nine/nine_ff.c

Re: [Mesa-dev] [radeonsi] Clover broken after new 'nir_serialize'

[Dieter Nützel]

You speedy man!

Yes, tested and works.

Thank you.

Dieter

Am 11.10.2019 00:45, schrieb Marek Olšák:

It should be fixed now.

Marek

On Thu, Oct 10, 2019 at 6:42 PM Marek Olšák 
wrote:


Hi,

Sorry for the breakage. I guess it's a recently added file, because
I didn't see it in my IDE.

Marek

On Thu, Oct 10, 2019 at 6:27 PM Dieter Nützel
 wrote:


Hello Marek,

forgotten to update Clover?

Greetings,
Dieter

[1261/1386] Compiling C++ object
'src/gallium/st...clover/ae4504a@@clnir@sta/nir_invocation.cpp.o'.
FAILED:




src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o

ccache c++ -Isrc/gallium/state_trackers/clover/ae4504a@@clnir@sta
-Isrc/gallium/state_trackers/clover
-I../src/gallium/state_trackers/clover -Iinclude -I../include
-Isrc
-I../src -I../src/gallium/include -Isrc/gallium/auxiliary
-I../src/gallium/auxiliary -Isrc/mesa -I../src/mesa
-Isrc/compiler/nir
-I../src/compiler/nir -fdiagnostics-color=always -DNDEBUG -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor
-std=c++14
-O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="19.3.0-devel"'




'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/issues;'


-DUSE_ELF_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM
-DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM
-DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
-DHAVE___BUILTIN_BSWAP64
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
-DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS
-DHAVE___BUILTIN_FFSLL
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT
-DHAVE_FUNC_ATTRIBUTE_WEAK
-DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED
-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN
-DHAVE_UINT128 -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS

-DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H
-DHAVE_EXECINFO_H
-DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
-DHAVE_POSIX_MEMALIGN -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE
-DHAVE_RANDOM_R -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_STRTOD_L
-DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DLLVM_AVAILABLE
'-DMESA_LLVM_VERSION_STRING="10.0.0"' -DUSE_LIBGLVND=1
-DHAVE_LIBUNWIND
-DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_LIBSENSORS=1
-Werror=return-type -Werror=format -Wformat-security
-Wno-non-virtual-dtor -Wno-missing-field-initializers
-Wno-format-truncation -fno-math-errno -fno-trapping-math -fPIC
-DHAVE_CLOVER_SPIRV -fvisibility=hidden -MD -MQ




'src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o'


-MF




'src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o.d'


-o




'src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o'


-c ../src/gallium/state_trackers/clover/nir/invocation.cpp
../src/gallium/state_trackers/clover/nir/invocation.cpp: In
function
‘clover::module clover::nir::spirv_to_nir(const clover::module&,
const
clover::device&, std::string&)’:
../src/gallium/state_trackers/clover/nir/invocation.cpp:146:31:
error:
too few arguments to function ‘void nir_serialize(blob*, const
nir_shader*, bool)’
146 |   nir_serialize(, nir);
|   ^
In file included from
../src/gallium/state_trackers/clover/nir/invocation.cpp:34:
../src/compiler/nir/nir_serialize.h:34:6: note: declared here
34 | void nir_serialize(struct blob *blob, const nir_shader
*nir,
bool strip);
|  ^
[1270/1386] Compiling C++ object
'src/gallium/st...over/ae4504a@@clllvm@sta/llvm_invocation.cpp.o'.
ninja: build stopped: subcommand failed.

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

[Mesa-dev] [radeonsi] Clover broken after new 'nir_serialize'

[Dieter Nützel]

Hello Marek,

forgotten to update Clover?

Greetings,
Dieter

[1261/1386] Compiling C++ object 
'src/gallium/st...clover/ae4504a@@clnir@sta/nir_invocation.cpp.o'.
FAILED: 
src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o
ccache c++ -Isrc/gallium/state_trackers/clover/ae4504a@@clnir@sta 
-Isrc/gallium/state_trackers/clover 
-I../src/gallium/state_trackers/clover -Iinclude -I../include -Isrc 
-I../src -I../src/gallium/include -Isrc/gallium/auxiliary 
-I../src/gallium/auxiliary -Isrc/mesa -I../src/mesa -Isrc/compiler/nir 
-I../src/compiler/nir -fdiagnostics-color=always -DNDEBUG -pipe 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++14 
-O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="19.3.0-devel"' 
'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/issues;' 
-DUSE_ELF_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING 
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM 
-DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ 
-DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL 
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL 
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST 
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC 
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED 
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK 
-DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED 
-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_VISIBILITY 
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN 
-DHAVE_UINT128 -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS 
-DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H 
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_EXECINFO_H 
-DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_STRTOF -DHAVE_MKOSTEMP 
-DHAVE_POSIX_MEMALIGN -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE 
-DHAVE_RANDOM_R -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_STRTOD_L 
-DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD 
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DLLVM_AVAILABLE 
'-DMESA_LLVM_VERSION_STRING="10.0.0"' -DUSE_LIBGLVND=1 -DHAVE_LIBUNWIND 
-DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_LIBSENSORS=1 
-Werror=return-type -Werror=format -Wformat-security 
-Wno-non-virtual-dtor -Wno-missing-field-initializers 
-Wno-format-truncation -fno-math-errno -fno-trapping-math -fPIC 
-DHAVE_CLOVER_SPIRV -fvisibility=hidden -MD -MQ 
'src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o' 
-MF 
'src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o.d' 
-o 
'src/gallium/state_trackers/clover/ae4504a@@clnir@sta/nir_invocation.cpp.o' 
-c ../src/gallium/state_trackers/clover/nir/invocation.cpp
../src/gallium/state_trackers/clover/nir/invocation.cpp: In function 
‘clover::module clover::nir::spirv_to_nir(const clover::module&, const 
clover::device&, std::string&)’:
../src/gallium/state_trackers/clover/nir/invocation.cpp:146:31: error: 
too few arguments to function ‘void nir_serialize(blob*, const 
nir_shader*, bool)’

  146 |   nir_serialize(, nir);
  |   ^
In file included from 
../src/gallium/state_trackers/clover/nir/invocation.cpp:34:

../src/compiler/nir/nir_serialize.h:34:6: note: declared here
   34 | void nir_serialize(struct blob *blob, const nir_shader *nir, 
bool strip);

  |  ^
[1270/1386] Compiling C++ object 
'src/gallium/st...over/ae4504a@@clllvm@sta/llvm_invocation.cpp.o'.

ninja: build stopped: subcommand failed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [clover/spirv] radeonsi/NIR (with Nine) - final linking failed on libOpenCL.so.1.0.0

[Dieter Nützel]

Sorry Aaron,

that I haven't had the time to save you some time...

I've only set CFLAGS="-fPIC" and CXXFLAGS="-fPIC"
and run

cmake ..
make llvm-spirv -j`nproc`

And could rebuild mesa with -Dopencl-spirv=true 
-Dgallium-opencl=standalone


Only old luxmark-linux64-v2.0 (scene 'LuxBall Sky') show corruption with 
_both_ libOpenCL versions (with and _without_ spirv functionality).


@Karol
Do you suggest any special tests?

Thanks,
Dieter


Am 30.09.2019 02:39, schrieb Aaron Watry:

Yup.

I thought I had tried to do that, but I probably messed it up.  I just
ran the following for the spirv translator and was able to rebuild
mesa with the spirv functionality enabled:
mkdir build
cd build
CFLAGS="-fPIC" CXXFLAGS="-fPIC" LDFLAGS="-fPIC" ccmake ../
CFLAGS="-fPIC" CXXFLAGS="-fPIC" LDFLAGS="-fPIC" make -j && sudo make 
install



On Thu, Sep 26, 2019 at 2:34 AM Karol Herbst  
wrote:


I think you only need to recompile the translator with -fPIC enabled.
At least that's what the error is saying.

On Thu, Sep 26, 2019 at 6:53 AM Aaron Watry  wrote:
>
> Pretty sure I'm running into the same thing trying to build clover
> with llvm-spirv enabled.  If it's a known solution, I wouldn't mind
> having some time saved :)
>
> --Aaron
>
> On Wed, Sep 25, 2019 at 10:30 AM Dieter Nützel  wrote:
> >
> > Hello Karol and Pierre,
> >
> > tried it on radeonsi/NIR with Nine and OpenCL enabled
> > (-Dgallium-nine=true -Dopencl-spirv=true -Dgallium-opencl=standalone).
> >
> > I think I have all SPIRV-LLVM-Translator stuff in place
> > (/opt/llvm/projects/SPIRV-LLVM-Translator/). Resulting lib is installed
> > at /usr/local/lib/libLLVMSPIRVLib.a.
> >
> > Do I need a shared version (*.so ) of it? 'ld' output point at this
> > (relocation R_X86_64_32 against symbol `_ZTVN4SPIR13PrimitiveTypeE' can
> > not be used when making a shared object; recompile with -fPIC).
> >
> > Thanks,
> > Dieter
> >
> > [1384/1384] Linking target
> > src/gallium/targets/opencl/libOpenCL.so.1.0.0.
> > FAILED: src/gallium/targets/opencl/libOpenCL.so.1.0.0
> > ccache c++  -o src/gallium/targets/opencl/libOpenCL.so.1.0.0
> > -Wl,--no-undefined -Wl,--as-needed -Wl,-O1 -shared -fPIC
> > -Wl,--start-group -Wl,-soname,libOpenCL.so.1 -Wl,--whole-archive
> > src/gallium/state_trackers/clover/libclover.a -Wl,--no-whole-archive
> > src/gallium/auxiliary/pipe-loader/libpipe_loader_dynamic.a
> > src/loader/libloader.a src/util/libxmlconfig.a src/util/libmesa_util.a
> > src/gallium/auxiliary/libgallium.a src/compiler/nir/libnir.a
> > src/compiler/libcompiler.a src/gallium/state_trackers/clover/libclllvm.a
> > src/gallium/state_trackers/clover/libclspirv.a
> > src/gallium/state_trackers/clover/libclnir.a -Wl,--gc-sections
> > -Wl,--version-script /opt/mesa/src/gallium/targets/opencl/opencl.sym
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libz.so -pthread
> > -lm -ldl /usr/lib64/libunwind.so /usr/lib64/libelf.so
> > /usr/local/lib/libclangCodeGen.a /usr/local/lib/libclangFrontendTool.a
> > /usr/local/lib/libclangFrontend.a /usr/local/lib/libclangDriver.a
> > /usr/local/lib/libclangSerialization.a /usr/local/lib/libclangParse.a
> > /usr/local/lib/libclangSema.a /usr/local/lib/libclangAnalysis.a
> > /usr/local/lib/libclangAST.a /usr/local/lib/libclangASTMatchers.a
> > /usr/local/lib/libclangEdit.a /usr/local/lib/libclangLex.a
> > /usr/local/lib/libclangBasic.a /usr/lib64/libdrm.so
> > /usr/lib64/libexpat.so -L/usr/local/lib -lLLVM-10svn -lsensors
> > -L/usr/local/lib -lLLVM-10svn /usr/local/lib/libLLVMSPIRVLib.a
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libSPIRV-Tools.so
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libSPIRV-Tools-link.so
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libSPIRV-Tools-opt.so
> > -Wl,--end-group
> > 
'-Wl,-rpath,$ORIGIN/../../auxiliary/pipe-loader:$ORIGIN/../../../loader:$ORIGIN/../../../util:$ORIGIN/../../auxiliary:$ORIGIN/../../../compiler/nir:$ORIGIN/../../../compiler'
> > -Wl,-rpath-link,/opt/mesa/build/src/gallium/auxiliary/pipe-loader
> > -Wl,-rpath-link,/opt/mesa/build/src/loader
> > -Wl,-rpath-link,/opt/mesa/build/src/util
> > -Wl,-rpath-link,/opt/mesa/build/src/gallium/auxiliary
> > -Wl,-rpath-link,/opt/mesa/build/src/compiler/nir
> > -Wl,-rpath-link,/opt/mesa/build/src/compiler
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> > /usr/local/lib/libLLVMSPIRVLib.a(SPIRVWriter.cpp.o): relocation
> > R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not
> > be used when making a shared object; r

[Mesa-dev] [clover/spirv] radeonsi/NIR (with Nine) - final linking failed on libOpenCL.so.1.0.0

[Dieter Nützel]

Hello Karol and Pierre,

tried it on radeonsi/NIR with Nine and OpenCL enabled 
(-Dgallium-nine=true -Dopencl-spirv=true -Dgallium-opencl=standalone).


I think I have all SPIRV-LLVM-Translator stuff in place 
(/opt/llvm/projects/SPIRV-LLVM-Translator/). Resulting lib is installed 
at /usr/local/lib/libLLVMSPIRVLib.a.


Do I need a shared version (*.so ) of it? 'ld' output point at this 
(relocation R_X86_64_32 against symbol `_ZTVN4SPIR13PrimitiveTypeE' can 
not be used when making a shared object; recompile with -fPIC).


Thanks,
Dieter

[1384/1384] Linking target 
src/gallium/targets/opencl/libOpenCL.so.1.0.0.

FAILED: src/gallium/targets/opencl/libOpenCL.so.1.0.0
ccache c++  -o src/gallium/targets/opencl/libOpenCL.so.1.0.0  
-Wl,--no-undefined -Wl,--as-needed -Wl,-O1 -shared -fPIC 
-Wl,--start-group -Wl,-soname,libOpenCL.so.1 -Wl,--whole-archive 
src/gallium/state_trackers/clover/libclover.a -Wl,--no-whole-archive 
src/gallium/auxiliary/pipe-loader/libpipe_loader_dynamic.a 
src/loader/libloader.a src/util/libxmlconfig.a src/util/libmesa_util.a 
src/gallium/auxiliary/libgallium.a src/compiler/nir/libnir.a 
src/compiler/libcompiler.a src/gallium/state_trackers/clover/libclllvm.a 
src/gallium/state_trackers/clover/libclspirv.a 
src/gallium/state_trackers/clover/libclnir.a -Wl,--gc-sections 
-Wl,--version-script /opt/mesa/src/gallium/targets/opencl/opencl.sym 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libz.so -pthread 
-lm -ldl /usr/lib64/libunwind.so /usr/lib64/libelf.so 
/usr/local/lib/libclangCodeGen.a /usr/local/lib/libclangFrontendTool.a 
/usr/local/lib/libclangFrontend.a /usr/local/lib/libclangDriver.a 
/usr/local/lib/libclangSerialization.a /usr/local/lib/libclangParse.a 
/usr/local/lib/libclangSema.a /usr/local/lib/libclangAnalysis.a 
/usr/local/lib/libclangAST.a /usr/local/lib/libclangASTMatchers.a 
/usr/local/lib/libclangEdit.a /usr/local/lib/libclangLex.a 
/usr/local/lib/libclangBasic.a /usr/lib64/libdrm.so 
/usr/lib64/libexpat.so -L/usr/local/lib -lLLVM-10svn -lsensors 
-L/usr/local/lib -lLLVM-10svn /usr/local/lib/libLLVMSPIRVLib.a 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libSPIRV-Tools.so 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libSPIRV-Tools-link.so 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/libSPIRV-Tools-opt.so 
-Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../../auxiliary/pipe-loader:$ORIGIN/../../../loader:$ORIGIN/../../../util:$ORIGIN/../../auxiliary:$ORIGIN/../../../compiler/nir:$ORIGIN/../../../compiler' 
-Wl,-rpath-link,/opt/mesa/build/src/gallium/auxiliary/pipe-loader 
-Wl,-rpath-link,/opt/mesa/build/src/loader 
-Wl,-rpath-link,/opt/mesa/build/src/util 
-Wl,-rpath-link,/opt/mesa/build/src/gallium/auxiliary 
-Wl,-rpath-link,/opt/mesa/build/src/compiler/nir 
-Wl,-rpath-link,/opt/mesa/build/src/compiler
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(SPIRVWriter.cpp.o): relocation 
R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not 
be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(PreprocessMetadata.cpp.o): relocation 
R_X86_64_32 against `.rodata' can not be used when making a shared 
object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(SPIRVDebug.cpp.o): relocation 
R_X86_64_32 against `.bss' can not be used when making a shared object; 
recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(SPIRVDecorate.cpp.o): relocation 
R_X86_64_32 against symbol `_ZTVN5SPIRV20SPIRVDecorateGenericE' can not 
be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(SPIRVEntry.cpp.o): relocation 
R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not 
be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(SPIRVFunction.cpp.o): relocation 
R_X86_64_32 against symbol `_ZTVN5SPIRV22SPIRVFunctionParameterE' can 
not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(SPIRVInstruction.cpp.o): relocation 
R_X86_64_32 against symbol `_ZTVN5SPIRV16SPIRVInstructionE' can not be 
used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/usr/local/lib/libLLVMSPIRVLib.a(SPIRVModule.cpp.o): relocation 
R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not 
be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 

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

[Dieter Nützel]

Thank you Marek and Pierre-Eric,

with

'radeonsi: allocate and resize global_buffers as needed'

Clover OpenCL works with Blender, now.

My patch is obsolete with it.

Great.

Dieter

Am 08.08.2019 18:36, schrieb 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

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

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

[Dieter Nützel]

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,
DieterFrom 9c3bd0c4c51452a8b1fd278006ef51feed055864 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dieter=20N=C3=BCtzel?= 
Date: Wed, 7 Aug 2019 04:33:57 +0200
Subject: [PATCH] radeonsi: Bump number of allowed global buffers to 48
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Dieter Nützel 
---
 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 86021178533..5a9be612104 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 32
+#define MAX_GLOBAL_BUFFERS 48
 
 struct si_compute {
 	struct si_shader_selector sel;
-- 
2.22.0

___
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

[Dieter Nützel]

Back from vacation try to bring all stuff on par - LLVM 10 (with Clover) 
- and boom...


Acked-by: Dieter Nützel 
Tested-by: Dieter Nützel 

Thank you Jan!

Dieter

Am 06.08.2019 19:59, schrieb 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

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

Re: [Mesa-dev] radeonsi: glmark2 - regression (GL_INVALID_OPERATION in glFramebufferTexture2D) - bisected

[Dieter Nützel]

Hello Emil et al.,

sorry Emil you were NOT the right person to blame for this - see below.

Am 22.06.2019 04:55, schrieb Dieter Nützel:

Hello Emil,

I see glmark2 - [desktop] blur-radius=5

libpng warning: iCCP: known incorrect sRGB profile
Mesa: User error: GL_INVALID_OPERATION in
glFramebufferTexture2D(window-system framebuffer)
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 4879 FrameTime: 0.205 ms

after your commits around beginning of June (2019-06-05) or your
'mapi'-work commited around 2019-06-10.


I had to go much further back...


Have to bisect.


Did it, now. Hello Marek and Mathias ;-)

/opt/mesa> git bisect good
b5697c311b6f29dee40b96c48bad3279e3667c1e is the first bad commit
commit b5697c311b6f29dee40b96c48bad3279e3667c1e
Author: Marek Olšák 
Date:   Thu May 9 21:04:23 2019 -0400

Change a few frequented uses of DEBUG to !NDEBUG

debugoptimized builds don't define NDEBUG, but they also don't 
define

DEBUG. We want to enable cheap debug code for these builds.
I only chose those occurences that I care about.

Reviewed-by: Mathias Fröhlich 

 src/gallium/auxiliary/tgsi/tgsi_ureg.c  | 2 +-
 src/gallium/drivers/radeonsi/si_descriptors.c   | 2 +-
 src/gallium/drivers/radeonsi/si_pipe.h  | 2 +-
 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 6 +++---
 src/gallium/drivers/radeonsi/si_state.c | 4 ++--
 src/mesa/main/context.c | 2 +-
 src/mesa/main/debug.c   | 4 ++--
 src/mesa/main/errors.c  | 6 +++---
 src/mesa/main/feedback.c| 2 +-
 src/mesa/main/formats.c | 2 --
 src/mesa/main/imports.c | 4 ++--
 src/mesa/main/mtypes.h  | 2 +-
 src/mesa/main/shaderapi.c   | 2 +-
 src/mesa/state_tracker/st_atom_framebuffer.c| 2 +-
 src/mesa/state_tracker/st_format.c  | 2 +-
 src/mesa/vbo/vbo_exec.h | 2 +-
 src/mesa/vbo/vbo_exec_api.c | 6 +++---
 src/util/slab.c | 4 ++--
 18 files changed, 27 insertions(+), 29 deletions(-)

After reverting this all is fine, again.

My meson config for Mesa git:
meson ../ --strip --buildtype debugoptimized -Ddri-drivers= 
-Dplatforms=drm,x11 -Dgallium-drivers=r600,radeonsi,swrast 
-Dvulkan-drivers=amd -Dgallium-nine=true -Dgallium-opencl=standalone 
-Dglvnd=true -Dgallium-va=false -Dgallium-xvmc=false 
-Dgallium-omx=disabled -Dgallium-xa=false


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

Re: [Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)

[Dieter Nützel]

t-b

Dieter

Am 25.06.2019 02:12, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/mesa/state_tracker/st_cb_drawpixels.c | 58 +++
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 59868d3ff1d..26d3cc33e5c 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1508,35 +1508,35 @@ static GLboolean
 blit_copy_pixels(struct gl_context *ctx, GLint srcx, GLint srcy,
  GLsizei width, GLsizei height,
  GLint dstx, GLint dsty, GLenum type)
 {
struct st_context *st = st_context(ctx);
struct pipe_context *pipe = st->pipe;
struct pipe_screen *screen = pipe->screen;
struct gl_pixelstore_attrib pack, unpack;
GLint readX, readY, readW, readH, drawX, drawY, drawW, drawH;

-   if (type == GL_COLOR &&
-   ctx->Pixel.ZoomX == 1.0 &&
+   if (ctx->Pixel.ZoomX == 1.0 &&
ctx->Pixel.ZoomY == 1.0 &&
-   ctx->_ImageTransferState == 0x0 &&
-   !ctx->Color.BlendEnabled &&
-   !ctx->Color.AlphaEnabled &&
-   (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp == 
GL_COPY) &&

-   !ctx->Depth.Test &&
-   !ctx->Fog.Enabled &&
-   !ctx->Stencil.Enabled &&
-   !ctx->FragmentProgram.Enabled &&
-   !ctx->VertexProgram.Enabled &&
-   !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
-   !_mesa_ati_fragment_shader_enabled(ctx) &&
-   ctx->DrawBuffer->_NumColorDrawBuffers == 1 &&
+   (type != GL_COLOR ||
+(ctx->_ImageTransferState == 0x0 &&
+ !ctx->Color.BlendEnabled &&
+ !ctx->Color.AlphaEnabled &&
+ (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp == 
GL_COPY) &&

+ !ctx->Depth.Test &&
+ !ctx->Fog.Enabled &&
+ !ctx->Stencil.Enabled &&
+ !ctx->FragmentProgram.Enabled &&
+ !ctx->VertexProgram.Enabled &&
+ !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
+ !_mesa_ati_fragment_shader_enabled(ctx) &&
+ ctx->DrawBuffer->_NumColorDrawBuffers == 1)) &&
!ctx->Query.CondRenderQuery &&
!ctx->Query.CurrentOcclusionObject) {
   struct st_renderbuffer *rbRead, *rbDraw;

   /*
* Clip the read region against the src buffer bounds.
* We'll still allocate a temporary buffer/texture for the 
original
* src region size but we'll only read the region which is 
on-screen.
* This may mean that we draw garbage pixels into the dest 
region, but

* that's expected.
@@ -1555,22 +1555,32 @@ blit_copy_pixels(struct gl_context *ctx, GLint
srcx, GLint srcy,
   unpack = pack;
   if (!_mesa_clip_drawpixels(ctx, , , , , 
))

  return GL_TRUE; /* all done */

   readX = readX - pack.SkipPixels + unpack.SkipPixels;
   readY = readY - pack.SkipRows + unpack.SkipRows;

   drawW = readW;
   drawH = readH;

-  rbRead = st_get_color_read_renderbuffer(ctx);
-  rbDraw = st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
+  if (type == GL_COLOR) {
+ rbRead = st_get_color_read_renderbuffer(ctx);
+ rbDraw = 
st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);

+  } else if (type == GL_DEPTH || type == GL_DEPTH_STENCIL) {
+ rbRead =
st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
+ rbDraw =
st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
+  } else if (type == GL_STENCIL) {
+ rbRead =
st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
+ rbDraw =
st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
+  } else {
+ return false;
+  }

   /* Flip src/dst position depending on the orientation of 
buffers. */

   if (st_fb_orientation(ctx->ReadBuffer) == Y_0_TOP) {
  readY = rbRead->Base.Height - readY;
  readH = -readH;
   }

   if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP) {
  /* We can't flip the destination for pipe->blit, so we only 
adjust

   * its position and flip the source.
@@ -1597,23 +1607,31 @@ blit_copy_pixels(struct gl_context *ctx, GLint
srcx, GLint srcy,
  blit.src.box.depth = 1;
  blit.dst.resource = rbDraw->texture;
  blit.dst.level = rbDraw->surface->u.tex.level;
  blit.dst.format = rbDraw->texture->format;
  blit.dst.box.x = drawX;
  blit.dst.box.y = drawY;
  blit.dst.box.z = rbDraw->surface->u.tex.first_layer;
  blit.dst.box.width = drawW;
  blit.dst.box.height = drawH;
  blit.dst.box.depth = 1;
- blit.mask = PIPE_MASK_RGBA;
  blit.filter = PIPE_TEX_FILTER_NEAREST;

+ if (type == GL_COLOR)
+blit.mask |= PIPE_MASK_RGBA;
+ if (type == GL_DEPTH)
+blit.mask |= PIPE_MASK_Z;
+ if (type == 

Re: [Mesa-dev] [PATCH 3/3] radeonsi: use a fragment shader blit instead of DB->CB copy for ZS CPU mappings

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

on Polaris 20, openSUSE Tumbleweed, KDE Plasma 5

Dieter

Am 21.06.2019 19:02, schrieb Marek Olšák:

From: Marek Olšák 

This mainly removes and simplifies code that is no longer needed.

There were some issues with the DB->CB stencil copy on gfx10, so let's
just use a fragment shader blit for all ZS mappings. It's more 
reliable.

---
 src/gallium/drivers/radeonsi/si_blit.c|  29 +---
 src/gallium/drivers/radeonsi/si_pipe.h|   9 +-
 src/gallium/drivers/radeonsi/si_state.c   |   2 +-
 src/gallium/drivers/radeonsi/si_texture.c | 166 +++---
 4 files changed, 52 insertions(+), 154 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index 5806342cca9..638f2ee4d24 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -173,45 +173,20 @@ si_blit_dbcb_copy(struct si_context *sctx,
}

sctx->decompression_enabled = false;
sctx->dbcb_depth_copy_enabled = false;
sctx->dbcb_stencil_copy_enabled = false;
si_mark_atom_dirty(sctx, >atoms.s.db_render_state);

return fully_copied_levels;
 }

-void si_blit_decompress_depth(struct pipe_context *ctx,
- struct si_texture *texture,
- struct si_texture *staging,
- unsigned first_level, unsigned last_level,
- unsigned first_layer, unsigned last_layer,
- unsigned first_sample, unsigned last_sample)
-{
-   const struct util_format_description *desc;
-   unsigned planes = 0;
-
-	assert(staging != NULL && "use si_blit_decompress_zs_in_place 
instead");

-
-   desc = util_format_description(staging->buffer.b.b.format);
-
-   if (util_format_has_depth(desc))
-   planes |= PIPE_MASK_Z;
-   if (util_format_has_stencil(desc))
-   planes |= PIPE_MASK_S;
-
-   si_blit_dbcb_copy(
-   (struct si_context *)ctx, texture, staging, planes,
-   u_bit_consecutive(first_level, last_level - first_level + 1),
-   first_layer, last_layer, first_sample, last_sample);
-}
-
 /* Helper function for si_blit_decompress_zs_in_place.
  */
 static void
 si_blit_decompress_zs_planes_in_place(struct si_context *sctx,
  struct si_texture *texture,
  unsigned planes, unsigned level_mask,
  unsigned first_layer, unsigned last_layer)
 {
struct pipe_surface *zsurf, surf_tmpl = {{0}};
unsigned layer, max_layer, checked_last_layer;
@@ -348,21 +323,21 @@ si_decompress_depth(struct si_context *sctx,
u_log_printf(sctx->log,
 
"\n\n"
 			 "Decompress Depth (levels %u - %u, levels Z: 0x%x S: 
0x%x)\n\n",

 first_level, last_level, levels_z, levels_s);

/* We may have to allocate the flushed texture here when called from
 * si_decompress_subresource.
 */
if (copy_planes &&
(tex->flushed_depth_texture ||
-	 si_init_flushed_depth_texture(>b, >buffer.b.b, 
NULL))) {

+si_init_flushed_depth_texture(>b, >buffer.b.b))) {
struct si_texture *dst = tex->flushed_depth_texture;
unsigned fully_copied_levels;
unsigned levels = 0;

assert(tex->flushed_depth_texture);

if (util_format_is_depth_and_stencil(dst->buffer.b.b.format))
copy_planes = PIPE_MASK_Z | PIPE_MASK_S;

if (copy_planes & PIPE_MASK_Z) {
@@ -1242,21 +1217,21 @@ static void si_blit(struct pipe_context *ctx,
assert(util_blitter_is_blit_supported(sctx->blitter, info));

/* The driver doesn't decompress resources automatically while
 * u_blitter is rendering. */
vi_disable_dcc_if_incompatible_format(sctx, info->src.resource,
  info->src.level,
  info->src.format);
vi_disable_dcc_if_incompatible_format(sctx, info->dst.resource,
  info->dst.level,
  info->dst.format);
-   si_decompress_subresource(ctx, info->src.resource, info->mask,
+   si_decompress_subresource(ctx, info->src.resource, PIPE_MASK_RGBAZS,
  info->src.level,
  info->src.box.z,
  info->src.box.z + info->src.box.depth - 1);

if (sctx->screen->debug_flags & DBG(FORCE_DMA) &&

[Mesa-dev] radeonsi: glmark2 - regression (GL_INVALID_OPERATION in glFramebufferTexture2D) since your work around 2019-06-05

[Dieter Nützel]

Hello Emil,

I see glmark2 - [desktop] blur-radius=5

libpng warning: iCCP: known incorrect sRGB profile
Mesa: User error: GL_INVALID_OPERATION in 
glFramebufferTexture2D(window-system framebuffer)
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: 
FPS: 4879 FrameTime: 0.205 ms


after your commits around beginning of June (2019-06-05) or your 
'mapi'-work commited around 2019-06-10.

Have to bisect.
Any hints/ideas for a good starting point?

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

Re: [Mesa-dev] [PATCH 8/8] radeonsi: rename and re-document cache flush flags

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

on Polaris 20

Except gfx10 stuff...;-)

Dieter

Am 20.06.2019 06:19, schrieb Marek Olšák:

From: Marek Olšák 

SMEM and VMEM caches are L0 on gfx10.
---
 src/gallium/drivers/radeonsi/si_compute.c |  2 +-
 .../drivers/radeonsi/si_compute_blit.c| 12 +++---
 src/gallium/drivers/radeonsi/si_descriptors.c |  2 +-
 src/gallium/drivers/radeonsi/si_gfx_cs.c  |  8 ++--
 src/gallium/drivers/radeonsi/si_pipe.c|  8 ++--
 src/gallium/drivers/radeonsi/si_pipe.h| 34 +
 src/gallium/drivers/radeonsi/si_state.c   | 14 +++
 src/gallium/drivers/radeonsi/si_state_draw.c  | 38 +--
 .../drivers/radeonsi/si_state_streamout.c |  6 +--
 .../drivers/radeonsi/si_test_dma_perf.c   |  6 +--
 10 files changed, 66 insertions(+), 64 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 7e5259b70a0..63c95ed2604 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -910,21 +910,21 @@ static void si_launch_grid(
/* Add buffer sizes for memory checking in need_cs_space. */
si_context_add_resource_size(sctx, >shader.bo->b.b);
/* TODO: add the scratch buffer */

if (info->indirect) {
si_context_add_resource_size(sctx, info->indirect);

/* Indirect buffers use TC L2 on GFX9, but not older hw. */
if (sctx->chip_class <= GFX8 &&
si_resource(info->indirect)->TC_L2_dirty) {
-   sctx->flags |= SI_CONTEXT_WRITEBACK_GLOBAL_L2;
+   sctx->flags |= SI_CONTEXT_WB_L2;
si_resource(info->indirect)->TC_L2_dirty = false;
}
}

si_need_gfx_cs_space(sctx);

if (sctx->bo_list_add_all_compute_resources)
si_compute_resources_add_all_to_bo_list(sctx);

if (!sctx->cs_shader_state.initialized) {
diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c
b/src/gallium/drivers/radeonsi/si_compute_blit.c
index 1cfdc9b62c6..4c5464ac118 100644
--- a/src/gallium/drivers/radeonsi/si_compute_blit.c
+++ b/src/gallium/drivers/radeonsi/si_compute_blit.c
@@ -44,23 +44,23 @@ static enum si_cache_policy
get_cache_policy(struct si_context *sctx,

 unsigned si_get_flush_flags(struct si_context *sctx, enum si_coherency 
coher,

enum si_cache_policy cache_policy)
 {
switch (coher) {
default:
case SI_COHERENCY_NONE:
case SI_COHERENCY_CP:
return 0;
case SI_COHERENCY_SHADER:
-   return SI_CONTEXT_INV_SMEM_L1 |
-  SI_CONTEXT_INV_VMEM_L1 |
-  (cache_policy == L2_BYPASS ? SI_CONTEXT_INV_GLOBAL_L2 : 
0);
+   return SI_CONTEXT_INV_SCACHE |
+  SI_CONTEXT_INV_VCACHE |
+  (cache_policy == L2_BYPASS ? SI_CONTEXT_INV_L2 : 0);
case SI_COHERENCY_CB_META:
return SI_CONTEXT_FLUSH_AND_INV_CB;
}
 }

 static void si_compute_internal_begin(struct si_context *sctx)
 {
sctx->flags &= ~SI_CONTEXT_START_PIPELINE_STATS;
sctx->flags |= SI_CONTEXT_STOP_PIPELINE_STATS;
sctx->render_cond_force_off = true;
@@ -165,21 +165,21 @@ static void si_compute_do_clear_or_copy(struct
si_context *sctx,
 
SI_COMPUTE_CLEAR_DW_PER_THREAD,
 
shader_dst_stream_policy, false);
}
ctx->bind_compute_state(ctx, sctx->cs_clear_buffer);
}

ctx->launch_grid(ctx, );

 	enum si_cache_policy cache_policy = get_cache_policy(sctx, coher, 
size);

sctx->flags |= SI_CONTEXT_CS_PARTIAL_FLUSH |
-		   (cache_policy == L2_BYPASS ? SI_CONTEXT_WRITEBACK_GLOBAL_L2 : 
0);

+  (cache_policy == L2_BYPASS ? SI_CONTEXT_WB_L2 : 0);

if (cache_policy != L2_BYPASS)
si_resource(dst)->TC_L2_dirty = true;

/* Restore states. */
ctx->bind_compute_state(ctx, saved_cs);
 	ctx->set_shader_buffers(ctx, PIPE_SHADER_COMPUTE, 0, src ? 2 : 1, 
saved_sb,

saved_writable_mask);
si_compute_internal_end(sctx);
 }
@@ -411,21 +411,21 @@ void si_compute_copy_image(struct si_context 
*sctx,

info.last_block[1] = height % 8;
info.block[2] = 1;
info.grid[0] = DIV_ROUND_UP(width, 8);
info.grid[1] = DIV_ROUND_UP(height, 8);
info.grid[2] = depth;
}

ctx->launch_grid(ctx, );

sctx->flags |= SI_CONTEXT_CS_PARTIAL_FLUSH |
-		   (sctx->chip_class <= GFX8 ? SI_CONTEXT_WRIT

Re: [Mesa-dev] [PATCH 7/7] radeonsi: don't use the low-optimizing compiler on LLVM 9

[Dieter Nützel]

Hello Marek,

is this (#7) obsolete, now?
Kind reminder.

Thanks,
Dieter

Am 13.06.2019 02:40, schrieb Marek Olšák:

From: Marek Olšák 

The compilation is faster on LLVM 9.
---
 src/gallium/drivers/radeonsi/si_pipe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 8527999645b..d2fd058f2cd 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -115,21 +115,22 @@ static const struct debug_named_value 
debug_options[] = {


DEBUG_NAMED_VALUE_END /* must be last */
 };

 static void si_init_compiler(struct si_screen *sscreen,
 struct ac_llvm_compiler *compiler)
 {
/* Only create the less-optimizing version of the compiler on APUs
 * predating Ryzen (Raven). */
bool create_low_opt_compiler = !sscreen->info.has_dedicated_vram &&
-  sscreen->info.chip_class <= GFX8;
+  sscreen->info.chip_class <= GFX8 &&
+  HAVE_LLVM < 0x0900;

enum ac_target_machine_options tm_options =
(sscreen->debug_flags & DBG(SI_SCHED) ? AC_TM_SISCHED : 0) |
(sscreen->debug_flags & DBG(GISEL) ? AC_TM_ENABLE_GLOBAL_ISEL : 
0) |
(sscreen->info.chip_class >= GFX9 ? AC_TM_FORCE_ENABLE_XNACK : 
0) |
(sscreen->info.chip_class < GFX9 ? AC_TM_FORCE_DISABLE_XNACK : 
0) |
(!sscreen->llvm_has_working_vgpr_indexing ?
AC_TM_PROMOTE_ALLOCA_TO_SCRATCH : 0) |
(sscreen->debug_flags & DBG(CHECK_IR) ? AC_TM_CHECK_IR : 0) |
(create_low_opt_compiler ? AC_TM_CREATE_LOW_OPT : 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

[Dieter Nützel]

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%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.


Hello Jan,

I'm so blind...
...bumping it 48 and 64 (first try) works. 33 not ;-)
We shouldn't waste to much memory.
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).

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

Re: [Mesa-dev] [PATCH 7/7] radeonsi: don't use the low-optimizing compiler on LLVM 9

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

on Polaris 20

Have a look here, too.
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1106085-linux-kernel-set-to-expose-hidden-nvidia-hda-controllers-helping-laptop-users?p=1106199#post1106199

Dieter

Am 13.06.2019 02:40, schrieb Marek Olšák:

From: Marek Olšák 

The compilation is faster on LLVM 9.
---
 src/gallium/drivers/radeonsi/si_pipe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 8527999645b..d2fd058f2cd 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -115,21 +115,22 @@ static const struct debug_named_value 
debug_options[] = {


DEBUG_NAMED_VALUE_END /* must be last */
 };

 static void si_init_compiler(struct si_screen *sscreen,
 struct ac_llvm_compiler *compiler)
 {
/* Only create the less-optimizing version of the compiler on APUs
 * predating Ryzen (Raven). */
bool create_low_opt_compiler = !sscreen->info.has_dedicated_vram &&
-  sscreen->info.chip_class <= GFX8;
+  sscreen->info.chip_class <= GFX8 &&
+  HAVE_LLVM < 0x0900;

enum ac_target_machine_options tm_options =
(sscreen->debug_flags & DBG(SI_SCHED) ? AC_TM_SISCHED : 0) |
(sscreen->debug_flags & DBG(GISEL) ? AC_TM_ENABLE_GLOBAL_ISEL : 
0) |
(sscreen->info.chip_class >= GFX9 ? AC_TM_FORCE_ENABLE_XNACK : 
0) |
(sscreen->info.chip_class < GFX9 ? AC_TM_FORCE_DISABLE_XNACK : 
0) |
(!sscreen->llvm_has_working_vgpr_indexing ?
AC_TM_PROMOTE_ALLOCA_TO_SCRATCH : 0) |
(sscreen->debug_flags & DBG(CHECK_IR) ? AC_TM_CHECK_IR : 0) |
(create_low_opt_compiler ? AC_TM_CREATE_LOW_OPT : 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

[Dieter Nützel]

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.

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://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1106085-linux-kernel-set-to-expose-hidden-nvidia-hda-controllers-helping-laptop-users?p=1106199#post1106199

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)

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
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
--- 

Re: [Mesa-dev] [PATCH] r300g: implement GLSL disk shader caching

[Dieter Nützel]

Hello Rui,

do you have some numbers with/without shader caching enabled, handy?
I didn't have r300 hardware anylonger...

Thanks!

Dieter

Am 07.06.2019 13:19, schrieb rsalvate...@gmail.com:

From: Rui Salvaterra 

This implements GLSL disk shader caching for the R300-R500 series of 
AMD GPUs.


Signed-off-by: Rui Salvaterra 
---
 src/gallium/drivers/r300/r300_screen.c | 38 +-
 src/gallium/drivers/r300/r300_screen.h |  3 ++
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index d26cf901a7b..b9df321de86 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -80,11 +80,42 @@ static const char* chip_families[] = {
 "ATI RV570"
 };

+static const char* r300_get_family_name(struct r300_screen* 
r300screen)

+{
+return chip_families[r300screen->caps.family];
+}
+
 static const char* r300_get_name(struct pipe_screen* pscreen)
 {
 struct r300_screen* r300screen = r300_screen(pscreen);

-return chip_families[r300screen->caps.family];
+return r300_get_family_name(r300screen);
+}
+
+static void r300_disk_cache_create(struct r300_screen* r300screen)
+{
+struct mesa_sha1 ctx;
+unsigned char sha1[20];
+char cache_id[20 * 2 + 1];
+
+_mesa_sha1_init();
+if (!disk_cache_get_function_identifier(r300_disk_cache_create,
+))
+return;
+
+_mesa_sha1_final(, sha1);
+disk_cache_format_hex_id(cache_id, sha1, 20 * 2);
+
+r300screen->disk_shader_cache =
+
disk_cache_create(r300_get_family_name(r300screen),

+  cache_id,
+  r300screen->debug);
+}
+
+static struct disk_cache* r300_get_disk_shader_cache(struct
pipe_screen* pscreen)
+{
+   struct r300_screen* r300screen = r300_screen(pscreen);
+   return r300screen->disk_shader_cache;
 }

 static int r300_get_param(struct pipe_screen* pscreen, enum pipe_cap 
param)
@@ -745,6 +776,8 @@ static void r300_destroy_screen(struct pipe_screen* 
pscreen)

 mtx_destroy(>cmask_mutex);
 slab_destroy_parent(>pool_transfers);

+disk_cache_destroy(r300screen->disk_shader_cache);
+
 if (rws)
   rws->destroy(rws);

@@ -795,6 +828,7 @@ struct pipe_screen* r300_screen_create(struct
radeon_winsys *rws,
 r300screen->screen.get_name = r300_get_name;
 r300screen->screen.get_vendor = r300_get_vendor;
 r300screen->screen.get_device_vendor = r300_get_device_vendor;
+r300screen->screen.get_disk_shader_cache = 
r300_get_disk_shader_cache;

 r300screen->screen.get_param = r300_get_param;
 r300screen->screen.get_shader_param = r300_get_shader_param;
 r300screen->screen.get_paramf = r300_get_paramf;
@@ -807,6 +841,8 @@ struct pipe_screen* r300_screen_create(struct
radeon_winsys *rws,

 r300_init_screen_resource_functions(r300screen);

+r300_disk_cache_create(r300screen);
+
 slab_create_parent(>pool_transfers, sizeof(struct
pipe_transfer), 64);

 (void) mtx_init(>cmask_mutex, mtx_plain);
diff --git a/src/gallium/drivers/r300/r300_screen.h
b/src/gallium/drivers/r300/r300_screen.h
index 952dc341ab7..b28de008304 100644
--- a/src/gallium/drivers/r300/r300_screen.h
+++ b/src/gallium/drivers/r300/r300_screen.h
@@ -27,6 +27,7 @@
 #include "r300_chipset.h"
 #include "radeon/radeon_winsys.h"
 #include "pipe/p_screen.h"
+#include "util/disk_cache.h"
 #include "util/slab.h"
 #include "os/os_thread.h"
 #include 
@@ -44,6 +45,8 @@ struct r300_screen {
 /** Combination of DBG_xxx flags */
 unsigned debug;

+struct disk_cache *disk_shader_cache;
+
 struct slab_parent_pool pool_transfers;

 /* The MSAA texture with CMASK access; */

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

Re: [Mesa-dev] [radeonsi] meson vs autotools used disk space observations

[Dieter Nützel]

Am 13.05.2019 11:06, schrieb Eric Engestrom:

On Monday, 2019-05-13 01:05:10 +0200, Dieter Nützel wrote:

Am 13.05.2019 00:03, schrieb Jason Ekstrand:
> Likely you're either getting slightly different build flags for some
> reason it else something extra is getting linked into the gallium
> driver that want before. Not all they concerning but I'll happily
> agree it is a bit odd and probably worth some investigation. If
> nothing else, your build setup isn't identical between the two
> somehow.  That said, without knowing your meson config parameters it's
> impossible to guess what that would be.

Hello Jason,

thank you that you step in.

> You provided some CMake thing
> but that looks irrelevant.

Oh, sh... (see below).

> On May 12, 2019 15:13:59 Dieter Nützel  wrote:
>
> > Hello to all of you,
> >
> > after long fiddling with fading away of autotools I have to present my
> > observations about used disk space at least for the radeonsi driver.
> > Same goes for radeon.
> >
> > autotools
> > -rwxr-xr-x   4 root root  4903184 12. Mai 19:28 radeonsi_drv_video.so
> > -rwxr-xr-x   4 root root  4903184 12. Mai 19:28 r600_drv_video.so
> > -rwxr-xr-x   8 root root 10933808 12. Mai 19:28 swrast_dri.so
> > -rwxr-xr-x   8 root root 10933808 12. Mai 19:28 radeonsi_dri.so
> > -rwxr-xr-x   8 root root 10933808 12. Mai 19:28 r600_dri.so
> > -rwxr-xr-x   8 root root 10933808 12. Mai 19:28 kms_swrast_dri.so
> >
> > meson ~940 k more
> > -rwxr-xr-x   6 root root  4903184 12. Mai 19:28 radeonsi_drv_video.so
> > -rwxr-xr-x   6 root root  4903184 12. Mai 19:28 r600_drv_video.so
> > -rwxr-xr-x   8 root root 11876040 12. Mai 21:26 swrast_dri.so
> > -rwxr-xr-x   8 root root 11876040 12. Mai 21:26 radeonsi_dri.so
> > -rwxr-xr-x   8 root root 11876040 12. Mai 21:26 r600_dri.so
> > -rwxr-xr-x   8 root root 11876040 12. Mai 21:26 kms_swrast_dri.so
> >
> > @Marek
> > Aren't *_drv_video.so needed any longer? They aren't built/installed
> > by
> > meson any more.
> >
> > autotools
> > -rwxr-xr-x   4 root root 4931824 12. Mai 19:28
> > libvdpau_radeonsi.so.1.0.0
> > -rwxr-xr-x   4 root root 4931824 12. Mai 19:28 libvdpau_r600.so.1.0.0
> >
> > meson ~430k more
> > -rwxr-xr-x   4 root root 5365912 12. Mai 21:26
> > libvdpau_radeonsi.so.1.0.0
> > -rwxr-xr-x   4 root root 5365912 12. Mai 21:26 libvdpau_r600.so.1.0.0
> >
> > autotools
> > -rwxr-xr-x  1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.1.0
> > -rwxr-xr-x  1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.0.0
> > -rwxr-xr-x  1 root root42792 12. Mai 19:28 libGLESv2.so.2.0.0
> > -rwxr-xr-x  1 root root   467872 12. Mai 19:28 libGLX_mesa.so.0.0.0
> > -rwxr-xr-x  1 root root 24152656 12. Mai 19:28 libOpenCL.so.1.0.0
> > -rwxr-xr-x  1 root root   221696 12. Mai 19:28 libEGL_mesa.so.0.0.0
> > -rwxr-xr-x  1 root root   203064 12. Mai 19:28 libglapi.so.0.0.0
> > -rwxr-xr-x  1 root root  3392464 12. Mai 19:28 libvulkan_radeon.so
> > -rwxr-xr-x  1 root root  2150968 12. Mai 19:28 libXvMCr600.so.1.0.0
> >
> > meson
> > -rwxr-xr-x 1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.1.0
> > -rwxr-xr-x 1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.0.0
> > -rwxr-xr-x 1 root root42792 12. Mai 19:28 libGLESv2.so.2.0.0
> > -rwxr-xr-x 1 root root  2150968 12. Mai 19:28 libXvMCr600.so.1.0.0
> > -rwxr-xr-x 1 root root   203072 12. Mai 21:26 libglapi.so.0.0.0
> > -rwxr-xr-x 1 root root  3683296 12. Mai 21:26 libvulkan_radeon.so
> > 290k more
> >
> > -rwxr-xr-x 1 root root   480160 12. Mai 21:26 libGLX_mesa.so.0.0.0
> > 130k more
> >
> > -rwxr-xr-x 1 root root   234016 12. Mai 21:26 libEGL_mesa.so.0.0.0
> > 130k more
> >
> > -rwxr-xr-x 1 root root 24144432 12. Mai 21:26 libOpenCL.so.1.0.0
> >
> > libGLE* aren't build/installed, too.
> >
> > This was last tested with mesa git #4111c380b05, because of 'final'
> > deletion of autotools. git revert xxx autotools commits.
> >
> > My configuration:
> > autotools
> > ./autogen.sh --prefix=/usr/local --with-dri-drivers=""
> > --with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast
> > --with-vulkan-drivers=radeon --enable-nine --enable-opencl
> > --disable-opencl_icd --enable-libglvnd --enable-autotools
> >
> > meson
> > cmake -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" ../

Argh,

this shouldn't show up. Not sure what I did...;-)

Shoul

Re: [Mesa-dev] [radeonsi] meson vs autotools used disk space observations

[Dieter Nützel]

Am 13.05.2019 00:03, schrieb Jason Ekstrand:

Likely you're either getting slightly different build flags for some
reason it else something extra is getting linked into the gallium
driver that want before. Not all they concerning but I'll happily
agree it is a bit odd and probably worth some investigation. If
nothing else, your build setup isn't identical between the two
somehow.  That said, without knowing your meson config parameters it's
impossible to guess what that would be.


Hello Jason,

thank you that you step in.


You provided some CMake thing
but that looks irrelevant.


Oh, sh... (see below).


On May 12, 2019 15:13:59 Dieter Nützel  wrote:


Hello to all of you,

after long fiddling with fading away of autotools I have to present my
observations about used disk space at least for the radeonsi driver.
Same goes for radeon.

autotools
-rwxr-xr-x   4 root root  4903184 12. Mai 19:28 radeonsi_drv_video.so
-rwxr-xr-x   4 root root  4903184 12. Mai 19:28 r600_drv_video.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 swrast_dri.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 radeonsi_dri.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 r600_dri.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 kms_swrast_dri.so

meson ~940 k more
-rwxr-xr-x   6 root root  4903184 12. Mai 19:28 radeonsi_drv_video.so
-rwxr-xr-x   6 root root  4903184 12. Mai 19:28 r600_drv_video.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 swrast_dri.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 radeonsi_dri.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 r600_dri.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 kms_swrast_dri.so

@Marek
Aren't *_drv_video.so needed any longer? They aren't built/installed 
by

meson any more.

autotools
-rwxr-xr-x   4 root root 4931824 12. Mai 19:28
libvdpau_radeonsi.so.1.0.0
-rwxr-xr-x   4 root root 4931824 12. Mai 19:28 libvdpau_r600.so.1.0.0

meson ~430k more
-rwxr-xr-x   4 root root 5365912 12. Mai 21:26
libvdpau_radeonsi.so.1.0.0
-rwxr-xr-x   4 root root 5365912 12. Mai 21:26 libvdpau_r600.so.1.0.0

autotools
-rwxr-xr-x  1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.1.0
-rwxr-xr-x  1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.0.0
-rwxr-xr-x  1 root root42792 12. Mai 19:28 libGLESv2.so.2.0.0
-rwxr-xr-x  1 root root   467872 12. Mai 19:28 libGLX_mesa.so.0.0.0
-rwxr-xr-x  1 root root 24152656 12. Mai 19:28 libOpenCL.so.1.0.0
-rwxr-xr-x  1 root root   221696 12. Mai 19:28 libEGL_mesa.so.0.0.0
-rwxr-xr-x  1 root root   203064 12. Mai 19:28 libglapi.so.0.0.0
-rwxr-xr-x  1 root root  3392464 12. Mai 19:28 libvulkan_radeon.so
-rwxr-xr-x  1 root root  2150968 12. Mai 19:28 libXvMCr600.so.1.0.0

meson
-rwxr-xr-x 1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.1.0
-rwxr-xr-x 1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.0.0
-rwxr-xr-x 1 root root42792 12. Mai 19:28 libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root  2150968 12. Mai 19:28 libXvMCr600.so.1.0.0
-rwxr-xr-x 1 root root   203072 12. Mai 21:26 libglapi.so.0.0.0
-rwxr-xr-x 1 root root  3683296 12. Mai 21:26 libvulkan_radeon.so
290k more

-rwxr-xr-x 1 root root   480160 12. Mai 21:26 libGLX_mesa.so.0.0.0
130k more

-rwxr-xr-x 1 root root   234016 12. Mai 21:26 libEGL_mesa.so.0.0.0
130k more

-rwxr-xr-x 1 root root 24144432 12. Mai 21:26 libOpenCL.so.1.0.0

libGLE* aren't build/installed, too.

This was last tested with mesa git #4111c380b05, because of 'final'
deletion of autotools. git revert xxx autotools commits.

My configuration:
autotools
./autogen.sh --prefix=/usr/local --with-dri-drivers=""
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast
--with-vulkan-drivers=radeon --enable-nine --enable-opencl
--disable-opencl_icd --enable-libglvnd --enable-autotools

meson
cmake -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" ../


Argh,

this shouldn't show up. Not sure what I did...;-)

Should be:

meson ../ --strip --buildtype debugoptimized -Ddri-drivers= 
-Dplatforms=drm,x11 -Dgallium-drivers=r600,radeonsi,swrast 
-Dvulkan-drivers=amd -Dgallium-nine=true -Dgallium-opencl=standalone 
-Dglvnd=true -Dgallium-va=false -Dgallium-xvmc=false 
-Dgallium-omx=disabled -Dgallium-xa=false


I'm on openSUSE Tumbleweed, latest meson-0.50.1.
Do you need some Tumbleweed meson build flags, too?

Thanks,
Dieter


Thanks,

Dieter
___
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] radv: remove sisched hack for talos

[Dieter Nützel]

Am 15.03.2019 23:47, schrieb Timothy Arceri:

On 16/3/19 6:53 am, Dieter Nützel wrote:

Am 15.03.2019 15:20, schrieb Samuel Pitoiset:

Results of my benchmarks are:

3 runs at 1080p:

GFX8: -1%

GFX9: -1.12%

3 runs at 4k:

GFX8: -2%

GFX9: -1.85%

I'm actually not sure if we want to remove it...


Yes, my hint is we should wait until Marek is back from vacation.
Running all the time with AMD_DEBUB (R600_DEBUG)=nir,sisched 'cause 
it's

worth it...


Can you point to specific games that are helped?


My most prominent example is UH (>6% speedup), but Marek had drirc patch 
for US ages ago, too. UV 'only' 1%.


UH, sisched
Benchmark results:
Time:   260.602
Frames: 23609
FPS:90.5942
Min FPS:8.95326
Max FPS:194.812
Score:  2282.07

UH
Benchmark results:
Time:   260.586
Frames: 22143
FPS:84.9738
Min FPS:8.85195
Max FPS:185.081
Score:  2140.49

UV, sisched
Benchmark results:
Time:   189.126
Frames: 16232
FPS:85.8264
Min FPS:26.4919
Max FPS:124.166
Score:  3590.98

UV
Benchmark results:
Time:   189.126
Frames: 16028
FPS:84.7478
Min FPS:27.965
Max FPS:125.107
Score:  3545.85

Several progs/apps run 'smoother' with 'sisched' and there are some 
reports on Phoronix that best performance is achieved with 'sisched', 
too,


Greetings,
Dieter



Dieter


On 3/15/19 11:25 AM, Timothy Arceri wrote:

This was added in 8a7d4092d260 but no longer seems to have any
impact on performance.
---
  src/amd/vulkan/radv_device.c | 10 +-
  1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c 
b/src/amd/vulkan/radv_device.c

index 9570c15af02..56421dbc74b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -499,15 +499,7 @@ radv_handle_per_app_options(struct 
radv_instance *instance,

  if (!name)
  return;
  -    if (!strcmp(name, "Talos - Linux - 32bit") ||
-    !strcmp(name, "Talos - Linux - 64bit")) {
-    if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
-    /* Force enable LLVM sisched for Talos because it looks
- * safe and it gives few more FPS.
- */
-    instance->perftest_flags |= RADV_PERFTEST_SISCHED;
-    }
-    } else if (!strcmp(name, "DOOM_VFR")) {
+    if (!strcmp(name, "DOOM_VFR")) {
  /* Work around a Doom VFR game bug */
  instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
  }

___
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] [radeonsi] meson vs autotools used disk space observations

[Dieter Nützel]

Hello to all of you,

after long fiddling with fading away of autotools I have to present my 
observations about used disk space at least for the radeonsi driver. 
Same goes for radeon.


autotools
-rwxr-xr-x   4 root root  4903184 12. Mai 19:28 radeonsi_drv_video.so
-rwxr-xr-x   4 root root  4903184 12. Mai 19:28 r600_drv_video.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 swrast_dri.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 radeonsi_dri.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 r600_dri.so
-rwxr-xr-x   8 root root 10933808 12. Mai 19:28 kms_swrast_dri.so

meson ~940 k more
-rwxr-xr-x   6 root root  4903184 12. Mai 19:28 radeonsi_drv_video.so
-rwxr-xr-x   6 root root  4903184 12. Mai 19:28 r600_drv_video.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 swrast_dri.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 radeonsi_dri.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 r600_dri.so
-rwxr-xr-x   8 root root 11876040 12. Mai 21:26 kms_swrast_dri.so

@Marek
Aren't *_drv_video.so needed any longer? They aren't built/installed by 
meson any more.


autotools
-rwxr-xr-x   4 root root 4931824 12. Mai 19:28 
libvdpau_radeonsi.so.1.0.0

-rwxr-xr-x   4 root root 4931824 12. Mai 19:28 libvdpau_r600.so.1.0.0

meson ~430k more
-rwxr-xr-x   4 root root 5365912 12. Mai 21:26 
libvdpau_radeonsi.so.1.0.0

-rwxr-xr-x   4 root root 5365912 12. Mai 21:26 libvdpau_r600.so.1.0.0

autotools
-rwxr-xr-x  1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.1.0
-rwxr-xr-x  1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.0.0
-rwxr-xr-x  1 root root42792 12. Mai 19:28 libGLESv2.so.2.0.0
-rwxr-xr-x  1 root root   467872 12. Mai 19:28 libGLX_mesa.so.0.0.0
-rwxr-xr-x  1 root root 24152656 12. Mai 19:28 libOpenCL.so.1.0.0
-rwxr-xr-x  1 root root   221696 12. Mai 19:28 libEGL_mesa.so.0.0.0
-rwxr-xr-x  1 root root   203064 12. Mai 19:28 libglapi.so.0.0.0
-rwxr-xr-x  1 root root  3392464 12. Mai 19:28 libvulkan_radeon.so
-rwxr-xr-x  1 root root  2150968 12. Mai 19:28 libXvMCr600.so.1.0.0

meson
-rwxr-xr-x 1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.1.0
-rwxr-xr-x 1 root root26408 12. Mai 19:28 libGLESv1_CM.so.1.0.0
-rwxr-xr-x 1 root root42792 12. Mai 19:28 libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root  2150968 12. Mai 19:28 libXvMCr600.so.1.0.0
-rwxr-xr-x 1 root root   203072 12. Mai 21:26 libglapi.so.0.0.0
-rwxr-xr-x 1 root root  3683296 12. Mai 21:26 libvulkan_radeon.so
290k more

-rwxr-xr-x 1 root root   480160 12. Mai 21:26 libGLX_mesa.so.0.0.0
130k more

-rwxr-xr-x 1 root root   234016 12. Mai 21:26 libEGL_mesa.so.0.0.0
130k more

-rwxr-xr-x 1 root root 24144432 12. Mai 21:26 libOpenCL.so.1.0.0

libGLE* aren't build/installed, too.

This was last tested with mesa git #4111c380b05, because of 'final' 
deletion of autotools. git revert xxx autotools commits.


My configuration:
autotools
./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast 
--with-vulkan-drivers=radeon --enable-nine --enable-opencl 
--disable-opencl_icd --enable-libglvnd --enable-autotools


meson
cmake -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" ../


Thanks,

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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Am 09.04.2019 02:42, schrieb Marek Olšák:

I'm pretty sure I merged this series in February.

Marek


Yes, of course you did (with my tb), but I meant... (see below)


On Mon, Apr 8, 2019 at 6:10 PM Dieter Nützel 
wrote:


Maybe someone working on this, too.

I'm feeling fine again after a short 'trip' into the hospital...;-)

Dieter

Am 26.02.2019 07:36, schrieb Marek Olšák:

We need to extend the CS ioctl to allow submitting 2 command

buffers

at the same time.


This additional work.

Dieter


Marek

On Mon, Feb 25, 2019, 10:06 PM Dieter Nützel



wrote:


Hello Marek,

you wrote with your series sent:

[-]
Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that
wasn't
there before.
[-]

Any ideas to speed this up, again?
glmark2 went from 9766 (best ever) down to 7455 (all with NIR).
Or are micro benchmarks not worth more effort?

Dieter

SDMA
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.30.0,
5.0.0-rc1-1.g7262353-default+, LLVM 9.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.0-devel
(git-a9b32aaa16)
===
[build] use-vbo=false: FPS: 3694 FrameTime: 0.271 ms
[build] use-vbo=true: FPS: 9341 FrameTime: 0.107 ms
[texture] texture-filter=nearest: FPS: 9140 FrameTime: 0.109 ms
[texture] texture-filter=linear: FPS: 9163 FrameTime: 0.109 ms
[texture] texture-filter=mipmap: FPS: 9161 FrameTime: 0.109 ms
[shading] shading=gouraud: FPS: 9234 FrameTime: 0.108 ms
[shading] shading=blinn-phong-inf: FPS: 9255 FrameTime: 0.108 ms
[shading] shading=phong: FPS: 9226 FrameTime: 0.108 ms
[shading] shading=cel: FPS: 9310 FrameTime: 0.107 ms
[bump] bump-render=high-poly: FPS: 9298 FrameTime: 0.108 ms
[bump] bump-render=normals: FPS: 9121 FrameTime: 0.110 ms
[bump] bump-render=height: FPS: 9120 FrameTime: 0.110 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 9858 FrameTime: 0.101

ms

libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 9854
FrameTime:
0.101 ms
[pulsar] light=false:quads=5:texture=false: FPS: 8468 FrameTime:
0.118
ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop]
blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 5181 FrameTime: 0.193 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 5374 FrameTime: 0.186 ms
[buffer]






columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 824 FrameTime: 1.214 ms
[buffer]






columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:


FPS: 1114 FrameTime: 0.898 ms
[buffer]






columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 899 FrameTime: 1.112 ms
[ideas] speed=duration: FPS: 3485 FrameTime: 0.287 ms
[jellyfish] : FPS: 7992 FrameTime: 0.125 ms
[terrain] : FPS: 1796 FrameTime: 0.557 ms
[shadow] : FPS: 7350 FrameTime: 0.136 ms
[refract] : FPS: 3595 FrameTime: 0.278 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 9401

FrameTime:


0.106 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 9413

FrameTime:


0.106 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 9417

FrameTime:


0.106 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 9365
FrameTime: 0.107 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 9451
FrameTime: 0.106 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS:
9300
FrameTime: 0.108 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5:

FPS:

9440
FrameTime: 0.106 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5:

FPS:

9392
FrameTime: 0.106 ms
===
glmark2 Score: 7455
===

Before
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.27.0,
4.20.0-rc3-1.g7262353-default+, LLVM 8.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.0.0-devel
(git-c49b3df3cb)
===
[build] use-vbo=false: FPS: 3373 FrameTime: 0.296 ms
[build] use-vbo=true: FPS: 13121 FrameTime: 0.076 ms
[texture] texture-filter=nearest: FPS: 12172 FrameTime: 0.082 ms
[texture] texture-filter=linear: FPS: 12557 FrameTime: 0.080 ms
[texture] texture-filter=mipmap: FPS: 12228 FrameTime: 0.082 ms
[shading] shading=gouraud: FPS: 12536 FrameTime: 0.080 ms
[shading] shading=blinn-phong-inf: FPS: 12782 FrameTime: 0.078 ms
[shading] shading=phong: FPS: 12619 FrameTime: 0.079 ms
[shading] shading

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Maybe someone working on this, too.

I'm feeling fine again after a short 'trip' into the hospital...;-)

Dieter

Am 26.02.2019 07:36, schrieb Marek Olšák:

We need to extend the CS ioctl to allow submitting 2 command buffers
at the same time.

Marek

On Mon, Feb 25, 2019, 10:06 PM Dieter Nützel 
wrote:


Hello Marek,

you wrote with your series sent:

[-]
Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that
wasn't
there before.
[-]

Any ideas to speed this up, again?
glmark2 went from 9766 (best ever) down to 7455 (all with NIR).
Or are micro benchmarks not worth more effort?

Dieter

SDMA
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.30.0,
5.0.0-rc1-1.g7262353-default+, LLVM 9.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.0-devel
(git-a9b32aaa16)
===
[build] use-vbo=false: FPS: 3694 FrameTime: 0.271 ms
[build] use-vbo=true: FPS: 9341 FrameTime: 0.107 ms
[texture] texture-filter=nearest: FPS: 9140 FrameTime: 0.109 ms
[texture] texture-filter=linear: FPS: 9163 FrameTime: 0.109 ms
[texture] texture-filter=mipmap: FPS: 9161 FrameTime: 0.109 ms
[shading] shading=gouraud: FPS: 9234 FrameTime: 0.108 ms
[shading] shading=blinn-phong-inf: FPS: 9255 FrameTime: 0.108 ms
[shading] shading=phong: FPS: 9226 FrameTime: 0.108 ms
[shading] shading=cel: FPS: 9310 FrameTime: 0.107 ms
[bump] bump-render=high-poly: FPS: 9298 FrameTime: 0.108 ms
[bump] bump-render=normals: FPS: 9121 FrameTime: 0.110 ms
[bump] bump-render=height: FPS: 9120 FrameTime: 0.110 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 9858 FrameTime: 0.101 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 9854
FrameTime:
0.101 ms
[pulsar] light=false:quads=5:texture=false: FPS: 8468 FrameTime:
0.118
ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop]
blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 5181 FrameTime: 0.193 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 5374 FrameTime: 0.186 ms
[buffer]


columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 824 FrameTime: 1.214 ms
[buffer]


columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:


FPS: 1114 FrameTime: 0.898 ms
[buffer]


columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 899 FrameTime: 1.112 ms
[ideas] speed=duration: FPS: 3485 FrameTime: 0.287 ms
[jellyfish] : FPS: 7992 FrameTime: 0.125 ms
[terrain] : FPS: 1796 FrameTime: 0.557 ms
[shadow] : FPS: 7350 FrameTime: 0.136 ms
[refract] : FPS: 3595 FrameTime: 0.278 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 9401 FrameTime:

0.106 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 9413 FrameTime:

0.106 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 9417 FrameTime:

0.106 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 9365
FrameTime: 0.107 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 9451
FrameTime: 0.106 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS:
9300
FrameTime: 0.108 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS:
9440
FrameTime: 0.106 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS:
9392
FrameTime: 0.106 ms
===
glmark2 Score: 7455
===

Before
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.27.0,
4.20.0-rc3-1.g7262353-default+, LLVM 8.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.0.0-devel
(git-c49b3df3cb)
===
[build] use-vbo=false: FPS: 3373 FrameTime: 0.296 ms
[build] use-vbo=true: FPS: 13121 FrameTime: 0.076 ms
[texture] texture-filter=nearest: FPS: 12172 FrameTime: 0.082 ms
[texture] texture-filter=linear: FPS: 12557 FrameTime: 0.080 ms
[texture] texture-filter=mipmap: FPS: 12228 FrameTime: 0.082 ms
[shading] shading=gouraud: FPS: 12536 FrameTime: 0.080 ms
[shading] shading=blinn-phong-inf: FPS: 12782 FrameTime: 0.078 ms
[shading] shading=phong: FPS: 12619 FrameTime: 0.079 ms
[shading] shading=cel: FPS: 12735 FrameTime: 0.079 ms
[bump] bump-render=high-poly: FPS: 11412 FrameTime: 0.088 ms
[bump] bump-render=normals: FPS: 12467 FrameTime: 0.080 ms
[bump] bump-render=height: FPS: 12422 FrameTime: 0.081 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel

Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute

[Dieter Nützel]

After you've recuperated from hopefully GREAT vacation,

is it time? ;-)

Greetings,
Dieter

Am 26.02.2019 03:31, schrieb Dieter Nützel:

Hello Marek,

do you plan to commit or rebase both set?

Dieter

Am 14.02.2019 07:29, schrieb Marek Olšák:

I have some fixes for Sea Islands that improve Radeon 290X performance
to 43 fps, moving it just below Radeon VII in the picture.

Marek

On Wed, Feb 13, 2019 at 12:16 AM Marek Olšák 
wrote:


Hi,

This patch series uses async compute to do primitive culling before
the vertex shader. It significantly improves performance for
applications
that use a lot of geometry that is invisible because primitives
don't
intersect sample points or there are a lot of back faces, etc.

It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100%
stable.
It supports all chips all the way from Sea Islands to Radeon VII.

As you can see in the results marked (ENABLED) in the picture below,
it destroys our competition (The GeForce results are from a Phoronix
article from 2017, the latest ones I could find):

Benchmark: ParaView - Many Spheres - 2560x1440
https://people.freedesktop.org/~mareko/prim-discard-cs-results.png

The last patch describes the implementation and functional
limitations
if you can find the huge code comment, so I'm not gonna do that
here.

I decided to enable this optimization on all Pro graphics cards.
The reason is that I haven't had time to benchmark games.
This decision may be changed based on community feedback, etc.

People using the Pro graphics cards can disable this by setting
AMD_DEBUG=nopd, and people using consumer graphics cards can enable
this by setting AMD_DEBUG=pd. So you always have a choice.

Eventually we might also enable this on consumer graphics cards for
those
games that benefit. It might decrease performance if there is not
enough
invisible geometry.

Branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs

Please review.

Thanks,
Marek

___
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] radeonsi: fix a crash when unbinding sampler states

[Dieter Nützel]

SOLVED it.

Thanks to both of you!

Dieter

Am 08.04.2019 21:12, schrieb James Zhu:

This patch is Acked-by: James Zhu 

On 2019-04-08 3:02 p.m., Marek Olšák wrote:


On Mon, Apr 8, 2019 at 2:45 PM James Zhu  wrote:

On 2019-04-08 2:39 p.m., Marek Olšák wrote:

On Mon, Apr 8, 2019 at 2:33 PM James Zhu  wrote:

On 2019-04-08 2:25 p.m., Marek Olšák wrote:

From: Marek Olšák 

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

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c

b/src/gallium/drivers/radeonsi/si_descriptors.c

index 244ba5a7bec..ac40ed27f91 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct

si_context *sctx)

static void si_bind_sampler_states(struct pipe_context *ctx,
enum pipe_shader_type shader,
unsigned start, unsigned

count, void **states)

{
struct si_context *sctx = (struct si_context *)ctx;
struct si_samplers *samplers = >samplers[shader];
struct si_descriptors *desc =

si_sampler_and_image_descriptors(sctx, shader);

struct si_sampler_state **sstates = (struct

si_sampler_state**)states;

int i;

- if (!count || shader >= SI_NUM_SHADERS)
+ if (!count || shader >= SI_NUM_SHADERS || !sstates)


if sstates == NULL, it means we want to unbind
samplers->sampler_states
from current setting.

So I think it is better not just bypass it.

The driver never unbinds constant state objects. If sstates[i] ==
NULL, it's not unbound. sstates == NULL is a similar case.


Then we should not call unbind sampler state after compute shader
launch. Since it is doing nothing.
You are right.

Marek
___
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"

[Dieter Nützel]

Tested-by: Dieter Nützel 
Acked-by: Dieter Nützel 

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

Re: [Mesa-dev] [PATCH] gallium/drivers/radeonsi: Add si_bind_sampler_states unbind support

[Dieter Nützel]

Tested-by: Dieter Nützel 

Thank you James!

Dieter

Am 06.04.2019 15:07, schrieb Zhu, James:

commit a613607dc3dab2b43884a4e5891aa5939cdcfbe0 will cause segfault
during unbind sampler state. This patch will fix the issue.

Signed-off-by: James Zhu 
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 244ba5a..883b91c 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -956,8 +956,11 @@ static void si_bind_sampler_states(struct
pipe_context *ctx,
unsigned slot = start + i;
unsigned desc_slot = si_get_sampler_slot(slot);

-   if (!sstates[i] ||
-   sstates[i] == samplers->sampler_states[slot])
+   if(!sstates) {
+   samplers->sampler_states[slot] = NULL;
+   continue;
+   } else if (!sstates[i] ||
+   sstates[i] == samplers->sampler_states[slot])
continue;

 #ifdef DEBUG

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

[Mesa-dev] gallium/auxiliary/vl: Add barrier/unbind after compute shader launch - vdpau sigfault - bisected

[Dieter Nützel]

Hello James,

sorry that I have to report that the mentioned commit sigfault with 
'mplayer -vo vdpau xxx' for radeonsi on my Polaris 20.


BISECTED

0f416b85fbb2a3988ddc2c81540e9aadfd63d6ae is the first bad commit
commit 0f416b85fbb2a3988ddc2c81540e9aadfd63d6ae
Author: James Zhu 
Date:   Fri Mar 29 15:59:39 2019 -0400

gallium/auxiliary/vl: Add barrier/unbind after compute shader 
launch.


Add memory barrier sync for multiple launch cases, and unbind 
completed

resources after launch.

Signed-off-by: James Zhu 
Reviewed-by: Marek Olšák 

:04 04 332a2b7a783ef82312e5dbd18f7fed200882d5fe 
1fb67385017edc9a65dd4eda7b26628427fdf1f6 M src


Reverting it SOLVED 'mplayer -vo vdpau xxx' for me.

Dieter
___
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

[Dieter Nützel]

Tested-by: Dieter Nützel 

For the first time since ages no horizontal line corruption with old 
luxmark-linux64-v2.0 (LuxBall e.g. HDR) on RX580.


Dieter

Am 02.04.2019 00:37, schrieb Marek Olšák:

From: Marek Olšák 

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

___
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

[Dieter Nützel]

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://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.


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
that you need it in LLVM too.
Mixing Clover/rtti and llvm/no-rtti
would probably complain about missing symbols in llvm libraries.


But why is this?
My 'autotools' Mesa/Clover compilations worked for ages with my current 
LLVM settings.


cmake -DLLVM_TARGETS_TO_BUILD="X86;AMDGPU" -DLLVM_APPEND_VC_REV=OFF 
-DCMAKE_BUILD_TYPE="Release" -DLLVM_LINK_LLVM_DYLIB=ON 
-DLLVM_PARALLEL_COMPILE_JOBS="9" ../


My Mesa autotools settings:
./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast 
--with-vulkan-drivers=radeon --enable-nine --enable-opencl 
--disable-opencl_icd --enable-libglvnd --enable-autotools


And Clover worked, too:

Number of platforms   1
  Platform Name   Clover
  Platform Vendor Mesa
  Platform VersionOpenCL 1.1 Mesa 
19.1.0-devel (git-ebe05b8148)

  Platform ProfileFULL_PROFILE
  Platform Extensions cl_khr_icd
  Platform Extensions function suffix MESA

  Platform Name   Clover
Number of devices 1
  Device Name Radeon RX 580 Series 
(POLARIS10, DRM 3.27.0, 5.0.5-1.g0fb0b14-default, LLVM 9.0.0)

  Device Vendor   AMD
  Device Vendor ID0x1002
  Device Version  OpenCL 1.1 Mesa 
19.1.0-devel (git-ebe05b8148)

  Driver Version  19.1.0-devel
  Device OpenCL C V

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

[Dieter Nützel]

Am 01.04.2019 19:27, schrieb Dylan Baker:

Quoting Jan Vesely (2019-03-31 22:43:50)

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


I sent this merge request to make building clover against a no-rtti 
llvm a hard

error in meson, that way at least you know why it's failing:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/558

Dylan


Thanks Dylan,

i'll test it (read Jan's answer on your GITLAB request - I didn't found 
the time to set my gitlab account right up, currently).


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

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

[Dieter Nützel]

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.


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))
  ^~

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

Re: [Mesa-dev] radv: Implement VK_EXT_pipeline_creation_feedback. - sigfault - bisected

[Dieter Nützel]

The world is saved...
you rocket man!

Greetings.

Dieter

Am 21.03.2019 09:00, schrieb Samuel Pitoiset:

Yeah, my bad... I have just sent a fix.

Thanks

On 3/21/19 7:22 AM, Dieter Nützel wrote:

Hello Bas,

sorry but your latest commit #5f5ac19f138
radv: Implement VK_EXT_pipeline_creation_feedback.

sigfault with every Vulkan apps for me.

Reverting it SOLVED it.

5f5ac19f138125b04d8ddedd6334b996f8925a4a is the first bad commit
commit 5f5ac19f138125b04d8ddedd6334b996f8925a4a
Author: Bas Nieuwenhuizen 
Date:   Tue Mar 19 02:30:33 2019 +0100

    radv: Implement VK_EXT_pipeline_creation_feedback.

    Does what it says on the tin.

    The per stage time is only an approximation due to linking and
    the Vega merged stages.

    Reviewed-by: Samuel Pitoiset 

:04 04 ea08bcac9b3630e10bf333c79227bcd0ed9a894b 
0924580849d9bc268e47be1248311ff3b5488c86 M src


I'm on the 'old' way compiling today:
./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast 
--with-vulkan-drivers=radeon --enable-nine --enable-opencl 
--disable-opencl_icd --enable-libglvnd --enable-autotools


/home/dieter> vkcube
Speicherschutzverletzung (core dumped)
/home/dieter> vkcubepp
Speicherschutzverletzung (core dumped)

[46339.977530] vkcube[29027]: segfault at 7ff7951ae840 ip 
7ff795146569 sp 7ffda7d3d070 error 7 in 
libvulkan_radeon.so[7ff7950e4000+1cf000]
[46339.977536] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 
f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 
39 fb ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 
00 00


[46341.772768] vkcubepp[29040]: segfault at 7fde85d21840 ip 
7fde85cb9569 sp 7ffeb679dfc0 error 7 in 
libvulkan_radeon.so[7fde85c57000+1cf000]
[46341.772775] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 
f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 
39 fb ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 
00 00


/home/dieter> vulkaninfo | less
Speicherschutzverletzung (core dumped)

==
VULKANINFO
==

Vulkan Instance Version: 1.1.98



Instance Extensions:

Instance Extensions count = 16
    VK_EXT_acquire_xlib_display : extension revision 1
    VK_EXT_debug_report : extension revision 9
    VK_EXT_debug_utils  : extension revision 1
    VK_EXT_direct_mode_display  : extension revision 1
    VK_EXT_display_surface_counter  : extension revision 1
    VK_KHR_device_group_creation    : extension revision 1
    VK_KHR_display  : extension revision 23
    VK_KHR_external_fence_capabilities  : extension revision 1
    VK_KHR_external_memory_capabilities : extension revision 1
    VK_KHR_external_semaphore_capabilities: extension revision  1
    VK_KHR_get_display_properties2  : extension revision 1
    VK_KHR_get_physical_device_properties2: extension revision  1
    VK_KHR_get_surface_capabilities2    : extension revision 1
    VK_KHR_surface  : extension revision 25
    VK_KHR_xcb_surface  : extension revision 6
    VK_KHR_xlib_surface : extension revision 6
Layers: count = 0
===
Presentable Surfaces:
=
GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xcb_surface
Formats:    count = 2
    B8G8R8A8_SRGB
    B8G8R8A8_UNORM
Present Modes:  count = 3
    IMMEDIATE_KHR
    MAILBOX_KHR
    FIFO_KHR
VkSurfaceCapabilitiesKHR:
    minImageCount   = 2
    maxImageCount   = 0
    currentExtent:
    width   = 256
    height  = 256
    minImageExtent:
    width   = 256
    height  = 256
    maxImageExtent:
    width   = 256
    height  = 256
    maxImageArrayLayers = 1
    supportedTransform:
    VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
    currentTransform:
    VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
    supportedCompositeAlpha:
    VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
    VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
    supportedUsageFlags:
    VK_IMAGE_USAGE_TRANSFER_SRC_BIT
    VK_IMAGE_USAGE_TRANSFER_DST_BIT
    VK_IMAGE_USAGE_SAMPLED_BIT
    VK_IMAGE_USAGE_STORAGE_BIT
    VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
    supportedSurfaceCounters:
    None

GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xlib_surface
Formats:    count = 2
    B8G8R8A8_SRGB
    B8G8R8A8_UNORM
Present Modes:  count = 3
    IMMEDIATE_KHR
    MAILBOX_KHR
    FIFO_KHR

Stops, here.

BTW
'vulkaninfo' sigfault

Re: [Mesa-dev] radv: Implement VK_EXT_pipeline_creation_feedback. - sigfault - bisected

[Dieter Nützel]

Hello Bas,

sorry but your latest commit #5f5ac19f138
radv: Implement VK_EXT_pipeline_creation_feedback.

sigfault with every Vulkan apps for me.

Reverting it SOLVED it.

5f5ac19f138125b04d8ddedd6334b996f8925a4a is the first bad commit
commit 5f5ac19f138125b04d8ddedd6334b996f8925a4a
Author: Bas Nieuwenhuizen 
Date:   Tue Mar 19 02:30:33 2019 +0100

radv: Implement VK_EXT_pipeline_creation_feedback.

Does what it says on the tin.

The per stage time is only an approximation due to linking and
the Vega merged stages.

Reviewed-by: Samuel Pitoiset 

:04 04 ea08bcac9b3630e10bf333c79227bcd0ed9a894b 
0924580849d9bc268e47be1248311ff3b5488c86 M src


I'm on the 'old' way compiling today:
./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast 
--with-vulkan-drivers=radeon --enable-nine --enable-opencl 
--disable-opencl_icd --enable-libglvnd --enable-autotools


/home/dieter> vkcube
Speicherschutzverletzung (core dumped)
/home/dieter> vkcubepp
Speicherschutzverletzung (core dumped)

[46339.977530] vkcube[29027]: segfault at 7ff7951ae840 ip 
7ff795146569 sp 7ffda7d3d070 error 7 in 
libvulkan_radeon.so[7ff7950e4000+1cf000]
[46339.977536] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 f3 
0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 39 fb 
ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 00 00


[46341.772768] vkcubepp[29040]: segfault at 7fde85d21840 ip 
7fde85cb9569 sp 7ffeb679dfc0 error 7 in 
libvulkan_radeon.so[7fde85c57000+1cf000]
[46341.772775] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 f3 
0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 39 fb 
ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 00 00


/home/dieter> vulkaninfo | less
Speicherschutzverletzung (core dumped)

==
VULKANINFO
==

Vulkan Instance Version: 1.1.98



Instance Extensions:

Instance Extensions count = 16
VK_EXT_acquire_xlib_display : extension revision  1
VK_EXT_debug_report : extension revision  9
VK_EXT_debug_utils  : extension revision  1
VK_EXT_direct_mode_display  : extension revision  1
VK_EXT_display_surface_counter  : extension revision  1
VK_KHR_device_group_creation: extension revision  1
VK_KHR_display  : extension revision 23
VK_KHR_external_fence_capabilities  : extension revision  1
VK_KHR_external_memory_capabilities : extension revision  1
VK_KHR_external_semaphore_capabilities: extension revision  1
VK_KHR_get_display_properties2  : extension revision  1
VK_KHR_get_physical_device_properties2: extension revision  1
VK_KHR_get_surface_capabilities2: extension revision  1
VK_KHR_surface  : extension revision 25
VK_KHR_xcb_surface  : extension revision  6
VK_KHR_xlib_surface : extension revision  6
Layers: count = 0
===
Presentable Surfaces:
=
GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xcb_surface
Formats:count = 2
B8G8R8A8_SRGB
B8G8R8A8_UNORM
Present Modes:  count = 3
IMMEDIATE_KHR
MAILBOX_KHR
FIFO_KHR
VkSurfaceCapabilitiesKHR:
minImageCount   = 2
maxImageCount   = 0
currentExtent:
width   = 256
height  = 256
minImageExtent:
width   = 256
height  = 256
maxImageExtent:
width   = 256
height  = 256
maxImageArrayLayers = 1
supportedTransform:
VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
currentTransform:
VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
supportedCompositeAlpha:
VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
supportedUsageFlags:
VK_IMAGE_USAGE_TRANSFER_SRC_BIT
VK_IMAGE_USAGE_TRANSFER_DST_BIT
VK_IMAGE_USAGE_SAMPLED_BIT
VK_IMAGE_USAGE_STORAGE_BIT
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
supportedSurfaceCounters:
None

GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xlib_surface
Formats:count = 2
B8G8R8A8_SRGB
B8G8R8A8_UNORM
Present Modes:  count = 3
IMMEDIATE_KHR
MAILBOX_KHR
FIFO_KHR

Stops, here.

BTW
'vulkaninfo' sigfault for some days even without this commit for me.

[-]
VK_KHR_shader_draw_parameters   : extension revision  1
VK_KHR_storage_buffer_storage_class : extension revision  1

Re: [Mesa-dev] [PATCH] radv: remove sisched hack for talos

[Dieter Nützel]

Am 15.03.2019 15:20, schrieb Samuel Pitoiset:

Results of my benchmarks are:

3 runs at 1080p:

GFX8: -1%

GFX9: -1.12%

3 runs at 4k:

GFX8: -2%

GFX9: -1.85%

I'm actually not sure if we want to remove it...


Yes, my hint is we should wait until Marek is back from vacation.
Running all the time with AMD_DEBUB (R600_DEBUG)=nir,sisched 'cause it's 
worth it...


Dieter


On 3/15/19 11:25 AM, Timothy Arceri wrote:

This was added in 8a7d4092d260 but no longer seems to have any
impact on performance.
---
  src/amd/vulkan/radv_device.c | 10 +-
  1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c 
b/src/amd/vulkan/radv_device.c

index 9570c15af02..56421dbc74b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -499,15 +499,7 @@ radv_handle_per_app_options(struct radv_instance 
*instance,

if (!name)
return;
  - if (!strcmp(name, "Talos - Linux - 32bit") ||
-   !strcmp(name, "Talos - Linux - 64bit")) {
-   if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
-   /* Force enable LLVM sisched for Talos because it looks
-* safe and it gives few more FPS.
-*/
-   instance->perftest_flags |= RADV_PERFTEST_SISCHED;
-   }
-   } else if (!strcmp(name, "DOOM_VFR")) {
+   if (!strcmp(name, "DOOM_VFR")) {
/* Work around a Doom VFR game bug */
instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
}

___
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] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected

[Dieter Nützel]

Hello Andre,

@Tim:

Tested-by: Dieter Nützel 

with UH on Polaris 20

Am 07.03.2019 15:35, schrieb Andre Heider:

On 07/03/2019 15:08, Dieter Nützel wrote:
can you please send a patch to the list (and then we will see it at 
Patchwork Mesa, too), please? It is much faster (for me) and I haven't 
the time to dig me into Gitlab MRs etc. stuff at the moment. OLD 
school man...


It's just a single patch in that MR.


I know. Got it in the meantime. There is an 'Options' pulldown (Download 
| Email Patches | Plain  Diff) on the 'page' of every commit.



As with github, you can append
.patch to the url:
https://gitlab.freedesktop.org/Venemo/mesa/commit/24d534e355f54edb4b27451d0e4d92a1adb1669c.patch

Or just `curl  | git am`. Does that work for you?


"Auch gut." ;-)


Regards,
Andre


I'm learning...

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

Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected

[Dieter Nützel]

Hello Tim,

can you please send a patch to the list (and then we will see it at 
Patchwork Mesa, too), please? It is much faster (for me) and I haven't 
the time to dig me into Gitlab MRs etc. stuff at the moment. OLD school 
man...


Thanks,
Dieter

Am 07.03.2019 11:16, schrieb Timur Kristóf:

Hi,

I was able to reproduce the problem with heaven, and that the proposed
patch fixes it, so I made a MR:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/402

Best regards,
Tim


On Thu, 2019-03-07 at 08:27 +0100, Timur Kristóf wrote:

Hi Dieter,

Thanks for noticing this.
I think I made a mistake by setting window_space_position the way I
did. Should've only set that for vertex shaders.

I believe this is the right thing to do:
https://gitlab.freedesktop.org/Venemo/mesa/commit/4d8b97bacbe14bd6584d7a45ff98e65dfcb4c02b
Still need to test it myself. If it works, I'll submit a MR.

Let me know what you think.
Best regards,
Tim


On Thu, 2019-03-07 at 05:45 +0100, Dieter Nützel wrote:
> This commit (#317f10bf404) brake whole tessellation (empty parts of
> the
> screen) running UH under radeonsi NIR on Polaris 20 (RX580).
>
> 317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit
> commit 317f10bf404b562e1dda79c0636aee86beeccc2f
> Author: Timur Kristóf 
> Date:   Tue Feb 5 18:08:24 2019 +0100
>
>  nir: Add ability for shaders to use window space coordinates.
>
>  This patch adds a shader_info field that tells the driver to
> use
> window
>  space coordinates for a given vertex shader. It also enables
> this
> feature
>  in radeonsi (the only NIR-capable driver that supported it in
> TGSI),
>  and makes tgsi_to_nir aware of it.
>
>  Signed-Off-By: Timur Kristóf 
>  Tested-by: Andre Heider 
>  Tested-by: Rob Clark 
>  Reviewed-by: Timothy Arceri 
>  Reviewed-by: Eric Anholt 
>
> :04 04 3123b07ce063ffd4fee56974c64c130f3e617373
> df57eb5bb70c0e46583399c73db499e1970fdd1b M src
>
> Reverting it fixed UH.
>
> Sorry, I don't have time for a ticket, yet 'cause I badly need
> some
> sleep...
>
> Dieter

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

Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected

[Dieter Nützel]

This commit (#317f10bf404) brake whole tessellation (empty parts of the 
screen) running UH under radeonsi NIR on Polaris 20 (RX580).


317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit
commit 317f10bf404b562e1dda79c0636aee86beeccc2f
Author: Timur Kristóf 
Date:   Tue Feb 5 18:08:24 2019 +0100

nir: Add ability for shaders to use window space coordinates.

This patch adds a shader_info field that tells the driver to use 
window
space coordinates for a given vertex shader. It also enables this 
feature

in radeonsi (the only NIR-capable driver that supported it in TGSI),
and makes tgsi_to_nir aware of it.

Signed-Off-By: Timur Kristóf 
Tested-by: Andre Heider 
Tested-by: Rob Clark 
Reviewed-by: Timothy Arceri 
Reviewed-by: Eric Anholt 

:04 04 3123b07ce063ffd4fee56974c64c130f3e617373 
df57eb5bb70c0e46583399c73db499e1970fdd1b M src


Reverting it fixed UH.

Sorry, I don't have time for a ticket, yet 'cause I badly need some 
sleep...


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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Hello Marek,

you wrote with your series sent:

[-]
Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that wasn't
there before.
[-]

Any ideas to speed this up, again?
glmark2 went from 9766 (best ever) down to 7455 (all with NIR).
Or are micro benchmarks not worth more effort?

Dieter

SDMA
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.30.0, 
5.0.0-rc1-1.g7262353-default+, LLVM 9.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.0-devel 
(git-a9b32aaa16)

===
[build] use-vbo=false: FPS: 3694 FrameTime: 0.271 ms
[build] use-vbo=true: FPS: 9341 FrameTime: 0.107 ms
[texture] texture-filter=nearest: FPS: 9140 FrameTime: 0.109 ms
[texture] texture-filter=linear: FPS: 9163 FrameTime: 0.109 ms
[texture] texture-filter=mipmap: FPS: 9161 FrameTime: 0.109 ms
[shading] shading=gouraud: FPS: 9234 FrameTime: 0.108 ms
[shading] shading=blinn-phong-inf: FPS: 9255 FrameTime: 0.108 ms
[shading] shading=phong: FPS: 9226 FrameTime: 0.108 ms
[shading] shading=cel: FPS: 9310 FrameTime: 0.107 ms
[bump] bump-render=high-poly: FPS: 9298 FrameTime: 0.108 ms
[bump] bump-render=normals: FPS: 9121 FrameTime: 0.110 ms
[bump] bump-render=height: FPS: 9120 FrameTime: 0.110 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 9858 FrameTime: 0.101 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 9854 FrameTime: 
0.101 ms
[pulsar] light=false:quads=5:texture=false: FPS: 8468 FrameTime: 0.118 
ms

libpng warning: iCCP: known incorrect sRGB profile
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: 
FPS: 5181 FrameTime: 0.193 ms

libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 5374 FrameTime: 0.186 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 824 FrameTime: 1.214 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: 
FPS: 1114 FrameTime: 0.898 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 899 FrameTime: 1.112 ms

[ideas] speed=duration: FPS: 3485 FrameTime: 0.287 ms
[jellyfish] : FPS: 7992 FrameTime: 0.125 ms
[terrain] : FPS: 1796 FrameTime: 0.557 ms
[shadow] : FPS: 7350 FrameTime: 0.136 ms
[refract] : FPS: 3595 FrameTime: 0.278 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 9401 FrameTime: 
0.106 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 9413 FrameTime: 
0.106 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 9417 FrameTime: 
0.106 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 9365 
FrameTime: 0.107 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 9451 
FrameTime: 0.106 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 9300 
FrameTime: 0.108 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 9440 
FrameTime: 0.106 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 9392 
FrameTime: 0.106 ms

===
  glmark2 Score: 7455
===


Before
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 
4.20.0-rc3-1.g7262353-default+, LLVM 8.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.0.0-devel 
(git-c49b3df3cb)

===
[build] use-vbo=false: FPS: 3373 FrameTime: 0.296 ms
[build] use-vbo=true: FPS: 13121 FrameTime: 0.076 ms
[texture] texture-filter=nearest: FPS: 12172 FrameTime: 0.082 ms
[texture] texture-filter=linear: FPS: 12557 FrameTime: 0.080 ms
[texture] texture-filter=mipmap: FPS: 12228 FrameTime: 0.082 ms
[shading] shading=gouraud: FPS: 12536 FrameTime: 0.080 ms
[shading] shading=blinn-phong-inf: FPS: 12782 FrameTime: 0.078 ms
[shading] shading=phong: FPS: 12619 FrameTime: 0.079 ms
[shading] shading=cel: FPS: 12735 FrameTime: 0.079 ms
[bump] bump-render=high-poly: FPS: 11412 FrameTime: 0.088 ms
[bump] bump-render=normals: FPS: 12467 FrameTime: 0.080 ms
[bump] bump-render=height: FPS: 12422 FrameTime: 0.081 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 13252 FrameTime: 0.075 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 11468 FrameTime: 
0.087 ms
[pulsar] 

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

[Dieter Nützel]

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 (sctx->last_num_draw_calls != sctx->num_draw_calls) {
-   si_update_fb_dirtiness_after_rendering(sctx);
-   sctx->last_num_draw_calls = sctx->num_draw_calls;
-   }
+   if (sctx->has_graphics) {
+   if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
+   si_update_fb_dirtiness_after_rendering(sctx);
+   sctx->last_num_draw_calls = sctx->num_draw_calls;
+   }

-   si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+   si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+   }

/* Add buffer sizes for memory checking in need_cs_space. */
si_context_add_resource_size(sctx, >shader.bo->b.b);
/* TODO: add the scratch buffer */

if (info->indirect) {
si_context_add_resource_size(sctx, info->indirect);

/* Indirect buffers use TC L2 on GFX9, 

Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute

[Dieter Nützel]

Hello Marek,

do you plan to commit or rebase both set?

Dieter

Am 14.02.2019 07:29, schrieb Marek Olšák:

I have some fixes for Sea Islands that improve Radeon 290X performance
to 43 fps, moving it just below Radeon VII in the picture.

Marek

On Wed, Feb 13, 2019 at 12:16 AM Marek Olšák 
wrote:


Hi,

This patch series uses async compute to do primitive culling before
the vertex shader. It significantly improves performance for
applications
that use a lot of geometry that is invisible because primitives
don't
intersect sample points or there are a lot of back faces, etc.

It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100%
stable.
It supports all chips all the way from Sea Islands to Radeon VII.

As you can see in the results marked (ENABLED) in the picture below,
it destroys our competition (The GeForce results are from a Phoronix
article from 2017, the latest ones I could find):

Benchmark: ParaView - Many Spheres - 2560x1440
https://people.freedesktop.org/~mareko/prim-discard-cs-results.png

The last patch describes the implementation and functional
limitations
if you can find the huge code comment, so I'm not gonna do that
here.

I decided to enable this optimization on all Pro graphics cards.
The reason is that I haven't had time to benchmark games.
This decision may be changed based on community feedback, etc.

People using the Pro graphics cards can disable this by setting
AMD_DEBUG=nopd, and people using consumer graphics cards can enable
this by setting AMD_DEBUG=pd. So you always have a choice.

Eventually we might also enable this on consumer graphics cards for
those
games that benefit. It might decrease performance if there is not
enough
invisible geometry.

Branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs

Please review.

Thanks,
Marek

___
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 7/7] radeonsi: implement ARB/KHR_parallel_shader_compile callbacks

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

Do we have a (special) test in the wild?

Dieter

Am 25.02.2019 19:27, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.c | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index b965d9d64d4..7dbd4cb2c40 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -19,20 +19,21 @@
  * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT 
SHALL

  * THE AUTHOR(S) AND/OR THEIR 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.
  */

 #include "si_pipe.h"
 #include "si_public.h"
 #include "si_shader_internal.h"
+#include "si_compute.h"
 #include "sid.h"

 #include "ac_llvm_util.h"
 #include "radeon/radeon_uvd.h"
 #include "gallivm/lp_bld_misc.h"
 #include "util/disk_cache.h"
 #include "util/u_log.h"
 #include "util/u_memory.h"
 #include "util/u_suballoc.h"
 #include "util/u_tests.h"
@@ -826,20 +827,46 @@ static void si_disk_cache_create(struct
si_screen *sscreen)
 */
STATIC_ASSERT(ALL_FLAGS <= UINT_MAX);
shader_debug_flags |= (uint64_t)sscreen->info.address32_hi << 32;

sscreen->disk_shader_cache =
disk_cache_create(sscreen->info.name,
  cache_id,
  shader_debug_flags);
 }

+static void si_set_max_shader_compiler_threads(struct pipe_screen 
*screen,

+  unsigned max_threads)
+{
+   struct si_screen *sscreen = (struct si_screen *)screen;
+
+   /* This function doesn't allow a greater number of threads than
+* the queue had at its creation. */
+   util_queue_adjust_num_threads(>shader_compiler_queue,
+ max_threads);
+   /* Don't change the number of threads on the low priority queue. */
+}
+
+static bool si_is_parallel_shader_compilation_finished(struct
pipe_screen *screen,
+  void *shader,
+  unsigned shader_type)
+{
+   if (shader_type == PIPE_SHADER_COMPUTE) {
+   struct si_compute *cs = (struct si_compute*)shader;
+
+   return util_queue_fence_is_signalled(>ready);
+   }
+   struct si_shader_selector *sel = (struct si_shader_selector *)shader;
+
+   return util_queue_fence_is_signalled(>ready);
+}
+
 struct pipe_screen *radeonsi_screen_create(struct radeon_winsys *ws,
   const struct pipe_screen_config 
*config)
 {
struct si_screen *sscreen = CALLOC_STRUCT(si_screen);
unsigned hw_threads, num_comp_hi_threads, num_comp_lo_threads, i;

if (!sscreen) {
return NULL;
}

@@ -856,20 +883,24 @@ struct pipe_screen
*radeonsi_screen_create(struct radeon_winsys *ws,
}

sscreen->debug_flags = debug_get_flags_option("R600_DEBUG",
  debug_options, 0);
sscreen->debug_flags |= debug_get_flags_option("AMD_DEBUG",
   debug_options, 0);

/* Set functions first. */
sscreen->b.context_create = si_pipe_create_context;
sscreen->b.destroy = si_destroy_screen;
+   sscreen->b.set_max_shader_compiler_threads =
+   si_set_max_shader_compiler_threads;
+   sscreen->b.is_parallel_shader_compilation_finished =
+   si_is_parallel_shader_compilation_finished;

si_init_screen_get_functions(sscreen);
si_init_screen_buffer_functions(sscreen);
si_init_screen_fence_functions(sscreen);
si_init_screen_state_functions(sscreen);
si_init_screen_texture_functions(sscreen);
si_init_screen_query_functions(sscreen);

 	/* Set these flags in debug_flags early, so that the shader cache 
takes

 * them into account.

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

Re: [Mesa-dev] [PATCH 4/4] radeonsi: use SDMA for uploading data through const_uploader

[Dieter Nützel]

For the _rev2_ version (Patchwork Mesa) series is

Tested-by: Dieter Nützel 

on Polaris 20

UH+UV working flawlessly, now.
No 'measurable' speed decrease. - GREAT!
Blender, FreeCAD, glmark2 all fine.

But I had to have rebased part 4 (see attachment).

Dieter

Am 07.02.2019 02:22, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_buffer.c | 56 ++--
 src/gallium/drivers/radeonsi/si_dma_cs.c | 19 
 src/gallium/drivers/radeonsi/si_gfx_cs.c | 42 +++---
 src/gallium/drivers/radeonsi/si_pipe.c   | 23 ++
 src/gallium/drivers/radeonsi/si_pipe.h   | 17 +++
 5 files changed, 131 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_buffer.c
b/src/gallium/drivers/radeonsi/si_buffer.c
index c01118ce96a..3f8db7cf4f0 100644
--- a/src/gallium/drivers/radeonsi/si_buffer.c
+++ b/src/gallium/drivers/radeonsi/si_buffer.c
@@ -433,21 +433,29 @@ static void *si_buffer_transfer_map(struct
pipe_context *ctx,

if (si_invalidate_buffer(sctx, buf)) {
/* At this point, the buffer is always idle. */
usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
} else {
/* Fall back to a temporary buffer. */
usage |= PIPE_TRANSFER_DISCARD_RANGE;
}
}

-   if ((usage & PIPE_TRANSFER_DISCARD_RANGE) &&
+   if (usage & PIPE_TRANSFER_FLUSH_EXPLICIT &&
+	buf->b.b.flags & SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA) 
{

+   usage &= ~(PIPE_TRANSFER_UNSYNCHRONIZED |
+  PIPE_TRANSFER_PERSISTENT);
+   usage |= PIPE_TRANSFER_DISCARD_RANGE;
+   force_discard_range = true;
+   }
+
+   if (usage & PIPE_TRANSFER_DISCARD_RANGE &&
((!(usage & (PIPE_TRANSFER_UNSYNCHRONIZED |
 PIPE_TRANSFER_PERSISTENT))) ||
 (buf->flags & RADEON_FLAG_SPARSE))) {
assert(usage & PIPE_TRANSFER_WRITE);

/* Check if mapping this buffer would cause waiting for the GPU.
 */
if (buf->flags & RADEON_FLAG_SPARSE ||
force_discard_range ||
 		si_rings_is_buffer_referenced(sctx, buf->buf, 
RADEON_USAGE_READWRITE) ||

@@ -514,32 +522,72 @@ static void *si_buffer_transfer_map(struct
pipe_context *ctx,
data += box->x;

return si_buffer_get_transfer(ctx, resource, usage, box,
ptransfer, data, NULL, 0);
 }

 static void si_buffer_do_flush_region(struct pipe_context *ctx,
  struct pipe_transfer *transfer,
  const struct pipe_box *box)
 {
+   struct si_context *sctx = (struct si_context*)ctx;
struct si_transfer *stransfer = (struct si_transfer*)transfer;
struct si_resource *buf = si_resource(transfer->resource);

if (stransfer->staging) {
unsigned src_offset = stransfer->offset +
  transfer->box.x % SI_MAP_BUFFER_ALIGNMENT 
+
  (box->x - transfer->box.x);

+		if (buf->b.b.flags & 
SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA) {

+   /* This should be true for all uploaders. */
+   assert(transfer->box.x == 0);
+
+   /* Find a previous upload and extend its range. The last
+* upload is likely to be at the end of the list.
+*/
+   for (int i = sctx->num_sdma_uploads - 1; i >= 0; i--) {
+   struct si_sdma_upload *up = 
>sdma_uploads[i];
+
+   if (up->dst != buf)
+   continue;
+
+   assert(up->src == stransfer->staging);
+   assert(box->x > up->dst_offset);
+   up->size = box->x + box->width - up->dst_offset;
+   return;
+   }
+
+   /* Enlarge the array if it's full. */
+   if (sctx->num_sdma_uploads == sctx->max_sdma_uploads) {
+   unsigned size;
+
+   sctx->max_sdma_uploads += 4;
+   size = sctx->max_sdma_uploads * 
sizeof(sctx->sdma_uploads[0]);
+   sctx->sdma_uploads = 
realloc(sctx->sdma_uploads, size);
+   }
+
+   /* Add a new upload. */
+   struct si_sdma_upload *up =
+   >sdma_uploads[sctx->num_sdma_uploads++];
+   up->dst = u

Re: [Mesa-dev] radeonsi: NIR - Polaris triangle sprinkling running UH SOLVED - finally

[Dieter Nützel]

Am 16.02.2019 03:56, schrieb Timothy Arceri:

On 13/2/19 8:28 am, Dieter Nützel wrote:

Hello Marek, Timo, Nicolai,

Timo SOLVED this long-standing NIR corruption on Polaris with his 
'nir: rewrite varying component packing' commit.


It was triggered with

commit 86b52d42368ac496fe24bc6674e754c323381635
Author: Marek Olšák 
Date:   Fri Jul 13 00:23:36 2018 -0400

     radeonsi: reduce LDS stalls by 40% for tessellation

     40% is the decrease in the LGKM counter (which includes SMEM too)
     for the GFX9 LSHS stage.

     This will make the LDS size slightly larger, but I wasn't able to 
increase
     the patch stride without corruption, so I'm increasing the vertex 
stride.


and now finally SOLVED with

commit 26aa460940f6222565ad5eb40a21c2377c59c3a6
Author: Timothy Arceri 
Date:   Mon Dec 10 10:23:51 2018 +1100

     nir: rewrite varying component packing

     There are a number of reasons for the rewrite.

     1. Adding support for packing tess patch varyings in a sane way.

     2. Making use of qsort allowing the code to be much easier to
    follow.

     3. Fixes a bug where different interp types caused component
    packing to be skipped for all varyings in some scenarios.

     4. Allows us to add a crude live range analysis for deciding
    which components should be packed together. This support can
    optionally be added in a future patch.

     Reviewed-by: Jason Ekstrand 

Maybe it should backported (Cc: lists.freedesktop.org>) ) for 19.0?


I'd rather it didn't since NIR isn't default for radeonsi and this is
use for other drivers like RADV. I'd rather have more testing in the
dev branch.


Of course, your're right. - Running NIR to long...;-)

Dieter

BTW
'New' stuttering (shader compiler) with Rocket League went in.
Our son is unhappy. Have to dig (bisect).


This change really shouldn't fix anything, it could just be that the
change avoids the bug. I'm really not sure.

One thing this change did fix was a bug with doubles, but I wasn't
aware of anything actually using doubles so I doubt this is it.



I hope my bisect help to bring some more understanding for this 
Polaris NIR bug.


Now, hunting for the (last) 19.0+ EQAA regression (DiRT Rally, black 
squares like  radv/DXVK corruption, NOT NIR related) and 'meson' 
OpenCL (Clover) build error.


Greetings,
Dieter

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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Am 12.02.2019 05:10, schrieb Dieter Nützel:

Am 12.02.2019 03:22, schrieb Dieter Nützel:

Am 12.02.2019 00:40, schrieb Dieter Nützel:
Sorry that I step in so late, but the whole family recover slowly 
from

a bad flu...

Tried your 'latest" three series altogether with my Polaris 20 
(NIR!).

UH and UV hang after some seconds reliable. VM faults. Have to dig
deeper in (remote) to get some logs.


UH

[47001.185090] amdgpu :01:00.0: GPU fault detected: 147 0x0b384801
for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586
[47001.185094] amdgpu :01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0373EF67
[47001.185096] amdgpu :01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001
[47001.185098] amdgpu :01:00.0: VM fault (0x01, vmid 3, pasid
32786) at page 57929575, read from 'TC4' (0x54433400) (72)
[47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout, signaled seq=11380701, emitted seq=11380703
[47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process
information: process  pid 0 thread  pid 0
[47011.401787] amdgpu :01:00.0: GPU reset begin!
[47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR*
[CRTC:49:crtc-0] hw_done or flip_done timed out


These GPU faults are SOLVED after reverting the SDMA (1-4) series.


So I gave this a second change with LLVM 9.0 git.
+ some other patches

e83af67eed7 (HEAD -> master) ac: use new LLVM 8 intrinsic when loading 
16-bit values

7f32d569ffc ac: add ac_build_llvm8_tbuffer_load() helper
037bda54a7d nir: remove simple dead if detection from nir_opt_dead_cf()
51fe88ff1ab radeonsi/nir: set shader_buffers_declared properly
e66a73aa1a6 radeonsi/nir: set colors_read properly
83955dfc81a radeonsi/nir: set input_usage_mask properly
4c355a562db radeonsi: use SDMA for uploading data through const_uploader
6855f871e47 gallium/u_upload_mgr: allow use of FLUSH_EXPLICIT with 
persistent mappings

2116355fc01 gallium/u_threaded: always unmap const_uploader
6e70cce39f3 st/mesa: always unmap the uploader in st_atom_array.c
22a88ca1d92 radeonsi: re-initialize query buffers if they are reused
6775665e5ee (origin/master, origin/HEAD) spirv: Eliminate dead 
input/output variables after translation.


UH
run some sences but (same? - Yes.) GPU fault. - Shit, sadly overwritten 
my dmesg.log. :-(


UV
run some sences but (same? - Yes.) GPU fault.

Unigine Valley Benchmark 1.0 (1.0)Unigine~# world_load valley/valley
Loading "valley/valley.cpp" 126ms
Loading "valley/valley.mat" 72 materials 1160ms
Loading "valley/sound/sound.prop" 142 properties 1ms
Loading "valley/valley.world" 2253ms
valley_x64: ../src/gallium/auxiliary/util/u_inlines.h:81: 
pipe_reference_described: Assertion `count != 1' failed.


[ 1079.415836] amdgpu :01:00.0: GPU fault detected: 147 0x0ca04801 
for process valley_x64 pid 18050 thread valley_x64:cs0 pid 18071
[ 1079.415841] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
 0x094A9594
[ 1079.415842] amdgpu :01:00.0:   
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x08048001
[ 1079.415845] amdgpu :01:00.0: VM fault (0x01, vmid 4, pasid 32769) 
at page 155882900, read from 'TC4' (0x54433400) (72)
[ 1089.543336] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx 
timeout, signaled seq=91489, emitted seq=91491
[ 1089.543379] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process 
information: process valley_x64 pid 18050 thread valley_x64:cs0 pid 
18071

[ 1089.543382] amdgpu :01:00.0: GPU reset begin!
[ 1099.773342] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* 
[CRTC:49:crtc-0] hw_done or flip_done timed out


Hope that helps some.

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

Re: [Mesa-dev] [PATCH] nir: remove simple dead if detection from nir_opt_dead_cf()

[Dieter Nützel]

Tested-by: Dieter Nützel 

running together with
[Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute 
- V2

https://lists.freedesktop.org/archives/mesa-dev/2019-February/215240.html

Dieter

Am 14.02.2019 02:37, schrieb Timothy Arceri:

This was probably useful when it was first written, however it
looks to be no longer necessary.

As far as I can tell these days dce is smart enough to remove useless
instructions from if branches. Once this is done
nir_opt_peephole_select() will end up removing the empty if.

Removing this support reduces the dolphin uber shader compilation
time by around 60%. Compile time is reduced due to no longer having
to compute the live ssa defs metadata so much.

No shader-db changes on i965 or radeonsi.
---
 src/compiler/nir/nir_opt_dead_cf.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/src/compiler/nir/nir_opt_dead_cf.c
b/src/compiler/nir/nir_opt_dead_cf.c
index 14986732096..053c5743527 100644
--- a/src/compiler/nir/nir_opt_dead_cf.c
+++ b/src/compiler/nir/nir_opt_dead_cf.c
@@ -180,7 +180,7 @@ def_not_live_out(nir_ssa_def *def, void *state)
 }

 /*
- * Test if a loop node or if node is dead. Such nodes are dead if:
+ * Test if a loop node is dead. Such nodes are dead if:
  *
  * 1) It has no side effects (i.e. intrinsics which could possibly 
affect the
  * state of the program aside from producing an SSA value, indicated 
by a lack

@@ -198,7 +198,7 @@ def_not_live_out(nir_ssa_def *def, void *state)
 static bool
 node_is_dead(nir_cf_node *node)
 {
-   assert(node->type == nir_cf_node_loop || node->type == 
nir_cf_node_if);

+   assert(node->type == nir_cf_node_loop);

nir_block *before = nir_cf_node_as_block(nir_cf_node_prev(node));
nir_block *after = nir_cf_node_as_block(nir_cf_node_next(node));
@@ -230,11 +230,6 @@ dead_cf_block(nir_block *block)
 {
nir_if *following_if = nir_block_get_following_if(block);
if (following_if) {
-  if (node_is_dead(_if->cf_node)) {
- nir_cf_node_remove(_if->cf_node);
- return true;
-  }
-
   if (!nir_src_is_const(following_if->condition))
  return false;

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

Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute

[Dieter Nützel]

For the whole series (the updated branch merged in)

Tested-by: Dieter Nützel 

on Polaris 20

FreeCAD, Blender, UH, UV, US, some VTK apps
No surprising speed up but e.g. NO slowdown.

tb stands even for
[Mesa-dev] [PATCH 0/4] RadeonSI: Follow-up for the primitive culling 
series

too (but no SI, here).

mplayer / mpv works like a charm, again.

ParaView-5.6.0-MPI-Linux-64bit

1920x1080
pd off ~18 fps
pd on ~24 fps ! ;-)

2560x1440
pd off ~14 fps
pd on ~16 fps

./pvbatch 
../lib/python2.7/site-packages/paraview/benchmark/manyspheres.py -s 100 
-r 726 -v 1920,1080 -f 30


Is this right?

Poor
Intel Xeon X3470, 2.93 GHz, 3.2 GHz turbo, 4c/8t
24 GB
Polaris 20, 8 GB
PCIe 2.1 only (NO PCIe atomics)

Dieter

Am 14.02.2019 03:07, schrieb Marek Olšák:

I just updated the branch, fixing video players.

Marek

On Wed, Feb 13, 2019 at 8:28 PM Dieter Nützel 
wrote:


Now with LLVM 9.0 git;-)

Running, except mplayer/mpv (same as before).

mplayer: ../src/gallium/drivers/radeon/radeon_winsys.h:866:
radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"'

failed.
Abbruch (core dumped)

mpv: ../src/gallium/drivers/radeon/radeon_winsys.h:866:
radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"'

failed.
Abbruch (core dumped)

And this after glxgears, Blender, FreeCAD, UH and UV:

[38939.440950] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx

679c61fd is still alive
[38939.440993] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx
679c61fd is still alive
[38964.901076] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx

9c4b659b is still alive
[38964.901130] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx
9c4b659b is still alive
[38980.844577] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx

1bee3a35 is still alive
[38980.844642] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx
1bee3a35 is still alive

Newer 'amd-staging-drm-next' needed? #0bf64b0a9f78 currently

If I only had some big triangle apps...;-)

Dieter

Am 13.02.2019 17:36, schrieb Marek Olšák:

Dieter, you need final LLVM 8.0.

Marek

On Wed, Feb 13, 2019 at 11:02 AM Dieter Nützel



wrote:


GREAT stuff, Marek!

But sadly some crashes.
Is my LLVM git version to old?
7. Jan 2019 (short before 8.0 cut)

LLVM (http://llvm.org/):
LLVM version 8.0.0svn
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: nehalem

Registered Targets:
amdgcn - AMD GCN GPUs
r600   - AMD GPUs HD2XXX-HD6XXX
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64

Please have a look at my post @Phoronix:






https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984


Thanks,
Dieter

Am 13.02.2019 06:15, schrieb Marek Olšák:

Hi,

This patch series uses async compute to do primitive culling

before

the vertex shader. It significantly improves performance for
applications
that use a lot of geometry that is invisible because primitives

don't

intersect sample points or there are a lot of back faces, etc.

It passes 99.% of all tests (GL CTS, dEQP, piglit) and is

100%



stable.
It supports all chips all the way from Sea Islands to Radeon

VII.


As you can see in the results marked (ENABLED) in the picture

below,

it destroys our competition (The GeForce results are from a

Phoronix

article from 2017, the latest ones I could find):

Benchmark: ParaView - Many Spheres - 2560x1440


https://people.freedesktop.org/~mareko/prim-discard-cs-results.png



The last patch describes the implementation and functional

limitations

if you can find the huge code comment, so I'm not gonna do that

here.


I decided to enable this optimization on all Pro graphics cards.
The reason is that I haven't had time to benchmark games.
This decision may be changed based on community feedback, etc.

People using the Pro graphics cards can disable this by setting
AMD_DEBUG=nopd, and people using consumer graphics cards can

enable

this by setting AMD_DEBUG=pd. So you always have a choice.

Eventually we might also enable this on consumer graphics cards

for

those
games that benefit. It might decrease performance if there is

not

enough
invisible geometry.

Branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs

Please review.

Thanks,
Marek
___
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 00/26] RadeonSI: Primitive culling with async compute

[Dieter Nützel]

Got it (merged in), thanks.
But now I need some sleep.
Have to drive my wife to the hospital in a few hours.
No, not hyperacute.

Dieter

Am 14.02.2019 03:07, schrieb Marek Olšák:

I just updated the branch, fixing video players.

Marek

On Wed, Feb 13, 2019 at 8:28 PM Dieter Nützel 
wrote:


Now with LLVM 9.0 git;-)

Running, except mplayer/mpv (same as before).

mplayer: ../src/gallium/drivers/radeon/radeon_winsys.h:866:
radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"'

failed.
Abbruch (core dumped)

mpv: ../src/gallium/drivers/radeon/radeon_winsys.h:866:
radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"'

failed.
Abbruch (core dumped)

And this after glxgears, Blender, FreeCAD, UH and UV:

[38939.440950] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx

679c61fd is still alive
[38939.440993] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx
679c61fd is still alive
[38964.901076] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx

9c4b659b is still alive
[38964.901130] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx
9c4b659b is still alive
[38980.844577] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx

1bee3a35 is still alive
[38980.844642] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx
1bee3a35 is still alive

Newer 'amd-staging-drm-next' needed? #0bf64b0a9f78 currently

If I only had some big triangle apps...;-)

Dieter

Am 13.02.2019 17:36, schrieb Marek Olšák:

Dieter, you need final LLVM 8.0.

Marek

On Wed, Feb 13, 2019 at 11:02 AM Dieter Nützel



wrote:


GREAT stuff, Marek!

But sadly some crashes.
Is my LLVM git version to old?
7. Jan 2019 (short before 8.0 cut)

LLVM (http://llvm.org/):
LLVM version 8.0.0svn
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: nehalem

Registered Targets:
amdgcn - AMD GCN GPUs
r600   - AMD GPUs HD2XXX-HD6XXX
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64

Please have a look at my post @Phoronix:






https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984


Thanks,
Dieter

Am 13.02.2019 06:15, schrieb Marek Olšák:

Hi,

This patch series uses async compute to do primitive culling

before

the vertex shader. It significantly improves performance for
applications
that use a lot of geometry that is invisible because primitives

don't

intersect sample points or there are a lot of back faces, etc.

It passes 99.% of all tests (GL CTS, dEQP, piglit) and is

100%



stable.
It supports all chips all the way from Sea Islands to Radeon

VII.


As you can see in the results marked (ENABLED) in the picture

below,

it destroys our competition (The GeForce results are from a

Phoronix

article from 2017, the latest ones I could find):

Benchmark: ParaView - Many Spheres - 2560x1440


https://people.freedesktop.org/~mareko/prim-discard-cs-results.png



The last patch describes the implementation and functional

limitations

if you can find the huge code comment, so I'm not gonna do that

here.


I decided to enable this optimization on all Pro graphics cards.
The reason is that I haven't had time to benchmark games.
This decision may be changed based on community feedback, etc.

People using the Pro graphics cards can disable this by setting
AMD_DEBUG=nopd, and people using consumer graphics cards can

enable

this by setting AMD_DEBUG=pd. So you always have a choice.

Eventually we might also enable this on consumer graphics cards

for

those
games that benefit. It might decrease performance if there is

not

enough
invisible geometry.

Branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs

Please review.

Thanks,
Marek
___
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 v2 2/2] radeonsi/nir: set colors_read properly

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

on Polaris 20

Dieter

Am 12.02.2019 01:15, schrieb Timothy Arceri:

shader-db results for VEGA64:

Totals from affected shaders:
SGPRS: 1976 -> 1976 (0.00 %)
VGPRS: 1240 -> 1144 (-7.74 %)
Spilled SGPRs: 145 -> 145 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 34632 -> 34604 (-0.08 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 261 -> 285 (9.20 %)
Wait states: 0 -> 0 (0.00 %)
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 4eec57b406d..55a950a675c 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -74,9 +74,18 @@ static void gather_intrinsic_load_deref_info(const
nir_shader *nir,
}
break;
}
-   default:
+   default: {
+   unsigned semantic_name, semantic_index;
+   tgsi_get_gl_varying_semantic(var->data.location, true,
+_name, _index);
+
+   if (semantic_name == TGSI_SEMANTIC_COLOR) {
+   uint8_t mask = 
nir_ssa_def_components_read(>dest.ssa);
+   info->colors_read |= mask << (semantic_index * 4);
+   }
break;
}
+   }
 }

 static void scan_instruction(const struct nir_shader *nir,

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

Re: [Mesa-dev] [PATCH] radeonsi/nir: set shader_buffers_declared properly

[Dieter Nützel]

Tested-by: Dieter Nützel 

Am 12.02.2019 04:46, schrieb Timothy Arceri:

---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 55a950a675c..c547f5f1c30 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -687,10 +687,15 @@ void si_nir_scan_shader(const struct nir_shader 
*nir,


struct set *ubo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
   _mesa_key_pointer_equal);
+   struct set *ssbo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);

/* Intialise const_file_max[0] */
info->const_file_max[0] = -1;

+   /* The first 8 are reserved for atomic counters using ssbo */
+   unsigned ssbo_idx = 8;
+
unsigned ubo_idx = 1;
nir_foreach_variable(variable, >uniforms) {
const struct glsl_type *type = variable->type;
@@ -705,12 +710,16 @@ void si_nir_scan_shader(const struct nir_shader 
*nir,

 */
if (variable->interface_type != NULL) {
if (variable->data.mode == nir_var_uniform ||
-   variable->data.mode == nir_var_mem_ubo) {
+   variable->data.mode == nir_var_mem_ubo ||
+   variable->data.mode == nir_var_mem_ssbo) {
+
+   struct set *buf_set = variable->data.mode == 
nir_var_mem_ssbo ?
+   ssbo_set : ubo_set;

unsigned block_count;
if (base_type != GLSL_TYPE_INTERFACE) {
struct set_entry *entry =
-   _mesa_set_search(ubo_set, 
variable->interface_type);
+   _mesa_set_search(buf_set, 
variable->interface_type);

/* Check if we have already processed
 * a member from this ubo.
@@ -723,16 +732,18 @@ void si_nir_scan_shader(const struct nir_shader 
*nir,

block_count = aoa_size;
}

-info->const_buffers_declared |= u_bit_consecutive(ubo_idx, 
block_count);

-   ubo_idx += block_count;
+   if (variable->data.mode == nir_var_uniform ||
+   variable->data.mode == nir_var_mem_ubo) {
+	info->const_buffers_declared |= u_bit_consecutive(ubo_idx, 
block_count);

+   ubo_idx += block_count;
+   } else {
+   assert(variable->data.mode == 
nir_var_mem_ssbo);

-   _mesa_set_add(ubo_set, 
variable->interface_type);
-   }
+	info->shader_buffers_declared |= u_bit_consecutive(ssbo_idx, 
block_count);

+   ssbo_idx += block_count;
+   }

-   if (variable->data.mode == nir_var_mem_ssbo) {
-   /* TODO: make this more accurate */
-   info->shader_buffers_declared =
-   u_bit_consecutive(0, 
SI_NUM_SHADER_BUFFERS);
+   _mesa_set_add(buf_set, 
variable->interface_type);
}

continue;
@@ -776,6 +787,7 @@ void si_nir_scan_shader(const struct nir_shader 
*nir,

}

_mesa_set_destroy(ubo_set, NULL);
+   _mesa_set_destroy(ssbo_set, NULL);

info->num_written_clipdistance = nir->info.clip_distance_array_size;
info->num_written_culldistance = nir->info.cull_distance_array_size;

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

Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute

[Dieter Nützel]

Now with LLVM 9.0 git;-)

Running, except mplayer/mpv (same as before).

mplayer: ../src/gallium/drivers/radeon/radeon_winsys.h:866: 
radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' 
failed.

Abbruch (core dumped)

mpv: ../src/gallium/drivers/radeon/radeon_winsys.h:866: 
radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' 
failed.

Abbruch (core dumped)

And this after glxgears, Blender, FreeCAD, UH and UV:

[38939.440950] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 
679c61fd is still alive
[38939.440993] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 
679c61fd is still alive
[38964.901076] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 
9c4b659b is still alive
[38964.901130] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 
9c4b659b is still alive
[38980.844577] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 
1bee3a35 is still alive
[38980.844642] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 
1bee3a35 is still alive


Newer 'amd-staging-drm-next' needed? #0bf64b0a9f78 currently

If I only had some big triangle apps...;-)

Dieter

Am 13.02.2019 17:36, schrieb Marek Olšák:

Dieter, you need final LLVM 8.0.

Marek

On Wed, Feb 13, 2019 at 11:02 AM Dieter Nützel 
wrote:


GREAT stuff, Marek!

But sadly some crashes.
Is my LLVM git version to old?
7. Jan 2019 (short before 8.0 cut)

LLVM (http://llvm.org/):
LLVM version 8.0.0svn
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: nehalem

Registered Targets:
amdgcn - AMD GCN GPUs
r600   - AMD GPUs HD2XXX-HD6XXX
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64

Please have a look at my post @Phoronix:


https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984


Thanks,
Dieter

Am 13.02.2019 06:15, schrieb Marek Olšák:

Hi,

This patch series uses async compute to do primitive culling

before

the vertex shader. It significantly improves performance for
applications
that use a lot of geometry that is invisible because primitives

don't

intersect sample points or there are a lot of back faces, etc.

It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100%



stable.
It supports all chips all the way from Sea Islands to Radeon VII.

As you can see in the results marked (ENABLED) in the picture

below,

it destroys our competition (The GeForce results are from a

Phoronix

article from 2017, the latest ones I could find):

Benchmark: ParaView - Many Spheres - 2560x1440
https://people.freedesktop.org/~mareko/prim-discard-cs-results.png


The last patch describes the implementation and functional

limitations

if you can find the huge code comment, so I'm not gonna do that

here.


I decided to enable this optimization on all Pro graphics cards.
The reason is that I haven't had time to benchmark games.
This decision may be changed based on community feedback, etc.

People using the Pro graphics cards can disable this by setting
AMD_DEBUG=nopd, and people using consumer graphics cards can

enable

this by setting AMD_DEBUG=pd. So you always have a choice.

Eventually we might also enable this on consumer graphics cards

for

those
games that benefit. It might decrease performance if there is not
enough
invisible geometry.

Branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs

Please review.

Thanks,
Marek
___
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 00/26] RadeonSI: Primitive culling with async compute

[Dieter Nützel]

GREAT stuff, Marek!

But sadly some crashes.
Is my LLVM git version to old?
7. Jan 2019 (short before 8.0 cut)

LLVM (http://llvm.org/):
  LLVM version 8.0.0svn
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: nehalem

  Registered Targets:
amdgcn - AMD GCN GPUs
r600   - AMD GPUs HD2XXX-HD6XXX
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64

Please have a look at my post @Phoronix:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984

Thanks,
Dieter

Am 13.02.2019 06:15, schrieb Marek Olšák:

Hi,

This patch series uses async compute to do primitive culling before
the vertex shader. It significantly improves performance for 
applications

that use a lot of geometry that is invisible because primitives don't
intersect sample points or there are a lot of back faces, etc.

It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100% 
stable.

It supports all chips all the way from Sea Islands to Radeon VII.

As you can see in the results marked (ENABLED) in the picture below,
it destroys our competition (The GeForce results are from a Phoronix
article from 2017, the latest ones I could find):

Benchmark: ParaView - Many Spheres - 2560x1440
https://people.freedesktop.org/~mareko/prim-discard-cs-results.png


The last patch describes the implementation and functional limitations
if you can find the huge code comment, so I'm not gonna do that here.

I decided to enable this optimization on all Pro graphics cards.
The reason is that I haven't had time to benchmark games.
This decision may be changed based on community feedback, etc.

People using the Pro graphics cards can disable this by setting
AMD_DEBUG=nopd, and people using consumer graphics cards can enable
this by setting AMD_DEBUG=pd. So you always have a choice.

Eventually we might also enable this on consumer graphics cards for 
those
games that benefit. It might decrease performance if there is not 
enough

invisible geometry.

Branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs

Please review.

Thanks,
Marek
___
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] radeonsi: NIR - Polaris triangle sprinkling running UH SOLVED - finally

[Dieter Nützel]

Hello Marek, Timo, Nicolai,

Timo SOLVED this long-standing NIR corruption on Polaris with his 'nir: 
rewrite varying component packing' commit.


It was triggered with

commit 86b52d42368ac496fe24bc6674e754c323381635
Author: Marek Olšák 
Date:   Fri Jul 13 00:23:36 2018 -0400

radeonsi: reduce LDS stalls by 40% for tessellation

40% is the decrease in the LGKM counter (which includes SMEM too)
for the GFX9 LSHS stage.

This will make the LDS size slightly larger, but I wasn't able to 
increase
the patch stride without corruption, so I'm increasing the vertex 
stride.


and now finally SOLVED with

commit 26aa460940f6222565ad5eb40a21c2377c59c3a6
Author: Timothy Arceri 
Date:   Mon Dec 10 10:23:51 2018 +1100

nir: rewrite varying component packing

There are a number of reasons for the rewrite.

1. Adding support for packing tess patch varyings in a sane way.

2. Making use of qsort allowing the code to be much easier to
   follow.

3. Fixes a bug where different interp types caused component
   packing to be skipped for all varyings in some scenarios.

4. Allows us to add a crude live range analysis for deciding
   which components should be packed together. This support can
   optionally be added in a future patch.

Reviewed-by: Jason Ekstrand 

Maybe it should backported (Cc: ) 
) for 19.0?


I hope my bisect help to bring some more understanding for this Polaris 
NIR bug.


Now, hunting for the (last) 19.0+ EQAA regression (DiRT Rally, black 
squares like  radv/DXVK corruption, NOT NIR related) and 'meson' OpenCL 
(Clover) build error.


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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Sorry that I step in so late, but the whole family recover slowly from a 
bad flu...


Tried your 'latest" three series altogether with my Polaris 20 (NIR!).
UH and UV hang after some seconds reliable. VM faults. Have to dig 
deeper in (remote) to get some logs.


But my reported Polaris triangle corruptions are solved, now.
W'll try to verify which patches fixed it.

Look here:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079319-running-the-radeonsi-nir-back-end-with-mesa-19-1-git?p=1079390#post1079390

Greetings,
Dieter

Am 07.02.2019 02:21, schrieb Marek Olšák:

Hi,

This patch series increases radeonsi performance in some cases.
glxgears performance decreases slightly.

Visible VRAM is usually congested due to CPU accesses, which cause
buffers to be evicted from that part of VRAM. This removes
the congestion for all data pushed into const_uploader.

We have had many problems with const_uploader slowing stuff down due
to visible VRAM congestion. The most recent one is this Starcraft 2
issue report on github:

https://github.com/iXit/Mesa-3D/issues/333

Since const_uploader reuses buffers from the winsys buffer cache,
the odds are that the reused buffers are already evicted, so the first
use is usually slower due to higher shader load latencies.

This series uses SDMA to get constants into VRAM, so it doesn't have
any of the above drawbacks.

SC2 numbers with various other methods (from the github issue report):
- originally: 50-55 fps
- changing const_uploader to STREAM: 75-80 fps
- use stream_uploader for constants in Nine: 90 fps
- this series: 105-110 fps

Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that wasn't
there before.

CPU-bound apps with many IBs are almost unaffected thanks to winsys
multithreading.

Feedback welcome,

Thanks,
Marek
___
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: use compute for clear_render_target when possible

[Dieter Nützel]

Maybe rebase?

Dieter

Am 24.01.2019 00:28, schrieb Marek Olšák:

From: Sonny Jiang 

Signed-off-by: Sonny Jiang 
Signed-off-by: Marek Olšák 
---
 src/gallium/drivers/radeonsi/si_clear.c   |  6 ++
 .../drivers/radeonsi/si_compute_blit.c| 96 +++
 src/gallium/drivers/radeonsi/si_pipe.c|  4 +
 src/gallium/drivers/radeonsi/si_pipe.h|  9 ++
 .../drivers/radeonsi/si_shaderlib_tgsi.c  | 69 +
 5 files changed, 184 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_clear.c
b/src/gallium/drivers/radeonsi/si_clear.c
index b3910a4651c..8afc01f2ccc 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -664,20 +664,26 @@ static void si_clear(struct pipe_context *ctx,
unsigned buffers,
 }

 static void si_clear_render_target(struct pipe_context *ctx,
   struct pipe_surface *dst,
   const union pipe_color_union *color,
   unsigned dstx, unsigned dsty,
   unsigned width, unsigned height,
   bool render_condition_enabled)
 {
struct si_context *sctx = (struct si_context *)ctx;
+   struct si_texture *sdst = (struct si_texture*)dst->texture;
+
+   if (dst->texture->nr_samples <= 1 && !sdst->dcc_offset) {
+		si_compute_clear_render_target(ctx, dst, color, dstx, dsty, width, 
height);

+   return;
+   }

si_blitter_begin(sctx, SI_CLEAR_SURFACE |
 (render_condition_enabled ? 0 : 
SI_DISABLE_RENDER_COND));
util_blitter_clear_render_target(sctx->blitter, dst, color,
 dstx, dsty, width, height);
si_blitter_end(sctx);
 }

 static void si_clear_depth_stencil(struct pipe_context *ctx,
   struct pipe_surface *dst,
diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c
b/src/gallium/drivers/radeonsi/si_compute_blit.c
index 38c48c30be9..f06497f4dac 100644
--- a/src/gallium/drivers/radeonsi/si_compute_blit.c
+++ b/src/gallium/drivers/radeonsi/si_compute_blit.c
@@ -18,20 +18,21 @@
  * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT 
SHALL

  * THE AUTHOR(S) AND/OR THEIR 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.
  *
  */

 #include "si_pipe.h"
 #include "util/u_format.h"
+#include "util/format_srgb.h"

 /* Note: Compute shaders always use SI_COMPUTE_DST_CACHE_POLICY for 
dst

  * and L2_STREAM for src.
  */
 static enum si_cache_policy get_cache_policy(struct si_context *sctx,
 enum si_coherency coher,
 uint64_t size)
 {
if ((sctx->chip_class >= GFX9 && (coher == SI_COHERENCY_CB_META ||
  coher == SI_COHERENCY_CP)) ||
@@ -418,10 +419,105 @@ void si_compute_copy_image(struct si_context 
*sctx,

ctx->bind_compute_state(ctx, saved_cs);
ctx->set_shader_images(ctx, PIPE_SHADER_COMPUTE, 0, 2, saved_image);
ctx->set_constant_buffer(ctx, PIPE_SHADER_COMPUTE, 0, _cb);
si_compute_internal_end(sctx);
 }

 void si_init_compute_blit_functions(struct si_context *sctx)
 {
sctx->b.clear_buffer = si_pipe_clear_buffer;
 }
+
+/* Clear a region of a color surface to a constant value. */
+void si_compute_clear_render_target(struct pipe_context *ctx,
+   struct pipe_surface *dstsurf,
+   const union pipe_color_union *color,
+   unsigned dstx, unsigned dsty,
+   unsigned width, unsigned height)
+{
+   struct si_context *sctx = (struct si_context *)ctx;
+   unsigned num_layers = dstsurf->u.tex.last_layer -
dstsurf->u.tex.first_layer + 1;
+   unsigned data[4 + sizeof(color->ui)] = {dstx, dsty,
dstsurf->u.tex.first_layer, 0};
+
+   if (width == 0 || height == 0)
+   return;
+
+   if (util_format_is_srgb(dstsurf->format)) {
+   union pipe_color_union color_srgb;
+   for (int i = 0; i < 3; i++)
+   color_srgb.f[i] = 
util_format_linear_to_srgb_float(color->f[i]);
+   color_srgb.f[3] = color->f[3];
+   memcpy(data + 4, color_srgb.ui, sizeof(color->ui));
+   } else {
+   memcpy(data + 4, color->ui, sizeof(color->ui));
+   }
+
+   si_compute_internal_begin(sctx);
+   sctx->flags |= SI_CONTEXT_CS_PARTIAL_FLUSH |
+  si_get_flush_flags(sctx, SI_COHERENCY_SHADER, L2_STREAM);
+   si_make_CB_shader_coherent(sctx, dstsurf->texture->nr_samples, true);
+
+   struct pipe_constant_buffer saved_cb = 

Re: [Mesa-dev] [PATCH] radeonsi: re-initialize query buffers if they are reused

[Dieter Nützel]

Tested-by: Dieter Nützel 

Calmed mostly some hiccups with Rocket League which our son found around 
XMass on Polaris. All was fine after additional Mesa git clean ups.


Thanks,
Dieter

Am 26.01.2019 01:58, schrieb Marek Olšák:

From: Marek Olšák 

Fixes: e0f0d3675d4 "radeonsi: factor si_query_buffer logic out of 
si_query_hw"

---
 src/gallium/drivers/radeonsi/si_query.c | 20 
 src/gallium/drivers/radeonsi/si_query.h |  1 +
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_query.c
b/src/gallium/drivers/radeonsi/si_query.c
index 266b9d3ce84..c115e7787b2 100644
--- a/src/gallium/drivers/radeonsi/si_query.c
+++ b/src/gallium/drivers/radeonsi/si_query.c
@@ -542,34 +542,46 @@ void si_query_buffer_reset(struct si_context
*sctx, struct si_query_buffer *buff
while (buffer->previous) {
struct si_query_buffer *qbuf = buffer->previous;
buffer->previous = qbuf->previous;

si_resource_reference(>buf, NULL);
buffer->buf = qbuf->buf; /* move ownership */
FREE(qbuf);
}
buffer->results_end = 0;

+   if (!buffer->buf)
+   return;
+
 	/* Discard even the oldest buffer if it can't be mapped without a 
stall. */

-   if (buffer->buf &&
-   (si_rings_is_buffer_referenced(sctx, buffer->buf->buf,
RADEON_USAGE_READWRITE) ||
-	 !sctx->ws->buffer_wait(buffer->buf->buf, 0, 
RADEON_USAGE_READWRITE))) {

+   if (si_rings_is_buffer_referenced(sctx, buffer->buf->buf,
RADEON_USAGE_READWRITE) ||
+	!sctx->ws->buffer_wait(buffer->buf->buf, 0, 
RADEON_USAGE_READWRITE)) {

si_resource_reference(>buf, NULL);
+   } else {
+   /* Re-initialize it before begin. */
+   buffer->prepare_buffer_before_begin = true;
}
 }

 bool si_query_buffer_alloc(struct si_context *sctx, struct
si_query_buffer *buffer,
 			   bool (*prepare_buffer)(struct si_context *, struct 
si_query_buffer*),

   unsigned size)
 {
-	if (buffer->buf && buffer->results_end + size >= 
buffer->buf->b.b.width0)
+	if (buffer->buf && buffer->results_end + size >= 
buffer->buf->b.b.width0) {

+   if (buffer->prepare_buffer_before_begin &&
+   prepare_buffer && unlikely(!prepare_buffer(sctx, buffer))) {
+   si_resource_reference(>buf, NULL);
+   return false;
+   }
+   buffer->prepare_buffer_before_begin = false;
return true;
+   }

if (buffer->buf) {
struct si_query_buffer *qbuf = MALLOC_STRUCT(si_query_buffer);
memcpy(qbuf, buffer, sizeof(*qbuf));
buffer->previous = qbuf;
}

buffer->results_end = 0;

/* Queries are normally read by the CPU after
diff --git a/src/gallium/drivers/radeonsi/si_query.h
b/src/gallium/drivers/radeonsi/si_query.h
index aaf0bd03aca..be393c2fbd2 100644
--- a/src/gallium/drivers/radeonsi/si_query.h
+++ b/src/gallium/drivers/radeonsi/si_query.h
@@ -170,20 +170,21 @@ struct si_query_hw_ops {
  struct si_resource *buffer, uint64_t va);
 	void (*clear_result)(struct si_query_hw *, union pipe_query_result 
*);

void (*add_result)(struct si_screen *screen,
   struct si_query_hw *, void *buffer,
   union pipe_query_result *result);
 };

 struct si_query_buffer {
/* The buffer where query results are stored. */
struct si_resource  *buf;
+   boolprepare_buffer_before_begin;
/* Offset of the next free result after current query data */
unsignedresults_end;
/* If a query buffer is full, a new buffer is created and the old one
 	 * is put in here. When we calculate the result, we sum up the 
samples

 * from all buffers. */
struct si_query_buffer  *previous;
 };

 void si_query_buffer_destroy(struct si_screen *sctx, struct
si_query_buffer *buffer);
 void si_query_buffer_reset(struct si_context *sctx, struct
si_query_buffer *buffer);

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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Am 12.02.2019 03:22, schrieb Dieter Nützel:

Am 12.02.2019 00:40, schrieb Dieter Nützel:

Sorry that I step in so late, but the whole family recover slowly from
a bad flu...

Tried your 'latest" three series altogether with my Polaris 20 (NIR!).
UH and UV hang after some seconds reliable. VM faults. Have to dig
deeper in (remote) to get some logs.


UH

[47001.185090] amdgpu :01:00.0: GPU fault detected: 147 0x0b384801
for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586
[47001.185094] amdgpu :01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0373EF67
[47001.185096] amdgpu :01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001
[47001.185098] amdgpu :01:00.0: VM fault (0x01, vmid 3, pasid
32786) at page 57929575, read from 'TC4' (0x54433400) (72)
[47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout, signaled seq=11380701, emitted seq=11380703
[47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process
information: process  pid 0 thread  pid 0
[47011.401787] amdgpu :01:00.0: GPU reset begin!
[47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR*
[CRTC:49:crtc-0] hw_done or flip_done timed out


These GPU faults are SOLVED after reverting the SDMA (1-4) series.


But my reported Polaris triangle corruptions are solved, now.


These reported (last year) triangle corruptions are SOLVED _before_ all 
of these patches. GREAT!



W'll try to verify which patches fixed it.


If I have more time then I'll try to find the corresponding patch/fix.

Cheers,
Dieter


Look here:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079319-running-the-radeonsi-nir-back-end-with-mesa-19-1-git?p=1079390#post1079390

Greetings,
Dieter

Am 07.02.2019 02:21, schrieb Marek Olšák:

Hi,

This patch series increases radeonsi performance in some cases.
glxgears performance decreases slightly.

Visible VRAM is usually congested due to CPU accesses, which cause
buffers to be evicted from that part of VRAM. This removes
the congestion for all data pushed into const_uploader.

We have had many problems with const_uploader slowing stuff down due
to visible VRAM congestion. The most recent one is this Starcraft 2
issue report on github:

https://github.com/iXit/Mesa-3D/issues/333

Since const_uploader reuses buffers from the winsys buffer cache,
the odds are that the reused buffers are already evicted, so the 
first

use is usually slower due to higher shader load latencies.

This series uses SDMA to get constants into VRAM, so it doesn't have
any of the above drawbacks.

SC2 numbers with various other methods (from the github issue 
report):

- originally: 50-55 fps
- changing const_uploader to STREAM: 75-80 fps
- use stream_uploader for constants in Nine: 90 fps
- this series: 105-110 fps

Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that wasn't
there before.

CPU-bound apps with many IBs are almost unaffected thanks to winsys
multithreading.

Feedback welcome,

Thanks,
Marek
___
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 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Am 12.02.2019 00:40, schrieb Dieter Nützel:

Sorry that I step in so late, but the whole family recover slowly from
a bad flu...

Tried your 'latest" three series altogether with my Polaris 20 (NIR!).
UH and UV hang after some seconds reliable. VM faults. Have to dig
deeper in (remote) to get some logs.


UH

[47001.185090] amdgpu :01:00.0: GPU fault detected: 147 0x0b384801 
for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586
[47001.185094] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
 0x0373EF67
[47001.185096] amdgpu :01:00.0:   
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001
[47001.185098] amdgpu :01:00.0: VM fault (0x01, vmid 3, pasid 32786) 
at page 57929575, read from 'TC4' (0x54433400) (72)
[47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx 
timeout, signaled seq=11380701, emitted seq=11380703
[47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process 
information: process  pid 0 thread  pid 0

[47011.401787] amdgpu :01:00.0: GPU reset begin!
[47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* 
[CRTC:49:crtc-0] hw_done or flip_done timed out



But my reported Polaris triangle corruptions are solved, now.
W'll try to verify which patches fixed it.

Look here:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079319-running-the-radeonsi-nir-back-end-with-mesa-19-1-git?p=1079390#post1079390

Greetings,
Dieter

Am 07.02.2019 02:21, schrieb Marek Olšák:

Hi,

This patch series increases radeonsi performance in some cases.
glxgears performance decreases slightly.

Visible VRAM is usually congested due to CPU accesses, which cause
buffers to be evicted from that part of VRAM. This removes
the congestion for all data pushed into const_uploader.

We have had many problems with const_uploader slowing stuff down due
to visible VRAM congestion. The most recent one is this Starcraft 2
issue report on github:

https://github.com/iXit/Mesa-3D/issues/333

Since const_uploader reuses buffers from the winsys buffer cache,
the odds are that the reused buffers are already evicted, so the first
use is usually slower due to higher shader load latencies.

This series uses SDMA to get constants into VRAM, so it doesn't have
any of the above drawbacks.

SC2 numbers with various other methods (from the github issue report):
- originally: 50-55 fps
- changing const_uploader to STREAM: 75-80 fps
- use stream_uploader for constants in Nine: 90 fps
- this series: 105-110 fps

Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that wasn't
there before.

CPU-bound apps with many IBs are almost unaffected thanks to winsys
multithreading.

Feedback welcome,

Thanks,
Marek
___
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/6] st/nine: Use helper to release swapchain buffers later

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

(with my 'normal' apps) ;-)

+ LS2015 (D3D9) under Wine Staging Nine 4.0-rc2
nice numbers

Dieter

Am 16.12.2018 22:25, schrieb Axel Davy:

This patch introduces a structure to release the
present_handles only when they are fully released
by the server, thus making
"DestroyD3DWindowBuffer" actually release the buffer
right away when called.

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/swapchain9.c | 49 
 src/gallium/state_trackers/nine/swapchain9.h |  1 +
 2 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/nine/swapchain9.c
b/src/gallium/state_trackers/nine/swapchain9.c
index d330c855726..138e8816a05 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -128,6 +128,40 @@ D3DWindowBuffer_create(struct NineSwapChain9 
*This,

 return ret;
 }

+static void
+D3DWindowBuffer_release(struct NineSwapChain9 *This,
+D3DWindowBuffer *present_handle)
+{
+int i;
+/* Add it to the 'pending release' list */
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (!This->present_handles_pending_release[i]) {
+This->present_handles_pending_release[i] = present_handle;
+break;
+}
+}
+if (i == (D3DPRESENT_BACK_BUFFERS_MAX_EX + 1)) {
+ERR("Server not releasing buffers...\n");
+assert(false);
+}
+
+/* Destroy elements of the list released by the server */
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (This->present_handles_pending_release[i] &&
+ID3DPresent_IsBufferReleased(This->present,
This->present_handles_pending_release[i])) {
+/* WaitBufferReleased also waits the presentation feedback
+ * (which should arrive at about the same time),
+ * while IsBufferReleased doesn't. DestroyD3DWindowBuffer
unfortunately
+ * checks it to release immediately all data, else the 
release

+ * is postponed for This->present release. To avoid leaks
(we may handle
+ * a lot of resize), call WaitBufferReleased. */
+ID3DPresent_WaitBufferReleased(This->present,
This->present_handles_pending_release[i]);
+ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles_pending_release[i]);
+This->present_handles_pending_release[i] = NULL;
+}
+}
+}
+
 static int
 NineSwapChain9_GetBackBufferCountForParams( struct NineSwapChain9 
*This,
 D3DPRESENT_PARAMETERS 
*pParams );

@@ -291,7 +325,7 @@ NineSwapChain9_Resize( struct NineSwapChain9 *This,
 This->enable_threadpool = FALSE;

 for (i = 0; i < oldBufferCount; i++) {
-ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles[i]);
+D3DWindowBuffer_release(This, This->present_handles[i]);
 This->present_handles[i] = NULL;
 if (This->present_buffers[i])
 pipe_resource_reference(&(This->present_buffers[i]), 
NULL);

@@ -519,6 +553,11 @@ NineSwapChain9_dtor( struct NineSwapChain9 *This )
 FREE(This->pending_presentation[i]);
 }

+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (This->present_handles_pending_release[i])
+ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles_pending_release[i]);
+}
+
 for (i = 0; i < This->num_back_buffers; i++) {
 if (This->buffers[i])
 NineUnknown_Detach(NineUnknown(This->buffers[i]));
@@ -738,13 +777,7 @@ present( struct NineSwapChain9 *This,
 create_present_buffer(This, target_width, target_height,
_resource, _handle);
 /* Switch to the new buffer */
 if (new_handle) {
-/* WaitBufferReleased also waits the presentation 
feedback,

- * while IsBufferReleased doesn't.
DestroyD3DWindowBuffer unfortunately
- * checks it to release immediately all data, else the 
release

- * is postponed for This->present release. To avoid
leaks (we may handle
- * a lot of resize), call WaitBufferReleased. */
-ID3DPresent_WaitBufferReleased(This->present,
This->present_handles[0]);
-ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles[0]);
+D3DWindowBuffer_release(This, 
This->present_handles[0]);

 This->present_handles[0] = new_handle;
 pipe_resource_reference(>present_buffers[0],
new_resource);
 pipe_resource_reference(_resource, NULL);
diff --git a/src/gallium/state_trackers/nine/swapchain9.h
b/src/gallium/state_trackers/nine/swapch

Re: [Mesa-dev] [PATCH v2 1/5] st/glsl_to_nir: call nir_lower_load_const_to_scalar() in the st

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

(with my 'normal' apps) ;-)

Dieter

Am 19.12.2018 11:03, schrieb Timothy Arceri:

This will help the new opt introduced in the following patches
allowing us to remove extra duplicate varyings.

Reviewed-by: Marek Olšák 
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 2 --
 src/mesa/state_tracker/st_glsl_to_nir.cpp| 4 +++-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 0a692277f6..3883337b00 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -823,8 +823,6 @@ si_lower_nir(struct si_shader_selector* sel)

ac_lower_indirect_derefs(sel->nir, sel->screen->info.chip_class);

-   NIR_PASS_V(sel->nir, nir_lower_load_const_to_scalar);
-
bool progress;
do {
progress = false;
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index ed9f643e89..5176756433 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -702,8 +702,10 @@ st_link_nir(struct gl_context *ctx,

   nir_shader *nir = shader->Program->nir;

-  if (is_scalar[i])
+  if (is_scalar[i]) {
  NIR_PASS_V(nir, nir_lower_io_to_scalar_early, mask);
+ NIR_PASS_V(nir, nir_lower_load_const_to_scalar);
+  }

   st_nir_opts(nir, is_scalar[i]);
}

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

Re: [Mesa-dev] [PATCH 1/3] radeonsi: remove unrequired param in si_nir_scan_tess_ctrl()

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

(with my 'normal' apps) ;-)

Dieter

Am 18.12.2018 02:17, schrieb Timothy Arceri:

---
 src/gallium/drivers/radeonsi/si_shader.h| 1 -
 src/gallium/drivers/radeonsi/si_shader_nir.c| 1 -
 src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gallium/drivers/radeonsi/si_shader.h
index f71e601574..cdb57958dd 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -708,7 +708,6 @@ const char *si_get_shader_name(const struct
si_shader *shader, unsigned processo
 void si_nir_scan_shader(const struct nir_shader *nir,
struct tgsi_shader_info *info);
 void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
-  const struct tgsi_shader_info *info,
   struct tgsi_tessctrl_info *out);
 void si_lower_nir(struct si_shader_selector *sel);

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 660b5bc356..b81bea00b8 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -278,7 +278,6 @@ static void scan_instruction(struct 
tgsi_shader_info *info,

 }

 void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
-  const struct tgsi_shader_info *info,
   struct tgsi_tessctrl_info *out)
 {
memset(out, 0, sizeof(*out));
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index de00df60ae..2d5d163247 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -2238,7 +2238,7 @@ static void *si_create_shader_selector(struct
pipe_context *ctx,
sel->nir = state->ir.nir;

si_nir_scan_shader(sel->nir, >info);
-   si_nir_scan_tess_ctrl(sel->nir, >info, >tcs_info);
+   si_nir_scan_tess_ctrl(sel->nir, >tcs_info);

si_lower_nir(sel);
}

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

Re: [Mesa-dev] [PATCH 1/6] radeonsi: don't emit redundant PKT3_NUM_INSTANCES packets

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

(with my 'normal' apps) ;-)

Dieter

Am 14.12.2018 22:23, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.h   | 3 +++
 src/gallium/drivers/radeonsi/si_state_draw.c | 9 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.h
b/src/gallium/drivers/radeonsi/si_pipe.h
index 1d677d29e88..b3522b60752 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -40,20 +40,21 @@

 #define ATI_VENDOR_ID  0x1002

 #define SI_NOT_QUERY   0x

 /* The base vertex and primitive restart can be any number, but we 
must pick

  * one which will mean "unknown" for the purpose of state tracking and
  * the number shouldn't be a commonly-used one. */
 #define SI_BASE_VERTEX_UNKNOWN INT_MIN
 #define SI_RESTART_INDEX_UNKNOWN   INT_MIN
+#define SI_INSTANCE_COUNT_UNKNOWN  INT_MIN
 #define SI_NUM_SMOOTH_AA_SAMPLES   8
 #define SI_MAX_POINT_SIZE  2048
 #define SI_GS_PER_ES   128
 /* Alignment for optimal CP DMA performance. */
 #define SI_CPDMA_ALIGNMENT 32

 /* Tunables for compute-based clear_buffer and copy_buffer: */
 #define SI_COMPUTE_CLEAR_DW_PER_THREAD 4
 #define SI_COMPUTE_COPY_DW_PER_THREAD  4
 #define SI_COMPUTE_DST_CACHE_POLICYL2_STREAM
@@ -918,20 +919,21 @@ struct si_context {
booldb_stencil_disable_expclear:1;
boolocclusion_queries_disabled:1;
boolgenerate_mipmap_for_depth:1;

/* Emitted draw state. */
boolgs_tri_strip_adj_fix:1;
boolls_vgpr_fix:1;
int last_index_size;
int last_base_vertex;
int last_start_instance;
+   int last_instance_count;
int last_drawid;
int last_sh_base_reg;
int last_primitive_restart_en;
int last_restart_index;
int last_prim;
int last_multi_vgt_param;
int last_rast_prim;
unsignedlast_sc_line_stipple;
unsignedcurrent_vs_state;
unsignedlast_vs_state;
@@ -1369,20 +1371,21 @@ si_context_add_resource_size(struct si_context
*sctx, struct pipe_resource *r)
/* Add memory usage for need_gfx_cs_space */
sctx->vram += r600_resource(r)->vram_usage;
sctx->gtt += r600_resource(r)->gart_usage;
}
 }

 static inline void
 si_invalidate_draw_sh_constants(struct si_context *sctx)
 {
sctx->last_base_vertex = SI_BASE_VERTEX_UNKNOWN;
+   sctx->last_instance_count = SI_INSTANCE_COUNT_UNKNOWN;
 }

 static inline unsigned
 si_get_atom_bit(struct si_context *sctx, struct si_atom *atom)
 {
return 1 << (atom - sctx->atoms.array);
 }

 static inline void
 si_set_atom_dirty(struct si_context *sctx, struct si_atom *atom, bool 
dirty)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 612ca910cb9..b707a6585c5 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -802,24 +802,29 @@ static void si_emit_draw_packets(struct 
si_context *sctx,

radeon_emit(cs, ((sh_base_reg + SI_SGPR_DRAWID * 4 -
SI_SH_REG_OFFSET) >> 2) |
S_2C3_DRAW_INDEX_ENABLE(1) |

S_2C3_COUNT_INDIRECT_ENABLE(!!indirect->indirect_draw_count));
radeon_emit(cs, indirect->draw_count);
radeon_emit(cs, count_va);
radeon_emit(cs, count_va >> 32);
radeon_emit(cs, indirect->stride);
radeon_emit(cs, di_src_sel);
}
} else {
+   unsigned instance_count = info->instance_count;
int base_vertex;

-   radeon_emit(cs, PKT3(PKT3_NUM_INSTANCES, 0, 0));
-   radeon_emit(cs, info->instance_count);
+   if (sctx->last_instance_count == SI_INSTANCE_COUNT_UNKNOWN ||
+   sctx->last_instance_count != instance_count) {
+   radeon_emit(cs, PKT3(PKT3_NUM_INSTANCES, 0, 0));
+   radeon_emit(cs, instance_count);
+   sctx->last_instance_count = instance_count;
+   }

/* Base vertex and start instance. */
base_vertex = index_size ? info->index_bias : info->start;

if (sctx->num_vs_blit_s

Re: [Mesa-dev] nir/algebraic: Generalize an optimization - RADV / DXVK 0.93+0.94 regression with LS2019

[Dieter Nützel]

Replying myself:

FIXED with Ian's

nir/algebraic: Don't put quotes around floating point literals
commit #96c4b135e34d0804e41bfbc28fc1b5050c49d71e

Thanks!

Dieter

Am 19.12.2018 06:36, schrieb Dieter Nützel:

Sorry guys,

but my son got a RADV + DXVK 0.93 and 0.94 (D3D11) regression running
brand new LS2019
(https://www.farming-simulator.com/?lang=en=us) on our Polaris
20. All heaven textures are gone and some others are wrong.

git bisect bad 445867c80d
git bisect good e4f9a37ace

/opt/mesa> git bisect good
615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5 is the first bad commit
commit 615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5
Author: Jason Ekstrand 
Date:   Thu Dec 6 12:56:33 2018 -0600

nir/algebraic: Generalize an optimization

This just makes it nicely scale across bit sizes.

Reviewed-by: Eric Anholt 
Reviewed-by: Bas Nieuwenhuizen 
Tested-by: Bas Nieuwenhuizen 

:04 04 ced4299ecdd6d76755839c9a0af11417e5f4973a
321e0c0e1c985c49c4e0b37f766c4a68c4ca145f M src

But git revert 615cc26b97 alone do NOT help.

Have to file a ticket after some sleep...;-)

Greetings,
Dieter
___
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] nir/algebraic: Generalize an optimization - RADV / DXVK 0.93+0.94 regression with LS2019

[Dieter Nützel]

Sorry guys,

but my son got a RADV + DXVK 0.93 and 0.94 (D3D11) regression running 
brand new LS2019 (https://www.farming-simulator.com/?lang=en=us) 
on our Polaris 20. All heaven textures are gone and some others are 
wrong.


git bisect bad 445867c80d
git bisect good e4f9a37ace

/opt/mesa> git bisect good
615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5 is the first bad commit
commit 615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5
Author: Jason Ekstrand 
Date:   Thu Dec 6 12:56:33 2018 -0600

nir/algebraic: Generalize an optimization

This just makes it nicely scale across bit sizes.

Reviewed-by: Eric Anholt 
Reviewed-by: Bas Nieuwenhuizen 
Tested-by: Bas Nieuwenhuizen 

:04 04 ced4299ecdd6d76755839c9a0af11417e5f4973a 
321e0c0e1c985c49c4e0b37f766c4a68c4ca145f M src


But git revert 615cc26b97 alone do NOT help.

Have to file a ticket after some sleep...;-)

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

Re: [Mesa-dev] [PATCH 1/2] radeonsi: don't send data after write-confirm with BOTTOM_OF_PIPE_TS

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

mpv drops notably, apart that '--vo=opengl-hq' isn't available any 
longer. Was replaced by '--vo=gpu'.


Dieter

Am 13.11.2018 22:23, schrieb Marek Olšák:

From: Marek Olšák 

There are no writes.
---
 src/gallium/drivers/radeonsi/si_fence.c   | 3 +--
 src/gallium/drivers/radeonsi/si_perfcounter.c | 3 +--
 src/gallium/drivers/radeonsi/si_query.c   | 8 +++-
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_fence.c
b/src/gallium/drivers/radeonsi/si_fence.c
index 3f22ee31ae8..d385f445774 100644
--- a/src/gallium/drivers/radeonsi/si_fence.c
+++ b/src/gallium/drivers/radeonsi/si_fence.c
@@ -270,22 +270,21 @@ static void si_fine_fence_set(struct si_context 
*ctx,

radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
S_370_WR_CONFIRM(1) |
S_370_ENGINE_SEL(V_370_PFP));
radeon_emit(cs, fence_va);
radeon_emit(cs, fence_va >> 32);
radeon_emit(cs, 0x8000);
} else if (flags & PIPE_FLUSH_BOTTOM_OF_PIPE) {
si_cp_release_mem(ctx,
  V_028A90_BOTTOM_OF_PIPE_TS, 0,
- EOP_DST_SEL_MEM,
- EOP_INT_SEL_SEND_DATA_AFTER_WR_CONFIRM,
+ EOP_DST_SEL_MEM, EOP_INT_SEL_NONE,
  EOP_DATA_SEL_VALUE_32BIT,
  NULL, fence_va, 0x8000,
  PIPE_QUERY_GPU_FINISHED);
} else {
assert(false);
}
 }

 static boolean si_fence_finish(struct pipe_screen *screen,
   struct pipe_context *ctx,
diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index 2ca6d2d7410..cea7d57e518 100644
--- a/src/gallium/drivers/radeonsi/si_perfcounter.c
+++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
@@ -574,22 +574,21 @@ static void si_pc_emit_start(struct si_context 
*sctx,

 }

 /* Note: The buffer was already added in si_pc_emit_start, so we don't 
have to

  * do it again in here. */
 static void si_pc_emit_stop(struct si_context *sctx,
struct r600_resource *buffer, uint64_t va)
 {
struct radeon_cmdbuf *cs = sctx->gfx_cs;

si_cp_release_mem(sctx, V_028A90_BOTTOM_OF_PIPE_TS, 0,
- EOP_DST_SEL_MEM,
- EOP_INT_SEL_SEND_DATA_AFTER_WR_CONFIRM,
+ EOP_DST_SEL_MEM, EOP_INT_SEL_NONE,
  EOP_DATA_SEL_VALUE_32BIT,
  buffer, va, 0, SI_NOT_QUERY);
si_cp_wait_mem(sctx, va, 0, 0x, 0);

radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
 	radeon_emit(cs, EVENT_TYPE(V_028A90_PERFCOUNTER_SAMPLE) | 
EVENT_INDEX(0));

radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
 	radeon_emit(cs, EVENT_TYPE(V_028A90_PERFCOUNTER_STOP) | 
EVENT_INDEX(0));

radeon_set_uconfig_reg(cs, R_036020_CP_PERFMON_CNTL,
   S_036020_PERFMON_STATE(V_036020_STOP_COUNTING) |
diff --git a/src/gallium/drivers/radeonsi/si_query.c
b/src/gallium/drivers/radeonsi/si_query.c
index 9b09c74d48a..21b9aeeac28 100644
--- a/src/gallium/drivers/radeonsi/si_query.c
+++ b/src/gallium/drivers/radeonsi/si_query.c
@@ -883,23 +883,22 @@ static void si_query_hw_do_emit_stop(struct
si_context *sctx,
break;
case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
va += 16;
for (unsigned stream = 0; stream < SI_MAX_STREAMS; ++stream)
emit_sample_streamout(cs, va + 32 * stream, stream);
break;
case PIPE_QUERY_TIME_ELAPSED:
va += 8;
/* fall through */
case PIPE_QUERY_TIMESTAMP:
-   si_cp_release_mem(sctx, V_028A90_BOTTOM_OF_PIPE_TS,
- 0, EOP_DST_SEL_MEM,
- EOP_INT_SEL_SEND_DATA_AFTER_WR_CONFIRM,
+   si_cp_release_mem(sctx, V_028A90_BOTTOM_OF_PIPE_TS, 0,
+ EOP_DST_SEL_MEM, EOP_INT_SEL_NONE,
  EOP_DATA_SEL_TIMESTAMP, NULL, va,
  0, query->b.type);
fence_va = va + 8;
break;
case PIPE_QUERY_PIPELINE_STATISTICS: {
unsigned sample_size = (query->result_size - 8) / 2;

va += sample_size;
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 2, 0));
 		radeon_emit(cs, EVENT_TYPE(V_028A90_SAMPLE_PIPELINESTAT) | 
EVENT_INDEX(2));

@@ -910,22 +909,21 @@ static void si_query_hw_do_emit_stop(struct
si_context *sctx,
break;
}
default:
  

Re: [Mesa-dev] [radeonsi] Blender/vsraytrace/fsraytrace/gsraytrace - GPUShader: compile error

[Dieter Nützel]

I can confirm, that adding

-fno-store-merging

looks like a workaround, but with 20-33% (!!!) speed decrease (most 
(synthetic) benchmarks) and bigger files.


Cheers,
Dieter

Am 13.11.2018 04:59, schrieb Dieter Nützel:

GREAT hint Tim!

Yes, of course.

/home/dieter> gcc --version
gcc (SUSE Linux) 8.2.1 20181025 [gcc-8-branch revision 265488]

So I have to ping SUSE to push the fix, too.

Thanks a lot.

Dieter

Am 12.11.2018 08:28, schrieb Timothy Arceri:
I'm guessing your using GCC 8.2.1 to compile Mesa? There was a 
compiler bug:


https://bugzilla.redhat.com/show_bug.cgi?id=1645400

On 12/11/18 2:11 pm, Dieter Nützel wrote:

Hello,

I get brocken shaders with Blender and the above demos didn't start
any longer.

NOT NIR related.
Have to start bisect.

OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 
4.19.0-rc1-1.g7262353-default+, LLVM 8.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 
19.0.0-devel (git-590fcb50e7)

OpenGL core profile shading language version string: 4.50

mesa-demos/glsl> blender
Read prefs: /home/dieter/.config/blender/2.79/config/userpref.blend
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

libGL: pci id for fd 16: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/local/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/local/lib64/dri/radeonsi_dri.so
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
Read blend: /data/Blender/BMW3v2.blend
2.66 versioning fix: replacing black sky with premultiplied alpha for 
scene Scene

Read blend: /data/Blender/BMW27GE.blend
GPUShader: compile error:
0:1177(22): error: invalid input layout qualifier used
[-]

Read blend: /data/Blender/BMW27.blend
skipping driver '100*power', automatic scripts are disabled
skipping driver '-100*power', automatic scripts are disabled
skipping driver '-90*brake', automatic scripts are disabled
skipping driver '90*brake', automatic scripts are disabled
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

Read blend: /data/Blender/sanisidro.blend
Read blend: /data/Blender/bh.blend
Info: Read library:  '/projeto.blend', '//../../projeto.blend', 
parent ''

Warning: Cannot find lib '/projeto.blend'
Warning: LIB: Group: 'Projeto' missing from '/projeto.blend', parent 
''
Info: Read library:  '/projeto.blend', '//../../projeto.blend', 
parent ''

Warning: Unable to open '/projeto.blend': No such file or directory
Warning: Cannot find lib '/projeto.blend'
Warning: LIB: Group: 'Projeto' missing from '/projeto.blend', parent 
''


GPUShader: compile error:
0:1177(22): error: invalid input layout qualifier used
[-]

mesa-demos/glsl> ./fsraytrace
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

libGL: pci id for fd 4: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/local/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/local/lib64/dri/radeonsi_dri.so
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
Error: problem compiling shader: 0:48(2): error: invalid input layout 
qualifier used


Same with 'vsraytrace' and 'gsraytrace'.

Thanks,
Dieter
___
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] [radeonsi] Blender/vsraytrace/fsraytrace/gsraytrace - GPUShader: compile error

[Dieter Nützel]

GREAT hint Tim!

Yes, of course.

/home/dieter> gcc --version
gcc (SUSE Linux) 8.2.1 20181025 [gcc-8-branch revision 265488]

So I have to ping SUSE to push the fix, too.

Thanks a lot.

Dieter

Am 12.11.2018 08:28, schrieb Timothy Arceri:
I'm guessing your using GCC 8.2.1 to compile Mesa? There was a compiler 
bug:


https://bugzilla.redhat.com/show_bug.cgi?id=1645400

On 12/11/18 2:11 pm, Dieter Nützel wrote:

Hello,

I get brocken shaders with Blender and the above demos didn't start
any longer.

NOT NIR related.
Have to start bisect.

OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 
4.19.0-rc1-1.g7262353-default+, LLVM 8.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 
19.0.0-devel (git-590fcb50e7)

OpenGL core profile shading language version string: 4.50

mesa-demos/glsl> blender
Read prefs: /home/dieter/.config/blender/2.79/config/userpref.blend
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

libGL: pci id for fd 16: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/local/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/local/lib64/dri/radeonsi_dri.so
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
Read blend: /data/Blender/BMW3v2.blend
2.66 versioning fix: replacing black sky with premultiplied alpha for 
scene Scene

Read blend: /data/Blender/BMW27GE.blend
GPUShader: compile error:
0:1177(22): error: invalid input layout qualifier used
[-]

Read blend: /data/Blender/BMW27.blend
skipping driver '100*power', automatic scripts are disabled
skipping driver '-100*power', automatic scripts are disabled
skipping driver '-90*brake', automatic scripts are disabled
skipping driver '90*brake', automatic scripts are disabled
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

Read blend: /data/Blender/sanisidro.blend
Read blend: /data/Blender/bh.blend
Info: Read library:  '/projeto.blend', '//../../projeto.blend', parent 
''

Warning: Cannot find lib '/projeto.blend'
Warning: LIB: Group: 'Projeto' missing from '/projeto.blend', parent 
''
Info: Read library:  '/projeto.blend', '//../../projeto.blend', parent 
''

Warning: Unable to open '/projeto.blend': No such file or directory
Warning: Cannot find lib '/projeto.blend'
Warning: LIB: Group: 'Projeto' missing from '/projeto.blend', parent 
''


GPUShader: compile error:
0:1177(22): error: invalid input layout qualifier used
[-]

mesa-demos/glsl> ./fsraytrace
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

libGL: pci id for fd 4: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/local/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/local/lib64/dri/radeonsi_dri.so
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such 
file or directory.

usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
Error: problem compiling shader: 0:48(2): error: invalid input layout 
qualifier used


Same with 'vsraytrace' and 'gsraytrace'.

Thanks,
Dieter
___
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] [radeonsi] Blender/vsraytrace/fsraytrace/gsraytrace - GPUShader: compile error

[Dieter Nützel]

Hello,

I get brocken shaders with Blender and the above demos didn't start
any longer.

NOT NIR related.
Have to start bisect.

OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 
4.19.0-rc1-1.g7262353-default+, LLVM 8.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel 
(git-590fcb50e7)

OpenGL core profile shading language version string: 4.50

mesa-demos/glsl> blender
Read prefs: /home/dieter/.config/blender/2.79/config/userpref.blend
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.

libGL: pci id for fd 16: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/local/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/local/lib64/dri/radeonsi_dri.so
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.

usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
Read blend: /data/Blender/BMW3v2.blend
2.66 versioning fix: replacing black sky with premultiplied alpha for 
scene Scene

Read blend: /data/Blender/BMW27GE.blend
GPUShader: compile error:
0:1177(22): error: invalid input layout qualifier used
[-]

Read blend: /data/Blender/BMW27.blend
skipping driver '100*power', automatic scripts are disabled
skipping driver '-100*power', automatic scripts are disabled
skipping driver '-90*brake', automatic scripts are disabled
skipping driver '90*brake', automatic scripts are disabled
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.

Read blend: /data/Blender/sanisidro.blend
Read blend: /data/Blender/bh.blend
Info: Read library:  '/projeto.blend', '//../../projeto.blend', parent 
''

Warning: Cannot find lib '/projeto.blend'
Warning: LIB: Group: 'Projeto' missing from '/projeto.blend', parent 
''
Info: Read library:  '/projeto.blend', '//../../projeto.blend', parent 
''

Warning: Unable to open '/projeto.blend': No such file or directory
Warning: Cannot find lib '/projeto.blend'
Warning: LIB: Group: 'Projeto' missing from '/projeto.blend', parent 
''


GPUShader: compile error:
0:1177(22): error: invalid input layout qualifier used
[-]

mesa-demos/glsl> ./fsraytrace
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.

libGL: pci id for fd 4: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/local/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/local/lib64/dri/radeonsi_dri.so
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.
libGL: Can't open configuration file /usr/local/etc/drirc: No such file 
or directory.

usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
Error: problem compiling shader: 0:48(2): error: invalid input layout 
qualifier used


Same with 'vsraytrace' and 'gsraytrace'.

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

Re: [Mesa-dev] [PATCH 1/2] gallium: add PIPE_CONTEXT_LOSE_CONTEXT_ON_RESET

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

Dieter

Am 02.11.2018 21:10, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/include/pipe/p_defines.h | 3 +++
 src/mesa/state_tracker/st_manager.c  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index dacedf5b936..693f041b1da 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -394,20 +394,23 @@ enum pipe_flush_flags
 /**
  * Create a high priority context.
  */
 #define PIPE_CONTEXT_HIGH_PRIORITY (1 << 4)

 /**
  * Create a low priority context.
  */
 #define PIPE_CONTEXT_LOW_PRIORITY  (1 << 5)

+/** Stop execution if the device is reset. */
+#define PIPE_CONTEXT_LOSE_CONTEXT_ON_RESET (1 << 6)
+
 /**
  * Flags for pipe_context::memory_barrier.
  */
 #define PIPE_BARRIER_MAPPED_BUFFER (1 << 0)
 #define PIPE_BARRIER_SHADER_BUFFER (1 << 1)
 #define PIPE_BARRIER_QUERY_BUFFER  (1 << 2)
 #define PIPE_BARRIER_VERTEX_BUFFER (1 << 3)
 #define PIPE_BARRIER_INDEX_BUFFER  (1 << 4)
 #define PIPE_BARRIER_CONSTANT_BUFFER   (1 << 5)
 #define PIPE_BARRIER_INDIRECT_BUFFER   (1 << 6)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index eb0b88ef473..bf5493190c8 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -881,20 +881,23 @@ st_api_create_context(struct st_api *stapi,
struct st_manager *smapi,
   ctx_flags |= PIPE_CONTEXT_ROBUST_BUFFER_ACCESS;

if (attribs->flags & ST_CONTEXT_FLAG_NO_ERROR)
   no_error = true;

if (attribs->flags & ST_CONTEXT_FLAG_LOW_PRIORITY)
   ctx_flags |= PIPE_CONTEXT_LOW_PRIORITY;
else if (attribs->flags & ST_CONTEXT_FLAG_HIGH_PRIORITY)
   ctx_flags |= PIPE_CONTEXT_HIGH_PRIORITY;

+   if (attribs->flags & ST_CONTEXT_FLAG_RESET_NOTIFICATION_ENABLED)
+  ctx_flags |= PIPE_CONTEXT_LOSE_CONTEXT_ON_RESET;
+
pipe = smapi->screen->context_create(smapi->screen, NULL, 
ctx_flags);

if (!pipe) {
   *error = ST_CONTEXT_ERROR_NO_MEMORY;
   return NULL;
}

st_visual_to_context_mode(>visual, );

if (attribs->visual.no_config)
   mode_ptr = NULL;

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

Re: [Mesa-dev] [PATCH] winsys/amdgpu: Stop using amdgpu_bo_handle_type_kms_noimport

[Dieter Nützel]

Tested-by: Dieter Nützel 

Bugzilla: https://bugs.freedesktop.org/108096
is (code)FIXED with this.

Thank you very much, Michel!

Dieter

Am 01.11.2018 12:31, schrieb Michel Dänzer:

From: Michel Dänzer 

It only behaves any different from amdgpu_bo_handle_type_kms with
libdrm 2.4.93, and it breaks if an older version is picked up.

Bugzilla: https://bugs.freedesktop.org/108096
Signed-off-by: Michel Dänzer 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index 68f0562a644..f49fb47b80e 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -486,7 +486,7 @@ static struct amdgpu_winsys_bo
*amdgpu_create_bo(struct amdgpu_winsys *ws,
else if (initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align64(size, ws->info.gart_page_size);

-   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
>u.real.kms_handle);
+   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms, 
>u.real.kms_handle);


amdgpu_add_buffer_to_global_list(bo);

@@ -1355,7 +1355,7 @@ static struct pb_buffer
*amdgpu_bo_from_handle(struct radeon_winsys *rws,
else if (bo->initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align64(bo->base.size, 
ws->info.gart_page_size);


-   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
>u.real.kms_handle);
+   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms, 
>u.real.kms_handle);


amdgpu_add_buffer_to_global_list(bo);

@@ -1463,7 +1463,7 @@ static struct pb_buffer
*amdgpu_bo_from_ptr(struct radeon_winsys *rws,

 amdgpu_add_buffer_to_global_list(bo);

-amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
>u.real.kms_handle);
+amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms,
>u.real.kms_handle);

 return (struct pb_buffer*)bo;

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

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

[Dieter Nützel]

Tested-by: Dieter Nützel 

Thanks!

Dieter

Am 01.11.2018 19:52, schrieb 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" : "",

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

Re: [Mesa-dev] [PATCH 1/2] radeonsi: use better DCC clear codes

[Dieter Nützel]

Tested-by: Dieter Nützel 

I only have Polaris 20...;-)

Am 30.10.2018 21:03, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_clear.c | 26 -
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_clear.c
b/src/gallium/drivers/radeonsi/si_clear.c
index 8aa3355afc8..2900c31fd21 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -27,20 +27,29 @@

 #include "util/u_format.h"
 #include "util/u_pack_color.h"
 #include "util/u_surface.h"

 enum {
SI_CLEAR = SI_SAVE_FRAGMENT_STATE,
SI_CLEAR_SURFACE = SI_SAVE_FRAMEBUFFER | SI_SAVE_FRAGMENT_STATE,
 };

+enum si_dcc_clear_code
+{
+DCC_CLEAR_COLOR_ = 0x,
+DCC_CLEAR_COLOR_0001 = 0x40404040,
+DCC_CLEAR_COLOR_1110 = 0x80808080,
+DCC_CLEAR_COLOR_ = 0xC0C0C0C0,
+DCC_CLEAR_COLOR_REG  = 0x20202020,
+};
+
 static void si_alloc_separate_cmask(struct si_screen *sscreen,
struct si_texture *tex)
 {
if (tex->cmask_buffer || !tex->surface.cmask_size)
 return;

tex->cmask_buffer =
si_aligned_buffer_create(>b,
 SI_RESOURCE_FLAG_UNMAPPABLE,
 PIPE_USAGE_DEFAULT,
@@ -126,21 +135,21 @@ static bool vi_get_fast_clear_parameters(enum
pipe_format base_format,
const struct util_format_description *desc =
util_format_description(si_simplify_cb_format(surface_format));

/* 128-bit fast clear with different R,G,B values is unsupported. */
if (desc->block.bits == 128 &&
(color->ui[0] != color->ui[1] ||
 color->ui[0] != color->ui[2]))
return false;

*eliminate_needed = true;
-   *clear_value = 0x20202020U; /* use CB clear color registers */
+   *clear_value = DCC_CLEAR_COLOR_REG;

if (desc->layout != UTIL_FORMAT_LAYOUT_PLAIN)
return true; /* need ELIMINATE_FAST_CLEAR */

bool base_alpha_is_on_msb = vi_alpha_is_on_msb(base_format);
bool surf_alpha_is_on_msb = vi_alpha_is_on_msb(surface_format);

/* Formats with 3 channels can't have alpha. */
if (desc->nr_channels == 3)
alpha_channel = -1;
@@ -201,24 +210,31 @@ static bool vi_get_fast_clear_parameters(enum
pipe_format base_format,
values[i] != color_value)
return true; /* require ELIMINATE_FAST_CLEAR */
}

/* This doesn't need ELIMINATE_FAST_CLEAR.
 * CB uses both the DCC clear codes and the CB clear color registers,
 * so they must match.
 */
*eliminate_needed = false;

-   if (color_value)
-   *clear_value |= 0x80808080U;
-   if (alpha_value)
-   *clear_value |= 0x40404040U;
+   if (color_value) {
+   if (alpha_value)
+   *clear_value = DCC_CLEAR_COLOR_;
+   else
+   *clear_value = DCC_CLEAR_COLOR_1110;
+   } else {
+   if (alpha_value)
+   *clear_value = DCC_CLEAR_COLOR_0001;
+   else
+   *clear_value = DCC_CLEAR_COLOR_;
+   }
return true;
 }

 void vi_dcc_clear_level(struct si_context *sctx,
struct si_texture *tex,
unsigned level, unsigned clear_value)
 {
struct pipe_resource *dcc_buffer;
uint64_t dcc_offset, clear_size;

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

Re: [Mesa-dev] EXT_gpu_shader4 / GL_EXT_gpu_shader4.mbox

[Dieter Nützel]

Hello Marek,

better late then...

Tested-by: Dieter Nützel 

Merged it into current git (0ff1ccca25).
Do you need any special tests?

Dieter

Am 08.09.2018 00:06, schrieb Marek Olšák:

Hi Dieter,

Here:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=ext_gpu_shader4

Marek

On Tue, Sep 4, 2018 at 8:43 PM, Dieter Nützel  
wrote:

Hello Marek,

what about

GL_EXT_gpu_shader4.mbox
and
mesa-only-allow-EXT_gpu_shader4-in-the-compatibility-profile.mbox

2cond
gallium-split-depth_clip-into-depth_clip_near-depth_clip_far.mbox

didn't apply any longer, but I've tested it before latest commits, so

tb for that, from me.

Thanks,
Dieter

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

Re: [Mesa-dev] [PATCH 00/15] A bunch of shared code and RadeonSI changes

[Dieter Nützel]

GREAT work Marek!

Best speed up for months on Polaris 20, at least.
Coming from vacation with injured right ankle joint, so I haven't had 
time for testing before commit. But 'glmark2' numbers are better than 
before all the Spectre shit (~8-9%?!).


In German: 'Da geht noch was...' ;-)

Greetings,
Dieter

===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.26.0, 
4.18.14-1.gce1c446-default, LLVM 8.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 18.3.0-devel 
(git-58a51d0a67)

===
[build] use-vbo=false: FPS: 3382 FrameTime: 0.296 ms
[build] use-vbo=true: FPS: 11679 FrameTime: 0.086 ms
[texture] texture-filter=nearest: FPS: 11607 FrameTime: 0.086 ms
[texture] texture-filter=linear: FPS: 11572 FrameTime: 0.086 ms
[texture] texture-filter=mipmap: FPS: 11676 FrameTime: 0.086 ms
[shading] shading=gouraud: FPS: 12207 FrameTime: 0.082 ms
[shading] shading=blinn-phong-inf: FPS: 11892 FrameTime: 0.084 ms
[shading] shading=phong: FPS: 12073 FrameTime: 0.083 ms
[shading] shading=cel: FPS: 11763 FrameTime: 0.085 ms
[bump] bump-render=high-poly: FPS: 11252 FrameTime: 0.089 ms
[bump] bump-render=normals: FPS: 11366 FrameTime: 0.088 ms
[bump] bump-render=height: FPS: 11226 FrameTime: 0.089 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 12171 FrameTime: 0.082 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 11314 FrameTime: 
0.088 ms
[pulsar] light=false:quads=5:texture=false: FPS: 10452 FrameTime: 0.096 
ms

libpng warning: iCCP: known incorrect sRGB profile
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: 
FPS: 5506 FrameTime: 0.182 ms

libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 5864 FrameTime: 0.171 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 812 FrameTime: 1.232 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: 
FPS: 1128 FrameTime: 0.887 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 893 FrameTime: 1.120 ms

[ideas] speed=duration: FPS: 2999 FrameTime: 0.333 ms
[jellyfish] : FPS: 9422 FrameTime: 0.106 ms
[terrain] : FPS: 1787 FrameTime: 0.560 ms
[shadow] : FPS: 8930 FrameTime: 0.112 ms
[refract] : FPS: 3418 FrameTime: 0.293 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 11901 FrameTime: 
0.084 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 11567 FrameTime: 
0.086 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 11614 FrameTime: 
0.086 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 11611 
FrameTime: 0.086 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 11643 
FrameTime: 0.086 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 11933 
FrameTime: 0.084 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 
11964 FrameTime: 0.084 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 11714 
FrameTime: 0.085 ms

===
  glmark2 Score: 9101
===

Before, even with DRM 3.27.0 (amd-staging-drm-next) I had

glmark2 Score: 8361

Am 03.10.2018 00:35, schrieb Marek Olšák:

Hi,

Interesting bits:
- CP DMA support for GDS (unused but there is a test)
- switch back to DX sample positions
- center the viewport in the scanline area for maximizing the guardband
- optimal PA_SU_PRIM_FILTER_CNTL
- higher subpixel precision for 4K and lower resolutions
  (for more precise rendering of T-junctions in geometry)

Please review.

Thanks,
Marek
___
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/4] gallium/u_inlines: normalize naming, use dst & src, style fixes

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

Dieter

Am 01.09.2018 08:54, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/auxiliary/util/u_inlines.h | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_inlines.h
b/src/gallium/auxiliary/util/u_inlines.h
index dee6f8f2d9e..7eb243779f7 100644
--- a/src/gallium/auxiliary/util/u_inlines.h
+++ b/src/gallium/auxiliary/util/u_inlines.h
@@ -45,139 +45,139 @@
 extern "C" {
 #endif


 /*
  * Reference counting helper functions.
  */


 static inline void
-pipe_reference_init(struct pipe_reference *reference, unsigned count)
+pipe_reference_init(struct pipe_reference *dst, unsigned count)
 {
-   p_atomic_set(>count, count);
+   p_atomic_set(>count, count);
 }

 static inline boolean
-pipe_is_referenced(struct pipe_reference *reference)
+pipe_is_referenced(struct pipe_reference *src)
 {
-   return p_atomic_read(>count) != 0;
+   return p_atomic_read(>count) != 0;
 }

 /**
  * Update reference counting.
  * The old thing pointed to, if any, will be unreferenced.
  * Both 'ptr' and 'reference' may be NULL.
  * \return TRUE if the object's refcount hits zero and should be 
destroyed.

  */
 static inline boolean
-pipe_reference_described(struct pipe_reference *ptr,
- struct pipe_reference *reference,
+pipe_reference_described(struct pipe_reference *dst,
+ struct pipe_reference *src,
  debug_reference_descriptor get_desc)
 {
boolean destroy = FALSE;

-   if(ptr != reference) {
+   if (dst != src) {
   /* bump the reference.count first */
-  if (reference) {
- assert(pipe_is_referenced(reference));
- p_atomic_inc(>count);
- debug_reference(reference, get_desc, 1);
+  if (src) {
+ assert(pipe_is_referenced(src));
+ p_atomic_inc(>count);
+ debug_reference(src, get_desc, 1);
   }

-  if (ptr) {
- assert(pipe_is_referenced(ptr));
- if (p_atomic_dec_zero(>count)) {
+  if (dst) {
+ assert(pipe_is_referenced(dst));
+ if (p_atomic_dec_zero(>count))
 destroy = TRUE;
- }
- debug_reference(ptr, get_desc, -1);
+
+ debug_reference(dst, get_desc, -1);
   }
}

return destroy;
 }

 static inline boolean
-pipe_reference(struct pipe_reference *ptr, struct pipe_reference 
*reference)

+pipe_reference(struct pipe_reference *dst, struct pipe_reference *src)
 {
-   return pipe_reference_described(ptr, reference,
+   return pipe_reference_described(dst, src,
(debug_reference_descriptor)
debug_describe_reference);
 }

 static inline void
-pipe_surface_reference(struct pipe_surface **ptr, struct pipe_surface 
*surf)
+pipe_surface_reference(struct pipe_surface **dst, struct pipe_surface 
*src)

 {
-   struct pipe_surface *old_surf = *ptr;
+   struct pipe_surface *old_dst = *dst;

-   if (pipe_reference_described(&(*ptr)->reference, >reference,
+   if (pipe_reference_described(&(*dst)->reference, >reference,
 (debug_reference_descriptor)
 debug_describe_surface))
-  old_surf->context->surface_destroy(old_surf->context, old_surf);
-   *ptr = surf;
+  old_dst->context->surface_destroy(old_dst->context, old_dst);
+   *dst = src;
 }

 /**
  * Similar to pipe_surface_reference() but always set the pointer to 
NULL
  * and pass in an explicit context.  The explicit context avoids the 
problem
  * of using a deleted context's surface_destroy() method when freeing 
a surface

  * that's shared by multiple contexts.
  */
 static inline void
 pipe_surface_release(struct pipe_context *pipe, struct pipe_surface 
**ptr)

 {
if (pipe_reference_described(&(*ptr)->reference, NULL,
 (debug_reference_descriptor)
 debug_describe_surface))
   pipe->surface_destroy(pipe, *ptr);
*ptr = NULL;
 }


 static inline void
-pipe_resource_reference(struct pipe_resource **ptr, struct 
pipe_resource *tex)
+pipe_resource_reference(struct pipe_resource **dst, struct 
pipe_resource *src)

 {
-   struct pipe_resource *old_tex = *ptr;
+   struct pipe_resource *old_dst = *dst;

-   if (pipe_reference_described(&(*ptr)->reference, >reference,
+   if (pipe_reference_described(&(*dst)->reference, >reference,
 (debug_reference_descriptor)
 debug_describe_resource)) {
   /* Avoid recursion, which would prevent inlining this function 
*/

   do {
- struct pipe_resource *next = old_tex->next;
+ struct pipe_resource *next = old_dst->next;

- old_tex->screen->resource_destroy(old_tex->screen, old_tex)