Skip to content

S
swiftshader
Switch branch/tag
  1. 03 Nov, 2018 1 commit
  3. 02 Nov, 2018 3 commits
  5. 01 Nov, 2018 2 commits
  7. 31 Oct, 2018 4 commits
  9. 30 Oct, 2018 2 commits
    • Fix Vulkan build. · 70942e2e
      Nicolas Capens authored 
      Initialization order mismatch is treated as an error with Clang/GCC:
-Werror=reorder

Bug b/118383648

Change-Id: I4e56aa3c61ce35d70a28dbdd1ab76d7ca8dae833
Reviewed-on: https://swiftshader-review.googlesource.com/c/22068Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
    • Generate an error when trying to clear an incomplete Framebuffer · e83048e2
      Alexis Hetu authored 
      Calling ClearBuffer* on an incomplete framebuffer was crashing
because a depth clear assumes 4 bytes per pixel and the type of
an incomplete framebuffer could be anything, which is potentially
smaller than 4 bytes, so memory was written out of bounds.

ClearBuffer* now also checks for completeness, just like clear
already does.

From the OpenGL ES 3.0 spec, section 4.4.4.4
"Effects of Framebuffer Completeness on Framebuffer Operations

 Attempting to render to or read from a framebuffer which is not
 framebuffer complete will generate an INVALID_FRAMEBUFFER_OPERATION
 error. This means that rendering commands (see section 2.6) ...
 will generate the error INVALID_FRAMEBUFFER_OPERATION if called
 while the framebuffer is not framebuffer complete"

And from the OpenGL ES 3.0 spec, section 2.6 Rendering Commands
"GL commands performing rendering into a framebuffer are called
 rendering commands, and include the drawing commands Draw* ...,
 as well as these additional commands:
• BlitFramebuffer
• Clear
• ClearBuffer*"

Bug b/117048995

Change-Id: I01fd2ad2829b4c9e0aac817620f65c789b11356e
Reviewed-on: https://swiftshader-review.googlesource.com/c/22048Tested-by: 's avatarAlexis Hétu <sugoi@google.com>
Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
  11. 29 Oct, 2018 2 commits
  13. 26 Oct, 2018 4 commits
  15. 25 Oct, 2018 4 commits
  17. 24 Oct, 2018 1 commit
  19. 22 Oct, 2018 2 commits
  21. 19 Oct, 2018 3 commits
  23. 18 Oct, 2018 7 commits
  25. 16 Oct, 2018 3 commits
  27. 15 Oct, 2018 2 commits
    • Vulkan dispatchable objects · 767b41b1
      Alexis Hetu authored 
      Vulkan has a few dispatchable objects: Instance, Device, Physical Device,
Command Buffer and Queue. These objects, when loaded through an ICD, are
constrained to have a bit of memory allocated at the beginning of these
objects to contain loader data.

In order to do this, a wrapper class, DispatchableObject, was created to handle
pointing directly to the loader data when casting to the associated VK handle
and similarly back to a pointer to the internal object. Note that Queue, being
allocated within another object, and not directly through the API, simply have
the loader data at the beginning of the class, without requiring a wrapper class.

Also, since all these object are allocated through a custom placement new
operator, they have to be deallocated through an associated destroy() function,
so the DispatchableObject destructor is deleted, in order to prevent these
objects from being released any other way.

Bug b/116336664

Change-Id: Iac749f6adcba0eaf7557f0df876ac0474081d9cc
Reviewed-on: https://swiftshader-review.googlesource.com/c/20948Tested-by: 's avatarAlexis Hétu <sugoi@google.com>
Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
    • Fix GN build. · 71e256ca
      Nicolas Capens authored 
      Bug b/115344057
Bug chromium:881334

Change-Id: Ib54e43a106c17b4878780382c4a80415e8f3583b
Reviewed-on: https://swiftshader-review.googlesource.com/c/21508Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>