Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Anubis-class Cruiser (12/20/24)

Poll

How is your Java 23 Experience?

It's great, working just like advertised
- 189 (55.1%)
It's better than vanilla
- 83 (24.2%)
It's making my game run worse
- 24 (7%)
I am still using Java 8 (JRE8)
- 47 (13.7%)

Total Members Voted: 343


Pages: 1 2 3 [4] 5 6 ... 13

Author Topic: [0.97a-RC11/0.96a-RC10] Mikohime Java 24  (Read 73252 times)

Shogouki

  • Captain
  • ****
  • Posts: 414
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #45 on: March 10, 2024, 05:34:58 PM »

I'm having some issues.  No errors or anything like that but my game is becoming choppy and I am getting ever increasing delay when opening my inventory whether it's at a station, in space or opening my Exotic Modifications box or shop at stations from the Exotica Technologies mod.  It doesn't happen at all when viewing my fleet or refit windows. 

I was using the 8GB option for VMParams and I tried the adaptive option as well to no avail.  I am running quite a few mods and only have 16GB of RAM but I make sure there's more than 8GB available for the game by shutting down any unnecessary programs beforehand.  However I did notice something in the command prompt window when starting up Starsector using your .bat file, though it's quite large so I'll place it behind a spoiler and the bits that I noticed that gave me pause I placed in bold:

Spoiler
Project : Rouge 26.4
Status  : Initializing
Loaded  : Miko_R3
Press any key to continue . . . OpenJDK 64-Bit Server VM warning: JVM cannot use large page memory because it does not have enough privilege to lock pages in memory.
[0.004s][info][gc] Min heap equals to max heap, disabling ShenandoahUncommit
-XX:AVX3Threshold=0 -XX:-AlignVector -XX:+AlwaysAtomicAccesses -XX:+AlwaysCompileLoopMethods -XX:+AlwaysPreTouch -XX:+AlwaysPreTouchStacks -XX:-BytecodeVerificationLocal -XX:-BytecodeVerificationRemote -XX:CompilerDirectivesFile=..\\mikohime/.rouge_owo -XX:-DebugInlinedCalls -XX:-DebugNonSafepoints -XX:+DisableExplicitGC -XX:-DontCompileHugeMethods -XX:-EnableThreadSMRStatistics -XX:+EnableVectorAggressiveReboxing -XX:+EnableVectorReboxing -XX:+EnableVectorSupport -XX:+EnableX86ECoreOpts -XX:+ErrorLogSecondaryErrorDetails -XX:+ExtensiveErrorReports -XX:IncreaseFirstTierCompileThresholdAt=99 -XX:InitialHeapSize=8589934592 -XX:InterpreterProfilePercentage=99 -XX:LockingMode=2 -XX:MaxGCPauseMillis=10 -XX:MaxHeapSize=8589934592 -XX:MinHeapSize=8589934592 -XX:NmethodSweepActivity=1 -XX:+ParallelRefProcEnabled -XX:PerMethodRecompilationCutoff=100000 -XX:+PrintCodeCache -XX:+PrintCommandLineFlags -XX:ProfileMaturityPercentage=100 -XX:+ReduceAllocationMerges -XX:ReferencesPerThread=0 -XX:ReservedCodeCacheSize=268435456 -XX:+SegmentedCodeCache -XX:ShenandoahAllocationThreshold=85 -XX:ShenandoahGCHeuristics=compact -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=0 -XX:+ShowCodeDetailsInExceptionMessages -XX:+ShowMessageBoxOnError -XX:ThreadPriorityPolicy=1 -XX:ThreadStackSize=4096 -XX:Tier0Delay=1 -XX:Tier0ProfilingStartPercentage=2000 -XX:+TieredCompilation -XX:TieredOldPercentage=10000 -XX:TieredStopAtLevel=4 -XX:TrimNativeHeapInterval=60000 -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:UseAVX=3 -XX:+UseBMI1Instructions -XX:+UseBMI2Instructions -XX:+UseCLMUL -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseCondCardMark -XX:+UseCriticalCompilerThreadPriority -XX:+UseCriticalJavaThreadPriority -XX:-UseDynamicNumberOfCompilerThreads -XX:+UseFMA -XX:+UseFPUForSpilling -XX:+UseFastStosb -XX:+UseFastUnorderedTimeStamps -XX:-UseLargePages -XX:+UseLargePagesIndividualAllocation -XX:UseSSE=4 -XX:+UseSSE42Intrinsics -XX:+UseShenandoahGC -XX:+UseStringDeduplication -XX:+UseUnalignedAccesses -XX:+UseUnalignedLoadStores -XX:+UseVectorCmov -XX:+UseVectorStubs -XX:+UseXMMForArrayCopy -XX:+UseXMMForObjInit -XX:+UseXmmI2D -XX:+UseXmmI2F -XX:-VerifyAdapterCalls -XX:-VerifyMethodHandles -XX:-VerifyReceiverTypes -XX:+ZeroTLAB
OpenJDK 64-Bit Server VM warning: UseAVX=3 is not supported on this CPU, setting it to UseAVX=2
OpenJDK 64-Bit Server VM warning: fast-string operations are not available on this CPU

[0.014s][info][gc] Heuristics ergonomically sets -XX:+ExplicitGCInvokesConcurrent
[0.014s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahImplicitGCInvokesConcurrent
[0.015s][info][gc] Using Shenandoah
[0.015s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahUncommit
[0.015s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahAlwaysClearSoftRefs
[0.016s][info][gc] Heuristics ergonomically sets -XX:ShenandoahImmediateThreshold=100
[0.016s][info][gc] Heuristics ergonomically sets -XX:ShenandoahUncommitDelay=1000
[0.016s][info][gc] Heuristics ergonomically sets -XX:ShenandoahGarbageThreshold=10
2 compiler directives added
WARNING: package java.nio.Buffer.UNSAFE not in java.base
WARNING: package java.awt.Rectangle not in java.desktop
[0.998s][warning][trimnative] Native heap trim is not supported on this platform
[close]

I have no idea if any of the JDK notices are relevant or the warnings at the end but being that I'm not a programmer I figured I'd at least ask if any of that seemed abnormal.  If it's helpful I'm running on an r7 3700x.  I also tried the suggestions in the troubleshooting part of your FAQ but it didn't seem to have an effect on performance except that with vsync off I did notice the screen tearing.

Aside from the choppiness and delay when opening inventory everything else seems to run ok.  I can also post the mods I'm using if that would be helpful too.
the warning is normal, it just mean it cannot use large page..
there is a known issue caused by Roider rn that make Inventory opening to be slow, as for game becoming choppy.. it depend on modlist as GC isnt omnipotent to clean memory..
increasing the size may help but narrowing down the mod that cause it would be better.
(usual culprit are Adjusted Sector being too big or RAT density sector on some case)

Thanks for the help!  Roiders are in my current game so that certainly explains the inventory lag, and what an odd bug that is.  I also did attempt this game with 150% stars in RAT so that could very well be the choppiness in general, though it wasn't choppy at the start (I don't think) but now that I'm about an ingame year into this one it's very noticeable.  I should note though that I have colonization deactivated until I start mine so no one has expanded their faction size yet.  I'll have to experiment later to try to find the cause but I won't be able to use my PC for about a week so I won't be able to report for a bit.


Having exact same issue.
Disabling roiders helped with inventory lag. But even without it, with every cycle fps gets hit, im at 216 cycle and game averages around 30 fps. Also running RAT at 200% constellation generation, but FPS was fine and the beginning of the game. I have around 50 mods activated. Changing vmparams to adaptive and rising the memory limit didnt help. I also enabled vsync back on because i couldn't stand screen tearing.

ATM im trying at default sector generation but it feels so empty lol

I've also noticed that process uses at most 20% of CPU and GPU. Out of 12 logical cpus only three are working and one is ultra sweaty sitting around 100% usage.

Well Starsector isn't a game that makes significant use of multi/hyper-threading so a lot of performance is going to depend on how much single core performance your CPU has.

The bit about the game not utilizing much CPU or GPU while still becoming bogged down is interesting though.  This was something I commented on after I started using this and noticed that my GPU wasn't being utilized nearly as much as with Java 8.
Logged

briansd9

  • Ensign
  • *
  • Posts: 47
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #46 on: March 10, 2024, 07:30:20 PM »

Hmm, I don't have FPS problems, but the loading time at startup really grinds my gears... does this mod improve that as well?
Logged

Dadada

  • Admiral
  • *****
  • Posts: 581
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #47 on: March 11, 2024, 01:15:31 PM »

Hmm, I don't have FPS problems, but the loading time at startup really grinds my gears... does this mod improve that as well?
Unexpectedly, yes. I never expected it to do so but it actually does. It's still laughably long with a long mod list but a lot shorter compared to Java 7/8.
Logged

Luminiferous

  • Ensign
  • *
  • Posts: 3
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #48 on: March 12, 2024, 02:19:01 PM »

Heya, I have a bit of a bug right here with this Java Version. To be specific, it fails to save the game:

Code
427189 [Thread-2] INFO  com.fs.starfarer.campaign.save.CampaignGameManager  - Renaming [campaign.xml] to [campaign.xml.bak]
427189 [Thread-2] INFO  com.fs.starfarer.campaign.save.CampaignGameManager  - Renaming [descriptor.xml] to [descriptor.xml.bak]
427248 [Thread-2] INFO  com.fs.starfarer.campaign.save.CampaignGameManager  - Error saving game
427248 [Thread-2] ERROR com.fs.starfarer.campaign.save.CampaignGameManager  - File rename failed. Your current save may be corrupted, but should be manually recoverable.

Please try saving again using the "Save Copy" option from the campaign menu - this should create a valid save file.
com.fs.starfarer.util.class: File rename failed. Your current save may be corrupted, but should be manually recoverable.

Please try saving again using the "Save Copy" option from the campaign menu - this should create a valid save file.
        at com.fs.starfarer.campaign.save.CampaignGameManager.o00000(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.campaign.save.CampaignGameManager.o00000(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.campaign.CampaignState.processInput(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.BaseGameState.traverse(Unknown Source) ~[port_obf.jar:?]
        at com.fs.state.AppDriver.begin(Unknown Source) ~[port.common_obf.jar:?]
        at com.fs.starfarer.combat.CombatMain.main(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.StarfarerLauncher.super(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.StarfarerLauncher$1.run(Unknown Source) ~[port_obf.jar:?]
        at java.base/java.lang.Thread.run(Thread.java:1575) [?:?]

According to this log, it fails to rename the descriptor.xml, and indeed this file is locked by the Java Process (C:\Program Files (x86)\Fractal Softworks\Starsector\jdk-23+7\bin\java.exe). Even more interesting, this file stays locked, even when I go to the main menu. So it seems like java is just reading the file while loading it, but then never unlocks the file afterwards. This issue isn't present on Java 7 or Java 8 LTS
Logged

Himemiko

  • Lieutenant
  • **
  • Posts: 50
  • a very clumsy miko
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #49 on: March 12, 2024, 06:10:41 PM »

Heya, I have a bit of a bug right here with this Java Version. To be specific, it fails to save the game:

Code
427189 [Thread-2] INFO  com.fs.starfarer.campaign.save.CampaignGameManager  - Renaming [campaign.xml] to [campaign.xml.bak]
427189 [Thread-2] INFO  com.fs.starfarer.campaign.save.CampaignGameManager  - Renaming [descriptor.xml] to [descriptor.xml.bak]
427248 [Thread-2] INFO  com.fs.starfarer.campaign.save.CampaignGameManager  - Error saving game
427248 [Thread-2] ERROR com.fs.starfarer.campaign.save.CampaignGameManager  - File rename failed. Your current save may be corrupted, but should be manually recoverable.

Please try saving again using the "Save Copy" option from the campaign menu - this should create a valid save file.
com.fs.starfarer.util.class: File rename failed. Your current save may be corrupted, but should be manually recoverable.

Please try saving again using the "Save Copy" option from the campaign menu - this should create a valid save file.
        at com.fs.starfarer.campaign.save.CampaignGameManager.o00000(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.campaign.save.CampaignGameManager.o00000(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.campaign.CampaignState.processInput(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.BaseGameState.traverse(Unknown Source) ~[port_obf.jar:?]
        at com.fs.state.AppDriver.begin(Unknown Source) ~[port.common_obf.jar:?]
        at com.fs.starfarer.combat.CombatMain.main(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.StarfarerLauncher.super(Unknown Source) ~[port_obf.jar:?]
        at com.fs.starfarer.StarfarerLauncher$1.run(Unknown Source) ~[port_obf.jar:?]
        at java.base/java.lang.Thread.run(Thread.java:1575) [?:?]

According to this log, it fails to rename the descriptor.xml, and indeed this file is locked by the Java Process (C:\Program Files (x86)\Fractal Softworks\Starsector\jdk-23+7\bin\java.exe). Even more interesting, this file stays locked, even when I go to the main menu. So it seems like java is just reading the file while loading it, but then never unlocks the file afterwards. This issue isn't present on Java 7 or Java 8 LTS
Hi!, this seems to be permission issue, you need to run the rouge with admin permission..
if issue still persist you also need to change the java.exe inside jdk-23+7/bin/ to have admin access through properties...
if none of that still not giving it permission.. your choice seems to be only moving the game out of program files to somewhere else...
Logged

alexcalibur

  • Ensign
  • *
  • Posts: 1
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #50 on: March 13, 2024, 04:11:36 PM »

Spoiler
The system cannot find the path specified.
Project : Rouge 26.4
Status  : Initializing
Loaded  : Miko_R3
Press any key to continue . . . OpenJDK 64-Bit Server VM warning: JVM cannot use large page memory because it does not have enough privilege to lock pages in memory.
[0.002s][info][gc] Min heap equals to max heap, disabling ShenandoahUncommit
-XX:AVX3Threshold=0 -XX:-AlignVector -XX:+AlwaysAtomicAccesses -XX:+AlwaysCompileLoopMethods -XX:+AlwaysPreTouch -XX:+AlwaysPreTouchStacks -XX:-BytecodeVerificationLocal -XX:-BytecodeVerificationRemote -XX:CompilerDirectivesFile=..\\mikohime/.rouge_owo -XX:-DebugInlinedCalls -XX:-DebugNonSafepoints -XX:+DisableExplicitGC -XX:-DontCompileHugeMethods -XX:-EnableThreadSMRStatistics -XX:+EnableVectorAggressiveReboxing -XX:+EnableVectorReboxing -XX:+EnableVectorSupport -XX:+EnableX86ECoreOpts -XX:+ErrorLogSecondaryErrorDetails -XX:+ExtensiveErrorReports -XX:IncreaseFirstTierCompileThresholdAt=99 -XX:InitialHeapSize=8589934592 -XX:InterpreterProfilePercentage=99 -XX:LockingMode=2 -XX:MaxGCPauseMillis=10 -XX:MaxHeapSize=8589934592 -XX:MinHeapSize=8589934592 -XX:NmethodSweepActivity=1 -XX:+ParallelRefProcEnabled -XX:PerMethodRecompilationCutoff=100000 -XX:+PrintCodeCache -XX:+PrintCommandLineFlags -XX:ProfileMaturityPercentage=100 -XX:+ReduceAllocationMerges -XX:ReferencesPerThread=0 -XX:ReservedCodeCacheSize=268435456 -XX:+SegmentedCodeCache -XX:ShenandoahAllocationThreshold=85 -XX:ShenandoahGCHeuristics=compact -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=0 -XX:+ShowCodeDetailsInExceptionMessages -XX:+ShowMessageBoxOnError -XX:ThreadPriorityPolicy=1 -XX:ThreadStackSize=4096 -XX:Tier0Delay=1 -XX:Tier0ProfilingStartPercentage=2000 -XX:+TieredCompilation -XX:TieredOldPercentage=10000 -XX:TieredStopAtLevel=4 -XX:TrimNativeHeapInterval=60000 -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:UseAVX=3 -XX:+UseBMI1Instructions -XX:+UseBMI2Instructions -XX:+UseCLMUL -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseCondCardMark -XX:+UseCriticalCompilerThreadPriority -XX:+UseCriticalJavaThreadPriority -XX:-UseDynamicNumberOfCompilerThreads -XX:+UseFMA -XX:+UseFPUForSpilling -XX:+UseFastStosb -XX:+UseFastUnorderedTimeStamps -XX:-UseLargePages -XX:+UseLargePagesIndividualAllocation -XX:UseSSE=4 -XX:+UseSSE42Intrinsics -XX:+UseShenandoahGC -XX:+UseStringDeduplication -XX:+UseUnalignedAccesses -XX:+UseUnalignedLoadStores -XX:+UseVectorCmov -XX:+UseVectorStubs -XX:+UseXMMForArrayCopy -XX:+UseXMMForObjInit -XX:+UseXmmI2D -XX:+UseXmmI2F -XX:-VerifyAdapterCalls -XX:-VerifyMethodHandles -XX:-VerifyReceiverTypes -XX:+ZeroTLAB
OpenJDK 64-Bit Server VM warning: UseAVX=3 is not supported on this CPU, setting it to UseAVX=2
OpenJDK 64-Bit Server VM warning: UseXMMForObjInit requires SSE2 and unaligned load/stores. Feature is switched off.
[0.008s][info][gc] Heuristics ergonomically sets -XX:+ExplicitGCInvokesConcurrent
[0.008s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahImplicitGCInvokesConcurrent
[0.008s][info][gc] Using Shenandoah
[0.008s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahUncommit
[0.008s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahAlwaysClearSoftRefs
[0.009s][info][gc] Heuristics ergonomically sets -XX:ShenandoahImmediateThreshold=100
[0.009s][info][gc] Heuristics ergonomically sets -XX:ShenandoahUncommitDelay=1000
[0.009s][info][gc] Heuristics ergonomically sets -XX:ShenandoahGarbageThreshold=10
Could not load file: ..\\mikohime/.rouge_owo
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
[close]

It seems that my system cannot find the path to the jre. I've checked environment vairables and there's no mention of anything java related.
Any idea how I should fix this? Thanks in advance.

EDIT: It seems I cannot read. Disregard lol
« Last Edit: March 13, 2024, 04:45:33 PM by alexcalibur »
Logged

Antrex

  • Ensign
  • *
  • Posts: 1
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #51 on: March 14, 2024, 09:01:02 AM »

The system cannot find the path specified.
Project : Rouge 26.4
Status  : Initializing
Loaded  : Miko_R3
Press any key to continue . . . OpenJDK 64-Bit Server VM warning: JVM cannot use large page memory because it does not have enough privilege to lock pages in memory.
[0.003s][info][gc] Min heap equals to max heap, disabling ShenandoahUncommit
-XX:AVX3Threshold=0 -XX:-AlignVector -XX:+AlwaysAtomicAccesses -XX:+AlwaysCompileLoopMethods -XX:+AlwaysPreTouch -XX:+AlwaysPreTouchStacks -XX:-BytecodeVerificationLocal -XX:-BytecodeVerificationRemote -XX:CompilerDirectivesFile=..\\mikohime/.rouge_owo -XX:-DebugInlinedCalls -XX:-DebugNonSafepoints -XX:+DisableExplicitGC -XX:-DontCompileHugeMethods -XX:-EnableThreadSMRStatistics -XX:+EnableVectorAggressiveReboxing -XX:+EnableVectorReboxing -XX:+EnableVectorSupport -XX:+EnableX86ECoreOpts -XX:+ErrorLogSecondaryErrorDetails -XX:+ExtensiveErrorReports -XX:IncreaseFirstTierCompileThresholdAt=99 -XX:InitialHeapSize=4294967296 -XX:InterpreterProfilePercentage=99 -XX:LockingMode=2 -XX:MaxGCPauseMillis=10 -XX:MaxHeapSize=4294967296 -XX:MinHeapSize=4294967296 -XX:NmethodSweepActivity=1 -XX:+ParallelRefProcEnabled -XX:PerMethodRecompilationCutoff=100000 -XX:+PrintCodeCache -XX:+PrintCommandLineFlags -XX:ProfileMaturityPercentage=100 -XX:+ReduceAllocationMerges -XX:ReferencesPerThread=0 -XX:ReservedCodeCacheSize=268435456 -XX:+SegmentedCodeCache -XX:ShenandoahAllocationThreshold=85 -XX:ShenandoahGCHeuristics=compact -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=0 -XX:+ShowCodeDetailsInExceptionMessages -XX:+ShowMessageBoxOnError -XX:ThreadPriorityPolicy=1 -XX:ThreadStackSize=4096 -XX:Tier0Delay=1 -XX:Tier0ProfilingStartPercentage=2000 -XX:+TieredCompilation -XX:TieredOldPercentage=10000 -XX:TieredStopAtLevel=4 -XX:TrimNativeHeapInterval=60000 -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:UseAVX=3 -XX:+UseBMI1Instructions -XX:+UseBMI2Instructions -XX:+UseCLMUL -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseCondCardMark -XX:+UseCriticalCompilerThreadPriority -XX:+UseCriticalJavaThreadPriority -XX:-UseDynamicNumberOfCompilerThreads -XX:+UseFMA -XX:+UseFPUForSpilling -XX:+UseFastStosb -XX:+UseFastUnorderedTimeStamps -XX:-UseLargePages -XX:+UseLargePagesIndividualAllocation -XX:UseSSE=4 -XX:+UseSSE42Intrinsics -XX:+UseShenandoahGC -XX:+UseStringDeduplication -XX:+UseUnalignedAccesses -XX:+UseUnalignedLoadStores -XX:+UseVectorCmov -XX:+UseVectorStubs -XX:+UseXMMForArrayCopy -XX:+UseXMMForObjInit -XX:+UseXmmI2D -XX:+UseXmmI2F -XX:-VerifyAdapterCalls -XX:-VerifyMethodHandles -XX:-VerifyReceiverTypes -XX:+ZeroTLAB
OpenJDK 64-Bit Server VM warning: UseAVX=3 is not supported on this CPU, setting it to UseAVX=2
OpenJDK 64-Bit Server VM warning: UseXMMForObjInit requires SSE2 and unaligned load/stores. Feature is switched off.
[0.012s][info][gc] Heuristics ergonomically sets -XX:+ExplicitGCInvokesConcurrent
[0.012s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahImplicitGCInvokesConcurrent
[0.013s][info][gc] Using Shenandoah
[0.013s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahUncommit
[0.014s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahAlwaysClearSoftRefs
[0.014s][info][gc] Heuristics ergonomically sets -XX:ShenandoahImmediateThreshold=100
[0.014s][info][gc] Heuristics ergonomically sets -XX:ShenandoahUncommitDelay=1000
[0.014s][info][gc] Heuristics ergonomically sets -XX:ShenandoahGarbageThreshold=10
Could not load file: ..\\mikohime/.rouge_owo
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

keep getting this error

Edit: I am hella stupid
« Last Edit: March 14, 2024, 09:13:18 AM by Antrex »
Logged

cesuoking

  • Ensign
  • *
  • Posts: 23
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #52 on: March 15, 2024, 04:01:12 PM »

The game is definitely faster when running but loading took a lot more time
Logged

Jazuke Taizago

  • Ensign
  • *
  • Posts: 48
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #53 on: March 15, 2024, 04:58:42 PM »

To me. This doesn't seem to do anything. Yes, i use GraphicsLib. Now, i followed every instructions to the exact details, and also looked around here for options and means to see any improvement. Such as disabling GraphicLib's Bloom. While also disabling VSync, GLFlush, GLFinish and forcenoVBO. I just took your FPS limit which was 1000, why not? Was using 8GB VRam, changed to 6GB VRam to see if that stopped my mini-stuttering, but no dice. I have been living with this mini-stuttering for as long as i can remember.

Playing with slightly above 110 Mods. Tried counting them all, kind of lost track the exact number but it's slightly above that.

It's sad that this doesn't really help me in any way that i know of.
Logged

Noir

  • Ensign
  • *
  • Posts: 10
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #54 on: March 15, 2024, 10:51:41 PM »

To me. This doesn't seem to do anything. Yes, i use GraphicsLib. Now, i followed every instructions to the exact details, and also looked around here for options and means to see any improvement. Such as disabling GraphicLib's Bloom. While also disabling VSync, GLFlush, GLFinish and forcenoVBO. I just took your FPS limit which was 1000, why not? Was using 8GB VRam, changed to 6GB VRam to see if that stopped my mini-stuttering, but no dice. I have been living with this mini-stuttering for as long as i can remember.

Playing with slightly above 110 Mods. Tried counting them all, kind of lost track the exact number but it's slightly above that.

It's sad that this doesn't really help me in any way that i know of.

From my very basic understanding, the main problem I think is playing with 110 mods and only having 6GB ram allocated to it. You might want to increase that to 11GB+ for a more smooth experience. If budgeting that much still doesn't work, then your CPU definitely needs upgrading (and if it's high end already, time to decrease the amount of mods).
Logged

Jazuke Taizago

  • Ensign
  • *
  • Posts: 48
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #55 on: March 16, 2024, 01:37:03 AM »

To me. This doesn't seem to do anything. Yes, i use GraphicsLib. Now, i followed every instructions to the exact details, and also looked around here for options and means to see any improvement. Such as disabling GraphicLib's Bloom. While also disabling VSync, GLFlush, GLFinish and forcenoVBO. I just took your FPS limit which was 1000, why not? Was using 8GB VRam, changed to 6GB VRam to see if that stopped my mini-stuttering, but no dice. I have been living with this mini-stuttering for as long as i can remember.

Playing with slightly above 110 Mods. Tried counting them all, kind of lost track the exact number but it's slightly above that.

It's sad that this doesn't really help me in any way that i know of.

From my very basic understanding, the main problem I think is playing with 110 mods and only having 6GB ram allocated to it. You might want to increase that to 11GB+ for a more smooth experience. If budgeting that much still doesn't work, then your CPU definitely needs upgrading (and if it's high end already, time to decrease the amount of mods).

Hmm. My PC specs are this.

GPU: Nvidia Geforce 2080 Ti, i have two of them.
Processor: Intel i9-9900 3.60 GHz, 16 CPUs
Memory: 32 GB
Starsector's Drive it sits at: 1.80 T SSD. 439 GB remains.

Let me know if there is more details that are important other than these three.

If having 110 Mods are too much, despite following every kind of Guide there is or that i could find, helps not. And i am overreaching the limits, such as not giving enough VRam, then alright. The vague guide saying that 8 GB lets you play with most Mods really means no more than 90 Mods, probably.
Logged

Himemiko

  • Lieutenant
  • **
  • Posts: 50
  • a very clumsy miko
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #56 on: March 16, 2024, 08:45:44 AM »

To me. This doesn't seem to do anything. Yes, i use GraphicsLib. Now, i followed every instructions to the exact details, and also looked around here for options and means to see any improvement. Such as disabling GraphicLib's Bloom. While also disabling VSync, GLFlush, GLFinish and forcenoVBO. I just took your FPS limit which was 1000, why not? Was using 8GB VRam, changed to 6GB VRam to see if that stopped my mini-stuttering, but no dice. I have been living with this mini-stuttering for as long as i can remember.

Playing with slightly above 110 Mods. Tried counting them all, kind of lost track the exact number but it's slightly above that.

It's sad that this doesn't really help me in any way that i know of.

From my very basic understanding, the main problem I think is playing with 110 mods and only having 6GB ram allocated to it. You might want to increase that to 11GB+ for a more smooth experience. If budgeting that much still doesn't work, then your CPU definitely needs upgrading (and if it's high end already, time to decrease the amount of mods).

Hmm. My PC specs are this.

GPU: Nvidia Geforce 2080 Ti, i have two of them.
Processor: Intel i9-9900 3.60 GHz, 16 CPUs
Memory: 32 GB
Starsector's Drive it sits at: 1.80 T SSD. 439 GB remains.

Let me know if there is more details that are important other than these three.

If having 110 Mods are too much, despite following every kind of Guide there is or that i could find, helps not. And i am overreaching the limits, such as not giving enough VRam, then alright. The vague guide saying that 8 GB lets you play with most Mods really means no more than 90 Mods, probably.
first, you can check if the game is heavily spamming GC when the stutter is happening (the cmd window that appear should show you)
if thats not the case which usually can be fixed by just giving more heap or narrowing down the mod, have you considered to only use single 2080 Ti?..
see if its actually caused by the motherboard pcie lanes being halved.
if the micro-stutter happen on combat, try removing fast engine rendering if you have it.
Logged

Jazuke Taizago

  • Ensign
  • *
  • Posts: 48
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #57 on: March 16, 2024, 10:57:44 AM »

To me. This doesn't seem to do anything. Yes, i use GraphicsLib. Now, i followed every instructions to the exact details, and also looked around here for options and means to see any improvement. Such as disabling GraphicLib's Bloom. While also disabling VSync, GLFlush, GLFinish and forcenoVBO. I just took your FPS limit which was 1000, why not? Was using 8GB VRam, changed to 6GB VRam to see if that stopped my mini-stuttering, but no dice. I have been living with this mini-stuttering for as long as i can remember.

Playing with slightly above 110 Mods. Tried counting them all, kind of lost track the exact number but it's slightly above that.

It's sad that this doesn't really help me in any way that i know of.

From my very basic understanding, the main problem I think is playing with 110 mods and only having 6GB ram allocated to it. You might want to increase that to 11GB+ for a more smooth experience. If budgeting that much still doesn't work, then your CPU definitely needs upgrading (and if it's high end already, time to decrease the amount of mods).

Hmm. My PC specs are this.

GPU: Nvidia Geforce 2080 Ti, i have two of them.
Processor: Intel i9-9900 3.60 GHz, 16 CPUs
Memory: 32 GB
Starsector's Drive it sits at: 1.80 T SSD. 439 GB remains.

Let me know if there is more details that are important other than these three.

If having 110 Mods are too much, despite following every kind of Guide there is or that i could find, helps not. And i am overreaching the limits, such as not giving enough VRam, then alright. The vague guide saying that 8 GB lets you play with most Mods really means no more than 90 Mods, probably.
first, you can check if the game is heavily spamming GC when the stutter is happening (the cmd window that appear should show you)
if thats not the case which usually can be fixed by just giving more heap or narrowing down the mod, have you considered to only use single 2080 Ti?..
see if its actually caused by the motherboard pcie lanes being halved.
if the micro-stutter happen on combat, try removing fast engine rendering if you have it.
GC? Sorry. I only have Entry level to Modding and these similar fields. I'll take more in-depth look at the cmd, if that is the case.

I have two 2080 Ti that is not connected with SLI. I made a grave and misinformed purchase, regarding GPU. Thus. I had to be settled with the two of them as i lack the income for a better one at all.

That is the VERY first time i have heard about pcie being halved. I have little understanding of this (newly, thanks to Himemiko's info). Okay. I learned a few things regarding pcie and it's details. I feel more enlightened. I'm not yet used to this kind of information, what it means and such. But by common sense and logic, i deduce that the compatibility is based on GPU pcie connectivity size versus Motherboard and etc pcie size, and it's Generation, if i am dumbing this down. This will help me greatly in the future, i truly hope. Thank you for bringing this info to me, Himemiko!

Fast Engine Rendering is disabled. Does that help, or should i just delete it completely? Considering it's not maintaned and updated anymore, for now.

Right. So i found the info regarding my Motherboard, at least. It is a MSI MPG Z390 GAMING PRO CARBON AC, S-115. I also had this purchased for my Rig HyperX Predator DDR4 3000MHz 32GB and later on to make up for my mistake a Kingston FURY Renegade PCIe M.2 NVME SSD 2TB, which i think is incompatible with my Motherboard that maxes out a 3.0, not a 4,0, if i am understanding this right? Since my Motherboard supports 3,0 x16. I have a much better (hopefully) Motherboard and Memory Cards on my wishlist, if i can manage to be a bit intelligent with my spending. A Nvidia 4090 GPU is simply impossible, for the time being, if that would change anything playing Starsector at 110+ Mods.

Edit: Found these, if they are of any concern, which gave me warnings:

OpenJDK 64-Bit Server VM warning: UseAVX=3 is not supported on this CPU, setting it to UseAVX=2
OpenJDK 64-Bit Server VM warning: UseXMMForObjInit requires SSE2 and unaligned load/stores. Feature is switched off.

Edit 2: Right. I think i understand what you mean by "GC" now. Their details as of my recent Copy is this:

[163.556s][info   ][gc        ] Trigger: Free (817M) is below minimum threshold (819M)
[163.561s][info   ][gc        ] GC(11) Concurrent reset 5.126ms
[163.562s][info   ][gc        ] GC(11) Pause Init Mark 0.096ms
[163.566s][info   ][gc        ] GC(11) Concurrent marking roots 4.118ms
[163.921s][info   ][gc        ] GC(11) Concurrent marking 355.258ms
[163.921s][info   ][gc        ] GC(11) Pause Final Mark 0.210ms
[163.921s][info   ][gc        ] GC(11) Concurrent thread roots 0.258ms
[163.923s][info   ][gc        ] GC(11) Concurrent weak references 1.832ms
[163.926s][info   ][gc        ] GC(11) Concurrent weak roots 3.032ms
[163.926s][info   ][gc        ] GC(11) Concurrent cleanup 6886M->5380M(8192M) 0.034ms
[163.930s][info   ][gc        ] GC(11) Concurrent strong roots 3.279ms
[163.978s][info   ][gc        ] GC(11) Concurrent evacuation 47.871ms
[163.978s][info   ][gc        ] GC(11) Pause Init Update Refs 0.008ms
[164.171s][info   ][gc        ] GC(11) Concurrent update references 193.674ms
[164.172s][info   ][gc        ] GC(11) Concurrent update thread roots 0.331ms
[164.172s][info   ][gc        ] GC(11) Pause Final Update Refs 0.098ms
[164.172s][info   ][gc        ] GC(11) Concurrent cleanup 5649M->1655M(8192M) 0.040ms


I think that's all about the CMD. If i am missing anything, please let me know. So i may correct myself.

Thanks for all the information and suggestions!
« Last Edit: March 16, 2024, 12:45:48 PM by Jazuke Taizago »
Logged

Himemiko

  • Lieutenant
  • **
  • Posts: 50
  • a very clumsy miko
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #58 on: March 16, 2024, 05:58:34 PM »

To me. This doesn't seem to do anything. Yes, i use GraphicsLib. Now, i followed every instructions to the exact details, and also looked around here for options and means to see any improvement. Such as disabling GraphicLib's Bloom. While also disabling VSync, GLFlush, GLFinish and forcenoVBO. I just took your FPS limit which was 1000, why not? Was using 8GB VRam, changed to 6GB VRam to see if that stopped my mini-stuttering, but no dice. I have been living with this mini-stuttering for as long as i can remember.

Playing with slightly above 110 Mods. Tried counting them all, kind of lost track the exact number but it's slightly above that.

It's sad that this doesn't really help me in any way that i know of.

From my very basic understanding, the main problem I think is playing with 110 mods and only having 6GB ram allocated to it. You might want to increase that to 11GB+ for a more smooth experience. If budgeting that much still doesn't work, then your CPU definitely needs upgrading (and if it's high end already, time to decrease the amount of mods).

Hmm. My PC specs are this.

GPU: Nvidia Geforce 2080 Ti, i have two of them.
Processor: Intel i9-9900 3.60 GHz, 16 CPUs
Memory: 32 GB
Starsector's Drive it sits at: 1.80 T SSD. 439 GB remains.

Let me know if there is more details that are important other than these three.

If having 110 Mods are too much, despite following every kind of Guide there is or that i could find, helps not. And i am overreaching the limits, such as not giving enough VRam, then alright. The vague guide saying that 8 GB lets you play with most Mods really means no more than 90 Mods, probably.
first, you can check if the game is heavily spamming GC when the stutter is happening (the cmd window that appear should show you)
if thats not the case which usually can be fixed by just giving more heap or narrowing down the mod, have you considered to only use single 2080 Ti?..
see if its actually caused by the motherboard pcie lanes being halved.
if the micro-stutter happen on combat, try removing fast engine rendering if you have it.
GC? Sorry. I only have Entry level to Modding and these similar fields. I'll take more in-depth look at the cmd, if that is the case.

I have two 2080 Ti that is not connected with SLI. I made a grave and misinformed purchase, regarding GPU. Thus. I had to be settled with the two of them as i lack the income for a better one at all.

That is the VERY first time i have heard about pcie being halved. I have little understanding of this (newly, thanks to Himemiko's info). Okay. I learned a few things regarding pcie and it's details. I feel more enlightened. I'm not yet used to this kind of information, what it means and such. But by common sense and logic, i deduce that the compatibility is based on GPU pcie connectivity size versus Motherboard and etc pcie size, and it's Generation, if i am dumbing this down. This will help me greatly in the future, i truly hope. Thank you for bringing this info to me, Himemiko!

Fast Engine Rendering is disabled. Does that help, or should i just delete it completely? Considering it's not maintaned and updated anymore, for now.

Right. So i found the info regarding my Motherboard, at least. It is a MSI MPG Z390 GAMING PRO CARBON AC, S-115. I also had this purchased for my Rig HyperX Predator DDR4 3000MHz 32GB and later on to make up for my mistake a Kingston FURY Renegade PCIe M.2 NVME SSD 2TB, which i think is incompatible with my Motherboard that maxes out a 3.0, not a 4,0, if i am understanding this right? Since my Motherboard supports 3,0 x16. I have a much better (hopefully) Motherboard and Memory Cards on my wishlist, if i can manage to be a bit intelligent with my spending. A Nvidia 4090 GPU is simply impossible, for the time being, if that would change anything playing Starsector at 110+ Mods.

Edit: Found these, if they are of any concern, which gave me warnings:

OpenJDK 64-Bit Server VM warning: UseAVX=3 is not supported on this CPU, setting it to UseAVX=2
OpenJDK 64-Bit Server VM warning: UseXMMForObjInit requires SSE2 and unaligned load/stores. Feature is switched off.

Edit 2: Right. I think i understand what you mean by "GC" now. Their details as of my recent Copy is this:

[163.556s][info   ][gc        ] Trigger: Free (817M) is below minimum threshold (819M)
[163.561s][info   ][gc        ] GC(11) Concurrent reset 5.126ms
[163.562s][info   ][gc        ] GC(11) Pause Init Mark 0.096ms
[163.566s][info   ][gc        ] GC(11) Concurrent marking roots 4.118ms
[163.921s][info   ][gc        ] GC(11) Concurrent marking 355.258ms
[163.921s][info   ][gc        ] GC(11) Pause Final Mark 0.210ms
[163.921s][info   ][gc        ] GC(11) Concurrent thread roots 0.258ms
[163.923s][info   ][gc        ] GC(11) Concurrent weak references 1.832ms
[163.926s][info   ][gc        ] GC(11) Concurrent weak roots 3.032ms
[163.926s][info   ][gc        ] GC(11) Concurrent cleanup 6886M->5380M(8192M) 0.034ms
[163.930s][info   ][gc        ] GC(11) Concurrent strong roots 3.279ms
[163.978s][info   ][gc        ] GC(11) Concurrent evacuation 47.871ms
[163.978s][info   ][gc        ] GC(11) Pause Init Update Refs 0.008ms
[164.171s][info   ][gc        ] GC(11) Concurrent update references 193.674ms
[164.172s][info   ][gc        ] GC(11) Concurrent update thread roots 0.331ms
[164.172s][info   ][gc        ] GC(11) Pause Final Update Refs 0.098ms
[164.172s][info   ][gc        ] GC(11) Concurrent cleanup 5649M->1655M(8192M) 0.040ms


I think that's all about the CMD. If i am missing anything, please let me know. So i may correct myself.

Thanks for all the information and suggestions!
SSD running at PCIe 3.0 instead of 4.0 shouldn't affect performance
Yes thats what i mean GC, if its still spamming too much.. i recommend using the one inside adaptive.zip and put slightly bigger size..
if thats not the case, its most likely the GPU being hampered by halved pcie lane
Goodluck troubleshooting it!, if there is any advise i could give is that you can prob sell your 2nd 2080 Ti and get some used 5800X3D from ebay (or sth equivalent)
Logged

Jazuke Taizago

  • Ensign
  • *
  • Posts: 48
    • View Profile
Re: [0.97a-RC11/0.96a-RC10] Mikohime Java 23
« Reply #59 on: March 16, 2024, 06:49:15 PM »

To me. This doesn't seem to do anything. Yes, i use GraphicsLib. Now, i followed every instructions to the exact details, and also looked around here for options and means to see any improvement. Such as disabling GraphicLib's Bloom. While also disabling VSync, GLFlush, GLFinish and forcenoVBO. I just took your FPS limit which was 1000, why not? Was using 8GB VRam, changed to 6GB VRam to see if that stopped my mini-stuttering, but no dice. I have been living with this mini-stuttering for as long as i can remember.

Playing with slightly above 110 Mods. Tried counting them all, kind of lost track the exact number but it's slightly above that.

It's sad that this doesn't really help me in any way that i know of.

From my very basic understanding, the main problem I think is playing with 110 mods and only having 6GB ram allocated to it. You might want to increase that to 11GB+ for a more smooth experience. If budgeting that much still doesn't work, then your CPU definitely needs upgrading (and if it's high end already, time to decrease the amount of mods).

Hmm. My PC specs are this.

GPU: Nvidia Geforce 2080 Ti, i have two of them.
Processor: Intel i9-9900 3.60 GHz, 16 CPUs
Memory: 32 GB
Starsector's Drive it sits at: 1.80 T SSD. 439 GB remains.

Let me know if there is more details that are important other than these three.

If having 110 Mods are too much, despite following every kind of Guide there is or that i could find, helps not. And i am overreaching the limits, such as not giving enough VRam, then alright. The vague guide saying that 8 GB lets you play with most Mods really means no more than 90 Mods, probably.
first, you can check if the game is heavily spamming GC when the stutter is happening (the cmd window that appear should show you)
if thats not the case which usually can be fixed by just giving more heap or narrowing down the mod, have you considered to only use single 2080 Ti?..
see if its actually caused by the motherboard pcie lanes being halved.
if the micro-stutter happen on combat, try removing fast engine rendering if you have it.
GC? Sorry. I only have Entry level to Modding and these similar fields. I'll take more in-depth look at the cmd, if that is the case.

I have two 2080 Ti that is not connected with SLI. I made a grave and misinformed purchase, regarding GPU. Thus. I had to be settled with the two of them as i lack the income for a better one at all.

That is the VERY first time i have heard about pcie being halved. I have little understanding of this (newly, thanks to Himemiko's info). Okay. I learned a few things regarding pcie and it's details. I feel more enlightened. I'm not yet used to this kind of information, what it means and such. But by common sense and logic, i deduce that the compatibility is based on GPU pcie connectivity size versus Motherboard and etc pcie size, and it's Generation, if i am dumbing this down. This will help me greatly in the future, i truly hope. Thank you for bringing this info to me, Himemiko!

Fast Engine Rendering is disabled. Does that help, or should i just delete it completely? Considering it's not maintaned and updated anymore, for now.

Right. So i found the info regarding my Motherboard, at least. It is a MSI MPG Z390 GAMING PRO CARBON AC, S-115. I also had this purchased for my Rig HyperX Predator DDR4 3000MHz 32GB and later on to make up for my mistake a Kingston FURY Renegade PCIe M.2 NVME SSD 2TB, which i think is incompatible with my Motherboard that maxes out a 3.0, not a 4,0, if i am understanding this right? Since my Motherboard supports 3,0 x16. I have a much better (hopefully) Motherboard and Memory Cards on my wishlist, if i can manage to be a bit intelligent with my spending. A Nvidia 4090 GPU is simply impossible, for the time being, if that would change anything playing Starsector at 110+ Mods.

Edit: Found these, if they are of any concern, which gave me warnings:

OpenJDK 64-Bit Server VM warning: UseAVX=3 is not supported on this CPU, setting it to UseAVX=2
OpenJDK 64-Bit Server VM warning: UseXMMForObjInit requires SSE2 and unaligned load/stores. Feature is switched off.

Edit 2: Right. I think i understand what you mean by "GC" now. Their details as of my recent Copy is this:

[163.556s][info   ][gc        ] Trigger: Free (817M) is below minimum threshold (819M)
[163.561s][info   ][gc        ] GC(11) Concurrent reset 5.126ms
[163.562s][info   ][gc        ] GC(11) Pause Init Mark 0.096ms
[163.566s][info   ][gc        ] GC(11) Concurrent marking roots 4.118ms
[163.921s][info   ][gc        ] GC(11) Concurrent marking 355.258ms
[163.921s][info   ][gc        ] GC(11) Pause Final Mark 0.210ms
[163.921s][info   ][gc        ] GC(11) Concurrent thread roots 0.258ms
[163.923s][info   ][gc        ] GC(11) Concurrent weak references 1.832ms
[163.926s][info   ][gc        ] GC(11) Concurrent weak roots 3.032ms
[163.926s][info   ][gc        ] GC(11) Concurrent cleanup 6886M->5380M(8192M) 0.034ms
[163.930s][info   ][gc        ] GC(11) Concurrent strong roots 3.279ms
[163.978s][info   ][gc        ] GC(11) Concurrent evacuation 47.871ms
[163.978s][info   ][gc        ] GC(11) Pause Init Update Refs 0.008ms
[164.171s][info   ][gc        ] GC(11) Concurrent update references 193.674ms
[164.172s][info   ][gc        ] GC(11) Concurrent update thread roots 0.331ms
[164.172s][info   ][gc        ] GC(11) Pause Final Update Refs 0.098ms
[164.172s][info   ][gc        ] GC(11) Concurrent cleanup 5649M->1655M(8192M) 0.040ms


I think that's all about the CMD. If i am missing anything, please let me know. So i may correct myself.

Thanks for all the information and suggestions!
SSD running at PCIe 3.0 instead of 4.0 shouldn't affect performance
Yes thats what i mean GC, if its still spamming too much.. i recommend using the one inside adaptive.zip and put slightly bigger size..
if thats not the case, its most likely the GPU being hampered by halved pcie lane
Goodluck troubleshooting it!, if there is any advise i could give is that you can prob sell your 2nd 2080 Ti and get some used 5800X3D from ebay (or sth equivalent)
Alright. That is good to know. Thanks!

Right then. I shall do exactly that. I tried it before with the 8 GB one, though. We'll see.

Halved pcie lane. Yeah. Not entirely sure, but if reason and logic dictates, it has to do with my placement for the GPU. Strangely, i don't feel like i have that much issue with anything else running, or i simply have not noticed, due to my lack of knowledge regarding this particular subject. I will have to learn all of this knowledge.

Alright then. I'll consider that. For now, i have mostly used it either for Streaming or for anything else. Friggen GPUs costs like over 2000 Murikanos or Euronian cash. It's WILD. I could only afford this if i robbed a bank, considering my income. Or be meticulous in my spending and sparing coin everywhere for about roughly ten or more years.

Thank you so much for your guidance!!! I'll get out of your hair now and use the information you have shared with me to figure things out. And hopefully find a solution. Take care!
Logged
Pages: 1 2 3 [4] 5 6 ... 13