1. 03 Dec, 2018 29 commits
  2. 01 Dec, 2018 5 commits
  3. 30 Nov, 2018 3 commits
  4. 29 Nov, 2018 3 commits
    • Lionel Landwerlin's avatar
      anv: flush pipeline before query result copies · 37f9788e
      Lionel Landwerlin authored
      Pipeline state pending bits should be taken into account when copying
      results.
      
      In the particular bug below, the results of the
      vkCmdCopyQueryPoolResults() command was being overwritten by the
      preceding vkCmdCopyBuffer() with a same destination buffer. This is
      because we copy the buffers using the 3D pipeline whereas we copy the
      query results using the command streamer. Those pieces of HW work in
      parallel and the results are somewhat undefined.
      
      v2: Unconditionally flush the pipeline before copying the results
          (Jason)
      
      v3: Wrap & expressions (Jason)
      Signed-off-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Suggested-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108894
      Cc: mesa-stable@lists.freedesktop.org
      37f9788e
    • Marek Olšák's avatar
      Revert "winsys/amdgpu: overallocate buffers for faster address translation on Gfx9" · 39b20b7d
      Marek Olšák authored
      I didn't mean to push this. I don't think it makes any difference.
      
      This reverts commit f737fe00.
      39b20b7d
    • Roland Scheidegger's avatar
      draw: fix infinite loop in line stippling · fbf95ce0
      Roland Scheidegger authored
      The calculated length of a line may be infinite, if the coords we
      get are bogus. This leads to an infinite loop in line stippling.
      To prevent this test for this explicitly (although technically
      on at least x86 sse it would actually work without the explicit
      test, as long as we use the int-converted length value).
      While here also get rid of some always-true condition.
      
      Note this does not actually solve the root cause, which is that
      the coords we receive are bogus after clipping. This seems a difficult
      problem to solve. One issue is that due to float arithmetic, clip w
      may become 0 after clipping if the incoming geometry is
      "sufficiently degenerate", hence x/y/z ndc (and window) coords will
      be all inf (or nan). Even with w not quite 0, I believe it's possible
      we produce values which are actually outside the view volume.
      (Also, x=y=z=w=0 coords in clipspace would be not considered subject
      to clipping, and similarly result in all NaN coords.) We just hope for
      now other draw stages (and rasterizers) can handle those relatively
      safely (llvmpipe itself should be sort of robust against this, certainly
      converstion to fixed point will produce garbage, it might fail a couple
      assertions but should neither hang nor crash otherwise).
      Reviewed-by: Jose Fonseca's avatarJose Fonseca <jfonseca@vmware.com>
      fbf95ce0