Open SvEgiiVEteR opened 8 years ago
I have the same problem. About %50 FPS drop going from 12e to 13b (only mod). Do you have a Radeon HD 4000 series graphics card? I have HD 4670.
I have HD 5770. leaves a lot of fps when looking down
Use VisualVM to get profiling data.
I used the Sampler tab, and Reika didn't tell me that was wrong. And make sure you're using DragonAPI v13 when you do it.
I need a site that actually works.
Run a longer sample, and what utility do you think I would get from this?
the light was turned off at home now.. will do .. the CPU? I don't know why 300 ms. 15 minutes I created the snapshot https://dl.dropboxusercontent.com/u/26268735/ShareX/2016/05/simpler.rar 1 888 000 ms + threaddump or https://dl.dropboxusercontent.com/u/26268735/ShareX/2016/05/snapshot-cpu-calltree.rar 5 999 000 ms look down 30-41 fps and log https://gist.github.com/7563f72283fac73b69047f20b6072556
tried DragonAPI 1.7.10 V14a.jar FPS drops too
Same here -- V14a same FPS drop.
tried DragonAPI 1.7.10 V14с.jar FPS drops too :(
Confirmed this. Only use Thermos + DragonAPI.
Only use Thermos + DragonAPI.
my tests FPS were in the single player game.
@ReikaKalseki @SvEgiiVEteR Oh...I test it in Server(Just a simple test, similar to the stand-alone. This is no different with the single...). But I think we can use some optimization mod like fastcraft, betterfps you know. This only occurs when I only installed DragonAPI.
@AuthMe fastcraft, betterfps - they did not help me. fps drops
Does it happen in a superflat with the default superflat preset?
@DaMachinator no. the default generation of the world.
So it doesn't happen on a superflat?
@DaMachinator DragonAPI 1.7.10 V14d.jar. look down and fps drops to 36(default generation) superflat 180 fps...
DragonAPI 1.7.10 V15a look down 30-41 fps ((((((((((
This may actually be caused by an IMPROVEMENT (less CPU requirements) in DragonAPI, so your CPU is throttling down. Try forcing your CPU to stay in it's lowest P-state (full speed), by disabling Cool & Quiet in your BIOS, or if you use MsrTweaker click the "Service" button and set the "P-state bounds" to 0 and 0.
It may also help to turn on "Advanced OpenGL" in your MC settings if you have that option.
@DaMachinator if "Advanced OpenGL" on. I have sometimes crashes the client...
Decidedly odd, that. Nonetheless I do have one more theory, that should be testable by running a lightly modded install on very bad hardware, as that should exacerbate it so that it is noticeable without DragonAPI if my theory is correct.
My theory is: You ALWAYS get an FPS drop when looking down. There's more stuff for the computer to render down there - caves, etc. However, normally the drop is too small to notice - until you install a large mod like DragonAPI. If this is true, the drop should also be noticeable on a vanilla, vanilla + forge only, or lightly modded install run on much worse hardware.
Advanced OpenGL was specifically designed to avoid that.
@DaMachinator I will be able to test your hypothesis to some extent in the next couple of days. However, this issue is not noticeable using DragonAPI v12, only using v13 or later so I doubt that this is the issue in any case. Unless v12 is so much less complicated that this goes from not noticeable at all to severely noticeable?
@ReikaKalseki I know it was designed to avoid rendering objects you can't actually see. However:
Maybe we should all post certain info about our computers, so we can find out what we (who have this problem) have in common. Here's the things I think we should list: Operating system CPU GPU Anti-Virus
Can anyone think of anything else?
How about HPET? Anyone else have their HPET on in the BIOS?
16a too
very bad fps (((
Note that looking down will ALWAYS cause an FPS drop, unless you have your FPS capped and it's still above the FPS cap. There are more blocks to render on and under the ground.
@DaMachinator 1 DragonAPI 1.7.10 V16d 2 also installed and removed(mod improves fps, but DragonAPI all breaks ) 3 included did not help,so I can play without OptiFine(makes worse fps), but without him the options that I have.
I have an Assembly DragonAPI 12 130 fps(looking down), mods 200 everything is OK. on the Assembly with 3 modes DragonAPI 1.7.10 V16d.jar InGameInfoXML-1.7.10-2.8.1.82-universal.jar LunatriusCore-1.7.10-1.1.2.21-universal.jar
20-40 fps(looking down) if up in the air 20 fps the author of the mod that broke with the above 12 version, and it seems unable or unwilling to fix...
UP fastcraft-1.23.jar + OptiFine_1.7.10_HD_U_D4.jar + enabling Advanced OpenGL it was 20-40 fps(looking down) if up in the air 20 fps now 50-60 fps(looking down) if up in the air 58 fps
but as you can see it's just a crutch. with 3 modes available.
DragonAPI 12 190 fps(looking down) if up in the air 190 fps DragonAPI 12 + enabling Advanced OpenGL 180 fps(looking down) if up in the air 180 fps
Note that looking down will ALWAYS cause an FPS drop, unless you have your FPS capped and it's still above the FPS cap. There are more blocks to render on and under the ground.
False. Minecraft doesn't render any chunks outside the view frustum, and solid blocks that are adjacent to other solid blocks get their faces culled. As such, you'd be rendering a small amount of grass, a couple caves, and maybe some lava if you're lucky. More than 99% of the blocks you're looking at simply won't be rendering at all.
I seem to be getting a fps halving when i add dragon api. Is this a known bug or could it be other mods i have conflicting. I thought it was a different mod of reika's, but i tested it just by adding dragonapi alone and that's what the cause was.
I never noticed this in earlier versions (Possibly because I wasn't paying attention), but for some reason, all blocks that are normally things like 'minecraft:blocks.dirt' are now 'dragonapi:minecraft:blocks.dirt'. I'm sure there's some important technical reason for that, and it may not be related at all to the fps, and if it is, it's unlikely to change.
1: That only applies to technical blocks, like off-state torches/repeaters. 2: That's done so that reika can render said blocks in his GUIs, because he doesn't want to make a separate texture for all of them. For example, the magnetostatic GUI has a button in it that cycles between high, low, and ignored redstone control. These states are represented by redstone torches, off-state redstone torches, and redstone dust respectively. 3: That's NOT the cause of this issue, but you are correct that it's unlikely to change.
Well, I'd be happy to provide any information I can to help resolve this issue, since it's crippling usability when FPS fluctuates so wildly; it makes me queezy.
my fps drops in half since the dragonapi. on a clean map, with 1 this mod. 12e ok
Well I got a new computer, and this is still an issue. I flew up to Y200 (view distance 10), and looked straight down. Tested using only mod DragonAPI. As the chunks are first loading, FPS stays around what it is with no mods (75 FPS), till about 75% (guessing) of the chunks have loaded, then it starts gradually going down, settling at 42 FPS before all chunks have loaded.
CPU: i5-6600 GPU: Radeon RX 480
Wait, so adding and removing CC fixes the issue....? Does this persist across reloads?
Sorry Reika, I had Vsync on, and it messed up my tests. (so i just deleted the whole comment)
Running into this issue as well, went from 400-500 fps without to 60-120 fps with.
Here's some profiler results both with:
and without DragonAPI:
Only other mods used were optifine and fastcraft with the only difference between the two results being whether or not DragonAPI was installed. Note that func_78419_a()
is actually net.minecraft.client.renderer.RenderList.callLists()
. It seems to take a marginal amount of time without DragonAPI and more time than everything else combined with DragonAPI.
Some more results with just DragonAPI:
Run 1:
Run 2:
Different results than last time for some reason and no idea what could be causing it, just that it is DragonAPI. Tried looking into it myself, but it seems like DragonAPI is way more invasive than I expected an "API" to be so I'm not too willing to look over all the changes. Plus, if this for sure happened in the 12e-13b transition, it should be relatively easy for Reika to go over the changes and see which caused it. I would totally try that myself too, but the infrequent, large, and cryptically named commits make it a pain. If this happens to every user it seems like this should be way higher priority than it seems like it is currently... 😞
... @ReikaKalseki
Wow I forgot just how inefficient normal MC rendering is, they really do not know how to make a rendering engine...
Either way, your stack traces imply two things:
First that an anomalous call is being injected via ASM with the name of doRender
, which is really slow, it seems it is being done from: https://github.com/ReikaKalseki/DragonAPI/blob/19a41c8f323c73b43a25dc3344ddd49dc8d391b3/ASM/Patchers/Hooks/Event/Render/EntityRender.java
Second, that the doRender call is slow because (assuming you have nothing but forge in the first image and nothing but forge and DragonAPI in the second) the OpenGL state is being left in an error state considering the GL11.glGetError()
time taken. This would be hard to trace down because it might not actually be 'in' doRender but would be caused by something rendering, however if all you have is just forge and dapi then it is likely a dapi opengl call (of which it has many) is not being cleaned up properly. It could also be caused by an excessive amount of OpenGL state push/pops instead of altering state smartly, but this would have to be pretty excessive to be that big anyway.
Would it be possible to attach an AMD or NVidia OpenGL debugger (depending on the video card you have) and report back and state errors it reports, or just in general dump as much information as is useful from it?
And yes, this slow-down happens to me as well with Reika's mods (though I've not tried just DAPI by itself), but I'm unable to test at moment, so if you could please @Joe12o . :-)
If you can point me to an NVIDIA OpenGL debugger, I'd be happy to. I've used gDEBugger in the past, but it seems like it died off. @OvermindDL1
@Joe12o As long as it supports your drivers then gDEBugger should be fine, MC's OpenGL is ancient anyway. Otherwise the official NVidia one is: https://developer.nvidia.com/nvidia-nsight-visual-studio-edition
Don't ask me how to use it though, I run AMD. ^.^
@OvermindDL1 Ah, alright. Might get to this tomorrow if I find the time for it. Looks like CodeXL is the successor to gDEBugger so I downloaded that, but need to figure out how to make it attach to a LWJGL process.
http://i.imgur.com/T7F5nh4.png http://i.imgur.com/OxXCOup.png drops fps when looking down... happens when i install DragonAPI 1.7.10 V13b.jar here is the config https://gist.github.com/7e6a017ef2c59ae5dd5a9d0ddd4d96e4 mod https://gist.github.com/f888ece36ecee702d8d49eb74b932088
without DragonAPI http://i.imgur.com/wvTy1kB.png http://i.imgur.com/aWxuk27.png
and only mod DragonAPI 13b: look down 30-40 fps look up 150 fps
and only mod DragonAPI 12e: look down 160-180 fps look up 230 fps