🔒 Locked

State changes

Started by IndirectX Jun 14, 2002 at 5:41 AM 3 replies 500+ views

Original Post

Jun 14, 2002 at 5:41 AM

Hi all, I''ve just fixed this incredible bug in my font engine after many weeks of debugging where the text was *sometimes* partially corrupted on my GF3 and disappeared completely on refrast and Radeon 7500, due to me not initializing ''rhw'' component of my vertices. Now it''s time to do some optimizations. Currently all text is rendered through one (global) dynamic vertex buffer. I''m doing two kinds of major state changes: 1) changing texture for different fonts and 2) changing vertex shader from XYZ|NORMAL for untransformed vertices to XYZRHW for transformed ones (I''m using fixed functions pipeline). I want to sort all render requests, so my quesion is this: what is more expensive: changing the texture or changing the vertex shader? I assume that smaller state changes such as culling and filtering are the least expensive of these three, is this correct?

S1CA

Jun 14, 2002 at 7:18 AM

In DX7 changing the vertex buffer (thus shader) was a bad thing to do - this was fixed/improved considerably in DX8.

I''d say if your textures don''t all fit in video memory during a complete frame, texture change will be the killer so is the thing to sort by. If they do all fit in when the fonts are drawn, then it starts to become more hardware dependent - though I''d still say sort on texture (I think)

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

greldik

Jun 14, 2002 at 7:39 AM

The only way to be sure is to time your code!

Changing between textures that are resident in VRAM is probably as fast as changing between different fixed function pipeline shaders. Changing to a texture that have to be uploaded to VRAM is most likley slower.

All state changes that doesn''t involve a lot of data transfer are probably equally slow...

But all this are just guesses of course. =)

/ Martin

S1CA

Jun 14, 2002 at 9:46 PM

Yep, agreed, it is a **very** hardware dependent thing...

texture changes require a flush of the texel cache and all pending primitives using that texture.

*some* state changes require a flush of the primitive data using the previous context whether that change is more expensive than the texture change is state and hardware dependent.

in our engine we sort on shader ID, but I think our definition is slightly different than most, in that our shader ID actually contains details of what is most important to sort on too, so we do end up actually sorting by vertex buffer, state type, primitive type etc...

IndirectX

Jun 15, 2002 at 5:22 AM

Thanks guys. I think I''ll go for the texture initially.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.