Page 48 of 48 FirstFirst ... 38464748
Results 706 to 715 of 715

Thread: Deep Rising Fx: Potential fluid simulator

  1. #706
    Quote Originally Posted by darkChief View Post
    The last frame took about 8-9 min (12 sub-steps per frame). Intel i5 four threads.
    hmm no gpu speedup?
    new web page up www.null.hr

  2. #707
    Registered User darkChief's Avatar
    Join Date
    Mar 2006
    Location
    Global
    Posts
    637
    The current GPU implementation should be able to do something similar if the card has enough memory, it didn't have the same memory limits. The only bottleneck is emitters, those didn't translate well to GPU, but working on that.

    The stability scales on the CPU solver now though. If you had the time you could sim 100,000,000 particles comfortably without worrying about the sim blowing up.

    So maybe distributed Sims in the future may happen.
    Last edited by darkChief; 10-19-2018 at 02:25 AM.

  3. #708
    Registered User Oldcode's Avatar
    Join Date
    Jan 2004
    Location
    Boston
    Posts
    383
    Hey Dark Chief,

    So, if you're using CPU to simulate the particles, the more cores the better? I have an 8 core system, but with Real Flow, they talk about some simulations where it's actually better to have a single core work on it because the process of splitting the simulation up between multiple cores can add a lot of overhead and actually slow the simulation down.

    Have you seen anything like that?

  4. #709
    Registered User darkChief's Avatar
    Join Date
    Mar 2006
    Location
    Global
    Posts
    637
    Quote Originally Posted by Oldcode View Post
    Hey Dark Chief,

    So, if you're using CPU to simulate the particles, the more cores the better? I have an 8 core system, but with Real Flow, they talk about some simulations where it's actually better to have a single core work on it because the process of splitting the simulation up between multiple cores can add a lot of overhead and actually slow the simulation down.

    Have you seen anything like that?
    The more cores you throw at Deep Rising the better. It scales nearly linearly. No splitting is necessary, every particle is part of one huge equation technically, one of the benefits of SPH.

    Splitting to my knowledge is normally used if you're using device's in different memory spaces (multiple GPU's, distributed computers).

  5. #710
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,441
    Quote Originally Posted by darkChief View Post
    The more cores you throw at Deep Rising the better. It scales nearly linearly. No splitting is necessary, every particle is part of one huge equation technically, one of the benefits of SPH.

    Splitting to my knowledge is normally used if you're using device's in different memory spaces (multiple GPU's, distributed computers).
    Might want to consider a basic NUMA topology check as well, most multipackage systems these days have dedicated memory per package, and thus use multiple distinct NUMA memory domains (f.e. my MacPro has two distinct NUMA memory domains, each attached to a single CPU package).

    In the case of multiple NUMA domains present, having multiple copies of working data (per NUMA domain) is significantly more efficient than forcing a process to reach across to another NUMA domain for memory access. Cache will mitigate somewhat, but cache tag churning also makes coherency between NUMA domains more costly/less efficient. If the main data set is too large to replicate entirely, consider replicating an "access window" of the data set per NUMA domain, and moving the windows around as needed.
    Last edited by jwiede; 10-21-2018 at 08:24 PM.
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  6. #711
    Registered User darkChief's Avatar
    Join Date
    Mar 2006
    Location
    Global
    Posts
    637
    Thanks for the tip, will look into it.

  7. #712
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,441
    What's the current compatibility story for DeepRising and LW2018 and/or LW2019? Do all versions "just work" or are specific versions needed for LW2019, etc?
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  8. #713
    Registered User darkChief's Avatar
    Join Date
    Mar 2006
    Location
    Global
    Posts
    637
    Quote Originally Posted by jwiede View Post
    What's the current compatibility story for DeepRising and LW2018 and/or LW2019? Do all versions "just work" or are specific versions needed for LW2019, etc?
    There's one plugin that works for LW2015-LW2019, and one compatibility version for LW 11. Both are included in a single download.

  9. #714
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,441
    Also, is there currently any support for either generating "wet maps" with DeepRising? Or, alternately, as node usable for surfacing and displacement (perhaps by setting to track fluid interaction with specific target object)?
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  10. #715
    Registered User darkChief's Avatar
    Join Date
    Mar 2006
    Location
    Global
    Posts
    637
    Quote Originally Posted by jwiede View Post
    Also, is there currently any support for either generating "wet maps" with DeepRising? Or, alternately, as node usable for surfacing and displacement (perhaps by setting to track fluid interaction with specific target object)?
    Not yet, wet maps I will have to implement at some point. I hadn't thought about incorporating it into the node system. Will add that to the feature requests.

Page 48 of 48 FirstFirst ... 38464748

Bookmarks

Posting Permissions

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