Subject: Graphics Cards | March 21, 2017 - 07:47 PM | Scott Michaud
Tagged: windows 10, vulkan, sli, multi-gpu, crossfire
Update (March 22nd @ 3:50pm EDT): And the Khronos Group has just responded to my follow-up questions. LDA has existed since Windows Vista, at the time for assisting with SLI and Crossfire support. Its implementation has changed in Windows 10, but that's not really relevant for Vulkan's multi-GPU support. To prove this, they showed LDA referenced in a Windows 8.1 MSDN post.
Vulkan's multi-GPU extensions can be used on Windows 7 and Windows 8.x. The exact process will vary from OS to OS, but the GPU vendor can implement these extensions if they choose, and LDA mode isn't exclusive to Windows 10.
Update (March 21st @ 11:55pm EDT): I came across a Microsoft Support page that discusses issues with LDA in Windows 7, so it seems like that functionality isn't limited to WDDM 2.0 and Windows 10. (Why have a support page otherwise?) Previously, I looked up an MSDN article that had it listed as a WDDM 2.0 feature, so I figured DSOGaming's assertion that it was introduced with WDDM 2.0 was correct.
As such, LDA might not require a GPU vendor's implementation at all. It'll probably be more clear when the Khronos Group responds to my earlier request, though.
That said, we're arguing over how much a GPU vendor needs to implement; either way, it will be possible to use the multi-GPU extensions in Windows 7 and Windows 8.x if the driver supports it.
Update (March 21st @ 7:30pm EDT): The Khronos Group has just released their statement. It's still a bit unclear, and I've submit another request for clarification.
Specifically, the third statement:
If an implementation on Windows does decide to use LDA mode, it is NOT tied to Windows 10. LDA mode has been available on many versions of Windows, including Windows 7 and 8.X.
... doesn't elaborate what is required for LDA mode on Windows outside of 10. (It could be Microsoft-supported, vendor-supported, or something else entirely.) I'll update again when that information is available. For now, it seems like the table, below, should actually look something like this:
|macOS||Apple doesn't allow the Vulkan API to ship in graphics drivers.
|Linux / etc.||✓||✓||✓|
... but we will update, again, should this be inaccurate.
Update (March 20th @ 3:50pm EDT): The Khronos Group has just responded that the other posts are incorrect. They haven't yet confirmed whether this post (which separates "device groups" from the more general "multi-GPU in Vulkan") is correct, though, because they're preparing an official statement. We'll update when we have more info.
Original Post Below (March 19th @ 9:36pm EDT)
A couple of days ago, some sites have noticed a bullet point that claims Windows-based GPU drivers will need WDDM in “linked display adapter” mode for “Native multi-GPU support for NVIDIA SLI and AMD Crossfire platforms” on Vulkan. This note came from an official slide deck by the Khronos Group, which was published during the recent Game Developers Conference, GDC 2017. The concern is that “linked display adapter” mode is a part of WDDM 2.0, which is exclusive to Windows 10.
This is being interpreted as “Vulkan does not support multi-GPU under Windows 7 or 8.x”.
I reached out to the Khronos Group for clarification, but I’m fairly sure I know what this does (and doesn’t) mean. Rather than starting with a written out explanation in prose, I will summarize it into a table, below, outlining what is possible on each platform. I will then elaborate below that.
|macOS||Apple doesn't allow the Vulkan API to ship in graphics drivers.
|Linux / etc.||✓||✓||✓|
So the good news is that it’s possible for a game developer to support multi-GPU (through what DirectX 12 would call MDA) on Windows 7 and Windows 8.x; the bad news is that no-one might bother with the heavy lifting. Linked display adapters allow the developer to assume that all GPUs are roughly the same performance, have the same amount of usable memory, and can be accessed through a single driver interface. On top of these assumptions, device groups also hide some annoying and tedious work inside the graphics driver, like producing a texture on one graphics card and quickly giving it to another GPU for rendering.
Basically, if the developer will go through the trouble of supporting AMD + NVIDIA or discrete GPU + integrated GPU systems, then they can support Windows 7 / 8.x in multi-GPU as well. Otherwise? Your extra GPUs will be sitting out unless you switch to DirectX 11 or OpenGL (or you use it for video encoding or something else outside the game).
On the other hand, this limitation might pressure some developers to support unlinked multi-GPU configurations. There are some interesting possibilities, including post-processing, GPGPU tasks like AI visibility and physics, and so forth, which might be ignored in titles whose developers were seduced by the simplicity of device groups. On the whole, device groups was apparently a high-priority request by game developers, and its inclusion will lead to more multi-GPU content. Developers who can justify doing it themselves, though, now have another reason to bother re-inventing a few wheels.
Or... you could just use Linux. That works, too.
Again, we are still waiting on the Khronos Group to confirm this story. See the latest update, above.
Subject: Processors | March 13, 2017 - 08:48 PM | Sebastian Peak
Tagged: Windows 7, windows 10, thread scheduling, SMT, ryzen, Robert Hallock, processor, cpu, amd
AMD's Robert Hallock (previously the Head of Global Technical Marketing for AMD and now working full time on the CPU side of things) has posted a comprehensive Ryzen update, covering AMD's official stance on Windows 10 thread scheduling, the performance implications of SMT, Windows power management settings, and more. The post in its entirety is reproduced below, and also available from AMD by following this link.
It’s been about two weeks since we launched the new AMD Ryzen™ processor, and I’m just thrilled to see all the excitement and chatter surrounding our new chip. Seems like not a day goes by when I’m not being tweeted by someone doing a new build, often for the first time in many years. Reports from media and users have also been good:
- “This CPU gives you something that we needed for a long time, which is a CPU that gives you a well-rounded experience.” –JayzTwoCents
- Competitive performance at 1080p, with Tech Spot saying the “affordable Ryzen 7 1700” is an “awesome option” and a “safer bet long term.”
- ExtremeTech showed strong performance for high-end GPUs like the GeForce GTX 1080 Ti, especially for gamers that understand how much value AMD Ryzen™ brings to the table
- Many users are noting that the 8-core design of AMD Ryzen™ 7 processors enables “noticeably SMOOTHER” performance compared to their old platforms.
While these findings have been great to read, we are just getting started! The AMD Ryzen™ processor and AM4 Platform both have room to grow, and we wanted to take a few minutes to address some of the questions and comments being discussed across the web.
We have investigated reports alleging incorrect thread scheduling on the AMD Ryzen™ processor. Based on our findings, AMD believes that the Windows® 10 thread scheduler is operating properly for “Zen,” and we do not presently believe there is an issue with the scheduler adversely utilizing the logical and physical configurations of the architecture.
As an extension of this investigation, we have also reviewed topology logs generated by the Sysinternals Coreinfo utility. We have determined that an outdated version of the application was responsible for originating the incorrect topology data that has been widely reported in the media. Coreinfo v3.31 (or later) will produce the correct results.
Finally, we have reviewed the limited available evidence concerning performance deltas between Windows® 7 and Windows® 10 on the AMD Ryzen™ CPU. We do not believe there is an issue with scheduling differences between the two versions of Windows. Any differences in performance can be more likely attributed to software architecture differences between these OSes.
Going forward, our analysis highlights that there are many applications that already make good use of the cores and threads in Ryzen, and there are other applications that can better utilize the topology and capabilities of our new CPU with some targeted optimizations. These opportunities are already being actively worked via the AMD Ryzen™ dev kit program that has sampled 300+ systems worldwide.
Above all, we would like to thank the community for their efforts to understand the Ryzen processor and reporting their findings. The software/hardware relationship is a complex one, with additional layers of nuance when preexisting software is exposed to an all-new architecture. We are already finding many small changes that can improve the Ryzen performance in certain applications, and we are optimistic that these will result in beneficial optimizations for current and future applications.
The primary temperature reporting sensor of the AMD Ryzen™ processor is a sensor called “T Control,” or tCTL for short. The tCTL sensor is derived from the junction (Tj) temperature—the interface point between the die and heatspreader—but it may be offset on certain CPU models so that all models on the AM4 Platform have the same maximum tCTL value. This approach ensures that all AMD Ryzen™ processors have a consistent fan policy.
Specifically, the AMD Ryzen™ 7 1700X and 1800X carry a +20°C offset between the tCTL° (reported) temperature and the actual Tj° temperature. In the short term, users of the AMD Ryzen™ 1700X and 1800X can simply subtract 20°C to determine the true junction temperature of their processor. No arithmetic is required for the Ryzen 7 1700. Long term, we expect temperature monitoring software to better understand our tCTL offsets to report the junction temperature automatically.
The table below serves as an example of how the tCTL sensor can be interpreted in a hypothetical scenario where a Ryzen processor is operating at 38°C.
Users may have heard that AMD recommends the High Performance power plan within Windows® 10 for the best performance on Ryzen, and indeed we do. We recommend this plan for two key reasons:
- Core Parking OFF: Idle CPU cores are instantaneously available for thread scheduling. In contrast, the Balanced plan aggressively places idle CPU cores into low power states. This can cause additional latency when un-parking cores to accommodate varying loads.
- Fast frequency change: The AMD Ryzen™ processor can alter its voltage and frequency states in the 1ms intervals natively supported by the “Zen” architecture. In contrast, the Balanced plan may take longer for voltage and frequency (V/f) changes due to software participation in power state changes.
In the near term, we recommend that games and other high-performance applications are complemented by the High Performance plan. By the first week of April, AMD intends to provide an update for AMD Ryzen™ processors that optimizes the power policy parameters of the Balanced plan to favor performance more consistent with the typical usage models of a desktop PC.
Simultaneous Multi-threading (SMT)
Finally, we have investigated reports of instances where SMT is producing reduced performance in a handful of games. Based on our characterization of game workloads, it is our expectation that gaming applications should generally see a neutral/positive benefit from SMT. We see this neutral/positive behavior in a wide range of titles, including: Arma® 3, Battlefield™ 1, Mafia™ III, Watch Dogs™ 2, Sid Meier’s Civilization® VI, For Honor™, Hitman™, Mirror’s Edge™ Catalyst and The Division™. Independent 3rd-party analyses have corroborated these findings.
For the remaining outliers, AMD again sees multiple opportunities within the codebases of specific applications to improve how this software addresses the “Zen” architecture. We have already identified some simple changes that can improve a game’s understanding of the "Zen" core/cache topology, and we intend to provide a status update to the community when they are ready.
Overall, we are thrilled with the outpouring of support we’ve seen from AMD fans new and old. We love seeing your new builds, your benchmarks, your excitement, and your deep dives into the nuts and bolts of Ryzen. You are helping us make Ryzen™ even better by the day. You should expect to hear from us regularly through this blog to answer new questions and give you updates on new improvements in the Ryzen ecosystem.
Such topics as Windows 7 vs. Windows 10 performance, SMT impact, and thread scheduling will no doubt still be debated, and AMD has correctly pointed out that optimization for this brand new architecture will only improve Ryzen performance going forward. Our own findings as to Ryzen and the Windows 10 thread scheduler appear to be validated as AMD officially dismisses performance impact in that area, though there is still room for improvement in other areas from our initial gaming performance findings. As mentioned in the post, AMD will have an update for Windows power plan optimization by the first week of April, and the company has "already identified some simple changes that can improve a game’s understanding of the 'Zen' core/cache topology, and we intend to provide a status update to the community when they are ready", as well.
It is refreshing to see a company publicly acknowledging the topics that have resulted in so much discussion in the past couple of weeks, and their transparency is commendable, with every issue (that this author is aware of) being touched on in the post.
** UPDATE 3/13 5 PM **
AMD has posted a follow-up statement that officially clears up much of the conjecture this article was attempting to clarify. Relevant points from their post that relate to this article as well as many of the requests for additional testing we have seen since its posting (emphasis mine):
"We have investigated reports alleging incorrect thread scheduling on the AMD Ryzen™ processor. Based on our findings, AMD believes that the Windows® 10 thread scheduler is operating properly for “Zen,” and we do not presently believe there is an issue with the scheduler adversely utilizing the logical and physical configurations of the architecture."
"Finally, we have reviewed the limited available evidence concerning performance deltas between Windows® 7 and Windows® 10 on the AMD Ryzen™ CPU. We do not believe there is an issue with scheduling differences between the two versions of Windows. Any differences in performance can be more likely attributed to software architecture differences between these OSes."
So there you have it, straight from the horse's mouth. AMD does not believe the problem lies within the Windows thread scheduler. SMT performance in gaming workloads was also addressed:
"Finally, we have investigated reports of instances where SMT is producing reduced performance in a handful of games. Based on our characterization of game workloads, it is our expectation that gaming applications should generally see a neutral/positive benefit from SMT. We see this neutral/positive behavior in a wide range of titles, including: Arma® 3, Battlefield™ 1, Mafia™ III, Watch Dogs™ 2, Sid Meier’s Civilization® VI, For Honor™, Hitman™, Mirror’s Edge™ Catalyst and The Division™. Independent 3rd-party analyses have corroborated these findings.
For the remaining outliers, AMD again sees multiple opportunities within the codebases of specific applications to improve how this software addresses the “Zen” architecture. We have already identified some simple changes that can improve a game’s understanding of the "Zen" core/cache topology, and we intend to provide a status update to the community when they are ready."
We are still digging into the observed differences of toggling SMT compared with disabling the second CCX, but it is good to see AMD issue a clarifying statement here for all of those out there observing and reporting on SMT-related performance deltas.
** END UPDATE **
Editor's Note: The testing you see here was a response to many days of comments and questions to our team on how and why AMD Ryzen processors are seeing performance gaps in 1080p gaming (and other scenarios) in comparison to Intel Core processors. Several outlets have posted that the culprit is the Windows 10 scheduler and its inability to properly allocate work across the logical vs. physical cores of the Zen architecture. As it turns out, we can prove that isn't the case at all. -Ryan Shrout
Initial reviews of AMD’s Ryzen CPU revealed a few inefficiencies in some situations particularly in gaming workloads running at the more common resolutions like 1080p, where the CPU comprises more of a bottleneck when coupled with modern GPUs. Lots of folks have theorized about what could possibly be causing these issues, and most recent attention appears to have been directed at the Windows 10 scheduler and its supposed inability to properly place threads on the Ryzen cores for the most efficient processing.
I typically have Task Manager open while running storage tests (they are boring to watch otherwise), and I naturally had it open during Ryzen platform storage testing. I’m accustomed to how the IO workers are distributed across reported threads, and in the case of SMT capable CPUs, distributed across cores. There is a clear difference when viewing our custom storage workloads with SMT on vs. off, and it was dead obvious to me that core loading was working as expected while I was testing Ryzen. I went back and pulled the actual thread/core loading data from my testing results to confirm:
The Windows scheduler has a habit of bouncing processes across available processor threads. This naturally happens as other processes share time with a particular core, with the heavier process not necessarily switching back to the same core. As you can see above, the single IO handler thread was spread across the first four cores during its run, but the Windows scheduler was always hitting just one of the two available SMT threads on any single core at one time.
My testing for Ryan’s Ryzen review consisted of only single threaded workloads, but we can make things a bit clearer by loading down half of the CPU while toggling SMT off. We do this by increasing the worker count (4) to be half of the available threads on the Ryzen processor, which is 8 with SMT disabled in the motherboard BIOS.
SMT OFF, 8 cores, 4 workers
With SMT off, the scheduler is clearly not giving priority to any particular core and the work is spread throughout the physical cores in a fairly even fashion.
Now let’s try with SMT turned back on and doubling the number of IO workers to 8 to keep the CPU half loaded:
SMT ON, 16 (logical) cores, 8 workers
With SMT on, we see a very different result. The scheduler is clearly loading only one thread per core. This could only be possible if Windows was aware of the 2-way SMT (two threads per core) configuration of the Ryzen processor. Do note that sometimes the workload will toggle around every few seconds, but the total loading on each physical core will still remain at ~%50. I chose a workload that saturated its thread just enough for Windows to not shift it around as it ran, making the above result even clearer.
Synthetic Testing Procedure
While the storage testing methods above provide a real-world example of the Windows 10 scheduler working as expected, we do have another workload that can help demonstrate core balancing with Intel Core and AMD Ryzen processors. A quick and simple custom-built C++ application can be used to generate generic worker threads and monitor for core collisions and resolutions.
This test app has a very straight forward workflow. Every few seconds it generates a new thread, capping at N/2 threads total, where N is equal to the reported number of logical cores. If the OS scheduler is working as expected, it should load 8 threads across 8 physical cores, though the division between the specific logical core per physical core will be based on very minute parameters and conditions going on in the OS background.
By monitoring the APIC_ID through the CPUID instruction, the first application thread monitors all threads and detects and reports on collisions - when a thread from our app is running on the same core as another thread from our app. That thread also reports when those collisions have been cleared. In an ideal and expected environment where Windows 10 knows the boundaries of physical and logical cores, you should never see more than one thread of a core loaded at the same time.
Click to Enlarge
This screenshot shows our app working on the left and the Windows Task Manager on the right with logical cores labeled. While it may look like all logical cores are being utilized at the same time, in fact they are not. At any given point, only LCore 0 or LCore 1 are actively processing a thread. Need proof? Check out the modified view of the task manager where I copy the graph of LCore 1/5/9/13 over the graph of LCore 0/4/8/12 with inverted colors to aid viewability.
If you look closely, by overlapping the graphs in this way, you can see that the threads migrate from LCore 0 to LCore 1, LCore 4 to LCore 5, and so on. The graphs intersect and fill in to consume ~100% of the physical core. This pattern is repeated for the other 8 logical cores on the right two columns as well.
Running the same application on a Core i7-5960X Haswell-E 8-core processor shows a very similar behavior.
Click to Enlarge
Each pair of logical cores shares a single thread and when thread transitions occur away from LCore N, they migrate perfectly to LCore N+1. It does appear that in this scenario the Intel system is showing a more stable threaded distribution than the Ryzen system. While that may in fact incur some performance advantage for the 5960X configuration, the penalty for intra-core thread migration is expected to be very minute.
The fact that Windows 10 is balancing the 8 thread load specifically between matching logical core pairs indicates that the operating system is perfectly aware of the processor topology and is selecting distinct cores first to complete the work.
Information from this custom application, along with the storage performance tool example above, clearly show that Windows 10 is attempting to balance work on Ryzen between cores in the same manner that we have experienced with Intel and its HyperThreaded processors for many years.
Subject: General Tech | March 3, 2017 - 01:33 PM | Jeremy Hellstrom
Tagged: microsoft, windows 10
If you are using Windows 10 Pro or Enterprise, you may have already disabled the automatic reboot function after updates are installed but for Home users after the Anniversary update, that has not been possible. It turns out there are a lot of users quite upset with unplanned reboots, especially those who leave their computers running overnight or while they are away. Microsoft have accepted this feedback and will return the ability to delay reboots to owners of the Home Edition in their next update. In the meantime, The Register describes a way in which you can regain a little more control over automatic reboots with your current build.
"Since the Windows 10 Anniversary Update in 2016, there is no way to prevent Windows 10 [Home] from automatically installing updates and rebooting your PC," fumed one vulture fan, John, who added that a group policy can be set on W10 Pro and Enterprise editions to prevent automated restarts."
Here is some more Tech News from around the web:
- Skype-on-Linux graduates from Alpha to Beta status @ The Register
- Google's troll-destroying AI can't cope with typos @ The Register
- biquiti UniFi AP AC HD WiFi Access Point (UAP-AC-HD) @ Custom PC Review
- Windows Phone users may find it harder to find love @ The Inquirer
Subject: General Tech | February 17, 2017 - 07:01 AM | Scott Michaud
Tagged: windows 10, microsoft
Don’t worry if you didn’t receive cumulative Windows Updates this month.
At first, Microsoft showed no love for Valentine’s Day when they delayed the update that was supposed to roll out to the public. No explanation was provided. Two days later, Microsoft decided to write off the whole month. Everything that has been fixed since January 10th will be delayed until March 14th.
This is quite the wait. Peter Bright of Ars Technica notes that “off-cycle updates are also unpopular”. Yes, IT professionals hate it when software vendors are difficult to schedule around. I’m not sure how much that had to do with this decision, though. On the one hand, when a new build launches to the public, it’s not uncommon to have an update (or more) per week over the first couple of months. On the other hand, it would be reasonable for Microsoft to assume that customers, those who carefully test patches before deploying them, would not have ingested a huge, nebulous feature release into their network just weeks after launch. Still, out-of-band updates happen, and it’s interesting that it didn’t happen in this circumstance.
One thing that this patch should have fixed, however, is delayed or clipped display output in games (and other 3D applications) on multi-monitor systems. While not as critical as security, it is probably annoying for anyone affected to need to wait another 28 days. Microsoft claims it will be fixed then, though.
Subject: General Tech | February 4, 2017 - 11:54 PM | Tim Verry
Tagged: windows insider, Windows Game Mode, windows 10, pc gaming, creators update, beta
Last month Microsoft confirmed that a new "Game Mode" would be part of the upcoming Windows 10 Creator's Update planned for a spring release ("early 2017"). Microsoft has recently started rolling out the Game Mode to its beta testers in the latest Windows Insider preview build (for those on the fast track anyway, I am currently on the slow ring and do not have Game Mode yet). Now that it is rolled out in preview form, gamers have naturally started benchmarking it, and PC Games News has posted an article on their testing of the new feature and their findings on two Win32 and one UWP game. Not to spoil the results, but at this point Game Mode does not appear to offer anything and can even result in less frames per second with it turned on with its only saving grace being that in some situations it does offer increased performance when the Game DVR feature is also being used to record gameplay. They tested both a NVIDIA GTX 1060 and an AMD RX 480, and Game Mode in it's current preview software on a preview OS appears to have more benefits for NVIDIA while the AMD card PC Games News tested mostly just did it's thing regardless of whether Game Mode was turned on or off (heh, not necessarily a bad thing).
With Game Mode now rolling out to Windows Insiders, there is more information on how Microsoft plans to implement it. Rather than hiding it in the Xbox app, Microsoft has thankfully put it in the main settings app under the Gaming category and users access it by bringing up a Game Bar menu in-game for those games that support it (PC Games News noted Doom and GTA V did not work). Game Mode is an OS-level feature that will dedicate a certain amount of CPU threads to the game when it is turned on and leaves the remaining threads to be used by background processes (which themselves are reportedly minimized). Currently, this seems to work better with multi-threaded games and older games that were coded to only use one or two threads may not see any benefit in turning Game Mode on (and it may actually result in lower FPS). To Microsoft's credit, they are not over promising with Game Mode and note that it should be good for around 2% better performance when enabled with Game Mode having a bigger impact on UWP titles.
I encourage you to check out the PC Games News article where they have their benchmark results presented in a number of bar graphs. Most of the tests saw little to no benefit from using Game Mode, but not a negative effect. Some games like Hitman saw a 6% increase in average frames per second on the GTX 1060. On the other side of things, Forza Horizon 3 (ironically, a UWP game) performance actually drops when Game Mode is turned on to the tune of 13% to 23% less FPS with the RX 480 and 9% to 15% less with the GTX 1060. As far as Tomb Raider, things are more in the middle and things stay the same or get slightly better minimum frames per second when Game Mode and Game DVR are both turned on (though oddly there is a result in there that shows a performance drop with Game Mode on and Game DVR off).
It ia also worth noting that overall, the trend seems to be that Game Mode is going to be most beneficial at increasing the minimum frame rates on games with the Game DVR feature is being used moreso than getting overall maximum or average FPS out of a game. The biggest hurdle is going to be game compatiblity, especially for older games, and Microsoft tweaking things so that at worst Game Mode won't tank performance (like it currently does with Hitman minimum frame rates when Game Mode is on but DVR is off) and things will stay the same as if Game Mode was not on at all and at best gamers will get slightly smoother gameplay.
Right now Game Mode is not compelling, but it is still a work in progress and if Microsoft can get Game Mode right it could be a useful addition (and incentive to upgrade to Windows 10 is probably why they are interested in pursuing this feature) and could come in handy especially on gaming laptops! I am not writing off the feature yet, and neither should you, but I do hope that compatibility is improved and the performance hits are reduced or eliminated when it is enabled. My guess is that the games that will work well with Game Mode are going to be almost all newer games and especially games that are developed post Creator's Update final release with Game Mode in mind.
Hopefully we can use our frame rating on the final product to see how well it truly works as far as user experience and smooth gameplay. What are your thoughts on Windows 10's Game Mode?
Subject: General Tech | January 25, 2017 - 01:18 PM | Jeremy Hellstrom
Tagged: apple, wine, linux, windows 10, mac
So much for your excuses, if you have sworn that you are abandoning Microsoft because of Windows 10 then start migrating to Mac or Linux and shrink their market share. Wine 2.0 just dropped, allowing you to continue to use your Windows programs and play your games on Mac or Linux. Shader Model 4 and 5 support has been improved, DX9, Direct3D 10 and Direct3D 11 all are improved or added for your visual enjoyment. If you want to make a statement to Microsoft then hit them where it hurts and head over to Slashdot to start your journey onto a competitors OS.
"It's finally here! After so many months of development and hard work, during which over 6,600 bugs have been patched, the Wine project is happy to announce today, January 24, 2017, the general availability of Wine 2.0. Wine 2.0 is the biggest and most complete version of the open-source software project that allows Linux and macOS users to run applications and games designed only for Microsoft Windows operating systems."
Here is some more Tech News from around the web:
- Chrome To Introduce Timer To Throttle Background Pages @ Slashdot
- Penguins force-fed root: Cruel security flaw found in systemd v228 @ The Register
- Furby Rickroll demo: What fresh hell is this? @ The Register
- Hello, This Is Yahoo Mail Security, This Is Not A Scam… @ Techgage
Subject: General Tech | January 21, 2017 - 08:42 PM | Scott Michaud
Tagged: windows 10, microsoft
Microsoft will be ending support for Windows 10 build 10240 on March 26th (via Mary Jo Foley), after a year and eight months since it launched in July 2015. For our home readers, this will not be too much of a concern, as most of us are on the Anniversary Update (or another OS entirely). Also, Microsoft supported it longer than some hardware vendors, such as NVIDIA, who requires a later build for PCs with a Pascal-based GPU. (Update: I haven't been able to find out whether AMD supports 10240 or not, and it's really a small point for home users anyway. The point was to show that users are heavily intended to be on the latest version.)
Rippin' off the band-aid.
Again, these new builds are free from Microsoft, so, from a financial standpoint, there’s little reason to not update if your machine can support it. What it does show, however, is how short of a time we have between a bad decision being implemented and a bad decision being forced upon all Windows PCs. If a change upsets you, or feels like it could be used anti-competitively now or in the future, don’t be shy to raise the concern when it appears. You will only have a year or two before it can no longer be avoided... at most... even if you're a business. In most cases, you'll only have a handful of months.
Subject: General Tech | January 21, 2017 - 06:27 PM | Scott Michaud
Tagged: microsoft, windows 10
Now that the holidays are over, software developers are going back to work. It seems like ones at Microsoft had several big changes stashed away, waiting to release when they would be around to support them in the new year. Over the last two weeks, we received three different builds, each with several significant changes. They seem to be tapering off, though, which would make sense if they’re merging through their backlog from 2016.
One feature that might be lauded by our readers is the ability to temporarily pause updates. This one came in on build 15002, and it gives users an option to delay any update that will cause a restart for up to 35 days. Unfortunately for some, this will be restricted to Windows 10 Pro and above, because Microsoft still does not trust that Windows 10 Home users will not ignore updates then complain about how insecure Windows is when a 9-month-old worm hits them. Instead, from Home users, they are pushing a change to “Active Hours”, allowing it to be extended into an 18-hour window. Sorry if you have a 24-hour render or something!
Moving on, some users will appreciate the lunar calendar being added to the taskbar calendar, alongside the conventional, Gregorian one. You would think that this localization feature should have been implemented years ago, but, with the Creator’s Update, affected users will have a more functional, built-in calendar.
Another interesting feature, which came out in the most recent build, 15014, is the power mode slider attached to the battery icon. Rather than having it buried in the advanced power settings, Microsoft is allowing users to “slide right” when they need things like higher CPU power states. In the current build, the UI isn’t hooked up to the back-end yet, because they’re still discussing (with OEMs) what power settings the slider options should correspond to.
There are also a lot of enhancements for Edge, of course, as all web browsers are still undergoing a rapid release schedule. A lot of it involves tab management, such as stashing tabs for later (like a more transient bookmark) and sharing them to other applications.
The Windows 10 Creators Update (1703) is expected for April.
Subject: General Tech | January 15, 2017 - 07:17 PM | Scott Michaud
Tagged: microsoft, windows 10, pc gaming
A few weeks ago, Windows Insiders noticed GameMode.dll was added to the Windows 10 preview builds. It was speculated by Windows Central, based on their anonymous sources, that it would allow the user to increase performance for games. Now, in an Xbox blog post, Mike Ybarra of Microsoft confirmed the existence of this feature. It will arrive with the Creators Update and, yes, it is intended to “optimize your Windows 10 PC for increased performance in gaming”.
That’s about all of the detail that is mentioned explicitly in the blog post. It does make a passing reference to “Windows Insiders will start seeing some of the visual elements for Game Mode this week, with the feature being fully operational in builds shortly thereafter”. While we don’t need to wait too long to actually find out, this snippet suggests that user involvement will be required. This might be a launcher or something else entirely.
On his Twitter, he also added that Game Mode will work for both Win32 and UWP games. Assuming this isn’t a mistake, and it’s stated quite bluntly albeit on Twitter, it looks likely that Game Mode’s UI won’t be an extension of Windows Store and it will work for any game. It will probably reside elsewhere, like an Xbox App or something, but we don’t really know yet.
The Windows 10 Creators Update arrives this spring. While its version number is 1703, rumors have it set for an April release date.