[opensuse-kernel] Could CONFIG_DRM_AMDGPU_CIK be enabled in the TW builds?
Hello there! I was hoping it would possible to enable CONFIG_DRM_AMDGPU_CIK in the stable kernel builds? This would allow AMD Hawaii owners to use the new "amdgpu" drivers. As it stands, those wanting reasonable 3D performance can't upgrade past kernel 4.4 because the proprietary "fglrx" driver is obsoleted in later versions, leaving "radeon" as the only choice. I have compiled locally with this config setting and the amdgpu driver seems to work pretty well. I don't think this would affect anyone negatively as users would still need to manually disable the "radeon" driver and pass the kernel parameter to enable amdgpu on experimental hardware before the driver would be chosen. Thank you for the consideration! -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 8/13/16 3:15 PM, Jason DeRose wrote:
Hello there!
I was hoping it would possible to enable CONFIG_DRM_AMDGPU_CIK in the stable kernel builds?
This would allow AMD Hawaii owners to use the new "amdgpu" drivers. As it stands, those wanting reasonable 3D performance can't upgrade past kernel 4.4 because the proprietary "fglrx" driver is obsoleted in later versions, leaving "radeon" as the only choice.
I have compiled locally with this config setting and the amdgpu driver seems to work pretty well. I don't think this would affect anyone negatively as users would still need to manually disable the "radeon" driver and pass the kernel parameter to enable amdgpu on experimental hardware before the driver would be chosen.
Thank you for the consideration!
Egbert, Stefan - Do you have an opinion here? I left it disabled because it was marked as experimental (and still is). -Jeff -- Jeff Mahoney SUSE Labs
On Sun, Aug 14, 2016 at 11:35:29PM -0400, Jeff Mahoney wrote:
On 8/13/16 3:15 PM, Jason DeRose wrote:
Hello there!
I was hoping it would possible to enable CONFIG_DRM_AMDGPU_CIK in the stable kernel builds?
This would allow AMD Hawaii owners to use the new "amdgpu" drivers. As it stands, those wanting reasonable 3D performance can't upgrade past kernel 4.4 because the proprietary "fglrx" driver is obsoleted in later versions, leaving "radeon" as the only choice.
I have compiled locally with this config setting and the amdgpu driver seems to work pretty well. I don't think this would affect anyone negatively as users would still need to manually disable the "radeon" driver and pass the kernel parameter to enable amdgpu on experimental hardware before the driver would be chosen.
Thank you for the consideration!
Egbert, Stefan -
Do you have an opinion here? I left it disabled because it was marked as experimental (and still is).
Not exactly, but: 'Sea islands' GPUs (Kaveri, Bonaire, Hawaii, Kabini, mullins) are also supported by radeon driver, so one needs to blacklist that driver on target systems with CI GPUs (and only on these!) in order to switch to amdgpu driver. As long as this remains unknown enabling it would be rather useless. Also once amdgpu support for CIK is considered stable, one needs to disable support in radeon driver. Hope upstream is not going to forget this ... So, if we want to enable it on SUSE, we need to disable it in radeon driver. So this would mean a patch, which may never become upstream ... Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany --------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, Aug 15, 2016, at 05:18 AM, Stefan Dirsch wrote:
On Sun, Aug 14, 2016 at 11:35:29PM -0400, Jeff Mahoney wrote:
On 8/13/16 3:15 PM, Jason DeRose wrote:
Hello there!
I was hoping it would possible to enable CONFIG_DRM_AMDGPU_CIK in the stable kernel builds?
This would allow AMD Hawaii owners to use the new "amdgpu" drivers. As it stands, those wanting reasonable 3D performance can't upgrade past kernel 4.4 because the proprietary "fglrx" driver is obsoleted in later versions, leaving "radeon" as the only choice.
I have compiled locally with this config setting and the amdgpu driver seems to work pretty well. I don't think this would affect anyone negatively as users would still need to manually disable the "radeon" driver and pass the kernel parameter to enable amdgpu on experimental hardware before the driver would be chosen.
Thank you for the consideration!
Egbert, Stefan -
Do you have an opinion here? I left it disabled because it was marked as experimental (and still is).
Not exactly, but: 'Sea islands' GPUs (Kaveri, Bonaire, Hawaii, Kabini, mullins) are also supported by radeon driver, so one needs to blacklist that driver on target systems with CI GPUs (and only on these!) in order to switch to amdgpu driver. As long as this remains unknown enabling it would be rather useless.
Also once amdgpu support for CIK is considered stable, one needs to disable support in radeon driver. Hope upstream is not going to forget this ...
So, if we want to enable it on SUSE, we need to disable it in radeon driver. So this would mean a patch, which may never become upstream ...
Thanks, Stefan
Just to be clear - I wasn't suggesting that radeon be blacklisted for Sea Island yet. But, with CONFIG_DRM_AMDGPU_CIK=y set the user then has the option to blacklist radeon and choose amdgpu instead themselves. I do not think there is a concern that users will not know about it - Any owners of these cards currently who are using fglrx will find that it no longer works once upgrading beyond kernel 4.4, and go searching for an answer (which is the way that I ended up here). There is quite a bit of discussion out there about these cards being essentially orphaned, especially for distros that have already made fixed releases with newer kernel versions. Of course, I don't have complete knowledge of the possible implications by loading this driver for users who never choose to use it, so if you tell me "no, go away" it will be understandable :) Thank you again for your time! -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, Aug 15, 2016 at 12:51:19PM -0400, Jason DeRose wrote:
On Mon, Aug 15, 2016, at 05:18 AM, Stefan Dirsch wrote:
On Sun, Aug 14, 2016 at 11:35:29PM -0400, Jeff Mahoney wrote:
On 8/13/16 3:15 PM, Jason DeRose wrote:
Hello there!
I was hoping it would possible to enable CONFIG_DRM_AMDGPU_CIK in the stable kernel builds?
This would allow AMD Hawaii owners to use the new "amdgpu" drivers. As it stands, those wanting reasonable 3D performance can't upgrade past kernel 4.4 because the proprietary "fglrx" driver is obsoleted in later versions, leaving "radeon" as the only choice.
I have compiled locally with this config setting and the amdgpu driver seems to work pretty well. I don't think this would affect anyone negatively as users would still need to manually disable the "radeon" driver and pass the kernel parameter to enable amdgpu on experimental hardware before the driver would be chosen.
Thank you for the consideration!
Egbert, Stefan -
Do you have an opinion here? I left it disabled because it was marked as experimental (and still is).
Not exactly, but: 'Sea islands' GPUs (Kaveri, Bonaire, Hawaii, Kabini, mullins) are also supported by radeon driver, so one needs to blacklist that driver on target systems with CI GPUs (and only on these!) in order to switch to amdgpu driver. As long as this remains unknown enabling it would be rather useless.
Also once amdgpu support for CIK is considered stable, one needs to disable support in radeon driver. Hope upstream is not going to forget this ...
So, if we want to enable it on SUSE, we need to disable it in radeon driver. So this would mean a patch, which may never become upstream ...
Thanks, Stefan
Just to be clear - I wasn't suggesting that radeon be blacklisted for Sea Island yet. But, with CONFIG_DRM_AMDGPU_CIK=y set the user then has the option to blacklist radeon and choose amdgpu instead themselves.
I'm a bit afraid, that it will be random at the end, which driver will get active, when two drivers are available. This may result in a lot of confusion. I would like to avoid that by removing support in radeon driver in case we decide to support Sea Islands GPUs via amdgpu driver.
I do not think there is a concern that users will not know about it - Any owners of these cards currently who are using fglrx will find that it no longer works once upgrading beyond kernel 4.4, and go searching for an answer (which is the way that I ended up here). There is quite a bit of discussion out there about these cards being essentially orphaned, especially for distros that have already made fixed releases with newer kernel versions.
Hmm. So AMD announced to no longer support Sea Islands GPUs with newer fglrx drivers? I wasn't aware of that, but I haven't seen a new driver since Dec 2015 anyway. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany --------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2016-08-17 12:31, Stefan Dirsch wrote:
On Mon, Aug 15, 2016 at 12:51:19PM -0400, Jason DeRose wrote:
Just to be clear - I wasn't suggesting that radeon be blacklisted for Sea Island yet. But, with CONFIG_DRM_AMDGPU_CIK=y set the user then has the option to blacklist radeon and choose amdgpu instead themselves.
I'm a bit afraid, that it will be random at the end, which driver will get active, when two drivers are available. This may result in a lot of confusion. I would like to avoid that by removing support in radeon driver in case we decide to support Sea Islands GPUs via amdgpu driver.
Radeon should load first, since it's listed before amdgpu in the Makefile and kmod respects that order: $ grep -n -e amdgpu -e radeon /lib/modules/`uname -r`/modules.order 361:kernel/drivers/gpu/drm/radeon/radeon.ko 362:kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko So it *should* be safe to have both modules support a range of devices. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Aug 17, 2016 at 04:58:38PM +0200, Michal Marek wrote:
On 2016-08-17 12:31, Stefan Dirsch wrote:
On Mon, Aug 15, 2016 at 12:51:19PM -0400, Jason DeRose wrote:
Just to be clear - I wasn't suggesting that radeon be blacklisted for Sea Island yet. But, with CONFIG_DRM_AMDGPU_CIK=y set the user then has the option to blacklist radeon and choose amdgpu instead themselves.
I'm a bit afraid, that it will be random at the end, which driver will get active, when two drivers are available. This may result in a lot of confusion. I would like to avoid that by removing support in radeon driver in case we decide to support Sea Islands GPUs via amdgpu driver.
Radeon should load first, since it's listed before amdgpu in the Makefile and kmod respects that order: $ grep -n -e amdgpu -e radeon /lib/modules/`uname -r`/modules.order 361:kernel/drivers/gpu/drm/radeon/radeon.ko 362:kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
So it *should* be safe to have both modules support a range of devices.
Ok. In that case feel free to enable support for Sea Islands GPUs in amdgpu driver. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany --------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, Aug 18, 2016, at 09:20 AM, Stefan Dirsch wrote:
On Wed, Aug 17, 2016 at 04:58:38PM +0200, Michal Marek wrote:
On 2016-08-17 12:31, Stefan Dirsch wrote:
On Mon, Aug 15, 2016 at 12:51:19PM -0400, Jason DeRose wrote:
Just to be clear - I wasn't suggesting that radeon be blacklisted for Sea Island yet. But, with CONFIG_DRM_AMDGPU_CIK=y set the user then has the option to blacklist radeon and choose amdgpu instead themselves.
I'm a bit afraid, that it will be random at the end, which driver will get active, when two drivers are available. This may result in a lot of confusion. I would like to avoid that by removing support in radeon driver in case we decide to support Sea Islands GPUs via amdgpu driver.
Radeon should load first, since it's listed before amdgpu in the Makefile and kmod respects that order: $ grep -n -e amdgpu -e radeon /lib/modules/`uname -r`/modules.order 361:kernel/drivers/gpu/drm/radeon/radeon.ko 362:kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
So it *should* be safe to have both modules support a range of devices.
Ok. In that case feel free to enable support for Sea Islands GPUs in amdgpu driver.
Thanks, Stefan
Great! I wasn't sure the next step, but I went ahead and created a Pull Request on github. I'm not sure if master is the correct branch. Let me know if there is something else I should do. Thanks again very much for everyone's time. - Jason -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 8/20/16 1:20 AM, Jason DeRose wrote:
On Thu, Aug 18, 2016, at 09:20 AM, Stefan Dirsch wrote:
On Wed, Aug 17, 2016 at 04:58:38PM +0200, Michal Marek wrote:
On 2016-08-17 12:31, Stefan Dirsch wrote:
On Mon, Aug 15, 2016 at 12:51:19PM -0400, Jason DeRose wrote:
Just to be clear - I wasn't suggesting that radeon be blacklisted for Sea Island yet. But, with CONFIG_DRM_AMDGPU_CIK=y set the user then has the option to blacklist radeon and choose amdgpu instead themselves.
I'm a bit afraid, that it will be random at the end, which driver will get active, when two drivers are available. This may result in a lot of confusion. I would like to avoid that by removing support in radeon driver in case we decide to support Sea Islands GPUs via amdgpu driver.
Radeon should load first, since it's listed before amdgpu in the Makefile and kmod respects that order: $ grep -n -e amdgpu -e radeon /lib/modules/`uname -r`/modules.order 361:kernel/drivers/gpu/drm/radeon/radeon.ko 362:kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
So it *should* be safe to have both modules support a range of devices.
Ok. In that case feel free to enable support for Sea Islands GPUs in amdgpu driver.
Thanks, Stefan
Great! I wasn't sure the next step, but I went ahead and created a Pull Request on github. I'm not sure if master is the correct branch. Let me know if there is something else I should do.
Thanks, Jason. I've pulled your branch and pushed to master. The correct branch for Tumbleweed is "stable." This change will eventually make it to the stable branch but it'll only happen automatically after we reach v4.8 upstream. BTW, AFAIK this is the first pull from the github repo. The github repo is actually a clone of our internal repository so we can't use github pull requests directly, but since github is just git behind the scenes, it was super easy to just pull directly from your branch. This might be a vector we can use to easily accept changes from community members. Our internal repo won't allow commits from external community members to land without a merge commit from one of the kernel maintainers, so it's not unsafe. Thanks to Michal Marek for making that work. -Jeff -- Jeff Mahoney SUSE Labs
Thanks all for this nice effort, and new way of collaboration. It will then (perhaps) could open the way to have amdgpu-pro also builded and package in a near future. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun 21 Aug 2016 10:42:00 AM CDT, Jeff Mahoney wrote:
On 8/20/16 1:20 AM, Jason DeRose wrote:
On Thu, Aug 18, 2016, at 09:20 AM, Stefan Dirsch wrote:
On Wed, Aug 17, 2016 at 04:58:38PM +0200, Michal Marek wrote:
On 2016-08-17 12:31, Stefan Dirsch wrote:
On Mon, Aug 15, 2016 at 12:51:19PM -0400, Jason DeRose wrote:
Just to be clear - I wasn't suggesting that radeon be blacklisted for Sea Island yet. But, with CONFIG_DRM_AMDGPU_CIK=y set the user then has the option to blacklist radeon and choose amdgpu instead themselves.
I'm a bit afraid, that it will be random at the end, which driver will get active, when two drivers are available. This may result in a lot of confusion. I would like to avoid that by removing support in radeon driver in case we decide to support Sea Islands GPUs via amdgpu driver.
Radeon should load first, since it's listed before amdgpu in the Makefile and kmod respects that order: $ grep -n -e amdgpu -e radeon /lib/modules/`uname -r`/modules.order 361:kernel/drivers/gpu/drm/radeon/radeon.ko 362:kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
So it *should* be safe to have both modules support a range of devices.
Ok. In that case feel free to enable support for Sea Islands GPUs in amdgpu driver.
Thanks, Stefan
Great! I wasn't sure the next step, but I went ahead and created a Pull Request on github. I'm not sure if master is the correct branch. Let me know if there is something else I should do.
Thanks, Jason. I've pulled your branch and pushed to master. The correct branch for Tumbleweed is "stable." This change will eventually make it to the stable branch but it'll only happen automatically after we reach v4.8 upstream.
BTW, AFAIK this is the first pull from the github repo. The github repo is actually a clone of our internal repository so we can't use github pull requests directly, but since github is just git behind the scenes, it was super easy to just pull directly from your branch. This might be a vector we can use to easily accept changes from community members. Our internal repo won't allow commits from external community members to land without a merge commit from one of the kernel maintainers, so it's not unsafe. Thanks to Michal Marek for making that work.
-Jeff
Hi I have a Mullins [Radeon R4/R5 Graphics] [1002:9851], seems it got missed? http://kernel.opensuse.org/cgit/kernel/commit/?h=stable&id=ac9a015a9094695e49136425b4c094e04283ed0f Once added that and recompiled the module all was good, aside from mullins support seems to be missing from xf86-video-amdgpu which I had to patch in and re-generate the pci id info? -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default up 5 days 9:05, 7 users, load average: 0.49, 0.27, 0.18 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2016-08-21 16:42, Jeff Mahoney wrote:
BTW, AFAIK this is the first pull from the github repo. The github repo is actually a clone of our internal repository so we can't use github pull requests directly, but since github is just git behind the scenes, it was super easy to just pull directly from your branch.
Did you actually get a github notification about the pull request? I noticed a notification in my mailbox this morning and wanted to forward it to you. I guess you had learned from Jason's email meanwhile.
This might be a vector we can use to easily accept changes from community members.
Right, but notifications need to be handled somehow. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 22 Aug 2016 12:37:35 +0200, Michal Marek wrote:
On 2016-08-21 16:42, Jeff Mahoney wrote:
BTW, AFAIK this is the first pull from the github repo. The github repo is actually a clone of our internal repository so we can't use github pull requests directly, but since github is just git behind the scenes, it was super easy to just pull directly from your branch.
Did you actually get a github notification about the pull request? I noticed a notification in my mailbox this morning and wanted to forward it to you. I guess you had learned from Jason's email meanwhile.
This might be a vector we can use to easily accept changes from community members.
Right, but notifications need to be handled somehow.
Currently the build-test is missing when done through github. So basically the branch maintainer should pull the requested github branch into their for-next branch? Then it'll get build-tested and automatically merged into the target branch once after it passes. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2016-08-22 13:26, Takashi Iwai wrote:
On Mon, 22 Aug 2016 12:37:35 +0200, Michal Marek wrote:
On 2016-08-21 16:42, Jeff Mahoney wrote:
BTW, AFAIK this is the first pull from the github repo. The github repo is actually a clone of our internal repository so we can't use github pull requests directly, but since github is just git behind the scenes, it was super easy to just pull directly from your branch.
Did you actually get a github notification about the pull request? I noticed a notification in my mailbox this morning and wanted to forward it to you. I guess you had learned from Jason's email meanwhile.
This might be a vector we can use to easily accept changes from community members.
Right, but notifications need to be handled somehow.
Currently the build-test is missing when done through github. So basically the branch maintainer should pull the requested github branch into their for-next branch? Then it'll get build-tested and automatically merged into the target branch once after it passes.
Yes, good point. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 8/22/16 7:36 AM, Michal Marek wrote:
On 2016-08-22 13:26, Takashi Iwai wrote:
On Mon, 22 Aug 2016 12:37:35 +0200, Michal Marek wrote:
On 2016-08-21 16:42, Jeff Mahoney wrote:
BTW, AFAIK this is the first pull from the github repo. The github repo is actually a clone of our internal repository so we can't use github pull requests directly, but since github is just git behind the scenes, it was super easy to just pull directly from your branch.
Did you actually get a github notification about the pull request? I noticed a notification in my mailbox this morning and wanted to forward it to you. I guess you had learned from Jason's email meanwhile.
This might be a vector we can use to easily accept changes from community members.
Right, but notifications need to be handled somehow.
Currently the build-test is missing when done through github. So basically the branch maintainer should pull the requested github branch into their for-next branch? Then it'll get build-tested and automatically merged into the target branch once after it passes.
Yes, good point.
Yep, but I thought that was the process anyway. If a maintainer pushes via their own for-next branch, it's merged automatically after build tests. I've been pushing /everything/ through my for-next branch as a result. -Jeff -- Jeff Mahoney SUSE Labs
participants (7)
-
Bruno Friedmann -
Jason DeRose -
Jeff Mahoney -
Malcolm -
Michal Marek -
Stefan Dirsch -
Takashi Iwai