Selecting supported chipsets in the driver?

Selecting supported chipsets in the driver?

[Christ-Jan Wijtmans]

[-- Attachment #1.1: Type: text/plain, Size: 474 bytes --]

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.


Live long and prosper,

Christ-Jan Wijtmans

[-- Attachment #1.2: Type: text/html, Size: 576 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Selecting supported chipsets in the driver?

[Emil Velikov]

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 :)

Cheers
Emil

> 
> Live long and prosper,
> 
> Christ-Jan Wijtmans
> 
> 
> 
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
> 

Re: Selecting supported chipsets in the driver?

[Ilia Mirkin]

On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

Re: Selecting supported chipsets in the driver?

[Martin Peres]

On 30/07/2013 18:43, Ilia Mirkin wrote:
> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
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).

Re: Selecting supported chipsets in the driver?

[Ilia Mirkin]

On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org> wrote:
> On 30/07/2013 18:43, Ilia Mirkin wrote:
>>
>> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> 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.)

> 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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Selecting supported chipsets in the driver?

[Martin Peres]

On 31/07/2013 11:03, Ilia Mirkin wrote:
> On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org> wrote:
>> On 30/07/2013 18:43, Ilia Mirkin wrote:
>>> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> 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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Selecting supported chipsets in the driver?

[Christ-Jan Wijtmans]

[-- Attachment #1.1: Type: text/plain, Size: 4312 bytes --]

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-GANU6spQydw@public.gmane.org> wrote:

> On 31/07/2013 11:03, Ilia Mirkin wrote:
>
>> On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
>> wrote:
>>
>>> On 30/07/2013 18:43, Ilia Mirkin wrote:
>>>
>>>> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>>> >
>>>> 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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>> http://lists.freedesktop.org/**mailman/listinfo/nouveau<http://lists.freedesktop.org/mailman/listinfo/nouveau>
>>>
>>
> ______________________________**_________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/**mailman/listinfo/nouveau<http://lists.freedesktop.org/mailman/listinfo/nouveau>
>

[-- Attachment #1.2: Type: text/html, Size: 6133 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Selecting supported chipsets in the driver?

[Christ-Jan Wijtmans]

[-- Attachment #1.1: Type: text/plain, Size: 4648 bytes --]

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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>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-GANU6spQydw@public.gmane.org>wrote:
>
>> On 31/07/2013 11:03, Ilia Mirkin wrote:
>>
>>> On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
>>> wrote:
>>>
>>>> On 30/07/2013 18:43, Ilia Mirkin wrote:
>>>>
>>>>> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <
>>>>> emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> 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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>>>>
>>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 7049 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Selecting supported chipsets in the driver?

[Martin Peres]

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