Vega 10 Huge Page Support, Lower CS Overhead For AMDGPU In Linux 4.14

[Zan Lynx]

Linux supports transparent huge pages so you will end up with a mix depending on allocations and memory fragmentation.

Yes, although many distributions like Fedora disable automatic huge pages. On those you only get huge pages when you ask for them with mmap and MAP_HUGETLB or madvise with MADV_HUGEPAGE.

I would think that anyone doing graphics or GPU compute would explicitly request huge page memory. Or the library they are using would. You wouldn't want to rely on transparent huge pages to maybe, possibly figure it out.

[bridgman]

Edit: Well, bested by agd5f !

Get used to it

[dwagner]

Thanks to agd5f and franglais125 for your explanations!

The commands

git fetch
git reset --hard origin/amd-staging-drm-next

did it for me - seems that if you don't tell git "to where to reset", it "resets" to some HEAD that it cannot merge with remote changes.

[Jedibeeftrix]

If you want to run DC on current drm-next, you can use this branch:
https://cgit.freedesktop.org/~agd5f/...aging-drm-next
For packaged releases, we support enterprise distros via dkms so they will be supported.

Not quite what I was asking...

Neither Suse Leap 15 or Ubuntu 18.04 are enterprise releases.
And while I know AMD provide a Pro driver for SLES/SLED, and Leap is derived from SLES/SLED, that driver does not work 'out-of-the-box' on Leap 42.x.

What does DKMS do for Vega users of Leap15 / Ubuntu 18.04 who are looking wistfully at the finally DC'ed 4.15 kernel from their own lowly position on 4.14?

Many thanks for taking the time to reply before.

[agd5f]

Not quite what I was asking...

Neither Suse Leap 15 or Ubuntu 18.04 are enterprise releases.
And while I know AMD provide a Pro driver for SLES/SLED, and Leap is derived from SLES/SLED, that driver does not work 'out-of-the-box' on Leap 42.x.

What does DKMS do for Vega users of Leap15 / Ubuntu 18.04 who are looking wistfully at the finally DC'ed 4.15 kernel from their own lowly position on 4.14?

Many thanks for taking the time to reply before.

amd-staging-drm-next is based on drm-next which is what will ultimately go upstream for 4.14, so you can use that branch if you want something 4.14-ish.

[pal666]

That is certainly not what I would consider a better way.

your consideration is flawed

[JordanL]

But.... do you (bridgman?) think that there is enough preparatory work happening for 4.14 that it is feasible that a full Vega open-source stack might be backported to 4.14, even if it initially arrives only with 4.15?

Are you asking with regards to the technical feasibility? We develop against drm-next, so certainly at some point the DC code will be working on the 4.14 kernel. Assuming no drastic changes in DRM interfaces from 4.14 to whatever kernel DC is accepted upstream, it shouldn't be difficult to get it working on older kernels, at least 4.12 and newer.

[Jedibeeftrix]

Are you asking with regards to the technical feasibility? We develop against drm-next, so certainly at some point the DC code will be working on the 4.14 kernel. Assuming no drastic changes in DRM interfaces from 4.14 to whatever kernel DC is accepted upstream, it shouldn't be difficult to get it working on older kernels, at least 4.12 and newer.

Yes, I suppose feasability is the question, insomuch as I am a suse Leap user who hopes to be using a Vega card with an opensource driver stack in the 'near' future.
Leap 15.x will use 4.14, and will stay on that throughout the cycle of of SLES 15.
So I want to know if the dream is a bust for the next few years on Leap...

[bridgman]

The big question IMO is not whether backporting will be feasible (it will be) but whether that kind of backporting would even be welcome in Leap.

My understanding of Leap is that from a graphics POV it is aimed more at systems which do not require ongoing hardware enablement and/or where hardware enablement can be handled by "proprietary drivers" (aka out-of-tree drivers rather than backported drivers). Nothing wrong with that - it's the normal enterprise distro compromise - but it argues against expecting a backport to happen unless it was prior to the first release.

The "proprietary" part isn't a problem because we will be offering open source drivers that can be installed like proprietary drivers, but my understanding is that there are no plans to aggressively pick up new driver code in the Leap kernels even if backporting were fairly straightforward.

Hopefully I am misunderstanding that.