Re: [hatari-devel] How many colors when rendering in Hatari ?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 16 huhtikuu 2013, Nicolas Pomarède wrote:
> Le 16/04/2013 18:09, Eero Tamminen a écrit :
> > There's no direct support for 24-bits, only 32-bits.
> > Just look at the file names in src/convert/. :-)
> 
> 24/32 are similar, just force the alpha byte to a constant value
> 
> > ST VDI and monochrome modes support only 8-bits, higher bitdepths
> > are converted from 8-bit.
> 
> do you mean VDI mode is requesting a 8 bpp surface in SDL, whatever the
> screen real bpp is ?

Yes.

------- screen.c ----------
static void Screen_SetResolution(void)
{
        int Width, Height, nZoom, SBarHeight, BitCount, maxW, maxH;
        Uint32 sdlVideoFlags;
        bool bDoubleLowRes = false;

        /* Bits per pixel */
        if (STRes == ST_HIGH_RES || bUseVDIRes)
        {
                BitCount = 8;
        }
        else
        {
                BitCount = ConfigureParams.Screen.nForceBpp;
        }
---------------------------

(nForceBpp = 0 i.e. "let SDL select" unless user has configured
it to be 8, 16, 24 or 32.)


> > Main reason for having direct convertors for different modes
> > is speed, in ST emulation screen convertion is one of the
> > largest CPU consumers (with full timer-D interrupts).
> 
> I'm not sure there's such a huge gap between working with a 8bbp surface
> and a 24 bpp surface. More bytes to move of course, but with today cpu
> architectures and caches I'm not sure it matters anymore (especially
> with the rather small window's size we're daealing with).

With borders and statusbar, 2x zoomed ST-low results in 832x576 sized
Hatari window & SDL surface.  In 32-bits this is 1.83 MB of data.

At 60Hz, that's 110MB/s of writes to SDL double buffered surface,
and same amount of reads from that to front buffer, i.e. 220 MB/s
together.

That's a noticeable part of e.g. 1Ghz ARM device memory bandwidth,
taken away from rest of memory bandwidth needed for the emulation.

If VDI & monochrome remain 8-bit, the speed difference actually
is user noticeable.  However, there's another thing, which is as
relevant performance-wise for the use-cases where monochrome
and VDI modes are most used... [1]


> Still, could be interesting to benchmark 10 seconds of a demo doing lots
> of color change in 8 bpp, 16bpp and 24bpp to see what kind of numbers we
> get.

Just run Falcon emulation by forcing different bitdepths
(without heavy DSP emulation i.e. using "--dsp none") and
just let it idle in GEM desktop.

Because videl emulation updates the screen always [1],
the difference is much more visible.


> > But I think reducing&  simplifying that code would be good.
> > You could consider changing the conversion routines to be
> > line based, see todo.txt for more info.
> 
> The conversion routines could be line based / screen based (that's the
> same, just a loop for each line).
> 
> My aim for the video emulation is to have an adaptative mode that can
> draw pixels every 4 cycles when necessary or as a whole line when no
> video trick is detected (today, we always drw a whole line and that's
> also a pain to maintain when you consider all the border removal
> combinations that can happen)

[1] The stuff discussed in the todo.txt concerns how it's checked whether
    and what part of screen needs to be updated.  In normal GEM desktop
    most of the time there are no changes, and mouse movement requires
    updating only very small area.

Currently this checking & updates are done in very fine-grained way,
long at the time I think.  The proposal was to do this check line
at the time, as this can be done much more generic way, just using
memcmp().


	- Eero