This article contains some pretty major errors, which is kind of surprising to see!
>The transformation used to represent the physically linear intensity data either generated synthetically via an algorithm or captured by a linear device (such as a CMOS of a digital camera or a scanner) with the discrete values of the perceptually linear scale is called gamma encoding.
This isn't super correct, and it underscores the biggest issue in this article:
sRGB (and its gamma encoding function) has absolutely nothing to do with perceptual linearity. sRGB is not perceptually linear! The original gamma encoding as far as I'm aware was made to compensate for the nonlinear transfer function of CRTs back in ye olde days. Its true that human vision is nonlinear, but sRGB is not a particularly good match to the perceptual linearity of human vision. Its a really common error to make, and leads to people wondering why we can't use sRGB to blend in if the reason why it was invented is because its perceptually linear
The article goes to compound on this mistake, which is why this is such a problematic misconception:
> Interestingly, Photoshop antialiases text using γ=1.42 by default, and this indeed seems to yield the best looking results (middle image). The reason for this is that most fonts have been designed for gamma-incorrect font rasterizers, hence if you use linear space (correctly), then the fonts will look thinner than they should.
This is where the mistakes start to add up
Consider what you're trying to achieve during antialiasing: when rasterising a line, lets say we discover that a pixel is only 40% covered and want to darken it. This means that we want our pixel's brightness to decrease by 40% to a human being. We don't want to emit 40% less light, because that's not what antialiasing is trying to achieve!
Both sRGB and linear colour are the wrong colour spaces to use. You want to blend in a perceptually linear colourspace, and photoshop's 1.42 gamma exponent probably maps better to human vision than 2.2 or 1.0 while being cheaper than a LUV conversion
>The standard gamma (γ) value to use in computer display systems is 2.2. The main reason for this is because a gamma of 2.2 approximately matches the power law sensitivity of human vision
The gamma transfer functions are also wrong. Its worth getting hung up on because it actually causes nontrivial errors, especially in the age of hardware accelerated sRGB conversions where doing it correctly is free
When antialiasing, I think you do want to model light: a fully black object occluding 40% of a pixel should cause it to emit 40% less light. Linear intensity representations of colour should therefore be used.
When doing a smooth fade-to-black in video, you may want to gradually decrease the amount of emitted light from the whole frame in a way that is smooth to a human. Here I think you should consider how a perceptual space can help.
I've been programming in OpenCL for 10+ years. This article is clearly AI generated, and its also completely wrong
OpenCL did not fragment into a mess of vendor specific extensions. I don't know where that even comes from, the extensions in the 1.1/1.2 days were very minimal. The story goes like this:
1. OpenCL 1.2 turned up. This was the first really viable version of OpenCL, although 1.1 was usable. It started to gain a fair bit of traction
2. As OpenCL increasingly started to eat at Nvidia's cuda dominance, Nvidia deliberately killed OpenCL support by neglecting it. There literally did 0 technical development on it for years, with long running critical bugs remaining unfixed
3. At some point, OpenCL started to gain prominence in machine vision stuff in the embedded world, especially for cars and that space. Nvidia's poor OpenCL support became a liability, and so they heavily invested in OpenCL, fixed all the old bugs, and implemented OpenCL 3.0 support
4. Apple dropped OpenCL support because their anti competitive market strategy is vendor lock in, so a cross platform cross vendor API is bad for them. There's some kind of long running legal clusterfuck going on between Apple, and Khronos, the details of which are not public
5. AMD's OpenCL support was absolutely great. A+_best in class, would recommend. It had a fair bit of buggyness/jankyness, but it was an order of magnitude better than Nvidia's support back when Nvidia was deliberately hamstringing it. Then they started developing ROCm
6. Around this time, Vulkan was standardised. Khronos had been considering merging OpenCL into vulkan to force vendors to support it properly, but this was killed. Instead, we got the absolutely insane OpenCL-specific SPIRV format that nobody has ever used for anything
7. With the advent of ROCm, AMD abandoned OpenCL. They swapped over their good OpenCL compiler, to a new compiler that is much shitter and still has way worse performance. OpenCL is now badly implemented on top of ROCm, but some of it is so buggy its clear that nobody has ever used it. They refuse to implement 3.0 support, even though Nvidia supports it
8. The tables have turned: AMDs GPU compute support sucks donkeyballs, and Nvidia is lightyears ahead of them
OpenCL is not a story of fragmentation. Its a story of how vendors deliberately independently set out to kill it, along with AMD's incompetence, and Khronos making several boneheaded decisions during its standardisation that lead to it being cut off at the knees
Despite this, OpenCL 1.2 is still by far the best cross platform cross vendor GPU Compute API, because it is the only one that exists. Vulkan still doesn't support everything you need. Its a nightmare all around
This is a fantastic overview. I learned a lot, thanks!
As someone whose only experience with GPU programming (except very high-level stuff via Torch) has been OpenCL, I gotta say I found it really pleasant! I've always wondered why it didn't take off, and hate the current situation.
I looked with hope at Vulkan, but am saddened by what you write about it. Could you elaborate on what the state of Vulkan Compute is, and where it might go from here?
From what I can see, your comment does not disapprove the main points of the article... Which are that OpenCL development moved very slowly (design by committee always do) and that vendors did not contribute with all their cards at the table.
While you may have adopted OpenCL for a long time, Chris Lattner created it (with his team, of course), I wouldn't dismiss his account of the early history offhand.
Thanks so much for explaining this. I was just about to comment "Isn't Vulkan the main OpenCL and CUDA alternative these days?" could you share a bit more on what Vulkan is missing relative to the other two?
AMD's entire software development strategy is insane. OpenCL was doing reasonably well, and then AMD have just fully dropped support for some reason. For the - albeit not huge - but actual cross platform API that people were using to develop for their GPUs. For a while, a few cross platform tools had OpenCL backends, but nobody has been able to get AMD to fix any of the damn bugs. In my testing, bug latency for even the most trivial but important bugfixes is often 4+ years, which is utterly mad. Some parts of their compute stack is so broken its clear that nobody has ever used it. There are exploitable privilege escalation vulnerabilities caused by threaded race conditions that are wontfix
They could support OpenCL 3.0. Nvidia do. AMD just chooses not to, even though they're the ones that desperately needs to support it most
Instead, we got ROCm which has been a disaster from start to end. It barely supports windows or consumer GPUs, for some reason. Its a buggy mess, for some reason. HIP/ROCm has worse performance than OpenCL, because they downgraded their compiler and stopped extracting read/write information on variables leading to a massive loss of parallelism and utilisation on their GPUs.. for some reason. Why? What are they doing? How is this so rubbish?
Literally ALL of this is WONTFIX, and I don't have a clue why. I've filed bugs, was part of their vanguard supporter program, have tried to reach out to AMD people to (gently) explain why good support is important. Or even just figure out what technology they're even intending to support for GPU development. Is ROCm deprecated? What should we be using on windows for GPU compute on consumer hardware AMD? For the love of god amd I want to make you money
As of 2026, the best cross platform cross vendor API for doing GPU compute is.. drumroll.. OpenCL 1.2. Vulkan is getting there, but its still missing a bunch of stuff. And this is literally AMDs direct fault at this point
Git is part of the LLM's training set though, so simply asking it to recreate git in another language is pretty equivalent. Like, you can almost certainly get these LLMs to output gits full source code with some prompting, so there's not that much difference (as much as we like to pretend that AI generated code has no copyright implications)
As mentioned in another comment, it's even more clear cut in this case. They actually put the original git sources in their project repo and instructed the agent to use it as the "source of truth".
Simple thought experiment. If you handed this same agents.md file (https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...) to a human software developer and let them work on exactly the same goal, would their output be considered a derivative work?
That's something I have been wondering. If I as a human want to make a clean room reimplementation of some API or application, I must not have read the source code of the original implementation. I don't see why this shouldn't apply to LLMs as well. If an LLM might have been trained on the original source code, it should be considered "tainted".
Yes, and realistically any code that LLMs produce is a derivative work of its training data. There's going to be a huge disaster licensing wise
I have absolutely no idea how LLMs got through anyone's legal departments, I guess the hope is that if everyone breaks the law enough, it'll just be fine
> if everyone breaks the law enough, it'll just be fine
That's pretty much what happened, isn't it? These concerns were all discussed in the beginning back in 2022, and I recall answers from many here on HN along the lines of "oh well, we can't stop it now or we'll risk falling behind China in AI development"
So yeah, the laws went out the window a long time ago the moment our government and the people decided to just look the other way willingly in the name of "progress."
> the hope is that if everyone breaks the law enough, it'll just be fine
Ever since the early 2010s when companies were started with the business idea "unlicensed hotels" and "unlicensed taxis" and made the owners really, really rich, this is said pretty much out loud. Look for words like "regulatory risks" and similar.
Maybe it started with the unlicensed gambling fad before that? That also made a lot of people filthy rich. Every time you have something under special license, or insuance requirements, then of course there is a margin for you if you can skimp on the license and hire gig workers instead.
The LLM situation with copyright and derived works in the 2020s is similar. Someone is likely to be rich, but there is a clear regulatory risk to it.
Problem is there's a lot more than a single repo in training data, the corpus is massive... Should the author of a blog post on cats also be compensated for simply being in the same training data as the git repo?
Honestly? Yes. This is why its such a problem that most of the training data was not used with permission, and without the correct copyright status or license associated with it
There's a lot of arguments about humans doing the same thing, but the reality is that humans and robots don't enjoy the same legal protection. Its clearly a derivative work of all of its training data
Then it works both ways. Say I manage to generate essentially a ripoff of your copyrighted song, release it and make a ton of money, you now have to split that royalty with keyboard cat. And Joe bloggs. You'd end up fractions of pennies
> If I as a human want to make a clean room reimplementation of some API or application, I must not have read the source code of the original implementation.
That is the difference between necessary and sufficient. Clean-room is sufficient to guarantee avoiding copyright, but it is not necessary. The line legally is south of there, but that position was chosen because they didn’t want to crossing and it was easier to argue for legally in court.
tl;dr: clean room is overkill for avoiding copyright infringement
> Like, you can almost certainly get these LLMs to output gits full source code with some prompting, so there's not that much difference (as much as we like to pretend that AI generated code has no copyright implications)
Are you sure? LLMs are in some way a compressed version of their input but it's a pretty lossy compression (arguably this makes them more like a compression algorithm than a compressed version of the data). I'm not sure you can prompt a full, accurate, copy of a nontrivial codebase out of them. Even with zero temperature their accuracy is just not that high.
> I'm not sure you can prompt a full, accurate, copy of a nontrivial codebase out of them. Even with zero temperature their accuracy is just not that high.
> For Claude 3.7 Sonnet, we were able to extract four whole books near-verbatim, including two books under copyright in the U.S.: Harry Potter and the Sorcerer’s Stone and 1984 (Section 4).
That paper is basically using the LLM as a compression algorithm: it's prompting with some section of the book and it's reprompting if it doesn't give the right output. Notably this only works if you already have a copy of the book in question!
You misunderstand my point: the LLM is not a losslessly compressed version of the text: you need to supply additional information from the original in order to 'extract' it from the LLM (and from that point of view, the extra information would be the compressed form).
1. Firefox's ctrl-f search doesn't highlight all instances of a found item on the right hand side. It sounds petty, but its a gigantic timesaver for looking through research documents
2. Firefox's tab crash recovery isn't as solid. I use chrome with fully persistent tabs, and its a gigantic pain if I can't re-open them
If I could find a way to fix these I'd swap in a heartbeat
You need to click "highlight all" to highlight all occurrences. It's the checkbox to the right of the search box. If you enable it for the first time, you may need to hit enter in the search bar again for it to show up (it remembers the setting and works instantly the next search)
> 2. Firefox's tab crash recovery isn't as solid. I use chrome with fully persistent tabs, and its a gigantic pain if I can't re-open them
I normally have 5-50 tabs open (so perhaps on the lower end), but I can't recall the last time I crashed a tab in the last 3 years. I also use persistent/pinned tabs and never noticed issues.
Its not the tabs themselves crashing, its when firefox (or my pc as a whole - I'm a developer and its a frequent occurance) crashes, firefox isn't as good as chrome at remembering what tabs were previously open
In some of the experiments, the same random noise background exists with different black blobs superimposed at where you expect the correct value to be. Ie they took a fixed realistic-ish looking background, and drew in the 'correct' values
Its hard to argue that that isn't fraud as a result. It isn't touching up existing data, its fully fabricating data
I've consistently tried to apply LLMs to physics problems and they're utterly useless. They'll just confidently lie, or blatantly plagiarise source materials
The issue is once you hit niche physics simulations there simply isn't any training data available, so the limitations of them become incredibly apparent. Its also problematic because a field itself will contain lots of wrong information (its research!), and AI picks all this up uncritically
I thought I'd give chatgpt a quick spin on my favourite question, which is "is the adm formalism strictly equivalent to general relativity", to which it consistently gives the wrong answer
>Ah, now you’re hitting the subtlety head-on—that’s exactly where the “strict equivalence” claim needs nuance. Let’s unpack this carefully.
I don't know how anyone can stand these tools. Its just an obnoxious glazing machine that tells me I'm a genius consistently
Gemini gives a little more of a robust answer, but fails catastrophically for the question "is the bssn formalism numerically stable", where just about the entire answer is completely wrong from top to bottom. It certainly looks convincing. Its got all the right terminology. It manages to piece together the right set of words, but all the informational content is wrong, which isn't exactly a small problem
That's why there are companies specialising in AI for physics, like Emmi AI (now part of Mistral). If BMW and Airbus go on stage to talk about how they're using it for their physics simulations, it's probably at least decent.
Usage isn't really a good indicator of quality currently in the AI space, the issue is that there's inherently no way that an AI physics sim can be as good as a real physics simulation, which makes it a very low value prospect
Usage by reputable engineering organisations with strict compliance and external testing validation (most notably Airbus, they have to prove to EASA that their tests are real and representative) is a decent indicator that there is something there.
There is absolutely no data, review, evidence, or any indication whatsoever of how this is being used, or what the efficacy of it is
The current trend of every industry is to jump onto anything, call it AI, and pretend its being used everywhere. There's absolutely good reason to be sceptical of this
>The transformation used to represent the physically linear intensity data either generated synthetically via an algorithm or captured by a linear device (such as a CMOS of a digital camera or a scanner) with the discrete values of the perceptually linear scale is called gamma encoding.
This isn't super correct, and it underscores the biggest issue in this article:
sRGB (and its gamma encoding function) has absolutely nothing to do with perceptual linearity. sRGB is not perceptually linear! The original gamma encoding as far as I'm aware was made to compensate for the nonlinear transfer function of CRTs back in ye olde days. Its true that human vision is nonlinear, but sRGB is not a particularly good match to the perceptual linearity of human vision. Its a really common error to make, and leads to people wondering why we can't use sRGB to blend in if the reason why it was invented is because its perceptually linear
The article goes to compound on this mistake, which is why this is such a problematic misconception:
> Interestingly, Photoshop antialiases text using γ=1.42 by default, and this indeed seems to yield the best looking results (middle image). The reason for this is that most fonts have been designed for gamma-incorrect font rasterizers, hence if you use linear space (correctly), then the fonts will look thinner than they should.
This is where the mistakes start to add up
Consider what you're trying to achieve during antialiasing: when rasterising a line, lets say we discover that a pixel is only 40% covered and want to darken it. This means that we want our pixel's brightness to decrease by 40% to a human being. We don't want to emit 40% less light, because that's not what antialiasing is trying to achieve!
Both sRGB and linear colour are the wrong colour spaces to use. You want to blend in a perceptually linear colourspace, and photoshop's 1.42 gamma exponent probably maps better to human vision than 2.2 or 1.0 while being cheaper than a LUV conversion
>The standard gamma (γ) value to use in computer display systems is 2.2. The main reason for this is because a gamma of 2.2 approximately matches the power law sensitivity of human vision
The gamma transfer functions are also wrong. Its worth getting hung up on because it actually causes nontrivial errors, especially in the age of hardware accelerated sRGB conversions where doing it correctly is free
reply