Skip to content
  1. May 06, 2024
    • Ville Syrjälä's avatar
      intel: Fix some theoretical buffer overflow · ce811e78
      Ville Syrjälä authored
      
      
      Looks to me like the theoretical max the sprintf()s need
      here is about 34+4+9+sizeof(de->d_name) bytes. Let's just
      make that 64+sizeof(de->d_name) for simplicity.
      
      This shuts up the compiler:
      ../src/intel_device.c: In function ‘__intel_open_device__pci’:
      ../src/intel_device.c:387:60: warning: ‘%s’ directive writing up to 255 bytes into a region of size 247 [-Wformat-overflow=]
        387 |                         sprintf(path + base + 4, "/dev/dri/%s", de->d_name);
            |                                                            ^~
      ../src/intel_device.c:387:25: note: ‘sprintf’ output between 10 and 265 bytes into a destination of size 256
        387 |                         sprintf(path + base + 4, "/dev/dri/%s", de->d_name);
            |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ../src/intel_device.c:392:54: warning: ‘/dev’ directive writing 4 bytes into a region of size between 0 and 255 [-Wformat-overflow=]
        392 |                         sprintf(path + base + 3, "/%s/dev", de->d_name);
            |                                                      ^~~~
      ../src/intel_device.c:392:25: note: ‘sprintf’ output between 6 and 261 bytes into a destination of size 256
        392 |                         sprintf(path + base + 3, "/%s/dev", de->d_name);
            |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      ce811e78
    • Ville Syrjälä's avatar
      sna/gen3: Silence compiler warn · 48b093ba
      Ville Syrjälä authored
      
      
      ../src/sna/kgem_debug_gen3.c:1289:50: warning: ‘%03d’ directive writing between 3 and 10 bytes into a region of size 8 [-Wformat-overflow=]
       1289 |                         sprintf(instr_prefix, "PS%03d", instr);
            |                                                  ^~~~
      ../src/sna/kgem_debug_gen3.c:1289:47: note: directive argument in the range [0, 1431655764]
       1289 |                         sprintf(instr_prefix, "PS%03d", instr);
            |                                               ^~~~~~~~
      ../src/sna/kgem_debug_gen3.c:1289:25: note: ‘sprintf’ output between 6 and 13 bytes into a destination of size 10
       1289 |                         sprintf(instr_prefix, "PS%03d", instr);
            |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      The compiler is utterly wrong here of course since 'instr'
      will at most be (0x1ff + 2 - 1) / 3 ~= 170 (though the hardware
      defined max is actually only 123). But let's bump the buffer
      size a little bit to shut the compiler up.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      48b093ba
    • Ville Syrjälä's avatar
      sna/gen3: Fix 3DSTATE_PIXEL_SHADER_PROGRAM debugs · 003bca92
      Ville Syrjälä authored
      
      
      3DSTATE_PIXEL_SHADER_PROGRAM instruction length is
      9 bits, not 8 bits.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      003bca92
    • Ville Syrjälä's avatar
      sna/gen2: Silence compiler warn · ea0b9aa5
      Ville Syrjälä authored
      
      
      ../src/sna/kgem_debug_gen2.c:625:5: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]
        625 |     const static struct {
            |     ^~~~~
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      ea0b9aa5
    • Ville Syrjälä's avatar
      sna: Switch debugs/errors to use crtc index rather than pipe · 0750dd02
      Ville Syrjälä authored
      
      
      Let's the limit the use of hardware pipe numbers to absolutely
      the only place where it's needed (MI_SCANLINE_WAIT). Everywhere
      else just use the crtc index.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      0750dd02
    • Ville Syrjälä's avatar
      sna/video: Use crtc index instead of pipe · 8c67db87
      Ville Syrjälä authored
      
      
      For consistency with most other code use the kms crtc index
      instead of the hardware pipe number where either will do.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      8c67db87
    • Ville Syrjälä's avatar
      sna: Switch to using crtc index instead of pipe · 86ba5af8
      Ville Syrjälä authored
      
      
      Start using the kms crtc index rather than the pipe almost
      everywhere. The two numbers could in theory be different
      if the hardware has some pipes fused off. Though I think
      such non-contiguous fusing won't actually happen on the
      hardware generations the driver fully supports.
      
      The places where we must use the kms crtc indexes are
      eg. vblank ioctl crtc selection bits, and checks
      against in encoder possible_crtcs bitmask.
      
      The only place where we must stick to the hardware pipe
      indexing is the MI_SCANLINE_WAIT stuff as there we have to
      construct CS packets to be consumed by the hardware itself.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      86ba5af8
    • Ville Syrjälä's avatar
      uxa: Switch to using crtc index instead of pipe · fdf78aea
      Ville Syrjälä authored
      
      
      Start using the kms crtc index rather than the pipe almost
      everywhere. The two numbers could in theory be different
      if the hardware has some pipes fused off. Though I think
      such non-contiguous fusing won't actually happen on the
      hardware generations the driver fully supports.
      
      The places where using the kms crtc index is the correct
      choice have to do with the vblank ioctl crtc selection.
      
      The only place where we must stick to the hardware pipe
      indexing is the MI_SCANLINE_WAIT stuff as there we have to
      construct CS packets to be consumed by the hardware itself.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      fdf78aea
  2. Feb 01, 2023
    • Ville Syrjälä's avatar
      sna: Shut up enum warns · b74b67f0
      Ville Syrjälä authored
      
      
      The libdrm enum usage is a mess, and modern gcc is unhappy about
      the implicit conversions:
      ../src/sna/sna_present.c:229:26: warning: implicit conversion from ‘enum <anonymous>’ to ‘enum drm_vblank_seq_type’ [-Wenum-conversion]
      
      Just cast to an integer type to silence the warns.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      b74b67f0
    • Ville Syrjälä's avatar
      sna: Don't redefine NV12 stuff if already defined · 1b69012e
      Ville Syrjälä authored
      
      
      Modern server headers already define NV12 for us. Avoid the
      redefine.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      1b69012e
    • Ville Syrjälä's avatar
      sna: Eliminate sna_mode_wants_tear_free() · 9aee418d
      Ville Syrjälä authored
      
      
      The modparam checks performed by sna_mode_wants_tear_free() don't
      generally work when the server is running as a regular user. Hence
      we can't rely on them to indicate whether FBC/PSR/etc is enabled.
      Also the "Panel Self-Refresh" connector property doesn't actually
      exist so we can nuke that part as well. Let's just nuke the whole
      thing and assume we want dirtyfb always when tearfree is not enabled.
      
      I'll anyway want to enable FBC by default across the board soonish
      so the check wouldn't really buy us much (would just exclude i830
      and a few old desktop chipsets which don't have FBC hardware).
      
      Additionally if we don't have working dirtyfb we really should
      enable tearfree by default because otherwise we're going to
      get horrible lag due to missing frontbuffer flushes.
      
      Without WC mmaps we could in theory rely on the hw gtt tracking
      except the kernel no longer differentiates between GTT/WC/CPU
      access in its software frontbuffer tracking code so it'll just
      deactivate FBC even for a GTT mmap and potentially never re-enable
      it due to the missing frontbuffer flush from dirtyfb. So dirtyfb
      is always needed.
      
      v2: Rebase due to ppgtt->tear free logic
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      9aee418d
    • Ville Syrjälä's avatar
      sna: Dump fences also on -ENOBUFS · 2a0d4fb1
      Ville Syrjälä authored
      
      
      Since kernel commit 78d2ad7eb4e1 ("drm/i915/gt: Fix
      -EDEADLK handling regression") running out of fences
      will result in -ENOBUFS instead of -EDEADLK (the latter
      having been stolen by ww mutextes for their internal use).
      Adjust the fence dumping to expect either errno value.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      2a0d4fb1
    • Ville Syrjälä's avatar
      sna: Don't emit sse2 code where not wanted · f2c27113
      Ville Syrjälä authored
      
      
      Fix the s/push_options/pop_options/ pragma so that we don't
      emit sse2 in the codepaths that run on non-sse2 machines as well.
      Seems gcc has become much more aggressive in its sse2 usage
      recently and I'm now hitting sse2 instructions in
      choose_memcpy_tiled_x() on my non-sse2 P3 machine.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      f2c27113
    • Ville Syrjälä's avatar
      sna: Allow DRI3 on gen2/3 · 2b552ed7
      Ville Syrjälä authored
      Once we have DRI3 in Mesa i915 driver we can allow DRI3
      on gen2/3.
      
      But due to the supposed missing DRI2 fallback with older Mesa
      let's only do that if the user explicitly requests it. Note
      that when I tried this with modern Mesa that lacks i915 DRI3
      support things seemed to fall back to DRI2 just fine, but
      better safe than sorry I guess.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      References: mesa/mesa!9734
      
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      2b552ed7
    • Ville Syrjälä's avatar
      sna: Fix async flips · c1499471
      Ville Syrjälä authored
      
      
      We need to wait for flip events even when doing async flips,
      otherwise the kernel will just hand us -EBUSY if we try to
      flip too fast.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      c1499471
  3. Jan 15, 2021
  4. Jan 10, 2021
  5. Dec 15, 2020
  6. Nov 26, 2020
    • Chris Wilson's avatar
      sna: Defer fbGetWindowPixmap() for sna_composite · 9236c582
      Chris Wilson authored
      Mike Lothian ran into a surprising situation where compScreenUpdate was
      calling CompositePicture without a pixmap attached to the destination
      Window, and so we found ourselves chasing a NULL PixmapPtr.
      
        #1  to_sna_from_pixmap (pixmap=0x0) at sna.h:521
        #2  sna_composite (op=<optimized out>, src=0x55b3346c1420, mask=0x0,
            dst=0x55b3346c1d50, src_x=<optimized out>, src_y=<optimized out>, mask_x=0,
            mask_y=0, dst_x=0, dst_y=0, width=3840, height=2160) at sna_composite.c:652
        #3  0x000055b33202c208 in damageComposite (op=<optimized out>,
            pSrc=0x55b3346c1420, pMask=0x0, pDst=0x55b3346c1d50, xSrc=<optimized out>,
            ySrc=<optimized out>, xMask=0, yMask=0, xDst=0, yDst=0, width=3840,
            height=2160) at damage.c:513
        #4  0x000055b33201820c in CompositePicture (op=<optimized out>,
            op@entry=1 '\001', pSrc=pSrc@entry=0x55b3346c1420, pMask=pMask@entry=0x0,
            pDst=pDst@entry=0x55b3346c1d50, xSrc=xSrc@entry=0, ySrc=ySrc@entry=0,
            xMask=0, yMask=0, xDst=0, yDst=0, width=3840, height=2160) at picture.c:1547
        #5  0x000055b331fc85d3 in compWindowUpdateAutomatic (
            pWin=pWin@entry=0x55b3343a6bc0) at compwindow.c:705
        #6  0x000055b331fca029 in compPaintWindowToParent (pWin=pWin@entry=0x55b3343a6bc0)
            at compwindow.c:729
        #7  0x000055b331fc9fbb in compPaintChildrenToWindow (pWin=0x55b333e77b50)
            at compwindow.c:744
        #8  0x000055b331fca59f in compScreenUpdate (pClient=<optimized out>,
            closure=<optimized out>) at compalloc.c:57
        #9  0x000055b331f3abf4 in ProcessWorkQueue () at dixutils.c:536
        #10 0x000055b3320aaa51 in WaitForSomething (are_ready=<optimized out>)
            at WaitFor.c:192
        #11 0x000055b331f361a9 in Dispatch () at dispatch.c:421
        #12 0x000055b331f39cec in dix_main (argc=13, argv=0x7ffcf273f538,
            envp=<optimized out>) at main.c:276
        #13 0x000055b331f247de in main (argc=<optimized out>, argv=<optimized out>,
            envp=<optimized out>) at stubmain.c:34
      
      Fortuitously, that drawable was also fully clipped so that it took an
      early exit and so we can hide the segfault by delaying querying the
      pixmap until after the clip check.
      
      The ongoing mystery is how we ended up in that state in the first place.
      
      Closes: #204
      
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      9236c582
  7. Nov 16, 2020
  8. Aug 20, 2020
  9. May 15, 2020
  10. May 11, 2020
  11. May 06, 2020
    • Chris Wilson's avatar
      sna/dri2: Prevent copying stale buffers · e781d43d
      Chris Wilson authored
      The back buffer of window/pixmap is invalidated by DRI2ScheduleSwap, and
      is not available until the client calls DRI2GetBuffers. If they try to
      use their old handles, they will only get stale data. Similarly if they
      ask us to DRI2CopyRegion before the GetBuffers has reallocated a new
      back buffer, that back buffer is stale. Since the back buffer is
      out-of-date [likely containing data from a couple of swaps ago], we
      should ignore the copy to avoid glitching [by hopefully having a less
      noticeable glitch!] It's not entirely clear what the client intended at
      this point...
      
      Closes: #195
      
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      e781d43d
  12. Apr 21, 2020
  13. Apr 17, 2020
  14. Apr 15, 2020
    • Chris Wilson's avatar
      sna/dri2: Interpret DRI2ATTACH_FORMAT as depth not bpp · f2a54e25
      Chris Wilson authored
      
      
      In mesa i915/i965 pass the bpp to use when creating the surface, but the
      gallium state tracker passed the depth. As it happens that
      BitsPerPixel(format) will do the right thing for both, use that.
      
      | DRI2ATTACH_FORMAT { attachment: CARD32
      |		      format:     CARD32 }
      |
      |  The DRI2ATTACH_FORMAT describes an attachment and the associated
      |  format.  'attachment' describes the attachment point for the buffer,
      |  'format' describes an opaque, device-dependent format for the buffer.
      
      Should we need to use an explicit format (heavens forbid as nobody likes
      DRI2) then that will have to start in the range above 256 (or higher).
      
      For now the convention is defined by the mixture of i965/iris, and that
      is to assume it is essentially a depth.
      
      Reported-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      References: mesa/mesa!4569
      
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      f2a54e25
  15. Mar 10, 2020
  16. Dec 09, 2019
  17. Nov 27, 2019
  18. Nov 17, 2019
  19. Nov 15, 2019
  20. Nov 02, 2019
  21. Oct 07, 2019
  22. Sep 27, 2019
Loading