AMD's New Open-Source "AMDGPU" Linux Driver Supports The R9 285 Tonga

[Creak]

I can run ANY game with my old 7770 and latest Mesa/llvm/kernel without issues. Performance is obviously lower than under Windows, but not that much lower anymore. For example TF2 runs at almost same speed, 70+ in 32 player scenarios and toping at almost 300 if there are no players on the server. On the other hand Witcher 2 with same settings runs at around 30fps under Linux and 60+ (stable 60 with vsync) under Windows, but that's developers fault actually.

To be fair I have some slow frame rates with Civ 5...

[schmidtbag]

@Slartifartblast
I appreciate how much nvidia has given linux, and unlike a lot of people here I don't really give a crap if the drivers are open source or not. However, nvidia has had pretty decent drivers for at least 10 years now, while AMD has just started picking up the pieces roughly 2 years ago. However, not only are they picking up these pieces but they're trying to comply with open source standards, which will help create a much more integrated and solid experience. I'm highly impressed and happy with their progress so far. I think helping fund AMD is the only way to make sure this progress continues.

@whitecat
Yes, I remember hearing how there's nothing magical about crossfire (I believe it was Alex who said it) but I think it's really only as simple as that in principle, otherwise, multi-GPU would've been implemented several years ago. Maybe not for AMD, but just in general. There are a few small things here and there that can add to complication, such as:
* Utilizing the hardware bridges existed to help stabilize performance
* The 2nd GPU's resources (including it's display ports) would be inaccessible, assuming it works anything like catalyst
* Knowing when to use different crossfire modes such as 1x1 or AFR, or knowing when to disable it entirely

When it comes to using single GPUs, the performance of the open source drivers is fantastic and in some cases better than Catalyst on windows. But for me personally I have about 4 games that I could play at full detail or near full if I had my 2nd GPU working.

[bridgman]

I can't help thinking it would be cheaper for us to send schmidtbag a faster card, take his 5750s away, and forget about Crossfire

[schmidtbag]

I can't help thinking it would be cheaper for us to send schmidtbag a faster card, take his 5750s away, and forget about Crossfire

I can wait, but I'd just like to know if it will ever happen and if so, a rough estimate as to when it will be worked on. If there's a strong chance it will not happen within the next 2 years I'll probably never bring it up again. I just never got a direct "no/yes & when" answer; I only a "not yet and here's why", which I appreciate but leaves me hanging. So that being said, I bring it up as often as I do because I'm hoping to get some news that may not have been reported yet.

So bridgman, to be more direct and put an end to my persistence - will it happen for pre-amdgpu drivers and if so, is there a rough estimate when it will be in development?

[bridgman]

So bridgman, to be more direct and put an end to my persistence - will it happen for pre-amdgpu drivers and if so, is there a rough estimate when it will be in development?

The hard work for multi-GPU 3D rendering is almost completely HW-independent so I think we were kinda hoping someone else would do it as a mostly-cross-vendor solution. It's also almost entirely userspace work so independent of the radeon/amdgpu transition. I think your question is more r600/radeonsi rather than radeon/amdgpu.

We would need to help with the HW bits behind the crossfire cables (that would need to go in the kernel drivers AFAIK) but that is really a last-stage optimization and not gating in any way.

[dungeon]

The hard work for multi-GPU 3D rendering is almost completely HW-independent so I think we were kinda hoping someone else would do it as a mostly-cross-vendor solution.

Sounds perfect to be part of GSoC ideas http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas/

[schmidtbag]

The hard work for multi-GPU 3D rendering is almost completely HW-independent so I think we were kinda hoping someone else would do it as a mostly-cross-vendor solution. It's also almost entirely userspace work so independent of the radeon/amdgpu transition. I think your question is more r600/radeonsi rather than radeon/amdgpu.

Ah ok, that makes sense, but yeah, the question is more about r600/radeonsi. I had a feeling it was mostly HW-independent but considering that not all GPUs can be crossfired, I figured there was some other hardware restriction.
I'm guessing this means you and your team won't be working on CF unless you've basically run out of other major things to do, which I know is several years away.

We would need to help with the HW bits behind the crossfire cables (that would need to go in the kernel drivers AFAIK) but that is really a last-stage optimization and not gating in any way.

I figured that was the case. I'm aware the bridges aren't even a requirement, and I wouldn't really be all that upset if support for them never came up. With ultra-fast PCIe lanes and frame-pacing/AFR, it seems the hardware bridges have been obsoleted entirely (hence them not existing on newer hardware). I think the bridges were really only necessary back when the GPUs were processing the same frames simultaneously and had a need to synchronize.

Anyway, thanks for the answer. I'll see if I can just use my 2nd GPU for openCL related tasks, or maybe to use as a player2 for games that don't support split-screen. I'll stop pestering about it now haha.


@dungeon
I agree, that would be a great idea.

[bridgman]

I'm guessing this means you and your team won't be working on CF unless you've basically run out of other major things to do, which I know is several years away.

... or someone gets bored with working on "must have" stuff, which is how many of the interesting improvements actually happen

[schmidtbag]

... or someone gets bored with working on "must have" stuff, which is how many of the interesting improvements actually happen

Just a guess, but is this where Marek usually comes in? At least based on phoronix news, I noticed half the stuff he releases are interesting and "obscure", but useful and not always required/mandatory. Considering how much contribution he's done before he was an AMD employee, I'm guessing he gets bored very easily and is full of good ideas.

[agd5f]

In the past radeon was the only kernel-driver.
Wouldn't it make more sense to merge radeon and amdgpu for easy maintainability ?
Or would the refactor not be worth the various changes you'd have to twice in the future with the separate codebase?

It wouldn't really help that much. Updating radeon is getting a bit unweildly. I think it might be the largest driver in the kernel. It accomodates ~15 years of asics. A lot has changed in those 15 years and we really want to restructure the driver to better handle modern requirements without worrying about regressing old hardware. There's never really a good time to split a driver (there's always some common bits that carry over across generations), so this seems like as good a time as any.