Skip to content
Snippets Groups Projects
  1. Jan 12, 2015
  2. Jan 07, 2015
  3. Jan 06, 2015
  4. Jan 04, 2015
    • Lina Versace's avatar
      i965: Use safer pointer arithmetic in gather_oa_results() · 9fbacc19
      Lina Versace authored and Emil Velikov's avatar Emil Velikov committed
      
      This patch reduces the likelihood of pointer arithmetic overflow bugs in
      gather_oa_results(), like the one fixed by b69c7c5d.
      
      I haven't yet encountered any overflow bugs in the wild along this
      patch's codepath. But I get nervous when I see code patterns like this:
      
         (void*) + (int) * (int)
      
      I smell 32-bit overflow all over this code.
      
      This patch retypes 'snapshot_size' to 'ptrdiff_t', which should fix any
      potential overflow.
      
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Signed-off-by: default avatarChad Versace <chad.versace@linux.intel.com>
      (cherry picked from commit 414be86c)
      9fbacc19
    • Lina Versace's avatar
      i965: Use safer pointer arithmetic in intel_texsubimage_tiled_memcpy() · 71cd8f13
      Lina Versace authored and Emil Velikov's avatar Emil Velikov committed
      
      This patch reduces the likelihood of pointer arithmetic overflow bugs in
      intel_texsubimage_tiled_memcpy() , like the one fixed by b69c7c5d.
      
      I haven't yet encountered any overflow bugs in the wild along this
      patch's codepath. But I recently solved, in commit b69c7c5d, an overflow
      bug in a line of code that looks very similar to pointer arithmetic in
      this function.
      
      This patch conceptually applies the same fix as in b69c7c5d. Instead
      of retyping the variables, though, this patch adds some casts. (I tried
      to retype the variables as ptrdiff_t, but it quickly got very messy. The
      casts are cleaner).
      
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Signed-off-by: default avatarChad Versace <chad.versace@linux.intel.com>
      (cherry picked from commit 225a0979)
      71cd8f13
    • Marek Olšák's avatar
      glsl_to_tgsi: fix a bug in copy propagation · 87017f21
      Marek Olšák authored and Emil Velikov's avatar Emil Velikov committed
      
      This fixes the new piglit test: arb_uniform_buffer_object/2-buffers-bug
      
      Cc: 10.2 10.3 10.4 <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      (cherry picked from commit 48094d0e)
      87017f21
    • Kenneth Graunke's avatar
      i965: Fix start/base_vertex_location for >1 prims but !BRW_NEW_VERTICES. · 8f22574e
      Kenneth Graunke authored and Emil Velikov's avatar Emil Velikov committed
      This is a partial revert of c8930698.
      It split the {start,base}_vertex_location handling into several steps:
      
      1. Set brw->draw.start_vertex_location = prim[i].start
         and brw->draw.base_vertex_location = prim[i].basevertex.
         (This happened once per _mesa_prim, in the main drawing loop.)
      2. Add brw->vb.start_vertex_bias and brw->ib.start_vertex_offset
         appropriately.  (This happened in brw_prepare_shader_draw_parameters,
         which was called just after brw_prepare_vertices, as part of state
         upload, and only happened when BRW_NEW_VERTICES was flagged.)
      3. Use those values when emitting 3DPRIMITIVE (once per _mesa_prim).
      
      If we drew multiple _mesa_prims, but didn't flag BRW_NEW_VERTICES on
      the second (or later) primitives, we would do step #1, but not #2.
      The first _mesa_prim would get correct values, but subsequent ones
      would only get the first half of the summation.
      
      The reason I originally did this was because I needed the value of
      gl_BaseVertexARB to exist in a buffer object prior to uploading
      3DSTATE_VERTEX_BUFFERS.  I believed I wanted to upload the value
      of 3DPRIMITIVE's "Base Vertex Location" field, which was computed
      as: (prims[i].indexed ? prims[i].start : prims[i].basevertex) +
      brw->vb.start_vertex_bias.  The latter value wasn't available until
      after brw_prepare_vertices, and the former weren't available in the
      state upload code at all.  Hence the awkward split.
      
      However, I believe that including brw->vb.start_vertex_bias was a
      mistake.  It's an extra bias we apply when uploading vertex data into
      VBOs, to move [min_index, max_index] to [0, max_index - min_index].
      
      >From the GL_ARB_shader_draw_parameters specification:
      "<gl_BaseVertexARB> holds the integer value passed to the <baseVertex>
       parameter to the command that resulted in the current shader
       invocation.  In the case where the command has no <baseVertex>
       parameter, the value of <gl_BaseVertexARB> is zero."
      
      I conclude that gl_BaseVertexARB should only include the baseVertex
      parameter from glDraw*Elements*, not any internal biases we add for
      optimization purposes.
      
      With that in mind, gl_BaseVertexARB only needs prim[i].start or
      prim[i].basevertex.  We can simply store that, and go back to computing
      start_vertex_location and base_vertex_location in brw_emit_prim(), like
      we used to.  This is much simpler, and should actually fix two bugs.
      
      Fixes missing geometry in Unvanquished.
      
      Cc: "10.4 10.3" <mesa-stable@lists.freedesktop.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85529
      
      
      Signed-off-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Acked-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: default avatarChris Forbes <chrisf@ijw.co.nz>
      (cherry picked from commit c633528c)
      8f22574e
    • Ilia Mirkin's avatar
      nv50,nvc0: set vertex id base to index_bias · 3bcde5a9
      Ilia Mirkin authored and Emil Velikov's avatar Emil Velikov committed
      
      Fixes the piglits which check that gl_VertexID includes the base vertex
      offset:
        arb_draw_indirect-vertexid elements
        gl-3.2-basevertex-vertexid
      
      Note that this leaves out the original G80, for which this will continue
      to fail. It could be fixed by passing a driver constbuf value in, but
      that's beyond the scope of this change.
      
      Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
      (cherry picked from commit be0311c9)
      3bcde5a9
    • Michel Dänzer's avatar
      radeonsi: Don't modify PA_SC_RASTER_CONFIG register value if rb_mask == 0 · 6ecffc89
      Michel Dänzer authored and Emil Velikov's avatar Emil Velikov committed
      
      E.g. this could happen on older kernels which don't support the
      RADEON_INFO_SI_BACKEND_ENABLED_MASK query yet. The code in
      si_write_harvested_raster_configs() doesn't deal with this correctly and
      would probably mangle the value badly.
      
      Cc: "10.4 10.3" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      Reviewed-by: default avatarTom Stellard <thomas.stellard@amd.com>
      (cherry picked from commit b3057f80)
      6ecffc89
    • Kenneth Graunke's avatar
      i965: Add missing BRW_NEW_*_PROG_DATA to texture/renderbuffer atoms. · 4b1332db
      Kenneth Graunke authored and Emil Velikov's avatar Emil Velikov committed
      This was probably missed when moving from a fixed binding table layout
      to a dynamic one that changes based on the shader.
      
      Fixes newly proposed Piglit test fbo-mrt-new-bind.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87619
      
      
      Signed-off-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: default avatarChris Forbes <chrisf@ijw.co.nz>
      Reviewed-by: default avatarMike Stroyan <mike@LunarG.com>
      Cc: "10.4 10.3" <mesa-stable@lists.freedesktop.org>
      (cherry picked from commit 4616b2ef)
      4b1332db
  5. Dec 30, 2014
  6. Dec 21, 2014
  7. Dec 14, 2014
    • Mario Kleiner's avatar
      glx/dri3: Don't fail on glXSwapBuffersMscOML(dpy, window, 0, 0, 0) (v2) · da8cde2f
      Mario Kleiner authored and Emil Velikov's avatar Emil Velikov committed
      
      glXSwapBuffersMscOML() with target_msc=divisor=remainder=0 gets
      translated into target_msc=divisor=0 but remainder=1 by the mesa
      api. This is done for server DRI2 where there needs to be a way
      to tell the server-side DRI2ScheduleSwap implementation if a call
      to glXSwapBuffers() or glXSwapBuffersMscOML(dpy,window,0,0,0) was
      done. remainder = 1 was (ab)used as a flag to tell the server to
      select proper semantic. The DRI3/Present backend ignored this
      signalling, treated any target_msc=0 as glXSwapBuffers() request,
      and called xcb_present_pixmap with invalid divisor=0, remainder=1
      combo. The present extension responded kindly to this with a
      BadValue error and dropped the request, but mesa's DRI3/Present
      backend doesn't check for error codes. From there on stuff went
      downhill quickly for the calling OpenGL client...
      
      This patch fixes the problem.
      
      v2: Change comments to be more clear, with reference to
      relevant spec, as suggested by Eric Anholt.
      
      Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarAxel Davy <axel.davy@ens.fr>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      (cherry picked from commit 0d7f4c86)
      da8cde2f
    • Mario Kleiner's avatar
      glx/dri3: Request non-vsynced Present for swapinterval zero. (v3) · d332e504
      Mario Kleiner authored and Emil Velikov's avatar Emil Velikov committed
      
      Restores proper immediate tearing swap behaviour for
      OpenGL bufferswap under DRI3/Present.
      
      Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
      
      v2: Add Frank Binns signed off by for his original earlier
      patch from April 2014, which is identical to this one, and
      Chris Wilsons reviewed tag from May 2014 for that patch, ergo
      also for this one.
      
      v3: Incorporate comment about triple buffering as suggested
      by Axel Davy, and reference to relevant spec provided by
      Eric Anholt.
      
      Signed-off-by: default avatarFrank Binns <frank.binns@imgtec.com>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarAxel Davy <axel.davy@ens.fr>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      (cherry picked from commit 455d3036)
      d332e504
    • Mario Kleiner's avatar
      glx/dri3: Track separate (ust, msc) for PresentPixmap vs. PresentNotifyMsc (v2) · 0af41bea
      Mario Kleiner authored and Emil Velikov's avatar Emil Velikov committed
      
      Prevent calls to glXGetSyncValuesOML() and glXWaitForMscOML()
      from overwriting the (ust,msc) values of the last successfull
      swapbuffers call (PresentPixmapCompleteNotify event), as
      glXWaitForSbcOML() relies on those values corresponding to
      the most recent completed swap, not to whatever was last
      returned from the server.
      
      Problematic call sequence without this patch would have been, e.g.,
      
      glXSwapBuffers()
      ... wait ...
      swap completes -> PresentPixmapComplete event -> (ust,msc)
      updated to reflect swap completion time and count.
      ... wait for at least 1 video refresh cycle/vblank increment.
      
      glXGetSyncValuesOML()
      -> PresentNotifyMsc event overwrites (ust,msc) of swap
      completion with (ust,msc) of most recent vblank
      
      glXWaitForSbcOML()
      -> Returns sbc of last completed swap but (ust,msc) of last
      completed vblank, not of last completed swap.
      -> Client is confused.
      
      Do this by tracking a separate set of (ust, msc) for the
      dri3_wait_for_msc() call than for the dri3_wait_for_sbc()
      call.
      
      This makes the glXWaitForSbcOML() call robust again and restores
      consistent behaviour with the DRI2 implementation.
      
      Fixes applications originally written and tested against
      DRI2 which also rely on this not regressing under DRI3/Present,
      e.g., Neuro-Science software like Psychtoolbox-3.
      
      This patch fixes the problem.
      
      v2: Rename vblank_msc/ust to notify_msc/ust as suggested by
      Axel Davy for better clarity.
      
      Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarAxel Davy <axel.davy@ens.fr>
      (cherry picked from commit ad8b0e8b)
      
      Conflicts:
      	src/glx/dri3_glx.c
      0af41bea
    • Mario Kleiner's avatar
      glx/dri3: Fix glXWaitForSbcOML() to handle targetSBC==0 correctly. (v2) · c085fcd2
      Mario Kleiner authored and Emil Velikov's avatar Emil Velikov committed
      
      targetSBC == 0 is a special case, which asks the function
      to block until all pending OpenGL bufferswap requests have
      completed.
      
      Currently the function just falls through for targetSBC == 0,
      returning bogus results.
      
      This breaks applications originally written and tested against
      DRI2 which also rely on this not regressing under DRI3/Present,
      e.g., Neuro-Science software like Psychtoolbox-3.
      
      This patch fixes the problem.
      
      v2: Simplify as suggested by Axel Davy. Add comments proposed
      by Eric Anholt.
      
      Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarAxel Davy <axel.davy@ens.fr>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      (cherry picked from commit 8cab54de)
      c085fcd2
  8. Dec 11, 2014
  9. Dec 05, 2014
  10. Dec 03, 2014
  11. Nov 28, 2014
Loading