SpriteBatch and GraphicsDevice: Impact of SpriteSortMode on GPU State Changes

Answer

Yes. With SpriteSortMode.Texture, MonoGame still forces a flush and a new GPU draw call for every BlendState variation inside the same Begin/End, even when sprites share the same texture. Texture sorting reduces texture binds, it does not suppress state-change flushes.

Confirmed facts

• MonoGame SpriteBatch maintains a current batch state that includes BlendState, SamplerState, RasterizerState and the bound texture. A Draw that differs from the current batch state causes SpriteBatch to flush the pending vertex buffer before recording the new draw.
• SpriteSortMode.Texture sorts the recorded draw entries by texture before flushing, to reduce texture binds. The sort does not suppress state-change flushes; state mismatches are evaluated per Draw and force an immediate flush.
• BlendState, SamplerState and RasterizerState are set at SpriteBatch.Begin and are compared on each Draw. Changing GraphicsDevice state directly between Draw calls is undefined and will still cause a flush or incorrect rendering.

Likely explanation

With SpriteSortMode.Texture and varying BlendState requirements inside a single Begin/End, each BlendState change triggers a flush and a new GPU draw call even if the texture is unchanged. Texture grouping reduces texture binds but does not coalesce sprites with different blend requirements. The CPU sort cost of Texture mode is incurred in addition to the state-change flushes.

Steps needed for this case

1. Group sprites by both texture and BlendState/SamplerState before drawing. Do not interleave different blends within one Begin/End.
2. If a blend change is required, End the current batch and Begin a new one with the new BlendState, then draw the next texture-grouped set. This is the supported MonoGame pattern.
3. Avoid mutating GraphicsDevice.BlendState/SamplerState between Draw calls. Use separate Begin/End pairs instead.

Uncertainty and verification

Implementation details are version-sensitive between MonoGame, FNA and legacy XNA, and effect changes also force a flush. Practical verification is recommended: create a minimal test with two sprites sharing the same texture but different BlendState under SpriteSortMode.Texture and count GraphicsDevice draw calls to observe flush per blend change.

One diagnostic detail that changes the recommendation: are you changing BlendState via separate SpriteBatch.Begin/End calls, or attempting per-sprite BlendState changes by mutating GraphicsDevice state between Draw calls? The supported path is Begin/End per state; direct device state mutation is undefined.