AMD, Intel and Nvidia driver issues and last recommended version

[ryrynz]

Now what the hell did they break...er, I mean, oh good! :DThere's always something. Chances are the majority of breaking happened with the new branch so if you were running the previous set these *should* be good. As long as it's not MadVR that's broken.. Anyway worry about getting your system sorted before u worry about the drivers for it [emoji39]

[SamuriHL]

Oh that system is dead. Not to be resurrected any time soon. But I still have my laptop with the 2080 in it so I do care about drivers. I didn't have any issues that I saw with the last driver, but, then I'm not using madvr at the moment. I've switched to playing with JRVR which is still in its infancy but has a lot of potential.

[huhn]

we also got new AMD driver for the same reason:
https://www.amd.com/en/support/kb/release-notes/rn-rad-win-21-10-3

[ryrynz]

I'm not using madvr at the moment.

Blasphemy [emoji50]

[Manni]

Blasphemy [emoji50]

I’m not using madVR at the moment either :)

Too many issues with drivers / OS versions, especially with HDR, I don’t have the time to debug/maintain and now that my HTPC isn’t just a HTPC but a video editing and gaming machine, I use a Dune 4K vision pro solo or an Oppo 203 clone as a player.

I use MyMovies on my iPad as a movie wall, select the film there, choose which player and the title is played automagically. No OS or drivers issue. The picture quality is the basically same on my 88” diag 16/9 screen as I use source direct on both and Envy as a processor, and with the new calibration options only available on Envy, that sealed the fate of madVR on the HTPC for now.

Obviously not an option for everyone, but don’t be surprised if You don’t see me around as often as I used to be. I might come back if/when there is a working version of madVR with latest OS/drivers, but for now I’m going to take a break.

[ryrynz]

Manni: MADVR was so 2010, so I got an Envy. Holiday profile activated [emoji41] Be Envy-ous.

[SamuriHL]

I wish. Can't afford one so I'm stuck with my laptop and streaming devices for now. I can't even afford to rebuild my htpc. Then again I should get cyberpower to pay for it since the battery dying in my ups is what destroyed the htpc. Sigh

Sent from my SM-G998U1 using Tapatalk

[ashlar42]

Then again I should get cyberpower to pay for it since the battery dying in my ups is what destroyed the htpc. Sigh
Since I have a CyberPower UPS for my main workstation I read these lines with dread... care to explain what went wrong (and sorry for the offtopic)?

[SamuriHL]

Since I have a CyberPower UPS for my main workstation I read these lines with dread... care to explain what went wrong (and sorry for the offtopic)?

A lot. Very specific to my setup and house. The battery died without warning me of such (showed 100% power at all times). And because the electrical circuit that the HTPC was on was overloaded at the time (since corrected by an electrician) I had power problems that essentially spiked the circuit, overloading the UPS with a dead battery, and essentially annihilating my HTPC's components. I've only traced a few of the dead parts but the power supply, memory, and GPU are all toast for sure. Mobo might be ok but not entirely sure at this point. I will (probably) eventually rebuild an entirely new machine but not until next year some time. Needless to say I'm unamused that the dead battery wasn't detected by the UPS but really what can you do. I've since replaced the battery and it's back to working properly. Plus rewiring the circuit will prevent any future issues. IOW, this is not something you should concern yourself with because it's a lot of failure points that you can't simply point to one and go "geeze that sucks".

Apologies for the off topic.

[huhn]

your PSU should have catched that.

if your UPS failed already why would you ever use it again. it did the opposite of what it's made for.

[SamuriHL]

Well, you can't fault it TOO much for having a dead battery on a messed up electrical circuit. Yes, I agree that it should have caught the dead battery situation and not lied to me about having 100% capacity when in fact it had 0. When I rebuild the HTPC, I'm likely to include a new UPS, as well. Right now it's just got my tivo and ATV on it so I'm not terribly worried about it.

As for my PSU, yea, I tend to agree there. It's an 850 eVGA gold so it's not some cheap low quality PSU. That'll have to get replaced when I build out a new machine.

Having the circuit fixed is nice, though. That was more problematic than the HTPC as it was a risk to the entire house. Yes, it was that bad.

[Balling]

Yes, here RGB 12 bit works with hdmi 2.0b on 24 Hz. SDR and HDR.

[ashlar42]

As for my PSU, yea, I tend to agree there. It's an 850 eVGA gold so it's not some cheap low quality PSU. That'll have to get replaced when I build out a new machine.
This gets funnier and funnier... what do I have inside my HTPC?

https://www.evga.com/products/product.aspx?pn=220-G3-0750-X1

:D

Ok, sorry everyone... ;-)

[Balling]

This gets funnier and funnier... what do I have inside my HTPC?

https://www.evga.com/products/product.aspx?pn=220-G3-0750-X1

:D

Ok, sorry everyone... ;-)

Hey, you should have bought normal Titanium 80 PLUS PSU that is recommended by Intel with all kind of ErP low level stuff and always awake mode.

[ryrynz]

New audio driver 1.3.38.94 as part of 496.76

[Klaus1189]

Anybody has a new 12 gen intel cpu already?
I am interested in iGPU, especially in Hardware deinterlacing.
If you have one play this sample file: https://drive.google.com/file/d/12wO8NJbIrfa2MD4yVaA38RrBBdziCda8/view
Please tell me if the logo "www.d88.com"
Any other issues?

[SamuriHL]

Maybe doom eternal will stop giving me nasty messages about how screwed up the nVidia drivers are after a certain revision now. LOL

[aufkrawall]

I wish you better luck than I had with RDR2 Vulkan. The last hotfix already mentioned a fix, yet it crashed the driver for me within minutes...

That being said, this driver still forces me to turn off MPO to avoid stutter with madVR/mpv in fullscreen.

[SamuriHL]

SIGH....it's clearly too much to ask for OS and driver MFG's to play nice together...

[ryrynz]

SIGH....it's clearly too much to ask for OS and driver MFG's to play nice together...

I don't quite understand why you can't just design your hardware to an open interface standard that's inside every OS and everything just works? No more driver updates breaking things.
Surely there's a better way the complete cluster f*ck that is current driver development.
People waste so much time testing, benchmarking and problem solving basically every new version, it's just ridiculous.

[Asmodian]

People waste so much time testing, benchmarking and problem solving basically every new version, it's just ridiculous.

It is one of those "too late now" situations. Backwards compatibility is nuts at this point. How many different versions of the DirectX API are still supported today? It is all a very complex software stack at this point.

Software features cannot simply stop changing, at least the next new one will get a lot of adoption so anything competitive is by definition pretty new. Humans have NOT perfected graphic APIs, DWMs, etc. The good and bad of this weird tool we call software. :confused:

Any new "everyone just use this" project would simply be adding another complication in the complex environment.

[nevcairiel]

Even in an ideal world that would never work, unless you want both hardware and software to stop evolving. Evolution means change, and change can present issues. No matter how open your design is.

You can see similar issues in the Linux world, even when you exclude drivers entirely. Software packages update, break compatibility with each other, and it all turns into a mess. All open-source, not even hardware related. The same principle holds. If you want new features and advancements, you need to be open to change, and anything that comes with that.

Besides, the majority of these "issues" are niche cases that affect a minority of users on specific setups, and often have simple work-arounds. Is it really worth it getting worked up about a theoretical issue you can potentially fix with a press of a button should it even affect you? My HTPC plays video flawlessly with zero drops or glitches without changing any settings, for what its worth. :)

[KrazyLurt]

Maybe doom eternal will stop giving me nasty messages about how screwed up the nVidia drivers are after a certain revision now. LOL
Via steam I assume, same for me, it bother the hell out of me for, but I read a while ago how to remove the warning.

If this update doesn't help then you can navigate to:
"xxx:\xxx\Steam\steamapps\common\DOOMEternal\launcherData\launcher.cfg"

edit launcher.cfg, line to a 0 value

rgl_showNvidiaStartupWarning 0

[SamuriHL]

Thanks for that.

As for video, yes, me as well, Nev. [emoji846] things are working very well on that front on my laptop.

As for just leaving things where they are I can't for quite a few reasons. The biggest being security. Yes, even with gpu drivers security comes into play. It's all well and good if you can isolate your machine offline then sure you can leave it alone and never touch it again. I can't do that. I require it to be online. As such I have no choice but to keep it up to date. And all the problems that brings.

Sent from my SM-G998U1 using Tapatalk

[aufkrawall]

You can see similar issues in the Linux world, even when you exclude drivers entirely.

Though components (e.g. user and kernel space drivers) are more or less developed independently from each other. Which is why it is usually much easier to deduce which component actually broke (unlike on Windows, where Windows and driver updates can cause all sorts of issues that are hard to identify) and with proper git practices, often single commits can be easily identified as culprit (and users can try fixes and provide feedback before they land on the main branch).

It also seems to be really beneficial for software quality if companies don't just dump giant code drops with hardly enough testing vs. single commits that undergo proper (and likely more strict) reviewing processes. I found upstream amdgpu Linux kernel driver and Mesa to be much more reliable than the bugged stuff AMD ships with their Windows driver, in fact also often/usually better than the Nvidia Windows driver.

It might be that traditional proprietary development practives aren't simply sufficient anymore for today's complex software. Also, Linux and Mesa development was hardly hit (if at all) by the pandemic.

[SamuriHL]

It might be that traditional proprietary development practives aren't simply sufficient anymore for today's complex software.

As a professional software engineer, I find that offensive! :P It's not that the development practices aren't sufficient, it's that they aren't followed. Part of the SDLC is in testing. In the commercial world, time crunches are artificially created by unrealistic business demands. The first thing that gets cut is testing. It should all be automated but often isn't. And because of that, things are the way they are now where end users end up being testers. As Nev mentioned, those niche edge cases that impact us the most, those aren't tested for. So they escape.

Bringing this back to driver development, it's clear the pressure to release at least one driver per month, focused on adding support for new games and new monitors takes priority over any other functionality within a driver. And that pressure leaves little time for the niche stuff. We have a lucky month when they simply leave our stuff untouched. That's really the best we can hope for most months. Once a year we tend to get a push that actually helps us like when they made 23Hz stable. Most months it's "please don't break s***".

[aufkrawall]

You're probably right that also proprietary software could be way better. But look at Microsoft: They drown in money more than ever, but software quality (who likes Windows 11, recent Outlook, Teams etc...) can hardly compete with that of gilded Windows 7 era (apart from security, perhaps).
Proper git development doesn't magically solve all issues, but I think there is a tendency of it enabling better software quality. Especially for complex/hard stuff like kernel or driver.

[SamuriHL]

You're preaching to the chore on the merits of git. I push for it in every company I work for. Proper source management is critical. Branching strategy plays a LARGE role in the quality of large development projects. Proper branching strategy would also allow for different release types. Yes, we have the studio vs gamer drivers now. But imagine if they had a dedicated "HTPC" driver that only changed when needed. Security updates? Yes. Updates for when the OS changes? Yes. Updates for HTPC functionality, hell yes. But other than that, leave it the F alone. LOL By having proper branching strategy, you could do that by merging the critical code to the branch, properly test it for the use case the branch exists for, and release it separately from the more popular gaming branch. Even the studio branch is technically closer but wildly different than what we would want from an "HTPC" branch. That's geared more toward content creation. We want something geared toward content consumption. :)

[nevcairiel]

There is no studio branch, actually. It's the same driver, they just release it more infrequently after more testing, so it's typically older, eg. more stable. It's not fundamentally different to GRD drivers otherwise.

Nvidia has typically two active driver branches, the "new feature" driver which is currently 496, and the "stable" driver which is 471. For marketing they get fancy names, but they don't differ other then by age - the older one has more fixes and less new things that break again.

[SamuriHL]

Well, they SHOULD. LOL That way they could keep an updated HTPC style driver devoid of all the BS that the game drivers go through. Proper branching strategy really would solve a lot of issues.

[nevcairiel]

The problem is how specific do you get? If you got a big screen TV with a reasonably powerful PC attached... wouldn't many people also want to couch-game on that, because why not? Why can't I have a driver that has video and gaming working fine? Instead I have to switch between two? :D

[aufkrawall]

I think that's why the aim should be to break less in the first place and then deal with breakage more transparently.
At least chances are you can still get a human response when reaching out to Nvidia and get improvements in the wake of it. I don't think AMD Windows team has any kind of support at all, they just despise their Windows customers. Can't explain that blunt ignorance and 0 communication otherwise.

[SamuriHL]

The problem is how specific do you get? If you got a big screen TV with a reasonably powerful PC attached... wouldn't many people also want to couch-game on that, because why not? Why can't I have a driver that has video and gaming working fine? Instead I have to switch between two? :D

The real world answer to that is already known. Too many variables. I get it, I have for years tried to have a machine that "does it all" myself. The reality is that you either spend an enormous amount of time fighting one side of the equation (game stability) or the other (HTPC stability) in order to strike that balance. You're right....we SHOULD be able to have both. The reality is that if the driver MFG's don't see HTPC functionality as a priority, introducing breaking changes in order to fix game stability is considered an acceptable risk. We've seen it many, MANY times.

Now, we're developers, so you know what I would say to this. Have an install that has the ability to "switch" between stable drivers under the covers based on which profile is selected at any given time. It's the equivalent of switching between a gaming driver and a stable HTPC driver, only done automagically based on a profile selection. :D

[SamuriHL]

I think that's why the aim should be to break less in the first place and then deal with breakage more transparently.
At least chances are you can still get a human response when reaching out to Nvidia and get improvements in the wake of it. I don't think AMD Windows team has any kind of support at all, they just despise their Windows customers. Can't explain that blunt ignorance and 0 communication otherwise.

The problem is that it's not a priority for them to test for breakage in the HTPC space. It's truly niche. Maybe a couple percent of their user base. When they've got the majority of their customers clamoring for support for Game X of the month, this niche space is just not a priority for testing, much less stopping the release of a driver that includes a breaking change.

Personally I like my idea of profile driver selection. But it, too, will never happen. Unless Nev decides to take me up on that idea and include private known stable driver versions in JRiver MC and have the ability to on the fly overlay those for playback and then revert to your gaming driver upon exit. BAHAHAHAHA :D

[Balling]

Once a year we tend to get a push that actually helps us like when they made 23Hz stable. Most months it's "please don't break s***".

You mean 24/1.001 stable as in EDID when it is in VIC timing that supports both with /1.001 and without? Yeah, but that is still quite broken in some players like in Chrome, it does some strange dropping and duplicating of frames even though both file and display are 24/1.001.

[Klaus1189]

511.09 SD has new new HD Audio Driver (https://drive.google.com/file/d/1zwdlJFG3trlchAGVVxvf_RoPk_PGeJPX/view?usp=sharing)

[SamuriHL]

That looks scary. LOL

[Charky]

Now, we're developers, so you know what I would say to this. Have an install that has the ability to "switch" between stable drivers under the covers based on which profile is selected at any given time. It's the equivalent of switching between a gaming driver and a stable HTPC driver, only done automagically based on a profile selection. :D
I use a non-dev solution that IMO seems wayyy easier : dual boot ;)

[SamuriHL]

Dual boot is certainly an option for some.

[ryrynz]

That looks scary. LOLRan with it last night on the 3060, all was well. System latency looks to be improved considerably based on what I and others have seen with LatencyMon.

[aufkrawall]

As with all Ampere driver updates so far, I notice zero difference with this one. Nothing broke, nothing was fixed, nothing runs better or worse. Could be better, could be worse. Excitement.

[SamuriHL]

Well that's good at least. They're getting better.

[mclingo]

having some issues with AMD drivers after 21.8.2, all seem to have some issues playing "some" HEVC movies, I cant track down what it cant play though, here are the details of the movie it wont play, major screen corruption.


General
Complete name :
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/mp41)
File size : 1.90 GiB
Duration : 2 h 2 min
Overall bit rate : 2 230 kb/s
Movie name :
Encoded date : UTC 2021-12-31 14:14:58
Tagged date : UTC 2021-12-31 14:14:58
Writing application : Lavf58.20.100
Comment :

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : hev1
Codec ID/Info : High Efficiency Video Coding
Duration : 2 h 2 min
Bit rate : 2 000 kb/s
Width : 1 800 pixels
Height : 1 080 pixels
Display aspect ratio : 5:3
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.043
Stream size : 1.71 GiB (90%)
Writing library : x265 3.3+4-rarbg-30eb4de83092:[Linux][GCC 8.3.1][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1800x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=2000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0
Encoded date : UTC 2021-12-31 14:14:58
Tagged date : UTC 2021-12-31 14:14:58
Codec configuration box : hvcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 2 h 2 min
Duration_LastFrame : -11 ms
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 196 MiB (10%)
Language : English
Default : Yes
Alternate group : 1
Encoded date : UTC 2021-12-31 14:14:58
Tagged date : UTC 2021-12-31 14:14:58

[quietvoid]

having some issues with AMD drivers after 21.8.2, all seem to have some issues playing "some" HEVC movies, I cant track down what it cant play though, here are the details of the movie it wont play, major screen corruption.


The video is 5:3. I've personally had issues with hardware decoding on my 5500 XT in the past with similar aspect ratios.
As of now they play fine with current Linux 5.16 amdgpu drivers.

[aufkrawall]

AMD Linux and Windows drivers are vastly different, especially when it comes to hardware decoding. Might be broken for good, it's AMD Windows driver team.

[DMU]

Give a link to a similar video, please.

[mclingo]

sorry i dont have a small enough sample to provide a test video, i've also moved back to 21.8.2 to solve the issue, I will try the next version released and report back.

[mclingo]

I fixed this issue but using this setting but not sure what it is, havent seen this before, only D3D11 - does D3D11(cb) it mean copy back maybe?

Any ideas?


https://1drv.ms/u/s!AgvFafeelEBiqbY-q1llWgVCn2tdBQ?e=MIewLw

[Asmodian]

Yes, cb means copy back.

[mclingo]

wonder why it fixes the rendering problem then?