I read about depth buffer emulation in the dolphin progress report. Dolphin seems to have a good way to emulate the depth buffer. Unfortunately depth buffer emulation is a big problem for hardware renderers in Nintendo64 emulators. Currently there are two approaches and both have massive drawbacks. It's described in this article
http://gliden64.blogspot.co.at/2014/07/d...ation.html?. This is a question to the developers here: do you know a better way to emulate the depth buffer? This would be a big help for N64 emulation. The main problem is that the depth buffer is stored in emulated RDRAM and rendering happens on the PC's video card. I'm asking here because maybe dolphin had similar problems and I see that there are many skilled developers around. Maybe it will be possible play Pokemon Snap with a N64 emulator. Currently N64 emulators only support this game with software renderers.
There is a very good way to emulate the depth buffer of the N64, but the hardware requirements are HUGE:
Implement all of the framebuffer with images just as gonetz did it. But don't get the same wrong assumtion that you don't need any synchronization. But D3D12.1 requires a new feature called "raster order views", which means you're able to configure a part of the pixel shader to run "in primitive order". So it's an easy way to program it, and the power requirements also aren't as high, but you'll need a very recent GPU:
Intel: Starting with Haswell
Nvidia: maxwell 200+ (Geforce 900)
AMD: Not right now
Mobiles: All but adreno iirc (in primitive order is basicly free on tiled renderer)
For OpenGL, there is also an extension which provides the same feature: ARB_fragment_shader_interlock, or legacy: INTEL_fragment_shader_ordering, EXT_shader_framebuffer_fetch (OpenGL ES)
Edit: Feel free to also ask me this question on #dolphin-emu on freenode
Thanks for this answer. I'm just trying to figure out what's wrong with gonetz's implementation. GLideN64 copies depth buffer data from the video card into the emulated RDRAM once per frame. This seriously affects performance. What exactly needs to be synchronised and how can this be done?
The point is that image access (so his framebuffer writes and reads) are unsynchronized. So it may happen (and in fact, it happens often), that a pixel of a second primitive is executed before the pixel of the first primitive. Even worse, the caches are not coherent, so to update the cache of the second pixel, the cache of the first pixel must be flushed. Just remember that a GPU doesn't use the same hardware for two pixels at the same position...
I think gonetz's way to fix it was to call glMemoryBarrier between every *primitive*, but this slows down the execution by far more than just do all of this work on the CPU...
Oh, and you should look for a way to detect when the CPU is trying to access the memory range. Those read & writes can be transformed in callbacks which to all of this ugly copying work "live".
These are valuable advices. N64 emulation needs a lot of work unfortunately.
(08-27-2015, 12:29 AM)degasus Wrote: [ -> ]Oh, and you should look for a way to detect when the CPU is trying to access the memory range. Those read & writes can be transformed in callbacks which to all of this ugly copying work "live".
This one made me think further, copying data is a big problem in N64 emulation
GLideN64 has code for copying color buffer to RDRAM
it has code for copying depth buffer to RDRAM
it has code for copying color buffer from RDRAM
it has code for copying depth buffer from RDRAM
It’s all ugly and hackish. Any details on this would be appreciated. The red dot in Pokemon Snap is a CPU based effect, the CPU checks for pixels and then the CPU draws the red dot. Dolphin can do this without problems, but all this copying work in GLideN64 does not help.
The gamecube also has the framebuffer mapped in the virtual address space of the ppc. We call this feature "efb access", we queue all writing access and apply them asynchronly on our framebuffer in VRAM. But readback is slower. On OGL, we try to cache them to speedup CPU based postprocessing, but every readback after a common rendering call needs a GPU round trip time, which is usually about one milli second.
I don't understand the difference between efb access and efb to ram options in dolphin. Pokemon snap uses cpu based effects but disabling efb access does not harm this game. Instead it needs efb to ram for camera detection and to display the pictures at the end of a level.
With GLideN64 this game needs copy color option, it fixes the missing pictures but not the missing camera detection and the red dot. I know how the copy color option in GLideN64 works. It uses glBlitFramebuffer to scale the framebuffer to N64 resolution and glReadPixels to read it from the video card. Then the data is converted into N64 format and copied into RDRAM. It costs performance if a game runs at a higher resolution than usual. Also GLideN64 calculates framebuffer width and height. This calculation goes wrong in a few games. Then program data in RDRAM can be overwritten and the emulator crashes
I’d like to bring this up again, I think N64 emulators can learn a lot from dolphin. Something like framebuffer access from CPU is definitely not implemented in N64 emulators. I suggested this to the emulator developers. In my previous post I explained the copy color method N64 emulators use. I noticed if a game needs copy color in a N64 emulator it also needs EFB to RAM in the virtual console in dolphin (monitors in Mario Kart, Camera in Pokemon Snap …). I’d like to find out if dolphin’s EFB to RAM is somehow comparable to copy color in N64 emulators. It seems to work better and it seems to have less drawbacks. Maybe dolphin found a better method to emulate this. I know how N64 emulators work but I don’t know much about dolphin.
"copy color" and EFB to RAM sound like the same feature. But emulating this feature always has a big performance impact, there is (almost) no way to deal with it. And dolphin doesn't try to deal with it at all. So we share the same disadvantages. Everything else just sounds like a bug.
So for me, this doesn't sound like you're looking forward to get technical knowlegde. More like if you want us to fix a N64 emulator.
If I'm wrong, feel free to ask me any questions on IRC about ideas how to improve it
But I doubt anyone here will now start to write an N64 emulator...