[9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Anton.Pavlovetsky]

Wiki (http://www.plan9.bell-labs.com/wiki/plan9/radeon_drivers) says
"the Radeon drivers are now (1/2010) part of the distribution". I have
a device which seems to work with the drivers: ATI Mobility Radeon
9600 M10 (RV350). I obtained vid and did numbers with the help of
pci(8) and added them to the /lib/vgadb. Now, vga(8) cannot initialize
the device,saying:

aux/vga: radeon: not found.

What do you think?

By the way, vid and did attributes in the /lib/vgadb are not
documented in vgadb(6). Can be confusing.

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[erik quanstrom]

On Mon Apr 26 07:23:20 EDT 2010, pavlovetsky@gmail.com wrote:
> Wiki (http://www.plan9.bell-labs.com/wiki/plan9/radeon_drivers) says
> "the Radeon drivers are now (1/2010) part of the distribution". I have
> a device which seems to work with the drivers: ATI Mobility Radeon
> 9600 M10 (RV350). I obtained vid and did numbers with the help of
> pci(8) and added them to the /lib/vgadb. Now, vga(8) cannot initialize
> the device,saying:
>
> aux/vga: radeon: not found.
>
> What do you think?

/sys/src/cmd/aux/vga/radeon.c uses radeon_pciids in radeon.h.
it ignores the vids and dids in /lib/vgadb.  this is probablly a
mistake.

- erik

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Anton.Pavlovetsky]

On Apr 26, 4:23 pm, quans...@quanstro.net (erik quanstrom) wrote:

> /sys/src/cmd/aux/vga/radeon.c uses radeon_pciids in radeon.h.
> it ignores the vids and dids in /lib/vgadb.  this is probablly a
> mistake.
>
> - erik

I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
vga and kernel; added line to /lib/vgadb.
Now kernel sees the device (and I see it too: cat /dev/vgactl), but
attempt to start framebuffer gives blank screen. Pointers are
appreciated!

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[erik quanstrom]

> I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
> vga and kernel; added line to /lib/vgadb.
> Now kernel sees the device (and I see it too: cat /dev/vgactl), but
> attempt to start framebuffer gives blank screen. Pointers are
> appreciated!

it didn't work for me, either.  i added a bit of
code to support the newer "atom bios" but
ran out of patience and the vesa driver works.

- erik

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Venkatesh Srinivas]

On Thu, Apr 29, 2010 at 7:17 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
>> vga and kernel; added line to /lib/vgadb.
>> Now kernel sees the device (and I see it too: cat /dev/vgactl), but
>> attempt to start framebuffer gives blank screen. Pointers are
>> appreciated!
>
> it didn't work for me, either.  i added a bit of
> code to support the newer "atom bios" but
> ran out of patience and the vesa driver works.

ATOM BIOS should be unnecessary for the R9600; it is an r300-era card.
I've not ever tried with a mobility (is it an m10?) r9600, but the
desktop variant works when its PCI IDs are added... I forget whether I
had to enable r300hack, though, for it...

-- vs

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Anton.Pavlovetsky]

On Apr 29, 3:55 pm, m...@acm.jhu.edu (Venkatesh Srinivas) wrote:

> is it an m10?

The device is ATI Technologies Inc RV350 [Mobility Radeon 9600 M10].
What is the r300hack?

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Anton.Pavlovetsky]

On Apr 29, 2:23 pm, quans...@quanstro.net (erik quanstrom) wrote:
> the vesa driver works.

I was curious to see how performance differs from vesa. And,
meanwhile, am I right if I think that the whole graphics math is done
on cpu (I mean - not on gpu), so the faster the cpu the better vesa
(and any) driver performance? Proprietary drivers use gpu and many
things built in the graphics controller and so they unload the cpu.
Plan 9 drivers are there to initialize and set up the device, scroll
and fill and this is, basically all, right? If this is so, the brute
force through powerful cpu + vesa is easiest solution, the way to go.

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[erik quanstrom]

> I was curious to see how performance differs from vesa.

me, too.  radeon performance is not good with vesa.

> meanwhile, am I right if I think that the whole graphics math is done
> on cpu (I mean - not on gpu), so the faster the cpu the better vesa
> (and any) driver performance?

cpu speed seems to have little to do with it.  the main slowdown
is reading from the hardware framebuffer, which plan 9 does a lot.
on many modern cards there is no phsical framebuffer.  it's
constructed by firmware (perhaps running in smm mode on the
cpu) on-the-fly.

> Proprietary drivers use gpu and many
> things built in the graphics controller and so they unload the cpu.
> Plan 9 drivers are there to initialize and set up the device, scroll
> and fill and this is, basically all, right? If this is so, the brute
> force through powerful cpu + vesa is easiest solution, the way to go.

i think it's mainly a question of getting the best graphics
performance.  but these days the 2d accelleration (especially
for radeon) is fairly poor.  i'd love to have my nvidia mx400
back with a pcie interface.

- erik

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Gabriel Díaz]

hello


Vesa code has some problems to deal with ati hd5750 cards here. Themouse cursor disappear when a lot of scrolling is happening,  vesa is unable to drive the card beyond 8bit depth modes or 1280x1024 resolutions. Besides that, the performance i see is almost the same i had with the radeon driver and the 9500 i had in the thinkpad, or the intel driver (given that my stress test is reading man pages and watching flickr photos. . . .)

I guess the radeon driver is unable to work with modern ati cards no?

I would love a book recommendation to learn something about graphics programming, so at least i can guess what or where to look to try to debug the problem.

slds.

gabi



----- Original Message ----
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Sent: Fri, April 30, 2010 2:07:07 PM
Subject: Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

> I was curious to see how performance differs from vesa.

me, too.  radeon performance is not good with vesa.

> meanwhile, am I right if I think that the whole graphics math is done
> on cpu (I mean - not on gpu), so the faster the cpu the better vesa
> (and any) driver performance?

cpu speed seems to have little to do with it.  the main slowdown
is reading from the hardware framebuffer, which plan 9 does a lot.
on many modern cards there is no phsical framebuffer.  it's
constructed by firmware (perhaps running in smm mode on the
cpu) on-the-fly.

> Proprietary drivers use gpu and many
> things built in the graphics controller and so they unload the cpu.
> Plan 9 drivers are there to initialize and set up the device, scroll
> and fill and this is, basically all, right? If this is so, the brute
> force through powerful cpu + vesa is easiest solution, the way to go.

i think it's mainly a question of getting the best graphics
performance.  but these days the 2d accelleration (especially
for radeon) is fairly poor.  i'd love to have my nvidia mx400
back with a pcie interface.

- erik

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Venkatesh Srinivas]

erik quanstrom wrote:
> /sys/src/cmd/aux/vga/radeon.c uses radeon_pciids in radeon.h.
> it ignores the vids and dids in /lib/vgadb.  this is probablly a
> mistake.

Agreed.

erik quanstrom wrote:
> i think it's mainly a question of getting the best graphics
> performance.  but these days the 2d accelleration (especially
> for radeon) is fairly poor.

Do you happen to have any workloads where this is a problem? There is
a lot more we can do for the radeon, particularly the r100-r300 chips,
which could improve draw performance.

Have you ever tried enabling HW_ACCEL in the Radeon driver? It
accelerates fill/scroll to some degree, which would certainly be a
first step.

Gabriel Díaz <gdiaz@rejaa.com> wrote:
> I guess the radeon driver is unable to work with modern ati cards no?

Right now the Radeon driver can deal with r100-r300; it is missing PCI
VID/DIDs for a number of r200 cards, mostly the later 9200 and 9250
series. It is also missing a number of r300s (9600, 9800) and the PCIe
X1050, X3xx, X5xx, and X6xx. I don't know how well the later cards
will work, but they are nominally the same as the 9500/9700, which are
supported.

Sean Stangl at CMU started working on support for more modern
(R500/R600 iirc) cards; I believe he got most of ATOMBIOS support and
snarf() routines for the r600 done.

> I would love a book recommendation to learn something about graphics programming, so at least i can guess what or where to look to try to debug the problem.

I don't know of a book that describes any modern graphics hardware,
sorry. However, here is a bit of an overview of what is going on with
the radeon, at least:

The radeon exposes a pair of bus-accessible memory regions (BARs), the
framebuffer and the MMIO region; these regions appear in physical
memory and are mapped by vgaradeon.c (take a look at radeonenable()).
On the Radeon, BAR 0 holds the framebuffer, IIRC; vgalinearpci()
searches the card for the largest region and guesses that that is the
framebuffer. BAR 2 holds the MMIO region. We ask that the framebuffer
segment is set to write-combining via the MTRRs; we cannot do the same
for the MMIO region.

To just draw, you can write to the framebuffer region.

To ask the radeon gpu to do anything interesting for you, you must
carry out a series of register writes - for example, to fill a
rectangle with a solid color, you write the rectangle's color to
DP_BRUSH_FGRD_CLR (register 0x147c), the start to DST_X_Y, and the
width and height to DST_WIDTH_HEIGHT. Everything you can ask the
radeon to do is ultimately done via register writes.

agd5f's blog has two entries that are pretty useful:
http://www.botchco.com/agd5f/?p=50 and
http://www.botchco.com/agd5f/?p=16.

-- vs

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[erik quanstrom]

> erik quanstrom wrote:
> > i think it's mainly a question of getting the best graphics
> > performance.  but these days the 2d accelleration (especially
> > for radeon) is fairly poor.
>
> Do you happen to have any workloads where this is a problem? There is
> a lot more we can do for the radeon, particularly the r100-r300 chips,
> which could improve draw performance.

i didn't make it clear that i'm using the vesa
interface.  and it's very slow for every day
use with acme, but it sure displays pictures quickly.

; pci | grep vid | grep 1002
1.5.0:	vid  03.00.00 1002/791e  10 0:d800000c 134217728 1:00000000 16 2:fbff0004 65536 3:00000000 16 4:0000a001 256 5:fbe00000 1048576
; pci 1002/791e
1002/791e
	ATI Technologies Inc RS690 [Radeon X1200 Series]

> To ask the radeon gpu to do anything interesting for you, you must
> carry out a series of register writes - for example, to fill a
> rectangle with a solid color, you write the rectangle's color to
> DP_BRUSH_FGRD_CLR (register 0x147c), the start to DST_X_Y, and the
> width and height to DST_WIDTH_HEIGHT. Everything you can ask the
> radeon to do is ultimately done via register writes.

i wonder if this pio doesn't explain a lot of the slowness.
i would have thought that they would have used a ring.

i hope you don't also pio the image data in?

- erik

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Venkatesh Srinivas]

On Sat, May 1, 2010 at 10:08 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> erik quanstrom wrote:
>> > i think it's mainly a question of getting the best graphics
>> > performance.  but these days the 2d accelleration (especially
>> > for radeon) is fairly poor.
>>
>> Do you happen to have any workloads where this is a problem? There is
>> a lot more we can do for the radeon, particularly the r100-r300 chips,
>> which could improve draw performance.
>
> i didn't make it clear that i'm using the vesa
> interface.  and it's very slow for every day
> use with acme, but it sure displays pictures quickly.
>
> ; pci | grep vid | grep 1002
> 1.5.0:  vid  03.00.00 1002/791e  10 0:d800000c 134217728 1:00000000 16 2:fbff0004 65536 3:00000000 16 4:0000a001 256 5:fbe00000 1048576
> ; pci 1002/791e
> 1002/791e
>        ATI Technologies Inc RS690 [Radeon X1200 Series]
>
>> To ask the radeon gpu to do anything interesting for you, you must
>> carry out a series of register writes - for example, to fill a
>> rectangle with a solid color, you write the rectangle's color to
>> DP_BRUSH_FGRD_CLR (register 0x147c), the start to DST_X_Y, and the
>> width and height to DST_WIDTH_HEIGHT. Everything you can ask the
>> radeon to do is ultimately done via register writes.
>
> i wonder if this pio doesn't explain a lot of the slowness.
> i would have thought that they would have used a ring.

There is a command processor on the radeon, which we do not
initialize; it can share a ring of commands with the host; it can also
accept indirect buffers. If the radeon driver (on supported h/w) was
too slow for general work, then we could use it, but if its fine right
now, there is no need.

If we really needed speed, we could go further - currently plan9 video
drivers can only accelerate fill and scroll, but in principle the draw
path could use any other functionality the card was willing to do for
it; for the earlier radeons, the 2D engine can do a lot... for the
later ones, we could use the 3d engine in the same style as X's EXA.

-- vs

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Venkatesh Srinivas]

> [...] the main slowdown
> is reading from the hardware framebuffer, which plan 9 does a lot.

Where in the draw path does Plan 9 read back from the framebuffer? Why so much?

Also, there is apparently a fast way to read-back on radeon series h/w
- map some system memory on the card via the GART and do the same
dance that drm's r100_copy_blit does. If the formats are amenable, it
might be nice to expose cards' fast download-from-screen features, by
adding something like Ctrl->dfs() or the like...

-- vs

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[erik quanstrom]

On Sat May  1 18:50:38 EDT 2010, me@endeavour.zapto.org wrote:
> > [...] the main slowdown
> > is reading from the hardware framebuffer, which plan 9 does a lot.
>
> Where in the draw path does Plan 9 read back from the framebuffer? Why so much?

/sys/src/9/port/devdraw.c:/^drawchar and multiple places in :/^drawmesg

- erik

Re: [9fans] ctrl radeon: not working for ATI Radeon 9600 Mobility?

[Anton.Pavlovetsky]

On May 2, 3:56 am, quans...@quanstro.net (erik quanstrom) wrote:
> On Sat May  1 18:50:38 EDT 2010, m...@endeavour.zapto.org wrote:
>
> > > [...] the main slowdown
> > > is reading from the hardware framebuffer, which plan 9 does a lot.
>
> > Where in the draw path does Plan 9 read back from the framebuffer? Why so much?
>
> /sys/src/9/port/devdraw.c:/^drawchar and multiple places in :/^drawmesg
>
> - erik

Okay, now let me generalize the discussion a little bit and ask what
do you think how the graphical performance can be achieved in
principle (on Plan 9). You say processor speed has little to do with
it: the bottleneck is how it interacts with hardware. Is the model of
interaction implemented in /sys/src/9/port/devdraw.c is okay or needs
to be changed? Or the devdraw.c is okay and this is the incomplete
driver which slows us? Is there a third way? What the third way? - let
me show you the case, not the exact replica of what I mean, but
something along the lines.
Before linuxemu emerged, the question of getting a variety of software
to work on Plan 9 was resolved in many ways and many times. First,
there is APE - an organized, if little theoretical system to port
software. Then, the attempts to port significant projects and make
them work natively: like X server and GCC. Then, VNC, which is said to
be "more then enough". We cannot forget an idea to port qemu. The
trend is to avoid to port and maintain the code and, instead to
produce the solution which works universally.
What I am trying to figure out is how to avoid the hardware specifics,
escape the driver bottlenecks, virtualize the whole thing and make it
work universally. I mean: maybe performance through specific driver
plus specific hardware is obsolete.