Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-162522

Setting render distance to values >8 chunks freezes the game for >1 second (minutes for higher values)

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • 19w46a
    • 19w39a, 19w40a, 19w42a, 19w44a, 19w45b
    • Community Consensus
    • Performance, Rendering
    • Very Important

      The bug

      This already happened in earlier versions, but ONLY when VBOs are disabled (that only happened on some GPU drivers, for example linux intel GPU drivers). That option has been removed in one of recent versions so this shouldn't be an issue anymore.

      I can reproduce it reliably every time now immediately after entering the world, but in the initial few tests, it appeared to happen only after a while of flying around the world (I don't know what actually triggered it).

      This was not an issue in 19w37a, it appears to be introduced in 19w38a

      It seems to coincide with MC not displaying GPU vendor and opengl version properly (screenshots showing this attached, it does show up correctly in crash report output).

      Running visualvm sampler shows that all of the time is spent in RenderSystem.glGenBuffers and subsequently GL15C.nglGenBuffers (sampler snapshot attached). As far as my understanding goes, this is very likely caused by requesting gl buffers separately for each render section, instead of all at once.

       

      Update: opengl version and vendor not being shown is a completely separate thing that doesn't affect anything. Appearing in the same snapshot was a coincidence.


      The reason

      After a bit of testing in mod development environment with latest snapshot, I was able to find a fix/workaround in code in GlStateManager. It's not exactly the best solution, but works really well in practice and requires very little code changes:

       

          private static final int GENBUFFERS_BATCH = 2048;
          private static IntBuffer BUFFERS;
      
          public static int genBuffers() {
              RenderSystem.assertThread(RenderSystem::isOnRenderThreadOrInit);
              if (BUFFERS == null || !BUFFERS.hasRemaining()) {
                  if (BUFFERS == null) {
                      BUFFERS = BufferUtils.createIntBuffer(GENBUFFERS_BATCH);
                  }
                  BUFFERS.rewind();
                  GL15.glGenBuffers(BUFFERS);
                  BUFFERS.rewind();
              }
              return BUFFERS.get();
          }
      

      This confirms that the issue is the huge amount of glGenBuffers calls, but it's still unclear to me why it's a performance issue to begin with, especially with glDeleteBuffers not being an issue at all.

      A good solution would be to allocate and delete all the chunk buffers in one glGenBuffers call but that doesn't work nicely with the way this code is written.

       -- 

      I also verified that this code didn't change in any significant way even since 1.12.2 so I really have no idea what has changed here that suddenntly makes this code path so much slower.

       

      After more debugging, this is the real reason (full explanation of how I found it in comments):

      Minecraft is binding already deleted VertexBuffers, which it internally assigns an ID of -1 to. This ends up changing mesa driver internal state in a way that always triggers a very slow code path for glGenBuffers.

       

       

        1. sampler_snapshot.nps
          5 kB
        2. forced_crash_19w40a.txt
          3 kB
        3. forced_crash_19w37a.txt
          2 kB
        4. 2019-11-11_22.30.43.png
          2019-11-11_22.30.43.png
          407 kB
        5. 2019-11-11_22.24.44.png
          2019-11-11_22.24.44.png
          412 kB
        6. 2019-11-11_08.45.41.png
          2019-11-11_08.45.41.png
          416 kB
        7. 2019-11-11_08.40.58.png
          2019-11-11_08.40.58.png
          415 kB
        8. 2019-11-11_08.36.51.png
          2019-11-11_08.36.51.png
          414 kB
        9. 2019-11-11_08.33.22.png
          2019-11-11_08.33.22.png
          405 kB
        10. 2019-11-11_08.30.15.png
          2019-11-11_08.30.15.png
          420 kB
        11. 2019-11-11_08.27.35.png
          2019-11-11_08.27.35.png
          399 kB
        12. 2019-11-11_08.25.12.png
          2019-11-11_08.25.12.png
          409 kB
        13. 2019-11-11_08.23.12.png
          2019-11-11_08.23.12.png
          414 kB
        14. 2019-11-11_08.21.25.png
          2019-11-11_08.21.25.png
          396 kB
        15. 2019-11-11_08.19.47.png
          2019-11-11_08.19.47.png
          413 kB
        16. 2019-11-11_08.18.27.png
          2019-11-11_08.18.27.png
          412 kB
        17. 2019-11-11_08.17.23.png
          2019-11-11_08.17.23.png
          409 kB
        18. 2019-11-11_08.16.31.png
          2019-11-11_08.16.31.png
          406 kB
        19. 2019-11-11_08.15.50.png
          2019-11-11_08.15.50.png
          410 kB
        20. 2019-11-11_08.15.08.png
          2019-11-11_08.15.08.png
          408 kB
        21. 2019-11-11_08.14.44.png
          2019-11-11_08.14.44.png
          425 kB
        22. 2019-11-11_08.14.15.png
          2019-11-11_08.14.15.png
          409 kB
        23. 2019-11-11_08.13.55.png
          2019-11-11_08.13.55.png
          417 kB
        24. 2019-11-11_08.13.43.png
          2019-11-11_08.13.43.png
          421 kB
        25. 2019-11-11_08.13.34.png
          2019-11-11_08.13.34.png
          411 kB
        26. 2019-11-11_08.13.24.png
          2019-11-11_08.13.24.png
          416 kB
        27. 2019-11-11_08.13.16.png
          2019-11-11_08.13.16.png
          415 kB
        28. 2019-11-11_08.13.10.png
          2019-11-11_08.13.10.png
          415 kB
        29. 2019-11-11_08.13.06.png
          2019-11-11_08.13.06.png
          412 kB
        30. 2019-11-11_08.13.02.png
          2019-11-11_08.13.02.png
          412 kB
        31. 2019-11-11_08.12.59.png
          2019-11-11_08.12.59.png
          412 kB
        32. 2019-11-11_08.12.57.png
          2019-11-11_08.12.57.png
          410 kB
        33. 2019-11-11_08.12.55.png
          2019-11-11_08.12.55.png
          375 kB
        34. 2019-11-11_08.12.11.png
          2019-11-11_08.12.11.png
          410 kB
        35. 2019-11-11_08.12.08.png
          2019-11-11_08.12.08.png
          372 kB
        36. 19w40a_noOpenglVersion.png
          19w40a_noOpenglVersion.png
          370 kB
        37. 19w37a_hasOpenglVersion.png
          19w37a_hasOpenglVersion.png
          408 kB

            fry [Mojang] Georgii Gavrichev
            Barteks2x Bartosz Skrzypczak
            Votes:
            5 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved:
              CHK: