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

["Anton.Pavlovetsky" <pavlovetsky@gmail.com>]

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.