Removal of Non-KMS support

Removal of Non-KMS support

[Ben Skeggs]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

I did a very quick pass at removing all the non-KMS support from the
DDX.  It's tested on G80 but nowhere else currently, I thought some
discussion would be a good idea rather than just ripping it out :)

The non-KMS paths are messy, and lets face it, rotting badly.  IMO the
KMS code is stable enough now that we can continue without the UMS
crutch, and indeed, the KMS code supports a lot more chipsets
(particularly on GF8 and up) than the UMS code ever will.

I've left the Xv overlay code intact, but ifdef'd out.  I want to bring
support back with KMS enabled (thinking of older chipsets where the
blitter sucks), so it made sense to leave the old code there for now.

So, who has some Signed-off-by's :)

Ben.


[-- Attachment #2: 0001-Initial-pass-at-removal-of-non-KMS-support.patch.bz2 --]
[-- Type: application/x-bzip, Size: 91651 bytes --]

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

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

Re: Removal of Non-KMS support

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 4101 bytes --]

Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> I did a very quick pass at removing all the non-KMS support from the
> DDX.  It's tested on G80 but nowhere else currently, I thought some
> discussion would be a good idea rather than just ripping it out :)
>
> The non-KMS paths are messy, and lets face it, rotting badly.  IMO the
> KMS code is stable enough now that we can continue without the UMS
> crutch, and indeed, the KMS code supports a lot more chipsets
> (particularly on GF8 and up) than the UMS code ever will.
>
> I've left the Xv overlay code intact, but ifdef'd out.  I want to bring
> support back with KMS enabled (thinking of older chipsets where the
> blitter sucks), so it made sense to leave the old code there for now.
>
> So, who has some Signed-off-by's :)

I'm very happy that we're finally getting rid of this :), besides a few
comments, you got my blessing:
Signed-off-by: Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>

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

Some snips from the patch in question:

> [...]
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index e37e7c1..3d2df8d 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> [...]
> +#define SOURCE_MASK_INTERLEAVE 32
> +#define TRANSPARENT_PIXEL   0
> +
> +/*
> + * Convert a source/mask bitmap cursor to an ARGB cursor, clipping or
> + * padding as necessary. source/mask are assumed to be alternated each
> + * SOURCE_MASK_INTERLEAVE bits.
> + */
> +static void
> +nv_cursor_convert_cursor(uint32_t *src, void *dst, int src_stride,
> +			 int dst_stride, int bpp, uint32_t fg, uint32_t bg)
> +{
> +	int width = min(src_stride, dst_stride);
> +	uint32_t b, m, pxval;
> +	int i, j, k;
> +
> +	for (i = 0; i < width; i++) {
> +		for (j = 0; j < width / SOURCE_MASK_INTERLEAVE; j++) {
> +			int src_off = i*src_stride/SOURCE_MASK_INTERLEAVE + j;
> +			int dst_off = i*dst_stride + j*SOURCE_MASK_INTERLEAVE;
> +
> +			b = src[2*src_off];
> +			m = src[2*src_off + 1];
> +
> +			for (k = 0; k < SOURCE_MASK_INTERLEAVE; k++) {
> +				pxval = TRANSPARENT_PIXEL;
> +#if X_BYTE_ORDER == X_BIG_ENDIAN
> +				if (m & 0x80000000)
> +					pxval = (b & 0x80000000) ? fg : bg;
> +				b <<= 1;
> +				m <<= 1;
> +#else
> +				if (m & 1)
> +					pxval = (b & 1) ? fg : bg;
> +				b >>= 1;
> +				m >>= 1;
> +#endif
> +				if (bpp == 32)
> +					((uint32_t *)dst)[dst_off + k] = pxval;
> +				else
> +					((uint16_t *)dst)[dst_off + k] = pxval;
> +			}
> +		}
> +	}
> +}
> +

I'm quite sure that, without UMS, this function doesn't make sense
anymore, you could leave this fun for the X server (we can use the
load_cursor_argb hook even on the cards we don't advertise ARGB
support). As a bonus that would probably solve Craig's rotated cursor
issue.

> [...]
> diff --git a/src/nv_setup.c b/src/nv_setup.c
> deleted file mode 100644
> index f0478ca..0000000
> --- a/src/nv_setup.c
> +++ /dev/null
> [...]
> -	pNv->alphaCursor = (pNv->NVArch >= 0x11);
> -
> -	pNv->twoHeads = (pNv->Architecture >= NV_ARCH_10) &&
> -			(implementation != CHIPSET_NV10) &&
> -			(implementation != CHIPSET_NV15) &&
> -			(implementation != CHIPSET_NFORCE) &&
> -			(implementation != CHIPSET_NV20);
> -
> -	pNv->gf4_disp_arch = pNv->twoHeads && implementation != CHIPSET_NV11;
> -
> -	/* nv30 and nv35 have two stage PLLs, but use only one register; they are dealt with separately */
> -	pNv->two_reg_pll = (implementation == CHIPSET_NV31) ||
> -			   (implementation == CHIPSET_NV36) ||
> -			   (pNv->Architecture >= NV_ARCH_40);
> -
> -	pNv->WaitVSyncPossible = (pNv->Architecture >= NV_ARCH_10) &&
> -				 (implementation != CHIPSET_NV10);
> -

The accel code still has some bogus checks for WaitVSyncPossible, and
bad things will happen if it's left uninitialized. Anyway, it would be
nice to kill all this crap from NVRec.

> -	pNv->BlendingPossible = ((pNv->Chipset & 0xffff) > CHIPSET_NV04);
> [...]

[-- Attachment #1.2: Type: application/pgp-signature, Size: 196 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: Removal of Non-KMS support

[Maarten Maathuis]

I had a quick look, and i have nothing to add. I must say a signed off
is inappropriate here, since we are neither the original copyright
holder or any of the subsequent "gateways". Depending on the level of
checking either an acked-by or reviewed-by is the right thing to do.
Since i did not check the patch line by line, and only agree with the
intention of the patch:

Acked-By: Maarten Maathuis <madman2003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Assuming curro_ concerns are dealt with.

On Wed, Jan 6, 2010 at 9:59 PM, Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org> wrote:
> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> I did a very quick pass at removing all the non-KMS support from the
>> DDX.  It's tested on G80 but nowhere else currently, I thought some
>> discussion would be a good idea rather than just ripping it out :)
>>
>> The non-KMS paths are messy, and lets face it, rotting badly.  IMO the
>> KMS code is stable enough now that we can continue without the UMS
>> crutch, and indeed, the KMS code supports a lot more chipsets
>> (particularly on GF8 and up) than the UMS code ever will.
>>
>> I've left the Xv overlay code intact, but ifdef'd out.  I want to bring
>> support back with KMS enabled (thinking of older chipsets where the
>> blitter sucks), so it made sense to leave the old code there for now.
>>
>> So, who has some Signed-off-by's :)
>
> I'm very happy that we're finally getting rid of this :), besides a few
> comments, you got my blessing:
> Signed-off-by: Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
>
>>
>> Ben.
>>
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>
> Some snips from the patch in question:
>
>> [...]
>> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
>> index e37e7c1..3d2df8d 100644
>> --- a/src/drmmode_display.c
>> +++ b/src/drmmode_display.c
>> [...]
>> +#define SOURCE_MASK_INTERLEAVE 32
>> +#define TRANSPARENT_PIXEL   0
>> +
>> +/*
>> + * Convert a source/mask bitmap cursor to an ARGB cursor, clipping or
>> + * padding as necessary. source/mask are assumed to be alternated each
>> + * SOURCE_MASK_INTERLEAVE bits.
>> + */
>> +static void
>> +nv_cursor_convert_cursor(uint32_t *src, void *dst, int src_stride,
>> +                      int dst_stride, int bpp, uint32_t fg, uint32_t bg)
>> +{
>> +     int width = min(src_stride, dst_stride);
>> +     uint32_t b, m, pxval;
>> +     int i, j, k;
>> +
>> +     for (i = 0; i < width; i++) {
>> +             for (j = 0; j < width / SOURCE_MASK_INTERLEAVE; j++) {
>> +                     int src_off = i*src_stride/SOURCE_MASK_INTERLEAVE + j;
>> +                     int dst_off = i*dst_stride + j*SOURCE_MASK_INTERLEAVE;
>> +
>> +                     b = src[2*src_off];
>> +                     m = src[2*src_off + 1];
>> +
>> +                     for (k = 0; k < SOURCE_MASK_INTERLEAVE; k++) {
>> +                             pxval = TRANSPARENT_PIXEL;
>> +#if X_BYTE_ORDER == X_BIG_ENDIAN
>> +                             if (m & 0x80000000)
>> +                                     pxval = (b & 0x80000000) ? fg : bg;
>> +                             b <<= 1;
>> +                             m <<= 1;
>> +#else
>> +                             if (m & 1)
>> +                                     pxval = (b & 1) ? fg : bg;
>> +                             b >>= 1;
>> +                             m >>= 1;
>> +#endif
>> +                             if (bpp == 32)
>> +                                     ((uint32_t *)dst)[dst_off + k] = pxval;
>> +                             else
>> +                                     ((uint16_t *)dst)[dst_off + k] = pxval;
>> +                     }
>> +             }
>> +     }
>> +}
>> +
>
> I'm quite sure that, without UMS, this function doesn't make sense
> anymore, you could leave this fun for the X server (we can use the
> load_cursor_argb hook even on the cards we don't advertise ARGB
> support). As a bonus that would probably solve Craig's rotated cursor
> issue.
>
>> [...]
>> diff --git a/src/nv_setup.c b/src/nv_setup.c
>> deleted file mode 100644
>> index f0478ca..0000000
>> --- a/src/nv_setup.c
>> +++ /dev/null
>> [...]
>> -     pNv->alphaCursor = (pNv->NVArch >= 0x11);
>> -
>> -     pNv->twoHeads = (pNv->Architecture >= NV_ARCH_10) &&
>> -                     (implementation != CHIPSET_NV10) &&
>> -                     (implementation != CHIPSET_NV15) &&
>> -                     (implementation != CHIPSET_NFORCE) &&
>> -                     (implementation != CHIPSET_NV20);
>> -
>> -     pNv->gf4_disp_arch = pNv->twoHeads && implementation != CHIPSET_NV11;
>> -
>> -     /* nv30 and nv35 have two stage PLLs, but use only one register; they are dealt with separately */
>> -     pNv->two_reg_pll = (implementation == CHIPSET_NV31) ||
>> -                        (implementation == CHIPSET_NV36) ||
>> -                        (pNv->Architecture >= NV_ARCH_40);
>> -
>> -     pNv->WaitVSyncPossible = (pNv->Architecture >= NV_ARCH_10) &&
>> -                              (implementation != CHIPSET_NV10);
>> -
>
> The accel code still has some bogus checks for WaitVSyncPossible, and
> bad things will happen if it's left uninitialized. Anyway, it would be
> nice to kill all this crap from NVRec.
>
>> -     pNv->BlendingPossible = ((pNv->Chipset & 0xffff) > CHIPSET_NV04);
>> [...]
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>
>

Re: Removal of Non-KMS support

[Maarten Maathuis]

It should be Acked-by (notice the lack of capital b):

Acked-by: Maarten Maathuis <madman2003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

And curro_ == Francisco Jerez, i was thinking in irc mode.

On Wed, Jan 6, 2010 at 11:16 PM, Maarten Maathuis <madman2003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I had a quick look, and i have nothing to add. I must say a signed off
> is inappropriate here, since we are neither the original copyright
> holder or any of the subsequent "gateways". Depending on the level of
> checking either an acked-by or reviewed-by is the right thing to do.
> Since i did not check the patch line by line, and only agree with the
> intention of the patch:
>
> Acked-By: Maarten Maathuis <madman2003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Assuming curro_ concerns are dealt with.
>
> On Wed, Jan 6, 2010 at 9:59 PM, Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org> wrote:
>> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> I did a very quick pass at removing all the non-KMS support from the
>>> DDX.  It's tested on G80 but nowhere else currently, I thought some
>>> discussion would be a good idea rather than just ripping it out :)
>>>
>>> The non-KMS paths are messy, and lets face it, rotting badly.  IMO the
>>> KMS code is stable enough now that we can continue without the UMS
>>> crutch, and indeed, the KMS code supports a lot more chipsets
>>> (particularly on GF8 and up) than the UMS code ever will.
>>>
>>> I've left the Xv overlay code intact, but ifdef'd out.  I want to bring
>>> support back with KMS enabled (thinking of older chipsets where the
>>> blitter sucks), so it made sense to leave the old code there for now.
>>>
>>> So, who has some Signed-off-by's :)
>>
>> I'm very happy that we're finally getting rid of this :), besides a few
>> comments, you got my blessing:
>> Signed-off-by: Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
>>
>>>
>>> Ben.
>>>
>>>
>>> _______________________________________________
>>> Nouveau mailing list
>>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>>
>> Some snips from the patch in question:
>>
>>> [...]
>>> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
>>> index e37e7c1..3d2df8d 100644
>>> --- a/src/drmmode_display.c
>>> +++ b/src/drmmode_display.c
>>> [...]
>>> +#define SOURCE_MASK_INTERLEAVE 32
>>> +#define TRANSPARENT_PIXEL   0
>>> +
>>> +/*
>>> + * Convert a source/mask bitmap cursor to an ARGB cursor, clipping or
>>> + * padding as necessary. source/mask are assumed to be alternated each
>>> + * SOURCE_MASK_INTERLEAVE bits.
>>> + */
>>> +static void
>>> +nv_cursor_convert_cursor(uint32_t *src, void *dst, int src_stride,
>>> +                      int dst_stride, int bpp, uint32_t fg, uint32_t bg)
>>> +{
>>> +     int width = min(src_stride, dst_stride);
>>> +     uint32_t b, m, pxval;
>>> +     int i, j, k;
>>> +
>>> +     for (i = 0; i < width; i++) {
>>> +             for (j = 0; j < width / SOURCE_MASK_INTERLEAVE; j++) {
>>> +                     int src_off = i*src_stride/SOURCE_MASK_INTERLEAVE + j;
>>> +                     int dst_off = i*dst_stride + j*SOURCE_MASK_INTERLEAVE;
>>> +
>>> +                     b = src[2*src_off];
>>> +                     m = src[2*src_off + 1];
>>> +
>>> +                     for (k = 0; k < SOURCE_MASK_INTERLEAVE; k++) {
>>> +                             pxval = TRANSPARENT_PIXEL;
>>> +#if X_BYTE_ORDER == X_BIG_ENDIAN
>>> +                             if (m & 0x80000000)
>>> +                                     pxval = (b & 0x80000000) ? fg : bg;
>>> +                             b <<= 1;
>>> +                             m <<= 1;
>>> +#else
>>> +                             if (m & 1)
>>> +                                     pxval = (b & 1) ? fg : bg;
>>> +                             b >>= 1;
>>> +                             m >>= 1;
>>> +#endif
>>> +                             if (bpp == 32)
>>> +                                     ((uint32_t *)dst)[dst_off + k] = pxval;
>>> +                             else
>>> +                                     ((uint16_t *)dst)[dst_off + k] = pxval;
>>> +                     }
>>> +             }
>>> +     }
>>> +}
>>> +
>>
>> I'm quite sure that, without UMS, this function doesn't make sense
>> anymore, you could leave this fun for the X server (we can use the
>> load_cursor_argb hook even on the cards we don't advertise ARGB
>> support). As a bonus that would probably solve Craig's rotated cursor
>> issue.
>>
>>> [...]
>>> diff --git a/src/nv_setup.c b/src/nv_setup.c
>>> deleted file mode 100644
>>> index f0478ca..0000000
>>> --- a/src/nv_setup.c
>>> +++ /dev/null
>>> [...]
>>> -     pNv->alphaCursor = (pNv->NVArch >= 0x11);
>>> -
>>> -     pNv->twoHeads = (pNv->Architecture >= NV_ARCH_10) &&
>>> -                     (implementation != CHIPSET_NV10) &&
>>> -                     (implementation != CHIPSET_NV15) &&
>>> -                     (implementation != CHIPSET_NFORCE) &&
>>> -                     (implementation != CHIPSET_NV20);
>>> -
>>> -     pNv->gf4_disp_arch = pNv->twoHeads && implementation != CHIPSET_NV11;
>>> -
>>> -     /* nv30 and nv35 have two stage PLLs, but use only one register; they are dealt with separately */
>>> -     pNv->two_reg_pll = (implementation == CHIPSET_NV31) ||
>>> -                        (implementation == CHIPSET_NV36) ||
>>> -                        (pNv->Architecture >= NV_ARCH_40);
>>> -
>>> -     pNv->WaitVSyncPossible = (pNv->Architecture >= NV_ARCH_10) &&
>>> -                              (implementation != CHIPSET_NV10);
>>> -
>>
>> The accel code still has some bogus checks for WaitVSyncPossible, and
>> bad things will happen if it's left uninitialized. Anyway, it would be
>> nice to kill all this crap from NVRec.
>>
>>> -     pNv->BlendingPossible = ((pNv->Chipset & 0xffff) > CHIPSET_NV04);
>>> [...]
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>>
>>
>

Re: Removal of Non-KMS support

[Ben Skeggs]

On Wed, 2010-01-06 at 21:59 +0100, Francisco Jerez wrote:
> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
> > I did a very quick pass at removing all the non-KMS support from the
> > DDX.  It's tested on G80 but nowhere else currently, I thought some
> > discussion would be a good idea rather than just ripping it out :)
> >
> > The non-KMS paths are messy, and lets face it, rotting badly.  IMO the
> > KMS code is stable enough now that we can continue without the UMS
> > crutch, and indeed, the KMS code supports a lot more chipsets
> > (particularly on GF8 and up) than the UMS code ever will.
> >
> > I've left the Xv overlay code intact, but ifdef'd out.  I want to bring
> > support back with KMS enabled (thinking of older chipsets where the
> > blitter sucks), so it made sense to leave the old code there for now.
> >
> > So, who has some Signed-off-by's :)
> 
> I'm very happy that we're finally getting rid of this :), besides a few
> comments, you got my blessing:
> Signed-off-by: Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
> 
> >
> > Ben.
> >
> >
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> > http://lists.freedesktop.org/mailman/listinfo/nouveau
> 
> Some snips from the patch in question:
> 
> > [...]
> > diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> > index e37e7c1..3d2df8d 100644
> > --- a/src/drmmode_display.c
> > +++ b/src/drmmode_display.c
> > [...]
> > +#define SOURCE_MASK_INTERLEAVE 32
> > +#define TRANSPARENT_PIXEL   0
> > +
> > +/*
> > + * Convert a source/mask bitmap cursor to an ARGB cursor, clipping or
> > + * padding as necessary. source/mask are assumed to be alternated each
> > + * SOURCE_MASK_INTERLEAVE bits.
> > + */
> > +static void
> > +nv_cursor_convert_cursor(uint32_t *src, void *dst, int src_stride,
> > +			 int dst_stride, int bpp, uint32_t fg, uint32_t bg)
> > +{
> > +	int width = min(src_stride, dst_stride);
> > +	uint32_t b, m, pxval;
> > +	int i, j, k;
> > +
> > +	for (i = 0; i < width; i++) {
> > +		for (j = 0; j < width / SOURCE_MASK_INTERLEAVE; j++) {
> > +			int src_off = i*src_stride/SOURCE_MASK_INTERLEAVE + j;
> > +			int dst_off = i*dst_stride + j*SOURCE_MASK_INTERLEAVE;
> > +
> > +			b = src[2*src_off];
> > +			m = src[2*src_off + 1];
> > +
> > +			for (k = 0; k < SOURCE_MASK_INTERLEAVE; k++) {
> > +				pxval = TRANSPARENT_PIXEL;
> > +#if X_BYTE_ORDER == X_BIG_ENDIAN
> > +				if (m & 0x80000000)
> > +					pxval = (b & 0x80000000) ? fg : bg;
> > +				b <<= 1;
> > +				m <<= 1;
> > +#else
> > +				if (m & 1)
> > +					pxval = (b & 1) ? fg : bg;
> > +				b >>= 1;
> > +				m >>= 1;
> > +#endif
> > +				if (bpp == 32)
> > +					((uint32_t *)dst)[dst_off + k] = pxval;
> > +				else
> > +					((uint16_t *)dst)[dst_off + k] = pxval;
> > +			}
> > +		}
> > +	}
> > +}
> > +
> 
> I'm quite sure that, without UMS, this function doesn't make sense
> anymore, you could leave this fun for the X server (we can use the
> load_cursor_argb hook even on the cards we don't advertise ARGB
> support). As a bonus that would probably solve Craig's rotated cursor
> issue.
Right, there's probably a lot of other things laying around that aren't
strictly necessary anymore too.  I guess we can just remove them as we
find them.

> 
> > [...]
> > diff --git a/src/nv_setup.c b/src/nv_setup.c
> > deleted file mode 100644
> > index f0478ca..0000000
> > --- a/src/nv_setup.c
> > +++ /dev/null
> > [...]
> > -	pNv->alphaCursor = (pNv->NVArch >= 0x11);
> > -
> > -	pNv->twoHeads = (pNv->Architecture >= NV_ARCH_10) &&
> > -			(implementation != CHIPSET_NV10) &&
> > -			(implementation != CHIPSET_NV15) &&
> > -			(implementation != CHIPSET_NFORCE) &&
> > -			(implementation != CHIPSET_NV20);
> > -
> > -	pNv->gf4_disp_arch = pNv->twoHeads && implementation != CHIPSET_NV11;
> > -
> > -	/* nv30 and nv35 have two stage PLLs, but use only one register; they are dealt with separately */
> > -	pNv->two_reg_pll = (implementation == CHIPSET_NV31) ||
> > -			   (implementation == CHIPSET_NV36) ||
> > -			   (pNv->Architecture >= NV_ARCH_40);
> > -
> > -	pNv->WaitVSyncPossible = (pNv->Architecture >= NV_ARCH_10) &&
> > -				 (implementation != CHIPSET_NV10);
> > -
> 
> The accel code still has some bogus checks for WaitVSyncPossible, and
> bad things will happen if it's left uninitialized. Anyway, it would be
> nice to kill all this crap from NVRec.
Oops, I did indeed miss a couple, thanks :)

> 
> > -	pNv->BlendingPossible = ((pNv->Chipset & 0xffff) > CHIPSET_NV04);
> > [...]

Re: Removal of Non-KMS support

[Xavier]

On Wed, Jan 6, 2010 at 9:59 PM, Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org> wrote:
>> [...]
>> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
>> index e37e7c1..3d2df8d 100644
>> --- a/src/drmmode_display.c
>> +++ b/src/drmmode_display.c
>> [...]
>> +#define SOURCE_MASK_INTERLEAVE 32
>> +#define TRANSPARENT_PIXEL   0
>> +
>> +/*
>> + * Convert a source/mask bitmap cursor to an ARGB cursor, clipping or
>> + * padding as necessary. source/mask are assumed to be alternated each
>> + * SOURCE_MASK_INTERLEAVE bits.
>> + */
>> +static void
>> +nv_cursor_convert_cursor(uint32_t *src, void *dst, int src_stride,
>> +                      int dst_stride, int bpp, uint32_t fg, uint32_t bg)
>> +{
>> +     int width = min(src_stride, dst_stride);
>> +     uint32_t b, m, pxval;
>> +     int i, j, k;
>> +
>> +     for (i = 0; i < width; i++) {
>> +             for (j = 0; j < width / SOURCE_MASK_INTERLEAVE; j++) {
>> +                     int src_off = i*src_stride/SOURCE_MASK_INTERLEAVE + j;
>> +                     int dst_off = i*dst_stride + j*SOURCE_MASK_INTERLEAVE;
>> +
>> +                     b = src[2*src_off];
>> +                     m = src[2*src_off + 1];
>> +
>> +                     for (k = 0; k < SOURCE_MASK_INTERLEAVE; k++) {
>> +                             pxval = TRANSPARENT_PIXEL;
>> +#if X_BYTE_ORDER == X_BIG_ENDIAN
>> +                             if (m & 0x80000000)
>> +                                     pxval = (b & 0x80000000) ? fg : bg;
>> +                             b <<= 1;
>> +                             m <<= 1;
>> +#else
>> +                             if (m & 1)
>> +                                     pxval = (b & 1) ? fg : bg;
>> +                             b >>= 1;
>> +                             m >>= 1;
>> +#endif
>> +                             if (bpp == 32)
>> +                                     ((uint32_t *)dst)[dst_off + k] = pxval;
>> +                             else
>> +                                     ((uint16_t *)dst)[dst_off + k] = pxval;
>> +                     }
>> +             }
>> +     }
>> +}
>> +
>
> I'm quite sure that, without UMS, this function doesn't make sense
> anymore, you could leave this fun for the X server (we can use the
> load_cursor_argb hook even on the cards we don't advertise ARGB
> support). As a bonus that would probably solve Craig's rotated cursor
> issue.
>

This patch has been pushed 2 days ago but that function is apparently
still there.
If it could solve the rotated cursor issue, could you provide a patch
to kill that function ?
A second user reported it :
http://bbs.archlinux.org/viewtopic.php?pid=687656#p687656

Re: Removal of Non-KMS support

[Ben Skeggs]

On Wed, 2010-01-13 at 22:22 +0100, Xavier wrote:
> On Wed, Jan 6, 2010 at 9:59 PM, Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org> wrote:
> >> [...]
> >> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> >> index e37e7c1..3d2df8d 100644
> >> --- a/src/drmmode_display.c
> >> +++ b/src/drmmode_display.c
> >> [...]
> >> +#define SOURCE_MASK_INTERLEAVE 32
> >> +#define TRANSPARENT_PIXEL   0
> >> +
> >> +/*
> >> + * Convert a source/mask bitmap cursor to an ARGB cursor, clipping or
> >> + * padding as necessary. source/mask are assumed to be alternated each
> >> + * SOURCE_MASK_INTERLEAVE bits.
> >> + */
> >> +static void
> >> +nv_cursor_convert_cursor(uint32_t *src, void *dst, int src_stride,
> >> +                      int dst_stride, int bpp, uint32_t fg, uint32_t bg)
> >> +{
> >> +     int width = min(src_stride, dst_stride);
> >> +     uint32_t b, m, pxval;
> >> +     int i, j, k;
> >> +
> >> +     for (i = 0; i < width; i++) {
> >> +             for (j = 0; j < width / SOURCE_MASK_INTERLEAVE; j++) {
> >> +                     int src_off = i*src_stride/SOURCE_MASK_INTERLEAVE + j;
> >> +                     int dst_off = i*dst_stride + j*SOURCE_MASK_INTERLEAVE;
> >> +
> >> +                     b = src[2*src_off];
> >> +                     m = src[2*src_off + 1];
> >> +
> >> +                     for (k = 0; k < SOURCE_MASK_INTERLEAVE; k++) {
> >> +                             pxval = TRANSPARENT_PIXEL;
> >> +#if X_BYTE_ORDER == X_BIG_ENDIAN
> >> +                             if (m & 0x80000000)
> >> +                                     pxval = (b & 0x80000000) ? fg : bg;
> >> +                             b <<= 1;
> >> +                             m <<= 1;
> >> +#else
> >> +                             if (m & 1)
> >> +                                     pxval = (b & 1) ? fg : bg;
> >> +                             b >>= 1;
> >> +                             m >>= 1;
> >> +#endif
> >> +                             if (bpp == 32)
> >> +                                     ((uint32_t *)dst)[dst_off + k] = pxval;
> >> +                             else
> >> +                                     ((uint16_t *)dst)[dst_off + k] = pxval;
> >> +                     }
> >> +             }
> >> +     }
> >> +}
> >> +
> >
> > I'm quite sure that, without UMS, this function doesn't make sense
> > anymore, you could leave this fun for the X server (we can use the
> > load_cursor_argb hook even on the cards we don't advertise ARGB
> > support). As a bonus that would probably solve Craig's rotated cursor
> > issue.
> >
> 
> This patch has been pushed 2 days ago but that function is apparently
> still there.
> If it could solve the rotated cursor issue, could you provide a patch
> to kill that function ?
> A second user reported it :
> http://bbs.archlinux.org/viewtopic.php?pid=687656#p687656
It's on the list.  I didn't do it yet as I hadn't gotten around to
testing on hw where it could possible break things :)

Ben.

Re: Removal of Non-KMS support

[Pekka Paalanen]

On Wed, 06 Jan 2010 15:32:30 +1000
Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> I did a very quick pass at removing all the non-KMS support from
> the DDX.  It's tested on G80 but nowhere else currently, I
> thought some discussion would be a good idea rather than just
> ripping it out :)
> 
> The non-KMS paths are messy, and lets face it, rotting badly.
> IMO the KMS code is stable enough now that we can continue
> without the UMS crutch, and indeed, the KMS code supports a lot
> more chipsets (particularly on GF8 and up) than the UMS code ever
> will.

Considering that any BSD will not have KMS for quite some time
(do they?), this sounds very cruel. Is it really such a big
pain to keep the code around?

OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
and TTM to BSDs. How much more will it cost to BSDs to add KMS
to the list of mandatory kernel features... rnoland and others,
any comments?

-- 
Pekka Paalanen
http://www.iki.fi/pq/

Re: Removal of Non-KMS support

[Ben Skeggs]

On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote:
> On Wed, 06 Jan 2010 15:32:30 +1000
> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > I did a very quick pass at removing all the non-KMS support from
> > the DDX.  It's tested on G80 but nowhere else currently, I
> > thought some discussion would be a good idea rather than just
> > ripping it out :)
> > 
> > The non-KMS paths are messy, and lets face it, rotting badly.
> > IMO the KMS code is stable enough now that we can continue
> > without the UMS crutch, and indeed, the KMS code supports a lot
> > more chipsets (particularly on GF8 and up) than the UMS code ever
> > will.
> 
> Considering that any BSD will not have KMS for quite some time
> (do they?), this sounds very cruel. Is it really such a big
> pain to keep the code around?
It's inconvenient in a lot of ways to keep around, especially if it
means you have to try and keep it working across changes.  If they want
to ship it, they can branch off before it's removed and pull fixes
across if they need it.  As it is the current DDX won't work for them
anyway, so I guess they've already done this...

> 
> OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
> and TTM to BSDs. How much more will it cost to BSDs to add KMS
> to the list of mandatory kernel features... rnoland and others,
> any comments?
> 

Re: Removal of Non-KMS support

[Robert Noland]

On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote:
> On Wed, 06 Jan 2010 15:32:30 +1000
> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > I did a very quick pass at removing all the non-KMS support from
> > the DDX.  It's tested on G80 but nowhere else currently, I
> > thought some discussion would be a good idea rather than just
> > ripping it out :)
> > 
> > The non-KMS paths are messy, and lets face it, rotting badly.
> > IMO the KMS code is stable enough now that we can continue
> > without the UMS crutch, and indeed, the KMS code supports a lot
> > more chipsets (particularly on GF8 and up) than the UMS code ever
> > will.
> 
> Considering that any BSD will not have KMS for quite some time
> (do they?), this sounds very cruel. Is it really such a big
> pain to keep the code around?
> 
> OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
> and TTM to BSDs. How much more will it cost to BSDs to add KMS
> to the list of mandatory kernel features... rnoland and others,
> any comments?

Well, I would prefer that this not get ripped out, honestly.  My current
big project queue is GEM, TTM and finally KMS.  I think that I finally
have a handle on how I'm going to finish implementing GEM now.  TTM, I
have started on, but mostly what I have now is stubs, so until I'm
deeper into porting/re-writing the code I don't have a clear plan.  I
think that it will likely be handled in much the same way as GEM, but
I'm sure there will be new things to sort out.

I've looked at KMS less than any of the other stuff so far really, but
the API is designed around linux and while much of the code to interact
with the hardware should be fairly easy to port I think, I'm really not
clear how the current API can/will tie into our (BSD) console code.  So,
basically what I'm saying here is that I don't currently have a plan for
how I'm going to deal with KMS, where I do at least have fairly clear
plans for GEM and hopefully TTM.

Unfortunately, the amount of time that I have available to work on stuff
has just been dramatically reduced, at least for the time being.

robert.

-- 
Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org>
2Hip Networks

Re: Removal of Non-KMS support

[Maarten Maathuis]

It's going to get ripped out at some point, the question is how long
do you expect to need it?

Depending on that estimate you can determine if it's worth it to keep
(there's no point in letting it bitrot all the way).

And for testing, you do know that you can write test applications that
can test various features to see if everything works as intended,
without having to make X work first.

Maarten.

On Thu, Jan 7, 2010 at 2:59 AM, Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org> wrote:
> On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote:
>> On Wed, 06 Jan 2010 15:32:30 +1000
>> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> > I did a very quick pass at removing all the non-KMS support from
>> > the DDX.  It's tested on G80 but nowhere else currently, I
>> > thought some discussion would be a good idea rather than just
>> > ripping it out :)
>> >
>> > The non-KMS paths are messy, and lets face it, rotting badly.
>> > IMO the KMS code is stable enough now that we can continue
>> > without the UMS crutch, and indeed, the KMS code supports a lot
>> > more chipsets (particularly on GF8 and up) than the UMS code ever
>> > will.
>>
>> Considering that any BSD will not have KMS for quite some time
>> (do they?), this sounds very cruel. Is it really such a big
>> pain to keep the code around?
>>
>> OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
>> and TTM to BSDs. How much more will it cost to BSDs to add KMS
>> to the list of mandatory kernel features... rnoland and others,
>> any comments?
>
> Well, I would prefer that this not get ripped out, honestly.  My current
> big project queue is GEM, TTM and finally KMS.  I think that I finally
> have a handle on how I'm going to finish implementing GEM now.  TTM, I
> have started on, but mostly what I have now is stubs, so until I'm
> deeper into porting/re-writing the code I don't have a clear plan.  I
> think that it will likely be handled in much the same way as GEM, but
> I'm sure there will be new things to sort out.
>
> I've looked at KMS less than any of the other stuff so far really, but
> the API is designed around linux and while much of the code to interact
> with the hardware should be fairly easy to port I think, I'm really not
> clear how the current API can/will tie into our (BSD) console code.  So,
> basically what I'm saying here is that I don't currently have a plan for
> how I'm going to deal with KMS, where I do at least have fairly clear
> plans for GEM and hopefully TTM.
>
> Unfortunately, the amount of time that I have available to work on stuff
> has just been dramatically reduced, at least for the time being.
>
> robert.
>
> --
> Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org>
> 2Hip Networks
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>

Re: Removal of Non-KMS support

[Ben Skeggs]

On Thu, 2010-01-07 at 09:56 +0100, Maarten Maathuis wrote:
> It's going to get ripped out at some point, the question is how long
> do you expect to need it?
It's not like the code is going anywhere too, it's in git :)  It
wouldn't be difficult to keep a branch from, say, now, and cherry pick
the changes to the accel code across if there are any.

Ben.
> 
> Depending on that estimate you can determine if it's worth it to keep
> (there's no point in letting it bitrot all the way).
> 
> And for testing, you do know that you can write test applications that
> can test various features to see if everything works as intended,
> without having to make X work first.
> 
> Maarten.
> 
> On Thu, Jan 7, 2010 at 2:59 AM, Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org> wrote:
> > On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote:
> >> On Wed, 06 Jan 2010 15:32:30 +1000
> >> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >> > I did a very quick pass at removing all the non-KMS support from
> >> > the DDX.  It's tested on G80 but nowhere else currently, I
> >> > thought some discussion would be a good idea rather than just
> >> > ripping it out :)
> >> >
> >> > The non-KMS paths are messy, and lets face it, rotting badly.
> >> > IMO the KMS code is stable enough now that we can continue
> >> > without the UMS crutch, and indeed, the KMS code supports a lot
> >> > more chipsets (particularly on GF8 and up) than the UMS code ever
> >> > will.
> >>
> >> Considering that any BSD will not have KMS for quite some time
> >> (do they?), this sounds very cruel. Is it really such a big
> >> pain to keep the code around?
> >>
> >> OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
> >> and TTM to BSDs. How much more will it cost to BSDs to add KMS
> >> to the list of mandatory kernel features... rnoland and others,
> >> any comments?
> >
> > Well, I would prefer that this not get ripped out, honestly.  My current
> > big project queue is GEM, TTM and finally KMS.  I think that I finally
> > have a handle on how I'm going to finish implementing GEM now.  TTM, I
> > have started on, but mostly what I have now is stubs, so until I'm
> > deeper into porting/re-writing the code I don't have a clear plan.  I
> > think that it will likely be handled in much the same way as GEM, but
> > I'm sure there will be new things to sort out.
> >
> > I've looked at KMS less than any of the other stuff so far really, but
> > the API is designed around linux and while much of the code to interact
> > with the hardware should be fairly easy to port I think, I'm really not
> > clear how the current API can/will tie into our (BSD) console code.  So,
> > basically what I'm saying here is that I don't currently have a plan for
> > how I'm going to deal with KMS, where I do at least have fairly clear
> > plans for GEM and hopefully TTM.
> >
> > Unfortunately, the amount of time that I have available to work on stuff
> > has just been dramatically reduced, at least for the time being.
> >
> > robert.
> >
> > --
> > Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org>
> > 2Hip Networks
> >
> > _______________________________________________
> > 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

Re: Removal of Non-KMS support

[Maarten Maathuis]

On Thu, Jan 7, 2010 at 11:23 AM, Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, 2010-01-07 at 09:56 +0100, Maarten Maathuis wrote:
>> It's going to get ripped out at some point, the question is how long
>> do you expect to need it?
> It's not like the code is going anywhere too, it's in git :)  It
> wouldn't be difficult to keep a branch from, say, now, and cherry pick
> the changes to the accel code across if there are any.

Sounds reasonable to me.

>
> Ben.
>>
>> Depending on that estimate you can determine if it's worth it to keep
>> (there's no point in letting it bitrot all the way).
>>
>> And for testing, you do know that you can write test applications that
>> can test various features to see if everything works as intended,
>> without having to make X work first.
>>
>> Maarten.
>>
>> On Thu, Jan 7, 2010 at 2:59 AM, Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org> wrote:
>> > On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote:
>> >> On Wed, 06 Jan 2010 15:32:30 +1000
>> >> Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>
>> >> > I did a very quick pass at removing all the non-KMS support from
>> >> > the DDX.  It's tested on G80 but nowhere else currently, I
>> >> > thought some discussion would be a good idea rather than just
>> >> > ripping it out :)
>> >> >
>> >> > The non-KMS paths are messy, and lets face it, rotting badly.
>> >> > IMO the KMS code is stable enough now that we can continue
>> >> > without the UMS crutch, and indeed, the KMS code supports a lot
>> >> > more chipsets (particularly on GF8 and up) than the UMS code ever
>> >> > will.
>> >>
>> >> Considering that any BSD will not have KMS for quite some time
>> >> (do they?), this sounds very cruel. Is it really such a big
>> >> pain to keep the code around?
>> >>
>> >> OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
>> >> and TTM to BSDs. How much more will it cost to BSDs to add KMS
>> >> to the list of mandatory kernel features... rnoland and others,
>> >> any comments?
>> >
>> > Well, I would prefer that this not get ripped out, honestly.  My current
>> > big project queue is GEM, TTM and finally KMS.  I think that I finally
>> > have a handle on how I'm going to finish implementing GEM now.  TTM, I
>> > have started on, but mostly what I have now is stubs, so until I'm
>> > deeper into porting/re-writing the code I don't have a clear plan.  I
>> > think that it will likely be handled in much the same way as GEM, but
>> > I'm sure there will be new things to sort out.
>> >
>> > I've looked at KMS less than any of the other stuff so far really, but
>> > the API is designed around linux and while much of the code to interact
>> > with the hardware should be fairly easy to port I think, I'm really not
>> > clear how the current API can/will tie into our (BSD) console code.  So,
>> > basically what I'm saying here is that I don't currently have a plan for
>> > how I'm going to deal with KMS, where I do at least have fairly clear
>> > plans for GEM and hopefully TTM.
>> >
>> > Unfortunately, the amount of time that I have available to work on stuff
>> > has just been dramatically reduced, at least for the time being.
>> >
>> > robert.
>> >
>> > --
>> > Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org>
>> > 2Hip Networks
>> >
>> > _______________________________________________
>> > 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
>
>
>

Porting nouveau/ttm/drm to FreeBSD/OpenSolaris

["C. Bergström"]

Hi all,

One of our (PathScale) engineers is planning to port nouveau and all 
dependencies to OpenSolaris.  We have two routes we can take and would 
like some feedback from the community.

1) There's an existing drm without ttm that was done by the FreeBSD 
developers.  Would anyone from the fbsd team like to go over some of the 
trouble they've had in porting ttm?

2) The engineer doing the work is much more familiar with Intel GEM and 
has said the following (which I don't honestly know if it's true or not)
    a. Intel GEM surely will continue to be supported
    b. It's already available on OpenSolaris
    c. More portable than ttm
    d. GEM doesn't have support for nvidia cards and is missing some 
important features.  (For OpenSolaris he says those can be added and is 
less effort than porting ttm)
    e. Is probably better performance compared to ttm

As some of you may know our interest is currently only in executing 
cuda-like kernels.  If it doesn't add a substantial amount of effort we 
would like our efforts to also benefit others.  (Specifically fbsd and 
the graphics contexts)

nouveau itself should be relatively easy to port, but what information 
do others have with regards to the surrounding dependencies.

Thanks!

./Christopher

Re: Porting nouveau/ttm/drm to FreeBSD/OpenSolaris

[Krzysztof Smiechowicz]

C. Bergström pisze:
> Hi all,
> 

Hi Christopher

> nouveau itself should be relatively easy to port, but what information 
> do others have with regards to the surrounding dependencies.

I can give you some information my work porting the nouveau/drm/ttm to 
AROS (http://www.aros.org/). AROS is AmigaOS clone and it's very very 
very far in terms of API and concepts from Linux kernel so I think it's 
a good example to talk about portability.

Currently my work is only focused on 3D part, not touching the 2D part 
at all. Generally it took me about 1,5 months of evenings to port the 
current (sources from December 2009) nouvea/drm/ttm/libdrm/nouvea 
gallium driver to AROS (I would call it alpha version of the port 
though) however I have never been working with graphics or graphics 
drivers before.

In terms of portability I would rate the modules in following order 
(starting from most portable)

nouveau gallium 3D drivers
nouveau NV0X-NV40 drm drivers
libdrm
nouveau "common code" (files named nouveau_XXX)
drm "common code" (files named drm_XXX)
nouveau NV50 drm driver
ttm

Basically the only module that does not seem to be specially written 
with portability in mind and has a lot of Linux dependencies it ttm. I 
implemented some of those dependencies in my AROS port (reference 
counting, atomics, spin locks) and disabled some others (swapping 
support, work queues)

If you are interested in any specific topic, please let me know :)

Best regards,
Krzysztof

Re: Porting nouveau/ttm/drm to FreeBSD/OpenSolaris

["C. Bergström"]

Krzysztof Smiechowicz wrote:
> C. Bergström pisze:
>> Hi all,
>>
>
> Hi Christopher
>
>> nouveau itself should be relatively easy to port, but what 
>> information do others have with regards to the surrounding dependencies.
>
> I can give you some information my work porting the nouveau/drm/ttm to 
> AROS (http://www.aros.org/). AROS is AmigaOS clone and it's very very 
> very far in terms of API and concepts from Linux kernel so I think 
> it's a good example to talk about portability.
>
> Currently my work is only focused on 3D part, not touching the 2D part 
> at all. Generally it took me about 1,5 months of evenings to port the 
> current (sources from December 2009) nouvea/drm/ttm/libdrm/nouvea 
> gallium driver to AROS (I would call it alpha version of the port 
> though) however I have never been working with graphics or graphics 
> drivers before.
>
> In terms of portability I would rate the modules in following order 
> (starting from most portable)
>
> nouveau gallium 3D drivers
> nouveau NV0X-NV40 drm drivers
> libdrm
> nouveau "common code" (files named nouveau_XXX)
> drm "common code" (files named drm_XXX)
> nouveau NV50 drm driver
> ttm
>
> Basically the only module that does not seem to be specially written 
> with portability in mind and has a lot of Linux dependencies it ttm. I 
> implemented some of those dependencies in my AROS port (reference 
> counting, atomics, spin locks) and disabled some others (swapping 
> support, work queues)
>
> If you are interested in any specific topic, please let me know :)
1.5 months seems to be pretty fast work, but I think disabling some of 
those portions of the code probably helped.  For us we will be focusing 
only on libdrm, drm "common code" nouveau NV50 drm driver and a memory 
manager.  There also already an older port of drm to OpenSolaris so 
that's mostly a forward port.  I've heard others complain about ttm 
repeatedly and thought maybe we can rethink the problem and solve two 
things at once.  I'll have one of our engineers email you directly about 
ttm if we have specific questions.

Thanks

./C


twitter : CTOPathScale

Re: Porting nouveau/ttm/drm to FreeBSD/OpenSolaris

[Robert Noland]

On Sat, 2010-01-23 at 13:25 +0300, "C. Bergström" wrote:
> Hi all,
> 
> One of our (PathScale) engineers is planning to port nouveau and all 
> dependencies to OpenSolaris.  We have two routes we can take and would 
> like some feedback from the community.
> 
> 1) There's an existing drm without ttm that was done by the FreeBSD 
> developers.  Would anyone from the fbsd team like to go over some of the 
> trouble they've had in porting ttm?

That would be me.  The primary issue for me has been that I didn't have
sufficient knowledge of our VM system to interact appropriately.  I
think that I am over that hurdle now, but there is still a lack of any
real documentation on the API, which means deciphering the Linux VM
interactions at least well enough to understand what the intention of
any given function is.

> 2) The engineer doing the work is much more familiar with Intel GEM and 
> has said the following (which I don't honestly know if it's true or not)
>     a. Intel GEM surely will continue to be supported
>     b. It's already available on OpenSolaris
>     c. More portable than ttm
>     d. GEM doesn't have support for nvidia cards and is missing some 
> important features.  (For OpenSolaris he says those can be added and is 
> less effort than porting ttm)

GEM really only deals with system memory, where TTM deals with pools of
memory from either system or device, along with different attributes.
Unfortunately, my time is very limited at the moment, so I'm unsure when
I'll actually get to work on any of this now.

robert.

>     e. Is probably better performance compared to ttm
> 
> As some of you may know our interest is currently only in executing 
> cuda-like kernels.  If it doesn't add a substantial amount of effort we 
> would like our efforts to also benefit others.  (Specifically fbsd and 
> the graphics contexts)
> 
> nouveau itself should be relatively easy to port, but what information 
> do others have with regards to the surrounding dependencies.
> 
> Thanks!
> 
> ./Christopher
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
-- 
Robert Noland <rnoland-4LXSwLOGEL8@public.gmane.org>
2Hip Networks

Re: Porting nouveau/ttm/drm to FreeBSD/OpenSolaris

[Stephane Marchesin]

2010/1/23 "C. Bergström" <cbergstrom-Hl0AACgZOF5l57MIdRCFDg@public.gmane.org>:
> Hi all,
>
> One of our (PathScale) engineers is planning to port nouveau and all
> dependencies to OpenSolaris.  We have two routes we can take and would
> like some feedback from the community.
>
> 1) There's an existing drm without ttm that was done by the FreeBSD
> developers.  Would anyone from the fbsd team like to go over some of the
> trouble they've had in porting ttm?
>
> 2) The engineer doing the work is much more familiar with Intel GEM and
> has said the following (which I don't honestly know if it's true or not)
>    a. Intel GEM surely will continue to be supported
>    b. It's already available on OpenSolaris
>    c. More portable than ttm
>    d. GEM doesn't have support for nvidia cards and is missing some
> important features.  (For OpenSolaris he says those can be added and is
> less effort than porting ttm)
>    e. Is probably better performance compared to ttm
>

How do you plan to handle "real" video memory in GEM? Will you add
support for it in the GEM common code?

Stephane

Re: Porting nouveau/ttm/drm to FreeBSD/OpenSolaris

["C. Bergström"]

Stephane Marchesin wrote:
> 2010/1/23 "C. Bergström" <cbergstrom-Hl0AACgZOF5l57MIdRCFDg@public.gmane.org>:
>   
>> Hi all,
>>
>> One of our (PathScale) engineers is planning to port nouveau and all
>> dependencies to OpenSolaris.  We have two routes we can take and would
>> like some feedback from the community.
>>
>> 1) There's an existing drm without ttm that was done by the FreeBSD
>> developers.  Would anyone from the fbsd team like to go over some of the
>> trouble they've had in porting ttm?
>>
>> 2) The engineer doing the work is much more familiar with Intel GEM and
>> has said the following (which I don't honestly know if it's true or not)
>>    a. Intel GEM surely will continue to be supported
>>    b. It's already available on OpenSolaris
>>    c. More portable than ttm
>>    d. GEM doesn't have support for nvidia cards and is missing some
>> important features.  (For OpenSolaris he says those can be added and is
>> less effort than porting ttm)
>>    e. Is probably better performance compared to ttm
>>
>>     
>
> How do you plan to handle "real" video memory in GEM? Will you add
> support for it in the GEM common code?
>   
Short answer.. If we go with GEM then yes.

Re: Porting nouveau/ttm/drm to FreeBSD/OpenSolaris

[Dave Airlie]

2010/1/23 "C. Bergström" <cbergstrom-Hl0AACgZOF5l57MIdRCFDg@public.gmane.org>:
> Hi all,
>
> One of our (PathScale) engineers is planning to port nouveau and all
> dependencies to OpenSolaris.  We have two routes we can take and would
> like some feedback from the community.
>
> 1) There's an existing drm without ttm that was done by the FreeBSD
> developers.  Would anyone from the fbsd team like to go over some of the
> trouble they've had in porting ttm?
>
> 2) The engineer doing the work is much more familiar with Intel GEM and
> has said the following (which I don't honestly know if it's true or not)
>    a. Intel GEM surely will continue to be supported
>    b. It's already available on OpenSolaris
>    c. More portable than ttm
>    d. GEM doesn't have support for nvidia cards and is missing some
> important features.  (For OpenSolaris he says those can be added and is
> less effort than porting ttm)
>    e. Is probably better performance compared to ttm

I expect your engineer hasn't quite grasped the differences between GEM and TTM.

Intel's GEM code is nearly all contained in the driver, making all the
code generic
and adding the VRAM support stuff to it, is definitely a lot more work
than porting TTM.

There is a reason TTM uses Linux kernel data structures, if your OS
cannot provide
these structures then it will probably require some TTM reworking,
however you don't
need every feature of TTM to get a port mostly working, like swapping
etc are unnecessary
for the initial port.

Dave.

Re: Removal of Non-KMS support

[Xavier]

On Wed, Jan 6, 2010 at 6:32 AM, Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I did a very quick pass at removing all the non-KMS support from the
> DDX.  It's tested on G80 but nowhere else currently, I thought some
> discussion would be a good idea rather than just ripping it out :)
>
> The non-KMS paths are messy, and lets face it, rotting badly.  IMO the
> KMS code is stable enough now that we can continue without the UMS
> crutch, and indeed, the KMS code supports a lot more chipsets
> (particularly on GF8 and up) than the UMS code ever will.
>
> I've left the Xv overlay code intact, but ifdef'd out.  I want to bring
> support back with KMS enabled (thinking of older chipsets where the
> blitter sucks), so it made sense to leave the old code there for now.
>
> So, who has some Signed-off-by's :)
>

That broke exapixmaps=no for me.
I tried to disable exapixmaps temporarily to workaround some
dri2/window resize problems, as suggested by calim.
After reverting "Removal of Non-KMS support", exapixmaps=no worked fine.

Jan  7 17:44:13 xps-m1530 init: Switching to runlevel: 5
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.449485] integrated sync not supported
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.555266] integrated sync not supported
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.664571] [drm] nouveau
0000:01:00.0: Allocating FIFO number 2
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.673371] [drm] nouveau
0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.674075] [TTM] Page number
range to small Need 4503599627369472 pages, range is [0, 65536]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.678391] [drm] nouveau
0000:01:00.0: nouveau_channel_free: freeing fifo 2
Jan  7 17:44:13 xps-m1530 gdm-binary[8150]: WARNING: GdmDisplay:
display lasted 0.309705 seconds
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.723902] integrated sync not supported
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.829683] integrated sync not supported
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.937500] [drm] nouveau
0000:01:00.0: Allocating FIFO number 2
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.945901] [drm] nouveau
0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946061]
=============================================================================
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946064] BUG kmalloc-512:
Poison overwritten
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946066]
-----------------------------------------------------------------------------
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946067]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946070] INFO:
0xffff8801183a6d18-0xffff8801183a6d1f. First byte 0x0 instead of 0x6b
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946081] INFO: Allocated in
nouveau_bo_new+0x5b/0x470 [nouveau] age=272 cpu=1 pid=8156
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946088] INFO: Freed in
nouveau_bo_del_ttm+0x9f/0xd0 [nouveau] age=272 cpu=1 pid=8156
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946091] INFO: Slab
0xffffea0003d4cc50 objects=14 used=11 fp=0xffff8801183a6b68
flags=0x80000000000040c3
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946094] INFO: Object
0xffff8801183a6b68 @offset=2920 fp=0xffff8801183a7918
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946095]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946097] Bytes b4
0xffff8801183a6b58:  75 73 49 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a
usI.....ZZZZZZZZ
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946107]   Object
0xffff8801183a6b68:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946117]   Object
0xffff8801183a6b78:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946126]   Object
0xffff8801183a6b88:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946136]   Object
0xffff8801183a6b98:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946145]   Object
0xffff8801183a6ba8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946155]   Object
0xffff8801183a6bb8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946170]   Object
0xffff8801183a6bc8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946179]   Object
0xffff8801183a6bd8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946187]   Object
0xffff8801183a6be8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946204]   Object
0xffff8801183a6bf8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946214]   Object
0xffff8801183a6c08:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946223]   Object
0xffff8801183a6c18:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946233]   Object
0xffff8801183a6c28:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946243]   Object
0xffff8801183a6c38:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946252]   Object
0xffff8801183a6c48:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6c58:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6c68:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6c78:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6c88:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6c98:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6ca8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6cb8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6cc8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6cd8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6ce8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6cf8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6d08:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6d18:  00 00 00 00 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b
........kkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6d28:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6d38:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6d48:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kkkkkkkkkkkkkkkk
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
0xffff8801183a6d58:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
kkkkkkkkkkkkkkk¥
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  Redzone
0xffff8801183a6d68:  bb bb bb bb bb bb bb bb
»»»»»»»»
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  Padding
0xffff8801183a6da8:  5a 5a 5a 5a 5a 5a 5a 5a
ZZZZZZZZ
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] Pid: 8160, comm: Xorg
Not tainted 2.6.32-nouveau #30
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] Call Trace:
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f5fc1>]
print_trailer+0x101/0x170
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f66e2>]
check_bytes_and_report+0xf2/0x120
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f691e>]
check_object+0x20e/0x260
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f892e>]
__slab_alloc+0x59e/0x7c0
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff812cd5cc>]
? security_inode_alloc+0x1c/0x20
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff81117526>]
? inode_init_always+0x116/0x1c0
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015b4ab>]
? nouveau_bo_new+0x5b/0x470 [nouveau]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f8dd7>]
kmem_cache_alloc+0xb7/0x140
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015b4ab>]
nouveau_bo_new+0x5b/0x470 [nouveau]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015dccf>]
nouveau_gem_new+0x3f/0xd0 [nouveau]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015de99>]
nouveau_gem_ioctl_new+0x139/0x320 [nouveau]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa00ec6ed>]
drm_ioctl+0x17d/0x3a0 [drm]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015dd60>]
? nouveau_gem_ioctl_new+0x0/0x320 [nouveau]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810e6238>]
? mmap_region+0x1f8/0x500
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff8110fc6c>]
vfs_ioctl+0x7c/0xa0
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff8110fda0>]
do_vfs_ioctl+0x80/0x560
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff81303e75>]
? __up_write+0xe5/0x150
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff81110301>]
sys_ioctl+0x81/0xa0
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff8100bf2b>]
system_call_fastpath+0x16/0x1b
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] FIX kmalloc-512:
Restoring 0xffff8801183a6d18-0xffff8801183a6d1f=0x6b
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] FIX kmalloc-512:
Marking all objects used
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.947018] [TTM] Page number
range to small Need 4503599627369472 pages, range is [0, 65536]
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.950986] [drm] nouveau
0000:01:00.0: nouveau_channel_free: freeing fifo 2
Jan  7 17:44:13 xps-m1530 gdm-binary[8150]: WARNING: GdmDisplay:
display lasted 0.270496 seconds
Jan  7 17:44:13 xps-m1530 kernel: [ 5113.987276] integrated sync not supported
Jan  7 17:44:13 xps-m1530 kernel: [ 5114.092992] integrated sync not supported

Re: Removal of Non-KMS support

[Ben Skeggs]

On Thu, 2010-01-07 at 20:49 +0100, Xavier wrote:
> On Wed, Jan 6, 2010 at 6:32 AM, Ben Skeggs <skeggsb@gmail.com> wrote:
> > I did a very quick pass at removing all the non-KMS support from the
> > DDX.  It's tested on G80 but nowhere else currently, I thought some
> > discussion would be a good idea rather than just ripping it out :)
> >
> > The non-KMS paths are messy, and lets face it, rotting badly.  IMO the
> > KMS code is stable enough now that we can continue without the UMS
> > crutch, and indeed, the KMS code supports a lot more chipsets
> > (particularly on GF8 and up) than the UMS code ever will.
> >
> > I've left the Xv overlay code intact, but ifdef'd out.  I want to bring
> > support back with KMS enabled (thinking of older chipsets where the
> > blitter sucks), so it made sense to leave the old code there for now.
> >
> > So, who has some Signed-off-by's :)
> >
> 
> That broke exapixmaps=no for me.
> I tried to disable exapixmaps temporarily to workaround some
> dri2/window resize problems, as suggested by calim.
> After reverting "Removal of Non-KMS support", exapixmaps=no worked fine.
Ah thanks, I didn't even think to test it still worked.  I'll fix that
today, but, that's also something that should be on the list of things
to cull from the DDX soon.

Ben.
> 
> Jan  7 17:44:13 xps-m1530 init: Switching to runlevel: 5
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.449485] integrated sync not supported
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.555266] integrated sync not supported
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.664571] [drm] nouveau
> 0000:01:00.0: Allocating FIFO number 2
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.673371] [drm] nouveau
> 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.674075] [TTM] Page number
> range to small Need 4503599627369472 pages, range is [0, 65536]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.678391] [drm] nouveau
> 0000:01:00.0: nouveau_channel_free: freeing fifo 2
> Jan  7 17:44:13 xps-m1530 gdm-binary[8150]: WARNING: GdmDisplay:
> display lasted 0.309705 seconds
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.723902] integrated sync not supported
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.829683] integrated sync not supported
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.937500] [drm] nouveau
> 0000:01:00.0: Allocating FIFO number 2
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.945901] [drm] nouveau
> 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946061]
> =============================================================================
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946064] BUG kmalloc-512:
> Poison overwritten
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946066]
> -----------------------------------------------------------------------------
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946067]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946070] INFO:
> 0xffff8801183a6d18-0xffff8801183a6d1f. First byte 0x0 instead of 0x6b
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946081] INFO: Allocated in
> nouveau_bo_new+0x5b/0x470 [nouveau] age=272 cpu=1 pid=8156
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946088] INFO: Freed in
> nouveau_bo_del_ttm+0x9f/0xd0 [nouveau] age=272 cpu=1 pid=8156
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946091] INFO: Slab
> 0xffffea0003d4cc50 objects=14 used=11 fp=0xffff8801183a6b68
> flags=0x80000000000040c3
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946094] INFO: Object
> 0xffff8801183a6b68 @offset=2920 fp=0xffff8801183a7918
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946095]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946097] Bytes b4
> 0xffff8801183a6b58:  75 73 49 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a
> usI.....ZZZZZZZZ
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946107]   Object
> 0xffff8801183a6b68:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946117]   Object
> 0xffff8801183a6b78:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946126]   Object
> 0xffff8801183a6b88:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946136]   Object
> 0xffff8801183a6b98:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946145]   Object
> 0xffff8801183a6ba8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946155]   Object
> 0xffff8801183a6bb8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946170]   Object
> 0xffff8801183a6bc8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946179]   Object
> 0xffff8801183a6bd8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946187]   Object
> 0xffff8801183a6be8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946204]   Object
> 0xffff8801183a6bf8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946214]   Object
> 0xffff8801183a6c08:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946223]   Object
> 0xffff8801183a6c18:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946233]   Object
> 0xffff8801183a6c28:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946243]   Object
> 0xffff8801183a6c38:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946252]   Object
> 0xffff8801183a6c48:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6c58:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6c68:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6c78:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6c88:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6c98:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6ca8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6cb8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6cc8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6cd8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6ce8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6cf8:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6d08:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6d18:  00 00 00 00 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b
> ........kkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6d28:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6d38:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6d48:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]   Object
> 0xffff8801183a6d58:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
> kkkkkkkkkkkkkkk¥
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  Redzone
> 0xffff8801183a6d68:  bb bb bb bb bb bb bb bb
> »»»»»»»»
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  Padding
> 0xffff8801183a6da8:  5a 5a 5a 5a 5a 5a 5a 5a
> ZZZZZZZZ
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] Pid: 8160, comm: Xorg
> Not tainted 2.6.32-nouveau #30
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] Call Trace:
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f5fc1>]
> print_trailer+0x101/0x170
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f66e2>]
> check_bytes_and_report+0xf2/0x120
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f691e>]
> check_object+0x20e/0x260
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f892e>]
> __slab_alloc+0x59e/0x7c0
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff812cd5cc>]
> ? security_inode_alloc+0x1c/0x20
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff81117526>]
> ? inode_init_always+0x116/0x1c0
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015b4ab>]
> ? nouveau_bo_new+0x5b/0x470 [nouveau]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810f8dd7>]
> kmem_cache_alloc+0xb7/0x140
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015b4ab>]
> nouveau_bo_new+0x5b/0x470 [nouveau]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015dccf>]
> nouveau_gem_new+0x3f/0xd0 [nouveau]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015de99>]
> nouveau_gem_ioctl_new+0x139/0x320 [nouveau]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa00ec6ed>]
> drm_ioctl+0x17d/0x3a0 [drm]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffffa015dd60>]
> ? nouveau_gem_ioctl_new+0x0/0x320 [nouveau]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff810e6238>]
> ? mmap_region+0x1f8/0x500
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff8110fc6c>]
> vfs_ioctl+0x7c/0xa0
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff8110fda0>]
> do_vfs_ioctl+0x80/0x560
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff81303e75>]
> ? __up_write+0xe5/0x150
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff81110301>]
> sys_ioctl+0x81/0xa0
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]  [<ffffffff8100bf2b>]
> system_call_fastpath+0x16/0x1b
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] FIX kmalloc-512:
> Restoring 0xffff8801183a6d18-0xffff8801183a6d1f=0x6b
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.946255] FIX kmalloc-512:
> Marking all objects used
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.947018] [TTM] Page number
> range to small Need 4503599627369472 pages, range is [0, 65536]
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.950986] [drm] nouveau
> 0000:01:00.0: nouveau_channel_free: freeing fifo 2
> Jan  7 17:44:13 xps-m1530 gdm-binary[8150]: WARNING: GdmDisplay:
> display lasted 0.270496 seconds
> Jan  7 17:44:13 xps-m1530 kernel: [ 5113.987276] integrated sync not supported
> Jan  7 17:44:13 xps-m1530 kernel: [ 5114.092992] integrated sync not supported


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau