I think nuclear winter is a fake invented by cold war propaganda. If tomorrow we detonate all nukes available, the amount of dust in the atmosphere won’t even approach a large volcanic eruption.
Volcanic eruptions occasionally inject literally cubic kilometres of stuff high into the atmosphere. That’s insufficient to cause a global winter, only a year without a summer: https://en.wikipedia.org/wiki/Year_Without_a_Summer
For the last few months, I’ve been working on a vendor-agnostic inference library. Have 3 backends so far: legacy D3D11 for compatibility, D3D12, and Vulkan 1.3. I have reasons to believe nVidia deliberately crippling Vulkan API for their consumer GPUs. Couple examples to be specific.
nVidia driver sets quite low number for VkPhysicalDeviceLimits::maxTexelBufferElements. I don’t think that’s a hardware limit because I have D3D12 backend doing the same thing on the same hardware.
Vulkan performance is not great on nVidia. On all AMD cards I am testing, Vulkan 1.3 is the fastest backend. On nVidia however, D3D12 is faster despite tensor cores (WMMA / wave matrix multiply accumulate / cooperative matrices) are only available through Vulkan, D3D12 is using shader cores exclusively.
I would add than SSE1 and SSE2 are now required parts of AMD64 instruction set. All 64-bit PC processors are required to support them both. For that reason, modern compilers are ignoring x87 FPU when building 64-bit binaries. Instead, they compile all float and double arithmetic into SSE1 and SSE2 instructions, respectively.
Take a look at the micro-architecture levels. x86-64-v1 contains all the instructions that the original AMD64 and compatible Intel CPUs supported. v2 is all the SSE levels, v3 is AVX and AVX2, v4 is AVX-512.
"Additional XMM (SSE) registers: Similarly, the number of 128-bit XMM registers (used for Streaming SIMD instructions) is also increased from 8 to 16...
"The original AMD64 architecture adopted Intel's SSE and SSE2 as core instructions."
x86-64 mandates SSE2 as a minimum requirement because it uses the SSE registers in the ABI for implementing float (which requires SSE) and double (which requires SSE2) arithmetic. (The x87 unit, which is what the 32-bit x86 ABI uses, can only do extended-precision arithmetic, which causes a whole heap of problems). Because it's so thoroughly integrated in the ABI, v1 has to have a min-SSE2 requirement.
Subsequently, there were additional instructions added in SSE3, SSSE3, SSE4.1 and SSE4.2, which are all incorporated into the v2 ISA level (along with a few other instructions). Then all of these instructions were given 256-bit variants in AVX, and AVX2 adds some more vector instructions; these are incorporated into the v3 ISA level. And then along comes AVX-512 and naming just becomes a podge at that point...
Not sure what your question is. I dont see any contradiction with the parent comment. SSE went to version 4.2 (it gets complicated in the numbering and even naming). Only 1 and 2 were included in the base 64-bit ISA.
Compilers like GCC and Clang treat C's "long double" type by default as 80-bit wide and result in x87 generated code. This can be overridden to use either 64-bit or 128-bit floating point values.
Which is not to say that they are necessarily auto-vectorizing. You know wassup when you see vaddsd instead of vaddpd. And ideally you'd use AVX-512 to saturate a modern cache line if you can afford to drop support for the older devices.
Another large part of using SSE for floating point arithmetic today is that while the floating point stack was very good for code-density (I still use older compilers for size-optimized C code for demoscene intros), it was also quite painful in being stateful.
This is a large part of why "floating point to integer conversion is slow" cargo culting came from (probably disappeared today but was often seen back in the day).
Many x86 standard libraries emitted code that first set the floating point rounding mode before the storing conversion, you could use a /QIfist compiler option on MSVC to omit that but if you were unlucky to call some code that fiddled with the rounding mode your code would become unreliable (iirc unfortunally that did include some old D3D or OGL version).
With SSE iirc it's separate instructions for different rounding instead of a FPU mode.
They were always required. IIRC early AMD64 CPUs did not support x87 instructions in long mode at all (causing #UD), and that support was Intel's extension in first EM64T CPUs.
LAHF and SAHF are an interesting rabbit hole themselves.
If you ever dug into x86 assembler programming... at first they make no sense at all. They only save/restore a tiny part of the available flag registers. The mnemonics themselves make little sense - load/store are not really used in any other base x86 mnemonics (unlike e.g. 6502 mnemonics, which use LD?/ST? instead of MOV like x86).
It only clicked when I read an Intel document about porting assembler code from the 8080 to the 8086.
LAHF/SAHF are basically convenience instructions to make porting easier. Many 8080 instructions did not alter the flags, unlike their 8086 counterparts. Substituting an `INX` instruction with `LAHF; INC; SAHF` made it possible to mechanically translate assembler source code.
And yeah, 8080 mnemonics had LDA and STA like the 6502...
10 MB is not too bad for a GUI app. If the app is full screen, display is FullHD and has 8 bit depth, that's almost 8 MB memory for the back buffer alone. Enable HDR and pixels become 8 bytes RGBA16_Float instead of 4 bytes BGRA8_Unorm, twice as much memory.
True, but many modern computers are using unified memory. On such systems all memory is almost equal, despite often reported differently.
For example, on my 5 years old laptop with integrated AMD GPU, windows 10 calculator in default state uses 33 MB system RAM, 9.6 MB dedicated VRAM. Maximized to FullHD screen, same app uses 36 MB system RAM, 13 MB dedicated VRAM. Maybe the OS counts VRAM as active private working set, maybe the app uses more than 1 buffer.
Regardless of the reason, it’s IMO unrealistic to expect a modern GUI app to consume less memory than required for the frame buffer for its window.
Before Windows Vista, Windows apps normally didn't have framebuffers. There was one framebuffer for the whole screen, and apps drew into it. That's why dragging another window over a non-responsive window left a "slime trail" - the non-responsive window wasn't redrawing parts of itself when the window covering them moved away.
Before Vista, we did not have window previews in task bar and alt+tab. We didn’t have a good multimedia framework based on the hardware codecs: media foundation arriving with Vista wasn’t a coincidence. It was hard to capture and encode desktop for screen recording and presentations: despite MS only added desktop duplication API in Win8, technically Vista and Win7 graphics stacks could already do that, MS just neglected. Also, these aero translucency visuals in Vista and Win7 were nice, until Win8 ruined everything.
All that stuff would be hard to impossible with the older GDI architecture and no desktop compositor process.
Not really true. Even machines with integrated graphics in Windows aren't truly using a fully shared memory pool. Usually the hardware reserves a chunk of the system memory for the iGPU.
“aren't truly using a fully shared memory pool” I think with AMD iGPUs I have here (GCN 5.1 and RDNA3 generations) it’s actually unified, at least on Windows 10. The difference between the reserved portion and the rest of the memory is cosmetic.
From Vulkan API POV, the reserved portion has device local and multi instance heap flags, the main heap doesn’t. However, the memory type is identical across all heaps, all of them have device local, host visible and host coherent property flags. And I can confirm VMA library from Vulkan SDK successfully allocates way more device visible memory than the size of that reserved portion.
One thing shared between old software rendered desktops and modern videogames is that they shunned these intermediate 'composited' screens. On the desktop, there used to be the screen, and basically windows used to draw on top of each other, there was no intermediate buffer for the whole window to draw itself to, which would then be smushed together with all others.
Video games are the same (mostly) - everything is rendered in screen space for performance reasons, it's very, very rare, that you would render something into a temporary buffer then composite it on top of the rest of the scene - you would need exceptional reasons for that.
Maybe it's time to get back to the olden days of display servers - where applications would push a list of render commands to the 'display server', which would consist of rendering primitives, which would then take these commands and construct the whole UI on the screen, without the intermediate steps of each app drawing into its own little buffer.
You could always fall back to drawing your own applciations, then asking the display server to composite that, but that would pretty much be the exception, not the norm.
There’s a reason why all modern desktop environments are designed the same way: power efficiency when multitasking.
Imagine you have 3 windows visible at the same time: a videogame rendering at the refresh rate of the display 144 Hz, a video player rendering frames at 30 Hz, and a text editor rendering blinking cursor at 2 Hz. Because the videogame wants to deliver frames at 144 Hz, the desktop compositor has to deliver the entire desktop at 144 Hz. Asking the video player and especially the text editor to also deliver frames at that frequency would be wasteful. Irrelevant for desktops with fast discrete GPUs, but directly translates to battery drain on laptops.
I don't think this is any better for power efficiency? You're taking the modern system as an axiom, which it isn't. The old system didn't "deliver frames at" any specific rate. The graphics chipset sent to the monitor whatever was in the framebuffer at a specific rate, and windows updated whenever they wanted to. The text editor didn't "deliver frames at 144Hz" or any other Hz - it updated some of the pixels in the framebuffer when you pressed a key.
It cost nothing to not change the pixels when you didn't press a key, no matter whether you weren't pressing keys at 60Hz or you weren't pressing them at 144Hz.
Most games haven't rendered directly into the "screen buffer" for 15-20 years.
Vast majority of titles use deferred rendering, and lighting is done off screen too. Usually the only thing done to the "screen buffer" is a final post-process pass or a copy.
Deferred renderers work differently from compositors. They still build up the entire displayed frame in screen space, except they dont write into a color buffer like directly, but produce a bunch or intermediate buffers, called G-buffers. Then they have a postprocess pass when they resolve these buffers into the final image.
This is called 'compositing' but its similar in name only. It's a fairly efficient process where each color pixel is produced by reading these buffer targets and producing a final color in a shader.
This is entirely different from what composited apps do, where they build up the app's background into a texture, and push that onto the screen, with potentially multiple screen's worth of windows living in memory. This would be equivalent in video game terms to rendering every character and object in the level as 'stickers' and then making the final image of these cutouts, which would consume tons of RAM uselessly, and would force us to render crazy amounts of detail that would never get shown.
It's one possible rendering pipeline. Is it really most games?
Regardless, video games normally update the entire screen (or window) every frame, because the screen is so dynamic. This is unlike Microsoft Excel which has a mostly static screen. Building Excel as if it's a video game is going to waste resources.
I agree. In the past, I have successfully used Debian and Alpine for embedded. Never needed to compile OS kernels or standard DLLs, other people already did and published in these package repositories.
As a part of the user-mode half of the GPU driver, GPU vendors ship media foundation transform DLLs to use HEVC hardware codecs. Don’t AMD, Intel and nVidia already pay patent royalties? I expect them to include into price of the GPUs with hardware support i.e. all of them made in the last decade.
Yes, albeit 100ppm is bad/cheap crystals. 50-30ppm is normal.
The difference with a quartz watch is that it's factory calibrated with the load capacitance on the crystal, and that it's a 32768Hz tuning fork. For a variety of reasons, generating higher frequency clocks off 32768Hz is... "annoying" (huge PLL ratio, very slow feedback loop step), and typical crystals in the 10-100MHz range are just less precise and thermally stable. (Not sure why, I'm not an oscillator manufacturer...)
(NB: you can of course correct for initial deviation in software. The actual problem is stability over temperature.)
> benefits from being kept at constant-ish body temperature
Some people take off their watches every day before going to sleep.
These high-end quartz oscillators are probably too expensive to use in commodity computers. Still, the cost shouldn’t look too bad when compared to a price or an airplane, marine vessel, or most military equipment.
We're in agreement; 1ppm is 31.5s/yr so this lines up with OCXO performance / keeping the crystal at constant temperature. It's still 1km zone of spoofability per hour without resync.
I'm unaware of any technology between OCXOs and Rb standards. The latter have gotten smaller but not tiny and also need quite a bit of ongoing maintenance and calibration.
> On which image does the gradation appear more even? It’s the second one!
Can’t reproduce. Tested on two monitors on my desk, designer-targeted Benq and cheap laptop. On the Benq, darkest 3 segments are indistinguishable, the 4-th one barely distinguishable. On the laptop, darkest 4 segments are indistinguishable, the 5-th barely distinguishable. However, on the “emitted light intensity” all bars are clearly visible.
> Image resizing
“Unsurprisingly, C gives the correct result” On my computers B very similar to A, just a tiny bit darker. While the “correct” C result is a lot lighter than A.
Also from the same section:
> B the result of resizing the pattern by 50% directly in sRGB-space (using bicubic interpolation)
Bicubic interpolation is only applicable when enraging images; downsampling is very different problem from interpolation.
“Is it because of government regulations, do we need to deregulate?”
Insufficient law enforcement. The same memory manufacturers already broke antimonopoly laws in the past, pleaded guilty. Apparently the fines were too small for these companies to care, and the people responsible were promoted instead of being punished. More information: https://en.wikipedia.org/wiki/DRAM_price_fixing_scandal
I totally get why they wanted a custom userland, built it myself for embedded devices. But IME Linux kernel is not terribly bad these days.
reply