[Scummvm-devel] Bitdepth/pixel format API concerns

RafaƂ Rzepecki divided.mind at gmail.com
Sun Jun 14 17:18:10 CEST 2009


2009/6/13 J Northup <upthorn at gmail.com>:
> Kirben: Ah, yes. I wasn't considering function reuse. That would lead to
> difficulties pretty quickly.
>
>>
>> I can't help but feel this whole discussion is an acute case of
>> premature optimalization. How expensive is colorspace conversion
>> anyway? My guess is, not very much. Most (all?) backends do full
>> screen conversions anyway, since the hardware is usually truecolor.
>> How much more expensive could full screen pixel swizzling be compared
>> to palette lookup?
>
> Fullscreen pixel-by-pixel RGB conversion is a significant performance impact
> compared to fullscreen CLUT lookup, even on modern multi GHZ CPUs. It is one
> thing to do
> putpixel(colortable[color]);
> and another thing entirely to do
> putpixel(((color >> 10) & 0x1F) | (((color >> 5) & 0x1F) << 6) | ((color &
> 0x1F) << 11));
> (which is the simplest case for RGB555 -> BGR565)

I beg to differ. BTW, this is hardly the simplest code for the
aforementioned conversion, but that's not really the point.

Actually I wasn't convinced about the impact, so I took the liberty of
running a simplistic benchmark, comparing palette lookup with
RGB555->BRG565 conversion with the simplest code possible. Here are
the results:
$ time ./swizzle 10000
Running 10000 iterations of swizzling RGB555->BGR565 for 640x480 fullscreen

real    0m27.200s
user    0m19.160s
sys     0m0.391s

$ time ./palette 10000
Running 10000 iterations of palette-lookup conversion for 640x480 fullscreen

real    0m23.111s
user    0m17.459s
sys     0m0.381s

This boils down to 522 vs. 573 FPS for swizzling vs. palette lookup,
respectively. Hardly a lifesaver, and that's for the most simple code
there is, ie. replacing outcolor = palette[incolor] with outcolor =
(incolor >> 10) | ((incolor & 0x3e0) << 1) | ((incolor & 0x1f) << 11);
this means platform-specific hacks (or, heck, even compiler
optimizations, above was with -O0) could easily snip away the
difference.

I've put the benchmarks on the pastebin so you can try it on your
hardware: http://pastebin.com/f3c5748dd for swizzle and
http://pastebin.com/f7d466a6 for the palette.

>> My vote is (although I'm not sure if I have any right to vote, so
>> let's make it "my voice") to KISS it. Let the engine request however
>> exotic colorspace it wants (as long as it's supported by our
>> conversion routines, ie. the PixelFormat struct) and let the backend
>> worry about how to draw it. Unless the engine just wants whatever
>> high/truecolor mode (as when doing conversion anyway), then let it ask
>> for any mode and let it find out what mode it was provided.
>
> However, many of the concerns I am seeing in this discussion are bringing my
> opinion into line with this anyway. There's no point forcing engines to
> convert if it causes significant performance loss there anyway. And since
> there are more engines that would be necessary to modify than backends, the
> performance impact is outweighed in importance. Especially since the
> performance impact would only apply to games that were previously
> unsupported.
>
> I am formulating a new proposal based on this discussion and will post it by
> the end of the day. I think LordHoto and fingolfin will find it much more
> agreeable than my previous one.
>




More information about the Scummvm-devel mailing list