What's new

angrylion's Per-Pixel RDP with OpenGL

OP
Iconoclast

Iconoclast

New member
It's less that I stopped working on it, more that I stopped booting into an available Windows partition.

I'm more concerned at the moment with having available 64-bit emulators for Linux/GNU/etc. Mupen64Plus never succeeded at fixing this problem without choosing to replace the common plugin specifications after v1.5, but in both Project64 and my modifications to Mupen64 we should have available emulators to plug in and test 64-bit RCP emulation code. Then I can continue backporting a couple remaining upstream commits by angrylion, improving the OpenGL with GLSL shading constraints and more frame buffer acceleration, look at the scan-lines feature request, etc..

But this longer list of goals has made me comfortable enjoying the time with many other projects I've liked working on in the meantime. (Project64 not, in particular, being one of them, but I figured I'd overwhelm zilmar with pull requests and wait for him to get too busy to merge anything else large-scale from me so that I can conscientiously return to those.)
 

Visor4

New member
Hello Iconoclast,

Thanks for all your work on this plug-in. Definitely looking good so far! :)

Anyway, I noticed that this plug-in only utilizes one CPU core. Is there a reason why multiple cores can't be used? I have an Ivy Bridge Core i5 3570K, and the plug-in frequently maxes out the 25% one core limit. I can overclock it up to 4.8 GHz, but I'd rather just utilize my other 3 cores if possible.

Cheers,
Visor
 
OP
Iconoclast

Iconoclast

New member
Hi Visor4,


Multiple CPU cores could be used, but this involves deciding on several aspects:

  1. How much--if any at all--of the RDP code should really be done on the CPU? You could multi-thread it, but by the time someone were to contribute to the sources (in a variant like what maister has started), much of it could be processed on the video hardware which can leave whatever left for the CPU.
  2. Should multi-threading parallelize the complex phases of the RDP emulator with other such phases within itself? Should it parallelize the RDP to the RSP? Should it parallelize the RSP and/or RDP to the CPU? (Note that the last could natively solve some timing-specific RSP problems in certain titles.)
  3. Should the multi-threading be managed within plugin callback loops or within the main CPU core loop (e.g., an exe process)? This is especially relevant if the above question isn't answered with the first idea.
  4. Is management of the chosen multi-threading design scheduled better than native CPU management within the simpler single-threaded execution model, if the performance was fast enough such that only a single CPU core would be needed for full speed?
  5. How much benefit does multi-threaded pixel-accurate RDP emulation yield when weighed against the benefits of other optimizations remaining to be committed for the plugin in a single-threaded environment?


Items 2 and 5 are more interesting to me. Item 1 I can overlook because I am not--internally to this same plugin project--playing with hardware-accelerating the RDP like maister is. I prefer keeping it optimized while staying a software renderer, at least within this single plugin. Item 3 can be overlooked in an anti-plugin environmental model, such as RetroArch, where the RCP emulation is done within the same process image as the CPU core (which makes multi-threading easier to play with). Item 4 can temporarily be ignored due to the fact that, at present, this plugin does not run at full speed within one single CPU core on the majority of x64 processors.

But item 5 is really what I was trying to get back to with this plugin--it should be optimized to perform well even for people who either can't or do not want to use more than 1 CPU core or have it multi-threaded. Ideally, any realistic possibility of the plugin running at full speed without multi-threading should come to fruition. My current computer has only 2 CPU cores and is plagued by CPU overheat when too much is utilized, so I really do not want to have the plugin running on more than 1 CPU core in this computer's case even though I probably could. That's just for my rather arbitrary scenario, personally.

That being said, all my interests in fulfilling feature requests like scan-lines, GLSL accelerations, disabled DirectDraw renderer code to analogize performance against the new not-yet-released OpenGL blitter code, etc. have sort of overwhelmed me into a mixed state of business and procrastination. The plugin should still get another update, but I'll have to throw some of those feature requests out of my head temporarily to be able to concentrate to returning to it.
 

fla56

New member
plugin futures

Hello Iconoclast,

Thanks for all your work on this plug-in. Definitely looking good so far! :)

Anyway, I noticed that this plug-in only utilizes one CPU core. Is there a reason why multiple cores can't be used? I have an Ivy Bridge Core i5 3570K, and the plug-in frequently maxes out the 25% one core limit. I can overclock it up to 4.8 GHz, but I'd rather just utilize my other 3 cores if possible.

Cheers,
Visor

[MENTION=13647]visor[/MENTION]

my advice, go away and wait 3-4 years

multithreading a software RDP (as you suggest) is of course fundamentally the answer to accurate if somewhat inefficient N64 emulation

however do not hold your breath here as most of the Project64 scene is sadly too fragmented and political to get together to actually make a workable emu

i suspect as core counts continue increasing this particular plugin will fade away into irrelevance

others GPU-based ones like GlideN64 may eventually become great, ditto the Cen64 emu, perhaps with time an OpenCL plugin may come to fruition but this seems far away hardware-wise

[MENTION=54177]Iconoclast[/MENTION]

no hard feelings, jst telling it like i see it, happy to chum you my 980x if/when i go Skylake-E next year, as long as it goes to a good home
 

fla56

New member
Hello Iconoclast,

Thanks for all your work on this plug-in. Definitely looking good so far! :)

Anyway, I noticed that this plug-in only utilizes one CPU core. Is there a reason why multiple cores can't be used? I have an Ivy Bridge Core i5 3570K, and the plug-in frequently maxes out the 25% one core limit. I can overclock it up to 4.8 GHz, but I'd rather just utilize my other 3 cores if possible.

Cheers,
Visor

hey visor4 and here it is(!)

multithreaded Angrylion -now hitting 60fps with massive compatiblity for me on my 5 year old rig on virtually every game:
https://github.com/ata4/angrylion-rdp-plus
 

Top