Some crazy fun without GPU

Discussion in 'Planetary Annihilation General Discussion' started by SXX, September 5, 2013.

  1. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    I'm wanted to build some large planets before, but I only have 8GB of RAM on desktop and it's exhausted very fast and my videocard also only have 1GB. So I'm tested some crazy idea about running game in with limited RAM and without videocard.

    So there it is, only 4GB RAM (strictly limited using cgroups), 7GB SWAP used on HDD, only software rendering (Gallium3D LLVMpipe).
    One planet with range radius 100 and few small:
    planets_4gb_RAM_software_rendering.png
    One planet with radius 150:
    planet_4gb_RAM_software_rendering_FPS.png planet_4gb_RAM_software_rendering_2.png planet_4gb_RAM_software_rendering_3.jpg

    Probably one day I'll check in on very powerful server.
    maxpowerz and thatothermitch like this.
  2. Ortikon

    Ortikon Active Member

    Messages:
    414
    Likes Received:
    183
    that better be one dense star! lol.
    Awesome.
  3. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    Planet with radius 300, 33GB of virtual memory used, took about two hours to generate:
    planet_radius 300_software_rendering.png planet_radius 300_software_rendering_2.png planet_radius 300_software_rendering_3.png planet_radius 300_software_rendering_4.png
    Code:
    [00:27:27.833] INFO Building planet of radius 6200 detail 2
    [00:28:05.586] INFO 1673238 decals generated.
    [00:38:18.088] INFO 2960266 total planet faces.
    [00:42:00.533] INFO 26255 feature decals generated.
    [00:56:30.888] INFO 3263197 features generated.
    [00:56:31.682] INFO 1.74e+03 sec
        PlanetBuilder::buildAsync: 1.74e+03 sec
            GenSurface: 175. msec
            PreviewSurfaceIters: 3.18 sec
                genHeight: 86.4 msec
                computeWaterDistance: 1.53 sec
                genBiomes: 587. msec
                computeBiomeDistance: 956. msec
                computePoleDistance: 13.2 msec
                other: 17.6 usec
            UpdateBVH: 1.64 sec
            GenBrushes: 32.8 sec
                PostCopyDecals: 129. msec
                other: 32.7 sec
            PreCsg: 30.0 sec
                Create Surface Meshes: 5.73 sec
                    Connectivity: 4.48 sec
                    other: 1.25 sec
                other: 24.3 sec
            Csg: 587. sec
                UpdateBVH: 2.69 sec
                other: 585. sec
            GenWater: 22.6 sec
            BuildMeshes: 572. sec
                Final: 6.78 sec
                SetupVT: 562. sec
                Water: 2.90 sec
                other: 9.95 usec
            getFeatures: 278. sec
            Features: 198. sec
                generate: 183. sec
                PostCopyFeatureDecals: 14.9 sec
                other: 5.35 usec
            Flow Water: 11.8 sec
            other: 6.09 sec
        other: 5.81 usec
    build complete
    Last edited: September 5, 2013
    stormingkiwi likes this.
  4. rick104547

    rick104547 Member

    Messages:
    305
    Likes Received:
    17
    The scale of the atmosphere doesnt seem to scale with the scale of the planet. Is this getting changed later on? Kinda looks weird on larger planets.
  5. kryovow

    kryovow Well-Known Member

    Messages:
    1,112
    Likes Received:
    240
    weird? Look at earths atmosphere... 30 km for the lower parts of it and the radius is >6000 km :)
  6. rick104547

    rick104547 Member

    Messages:
    305
    Likes Received:
    17
    But it doesnt look consistent in this game. Small planet has a huge atmosphere and a big planet has a small atmosphere relative to each other.

    Now iam thinking of earth i think of clouds. Would those be ingame?
  7. Gorbles

    Gorbles Post Master General

    Messages:
    1,832
    Likes Received:
    1,421
    0.0 FPS, heh.
    thelowleypineapple likes this.
  8. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    I'm agree with what kryovow said and I'm don't see any problem with atmosphere feeling, but some other effects like clouds (even few and totally flat) will make planets even more awesome. But for me main problem is lack of lighting effects and big oceans and current planet generator not working on large planets as good as it work for small.
    Last edited: September 6, 2013
  9. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    It's 100% software rendering, CPU only and most of game swapping to HDD . I'm can't generate such big planet on my GPU because it's only have 1GB GDDR5 and will crash immediately even on radius 150-170...

    Probably when uber done some more advanced LOD system it's will be possible to view something like that on GPU, but currently it's just need too much memory for textures.

    PS: I'm also tried to generate 500 radius metal planet (10200 meters), but it's failed after eat 70GB of SWAP. :(
    Last edited: September 6, 2013
  10. extraammo

    extraammo Member

    Messages:
    57
    Likes Received:
    15
    It's... beautiful :')
  11. tatsujb

    tatsujb Post Master General

    Messages:
    12,902
    Likes Received:
    5,385
    how does all of this run? do you have to let the whole process run again if you want to pan around on a planet's surface?
    Can you do that at all? is it more or less responsive?
    so the 150 radius planet took ~30mins to render?
  12. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    Nope, game process still in memory partially, but memory pages which were accessed long ago moved to SWAP on HDD. There is nothing special in Linux about that, only difference it's easy to control swapping (and any other system resource usage) per process.

    I also think that system editor actually don't use all data about planets it's stored (e.g probably memory leaks is here), so partially data in SWAP just not being used at all.
    Most times toked by planet generation process and not software rendering, but yeah something like that.
    150 radius planet were more or less responsive, e.g few minutes to generate frame. 300 took something like 6-8 minutes per frame. Obviously it's not responsible at all, but I'm able to make cool screenshots. :D
    And yeah I'm able to control UI with radius 150 planet.

    I sure I'm can get much better responsibility if I'm give all 8GB and I/O to game, but I'm actually working on desktop in same time, so I'm only give game 4GB of RAM.

    Very easy:
    1. Run my normal Kubuntu 13.04 with latest Mesa from PPA.
    2. Increased swap size to 70GB.
    3. Install cgroup-bin package.
    4. Run PA this way:
      Code:
      LIBGL_ALWAYS_SOFTWARE=1 ./PA
    5. Now put memory and simple I/O limitation and check it:
      Code:
      sudo -i
      cgcreate -a $USER -g memory:patest
      echo 4294967296 > /sys/fs/cgroup/memory/patest/memory.limit_in_bytes
      cgclassify -g memory:patest/ `pidof PA`
      cat /proc/`pidof PA`/cgroup
      ionice -c 3 -p `pidof PA`
    6. Now run planet generation process.
    Few linux commands, but no magic in it, but you better to have pretty good processor and cooling. :)
    Also I'm think you can run game with LLVMPipe even if proprietary drivers installed, but you need preload correct GL lib for game.
    Last edited: September 6, 2013
    thatothermitch and tatsujb like this.
  13. tatsujb

    tatsujb Post Master General

    Messages:
    12,902
    Likes Received:
    5,385
    i do have a pretty good processor and cooling. but....what I'm really asking is in the future will GPU's dissapear entirely?

    if this method is as functional and fast as gpu-rendring then why gpu?

    why kubuntu in particular?
  14. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    Even if that ever happen that won't be result of software rendering.

    This method might be as functional as GPU rendering as long as all OpenGL extension supported in this open source driver. Currently it's don't even have full OpenGL 3 support, but have enough functionality to run PA.

    But software rendering will be never as fast as specialized GPUs.

    Because I'm KDE user, just that.

    That's even will work on Windows if you manage to compile Mesa with LLVMpipe there and then limit PA RAM usage somehow (I'm sure you can do that on Windows too).
    thatothermitch likes this.
  15. cwarner7264

    cwarner7264 Moderator Alumni

    Messages:
    4,460
    Likes Received:
    5,390
    Honestly, SSX, I think your definition of 'crazy fun' and mine are not quite the same thing ;)
  16. exterminans

    exterminans Post Master General

    Messages:
    1,881
    Likes Received:
    986
    It's only functional, but not fast.
    GPUs have not only about 10-20x more raw computation power than CPUs, the advantage is even bigger since there are a lot of tasks which are hardware accelerated on the GPU (e.g. rasterization, thats converting from polygons to pixels) while the CPU would have to use algorithms implemented in pure software for that task.

    If it wasn't for the lack of VRAM, the GPU would still outperform the CPU by a factor of 1,000 or more.
  17. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    I'm don't sure if VRAM size it's only limit which not let me generate extremely large planets. I know what post linked you there, so I'm very interested to know your opinion if you have one. ;)

    I'm don't think LLVMpipe works this way. As I understand from description and code it's more like GPU simulation and not reimplementing everything in software. It's just translate shaders code to run it on CPU. It's a point why it's build on top of Gallium3D.
    tatsujb likes this.
  18. exterminans

    exterminans Post Master General

    Messages:
    1,881
    Likes Received:
    986
    LLVMpipe is pure software, every piece of the GPU is emulated. Well, actually not the hardware is emulated, only the individual stages of the render pipeline, but thats bad enough. Rasterization and alike are usually performed on dedicated hardware for a good reason.

    And as for the performance:
    The GPU is just a lot faster at these tasks, that's undeniable. Memory bandwidth, streamlined pipeline, massive parallel execution of shaders, fitted instructionset, all that contributes and gives you a constant performance boost over any software renderer.
    I guess you actually ran out of VRAM for the geometry.
    Last edited: September 17, 2013
    tatsujb likes this.
  19. SXX

    SXX Post Master General

    Messages:
    6,896
    Likes Received:
    1,812
    It's just controversy about terminology. I just can't find exact words to explain what I mean. :oops:

    I want to say this: LLVMPipe doesn't change algorithms to run them on software, but convert low-end GPU commands and shaders to run them on CPU.

    Probably, just want find out what can help me to generate extremely large planets. :)
  20. exterminans

    exterminans Post Master General

    Messages:
    1,881
    Likes Received:
    986
    Try how far you can get with the --nofeatures option

Share This Page