Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Altazimuth

Members
 View Profile  See their activity

  • Content count

    759

  • Joined

  • Last visited

Posts posted by Altazimuth

  8. Posted

    11 hours ago, skillsaw said:

    Was looking to update -- did the dev build run? It's looking like the latest is still dated Apr 26.

    I've been trying to sort this out. Recent libpng updates have caused devbuilds to not work. I tried to fix it but failed to do so prior to the scheduled time last night. Hopefully it'll be sorted by next time. In the meantime have a manual build from me.

     

    Eternity_Master_2606a1.7z

    5

  9. Posted · Edited by Altazimuth

    It's live! The new DRDTeam build (about 19 hours from now) will have this officially in. Yes, I lied, I couldn't wait. Earlier today I made an important change that means that it scales far better with number of threads, both performance (faster) and CPU usage (lower). A sensible maximum at this stage is the number of physical cores your processor has. I did see some gains past that point on my 7950x but not that huge.

    I haven't tested this on a processor with E and P-cores and frankly I'm scared of what'll happen if I do.

    14

  11. Posted

    7 hours ago, dpJudas said:

    I never finished it for GZD due to too many drawers to port for me to bother, but I can highly recommend implementing that optimization too if you're up to it. :)

    I gave a stab at an incredibly simplistic attempt but couldn't quite figure out how to resolve rendering issues easily enough to bother. It seemed like some sort of persistent data was causing sprites to not render in the zones between the render context where the load balancing was happening. I'll probably pester GooberMan when he's freer.

    0

  13. Posted

    Edward850 got a Steam Deck and his crap experience using it to play Eternity prompted me to drastically improve the out-of-the box controller experience for that. You could try a devbuild if you want, though there's still stuff that needs improving (certain numeric fields only take input via kb). Either way it's much better than it used to be.

    1

  14. Posted

    Yeah honestly for the guy who ironed out all these multithreading kinks I really don't know what I'm doing to a large degree. Initial set-up was based on Rum & Raisin code and then the vast majority of it was coming up with novel solutions to issues reported to me by ThreadSanitizer.

    It should be beared in mind there's no thread joining here, just setting an atomic bool to true and releasing of a semaphore (at which point the threads will spin). The whole communication between the threads happens on the render end here, and on the main thread's end here.

    0

  15. Posted

    4 hours ago, dpJudas said:

    What are you synchronizing?

    Just the start/end of threaded rendering. I might be using terminology incorrectly here, to be fair. Any synchronising within the render threads should be at a minimum. All texture caching and such were moved outside rendering. Allocations are all for thread-local heaps, last I checked. There is a mutex for the global zone heap, but basically nothing uses it from within the render threads.

    0

  16. Posted

    12 hours ago, Andromeda said:

    Maybe you could make it so it autodetects which amount of threads is needed for the best performance

    Not sure how I'd figure out how to do this. Would require some wide-scale rewrites and even with that done I'm not sure I'd be confident in any sort of heuristics I could use to figure out what the best thread count it.

     

    10 hours ago, ValveMercenary said:

    I couldn't think of a better wad to try with, so I just resorted to the ol' NUTS.WAD

    I think NUTS is largely slow due to just how many monsters are thinking, rather than being rendered. It's definitely a combo but IIRC the thinking takes up way more time, meaning that faster rendering isn't gonna help toooo much.

    2

  17. Posted

    Glad to hear of the perf improvement! Sadly as long as the synchronisation time increase per thread is so large it'll end up outweighing the gradually-decreasing gains from increasing the number of render threads. If there's any way that people think I might be able to improve this then I'd owe you a debt of gratitude if you informed me of it.

    In other news I uploaded another build, though this only really folds in fixes from master. Most of the rendering changes were to tidy things up and make more things const.

    1

  20. Posted

    10 hours ago, skillsaw said:

    One possible issue with the menu:

    When using the left arrow key to set renderer threads to the maximum number from single threaded mode, renderer threads is set to 19 (max threads - 1) rather than maximum threads (20).

    Thanks for the report, fixed. Good to know it's running far better in Heartland. That was one of my targets, and some scenes really tested the performance. I won't generate a new build for solely this change just to keep things simpler in the case that there are crash reports to deal with soon.

    I'm half-tempted to make the contexts a number entry field to reduce the window recreation spam, but then there's no exact way to know the max thread count, and also number entry fields don't work if you're going controller-only which is something I've been trying to improve the experience for recently.

    1

  21. Posted · Edited by Altazimuth

    UPDATE: It's live! Get any devbuild from May or later to use it! https://devbuilds.drdteam.org/eternity/

     

    Well hi there. I just got done putting the final touches on my multithreaded renderer branch to make it actually usable! While I'd love to just sit on these changes forever and keep my mental state and blood pressure in check, I need people to actually test that I haven't introduced any extreme weirdness or crashes by making all these changes. To that end, it's time for a public beta! You may find the files at the bottom of the post, and the source is on the multithreaded-renderer-fixes branch if you wish to compile it yourself. In the meantime a brief explanation of the new settings and how to mess with them.

    • r_numcontexts: Video Options > Page 2 > Renderer Threads. This does what it says on the tin. The higher the number, the more render contexts there are. This number ranges from 1 to however many threads your CPU supports. The optimal number of threads will vary based on your CPU and how complex the scene you're rendering is. Do not assume that the highest number is the best.
      • Note that this number is technically off by one if you're talking about threads. It spawns one fewer than the number of contexts, because one context is actually run on the main thread.
      • Separately implemented from this, if you only have one render thread then the whole system acts as it used to. Everything is executed on the main thread.
    • r_sprprojstyle: Video Options > Page 2 > Sprite Projection Style. This has three settings, Default, Fast, and Thorough.
      • Default means Fast for 1 thread, or Thorough for more than 1 thread.
      • Fast is the classic Doom sprite projection style—if a subsector isn't visible in a given render context then it won't be renderered. This may cause sprites to have a cut-off appearance between the boundaries of render context windows. As the setting implies though, it is a fair bit faster than the Thorough setting.
      • Thorough will (generally) eliminate the issues seen in Fast. It works by not just considering sprites that have their centre in the sector being renderered, but anything whose hitbox (yes, it's based on hitbox radius instead of sprite size) is within the rendered sector. Previously-drawn sprites that frame are then cached to avoid redrawing. Though this can cause a reduction in performance in more heavy scenes compared to Fast, in your average vanilla WAD you're not likely to notice much of a difference.

    It's not in the menus, but if you want to compare FPS between settings you will want to set `d_drawfps` to `on`. If you have any scenes where the rendering glitches out where it didn't previously then the ideal thing to provide would be your resolution, number of contexts, any savegames that have the exact frame where the glitch is happening, and the WADs you're running it with. Crashes are much the same as above, though obviously you can't provide a save; the crash report application will give you further instruction on how best to report crashes.

     

    BUILDS:

    2023-05-01: Windows (x64)

    2023-04-30: Windows (x64)

    2023-04-29: macOS (x64), macOS (Apple Silicon)

    2023-04-28: Windows (x64)

     

    NOTE: There's no load balancing yet because I'm so tired, dude, just so tired. I just wanna show this off now that it seems mostly done. I was worried this was gonna take another year or so of off-and-on work but nope, it's working just fine seemingly.

     

    You can thank GooberMan for this existing at all. Without Rum & Raisin doom I wouldn't ever have managed this.

    51

  25. Posted · Edited by Altazimuth

    17 hours ago, rfomin said:

    Not yet, at least not in "Public Build 3".

    Are you sure you have Public Build 3? It's fixed in mine. Anyway, I will try and work on a hack to make Eternity behave the same as the rest of them. I already have one working, I just need to make sure it works properly.

    EDIT: It works properly in Eternity now.

    1
×