An error occurred fetching the project authors.
  1. 30 May, 2018 1 commit
  2. 30 Apr, 2018 1 commit
  3. 23 Apr, 2018 2 commits
  4. 10 Feb, 2018 1 commit
  5. 08 Dec, 2017 1 commit
  6. 19 Oct, 2017 1 commit
  7. 08 Aug, 2017 1 commit
  8. 29 Jul, 2017 1 commit
  9. 28 Jul, 2017 1 commit
    • Eric Anholt's avatar
      drm/vc4: Add an ioctl for labeling GEM BOs for summary stats · f3099462
      Eric Anholt authored
      This has proven immensely useful for debugging memory leaks and
      overallocation (which is a rather serious concern on the platform,
      given that we typically run at about 256MB of CMA out of up to 1GB
      total memory, with framebuffers that are about 8MB ecah).
      
      The state of the art without this is to dump debug logs from every GL
      application, guess as to kernel allocations based on bo_stats, and try
      to merge that all together into a global picture of memory allocation
      state.  With this, you can add a couple of calls to the debug build of
      the 3D driver and get a pretty detailed view of GPU memory usage from
      /debug/dri/0/bo_stats (or when we debug print to dmesg on allocation
      failure).
      
      The Mesa side currently labels at the gallium resource level (so you
      see that a 1920x20 pixmap has been created, presumably for the window
      system panel), but we could extend that to be even more useful with
      glObjectLabel() names being sent all the way down to the kernel.
      
      (partial) example of sorted debugfs output with Mesa labeling all
      resources:
      
                     kernel BO cache:  16392kb BOs (3)
             tiling shadow 1920x1080:   8160kb BOs (1)
             resource 1920x1080@32/0:   8160kb BOs (1)
      scanout resource 1920x1080@32/0:   8100kb BOs (1)
                              kernel:   8100kb BOs (1)
      
      v2: Use strndup_user(), use lockdep assertion instead of just a
          comment, fix an array[-1] reference, extend comment about name
          freeing.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170725182718.31468-2-eric@anholt.netReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      f3099462
  10. 15 Jun, 2017 1 commit
  11. 22 May, 2017 1 commit
  12. 10 May, 2017 1 commit
    • Daniel Vetter's avatar
      drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos · 1bf6ad62
      Daniel Vetter authored
      If we restrict this helper to only kms drivers (which is the case) we
      can look up the correct mode easily ourselves. But it's a bit tricky:
      
      - All legacy drivers look at crtc->hwmode. But that is updated already
        at the beginning of the modeset helper, which means when we disable
        a pipe. Hence the final timestamps might be a bit off. But since
        this is an existing bug I'm not going to change it, but just try to
        be bug-for-bug compatible with the current code. This only applies
        to radeon&amdgpu.
      
      - i915 tries to get it perfect by updating crtc->hwmode when the pipe
        is off (i.e. vblank->enabled = false).
      
      - All other atomic drivers look at crtc->state->adjusted_mode. Those
        that look at state->requested_mode simply don't adjust their mode,
        so it's the same. That has two problems: Accessing crtc->state from
        interrupt handling code is unsafe, and it's updated before we shut
        down the pipe. For nonblocking modesets it's even worse.
      
      For atomic drivers try to implement what i915 does. To do that we add
      a new hwmode field to the vblank structure, and update it from
      drm_calc_timestamping_constants(). For atomic drivers that's called
      from the right spot by the helper library already, so all fine. But
      for safety let's enforce that.
      
      For legacy driver this function is only called at the end (oh the
      fun), which is broken, so again let's not bother and just stay
      bug-for-bug compatible.
      
      The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
      directly to implement ->get_vblank_timestamp in every driver, deleting
      a lot of code.
      
      v2: Completely new approach, trying to mimick the i915 solution.
      
      v3: Fixup kerneldoc.
      
      v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
      currently unconditionally call this. Recomputing the same stuff should
      be harmless.
      
      v5: Fix typos and move misplaced hunks to the right patches (Neil).
      
      v6: Undo hunk movement (kbuild).
      
      Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Reviewed-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
      1bf6ad62
  13. 08 May, 2017 1 commit
  14. 13 Apr, 2017 1 commit
  15. 17 Mar, 2017 1 commit
  16. 28 Feb, 2017 1 commit
  17. 09 Feb, 2017 1 commit
  18. 07 Feb, 2017 1 commit
  19. 01 Feb, 2017 1 commit
  20. 30 Jan, 2017 1 commit
  21. 09 Dec, 2016 2 commits
  22. 16 Nov, 2016 1 commit
    • Jonas Pfeil's avatar
      drm/vc4: Add fragment shader threading support · c778cc5d
      Jonas Pfeil authored
      FS threading brings performance improvements of 0-20% in glmark2.
      
      The validation code checks for thread switch signals and ensures that
      the registers of the other thread are not touched, and that our clamps
      are not live across thread switches.  It also checks that the
      threading and branching instructions do not interfere.
      
      (Original patch by Jonas, changes by anholt for style cleanup,
      removing validation the kernel doesn't need to do, and adding the flag
      for userspace).
      
      v2: Minor style fixes from checkpatch.
      Signed-off-by: default avatarJonas Pfeil <pfeiljonas@gmx.de>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      c778cc5d
  23. 04 Nov, 2016 2 commits
    • Eric Anholt's avatar
      drm/vc4: Use runtime autosuspend to avoid thrashing V3D power state. · 3a622346
      Eric Anholt authored
      The pm_runtime_put() we were using immediately released power on the
      device, which meant that we were generally turning the device off and
      on once per frame.  In many profiles I've looked at, that added up to
      about 1% of CPU time, but this could get worse in the case of frequent
      rendering and readback (as may happen in X rendering).  By keeping the
      device on until we've been idle for a couple of frames, we drop the
      overhead of runtime PM down to sub-.1%.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      3a622346
    • Eric Anholt's avatar
      drm/vc4: Add support for rendering with ETC1 textures. · 7154d76f
      Eric Anholt authored
      The validation for it ends up being quite simple, but I hadn't got
      around to it before merging the driver.  For backwards compatibility,
      we also need to add a flag so that the userspace GL driver can easily
      tell if the kernel will allow ETC1 textures (on an old kernel, it will
      continue to convert to RGBA8)
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      7154d76f
  24. 02 Nov, 2016 1 commit
  25. 22 Sep, 2016 1 commit
  26. 20 Aug, 2016 1 commit
  27. 12 Aug, 2016 1 commit
  28. 18 Jul, 2016 1 commit
  29. 15 Jul, 2016 1 commit
  30. 14 Jul, 2016 1 commit
    • Eric Anholt's avatar
      drm/vc4: Add a getparam ioctl for getting the V3D identity regs. · af713795
      Eric Anholt authored
      As I extend the driver to support different V3D revisions, userspace
      needs to know what version it's targeting.  This is most easily
      detected using the V3D identity registers.
      
      v2: Make sure V3D is runtime PM on when reading the registers.
      v3: Switch to a 64-bit param value (suggested by Rob Clark in review)
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2)
      Reviewed-by: Rob Clark <robdclark@gmail.com> (v3, over irc)
      af713795
  31. 12 Jul, 2016 3 commits
    • Colin Ian King's avatar
      drm/vc4: remove redundant ret status check · deb4765d
      Colin Ian King authored
      At the current point where ret is being checked for non-zero it has
      not changed since it was initialized to zero, hence the check and the
      label unref are redundant and can be removed.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      deb4765d
    • Mario Kleiner's avatar
      drm/vc4: Implement precise vblank timestamping. · 1bf59f1d
      Mario Kleiner authored
      Precise vblank timestamping is implemented via the
      usual scanout position based method. On VC4 the
      pixelvalves PV do not have a scanout position
      register. Only the hardware video scaler HVS has a
      similar register which describes which scanline for
      the output is currently composited and stored in the
      HVS fifo for later consumption by the PV.
      
      This causes a problem in that the HVS runs at a much
      faster clock (system clock / audio gate) than the PV
      which runs at video mode dot clock, so the unless the
      fifo between HVS and PV is full, the HVS will progress
      faster in its observable read line position than video
      scan rate, so the HVS position reading can't be directly
      translated into a scanout position for timestamp correction.
      
      Additionally when the PV is in vblank, it doesn't consume
      from the fifo, so the fifo gets full very quickly and then
      the HVS stops compositing until the PV enters active scanout
      and starts consuming scanlines from the fifo again, making
      new space for the HVS to composite.
      
      Therefore a simple translation of HVS read position into
      elapsed time since (or to) start of active scanout does
      not work, but for the most interesting cases we can still
      get useful and sufficiently accurate results:
      
      1. The PV enters active scanout of a new frame with the
         fifo of the HVS completely full, and the HVS can refill
         any fifo line which gets consumed and thereby freed up by
         the PV during active scanout very quickly. Therefore the
         PV and HVS work effectively in lock-step during active
         scanout with the fifo never having more than 1 scanline
         freed up by the PV before it gets refilled. The PV's
         real scanout position is therefore trailing the HVS
         compositing position as scanoutpos = hvspos - fifosize
         and we can get the true scanoutpos as HVS readpos minus
         fifo size, so precise timestamping works while in active
         scanout, except for the last few scanlines of the frame,
         when the HVS reaches end of frame, stops compositing and
         the PV catches up and drains the fifo. This special case
         would only introduce minor errors though.
      
      2. If we are in vblank, then we can only guess something
         reasonable. If called from vblank irq, we assume the irq is
         usually dispatched with minimum delay, so we can take a
         timestamp taken at entry into the vblank irq handler as a
         baseline and then add a full vblank duration until the
         guessed start of active scanout. As irq dispatch is usually
         pretty low latency this works with relatively low jitter and
         good results.
      
         If we aren't called from vblank then we could be anywhere
         within the vblank interval, so we return a neutral result,
         simply the current system timestamp, and hope for the best.
      
      Measurement shows the generated timestamps to be rather precise,
      and at least never off more than 1 vblank duration worst-case.
      
      Limitations: Doesn't work well yet for interlaced video modes,
                   therefore disabled in interlaced mode for now.
      
      v2: Use the DISPBASE registers to determine the FIFO size (changes
          by anholt)
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
      1bf59f1d
    • Eric Anholt's avatar
      drm/vc4: Bind the HVS before we bind the individual CRTCs. · 7a100969
      Eric Anholt authored
      We need to be able to look at the CRTC's registers in the HVS as part
      of initialization, while the HVS doesn't need to look at the PV
      registers.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-and-tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      7a100969
  32. 22 Jun, 2016 2 commits
  33. 06 Jun, 2016 1 commit
  34. 31 May, 2016 1 commit