Page 5 of 5 FirstFirst ... 345
Results 41 to 47 of 47
  1. #41
    EmuTalk Member
    Join Date
    Jun 2013
    Posts
    12
    Mentioned
    0 Post(s)
    Any chance of getting the upstream changes through r97?
    Last edited by tony971; October 16th, 2015 at 04:50. Reason: there have been more revisions since this was posted

  2. #42
    EmuTalk Member
    Join Date
    Apr 2013
    Posts
    3
    Mentioned
    0 Post(s)
    Is this plug in still being worked on?

  3. #43
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    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.)

  4. #44
    EmuTalk Member
    Join Date
    May 2016
    Posts
    1
    Mentioned
    0 Post(s)
    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

  5. #45
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    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.

  6. #46
    EmuTalk Member
    Join Date
    Jan 2013
    Posts
    7
    Mentioned
    0 Post(s)

    plugin futures

    Quote Originally Posted by Visor4 View Post
    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
    @visor

    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


    @Iconoclast

    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

  7. #47
    EmuTalk Member
    Join Date
    Jan 2013
    Posts
    7
    Mentioned
    0 Post(s)
    Quote Originally Posted by Visor4 View Post
    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


Page 5 of 5 FirstFirst ... 345

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •