Support for special framebuffer stuff in plug-ins?

[Poobah]

I don't really know entirely how it works, or what it is, but is there any chance that Project64 could implement the special frame-buffer stuff that Mupen64 supports? With the Glide64 plug-in, it has a "get framebuffer info" option, and this option used with Mupen64 results in great framebuffer emulation. So could Project64 support this?

 

[squall_leonhart]

seconded, is it possible?

 

[Poobah]

(Bump)

 

[zilmar]

It is possible, I guess it is just a matter of working out what info it is after and the functions I need to hook to use it

 

[Doomulation]

Perhaps ask hacktarux since I assume it was he who invented it (or added it to mupen, if you prefer).

 

[Gonetz]

This feature uses schibo-Rice extension to zilmar's specifications.
Here are the extension functions:

/******************************************************************
Function: FrameBufferRead
Purpose: This function is called to notify the dll that the
frame buffer memory is beening read at the given address.
DLL should copy content from its render buffer to the frame buffer
in N64 RDRAM
DLL is responsible to maintain its own frame buffer memory addr list
DLL should copy 4KB block content back to RDRAM frame buffer.
Emulator should not call this function again if other memory
is read within the same 4KB range
input: addr rdram address
val val
size 1 = BYTE, 2 = WORD, 4 = DWORD
output: none
*******************************************************************/
EXPORT void CALL FBRead(DWORD addr)

/******************************************************************
Function: FrameBufferWriteList
Purpose: This function is called to notify the dll that the
frame buffer has been modified by CPU at the given address.
input: FrameBufferModifyEntry *plist
size = size of the plist, max = 1024
output: none
*******************************************************************/
EXPORT void CALL FBWList(FrameBufferModifyEntry *plist, DWORD size)

/******************************************************************
Function: FrameBufferWrite
Purpose: This function is called to notify the dll that the
frame buffer has been modified by CPU at the given address.
input: addr rdram address
val val
size 1 = BYTE, 2 = WORD, 4 = DWORD
output: none
*******************************************************************/
EXPORT void CALL FBWrite(DWORD addr, DWORD size)

/************************************************************************
Function: FBGetFrameBufferInfo
Purpose: This function is called by the emulator core to retrieve frame
buffer information from the video plugin in order to be able
to notify the video plugin about CPU frame buffer read/write
operations

size:
= 1 byte
= 2 word (16 bit) <-- this is N64 default depth buffer format
= 4 dword (32 bit)

when frame buffer information is not available yet, set all values
in the FrameBufferInfo structure to 0

input: FrameBufferInfo pinfo[6]
pinfo is pointed to a FrameBufferInfo structure which to be
filled in by this function
output: Values are return in the FrameBufferInfo structure
Plugin can return up to 6 frame buffer info
/************************************************************************/
typedef struct
{
DWORD addr;
DWORD size;
DWORD width;
DWORD height;
} FrameBufferInfo;
EXPORT void CALL FBGetFrameBufferInfo(void *p)

FBWList actually does not used.

 

[squall_leonhart]

so is that more efficient (faster)

 

[MooglyTwo]

Not particularly. Constant transfers from your video card's memory to your computer's main memory will pretty easily saturate the bus and kill performance no matter how you look at it.

Incidentally, that's why the PS3's architecture is so great - it has dedicated DMA hardware for RAM -> VRAM and VRAM -> RAM transfers, so you get things like that for free. Not so on comsumer PCs.

 

[squall_leonhart]

um right... stop talking out your ass.

the biggest limiting fact in a computer is the hard disk, as they are limited by current disk head technology... you rarely ever reach 100mb/s

memory on the other hand, can transfer 100mb in a microsecond,
the pci-e bus is directly linked to the memory bus on the cpu and the agp port is made to bypass memory when fastwrites is enabled.

btw, DMA is not a good thing, thats why AGP and PCI-E are so well designed as they completely bypass the need for DMA

also, a computer will always out to a PS3 as the ps3 is designed to read a certain format of code,

 

[synch]

Actually, MooglyTwo was right. Memory readbacks from the framebuffer (or VRAM) are not cheap at all. First of all, are the pipeline stalls, the swizzling, and more. Second, usually, you've to retransfer the data again to the card (if you downloaded it to RAM for some treatment, for example, blur), that causes another stall, and if the format is some "strange" one that the destination texture needs, a slow upload. There're lot of more tiny details included, but this is the "big picture".

And DMA are good, because cpu is not used for the transfer.

So, more or less, squall_leonhart, you're totally wrong

 

[gandalf]

I don´t get it, why so much bandwith will be saturated only by tinny frame buffers

 

[squall_leonhart]

DMA is not good, which is why DMA is not used on video cards on agp and pci-e.

they both bypass Direct memory access, by having a pipeline of thier own to the memory, DMA is limited by the chipset as the chipset handles dma access in hardware,
Agp and PCI-E both have direct access to the memory via the GART table

DMA is an antique method, and is being phased out and replaced by higher memory access, the first generation of processors to do this are the Athlon 64 cpu's with on-die cpu controllers, meaning that memory speed is limited by only the cpu.

these days, using the cpu for transfer is much faster then dma becoz of this.

the reason why cpu access was slow before is becoz it had to work like this

CPU is asked to handle a memory request
CPU passes this along the old 100-400mhz hostBus
the northbridge intercepts this and forwards it onto the memory bus.
the memory bus then sends it back through the
northbridge back to the cpu.


DMA was good then

nowadays it works like this
cpu is sent the transfer request
cpu sends the request directly onto the memory controller, into ram, and is read back to the cpu.

this is alot faster then DMA was ever capable of. and its not limited by the old host bus.

this is why PCI-E doesnt require FW and SBA as it is directly connected to the cpu memory controller.


what i want to know though, is why can't the plugin be rewritten to only access the framebuffer information that is needed. this would be quicker..

would take more time to make the plugin.. but its more efficient, and its possible as gpu pete did the same in his PSX opengl plugins

I don´t get it, why so much bandwith will be saturated only by tinny frame buffers

im not sure either dude,

the agp bus is capable of 1gb of second at 4x and 2gb/s at 8x, and memory is capable of 3200mb's at 400mhz

 

[Doomulation]

what i want to know though, is why can't the plugin be rewritten to only access the framebuffer information that is needed. this would be quicker..

would take more time to make the plugin.. but its more efficient, and its possible as gpu pete did the same in his PSX opengl plugins

Either it seems to me that it can't be done or is very complicated.
I mean, the application needs the entire scene that is rendered, do its modifications, then send it back.
But this is a question best forwarded to a developer who knows about this.

 

[synch]

Well, your numbers are theorical maximums, check this for more references on REAL world maximums (a bit exaggerated, though):

http://download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_Texture_Transfers.pdf.

Anyway, I highly doubt they'd be f*** up by the needed transfers for the nintendo64, but as I don't (and I suppose you neither) know the n64 architecture in detail, let's just suppose that if it hasn't been done yet, is for a reason.

 

[Rice]

Incidentally, that's why the PS3's architecture is so great - it has dedicated DMA hardware for RAM -> VRAM and VRAM -> RAM transfers, so you get things like that for free. Not so on comsumer PCs.

If CPU need the content from video RAM, it still has to request GPU to transfer it back to main RAM. A dedicated DMA transfer seems to work better than PC, but DMA isn't fast and free. Framebuffer is big chunk of data, it will be slow to be transferred (if entirely) back to main CPU RAM.

In the meantime, XBOX 360, both CPU and GPU are sharing the same piece of RAM, just like N64, seems to work better in such situation, because nothing to transfer.

 

[squall_leonhart]

...hmmm.. Rice, would making better use of the Cpu's cache help?

maybe precaching framebuffer would allow a smoother and faster framebuffer read?

 

[Poobah]

...hmmm.. Rice, would making better use of the Cpu's cache help?

I'm not that much of a hardware guy, but I don't really think optimisation is going to remove the large transfer time from between VRAM and regular RAM.

maybe precaching framebuffer would allow a smoother and faster framebuffer read?

What do you mean? Sending over a previous "frame" in the background while the emulator continues to work as normal? If that were possible, I'm sure it would've been implemented straight away.

 

[squall_leonhart]

anything is possible with the on die cache.

 

[Doomulation]

...hmmm.. Rice, would making better use of the Cpu's cache help?

I doubt that. The cache is much too small and there is no way to tell what is going to be stored there.

maybe precaching framebuffer would allow a smoother and faster framebuffer read?

I would doubt that, too. Can you see the fast transfer rates (in the doc)? Yes, those are speeds per second. If an emulator can't do framebuffer read/write all the time, then that means it must surpass the speed that it can write and read from per second. Again, which means it could consume 1 gb+ of ram to buffer it. And whatever you say, referencing and modifying such a big block of memory is nowhere near cheap. That is my theory.

 

[smcd]

/me agrees with synch and mooglytwo