[4/5] wined3d: Convert some BOOLs to bitfields in struct IWineD3DDeviceImpl.

[Henri Verbeet]

2009/1/2 Rob Shearman <robertshearman at gmail.com>:
> How many instances of this structure are likely to be in a process at
> any one time? It seems to me as though as any memory savings gained by
> making the BOOLs into bitfields will be taken up by increased code
> size. There is also the risk that there will be a small performance
> penalty for this and the other similar changes too.
>
In a typical application there's only one instance of the device
struct, but the fields are accessed a lot. The patch isn't so much
about saving memory as it's about not wasting cachelines. The
SAVEDSTATES struct, which most of the other patches modify is used a
bit more, once for each stateblock. Note that that structure was
initially 5448 bytes large, using up 86 64-bit cachelines. It should
be possible to get that down to 3 or 4.

Code size increase should be insignificant for this patch, in case of
setting a flag you essentially replace a mov with an or, and testing
stays mostly the same. For the SAVEDSTATES patches a couple of extra
shifts are introduced, but I'm pretty sure those are worth it compared
to the saved cachelines.

> These kinds of optimisations need to be backed up by benchmarks, for
> both memory and performance.
>
I did of course run some benchmarks before sending these changes in.
3DMark03 shows a small but consistent improvement. The CSS stress test
doesn't get much more than a single fps improvement for the average
frame rate, but that one is mostly limited by shader constant loading
and sample size & rate conversion in dsound (ignoring sRGB texture
loading). I didn't notice any performance regressions in any
applications.