Re: Is LLVM 13 (git) really ready for testing/development? libclc didn't compile

[Dieter Nützel]

[CC trimmed - excluded Marek]

Too bad  Jan,

'configure' works, now. But compilation brakes after that.
How can we add '-cl-no-stdinc' only to CMAKE_CLC_FLAGS and NOT CXX flags 
(see below)?


Tried

libclc/build> pwd
/opt/llvm-project/libclc/build

libclc/build> cmake ../ -DLLVM_CONFIG=/usr/local/bin/llvm-config 
-DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -DCMAKE_CLC_FLAGS=-cl-no-stdinc


and

libclc/build> cmake ../../../llvm-project/libclc/ 
-DLLVM_CONFIG=/usr/local/bin/llvm-config 
-DCMAKE_LLAsm_FLAGS=-cl-no-stdinc


-- The CXX compiler identification is GNU 10.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
LLVM version: 13.0.0git
LLVM system libs:
LLVM libs: -lLLVM-13git
LLVM libdir: /usr/local/lib
LLVM bindir: /usr/local/bin
LLVM ld flags: -L/usr/local/lib
LLVM cxx flags: 
-I/usr/local/include;-std=c++14;;;-fno-exceptions;-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS;-fno-rtti;-fno-exceptions;-fno-exceptions;-cl-no-stdinc


clang: /usr/local/bin/clang
llvm-as: /usr/local/bin/llvm-as
llvm-link: /usr/local/bin/llvm-link
opt: /usr/local/bin/opt
llvm-spirv: /usr/local/bin/llvm-spirv

-- Check for working CLC compiler: /usr/local/bin/clang
-- Check for working CLC compiler: /usr/local/bin/clang -- works
-- Check for working LLAsm compiler: /usr/local/bin/llvm-as
-- Check for working LLAsm compiler: /usr/local/bin/llvm-as -- works
-- Found Python3: /usr/bin/python3.8 (found version "3.8.8") found 
components: Interpreter

BUILDING amdgcn--
DEVICE: tahiti ( 
pitcairn;verde;oland;hainan;bonaire;kabini;kaveri;hawaii;mullins;tonga;iceland;carrizo;fiji;stoney;polaris10;polaris11;gfx900;gfx902;gfx904;gfx906 
)

BUILDING amdgcn--amdhsa
DEVICE: none (  )
BUILDING amdgcn-mesa-mesa3d
DEVICE: tahiti ( 
pitcairn;verde;oland;hainan;bonaire;kabini;kaveri;hawaii;mullins;tonga;iceland;carrizo;fiji;stoney;polaris10;polaris11;gfx900;gfx902;gfx904;gfx906 
)

BUILDING clspv--
DEVICE: none (  )
BUILDING nvptx--
DEVICE: none (  )
BUILDING nvptx--nvidiacl
DEVICE: none (  )
BUILDING nvptx64--
DEVICE: none (  )
BUILDING nvptx64--nvidiacl
DEVICE: none (  )
BUILDING r600--
DEVICE: cedar ( palm;sumo;sumo2;redwood;juniper )
DEVICE: cypress ( hemlock )
DEVICE: barts ( turks;caicos )
DEVICE: cayman ( aruba )
BUILDING spirv-mesa3d-
DEVICE: none (  )
BUILDING spirv64-mesa3d-
DEVICE: none (  )
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/llvm-project/libclc/build
libclc/build> make -j
  Scanning dependencies of target 
generate_convert.cl

Scanning dependencies of target prepare_builtins
[  0%] Generating convert.cl
[  0%] Building CXX object 
CMakeFiles/prepare_builtins.dir/utils/prepare-builtins.cpp.o
c++: error: unrecognized command-line option ‘-cl-no-stdinc’; did you 
mean ‘-nostdinc’?
make[2]: *** [CMakeFiles/prepare_builtins.dir/build.make:82: 
CMakeFiles/prepare_builtins.dir/utils/prepare-builtins.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:1810: 
CMakeFiles/prepare_builtins.dir/all] Fehler 2

make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet
[  0%] Built target generate_convert.cl
make: *** [Makefile:160: all] Fehler 2

And YES, my time during these 'Corona-Times' is limited, too...
...my wife is a children's nurse, we 5 aktive doctors (4 pneumologist), 
7 entire in our family and my second discipline was medicine, too. ;-)


Greetings and Gesundheit
to all of you!

Dieter

Am 10.03.2021 18:03, schrieb Jan Vesely:

One more update. without changing any cmake files the following
cmdline should work:
cmake ../llvm-project/libclc/
-DLLVM_CONFIG=/usr/local/llvm-git/bin/llvm-config
-DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -DCMAKE_CLC_FLAGS=-cl-no-stdinc

Jan

On Wed, Mar 10, 2021 at 1:20 AM Jan Vesely 
wrote:


hi,

sorry the option is actually -cl-no-stdinc. you can add it to
'target_compiler_options'.
I should have a patch ready soon(tm), but time is scarce.

Jan

On Sun, Mar 7, 2021 at 9:51 PM Dieter Nützel 
wrote:


Hello Jan,

I very much appreciate your advice.
Tried several places...
...where to put it?

Dieter

Am 06.03.2021 17:56, schrieb Jan Vesely:

Not Marek, but hope this answer will help.
libclc uses clang CLC preprocessor on .ll files, llvm/clang-13

started

including clc declarations by default (clang
cf3ef15a6ec5e5b45c6c54e8fbe3769255e815ce),
thus corrupting any .ll assembly files that are used by libclc.
Inclusion of the default declarations can be turned off using a
cmdline switch but that remains to be implemented in the libclc

build

system.
manually adding '-cl-no-stdinc' should work as a workaround

Is LLVM 13 (git) really ready for testing/development? libclc didn't compile

[Dieter Nützel]

Hello Marek,

can't compile anything, here.
Poor Intel Nehalem X3470.

Trying LLVM 12-rc2 later.

Greetings,
Dieter

llvm-project/libclc> cd build && cmake ../
-- The CXX compiler identification is GNU 10.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
LLVM version: 13.0.0git
LLVM system libs:
LLVM libs: -lLLVM-13git
LLVM libdir: /usr/local/lib
LLVM bindir: /usr/local/bin
LLVM ld flags: -L/usr/local/lib
LLVM cxx flags: 
-I/usr/local/include;-std=c++14;;;-fno-exceptions;-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS;-fno-rtti;-fno-exceptions


clang: /usr/local/bin/clang
llvm-as: /usr/local/bin/llvm-as
llvm-link: /usr/local/bin/llvm-link
opt: /usr/local/bin/opt
llvm-spirv: /usr/local/bin/llvm-spirv

-- Check for working CLC compiler: /usr/local/bin/clang
-- Check for working CLC compiler: /usr/local/bin/clang -- works
-- Check for working LLAsm compiler: /usr/local/bin/llvm-as
-- Check for working LLAsm compiler: /usr/local/bin/llvm-as -- broken
CMake Error at cmake/CMakeTestLLAsmCompiler.cmake:40 (message):
  The LLAsm compiler "/usr/local/bin/llvm-as" is not able to compile a 
simple

  test program.

  It fails with the following output:

   Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp



  Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast && /usr/bin/gmake 
-f

  CMakeFiles/cmTC_87af9.dir/build.make CMakeFiles/cmTC_87af9.dir/build

  gmake[1]: Verzeichnis
  „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird betreten

  Building LLAsm object CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc

  /usr/local/bin/clang -E -P -x cl
  
/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll 
-o

  CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp

  /usr/local/bin/llvm-as -o 
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc

  CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp

  /usr/local/bin/llvm-as:
  CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error: 
expected

  top-level entity

  typedef unsigned char uchar;

  ^

  gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86:
  CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1

  gmake[1]: Verzeichnis
  „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird verlassen

  gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2







  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:127 (enable_language)


-- Configuring incomplete, errors occurred!
See also "/opt/llvm-project/libclc/build/CMakeFiles/CMakeOutput.log".
See also "/opt/llvm-project/libclc/build/CMakeFiles/CMakeError.log".


CMakeError.log
Determining if the LLAsm compiler works failed with the following 
output:

Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast && /usr/bin/gmake  
-f CMakeFiles/cmTC_87af9.dir/build.make CMakeFiles/cmTC_87af9.dir/build
gmake[1]: Verzeichnis 
„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird betreten

Building LLAsm object CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc
/usr/local/bin/clang -E -P -x cl 
/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll 
-o CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp
/usr/local/bin/llvm-as -o CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc 
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp
/usr/local/bin/llvm-as: 
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error: expected 
top-level entity

typedef unsigned char uchar;
^
gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86: 
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1
gmake[1]: Verzeichnis 
„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird verlassen

gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Is LLVM 13 (git) really ready for testing/development? libclc didn't compile

[Dieter Nützel]

Hello Jan,

I very much appreciate your advice.
Tried several places...
...where to put it?

Dieter

Am 06.03.2021 17:56, schrieb Jan Vesely:

Not Marek, but hope this answer will help.
libclc uses clang CLC preprocessor on .ll files, llvm/clang-13 started
including clc declarations by default (clang
cf3ef15a6ec5e5b45c6c54e8fbe3769255e815ce),
thus corrupting any .ll assembly files that are used by libclc.
Inclusion of the default declarations can be turned off using a
cmdline switch but that remains to be implemented in the libclc build
system.
manually adding '-cl-no-stdinc' should work as a workaround.

Jan

On Thu, Mar 4, 2021 at 10:27 PM Dieter Nützel 
wrote:


Hello Marek,

can't compile anything, here.
Poor Intel Nehalem X3470.

Trying LLVM 12-rc2 later.

Greetings,
Dieter

llvm-project/libclc> cd build && cmake ../
-- The CXX compiler identification is GNU 10.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
LLVM version: 13.0.0git
LLVM system libs:
LLVM libs: -lLLVM-13git
LLVM libdir: /usr/local/lib
LLVM bindir: /usr/local/bin
LLVM ld flags: -L/usr/local/lib
LLVM cxx flags:


-I/usr/local/include;-std=c++14;;;-fno-exceptions;-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS;-fno-rtti;-fno-exceptions


clang: /usr/local/bin/clang
llvm-as: /usr/local/bin/llvm-as
llvm-link: /usr/local/bin/llvm-link
opt: /usr/local/bin/opt
llvm-spirv: /usr/local/bin/llvm-spirv

-- Check for working CLC compiler: /usr/local/bin/clang
-- Check for working CLC compiler: /usr/local/bin/clang -- works
-- Check for working LLAsm compiler: /usr/local/bin/llvm-as
-- Check for working LLAsm compiler: /usr/local/bin/llvm-as --
broken
CMake Error at cmake/CMakeTestLLAsmCompiler.cmake:40 (message):
The LLAsm compiler "/usr/local/bin/llvm-as" is not able to
compile a
simple
test program.

It fails with the following output:

Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast &&
/usr/bin/gmake
-f
CMakeFiles/cmTC_87af9.dir/build.make
CMakeFiles/cmTC_87af9.dir/build

gmake[1]: Verzeichnis
„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird
betreten

Building LLAsm object
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc

/usr/local/bin/clang -E -P -x cl



/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll


-o
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp

/usr/local/bin/llvm-as -o
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp

/usr/local/bin/llvm-as:
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error:
expected
top-level entity

typedef unsigned char uchar;

^

gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86:
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1

gmake[1]: Verzeichnis
„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird
verlassen

gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:127 (enable_language)

-- Configuring incomplete, errors occurred!
See also
"/opt/llvm-project/libclc/build/CMakeFiles/CMakeOutput.log".
See also "/opt/llvm-project/libclc/build/CMakeFiles/CMakeError.log".

CMakeError.log
Determining if the LLAsm compiler works failed with the following
output:
Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast &&
/usr/bin/gmake
-f CMakeFiles/cmTC_87af9.dir/build.make
CMakeFiles/cmTC_87af9.dir/build
gmake[1]: Verzeichnis
„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird
betreten
Building LLAsm object CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc
/usr/local/bin/clang -E -P -x cl


/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll


-o CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp
/usr/local/bin/llvm-as -o
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp
/usr/local/bin/llvm-as:
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error:
expected
top-level entity
typedef unsigned char uchar;
^
gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86:
CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1
gmake[1]: Verzeichnis
„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird
verlassen
gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600/nir: enable soft-fp64 for evengreen class hardware - brake compilation of Mesa git

[Dieter Nützel]

Hello Gert,

new year, new luck,...;-)

mkdir build
cd build
meson ../ --strip --buildtype release -Ddri-drivers= -Dplatforms=x11 
-Dgallium-drivers=r600,radeonsi,swrast -Dvulkan-drivers=amd 
-Dgallium-nine=true -Dopencl-spirv=true -Dgallium-opencl=standalone 
-Dglvnd=true -Dgallium-va=enabled -Dgallium-xvmc=disabled 
-Dgallium-omx=disabled -Dgallium-xa=disabled



[1067/1508] Compiling C object 
src/gallium/auxiliary/libgallium.a.p/gallivm_lp_bld_format_s3tc.c.o
../src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c: In function 
‘lp_build_fetch_rgtc_rgba_aos’:
../src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c:2649:17: warning: 
‘green_hi’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
 2649 |  rgba = latc2_to_rgba_aos(gallivm, n, 
format_desc->format,
  | 
^~
 2650 |   red_lo, red_hi, green_lo, 
green_hi, i, j);
  |   
~
../src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c:2649:17: warning: 
‘green_lo’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
[1089/1508] Compiling C object 
src/gallium/auxiliary/libgallium.a.p/gallivm_lp_bld_nir.c.o

In file included from ../src/gallium/auxiliary/gallivm/lp_bld_nir.c:26:
../src/gallium/auxiliary/gallivm/lp_bld_nir.c: In function 
‘visit_cf_list.isra’:
../src/gallium/auxiliary/gallivm/lp_bld_nir.h:263:27: warning: ‘result’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]
  263 |LLVMTypeRef arr_type = LLVMArrayType(LLVMTypeOf(values[0]), 
value_count);
  |   
^
../src/gallium/auxiliary/gallivm/lp_bld_nir.c:175:4: warning: ‘undef’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]
  175 |assign_ssa(bld_base, ssa->index, ssa->num_components == 1 ? 
vals[0] : 
lp_nir_array_build_gather_values(bld_base->base.gallivm->builder, vals, 
ssa->num_components));
  |
^~~
[1254/1508] Compiling C++ object 
src/gallium/drivers/r600/libr600.a.p/sb_sb_sched.cpp.o
../src/gallium/drivers/r600/sb/sb_sched.cpp: In member function ‘void 
r600_sb::literal_tracker::reset()’:
../src/gallium/drivers/r600/sb/sb_sched.cpp:1953:26: warning: ‘void* 
memset(void*, int, size_t)’ clearing an object of non-trivial type 
‘struct r600_sb::literal’; use assignment or value-initialization 
instead [-Wclass-memaccess]

 1953 |  memset(lt, 0, sizeof(lt));
  |  ^
In file included from ../src/gallium/drivers/r600/sb/sb_sched.cpp:35:
../src/gallium/drivers/r600/sb/sb_bc.h:409:8: note: ‘struct 
r600_sb::literal’ declared here

  409 | struct literal {
  |^~~
[1260/1508] Compiling C object 
src/gallium/drivers/r600/libr600.a.p/r600_state_common.c.o
../src/gallium/drivers/r600/r600_state_common.c: In function 
‘r600_create_shader_state’:
../src/gallium/drivers/r600/r600_state_common.c:960:39: warning: ‘sel’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]

  960 |   sel->lds_patch_outputs_written_mask = 0;
  |   ^~~
../src/gallium/drivers/r600/r600_state_common.c: In function 
‘r600_create_tes_state’:
../src/gallium/drivers/r600/r600_state_common.c:947:10: warning: ‘sel’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]

  947 |  sel->so = state->stream_output;
  |  ^~
../src/gallium/drivers/r600/r600_state_common.c:937:36: note: ‘sel’ was 
declared here

  937 |  struct r600_pipe_shader_selector *sel;
  |^~~
../src/gallium/drivers/r600/r600_state_common.c: In function 
‘r600_create_ps_state’:
../src/gallium/drivers/r600/r600_state_common.c:947:10: warning: ‘sel’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]

  947 |  sel->so = state->stream_output;
  |  ^~
../src/gallium/drivers/r600/r600_state_common.c:937:36: note: ‘sel’ was 
declared here

  937 |  struct r600_pipe_shader_selector *sel;
  |^~~
../src/gallium/drivers/r600/r600_state_common.c: In function 
‘r600_create_gs_state’:
../src/gallium/drivers/r600/r600_state_common.c:951:23: warning: ‘sel’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]

  951 |   sel->gs_output_prim =
  |   ^
  952 |sel->info.properties[TGSI_PROPERTY_GS_OUTPUT_PRIM];
  |~~
../src/gallium/drivers/r600/r600_state_common.c:937:36: note: ‘sel’ was 
declared here

  937 |  struct r600_pipe_shader_selector *sel;
  |^~~
[1318/1508] Compiling C++ object 
src/

Re: [PATCH v5 1/6] drm/amd/display: wait for fence without holding reservation lock

[Dieter Nützel]

Hello Andrey,

this series can't apply (brake on #3) on top of amd-staging-drm-next.
v2 works (Thu, 11 Apr 2019).

Dieter

Am 18.04.2019 17:00, schrieb Andrey Grodzovsky:

From: Christian König 

Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.

Signed-off-by: Christian König 
Reviewed-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 380a7f9..ad4f0e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4814,23 +4814,26 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
continue;
}

+   abo = gem_to_amdgpu_bo(fb->obj[0]);
+
+   /* Wait for all fences on this FB */
+   r = reservation_object_wait_timeout_rcu(abo->tbo.resv, true,
+   false,
+   MAX_SCHEDULE_TIMEOUT);
+   WARN_ON(r < 0);
+
/*
 * TODO This might fail and hence better not used, wait
 * explicitly on fences instead
 * and in general should be called for
 * blocking commit to as per framework helpers
 */
-   abo = gem_to_amdgpu_bo(fb->obj[0]);
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0)) {
DRM_ERROR("failed to reserve buffer before flip\n");
WARN_ON(1);
}

-   /* Wait for all fences on this FB */
-		WARN_ON(reservation_object_wait_timeout_rcu(abo->tbo.resv, true, 
false,

-   
MAX_SCHEDULE_TIMEOUT) < 0);
-
amdgpu_bo_get_tiling_flags(abo, &tiling_flags);

amdgpu_bo_unreserve(abo);

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Missing Thunderbolt 3 PCI-E atomics support

[Dieter Nützel]

Hello to both of you, Tim and Mika,

sorry that I step in so late, but after I've read that Tim's laptop 
didn't have PCIe atomics (is it realy PCIe 2.xx?) I have some hints, 
too. Question: Is PCIe 3.xx+ needed together with Thunderbold 3 or is 
PCIe 2.xx enaugth (like Tim's laptop)?


If Tim's laptop is realy only PCIe 2.xx (_without_ atomics) like mine 
'old' Intel Xeon X3470 (3400 Series Chipset) _without_ atomics you/we 
only have the option running Clover or AMD-pro's OpenCL. ROCm isn't an 
option with Polaris (20/RX580, here), currently. But we had some 
questions about AMD (Polaris) running as eGPU on one of our lists 
(mesa-devel / dri-devel / amd-gfx), lately.


I've CC'ed Alex.

Have a look here (ROCm 2.2), too:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1086267-radeon-rocm-2-2-released-with-vega-20-optimization-caffe2-multi-gpu-training?p=1086387#post1086387

Greetings,
Dieter

Am 14.03.2019 19:36, schrieb Timur Kristóf:

On Thu, 2019-03-14 at 20:17 +0200, Mika Westerberg wrote:

> > > Here is the output of 'lspci -vv':
> > > https://pastebin.com/Qt5RUFVc
> >
> > The root port (1c.4) says this:
> >
> >   DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+,
> > OBFF
> > Not Supported ARIFwd+
> >  AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS-
> >
> > Not knowing much about AtomicOps but to me this looks like the
> > root
> > port
> > does not support the feature.
>
> What kind of output should lspci show if the feature were
> supported?

The AMD card has this:

 DevCap2: Completion Timeout: Not Supported, TimeoutDis-,
LTR+, OBFF Not Supported
  AtomicOpsCap: 32bit+ 64bit+ 128bitCAS-

so I would expect something similar on the root port side as
pci_enable_atomic_ops_to_root() fails otherwise with mask of
PCI_EXP_DEVCAP2_ATOMIC_COMP32 | PCI_EXP_DEVCAP2_ATOMIC_COMP64 that
the
AMD driver requests.

> As far as I understand the root port is integrated in the CPU, or
> in
> the chipset maybe? It says it's a Sunrise Point-LP, and I googled
> it
> but was unable to find a spec sheet.

You can find it here:


https://www.intel.com/content/www/us/en/products/docs/processors/core/6th-gen-core-pch-u-y-io-datasheet-vol-2.html

Pages 845-826 show the DEVCAP2 register for the 1c.4 (D28/F4) and it
does not seem to have AtomicOps caps set.


This would be the 8th gen (8550U) but I assume it has similar
capabilities to the 6th gen. So, it seems that this is a hardware
limitation of the chipset.

Thanks Mika for clearing that up.

Best regards,
Tim

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GITLAB] spelling/typo: Shouldn't this thing called 'Merge Bot'?

[Dieter Nützel]

Hello Eric, hello all,

saw latest commits:

committer   Marge Bot 
[-]
Reviewed-by: Jason Ekstrand 
Tested-by: Marge Bot 


etc.

What do you think?

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

Re: Resizeable PCI BAR support V5

[Dieter Nützel]

Hello Christian,

I've running this since you've sent it on-top of amd-staging-4.11. But I 
think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), 
PCIe 2.0, 24 GB is to old for this stuff...


[1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 
0x-0x0003 64bit] (contains BAR0 for 16 VFs)
[1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 
0x-0x003f 64bit] (contains BAR2 for 16 VFs)
[1.121656] pci :00:1c.0: BAR 15: assigned [mem 
0x8000-0x801f 64bit pref]
[1.121659] pci :00:1c.6: BAR 15: assigned [mem 
0x8020-0x803f 64bit pref]
[1.121662] pci :01:00.0: BAR 6: assigned [mem 
0xb012-0xb013 pref]
[1.121681] pci :05:00.0: BAR 6: assigned [mem 
0xb028-0xb02f pref]
[1.121683] pci :05:00.0: BAR 9: no space for [mem size 
0x0040 64bit]
[1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 
0x0040 64bit]
[1.121685] pci :05:00.0: BAR 7: no space for [mem size 
0x0004 64bit]
[1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 
0x0004 64bit]
[3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 
0xc000-0xcfff 64bit pref]
[3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 
0xb040-0xb05f 64bit pref]
[3.874198] pcieport :00:03.0: BAR 15: releasing [mem 
0xb040-0xcfff 64bit pref]
[3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 
0x3 64bit pref]
[3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem size 
0x3 64bit pref]
[3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 
0x2 64bit pref]
[3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 
0x2 64bit pref]
[3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 
0x0020 64bit pref]
[3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 
0x0020 64bit pref]

[3.874258] [drm] Not enough PCI address space for a large BAR.
[3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 
0xc000-0xcfff 64bit pref]
[3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 
0xb040-0xb05f 64bit pref]

[3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M

Anyway rebase for current amd-staging-4.11 needed.
Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz

Greetings,
Dieter

Am 09.06.2017 10:59, schrieb Christian König:

Hi everyone,

This is the fith incarnation of this set of patches. It enables device
drivers to resize and most likely also relocate the PCI BAR of devices
they manage to allow the CPU to access all of the device local memory 
at once.


This is very useful for GFX device drivers where the default PCI BAR is 
only
about 256MB in size for compatibility reasons, but the device easily 
have

multiple gigabyte of local memory.

Some changes since V4:
1. Rebased on 4.11.
2. added the rb from Andy Shevchenko to patches which look complete 
now.
3. Move releasing the BAR and reallocating it on error to the driver 
side.

4. Add amdgpu support for GMC V6 hardware generation as well.

Please review and/or comment,
Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

dmesg-amd-staging-4.11-1.g7262353-default+.log.xz
Description: application/xz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[short question for propper bug report] RX580 Nitro+ / 4.11 boot message 'Invalid PCI ROM header signature'

[Dieter Nützel]

Hello Alex,

got mine Sapphire Nitro+ RX 580, 8 GB (of course) up and _flying_. ;-)
Sadly 'only' with PCIe 2.0 x8 (cutted server mobo slot).
With kernel 4.11 I've the below in dmesg:

[3.714150] [drm] amdgpu kernel modesetting enabled.
[3.721233] fb: switching to amdgpudrmfb from VESA VGA
[3.835926] amdgpu :01:00.0: Invalid PCI ROM header signature: 
expecting 0xaa55, got 0x
[3.836424] amdgpu :01:00.0: VRAM: 8192M 0x - 
0x0001 (8192M used)
[3.836426] amdgpu :01:00.0: GTT: 8192M 0x0002 - 
0x0003

[3.836545] [drm] amdgpu: 8192M of VRAM memory ready
[3.836546] [drm] amdgpu: 8192M of GTT memory ready.
[3.837817] amdgpu :01:00.0: amdgpu: using MSI.
[3.837835] [drm] amdgpu: irq initialized.
[3.837860] amdgpu: [powerplay] amdgpu: powerplay sw initialized
[3.838567] amdgpu :01:00.0: fence driver on ring 0 use gpu addr 
0x00020008, cpu addr 0x8e4c22198008
[3.838752] amdgpu :01:00.0: fence driver on ring 1 use gpu addr 
0x00020018, cpu addr 0x8e4c22198018
[3.838805] amdgpu :01:00.0: fence driver on ring 2 use gpu addr 
0x00020028, cpu addr 0x8e4c22198028
[3.839778] amdgpu :01:00.0: fence driver on ring 3 use gpu addr 
0x00020038, cpu addr 0x8e4c22198038
[3.839834] amdgpu :01:00.0: fence driver on ring 4 use gpu addr 
0x00020048, cpu addr 0x8e4c22198048
[3.839881] amdgpu :01:00.0: fence driver on ring 5 use gpu addr 
0x00020058, cpu addr 0x8e4c22198058
[3.839928] amdgpu :01:00.0: fence driver on ring 6 use gpu addr 
0x00020068, cpu addr 0x8e4c22198068
[3.839972] amdgpu :01:00.0: fence driver on ring 7 use gpu addr 
0x00020078, cpu addr 0x8e4c22198078
[3.840024] amdgpu :01:00.0: fence driver on ring 8 use gpu addr 
0x00020088, cpu addr 0x8e4c22198088
[3.840069] amdgpu :01:00.0: fence driver on ring 9 use gpu addr 
0x00020098, cpu addr 0x8e4c22198098
[3.840188] amdgpu :01:00.0: fence driver on ring 10 use gpu addr 
0x000200a8, cpu addr 0x8e4c221980a8
[3.840233] amdgpu :01:00.0: fence driver on ring 11 use gpu addr 
0x000200b8, cpu addr 0x8e4c221980b8
[3.841051] amdgpu :01:00.0: fence driver on ring 12 use gpu addr 
0x01165420, cpu addr 0xa244c545a420
[3.841276] amdgpu :01:00.0: fence driver on ring 13 use gpu addr 
0x000200d8, cpu addr 0x8e4c221980d8
[3.841316] amdgpu :01:00.0: fence driver on ring 14 use gpu addr 
0x000200e8, cpu addr 0x8e4c221980e8

[3.883443] amdgpu: [powerplay] [AVFS] Something is broken. See log!
[3.885296] amdgpu: [powerplay] Can't find requested voltage id in 
vdd_dep_on_sclk table!

[4.168877] fbcon: amdgpudrmfb (fb0) is primary device
[4.622128] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device
[4.638924] [drm] Initialized amdgpu 3.10.0 20150101 for :01:00.0 
on minor 0



NO HDMI sound as expected, need your wip branch (which version?).
The (VM) speed regression (need your wip branch, too or 4.12-rcx).
NO 'Zero core' but GREAT temperatur.

IDLE:
amdgpu-pci-0100
Adapter: PCI adapter
fan1: 853 RPM
temp1:+27.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

Where should we put the RX5xx strings?

GREAT stuff!

Dieter

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Ellesmere [Radeon RX 470/480] (rev e7) (prog-if 00 [VGA 
controller])

Subsystem: Device 1da2:e366
Physical Slot: 6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 30
Region 0: Memory at c000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at b040 (64-bit, prefetchable) [size=2M]
Region 4: I/O ports at 2000 [size=256]
Region 5: Memory at b014 (32-bit, non-prefetchable) 
[size=256K]

[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1+,D2+,D3hot+,D3cold+)

Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 
<4us, L1 unlimited

ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ 
Unsupported-

RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes

r600/shader: emit tessellation factors to GDS at end of TCS.

[Dieter Nützel]

Hello Dave,

first all the best for your newborn and your whole family!

Second:
What could be differend between r6xx/r7xx and EG+ (NI, here) that the 
below
fixes the 'gsraytrace' GPU hang on the later but NOT on the former?

Any ideas, hints where I could start?
r6xx/r7xx do not have any TESS support as we now.
So where to start?
Disabling some lines of your commit and try?

commit 2239f3eaff5c72c4cb1d4a5be97feb4af3d08d25
Author: Dave Airlie 
Date:   Mon Nov 30 15:48:22 2015 +1000

 r600/shader: emit tessellation factors to GDS at end of TCS.

 When we are finished the shader, we read back all the tess factors
 from LDS and write them to special global memory storage using
 GDS instructions.

 This also handles adding NOP when GDS or ENDLOOP end the TCS.

 Signed-off-by: Dave Airlie 

Thanks,
   Dieter

r600/shader: emit tessellation factors to GDS at end of TCS.

[Dieter Nützel]

Am 15.01.2016 21:04, schrieb Dave Airlie:
> On 15 January 2016 at 12:25, Dieter Nützel  
> wrote:
>> Hello Dave,

>> Second:
>> What could be differend between r6xx/r7xx and EG+ (NI, here) that the 
>> below
>> fixes the 'gsraytrace' GPU hang on the later but NOT on the former?
>> 
>> Any ideas, hints where I could start?
>> r6xx/r7xx do not have any TESS support as we now.
>> So where to start?
>> Disabling some lines of your commit and try?
> 
> This commit just fixed things by luck on EG I suppose,

I called it by 'accident' ;-)
Look, here:
Bug 91865 - [r600g] GPU hang in 'gsraytrace' - NI/Turks (6670)
https://bugs.freedesktop.org/show_bug.cgi?id=91865#c10

> it must be the NOP
> at the end of the shader, and I think on r600/700 that could should
> still happen,
> 
> I'd probably need to spend some time staring at fglrx dumps to work out 
> why
> we crash, does R600_DEBUG=nosb help at all?

Not at all, for me on EG and RV730.

With the commit it crash on RV730 for 'gsraytrace':
Bug 83319 - [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319#c15

For all other cases with R600_DEBUG=nosb
vsraytrace and fsraytrace on RV730,
vsraytrace, fsraytrace and gsraytrace on EG it show the damages like
below (see attachments):
Bug 93715 - [r600g] rendering issues with R600_DEBUG=nosb for all three 
'raytrace' variants

BTW gsraytrace on EG is now better than with fglrx (15.11?)

Let me know when I should test sth on RV730.
Thanks for looking at it.

-Dieter

[pull] radeon drm-fixes-3.16

[Dieter Nützel]

Am 17.07.2014 22:50, schrieb Alex Deucher:
> Hi Dave,
> 
> A few more fixes for 3.16.  The pageflipping fixes I dropped last week
> have finally shaped up so this is mostly fixes for fallout from the
> pageflipping code changes.  Also fix a memory leak and a black screen
> when restoring the backlight on console unblanking.
> 
> The following changes since commit 
> bf38b025d3f58f4c1273714ff1be5bfbf99574a4:
> 
>   Merge branch 'drm-fixes-3.16' of
> git://people.freedesktop.org/~agd5f/linux into drm-fixes (2014-07-11
> 11:24:13 +1000)
> 
> are available in the git repository at:
> 
> 
>   git://people.freedesktop.org/~agd5f/linux drm-fixes-3.16
> 
> for you to fetch changes up to 
> 5f87e090a7368adc2290ae17ffd82a070caadd20:
> 
>   drm/radeon: Make classic pageflip completion path less racy.
> (2014-07-17 09:04:03 -0400)
> 
> 
> Alex Deucher (2):
>   drm/radeon: avoid leaking edid data
>   drm/radeon: set default bl level to something reasonable
> 
> Mario Kleiner (4):
>   drm/radeon: Prevent too early kms-pageflips triggered by vblank.
>   drm/radeon: Remove redundant fence unref in pageflip path.
>   drm/radeon: Add missing vblank_put in pageflip ioctl error path.
>   drm/radeon: Make classic pageflip completion path less racy.
> 
> Michel D?nzer (2):
>   drm/radeon: Move pinning the BO back to radeon_crtc_page_flip()
>   drm/radeon: Complete page flip even if waiting on the BO fence 
> fails

Hello Alex and Michel,

isn't this needed anylonger?
drm-radeon-Disable-pflip-interrupts.patch

[-]
 From 462febcc7b5f6e54648f2fd941b9f90de16e54f1 Mon Sep 17 00:00:00 2001
 From: Michel D?nzer 
Date: Mon, 14 Jul 2014 06:42:06 +
Subject: drm/radeon: Disable pflip interrupts

With Mario's previous fix, there are three possible scenarios for the
pflip interrupts:

1) If a pflip interrupt can occur before the corresponding vblank
interrupt, the sequence number of the userspace event will be too
small by one.
2) If a pflip interrupt can occur after the vblank interrupt and after
the next flip is programmed to the hardware, 
radeon_crtc_handle_flip()
will complete the next flip earlier than expected by userspace.
3) Otherwise, radeon_crtc_handle_flip() doesn't perform any actual work
when called from the pflip interrupt handler, i.e. the pflip 
interrupt
is useless.

In summary, Mario's fix made the pflip interrupts useless in the best
case and harmful in the worst case, so let's disable them.

Signed-off-by: Michel D?nzer 
Signed-off-by: Alex Deucher 
[-]

Thanks,
   Dieter

[PATCH 0/5] radeon: Write-combined CPU mappings of BOs in GTT

[Dieter Nützel]

Am 18.07.2014 05:07, schrieb Michel D?nzer:
> On 17.07.2014 19:09, Christian K?nig wrote:
>> Am 17.07.2014 12:01, schrieb Michel D?nzer:
>>> In order to try and improve X(Shm)PutImage performance with glamor, I
>>> implemented support for write-combined CPU mappings of BOs in GTT.
>>> 
>>> This did provide a nice speedup, but to my surprise, using VRAM 
>>> instead
>>> of write-combined GTT turned out to be even faster in general on my
>>> Kaveri machine, both for the internal GPU and for discrete GPUs.
>>> 
>>> However, I've kept the changes from GTT to VRAM separated, in case 
>>> this
>>> turns out to be a loss on other setups.
>>> 
>>> Kernel patches:
>>> 
>>> [PATCH 1/5] drm/radeon: Remove radeon_gart_restore()
>>> [PATCH 2/5] drm/radeon: Pass GART page flags to
>>> [PATCH 3/5] drm/radeon: Allow write-combined CPU mappings of BOs in
>>> [PATCH 4/5] drm/radeon: Use write-combined CPU mappings of rings and
>> 
>> Those four are Reviewed-by: Christian K?nig 
> 
> Thanks!
> 
> 
>>> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
>> 
>> I'm still not very keen with this change since I still don't 
>> understand
>> the reason why it's faster than with GTT. Definitely needs more 
>> testing
>> on a wider range of systems.
> 
> Sure. If anyone wants to give this patch a spin and see if they can
> measure any performance difference, good or bad, that would be 
> interesting.
> 
>> Maybe limit it to APUs for now?
> 
> But IIRC, CPU writes to VRAM vs. write-combined GTT are actually an 
> even
> bigger win with dedicated GPUs than with the Kaveri built-in GPU on my
> system. I suspect it may depend on the bandwidth available for PCIe vs.
> system memory though.

Michel,

please, please do NOT change anything on this!;-)
You all know that I currently can only run this on my poor Duron 1800 
with RV730 (AGP), but...

With this all 'objview' demos (mesa-demos) run at 60 fps (vsync),
even with chip set/CPU power management enabled (athcool on).

If I set vblank_mode=0
the slowest GreatLakesBiplaneHP.obj
run at ~100 fps (~16 fps before) => 6x speedup.
(Even 5 planes run at 30 fps) - Wow!!!

'buddha' went from ~40 fps up to ~175 fps
'bunny' went from ~60 fps up to ~215 fps
'bobcat' show not such a big improvement 'only' 70 fps more

R600_HYPERZ=1
help somewhat, too but not in all cases.

Overall X/Kwin eXperience is much better.
Let me know which benchmarks you need.

Cheers,
   Dieter

BTW Do anyone know how I can override BIOS GTT settings?
I can only set 256 MB max. - BIOS patching?
With agpmode=-1 I can run with 1024 MB GTT

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 23.06.2014 11:34, schrieb Michel D?nzer:
> On 18.06.2014 18:14, Christian K?nig wrote:
>> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>>> 
>>> Looking into these issues has got me thinking about the use of the 
>>> page
>>> flip interrupt: If the page flip interrupt arrives before the
>>> corresponding
>>> vertical blank interrupt, the DRM vblank counter will be lower than
>>> expected by 1 in drm_send_vblank_event(). I suspect this is the cause 
>>> of
>>> 
>>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion
>>> event has impossible msc [x-1] < target_msc [x]
>>> 
>>> messages in the X log file which have been popping up in bug reports
>>> lately.
>>> This also results in 0s being returned to the client for the MSC and
>>> timestamp of the swap completion, which could cause all kinds of bad
>>> behaviour.
>> First of all thanks for looking into it. Are you getting this on 3.16 
>> or
>> 3.15?
> 
> I haven't actually run into this myself yet. I thought I'd seen it in
> several bug reports, but right now I can only find
> https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems to
> include the page flipping changes from 3.16.

With 3.16-rc2 I get it now on my RV730 AGP as in the above bug report.
But only the lines in Xorg.0.log.
NO signs of any damage/error in use.

Since 3.15 and 3.16 (rc2 only) my system is rock solid.

I've tried 3.15-rc7 + Christian's pflip rework (did some little 
handwork), too.
It was solid but I saw the reported flip/black distortion in the below 
part during Kwin 4.13 cube screen effect (rotation). Your fix for 
3.16-rc1 fixed that.

Before 3.15/3.16-rcX I got some hangs from time to time during system 
boot.
Nothing in the logs but SSD RAID1 rebuild. Maybe it was MD related an 
NOT r600/DRM.

3.16-rcX (3.15-rc7+pflip patches) seems to be more responsive that 3.15, 
for me.

First and latest attchments from bug #80141
https://bugs.freedesktop.org/attachment.cgi?id=101605
show same.

Where should I add/send my Xorg.0.log?

Cheers,
   Dieter

>> I don't think that the pflip irq is thrown earlier than the vblank, 
>> but
>> on 3.16 it might actually be that we program the flip so fast into the
>> hardware that we do it one frame earlier than planned.
> 
> So userspace is notified of the previous vertical blank period and 
> calls
> the page flip ioctl in response, which then manages to program the
> scanout address update into the hardware before the scanout address
> update is latched during the previous vertical blank period?
> 
> To avoid that scenario, one possibility might be to check if we're in
> vertical blank before calling radeon_page_flip(), and if so sleep for
> 1ms or so before trying again? That might unnecessarily delay flips on
> other CRTCs though...

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 23.06.2014 21:46, schrieb Dieter N?tzel:
> Am 23.06.2014 11:34, schrieb Michel D?nzer:
>> On 18.06.2014 18:14, Christian K?nig wrote:
>>> Am 18.06.2014 07:53, schrieb Michel D?nzer:
 
 Looking into these issues has got me thinking about the use of the 
 page
 flip interrupt: If the page flip interrupt arrives before the
 corresponding
 vertical blank interrupt, the DRM vblank counter will be lower than
 expected by 1 in drm_send_vblank_event(). I suspect this is the 
 cause of
 
   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
 completion
 event has impossible msc [x-1] < target_msc [x]
 
 messages in the X log file which have been popping up in bug reports
 lately.
 This also results in 0s being returned to the client for the MSC and
 timestamp of the swap completion, which could cause all kinds of bad
 behaviour.
>>> First of all thanks for looking into it. Are you getting this on 3.16 
>>> or
>>> 3.15?
>> 
>> I haven't actually run into this myself yet. I thought I'd seen it in
>> several bug reports, but right now I can only find
>> https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems 
>> to
>> include the page flipping changes from 3.16.
> 
> With 3.16-rc2 I get it now on my RV730 AGP as in the above bug report.
> But only the lines in Xorg.0.log.
> NO signs of any damage/error in use.
> 
> Since 3.15 and 3.16 (rc2 only) my system is rock solid.
> 
> I've tried 3.15-rc7 + Christian's pflip rework (did some little 
> handwork), too.
> It was solid but I saw the reported flip/black distortion in the below
> part during Kwin 4.13 cube screen effect (rotation). Your fix for
> 3.16-rc1 fixed that.
> 
> Before 3.15/3.16-rcX I got some hangs from time to time during system 
> boot.
> Nothing in the logs but SSD RAID1 rebuild. Maybe it was MD related an
> NOT r600/DRM.
> 
> 3.16-rcX (3.15-rc7+pflip patches) seems to be more responsive that 
> 3.15, for me.
> 
> First and latest attchments from bug #80141
> https://bugs.freedesktop.org/attachment.cgi?id=101605
> show same.
> 
> Where should I add/send my Xorg.0.log?
> 
> Cheers,
>   Dieter

Addendum:

I can reliable generate such lines in Xorg.0.log with KWin cube desktop 
effect.

Rotate screens with mouse wheel or screen switcher => new entry in 
Xorg.0.log. If it happens I notice ('see') flip delay.

[  9893.183] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 594382 < target_msc 594383
[ 10859.753] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 652497 < target_msc 652498
[ 10915.719] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 655863 < target_msc 655864
[ 10916.817] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 655929 < target_msc 655930
[ 10925.843] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 656472 < target_msc 656473
[ 10926.774] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 656528 < target_msc 656529
[ 10965.519] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 658859 < target_msc 658860
[ 11081.878] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 665846 < target_msc 665847

>>> I don't think that the pflip irq is thrown earlier than the vblank, 
>>> but
>>> on 3.16 it might actually be that we program the flip so fast into 
>>> the
>>> hardware that we do it one frame earlier than planned.
>> 
>> So userspace is notified of the previous vertical blank period and 
>> calls
>> the page flip ioctl in response, which then manages to program the
>> scanout address update into the hardware before the scanout address
>> update is latched during the previous vertical blank period?
>> 
>> To avoid that scenario, one possibility might be to check if we're in
>> vertical blank before calling radeon_page_flip(), and if so sleep for
>> 1ms or so before trying again? That might unnecessarily delay flips on
>> other CRTCs though...
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 24.06.2014 12:05, schrieb Michel D?nzer:
> On 24.06.2014 05:32, Dieter N?tzel wrote:
>> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
 On 18.06.2014 18:14, Christian K?nig wrote:
> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>> 
>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
>> completion
>> event has impossible msc [x-1] < target_msc [x]
>> 
>> messages in the X log file which have been popping up in bug 
>> reports
>> lately.
>> This also results in 0s being returned to the client for the MSC 
>> and
>> timestamp of the swap completion, which could cause all kinds of 
>> bad
>> behaviour.
> First of all thanks for looking into it. Are you getting this on
> 3.16 or
> 3.15?
 
 I haven't actually run into this myself yet. I thought I'd seen it 
 in
 several bug reports, but right now I can only find
 https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems 
 to
 include the page flipping changes from 3.16.
>>> 
>>> With 3.16-rc2 I get it now on my RV730 AGP as in the above bug 
>>> report.
>>> But only the lines in Xorg.0.log.
>>> NO signs of any damage/error in use.
>>> 
>>> Since 3.15 and 3.16 (rc2 only) my system is rock solid.
>>> 
>>> I've tried 3.15-rc7 + Christian's pflip rework (did some little
>>> handwork), too.
>>> It was solid but I saw the reported flip/black distortion in the 
>>> below
>>> part during Kwin 4.13 cube screen effect (rotation). Your fix for
>>> 3.16-rc1 fixed that.
> 
> That's good to hear.
> 
> 
>> I can reliable generate such lines in Xorg.0.log with KWin cube 
>> desktop
>> effect.
>> 
>> Rotate screens with mouse wheel or screen switcher => new entry in
>> Xorg.0.log. If it happens I notice ('see') flip delay.
> 
> I was only able to reproduce it a couple of times even with that, but 
> not
> at all yet with the patch below. Does it help for you as well?

Will try in the next run.

My daughter generated kernel crash for us.;-)
See would open up a zoom image in Konqi of a new Waveboard for here girl 
friends...

But I could only take images with my mobile.
kernel BUG at drivers/gpu/drm/drm_irq.c:976!
Will send one, have two more.

Greetings,
   Dieter

2nd, try.
This time without image.
Let me know where I should add it, please.

> 
> I don't think that the pflip irq is thrown earlier than the vblank, 
> but
> on 3.16 it might actually be that we program the flip so fast into 
> the
> hardware that we do it one frame earlier than planned.
 
 So userspace is notified of the previous vertical blank period and 
 calls
 the page flip ioctl in response, which then manages to program the
 scanout address update into the hardware before the scanout address
 update is latched during the previous vertical blank period?
> 
> I think there's another possible scenario:
> 
>  1. Userspace submits page flip intended for MSC x
>  2. The vertical blank interrupt is triggered for MSC x =>
> radeon_crtc_handle_vblank() => radeon_crtc_handle_flip()
>  3. Userspace submits page flip intended for MSC (x + 1)
>  4. The page flip interrupt is triggered for the previous flip =>
> radeon_crtc_handle_flip() => drm_send_vblank_event(). The second 
> flip
> hasn't actually executed yet, and the event has MSC x instead of (x 
> + 1)
> as expected by userspace.
> 
> If that is the case, only actually enabling and handling the page flip
> interrupt when a flip is pending might also avoid it. I can hack that 
> up
> tomorrow, if Christian doesn't beat me to it.
> 
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 8b575a4..8350f8c 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -336,14 +336,19 @@ void radeon_crtc_handle_flip(struct
> radeon_device *rdev, int crtc_id)
> struct radeon_crtc *radeon_crtc = 
> rdev->mode_info.crtcs[crtc_id];
> struct radeon_flip_work *work;
> unsigned long flags;
> +   struct timeval vblank_time;
> +   u32 vblank_seq;
> 
> /* this can happen at init */
> if (radeon_crtc == NULL)
> return;
> 
> +   vblank_seq = drm_vblank_count_and_time(rdev->ddev, crtc_id,
> &vblank_time);
> +
> spin_lock_irqsave(&rdev->ddev->event_lock, flags);
> work = radeon_crtc->flip_work;
> -   if (work == NULL) {
> +   if (work == NULL ||
> +   (vblank_seq - work->event->event.sequence) > (1<<23)) {
> spin_unlock_irqrestore(&rdev->ddev->event_lock, flags);
> return;
> }
> @@ -379,6 +384,7 @@ static void radeon_flip_work_func(struct
> work_struct *__work)
> 
> struct drm_crtc *crtc = &radeon_crtc->base;
> struct drm_framebuffer *fb = work->fb;
> +   struct timeval vblank_time;
> 
> uint32_t t

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 24.06.2014 12:05, schrieb Michel D?nzer:
> On 24.06.2014 05:32, Dieter N?tzel wrote:
>> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
 On 18.06.2014 18:14, Christian K?nig wrote:
> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>> 
>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
>> completion
>> event has impossible msc [x-1] < target_msc [x]
>> 
>> messages in the X log file which have been popping up in bug 
>> reports
>> lately.
>> This also results in 0s being returned to the client for the MSC 
>> and
>> timestamp of the swap completion, which could cause all kinds of 
>> bad
>> behaviour.
> First of all thanks for looking into it. Are you getting this on
> 3.16 or
> 3.15?
 
 I haven't actually run into this myself yet. I thought I'd seen it 
 in
 several bug reports, but right now I can only find
 https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems 
 to
 include the page flipping changes from 3.16.
>>> 
>>> With 3.16-rc2 I get it now on my RV730 AGP as in the above bug 
>>> report.
>>> But only the lines in Xorg.0.log.
>>> NO signs of any damage/error in use.
>>> 
>>> Since 3.15 and 3.16 (rc2 only) my system is rock solid.
>>> 
>>> I've tried 3.15-rc7 + Christian's pflip rework (did some little
>>> handwork), too.
>>> It was solid but I saw the reported flip/black distortion in the 
>>> below
>>> part during Kwin 4.13 cube screen effect (rotation). Your fix for
>>> 3.16-rc1 fixed that.
> 
> That's good to hear.
> 
> 
>> I can reliable generate such lines in Xorg.0.log with KWin cube 
>> desktop
>> effect.
>> 
>> Rotate screens with mouse wheel or screen switcher => new entry in
>> Xorg.0.log. If it happens I notice ('see') flip delay.
> 
> I was only able to reproduce it a couple of times even with that, but 
> not
> at all yet with the patch below. Does it help for you as well?

You have my Tested-by: for it.
Can't reproduce it any longer with your patch below.
Even that it didn't apply ontop of 3.16-rc2, but
most of the time I know what I'm doing...;-)

Now some little Fu?ball watching!

Cheers,
Dieter

> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 8b575a4..8350f8c 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -336,14 +336,19 @@ void radeon_crtc_handle_flip(struct
> radeon_device *rdev, int crtc_id)
> struct radeon_crtc *radeon_crtc = 
> rdev->mode_info.crtcs[crtc_id];
> struct radeon_flip_work *work;
> unsigned long flags;
> +   struct timeval vblank_time;
> +   u32 vblank_seq;
> 
> /* this can happen at init */
> if (radeon_crtc == NULL)
> return;
> 
> +   vblank_seq = drm_vblank_count_and_time(rdev->ddev, crtc_id,
> &vblank_time);
> +
> spin_lock_irqsave(&rdev->ddev->event_lock, flags);
> work = radeon_crtc->flip_work;
> -   if (work == NULL) {
> +   if (work == NULL ||
> +   (vblank_seq - work->event->event.sequence) > (1<<23)) {
> spin_unlock_irqrestore(&rdev->ddev->event_lock, flags);
> return;
> }
> @@ -379,6 +384,7 @@ static void radeon_flip_work_func(struct
> work_struct *__work)
> 
> struct drm_crtc *crtc = &radeon_crtc->base;
> struct drm_framebuffer *fb = work->fb;
> +   struct timeval vblank_time;
> 
> uint32_t tiling_flags, pitch_pixels;
> uint64_t base;
> @@ -466,6 +472,10 @@ static void radeon_flip_work_func(struct
> work_struct *__work)
> goto pflip_cleanup;
> }
> 
> +   work->event->event.sequence =
> +   drm_vblank_count_and_time(crtc->dev, 
> radeon_crtc->crtc_id,
> + &vblank_time) + 1;
> +
> /* We borrow the event spin lock for protecting flip_work */
> spin_lock_irqsave(&crtc->dev->event_lock, flags);

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 25.06.2014 09:57, schrieb Michel D?nzer:
> On 25.06.2014 03:13, Dieter N?tzel wrote:
>> Am 24.06.2014 12:05, schrieb Michel D?nzer:
>>> On 24.06.2014 05:32, Dieter N?tzel wrote:
 Am 23.06.2014 21:46, schrieb Dieter N?tzel:
> Am 23.06.2014 11:34, schrieb Michel D?nzer:
>> On 18.06.2014 18:14, Christian K?nig wrote:
>>> Am 18.06.2014 07:53, schrieb Michel D?nzer:
 
   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
 completion
 event has impossible msc [x-1] < target_msc [x]
 [...]
 I can reliable generate such lines in Xorg.0.log with KWin cube 
 desktop
 effect.
 
 Rotate screens with mouse wheel or screen switcher => new entry in
 Xorg.0.log. If it happens I notice ('see') flip delay.
>>> 
>>> I was only able to reproduce it a couple of times even with that, but 
>>> not
>>> at all yet with the patch below. Does it help for you as well?
>> 
>> Will try in the next run.

It helped half way as reported already. (Second half below.) ;-)

>> My daughter generated kernel crash for us.;-)
>> See would open up a zoom image in Konqi of a new Waveboard for here 
>> girl
>> friends...
>> 
>> But I could only take images with my mobile.
>> kernel BUG at drivers/gpu/drm/drm_irq.c:976!
> 
> I was able to reproduce all these issues, and the attached three 
> patches
> fix them for me. Please let me know if you can still trigger the panic
> or the diagnostic error messages in patch 2 somehow. If everything 
> works
> fine for you as well with these, I'll submit them with the error
> messages in patch 2 changed to debug messages.

Tested-by: Dieter at nuetzel-hh.de on top of 3.16-rc2.
Can't trigger any of the above problems with your three patches applied.

With your former single patch I got three hangs during boot up in the 
morning.
Nothing in the logs or catchable. Screen showed openSUSE plymouth
startup logo. - But no RAID1 rebuild needed.

Shouldn't this go into -rc3 if Christian and Alex ACKed it?

Greetings,
Dieter

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Dieter Nützel]

Am 26.06.2014 12:39, schrieb Christian K?nig:
> Am 26.06.2014 11:29, schrieb Michel D?nzer:
>> From: Michel D?nzer 
>> 
>> Prevents radeon_crtc_handle_flip() from running before
>> radeon_flip_work_func(), resulting in a kernel panic due to the 
>> BUG_ON()
>> in drm_vblank_put().
>> 
>> Tested-by: Dieter N?tzel 
>> Signed-off-by: Michel D?nzer 
> 
> Does patch #2 alone fixes the problem as well?
> 
> I would rather want to avoid turning the pflip interrupt on and off.
> 
> Christian.

Christian,

I'll try for you after the doctor (my wife and I are sick over the last 
several weeks(!) ;-() and before 'Fu?ball' ;-)))
--- That's why I'm on the 'hobel' that much and not in our forest, 
etc...
But our two children are OK...

All the above is my 'new/second' life...
...before that I've studied computer science with medicine as second 
part and had a deeper look into medical imagery.

Cheers,
Dieter

>> ---
>>   drivers/gpu/drm/radeon/cik.c   | 18 ++
>>   drivers/gpu/drm/radeon/evergreen.c | 18 ++
>>   drivers/gpu/drm/radeon/r600.c  | 12 
>>   drivers/gpu/drm/radeon/si.c| 18 ++
>>   4 files changed, 38 insertions(+), 28 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/radeon/cik.c 
>> b/drivers/gpu/drm/radeon/cik.c
>> index 0f4b38f..7f522a4 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -7145,21 +7145,21 @@ int cik_irq_set(struct radeon_device *rdev)
>>  if (rdev->num_crtc >= 2) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[0]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[1]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  }
>>  if (rdev->num_crtc >= 4) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[2]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[3]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  }
>>  if (rdev->num_crtc >= 6) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[4]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[5]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  }
>>  WREG32(DC_HPD1_INT_CONTROL, hpd1);
>> @@ -7611,8 +7611,10 @@ restart_ih:
>>  case 14: /* D4 page flip */
>>  case 16: /* D5 page flip */
>>  case 18: /* D6 page flip */
>> -DRM_DEBUG("IH: D%d flip\n", ((src_id - 8) >> 1) + 1);
>> -radeon_crtc_handle_flip(rdev, (src_id - 8) >> 1);
>> +src_id = (src_id - 8) >> 1;
>> +DRM_DEBUG("IH: D%d flip\n", src_id + 1);
>> +if (atomic_read(&rdev->irq.pflip[src_id]))
>> +radeon_crtc_handle_flip(rdev, src_id);
>>  break;
>>  case 42: /* HPD hotplug */
>>  switch (src_data) {
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index 0443183..fa6e320 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -4542,20 +4542,20 @@ int evergreen_irq_set(struct radeon_device 
>> *rdev)
>>  }
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[0]) ? GRPH_PFLIP_INT_MASK : 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[1]) ? GRPH_PFLIP_INT_MASK : 0);
>>  if (rdev->num_crtc >= 4) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[2]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[3]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  }
>>  if (rdev->num_crtc >= 6) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[4]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Dieter Nützel]

Am 25.06.2014 05:59, schrieb Michel D?nzer:
> On 24.06.2014 19:14, Christian K?nig wrote:
>> Am 24.06.2014 08:49, schrieb Michel D?nzer:
>>> On 23.06.2014 18:56, Christian K?nig wrote:
 Am 23.06.2014 10:15, schrieb Michel D?nzer:
> On 19.06.2014 18:45, Christian K?nig wrote:
> 
>> I think even when we revert to the old code we have a couple of
>> unsolved
>> problems with the VM support or in the driver in general where we
>> should
>> try to understand the underlying reason for it instead of applying
>> more
>> workarounds.
> I'm not suggesting applying more workarounds but going back to a 
> known
> more stable state. It seems like we've maneuvered ourselves to a 
> rather
> uncomfortable position from there, with no clear way to a better 
> place.
> But if we basically started from the 3.14 state again, we have a 
> few
> known hurdles like mine and Marek's Bonaire etc. which we know any
> further improvements will have to pass before they can be 
> considered
> for
> general consumption.
 Yeah agree, especially on the uncomfortable position.
 
 Please try with the two attached patches applied on top of 3.15 and
 retest. They should revert back to the old implementation.
>>> Unfortunately, X fails to start with these, see the attached excerpt
>>> from dmesg.
>> 
>> My fault, incorrectly solved a merge conflict and then failed to test
>> the right kernel.
>> 
>> BTW: Wasn't there an option to tell grup to use the latest installed
>> kernel instead of the one with the highest version number? Can't seem 
>> to
>> find that any more.

Maybe this helps (section 5. Grub 2 Files & Options).
http://ubuntuforums.org/showthread.php?t=1195275

GRUB_DEFAULT

Regards,
   Dieter

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Dieter Nützel]

Am 26.06.2014 12:39, schrieb Christian K?nig:
> Am 26.06.2014 11:29, schrieb Michel D?nzer:
>> From: Michel D?nzer 
>> 
>> Prevents radeon_crtc_handle_flip() from running before
>> radeon_flip_work_func(), resulting in a kernel panic due to the 
>> BUG_ON()
>> in drm_vblank_put().
>> 
>> Tested-by: Dieter N?tzel 
>> Signed-off-by: Michel D?nzer 
> 
> Does patch #2 alone fixes the problem as well?

With #2 alone I get this during boot up (before plymouth):

[   11.942342] [drm] fb depth is 24
[   11.942344] [drm]pitch is 7680
[   11.942739] fbcon: radeondrmfb (fb0) is primary device
[   11.943090] [drm:radeon_crtc_handle_flip] *ERROR* 
radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)
[   11.943912] Console: switching to colour frame buffer device 240x67
[   11.995623] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[   11.995628] radeon :01:00.0: registered panic notifier
[   11.998112] [drm] Initialized radeon 2.39.0 20080528 for :01:00.0 
on minor 0
[   15.259867] [drm:radeon_crtc_handle_flip] *ERROR* 
radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)

And during X / KDE start, again:

[   30.960442] [drm:radeon_crtc_handle_flip] *ERROR* 
radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)
[   31.343925] [drm:radeon_crtc_handle_flip] *ERROR* 
radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)
[   37.687138] [drm:radeon_crtc_handle_flip] *ERROR* 
radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)
[  187.005621] [drm:radeon_crtc_handle_flip] *ERROR* 
radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)

Much more in dmesg.
(See dmesg-3.16-rc2-Michel-2.xz)

But with Michel's #1+2 and 3 I got this in Xorg.0.log:
(See Xorg.0.log.old.xz)

(EE) [mi] EQ overflowing.  Additional events will be discarded until 
existing events are processed.
(EE)
(EE) Backtrace:

> I would rather want to avoid turning the pflip interrupt on and off.

I'm under the impression, that #2 alone is more responsive, but.

Sorry, after Fu?ball ;-)

Dieter

>> ---
>>   drivers/gpu/drm/radeon/cik.c   | 18 ++
>>   drivers/gpu/drm/radeon/evergreen.c | 18 ++
>>   drivers/gpu/drm/radeon/r600.c  | 12 
>>   drivers/gpu/drm/radeon/si.c| 18 ++
>>   4 files changed, 38 insertions(+), 28 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/radeon/cik.c 
>> b/drivers/gpu/drm/radeon/cik.c
>> index 0f4b38f..7f522a4 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -7145,21 +7145,21 @@ int cik_irq_set(struct radeon_device *rdev)
>>  if (rdev->num_crtc >= 2) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[0]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[1]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  }
>>  if (rdev->num_crtc >= 4) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[2]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[3]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  }
>>  if (rdev->num_crtc >= 6) {
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[4]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET,
>> -   GRPH_PFLIP_INT_MASK);
>> +   atomic_read(&rdev->irq.pflip[5]) ? GRPH_PFLIP_INT_MASK : 
>> 0);
>>  }
>>  WREG32(DC_HPD1_INT_CONTROL, hpd1);
>> @@ -7611,8 +7611,10 @@ restart_ih:
>>  case 14: /* D4 page flip */
>>  case 16: /* D5 page flip */
>>  case 18: /* D6 page flip */
>> -DRM_DEBUG("IH: D%d flip\n", ((src_id - 8) >> 1) + 1);
>> -radeon_crtc_handle_flip(rdev, (src_id - 8) >> 1);
>> +src_id = (src_id - 8) >> 1;
>> +DRM_DEBUG("IH: D%d flip\n", src_id + 1);
>> +if (atomic_read(&rdev->irq.pflip[src_id]))
>> +radeon_crtc_handle_flip(rdev, src_id);
>>  break;
>>  case 42: /* HPD hotplug */
>>  switch (src_data) {
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index 0443183..fa6e320 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -4542,20 +4542,20 @@ int evergreen_irq_set(struct radeon_device 
>>

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Dieter Nützel]

Am 27.06.2014 03:03, schrieb Michel D?nzer:
> On 27.06.2014 09:53, Dieter N?tzel wrote:
>> Am 26.06.2014 12:39, schrieb Christian K?nig:
>>> Am 26.06.2014 11:29, schrieb Michel D?nzer:
 From: Michel D?nzer 
 
 Prevents radeon_crtc_handle_flip() from running before
 radeon_flip_work_func(), resulting in a kernel panic due to the 
 BUG_ON()
 in drm_vblank_put().
 
 Tested-by: Dieter N?tzel 
 Signed-off-by: Michel D?nzer 
>>> 
>>> Does patch #2 alone fixes the problem as well?
>> 
>> With #2 alone I get this during boot up (before plymouth):
> 
> [...]
> 
>> [   15.259867] [drm:radeon_crtc_handle_flip] *ERROR*
>> radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)
> 
> That's the original patch I sent to you along with two others for
> testing. The patch I submitted in this series has these messages
> downgraded to debugging messages, as they just show the patch 
> preventing
> bad stuff from happening as designed.
> 
> The question is, can you reproduce the panic or the 'impossible msc'
> lines in the Xorg log with only patch #2?

Oh, shit sorry.
I'll redo in a minute before I went to bed!

-Dieter

>> But with Michel's #1+2 and 3 I got this in Xorg.0.log:
>> (See Xorg.0.log.old.xz)
>> 
>> (EE) [mi] EQ overflowing.  Additional events will be discarded until
>> existing events are processed.
> 
> That may not be directly related to the page flipping issues.

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Dieter Nützel]

Am 27.06.2014 03:03, schrieb Michel D?nzer:
> On 27.06.2014 09:53, Dieter N?tzel wrote:
>> Am 26.06.2014 12:39, schrieb Christian K?nig:
>>> Am 26.06.2014 11:29, schrieb Michel D?nzer:
 From: Michel D?nzer 
 
 Prevents radeon_crtc_handle_flip() from running before
 radeon_flip_work_func(), resulting in a kernel panic due to the 
 BUG_ON()
 in drm_vblank_put().
 
 Tested-by: Dieter N?tzel 
 Signed-off-by: Michel D?nzer 
>>> 
>>> Does patch #2 alone fixes the problem as well?
>> 
>> With #2 alone I get this during boot up (before plymouth):
> 
> [...]
> 
>> [   15.259867] [drm:radeon_crtc_handle_flip] *ERROR*
>> radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)
> 
> That's the original patch I sent to you along with two others for
> testing. The patch I submitted in this series has these messages
> downgraded to debugging messages, as they just show the patch 
> preventing
> bad stuff from happening as designed.
> 
> The question is, can you reproduce the panic or the 'impossible msc'
> lines in the Xorg log with only patch #2?

Here we go (the 'new' #2 alone):

For the panic I need more time.
But the first 'impossible msc' line arise during X start:

[80.271] (II) RADEON(0): Modeline "1680x1050"x0.0  119.00  1680 1728 
1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
[80.271] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920 
2040 2248 2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
[   100.246] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 5302 < target_msc 5303

Some arise with KWin cube effects.

[  1059.124] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 62948 < target_msc 62949
[  1067.223] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 63435 < target_msc 63436
[  1081.458] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 64290 < target_msc 64291
[  1233.165] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 73416 < target_msc 73417
[  1233.515] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 73437 < target_msc 73438
[  1234.330] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 73486 < target_msc 73487
[  1235.079] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 73531 < target_msc 73532

Sleep well!

-Dieter

>> But with Michel's #1+2 and 3 I got this in Xorg.0.log:
>> (See Xorg.0.log.old.xz)
>> 
>> (EE) [mi] EQ overflowing.  Additional events will be discarded until
>> existing events are processed.
> 
> That may not be directly related to the page flipping issues.

Re: [git pull] drm radeon/nouveau/core fixes

[Dieter Nützel]

Am 19.09.2013 04:07, schrieb Dave Airlie:

Hi Linus,

mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
for AST driver.

Dave.

The following changes since commit 
01172772c7c973debf5b4881fcb9463891ea97ec:


  drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 
+1000)


are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 
928c2f0c006bf7f381f58af2b2786d2a858ae311:


  drm/fb-helper: don't sleep for screen unblank when an oops is in
progress (2013-09-19 11:54:34 +1000)


[-]


Christian König (3):
  drm/radeon: remove stale radeon_fence_retire tracepoint
  drm/radeon: add command submission tracepoint
  drm/radeon: avoid UVD corruptions on AGP cards


Alex,

I think your PCIE AGP (radeon.agpmode=-1) UVD fix is missing, here.

Thanks for working UVD and dpm on mostly all asics!

-Dieter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730

[Dieter Nützel]

Hello Christian,

after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with 
my RV730 (AGP).


All nice videos didn't play any longer.

-Dieter

BTW I'm not on Mesa Devel, so please CC me.

/opt/mesa> vdpauinfo
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
---
420 8192  8192  NV12 YV12
422 8192  8192  UYVY YUYV
444 8192  8192  Y8U8V8A8 V8U8Y8A8

Decoder capabilities:

name   level macbs width height
---
MPEG1 0 262144  8192  8192
MPEG2_SIMPLE  3 262144  8192  8192
MPEG2_MAIN3 262144  8192  8192

Output surface:

name  width height nat types

B8G8R8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
R8G8B8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
R10G10B10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
B10G10R10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8

Bitmap surface:

name  width height
--
B8G8R8A8  8192  8192
R8G8B8A8  8192  8192
R10G10B10A2   8192  8192
B10G10R10A2   8192  8192
A88192  8192

Video mixer:

feature namesup

DEINTERLACE_TEMPORAL -
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION  y
SHARPNESSy
LUMA_KEY -
HIGH QUALITY SCALING - L1-
HIGH QUALITY SCALING - L2-
HIGH QUALITY SCALING - L3-
HIGH QUALITY SCALING - L4-
HIGH QUALITY SCALING - L5-
HIGH QUALITY SCALING - L6-
HIGH QUALITY SCALING - L7-
HIGH QUALITY SCALING - L8-
HIGH QUALITY SCALING - L9-

parameter name  sup  min  max
-
VIDEO_SURFACE_WIDTH  y48 8192
VIDEO_SURFACE_HEIGHT y48 8192
CHROMA_TYPE  y
LAYERS   y 04

attribute name  sup  min  max
-
BACKGROUND_COLOR y
CSC_MATRIX   y
NOISE_REDUCTION_LEVELy  0.00 1.00
SHARPNESS_LEVEL  y -1.00 1.00
LUMA_KEY_MIN_LUMAy
LUMA_KEY_MAX_LUMAy


Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion 
`map->l_init_called' failed!


(I've only have libvdpau1-0.6 not 0.7 on openSUSE 12.3.)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space

[Dieter Nützel]

Am 30.09.2013 13:36, schrieb Daniel Vetter:

On Sat, Sep 28, 2013 at 12:49:24PM -0400, John Hupp wrote:

[I emailed the list with this same material on 9/13, but it has
received no response and someone on the Ubuntu kernel team suggested
that I change the email Subject from "Re: Moving a bug upstream per
downstream request, emailing the maintainers" to the more
descriptive one above.]

When I emailed the maintainers with the report below on 8/15 (and
archived at 
http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html),

a response came on 8/16:

"It's a flash bug. They ignore the format of the Window that they
PutImage to. (Worse, they create an image of the right depth or else X
would reject the PutImage with a BadMatch and then render incorrect
pixel data into it.)"

Despite that, someone on the Ubuntu kernel team asserted "at a
minimum a non-flash regression exists going from Quantal to Raring,"
and urged me to proceed with upstream kernel bisection.

I finally finished that, and arrived at the result:


Still a flash bug. This commit simply enables rgb555 in the kernel, 
which

sna likes to use on gen2/3. Flash is just too dense and always presumes
xrgb. Adding

Section "Screen"
Identifier "igd"
DefaultDepth 24
EndSection

to your xorg.conf will work around.
-Daniel


Hello Daniel, hello John,

I see the same shit thing with my Radeon RV730 AGP (HD4650) 'cause I 
have an old SSE1 system, only. The poor people at Adobe do NOT release 
any update (even a security one) for SSE1 systems since summer 2012!!!


Even so, I have no xorg.conf only /etc/X11/xorg.conf.d/ files.
Which one should I create/change for testing, this?

Thanks,
   Dieter

PS I only see this with 'hardware acceleration' (ha,ha, 2012..., only 
working right with SSE2, Adobe thinks,...)

PPS The little preview pictures during Flash search are right.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730

[Dieter Nützel]

Am 30.09.2013 10:47, schrieb Grigori Goronzy:

On 30.09.2013 10:06, Michel Dänzer wrote:

On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote:


after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN 
with

my RV730 (AGP).




Same problem on PALM. Bisection shows that it is caused by commit
68f6dec32. The initialization order seems to be wrong, the check for
UVD is done too early. I'll send a patch in a minute.

Best regards
Grigori


Thank you Grigori and Marek (AMD!) ;-)

-Dieter


That probably means you lost UVD support for some reason. Assuming UVD
is still enabled in the kernel, can you bisect which Mesa change 
caused

the problem for you?


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: avoid segfault on device open when accel is not working.

[Dieter Nützel]

Hello Christian,

no one has picked this.
http://lists.freedesktop.org/archives/dri-devel/2014-May/059189.html

Even Alex ACKed it.
http://lists.freedesktop.org/archives/dri-devel/2014-May/059191.html

Greetings,
   Dieter

[drm-next-3.18 (-wip)] only works with b6c2b4 below evergreen (UVD)

[Dieter Nützel]

Hello Alex and Christian,

RV730 (AGP) need badly

 From b6c2b4faf90230ef9cf1a81f36cbccda4a606c59 Mon Sep 17 00:00:00 2001
 From: Alex Deucher 
Date: Mon, 8 Sep 2014 13:16:39 -0400
Subject: [PATCH] drm/radeon: only use me/pfp sync on evergreen+

The packet seems to cause hangs on some 7xx asics.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=83616

Signed-off-by: Alex Deucher 

to get UVD going, again.

Thanks,
Dieter.

PS
Examination of
[   11.279944] radeon :01:00.0: (-1) pin WB bo failed
[   11.279956] radeon :01:00.0: f6124800 unpin not necessary
[   11.279975] radeon :01:00.0: disabling GPU acceleration
[   11.331227] radeon :01:00.0: f610e000 unpin not necessary
is under way - I'm learning GIT...;-)

[drm-next-3.18 (-wip)] only works with b6c2b4 below evergreen (UVD)

[Dieter Nützel]

Am 12.09.2014 00:14, schrieb Alex Deucher:
> On Thu, Sep 11, 2014 at 6:12 PM, Dieter N?tzel  
> wrote:
>> Hello Alex and Christian,
>> 
>> RV730 (AGP) need badly
>> 
>> From b6c2b4faf90230ef9cf1a81f36cbccda4a606c59 Mon Sep 17 00:00:00 2001
>> From: Alex Deucher 
>> Date: Mon, 8 Sep 2014 13:16:39 -0400
>> Subject: [PATCH] drm/radeon: only use me/pfp sync on evergreen+
>> 
>> The packet seems to cause hangs on some 7xx asics.
>> 
>> bug:
>> https://bugs.freedesktop.org/show_bug.cgi?id=83616
>> 
>> Signed-off-by: Alex Deucher 
>> 
>> to get UVD going, again.
> 
> Dave already pulled it into drm-next:
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=b6c2b4faf90230ef9cf1a81f36cbccda4a606c59
> 
> Alex

Ah, shit... you're too fast with your nice 'Hobels'...

Much appreciated!
Dieter

>> Thanks,
>> Dieter.
>> 
>> PS
>> Examination of
>> [   11.279944] radeon :01:00.0: (-1) pin WB bo failed
>> [   11.279956] radeon :01:00.0: f6124800 unpin not necessary
>> [   11.279975] radeon :01:00.0: disabling GPU acceleration
>> [   11.331227] radeon :01:00.0: f610e000 unpin not necessary
>> is under way - I'm learning GIT...;-)

[Bug 92173] [regression, bisected] commit 266d05a broke WebGL-Water Caustics on NI/Turks (6670)

[Dieter Nützel]

Hello Tapani,

this was your patch.
Any comments?

Thanks,
   Dieter

Am 29.09.2015 03:56, schrieb bugzilla-daemon at freedesktop.org:
> BUG ID
>   92173 [3]
> 
>   SUMMARY
>   [regression, bisected] commit 266d05a broke WebGL-Water 
> Caustics on
> NI/Turks (6670)
> 
>   PRODUCT
>   Mesa
> 
>   VERSION
>   git
> 
>   HARDWARE
>   x86-64 (AMD64)
> 
>   OS
>   Linux (All)
> 
>   STATUS
>   NEW
> 
>   SEVERITY
>   major
> 
>   PRIORITY
>   medium
> 
>   COMPONENT
>   Drivers/Gallium/r600
> 
>   ASSIGNEE
>   dri-devel at lists.freedesktop.org
> 
>   REPORTER
>   Dieter at nuetzel-hh.de
> 
>   QA CONTACT
>   dri-devel at lists.freedesktop.org
> 
> Created attachment 118509 [1] [details] [2]
> WebGL-Water with broken caustics
> 
> WebGL-Water show broken or NO Caustics on NI/Turks (6670) since commit
> 266d05a.
> Sometimes GPU hangs and/or slow down badly.
> 
> git revert 266d05a
> Works again.
> 
> git bisect show this:
> /opt/mesa> git bisect bad
> 266d05a3a0651ac954c91aea12c870940e8a9820 is the first bad commit
> commit 266d05a3a0651ac954c91aea12c870940e8a9820
> Author: Tapani Pälli 
> Date:   Fri Sep 25 09:56:39 2015 +0300
> 
> glsl: fix packed varyings interface type and add default case
> 
> fixes Piglit test:
>arb_program_interface_query/linker/query-varyings.shader_test
> 
> Signed-off-by: Tapani Pälli 
> Reviewed-by: Ilia Mirkin 
> 
> :04 04 4ab4878fd41868c4b674c13f833b82d089ce971f
> d8ef9c2c4746a610989e7dfe24552d044e914a9b M src
> 
> -
>  You are receiving this mail because:
> 
>   * You are the assignee for the bug.
> 
> 
> 
> Links:
> --
> [1] http://ssl.lux01.de/attachment.cgi?id=118509
> [2] http://ssl.lux01.de/attachment.cgi?id=118509&action=edit
> [3] https://bugs.freedesktop.org/show_bug.cgi?id=92173
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

tgsi: add support for buffer/atomic operations to tgsi_exec

[Dieter Nützel]

Warning during compilation after git pull:

tgsi/tgsi_exec.c: In function 'exec_atomop_buf':
tgsi/tgsi_exec.c:4060:8: warning: array subscript is above array bounds 
[-Warray-bounds]
r[3].f[j] = rgba[3][j];
 ^

Any hints where I should look?

Dieter

Re: [PATCH v3 0/5] drm/ttm,amdgpu: Introduce LRU bulk move functionality

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

on RX580,
amd-staging-drm-next
#5024f8dfe478

Dieter

Am 13.08.2018 11:58, schrieb Huang Rui:
The idea and proposal is originally from Christian, and I continue to 
work to

deliver it.

Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then 
move all of
them on the end of LRU list one by one. Thus, that cause so many BOs 
moved to

the end of the LRU, and impact performance seriously.

Then Christian provided a workaround to not move PD/PT BOs on LRU with 
below

patch:
"drm/amdgpu: band aid validating VM PTs"
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae

However, the final solution should bulk move all PD/PT and PerVM BOs on 
the LRU

instead of one by one.

Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which 
need to be
validated we move all BOs together to the end of the LRU without 
dropping the

lock for the LRU.

While doing so we note the beginning and end of this block in the LRU 
list.


Now when amdgpu_vm_validate_pt_bos() is called and we don't have 
anything to do,
we don't move every BO one by one, but instead cut the LRU list into 
pieces so

that we bulk move everything to the end in just one operation.

Test data:
+--+-+---+---+
|  |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
  |
|  |Principle(Vulkan)|   |
  |
++
|  | |   |0.319 ms(1k) 0.314
ms(2K) 0.308 ms(4K) |
| Original |  147.7 FPS  |  76.86 us |0.307 ms(8K) 0.310
ms(16K) |
++
| Orignial + WA| |   |0.254 ms(1K) 0.241
ms(2K)  |
|(don't move   |  162.1 FPS  |  42.15 us |0.230 ms(4K) 0.223
ms(8K) 0.204 ms(16K)|
|PT BOs on LRU)| |   |
  |
++
| Bulk move|  163.1 FPS  |  40.52 us |0.244 ms(1K) 0.252
ms(2K) 0.213 ms(4K) |
|  | |   |0.214 ms(8K) 0.225
ms(16K) |
+--+-+---+---+

After test them with above three benchmarks include vulkan and opencl. 
We can
see the visible improvement than original, and even better than 
original with

workaround.

Changes from V1 -> V2:
- Fix to missed the BOs in relocated/moved that should be also moved to 
the end

  of LRU.

Changes from V2 -> V3:
- Remove unused parameter and use list_for_each_entry instead of the 
one with

  save entry.

Thanks,
Rui

Christian König (2):
  drm/ttm: add helper structures for bulk moves on lru list
  drm/ttm: revise ttm_bo_move_to_lru_tail to support bulk moves

Huang Rui (3):
  drm/ttm: add bulk move function on LRU
  drm/amdgpu: use bulk moves for efficient VM LRU handling (v3)
  drm/amdgpu: move PD/PT bos on LRU again

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 75 


 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  4 ++
 drivers/gpu/drm/ttm/ttm_bo.c   | 78 
+-

 include/drm/ttm/ttm_bo_api.h   | 16 ++-
 include/drm/ttm/ttm_bo_driver.h| 28 
 5 files changed, 182 insertions(+), 19 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Provide ttm_bo_{get,put} for TMM BO ref-counting

[Dieter Nützel]

Am 21.06.2018 16:53, schrieb Christian König:

Am 21.06.2018 um 15:21 schrieb Thomas Zimmermann:

TTM buffer objects provide ttm_bo_reference() and ttm_bo_unref() for
managing reference counters. This patch set introduces ttm_bo_get()
and ttm_ot_put(), which follow Linux kernel conventions.

   ^^
I hope this typo is only in explanation text...;-)

Greetings,
Dieter


A call to ttm_bo_unref() clears the supplied pointer to NULL. This is

unnecessary in most cases and occationally callers have to work around
this behaviour. ttm_bo_put() only releases the reference, but keeps
the pointer's value.

This patch set introduces ttm_bo_get() and ttm_bo_put(), and converts
TTM to the new functions. The old functions remain in place until all
callers have been converted.


Thanks, series is Reviewed-by: Christian König
 and I'm going to pick it up for our
internal TTM branch.

It is appreciated that you do this only one driver/component at a time
and not in a massive change.

Are you planning to stick with applying that to the individual drivers 
using it?


Thanks,
Christian.



Thomas Zimmermann (3):
   drm/ttm: Introduce ttm_bo_get() and ttm_bo_put() for ref counting
   drm/ttm: Replace ttm_bo_reference() with ttm_bo_get()
   drm/ttm: Replace ttm_bo_unref() with ttm_bo_put()

  drivers/gpu/drm/ttm/ttm_bo.c  | 10 --
  drivers/gpu/drm/ttm/ttm_bo_util.c | 11 ++-
  drivers/gpu/drm/ttm/ttm_bo_vm.c   | 18 ++
  include/drm/ttm/ttm_bo_api.h  | 25 -
  4 files changed, 48 insertions(+), 16 deletions(-)

--
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCIe P2P access to GPU memory

[Dieter Nützel]

Hello Dirk,

I think Christian is talking about this branch:

https://cgit.freedesktop.org/~deathsimple/linux/log/?h=p2p

His 'home' is, here:
https://cgit.freedesktop.org/~deathsimple/linux/

Happy hacking! ;-)

Dieter

Am 29.09.2018 10:17, schrieb Dirk Eibach:

This is work in progress.

I published patches to enable DMA_buf P2P a few months ago, but now 
I'm waiting for the PCI subsystem to pick up core support for this.


Great news! Can you give me a link to this series so I can already have 
a look?


I can prepare you a branch based on current upstream kernel next week 
if you want to test this.


That would be awesome, thanks.

Cheers
Dirk
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

[Dieter Nützel]

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse move.
Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?

Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:

Since we now deal with multiple rq we need to update all of them, not
just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

for (i = 0; i < adev->num_rings; i++) {
ring = adev->rings[i];
entity = &ctx->rings[i].entity;
-   rq = &ring->sched.sched_rq[ctx_prio];

if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
continue;

-   drm_sched_entity_set_rq(entity, rq);
+   drm_sched_entity_set_priority(entity, ctx_prio);
}
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void drm_sched_entity_clear_dep(struct
dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq **rq,
+enum drm_sched_priority priority)
+{
+   *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets priority of the entity
  *
  * @entity: scheduler entity
- * @rq: scheduler run queue
+ * @priority: scheduler priority
  *
- * Sets the run queue for an entity and removes the entity from the 
previous

- * run queue in which was present.
+ * Update the priority of runqueus used for the entity.
  */
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
-struct drm_sched_rq *rq)
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+  enum drm_sched_priority priority)
 {
-   if (entity->rq == rq)
-   return;
-
-   BUG_ON(!rq);
+   unsigned int i;

spin_lock(&entity->rq_lock);
+
+   for (i = 0; i < entity->num_rq_list; ++i)
+   drm_sched_entity_set_rq_priority(&entity->rq_list[i], priority);
+
drm_sched_rq_remove_entity(entity->rq, entity);
-   entity->rq = rq;
-   drm_sched_rq_add_entity(rq, entity);
+   drm_sched_entity_set_rq_priority(&entity->rq, priority);
+   drm_sched_rq_add_entity(entity->rq, entity);
+
spin_unlock(&entity->rq_lock);
 }
-EXPORT_SYMBOL(drm_sched_entity_set_rq);
+EXPORT_SYMBOL(drm_sched_entity_set_priority);

 /**
  * drm_sched_dependency_optimized
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 0c4cfe689d4c..22c0f88f7d8f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -298,9 +298,8 @@ void drm_sched_entity_fini(struct drm_sched_entity 
*entity);

 void drm_sched_entity_destroy(struct drm_sched_entity *entity);
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
   struct drm_sched_entity *entity);
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
-struct drm_sched_rq *rq);
-
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+  enum drm_sched_priority priority);
 struct drm_sched_fence *drm_sched_fence_create(
struct drm_sched_entity *s_entity, void *owner);
 void drm_sched_fence_scheduled(struct drm_sched_fence *fence);

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

[Dieter Nützel]

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the "[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series is
causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem 
definitions into amdgpu_gem header


works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 

Sorry about the noise.
Dieter



Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:

Since we now deal with multiple rq we need to update all of them, not
just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = &ctx->rings[i].entity;
-    rq = &ring->sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void drm_sched_entity_clear_dep(struct
dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq 
**rq,

+ enum drm_sched_priority priority)
+{
+    *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets priority of the entity
  *
  * @entity: scheduler entity
- * @rq: scheduler run queue
+ * @priority: scheduler priority
  *
- * Sets the run queue for an entity and removes the entity from the 
previous

- * run queue in which was present.
+ * Update the priority of runqueus used for the entity.
  */
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq)
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority)
 {
-    if (entity->rq == rq)
-    return;
-
-    BUG_ON(!rq);
+    unsigned int i;

 spin_lock(&entity->rq_lock);
+
+    for (i = 0; i < entity->num_rq_list; ++i)
+ drm_sched_entity_set_rq_priority(&entity->rq_list[i], priority);
+
 drm_sched_rq_remove_entity(entity->rq, entity);
-    entity->rq = rq;
-    drm_sched_rq_add_entity(rq, entity);
+    drm_sched_entity_set_rq_priority(&entity->rq, priority);
+    drm_sched_rq_add_entity(entity->rq, entity);
+
 spin_unlock(&entity->rq_lock);
 }
-EXPORT_SYMBOL(drm_sched_entity_set_rq);
+EXPORT_SYMBOL(drm_sched_entity_set_priority);

 /**
  * drm_sched_dependency_optimized
diff --git a/include/drm/gpu_scheduler.h 
b/include/drm/gpu_scheduler.h

index 0c4cfe689d4c..22c0f88f7d8f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -298,9 +298,8 @@ void drm_sched_entity_fini(struct 
drm_sched_entity *entity);

 void drm_sched_entity_destroy(struct drm_sched_entity *entity);
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
    struct drm_sched_entity *entity);
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq);
-
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority);
 struct drm_sched_fence *drm_sched_fence_create(
 struct drm_sched_entity *s_entity, void *owner);
 void drm_sched_fence_scheduled(struct drm_sched_fence *fence);

___

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

[Dieter Nützel]

Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the "[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series is
causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = &ctx->rings[i].entity;
-    rq = &ring->sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void drm_sched_entity_clear_dep(struct
dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq 
**rq,

+ enum drm_sched_priority priority)
+{
+    *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets priority of the entity
  *
  * @entity: scheduler entity
- * @rq: scheduler run queue
+ * @priority: scheduler priority
  *
- * Sets the run queue for an entity and removes the entity from the 
previous

- * run queue in which was present.
+ * Update the priority of runqueus used for the entity.
  */
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq)
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority)
 {
-    if (entity->rq == rq)
-    return;
-
-    BUG_ON(!rq);
+    unsigned int i;

 spin_lock(&entity->rq_lock);
+
+    for (i = 0; i < entity->num_rq_list; ++i)
+ drm_sched_entity_set_rq_priority(&entity->rq_list[i], priority);
+
 drm_sched_rq_remove_entity(entity->rq, entity);
-    entity->rq = rq;
-    drm_sched_rq_add_entity(rq, entity);
+    drm_sched_entity_set_rq_priority(&entity->rq, priority);
+    drm_sched_rq_add_entity(entity->rq, entity);
+
 spin_unlock(&entity->rq_lock);
 }
-EXPORT_SYMBOL(drm_sched_entity_set_rq);
+EXPORT_SYMBOL(drm_sched_entity_set_priority);

 /**
  * drm_sched_dependency_optimized
diff --git a/include/drm/gpu_scheduler.h 
b/include/drm/gpu_scheduler.h

index 0c4cfe689d4c..22c0f88f7d8f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -298,9 +298,8 @@ void drm_sched_entity_fini(struct 
drm_sched_entity *entity);

 void drm_sched_entity_destroy(struct drm_sched_entity *entity);
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
    struct drm_sched_entity *entity);
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq);
-
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority);
 struct drm_sched_fence *drm_sched_fence_create(
 struc

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

[Dieter Nützel]

Am 04.08.2018 06:12, schrieb Dieter Nützel:

Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the "[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series is
causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter


Argh, shi...
wrong dmesg version.

Should be this one. (For sure...)
Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = &ctx->rings[i].entity;
-    rq = &ring->sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void drm_sched_entity_clear_dep(struct
dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq 
**rq,

+ enum drm_sched_priority priority)
+{
+    *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets priority of the entity
  *
  * @entity: scheduler entity
- * @rq: scheduler run queue
+ * @priority: scheduler priority
  *
- * Sets the run queue for an entity and removes the entity from 
the previous

- * run queue in which was present.
+ * Update the priority of runqueus used for the entity.
  */
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq)
+void drm_sched_entity_set_priority(struct drm_sched_entity 
*entity,

+   enum drm_sched_priority priority)
 {
-    if (entity->rq == rq)
-    return;
-
-    BUG_ON(!rq);
+    unsigned int i;

 spin_lock(&entity->rq_lock);
+
+    for (i = 0; i < entity->num_rq_list; ++i)
+ drm_sched_entity_set_rq_priority(&entity->rq_list[i], priority);
+
 drm_sched_rq_remove_entity(entity->rq, entity);
-    entity->rq = rq;
-    drm_sched_rq_add_entity(rq, entity);
+    drm_sched_entity_set_rq_priority(&entity->rq, priority);
+    drm_sched_rq_add_entity(entity->rq, entity);
+
 spin_unlock(&entity->rq_lock);
 }
-EXPORT_SYMBOL(drm_sched_entity_set_rq);
+EXPORT_SYMBOL(drm_sched_entity_set_priority);

 /**
  * drm_sched_dependency_optimized
diff --git a/include/drm/gpu_scheduler.h 
b/include/drm/gpu_scheduler.h

index 0c4cfe689d4c..22c0f88f7d8f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -298,9 +298,8 @@ void drm_sched_entity_fini(struct 
drm_sched_entity *entity);

 void drm_sched_entity_destroy(struct drm_sched_entity *entity);
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
    struct drm_sched_entity *entity);
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq);
-
+void drm_sched_entity_set_priority(struct drm_sched_entity 
*entity

Re: [PATCH] drm/scheduler: fix setting the priorty for entities - bisected

[Dieter Nützel]

Am 04.08.2018 06:18, schrieb Dieter Nützel:

Am 04.08.2018 06:12, schrieb Dieter Nützel:

Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the "[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series is
causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter


Argh, shi...
wrong dmesg version.

Should be this one. (For sure...)


Puh,

this took some time...
During the 'last' git bisect run => 'first bad commit is' I got next 
freeze.

But I could get a new dmesg.log file per remote phone (see attachment).

git bisect log show this:

SOURCE/amd-staging-drm-next> git bisect log
git bisect start
# good: [adebfff9c806afe1143d69a0174d4580cd27b23d] drm/scheduler: fix 
setting the priorty for entities

git bisect good adebfff9c806afe1143d69a0174d4580cd27b23d
# bad: [43202e67a4e6fcb0e6b773e8eb1ed56e1721e882] drm/amdgpu: use entity 
instead of ring for CS

git bisect bad 43202e67a4e6fcb0e6b773e8eb1ed56e1721e882
# bad: [9867b3a6ddfb73ee3105871541053f8e49949478] drm/amdgpu: use 
scheduler load balancing for compute CS

git bisect bad 9867b3a6ddfb73ee3105871541053f8e49949478
# good: [5d097a4591aa2be16b21adbaa19a8abb76e47ea1] drm/amdgpu: use 
scheduler load balancing for SDMA CS

git bisect good 5d097a4591aa2be16b21adbaa19a8abb76e47ea1
# first bad commit: [9867b3a6ddfb73ee3105871541053f8e49949478] 
drm/amdgpu: use scheduler load balancing for compute CS


git log --oneline
5d097a4591aa (HEAD, 
refs/bisect/good-5d097a4591aa2be16b21adbaa19a8abb76e47ea1) drm/amdgpu: 
use scheduler load balancing for SDMA CS

d12ae5172f1f drm/amdgpu: use new scheduler load balancing for VMs
adebfff9c806 (refs/bisect/good-adebfff9c806afe1143d69a0174d4580cd27b23d) 
drm/scheduler: fix setting the priorty for entities
bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem 
definitions into amdgpu_gem header

5031ae5f9e5c drm/amdgpu: move psp macro into amdgpu_psp header
[-]

I'm not really sure that
drm/amdgpu: use scheduler load balancing for compute CS
is the offender.

One step earlier could it be, too.
drm/amdgpu: use scheduler load balancing for SDMA CS

I'm try running with the SDMA CS patch for the next days.

If you need more ask!

Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = &ctx->rings[i].entity;
-    rq = &ring->sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void 
drm_sched_entity_clear_dep(struct

dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq 
**rq,

+ enum drm_sched_priority priority)
+{
+    *rq = &(*rq)->sched->sched_rq[prior

Re: [PATCH] drm/scheduler: fix setting the priorty for entities - bisected

[Dieter Nützel]

Am 06.08.2018 02:13, schrieb Dieter Nützel:

Am 04.08.2018 06:18, schrieb Dieter Nützel:

Am 04.08.2018 06:12, schrieb Dieter Nützel:

Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the 
"[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series 
is

causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter


Argh, shi...
wrong dmesg version.

Should be this one. (For sure...)


Puh,

this took some time...
During the 'last' git bisect run => 'first bad commit is' I got next 
freeze.

But I could get a new dmesg.log file per remote phone (see attachment).

git bisect log show this:

SOURCE/amd-staging-drm-next> git bisect log
git bisect start
# good: [adebfff9c806afe1143d69a0174d4580cd27b23d] drm/scheduler: fix
setting the priorty for entities
git bisect good adebfff9c806afe1143d69a0174d4580cd27b23d
# bad: [43202e67a4e6fcb0e6b773e8eb1ed56e1721e882] drm/amdgpu: use
entity instead of ring for CS
git bisect bad 43202e67a4e6fcb0e6b773e8eb1ed56e1721e882
# bad: [9867b3a6ddfb73ee3105871541053f8e49949478] drm/amdgpu: use
scheduler load balancing for compute CS
git bisect bad 9867b3a6ddfb73ee3105871541053f8e49949478
# good: [5d097a4591aa2be16b21adbaa19a8abb76e47ea1] drm/amdgpu: use
scheduler load balancing for SDMA CS
git bisect good 5d097a4591aa2be16b21adbaa19a8abb76e47ea1
# first bad commit: [9867b3a6ddfb73ee3105871541053f8e49949478]
drm/amdgpu: use scheduler load balancing for compute CS

git log --oneline
5d097a4591aa (HEAD,
refs/bisect/good-5d097a4591aa2be16b21adbaa19a8abb76e47ea1) drm/amdgpu:
use scheduler load balancing for SDMA CS
d12ae5172f1f drm/amdgpu: use new scheduler load balancing for VMs
adebfff9c806
(refs/bisect/good-adebfff9c806afe1143d69a0174d4580cd27b23d)
drm/scheduler: fix setting the priorty for entities
bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header
5031ae5f9e5c drm/amdgpu: move psp macro into amdgpu_psp header
[-]

I'm not really sure that
drm/amdgpu: use scheduler load balancing for compute CS
is the offender.

One step earlier could it be, too.
drm/amdgpu: use scheduler load balancing for SDMA CS

I'm try running with the SDMA CS patch for the next days.

If you need more ask!


Hello Christian,

running the second day _without_ the 2. patch
[2/7] drm/amdgpu: use scheduler load balancing for SDMA CS
my system is stable, again.

To be clear.
I've now only #1 applied on top of amd-staging-drm-next.
'This one' is still in.
So we should switching the thread.

Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = &ctx->rings[i].entity;
-    rq = &ring->sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void 
drm_sched_entity_clear_dep(struct

dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_

drm-radeon-fix-typo-in-fetching-mpll-params.patch et.al isn't in 'drm-fixes' and 3.13-rc2

[Dieter Nützel]

Only a reminder.

Thanks,
Dieter

PS Hope all of you had have a nice first Sunday of Advent!

[drm/radeon] Nothing for stable is in 3.12.2, at least.

[Dieter Nützel]

Cheers,
Dieter

Re: [amd-staging-drm-next] regression - no fan info (sensors) on RX580

[Dieter Nützel]

Sorry Rex,

after return from our vacation,
I've tested latest amd-staging-drm-next (e5f6a57e350a)
but it is NOT solved on my RX580.
I'll try bisecting if I find some more time in the coming days.

amdgpu-pci-0100
Adapter: PCI adapter
temp1:+27.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] (rev e7) (prog-if 00 
[VGA controller])

Subsystem: Sapphire Technology Limited Radeon RX 570

[36.740] (--) AMDGPU(0): Chipset: "Radeon RX 580 Series" (ChipID = 
0x67df)


Thanks,
Dieter

Am 30.09.2017 05:09, schrieb Zhu, Rex:

Yes, caused by the commit e37a7b4088da
("drm/amd/powerplay: tidy up ret checks in amd_powerplay.c")

Replace error when split patches.

Have sent the fix patch.
Please review.

Best Regards
Rex


-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Friday, September 29, 2017 10:11 PM
To: Dieter Nützel; Zhu, Rex
Cc: amd-devel; DRI Devel; Wentland, Harry; Michel Dänzer
Subject: Re: [amd-staging-drm-next] regression - no fan info (sensors) 
on RX580


Rex, probably related to the recent cleanups in powerplay.

On Fri, Sep 29, 2017 at 10:09 AM, Dieter Nützel  
wrote:

Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to
our vacation.

Maybe in the evening (only a few commits).

Greetings,
Dieter

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [amd-staging-drm-next] regression - no fan info (sensors) on RX580

[Dieter Nützel]

OK, got it but can't revert the commit clean.

amdgpu-pci-0100
Adapter: PCI adapter
fan1: 873 RPM
temp1:+26.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

SOURCE/amd-staging-drm-next> git bisect good
0944c350c8eddf4064e7abb881dd245032fdfa23 is the first bad commit
commit 0944c350c8eddf4064e7abb881dd245032fdfa23
Author: Rex Zhu 
Date:   Mon Sep 25 18:51:50 2017 +0800

drm/amdgpu: delete pp_enable in adev

amdgpu not care powerplay or dpm is enabled.
just check ip functions and pp functions

Change-Id: Iaac75d45170ef9b20e212465f837eaaa798365bd
Reviewed-by: Alex Deucher 
Signed-off-by: Rex Zhu 

:04 04 72361654709479890586e383ec73088e535a1cf5 
2b6d5a75ffc3b6fd48c63e79bf28faddcc734918 M drivers


Greetings,
Dieter


Am 09.10.2017 02:19, schrieb Dieter Nützel:

Sorry Rex,

after return from our vacation,
I've tested latest amd-staging-drm-next (e5f6a57e350a)
but it is NOT solved on my RX580.
I'll try bisecting if I find some more time in the coming days.

amdgpu-pci-0100
Adapter: PCI adapter
temp1:+27.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] (rev e7) (prog-if 00
[VGA controller])
Subsystem: Sapphire Technology Limited Radeon RX 570

[36.740] (--) AMDGPU(0): Chipset: "Radeon RX 580 Series" (ChipID = 
0x67df)


Thanks,
Dieter

Am 30.09.2017 05:09, schrieb Zhu, Rex:

Yes, caused by the commit e37a7b4088da
("drm/amd/powerplay: tidy up ret checks in amd_powerplay.c")

Replace error when split patches.

Have sent the fix patch.
Please review.

Best Regards
Rex


-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Friday, September 29, 2017 10:11 PM
To: Dieter Nützel; Zhu, Rex
Cc: amd-devel; DRI Devel; Wentland, Harry; Michel Dänzer
Subject: Re: [amd-staging-drm-next] regression - no fan info (sensors) 
on RX580


Rex, probably related to the recent cleanups in powerplay.

On Fri, Sep 29, 2017 at 10:09 AM, Dieter Nützel  
wrote:

Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to
our vacation.

Maybe in the evening (only a few commits).

Greetings,
Dieter

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] amdgpu dc drm-next-4.15-dc

[Dieter Nützel]

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Last batch of new stuff for DC. Highlights:
- Fix some memory leaks
- S3 fixes
- Hotplug fixes
- Fix some CX multi-display issues
- MST fixes
- DML updates from the hw team
- Various code cleanups
- Misc bug fixes


Now this tree has the same fan regression as 'amd-staging-drm-next' 
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.


Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Second:
KDE's greeter 'kdm_greet' (login screen went into dpms) and KDE's 
'screen blank' (energy saving / dpms off) never came back. All I can do 
is a clean reboot. So I have to disable all 'dpms'.

But I could attach gdb remotely on it.
'kdm_greet' hang in 'poll'.
Nothing alarming in 'dmesg' and 'Xorg.0.log'. (Both available taken from 
'amd-staging-drm-next' if needed).


Cheers,
Dieter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] amdgpu dc drm-next-4.15-dc

[Dieter Nützel]

Am 22.10.2017 23:48, schrieb Dieter Nützel:

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Last batch of new stuff for DC. Highlights:
- Fix some memory leaks
- S3 fixes
- Hotplug fixes
- Fix some CX multi-display issues
- MST fixes
- DML updates from the hw team
- Various code cleanups
- Misc bug fixes


Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Second:
KDE's greeter 'kdm_greet' (login screen went into dpms) and KDE's
'screen blank' (energy saving / dpms off) never came back. All I can
do is a clean reboot. So I have to disable all 'dpms'.
But I could attach gdb remotely on it.
'kdm_greet' hang in 'poll'.
Nothing alarming in 'dmesg' and 'Xorg.0.log'. (Both available taken
from 'amd-staging-drm-next' if needed).


Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the 'screen 
blank' (monitor standby mode):

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe due 
to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within KDE 
session with replugging the video cable, but for all later tests on both 
kernels I have to blindly switching back to login screen (kdm_greet) and 
then replugging the video cable.


For me these regression started with 'amd-staging-drm-next' much earlier 
than with the latest commit.


Dieter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] amdgpu dc drm-next-4.15-dc

[Dieter Nützel]

Hello Alex & Rex,

any progress?
The 'screen blank' (monitor standby mode) is really annoying.

Thanks,
Dieter

Am 23.10.2017 03:03, schrieb Dieter Nützel:

Am 22.10.2017 23:48, schrieb Dieter Nützel:

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Last batch of new stuff for DC. Highlights:
- Fix some memory leaks
- S3 fixes
- Hotplug fixes
- Fix some CX multi-display issues
- MST fixes
- DML updates from the hw team
- Various code cleanups
- Misc bug fixes


Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Second:
KDE's greeter 'kdm_greet' (login screen went into dpms) and KDE's
'screen blank' (energy saving / dpms off) never came back. All I can
do is a clean reboot. So I have to disable all 'dpms'.
But I could attach gdb remotely on it.
'kdm_greet' hang in 'poll'.
Nothing alarming in 'dmesg' and 'Xorg.0.log'. (Both available taken
from 'amd-staging-drm-next' if needed).


Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the
'screen blank' (monitor standby mode):
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe due
to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within
KDE session with replugging the video cable, but for all later tests
on both kernels I have to blindly switching back to login screen
(kdm_greet) and then replugging the video cable.

For me these regression started with 'amd-staging-drm-next' much
earlier than with the latest commit.

Dieter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] amdgpu dc drm-next-4.15-dc

[Dieter Nützel]

Am 26.10.2017 19:26, schrieb Alex Deucher:
On Thu, Oct 26, 2017 at 10:10 AM, Dieter Nützel  
wrote:

Hello Alex & Rex,

any progress?
The 'screen blank' (monitor standby mode) is really annoying.


Does this patch help?
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=ddabbf65aae36e21b4c79354940f80eae6c36104

Alex


Yes, it seems so. Many thanks to Jerry for this fix.
I've tested it with latest amd-staging-drm-next #4ce527eb8bb3 on my 
Polaris 20. Both cases (kdm_greet and 'screen blank') are solved. W'll 
apply it on drm-next-4.15-dc, too.


Side note:
HDMI audio is _gone_ after logout and relogin.
Missing reinitialization?

Next:
Fix fan speed...

Thank you very much!
Dieter



Thanks,
Dieter

Am 23.10.2017 03:03, schrieb Dieter Nützel:


Am 22.10.2017 23:48, schrieb Dieter Nützel:


Am 21.10.2017 23:22, schrieb Alex Deucher:


Hi Dave,

Last batch of new stuff for DC. Highlights:
- Fix some memory leaks
- S3 fixes
- Hotplug fixes
- Fix some CX multi-display issues
- MST fixes
- DML updates from the hw team
- Various code cleanups
- Misc bug fixes



Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Second:
KDE's greeter 'kdm_greet' (login screen went into dpms) and KDE's
'screen blank' (energy saving / dpms off) never came back. All I can
do is a clean reboot. So I have to disable all 'dpms'.
But I could attach gdb remotely on it.
'kdm_greet' hang in 'poll'.
Nothing alarming in 'dmesg' and 'Xorg.0.log'. (Both available taken
from 'amd-staging-drm-next' if needed).



Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the
'screen blank' (monitor standby mode):

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe 
due

to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within
KDE session with replugging the video cable, but for all later tests
on both kernels I have to blindly switching back to login screen
(kdm_greet) and then replugging the video cable.

For me these regression started with 'amd-staging-drm-next' much
earlier than with the latest commit.

Dieter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: once more fix ttm_buffer_object_transfer

[Dieter Nützel]

Hello Christian,

is this for these warnings flooding my dmesg-log or do I have to open a 
new ticket:


Current amd-staging-drm-next commit #7781a8c68a6a from you ;-)

[ 6588.429302] WARNING: CPU: 5 PID: 2957 at 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 
generic_reg_update_ex+0xdc/0x120 [amdgpu]
[ 6588.429303] Modules linked in: fuse rfcomm rpcsec_gss_krb5 
auth_rpcgss nfsv4 nf_log_ipv6 xt_comment nf_log_ipv4 nf_log_common 
xt_LOG xt_limit dns_resolver nfs lockd nfnetlink_cthelper nfnetlink 
grace sunrpc fscache af_packet ipmi_ssif iscsi_ibft iscsi_boot_sysfs 
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT 
nf_reject_ipv4 xt_pkttype xt_tcpudp iptable_filter ip6table_mangle 
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 
nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack libcrc32c bnep 
ip6table_filter ip6_tables x_tables jc42 joydev snd_hda_codec_hdmi 
snd_hda_intel intel_powerclamp coretemp snd_hda_codec kvm_intel 
snd_hwdep kvm snd_hda_core snd_pcm e1000e iTCO_wdt hid_generic snd_timer 
iTCO_vendor_support snd usbhid irqbypass btusb crc32c_intel btrtl btbcm
[ 6588.429340]  pcspkr ptp soundcore btintel bluetooth pps_core 
i7core_edac i2c_i801 tpm_infineon tpm_tis lpc_ich shpchp tpm_tis_core 
ipmi_si tpm ipmi_devintf ipmi_msghandler ac button rfkill ecdh_generic 
acpi_cpufreq tcp_bbr raid1 md_mod amdkfd amd_iommu_v2 serio_raw amdgpu 
sr_mod cdrom chash i2c_algo_bit drm_kms_helper syscopyarea ehci_pci 
sysfillrect sysimgblt ehci_hcd fb_sys_fops mpt3sas raid_class ttm 
scsi_transport_sas usbcore drm sg dm_multipath dm_mod scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua
[ 6588.429370] CPU: 5 PID: 2957 Comm: X Tainted: GW   
4.13.0-rc5-1.g7262353-default+ #1
[ 6588.429371] Hardware name: FUJITSU  PRIMERGY 
TX150 S7 /D2759, BIOS 6.00 Rev. 1.19.2759.A1   
09/26/2012

[ 6588.429373] task: 8841a3658080 task.stack: 9ce4c3c38000
[ 6588.429426] RIP: 0010:generic_reg_update_ex+0xdc/0x120 [amdgpu]
[ 6588.429427] RSP: 0018:9ce4c3c3b760 EFLAGS: 00010246
[ 6588.429429] RAX: 0030 RBX:  RCX: 

[ 6588.429430] RDX: 0001 RSI:  RDI: 
8841a36c1980
[ 6588.429431] RBP: 9ce4c3c3b7c8 R08: 00ff R09: 
9ce4c3c3b778
[ 6588.429432] R10:  R11: 0002 R12: 
9ce4c3c3b7f8
[ 6588.429433] R13:  R14:  R15: 

[ 6588.429436] FS:  7f206d780a40() GS:8841bfd4() 
knlGS:

[ 6588.429437] CS:  0010 DS:  ES:  CR0: 80050033
[ 6588.429439] CR2: 7f745636a000 CR3: 0006654a5000 CR4: 
06e0

[ 6588.429439] Call Trace:
[ 6588.429498]  dce_mi_program_pte_vm+0x211/0x270 [amdgpu]
[ 6588.429555]  dce110_program_front_end_for_pipe+0x256/0x370 [amdgpu]
[ 6588.429613]  dce110_apply_ctx_for_surface+0xda/0x200 [amdgpu]
[ 6588.429668]  dc_commit_updates_for_stream+0x46a/0x4e0 [amdgpu]
[ 6588.429725]  dc_commit_planes_to_stream+0x322/0x380 [amdgpu]
[ 6588.429783]  amdgpu_dm_atomic_commit_tail+0x72a/0xaf0 [amdgpu]
[ 6588.429787]  ? ww_mutex_unlock+0x26/0x30
[ 6588.429844]  ? dm_plane_helper_prepare_fb+0xd2/0x230 [amdgpu]
[ 6588.429853]  ? drm_atomic_helper_wait_for_dependencies+0x89/0x160 
[drm_kms_helper]
[ 6588.429861]  ? drm_atomic_helper_swap_state+0x18d/0x360 
[drm_kms_helper]

[ 6588.429868]  commit_tail+0x3f/0x60 [drm_kms_helper]
[ 6588.429875]  drm_atomic_helper_commit+0x106/0x110 [drm_kms_helper]
[ 6588.429931]  amdgpu_dm_atomic_commit+0x8d/0xa0 [amdgpu]
[ 6588.429948]  drm_atomic_commit+0x4b/0x50 [drm]
[ 6588.429957]  drm_atomic_helper_legacy_gamma_set+0x114/0x150 
[drm_kms_helper]

[ 6588.429971]  drm_mode_gamma_set_ioctl+0x127/0x190 [drm]
[ 6588.429985]  ? drm_mode_crtc_set_gamma_size+0xb0/0xb0 [drm]
[ 6588.429997]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[ 6588.430009]  drm_ioctl+0x31a/0x3d0 [drm]
[ 6588.430024]  ? drm_mode_crtc_set_gamma_size+0xb0/0xb0 [drm]
[ 6588.430027]  ? vfs_writev+0xaa/0xf0
[ 6588.430063]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[ 6588.430065]  do_vfs_ioctl+0x92/0x5c0
[ 6588.430067]  ? __fget+0x6e/0x90
[ 6588.430069]  ? __fget+0x6e/0x90
[ 6588.430071]  SyS_ioctl+0x79/0x90
[ 6588.430075]  entry_SYSCALL_64_fastpath+0x1e/0xa9
[ 6588.430077] RIP: 0033:0x7f206b0fa077
[ 6588.430078] RSP: 002b:7ffd89a37978 EFLAGS: 3246 ORIG_RAX: 
0010
[ 6588.430080] RAX: ffda RBX: 00c3495ed210 RCX: 
7f206b0fa077
[ 6588.430081] RDX: 7ffd89a379b0 RSI: c02064a5 RDI: 
000d
[ 6588.430082] RBP: 00c34a30a690 R08: 00c349740ce0 R09: 
00c349740ee0
[ 6588.430083] R10: 0001 R11: 3246 R12: 
00c3488cd300
[ 6588.430084] R13: 00c34a30a690 R14: 00c34a6c3980 R15: 
0020
[ 6588.430086] Code: 45 21 e8 44 31 c3 41 39 d3 75 ab 45 84 d2 75 45 48 
8b 7f 18 89 da 48 8b 07 ff 50 38 48 83 c4 48 89 d8 5b 41 5a 41 5c 4

Re: [radeon-alex:amd-staging-drm-next 68/819] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:154:10: error: 'drm_atomic_helper_connector_dpms' undeclared here (not in a function

[Dieter Nützel]

I've send a related kernel crash log to amd-devel some days ago without 
any answer, yet...


Was:
[amd-staging-drm-next] kernel crash with amdgpu on RX580 in 
'drm_object_property_get_value'


I get this in _all_ current 'amd-staging-drm-next' versions. ;-(

[16301.515079] [ cut here ]
[16301.515105] WARNING: CPU: 4 PID: 11871 at 
drivers/gpu/drm/drm_mode_object.c:294 
drm_object_property_get_value+0x22/0x30 [drm]
[16301.515106] Modules linked in: fuse rfcomm nf_log_ipv6 xt_comment 
nf_log_ipv4 nf_log_common xt_LOG xt_limit rpcsec_gss_krb5 auth_rpcgss 
nfsv4 dns_resolver nfs lockd nfnetlink_cthelper grace nfnetlink sunrpc 
fscache af_packet ipmi_ssif iscsi_ibft iscsi_boot_sysfs ip6t_REJECT 
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT 
nf_reject_ipv4 xt_pkttype xt_tcpudp iptable_filter ip6table_mangle 
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 
nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack libcrc32c 
ip6table_filter ip6_tables x_tables jc42 bnep joydev snd_hda_codec_hdmi 
snd_hda_intel snd_hda_codec btusb snd_hwdep btrtl snd_hda_core btbcm 
btintel bluetooth snd_pcm e1000e intel_powerclamp iTCO_wdt snd_timer 
coretemp iTCO_vendor_support hid_generic snd ptp kvm_intel pps_core 
rfkill
[16301.515129]  kvm ecdh_generic tpm_infineon soundcore irqbypass 
tpm_tis tpm_tis_core crc32c_intel pcspkr shpchp ipmi_si tpm usbhid 
i2c_i801 i7core_edac lpc_ich ipmi_devintf ipmi_msghandler ac button 
acpi_cpufreq tcp_bbr raid1 md_mod amdkfd amd_iommu_v2 serio_raw sr_mod 
cdrom amdgpu mpt3sas i2c_algo_bit raid_class scsi_transport_sas 
drm_kms_helper syscopyarea sysfillrect ehci_pci sysimgblt fb_sys_fops 
ehci_hcd ttm usbcore drm sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc 
scsi_dh_alua
[16301.515147] CPU: 4 PID: 11871 Comm: X Tainted: GW   
4.13.0-rc5-1.g7262353-default+ #1
[16301.515148] Hardware name: FUJITSU  PRIMERGY 
TX150 S7 /D2759, BIOS 6.00 Rev. 1.19.2759.A1   
09/26/2012

[16301.515149] task: 90c49525a180 task.stack: b84786ef4000
[16301.515156] RIP: 0010:drm_object_property_get_value+0x22/0x30 [drm]
[16301.515157] RSP: 0018:b84786ef7bf8 EFLAGS: 00010282
[16301.515158] RAX: c03f0cc0 RBX: 90c52200 RCX: 

[16301.515158] RDX: b84786ef7c10 RSI: 90c523837600 RDI: 
90c523b19028
[16301.515159] RBP: b84786ef7bf8 R08: 90c41ee28280 R09: 
90c515defc00
[16301.515159] R10: 00024bb8 R11:  R12: 

[16301.515160] R13: 90c523b19000 R14: ffea R15: 
90c511e8c100
[16301.515161] FS:  7f86f15c9a40() GS:90c53fd0() 
knlGS:

[16301.515162] CS:  0010 DS:  ES:  CR0: 80050033
[16301.515162] CR2: 000849a98680 CR3: 0005dcc1a000 CR4: 
06e0

[16301.515163] Call Trace:
[16301.515255]  amdgpu_dm_connector_atomic_set_property+0xe8/0x150 
[amdgpu]

[16301.515292]  drm_atomic_set_property+0x164/0x470 [drm]
[16301.515300]  drm_mode_obj_set_property_ioctl+0x10b/0x240 [drm]
[16301.515311]  ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm]
[16301.515318]  drm_mode_connector_property_set_ioctl+0x30/0x40 [drm]
[16301.515324]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[16301.515332]  drm_ioctl+0x31a/0x3d0 [drm]
[16301.515339]  ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm]
[16301.515342]  ? ext4_file_write_iter+0xba/0x390
[16301.515362]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[16301.515365]  do_vfs_ioctl+0x92/0x5c0
[16301.515367]  ? __fget+0x6e/0x90
[16301.515368]  SyS_ioctl+0x79/0x90
[16301.515372]  entry_SYSCALL_64_fastpath+0x1e/0xa9
[16301.515373] RIP: 0033:0x7f86eef46507
[16301.515373] RSP: 002b:7fffe5f9dca8 EFLAGS: 3246 ORIG_RAX: 
0010
[16301.515374] RAX: ffda RBX: 00084aeea990 RCX: 
7f86eef46507
[16301.515375] RDX: 7fffe5f9dce0 RSI: c01064ab RDI: 
000d
[16301.515375] RBP: 00084b50d830 R08: 00084b07d690 R09: 
0001
[16301.515376] R10: 0004 R11: 3246 R12: 
00084aeea990
[16301.515376] R13: 0005 R14: 00084aeeedd0 R15: 
00084aeeedd0
[16301.515377] Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 46 
60 55 48 89 e5 48 8b 80 70 03 00 00 48 83 78 20 00 75 07 e8 60 ff ff ff 
5d c3 <0f> ff e8 57 ff ff ff 5d c3 0f 1f 44 00 00 66 66 66 66 90 55 48

[16301.515394] ---[ end trace f957c1d5844ce46f ]---

Thanks,
Dieter

Am 30.08.2017 00:22, schrieb kbuild test robot:
tree:   git://people.freedesktop.org/~agd5f/linux.git 
amd-staging-drm-next

head:   ff14f0dca1f23b2cff41e43440c7952965e5fc1b
commit: 9b37a9b8f6464e3ce1ce59eda1ec7053c8e77ca3 [68/819] drm/amd/dc:
Add dc display driver (v2)
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
  

[amd-staging-drm-next] regression - no fan info (sensors) on RX580

[Dieter Nützel]

Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to our 
vacation.


Maybe in the evening (only a few commits).

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

Re: [amd-staging-drm-next] regression - *ERROR* Don't have enable_spread_spectrum_on_ppll for v4

[Dieter Nützel]

Am 03.01.2018 16:03, schrieb Harry Wentland:

On 2017-12-27 04:04 AM, Michel Dänzer wrote:

On 2017-12-27 05:43 AM, Dieter Nützel wrote:

Hello AMD team,

I got this since latest 'amd-staging-drm-next' git update
(#b956c586e58a) during boot with Polaris RX580 DC on:

[    3.586342] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* 
Don't

have enable_spread_spectrum_on_ppll for v4
[    3.586410] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* 
Don't

have program_clock for v7

Latest GOOD commit was #b341a19e8039 (drm/radeon: Remove
KFD_CIK_SDMA_QUEUE_OFFSET).

I'll bisect if I have some time.
Maybe someone send a hint to the right commit.


I don't think bisecting is useful, it'll most likely just identify
commit 040dda2e1f52 ("drm/amd/display: Error print when ATOM BIOS
implementation is missing") which started printing these messages for
missing ATOM BIOS implementations.

I'm not sure, but I suspect these messages are harmless, given that
things are otherwise presumably still working as well as they were 
before.


These are harmless. I wrongfully assumed that printing errors here
should be fine on all ASICs as I assumed all relevant functions were
implemented. Apparently they're not, proving me wrong and proving the
usefulness of some sort of print here. I'll send a patch to demote the
prints to debug level.

Harry


Thank you Harry,

current amd-staging-drm-next (#0a7d506e54ca) calmed it, at least for me. 
;-)


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

Re: Resizeable PCI BAR support V5

[Dieter Nützel]

Hello Christian,

after (long ;-)) vacation, injured wife (bad lumbago/luckily NO disc 
prolapse) on 2cond day @ our target, our daughter's 12th birthday, 
school start for both kids and mostly dad work I'm back...


Do you have a V6 handy.
Will do my fingers dirty if no Intel guy beats me at it.

Greetings,
Dieter

Am 30.06.2017 14:55, schrieb Christian König:

Hi Dieter,

thanks a lot for testing that.

But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 
(Nehalem), PCIe 2.0, 24 GB is to old for this stuff...

Well, actually you only need to figure out how to enable a PCIe window
above the 4GB limit.

Could be that the BIOS supports this with the ACPI tables (totally
unlikely) or you could try to dig up the Northbridge documentation for
this CPU from Intel and use my patch for the AMD CPUs as blueprint how
to do this on an Intel CPU as well.

Fact is you GFX hardware is perfectly capable of doing this, it's just
that the BIOS/Motherboard didn't enabled a PCIe window per default to
avoid problems with 32bit OSes.

Regards,
Christian.

Am 30.06.2017 um 01:51 schrieb Dieter Nützel:

Hello Christian,

I've running this since you've sent it on-top of amd-staging-4.11. But 
I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 
(Nehalem), PCIe 2.0, 24 GB is to old for this stuff...


[1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 
0x-0x0003 64bit] (contains BAR0 for 16 VFs)
[1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 
0x-0x003f 64bit] (contains BAR2 for 16 VFs)
[1.121656] pci :00:1c.0: BAR 15: assigned [mem 
0x8000-0x801f 64bit pref]
[1.121659] pci :00:1c.6: BAR 15: assigned [mem 
0x8020-0x803f 64bit pref]
[1.121662] pci :01:00.0: BAR 6: assigned [mem 
0xb012-0xb013 pref]
[1.121681] pci :05:00.0: BAR 6: assigned [mem 
0xb028-0xb02f pref]
[1.121683] pci :05:00.0: BAR 9: no space for [mem size 
0x0040 64bit]
[1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 
0x0040 64bit]
[1.121685] pci :05:00.0: BAR 7: no space for [mem size 
0x0004 64bit]
[1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 
0x0004 64bit]
[3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 
0xc000-0xcfff 64bit pref]
[3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 
0xb040-0xb05f 64bit pref]
[3.874198] pcieport :00:03.0: BAR 15: releasing [mem 
0xb040-0xcfff 64bit pref]
[3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 
0x3 64bit pref]
[3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem 
size 0x3 64bit pref]
[3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 
0x2 64bit pref]
[3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 
0x2 64bit pref]
[3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 
0x0020 64bit pref]
[3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 
0x0020 64bit pref]

[3.874258] [drm] Not enough PCI address space for a large BAR.
[3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 
0xc000-0xcfff 64bit pref]
[3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 
0xb040-0xb05f 64bit pref]

[3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M

Anyway rebase for current amd-staging-4.11 needed.
Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz

Greetings,
Dieter

Am 09.06.2017 10:59, schrieb Christian König:

Hi everyone,

This is the fith incarnation of this set of patches. It enables 
device
drivers to resize and most likely also relocate the PCI BAR of 
devices
they manage to allow the CPU to access all of the device local memory 
at once.


This is very useful for GFX device drivers where the default PCI BAR 
is only
about 256MB in size for compatibility reasons, but the device easily 
have

multiple gigabyte of local memory.

Some changes since V4:
1. Rebased on 4.11.
2. added the rb from Andy Shevchenko to patches which look complete 
now.
3. Move releasing the BAR and reallocating it on error to the driver 
side.

4. Add amdgpu support for GMC V6 hardware generation as well.

Please review and/or comment,
Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Operation context for TTM

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on RX580
amd-staging-drm-next 85d09ce5e5039644487e9508d6359f9f4cf64427

with glmark2, DiRT Rally and F1 2017 (radv)

Dieter

Am 17.11.2017 11:49, schrieb Christian König:

Hi everyone,

Michel already reviewed this back in April, but I didn't found time to
actually fully test it before now.

So sending this one out once more because it's an interface change
which affects all driver using TTM.

Please review and/or comment.

Regards,
Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [amd-staging-drm-next] regression - no fan info (sensors) on RX580

[Dieter Nützel]

That did it.

a716d5540346 (HEAD -> amd-staging-drm-next) drm/amdgpu: don't skip 
attributes when powerplay is enabled
9f896d936c9d (origin/amd-staging-drm-next) drm/amdgpu: fix VCE buffer 
placement restrictions v2

ca9b5d953735 drm/amdgpu: align GTT start to 4GB v2
52364b9f0226 drm/amdgpu: remove VRAM size reduction v2
95d8c587cba5 drm/amd/pp: fix typecast error in powerplay.
[-]

amdgpu-pci-0100
Adapter: PCI adapter
fan1: 881 RPM
temp1:+29.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

Tested-by: Dieter Nützel 

Thank you very much Alex!

Dieter

Am 20.11.2017 23:57, schrieb Alex Deucher:
On Sun, Oct 8, 2017 at 10:31 PM, Dieter Nützel  
wrote:

OK, got it but can't revert the commit clean.

amdgpu-pci-0100
Adapter: PCI adapter
fan1: 873 RPM
temp1:+26.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

SOURCE/amd-staging-drm-next> git bisect good
0944c350c8eddf4064e7abb881dd245032fdfa23 is the first bad commit
commit 0944c350c8eddf4064e7abb881dd245032fdfa23
Author: Rex Zhu 
Date:   Mon Sep 25 18:51:50 2017 +0800

drm/amdgpu: delete pp_enable in adev

amdgpu not care powerplay or dpm is enabled.
just check ip functions and pp functions

Change-Id: Iaac75d45170ef9b20e212465f837eaaa798365bd
Reviewed-by: Alex Deucher 
Signed-off-by: Rex Zhu 

:04 04 72361654709479890586e383ec73088e535a1cf5
2b6d5a75ffc3b6fd48c63e79bf28faddcc734918 M drivers


I think the attached patch should fix it.

Alex



Greetings,
Dieter



Am 09.10.2017 02:19, schrieb Dieter Nützel:


Sorry Rex,

after return from our vacation,
I've tested latest amd-staging-drm-next (e5f6a57e350a)
but it is NOT solved on my RX580.
I'll try bisecting if I find some more time in the coming days.

amdgpu-pci-0100
Adapter: PCI adapter
temp1:+27.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] (rev e7) (prog-if 00
[VGA controller])
Subsystem: Sapphire Technology Limited Radeon RX 570

[36.740] (--) AMDGPU(0): Chipset: "Radeon RX 580 Series" (ChipID 
=

0x67df)

Thanks,
Dieter

Am 30.09.2017 05:09, schrieb Zhu, Rex:


Yes, caused by the commit e37a7b4088da
("drm/amd/powerplay: tidy up ret checks in amd_powerplay.c")

Replace error when split patches.

Have sent the fix patch.
Please review.

Best Regards
Rex


-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Friday, September 29, 2017 10:11 PM
To: Dieter Nützel; Zhu, Rex
Cc: amd-devel; DRI Devel; Wentland, Harry; Michel Dänzer
Subject: Re: [amd-staging-drm-next] regression - no fan info 
(sensors) on

RX580

Rex, probably related to the recent cleanups in powerplay.

On Fri, Sep 29, 2017 at 10:09 AM, Dieter Nützel 


wrote:


Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to
our vacation.

Maybe in the evening (only a few commits).

Greetings,
Dieter


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Operation context for TTM

[Dieter Nützel]

Hello Christian,

your latest 'amd-staging-drm-next' commit
drm/amdgpu: fix VCE buffer placement restrictions v2
#9f896d936c9d4ea936a02d52eaeb14fdd209193b

static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser *p, uint32_t 
ib_idx,

  int lo, int hi, unsigned size, int32_t index)

[-]

return ttm_bo_validate(&bo->tbo, &bo->placement, false, false);

^^
'ttm_bo_validate' with 4 than 3 parameter clash.

drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c: In function 
‘amdgpu_vce_validate_bo’:
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:590:9: error: too many arguments 
to function ‘ttm_bo_validate’

  return ttm_bo_validate(&bo->tbo, &bo->placement, false, false);
 ^~~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu.h:39:0,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:33:
./include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
 int ttm_bo_validate(struct ttm_buffer_object *bo,
 ^~~

New version comming?

Thanks,
Dieter


Am 20.11.2017 05:35, schrieb Dieter Nützel:

For the series:

Tested-by: Dieter Nützel 

on RX580
amd-staging-drm-next 85d09ce5e5039644487e9508d6359f9f4cf64427

with glmark2, DiRT Rally and F1 2017 (radv)

Dieter

Am 17.11.2017 11:49, schrieb Christian König:

Hi everyone,

Michel already reviewed this back in April, but I didn't found time to
actually fully test it before now.

So sending this one out once more because it's an interface change
which affects all driver using TTM.

Please review and/or comment.

Regards,
Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: swap consecutive allocated pooled pages v4

[Dieter Nützel]

Tested-by: Dieter Nützel 

Dieter

Am 05.12.2017 13:54, schrieb Christian König:

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page
v4: don't touch the loop variable

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b6f7ce286fb1..44343a2bf55c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -958,8 +958,15 @@ static int ttm_get_pages(struct page **pages,
unsigned npages, int flags,
r = ttm_page_pool_get_pages(pool, &plist, flags, cstate,
npages - count, 0);

-   list_for_each_entry(p, &plist, lru)
-   pages[count++] = p;
+   first = count;
+   list_for_each_entry(p, &plist, lru) {
+   struct page *tmp = p;
+
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == tmp - 1)
+   swap(tmp, pages[count - 1]);
+   pages[count++] = tmp;
+   }

if (r) {
/* If there is any pages in the list put them back to

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/2] AMDGPU scheduler move, take 2

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on RX580 8GB

with UH, UV, Blender 2.79, smoketest (Vulkan), glmark2 (parallel with 
OpenCL (/opt/opencl-example>./run_tests.sh))


Dieter

Am 06.12.2017 17:49, schrieb Lucas Stach:

Hi all,

second try to move the AMDGPU scheduler into a common location, this
time rebased onto drm-next-4.16-wip.

I've tested my etnaviv series on top of this and things seem to work
fine. I checked that AMDGPU still builds, but I don't have any means
to actually runtime test this currently, so I would be very happy to
receive some tested-bys from the AMD side.

Alex, if this looks good please pull this in so it gets your usual
testing.

Thanks,
Lucas

Lucas Stach (2):
  drm: move amd_gpu_scheduler into common location
  drm/sched: move fence slab handling to module init/exit

 drivers/gpu/drm/Kconfig|   5 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
 drivers/gpu/drm/scheduler/Makefile |   4 +
 .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 
++---

 drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
 include/drm/gpu_scheduler.h| 173 
 .../drm/gpu_scheduler_trace.h  |  14 +-
 .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
 35 files changed, 529 insertions(+), 523 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
 create mode 100644 drivers/gpu/drm/scheduler/Makefile
 rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
 rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
 create mode 100644 include/drm/gpu_scheduler.h
 rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h =>
include/drm/gpu_scheduler_trace.h (82%)
 rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h 
(95%)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[amd-staging-drm-next] regression - *ERROR* Don't have enable_spread_spectrum_on_ppll for v4

[Dieter Nützel]

Hello AMD team,

I got this since latest 'amd-staging-drm-next' git update 
(#b956c586e58a) during boot with Polaris RX580 DC on:


[3.586342] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't 
have enable_spread_spectrum_on_ppll for v4
[3.586410] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't 
have program_clock for v7


Latest GOOD commit was #b341a19e8039 (drm/radeon: Remove 
KFD_CIK_SDMA_QUEUE_OFFSET).


I'll bisect if I have some time.
Maybe someone send a hint to the right commit.

Thanks,
Dieter[0.00] microcode: microcode updated early to revision 0x7, date = 
2013-08-20
[0.00] Linux version 4.15.0-rc2-1.g7262353-default+ (dieter@SunWave1) 
(gcc version 7.2.1 20171020 [gcc-7-branch revision 253932] (SUSE Linux)) #1 SMP 
PREEMPT Wed Dec 20 22:10:01 CET 2017
[0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc2-1.g7262353-default+ 
root=UUID=e19dd5e4-9df9-4ed6-8962-2d8f4993b6a5 video=1920x1080 noresume 
splash=silent quiet showopts amdgpu.dc=1
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009b7ff] usable
[0.00] BIOS-e820: [mem 0x0009b800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d-0x000d7fff] reserved
[0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7f7a] usable
[0.00] BIOS-e820: [mem 0x7f7b-0x7f7bbfff] ACPI data
[0.00] BIOS-e820: [mem 0x7f7bc000-0x7f7bcfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7f7bd000-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfecf] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00067fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.6 present.
[0.00] DMI: FUJITSU  PRIMERGY TX150 S7  
   /D2759, BIOS 6.00 Rev. 1.19.2759.A1   09/26/2012
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x68 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C7FFF write-protect
[0.00]   C8000-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 1 mask F write-back
[0.00]   2 base 2 mask E write-back
[0.00]   3 base 4 mask E write-back
[0.00]   4 base 6 mask F8000 write-back
[0.00]   5 base 0FE00 mask FFE00 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: update [mem 0x8000-0x] usable ==> reserved
[0.00] e820: last_pfn = 0x7f7b0 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f97c0-0x000f97cf] mapped at [
(ptrval)]
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [(ptrval)] 95000 size 24576
[0.00] BRK [0x35d3d, 0x35d3d0fff] PGTABLE
[0.00] BRK [0x35d3d1000, 0x35d3d1fff] PGTABLE
[0.00] BRK [0x35d3d2000, 0x35d3d2fff] PGTABLE
[0.00] BRK [0x35d3d3000, 0x35d3d3fff] PGTABLE
[0.00] BRK [0x35d3d4000, 0x35d3d4fff] PGTABLE
[0.00] BRK [0x35d3d5000, 0x35d3d5fff] PGTABLE
[0.00] BRK [0x35d3d6000, 0x35d3d6fff] PGTABLE
[0.00] BRK [0x35d3d7000, 0x35d3d7fff] PGTABLE
[0.00] RAMDISK: [mem 0x36517000-0x37282fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F9790 24 (v02 PTLTD )
[0.00] ACPI: XSDT 0x7F7B4206 00010C (v01 PTLTD  ? XSDT   
0006  LTP )
[0.00] ACPI: FACP 0x7F7B9D07 F4 (v03 FTSD2759/Ax 
0006 FTS  000F4240)
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Pm1aControlBlock: 16/32 (20170831/tbfadt-603)
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Pm2ControlBlock: 8/32 (20170831/tbfadt-603)
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/PmTimerBlock: 32/24 (20170831/tbfadt-603)
[0.00] ACPI

Congrats AMD-Team! --- RX480 + Mesa-git + 4.7-rcX

[Dieter Nützel]

Well done!

Best wishes.

Dieter

Re: UVD fails to init on rv790

[Dieter Nützel]

Am 2013-04-03 15:21, schrieb Alex Deucher:
On Wed, Apr 3, 2013 at 7:29 AM, Christian König 
 wrote:

Hi Andy,

crap! I feared that something like this would happen. IIRC we never 
tested

UVD on an rv790, and this hardware isn't easy to get any more.

RV770/RV790 have a separate UVD hardware generation (that's why they 
have
their own firmware) and there possible is some bug or something like 
this
that we haven't implemented. You couldn't give me SSH access to that 
system?


I tested on an RV770 earlier in development and it was working ok at
the time I think.  I'll give it another try today.

Alex



Hello Alex,

time goes by so fast --- wife, home, 2 children...

but what do I need:
I'll test it on my 2 HD4650/RV730 AGP (!) low speed Duron and dual 
Athlon MP.


git:// drm-fixes kernel
git:// mesa
patches

R700_rlc.bin
RV710_uvd.bin

BTW Any hints for libvdpau_r600.so.1.0.0?
I get wrong colors (red is like blue, blue is like yellow, etc.)

Thank you very much for all your GREAT work!
UVD - What a big day!

Regards,
  Dieter

--
The Voodoo5 5000 Dieter...-)
Anyone want's it? - I have the original package etc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UVD fails to init on rv790

[Dieter Nützel]

Am 2013-04-03 23:06, schrieb Alex Deucher:
On Wed, Apr 3, 2013 at 4:45 PM, Dieter Nützel  
wrote:

Am 2013-04-03 15:21, schrieb Alex Deucher:

On Wed, Apr 3, 2013 at 7:29 AM, Christian König 


wrote:


Hi Andy,

crap! I feared that something like this would happen. IIRC we never
tested
UVD on an rv790, and this hardware isn't easy to get any more.

RV770/RV790 have a separate UVD hardware generation (that's why 
they have
their own firmware) and there possible is some bug or something 
like this
that we haven't implemented. You couldn't give me SSH access to 
that

system?



I tested on an RV770 earlier in development and it was working ok at
the time I think.  I'll give it another try today.

Alex




Hello Alex,

time goes by so fast --- wife, home, 2 children...

but what do I need:
I'll test it on my 2 HD4650/RV730 AGP (!) low speed Duron and dual 
Athlon

MP.

git:// drm-fixes kernel
git:// mesa
patches

R700_rlc.bin
RV710_uvd.bin

BTW Any hints for libvdpau_r600.so.1.0.0?
I get wrong colors (red is like blue, blue is like yellow, etc.)



What are you testing with?


Only mplayer (defaults to vdpau, really?) of course without UVD, 
currently.
Works much better on the slow children's Duron. I have ~10% idle left 
on our Duron 1800. Without vdpau lib together with HD4650 unplayable on 
this system.


/home/dieter> mplayer /data/Filme/Serenity\ -\ HD\ DVD\ Trailer.mp4
MPlayer dev-SVN-r35127-4.7-openSUSE Linux 12.2 (i586)-Packman (C) 
2000-2012 MPlayer Team

Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote 
control.


Playing /data/Filme/Serenity - HD DVD Trailer.mp4.
libavformat version 54.25.104 (internal)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8aba6e0]max_analyze_duration 500 
reached at 5005000

[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
[lavf] stream 2: video (mjpeg), -vid 1
VIDEO:  [H264]  1280x720  24bpp  23.976 fps  4674.1 kbps (570.6 
kbyte/s)

Clip info:
 major_brand: isom
 minor_version: 1
 compatible_brands: isomavc1
 creation_time: 1937-04-23 22:52:15
 genre: Trailer
 artist: Universal Pictures
 title: Serenity - HD DVD Trailer
 date: 2005
Load subtitles in /data/Filme/
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 54.54.100 (internal)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==
==
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 127.5 kbit/8.30% (ratio: 15942->192000)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 
Audio))

==
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
Movie-Aspect is undefined - no prescaling applied.
VO: [vdpau] 1280x720 => 1280x720 Planar YV12
A:   3.5 V:   2.6 A-V:  0.903 ct:  0.018   0/  0 56% 72%  0.6% 50 0


   
    Your system is too SLOW to play this!  
   

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
  - Try -ao sdl or use the OSS emulation of ALSA.
  - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
  - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
  - Don't try to play a big DVD/DivX on a slow CPU! Try some of the 
lavdopts,

e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
  - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
  - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
  - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.

A:   9.6 V:   7.1 A-V:  2.434 ct:  0.011   0/  0 58% 69%  1.0% 156 0

Exiting... (Quit)



The adobe flash vdpau implementation
reverses the channels.  IIRC, newer versions of libvdpau have a
workaround for it.


I know, but I can't use this crappy stupid software since summer 2012, 
'cause they do NOT offer any current linux player (even with their 
hardware acceleration) without SSE2...


...Duron/AthlonMP => AMD could you help, PLEASE?!

In the meantime I use an older libflash taken from Chrome without 
hardware acceleration, too. But it is compiled without SSE2. 

Re: UVD status on loongson 3a platform

[Dieter Nützel]

Am 2013-04-19 17:34, schrieb Christian König:

Am 19.04.2013 10:51, schrieb Chen Jie:
Hi all,

Recently, the uvd supporting is released, and we've tried it on
loongson 3a platform.
Brief introduction about loongson 3a, it's a MIPS III compatible, 4
cores processor.

More details about the platform [1]:
* The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video 
card

* The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
* OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
** kernel: 3.9 + uvd related patches
** mesa: git master version (d0e9aa)

We tried three video samples:
* big_buck_bunny_1080p_h264.mov
(http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
* Sintel.2010.2K.x264-VODO.mp4
(http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
* test.avi 
(http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)


For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
the beginning, and it has some video mosaic. We've recorded a video
for it, see 
http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4

For video mosaic, what could it be caused by?

That looks like a known problem with the semaphores and also happens
on X86, it gets worse when you have a slower CPU and/or less bandwidth
cause then UVD needs to block on the DMA to wait till everything is in
place. I'm going to try to release the workaround for it.


With '...when you have a slower CPU and/or less bandwidth...' you 
naturally mean my Duron 1800/RV730 AGP (!!!) system, am I right? ;-)


Yes, that's the problem I get since the 'shadow' is fixed.
I can get it much faster when I go forward or backward in mplayer.

Do you have anything released?

For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first 
frame.

We've also recorded a video for it, see
http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
Any idea about the long wait for the first frame?

No idea, that also happens on X86, but the wait is actually not as
long. If I'm not completely wrong it seems to be mplayer who is
causing this startup delay.


I mostly don't see such delay, here.
But hey, I get this with test.avi, now:

[VD_FFMPEG] Trying pixfmt=0.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 H.264 VDPAU acceleration
[VD_FFMPEG] XVMC-accelerated MPEG-2.
radeon: The kernel rejected CS, see dmesg for more information.105 0
radeon: The kernel rejected CS, see dmesg for more information.107 0

[ 8362.657224] [drm:radeon_uvd_cs_msg] *ERROR* Invalid UVD handle!
[ 8362.657236] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8362.693846] [drm:radeon_uvd_cs_msg] *ERROR* Invalid UVD handle!
[ 8362.693859] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8362.726656] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!

[ 8362.726668] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8427.206169] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!

[ 8427.206179] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8428.296537] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!

[ 8428.296548] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !


For test.avi(video: ITU H.264, 1920x1080), it's playing back
perfectly! Thanks for the effort on UVD!


Perfectly, with such mosaic, after some few seconds?
And your test.avi is not seekable.

A:   7.7 V:   7.7 A-V:  0.002 ct: -0.074 231/231 49% 108%  3.5% 131 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)

A:   8.7 V:   8.5 A-V:  0.198 ct: -0.076 254/254 45% 104%  3.3% 132 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)

A:   9.6 V:   9.1 A-V:  0.495 ct: -0.063 272/272 42% 107%  3.8% 139 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)

A:  10.7 V:  10.6 A-V:  0.076 ct: -0.068 319/319 36% 100%  3.4% 178 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)

A:  36.4 V:  36.4 A-V: -0.004 ct: -0.081 1092/1092 12% 32%  1.6% 182 0

Cheers,
Dieter

PS Alex's drm-next-3.10, mesa master, drm-2.4.44 master
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UVD status on loongson 3a platform

[Dieter Nützel]

Am 2013-04-19 10:51, schrieb Chen Jie:

Hi all,

Recently, the uvd supporting is released, and we've tried it on
loongson 3a platform.
Brief introduction about loongson 3a, it's a MIPS III compatible, 4
cores processor.

More details about the platform [1]:
* The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video 
card

* The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
* OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
** kernel: 3.9 + uvd related patches
** mesa: git master version (d0e9aa)


Are you guys interested in OpenCL (on your platform)?
OpenCV (one of the basis for digikam for example) has some support for 
Nvidia and now AMD. It is under development by Institute Of Software 
Chinese Academy Of Science.

AFDS 2012
http://www.youtube.com/watch?v=LhIuSShTO0g

Even the next big Gimp version (2.10) should be accelerated by OpenCL 
through GEGL.


Wouldn't it be cool to have OSS OpenCL even for 'smaller' sized gfx 
cards from AMD?
You are a hardware shop so maybe your demand is it AMD worth to have 
something around?


Regards,
Dieter

PS Here comes something about Nvidia's other collaboration...
http://www.h-online.com/open/features/Kernel-comment-Bad-show-NVIDIA-1845899.html



[1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
[2] http://dev.lemote.com/653.html (zh_CN)
[3] http://dev.lemote.com/663.html (zh_CN)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm_edid_to_sad: (drm-next-3.10) compiler warnings

[Dieter Nützel]

CC [M]  drivers/gpu/drm/drm_edid.o
drivers/gpu/drm/drm_edid.c: In Funktion »drm_edid_to_sad«:
drivers/gpu/drm/drm_edid.c:2550:4: Warnung: ISO-C90 verbietet gemischte 
Deklarationen und Code [-Wdeclaration-after-statement]


Regards,
Dieter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: fix scratch reg handling for UVD fence

[Dieter Nützel]

Am 2013-04-24 14:12, schrieb Christian König:

From: Christian König 

Also init the scratch reg to zero on the UVD ring.
This fixes UVD on AGP based cards.

Signed-off-by: Christian König 


Tested-by: Dieter Nützel 

RV730 AGP (UVD 2.2) works with radeon.agpmode=8, now.

[   10.394741] ATOM BIOS: 113
[   10.394948] [drm] AGP mode requested: 8
[   10.394960] agpgart-via :00:00.0: AGP 3.5 bridge
[   10.394989] agpgart-via :00:00.0: putting AGP V3 device into 8x 
mode

[   10.396634] radeon :01:00.0: putting AGP V3 device into 8x mode
[   10.396649] radeon :01:00.0: GTT: 256M 0xE000 - 0xEFFF
[   10.396661] radeon :01:00.0: VRAM: 1024M 0xA000 - 0xDFFF 
(1024M used)

[   10.399244] [drm] Detected VRAM RAM=1024M, BAR=256M
[   10.399254] [drm] RAM width 128bits DDR
[   10.402125] [TTM] Zone  kernel: Available graphics memory: 441924 kiB
[   10.402133] [TTM] Zone highmem: Available graphics memory: 1033768 
kiB

[   10.402136] [TTM] Initializing pool allocator
[   10.402198] [drm] radeon: 1024M of VRAM memory ready
[   10.402202] [drm] radeon: 256M of GTT memory ready.
[   10.402244] [drm] Supports vblank timestamp caching Rev 1 
(10.10.2010).

[   10.402247] [drm] Driver supports precise vblank timestamp query.
[   10.402319] [drm] radeon: irq initialized.

[-]

[   10.524045] [drm] GART: num cpu pages 65536, num gpu pages 65536
[   10.528182] [drm] Loading RV730 Microcode
[   10.641945] radeon :01:00.0: WB disabled
[   10.641964] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0xe004 and cpu a

ddr 0xf84c0004
[   10.641969] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0xec0c and cpu addr 0xf84c0c0c
[   10.642218] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0xa005c598 and cpu addr 0xf879c598

[   10.785565] [drm] ring test on 0 succeeded in 1 usecs
[   10.785636] [drm] ring test on 3 succeeded in 1 usecs
[   10.842237]  md127:
[   10.847965] [drm] ring test on 5 succeeded in 1 usecs
[   10.847976] [drm] UVD initialized successfully.
[   10.848690] [drm] ib test on ring 0 succeeded in 0 usecs
[   10.848729] [drm] ib test on ring 3 succeeded in 1 usecs
[   10.858255] [drm] ib test on ring 5 succeeded

Thank you Christian!

Dieter


---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 1a699ce..5b937df 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -767,8 +767,8 @@ int radeon_fence_driver_start_ring(struct
radeon_device *rdev, int ring)

radeon_scratch_free(rdev, rdev->fence_drv[ring].scratch_reg);
if (rdev->wb.use_event || !radeon_ring_supports_scratch_reg(rdev,
&rdev->ring[ring])) {
+   rdev->fence_drv[ring].scratch_reg = 0;
if (ring != R600_RING_TYPE_UVD_INDEX) {
-   rdev->fence_drv[ring].scratch_reg = 0;
index = R600_WB_EVENT_OFFSET + ring * 4;
rdev->fence_drv[ring].cpu_addr = &rdev->wb.wb[index/4];
rdev->fence_drv[ring].gpu_addr = rdev->wb.gpu_addr +

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: allocate SA bo in the requested domain

[Dieter Nützel]

Am 2013-04-25 18:19, schrieb Christian König:

From: Christian König 

This avoid moving the BO directly after allocating it.

Signed-off-by: Christian König 


Tested-by: Dieter Nützel 

Regards,
Dieter


---
drivers/gpu/drm/radeon/radeon_sa.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index cb80099..0abe5a9 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -64,7 +64,7 @@ int radeon_sa_bo_manager_init(struct radeon_device 
*rdev,

}

r = radeon_bo_create(rdev, size, RADEON_GPU_PAGE_SIZE, true,
-RADEON_GEM_DOMAIN_CPU, NULL, &sa_manager->bo);
+domain, NULL, &sa_manager->bo);
if (r) {
dev_err(rdev->dev, "(%d) failed to allocate bo for manager\n", 
r);
return r;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space

[Dieter Nützel]

Am 02.10.2013 21:20, schrieb John Hupp:

On 9/30/2013 7:36 AM, Daniel Vetter wrote:

On Sat, Sep 28, 2013 at 12:49:24PM -0400, John Hupp wrote:

[I emailed the list with this same material on 9/13, but it has
received no response and someone on the Ubuntu kernel team suggested
that I change the email Subject from "Re: Moving a bug upstream per
downstream request, emailing the maintainers" to the more
descriptive one above.]

When I emailed the maintainers with the report below on 8/15 (and
archived at 
http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html),

a response came on 8/16:

"It's a flash bug. They ignore the format of the Window that they
PutImage to. (Worse, they create an image of the right depth or else 
X

would reject the PutImage with a BadMatch and then render incorrect
pixel data into it.)"

Despite that, someone on the Ubuntu kernel team asserted "at a
minimum a non-flash regression exists going from Quantal to Raring,"
and urged me to proceed with upstream kernel bisection.

I finally finished that, and arrived at the result:
Still a flash bug. This commit simply enables rgb555 in the kernel, 
which
sna likes to use on gen2/3. Flash is just too dense and always 
presumes

xrgb. Adding

Section "Screen"
 Identifier "igd"
 DefaultDepth 24
EndSection

to your xorg.conf will work around.
-Daniel


*Thanks!  That successfully works around the Flash problem with the
Intel driver/chipsets that I reported on.  We have at least 4 of those
machines here.*


Hello John,

which 'special' Flash version are you running?
I see that you have an Celeron so YOU can use the SSE2 enabled version, 
which I can't 'cause a have old Athlon/Duron without SSE2.


Do you have to fiddle with

/etc/vdpau_wrapper.cfg
enable_flash_uv_swap=1
disable_flash_pq_bg_color=1
?

I can't get around the green and purple colors, but NO line distortion 
on my RV730 AGP, here.


Any hints, Christian?

Thank you for your insistence, John!

-Dieter



57779d06367a915ee03e6cb918d7575f0a46e419 is the first bad commit
commit 57779d06367a915ee03e6cb918d7575f0a46e419
Author: Ville Syrjälä 
Date: Wed Oct 31 17:50:14 2012 +0200

 drm/i915: Fix display pixel format handling

 Fix support for all RGB/BGR pixel formats (except the
16:16:16:16 float
 format).

 Fix intel_init_framebuffer() to match hardware and driver 
limitations:

 * RGB332 is not supported at all
 * CI8 is supported
 * XRGB1555 & co. are supported on Gen3 and earlier
 * XRGB210101010 & co. are supported from Gen4 onwards
 * BGR formats are supported from Gen4 onwards
 * YUV formats are supported from Gen5 onwards (driver 
limitation)


 Signed-off-by: Ville Syrjälä 
 Reviewed-by: Jesse Barnes 
 Signed-off-by: Daniel Vetter 

:04 04 334e1536b3513d0c329a8bb6360593d12065b71d
bf0996ec13cbee07156c5e9f98dcdee30200e658 M drivers

-

The git bisect log:

git bisect start
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3
git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20
# good: [db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070] Merge tag 'dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070
# bad: [3c2e81ef344a90bb0a39d84af6878b4aeff568a2] Merge branch
'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect bad 3c2e81ef344a90bb0a39d84af6878b4aeff568a2
# good: [d8c532c40721f7507896d202b8cae3b3642d2b0d] Merge branch
'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good d8c532c40721f7507896d202b8cae3b3642d2b0d
# good: [2a74dbb9a86e8102dcd07d284135b4530a84826e] Merge branch
'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
git bisect good 2a74dbb9a86e8102dcd07d284135b4530a84826e
# bad: [124ea297c8f0e0a3a567af0894fdbe05caaf80ec] drm/nouveau: unpin
pushbuffer bo before destroying it
git bisect bad 124ea297c8f0e0a3a567af0894fdbe05caaf80ec
# bad: [12f3382bc0262e981a2e58aca900cbbdbbe66825] drm/i915:
implement WaDisablePSDDualDispatchEnable on IVB & VLV
git bisect bad 12f3382bc0262e981a2e58aca900cbbdbbe66825
# good: [20474e90c948545c51da95689b8342a4f3bbaeb6] drm/i915: fix
checks inside ironlake_crtc_{enable, disable}
git bisect good 20474e90c948545c51da95689b8342a4f3bbaeb6
# good: [00c09d70df6b30c980f20facc1db3def3f5a637e] drm/i915: create
the DDI encoder
git bisect good 00c09d70df6b30c980f20facc1db3def3f5a637e
# bad: [a35f267946947b3798827a783d82d3d2aa55697d] drm/i915: remove
IBX code from lpt_enable_pch_transcoder
git bisect bad a35f267946947b3798827a783d82d3d2aa55697d
# bad: [9256aa195d3badd009bf4addee6c3ae39879b8a6] drm/i915: move
encoder->mode_set calls to crtc_mode_set
git bisect bad 9256aa195d3badd009bf4addee6c3ae39879b8a6
# good: [e7210c3c4f0d05e318b854bbd545f

Re: [TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)

[Dieter Nützel]

Am 07.10.2013 11:22, schrieb Christian König:

Am 07.10.2013 10:58, schrieb Rafał Miłecki:

2013/10/7 Christian König :

Why didn't you just asked me?

I was told on #radeon you're on holidays ;) I was trying to catch you.


I'm on vacation right now, but got back yesterday and now greping
though my accumulated mails ;)



I've figured this out over five years ago by applying brute force to 
one of
the "magic" DVI->HDMI adapters that came with my original RV635. And 
it

indeed contains an extra EEPROM on the I2C bus ;)

Did you find any way to workaround this? So I can use my generic
adapter with fglrx for audio?


Not that I know of any, well those adapters where only used on the
early RV6xx HDMI days. IIRC my later RV7xx worked well with the
10meters DVI->HDMI cable fglrx on RV6xx failed.


Hello to both of you!

Christian, is there any change to get HDMI audio out of my 2 x Dual-Link 
DVI RV730 AGP ports with one of those adapters (were can I get one) or 
is the poor little one which came with the gfx card (SAPPHIRE HD 4650 
1GB DDR2 AGP) enough?


Thanks,
   Dieter

PS Rafał, with the right solution I can maybe help you with your 
investigation ;-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/radeon: rework and fix reset detection v2

[Dieter Nützel]

Am 14.10.2013 11:32, schrieb Christian König:

From: Christian König 

Stop fiddling with jiffies, always wait for 
RADEON_FENCE_JIFFIES_TIMEOUT.
Consolidate the two wait sequence implementations into just one 
function.
Activate all waiters and remember if the reset was already done instead 
of

trying to reset from only one thread.

v2: clear reset flag earlier to avoid timeout in IB test


Hello Christian,

even for radeon_fence.c  Dan Carpenter had a question/patch on October, 
6

[patch] drm/radeon: tweak a timeout condition slightly
and nobody replied.

Greetings,
  Dieter



Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h|   2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   8 +
 drivers/gpu/drm/radeon/radeon_fence.c  | 347 
+++--

 3 files changed, 127 insertions(+), 230 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h 
b/drivers/gpu/drm/radeon/radeon.h

index a400ac1..0201c6e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -327,7 +327,6 @@ struct radeon_fence_driver {
/* sync_seq is protected by ring emission lock */
uint64_tsync_seq[RADEON_NUM_RINGS];
atomic64_t  last_seq;
-   unsigned long   last_activity;
boolinitialized;
 };

@@ -2170,6 +2169,7 @@ struct radeon_device {
boolneed_dma32;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
+   boolneeds_reset;
struct radeon_surface_reg surface_regs[RADEON_GEM_MAX_SURFACES];
const struct firmware *me_fw;   /* all family ME firmware */
const struct firmware *pfp_fw;  /* r6/700 PFP firmware */
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 841d0e0..3f35f21 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1549,6 +1549,14 @@ int radeon_gpu_reset(struct radeon_device *rdev)
int resched;

down_write(&rdev->exclusive_lock);
+
+   if (!rdev->needs_reset) {
+   up_write(&rdev->exclusive_lock);
+   return 0;
+   }
+
+   rdev->needs_reset = false;
+
radeon_save_bios_scratch_regs(rdev);
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index ddb8f8e..b8f68b2 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -190,10 +190,8 @@ void radeon_fence_process(struct radeon_device
*rdev, int ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);

-   if (wake) {
-   rdev->fence_drv[ring].last_activity = jiffies;
+   if (wake)
wake_up_all(&rdev->fence_queue);
-   }
 }

 /**
@@ -212,13 +210,13 @@ static void radeon_fence_destroy(struct kref 
*kref)

 }

 /**
- * radeon_fence_seq_signaled - check if a fence sequeuce number has 
signaled
+ * radeon_fence_seq_signaled - check if a fence sequence number has 
signaled

  *
  * @rdev: radeon device pointer
  * @seq: sequence number
  * @ring: ring index the fence is associated with
  *
- * Check if the last singled fence sequnce number is >= the requested
+ * Check if the last signaled fence sequnce number is >= the requested
  * sequence number (all asics).
  * Returns true if the fence has signaled (current fence value
  * is >= requested value) or false if it has not (current fence
@@ -263,113 +261,131 @@ bool radeon_fence_signaled(struct radeon_fence 
*fence)

 }

 /**
- * radeon_fence_wait_seq - wait for a specific sequence number
+ * radeon_fence_any_seq_signaled - check if any sequence number is 
signaled

  *
  * @rdev: radeon device pointer
- * @target_seq: sequence number we want to wait for
- * @ring: ring index the fence is associated with
+ * @seq: sequence numbers
+ *
+ * Check if the last signaled fence sequnce number is >= the requested
+ * sequence number (all asics).
+ * Returns true if any has signaled (current value is >= requested 
value)

+ * or false if it has not. Helper function for radeon_fence_wait_seq.
+ */
+static bool radeon_fence_any_seq_signaled(struct radeon_device *rdev, 
u64 *seq)

+{
+   unsigned i;
+
+   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   if (seq[i] && radeon_fence_seq_signaled(rdev, seq[i], i))
+   return true;
+   }
+   return false;
+}
+
+/**
+ * radeon_fence_wait_seq - wait for a specific sequence numbers
+ *
+ * @rdev: radeon device pointer
+ * @target_seq: sequence number(s) we want to wait for
  * @intr: use interruptable sleep
  * @lock_ring: whether the ring should be locked or not
  *
- * Wait for the requested se

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Dieter Nützel]

Am 30.06.2014 14:31, schrieb Christian K?nig:
> Am 30.06.2014 11:34, schrieb Michel D?nzer:
>> On 27.06.2014 19:47, Christian K?nig wrote:
>>> Am 27.06.2014 11:44, schrieb Michel D?nzer:
 On 27.06.2014 17:18, Christian K?nig wrote:
> Am 27.06.2014 04:58, schrieb Michel D?nzer:
>> On 26.06.2014 19:39, Christian K?nig wrote:
>>> Am 26.06.2014 11:29, schrieb Michel D?nzer:
 From: Michel D?nzer 
 
 Prevents radeon_crtc_handle_flip() from running before
 radeon_flip_work_func(), resulting in a kernel panic due to
 the BUG_ON() in drm_vblank_put().
 
 Tested-by: Dieter N?tzel  Signed-off-by:
 Michel D?nzer 
>>> Does patch #2 alone fixes the problem as well?
>> It should avoid the panic as well.
>> I've sent a v2 of that patch with an updated commit log. Alex, please 
>> get
>> that into 3.16 ASAP to prevent people from running into the panic.

Compiling...

>>> I would rather want to avoid turning the pflip interrupt on and
>>> off.
>> What's the problem with that? It's not like we're saving any
>> register writes by not doing it.
> We don't? As far as I can see we reprogram all interrupt registers
> if any of the interrupts changed,
 Maybe I'm missing something, but: radeon_irq_kms_pflip_irq_get/put()
 call radeon_irq_set() every time, as there can only be one active 
 page
 flip per CRTC. And radeon_irq_set() always writes the same 
 registers,
 only the bits it writes to them change depending on which interrupts 
 the
 driver is currently interested in.
>>> We first turn on the vblank interrupt which results in a
>>> radeon_irq_set() and then turn on the pflip, which results in another
>>> radeon_irq_set() .
>> The DRM core delays disabling the hardware vblank interrupt, so
>> radeon_irq_set() should only be called once for that.
>> 
>> radeon_irq_kms_pflip_irq_get/put() always call radeon_irq_set() even 
>> before
>> my changes.
>> 
>> 
>> Anyway, for the issues surrounding the pflip interrupt, I took a step 
>> back
>> and considered a fundamentally different approach: It occurred to me 
>> that a
>> lot of the issues we've been struggling with are related to 
>> programming the
>> flips to the hardware such that they execute during the vertical blank
>> period. We don't know exactly when the hardware update happens or when 
>> would
>> be a good time to program the flip. So why bother with that at all?
> I've considered this as well, but at this time still hoped that we
> could completely replace the vblank interrupt with the pflip
> interrupt.
> 
>> The patch below (only fleshed out for CIK) moves the programming of 
>> the
>> flip to the hardware back to the vertical blank interrupt handler, but
>> changes it to execute during the horizontal blank period. In addition 
>> to
>> allowing the pflip interrupt handling, radeon_crtc_handle_vblank() and
>> radeon_flip_pending() to be removed, this should make adding support 
>> for
>> asynchronous flips trivial and support for replacing pending flips 
>> much
>> easier. What do you think?
> It also allows us to stop fiddling with the update pending bit as
> well, e.g. no more busy waiting for it to become high in
> evergreen_page_flip.
> 
> And as far as I can see it still support all not so trivial use cases
> like switching to hblank if rendering isn't completed before a certain
> timeout and dynamic refresh etc...
> 
> Yeah, sounds like a really good idea to me.
> 
>>> The delay between vblank start and the flip being executed seemed to 
>>> be
>>> depending on the pixel clock (which makes sense because the CRTC is
>>> driven by it), so when it might work ok for a 50Hz mode we can still 
>>> run
>>> into problems with 24Hz modes.
>> I couldn't see any tearing with this patch at 640x480 at 60 Hz and 
>> reduced
>> blanking, which should have a lower pixel clock and shorter vertical 
>> blank
>> period than 1920x1080 at 24 Hz?
> 
> In theory that should do the trick as well. But let's just make
> patches for it and then we can make a request to the people who
> originally reported the problem to test the whole implementation.
> 
> That should give us enough confidence that it will work correctly,
> Christian.

So please flesh something out (for r600 at least) and let me try ;-)

BTW Have someone looked at this (dpm typos):
Bug 79071 - Hang with dpm radeon hd 5750, pcie 1.1 motherboard
https://bugzilla.kernel.org/show_bug.cgi?id=79071

UVD fails to init on rv790

[Dieter Nützel]

Am 2013-04-03 15:21, schrieb Alex Deucher:
> On Wed, Apr 3, 2013 at 7:29 AM, Christian K?nig 
>  wrote:
>> Hi Andy,
>> 
>> crap! I feared that something like this would happen. IIRC we never 
>> tested
>> UVD on an rv790, and this hardware isn't easy to get any more.
>> 
>> RV770/RV790 have a separate UVD hardware generation (that's why they 
>> have
>> their own firmware) and there possible is some bug or something like 
>> this
>> that we haven't implemented. You couldn't give me SSH access to that 
>> system?
> 
> I tested on an RV770 earlier in development and it was working ok at
> the time I think.  I'll give it another try today.
> 
> Alex


Hello Alex,

time goes by so fast --- wife, home, 2 children...

but what do I need:
I'll test it on my 2 HD4650/RV730 AGP (!) low speed Duron and dual 
Athlon MP.

git:// drm-fixes kernel
git:// mesa
patches

R700_rlc.bin
RV710_uvd.bin

BTW Any hints for libvdpau_r600.so.1.0.0?
I get wrong colors (red is like blue, blue is like yellow, etc.)

Thank you very much for all your GREAT work!
UVD - What a big day!

Regards,
   Dieter

--
The Voodoo5 5000 Dieter...-)
Anyone want's it? - I have the original package etc.

UVD fails to init on rv790

[Dieter Nützel]

Am 2013-04-03 23:06, schrieb Alex Deucher:
> On Wed, Apr 3, 2013 at 4:45 PM, Dieter N?tzel  
> wrote:
>> Am 2013-04-03 15:21, schrieb Alex Deucher:
>> 
>>> On Wed, Apr 3, 2013 at 7:29 AM, Christian K?nig 
>>> 
>>> wrote:
 
 Hi Andy,
 
 crap! I feared that something like this would happen. IIRC we never
 tested
 UVD on an rv790, and this hardware isn't easy to get any more.
 
 RV770/RV790 have a separate UVD hardware generation (that's why 
 they have
 their own firmware) and there possible is some bug or something 
 like this
 that we haven't implemented. You couldn't give me SSH access to 
 that
 system?
>>> 
>>> 
>>> I tested on an RV770 earlier in development and it was working ok at
>>> the time I think.  I'll give it another try today.
>>> 
>>> Alex
>> 
>> 
>> 
>> Hello Alex,
>> 
>> time goes by so fast --- wife, home, 2 children...
>> 
>> but what do I need:
>> I'll test it on my 2 HD4650/RV730 AGP (!) low speed Duron and dual 
>> Athlon
>> MP.
>> 
>> git:// drm-fixes kernel
>> git:// mesa
>> patches
>> 
>> R700_rlc.bin
>> RV710_uvd.bin
>> 
>> BTW Any hints for libvdpau_r600.so.1.0.0?
>> I get wrong colors (red is like blue, blue is like yellow, etc.)
>> 
> 
> What are you testing with?

Only mplayer (defaults to vdpau, really?) of course without UVD, 
currently.
Works much better on the slow children's Duron. I have ~10% idle left 
on our Duron 1800. Without vdpau lib together with HD4650 unplayable on 
this system.

/home/dieter> mplayer /data/Filme/Serenity\ -\ HD\ DVD\ Trailer.mp4
MPlayer dev-SVN-r35127-4.7-openSUSE Linux 12.2 (i586)-Packman (C) 
2000-2012 MPlayer Team
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote 
control.

Playing /data/Filme/Serenity - HD DVD Trailer.mp4.
libavformat version 54.25.104 (internal)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8aba6e0]max_analyze_duration 500 
reached at 5005000
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
[lavf] stream 2: video (mjpeg), -vid 1
VIDEO:  [H264]  1280x720  24bpp  23.976 fps  4674.1 kbps (570.6 
kbyte/s)
Clip info:
  major_brand: isom
  minor_version: 1
  compatible_brands: isomavc1
  creation_time: 1937-04-23 22:52:15
  genre: Trailer
  artist: Universal Pictures
  title: Serenity - HD DVD Trailer
  date: 2005
Load subtitles in /data/Filme/
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 54.54.100 (internal)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==
==
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 127.5 kbit/8.30% (ratio: 15942->192000)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 
Audio))
==
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
Movie-Aspect is undefined - no prescaling applied.
VO: [vdpau] 1280x720 => 1280x720 Planar YV12
A:   3.5 V:   2.6 A-V:  0.903 ct:  0.018   0/  0 56% 72%  0.6% 50 0



 Your system is too SLOW to play this!  


Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
   - Try -ao sdl or use the OSS emulation of ALSA.
   - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
   - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
   - Don't try to play a big DVD/DivX on a slow CPU! Try some of the 
lavdopts,
 e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
   - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
   - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
   - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.

A:   9.6 V:   7.1 A-V:  2.434 ct:  0.011   0/  0 58% 69%  1.0% 156 0

Exiting... (Quit)


> The adobe flash vdpau implementation
> reverses the channels.  IIRC, newer versions of libvdpau have a
> workaround for it.

I know, but I can't use this crappy stupid software since summer 2012, 
'cause they do NOT offer any current linux player (even with their 
hardware acceleration) without SSE2...

...Duron/AthlonMP => AMD could you help, PLEASE?!

In the meantime

[PATCH 00/11] basic UVD support v3

[Dieter Nützel]

Am 2013-04-08 16:50, schrieb Christian K?nig:
> Am 08.04.2013 16:37, schrieb Dieter N?tzel:
>> Am 2013-04-08 12:41, schrieb Christian K?nig:
>>> Hello everyone,
>>> 
>>> Third round of this patchset, and only some stupid typos fixed. I've
>>> uploaded this patchset as branch uvd-3.9 to
>>> git://people.freedesktop.org/~deathsimple/linux.
>> 
>> Hello Christian,
>> 
>> I did last night a
>> git clone -b uvd-3.9 git://people.freedesktop.org/~deathsimple/linux
>> to get v2 (1,35 GB) but when I try to get an update (v3) with
>> git pull git://people.freedesktop.org/~deathsimple/linux
>> I get merge trouble.
>> 
>> What is the right way to get the code?
>> 
> 
> That branch is a complete new version of the patchset, not only new
> additional patches.
> 
> Try:
> 
> git fetch origin
> git reset --hard origin/uvd-3.9
> 
> instead of pull.

Ok, your 3.9.0-rc2 compiled 1 and a half hour on the slow Duron 1800...

Mesa git is:
04ffce3004faa50f33a740ea36aa4abdc03f652f

plus your Mesa patches:
[Mesa-dev] [PATCH] radeon/uvd: add UVD implementation v4

got rejections in three Makefile's
so applied them by hand

copied latest firmware (taken form your tree)
R700_rlc.bin and
RV710_uvd.bin

into
/lib/firmware/radeon/

booted 3.9.0-rc2-1-desktop+

GRUB2 started OK
KMS in 1920x1080 OK
plymouth (openSUSE animated) OK

NO animated X cursor (kdm should come up)
X do not start correctly
(see Xorg.0.log.old-BAD-UVD.bz2 vs Xorg.0.log.old.bz2)

Am I missing something in my 'new' kernel configuration?
I used openSUSE .config as basis.

But I got something in the logs (console):

Apr  9 06:01:42 Sonja kernel: [60589.312254] [drm:radeon_cs_get_ring] 
*ERROR* unknown ring id: 3
Apr  9 06:01:42 Sonja kernel: [60589.312264] [drm:radeon_cs_ioctl] 
*ERROR* Failed to initialize parser !
[-]

more in messages-BAD-UVD.bz2

second boot I got some more info (messages-BAD-UVD.bz2, again):

[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 1 usecs
radeon :01:00.0: GPU lockup CP stall for more than 1msec
radeon :01:00.0: GPU lockup (waiting for 0x0002 last 
fence id 0x)
[drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35).
[drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 
(-35).

What next?

Dieter.

> Christian.
> 
>> Thanks,
>>   Dieter
>> 
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log.old-BAD-UVD.bz2
Type: application/x-bzip2
Size: 4519 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log.old.bz2
Type: application/x-bzip2
Size: 8966 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: messages-BAD-UVD.bz2
Type: application/x-bzip2
Size: 67465 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: lspci.log.bz2
Type: application/x-bzip2
Size: 2473 bytes
Desc: not available
URL: 

UVD status on loongson 3a platform

[Dieter Nützel]

Am 2013-04-19 17:34, schrieb Christian K?nig:
> Am 19.04.2013 10:51, schrieb Chen Jie:
> Hi all,
> 
> Recently, the uvd supporting is released, and we've tried it on
> loongson 3a platform.
> Brief introduction about loongson 3a, it's a MIPS III compatible, 4
> cores processor.
> 
> More details about the platform [1]:
> * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video 
> card
> * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
> * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
> ** kernel: 3.9 + uvd related patches
> ** mesa: git master version (d0e9aa)
> 
> We tried three video samples:
> * big_buck_bunny_1080p_h264.mov
> (http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
> * Sintel.2010.2K.x264-VODO.mp4
> (http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
> * test.avi 
> (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)
> 
> For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
> the beginning, and it has some video mosaic. We've recorded a video
> for it, see 
> http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
> For video mosaic, what could it be caused by?
> 
> That looks like a known problem with the semaphores and also happens
> on X86, it gets worse when you have a slower CPU and/or less bandwidth
> cause then UVD needs to block on the DMA to wait till everything is in
> place. I'm going to try to release the workaround for it.

With '...when you have a slower CPU and/or less bandwidth...' you 
naturally mean my Duron 1800/RV730 AGP (!!!) system, am I right? ;-)

Yes, that's the problem I get since the 'shadow' is fixed.
I can get it much faster when I go forward or backward in mplayer.

Do you have anything released?

> For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first 
> frame.
> We've also recorded a video for it, see
> http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
> Any idea about the long wait for the first frame?
> 
> No idea, that also happens on X86, but the wait is actually not as
> long. If I'm not completely wrong it seems to be mplayer who is
> causing this startup delay.

I mostly don't see such delay, here.
But hey, I get this with test.avi, now:

[VD_FFMPEG] Trying pixfmt=0.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 H.264 VDPAU acceleration
[VD_FFMPEG] XVMC-accelerated MPEG-2.
radeon: The kernel rejected CS, see dmesg for more information.105 0
radeon: The kernel rejected CS, see dmesg for more information.107 0

[ 8362.657224] [drm:radeon_uvd_cs_msg] *ERROR* Invalid UVD handle!
[ 8362.657236] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8362.693846] [drm:radeon_uvd_cs_msg] *ERROR* Invalid UVD handle!
[ 8362.693859] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8362.726656] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!
[ 8362.726668] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8427.206169] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!
[ 8427.206179] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8428.296537] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!
[ 8428.296548] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

> For test.avi(video: ITU H.264, 1920x1080), it's playing back
> perfectly! Thanks for the effort on UVD!

Perfectly, with such mosaic, after some few seconds?
And your test.avi is not seekable.

A:   7.7 V:   7.7 A-V:  0.002 ct: -0.074 231/231 49% 108%  3.5% 131 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:   8.7 V:   8.5 A-V:  0.198 ct: -0.076 254/254 45% 104%  3.3% 132 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:   9.6 V:   9.1 A-V:  0.495 ct: -0.063 272/272 42% 107%  3.8% 139 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:  10.7 V:  10.6 A-V:  0.076 ct: -0.068 319/319 36% 100%  3.4% 178 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:  36.4 V:  36.4 A-V: -0.004 ct: -0.081 1092/1092 12% 32%  1.6% 182 0

Cheers,
Dieter

PS Alex's drm-next-3.10, mesa master, drm-2.4.44 master

UVD status on loongson 3a platform

[Dieter Nützel]

Am 2013-04-19 10:51, schrieb Chen Jie:
> Hi all,
> 
> Recently, the uvd supporting is released, and we've tried it on
> loongson 3a platform.
> Brief introduction about loongson 3a, it's a MIPS III compatible, 4
> cores processor.
> 
> More details about the platform [1]:
> * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video 
> card
> * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
> * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
> ** kernel: 3.9 + uvd related patches
> ** mesa: git master version (d0e9aa)

Are you guys interested in OpenCL (on your platform)?
OpenCV (one of the basis for digikam for example) has some support for 
Nvidia and now AMD. It is under development by Institute Of Software 
Chinese Academy Of Science.
AFDS 2012
http://www.youtube.com/watch?v=LhIuSShTO0g

Even the next big Gimp version (2.10) should be accelerated by OpenCL 
through GEGL.

Wouldn't it be cool to have OSS OpenCL even for 'smaller' sized gfx 
cards from AMD?
You are a hardware shop so maybe your demand is it AMD worth to have 
something around?

Regards,
Dieter

PS Here comes something about Nvidia's other collaboration...
http://www.h-online.com/open/features/Kernel-comment-Bad-show-NVIDIA-1845899.html

> 
> [1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
> [2] http://dev.lemote.com/653.html (zh_CN)
> [3] http://dev.lemote.com/663.html (zh_CN)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm_edid_to_sad: (drm-next-3.10) compiler warnings

[Dieter Nützel]

CC [M]  drivers/gpu/drm/drm_edid.o
drivers/gpu/drm/drm_edid.c: In Funktion ?drm_edid_to_sad?:
drivers/gpu/drm/drm_edid.c:2550:4: Warnung: ISO-C90 verbietet gemischte 
Deklarationen und Code [-Wdeclaration-after-statement]

Regards,
Dieter

[PATCH] drm/radeon: fix scratch reg handling for UVD fence

[Dieter Nützel]

Am 2013-04-24 14:12, schrieb Christian K?nig:
> From: Christian K?nig 
> 
> Also init the scratch reg to zero on the UVD ring.
> This fixes UVD on AGP based cards.
> 
> Signed-off-by: Christian K?nig 

Tested-by: Dieter N?tzel 

RV730 AGP (UVD 2.2) works with radeon.agpmode=8, now.

[   10.394741] ATOM BIOS: 113
[   10.394948] [drm] AGP mode requested: 8
[   10.394960] agpgart-via :00:00.0: AGP 3.5 bridge
[   10.394989] agpgart-via :00:00.0: putting AGP V3 device into 8x 
mode
[   10.396634] radeon :01:00.0: putting AGP V3 device into 8x mode
[   10.396649] radeon :01:00.0: GTT: 256M 0xE000 - 0xEFFF
[   10.396661] radeon :01:00.0: VRAM: 1024M 0xA000 - 0xDFFF 
(1024M used)
[   10.399244] [drm] Detected VRAM RAM=1024M, BAR=256M
[   10.399254] [drm] RAM width 128bits DDR
[   10.402125] [TTM] Zone  kernel: Available graphics memory: 441924 kiB
[   10.402133] [TTM] Zone highmem: Available graphics memory: 1033768 
kiB
[   10.402136] [TTM] Initializing pool allocator
[   10.402198] [drm] radeon: 1024M of VRAM memory ready
[   10.402202] [drm] radeon: 256M of GTT memory ready.
[   10.402244] [drm] Supports vblank timestamp caching Rev 1 
(10.10.2010).
[   10.402247] [drm] Driver supports precise vblank timestamp query.
[   10.402319] [drm] radeon: irq initialized.

[-]

[   10.524045] [drm] GART: num cpu pages 65536, num gpu pages 65536
[   10.528182] [drm] Loading RV730 Microcode
[   10.641945] radeon :01:00.0: WB disabled
[   10.641964] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0xe004 and cpu a
ddr 0xf84c0004
[   10.641969] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0xec0c and cpu addr 0xf84c0c0c
[   10.642218] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0xa005c598 and cpu addr 0xf879c598
[   10.785565] [drm] ring test on 0 succeeded in 1 usecs
[   10.785636] [drm] ring test on 3 succeeded in 1 usecs
[   10.842237]  md127:
[   10.847965] [drm] ring test on 5 succeeded in 1 usecs
[   10.847976] [drm] UVD initialized successfully.
[   10.848690] [drm] ib test on ring 0 succeeded in 0 usecs
[   10.848729] [drm] ib test on ring 3 succeeded in 1 usecs
[   10.858255] [drm] ib test on ring 5 succeeded

Thank you Christian!

Dieter

> ---
> drivers/gpu/drm/radeon/radeon_fence.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 1a699ce..5b937df 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -767,8 +767,8 @@ int radeon_fence_driver_start_ring(struct
> radeon_device *rdev, int ring)
> 
>   radeon_scratch_free(rdev, rdev->fence_drv[ring].scratch_reg);
>   if (rdev->wb.use_event || !radeon_ring_supports_scratch_reg(rdev,
> &rdev->ring[ring])) {
> + rdev->fence_drv[ring].scratch_reg = 0;
>   if (ring != R600_RING_TYPE_UVD_INDEX) {
> - rdev->fence_drv[ring].scratch_reg = 0;
>   index = R600_WB_EVENT_OFFSET + ring * 4;
>   rdev->fence_drv[ring].cpu_addr = &rdev->wb.wb[index/4];
>   rdev->fence_drv[ring].gpu_addr = rdev->wb.gpu_addr +

[PATCH] drm/radeon: allocate SA bo in the requested domain

[Dieter Nützel]

Am 2013-04-25 18:19, schrieb Christian K?nig:
> From: Christian K?nig 
> 
> This avoid moving the BO directly after allocating it.
> 
> Signed-off-by: Christian K?nig 

Tested-by: Dieter N?tzel 

Regards,
Dieter

> ---
> drivers/gpu/drm/radeon/radeon_sa.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
> b/drivers/gpu/drm/radeon/radeon_sa.c
> index cb80099..0abe5a9 100644
> --- a/drivers/gpu/drm/radeon/radeon_sa.c
> +++ b/drivers/gpu/drm/radeon/radeon_sa.c
> @@ -64,7 +64,7 @@ int radeon_sa_bo_manager_init(struct radeon_device 
> *rdev,
>   }
> 
>   r = radeon_bo_create(rdev, size, RADEON_GPU_PAGE_SIZE, true,
> -  RADEON_GEM_DOMAIN_CPU, NULL, &sa_manager->bo);
> +  domain, NULL, &sa_manager->bo);
>   if (r) {
>   dev_err(rdev->dev, "(%d) failed to allocate bo for manager\n", 
> r);
>   return r;

[PATCH] drm/radeon: drm/radeon: add missing radeon_semaphore_free to error path

[Dieter Nützel]

Tested-by for RV730 (r600.c).

Am 24.04.2014 13:29, schrieb Maarten Lankhorst:
> It would appear this bug has been copy/pasted many times without being 
> noticed.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/radeon/cik.c 
> b/drivers/gpu/drm/radeon/cik.c
> index f58a07c26b86..0e071571a4c6 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -3670,6 +3670,7 @@ int cik_copy_cpdma(struct radeon_device *rdev,
>   r = radeon_fence_emit(rdev, fence, ring->idx);
>   if (r) {
>   radeon_ring_unlock_undo(rdev, ring);
> + radeon_semaphore_free(rdev, &sem, NULL);
>   return r;
>   }
>  diff --git a/drivers/gpu/drm/radeon/cik_sdma.c
> b/drivers/gpu/drm/radeon/cik_sdma.c
> index 94626ea90fa5..06ca19cf5446 100644
> --- a/drivers/gpu/drm/radeon/cik_sdma.c
> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
> @@ -564,6 +564,7 @@ int cik_copy_dma(struct radeon_device *rdev,
>   r = radeon_fence_emit(rdev, fence, ring->idx);
>   if (r) {
>   radeon_ring_unlock_undo(rdev, ring);
> + radeon_semaphore_free(rdev, &sem, NULL);
>   return r;
>   }
>  diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c
> b/drivers/gpu/drm/radeon/evergreen_dma.c
> index a37b54436382..e6b8c752e42c 100644
> --- a/drivers/gpu/drm/radeon/evergreen_dma.c
> +++ b/drivers/gpu/drm/radeon/evergreen_dma.c
> @@ -151,6 +151,7 @@ int evergreen_copy_dma(struct radeon_device *rdev,
>   r = radeon_fence_emit(rdev, fence, ring->idx);
>   if (r) {
>   radeon_ring_unlock_undo(rdev, ring);
> + radeon_semaphore_free(rdev, &sem, NULL);
>   return r;
>   }
>  diff --git a/drivers/gpu/drm/radeon/r600.c 
> b/drivers/gpu/drm/radeon/r600.c
> index 7a4ee41c7cab..fc9568547a97 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2843,6 +2843,7 @@ int r600_copy_cpdma(struct radeon_device *rdev,
>   r = radeon_fence_emit(rdev, fence, ring->idx);
>   if (r) {
>   radeon_ring_unlock_undo(rdev, ring);
> + radeon_semaphore_free(rdev, &sem, NULL);
>   return r;
>   }
>  diff --git a/drivers/gpu/drm/radeon/r600_dma.c
> b/drivers/gpu/drm/radeon/r600_dma.c
> index b2d4c91e6272..2590e2289303 100644
> --- a/drivers/gpu/drm/radeon/r600_dma.c
> +++ b/drivers/gpu/drm/radeon/r600_dma.c
> @@ -493,6 +493,7 @@ int r600_copy_dma(struct radeon_device *rdev,
>   r = radeon_fence_emit(rdev, fence, ring->idx);
>   if (r) {
>   radeon_ring_unlock_undo(rdev, ring);
> + radeon_semaphore_free(rdev, &sem, NULL);
>   return r;
>   }
>  diff --git a/drivers/gpu/drm/radeon/rv770_dma.c
> b/drivers/gpu/drm/radeon/rv770_dma.c
> index aca8cbe8a335..bbf2e076ee45 100644
> --- a/drivers/gpu/drm/radeon/rv770_dma.c
> +++ b/drivers/gpu/drm/radeon/rv770_dma.c
> @@ -86,6 +86,7 @@ int rv770_copy_dma(struct radeon_device *rdev,
>   r = radeon_fence_emit(rdev, fence, ring->idx);
>   if (r) {
>   radeon_ring_unlock_undo(rdev, ring);
> + radeon_semaphore_free(rdev, &sem, NULL);
>   return r;
>   }
>  diff --git a/drivers/gpu/drm/radeon/si_dma.c 
> b/drivers/gpu/drm/radeon/si_dma.c
> index 59be2cfcbb47..e61ab2d7da41 100644
> --- a/drivers/gpu/drm/radeon/si_dma.c
> +++ b/drivers/gpu/drm/radeon/si_dma.c
> @@ -215,6 +215,7 @@ int si_copy_dma(struct radeon_device *rdev,
>   r = radeon_fence_emit(rdev, fence, ring->idx);
>   if (r) {
>   radeon_ring_unlock_undo(rdev, ring);
> + radeon_semaphore_free(rdev, &sem, NULL);
>   return r;
>   }
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: avoid UVD corruptions on AGP cards

[Dieter Nützel]

Am 15.09.2013 13:31, schrieb Christian K?nig:
> From: Christian K?nig 
> 
> Putting everything into VRAM seems to help.
> 
> Signed-off-by: Christian K?nig 
> ---
>  drivers/gpu/drm/radeon/radeon_cs.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 27ea004..ac6ece6 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -81,9 +81,11 @@ static int radeon_cs_parser_relocs(struct
> radeon_cs_parser *p)
>   p->relocs[i].lobj.bo = p->relocs[i].robj;
>   p->relocs[i].lobj.written = !!r->write_domain;
> 
> - /* the first reloc of an UVD job is the
> -msg and that must be in VRAM */
> - if (p->ring == R600_RING_TYPE_UVD_INDEX && i == 0) {
> + /* the first reloc of an UVD job is the msg and that must be in
> +VRAM, also but everything into VRAM on AGP cards to avoid
> +image corruptions */
> + if (p->ring == R600_RING_TYPE_UVD_INDEX &&
> + (i == 0 || p->rdev->flags & RADEON_IS_AGP)) {
>   /* TODO: is this still needed for NI+ ? */
>   p->relocs[i].lobj.domain =
>   RADEON_GEM_DOMAIN_VRAM;

Go a head - direct way to stable!!!
What a nice weekend present Christian ;-)
Works like a charm.

2 simultaneous mplayer videos (1280x720 H.264, 854x480 H.264) plus ~35 % 
idle on my poor Duron 1800.

Chen Jie's test.avi (1920x1080 H.264) on my 1920x1080 desktop at ~35% 
idle, too.

Cheers,
   Dieter
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dmesg-drm-fixes-3.12-AGP-patch-dpm-1.log
URL: 

Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space

[Dieter Nützel]

Am 30.09.2013 14:19, schrieb Daniel Vetter:
> On Mon, Sep 30, 2013 at 2:04 PM, Dieter N?tzel  
> wrote:
>> Even so, I have no xorg.conf only /etc/X11/xorg.conf.d/ files.
>> Which one should I create/change for testing, this?
> 
> Just add the snippet I've pasted into a new file in xorg.conf.d and X
> should pick it up and integrate it into the autodetected config. You
> can check in the Xorg.log whether it worked out.
> -Daniel

OK, I guessed that...
...and put it in /etc/X11/xorg.conf.d/99-vblank.conf
X picked it up

[-]
[43.333] (==) No Layout section.  Using the first Screen section.
[43.333] (**) |-->Screen "igd" (0)
[43.333] (**) |   |-->Monitor ""
[43.338] (==) No monitor specified for screen "igd"
[-]
[43.583] (II) RADEON(0): Creating default Display subsection in 
Screen section
 "igd" for depth/fbbpp 24/32
[43.583] (**) RADEON(0): Depth 24, (--) framebuffer bpp 32
[43.583] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 
bpp pixmaps)
[43.583] (==) RADEON(0): Default visual is TrueColor
[43.588] (==) RADEON(0): RGB weight 888
[43.588] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[43.588] (--) RADEON(0): Chipset: "ATI Radeon HD 4600 Series" 
(ChipID = 0x9495)
[-]

But that didn't help, here.
I've fiddled around with patching libvdpau-0.6 (the 
/etc/vdpau_wrapper.cfg thing, changing 'libflashplayer' to 
'libgcflashplayer' from 2012, which is the only one that works a little 
with hardware acceleration on SSE1 systems), but that didn't help, here 
neither ;-(((

Fu.. you ADOBE!

Thanks,
Dieter
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: Xorg.0.log
URL: 

[PATCH] drm/radeon: fix missing bo reservation

[Dieter Nützel]

Alex,

shouldn't you send a pull request, that this land in 3.14-rc4?
Just in case...

Thanks,
   Dieter

Am 20.02.2014 18:47, schrieb Christian K?nig:
> From: Christian K?nig 
> 
> Otherwise we might get a crash here.
> 
> Signed-off-by: Christian K?nig 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 114d167..2aecd6d 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -537,6 +537,10 @@ int radeon_driver_open_kms(struct drm_device
> *dev, struct drm_file *file_priv)
> 
>   radeon_vm_init(rdev, &fpriv->vm);
> 
> + r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
> + if (r)
> + return r;
> +
>   /* map the ib pool buffer read only into
>* virtual address space */
>   bo_va = radeon_vm_bo_add(rdev, &fpriv->vm,
> @@ -544,6 +548,8 @@ int radeon_driver_open_kms(struct drm_device *dev,
> struct drm_file *file_priv)
>   r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET,
> RADEON_VM_PAGE_READABLE |
> RADEON_VM_PAGE_SNOOPED);
> +
> + radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
>   if (r) {
>   radeon_vm_fini(rdev, &fpriv->vm);
>   kfree(fpriv);

[PATCH] drm/doc: Clarify the dumb object interfaces

[Dieter Nützel]

Am 24.01.2014 17:58, schrieb Daniel Vetter:

Just two typos ('said' my spellchecker...;-)

Regards,
Dieter

> - This is _not_ a generic interface to create gem objects, but just an
>   interface to make early boot services (like boot splash) with a
>   generic KMS userspace driver possible. Hence it's better to move
>   the documentation for this from the GEM section to the KMS section,
>   next to the creation of framebuffer objects.
> 
> - Make it really clear that the returned handle isn't necessarily a
>   GEM object (it can also be e.g. a TTM handle when running on top of
>   vmwgfx).
> 
> - Add a paragraph to make it clear that this is just for unaccelarated
>   userspace - gpu drivers need to have their own buffer object
>   creation ioctl which is hardware specific.
> 
> v2: Clarify that the documentation doesn't just apply to GEM-based
> drivers only but is now generally valid, as suggested by David.
> 
> v3: Polish the intro sentence a bit and one s/objects/handles/ for
> clarification, both suggested by Laurent.
> 
> v4: More text polish from Laurent's review.
> 
> Cc: David Herrmann 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/drm.tmpl | 131 
> ++---
>  1 file changed, 71 insertions(+), 60 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl 
> b/Documentation/DocBook/drm.tmpl
> index ed1d6d289022..67cfe184749c 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -830,62 +830,6 @@ char *date;
>  
>
>
> -Dumb GEM Objects
> -
> -  The GEM API doesn't standardize GEM objects creation and 
> leaves it to
> -  driver-specific ioctls. While not an issue for full-fledged 
> graphics
> -  stacks that include device-specific userspace components
> (in libdrm for
> -  instance), this limit makes DRM-based early boot graphics
> unnecessarily
> -  complex.
> -
> -
> -  Dumb GEM objects partly alleviate the problem by providing a 
> standard
> -  API to create dumb buffers suitable for scanout, which can
> then be used
> -  to create KMS frame buffers.
> -
> -
> -  To support dumb GEM objects drivers must implement the
> -  dumb_create,
> -  dumb_destroy and
> -  dumb_map_offset operations.
> -
> -
> -  
> -int (*dumb_create)(struct drm_file *file_priv,
> struct drm_device *dev,
> - struct drm_mode_create_dumb *args);
> -
> -  The dumb_create operation 
> creates a GEM
> -  object suitable for scanout based on the width, height 
> and depth
> -  from the struct 
> drm_mode_create_dumb
> -  argument. It fills the argument's
> handle,
> -  pitch and
> size
> -  fields with a handle for the newly created GEM object
> and its line
> -  pitch and size in bytes.
> -
> -  
> -  
> -int (*dumb_destroy)(struct drm_file *file_priv,
> struct drm_device *dev,
> -  uint32_t handle);
> -
> -  The dumb_destroy operation
> destroys a dumb
> -  GEM object created by 
> dumb_create.
> -
> -  
> -  
> -int (*dumb_map_offset)(struct drm_file
> *file_priv, struct drm_device *dev,
> - uint32_t handle, uint64_t 
> *offset);
> -
> -  The dumb_map_offset operation
> associates an
> -  mmap fake offset with the GEM object given by the
> handle and returns
> -  it. Drivers must use the
> -  drm_gem_create_mmap_offset function 
> to
> -  associate the fake offset as described in
> -  .
> -
> -  
> -
> -  
> -  
>  Memory Coherency
>  
>When mapped to the device or used in a command buffer, 
> backing pages
> @@ -968,9 +912,11 @@ int max_width, max_height;
>  Frame buffers rely on the underneath memory manager for
> low-level memory
>  operations. When creating a frame buffer applications pass a 
> memory
>  handle (or a list of memory handles for multi-planar formats) 
> through
> -the drm_mode_fb_cmd2 argument. This 
> document
> -assumes that the driver uses GEM, those handles thus reference 
> GEM
> -objects.
> + the drm_mode_fb_cmd2 argument. For drivers 
> using
> + GEM as their userspace buffer management interface this would be a 
> GEM
> + handle.  Drivers are however free to use their own backing storage 
> object
> + handles, e.g. vmwgfx directly exposes special TTM handles to 
> userspace
> + and so expects TTM handles in the create ioctl and not GEM handles.
>
>
>  Drivers must first valida

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

[Dieter Nützel]

Am 01.07.2014 10:14, schrieb Michel D?nzer:
> From: Michel D?nzer 
> 
> But move the programming back to the vertical blank interrupt handler.
> And signal the flip as being completed immediately after programming it
> to the hardware.
> 
> This way we don't have to guess whether or not the hardware will 
> execute
> the flip in a given vertical blank period, avoiding a whole lot of
> trouble.
> 
> Also, not using the page flip interrupt anymore avoids problems due to
> completing page flips earlier than expected by userspace.
> 
> Signed-off-by: Michel D?nzer 

Michel,

against which tree is this first one?
Don't apply clean on 3.16-rc2.

Can't find this in 'my' source (radeon_display.c).

>>radeon_crtc->flip_status = RADEON_FLIP_SUBMITTED; <<<
 spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
 up_read(&rdev->exclusive_lock);

Thanks,
Dieter

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

[Dieter Nützel]

Am 02.07.2014 02:29, schrieb Michel D?nzer:
> On 02.07.2014 01:46, Dieter N?tzel wrote:
>> Am 01.07.2014 10:14, schrieb Michel D?nzer:
>>> From: Michel D?nzer 
>>> 
>>> But move the programming back to the vertical blank interrupt 
>>> handler.
>>> And signal the flip as being completed immediately after programming 
>>> it
>>> to the hardware.
>>> 
>>> This way we don't have to guess whether or not the hardware will 
>>> execute
>>> the flip in a given vertical blank period, avoiding a whole lot of
>>> trouble.
>>> 
>>> Also, not using the page flip interrupt anymore avoids problems due 
>>> to
>>> completing page flips earlier than expected by userspace.
>>> 
>>> Signed-off-by: Michel D?nzer 
>> 
>> Michel,
>> 
>> against which tree is this first one?
>> Don't apply clean on 3.16-rc2.
>> 
>> Can't find this in 'my' source (radeon_display.c).
>> 
radeon_crtc->flip_status = RADEON_FLIP_SUBMITTED; <<<
>> spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
>> up_read(&rdev->exclusive_lock);
> 
> The patch applies on top of my previous page flipping fix.

Had some trouble with the first one but...
After digikam -> OpenGL Viewer (r600g/RV730 AGP)

[-]
[   503.736] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920 
2040 2248 2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
[   999.627] (WW) RADEON(0): flip queue failed: Device or resource busy
[   999.627] (WW) RADEON(0): Page flip failed: Device or resource busy

Another day ;-)

Mesa git - auxiliary: compilation error with latest LLVM git in gallivm/lp_bld_debug.lo

[Dieter Nützel]

make[4]: Entering directory '/opt/mesa/src/gallium/auxiliary'
   CXX  gallivm/lp_bld_debug.lo
gallivm/lp_bld_debug.cpp: In function 'size_t disassemble(const void*, 
llvm::raw_ostream&)':
gallivm/lp_bld_debug.cpp:280:54: error: no matching function for call to 
'llvm::TargetMachine::getSubtargetImpl()'
 const TargetInstrInfo *TII = TM->getSubtargetImpl()->getInstrInfo();
   ^
gallivm/lp_bld_debug.cpp:280:54: note: candidate is:
In file included from gallivm/lp_bld_debug.cpp:31:0:
/usr/local/include/llvm/Target/TargetMachine.h:111:38: note: virtual 
const llvm::TargetSubtargetInfo* 
llvm::TargetMachine::getSubtargetImpl(const llvm::Function&) const
virtual const TargetSubtargetInfo *getSubtargetImpl(const Function &) 
const {
   ^
/usr/local/include/llvm/Target/TargetMachine.h:111:38: note:   candidate 
expects 1 argument, 0 provided
Makefile:2221: recipe for target 'gallivm/lp_bld_debug.lo' failed
make[4]: *** [gallivm/lp_bld_debug.lo] Error 1

Mesa git - auxiliary: compilation error with latest LLVM git in gallivm/lp_bld_debug.lo

[Dieter Nützel]

Forget this one.
Duplicate of:
https://bugs.freedesktop.org/show_bug.cgi?id=89705

Sorry for the noise!

-Dieter

Am 22.03.2015 03:49, schrieb Dieter Nützel:
> make[4]: Entering directory '/opt/mesa/src/gallium/auxiliary'
>   CXX  gallivm/lp_bld_debug.lo
> gallivm/lp_bld_debug.cpp: In function 'size_t disassemble(const void*,
> llvm::raw_ostream&)':
> gallivm/lp_bld_debug.cpp:280:54: error: no matching function for call
> to 'llvm::TargetMachine::getSubtargetImpl()'
> const TargetInstrInfo *TII = 
> TM->getSubtargetImpl()->getInstrInfo();
>   ^
> gallivm/lp_bld_debug.cpp:280:54: note: candidate is:
> In file included from gallivm/lp_bld_debug.cpp:31:0:
> /usr/local/include/llvm/Target/TargetMachine.h:111:38: note: virtual
> const llvm::TargetSubtargetInfo*
> llvm::TargetMachine::getSubtargetImpl(const llvm::Function&) const
>virtual const TargetSubtargetInfo *getSubtargetImpl(const Function 
> &) const {
>   ^
> /usr/local/include/llvm/Target/TargetMachine.h:111:38: note:
> candidate expects 1 argument, 0 provided
> Makefile:2221: recipe for target 'gallivm/lp_bld_debug.lo' failed
> make[4]: *** [gallivm/lp_bld_debug.lo] Error 1

LLVM / Clang git for libclc: optimized build or debug?

[Dieter Nützel]

make[1]: Leaving directory '/opt/llvm/bindings'
llvm[0]: * Completed Debug+Asserts Build
llvm[0]: * Note: Debug build can be 10 times slower than an
llvm[0]: * optimized build. Use make ENABLE_OPTIMIZED=1 to
llvm[0]: * make an optimized build. Alternatively you can
llvm[0]: * configure with --enable-optimized.
304.322u 15.792s 1:50.25 290.3% 0+0k 6156432+1518784io 942pf+0w

Second:
'make -j 4' do NOT work in the first run. --- Known?

It breaks with 'killed' not known.

Thanks,
   Dieter

r600 - NI/Turks: flickering with 'geom-outlining-150'

[Dieter Nützel]

Hello Alex,

I get _today_ flickering with Mesa-demo 'geom-outlining-150'.
It worked OK last night and I've reseted Mesa git back to 5c1aac1 but NO 
success.
Only thing is I've used LLVM  git of today, too and for GOOD result LLVM 
from 18th.
Any hints?

For the record:

'geom-outlining-150'
'gsraytrace' (both Mesa-demo)
and
'gl-320-primitive-shading' (ogl-samples)

GS stuff works on r600 - NI/Turks nearly perfect (only the above 
flickering) which show corruption (first and last) or crash 'gsraytrace' 
with r600 - RV730 (AGP).

Maybe I've to add this on the open bug reports...

Great 'experience' with Evergreen+ on PCIE (Xeon X3430/16GB/all 
SSD/Fujitsu PRIMERGY TX150 S7 server-workstation) ;-)

-Dieter

PS I use ccache linked to /dev/shm/.ccache for LLVM as Michel suggested.

r600 - NI/Turks: flickering with 'geom-outlining-150'

[Dieter Nützel]

Am 20.02.2015 17:29, schrieb Alex Deucher:
> On Fri, Feb 20, 2015 at 10:54 AM, Dieter Nützel  
> wrote:
>> Hello Alex,
>> 
>> I get _today_ flickering with Mesa-demo 'geom-outlining-150'.
>> It worked OK last night and I've reseted Mesa git back to 5c1aac1 but 
>> NO
>> success.
>> Only thing is I've used LLVM  git of today, too and for GOOD result 
>> LLVM
>> from 18th.
>> Any hints?
>> 
> 
> Please narrow it down to what update caused the issue and then use git
> to bisect.
> 
> Alex

Couldn't find a GOOD version (Mesa/LLVM) for bisect start so far.
I've to search further.
-Dieter


>> For the record:
>> 
>> 'geom-outlining-150'
>> 'gsraytrace' (both Mesa-demo)
>> and
>> 'gl-320-primitive-shading' (ogl-samples)
>> 
>> GS stuff works on r600 - NI/Turks nearly perfect (only the above 
>> flickering)
>> which show corruption (first and last) or crash 'gsraytrace' with r600 
>> -
>> RV730 (AGP).
>> 
>> Maybe I've to add this on the open bug reports...
>> 
>> Great 'experience' with Evergreen+ on PCIE (Xeon X3430/16GB/all 
>> SSD/Fujitsu
>> PRIMERGY TX150 S7 server-workstation) ;-)
>> 
>> -Dieter
>> 
>> PS I use ccache linked to /dev/shm/.ccache for LLVM as Michel 
>> suggested.

drm-next-4.1-wip: NI/Turks *ERROR* chosen encoder in use 4

[Dieter Nützel]

Hello Alex,

I get this in dmesg:

[   26.001926] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* 
chosen encoder in use 4

What do you need?

-Dieter
-- next part --
A non-text attachment was scrubbed...
Name: dmesg-4.1-wip.log.xz
Type: application/x-xz
Size: 14832 bytes
Desc: not available
URL: 

Fwd: drm-next-4.1-wip: NI/Turks *ERROR* chosen encoder in use 4

[Dieter Nützel]

Hello Dave,

latest change comes from you.

author  Dave Airlie  2015-02-23 23:24:03 (GMT)
committer   Alex Deucher  2015-02-24 
19:52:03 
(GMT)
commit  8eeefdc92b7e0b05a627ec7e3cb3ce31c03362ab (patch)

Any idea?

Thanks,
   Dieter

 Originalnachricht 
Betreff: drm-next-4.1-wip: NI/Turks *ERROR* chosen encoder in use 4
Datum: 25.02.2015 05:20
Von: Dieter Nützel 
An: Alex Deucher 
Kopie: Dri Devel 

Hello Alex,

I get this in dmesg:

[   26.001926] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* 
chosen encoder in use 4

What do you need?

-Dieter
___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: dmesg-4.1-wip.log.xz
Type: application/x-xz
Size: 14832 bytes
Desc: not available
URL: 

r600 - NI/Turks: flickering with 'geom-outlining-150'

[Dieter Nützel]

Am 25.02.2015 09:31, schrieb Michel Dänzer:
> On 25.02.2015 13:04, Dieter Nützel wrote:
>> Am 20.02.2015 17:29, schrieb Alex Deucher:
>>> On Fri, Feb 20, 2015 at 10:54 AM, Dieter Nützel 
>>> 
>>> wrote:
 Hello Alex,
 
 I get _today_ flickering with Mesa-demo 'geom-outlining-150'.
 It worked OK last night and I've reseted Mesa git back to 5c1aac1 
 but NO
 success.
 Only thing is I've used LLVM  git of today, too and for GOOD result 
 LLVM
 from 18th.
 Any hints?
 
>>> 
>>> Please narrow it down to what update caused the issue and then use 
>>> git
>>> to bisect.
>>> 
>>> Alex
>> 
>> Couldn't find a GOOD version (Mesa/LLVM) for bisect start so far.
>> I've to search further.
> 
> Note that the r600g driver doesn't use LLVM for graphics shader
> compilation, so you should only need to search in Mesa and maybe the
> kernel or libdrm.

Thanks for the hint Michel.

But, ughhh...
...in the minute it WORKS without a hitch!

I'm running a new LLVM compilation with 4 cores and thought try it.

System spec:
Mesa 10.6.0-devel (git-cb25087)
libdrm-2.4.59 (minor distro update on 24th)
Linux 4.0.0-rc1-2.g1133f88-desktop+ (drm-next-4.1, 50c7535, 23 hours 
ago)

I'll freeze LLVM (do not install latest compile) and try to bisect Mesa 
(?) 'cause kernel and libdrm did NOT changed compared to tests last 
night.

-Dieter

drm-next-4.1-wip: NI/Turks *ERROR* chosen encoder in use 4

[Dieter Nützel]

Am 25.02.2015 23:02, schrieb Dave Airlie:
> On 26 February 2015 at 06:22, Alex Deucher  
> wrote:
>> On Tue, Feb 24, 2015 at 11:20 PM, Dieter Nützel  
>> wrote:
>>> Hello Alex,
>>> 
>>> I get this in dmesg:
>>> 
>>> [   26.001926] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* 
>>> chosen
>>> encoder in use 4
>>> 
>>> What do you need?
>> 
>> The message is harmless I think.  It's just debugging output from the
>> DP MST patches.  I think what's happening is that when you change the
>> mode on an encoder that is already enabled, it see that the encoder is
>> already in use (by itself).  I think the fix would be to call
>> radeon_atom_release_dig_encoder() in the encoder prepare callback, but
>> I'm not sure if that will negatively affect MST or not.  Dave?
> 
> well we can drop the message down to debug_kms, I'll have a look
> to see if we need to do a release there, its probably safe but I'd have 
> to
> test it.
> 
> Dave.

Fixed in (new) drm-next-4.1-wip by commit:
2248a6a41473e4a77391a2163284fe0683eac165

Thanks Dave and Alex!

-Dieter

[PATCH] drm/radeon: release digital encoder before asking for new one.

[Dieter Nützel]

Am 26.02.2015 03:05, schrieb Alex Deucher:
> On Wed, Feb 25, 2015 at 8:32 PM, Dave Airlie  wrote:
>> From: Dave Airlie 
>> 
>> This stops a DRM_ERROR that says we already used the encoder.
>> 
>> Reported-by: Dieter Nützel 
>> Signed-off-by: Dave Airlie 
> 
> I've squashed this into the appropriate patch and pushed a new 4.1-wip 
> tree.
> 
> Alex

Up and running.
Thanks!

-⁠Dieter

>> ---
>>  drivers/gpu/drm/radeon/atombios_encoders.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index e8fe2b7..0f46f68 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -2465,6 +2465,8 @@ static void radeon_atom_encoder_prepare(struct 
>> drm_encoder *encoder)
>>  ENCODER_OBJECT_ID_NONE)) {
>> struct radeon_encoder_atom_dig *dig = 
>> radeon_encoder->enc_priv;
>> if (dig) {
>> +   if (dig->dig_encoder >= 0)
>> +   radeon_atom_release_dig_encoder(rdev, 
>> dig->dig_encoder);
>> dig->dig_encoder = 
>> radeon_atom_pick_dig_encoder(encoder, -1);
>> if (radeon_encoder->active_device & 
>> ATOM_DEVICE_DFP_SUPPORT) {
>> if (rdev->family >= CHIP_R600)
>> --
>> 2.1.0
>> 
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

r600 - NI/Turks: flickering with 'geom-outlining-150'

[Dieter Nützel]

Am 25.02.2015 22:50, schrieb Dieter Nützel:
> Am 25.02.2015 09:31, schrieb Michel Dänzer:
>> On 25.02.2015 13:04, Dieter Nützel wrote:
>>> Am 20.02.2015 17:29, schrieb Alex Deucher:
 On Fri, Feb 20, 2015 at 10:54 AM, Dieter Nützel 
 
 wrote:
> Hello Alex,
> 
> I get _today_ flickering with Mesa-demo 'geom-outlining-150'.
> It worked OK last night and I've reseted Mesa git back to 5c1aac1 
> but NO
> success.
> Only thing is I've used LLVM  git of today, too and for GOOD result 
> LLVM
> from 18th.
> Any hints?
> 
 
 Please narrow it down to what update caused the issue and then use 
 git
 to bisect.
 
 Alex
>>> 
>>> Couldn't find a GOOD version (Mesa/LLVM) for bisect start so far.
>>> I've to search further.
>> 
>> Note that the r600g driver doesn't use LLVM for graphics shader
>> compilation, so you should only need to search in Mesa and maybe the
>> kernel or libdrm.
> 
> Thanks for the hint Michel.
> 
> But, ughhh...
> ...in the minute it WORKS without a hitch!
> 
> I'm running a new LLVM compilation with 4 cores and thought try it.
> 
> System spec:
> Mesa 10.6.0-devel (git-cb25087)
> libdrm-2.4.59 (minor distro update on 24th)
> Linux 4.0.0-rc1-2.g1133f88-desktop+ (drm-next-4.1, 50c7535, 23 hours 
> ago)
> 
> I'll freeze LLVM (do not install latest compile) and try to bisect
> Mesa (?) 'cause kernel and libdrm did NOT changed compared to tests
> last night.

Michel,

it seems to be radeon drm ((HDMI) audio_dpms) related.
Have a look here:
https://bugs.freedesktop.org/show_bug.cgi?id=89327

Greetings,
   Dieter

[PATCH 5/7] drm/radeon: add spinlock for BO_VA status protection

[Dieter Nützel]

Am 27.11.2014 14:48, schrieb Christian König:
> From: Christian König 
> 
> Stop using the VM mutex for this
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/radeon/radeon.h|  3 +++
>  drivers/gpu/drm/radeon/radeon_vm.c | 36 
> ++--
>  2 files changed, 33 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon.h 
> b/drivers/gpu/drm/radeon/radeon.h
> index da1c549..3680cf0 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -929,6 +929,9 @@ struct radeon_vm {
> 
>   struct rb_root  va;
> 
> + /* ptotecting invalidated and freed */

protecting

> + spinlock_t  status_lock;
> +
>   /* BOs moved, but not yet updated in the PT */
>   struct list_headinvalidated;
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index 6bc3821..cde48c4 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -487,7 +487,9 @@ int radeon_vm_bo_set_addr(struct radeon_device 
> *rdev,
>   tmp->vm = vm;
>   tmp->addr = bo_va->addr;
>   tmp->bo = radeon_bo_ref(bo_va->bo);
> + spin_lock(&vm->status_lock);
>   list_add(&tmp->vm_status, &vm->freed);
> + spin_unlock(&vm->status_lock);
>   }
> 
>   interval_tree_remove(&bo_va->it, &vm->va);
> @@ -913,7 +915,9 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
>   return -EINVAL;
>   }
> 
> + spin_lock(&vm->status_lock);
>   list_del_init(&bo_va->vm_status);
> + spin_unlock(&vm->status_lock);
> 
>   bo_va->flags &= ~RADEON_VM_PAGE_VALID;
>   bo_va->flags &= ~RADEON_VM_PAGE_SYSTEM;
> @@ -1028,17 +1032,25 @@ int radeon_vm_bo_update(struct radeon_device 
> *rdev,
>  int radeon_vm_clear_freed(struct radeon_device *rdev,
> struct radeon_vm *vm)
>  {
> - struct radeon_bo_va *bo_va, *tmp;
> + struct radeon_bo_va *bo_va;
>   int r;
> 
> - list_for_each_entry_safe(bo_va, tmp, &vm->freed, vm_status) {
> + spin_lock(&vm->status_lock);
> + while (!list_empty(&vm->freed)) {
> + bo_va = list_first_entry(&vm->freed,
> + struct radeon_bo_va, vm_status);
> + spin_unlock(&vm->status_lock);
> +
>   r = radeon_vm_bo_update(rdev, bo_va, NULL);
>   radeon_bo_unref(&bo_va->bo);
>   radeon_fence_unref(&bo_va->last_pt_update);
>   kfree(bo_va);
>   if (r)
>   return r;
> +
> + spin_lock(&vm->status_lock);
>   }
> + spin_unlock(&vm->status_lock);
>   return 0;
> 
>  }
> @@ -1057,14 +1069,23 @@ int radeon_vm_clear_freed(struct radeon_device 
> *rdev,
>  int radeon_vm_clear_invalids(struct radeon_device *rdev,
>struct radeon_vm *vm)
>  {
> - struct radeon_bo_va *bo_va, *tmp;
> + struct radeon_bo_va *bo_va;
>   int r;
> 
> - list_for_each_entry_safe(bo_va, tmp, &vm->invalidated, vm_status) {
> + spin_lock(&vm->status_lock);
> + while (!list_empty(&vm->invalidated)) {
> + bo_va = list_first_entry(&vm->invalidated,
> + struct radeon_bo_va, vm_status);
> + spin_unlock(&vm->status_lock);
> +
>   r = radeon_vm_bo_update(rdev, bo_va, NULL);
>   if (r)
>   return r;
> +
> + spin_lock(&vm->status_lock);
>   }
> + spin_unlock(&vm->status_lock);
> +
>   return 0;
>  }
> 
> @@ -1087,6 +1108,7 @@ void radeon_vm_bo_rmv(struct radeon_device *rdev,
> 
>   mutex_lock(&vm->mutex);
>   interval_tree_remove(&bo_va->it, &vm->va);
> + spin_lock(&vm->status_lock);
>   list_del(&bo_va->vm_status);
> 
>   if (bo_va->addr) {
> @@ -1096,6 +1118,7 @@ void radeon_vm_bo_rmv(struct radeon_device *rdev,
>   radeon_fence_unref(&bo_va->last_pt_update);
>   kfree(bo_va);
>   }
> + spin_unlock(&vm->status_lock);
> 
>   mutex_unlock(&vm->mutex);
>  }
> @@ -1116,10 +1139,10 @@ void radeon_vm_bo_invalidate(struct 
> radeon_device *rdev,
> 
>   list_for_each_entry(bo_va, &bo->va, bo_list) {
>   if (bo_va->addr) {
> - mutex_lock(&bo_va->vm->mutex);
> + spin_lock(&bo_va->vm->status_lock);
>   list_del(&bo_va->vm_status);
>   list_add(&bo_va->vm_status, &bo_va->vm->invalidated);
> - mutex_unlock(&bo_va->vm->mutex);
> + spin_unlock(&bo_va->vm->status_lock);
>   }
>   }
>  }
> @@ -1147,6 +1170,7 @@ int radeon_vm_init(struct radeon_device *rdev,
> struct radeon_vm *vm)
>   }
>   mutex_init(&vm->mutex);
>   vm->va = RB_ROOT;
> + spin_lock_init(&vm->status_lock);
> 

[r600g] Is LLVM-compiler (--enable-r600-llvm-compiler) usable, now?

[Dieter Nützel]

Hello Michel,

subject say it all ;-)

Second, we are now nearly on par with 3.16 on RV730 (AGP) with all your 
latest work, but I think about what we could get if we find the right 
commit between 3.16 (.4 here) and 3.17-rc1 (the transition from 3.16 to 
3.17-next).

I do not have 3.16.x around (it is not any longer in the openSUSE kernel 
current tree) but with latest 3.16.4 I was faster then with all 3.17.x 
and 3.18/3.19-next kernels.

bisect do not work right or I couldn't revert the 'right' commit.
WC helped on RV730 (AGP) with some apps, here:

mesa-demos e.g.
vsraytrace
fsraytrace
objview

Any ideas?

-Dieter