4 ms·

> and release them on the same day That isn't necessary. > without writing code twice That isn't anywhere near as difficult as you make it out to be. Writing

> and release them on the same day That isn't necessary. > without writing code twice That isn't anywhere near as difficult as you make it out to be. Writing code is not difficult, or particularly time-consuming. Designing code is. Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. to run incorrectly to optimize for a specific proprietary game engine. Those updates are to the OpenGL/etc. implementation itself, not the communication with the kernel, meaning those changes will be similar, if not exactly the same in each driver, without any extra abstraction. Also remember that most of these AAA title games do not have Linux support in the first place, and many of them only support DirectX, which will not be implemented in the Linux driver. Here in Linux, we care about FPS in proprietary game engines much less than correct working drivers. > You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes. It's true that graphics APIs (especially Vulkan) are continually changing, and that those changes must be implemented in each driver. That still does not mean it is significantly easier to write one implementation for windows, and just copy it to the Linux driver. In fact, those who work on Linux itself believe the opposite. It's also worth noting that Vulkan is meant to be so low-level that its implementations will likely be quite different between Windows and Linux. > AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me. > Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux. You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. That means you are relying on AMD alone to implement them, so I am entirely unable to help you. That is the situation we started with for the entire driver, and AMDGPU marks a significant improvement. You may believe that Linux devs compromising to allow AMD to create a complicated layer in their mainline driver would help them, but I don't believe that to be the case, and neither do they. The true reason that AMD wants a DAL in their driver is that they aren't willing to entirely discard their old habits, and instead insist on a driver that is, at least partially, closed source. As long as they do that, they require themselves to do wildly unnecessary work, and create entirely worthless incompatibilities, purely out of stubbornness. Stubbornness that will continue to be reciprocated by the Linux dev team. I will continue to do what I can to support AMD, as long as they make strides toward Free drivers, but I know there are always politics involved, and that AMD won't change overnight.

kuschku 9y ago
> That isn't necessary. Yes it is, if you care about your users. > Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. t Thanks to Vulkan that’s irrelevant anyway – I’m talking about stuff like shadowplay or similar functionality, and the APIs for that. > It's true that graphics APIs (especially Vulkan) are continually changing > You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. Stop being so stubborn, please. You still don’t get it. I’m not talking about the graphics APIs, which change on a scale of months to years. I’m talking about exactly these additional functionalities, which are basically addons to the driver, hook into the driver, and for example dump the driver state at a moment (for 3D screenshots), or keep a memory buffer of the current videostream (for instant replay and share), or so on. None of this functionality has to be closed source. If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them. > If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me. You mean, developers that still don’t get the entire point of what I’ve been talking about, developers that suggest they’d rather have people use Windows than add a stable driver ABI into Linux, developers that want to force a release cycle of several years onto drivers? Because that’s the reality of forcing drivers to be mainlined without a stable ABI. The majority of users will be stuck on a several year old kernel. How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
- thomastjeffery 9y ago
  > You still don’t get it. I do. Believe me, I do. > developers that still don’t get the entire point of what I’ve been talking about They do too. They acutely understand all of the advantages and drawbacks of a HAL, and how it would effect the project that they work on, and have chosen explicitly not to allow one. I'd like you to understand why, because these are intelligent people, many of them dedicating time and expertise for nothing in return but the satisfaction of the contribution itself. It sounds like a great idea to have an abstract interface for these things. That's what a microkernel is all about. Microkernels are great, but Linux is a monolithic kernel. That is the core of its design. Linux isn't going to adapt its core design to be more compatible with proprietary software. In fact, Linux should do nothing to be more compatible with proprietary software, because that would simply perpetuate the problem. A monolithic kernel does have some advantages. * The kernel can change without breaking drivers, because drivers are part of the kernel * There is no layer between drivers and the kernel, meaning no overhead, no translation, but raw communication. These advantages are fundamentally broken by introducing abstraction layers. Extra abstraction also introduces more maintenance work. If AMD really wants a microkernel, it can start focusing on its FreeBSD driver. > None of this functionality has to be closed source. That is entirely my point. > If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them. That is a compromise. A compromise that kernel devs are not willing to make. Linux is Free Software. Free as in Freedom. Free software users do not have to deal with the problems that are caused by proprietary software, of which there are many. > How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years? > The majority of users will be stuck on a several year old kernel. The "majority of users" are running enterprise servers. That is the only reason to use a longterm kernel release. Users of a longterm kernel will not expect driver updates, in fact expecting the opposite. The vast majority of users similar to you will be running stable kernels. > Stable kernel updates are released on as-needed basis, usually 2-3 a month. [1] That is an entirely reasonable time-frame for updates. If users want a more bleeding-edge release, they will use prepatch (RC) kernels. [1](https://www.kernel.org/category/releases.html https://www.kernel.org/category/releases.html)

kuschku 9y ago

> That isn't necessary. Yes it is, if you care about your users. > Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. t Thanks to Vulkan that’s irrelevant anyway – I’m talking about stuff like shadowplay or similar functionality, and the APIs for that. > It's true that graphics APIs (especially Vulkan) are continually changing > You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. Stop being so stubborn, please. You still don’t get it. I’m not talking about the graphics APIs, which change on a scale of months to years. I’m talking about exactly these additional functionalities, which are basically addons to the driver, hook into the driver, and for example dump the driver state at a moment (for 3D screenshots), or keep a memory buffer of the current videostream (for instant replay and share), or so on. None of this functionality has to be closed source. If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them. > If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me. You mean, developers that still don’t get the entire point of what I’ve been talking about, developers that suggest they’d rather have people use Windows than add a stable driver ABI into Linux, developers that want to force a release cycle of several years onto drivers? Because that’s the reality of forcing drivers to be mainlined without a stable ABI. The majority of users will be stuck on a several year old kernel. How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?

thomastjeffery 9y ago
> You still don’t get it. I do. Believe me, I do. > developers that still don’t get the entire point of what I’ve been talking about They do too. They acutely understand all of the advantages and drawbacks of a HAL, and how it would effect the project that they work on, and have chosen explicitly not to allow one. I'd like you to understand why, because these are intelligent people, many of them dedicating time and expertise for nothing in return but the satisfaction of the contribution itself. It sounds like a great idea to have an abstract interface for these things. That's what a microkernel is all about. Microkernels are great, but Linux is a monolithic kernel. That is the core of its design. Linux isn't going to adapt its core design to be more compatible with proprietary software. In fact, Linux should do nothing to be more compatible with proprietary software, because that would simply perpetuate the problem. A monolithic kernel does have some advantages. * The kernel can change without breaking drivers, because drivers are part of the kernel * There is no layer between drivers and the kernel, meaning no overhead, no translation, but raw communication. These advantages are fundamentally broken by introducing abstraction layers. Extra abstraction also introduces more maintenance work. If AMD really wants a microkernel, it can start focusing on its FreeBSD driver. > None of this functionality has to be closed source. That is entirely my point. > If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them. That is a compromise. A compromise that kernel devs are not willing to make. Linux is Free Software. Free as in Freedom. Free software users do not have to deal with the problems that are caused by proprietary software, of which there are many. > How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years? > The majority of users will be stuck on a several year old kernel. The "majority of users" are running enterprise servers. That is the only reason to use a longterm kernel release. Users of a longterm kernel will not expect driver updates, in fact expecting the opposite. The vast majority of users similar to you will be running stable kernels. > Stable kernel updates are released on as-needed basis, usually 2-3 a month. [1] That is an entirely reasonable time-frame for updates. If users want a more bleeding-edge release, they will use prepatch (RC) kernels. [1](https://www.kernel.org/category/releases.html https://www.kernel.org/category/releases.html)