User talk:Aemony

About this board

D0x360 (talkcontribs)

There is plenty of evidence you can check for yourself. I tested it on 3 systems, 2 Intel and 1 ryzen. All had 32 gigs of system ram. Over the course of 3 hours on every single run of the game it would go from using 12% up to 68% and im 1 case it was at 84%(of 32 gigs). All memory would then be released the second the game was either quit or forced to end via task manager.

The information about increasing the page file size during shader compilation is further evidence of this. You shouldn't even need a page file with 32 gigs of system memory if all you are doing is playing a game.

I am a programmer, I know a memory leak when I see one and that aside the forums are full of people describing memory leaks without even knowing it.

Aemony (talkcontribs)

As mentioned in the change, the reports are inconsistent enough to be unreliable and the inclusion of it in the section has no real informative value other than as unnecessary speculation.

Saying that it is potentially caused by a memory leak helps nobody -- especially not when reports are widely different with users of 4 GB of VRAM and 8 GB RAM reporting minor number of crashes and people with 64 GB of RAM reporting multiple crashes.

That whole "High memory usage" section in itself is technically also problematic as "unexpectedly high [...] usage" is a subjective statement to begin with when there is no official baseline to compare again. Further on, the references listed is filled with counteracting reports further questioning its inclusion on the wiki page. But so far I have looked past it while at least trimming the more speculative parts of the section while waiting for further development on how to proceed.

Further on, based on testing by myself as well as, again, reports from other users it is not even guaranteed that the crashes the game experiences is caused by the memory usage, and we have yet to actually see sufficiently reliable reports or findings that actually suggests the memory usage is an issue as well as what is might cause.

Like, take my last session just now where I played the game for more than two hours -- no crashes, no issues, only about 3 GB of RAM used towards the end of the session.

It's basically speculations everywhere combined with clueless users whom might not even know what they're looking at and so blames "unexpectedly high" (what does that even mean without a baseline?) RAM usage when crashes caused by unexpected D3D12 results causes the game to "crash". Like really, you can't even manipulate the number of back buffers used by the swapchain without the game going "Oh my god, this is unexpected! I believe I have crashed!" when in reality it would function just fine. It's more than likely that half the crashes experienced by users is due to the game's fucked up D3D12 usage that treats any minor unexpected result as a "crash".

Random tangent over -- What will most likely happen is that when further evidence or confirmed reports arise we'll remove that whole "high memory usage" section and throw it under a general-purpose "the game crashes" section instead. But we're not there yet, and so we need to minimize the speculation present in the PCGW article.

On another note, I'm still waiting for a reply from you on Rose's talk page in regards to in what way the game isn't "proper HDR".

On a third note, the talk page of the article is for these kinds of discussions -- not individual editors/administrators talk pages.

D0x360 (talkcontribs)

I'm new to this but I will have it down soon enough. Having some health issues that are slowing me down. Anyways... I confirmed the memory leak on 3 different systems (all with different hardware and tested with multiple driver revisions on a fresh install of win10) using tools designed specifically to look for them. Also the fact that every system showed over 70% memory use after 5 hours on a system with 64 gigs of memory and no other major tasks running is good reason to investigate hence the use of tools and why I'm so adamant about it. I was a programmer and behavior is consistent with unreleased memory. I agree it's inconsistent but likely not as inconsistent as you seem to believe. It's the leak that causes attempts to read or write to non existent address space causing a crash. It also causes performance issues because despite already loading data it needs into memory the leak makes it invisible to the game (at times) so it has to load the same data twice in a row.

The point of bringing it up is to draw attention so hopefully the developer fixes it. Otherwise crashes will continue. Also if users know about it then they can restart the game every hour or so to help avoid crashes and/or performance issues.

True HDR... It's determined by the measurements of contrast, nits and color. This game doesn't meet the criteria for HDR because it's color space is 8 bit and their are some major inaccuracies with said color (at times) which isn't the main reason. The main and defining reason is nits. It doesn't meet the criteria for the HDR spec.

Aemony (talkcontribs)

> The point of bringing it up is to draw attention so hopefully the developer fixes it.

Developers do not visit nor use PCGamingWiki as a resource. Guerrilla Games are basically only active on the subreddit and gets their information from the community there, as well as the multitude crash reports that users sends to them.

This isn't a place to throw darts on the board hoping against all wishes that *someone* might eventually see it. It's for confirmed and reproducible situations with valuable information for end users -- which speculations aren't.

And again, there's very little correlation between the crashes and memory usage, and your findings on 3 systems does not match the reports of multiple others. Right now the *vast* majority of crashes seems to be related to D3D12 calls as well, which this speculation further doesn't help with.


> It's the leak that causes attempts to read or write to non existent address space causing a crash.

Patch v1.02 fixed a crash related to memory incorrectly being overwritten.

And as for non-existent address space -- we already cover this under the "Seldom crashes due to game trying to write to nonexistent memory address" section.


> The main and defining reason is nits. It doesn't meet the criteria for the HDR spec.

Again though, by what specs are you measuring? The HDR visualization I provided in the other thread shows nits around or above 4000 (the purple areas).

Just saying "it doesn't meet the criteria" when the game makes use of HDR, makes use of *thousands* of nits, and you don't provide any actual example of said "major inaccuracies" doesn't make it HDR.

PCGamingWiki is not a site where individual users inject their personal belief into the articles. If 8-bit HDR is how Guerrilla Games have decided to provide HDR on PC, then that's how they've decided it as. *At most* what we can do on the PCGW article is set the HDR state as limited instead of true with a minor note about it, but we shouldn't outright state it as false when by most accounts it's still HDR -- just not the more preferred 10-bit HDR.

D0x360 (talkcontribs)

Im not just injecting my personal beliefs but I will concede on the HDR issue since it's only 8 bit and that's mostly nvidias fault.

As for the memory leak.. yes they fixed a memory bug during shader compilation however they still have not fixed the memory leak that occurs during gameplay.

Also the point about informing people in hopes that it helps get the issue fixed... I don't expect devs to read this site (although they definitely do, I've asked many) and it's not throwing darts to inform users of a significant bug. The benefit of people knowing something exist is they can talk about it and when people talk about certain bugs they tend to get focused on.

I don't see how informing people of a bug is a bad thing. It is confirmed and easily reproduced. You can check yourself with tools that literally check a program for a memory leak. You can also just see it happening as time goes on. There is no reason you would see 60+% memory use on a system with 32+ gigs of RAM. The latest version of the game used 37% of 128 gigs of system memory after 4 hours of running and also was flagged positive for a memory leak.

I'm not just some guy arguing because I think I'm right. I used to work for Sega of America and Epic. I have a degree in computer science, I am in charge of IT for a multi million dollar company called DEKA.. I am speaking as a professional not as a gamer.

D0x360 (talkcontribs)

Had to make an edit to my last post that completely changes the meaning. Auto correct removed the word "NOT" in the first sentence.

Although since nobody replied I guess the issue about the memory leak is closed. Although I tested the game yesterday and the memory leak is still present. That was a tool based check then I let the game run for 6 hours of a system with 128 gigs of system ram and when I checked in using monitoring tools there was 86% of system ram in use by absolutely nothing which is in line with a memory leak. Address space is reserved but not properly released. It doesn't get attributed to any application but it can't be used due to the error during release.

Reply to "HZD Memory leak"
Chick'n'Duck (talkcontribs)

Why are they removed/replaced? With them one can navigate through the games with one click.

Aemony (talkcontribs)

It was mentioned that the infobox was starting to become too long and so the seriesboxes were deemed to be removed when they are replaced by the new taxonomy rows that also includes the seriesname.

The team is aware of the downside of this though and we're currently discussing adding an automated check that will automatically add the seriesbox below the infobox again with either an expanded state (basically the same as before) or a collapsed state (like how the seriesbox worked on mobile devices). It would basically calculate how many rows a seriesbox included and if it was found to be too many (something like 10 or more), it would collapse the section.

We currently have no estimation though when this might be implemented.

Chick'n'Duck (talkcontribs)

Sounds good to me.

Reply to "Seriesboxes"
Erexx (talkcontribs)

Can we please talk?

Aemony (talkcontribs)

The edit notes on the history page should explain the situation already, but here's a more elaborate explanation:

1. The source of the fix is already present in the fixbox as a reference. This is the standard way of referencing fixes on PCGW, and we do not need a duplicate link 5 lines below the existing one.

2. The image of the launcher does not contribute with anything since a screenshot of the external launcher is already present higher up the page. The only differences between the two screenshots were a) the GPU selected, and b) the resolution selected. This isn't enough to warrant a new screenshot solely for that fixbox. The instructions of the fix are clear enough without the additional duplicate screenshot.

Erexx (talkcontribs)

"The source of the fix is already present in the fixbox as a reference"

1.Could you please point out where? The Fixbox I see only includes the fix that I found and added here to the PC Gaming Wiki. --The link is really meant as a citation and it keeps getting removed.

2.The Image makes it clear that the Fix is for nVidia cards ---and not RV cards which dont have the problem.


As for #1 where is the *good* edit that links back to the source?

As for #2 go for it.... I think that its confusing.

Aemony (talkcontribs)

The link is used as the actual reference of the fix: https://images.aemony.se/sharex/firefox_2019-06-09_00-38-45.png per the standardized instructions for how to reference fixes on PCGW.

The image is unnecessary to make it clear that it concerns Nvidia cards since on a modern Nvidia GPU is already a part of the informative bullet of the issue: https://images.aemony.se/sharex/firefox_2019-06-09_00-41-36.png

Using an image that is identical to an already existing image by arguably 95%+ to convey that it concerns Nvidia cards is not an effective way of conveying information. Actually mentioning it in the bullet point as the page currently does is a far more effective way.

Reply to "Can we please talk?"
Deton24 (talkcontribs)

About this edit (at the bottom):

https://pcgamingwiki.com/w/index.php?title=Microsoft_Windows&diff=782979&oldid=782873 From: https://pcgamingwiki.com/wiki/Microsoft_Windows#Changing_default_timer_resolution

" Other applications might already be requesting a higher resolution, such as the Steam client and Discord,[Note 1] making this tool unnecessary."

Could you confirm that, despite of having TimerResolution tool enabled and set to maximum, it still reverts it to default value?

It's easy to check.

Download:

filecroco.com/download-timer-resolution/

Set to maximum. Wait ~1 minute or less. Don't close the app. Download and open:

vvvv.org/contribution/windows-system-timer-tool

Check the timer.

It should show still the same value.

Please confirm it to make an edit.

Aemony (talkcontribs)

I've amended the note with references and more detailed info on the Power Efficiency Diagnostics Report.

Deton24 (talkcontribs)

You didn't provide any new references, but you only confirmed credibility of your own edit as a reference.

Could you confirm that, despite of having TimerResolution tool enabled and set to maximum, it still reverts it to default value while checking it in other program?

Aemony (talkcontribs)

> it still reverts it to default value while checking it in other program?

I'm not sure I understand... The note is meant to show that _other applications_ on the computer might already be requesting a higher resolution (e.g. lower value) for the timer. It have nothing to do with reverts to the default value.

The only reason the timer would revert to its default value would be if no other process requests a higher resolution, e.g. the opposite of what that note is talking about.

Deton24 (talkcontribs)

For clarification, yes, certain application can request timer resolution change, it is among others the reason to use Timer Resolution.

Bad timer resolution settings may influence CPU performance, and this is the tool to get rid of this problem - among others, to keep that value the same all the time, despite any program's request. That was the thing I asked you on the beginning, to verify it, if you just deny that this tool is unnecessary due to random program's request. The tool should prevent it.

The thing I try to say is that, if this tool kept in background (with resolution set to 0.5), really keeps the same value of the timer, then it is not true that:

"Other applications [...], such as the Steam client[41] and Discord,[41] [make] this tool unnecessary"

And this edit is the purpose of the discussion.


Changing timer resolution by normal applications which you mentioned, is said by MS as a bad practice.

W10 can revert value to default. If random program can change that value, it can cause performance issues especially on W8 and below.

Aemony (talkcontribs)

That "more information" note is only there to mention the fact that other applications might already be setting a higher timer resolution already, which will remain in effect until either those processes are terminated, or they request another timer resolution by making a follow-up call.

TimerTool itself only sets the requested resolution when clicking on "Set Timer" and then assumes the timer is set as requested until its process is terminated, since Windows uses the lowest value (that is, highest resolution) requested by any process until said process is terminated (or the process requests the resolution unset or lowered).

Basically, that note is meant to highlight the fact that other applications can also requests various timer resolutions, and it is up for each user interested in knowing more to generate a power efficiency diagnostics report and determining whether another process is already setting a higher resolution or not.

For me, personally, I have no use of that tool since both Discord and Steam (as well as my sound card) requests a 1ms resolution constantly, which keeps the timer resolution on my system set at 1ms forever. I imagine in the case of Discord and Steam it might be their use of CEF (Chromium Embedded Frameworks) since Chromium used to love to set the timer resolution to 1 ms and forget it.

Deton24 (talkcontribs)

Thank you for your reply.

Yes, we already mentioned that some application set their own timer resolution, but as you said - e.g. 1 ms. The tool sets 0.500 ms timer, and it is widely used value by CPU testers to have reliable results while using various configurations which may cause diffrent timer changes.

In my PC I also have 1ms all the time, I also use Steam and Chrome, but it is kept on 0.5 ms while using this tool and keeping it in backround. I also have some sound card from Creative.

Considering this, I still cannot really agree with your edit, though I understand what you mean, still, in my opinion, it is misleading. 1ms is not 0.500 ms. But it is generally very small performance change, and considering that fact, we may say that the program is unnecessary in such case. Though, in the entry I already stated certain dependance while 30% performance increase existed when default resolution clock was changed from ~10ms to 0.500ms. Logically change from 1ms to 0.500ms won't give noticeable performance increase - and this the thing I'd write next to your note, to clarify what you mean if you don't have anything constructive against.

Aemony (talkcontribs)

I'd say just leave the whole section as it is right now as there's nothing directly wrong with anything per se. "more information" bullet are just that, more information. They're meant to provide additional information that for those users wanting to know more, but can otherwise be ignored.

The point of that bullet isn't to showcase that Discord or Steam requests a 1 ms timer resolution. The point of that bullet is to make those wanting to know more aware that they might already be running another application that's requesting a higher resolution (than the default 10/15 ms), and instruct them on how to find out which applications they are and what timer resolution they're requesting.

Reply to "Keeping Timer Resolution"
68.119.86.156 (talkcontribs)

First off, thank you for your work on the various. I do have one suggested change for the lists that I hope will be considered. Given that is not unheard of for some games in development and even in late stage testing not to survive to release, or to undergo significant redevelopment before they do, my suggestion is to wait to add games to the lists until the games are formally released. Alternatively, the games could be commented out in the lists until they are released. Best regards.

68.119.86.156 (talkcontribs)
Aemony (talkcontribs)

The lists are dynamically generated by polling PCGW's internal database of pages, making them directly influenced by the community-driven input on PCGW as editors or guests go around and update articles on their own leisure. This means that there is no manual supervision of each entry when one gets added.

All that said, the release date column technically allows to separate the released games from games currently in development, as TBA/Early Access titles or similar will not have a release date set, or have one set in the future.

Reply to "Graphics API lists"
Saftzie (talkcontribs)

Welcome to PC Gaming Wiki!

Reply to "Welcome"
Dove (talkcontribs)

{{Subst:Welcome}} Dove (talk) 05:53, 6 March 2019 (CET)

Reply to "Welcome!"
There are no older topics