AMDGPU Feature Updates Submitted For Linux 4.18, Bringing Vega M & More

[Jumbotron]

There's no really profound reason - just that new HW capabilities arrive in big slugs but we can't ramp the SW teams up and down to match, so while open source driver development was catching up with new HW projects the "important" features generally got supported at launch and the remaining features got supported later.

Now that we have caught up with new HW introductions (remember that we were ~5 generations behind when we restarted open source driver work) we have been beginning work on driver support for new product support earlier each cycle, so you should see less of this in the future.

As always, bridgman for the win. Not surprising to read this. I think we all would like new feature sets to be supported Day 1 or near about. But, on the flip side, it's also a great thing that open source allows aging platforms to get a new breadth of life and vitality ( look at the news of Kaveri's performance boost from the upcoming Mesa 18.2.x. And the fact, as bridgman stated, that this gap is narrowing for the future is great news. Thanks again, bridgman, for the clarification !

[bridgman]

There's no really profound reason - just that new HW capabilities arrive in big slugs but we can't ramp the SW teams up and down to match, so while open source driver development was catching up with new HW projects the "important" features generally got supported at launch and the remaining features got supported later.

Now that we have caught up with new HW introductions (remember that we were ~5 generations behind when we restarted open source driver work) we have been beginning work on driver support for new product support earlier each cycle, so you should see less of this in the future.

[Jumbotron]

"Scatter/Gather Display" All AMD GPUs support scatter/gather DMA. Display hardware has very strict latency requirements and going through page tables adds latency. All dGPUs and until Carrizo, all APUs required that displays be in contiguous memory pools (vram on dGPUs and UMA carve out on APUs) that do not go through page tables. With Carrizo and newer APUs, display buffers don't have to be in carve out. It gives more flexibility for placement of display buffers on APUs.

Thanks agd5f ! I had already intuited this beforehand, although your more technical explanation helped. I wasn't questioning support by the AMD APU's themselves but the Linux Kernel support. Why is the kernel just now getting to supporting something that 2-3+ year old processors have been capable of from the start? Is it something that hard to code for? Seriously asking...not being snarky.

[agd5f]

While I appreciate the continued support of the Carrizo family with the addition now of scatter gather DMA (my Bristol Ridge laptop and desktop should also benefit) I do wonder why this feature is just now coming into play. The whole purpose of the Fusion/APU/HSA model was to lessen if not eliminate copies across the bus to and from both CPU memory and GPU memory. This is even less a factor with APUs since not only is the GPU embedded on-die both the CPU and GPU share system memory. Why wasn't this Day 1 support, especially for Carrizo, particularly after Kaveri? Or am I missing something,which is probably the case.

"Scatter/Gather Display" All AMD GPUs support scatter/gather DMA. Display hardware has very strict latency requirements and going through page tables adds latency. All dGPUs and until Carrizo, all APUs required that displays be in contiguous memory pools (vram on dGPUs and UMA carve out on APUs) that do not go through page tables. With Carrizo and newer APUs, display buffers don't have to be in carve out. It gives more flexibility for placement of display buffers on APUs.

[Jumbotron]

While I appreciate the continued support of the Carrizo family with the addition now of scatter gather DMA (my Bristol Ridge laptop and desktop should also benefit) I do wonder why this feature is just now coming into play. The whole purpose of the Fusion/APU/HSA model was to lessen if not eliminate copies across the bus to and from both CPU memory and GPU memory. This is even less a factor with APUs since not only is the GPU embedded on-die both the CPU and GPU share system memory. Why wasn't this Day 1 support, especially for Carrizo, particularly after Kaveri? Or am I missing something,which is probably the case.

[Brisse]

I haven't really noticed if freesync is now working with the recent kernels.
Since I am using a R9 290 I can't test it because it is not useable by default until 4.17

If it is working, how much can you expect from it? Is it working just how you would expect it to work?
Are there any differences to freesync with windows?

It won't be working until there are user-space implementations. Just having the right kernel isn't enough, so there will be quite some time until we can start enjoying Freesync yet.

[Morbis55]

I haven't really noticed if freesync is now working with the recent kernels.
Since I am using a R9 290 I can't test it because it is not useable by default until 4.17

If it is working, how much can you expect from it? Is it working just how you would expect it to work?
Are there any differences to freesync with windows?

[blae]

Where's the link to the pull request?

[phoronix]

Phoronix: AMDGPU Feature Updates Submitted For Linux 4.18, Bringing Vega M & More

Alex Deucher of AMD today submitted the initial batch of Radeon/AMDGPU DRM driver feature updates to DRM-Next that in turn are slated to land in the Linux 4.18 merge window in June. There's a fair amount of notable feature work this round for Radeon Linux users...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-AMDGPU-Features-1