Anyone looking to contribute?

Discuss topics related to development here.
Post Reply
User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Anyone looking to contribute?

Post by MarathonMan » Fri Jul 22, 2016 2:46 am

I have a couple RDP optimizations that can be done for anyone that's familiar with policy-based design (C++). Your contributions aren't exclusive to CEN64 and will possibly get swept up into Retroarch and maybe other HLE plugins.

If you're not familiar with policy-based design, that's OK... I'm willing to help point you in the right direction. Basically, you leverage the compiler to maintain a bunch of implementations of these particularly branch-y functions like the color combiner:

Code: Select all

#include <cstdint>
 
// Make policies some chromabypass; we either do it, or not.
template <bool kOtherModesKeyEn>
void combiner_1cycle_chromabypass();
 
template <>
void combiner_1cycle_chromabypass<false>() {}
 
template <>
void combiner_1cycle_chromabypass<true>() {
  chromabypass.r = *combiner_rgbsub_a_r[1];
  chromabypass.g = *combiner_rgbsub_a_g[1];
  chromabypass.b = *combiner_rgbsub_a_b[1];
}
 
// OK, here's the implementation for combiner_1cycle.
template <bool kOtherModesKeyEn>
void combiner_1cycle(int adseed, uint32_t* curpixel_cvg) {
 
  // Template magic! Use policies to specify whether this version
  // of the color combiner should do chroma bypass or not.
  combiner_1cycle_chromabypass<kOtherModesKeyEn>();
 
  // ...
}
 
// Then just generate a variants of combiner_1cycle
// and select amongst them with a list of function ptrs.
void (*combiner_1cycle_ptrs[])(int, uint32_t*) = {
  combiner_1cycle<true>,
  combiner_1cycle<false>
};
If nobody's willing, that's OK... I'll get around to it in a couple weeks. But hey, if you want to slap your name on some N64 optimizations, now's your chance!

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: Anyone looking to contribute?

Post by Narann » Mon Jul 25, 2016 9:02 am

I get the code but not what you expect from us. :mrgreen:

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Anyone looking to contribute?

Post by MarathonMan » Mon Jul 25, 2016 3:12 pm

Mostly just putting out a feeler to see if anyone is interested in doing angrylion RDP optimizations.

Though, when I tried to compile CEN64 with a C++ compiler, I was having issues... :(

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: Anyone looking to contribute?

Post by Narann » Mon Jul 25, 2016 3:46 pm

Is Angrylion not supposed to be C code? And why not rely on the retro arch port using Vulkan? I'm just wondering.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Anyone looking to contribute?

Post by MarathonMan » Mon Jul 25, 2016 7:49 pm

Narann wrote:Is Angrylion not supposed to be C code? And why not rely on the retro arch port using Vulkan? I'm just wondering.
angrylion uses C, I think. But for a codebase this small, it's easy to flip it to C++.

TBH, I don't have any graphics drivers that support Vulkan. :) If it's at all possible to do RDP on the CPU, I'd much prefer that if possible.

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: Anyone looking to contribute?

Post by Narann » Mon Jul 25, 2016 9:56 pm

MarathonMan wrote:angrylion uses C, I think. But for a codebase this small, it's easy to flip it to C++.
angrylion is quite hard to read and maintain. I would have suggest to start from scratch and use it as a reference (even if it's harder).
MarathonMan wrote:TBH, I don't have any graphics drivers that support Vulkan. :) If it's at all possible to do RDP on the CPU, I'd much prefer that if possible.
No problem. I realized, writing (and never finishing of course) a RDP emulator from scratch keeping multithreading (MT) in mind that rasterizer (RS) wouldn't be so easy to MT because of how it works. It's truly a scanline that require to have the previous line computed to fulfill its registers properly. I was wondering if there would have a way to predict RDP register values based on arbitrary lines (so you could render line packets on different threads) and can't figure out how but I'm not an expert (and I had to at least finish a first step of RDP emulation). Other per pixel operations should be easier to multithread (maybe on a tile based approach). Texture and filtering (TX and TF) would even be possible to vectorize (get every uv position for a particular texture, sample and filter).

But the fact retroarch guys succeed to properly emulate RS using vulkan would mean my scanline concerns are pointless.

User avatar
Matti
Posts: 13
Joined: Sun Jul 10, 2016 2:46 pm

Re: Anyone looking to contribute?

Post by Matti » Tue Jul 26, 2016 3:13 am

And we still have to wait if the Vulkan aproach is any faster that a good multithreaded aproach. Right now paraLLEl has many rendering errors, texture mapping problems and lockups (and it renders only a few games at 60VI/s for me). It is possible that the performance drops down more in later releases.

User avatar
Sintendo
Posts: 25
Joined: Thu Oct 31, 2013 9:11 am

Re: Anyone looking to contribute?

Post by Sintendo » Tue Jul 26, 2016 8:35 am

I'm a little confused by the array of function pointers. How will it be able to correctly handle changes to other_modes.key_en?

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Anyone looking to contribute?

Post by MarathonMan » Tue Jul 26, 2016 4:00 pm

Matti wrote:It is possible that the performance drops down more in later releases.
I have always thought that sync overhead is just going to be too much. If you had asked me if they were ever going to get this far, I would have completely disagreed.

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 will be their worst nightmare.
Sintendo wrote:I'm a little confused by the array of function pointers. How will it be able to correctly handle changes to other_modes.key_en?
It's only set by one RDP instruction (SET OTHER MODES) that is called rather infrequently. You swap in the function pointer at that point.

AIO
Posts: 51
Joined: Wed Nov 05, 2014 4:56 pm

Re: Anyone looking to contribute?

Post by AIO » Wed Jul 27, 2016 3:47 am

MarathonMan wrote: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 will be their worst nightmare.
The speed issue actually varies per game. I tried Bangaioh the other day and only got around 75 fps, with frame limiter removed. Consider that this game uses maybe 2-3% cpu on gfx RSp tasks while running at 60 fps and is almost entirely 2d graphics. Interestingly, some games that are far more rdp intensive in angrylion's, are full speed with the vulkan plugin, like killer instinct.

There's also the fact that mupen's cpu core is slow in some games.

What's wrong with mario golf, with the vulkan plugin?

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests