Glossary talk:Graphics card

About this board

Mirh (talkcontribs)

I knew people could be annoyed by PWM, howsoever bad a display could use it. But I just wasn't aware there are people sensitive to *dithering* (and there seems to be a whole forum of them)

... While I was writing this comment, I also remembered that a lot of "average joes and janes" I know use(d) to dislike computers a fair bit because after a relatively short while nausea and eyesore ensued. Some were just doofus that couldn't understand the concept of "monitor brightness settings", but I guess even mentioning blue-light blocking glasses could still be a step forward for gaming here.

A deficiencies "subjective factors" page could probably be created.

Reply to "Photons sensitivity"
Mirh (talkcontribs)

We don't have an article about display interfaces, so here's a roundup of problems:

  • Despite DE-15 being technically compatible with SCART, component, composite and whatnot, passive adapters (but even a lot of "normal" active ones, which are just meant to go from a modern digital connection to PC VGA) won't work with most older TVs due to just-too-different video sync signals, scan rate or color space.
  • RGB-to-CRT hacks, custom cabling, having a multisync magic box or an old VIVO card are all possible solutions. Or you could just buy a direct converter between the two desired standards.
  • Not only may monitors support different "overt features" depending on the protocol and port they are currently hooked with, these factors can even affect input lag
  • The final capabilities and bandwidth of a video connection is determined by the greatest common divisor between the GPU display engine block, the physical link encoder, cables (and/or possible adapters), and display-receiver:
  • Data rate bounds are set by the RAMDAC frequency for VGA, while DVI and HDMI terms are set by the TMDS clock. These can often lead to lower supported resolutions than the official maximum of the protocols, especially on laptops (I have yet to hear about similar unexpected shortcomings in DP though)
  • these limitations, which can be even more paradoxical with adapters in-between, can be sometimes worked around (even with respect to the official specification), particularly on linux.
  • As far as "features themselves" are concerned instead, display controllers are relatively programmable (as seen many times), and these are almost never theoretically unachievable.
  • it goes without saying though, the GPU drivers are paramount in doing anything. And when it's not for the flip-flopping bugs (best to draw a veil over this) they still have arbitrary blocks, from VRR to chroma subsampling. Sometimes even the specification itself can be too stupid for its own sake.
  • "Embedded" applications (i.e. about anywhere that isn't a desktop PC) have less stricter (and uniform) requirements on the transmitter chip bridges (this is most notable in the TV world with the most disparate subsets of HDMI 2.1 limitations)
  • Seriously, adapters are a can of worms.
  • Cables don't have "versions" (well, except HDMI w/ ethernet which is separate by design I guess). You only have a minimum guaranteed bandwidth certification, which the actual cord could also easily exceed in practice.
  • Of course there are all similar kinds of problems on the screen's end too.
  • not last, since HDMI for some whimsical reason cannot have the YCbCr 4:2:2 bit depth measured (the thing actually always being carried on a 12-bit signal), some displays diagnostics menus can report "8 bit" as a placeholder value
  • tinkering around bandwidth limitation of the interface is even more of a nightmare when the usual caveats meet HDR
  • many TVs may outright refuse any non-standard (as in: anything that isn't commonly found in a "home theatre" setting) resolution, even when forced
  • this is at least still better than the past, when they didn't support non-subsampled 4:4:4 colours either
Reply to "Cables, interfaces, and you"
Mirh (talkcontribs)

So... These days graphic drivers are probably too much complex to be modified by users.. Though once, some people used to fix and improve them, without having to wait for ATi or Nvidia grace
I could find some names in this comparison. Omega, DNA, NGO, DHzer0point...

They may be worth a look for anybody on older cards with special needs. In particular AGP compatibility issues should be solved.
Please take note not every driver supports Windows Vista.
Original hosters are down or discontinued by now, though mirrors are available


Thankfully Intel graphics is still so slow and buggy that compilations are a must.
Putting aside the famous intellimodder (old mirrors, caution it screws with power plans), you have:

For anything from Ivy Bridge and above instead (dx11 igps), really, don't bother. Some slight overclocking or setting Windows to high performance energy profile is the most optimization you can reasonably get.

EDIT: in fact, I think I just now figured out the functioning basis of all the hacks that have ever been. Intel older igps were so shitty, that despite them having in-hardware support for some features (such as SM3.0 and T&L), you could actually get them offloaded to the cpu and increase your performance. Because whatever the obvious overhead this operation has, it was still faster than tasking the potato gpu with yet another operation (or maybe vertex processing is just straightaway quicker on a 200€ cpu of the time, compared to a 2€ graphics adapter).

Anyway, for these reasons the driver has a registry whitelist codenamed "Enable3DContexts" (I don't even want to think instead to that can of software worms Gen3 was). In my testing with a X4500 and the latest 2869 stock drivers, I found out that after setting Mass Effect exe to 1, frametimes improved by more than 10% (benchmarks and a bunch of newer applications seemed to have the mysterious value of 2 OOTB, mileage may vary on what's the best one).

Once accounted for that, there was no other difference in ME1 and HL2 across all the 4 modded drivers. DODSQE maybe is the only other thing with a possible 3D speed impact, but I couldn't confirm.

So.. I believe that a fair TL;DR would be that at least if you are on a desktop, in the proper Windows version the official drivers were released for, there's no need to install anything else. Even though in 2020 it's probably easier to find and download a hacky community driver, than the actually latest version from the intel website.

I guess W10 (though there is the question of why even using that when you are low-end-gaming hard) or laptops are different story instead. The original .infs might even have been explicitly disallowing "forward-compatibility", and for example Display1_EnableDynamicScaling is allegedly among the requirements for metro (thus UWP?) applications to work properly.

Let alone laptops, whose silicon may even be identical, except that they have been heavily down binned. And then there's all the LVDS voltages and timings, or that god forbid OEMs let you had a nice BIOS with all the right memory settings.

Reply to "Custom drivers"
SirYodaJedi (talkcontribs)

This might be useful docs.google.com/document/d/1xRRx_3r8GgCpBAMuhT9n5kK6Zse_DYKWvjsW0rLcYQ0/edit

Reply to "Display Driver Uninstaller"
Mirh (talkcontribs)
Reply to "Non-Power-Of-Two textures"
Mirh (talkcontribs)

A list with some affected games can be found here

One of the recommended workarounds looked suspiciously too similar to a problem I once had in CoD and this

...

So I realized we have a little to much confusion in our files section. There are:

... and nobody has a clue of whatever there are even differences between these files.

Somebody should check that.

Expack3 (talkcontribs)

All those games on the VOGONS list are pre-DX8 - meaning dgVoodoo2 will likely work for them. Heck, Darkstone, a game not on that list, sufferes from Z-buffer issues on AMD hardware with recent drivers unless you use dgVoodoo2!

As for the more modern ones?...I haven't a clue. WineD3D for Windows without game-specific specific compilation settings or code modifications is too unreliable to work for DirectX games in general (though there will be outliers, like Silent Storm), and I don't know of anything which converts OpenGL code from a lower version to a higher one (i.e. OpenGL 1.0 to OpenGL 4.0).

Mirh (talkcontribs)

If it's just for Z-buffer, I'm pretty sure swapping dlls can already be considered a good solution.
The thing that really turn up my nose was that.. we probably have 5 dlls for a single issue (or two at most).

Btw I don't think there are going to be problems with openGL, considering all the fuss behind retrocompatibility with that API.

Expack3 (talkcontribs)

Yes, a good solution, but not the solution. Depending on which DLL we settle on, we'll eventually hit a point where either the graphics card or the OS is simply unsupported.

Again, for pre-DX8 games, dgVoodoo2 is the way to go for most games since it mainly relies on DX11's continued support and the author continuing to maintain the app. Just slap in the replacement DirectX DLLs, configure them as needed, then play the game. Really that simple for those ancient games! Even then, dgVoodoo2 is still a solution. A dang fine solution, but just one solution nonetheless.

Mirh (talkcontribs)

Well, I wouldn't know.
I mean.. we are talking about a normal user side dll, not the system driver.

Aside of the OS (drivers are even forward compatible most of times) I guess that a new architecture may indeed change the way it can be instructed...

Anyway, do you know if dgVoodoo2 also support W-buffer?

Expack3 (talkcontribs)
Reply to "Z-buffer issues + download hell"
There are no older topics