Skip to content

S
swiftshader
Switch branch/tag
  1. 29 Sep, 2020 12 commits
  3. 28 Sep, 2020 2 commits
  5. 24 Sep, 2020 2 commits
  7. 21 Sep, 2020 1 commit
  9. 16 Sep, 2020 1 commit
  11. 15 Sep, 2020 2 commits
  13. 14 Sep, 2020 4 commits
  15. 11 Sep, 2020 1 commit
  17. 10 Sep, 2020 1 commit
  19. 09 Sep, 2020 4 commits
  21. 07 Sep, 2020 1 commit
  23. 04 Sep, 2020 1 commit
  25. 03 Sep, 2020 3 commits
  27. 02 Sep, 2020 2 commits
  29. 01 Sep, 2020 3 commits
    • Fix undefined behavior in minifloat conversion · e1051cba
      Nicolas Capens authored 
      Shifting a 32-bit value by 32 or more is undefined behavior in C++. This
previously happened in this code when converting a 32-bit float value to
an 11- or 10-bit minifloat which is too small to be represented as a
denormal, and should produce 0 instead.

Instead of going through this arithmetic for denormals, just test
whether the input value is too small to produce a valid denormal, and
return 0 instead.

Bug: chromium:1117433
Change-Id: I8149996fb6d66d328db45725c4cdb81dc7826a10
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48069
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
    • Add unit test for 11/10-bit minifloat denormal underflow · 558540fe
      Nicolas Capens authored 
      The reference code for conversion from 32-bit floating-point to 11- and
10-bit minifloat formats supports producing denormals for values smaller
than what can be represented as normalized representations. The
arithmetic can underflow to produce zero for values too small to be
represented as denormals.

This arithmetic contains a 32-bit shift operation which can shift by an
amount greater than 32, which has undefined behavior in C++ but produces
zero on x86 processors.

This change adds unit tests for the intended behavior around the cutoff
between the smallest denormal, and zero, to help validate the fix for
the UB in a future change.

Bug: b/147900455
Bug: chromium:1117433
Change-Id: Ic5e495dd822231d52a5551ee12733a616728d486
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48068Reviewed-by: 's avatarAntonio Maiorano <amaiorano@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
    • Assert multisample resolve has equal input and output formats · 2d5bbdc4
      Nicolas Capens authored 
      While our generic Blitter routine can handle resolving any multisample
format into any other format, the 'fastResolve()' method performs simple
per-component sample averaging, thus assuming the input and output
formats are identical.

This is also demanded by the Vulkan specification:
- vkCmdResolveImage: "srcImage and dstImage must have been created with
  the same image format."
- VkSubpassDescription: "each resolve attachment that is not
  VK_ATTACHMENT_UNUSED must have the same VkFormat as its corresponding
  color attachment."

This change adds an assert which would catch violations of that.

Bug: b/147802090
Change-Id: I23d2d463efbbaed04a782a0cf61b255bf1c25b03
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48088
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>