PS: no one gives a shit about metric vs imperial system on a graphics forum
No problems on my GTX 1080 here. I usually use DDU to uninstall old drivers as sometimes installing over old drivers sometimes causes the weird and unexpected.Updated my drivers yesterday for my 1080, resulting in immediate random horizontal line corruptions and screen blanking.
A lot of people are starting to use HEVC x265 to encode. When I do encode I use NVENC (ConvertXtoVideo) and haven't experienced any stutters.Still no fix for NVENC recording are stuttering... Ouch.
That does not sound like NVENC bug. Just to be clear, the NVENC interface by itself can't "stutter". Together with the frame, you pass a presentation timestamp in, you get the same timestamp out. And regardless of the pacing of the encoder, the client will apply sufficient prebuffer to display the frames exactly as paced by the increment in presentation timestamp. Some clients have trouble if frames are not evenly paced.Still no fix for NVENC recording are stuttering... Ouch.
The current Workaround: use RTSS to manually set frame limit to be the same as monitor refresh rate.
Don't get your hopes up, that's limited to the leaks in Vulkan only. The other leaks they have recently introduced in D3D and Cuda are still there.Fixed various resource leaks
Have you tried the Beta drivers yet?Don't get your hopes up, that's limited to the leaks in Vulkan only. The other leaks they have recently introduced in D3D and Cuda are still there.
Have to double-check if I haven't installed wrong driver release by accident, but yes, I think so. The multi-GPU related leaks are still present.Have you tried the Beta drivers yet?
A lot of people are starting to use HEVC x265 to encode. When I do encode I use NVENC (ConvertXtoVideo) and haven't experienced any stutters.
Edit: Which card are you using? Seems some Turing cards (budget) are not using the new efficient Turing encoder.
That does not sound like NVENC bug. Just to be clear, the NVENC interface by itself can't "stutter". Together with the frame, you pass a presentation timestamp in, you get the same timestamp out. And regardless of the pacing of the encoder, the client will apply sufficient prebuffer to display the frames exactly as paced by the increment in presentation timestamp. Some clients have trouble if frames are not evenly paced.
So if it stutters for you, the fault happens already before the frame is handed to NVENC. Sounds like whatever software you are using for recording fails to associate frames with their correct timestamp, or has a poor logic for selecting frames suitable for encoding.
Don't get your hopes up, that's limited to the leaks in Vulkan only. The other leaks they have recently introduced in D3D and Cuda are still there.
You have an adaptive sync monitor, don't you? As I said, most clients don't like non-monotonous frame pacing. And that is exactly what you get with an adaptive sync monitor when playing full screen. If you want to record / stream, make sure you are running at a fixed refresh rate. Same refresh rate as the target display, to be accurate, in case of ALVR.GF experience and OBS recording stutter will be gone with RTSS frame limit enabled
You have an adaptive sync monitor, don't you? As I said, most clients don't like non-monotonous frame pacing. And that is exactly what you get with an adaptive sync monitor when playing full screen. If you want to record / stream, make sure you are running at a fixed refresh rate. Same frame rate as the target display, to be accurate, in case of ALVR.
Any funny settings in driver? "FastSync" especially? Whatever could result in proper vsync being lost from application perspective.I use 60hz lg 24mp monitor