Skip to content

[spirv] Add option to flatten array of resources. - #2397

Merged
Ehsan (ehsannas) merged 6 commits into
microsoft:masterfrom
ehsannas:flatten_texture_array
Aug 14, 2019
Merged

[spirv] Add option to flatten array of resources.#2397
Ehsan (ehsannas) merged 6 commits into
microsoft:masterfrom
ehsannas:flatten_texture_array

Conversation

@ehsannas

Copy link
Copy Markdown
Contributor

No description provided.

@ehsannas Ehsan (ehsannas) added the spirv Work related to SPIR-V label Aug 7, 2019
@ehsannas Ehsan (ehsannas) self-assigned this Aug 7, 2019
@ehsannas Ehsan (ehsannas) changed the title Flatten texture array [spirv] Add option to flatten array of resources. Aug 7, 2019
@AppVeyorBot

Copy link
Copy Markdown

@AppVeyorBot

Copy link
Copy Markdown

@ehsannas

Copy link
Copy Markdown
Contributor Author

The failure is due to the missing spirv-tools update. I'll have to rebase this PR.

Current SPIR-V code generation uses 1 binding number for an array of
resources (e.g. an array of textures). However, the DX side uses one
binding number per array element. The newly added
'-fspv-flatten-resource-arrays' changes the SPIR-V backend behavior to
use one binding number per array element, and uses spirv-opt to flatten
the array.

TODO: Add a test where the array is passed around.
TODO: Test this works with steven's PR and proper results are produced.
@AppVeyorBot

Copy link
Copy Markdown

@jaebaek Jaebaek Seo (jaebaek) left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly LGTM, but two minor issues.
Those issues are just my opinion but it is not critical and I will follow your decision.


// Check whether the chunk of |n| binding numbers can be fitted at the
// very beginning of the list (start at binding 0 in the current set).
if ((*existingBindings.begin()) >= n)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is based on the assumption that std::set::iterator always visits elements in sorted order.
I just quickly checked a discussion and it looks fine, but I am just worried what if it causes a problem in the future (e.g., other stl implementations?).

Maybe putting a comment here about the assumption would be helpful?
I am not 100% sure about this, just I will follow your opinion.

@ehsannas Ehsan (ehsannas) Aug 13, 2019

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the std::set iterator always iterates on a sorted basis. That's why we also have std::unordered_set, which only contains a set of things that are not necessarily sorted.

if (existingBindings.empty())
return 0;

// Check whether the chunk of |n| binding numbers can be fitted at the

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the following code can avoid twice of iter != exisitingBindings.end() and curBinding = *iter, nextBinding = *iter:

    // Check whether the chunk of |n| binding numbers can be fitted at the
    // very beginning of the list (start at binding 0 in the current set).
    uint32_t curBinding = *existingBindings.begin();
    if (curBinding >= n)
      return 0;

    auto iter = std::next(existingBindings.begin());
    while (iter != existingBindings.end()) {
      // There exists a next binding number that is used. Check to see if the
      // gap between current binding number and next binding number is large
      // enough to accommodate |n|.
      uint32_t nextBinding = *iter;
      if (n <= nextBinding - curBinding - 1)
        return curBinding + 1;

      curBinding = nextBinding;

      // Peek at the next binding that has already been used (if any).
      ++iter;
    }

    // |curBinding| was the last binding that was used in this set. The next
    // chunk of |n| bindings can start at |curBinding|+1.
    return curBinding + 1;

Notice that because of if (existingBindings.empty()) return 0; above we can assume that std::next(existingBindings.begin()) is not existingBindings.end().

Please let me know if I misunderstood something.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're right. I'll make the update.

@AppVeyorBot

Copy link
Copy Markdown

@jaebaek Jaebaek Seo (jaebaek) left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ehsannas
Ehsan (ehsannas) merged commit 922ef65 into microsoft:master Aug 14, 2019
@ehsannas
Ehsan (ehsannas) deleted the flatten_texture_array branch August 14, 2019 13:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

spirv Work related to SPIR-V

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants