Skip to content
Snippets Groups Projects
  1. Mar 21, 2015
  2. Mar 18, 2015
    • Marek Olšák's avatar
      radeonsi: increase coords array size for radeon_llvm_emit_prepare_cube_coords · 832c94a5
      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)
      832c94a5
    • Mario Kleiner's avatar
      glx: Handle out-of-sequence swap completion events correctly. (v2) · 70832be2
      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)
      70832be2
    • Emil Velikov's avatar
      auxiliary/os: fix the android build - s/drm_munmap/os_munmap/ · ad259df2
      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)
      ad259df2
    • Emil Velikov's avatar
      loader: include <sys/stat.h> for non-sysfs builds · df2db2a5
      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)
      df2db2a5
    • Rob Clark's avatar
      freedreno: update generated headers · 0506f69f
      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)
      [Emil Velikov: sqush trivial conflicts, drop the a4xx.xml.h changes]
      
      Signed-off-by: default avatarEmil Velikov <emil.l.velikov@gmail.com>
      
      Conflicts:
      	src/gallium/drivers/freedreno/a2xx/a2xx.xml.h
      	src/gallium/drivers/freedreno/a3xx/a3xx.xml.h
      	src/gallium/drivers/freedreno/a4xx/a4xx.xml.h
      	src/gallium/drivers/freedreno/adreno_common.xml.h
      	src/gallium/drivers/freedreno/adreno_pm4.xml.h
      0506f69f
    • Ilia Mirkin's avatar
      freedreno: fix slice pitch calculations · a5630450
      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)
      a5630450
    • Samuel Iglesias Gonsálvez's avatar
      glsl: optimize (0 cmp x + y) into (-x cmp y). · b2e243f7
      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)
      b2e243f7
  3. Mar 11, 2015
  4. Mar 07, 2015
  5. Mar 06, 2015
  6. Mar 04, 2015
Loading