Christ-Jan Wijtmans
2013-Aug-01 00:15 UTC
[Nouveau] Selecting supported chipsets in the driver?
Sorry but 1.7 and 6.3 MB are huge... Live long and prosper, Christ-Jan Wijtmans http://facebook.com/cj.wijtmans http://twitter.com/cjwijtmans On Wed, Jul 31, 2013 at 5:42 PM, Martin Peres <martin.peres at free.fr> wrote:> On 31/07/2013 11:03, Ilia Mirkin wrote: > >> On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres at free.fr> >> wrote: >> >>> On 30/07/2013 18:43, Ilia Mirkin wrote: >>> >>>> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov at gmail.com >>>> > >>>> wrote: >>>> >>>>> On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >>>>> >>>>>> Hi, my apologies if this is the wrong place to post this. >>>>>> I had the desire to turn on or off support for certain chipsets. >>>>>> Because i felt like the nouveau drivers are (relatively) quite large >>>>>> and >>>>>> depends on some kernel code that would only be used for certain >>>>>> chipsets. >>>>>> I will take some time this week to see how this is coded and if its >>>>>> possible but i just wanted a head sup opinion on you guys before i >>>>>> start >>>>>> wasting my time. >>>>>> >>>>>> I'm not entirely sure if you're talking about the kernel module, ddx >>>>> (xf86-video-nouveau) or mesa. >>>>> >>>>> In either case, all three should be relatively easy to do, as normally >>>>> the generation specific code is divided. Not too sure if it's worth the >>>>> effort though >>>>> >>>>> * kernel module - 1.7 MiB, ~400KiB gzip >>>>> * ddx - ~200KiB >>>>> * mesa - 6.3 MiB (nouveau/gallium only) >>>>> >>>>> As you can see the sizes are not that big, and I'm not sure if the >>>>> maintainers would be up-to the idea >>>>> >>>>> Not a maintainer myself so take the last statement if a healthy pinch >>>>> of >>>>> salt :) >>>>> >>>> I'm not a maintainer either, but to provide an opposing opinion, I >>>> strongly support the notion of being able to select card generations >>>> to build support for. 1.7M of kernel code is huge. I don't even think >>>> it'd be that hard (at least for the kernel module and mesa, and I >>>> think there's a lot less value in doing it for the DDX). I think it >>>> might be as easy as some Makefile changes + a couple of ifdefs in the >>>> init code to do Y/N selects. Making it so that the additional >>>> functionality can be loaded on demand (i.e. Y/M/N) may be much >>>> trickier, to the point of it not being worth it for the additional >>>> complexity. >>>> >>>> -ilia >>>> >>> >>> In mesa, it is possible to build the driver you want (nouveau_vieux, >>> nv30, >>> nv50 or nvc0) so the feature is already there. >>> >> Really? How do you compile only nv50? (Hint: you can't. nv30/nv50/nvc0 >> are all linked together in the nouveau driver, no way to split them >> out, largely because of the nouveau_drm_screen_create function.) >> > Hmm, as I need to specify which driver I want in configure, I thought > they were separated. My bad > > >> There is no point for the ddx. >>> >>> As for drm, I sure would use this feature as this would cut down >>> compilation >>> time a lot when doing out of the tree builds. With the core arch, in >>> theory, >>> it shouldn't be that hard if you want plan on using old cards only. >>> However, >>> if you plan on doing the opposite (drop old cards support), it is harder >>> as newer cards still use code written for the old ones. If you like, >>> you can draw a dependency map quite easily by looking into the device >>> directory that will contain all the dependencies for every chipset. >>> >>> One more thing, maintaining these dependencies will be done poorly and >>> eat development time. So I'm not in huge favour of this unless you >>> introduce a system that only compiles code for chipsets up to a certain >>> point (which is useless IMO). >>> >>> >>> >>> ______________________________**_________________ >>> Nouveau mailing list >>> Nouveau at lists.freedesktop.org >>> http://lists.freedesktop.org/**mailman/listinfo/nouveau<http://lists.freedesktop.org/mailman/listinfo/nouveau> >>> >> > ______________________________**_________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/**mailman/listinfo/nouveau<http://lists.freedesktop.org/mailman/listinfo/nouveau> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130801/ae324293/attachment-0001.html>
Christ-Jan Wijtmans
2013-Nov-29 13:17 UTC
[Nouveau] Selecting supported chipsets in the driver?
so uhm, as far as i know in ATI drivers this is possible, why no nouveau? Live long and prosper, Christ-Jan Wijtmans https://github.com/cjwijtmans http://facebook.com/cj.wijtmans http://twitter.com/cjwijtmans On Thu, Aug 1, 2013 at 2:15 AM, Christ-Jan Wijtmans <cj.wijtmans at gmail.com>wrote:> Sorry but 1.7 and 6.3 MB are huge... > > > Live long and prosper, > > Christ-Jan Wijtmans > http://facebook.com/cj.wijtmans > http://twitter.com/cjwijtmans > > > On Wed, Jul 31, 2013 at 5:42 PM, Martin Peres <martin.peres at free.fr>wrote: > >> On 31/07/2013 11:03, Ilia Mirkin wrote: >> >>> On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres at free.fr> >>> wrote: >>> >>>> On 30/07/2013 18:43, Ilia Mirkin wrote: >>>> >>>>> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov < >>>>> emil.l.velikov at gmail.com> >>>>> wrote: >>>>> >>>>>> On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >>>>>> >>>>>>> Hi, my apologies if this is the wrong place to post this. >>>>>>> I had the desire to turn on or off support for certain chipsets. >>>>>>> Because i felt like the nouveau drivers are (relatively) quite large >>>>>>> and >>>>>>> depends on some kernel code that would only be used for certain >>>>>>> chipsets. >>>>>>> I will take some time this week to see how this is coded and if its >>>>>>> possible but i just wanted a head sup opinion on you guys before i >>>>>>> start >>>>>>> wasting my time. >>>>>>> >>>>>>> I'm not entirely sure if you're talking about the kernel module, ddx >>>>>> (xf86-video-nouveau) or mesa. >>>>>> >>>>>> In either case, all three should be relatively easy to do, as normally >>>>>> the generation specific code is divided. Not too sure if it's worth >>>>>> the >>>>>> effort though >>>>>> >>>>>> * kernel module - 1.7 MiB, ~400KiB gzip >>>>>> * ddx - ~200KiB >>>>>> * mesa - 6.3 MiB (nouveau/gallium only) >>>>>> >>>>>> As you can see the sizes are not that big, and I'm not sure if the >>>>>> maintainers would be up-to the idea >>>>>> >>>>>> Not a maintainer myself so take the last statement if a healthy pinch >>>>>> of >>>>>> salt :) >>>>>> >>>>> I'm not a maintainer either, but to provide an opposing opinion, I >>>>> strongly support the notion of being able to select card generations >>>>> to build support for. 1.7M of kernel code is huge. I don't even think >>>>> it'd be that hard (at least for the kernel module and mesa, and I >>>>> think there's a lot less value in doing it for the DDX). I think it >>>>> might be as easy as some Makefile changes + a couple of ifdefs in the >>>>> init code to do Y/N selects. Making it so that the additional >>>>> functionality can be loaded on demand (i.e. Y/M/N) may be much >>>>> trickier, to the point of it not being worth it for the additional >>>>> complexity. >>>>> >>>>> -ilia >>>>> >>>> >>>> In mesa, it is possible to build the driver you want (nouveau_vieux, >>>> nv30, >>>> nv50 or nvc0) so the feature is already there. >>>> >>> Really? How do you compile only nv50? (Hint: you can't. nv30/nv50/nvc0 >>> are all linked together in the nouveau driver, no way to split them >>> out, largely because of the nouveau_drm_screen_create function.) >>> >> Hmm, as I need to specify which driver I want in configure, I thought >> they were separated. My bad >> >> >>> There is no point for the ddx. >>>> >>>> As for drm, I sure would use this feature as this would cut down >>>> compilation >>>> time a lot when doing out of the tree builds. With the core arch, in >>>> theory, >>>> it shouldn't be that hard if you want plan on using old cards only. >>>> However, >>>> if you plan on doing the opposite (drop old cards support), it is harder >>>> as newer cards still use code written for the old ones. If you like, >>>> you can draw a dependency map quite easily by looking into the device >>>> directory that will contain all the dependencies for every chipset. >>>> >>>> One more thing, maintaining these dependencies will be done poorly and >>>> eat development time. So I'm not in huge favour of this unless you >>>> introduce a system that only compiles code for chipsets up to a certain >>>> point (which is useless IMO). >>>> >>>> >>>> >>>> _______________________________________________ >>>> Nouveau mailing list >>>> Nouveau at lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/nouveau >>>> >>> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/nouveau >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20131129/f1438612/attachment.html>
Le 29/11/2013 14:17, Christ-Jan Wijtmans a ?crit :> so uhm, as far as i know in ATI drivers this is possible, why no nouveau?Well, because we share a lot of code between chipsets and it would be a pain not to compile everything. FYI, on Archlinux: -rw-r--r-- 1 root root 379K 26 nov. 11:18 /lib/modules/3.12.1-3-ARCH/kernel/drivers/gpu/drm/nouveau/nouveau.ko.gz -rw-r--r-- 1 mupuf mupuf 1,5M 29 nov. 15:06 nouveau.ko -rwxr-xr-x 1 root root 180K 16 nov. 16:00 /usr/lib/xorg/modules/dri/nouveau_vieux_dri.so -rwxr-xr-x 1 root root 6,5M 16 nov. 16:00 /usr/lib/xorg/modules/dri/nouveau_dri.so -rw-r--r-- 1 root root 583K 26 nov. 11:18 /lib/modules/3.12.1-3-ARCH/kernel/drivers/gpu/drm/radeon/radeon.ko.gz -rw-r--r-- 1 mupuf mupuf 2,2M 29 nov. 15:07 radeon.ko -rw-r--r-- 1 root root 337K 26 nov. 11:18 /lib/modules/3.12.1-3-ARCH/kernel/drivers/gpu/drm/i915/i915.ko.gz -rw-r--r-- 1 mupuf mupuf 1,2M 29 nov. 15:08 i915.ko So, the whole of nouveau weights a little more than 7MB. Even by floppy standards, it isn't huge! And I'm not talking about nvidia's driver that is WAY bigger. So, If you manage to make a good patch a prove you can save a substential amount of space and that isn't a pain to maintain, then maybe we'll consider this. Cheers, Martin