[Bug 95472] [i915] Feature request: Add support for fencing for PRIME setups

[bugzilla-daemon at freedesktop.org]

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

Mario Kleiner <mario.kleiner at tuebingen.mpg.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mario.kleiner at tuebingen.mpg
                   |                            |.de

--- Comment #54 from Mario Kleiner <mario.kleiner at tuebingen.mpg.de> ---
To add some additional data.

I tested the current Linux 4.8-rc4 with DRI3/Present + PRIME renderoffload on:

a) Intel Ivybridge desktop + AMD Cedar (Evergreen family), radeon-kms + r600g
b) Intel Haswell desktop + AMD Tonga (VI family), amdgpu-kms + radeonsi.

This was tested with page-flipping, and the ftrace scripts i'll attach shortly.

In case a) page-flipping worked under all loads without any tearing or
rendering artifacts. The traces show that i915 properly blocks on the
dmabuf-fence / reservation objects for a couple of milliseconds, longer if the
rendering load is higher.

This is consistent with other successful tests i did with radeon-kms/r600 on
AMD evergreen + AMD evergreen, and with Intel + Nvidia under nouveau. In all
cases i got the right behaviour under DRI + Prime renderoffload.

E.g. from i915_optimus_tracing.sh:

low load:

 2)               |  intel_mmio_flip_work_func [i915]() {
 2) # 3878.042 us |    reservation_object_wait_timeout_rcu();
 2) # 3882.433 us |  }

Output from tonga_tracing.sh with the proper line uncommented for
intel+radeon-kms:

  PTB mainthread-3235  [002] ....  7474.200826: radeon_cs_ioctl <-drm_ioctl
  PTB mainthread-3224  [003] ....  7474.202235:
reservation_object_wait_timeout_rcu <-radeon_gem_wait_idle_ioctl
  PTB mainthread-3235  [002] ....  7474.202277: radeon_cs_ioctl <-drm_ioctl
  PTB mainthread-3235  [002] ....  7474.202423: radeon_cs_ioctl <-drm_ioctl
               X-2588  [002] ....  7474.202592: intel_crtc_page_flip
<-drm_mode_page_flip_ioctl
     kworker/2:1-47    [002] ....  7474.202606: intel_mmio_flip_work_func
<-process_one_work
     kworker/2:1-47    [002] ....  7474.202606:
reservation_object_wait_timeout_rcu <-intel_mmio_flip_work_func

==> Blocks as expected for a few msecs.

     kworker/2:1-47    [002] ....  7474.206213: intel_pipe_update_start
<-intel_mmio_flip_work_func


Case b) otoh., i don't see the pageflip ever blocking on the reservation
object, and while rendering looks good under low/medium load, i can get it to
show incomplete rendering under high load. Exactly the Z-style tearing pattern
one would expect if the Intel flips while the AMD Tonga still renders to the
dmabuf.

E.g., output from tonga_tracing.sh with line for intel+amdgpu-kms under very
high load, when Z-tearing happens:

  PTB mainthread-12766 [001] .... 12538.537618: amdgpu_cs_ioctl <-drm_ioctl
  PTB mainthread-12766 [001] .... 12538.537875: amdgpu_cs_ioctl <-drm_ioctl
  PTB mainthread-12766 [001] .... 12538.537906: amdgpu_cs_ioctl <-drm_ioctl
               X-12250 [000] .... 12538.537935: intel_crtc_page_flip
<-drm_mode_page_flip_ioctl
     kworker/0:2-11651 [000] .... 12538.537957: intel_mmio_flip_work_func
<-process_one_work
     kworker/0:2-11651 [000] .... 12538.537957:
reservation_object_wait_timeout_rcu <-intel_mmio_flip_work_func

==> Falls through although the massive rendering (over)load should cause a ~ 50
msecs delay

     kworker/0:2-11651 [000] .... 12538.537957: intel_pipe_update_start
<-intel_mmio_flip_work_func

Given that intel-kms with pageflipping seems to wait just fine on the dmabuf
fence for both old AMD radeon-kms + r600 and for different NVidia's under
nouveau, but it goes wrong with Tonga on amdgpu + radeonsi, it looks as if
something is missing in amdgpu-kms or radeonsi?

I'll also try with Chris eb-fence branch how it behaves for windowed swaps.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160904/830be7bc/attachment-0001.html>