CEN64 Discussion Forums

Nintendo Maniac 64 wrote:Though an odd thing is that some games, such as Rush 2049, have their audio playing too fast even when the emulator is at 60 VI/s...

Probably means CEN64 is either firing AI interrupts too frequently, or needs to set AI status reg to full more often.

LLE graphic plugins don't even look right with this game. Seems to only look ok with HLE.. I guess the devs only use / test with HLE.

If you really want very good performance, then you should get the i5 6600k. Not sure if you consider it "reasonably priced", but I don't think you can find a better deal for the performance you'll be getting. Emulators tend to access memory more often than your typical program, so RAM is very import...

I hear an i3 6100 is a good budget cpu. Too bad you can't effectively overclock it though. Skylakes have good IPC, which is very important for CEN64. GPU doesn't really matter for N64 emulation. I heard IGP is actually faster at blitting, so you may be better off just using IGP for CEN64. I think 10...

World Driver Championship needs RSP synchronization, same with Gauntlet Legends. If Gauntlet doesn't work, then there's a good chance you need to change some RSP code. I doubt the current FPU bugs would cause it to not work, considering most emulators likely have some FPU bugs.

The speed issue is less due to Vulkan, and more due to the RSP right now. AFAIK Tiny Tiger is working on the RSP performance issue, which is why the rendering errors aren't getting fixed (yet). I'm still unsure whether they'll be able to get it to work with all titles. Some things like Mario Golf w...

OK, with reinstalling and downgrading the NVidia driver to 368.69, praLLEl works now. :) But with an i5 3.2 Ghz and a GTX 770 even Super Mario 64 drops down to 40fps. But the rendering seems to be complete. Wow that's actually surprising. I wonder why it would drop down to 40 fps.. Yes, [he who doe...

Zelda MM is a bit more intensive but it's playable enough, however it slows more when we are in Clock Town, especially in the south sector where VI/s can reach near 40 VI/s. I tried running around Clock Town today and the game doesn't seem intensive tbh. I'm honestly surprised you don't get full sp...

True, Mario Party isn't that intensive, but it becomes slow in that particular place I have mentioned before, the world hub where there are the tube, the bank, the raft and some other buildings. I cannot think of any other similar places where the VI/s drops, though. Zelda MM is a bit more intensiv...

I don't own Vigilante 8, and I never noticed frame skipping whenever I last played it 10-15 years ago (but I was much less sensitive to such thing), but anyone that's done 3-4 player splitscreen in GoldenEye with any sort of explosive weapon in a level with exploding scenery will very know that Gol...

Do you think these optimizations in the end will yield enough boost so that games can be run at 60 VI/s with the single-threaded build? What games do you have in mind? I'm willing to profile and examine a few popular games that are very slow, to see what can be done. I'm not really concerned about ...

Do you think these optimizations in the end will yield enough boost so that games can be run at 60 VI/s with the single-threaded build? A lot of 2D games should be able to run full speed after optimizing. It seems that games which use a lot of rectangles, use the RSP less as well (Yoshi's Story, Ba...

Good news is that I realized that pmaddwd is quite useful for certain algorithms :D . Now, the gap between SSE2 and SSE4 is smaller, since pmulld isn't necessary most of the time. I'm going to start using that instruction in rgbaz_correct_clip and texture_pipeline_cycle. It will not only shorten the...

I'm intrigued that Hydro Thunder works. Other emulators use some game specific code to get it working.

The problem is that Project64's codebase is a bit more troublesome to trudge through, whereas Mupen64Plus's is closer in organization to Cen64's, so backporting changes back and forth is easier. Granted, Project64 IS the most compatible N64 emulator of the whole bunch, so in that sense it does make...

GPDP wrote:It may be worthwhile to take another look at Cen64's RSP code and attempt to backport some of what was done in Mupen64Plus-libretro to fix these games.

I can say from experience that it is better to look at Project64's code instead of Mupen64Plus-libretro.

I started optimizing the RDP some more and have reached the point where simple optimizations are making a noticeable difference :D . Using more arrays really helped. For some reason, any compiler I've looked at, didn't vectorize TEX->r = t3.r + ((((invsf * (t2.r - t3.r)) + (invtf * (t1.r - t3.r))) +...

However there is still a preference towards a non-cycle accurate RDP, which I believe - in my truest and most honest opinion - is bullshit. I don't know what you're talking about. I don't see how focusing on other parts of N64 emulation, has anything to do with having a preference towards a non-cyc...

How come you're stuck with 32-bit? Since you have SSE4, I'm assuming your CPU is capable of 64-bit. I'd hate to see you spend all this time optimizing things specifically for 32-bit. My hardware and OS is 64-bit, but atm I rely too much on 32-bit software. 32-bit zilmar spec emulators are a great e...

I found out the code you were talking about in a fork of mupen64plus. It's hard to say whether the LUT is advantageous, because results differ a lot among scenarios and CPUs. It's really possible that the code with the LUT performs better in a real word application. Measuring the cpu time by hand i...

It can get a lot faster, but (IMO): Incremental changes/refactorings won't make a big difference. You really need to fundamentally change the plugin and do something quite radical (vectorize it with SSE, make a JIT/dynarec RDP, etc.). If you are wondering why dynarec RDP could help, consider that a...

Any reason why 128-bit (4xint) isn't sufficient? I don't think you'll find yourself working on more than one COLOR at a time, right? Well, the primary reason would be for code like TEX->r = t3.r + ((((invsf * (t2.r - t3.r)) + (invtf * (t1.r - t3.r))) + 0x10) >> 5); I know it's possible to do 32bit ...

Here's my attempt: #include <stdint.h> uint8_t nolut(uint8_t s, unsigned byteval) { unsigned sa = (s & 1) * 4; uint8_t c = byteval << sa; return (c >> 4) | (c & 0xF0); } Nice :D . I realized my example wasn't great ;/ . I spent quite some time this week, trying to see what I can do to speed up the ...

Hello izy :D ! I did some benchmarking and tested your LUT example vs your optimized C version of non-LUT example. I profiled Mario Party 1 and just played the intro (~121 seconds), since that game actually uses "case TEXEL_I4:" in fetch_texel. The LUT took ~142ms while the non-LUT took ~172ms. I th...

I think for now, it's best to just use OpenGL and just heavily optimize the current code base. I wouldn't bother with multi threading either, until the RSP and RDP have been significantly sped up. One good way to reduce the amount of branching is to use LUTs, like in my previous example. Fortunately...

From my perspective, current Cen64 RDP implementation (angrylion) have a lot of possible optimizations (first one is re factorize in order to benefit from CPU vectorization). I think you're right, but it would require a ton of work to see results. From what I've seen, quite a bit of the code is alr...

Well, I know that emulators like PJ64 stutter in intros/cut scenes while using CPU recompiler, especially when advanced block linking is enabled. So there are times where it has to compile a lot, for the cpu. Doesn't seem to be as big of a problem on 1964 (I think their recompiler is more optimized)...

Well, there aren't really any problems, but... there's some unimplemented RSP opcodes that I consider very important, namely LTV/STV (for some lighting effects, like in SM64) and maybe MTC0 (e.g. Mortal Kombat 4 doesn't work properly without it). If you want to help us with these, naturally. ;) Wel...

Speaking of which, where has AIO gone? His contributions to the opcodes have been very important to CEN64's development, what has happened to him? Is he done with it, or has he been busy with life/work too? I'm still around :D . I've just been preoccupied, to say the least. I'm not sure what I can ...

MarathonMan, are you using Intel 2015? I just tried it on a friend's machine and I saw some really strange results. In some ways 2015 improved, compared to 2013, but there seems to be some downsides. On the upside, it identifies more stuff, like JIT code is no longer labeled as unknown. But it's tel...

I'm not an expert in the VI, but: From an HLE prospective, you might be able to get away with just checking if the VI_ORIGIN didn't change and not re-rendering/re-computing the frame. Thanks! Tested it and seems like a decent solution for my standards :D . From a cycle-accurate perspective, you hav...

MarathonMan wrote:I'll probably start by deferring VI filters to another thread or something at first.

Speaking of VI filters, Angrylion's applies them every frame, even though most games are not 60 fps. Is there a feasible way to implement automatic frame skip for VI filters?

Nacho wrote:Well, from my testing:

SSE2 -> Affected
SSE3 -> Affected
SSE4.1 -> Not affected
SSSE3 -> Not affected

Well, that narrows it down quite a bit

. I'll take a look today to see if I can spot the mistake(s).

I knew it was a stretch, but I thought maybe an unlikely scenario could actually be true. I know that on zilmar spec emulators, with OpenGL plugins, I generally get less VI/s, but idk how threading works. I will have to learn about threading! Furthermore, if you compile CEN64 for Windows on Windows ...

Eckster wrote:Any hardware that requires it will not be sufficient to run CEN64 in the foreseeable future anyway.

Even if this is true (in my case it is), I'd still rather get closer to full speed

. Also it's a pain dealing with bugs due to hardware ;/ .

I've honestly had good experiences with using Intel's profiler. When I finally get around to compiling, I can try profiling as well. One thing I love about Intel's compiler is that it aggressively inlines :D . Could the performance difference on windows be because of OpenGL? I know that my hardware ...

I think

Code: Select all

Renderer: Intel 945G
Vendor: Intel
Version: 1.4.0 - Build 8.14.10.1930

is the problem unfortunately.

So.... As far as I know, CEN64 implements different vectorization methods depending on the different capabilities of the CPU. Right? Then, the same opcode is written twice for, let's say, SSE2 and AVX? When testing, should we try with different compiler options, in order to chase bugs? It's highly ...

I think you guys should wait until RSP is fixed up, before doing serious performance testing. These bugs could effect the VI/s for all we know. I've seen that happen before. Also the AVX code optimizations are not completely done :D . So the gap will only get wider. Also a good way to test RSP speed...

Alegend45 wrote:
Narann wrote:Impressive! I'm surprised about the darkness of the provided screenshots.

Silly question: No RDP rewrite? You will remain on the angrylion one?
The angrylion RDP is already pixel-accurate. What more could you want?

Speed

!

Cmon guys! N64 scene isn't that bad 8-) . I'd honestly be satisfied if my hardware didn't suck with z64gl ;/ . I'd say the biggest problems are not enough developers, not enough teamwork, and people not willing to take advantage of modern hardware. That last one mostly applies to graphics. Things wo...

As long as hardware like mine exist, I don't think Direct3D will ever be pointless.

Some of the vector clips, square roots, and others were actually incorrectly vectorized, I think. They're close, but there's a few edge cases that I think I missed. I've been trying to go through very, very carefully and find those at the moment. If there are errors in some of these instructions an...

I'm glad that I'm able to help :D . So i reviewed more of your code. For VGE I did /* equal = (~vco | ~vne) && (vs == vt) */ temp = _mm_and_si128(vne, vco); equal = _mm_cmpeq_epi16(vsReg, vtShuf); equal = _mm_andnot_si128(temp, equal); /* ge = vs > vt | equal */ greaterEqual = _mm_cmpgt_epi16(vsReg,...

Yes, not all of the functions are done... Lol just making sure I didn't miss anything :D . RE: VABS and VSUB, as long as you're willing to license under 3-clause BSD... sure. ;) Here are my former attempts: https://github.com/tj90241/cen64-rsp/blob/master/CP2.c#L251 https://github.com/tj90241/cen64...

Where can I find the latest RSP code for the SSE2 version? I'd like to take a closer look :D . It's scattered about in arch/x86_64/rsp. rsp.h/c contain some vector load/store shuffling/shifting/muxing algorithms (one taking advantage of pshufb/SSSE3, the other being SSE2). The rest of the intrinsic...

Where can I find the latest RSP code for the SSE2 version? I'd like to take a closer look

.

So will CEN64 benefit from this? Unfortunately emulators are generally not very vectorizable. If there's any part of CEN64 that might benefit from this, I'd say it'd be some of the RDP code, but I'll leave it to others who know more about the code to comment on that. On the plus side, this is just ...

Wow I must have been out of the loop! For a while, I've been looking at the RSP source on github

.

What needs to be done to have full SSE2 support for the RSP?

Great job so far!

Hi AIO, the RDP OpenGL backend is not being worked on at the mo, I got side tracked with HW RSP tests :( I am waiting for the latest cen64 to become more complete before I get back to work on this, my earlier attempt was just a proof of concept to show MarathonMan the speed increases when offloadin...

Search found 51 matches