1. 20 Aug, 2012 1 commit
  2. 19 Aug, 2012 1 commit
  3. 16 Aug, 2012 1 commit
  4. 13 Aug, 2012 2 commits
    • Mans Rullgard's avatar
      x86: swscale: fix fragile memory accesses · 90540c2d
      Mans Rullgard authored
      To access data at multiple fixed offsets from a base address, this
      code uses a single "m" operand and code of the form "32%0", relying on
      the memory operand instantiation having no displacement, giving a final
      result of the form "32(%rax)".  If the compiler uses a register and
      displacement, e.g. "64(%rax)", the end result becomes "3264(%rax)",
      which obviously does not work.
      
      Replacing the "m" operands with "r" operands allows safe addition of a
      displacement.  In theory, multiple memory operands could use a shared
      base register with different index registers, "(%rax,%rbx)", potentially
      making more efficient use of registers.  In the cases at hand, no such
      sharing is possible since the addresses involved are entirely unrelated.
      
      After this change, the code somewhat rudely accesses memory without
      using a corresponding memory operand, which in some cases can lead to
      unwanted "optimisations" of surrounding code.  However, the original
      code also accesses memory not covered by a memory operand, so this is
      not adding any defect not already present.  It is also hightly unlikely
      that any such optimisations could be performed here since the memory
      locations in questions are not accessed elsewhere in the same functions.
      
      This fixes crashes with suncc.
      Signed-off-by: 's avatarMans Rullgard <mans@mansr.com>
      90540c2d
    • Mans Rullgard's avatar
      x86: swscale: remove disabled code · 10b83cb6
      Mans Rullgard authored
      This code has been disabled since 2003.  Nobody will ever look at
      it again.
      Signed-off-by: 's avatarMans Rullgard <mans@mansr.com>
      10b83cb6
  5. 08 Aug, 2012 1 commit
  6. 03 Aug, 2012 1 commit
    • Diego Biurrun's avatar
      x86: build: replace mmx2 by mmxext · 239fdf1b
      Diego Biurrun authored
      Refactoring mmx2/mmxext YASM code with cpuflags will force renames.
      So switching to a consistent naming scheme beforehand is sensible.
      The name "mmxext" is more official and widespread and also the name
      of the CPU flag, as reported e.g. by the Linux kernel.
      239fdf1b
  7. 22 Jul, 2012 2 commits
  8. 21 Jul, 2012 1 commit
  9. 05 Jul, 2012 2 commits
  10. 04 Jul, 2012 2 commits
  11. 05 Jun, 2012 1 commit
  12. 12 Apr, 2012 1 commit
  13. 11 Apr, 2012 1 commit
  14. 15 Mar, 2012 2 commits
  15. 06 Mar, 2012 1 commit
  16. 04 Mar, 2012 2 commits
  17. 23 Feb, 2012 1 commit
  18. 19 Feb, 2012 1 commit
    • Ronald S. Bultje's avatar
      Revert two swscale commits. · b18f8cbf
      Ronald S. Bultje authored
      Revert "swscale: update context offsets after removal of AlpMmxFilter."
      (commit a95e3fa9)
      and
      Revert "swscale: Remove some write-only variables related to alpha handling."
      (commit 9d03cb9f).
      
      They broke alpha handling - it's the evil inline asm that still uses that
      variable, so it's not truely write-only.
      b18f8cbf
  19. 17 Feb, 2012 2 commits
  20. 14 Feb, 2012 3 commits
  21. 13 Feb, 2012 1 commit
    • Ronald S. Bultje's avatar
      swscale: fix crashes in yuv2yuvX on x86-32. · 771bab7f
      Ronald S. Bultje authored
      They were introduced in an earlier commit that introduced use of named
      arguments. One cause was a typo, a second cause appears to be a bug in
      x264asm that I work around by not using named arguments.
      771bab7f
  22. 12 Feb, 2012 3 commits
  23. 08 Feb, 2012 1 commit
  24. 07 Feb, 2012 2 commits
  25. 02 Feb, 2012 2 commits
  26. 01 Feb, 2012 2 commits