SteamWar/Paper
13
0
Fork 0
geforkt von Mirrors/Paper
Code Issues Pull-Requests 1 Projekte Releases Wiki Aktivität
2dcae290df
Paper/Spigot-Server-Patches/0380-Optimize-Light-Recalculations.patch

78 Zeilen
4.0 KiB
Diff
Originalformat Normale Ansicht Verlauf

Disable use of Locks on main thread for DataPaletteBlock This should greatly improve performance by using a No Op lock while on the main thread. Vanilla always had a write lock on write operations, but we added a Read Lock during Async Chunks to make concurrent writes non fatal for Async Chunks. This means we added on a bunch of over head to all chunk read operations. This corrects that, as well as disabling the write lock while on main thread. It is a general rule that you do not touch a chunk async once it is loaded into the world, as we never had locks on the chunk before 1.13 even. So once we are on main, we don't expect concurrent access to begin with, so we don't need the write locks either.
2018-10-03 04:29:31 +02:00
From 1b776a800b336105e8b519498c9ad387a58035b0 Mon Sep 17 00:00:00 2001
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
From: Aikar <aikar@aikar.co>
Date: Fri, 28 Sep 2018 20:46:29 -0400
Subject: [PATCH] Optimize Light Recalculations
The server triggers light recalculations even if the new block
is the same as the old block. At this time, BlockData Properties
do not impact light calculations.
So the only way light should change, is if the block itself
changes from 1 block to another.
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
Also optimizes to not repeatedly look up the same chunk for
light lookups.
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
diff --git a/src/main/java/net/minecraft/server/Chunk.java b/src/main/java/net/minecraft/server/Chunk.java
Disable use of Locks on main thread for DataPaletteBlock This should greatly improve performance by using a No Op lock while on the main thread. Vanilla always had a write lock on write operations, but we added a Read Lock during Async Chunks to make concurrent writes non fatal for Async Chunks. This means we added on a bunch of over head to all chunk read operations. This corrects that, as well as disabling the write lock while on main thread. It is a general rule that you do not touch a chunk async once it is loaded into the world, as we never had locks on the chunk before 1.13 even. So once we are on main, we don't expect concurrent access to begin with, so we don't need the write locks either.
2018-10-03 04:29:31 +02:00
index 15a327923f..0b2d9a05f4 100644
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
--- a/src/main/java/net/minecraft/server/Chunk.java
+++ b/src/main/java/net/minecraft/server/Chunk.java
Disable use of Locks on main thread for DataPaletteBlock This should greatly improve performance by using a No Op lock while on the main thread. Vanilla always had a write lock on write operations, but we added a Read Lock during Async Chunks to make concurrent writes non fatal for Async Chunks. This means we added on a bunch of over head to all chunk read operations. This corrects that, as well as disabling the write lock while on main thread. It is a general rule that you do not touch a chunk async once it is loaded into the world, as we never had locks on the chunk before 1.13 even. So once we are on main, we don't expect concurrent access to begin with, so we don't need the write locks either.
2018-10-03 04:29:31 +02:00
@@ -348,7 +348,7 @@ public class Chunk implements IChunkAccess {
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
private void a(int i, int j, int k, int l) {
if (l > k && this.areNeighborsLoaded(1)) { // Paper
for (int i1 = k; i1 < l; ++i1) {
- this.world.c(EnumSkyBlock.SKY, new BlockPosition(i, i1, j));
+ this.world.updateBrightness(EnumSkyBlock.SKY, new BlockPosition(i, i1, j), this); // Paper
}
this.x = true;
Disable use of Locks on main thread for DataPaletteBlock This should greatly improve performance by using a No Op lock while on the main thread. Vanilla always had a write lock on write operations, but we added a Read Lock during Async Chunks to make concurrent writes non fatal for Async Chunks. This means we added on a bunch of over head to all chunk read operations. This corrects that, as well as disabling the write lock while on main thread. It is a general rule that you do not touch a chunk async once it is loaded into the world, as we never had locks on the chunk before 1.13 even. So once we are on main, we don't expect concurrent access to begin with, so we don't need the write locks either.
2018-10-03 04:29:31 +02:00
@@ -579,7 +579,7 @@ public class Chunk implements IChunkAccess {
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
} else {
if (flag1) {
this.initLighting();
- } else {
Remove Water optimization from the Light Optimizations case was found where it could cause light to become incorrect But we still get to optimize out any same block updates which reduces light operations
2018-09-29 04:37:43 +02:00
+ } else if (block != block1) { // Paper - Optimize light recalculations
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
this.runOrQueueLightUpdate(() -> { // Paper - Queue light update
int i1 = iblockdata.b(this.world, blockposition);
int j1 = iblockdata1.b(this.world, blockposition);
diff --git a/src/main/java/net/minecraft/server/World.java b/src/main/java/net/minecraft/server/World.java
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
index 13f69f1b82..4179ba7cd8 100644
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
--- a/src/main/java/net/minecraft/server/World.java
+++ b/src/main/java/net/minecraft/server/World.java
@@ -444,7 +444,7 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
} else {
IBlockData iblockdata2 = this.getType(blockposition);
- if (iblockdata2.b(this, blockposition) != iblockdata1.b(this, blockposition) || iblockdata2.e() != iblockdata1.e()) {
Remove Water optimization from the Light Optimizations case was found where it could cause light to become incorrect But we still get to optimize out any same block updates which reduces light operations
2018-09-29 04:37:43 +02:00
+ if (iblockdata.getBlock() != iblockdata2.getBlock() && iblockdata2.b(this, blockposition) != iblockdata1.b(this, blockposition) || iblockdata2.e() != iblockdata1.e()) { // Paper - optimize light recalculations
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
this.methodProfiler.a("checkLight");
chunk.runOrQueueLightUpdate(() -> this.r(blockposition)); // Paper - Queue light update
this.methodProfiler.e();
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
@@ -588,8 +588,9 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
}
if (this.worldProvider.g()) {
- for (i1 = k; i1 <= l; ++i1) {
- this.c(EnumSkyBlock.SKY, new BlockPosition(i, i1, j));
+ Chunk chunk = getChunkIfLoaded(i >> 4, j >> 4); // Paper
+ for (i1 = k; chunk != null && i1 <= l; ++i1) { // Paper
+ this.updateBrightness(EnumSkyBlock.SKY, new BlockPosition(i, i1, j), chunk); // Paper
}
}
@@ -2293,6 +2294,11 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
public boolean c(EnumSkyBlock enumskyblock, BlockPosition blockposition) {
// CraftBukkit start - Use neighbor cache instead of looking up
Chunk chunk = this.getChunkIfLoaded(blockposition.getX() >> 4, blockposition.getZ() >> 4);
+ // Paper start - optimize light updates where chunk is known
+ return updateBrightness(enumskyblock, blockposition, chunk);
+ }
+ public boolean updateBrightness(EnumSkyBlock enumskyblock, BlockPosition blockposition, Chunk chunk) {
+ // Paper end
if (chunk == null || !chunk.areNeighborsLoaded(1) /*!this.areChunksLoaded(blockposition, 17, false)*/) {
// CraftBukkit end
return false;
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
--
2.19.0
In neuem Issue referenzieren Permalink kopieren