Windows actually runs a lot of drivers in user-mode, even GPU drivers. largely this is because third-party drivers were responsible for the vast majority of blue screens, but the users would blame Microsoft. which makes sense; Windows crashes so they blame Windows, but I doubt anyone blamed Linux for the kernel panic.
I think windows can be blamed on how badly you can fix that kind of issues. I mean on linux or any bsd admins would build an iso image that would automatically run a script that would take care of optionnally decrypting the system drive, then remove crowdstrike. Or alternatively simply building a live system that take an address via dhcp and start an ssh server. and admins would remotely and automatically run a playbook that mount that iso on the hypervisor, boot it, remotely apply the fix, then boot back the system on the system drive.
Maybe this is just my ignorance about windows and its ecosystem but it seems most admins this morning were clueless on how to fix that automatically and remotely on n machines and would resort to boot in safe mode and remove a file manually on each single server. This is just insane to think that supposed windows sysadmins / cloudops have no idea how to deploy a fix automatically on that platform.
While I agree C++ is very verbose, I would argue that modern C++ reduces the amount of code you need to write. The full code above should be :
foo* x = new foo();
if (x != nullptr) {
...
}
delete x;
and the equivalent modern C++:
auto x = std::make_shared<x>();
...
The post-incident report found a design flaw in the box that transmits the ejection signal from the back seat to the front seat, allowing it to get damaged.
That and one loose screw.
There is no such thing as direct rendering, commands are always buffered by the driver before being sent to the gpu. (and Forward rendering as in the rendering technique ?)
With Vulkan/Dx12 you can record multiple command buffers in parallel. That is not possible in OpenGl/Dx11 (There are 'deferred contexts' that let you do things in parallel but it's really not great).
By 'multiple cores on the GPU', I think you mean the hardware queues ? Usually there are 3 (on PCIe discrete GPUs, that is) a graphics queue to record any commands, a compute queue for compute tasks, and a copy queue for DMA copies across the PCIe bus.
I don't know if you can access them independently on older APIs, but on Vulkan/dx12 you certainly can.
Leaving aside arguments about "what the drivers are", the kernel driver being discussed here generally doesn't have or need that kind of thing. The user-space drivers which talk to the kernel drivers are under the Mesa umbrella as part of Gallium for OpenGL and Direct3D support (e.g. https://github.com/mesa3d/mesa/tree/master/src/gallium/drive...) or as a standalone driver for Vulkan support (https://github.com/mesa3d/mesa/tree/master/src/amd/vulkan). That said, I haven't seen many app-specific hacks in the open source drivers, even in the user-space code.
If anyone wants to learn more about lower-level aspects of GPUs, the Vulkan driver code I linked is one of the best places to start. It directly implements the Vulkan API on one end and talks to the kernel drivers on the other end, so it's relatively easy to follow if you're a systems programmer with an API-level understanding of graphics. Just pick a Vulkan function of your choice and start tracing through the code, e.g. vkCmdDraw: https://github.com/mesa3d/mesa/blob/master/src/amd/vulkan/ra.... The Vulkan driver calls into some of the low-level radeonsi code I linked from the Gallium tree but it isn't a Gallium-based driver, so you don't have to deal with those extra layers of abstraction.
Eurogamer did write a review about playing modern games on a (very good) CRT monitor [1]. It's better than any LCD and even OLED monitors according to them:
A point not mentioned there but that is a major reason for me to use CRT: Contrast.
The contrast in most flat screens I tried is just terrible, a classic example I use is trying to play Superhot and then watch Game of Thrones right after... Superhot was everything white, so I fiddled with the controls until it was playable.
Then Game of Thrones everything was black. So I fixed it... then went back to Superhot and everything was white again.
With CRT after I adjusted it, I don't need to adjust anymore.
There seems to be some confusion between paternity leave and parental leave. Figure 1 (page 6) in document [1] gives a good comparison between among EU countries., where paternity leave is represented by a black bar.
