pbkit: Set default PTIMER values without killing the system

[GXTX]

2nd go at #585

Fixes #536

Edit: Playing around with this, it seems like we can remove it. The kernel and applications before should already be properly setting up these 2 regs and they aren't reset during a launch. Thoughts on removing it completely? I tried testing with abaire/nxdk_pgraph_tests but their nxdk is out of date and refuses to build on my system.

The kernel sets these registers up before ever launching an application, so we don't need to be calculating them. Verified this on 3944 and some scene kernels.

[JayFoxRox]

Rather than checking if the kernel does it, I think we should be doing what Direct3D is doing.
Yes, the kernel also initializes a bunch of other hardware, but the state isn't always ideal.

The GPU setup in the boot animation might be incomplete and there might even be scenarios where a dashboard messes up these registers. If D3D does it, then that dashboard would work for almost any XDK app, but nxdk apps would suddenly break.

[GXTX]

Turns out the XDK just hard codes these values. Taken from LEGO Star Wars 1. So.. change to these values instead?

[JayFoxRox]

That's essentially the code we already have, with a slight off-by-one.

I'd be fine with either:
A. keeping as-is.
B. modifying to XDK variant.
C. making clock adjustable in a high-level fashion (like #585) but ideally defaulting to the current values. This might also require code on cleanup to default to more standard-ish values if not done from a stay-resident app?).

Removing (this PR) is a bad idea in my opinion; there are probably reasons why the XDK code does it.
Behaving more similar to XDK reduces risk for errors which are hard to debug and avoids potentially dangerous hardware state.

However, I think it's a good idea to extend behaviour in nxdk for advanced / experimental users.
There migh be good arguments for skipping parts of init or modifying it (overclock/underclock) in some case, but the default option should drive the hardware similar to the XDK (in my opinion).

[GXTX]

I don't really care how this turns out. I would like to stop using the dashboard I'm using and use a nxdk based one, this requires not killing the application when NVCLK is overclocked. So you or other org members need to decide the implementation. You suggested we do it the way XDK does it so I found that it's just static, can we remove this check and be done with it?....

[GXTX]

Went ahead and changed this to have the default values without killing the box and opened a 2nd PR as the alternative (setting it the way the kernel is). Please decide. Thanks.

[LoveMHz]

NIT Leftover local variables
c9c5e0e#diff-c92b0ba9ff23ed7ddf65f431953c6337f07b548db0dd4af9cfab12ad507117bfR2639

NIT Leftover logic
c9c5e0e#diff-c92b0ba9ff23ed7ddf65f431953c6337f07b548db0dd4af9cfab12ad507117bfR2804

[LoveMHz]

Turns out the XDK just hard codes these values. Taken from LEGO Star Wars 1. So.. change to these values instead?

The sample provided here does not match the proposed implementation. In the sample NV_PTIMER_NUMERATOR is being set to 56966, whereas the current/proposed implementation differs.

Context: It's been suggested that an acceptable solution should follow existing retail software logic (XDK).

[LoveMHz]

Removing (this PR) is a bad idea in my opinion; there are probably reasons why the XDK code does it.

I'm not sure I follow this comment (between the multiple PRs, force pushes, etc; it's all kinda hard to follow).

Are you referring to removing the PLL check as bad? I understand that other logic may implicitly be affected by the PLL value via assumption, but I'm not seeing it in the sample that I'm currently looking at LEGO Star Wars - The Video Game (USA).

With LEGO Star Wars - The Video Game (USA) the values of NV_PRAMDAC_MPLL_COEFF, NV_PRAMDAC_VPLL_COEFF, NV_PRAMDAC_NVPLL_COEFF are being read in at the function located at 0x0018441D, and stored in CMiniport, but I'm not seeing any readback references to those values.

[JayFoxRox]

Removing (this PR) is a bad idea in my opinion; there are probably reasons why the XDK code does it.

I'm not sure I follow this comment (between the multiple PRs, force pushes, etc; it's all kinda hard to follow).

My comment was about the state at the time of commenting: 5f4c262.
That revision removed the core functionality of the XDK counterpart: initialization of the GPU registers (NV_PTIMER_NUMERATOR, NV_PTIMER_DENOMINATOR and NV_PTIMER_ALARM_0)

Are you referring to removing the PLL check as bad?

I don't have a strong opinion about the PLL check.

• If the PLL is misconfigured, an assumption is broken, so it's fine if the code fails / checks it.
• I'm also fine if PLL is not checked if it's intended to be overclocked.

Eitherway, the default code path should be safe and stable (= mimic XDK; in this case I'm not sure what XDK does).

I have a stronger opinion about setting GPU registers on startup.
It's probably part of the hardware init and skipping it might be unsafe (= mimic XDK; set registers by default).

I'm fine with configuring other values for the clocks or skipping certain parts (checks or even register writes) - but if it happens it should happen through its own API or compile-time options, so people don't use it accidentally (which might break hardware / software).
The default options should mimic the XDK closely, so we have a stable reference to work against (and avoid bricking hardware / causing hard-to-debug bugs).

[GXTX]

I once again have a need to be able to launch a pbkit app with differing ptimer values... This arbitrary block is stupid, and as far as I can tell alarm0 isn't used by any retail application.

iirc 3944 and earlier actually calculate these values, whereas later ones set the values we already have.

[GXTX]

Status?

[GXTX]

Status?

[abaire]

... and as far as I can tell alarm0 isn't used by any retail application.

For context, it is used in Def Jam Fight for NY, though I believe the interaction may be through xapilib rather than the title directly interacting w/ the nv2a.

---

For what it's worth, I agree with the sentiment that pbkit should default to XDK behavior but allow advanced users to modify behavior (at their own risk). The current (master) implementation of blowing up on unexpected values looks like it was simply intended as a mechanism to inform the nxdk team of any devices in the wild that were initialized to an unexpected value so they could be handled. This feels heavy handed; an app designed to gracefully handle an atypical setup can't be written without modifying pbkit.

If the decision is blocked due to concern over changing the current behavior, perhaps a simple flag could be added via an init struct to control this check? That could also provide a mechanism to alter other defaults (e.g., triple buffering) until there's a replacement for pbkit or at least the hardcoded startup decisions which are known to be problematic for a number of users due to things like memory use, etc...