On May 2, 3:56 am, [email protected] (erik quanstrom) wrote: > On Sat May 1 18:50:38 EDT 2010, [email protected] 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.
