Add support for getting vulkan descriptor sets without a GrVkUniformHandler.

Add support for getting vulkan descriptor sets without a GrVkUniformHandler.

This change allows us to use the current descriptor set system for doing
copies as draws. This is a step towards being able to track resources for draws
that don't go through out normal pipeline.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275633002

Committed: https://skia.googlesource.com/skia/+/4d866dfc46bc381da1761d05ce8b5a3bb0cd7f00

[egdaniel, 2016-08-23 18:45:24]

Description was changed from

==========
Add support for getting vulkan descriptor sets without a GrVkUniformHandler.

This change allows us to use the current descriptor set system for doing
copies as draws. This is a step towards being able to track resources for draws
that don't go through out normal pipeline.

BUG=skia:
==========

to

==========
Add support for getting vulkan descriptor sets without a GrVkUniformHandler.

This change allows us to use the current descriptor set system for doing
copies as draws. This is a step towards being able to track resources for draws
that don't go through out normal pipeline.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275633002
==========

[egdaniel, 2016-08-23 18:46:19]

egdaniel@google.com changed reviewers:
+ brianosman@google.com, jvanverth@google.com

[jvanverth1, 2016-08-23 20:13:36]

https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
File src/gpu/vk/GrVkDescriptorSetManager.cpp (right):

https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
src/gpu/vk/GrVkDescriptorSetManager.cpp:23:
fBindingVisibilities.push_back(uniformHandler->getSampler(i).visibility());
Any possibility of storing the visibilities as a separate SkTArray in the
uniform handler or would that be too much of a nuisance? Then you'd only need
one constructor that takes an SkTArray.

[egdaniel, 2016-08-23 20:36:31]

On 2016/08/23 20:13:36, jvanverth1 wrote:
>
https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
> File src/gpu/vk/GrVkDescriptorSetManager.cpp (right):
> 
>
https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
> src/gpu/vk/GrVkDescriptorSetManager.cpp:23:
> fBindingVisibilities.push_back(uniformHandler->getSampler(i).visibility());
> Any possibility of storing the visibilities as a separate SkTArray in the
> uniform handler or would that be too much of a nuisance? Then you'd only need
> one constructor that takes an SkTArray.

It would be a pain, unless I store a separate copy of the visibilities.
Currently the UniformHandler basically has an array of GrGLSLShaderVars which in
turn each have a visibility as part of them. So thoughts on redundant data
storage vs. semi-duplicate ctors?

[jvanverth1, 2016-08-23 20:43:07]

lgtm

https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
File src/gpu/vk/GrVkDescriptorSetManager.h (right):

https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
src/gpu/vk/GrVkDescriptorSetManager.h:35: const uint32_t* visibilities,
Suggestion: use a const SkTArray<uint32_t>& rather than a raw pointer and count.

[jvanverth1, 2016-08-23 20:44:02]

On 2016/08/23 20:36:31, egdaniel wrote:
> On 2016/08/23 20:13:36, jvanverth1 wrote:
> >
>
https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
> > File src/gpu/vk/GrVkDescriptorSetManager.cpp (right):
> > 
> >
>
https://codereview.chromium.org/2275633002/diff/1/src/gpu/vk/GrVkDescriptorSe...
> > src/gpu/vk/GrVkDescriptorSetManager.cpp:23:
> > fBindingVisibilities.push_back(uniformHandler->getSampler(i).visibility());
> > Any possibility of storing the visibilities as a separate SkTArray in the
> > uniform handler or would that be too much of a nuisance? Then you'd only
need
> > one constructor that takes an SkTArray.
> 
> It would be a pain, unless I store a separate copy of the visibilities.
> Currently the UniformHandler basically has an array of GrGLSLShaderVars which
in
> turn each have a visibility as part of them. So thoughts on redundant data
> storage vs. semi-duplicate ctors?

I'm okay with semi-duplicate ctors, just thought I'd ask if it's possible.

[egdaniel, 2016-08-25 20:15:04]

The CQ bit was checked by egdaniel@google.com

[egdaniel, 2016-08-25 20:15:04]

The patchset sent to the CQ was uploaded after l-g-t-m from jvanverth@google.com
Link to the patchset: https://codereview.chromium.org/2275633002/#ps20001
(title: " ")

[commit-bot: I haz the power, 2016-08-25 20:15:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-25 20:52:14]

Description was changed from

==========
Add support for getting vulkan descriptor sets without a GrVkUniformHandler.

This change allows us to use the current descriptor set system for doing
copies as draws. This is a step towards being able to track resources for draws
that don't go through out normal pipeline.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275633002
==========

to

==========
Add support for getting vulkan descriptor sets without a GrVkUniformHandler.

This change allows us to use the current descriptor set system for doing
copies as draws. This is a step towards being able to track resources for draws
that don't go through out normal pipeline.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275633002

Committed:
https://skia.googlesource.com/skia/+/4d866dfc46bc381da1761d05ce8b5a3bb0cd7f00
==========

[commit-bot: I haz the power, 2016-08-25 20:52:15]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/4d866dfc46bc381da1761d05ce8b5a3bb0cd7f00