> Interesting, I wouldn't have split blend_factor from inverting the
> factor. I'm fine with it, though.
The rationale was that the code logic needs it split anyway, so the
split has to happen in one place or another... at least this way there's
less redundant enum'ing. TBH, I'd prefer Gallium
Alyssa Rosenzweig writes:
> We add enums corresponding to (GLES) blend state to shader_enums.h,
> complementing the existing advanced blending enums in the file. This
> allows us to represent blending state in a driver-agnostic, API-agnostic
> way to permit lowering.
>
> Signed-off-by: Alyssa
This commit is
Reviewed-by: Ian Romanick
On 5/5/19 7:26 PM, Alyssa Rosenzweig wrote:
> We add enums corresponding to (GLES) blend state to shader_enums.h,
> complementing the existing advanced blending enums in the file. This
> allows us to represent blending state in a driver-agnostic,
We add enums corresponding to (GLES) blend state to shader_enums.h,
complementing the existing advanced blending enums in the file. This
allows us to represent blending state in a driver-agnostic, API-agnostic
way to permit lowering.
Signed-off-by: Alyssa Rosenzweig
Cc: Eric Anholt
Cc: Kenneth
