> performance-hungry programs (read: games) sometimes have to check the spec of the PC they're installed on and tell the poor punter that their PC isn't fast enough.
This seems like the root problem. Developers, please don't do this. Just let the user run the software, and if it's not fast enough for them, it will be self evident. Don't insert your own personal judgment about what kind of PC is "good enough" and if you absolutely feel you have to butt in like that, don't make the logic faulty like these games apparently do.
When I buy a game, I expect to run it. If my PC is too slow, it will run slowly and I'll be motivated to upgrade or fiddle with the graphics settings. Trying to be this performance police is like saying "Your PC is pathetic. In lieu of letting you run this software you paid for, please accept this picture of my middle finger instead." I wouldn't want to do business with a developer that treats me like that.
Also: Let API calls fail and return errors instead of trying to "predict" errors and be "helpful" to the user. You don't know how people are going to use the software you've written in the future.
Example: Old software that can't handle larger-than-expected disk free space. There are AppCompat shims in Windows for lying to applications re: free disk space quantity because some old applications stored the result of disk free queries in 32-bit integers. Who would ever have more than 4GB of free disk?!?
The integer overflows that result invariably cause unexpected behavior.
Just make the API call to write to the disk. If that returns "disk full" let the user know. Don't "check" first.
Surprisingly, some really old windows software installers will ask you want to run the install anyways even after it determines there's not enough space. That seems to be the ideal solution.
> Just make the API call to write to the disk. If that returns "disk full" let the user know. Don't "check" first.
idk. Things don't always behave super gracefully if the disk is actually entirely full, this could lead to data loss as other applications can't persist their state as they expect to be able to.
I think you have a good point but with the worst example. Though the example is good in that it shows the nuance of how it's clearly not always the best choice.
If you're doing something like a system update where you're updating shared libraries, you don't want to get the kernel and glibc yet only half the libraries. You could easily end up in a state where you're not able to rerun the install or even free space without booting up a live USB or something.
On the other hand, if you are running a Pentium II I know that you won't even be able to get past the menu screen. If I simply don't let you in at all, you'll go right to steam and ask for a refund, get it, and not be mad at me. If I do let you in, you may spend a few hours trying to tweak the settings, fail, be unable to get a refund, and leave a bad review.
I have many times seen this kind of error while running games in Proton. It has never actually prevented me from proceeding. It usually just says GPU too old / drivers out of date. Then it sets every graphics setting to its lowest value and lets you proceed.
Today's turbo button which does what it says (speed things up) is the two last buttons of uBlock Origin's first toolbar… which block web fonts and javascript. The fastest code is the one that is not downloaded and run.
> Which is a problem if the hapless app finds a shiny new 12th-gen processor that looks like a bunch of Atom-class cores – it complains that this new-fastest-ever-chip isn't quick enough.
From the article I assumed this was different from the DRM issue, but it links to the exact same Intel KB article.
Years ago, Sim City 4 and The Sims 2 had a similar problem – depending on the processor frequency and GPU model they'd automatically enable or disable certain graphics features.
The problem with that was that the processor frequency to high/medium/low-performance class mapping was being done based on Pentium 4 clock speeds, so if you were using an AMD processor (or even one of the first generations of Intel's own Core i-processors if you still happened to be playing those games a few years later) with a lower clock speed but higher IPCs (so a roughly equivalent performance), those games would mistakenly assume your processor was slow and disable various graphics effects and other settings.
Somewhat annoyingly, Maxis/EA never fixed that issue even though AMD processors weren't totally obscure even at that time, either.
The saving grace was that at least things weren't totally hard-coded – there was a rules file in a plain text-based format controlling the various things that should be enabled or disabled based on the detected performance level, and so it was comparatively easy to just change the expected clock speed levels to something more reasonable for a non-Pentium 4 processor.
Later this was also helpful because the GPU detection started having its own issues a few years down the line: When AMD started recycling model numbers for its graphics cards, some newer models were then being mis-identified as some slow, older model that would require various workarounds/lower graphics settings, so again you had to manually edit the rules to fix things.
From memory it was something like UT99 running a loop to determine CPU speed at the start when most modern CPUs are running at a lower clock, and when you start actually playing CPU speeds up and game engine goes crazy.
> This is an assembler instruction that reads the "Cycle Counter" value from your CPU."
It did that ~10 years ago. On modern CPUs however, that instruction reads a counter which grows at the stock frequency of the CPU (e.g. at 3.6GHz for Ryzen 5 3600), regardless of frequency scaling of any of the cores.
It's basically the same thing. DRM and anticheat software is deliberately picky to make sure it's running in an expected environment: nothing that looks like processors changing, varying in speed, etc, that may indicate debugging.
I sudo echo 0 > /sys/devices/system/cpu/cpufreq/boost (for AMD) to get constant clock rates when doing wall-time benchmarks. Sure, instruction counts would be more accurate but not everything has perf-counters built into it for measurements.
I should hotkey that to have a turbo button too.
Yes, I do occasionally use Excel (although I favour LibreOffice for most things these days.) TBH, though, this is I think the first time I have ever heard of anyone wanting this behaviour. Usually I heard about people who couldn't understand why they were no longer able to scroll around their spreadsheet in the usual way.
I'm vaguely glad to learn that someone somewhere does want this!
Scroll lock mode (arrow keys scrolling the window rather than moving the cursor) is almost identical to the way the arrow keys work to scroll a web page – a sort of keyboard equivalent to using a mouse scroll wheel or 2-finger scrolling on a trackpad. It's particularly nice in that it scrolls a single row or column at a time, and particularly useful for spreadsheets (Excel) and text editors.
I currently have a compact ("tenkeyless") keyboard which lacks the key, so I tend to use a spring-loaded setup where holding down alt/option/etc. and an arrow key scrolls the window.
This is basically what the Scroll Lock key was meant for in the first place, but the convention never really caught on, so the continued presence of the key baffles a lot of people. I recall FreeBSD's console driver supporting using Scroll Lock in a similar way to move through the scrollback buffer, although I don't know whether this is still true in practice (e.g. if using a UEFI or drm console driver rather than old-school VGA).
Terrible post. It's nothing like the turbo button. This iteration is based on aggressive DRM that gets it wrong. Maybe having different game threads on one or the other type of core might matter but that's not what the current problem is.
Slightly off topic but Porsche came out with an EV and the top trim is called "Turbo S" which lines up with their other gas car naming.
Some people got upset because it doesn't have a turbocharger in it and felt it was wrong to use the word in the name.
Because of turbo buttons on PCs when i was growing up, turbo buttons on 3rd party console controllers, and many other experiences i always associated with just fast, not a specific car part.
Critics of the Taycan Turbo badging usually make some argument about "Turbo" meaning the-model-that-has-turbocharger(s), but Porsche hasn't been consistent about that for some time. The iconic 911 Turbo is turbocharged, but since 2015 the regular non-Turbo 911 is as well.
(Next we can discuss whether a "Mustang" is a kind of horse, a two-door sports car, a four-door electric crossover, or...)
TL;DR: Games may look at the efficiency cores of new hybrid Intel CPUs and determine the CPU is too slow to run the game. Intel fix: If enabled in the firmware, you can disable those cores (leaving only the beefy ones) by pushing scroll lock.
(Disclaimer: No fact checking was performed on my end).
>Better still, you won't need any new hardware, because it's repurposing something you already have but never use: your Scroll Lock key.
But I do use it. It's a great key for toggling screen recording, because it's right next to Print Screen and makes logical sense in terms of positioning. It also doesn't do anything useful, or didn't.
Obviously it's not a real problem, but you can't really assume people don't work buttons into their workflow that aren't normally used.
There's a whole series of annoying problems which come from this mix of fast and slow CPUs. I want to put the refresh thread on a fast CPU, the asset loading threads on slow CPUs, and the network update thread on something in between. How do I tell the OS that?
A problem right now is asking how much memory the GPU has. The NVidia driver for Linux will spill data out to main memory if the GPU memory fills up, but you take about a 50% performance hit when this happens. It's better to cut down distant detail and stay in fast GPU memory. But it's hard to find out how much GPU memory is available and how much a spill costs. With "onboard graphics", as in laptops, there may not be any dedicated GPU memory, so this isn't even a meaningful question.
The original IBM PC could have been 5Mhz. But, it was set to 4.77Mhz instead because that way the NTSC out feature of the video card could piggyback it's signal generator off of the CPU clock rather than paying for an additional clock. That way you didn't necessarily have to buy a computer monitor. You could cheap out and use your existing TV instead.
Later models obviously ran faster, but that broke the TV out feature. It seems bad to sell people a newer, more expensive model that loses a popular feature. So, a TV back-compat button was put in so you could still use your TV in cases where you really need to. Technically, you didn't lose the feature when you upgraded.
Also, some games were written with the assumption of a fixed 4.77Mhz clock and would run unplayably fast on newer machines. The back-compat button would slow the machine down so you could still play last-year's games.
But "NTSC Backwards Compatibility Button" is not a sexy name for a feature. So, some genius labeled it the "Turbo Button" even though it actually slowed down the machine.
Once the early machines had it, all the later machines had to have it too. For a long time it simply cut the clock rate in half. Eventually, it did nothing and was abandoned soon after.
The 286 could still run at a low enough clock speed that changing the clock frequency made sense.
On the 386 that didn't work anymore, but there was an external cache. So typically, the turbo button would disable external cache.
Then the 486 came with built-in L1 cache. And it was always way too fast. At that point the turbo button didn't make sense any more. I guess there were software solutions, but I don't recall any name.
That screen was just telling you whether the switch was on or off, though - the logic to decide what to display was just a series of jumpers in the case front. That's why some were configured to read
|_| |
| | |
and
| _
|_ |_|
instead. It's not like it was actually measuring the bus frequency.
There was definitely a "cache enable" pin on the 486 socket.
I had a 5x86/133 that had that pin broken. It worked but unimaginably slowly. Wedging a snapped off pin from another CPU into the socket and trying to keep the whole mess bodged/glued/soldered together made it usable again.
This seems like the root problem. Developers, please don't do this. Just let the user run the software, and if it's not fast enough for them, it will be self evident. Don't insert your own personal judgment about what kind of PC is "good enough" and if you absolutely feel you have to butt in like that, don't make the logic faulty like these games apparently do.
When I buy a game, I expect to run it. If my PC is too slow, it will run slowly and I'll be motivated to upgrade or fiddle with the graphics settings. Trying to be this performance police is like saying "Your PC is pathetic. In lieu of letting you run this software you paid for, please accept this picture of my middle finger instead." I wouldn't want to do business with a developer that treats me like that.