Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On 02/04/2014 12:53 PM, Ben Skeggs wrote: On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot wrote: Hello everyone, Hey Alex, The series looks pretty good to me. I'll reply to the relevant patches with any minor nit-picks on top of what's already been said by others. Thanks for the review and the welcome. The first part (infrastructure changes to support platform devices) has not really been commented yet. If this means it is already in acceptable shape, I propose to re-submit it separately so it can be merged ahead of the rest. Let me know if you would like us to generalize the use of the bus abstraction functions throughout the driver. For the actual GK20A support, what worries me the most is the memory model, and my very incomplete understanding of how Nouveau manages memory doesn't help here. I hope to get some more feedback about it and see if we can fit somewhere before attempting broader changes. Thanks! Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On 02/04/2014 12:53 PM, Ben Skeggs wrote: On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot acour...@nvidia.com wrote: Hello everyone, Hey Alex, The series looks pretty good to me. I'll reply to the relevant patches with any minor nit-picks on top of what's already been said by others. Thanks for the review and the welcome. The first part (infrastructure changes to support platform devices) has not really been commented yet. If this means it is already in acceptable shape, I propose to re-submit it separately so it can be merged ahead of the rest. Let me know if you would like us to generalize the use of the bus abstraction functions throughout the driver. For the actual GK20A support, what worries me the most is the memory model, and my very incomplete understanding of how Nouveau manages memory doesn't help here. I hope to get some more feedback about it and see if we can fit somewhere before attempting broader changes. Thanks! Alex. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot wrote: > Hello everyone, Hey Alex, The series looks pretty good to me. I'll reply to the relevant patches with any minor nit-picks on top of what's already been said by others. Thank you, and welcome to Nouveau :) Ben. > > GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The > following > patches perform architectural changes to Nouveau that are necessary to support > non-PCI GPUs and add initial support for GK20A. Although the support is still > very basic and more user-space changes will be needed to make the full > graphics > stack run on top of it, we were able to successfully open channels and run > simple pushbuffers with libdrm (more testing including rendering is in > progress > as we get more familiar with Nouveau's user-space interface). > > This work should be considered as a RFC and a proof-of-concept for driving > future Tegra GPUs with Nouveau. Some design choices need to be discussed and > quite a few inelegant shortcuts were purposely taken to minimize the size of > this first set. Or said otherwise, apart from the changes that add support for > non-PCI GPUs, remarkably little code needs to be added to get GK20A to a point > where it is actually running. This is very encouraging, and it will be > interesting to keep improving this support and see where this gets us. > > The first part of this series (patches 01/09) adds support for platform > devices > to Nouveau. Nouveau currently only supports PCI devices, and GK20A uses the > platform bus and Device Tree. So the first step towards GK20A support is to > abstract the PCI functions used by Nouveau (mainly resources range querying > and > page mapping functions) and add platform device probing functions. For most of > the existing chips, platform device support does not make any sense, so only > the > subdev and engine drivers actually used by GK20A were updated to use these > abstractions. If, for consistency reasons, it is deemed preferable to use them > everywhere in the driver, we will do it in the next revision of this series. > > This part can be considered independently from the actual GK20A support, and I > believe it would make sense to discuss what needs to be improved and drive it > to > merge separately, as the remainder of the series will likely require more > work. > > The second part (10/14) updates existing subdev/engine drivers to support > GK20A, > and adds a very simple memory driver that simulates dedicated video memory by > allocating a large system memory chunk at boot time. This is clearly > sub-optimal > and should not be merged, but allowed us to quickly bring GK20A up with > Nouveau. > Other drivers changes are fairly small, and are here to handle the difference > in > number of engines and units compared to desktop Kepler as well as to perform a > few things usually done by the video BIOS (which Tegra does not feature). > > Finally, support for probing GK20A is added in the last 2 patches. It should > be > noted that contrary to what Nouveau currently expects, GK20A does not embed > any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured out how to turn GK20A's > instantiation > of Nouveau into a render-node only driver without breaking support for > existing > desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which > we > should try to get rid of. > > I guess my email address might surprise some of you, so let me anticipate some > questions you might have. :P Yes, this work is endorsed by NVIDIA. Several > other > NVIDIAns (CC'd), including core GPU experts, have provided significant > technical > guidance and will continue their involvement. Special thanks go to Terje > Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding > (at FOSDEM this weekend) for help with debugging and user-space testing. > > Let me also stress that although very exciting, this effort is still > experimental, so I would like to make sure that nobody makes excessive > expectations based on these few patches. The scope of this work is strictly > limited to Tegra (although given the similarities desktop GPU support will > certainly benefit from it indirectly), and we do not have any plan to work on > user-space support. So do not uninstall that proprietary driver just yet. ;) > > With this being clarified, we are looking forward to getting your feedback and > working with you guys to bring and improve Tegra K1 support into Nouveau! :) > > Alexandre Courbot (16): > drm/nouveau: handle -EACCES runtime PM return code > drm/nouveau: basic support for platform devices > drm/nouveau: add platform device probing function > drm/nouveau/fifo: support platform devices > drm/nouveau/bar: support platform devices > drm/nouveau/bar: only ioremap BAR3 if
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On 02/03/2014 08:25 PM, David Herrmann wrote: Hi [..snip..] Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A's instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we should try to get rid of. You cannot get rid of cardX currently. It is implied by DRIVER_MODESET and that flag should actually be called NOT_A_LEGACY_DRIVER. So you cannot remove it. I did try to replace DRIVER_MODESET by an inverted DRIVER_LEGACY flag some time ago, but I thought it's not worth it. Anyhow, you can easily add a new flag to make drm_dev_register()/drm_dev_alloc() not create the drm_minor for DRM_MINOR_LEGACY, which would prevent the card0 node from showing up. But people started using the cardX interface as base interface so mesa might not be able to open render-nodes if the related card-node is not available (which is a bug in their code, so no reason to support that by not adding stand-alone render-nodes). Actually my mention of /dev/dri/cardX was misleading. I was rather thinking about getting rid of the DRIVER_MODESET flag to correctly expose what the card provides, not only to user-space, but to DRM itself. The legacy node is ok as long as DRM itself correctly knows what the driver can and cannot do and fails gracefully if the user tries to set a mode. DRIVER_MODESET is statically set in nouveau_drm.c, and the reason why I cannot get rid of it is because the driver (and its features) is registered with drm_pci_init() before the card is probed and its actual features known. For platform devices, you could check the card features before registering it with drm_platform_init(), but then you have the issue that the driver instance is referenced by every probed card, and thus you cannot have cards with different capabilities. So it seems like handling this would require the driver_features to move from drm_driver to drm_device, but that's quite a core change. As pointed out by you and Daniel, we can certainly live with the control and legacy nodes. Nonetheless I'd be curious to know how (and if) this case can be correctly handled. Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Sat, Feb 1, 2014 at 4:16 AM, Alexandre Courbot wrote: > Finally, support for probing GK20A is added in the last 2 patches. It should > be > noted that contrary to what Nouveau currently expects, GK20A does not embed > any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured out how to turn GK20A's > instantiation > of Nouveau into a render-node only driver without breaking support for > existing > desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which > we > should try to get rid of. tbh I wouldn't care about the lagecy dev nodes - we have hw platforms on intel with similar setup (i.e. just rendering and no outputs) and we don't bother to hide the legacy node. kms ioctl will still be there, but as long as no encoder/connector/crtc/... gets set up by the driver the only thing userspace can do is create framebuffers. Which is rather harmless ;-) And having legacy dev nodes around helps on older userspace (e.g. X/Prime with dri2 which uses flink). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
Hi [..snip..] > Finally, support for probing GK20A is added in the last 2 patches. It should > be > noted that contrary to what Nouveau currently expects, GK20A does not embed > any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured out how to turn GK20A's > instantiation > of Nouveau into a render-node only driver without breaking support for > existing > desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which > we > should try to get rid of. You cannot get rid of cardX currently. It is implied by DRIVER_MODESET and that flag should actually be called NOT_A_LEGACY_DRIVER. So you cannot remove it. I did try to replace DRIVER_MODESET by an inverted DRIVER_LEGACY flag some time ago, but I thought it's not worth it. Anyhow, you can easily add a new flag to make drm_dev_register()/drm_dev_alloc() not create the drm_minor for DRM_MINOR_LEGACY, which would prevent the card0 node from showing up. But people started using the cardX interface as base interface so mesa might not be able to open render-nodes if the related card-node is not available (which is a bug in their code, so no reason to support that by not adding stand-alone render-nodes). Long story short: If you want to do it properly, just add a flag to DRM core that prevents DRM_MINOR_LEGACY from showing up. If you just want it to work, simply keep a dummy card0. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
Hi [..snip..] Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A's instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we should try to get rid of. You cannot get rid of cardX currently. It is implied by DRIVER_MODESET and that flag should actually be called NOT_A_LEGACY_DRIVER. So you cannot remove it. I did try to replace DRIVER_MODESET by an inverted DRIVER_LEGACY flag some time ago, but I thought it's not worth it. Anyhow, you can easily add a new flag to make drm_dev_register()/drm_dev_alloc() not create the drm_minor for DRM_MINOR_LEGACY, which would prevent the card0 node from showing up. But people started using the cardX interface as base interface so mesa might not be able to open render-nodes if the related card-node is not available (which is a bug in their code, so no reason to support that by not adding stand-alone render-nodes). Long story short: If you want to do it properly, just add a flag to DRM core that prevents DRM_MINOR_LEGACY from showing up. If you just want it to work, simply keep a dummy card0. Thanks David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Sat, Feb 1, 2014 at 4:16 AM, Alexandre Courbot acour...@nvidia.com wrote: Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A's instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we should try to get rid of. tbh I wouldn't care about the lagecy dev nodes - we have hw platforms on intel with similar setup (i.e. just rendering and no outputs) and we don't bother to hide the legacy node. kms ioctl will still be there, but as long as no encoder/connector/crtc/... gets set up by the driver the only thing userspace can do is create framebuffers. Which is rather harmless ;-) And having legacy dev nodes around helps on older userspace (e.g. X/Prime with dri2 which uses flink). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On 02/03/2014 08:25 PM, David Herrmann wrote: Hi [..snip..] Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A's instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we should try to get rid of. You cannot get rid of cardX currently. It is implied by DRIVER_MODESET and that flag should actually be called NOT_A_LEGACY_DRIVER. So you cannot remove it. I did try to replace DRIVER_MODESET by an inverted DRIVER_LEGACY flag some time ago, but I thought it's not worth it. Anyhow, you can easily add a new flag to make drm_dev_register()/drm_dev_alloc() not create the drm_minor for DRM_MINOR_LEGACY, which would prevent the card0 node from showing up. But people started using the cardX interface as base interface so mesa might not be able to open render-nodes if the related card-node is not available (which is a bug in their code, so no reason to support that by not adding stand-alone render-nodes). Actually my mention of /dev/dri/cardX was misleading. I was rather thinking about getting rid of the DRIVER_MODESET flag to correctly expose what the card provides, not only to user-space, but to DRM itself. The legacy node is ok as long as DRM itself correctly knows what the driver can and cannot do and fails gracefully if the user tries to set a mode. DRIVER_MODESET is statically set in nouveau_drm.c, and the reason why I cannot get rid of it is because the driver (and its features) is registered with drm_pci_init() before the card is probed and its actual features known. For platform devices, you could check the card features before registering it with drm_platform_init(), but then you have the issue that the driver instance is referenced by every probed card, and thus you cannot have cards with different capabilities. So it seems like handling this would require the driver_features to move from drm_driver to drm_device, but that's quite a core change. As pointed out by you and Daniel, we can certainly live with the control and legacy nodes. Nonetheless I'd be curious to know how (and if) this case can be correctly handled. Alex. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot acour...@nvidia.com wrote: Hello everyone, Hey Alex, The series looks pretty good to me. I'll reply to the relevant patches with any minor nit-picks on top of what's already been said by others. Thank you, and welcome to Nouveau :) Ben. GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open channels and run simple pushbuffers with libdrm (more testing including rendering is in progress as we get more familiar with Nouveau's user-space interface). This work should be considered as a RFC and a proof-of-concept for driving future Tegra GPUs with Nouveau. Some design choices need to be discussed and quite a few inelegant shortcuts were purposely taken to minimize the size of this first set. Or said otherwise, apart from the changes that add support for non-PCI GPUs, remarkably little code needs to be added to get GK20A to a point where it is actually running. This is very encouraging, and it will be interesting to keep improving this support and see where this gets us. The first part of this series (patches 01/09) adds support for platform devices to Nouveau. Nouveau currently only supports PCI devices, and GK20A uses the platform bus and Device Tree. So the first step towards GK20A support is to abstract the PCI functions used by Nouveau (mainly resources range querying and page mapping functions) and add platform device probing functions. For most of the existing chips, platform device support does not make any sense, so only the subdev and engine drivers actually used by GK20A were updated to use these abstractions. If, for consistency reasons, it is deemed preferable to use them everywhere in the driver, we will do it in the next revision of this series. This part can be considered independently from the actual GK20A support, and I believe it would make sense to discuss what needs to be improved and drive it to merge separately, as the remainder of the series will likely require more work. The second part (10/14) updates existing subdev/engine drivers to support GK20A, and adds a very simple memory driver that simulates dedicated video memory by allocating a large system memory chunk at boot time. This is clearly sub-optimal and should not be merged, but allowed us to quickly bring GK20A up with Nouveau. Other drivers changes are fairly small, and are here to handle the difference in number of engines and units compared to desktop Kepler as well as to perform a few things usually done by the video BIOS (which Tegra does not feature). Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A's instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we should try to get rid of. I guess my email address might surprise some of you, so let me anticipate some questions you might have. :P Yes, this work is endorsed by NVIDIA. Several other NVIDIAns (CC'd), including core GPU experts, have provided significant technical guidance and will continue their involvement. Special thanks go to Terje Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding (at FOSDEM this weekend) for help with debugging and user-space testing. Let me also stress that although very exciting, this effort is still experimental, so I would like to make sure that nobody makes excessive expectations based on these few patches. The scope of this work is strictly limited to Tegra (although given the similarities desktop GPU support will certainly benefit from it indirectly), and we do not have any plan to work on user-space support. So do not uninstall that proprietary driver just yet. ;) With this being clarified, we are looking forward to getting your feedback and working with you guys to bring and improve Tegra K1 support into Nouveau! :) Alexandre Courbot (16): drm/nouveau: handle -EACCES runtime PM return code drm/nouveau: basic support for platform devices drm/nouveau: add platform device probing function drm/nouveau/fifo: support platform devices drm/nouveau/bar: support platform devices drm/nouveau/bar: only ioremap BAR3 if it exists drm/nouveau/bar/nvc0: support chips without BAR3
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Mon, Feb 3, 2014 at 1:14 PM, Ilia Mirkin wrote: > On Sun, Feb 2, 2014 at 9:44 PM, Alexandre Courbot wrote: >> One beginner question: is it appropriate to send kernel patches to the >> nouveau list in addition to dri-devel? The moderation messages I receive >> make me think that this list might rather be intended for general >> discussion. > > I usually do. The main thing is to make sure that they're To: Ben, > since he's the one who will be ultimately be picking them up. I think > that if you're not subscribed, all the lists.freedesktop.org lists > moderate you, but dri-devel is configured not to tell you about it. > Also I've been getting bounce messages from nouveau@ complaining of > too many cc's and so it's getting auto-moderated -- not sure who, if > anyone, is an admin of the nouveau list. Hopefully someone :) The Nouveau list seems the most appropriate. There's not really any need to explicitly CC me either, I do watch the list :) > > -ilia > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Sun, Feb 2, 2014 at 9:44 PM, Alexandre Courbot wrote: > One beginner question: is it appropriate to send kernel patches to the > nouveau list in addition to dri-devel? The moderation messages I receive > make me think that this list might rather be intended for general > discussion. I usually do. The main thing is to make sure that they're To: Ben, since he's the one who will be ultimately be picking them up. I think that if you're not subscribed, all the lists.freedesktop.org lists moderate you, but dri-devel is configured not to tell you about it. Also I've been getting bounce messages from nouveau@ complaining of too many cc's and so it's getting auto-moderated -- not sure who, if anyone, is an admin of the nouveau list. Hopefully someone :) -ilia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On 02/03/2014 04:10 AM, Ilia Mirkin wrote: Hi Alexandre, On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot wrote: I guess my email address might surprise some of you, so let me anticipate some questions you might have. :P Yes, this work is endorsed by NVIDIA. Several other NVIDIAns (CC'd), including core GPU experts, have provided significant technical guidance and will continue their involvement. Special thanks go to Terje Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding (at FOSDEM this weekend) for help with debugging and user-space testing. Let me also stress that although very exciting, this effort is still experimental, so I would like to make sure that nobody makes excessive expectations based on these few patches. The scope of this work is strictly limited to Tegra (although given the similarities desktop GPU support will certainly benefit from it indirectly), and we do not have any plan to work on user-space support. So do not uninstall that proprietary driver just yet. ;) With this being clarified, we are looking forward to getting your feedback and working with you guys to bring and improve Tegra K1 support into Nouveau! :) I've sent a couple of fairly trivial comments, as you saw, and I suspect that others with a better understanding of the guts will have more substantial architectural feedback, esp after the weekend/FOSDEM. However, since no one's said it already -- welcome to Nouveau! Thanks! ^_^v One beginner question: is it appropriate to send kernel patches to the nouveau list in addition to dri-devel? The moderation messages I receive make me think that this list might rather be intended for general discussion. From the looks of it, you could bring up a full open-source stack with your patches (i.e. Xorg + nouveau DDX + mesa) and use PRIME to render stuff (assuming the actual display hw has an X ddx). Although I suspect that you're going to want to use your own drivers. Still a little curious if you've tried the open-source stack and whether it worked. [Not sure what the status is of render-node support is in mesa, but perhaps it's enough to try running piglit tests, if you can't get X going with the display HW.] We are still testing things at libdrm level, but are eventually interested in bringing up the existing open-source stack. Our guess (and hope) is that it will work nicely almost as-is, minus the fact that the display hardware is not handled by Nouveau and we only support render nodes (I have yet to look at what the state of render nodes in Mesa is). For X, Thierry is IIUC working on the display driver, and at some point these efforts should join to connect tegradrm and Nouveau using PRIME. We are not quite there yet, and since we are working with limited resources it will likely require some time, but the fact we could bring up a (seemingly) working Nouveau kernel driver with so little code is encouraging. Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
Hi Alexandre, On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot wrote: > I guess my email address might surprise some of you, so let me anticipate some > questions you might have. :P Yes, this work is endorsed by NVIDIA. Several > other > NVIDIAns (CC'd), including core GPU experts, have provided significant > technical > guidance and will continue their involvement. Special thanks go to Terje > Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding > (at FOSDEM this weekend) for help with debugging and user-space testing. > > Let me also stress that although very exciting, this effort is still > experimental, so I would like to make sure that nobody makes excessive > expectations based on these few patches. The scope of this work is strictly > limited to Tegra (although given the similarities desktop GPU support will > certainly benefit from it indirectly), and we do not have any plan to work on > user-space support. So do not uninstall that proprietary driver just yet. ;) > > With this being clarified, we are looking forward to getting your feedback and > working with you guys to bring and improve Tegra K1 support into Nouveau! :) I've sent a couple of fairly trivial comments, as you saw, and I suspect that others with a better understanding of the guts will have more substantial architectural feedback, esp after the weekend/FOSDEM. However, since no one's said it already -- welcome to Nouveau! >From the looks of it, you could bring up a full open-source stack with your patches (i.e. Xorg + nouveau DDX + mesa) and use PRIME to render stuff (assuming the actual display hw has an X ddx). Although I suspect that you're going to want to use your own drivers. Still a little curious if you've tried the open-source stack and whether it worked. [Not sure what the status is of render-node support is in mesa, but perhaps it's enough to try running piglit tests, if you can't get X going with the display HW.] -ilia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
Hi Alexandre, On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot acour...@nvidia.com wrote: I guess my email address might surprise some of you, so let me anticipate some questions you might have. :P Yes, this work is endorsed by NVIDIA. Several other NVIDIAns (CC'd), including core GPU experts, have provided significant technical guidance and will continue their involvement. Special thanks go to Terje Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding (at FOSDEM this weekend) for help with debugging and user-space testing. Let me also stress that although very exciting, this effort is still experimental, so I would like to make sure that nobody makes excessive expectations based on these few patches. The scope of this work is strictly limited to Tegra (although given the similarities desktop GPU support will certainly benefit from it indirectly), and we do not have any plan to work on user-space support. So do not uninstall that proprietary driver just yet. ;) With this being clarified, we are looking forward to getting your feedback and working with you guys to bring and improve Tegra K1 support into Nouveau! :) I've sent a couple of fairly trivial comments, as you saw, and I suspect that others with a better understanding of the guts will have more substantial architectural feedback, esp after the weekend/FOSDEM. However, since no one's said it already -- welcome to Nouveau! From the looks of it, you could bring up a full open-source stack with your patches (i.e. Xorg + nouveau DDX + mesa) and use PRIME to render stuff (assuming the actual display hw has an X ddx). Although I suspect that you're going to want to use your own drivers. Still a little curious if you've tried the open-source stack and whether it worked. [Not sure what the status is of render-node support is in mesa, but perhaps it's enough to try running piglit tests, if you can't get X going with the display HW.] -ilia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On 02/03/2014 04:10 AM, Ilia Mirkin wrote: Hi Alexandre, On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot acour...@nvidia.com wrote: I guess my email address might surprise some of you, so let me anticipate some questions you might have. :P Yes, this work is endorsed by NVIDIA. Several other NVIDIAns (CC'd), including core GPU experts, have provided significant technical guidance and will continue their involvement. Special thanks go to Terje Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding (at FOSDEM this weekend) for help with debugging and user-space testing. Let me also stress that although very exciting, this effort is still experimental, so I would like to make sure that nobody makes excessive expectations based on these few patches. The scope of this work is strictly limited to Tegra (although given the similarities desktop GPU support will certainly benefit from it indirectly), and we do not have any plan to work on user-space support. So do not uninstall that proprietary driver just yet. ;) With this being clarified, we are looking forward to getting your feedback and working with you guys to bring and improve Tegra K1 support into Nouveau! :) I've sent a couple of fairly trivial comments, as you saw, and I suspect that others with a better understanding of the guts will have more substantial architectural feedback, esp after the weekend/FOSDEM. However, since no one's said it already -- welcome to Nouveau! Thanks! ^_^v One beginner question: is it appropriate to send kernel patches to the nouveau list in addition to dri-devel? The moderation messages I receive make me think that this list might rather be intended for general discussion. From the looks of it, you could bring up a full open-source stack with your patches (i.e. Xorg + nouveau DDX + mesa) and use PRIME to render stuff (assuming the actual display hw has an X ddx). Although I suspect that you're going to want to use your own drivers. Still a little curious if you've tried the open-source stack and whether it worked. [Not sure what the status is of render-node support is in mesa, but perhaps it's enough to try running piglit tests, if you can't get X going with the display HW.] We are still testing things at libdrm level, but are eventually interested in bringing up the existing open-source stack. Our guess (and hope) is that it will work nicely almost as-is, minus the fact that the display hardware is not handled by Nouveau and we only support render nodes (I have yet to look at what the state of render nodes in Mesa is). For X, Thierry is IIUC working on the display driver, and at some point these efforts should join to connect tegradrm and Nouveau using PRIME. We are not quite there yet, and since we are working with limited resources it will likely require some time, but the fact we could bring up a (seemingly) working Nouveau kernel driver with so little code is encouraging. Thanks, Alex. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Sun, Feb 2, 2014 at 9:44 PM, Alexandre Courbot acour...@nvidia.com wrote: One beginner question: is it appropriate to send kernel patches to the nouveau list in addition to dri-devel? The moderation messages I receive make me think that this list might rather be intended for general discussion. I usually do. The main thing is to make sure that they're To: Ben, since he's the one who will be ultimately be picking them up. I think that if you're not subscribed, all the lists.freedesktop.org lists moderate you, but dri-devel is configured not to tell you about it. Also I've been getting bounce messages from nouveau@ complaining of too many cc's and so it's getting auto-moderated -- not sure who, if anyone, is an admin of the nouveau list. Hopefully someone :) -ilia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Mon, Feb 3, 2014 at 1:14 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Sun, Feb 2, 2014 at 9:44 PM, Alexandre Courbot acour...@nvidia.com wrote: One beginner question: is it appropriate to send kernel patches to the nouveau list in addition to dri-devel? The moderation messages I receive make me think that this list might rather be intended for general discussion. I usually do. The main thing is to make sure that they're To: Ben, since he's the one who will be ultimately be picking them up. I think that if you're not subscribed, all the lists.freedesktop.org lists moderate you, but dri-devel is configured not to tell you about it. Also I've been getting bounce messages from nouveau@ complaining of too many cc's and so it's getting auto-moderated -- not sure who, if anyone, is an admin of the nouveau list. Hopefully someone :) The Nouveau list seems the most appropriate. There's not really any need to explicitly CC me either, I do watch the list :) -ilia ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open channels and run simple pushbuffers with libdrm (more testing including rendering is in progress as we get more familiar with Nouveau's user-space interface). This work should be considered as a RFC and a proof-of-concept for driving future Tegra GPUs with Nouveau. Some design choices need to be discussed and quite a few inelegant shortcuts were purposely taken to minimize the size of this first set. Or said otherwise, apart from the changes that add support for non-PCI GPUs, remarkably little code needs to be added to get GK20A to a point where it is actually running. This is very encouraging, and it will be interesting to keep improving this support and see where this gets us. The first part of this series (patches 01/09) adds support for platform devices to Nouveau. Nouveau currently only supports PCI devices, and GK20A uses the platform bus and Device Tree. So the first step towards GK20A support is to abstract the PCI functions used by Nouveau (mainly resources range querying and page mapping functions) and add platform device probing functions. For most of the existing chips, platform device support does not make any sense, so only the subdev and engine drivers actually used by GK20A were updated to use these abstractions. If, for consistency reasons, it is deemed preferable to use them everywhere in the driver, we will do it in the next revision of this series. This part can be considered independently from the actual GK20A support, and I believe it would make sense to discuss what needs to be improved and drive it to merge separately, as the remainder of the series will likely require more work. The second part (10/14) updates existing subdev/engine drivers to support GK20A, and adds a very simple memory driver that simulates dedicated video memory by allocating a large system memory chunk at boot time. This is clearly sub-optimal and should not be merged, but allowed us to quickly bring GK20A up with Nouveau. Other drivers changes are fairly small, and are here to handle the difference in number of engines and units compared to desktop Kepler as well as to perform a few things usually done by the video BIOS (which Tegra does not feature). Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A’s instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we should try to get rid of. I guess my email address might surprise some of you, so let me anticipate some questions you might have. :P Yes, this work is endorsed by NVIDIA. Several other NVIDIAns (CC'd), including core GPU experts, have provided significant technical guidance and will continue their involvement. Special thanks go to Terje Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding (at FOSDEM this weekend) for help with debugging and user-space testing. Let me also stress that although very exciting, this effort is still experimental, so I would like to make sure that nobody makes excessive expectations based on these few patches. The scope of this work is strictly limited to Tegra (although given the similarities desktop GPU support will certainly benefit from it indirectly), and we do not have any plan to work on user-space support. So do not uninstall that proprietary driver just yet. ;) With this being clarified, we are looking forward to getting your feedback and working with you guys to bring and improve Tegra K1 support into Nouveau! :) Alexandre Courbot (16): drm/nouveau: handle -EACCES runtime PM return code drm/nouveau: basic support for platform devices drm/nouveau: add platform device probing function drm/nouveau/fifo: support platform devices drm/nouveau/bar: support platform devices drm/nouveau/bar: only ioremap BAR3 if it exists drm/nouveau/bar/nvc0: support chips without BAR3 drm/nouveau/mc: support platform devices drm/nouveau/fb: support platform devices drm/nouveau/timer: skip calibration on GK20A drm/nouveau/fifo: allocate usermem as needed drm/nouveau/fifo: add GK20A support drm/nouveau/ibus: add GK20A support drm/nouveau/fb: add GK20A support drm/nouveau: support GK20A in nouveau_accel_init() drm/nouveau: support for probing GK20A
[RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open channels and run simple pushbuffers with libdrm (more testing including rendering is in progress as we get more familiar with Nouveau's user-space interface). This work should be considered as a RFC and a proof-of-concept for driving future Tegra GPUs with Nouveau. Some design choices need to be discussed and quite a few inelegant shortcuts were purposely taken to minimize the size of this first set. Or said otherwise, apart from the changes that add support for non-PCI GPUs, remarkably little code needs to be added to get GK20A to a point where it is actually running. This is very encouraging, and it will be interesting to keep improving this support and see where this gets us. The first part of this series (patches 01/09) adds support for platform devices to Nouveau. Nouveau currently only supports PCI devices, and GK20A uses the platform bus and Device Tree. So the first step towards GK20A support is to abstract the PCI functions used by Nouveau (mainly resources range querying and page mapping functions) and add platform device probing functions. For most of the existing chips, platform device support does not make any sense, so only the subdev and engine drivers actually used by GK20A were updated to use these abstractions. If, for consistency reasons, it is deemed preferable to use them everywhere in the driver, we will do it in the next revision of this series. This part can be considered independently from the actual GK20A support, and I believe it would make sense to discuss what needs to be improved and drive it to merge separately, as the remainder of the series will likely require more work. The second part (10/14) updates existing subdev/engine drivers to support GK20A, and adds a very simple memory driver that simulates dedicated video memory by allocating a large system memory chunk at boot time. This is clearly sub-optimal and should not be merged, but allowed us to quickly bring GK20A up with Nouveau. Other drivers changes are fairly small, and are here to handle the difference in number of engines and units compared to desktop Kepler as well as to perform a few things usually done by the video BIOS (which Tegra does not feature). Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A’s instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we should try to get rid of. I guess my email address might surprise some of you, so let me anticipate some questions you might have. :P Yes, this work is endorsed by NVIDIA. Several other NVIDIAns (CC'd), including core GPU experts, have provided significant technical guidance and will continue their involvement. Special thanks go to Terje Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry Reding (at FOSDEM this weekend) for help with debugging and user-space testing. Let me also stress that although very exciting, this effort is still experimental, so I would like to make sure that nobody makes excessive expectations based on these few patches. The scope of this work is strictly limited to Tegra (although given the similarities desktop GPU support will certainly benefit from it indirectly), and we do not have any plan to work on user-space support. So do not uninstall that proprietary driver just yet. ;) With this being clarified, we are looking forward to getting your feedback and working with you guys to bring and improve Tegra K1 support into Nouveau! :) Alexandre Courbot (16): drm/nouveau: handle -EACCES runtime PM return code drm/nouveau: basic support for platform devices drm/nouveau: add platform device probing function drm/nouveau/fifo: support platform devices drm/nouveau/bar: support platform devices drm/nouveau/bar: only ioremap BAR3 if it exists drm/nouveau/bar/nvc0: support chips without BAR3 drm/nouveau/mc: support platform devices drm/nouveau/fb: support platform devices drm/nouveau/timer: skip calibration on GK20A drm/nouveau/fifo: allocate usermem as needed drm/nouveau/fifo: add GK20A support drm/nouveau/ibus: add GK20A support drm/nouveau/fb: add GK20A support drm/nouveau: support GK20A in nouveau_accel_init() drm/nouveau: support for probing GK20A
