The Slides Announcing The New "AMDGPU" Kernel Driver

[whitecat]

Any idea on if/when crossfire will be hammered out?

I don't think AMD will work on this soon, there is more important things on the TODO list before that.
Moreover, if I remeber a comment from David Airlie or maybe Alex Deucher, there is nothing really magical in Crossfire/SLI. This is about balancing in some manner the rendering a different GPU.
Such things needs modification in the kernel (?), DRM (?), Mesa (?) that can be done by someone outside of AMD (Red Hat, community, etc.). There is maybe some "magic" number/register to set up but I'm pretty sure AMD will give some help if someone intend to work on this Crossfire support.

That is exactly why I buy Nvidia - decent support length.

There is exactly 4 years between the former HD4000 series release and the last Catalyst version to support them.
AMD, Enterprise vendor and the "community" still provides updates to r300 and r600g, and even r200 which so implies hardware from mid-2001.
And the kernel and xorg packages still includes drivers from even older hardware.

Please give me a game that HD4000/r600g can't handle correctly with decent performance.

[dungeon]

If you watched the presentation explaining all this, you'd have your answer already.

The non-pro version exists now because people today rely on the Catalyst driver for GL4, OpenCL2, etc. work that the open driver does not yet provide.

He pretty much flat out said they'd like to get rid of the remaining Catalyst blob on linux, it's just that Mesa isn't quite there yet and so they have to keep their current customers happy.

I watched a video, they will do it like they want... so there is no question about that, i suggest what i liked more .

They can put more resources to opensource driver and mesa UMD... well i avoid using acronym like that , that does not exists in my plan at all, because there is no any collision/competing userspace drivers for the same asic

If they really want to expand opensource driver and talk about opensource, that is the way i think... OpenGL4 mature, oh that is a nonsense for non-pro users if they actually work more on Mesa instead, isn't it It does not matter if they lag a little with that, if they do a right thing.

[whitecat]

I don't think AMD will work on this soon, there is more important things on the TODO list before that.
Moreover, if I remeber a comment from David Airlie or maybe Alex Deucher, there is nothing really magical in Crossfire/SLI. This is about balancing in some manner the rendering a different GPU.
Such things needs modification in the kernel (?), DRM (?), Mesa (?) that can be done by someone outside of AMD (Red Hat, community, etc.). There is maybe some "magic" number/register to set up but I'm pretty sure AMD will give some help if someone intend to work on this Crossfire support.


There is exactly 4 years between the former HD4000 series release and the last Catalyst version to support them.
AMD, Enterprise vendor and the "community" still provides updates to r300 and r600g, and even r200 which so implies hardware from mid-2001.
And the kernel and xorg packages still includes drivers from even older hardware.

Please give me a game that HD4000/r600g can't handle correctly with decent performance.

Wrong thread

[profoundWHALE]

Will AMD cooperate with the *BSDs and (Open-)Solaris, so we will have a choice (today only nVIDIA) there in the future?

The way I see it, in theory with one unified driver we could see the porting of it over to the BSDs and then the userspace driver should be a lot easier to keep updated/ported if it is needed. Of course, this would require the BSDs to accept it.

Honestly, while I would love better BSD support from AMD, I would rather have more devs working on just the open source Linux side, because odds are that awesome will be spread around like a jar of some sweet, sweet, jam.

[drSeehas]

The way I see it, in theory with one unified driver we could see the porting of it over to the BSDs and then the userspace driver should be a lot easier to keep updated/ported if it is needed. ...

AMD could make this porting to the *BSDs (done by the *BSDs) much easier, if AMD talks to the *BSDs before AMD makes any decision during the whole process.

... while I would love better BSD support from AMD, I would rather have more devs working on just the open source Linux side, ...

I am not talking/writing about AMD devs working on the *BSDs side. See above.

[Luke_Wolf]

AMD could make this porting to the *BSDs (done by the *BSDs) much easier, if AMD talks to the *BSDs before AMD makes any decision during the whole process.

I am not talking/writing about AMD devs working on the *BSDs side. See above.

Eh... It's more on the *BSDs to engage in dialog with AMD and get involved with the discussions happening upstream than for AMD to engage with the *BSDs downstream. Besides the *BSDs really aren't in a spot right now where talk is useful, they need to finish modernizing their stack and then finish porting the kernel drivers over first and once they're matched with upstream then discussion on future plans will be useful.

This all said what the *BSDs really need is help.

[drSeehas]

... the *BSDs really aren't in a spot right now where talk is useful, ...

??? Why?

... they need to finish modernizing their stack ...

You mean adapting to the Linux flavor?

... and then finish porting the kernel drivers over first ...

Oh, the new AMDGPU kernel drivers are already there?
As I wrote previously: There should be talks before releasing the new drivers.

... and once they're matched with upstream then discussion on future plans will be useful.

So you think the discussion will be usefull after the new AMDGPU driver is released?
My opinion: Then it is far too late :-(

This all said what the *BSDs really need is help.

And making the porting to the *BSDs easier would be a lot of help too.

[Luke_Wolf]

??? Why?

Because it's putting the cart before the horse.

Let me put this in an analogy for you

Imagine you've got one guy who has got a house with all kinds of expansions and neat features we'll call him AMD Linux, then we've got another guy who has the foundation laid but is still working on setting up the framework of the house, we'll call him BSD Graphics. It's not really useful for AMD Linux to talk to BSD Graphics about all the new cool home expansions and systems he's setting up, when BSD Graphics doesn't even have his house finished yet. On the other hand what BSD Graphics could really use is for AMD Linux to come over and help him get his house built.

You mean adapting to the Linux flavor?

Yes adopting the modern KMS infrastructure and friends

Oh, the new AMDGPU kernel drivers are already there?

They're not public yet but they already exist as a variant of the Radeon kernel driver, yes

As I wrote previously: There should be talks before releasing the new drivers.

And what use would that be? I've seen nothing that implicates that AMDGPU is going to change the kernel infrastructure around the GPU drivers as opposed to the changes being encapsulated inside the AMDGPU kernel driver itself. Further even if that were the case BSD doesn't have enough together to really even talk about it at this point

So you think the discussion will be usefull after the new AMDGPU driver is released?
My opinion: Then it is far too late :-(

Not after AMDGPU driver is released, after BSD gets their graphics stack modernized regardless of the release status of AMDGPU at that point

And making the porting to the *BSDs easier would be a lot of help too.

Talking won't make porting easier, not right now anyway. Actually helping to build the required infrastructure so that BSD Graphics can have a house so that they can then actually have a basis from which to talk about expansions will.

[drSeehas]

Because it's putting the cart before the horse.

Let me put this in an analogy for you

Imagine you've got one guy who has got a house with all kinds of expansions and neat features we'll call him AMD Linux, then we've got another guy who has the foundation laid but is still working on setting up the framework of the house, we'll call him BSD Graphics. It's not really useful for AMD Linux to talk to BSD Graphics about all the new cool home expansions and systems he's setting up, when BSD Graphics doesn't even have his house finished yet. On the other hand what BSD Graphics could really use is for AMD Linux to come over and help him get his house built.

I see it different:

Once upon a time in the old days of FOSS the developers wanted their software tu run on as much as possible OSs or in your analogy: fit in as much as possible houses. Both, the *BSD and Linux houses, were treated equally and were fully functional, working, usable and livable houses "with all kinds of expansions and neat features".

Then some day the makers for e.g. the windows (ha!) decided to only support the Linux houses.
A window consist among other things of the frame and the glass. The *BSD houses (were forced to) keep the old frames and only one glass maker (nVIDIA) still supports at least one of these old frames in the *BSD houses.

Now another glass maker (AMD) announces the development of a new glass. Wouldn't it be a good idea to develop this new glass in a way, that it will fit also in the old frames of the *BSD houses?
If the glass maker of the new glass cares about the *BSD houses it would visit these houses and look how these old frames are designed so the new glass will fit easily into these old frames.

Yes, I know, the story above is simplified.

...

In short you say the *BSDs should go the Linux way as DragonflyBSD plans already.

[Luke_Wolf]

I see it different:

Once upon a time in the old days of FOSS the developers wanted their software tu run on as much as possible OSs or in your analogy: fit in as much as possible houses. Both, the *BSD and Linux houses, were treated equally and were fully functional, working, usable and livable houses "with all kinds of expansions and neat features".

Then some day the makers for e.g. the windows (ha!) decided to only support the Linux houses.
A window consist among other things of the frame and the glass. The *BSD houses (were forced to) keep the old frames and only one glass maker (nVIDIA) still supports at least one of these old frames in the *BSD houses.

Now another glass maker (AMD) announces the development of a new glass. Wouldn't it be a good idea to develop this new glass in a way, that it will fit also in the old frames of the *BSD houses?
If the glass maker of the new glass cares about the *BSD houses it would visit these houses and look how these old frames are designed so the new glass will fit easily into these old frames.

Yes, I know, the story above is simplified.


In short you say the *BSDs should go the Linux way as DragonflyBSD plans already.

Actually It went more like:
Intel decided that Kernel modesetting as opposed to User modesetting would give them really neat features. AMD said "Cool Bro, Let me in on some of that", and Linus was all "Cool Man dish it up" meanwhile the BSDs were all "But Bros... We like Userspace Modesetting" and so the BSDs decided to sit on the Userspace Modesetting, thinking that it was just going to be a temporary thing, while the rest of the world moved on and decided "We like this KMS thing", until recently where the BSDs finally realized that no, in fact the world would not be going back to UMS anytime soon and so have finally decided to move to KMS, and it's going to take them a while to finish.

Seriously though the fact that the BSDs got left behind is nobody fault but their own, as demonstrated by the fact that between the various BSDs there's around a dozen developers now working on this problem. If they hadn't decided "UMS FTW!" they wouldn't need to be working on catching up now.

Also it's not just me saying it, All 3 XDC Presentations said so, and the unrepresented NetBSD was mentioned as doing the same developments