Skip to content
Snippets Groups Projects
  1. Apr 12, 2015
  2. Apr 09, 2015
  3. Apr 08, 2015
  4. Mar 28, 2015
  5. Mar 26, 2015
  6. Mar 25, 2015
    • Marek Olšák's avatar
      radeonsi: increase coords array size for radeon_llvm_emit_prepare_cube_coords · d33bf815
      Marek Olšák authored and Emil Velikov's avatar Emil Velikov committed
      
      radeon_llvm_emit_prepare_cube_coords uses coords[4] in some cases (TXB2 etc.)
      
      Discovered by Coverity. Reported by Ilia Mirkin.
      
      Cc: 10.5 10.4 <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      (cherry picked from commit a984abda)
      d33bf815
    • Mario Kleiner's avatar
      glx: Handle out-of-sequence swap completion events correctly. (v2) · 8ebda1f1
      Mario Kleiner authored and Emil Velikov's avatar Emil Velikov committed
      
      The code for emitting INTEL_swap_events swap completion
      events needs to translate from 32-Bit sbc on the wire to
      64-Bit sbc for the events and handle wraparound accordingly.
      
      It assumed that events would be sent by the server in the
      order their corresponding swap requests were emitted from
      the client, iow. sbc count should be always increasing. This
      was correct for DRI2.
      
      This is not always the case under the DRI3/Present backend,
      where the Present extension can execute presents and send out
      completion events in a different order than the submission
      order of the present requests, due to client code specifying
      targetMSC target vblank counts which are not strictly
      monotonically increasing. This confused the wraparound
      handling. This patch fixes the problem by handling 32-Bit
      wraparound in both directions. As long as successive swap
      completion events real 64-Bit sbc's don't differ by more
      than 2^30, this should be able to do the right thing.
      
      How this is supposed to work:
      
      awire->sbc contains the low 32-Bits of the true 64-Bit sbc
      of the current swap event, transmitted over the wire.
      
      glxDraw->lastEventSbc contains the low 32-Bits of the 64-Bit
      sbc of the most recently processed swap event.
      
      glxDraw->eventSbcWrap is a 64-Bit offset which tracks the upper
      32-Bits of the current sbc. The final 64-Bit output sbc
      aevent->sbc is computed from the sum of awire->sbc and
      glxDraw->eventSbcWrap.
      
      Under DRI3/Present, swap completion events can be received
      slightly out of order due to non-monotic targetMsc specified
      by client code, e.g., present request submission:
      
      Submission sbc:   1   2   3
      targetMsc:        10  11  9
      
      Reception of completion events:
      Completion sbc:   3   1   2
      
      The completion sequence 3, 1, 2 would confuse the old wraparound
      handling made for DRI2 as 1 < 3 --> Assumes a 32-Bit wraparound
      has happened when it hasn't.
      
      The client can queue multiple present requests, in the case of
      Mesa up to n requests for n-buffered rendering, e.g., n =  2-4 in
      the current Mesa GLX DRI3/Present implementation. In the case of
      direct Pixmap presents via xcb_present_pixmap() the number n is
      limited by the amount of memory available.
      
      We reasonably assume that the number of outstanding requests n is
      much less than 2 billion due to memory contraints and common sense.
      Therefore while the order of received sbc's can be a bit scrambled,
      successive 64-Bit sbc's won't deviate by much, a given sbc may be
      a few counts lower or higher than the previous received sbc.
      
      Therefore any large difference between the incoming awire->sbc and
      the last recorded glxDraw->lastEventSbc will be due to 32-Bit
      wraparound and we need to adapt glxDraw->eventSbcWrap accordingly
      to adjust the upper 32-Bits of the sbc.
      
      Two cases, correponding to the two if-statements in the patch:
      
      a) Previous sbc event was below the last 2^32 boundary, in the previous
      glxDraw->eventSbcWrap epoch, the new sbc event is in the next 2^32
      epoch, therefore the low 32-Bit awire->sbc wrapped around to zero,
      or close to zero --> awire->sbc is apparently much lower than the
      glxDraw->lastEventSbc recorded for the previous epoch
      
      --> We need to increment glxDraw->eventSbcWrap by 2^32 to adjust
      the current epoch to be one higher than the previous one.
      
      --> Case a) also handles the old DRI2 behaviour.
      
      b) Previous sbc event was above closest 2^32 boundary, but now a
      late event from the previous 2^32 epoch arrives, with a true sbc
      that belongs to the previous 2^32 segment, so the awire->sbc of
      this late event has a high count close to 2^32, whereas
      glxDraw->lastEventSbc is closer to zero --> awire->sbc is much
      greater than glXDraw->lastEventSbc.
      
      --> We need to decrement glxDraw->eventSbcWrap by 2^32 to adjust
      the current epoch back to the previous lower epoch of this late
      completion event.
      
      We assume such a wraparound to a higher (a) epoch or lower (b)
      epoch has happened if awire->sbc and glxDraw->lastEventSbc differ
      by more than 2^30 counts, as such a difference can only happen
      on wraparound, or if somehow 2^30 present requests would be pending
      for a given drawable inside the server, which is rather unlikely.
      
      v2: Explain the reason for this patch and the new wraparound handling
          much more extensive in commit message, no code change wrt. initial
          version.
      
      Cc: "10.3 10.4 10.5" <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      (cherry picked from commit cc5ddd58)
      8ebda1f1
    • Emil Velikov's avatar
      auxiliary/os: fix the android build - s/drm_munmap/os_munmap/ · 0410d9b1
      Emil Velikov authored
      
      Squash this silly typo introduced with commit c63eb5dd(auxiliary/os: get
      the mmap/munmap wrappers working with android)
      
      Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarEmil Velikov <emil.l.velikov@gmail.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      (cherry picked from commit 55f0c0a2)
      0410d9b1
    • Emil Velikov's avatar
      loader: include <sys/stat.h> for non-sysfs builds · af3e6e28
      Emil Velikov authored
      Required by fstat(), otherwise we'll error out due to implicit function
      declaration.
      
      Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89530
      
      
      Signed-off-by: default avatarEmil Velikov <emil.l.velikov@gmail.com>
      Reported-by: default avatarVadim Rutkovsky <vrutkovs@redhat.com>
      Tested-by: default avatarVadim Rutkovsky <vrutkovs@redhat.com>
      (cherry picked from commit 771cd266)
      af3e6e28
    • Felix Janda's avatar
      c11/threads: Use PTHREAD_MUTEX_RECURSIVE by default · 29810e43
      Felix Janda authored and Emil Velikov's avatar Emil Velikov committed
      Previously PTHREAD_MUTEX_RECURSIVE_NP had been used on linux for
      compatibility with old glibc. Since mesa defines __GNU_SOURCE__
      on linux PTHREAD_MUTEX_RECURSIVE is also available since at least
      1998. So we can unconditionally use the portable version
      PTHREAD_MUTEX_RECURSIVE.
      
      Cc: "10.5" <mesa-stable@lists.freedesktop.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88534
      
      
      Reviewed-by: default avatarEmil Velikov <emil.l.velikov@gmail.com>
      (cherry picked from commit aead7fe2)
      29810e43
    • Rob Clark's avatar
      freedreno: update generated headers · 2e0f2ad5
      Rob Clark authored and Emil Velikov's avatar Emil Velikov committed
      
      Fix a3xx texture layer-size.
      
      Signed-off-by: default avatarRob Clark <robclark@freedesktop.org>
      Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
      (cherry picked from commit e92bc6b3)
      2e0f2ad5
    • Ilia Mirkin's avatar
      freedreno: fix slice pitch calculations · 411f975a
      Ilia Mirkin authored and Emil Velikov's avatar Emil Velikov committed
      
      For example if width were 65, the first slice would get 96 while the
      second would get 32. However the hardware appears to expect the second
      pitch to be 64, based on halving the 96 (and aligning up to 32).
      
      This fixes texelFetch piglit tests on a3xx below a certain size. Going
      higher they break again, but most likely due to unrelated reasons.
      
      Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarRob Clark <robclark@freedesktop.org>
      (cherry picked from commit 620e29b7)
      411f975a
    • Ilia Mirkin's avatar
      freedreno/a3xx: use the same layer size for all slices · 3fa76f3f
      Ilia Mirkin authored and Emil Velikov's avatar Emil Velikov committed
      
      We only program in one layer size per texture, so that means that all
      levels must share one size. This makes the piglit test
      
      bin/texelFetch fs sampler2DArray
      
      have the same breakage as its non-array version instead of being
      completely off, and makes
      
      bin/ext_texture_array-gen-mipmap
      
      start passing.
      
      Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarRob Clark <robclark@freedesktop.org>
      (cherry picked from commit 89b26d5a)
      3fa76f3f
    • Samuel Iglesias Gonsálvez's avatar
      glsl: optimize (0 cmp x + y) into (-x cmp y). · 5e572b1c
      Samuel Iglesias Gonsálvez authored and Emil Velikov's avatar Emil Velikov committed
      
      The optimization done by commit 34ec1a24 did not take it into account.
      
      Fixes:
      
      dEQP-GLES3.functional.shaders.random.all_features.fragment.20
      
      Signed-off-by: default avatarSamuel Iglesias Gonsalvez <siglesias@igalia.com>
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: default avatarMatt Turner <mattst88@gmail.com>
      Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
      (cherry picked from commit b43bbfa9)
      5e572b1c
    • Emil Velikov's avatar
      st/egl: don't ship the dri2.c link at the tarball · 2beab3c0
      Emil Velikov authored
      During 'make dist' the path of the symbolic link (x11/dri2.c) becomes
      too long, and tar converts it to hard one. To make it more complicated
      on Haiku tar errors out (due to lack of hardlink support) rather than
      falling back to the next best thing.
      So remove the symlink from git, and disable the scons x11_drm egl code.
      The offending code is not build with either automake nor android.
      
      Brian, Jose would you have any objections against this ? I was
      playing around to get the symlink resolved, although I could not get the
      dependency tracking resolved, so env.Command() was never executed :-\
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89680
      
      
      Cc: mesa-stable@lists.freedesktop.org
      Cc: Alexander von Gluck IV <kallisti5@unixzen.com>
      Cc: Brian Paul <brianp@vmware.com>
      Acked-by: default avatarJose Fonseca <jfonseca@vmware.com>
      Signed-off-by: default avatarEmil Velikov <emil.l.velikov@gmail.com>
      2beab3c0
Loading