6,400 karma · joined March 2, 2015
http://const.me/
If you have two Bloom filters which use same set of possible keys and same filter setup, you can compute intersection of their represented sets with a bitwise AND operation over the bitsets in these filters.
If you store bitsets aligned and padded by SIMD vector size (for example, an array of __m128i in C++ as opposed to the array of uint64 values in the golang example), computing such intersection is very efficient on modern computers.
I once used that technique to filter 3D objects from a large set using the intersection of 3 range queries, one per coordinate. Compute two Bloom filters filled with the objects returned by X and Y queries, intersect the filters, then iterate over the objects returned by the remaining Z query testing against the intersected Bloom filter. Due to probabilistic nature of the Bloom filter you still need to test for X and Y queries for the objects tested positive by the filter, however with proper setup the filter should reject vast majority of them.
Agree with the rest of your comment. I also think the main reason for high traffic deaths in America is road design.
The 8GB version struggles in 1440p, and only delivers playable framerates in 1080p with some combination of in-game settings. Here’s the original article: https://www.techspot.com/review/2980-nvidia-geforce-rtx-5060...
I agree with the author: that level of performance for $400 is inadequate. BTW, I remember 10 years ago I bought nVidia 960 for about $200. For the next couple years, the performance stayed pretty good even for newly released games.
nVidia says the launch prices for them are $400 and $500, respectively.
> seems like a good, rather than a bad, thing to me
The bad thing is the most affordable current generation card capable of playing modern videogames in decent quality now costs $500. That’s too expensive for most consumers I’m afraid.
Steam hardware survey says 7 out of 10 most popular cards are nVidia [234]060 which were sold for around $300. Despite most of them also have 8GB VRAM, when consumers bought these cards a few years ago, 8 GB was good enough for videogames released at that time.
Most consumers buy GPUs to play videogames. Recently, nVidia launched two flavors of 5060 Ti consumer GPU with 8GB and 16GB memory, the cards are otherwise identical.
Apparently, the 8GB version is only good for 1080p resolution with no DLSS. In many games, the difference between these versions is very substantial. The article says 8GB version is deprecated right at launch: https://videocardz.com/newz/nvidia-geforce-rtx-5060-ti-with-...
Another reason to prefer fixed width, compilers may pass vectors to functions in SIMD registers. When register size is unknown at compile time, they have to pass data in memory. For complicated SIMD algorithms the performance overhead gonna be huge.
They don’t always do that well when you need a reduction in that loop, e.g. you are searching for something in memory, or computing dot product of long vectors.
Reductions in the loop form a continuous data dependency chain between loop iteration, which prevents processors from being able to submit instructions for multiple iterations of the loop. Fixable with careful manual unrolling.
When I need something like that, in my destructor I usually ask worker thread to shut down voluntarily (using a special posted message, manual reset event, or an atomic flag), then wait for the worker thread to quit within a reasonable timeout. If it didn’t quit within the timeout, I log a warning message if I can.
That would be me, I’m afraid. I know little about Taylor series, but I’m pretty sure it’s less than ideal for the use case.
Here’s a better way to implement faster trigonometry functions in C++ https://github.com/Const-me/AvxMath/blob/master/AvxMath/AvxM... That particular source file implements that for 4-wide FP64 AVX vectors.
A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all.
The tricky part is estimating consequences of these technical decisions. If you’re more or less confident in your estimations, and you believe the technical decision being made has severe consequences (not just to the product, in the long run development process is equally important), only then is the time to commit.
It seems their revenue in 2024 exceeded $3B.
> they will sell your data to make ends meet
I’m not sure they can do that without breaching the contract. My employer pays for ChatGPT enterprise I use.
Another thing, OpenAI has very small amount of my data because they only have the stuff I entered to their web service. Google on the other hand tracks people across half of the internets, because half of the web pages contain ads served by google. Too bad antimonopoly regulators were asleep on their job when google acquired DoubleClick, AdMob, and the rest of them.
Indeed, but sharing code between CPU and shaders is not the only way to solve the problem. I wrote a simple design-time tool which loads compiled shaders with shader reflection API, and generates a source file with C++ header (or for other projects C# structures) with these constant buffers. At least with D3D11, compiled shaders have sufficient type and memory layout info to generate these structures, matching memory layout by generating padding fields when necessary.
> not sure how about d3d land
Pretty sure D3D11 doesn’t have an equivalent of that Vulkan extension. Not sure about D3D12 though, only used the 12 briefly.
> I've been using custom vertex fetch with buffer device address in my projects
In my projects, I sometimes use a lot of non-trivial input layout features. Sometimes I need multiple vertex buffers, e.g. to generate normals on GPU with a compute shader. Sometimes I need instancing. Often I need FP16 or SNORM/UNORM vertex attributes, like RG16_UNORM for octahedron-encoded normals.
Yeah, that will work fine for byte address buffers, to lesser extent constant buffers (they don’t convert data types but the access sematic and alignment are a bit tricky), but not much else. Vertex buffers, textures, and texel buffers / typed buffers in D3D are all widely used in real-time graphics.
> which you could write yourself in a shader and get same perf
Pretty sure it’s hardware. Emulating anisotropic texture sampler with HLSL codes would need hundreds of instructions, prohibitively expensive. Even simpler trilinear sampling is surprisingly tricky to emulate due to these screen-space partial derivatives on input.
> I have not seen an apples to apples benchmark about these format conversions.
Here’s a benchmark for vertex buffers https://wickedengine.net/2017/06/should-we-get-rid-of-vertex... As you see, on AMD GCN4 he indeed measured pretty much the same perf, however on nVidia Maxwell vertex buffers were 2-4 times faster.
Google’s main source of income, by far, is selling ads. Not just any ads but highly targeted ones, which means global digital surveillance is an essential part of their business model.
How they did it? Hard to do because GPU hardware can convert data types on the fly, e.g. you can store bytes in VRAM, and convert them to 32-bit floats in [ 0 .. +1 ] in the shader. GPUs can do that for both inputs (loaded texture texels, loaded buffer elements, vertex attributes) and outputs (rendered pixels, stored UAV elements).
The memory is slower but not by much, 256 GB/s is much faster than system memory found in most consumer-targeted PCs. The devices have way more memory, up to 128 GB. A system with a Strix Halo APU is a general-purpose computer; these special accelerator cards can only be used for one thing.
Similarly, a man purchasing physical stuff is giving money in exchange for the goods as opposed to advertisement services. Classic contract of sale of physical goods, nothing even slightly ambiguous.
It’s the same with ordering a sign. “Exchanging money in order to promote a product” doesn’t happen because manufacturing the sign is not a promotion. To promote something using a sign, you would need to post the sign in a publicly visible place. Manufacturing a sign and giving it to your client in private doesn’t promote the product shown on the sign.
The first case is legal because waiter gets paid by the restaurant to serve meals, not to promote the specific brand of rose wine. Only illegal if the waiter has another, secret contract with the wine manufacturer to “recommend” specific wine.
The other two cases are legal because the money exchanged in order to receive goods. The fact the goods are then used to promote something is irrelevant.
I believe that approach, i.e. the compute shaders, is the correct thing to do because modern videogames use them a lot, the runtime support is stable and performant now. No need for special HPC-only drivers or runtime components.
As you see, the technology deprecated in Visual Studio 2022. I don’t know why but I would guess people just didn’t care. Maybe because it only run on Windows.
> I have flatpaks from several years ago that no longer work (Krita) due to some GL issues.
That’s an example of Linux GPU APIs being unstable in practice, and container images not helping to fix that.
Unless you are running Windows, in which case it doesn’t. Intel simply has not made a driver.
An example from another comment: https://news.ycombinator.com/item?id=43519949
Then there’re quality issues. If you search internets for “Windows Vulkan issue” you’ll find many end users with crashing games, game developers with crashing game engines https://github.com/godotengine/godot/issues/100807 recommendations to update drivers or disable some Vulkan layers in registry, etc.
On Windows, Vulkan is simply not as reliable as D3D. The reasons include market share, D3D being a requirement to render the desktop, D3D runtime being a part of the OS supported by Microsoft (Vulkan relies solely on GPU vendors), and D3D being older (first version of VK spec released in 2016, D3D11 is from 2009).
Another thing, on Linux, the situation with Vulkan support is less than ideal for mobile and embedded systems. Some embedded ARM SoCs only support GLES 3.1 (which BTW is not too far from D3D 11.0 feature-wise) but not Vulkan.
Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS.
I view all that modern stuff like Direct3D, Direct2D, DirectWrite, Media Foundation as simply newer parts of the WinAPI. Pretty sure Microsoft will continue to support them for long time. For example, they can’t even deprecate the 23 years old DirectX 9 because still widely used, e.g. current version of Microsoft’s own WPF GUI framework relies on Direct3D 9 for graphics.
That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific.
In contrast, it’s impossible to run modern Windows without working Direct3D 11.0 because dwm.exe desktop compositor requires it. If a software consumes Direct3D 11.0 and doesn’t require any optional features (for example, FP64 math support in shaders is an optional feature, but sticking to the required set of features is not very limiting in practice unless you need to support very old GPUs which don’t implement feature level 11.0), will run on any modern Windows. Surprisingly, it will also run on Linux systems which support Wine: without Vulkan-capable GPU will be slow but should still work due to Lavapipe, which is a Linux equivalent of microsoft’s WARP they use on Windows computers without hardware 3D GPU.
Indeed. In addition to that, I think that library is less than ideal for chips with an integrated 3D graphics hardware, like ARM Mali. Except applications with very low-resolution screens way below 1 megapixel, in which case CPU software rendering should be fine.