windows-server-2003/multimedia/directx/dxg/d3d/dx6/rast/mmxspan

Status of general MMX span routines.



09/08/97 Checked in MMX code.

  There is no way that the current code will compile and run.  I haven't

  even tried to compile it. This is primarily to have it backed up and

  to let anyone that is interested see what has been done.

  The orginal C (or MCP) code are comments of these ASM or MAS files.



  The ACP directory contains a program that generates the .INC file

  for offsets to all the data.  This program was used by Drew and

  seems to work better than H2INC.  We should probably only have one

  of these that would go in the inc directory, but it's not done that

  way now (Plus, my code doesn't generate it based on a makefile.



  Three regular registers have been set aside for use to access the data.

  Since these are passed to every routine, I don't have to pass anything

  on the stack as long as I don't modify them.  I have modified them a

  couple of times before I added this and they need to be changed to esi,

  edi, ebp or eax (eax is usually used for the next indirect jump).



  ebx is a pointer to the D3DI_SPANITER data (Also Accesses the SI stuff

    inside it).

  ecx is a pointer to the D3DI_RASTPRIM data.

  edx is a pointer to tge D3DI_RASTSPAN data.



  There are a few very useful m4 macros to acess this data in

  readable way (It also made converting C code easier):



define(`XpCtxSI',`[ebx+D3DI_SPANITER_$1]')dnl

define(`XpCtx',`[ebx+D3DI_RASTCTX_$1]')dnl

define(`XpP', `[ecx+D3DI_RASTPRIM_$1]')dnl

define(`XpS', `[edx+D3DI_RASTSPAN_$1]')dnl



  Things that need to be done.

    1) New Special W divide.   MMX newton's method code has already

        been written, but it was very specialized (I negated the

        OoW and OoWDX so that 2 - Oow*iW could be done with a pmadd

        and a few other things.)  Code shouldn't have to change much.



    2) Assembly equivalents to the ACMP, ZCMP macros.  A version of

        these has also been written, but most compares were done in

        a reverse order (to preserve registers).  The MMX Alpha and

        Z setup will most likely have to be different.  This means

        that the atest.asm has not been coded.  A test.mas file is

        written, and is missing ZCMP16 and ZCMP32.  The other 4

        specific code cases are done exactly like the C version

        except the iXorMask always seems to be inverted do to how

        the comparison is done.



    3) BufWrite is not implemented.  The code for doing this has

        been done in APP notes.  The 16 bit cases use a pmaddw

        to combine the colors more quickly than shifting.  There

        is also work beening done on a quick dithering routine.

        The MMX dithering routine will use a pcmpgtw to compare

        with the dither table and the do a psubssw since if the

        color value is to be incremented, then the mask will be

        all ones (= -1). Subtracting it will increment the color.

        The saturation is used to not increase too much.  The

        only problem to this is that the color is unsigned so

        it has to be shifted down by one to saturate to 7fff.



    4) BuffRead is not done.  It uses almost identical routines

        as those in texread.





    5) Lots of clean up and 64 bit constants that need to be in

        memory.  I have to figure out what registers get passed

        to routines that are called and what is passed back.

        In some cases, it may be possible to pass data from one

        bead to the next using registers.  This maybe difficult

        though.



    6) ColorBld conversion.  Mostly ROP stuff and calling of

        bldfuncs.asm.  ROP stuff should be pretty easy.



    7) Since function names are the same, if I made a header

        file declaring them extern "C" { },  the assembly code

        could concievably execute in place of the current c code.

        This is where the true bomb test is.



    8) There's probably more, but there is always more.