RDP development thread

[mudlord_]

started porting marathonman's work back to pj64 plugin

[MarathonMan]

Does it work now? How does it compare to angrylion stock RDP? CEN64 spends a large majority of time outside of RDP currently, so I can't tell much of a difference yet.

Another thing I thought of: performance is going to suffer somewhat without LTO. I'll see if I can compile this with gcc tonight and/or think of a way to cleanly remove this "optimization dependency".

[mudlord_]

Thats the thing: doesn't work atm currently. I replaced the macros etc.

Would be nice indeed to see a GCC compile with it working.

[HatCat]

angrylion admittedly avoided many endianness issues in his plugin.

If you do any 16- or 32-bit reads and writes (like DST = *(int *)(base + addr)) then this is going to end up little-endian anyway.

Since MarathonMan's emulator is entirely big-endian (which is correct for all storage purposes), I think the RREADADDR8 or w/e functions would themselves all need to be rewritten to become byte-iterative.

Not really an easy thing, but, not sure whether it's easier to port it now and keep it in sync with future changes, or to delay porting it until after MM "simplifies" it.

[MarathonMan]

Originally Posted by BatCat

angrylion admittedly avoided many endianness issues in his plugin.

If you do any 16- or 32-bit reads and writes (like DST = *(int *)(base + addr)) then this is going to end up little-endian anyway.

Since MarathonMan's emulator is entirely big-endian (which is correct for all storage purposes), I think the RREADADDR8 or w/e functions would themselves all need to be rewritten to become byte-iterative.

Not really an easy thing, but, not sure whether it's easier to port it now and keep it in sync with future changes, or to delay porting it until after MM "simplifies" it.

Thankfully he enclosed all RSP and RDRAM accesses using those macros (or was it MooglyGuy? -- possibly the latter), so all I had to do was enclose the macros in bswap functions.

[MarathonMan]

Latest version in CEN64 is looking pretty gnarly. Give her some more vectorization and work and fun shall be had.

http://www.youtube.com/watch?v=oaWTlqzBFvw

[mudlord_]

wow, looks very nice.
got back to porting over bits, one by one, so i dont break anything.

almost ported all the precompiled tables except for the cvarray, which doesnt work for some reason here.

[MarathonMan]

Originally Posted by haxatax

wow, looks very nice.
got back to porting over bits, one by one, so i dont break anything.

almost ported all the precompiled tables except for the cvarray, which doesnt work for some reason here.

EDIT: Nevermind, I didn't know that the port was a work in progress.

Hmm... not sure why it wouldn't work, though...

[HatCat]

Probably because only the cvarray has this struct type declared:

typedef struct {
    uint8_t cvg;
    uint8_t cvbit;
    uint8_t xoff;
    uint8_t yoff;
} CVtcmaskDERIVATIVE;

I don't know whether endianness for structs is maintained or if it needs to be corrected in this case with a byte-swap, but if it is maintained then maybe it's just the run-time initialization of the array:

	for (; i < 0x100; i++)
	{
		mask = decompress_cvmask_frombyte(i);
		cvarray[i].cvg = cvarray[i].cvbit = 0;
		cvarray[i].cvbit = (i >> 7) & 1;
		for (k = 0; k < 8; k++)
			cvarray[i].cvg += ((i >> k) & 1);

		
		masky = maskx = offx = offy = 0;
		for (k = 0; k < 4; k++)
			masky |= ((mask & (0xf000 >> (k << 2))) > 0) << k;

		offy = yarray[masky];
		
		maskx = (mask & (0xf000 >> (offy << 2))) >> ((offy ^ 3) << 2);
		
		
		offx = xarray[maskx];
		
		cvarray[i].xoff = offx;
		cvarray[i].yoff = offy;
	}

Question: Why do we use angrylion's FPTR for this module instead of "nocomment"? Wasn't the latter supposed to be more accurate and up-to-date with more of his fixes and optimizations?

[MarathonMan]

Originally Posted by BatCat

Probably because only the cvarray has this struct type declared:

typedef struct {
    uint8_t cvg;
    uint8_t cvbit;
    uint8_t xoff;
    uint8_t yoff;
} CVtcmaskDERIVATIVE;

I don't know whether endianness for structs is maintained or if it needs to be corrected in this case with a byte-swap, but if it is maintained then maybe it's just the run-time initialization of the array:

	for (; i < 0x100; i++)
	{
		mask = decompress_cvmask_frombyte(i);
		cvarray[i].cvg = cvarray[i].cvbit = 0;
		cvarray[i].cvbit = (i >> 7) & 1;
		for (k = 0; k < 8; k++)
			cvarray[i].cvg += ((i >> k) & 1);

		
		masky = maskx = offx = offy = 0;
		for (k = 0; k < 4; k++)
			masky |= ((mask & (0xf000 >> (k << 2))) > 0) << k;

		offy = yarray[masky];
		
		maskx = (mask & (0xf000 >> (offy << 2))) >> ((offy ^ 3) << 2);
		
		
		offx = xarray[maskx];
		
		cvarray[i].xoff = offx;
		cvarray[i].yoff = offy;
	}

Question: Why do we use angrylion's FPTR for this module instead of "nocomment"? Wasn't the latter supposed to be more accurate and up-to-date with more of his fixes and optimizations?

Nah, no byte-ordering issues. The tables are loaded the same if he used the arrays from Tables.c.

I used angrylion's nocomment branch.