R128 Scaling.

R128 Scaling.

[Stefan Berndtsson]

What is the status of the scaling registers for rage128? I saw a patch
in the archive, that adds scaling capabilities for the framebuffer,
and that seems to work reasonably well.

When running XF4.1, with UseFBDev, I can switch resolutions, and they
scale nicely.

When running XF4.2, with UseFBDev, the situation is more or less the same.

When running XF4.2, without UseFBDev, scaling is no longer available, which
makes sense if it's a patch in the framebuffer.

When running something in DGA (xmame for example), with XF4.1 and UseFBDev,
the resolution is changed by MAME, but it seems it still gets the fullsize
resolution passed to it, because it draws completely distorted graphics.
The area indicates that 1024x768 is passed as resolution even though the
display is set to 640x480 using scaling.

I'm using an ibook (autumn 2001), with 2.4.19-pre6-ben0 patched with the
mentioned framebuffer patch.

The system is debian, with a patched r128_drv.o since the default one
for XF4.1 doesn't do any sensible DGA for me.

The XF4.2 was unpatched in the test, and I'm using the test preview from
Michel Dänzer, as of 2002-04-01.

Will XF4.1/4.2 be able to scale and do DGA on this machine?

It seems, things are close to working, but I might miss some big problem
with it. I assume something is in the way, since it's been out since November,
and it's not in Ben's kernel.

It would be very nice to be able to run MAME and other programs in
fullscreen. :)

/Stefan Berndtsson

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

Re: R128 Scaling.

[Adrian Cox]

On 16 Apr 2002 13:49:12 +0200
Stefan Berndtsson <stefan@nocrew.org> wrote:

> What is the status of the scaling registers for rage128? I saw a patch
> in the archive, that adds scaling capabilities for the framebuffer,
> and that seems to work reasonably well.

I started looking at that a while ago, but didn't get very far. To get
much further (and also to tackle the VGA out problems) I probably need
the chip docs, but I haven't really pursued them. My one email asking to
become an X developer was ignored, and I don't know of any other way to
get the docs currently.

The scaling patches I worked on had a problem with display flickering.
They also needed a general mechanism to get the physical panel size.

> When running something in DGA (xmame for example), with XF4.1 and UseFBDev,
> the resolution is changed by MAME, but it seems it still gets the fullsize
> resolution passed to it, because it draws completely distorted graphics.
> The area indicates that 1024x768 is passed as resolution even though the
> display is set to 640x480 using scaling.

I didn't get this one resolved at the time.


--
Adrian Cox
http://www.humboldt.co.uk/

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

Re: R128 Scaling.

[Stefan Berndtsson]

Adrian Cox <adrian@humboldt.co.uk> writes:

> I started looking at that a while ago, but didn't get very far. To get
> much further (and also to tackle the VGA out problems) I probably need
> the chip docs, but I haven't really pursued them. My one email asking to
> become an X developer was ignored, and I don't know of any other way to
> get the docs currently.
>
> The scaling patches I worked on had a problem with display flickering.
> They also needed a general mechanism to get the physical panel size.

I guess I never mentioned it was your patch I messed with. When switching
to 640x480, I get flickering if running 60Hz, but with 85 (which is what
fbset reports for me now), I see no such thing.

> > When running something in DGA (xmame for example), with XF4.1 and UseFBDev,
> > the resolution is changed by MAME, but it seems it still gets the fullsize
> > resolution passed to it, because it draws completely distorted graphics.
> > The area indicates that 1024x768 is passed as resolution even though the
> > display is set to 640x480 using scaling.
>
> I didn't get this one resolved at the time.

Too bad.. I hope it can be fixed :)

/Stefan

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

Re: R128 Scaling.

[Michel Dänzer]

On Tue, 2002-04-16 at 14:32, Adrian Cox wrote:
>
> On 16 Apr 2002 13:49:12 +0200
> Stefan Berndtsson <stefan@nocrew.org> wrote:
>
> > What is the status of the scaling registers for rage128? I saw a patch
> > in the archive, that adds scaling capabilities for the framebuffer,
> > and that seems to work reasonably well.
>
> I started looking at that a while ago, but didn't get very far. To get
> much further (and also to tackle the VGA out problems) I probably need
> the chip docs, but I haven't really pursued them. My one email asking to
> become an X developer was ignored, and I don't know of any other way to
> get the docs currently.

You can apply for them with ATI directly, their developer relations
program to be exact.

> The scaling patches I worked on had a problem with display flickering.

I could resolve that problem with custom modes I obtained in a way Kevin
Hendricks posted here.

> They also needed a general mechanism to get the physical panel size.

Shouldn't be hard with Apple machines, and on x86 one can use the BIOS
as seen in the X driver.


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

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

Re: R128 Scaling.

[Michel Dänzer]

On Tue, 2002-04-16 at 13:49, Stefan Berndtsson wrote:
>
> When running XF4.2, without UseFBDev, scaling is no longer available, which
> makes sense if it's a patch in the framebuffer.

XFree86 4.2 does support scaling on its own, but you need to provide it
the panel resolution, as should be visible in the log.

> When running something in DGA (xmame for example), with XF4.1 and UseFBDev,
> the resolution is changed by MAME, but it seems it still gets the fullsize
> resolution passed to it, because it draws completely distorted graphics.
> The area indicates that 1024x768 is passed as resolution even though the
> display is set to 640x480 using scaling.

Or maybe it wrongly uses a 640 pitch? The virtual width is always 1024.

This could be a bug either in the X driver's DGA support or xmame.


> It would be very nice to be able to run MAME and other programs in
> fullscreen. :)

Note that fullscreen doesn't require DGA per se. Direct framebuffer
access is generally slow, xmame might be better off using normal X
images or pixmaps and relying on an optimized ImageWrite acceleration in
the driver.


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

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

Re: R128 Scaling.

[Stefan Berndtsson]

Michel Dänzer <michel@daenzer.net> writes:

> On Tue, 2002-04-16 at 13:49, Stefan Berndtsson wrote:
> >
> > When running XF4.2, without UseFBDev, scaling is no longer available, which
> > makes sense if it's a patch in the framebuffer.
>
> XFree86 4.2 does support scaling on its own, but you need to provide it
> the panel resolution, as should be visible in the log.

Ok.. I will have a look at that. I noticed all DGA using programs makes the
X-server crash when the programs exit, on your XF4.2.

> Or maybe it wrongly uses a 640 pitch? The virtual width is always 1024.
>
> This could be a bug either in the X driver's DGA support or xmame.

Could very well be. The DGA-hack is another patch floating around somewhere
that fixed some basic DGA stuff on the ibook2, but was known to crash
from time to time.

> Note that fullscreen doesn't require DGA per se. Direct framebuffer
> access is generally slow, xmame might be better off using normal X
> images or pixmaps and relying on an optimized ImageWrite acceleration in
> the driver.

I know you technically, don't need DGA for fullscreen, but afaik, MAME
supports -x11-mode 0 or 1, where 0 is window, and 1 is DGA. Comparing the
two on a stationary machine, where LCD-scaling isn't an issue, DGA is
faster in every case.

Also comparing small SDL-hacks in the same environment, DGA beats non-DGA
hands down.

/Stefan

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

Re: R128 Scaling.

[Michel Dänzer]

On Tue, 2002-04-16 at 15:30, Stefan Berndtsson wrote:
>
> > Note that fullscreen doesn't require DGA per se. Direct framebuffer
> > access is generally slow, xmame might be better off using normal X
> > images or pixmaps and relying on an optimized ImageWrite acceleration in
> > the driver.
>
> I know you technically, don't need DGA for fullscreen, but afaik, MAME
> supports -x11-mode 0 or 1, where 0 is window, and 1 is DGA. Comparing the
> two on a stationary machine, where LCD-scaling isn't an issue, DGA is
> faster in every case.
>
> Also comparing small SDL-hacks in the same environment, DGA beats non-DGA
> hands down.

Is that with a driver with optimized ImageWrite acceleration? I don't
think any stock XFree86 driver is really optimized there yet, I'm
working on radeon now and the results should be easily applicable to
r128.


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

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

Re: R128 Scaling.

[Stefan Berndtsson]

Michel Dänzer <michel@daenzer.net> writes:

> Is that with a driver with optimized ImageWrite acceleration? I don't
> think any stock XFree86 driver is really optimized there yet, I'm
> working on radeon now and the results should be easily applicable to
> r128.

It's with a fairly old XF4.1, with r128 (B&W G3), and I'm pretty sure
it's not optimized in that area. I don't use it graphically very much
anymore, so I haven't upgraded the X stuff in a bunch of months or so.

/Stefan

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

Re: R128 Scaling.

[Adrian Cox]

On 16 Apr 2002 15:12:12 +0200
Michel D <michel@daenzer.net> wrote:

> You can apply for them with ATI directly, their developer relations
> program to be exact.

Thanks - found it by Google. I can't find a route to it from ati.com,
which is why I missed it.


--
Adrian Cox
http://www.humboldt.co.uk/

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

Re: R128 Scaling.

[Geert Uytterhoeven]

On Tue, 16 Apr 2002, Adrian Cox wrote:
> On 16 Apr 2002 15:12:12 +0200
> Michel D <michel@daenzer.net> wrote:
>
> > You can apply for them with ATI directly, their developer relations
> > program to be exact.
>
> Thanks - found it by Google. I can't find a route to it from ati.com,
> which is why I missed it.

Because it's atitech.com? ;-) ati.com is an embedded OS supplier.

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: R128 Scaling.

[Adrian Cox]

On Tue, 16 Apr 2002 16:01:42 +0200 (MEST)
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Because it's atitech.com? ;-) ati.com is an embedded OS supplier.

Not any more. ATI technologies owns it now.

--
Adrian Cox
http://www.humboldt.co.uk/

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

Re: R128 Scaling.

[Ani Joshi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 599 bytes --]


On 16 Apr 2002, Michel [ISO-8859-1] Dänzer wrote:

> Is that with a driver with optimized ImageWrite acceleration? I don't
> think any stock XFree86 driver is really optimized there yet, I'm
> working on radeon now and the results should be easily applicable to
> r128.


There are several that do ImageWrie acceleration.  The radeon driver already
does indirect ImageWrite acceleration (its the same as CPUToScreen color
expansion).  There are others which do it in the direct method, the savage
driver is an example.


ani


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

Re: R128 Scaling.

[Michel Dänzer]

On Wed, 2002-04-17 at 07:44, Ani Joshi wrote:
>
> On 16 Apr 2002, Michel [ISO-8859-1] Dänzer wrote:
>
> > Is that with a driver with optimized ImageWrite acceleration? I don't
> > think any stock XFree86 driver is really optimized there yet, I'm
> > working on radeon now and the results should be easily applicable to
> > r128.
>
> There are several that do ImageWrie acceleration.  The radeon driver already
> does indirect ImageWrite acceleration (its the same as CPUToScreen color
> expansion).

Which is slower than memcpy for a simple upload. I'm finishing a CP based
implementation which is significantly faster, at least in 16 bit.


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

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