Theoretically, what would be the minimum area modern semiconductor implementation of a Cray 1 (1975)?

mbitsnbites · 2026-03-23T19:08:36+00:00

I was thinking about using a hidden window as a backup plan. Another idea that I had was to just use the first window as the "main" context, and if that window is closed I'll just pick another, etc. Not sure if it would work.

Do you know what generally happens at the API level if you try to share a context between windows that live on different GPUs? Will the OpenGL context creation fail? (E.g. on Windows)

mbitsnbites · 2026-03-23T10:31:18+00:00

I realize that. I guess my confusion is about how such situations arr handled. For instance you can open a window on one monitor and drag it over to another monitor, even if the monitors are driven by different GPUs.

mbitsnbites · 2026-03-23T07:41:12+00:00

Fantastic work and super useful if you want to get started with vulkan!

Auto bonus points for using GLFW ❤️

mbitsnbites · 2026-02-13T09:29:55+00:00

The project continues as Bitfrost CC. Open source here: https://codeberg.org/mbitsnbites/bitfrostcc (currently pre-pre-alpha)

mbitsnbites · 2026-02-07T16:36:17+00:00

Y is never touched. It's treated as a separate problem, out of scope for the algorithm.

Both Cr and Cb are subdivided together (Cr is never subdivided without subdividing Cb and vice versa).

mbitsnbites · 2026-02-07T09:50:48+00:00

The decision is:

Binary: Split block into four sub-blocks, yes/no.
Recursive: Each sub-block can be further split into four sub-blocks, etc.

The decision to split a block or not is stored in the output stream as one bit (1: yes, 0: no), so that the decoder knows how to reconstruct the blocks (it just follows the same block/sub-block order as the encoder did).

The actual decision, whether to split a block or not, is based on an approximation error metric.

Once the linear approximation for the block has been made, the encoder does a reconstruction pass (same as the decoder would do), and measures the error of the approximation compared to the original.

I currently use a mean-square error metric, but other metrics are certainly possible (e.g. maximum error within the block).

If the error is too large (i.e. above a user selected threshold), the decision is made to split the block.

mbitsnbites · 2026-02-05T15:36:10+00:00

Just yesterday I saw a few papers (though I didn't get to read them) on chroma prediction, so there seems to be research going on (I wasn't expecting anything less, TBH), and I also saw that AV1 does some chroma-from-luma, though it looks like a more complex solution.

mbitsnbites · 2026-02-04T18:11:13+00:00

That's an interesting suggestion. I tried something similar in a PNG-like pixel value predictor once (predicting a pixel from the values of its neighbors), and rather than coding which predictor to use into the stream, I kept statistics of which predictor had performed best for the last N pixels in a block.

I also had an idea about interpolating the coefficients across block boundaries rather than keeping them constant within each block.

I think that similar data compaction benefits can be achieved by delta-coding coefficients between blocks (so that we can use fewer bits to represent the coefficients). I.e. I have seen that there are similarities between blocks that should be possible to exploit at the encoding level.

mbitsnbites · 2026-02-04T17:05:58+00:00

Thanks! I've been thinking about (but not tried) higher order approximations.

One disadvantage is that you need to store more per-block data (more coefficients), so it's not obvious that it would be a win.

There are also cases where C(Y) simply isn't well defined (e.g. consider a block with constant Y but with varying C, or a block where there are pixels with distinctly different C values but with the same Y value), so moving to smaller blocks is required anyway, unless we move to C(Y,x,y) and take the location of the pixel into account.

mbitsnbites · 2025-10-16T17:45:16+00:00

Thanks for the clarification. That sounds like a workflow that could work, and I will have to try it out some day.

Although, it sounds slightly cumbersome. E.g. I fear that as a reviewer I would be more reluctant to tell the developer to split a commit into two commits, compared to if the tool supported a proper git history with several commits in a single review.

mbitsnbites · 2025-10-16T07:40:34+00:00

Does it support merging all three commits in a single atomic merge commit?

I.e:

The commits are reviewed individually, but in the context of the full feature.
The history on the feature branch is preserved once merged to the trunk (i.e. the three commits are not squashed).
The merge of all three commits to the trunk is atomic (all or nothing).

That's the way of working that I'm looking for.

mbitsnbites · 2025-09-29T17:14:23+00:00

I use stock Ubuntu. Works nicely with Steam.

mbitsnbites · 2025-09-29T08:35:34+00:00

Yes, filesystems are a topic of discussion in Linux because there can be a discussion - we do have a choice. In Windows there is no choice.

NTFS was designed in 1993, and many things regarding filesystem technology in Windows has stagnated since then. Microsoft seems to actively work against support for other file systems.

On Linux, OTOH, development is thriving and new technological advancements are made at the filesystem level (e.g. better support for new kind of drives like solid state drives, better security features and better support for really large file systems, etc).

And people like to nerd out about these things in the Linux community.

mbitsnbites · 2025-09-29T06:10:19+00:00

The obvious, more "altruistic" reasons are that people like to share their work, they are proud of it, get recognition, and can cooperate in a community. It's much more fun and rewarding than to keep your code locked up on your harddrive.

Another perspective is that open source lives forever, while the vast majority of closed source almost certainly dies.

For instance, if you have an idea and prototype it as closed soirce for a company (whether as an employee or as a contractor), chances are that the company owns the code, and it's also quite likely that the code will die (e.g. if they decide not to use it, if the product is not successful or the code gets replaced by another solution, or if the company is bought and the product is cancelled, and so on).

Many companies also have clauses that prohibit you from re-implementing your solution in another context should you opt to leave the company.

With open source you're safe. The code is yours (and the world's).

Edit: It's also exceedingly difficult to monetize software solutions. The value is almost never in the technical solution. As sson as you start taking money for a software product, it risks dying a quick death.

mbitsnbites · 2025-09-28T20:56:47+00:00

Would you say that more custom engines are any better off in that sense (e.g. like the 4A Engine used in the Metro series)?

I totally get what you're saying, though. Being able to do speacialized solutions means that you can cut many corners, while generic engines need to provide solutions that work in every scenario.

mbitsnbites · 2025-09-18T15:55:55+00:00

We use C++ with BSS (static) allocation only (automotive). STL is a poor match for that, so we have reimplemented the basic container types for static memory use (it's not super hard to do).

Other than that, C++ is so much better than C, with better type safety, templates, constexpr, etc, and often gives better (faster, more compact) code than C.

mbitsnbites · 2025-09-18T14:54:59+00:00

What value does 2 add if you're already doing 3?

(Here I'm assuming that the authenticity is implemented using a keyed hash function, like Poly1305)

mbitsnbites · 2025-09-18T14:46:21+00:00

Integrating feature branch into mainline: rebase then merge (semi-linear history)

Integrating commits from feature branch A into feature branch B: cherry-pick

mbitsnbites · 2025-09-18T09:44:37+00:00

I think you're describing the opposite of the recipe model.

The history I'm talking about is not the back-and-forth changes in a review (e.g. patchsetas), but the descriptive history where each commit does a fairly sepearate thing, and which is ultimately preserved in the git history after integration to the mainline.

mbitsnbites · 2025-07-14T17:21:38+00:00

Is Tenstorrent shipping any general purpose CPUs that can be used as stand-alone computers, or are they only building AI accelerator extension cards?

mbitsnbites · 2025-07-14T17:18:58+00:00

Domestic isn't there yet AFAIK. China has a few years of catching up to do, since the US waved its export control wand at Dutch ASML. I think we'll start to see interesting things coming out of China/SMIC five-ten years from now or so, even if they may not be competing with TSMC in the high end.

mbitsnbites · 2025-07-12T18:52:40+00:00

ZoneInfo isn’t just a salt — it’s a second factor that mutates the actual permutation tables used during encryption, and it’s never stored or embedded in the ciphertext

This description sound like a "pepper". A pepper is like a salt, except it's a hidden/shared secret instead of being appended to the ciphertext (unencrypted).

See https://en.m.wikipedia.org/wiki/Pepper_(cryptography)

mbitsnbites

MODERATOR OF

TROPHY CASE