The main goal of this refactorization is to allow Vulkan to use separate
sampler and texture objects in the shader and descriptor sets and combine
them into a sampler2d in the shader where needed.
A large part of this is separating how we store samplers and uniforms in the
UniformHandler. We no longer need to store handles to samplers besides when
we are initially emitting code. After we emit code all we ever do is loop over
all samplers and do some processor independent work on them, so we have no need
for direct access to individual samplers.
In the GLProgram all we ever do is set the sampler uniforms in the ctor and never
touch them again, so no need to save sampler info there. The texture access on
program reuse just assume that they come in the same order as we set the texture
units for the samplers
For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers,
then when we get new textures, we just assume they come in in the same order as we
set the samplers on the descriptor sets. Thus no need to save direct vulkan info.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004
Committed: https://skia.googlesource.com/skia/+/45b61a1c4c0be896e7b12fd1405abfece799114f
Review URL: https://codereview.chromium.org/1885863004
Reason for revert:
breaking bots
Original issue's description:
> Refactor how we store and use samplers in Ganesh
>
> The main goal of this refactorization is to allow Vulkan to use separate
> sampler and texture objects in the shader and descriptor sets and combine
> them into a sampler2d in the shader where needed.
>
> A large part of this is separating how we store samplers and uniforms in the
> UniformHandler. We no longer need to store handles to samplers besides when
> we are initially emitting code. After we emit code all we ever do is loop over
> all samplers and do some processor independent work on them, so we have no need
> for direct access to individual samplers.
>
> In the GLProgram all we ever do is set the sampler uniforms in the ctor and never
> touch them again, so no need to save sampler info there. The texture access on
> program reuse just assume that they come in the same order as we set the texture
> units for the samplers
>
> For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers,
> then when we get new textures, we just assume they come in in the same order as we
> set the samplers on the descriptor sets. Thus no need to save direct vulkan info.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004
>
> Committed: https://skia.googlesource.com/skia/+/45b61a1c4c0be896e7b12fd1405abfece799114fTBR=bsalomon@google.com,jvanverth@google.com,cdalton@nvidia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1896013003
The main goal of this refactorization is to allow Vulkan to use separate
sampler and texture objects in the shader and descriptor sets and combine
them into a sampler2d in the shader where needed.
A large part of this is separating how we store samplers and uniforms in the
UniformHandler. We no longer need to store handles to samplers besides when
we are initially emitting code. After we emit code all we ever do is loop over
all samplers and do some processor independent work on them, so we have no need
for direct access to individual samplers.
In the GLProgram all we ever do is set the sampler uniforms in the ctor and never
touch them again, so no need to save sampler info there. The texture access on
program reuse just assume that they come in the same order as we set the texture
units for the samplers
For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers,
then when we get new textures, we just assume they come in in the same order as we
set the samplers on the descriptor sets. Thus no need to save direct vulkan info.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004
Review URL: https://codereview.chromium.org/1885863004
- Moves CPU feature detection to its own file.
- Cleans up some redundant feature detection scattered around core/ and opts/.
- Can now detect a few new CPU features:
* F16C -> Intel f16<->f32 instructions, added between AVX and AVX2
* FMA -> Intel FMA instructions, added at the same time as AVX2
* VFP_FP16 -> ARM f16<->f32 instructions, quite common
* NEON_FMA -> ARM FMA instructions, also quite common
* SSE and SSE3... why not?
This new internal API makes it very cheap to do fine-grained runtime CPU
feature detection. Redundant calls to SkCpu::Supports() should be eliminated
and it's hoistable out of loops. It compiles away entirely when we have the
appropriate instructions available at compile time.
This means we can call it to guard even a little snippet of 1 or 2 instructions
right where needed and let inlining hoist the check (if any at all) up to
somewhere that doesn't hurt performance. I've explained how I made this work
in the private section of the new header.
Once this lands and bakes a bit, I'll start following up with CLs to use it more
and to add a bunch of those little 1-2 instruction snippets we've been wanting,
e.g. cvtps2ph, cvtph2ps, ptest, pmulld, pmovzxbd, blendvps, pshufb, roundps
(for floor) on x86, and vcvt.f32.f16, vcvt.f16.f32 on ARM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890483002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Committed: https://skia.googlesource.com/skia/+/872ea29357439f05b1f6995dd300fc054733e607
Review URL: https://codereview.chromium.org/1890483002
Reason for revert:
many unexpected GM diffs across GPU+CPU configs on Windows (hopefully just text masks on GPU?). seems like we pick a different srcover variant in some places.
Original issue's description:
> Move CPU feature detection to its own file.
>
> - Moves CPU feature detection to its own file.
> - Cleans up some redundant feature detection scattered around core/ and opts/.
> - Can now detect a few new CPU features:
> * F16C -> Intel f16<->f32 instructions, added between AVX and AVX2
> * FMA -> Intel FMA instructions, added at the same time as AVX2
> * VFP_FP16 -> ARM f16<->f32 instructions, quite common
> * NEON_FMA -> ARM FMA instructions, also quite common
> * SSE and SSE3... why not?
>
> This new internal API makes it very cheap to do fine-grained runtime CPU
> feature detection. Redundant calls to SkCpu::Supports() should be eliminated
> and it's hoistable out of loops. It compiles away entirely when we have the
> appropriate instructions available at compile time.
>
> This means we can call it to guard even a little snippet of 1 or 2 instructions
> right where needed and let inlining hoist the check (if any at all) up to
> somewhere that doesn't hurt performance. I've explained how I made this work
> in the private section of the new header.
>
> Once this lands and bakes a bit, I'll start following up with CLs to use it more
> and to add a bunch of those little 1-2 instruction snippets we've been wanting,
> e.g. cvtps2ph, cvtph2ps, ptest, pmulld, pmovzxbd, blendvps, pshufb, roundps
> (for floor) on x86, and vcvt.f32.f16, vcvt.f16.f32 on ARM.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890483002
> CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/872ea29357439f05b1f6995dd300fc054733e607TBR=fmalita@chromium.org,herb@google.com,reed@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1892643003
- Moves CPU feature detection to its own file.
- Cleans up some redundant feature detection scattered around core/ and opts/.
- Can now detect a few new CPU features:
* F16C -> Intel f16<->f32 instructions, added between AVX and AVX2
* FMA -> Intel FMA instructions, added at the same time as AVX2
* VFP_FP16 -> ARM f16<->f32 instructions, quite common
* NEON_FMA -> ARM FMA instructions, also quite common
* SSE and SSE3... why not?
This new internal API makes it very cheap to do fine-grained runtime CPU
feature detection. Redundant calls to SkCpu::Supports() should be eliminated
and it's hoistable out of loops. It compiles away entirely when we have the
appropriate instructions available at compile time.
This means we can call it to guard even a little snippet of 1 or 2 instructions
right where needed and let inlining hoist the check (if any at all) up to
somewhere that doesn't hurt performance. I've explained how I made this work
in the private section of the new header.
Once this lands and bakes a bit, I'll start following up with CLs to use it more
and to add a bunch of those little 1-2 instruction snippets we've been wanting,
e.g. cvtps2ph, cvtph2ps, ptest, pmulld, pmovzxbd, blendvps, pshufb, roundps
(for floor) on x86, and vcvt.f32.f16, vcvt.f16.f32 on ARM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890483002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1890483002
