Skip to content

S
swiftshader
Switch branch/tag
  1. 30 Apr, 2020 5 commits
  3. 29 Apr, 2020 1 commit
  5. 28 Apr, 2020 5 commits
  7. 27 Apr, 2020 5 commits
    • Record vkCmdBindDescriptorSets() as a single command · 002b7c19
      Nicolas Capens authored 
      Previously we split it up into multiple commands to bind each descriptor
set individually. This required knowing how many dynamic offsets buffers
exist in each set, and some of the work happened at the time of the
command execution.

Now it's just a single simple data copying operation which doesn't need
to know how the dynamic offsets are distributed between the sets.

Bug: b/154522740
Change-Id: I0f094a7f91abc16e6bf971994426c104e8582c00
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44329Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
    • Store binding information in the pipeline layout · 026f7d07
      Nicolas Capens authored 
      Descriptor set layout binding information needed by the pipeline layout
has to persist after the descriptor set layout object has been
destroyed.

The spec states:
"VkDescriptorSetLayout objects may be accessed by commands that operate
on descriptor sets allocated using that layout, and those descriptor
sets must not be updated with vkUpdateDescriptorSets after the
descriptor set layout has been destroyed. Otherwise, a
VkDescriptorSetLayout object passed as a parameter to create another
object is not further accessed by that object after the duration of the
command it is passed into."

Bug: b/154522740
Change-Id: Ia6349383139ae0fceac328a685b06e2ec253a589
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44328
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: 's avatarBen Clayton <bclayton@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
    • Don't expose individual descriptor set layouts to SPIR-V compilation · c7d5ec39
      Nicolas Capens authored 
      Shader compilation requires access to the pipeline layout, but not to
each of its descriptor set layout interfaces. This change ensures that
all information is queried only through the pipeline layout interface.
This facilitates refactoring the pipeline layout object to contain all
this information, instead of depending on the descriptor set layout
objects to remain alive after pipeline layout creation.

The Vulkan spec states that "a VkDescriptorSetLayout object passed as
a parameter to create another object is not further accessed by that
object after the duration of the command it is passed into."

Also consistently use "index" for values that index into an array, and
"offset" for byte offsets. "descriptor" signifies an individual resource
descriptor, while "binding" refers to the descriptor set binding which
is an array (often of just one descriptor). Use "setNumber" and
"bindingNumber" for the 32-bit identifiers used by SPIR-V, to
distinguish them from the actual objects.

Bug: b/154522740
Change-Id: If3f6e56b6769aae6ebbd49109e7dc1e78cf6558c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44188
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarBen Clayton <bclayton@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
    • Fix ordering of descriptor set bindings · ca9de964
      Nicolas Capens authored 
      The Vulkan spec states that for vkCmdBindDescriptorSets():
"If any of the sets being bound include dynamic uniform or storage
buffers, then pDynamicOffsets includes one element for each array
element in each dynamic descriptor type binding in each set. Values are
taken from pDynamicOffsets in an order such that all entries for set N
come before set N+1; within a set, entries are ordered by the binding
numbers in the descriptor set layouts; and within a binding array,
elements are in order."

Using a direct-mapped array of bindings ensures we can easily compute
which descriptor each dynamic offset applies to. This is also supported
by the spec:
"The above layout definition allows the descriptor bindings to be
specified sparsely such that not all binding numbers between 0 and the
maximum binding number need to be specified in the pBindings array.
Bindings that are not specified have a descriptorCount and stageFlags of
zero, and the value of descriptorType is undefined. However, all binding
numbers between 0 and the maximum binding number in the
VkDescriptorSetLayoutCreateInfo::pBindings array may consume memory in
the descriptor set layout even if not all descriptor bindings are used,
though it should not consume additional memory from the descriptor pool.

The maximum binding number specified should be as compact as possible
to avoid wasted memory."

In addition, the spec states that for vkUpdateDescriptorSets():
"If the dstBinding has fewer than descriptorCount array elements
remaining starting from dstArrayElement, then the remainder will be used
to update the subsequent binding - dstBinding+1 starting at array
element zero."

Which also demands that the bindings in the descriptor set are sorted
by binding number.

Bug: b/154241029
Change-Id: Iae550a02bc9fa1132473c6ba4c5840440f970155
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44308
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
    • SpirvShader: Document activeLaneMask() and storesAndAtomicsMask() · 7483e56f
      Ben Clayton authored 
      These had no documentation and it took me a while to figure out what the distinction was between them.

I've also added the currently unused activeStoresAndAtomicsMask() method.
While I'm not keen on adding dead code, the other two methods make reference to the fact this is the method you probably want to use if you are doing something that has side effects.
Given that it's inline, it should have no bloat to the final binary while it is currently unused.

Bug: b/140294254
Change-Id: I0f1517aef86679f277d998f2a3fb301cf657f03a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44369
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
Tested-by: 's avatarBen Clayton <bclayton@google.com>
  9. 24 Apr, 2020 5 commits
  11. 23 Apr, 2020 4 commits
  13. 22 Apr, 2020 12 commits
  15. 21 Apr, 2020 1 commit
  17. 20 Apr, 2020 1 commit
  19. 17 Apr, 2020 1 commit