HN user

elabajaba

451 karma
Posts0
Comments141
View on HN
No posts found.

Straight piped trucks can easily hit over 100dB (I've seen numbers as high as 118dB) which is well above the 85dB hearing damage level, and is at the level where hearing damage occurs in minutes or even seconds of exposure.

Sorry I don't want to get tinnitus just because some asshole wanted to make his truck "sound better".

360hz screens have been available for about 6 years now and you can get one for $200-300 now. ~500hz monitors have been widely available for ~3 years now, and in the last year we've had companies launching monitors with 720hz and soon 1000hz refresh rates (1000hz is needed to avoid persistence blur due to sample and hold display tech https://blurbusters.com/blur-busters-law-amazing-journey-to-...).

Annoyingly, on Firefox this is locked to 60fps on my 120hz display.

There really aren't very many different tip types available for airpods, since they use a special clip attachment method that means you can't use any standard existing tips. I've been looking for aftermarket tips for my pro 3s and there's maybe 5 actually different tips available (crappy foam, decent foam, bad hybrid, basic sticky silicone, basic bad rubber). They're distinctly lacking in good quality tips with different textures (can help with comfort and keeping them in your ears) or different bore sizes (comfort and changes the sound signature). TRI clarion, Tangzu Tang Sancai, Penon Liqueur, JVC Spiral Dot are a few different standard tips that would likely be way more comfortable than the standard airpods tips if you could actually use them.

Shoes are actually a great analogy here, because the companies all use different lasts, so it doesn't matter that eg. Adidas has thousands of different shoes in over a dozen sizes, none of them actually comfortably fit my feet because the heel is always too wide and the forefoot too narrow.

Also, they only come with 5 tip sizes (4+1 on the buds) and use an oval shape which I personally find less comfortable than circular tips+stems.

Apple officially deprecated GL/GLES on both MacOS and iOS 7 years ago, and only ever supported up to GL 4.1 (which came out in 2010), meaning it doesn't support essential "modern" features like compute shaders (DX11 had them in 2009), or bindless textures (supported since 2012 on AMD+Nvidia, and 2015 for Intel iGPUs, massive performance win, needed for GPU driven rendering and ray tracing).

E-CVTs are extremely reliable and are different from CVTs (CVTs use a belt attached to 2 cones, E-CVTs are just a single planetary gear set), but a lot of car guys and even some mechanics don't realize they're completely different.

Part of the rust dependency issue is that the compiler only multithreads at the crate level currently (slowly being improved on nightly, but there's still some bugs before they can roll out the parallel compiler), so most libraries split themselves up into a ton of small crates because otherwise they just take too long to compile.

edit: Also, `cargo-vet` is useful for distributed auditing of crates. There's also `cargo-crev`, but afaik it doesn't have buy in from the megacorps like cargo-vet and last I checked didn't have as many/as consistent reviews.

https://github.com/mozilla/cargo-vet

https://github.com/crev-dev/cargo-crev

R5s has a garbage CPU that won't be able to handle QoS on probably >250mbps.

I'd avoid anything arm based that doesn't have a7x cores (ideally a76/a78 or newer, though I don't think there's any SBC socs using the a710/715/720 yet). A55 cores are old stupidly slow efficiency cores (area efficient, not power efficient).

Hell, modern audio codecs (opus and AAC, but not the ffmpeg opus/AAC encoders) are transparent at ~160-192k. MP3 is a legacy codec these days, and generally needs ~30% more bitrate for similar quality.

Intel GPU drivers have always been terrible. There's so many features that are just broken if you try to actually use them, on top of just generally being extremely slow.

Hell, the B580 is CPU bottlenecked on everything that isn't a 7800x3d or 9800x3d which is insane for a low-midrange GPU.

The amount of memory you can put on a GPU is mainly constrained by the GPU's memory bus width (which is both expensive and power hungry to expand) and the available GDDR chips (generally require 32bits of the bus per chip). We've been using 16Gbit (2GB) chips for awhile, and they're just starting to roll out 24Gbit (3GB) GDDR7 modules, but they're expensive and in limited demand. You also have to account for VRAM being somewhat power hungry (~1.5-2.5w per module under load).

Once you've filled all the slots your only real option is to do a clamshell setup that will double the VRAM capacity by putting chips on the back of the PCB in the same spot as the ones on the front (for timing reasons the traces all have to be the same length). Clamshell designs then need to figure out how to cool those chips on the back (~1.5-2.5w per module depending on speed and if it's GDDR6/6X/7, meaning you could have up to 40w on the back).

Some basic math puts us at 16 modules for a 512 bit bus (only the 5090, have to go back a decade+ to get the last 512bit bus GPU), 12 with 384bit (4090, 7900xtx), or 8 with 256bit (5080, 4080, 7800xt).

A clamshell 5090 with 2GB modules has a max limit of 64GB, or 96GB with (currently expensive and limited) 3GB modules (you'll be able to buy this at some point as the RTX 6000 Blackwell at stupid prices).

HBM can get you higher amounts, but it's extremely expensive to buy (you're competing against H100s, MI300Xs, etc), supply limited (AI hardware companies are buying all of it and want even more), requires a different memory controller (meaning you'll still have to partially redesign the GPU), and requires expensive packaging to assemble it.

To get 128GB of RAM on a GPU you'd need at least a 1024 bit bus. GDDR6x is 16Gbit 32 pins, so you'd need 64 GDDR6x chips, which good luck even trying to fit that around the GPU die since traces need to be the same length, and you want to keep them as short as possible. There's also a good chance you can't run a clamshell setup so you'd have to double the bus width to 2048 because 32 GDDR6x chips would kick off way too much heat to be cooled on the back of a GPU. Such a ridiculous setup would obviously be extremely expensive and would use way too much power.

A more sensible alternative would be going with HBM, except good luck getting any capacity for that since it's all being used for the extremely high margin data center GPUs. HBM is also extremely expensive both in terms of the cost of buying the chips and due to it's advanced packaging requirements.

They're talking about the 16 sampled texture binding limit which is the same as webgl2. If you look at eg. the list of devices that are stuck with that few texture bindings they don't even support basic GL with compute shaders or vulkan, so they can't even run webgpu in the first place.

Intel Arc GPUs are terrible for Nanite rendering, since they lack hardware support for both indirect draws (widely used in GPU driven renderers, Intel emulates it in software which is slow) and 64bit atomics, which are required for nanite.

It looks like they're still actively maintaining a bunch of rust crates, and they're still developing Wim (their blobby Roblox competitor written in rust).

They have pulled back from the rust ecosystem quite a bit though since repi (their former CTO) left shortly after The Finals released. They stopped all their FOSS sponsorships, and there was [this PR](https://github.com/EmbarkStudios/rust-ecosystem/commit/61f0e...) which definitely doesn't inspire confidence.

Other fps game maps don't have licenses that let you use them to stress test your renderer or game engine. Existing freely available scenes are all too small and poorly made to be proper stress tests with modern hardware (eg. Old sponza is way too light, Intel sponza they just spammed the subdivision modifier to make it stupidly high poly, Bistro is small and really weirdly made, etc).

VR needs a more powerful CPU and GPU than a MacBook Pro needs if you're trying to break into the VR gaming market (not saying you need a faster CPU than an M3, but VR is extremely demanding and will use all the CPU and GPU you can throw at it to maintain 90+fps with multiview rendering), especially since Apple keeps pushing Metal and not supporting Vulkan. (Metal tends to have higher CPU overhead vs Vulkan, and means you have to add an additional rendering backend for existing VR games)

A lot of their testing is running custom OpenCL and Vulkan code, both of which are essentially unsupported on macOS (moltenvk exists, but kinda sucks and adds overhead that would make the comparisons invalid anyways).