-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pbkit: Set default PTIMER values without killing the system #621
Conversation
4f8c544
to
5f4c262
Compare
Rather than checking if the kernel does it, I think we should be doing what Direct3D is doing. 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. |
That's essentially the code we already have, with a slight off-by-one. I'd be fine with either: Removing (this PR) is a bad idea in my opinion; there are probably reasons why the XDK code does it. However, I think it's a good idea to extend behaviour in nxdk for advanced / experimental users. |
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?.... |
5f4c262
to
c9c5e0e
Compare
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. |
NIT Leftover local variables NIT Leftover logic |
The sample provided here does not match the proposed implementation. In the sample Context: It's been suggested that an acceptable solution should follow existing retail software logic (XDK). |
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 With |
My comment was about the state at the time of commenting: 5f4c262.
I don't have a strong opinion about the PLL check.
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. 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). |
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 withabaire/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.