[measurement] (was Re: XF4 (mach64) help please)

[measurement] (was Re: XF4 (mach64) help please)

[Iain Sandoe]

I wrote:
> On  Thu, Apr 19, 2001, Geert Uytterhoeven wrote:
>> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>>> On Thu, Apr 19, 2001,  Ani Joshi wrote:
>>> > On Thu, 19 Apr 2001, William Blew wrote:
>>> >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>>> >> > 2/  how difficult would it be to plumb the scroll acceleration back
into
>>> the
>>> >> > console driver?  (would one need access to the NDA stuff?) -- the
> scrolling
>>> >> > of console is a real problem in blocking sound :-/
>>> >>
>>> >> For mach64 at least, I would start by porting the CopyScreen2Screen XXA
>>> >> operation into the kernel and then using it during scrolling.
>>> >
>>> > This is already done by atyfb in the kernel,
>>>
>>> then why is the atyfb scroll (and fbdevhw) _so_ much slower than the X
>>> 'native' driver ... the same reason as below?
>>
>> Because xterm uses jump scroll? Try scrolling line by line in X11.
>
> hmmm.  I was comparing "before" and "after" changing to Ani's new ati_drv.o
> (before was using libfbdevhw.a) - in all other respects the configuration
> was identical.
>
> this is mach64 (3DU Pro) on G3/beige - the difference seemed to be striking
> enough to comment (but I guess I could wind it back and do an X11Perf).

       with libfbdevhw.a           with new ati_drv.o/atimisc_drv.o

-scroll500    51.8/sec                76.5/sec
-shmput500    14.2/sec                25.4/sec

doesn't seem that different, I suppose, but this is...

cat test.txt  10.382 sec               5.132 sec

I guess that's what I've noticed on things like kernel builds.

>>> >however the problem lies in
>>> > the entire fbcon layer where there is some improper locking/interrupts
>>
>> Read: the entire console layer. Fbcon cannot (read: couldn't) use interrupts
>> because the upper console layer disables (disabled) interrupts.
>>
>>> > going on there.  This was discussed here and on linux-fbdev a few months
>>> > ago and I believe will be addressed in 2.5.
>>>
>>> and there is a (temporary) fix for it (I believe) involving a patch from
>>> Andrew Morton - (which I haven't had time to try on PPC yet).  Will that fix
>>> the slow console scroll as well?
>>
>> It's supposed to. Haven't tried it yet, though.
>
> I will ASAP - AFAICT the various blocking issues are the main problem with
> (pmac) sound now.

I've fetched AM's latest console patch (2.4.3-pre8) and will try applying it
later and re-run the libfbdevhw.a test.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [measurement] (was Re: XF4 (mach64) help please)

[Geert Uytterhoeven]

On Fri, 20 Apr 2001, Iain Sandoe wrote:
> I wrote:
> > On  Thu, Apr 19, 2001, Geert Uytterhoeven wrote:
> >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
> >>> On Thu, Apr 19, 2001,  Ani Joshi wrote:
> >>> > On Thu, 19 Apr 2001, William Blew wrote:
> >>> >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
> >>> >> > 2/  how difficult would it be to plumb the scroll acceleration back
> into
> >>> the
> >>> >> > console driver?  (would one need access to the NDA stuff?) -- the
> > scrolling
> >>> >> > of console is a real problem in blocking sound :-/
> >>> >>
> >>> >> For mach64 at least, I would start by porting the CopyScreen2Screen XXA
> >>> >> operation into the kernel and then using it during scrolling.
> >>> >
> >>> > This is already done by atyfb in the kernel,
> >>>
> >>> then why is the atyfb scroll (and fbdevhw) _so_ much slower than the X
> >>> 'native' driver ... the same reason as below?
> >>
> >> Because xterm uses jump scroll? Try scrolling line by line in X11.
> >
> > hmmm.  I was comparing "before" and "after" changing to Ani's new ati_drv.o
> > (before was using libfbdevhw.a) - in all other respects the configuration
> > was identical.
> >
> > this is mach64 (3DU Pro) on G3/beige - the difference seemed to be striking
> > enough to comment (but I guess I could wind it back and do an X11Perf).
>
>        with libfbdevhw.a           with new ati_drv.o/atimisc_drv.o

What's this libfbdevhw.a? Is it just the plain fbdev driver from XFree86?

> -scroll500    51.8/sec                76.5/sec
> -shmput500    14.2/sec                25.4/sec
>
> doesn't seem that different, I suppose, but this is...
>
> cat test.txt  10.382 sec               5.132 sec
>
> I guess that's what I've noticed on things like kernel builds.
>
> >>> >however the problem lies in
> >>> > the entire fbcon layer where there is some improper locking/interrupts
> >>
> >> Read: the entire console layer. Fbcon cannot (read: couldn't) use interrupts
> >> because the upper console layer disables (disabled) interrupts.
> >>
> >>> > going on there.  This was discussed here and on linux-fbdev a few months
> >>> > ago and I believe will be addressed in 2.5.
> >>>
> >>> and there is a (temporary) fix for it (I believe) involving a patch from
> >>> Andrew Morton - (which I haven't had time to try on PPC yet).  Will that fix
> >>> the slow console scroll as well?
> >>
> >> It's supposed to. Haven't tried it yet, though.
> >
> > I will ASAP - AFAICT the various blocking issues are the main problem with
> > (pmac) sound now.
>
> I've fetched AM's latest console patch (2.4.3-pre8) and will try applying it
> later and re-run the libfbdevhw.a test.

If libfbdevhw.a is from XFree86, it has nothing to do with the console.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [measurement] (was Re: XF4 (mach64) help please)

[Michel Dänzer]

Geert Uytterhoeven wrote:
>
> On Fri, 20 Apr 2001, Iain Sandoe wrote:
> > I wrote:
> > > On  Thu, Apr 19, 2001, Geert Uytterhoeven wrote:
> > >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
> > >>> On Thu, Apr 19, 2001,  Ani Joshi wrote:
> > >>> > On Thu, 19 Apr 2001, William Blew wrote:
> > >>> >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
> > >>> >> > 2/  how difficult would it be to plumb the scroll acceleration
> > >>> >> > back into the console driver?  (would one need access to the NDA
> > >>> >> > stuff?) -- the scrolling
> > >>> >> > of console is a real problem in blocking sound :-/
> > >>> >>
> > >>> >> For mach64 at least, I would start by porting the CopyScreen2Screen
> > >>> >> XXA operation into the kernel and then using it during scrolling.
> > >>> >
> > >>> > This is already done by atyfb in the kernel,
> > >>>
> > >>> then why is the atyfb scroll (and fbdevhw) _so_ much slower than the X
> > >>> 'native' driver ... the same reason as below?
> > >>
> > >> Because xterm uses jump scroll? Try scrolling line by line in X11.
> > >
> > > hmmm.  I was comparing "before" and "after" changing to Ani's new
> > > ati_drv.o (before was using libfbdevhw.a) - in all other respects the
> > > configuration was identical.
> > >
> > > this is mach64 (3DU Pro) on G3/beige - the difference seemed to be
> > > striking enough to comment (but I guess I could wind it back and do an
> > > X11Perf).
> >
> >        with libfbdevhw.a           with new ati_drv.o/atimisc_drv.o
>
> What's this libfbdevhw.a? Is it just the plain fbdev driver from XFree86?

Nope, it's just the fbdevHW layer. But I guess Iain actually means the fbdev
driver?


> > -scroll500    51.8/sec                76.5/sec
> > -shmput500    14.2/sec                25.4/sec
> >
> > doesn't seem that different, I suppose, but this is...
> >
> > cat test.txt  10.382 sec               5.132 sec
> >
> > I guess that's what I've noticed on things like kernel builds.
> >
> > >>> >however the problem lies in
> > >>> > the entire fbcon layer where there is some improper
> > >>> > locking/interrupts
> > >>
> > >> Read: the entire console layer. Fbcon cannot (read: couldn't) use
> > >> interrupts because the upper console layer disables (disabled)
> > >> interrupts.
> > >>
> > >>> > going on there.  This was discussed here and on linux-fbdev a few
> > >>> > months ago and I believe will be addressed in 2.5.
> > >>>
> > >>> and there is a (temporary) fix for it (I believe) involving a patch
> > >>> from Andrew Morton - (which I haven't had time to try on PPC yet).
> > >>> Will that fix the slow console scroll as well?
> > >>
> > >> It's supposed to. Haven't tried it yet, though.
> > >
> > > I will ASAP - AFAICT the various blocking issues are the main problem
> > > with (pmac) sound now.
> >
> > I've fetched AM's latest console patch (2.4.3-pre8) and will try applying
> > it later and re-run the libfbdevhw.a test.
>
> If libfbdevhw.a is from XFree86, it has nothing to do with the console.

That's it.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/