Open-Source AMD Radeon Linux Graphics In Great Shape For Workstations, Handily Beating Proprietary Driver

[smitty3268]

I feel like Mesa3D is in it's GCC stage of life right now and needs to move on to being LLVM.... I realize Mesa has more in common with LLVM but the point stands due to various relatively small areas of the code its very Linux specific. Aka small portion of the code or minor architectural issues making it difficult to adopt elsewhere.

Mesa runs perfectly fine on windows, and has for a long time. The only issue is that the windows kernel driver and the linux kernel drivers are different. So you have to port the userspace drivers to the different kernel APIs if you want it to work.

Same thing that causes radv to only support the amdgpu kernel driver on linux and not the older radeon kernel driver.

[smitty3268]

there were also stupid reasons like "too much abstraction" without taking into account requirement to share code with other environments

Whose requirement? AMD can add whatever requirements they want to their own code, but all the linux kernel maintainers care about is whether the code integrates well with the linux kernel. If you can't do that, they're under no obligation to take it anyway.

[cb88]

Sure. In this case we'd just need to convince a larger team which has been maintaining and tuning their code base for years across OSes to switch to a different code base with a different governance model that doesn't currently support their main target OS.

There are in fact many good arguments in favor of exactly that. From every angle...
If it is easier to use the code in a wider number of use cases... more people will use it.
More people using the code means more development input. (granted there are caveats like maybe billions of android users don't translate into many developers whereas HPC translates into a lot etc...)
Also once more people use your code... more people test against your code... which helps both in reporting bugs as well as passively code getting written to run well on Mesa to begin with.

I feel like Mesa3D is in it's GCC stage of life right now and needs to move on to being LLVM.... I realize Mesa has more in common with LLVM but the point stands due to various relatively small areas of the code its very Linux specific. Aka small portion of the code or minor architectural issues making it difficult to adopt elsewhere.

[agd5f]

There is no reason for Mesa3D to not support other operating systems... Current Linux, BSD(s), Aros and Haiku have hardware acceleration maybe a few others but it is an area of Mesa3d that needs decoupling from Linux.

Sure. In this case we'd just need to convince a larger team which has been maintaining and tuning their code base for years across OSes to switch to a different code base with a different governance model that doesn't currently support their main target OS.

[cb88]

There are two separate teams. We still need to support other OSes so not having a closed source driver on Linux does not suddenly free up a lot of resources to work on Linux. Windows still needs a driver.

There is no reason for Mesa3D to not support other operating systems... Current Linux, BSD(s), Aros and Haiku have hardware acceleration maybe a few others but it is an area of Mesa3d that needs decoupling from Linux.

[pal666]

You specifically mentioned the trouble that AMD had in getting DC merged. There were legitimate reasons why that didn't just get merged straight away, it wasn't just "they buttmad we sharing code yo".

there were also stupid reasons like "too much abstraction" without taking into account requirement to share code with other environments

[Gonk]

Back to the topic of the article, this is excellent news since the rumours are that all of the next generation desktop Ryzen processors (Q3 this year maybe?) will have integrated graphics (RDNA2).

[agd5f]

You specifically mentioned the trouble that AMD had in getting DC merged. There were legitimate reasons why that didn't just get merged straight away, it wasn't just "they buttmad we sharing code yo".

There were some coding style issues, sure, but the main crux of the argument was whether you could have effectively code share between OSes. My point is that code sharing is not always so straight-forward as it may seem.

[microcode]

I'm not sure what I did that was offensive. I didn't say anything about my colleagues. I was merely commenting about the fickle whims and armchair commentary from the those who comment in this forum.

You specifically mentioned the trouble that AMD had in getting DC merged. There were legitimate reasons why that didn't just get merged straight away, it wasn't just "they buttmad we sharing code yo".

[agd5f]

I do not want to criticize anything you are doing. I do not have enough information and knowledge to do so.

It was truly just meant as a question. And I am also aware, that it must not necessarily be an advantage for the Linux drivers.

So no offense from my side, just curiosity.

No offense taken, it was meant as a somewhat of a joke I think it will be a challenge since each OS has it's own set of additional requirements. Windows has some pretty crazy requirements that wouldn't fly on Linux. So we'd probably have to fork it if we tried to code share. Resyncing trees would be a lot of work, for little gain. I think if you want to code share, you need to code share directly. Once you fork, it gets harder and harder to stay in sync. Additionally, there would be quite a bit of training required to get internal developers in sync with mesa governance models and what is ok and not ok to discuss in public. So, it's theoretically possible, but it's not that slam dunk it might seem to be.