Intel Thunder Bay is officially canceled, Linux driver code to be removed(phoronix.com)
phoronix.com
Intel Thunder Bay is officially canceled, Linux driver code to be removed
https://www.phoronix.com/news/Intel-Thunder-Bay-Cancelled
52 comments
In other intel news, Raja is no longer with them. Seems like he was forced out and some of the rumours about the bleak future of their consumer GPU business may turn out to be true
Turns out the leadership of Intel is stupider than I thought.
It's almost impossible to believe that they actually thought they'd be able to go up against two GPU makers each with 25+ years of experience.
This was always going to be a long uphill battle. Always. I figured it would take at least 10 years for Intel to become competitive, but turns out they tucked tail and ran.
Mediocre!
It's almost impossible to believe that they actually thought they'd be able to go up against two GPU makers each with 25+ years of experience.
This was always going to be a long uphill battle. Always. I figured it would take at least 10 years for Intel to become competitive, but turns out they tucked tail and ran.
Mediocre!
Arc is insanely good for a first attempt at a discrete GPU. It has mid tier performance for mid tier price, and drivers are still getting tons of work from intel that makes them better and better almost every release. It's actually crazy that they managed to do so well (mid-tier is still amazingly powerful, all things considered). If they stick with it, there's no reason to believe they won't be able to compete at the high end, too. I honestly expected a massive trash fire when I first heard of Arc, just because of the countless edge cases and driver/API hell that even Nvidia and AMD seem to run into continuously.
its not Intel's first foray into cancelled discreet GPUs. they've been on and off with this for at least 13 years
They've been trying with discreet gpus waaay longer than that. The 82786 is from the mid-80s.
I'm trying to understand their issue though, are they locked out of doing time tested solutions because of patents or something? My real question is are they just incompetent or are they not able to use known solutions.
They aren't incompetent or ignorant (well...on a macro scale). They just didn't succeed in a market that's a niche in a subset of the market they're after.
Intel makes a ton of money selling graphics silicon. They just haven't quite figured out the "plays the most demanding video games on max mode with a side of ML/AI" market yet.
Predictions of Intel's demise are greatly premature.
Intel makes a ton of money selling graphics silicon. They just haven't quite figured out the "plays the most demanding video games on max mode with a side of ML/AI" market yet.
Predictions of Intel's demise are greatly premature.
3060 wasn't mid tier performance when high-end Arc was released anymore.
Intel has been making GPUs since roughly 2002, 845 chipset series. (There were earlier ones, but I'm
Intel740, 1998.
I was on the team that wrote the DirectX 3 and 5 drivers for the 740 (I wrote the vxds in assembly using MASM 6.11). It wasn't a GPU in today's terms (huge parallel vector engines), it was just a basic 3d pipeline: triangle pipe (with Gouraud lighting, 1st version didn't even have phong/specular) followed by rasterizer, with a 2D engine. You sent it triangles with aRGB color, and it interpolated and rasterized them. Dat's it. Total dud compared to Voodoo 3DFx or ATI Rage3D. But when we integrated it into the 810 chipset it became the main reason why 3D gaming was held back for a decade: it was the top selling graphics engine but it sucked so every game dev had to design for the lowest common denominator. It was never intended to be good. But it sure did result in the promotion of a lot of engineers to principal. (raises hand)
You sent it triangles with aRGB color, and it interpolated and rasterized them. Dat's it. Total dud compared to Voodoo 3DFx or ATI Rage3D
I don't get it - that was what all gfx chips were before shaders came along. That's not unlike how the PS2's GS chip worked too. Texturing and triangles was everything. What feature did the Voodoo have that the 740 didn't?
I don't get it - that was what all gfx chips were before shaders came along. That's not unlike how the PS2's GS chip worked too. Texturing and triangles was everything. What feature did the Voodoo have that the 740 didn't?
3dfx/ATI were faster.
Ah - I see. Yeah, raw performance was (and is) really an enabling feature with gfx chips.
Intel 82786, 1986
Wasn't that mostly just PowerVR IP? Or was that mostly the SoC/Atom line.
That's Apple who uses PowerVR IP.
They only used PowerVR GPUs for a single Atom generation (I think it was the second).
Yes, just not good ones
Didn't they buy Chips and Technologies many years ago to improve their GPU offerings and then dumped the idea? Intel does GPUs in fits and starts but never sticks with it long term. It's always a pet project.
C&T wasn't really performance-oriented either; and as far as I know, they were 2D-only. The i740's non-3D parts have a lot of similarity to C&T's latest accelerators.
True. I think intel at the time got spooked by 3rd party MB mfgs (acer, asus, etc) who were integrating video in their mobos but intel wasn’t and they didn’t want to lose market share or maybe they wanted people to at least have a passable basic VGA without needing an add on card.
But for whatever business reason they felt mission accomplished and dropped it. Then over the years they’ve bought others for differing business reasons.
But the common thread is they never stuck to it and never dedicated resources to make it flourish and succeed on its own merit.
But for whatever business reason they felt mission accomplished and dropped it. Then over the years they’ve bought others for differing business reasons.
But the common thread is they never stuck to it and never dedicated resources to make it flourish and succeed on its own merit.
Gelsinger did a fantastic job ruining VMware before jumping over to Intel to do the same.
He projects himself as a savior if you've been around him. I'm not sure if it's his deep religious beliefs, but the guy doesn't understand what the market wants. He may be a great engineer, but he's horrible at the helm. Unfortunately, with someone like him, he's got credibility in areas that open doors for him that shouldn't be.
After going through their Larrabee efforts, and OpenGL drivers that used to lie about what was actually supported in hardware, I am not surprised how things turned out.
This is already being discussed in the relevant post: https://news.ycombinator.com/item?id=35252056
Weird I was born in Thunder Bay, thought maybe they were opening a plant there that got cancelled. Wonder why they called it Thunder Bay Harbor, especially because Thunder Bay is a harbor town...
Thunder Bay went to play with Larabee between the stars.
Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
I think the idea is that the hardware will work under linux right away when the hardware goes on sale, instead of some number of months or years later. Surely that amounts to a selling point.
> now we're left with useless crap in the kernel.
The article is specifically about removing the now-useless crap, and the removal patches were submitted by Intel. I don't see how Intel is doing anything wrong here.
> now we're left with useless crap in the kernel.
The article is specifically about removing the now-useless crap, and the removal patches were submitted by Intel. I don't see how Intel is doing anything wrong here.
> if that person quits or the company discontinues a product, now we're left with useless crap in the kernel
Presumably deleting code is not very hard if it is unmaintained or a burden.
> Why can't these companies just build their own modules? Why is it everyone else's problem?
They're not upstreaming this so their own internal dev lives are easier. They'd rather just keep using whatever development repo they already are without dealing with upstream reviews and requirements. They were upstreaming this so that everyone could have support for the hardware upon release.
And, to that end, "corporations" upstreaming high quality support for their hardware, as intel has been doing, benefits linux. Throwing shade at them for preparing day-1 support for hardware they ended up canceling seems counter-intuitive.
Presumably deleting code is not very hard if it is unmaintained or a burden.
> Why can't these companies just build their own modules? Why is it everyone else's problem?
They're not upstreaming this so their own internal dev lives are easier. They'd rather just keep using whatever development repo they already are without dealing with upstream reviews and requirements. They were upstreaming this so that everyone could have support for the hardware upon release.
And, to that end, "corporations" upstreaming high quality support for their hardware, as intel has been doing, benefits linux. Throwing shade at them for preparing day-1 support for hardware they ended up canceling seems counter-intuitive.
Maintaining out of tree kernel modules and guaranteeing compatibility is a nightmare.
Partially because in difference to the strict backward compatibility guarantees of the Linux user interface there are no such (strict) guarantees for the kernel interface.
In the end this is both grate for Linux and Intel (and Nvidea, Amd, etc.):
- kernel developers can make sure their code doesn't brake vendor code, this isn't just about being nice to vendors but about being able to do large internal refactoring which affect many/all kernel modules in a small way (good for both, in case of not yet released and in rare cases internal only hardware mainly for the vendor)
- kernel developers can see how the kernel is used and where there might be problems with the current kernel interface and design (good for Linux)
- kernel developers can enforce a certain minimal level of code quality or not allow hacks which would lead to serve security issues or incompatibilities (good for Linux)
- it's much easier to make sure that different drivers/kernel modules don't conflict in subtle ways (good for both Linux and vendors)
- customers buying the hardware often can use it from release date without needing custom kernels (good for everyone)
- abandoned drivers/modules can be picked up and maintained by 3rd parties allowing longer usage of otherwise no longer supported hardware
Lastly while companies like Intel do not own Linux they are some of the main contributors of financial resources often more then covering any additional costs caused by this (I mean for server hardware and more powerful embedding hardware Linux strongly dominates the marked and it's also one of the main markets for Intel, Amd, Nvidea and one of the main building blocks for companies like Google).
Anyway this is good for everyone and in _total_ reduces the amount of work involved in making Linux work with all kinds of hardware.
Partially because in difference to the strict backward compatibility guarantees of the Linux user interface there are no such (strict) guarantees for the kernel interface.
In the end this is both grate for Linux and Intel (and Nvidea, Amd, etc.):
- kernel developers can make sure their code doesn't brake vendor code, this isn't just about being nice to vendors but about being able to do large internal refactoring which affect many/all kernel modules in a small way (good for both, in case of not yet released and in rare cases internal only hardware mainly for the vendor)
- kernel developers can see how the kernel is used and where there might be problems with the current kernel interface and design (good for Linux)
- kernel developers can enforce a certain minimal level of code quality or not allow hacks which would lead to serve security issues or incompatibilities (good for Linux)
- it's much easier to make sure that different drivers/kernel modules don't conflict in subtle ways (good for both Linux and vendors)
- customers buying the hardware often can use it from release date without needing custom kernels (good for everyone)
- abandoned drivers/modules can be picked up and maintained by 3rd parties allowing longer usage of otherwise no longer supported hardware
Lastly while companies like Intel do not own Linux they are some of the main contributors of financial resources often more then covering any additional costs caused by this (I mean for server hardware and more powerful embedding hardware Linux strongly dominates the marked and it's also one of the main markets for Intel, Amd, Nvidea and one of the main building blocks for companies like Google).
Anyway this is good for everyone and in _total_ reduces the amount of work involved in making Linux work with all kinds of hardware.
You’re practically not supposed to to build external modules. It’s supported to only the most minimal degree- Linus, and the Linux project, WANT you to build things in.
And as everyone else has told you, this is so that support for hardware is in Linux and in distros BEFORE users have to taint their kernels and create crazy bugs kernel devs have to deal with.
And as everyone else has told you, this is so that support for hardware is in Linux and in distros BEFORE users have to taint their kernels and create crazy bugs kernel devs have to deal with.
> WANT you to build things in.
Only if you adhere to their standards, until very recently you couldn't even do rust. If i made something fully working in rust today it still wouldn't get accepted.
Only if you adhere to their standards, until very recently you couldn't even do rust. If i made something fully working in rust today it still wouldn't get accepted.
That’s exactly why they want you to do it with them though- so they can make you do it too their standards.
No it isn't. The reason you can't write external modules is because the kernel interfaces aren't stable. You would have to provide a module binary for every single kernel version (and maybe even for different configurations).
And the reason for that is mostly that providing a stable interface is a) a ton of work, and b) would make distributing closed source drivers easier which is something Linus hates.
And the reason for that is mostly that providing a stable interface is a) a ton of work, and b) would make distributing closed source drivers easier which is something Linus hates.
if you read the mailing list, you know there’s a lot of reasons. Linus hates out of tree and closed modules for quite a number of reasons- but in this specific context it seems the most relevant.
For the point about the Google firmware modules, the firmware directory you linked to is specifically for Chromebooks, which people do have, and the modules are useful if you want to run vanilla Linux with coreboot on this hardware. If the code for these modules was maintained out of tree it would be much harder to run a regular Linux distribution on the hardware as you'd have to go build a custom kernel rather than just reconfiguring and rebuilding the kernel your distro provides.
Furthermore the whole point of modules on Linux is that you can completely disable them, or if they're built as modules they'll only be loaded if needed (in some cases this is done on-demand automatically if the relevant hardware is detected, in other cases it might be done via logic in your initrd).
Furthermore the whole point of modules on Linux is that you can completely disable them, or if they're built as modules they'll only be loaded if needed (in some cases this is done on-demand automatically if the relevant hardware is detected, in other cases it might be done via logic in your initrd).
Because everyone is better off if distribution kernels get the hardware support before the hardware is purchased.
Because then consumers get hardware that works out of the box on Linux. That's how good corporations contribute.
https://youtu.be/fMeH7wqOwXA&t=420s
https://youtu.be/fMeH7wqOwXA&t=420s
> Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
To get the code ready for when the hardware is available.
> I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
A lot of companies and individuals can step up to maintain the code once it's there and working. If it's important, they will and they have. Only dead-dead systems like the 80386 get removed; or, in this case, vaporware that never materialized to begin with.
Modules are bad because they're code that isn't subject to the same review as normal kernel code, may be closed-source or under some obnoxious license, and probably is going to be more difficult to install than just a kernel update.
So we want it to be "everyone else's problem" because that means anyone else can step up if a company fires the people maintaining the code for hardware the kernel team still wants to support. With a module, it might be the case that the module only works on some range of kernels and is very difficult to replicate its functionality on more modern ones once the original company drops out. That's not a good position to be in if you rely on being able to run modern Linux on that hardware.
To get the code ready for when the hardware is available.
> I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
A lot of companies and individuals can step up to maintain the code once it's there and working. If it's important, they will and they have. Only dead-dead systems like the 80386 get removed; or, in this case, vaporware that never materialized to begin with.
Modules are bad because they're code that isn't subject to the same review as normal kernel code, may be closed-source or under some obnoxious license, and probably is going to be more difficult to install than just a kernel update.
So we want it to be "everyone else's problem" because that means anyone else can step up if a company fires the people maintaining the code for hardware the kernel team still wants to support. With a module, it might be the case that the module only works on some range of kernels and is very difficult to replicate its functionality on more modern ones once the original company drops out. That's not a good position to be in if you rely on being able to run modern Linux on that hardware.
[deleted]
Because if they don't allow these kinds of code contributions, and wait until products are shipping to accept code, upstream Linux will be a year or more behind when new chips get shipped, and users will have to run out-of-tree forks of questionable quality. And in this case, the now-useless crap is being removed from the kernel.
As a user, it seems much more likely to become my problem if it isn't baked in.
> I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
Because if it gets truly abandoned, the kernel folk are generally pretty good at ripping it out. And the idea is that supporting weird cases off and on will lead to a more general kernel that will be able to attack future needs for everyone a little better.
Because if it gets truly abandoned, the kernel folk are generally pretty good at ripping it out. And the idea is that supporting weird cases off and on will lead to a more general kernel that will be able to attack future needs for everyone a little better.
As long as its being maintained by them and isn't adding to their maintainence burden why care?
Eh, because it is nice to be able to buy hardware on release day and actually have it work.
Because linux just doesn't have a good driver stack like WDM. Everything is better just built into the kernel.
Kernel module just cannot solve all problems.
Because kernel developers are paid by same corporations?
Linux hasn't been a community project in decades. It's basically run by a consortium of the biggest Chinese and American companies. And especially since Linus went away for his vacation-style treatment a few years ago, it's been getting much much worse.