> Don't these two points contradict each other ?
In what way ?
> Virtualizing the graphics pipeline requires the graphics API used by
> application programmers to be much more abstract.
True but abstract in the way that it doesn't define anything. Even on SGI
servers the hardware varies so much that a API needed to cover it all was
impossible. So the solution was make the standard ioctl so generic that
they work everywhere. Take a look at linux/include/asm-mips/gfx.h. You
will see things like
struct gfx_getboardinfo_args {
unsigned int board; /* board number. starting from zero */
void *buf; /* pointer to gfx_info */
unsigned int len; /* buffer size of buf */
};
See the void. Also the platform had such a huge impact on the design. SGI
graphics hardware runs on mip 32 and mip 64 processors. Both these
processor have some big differences. On mips 64 some of the memory
regions are cachable and some are not. I believe on mips 32 this is
not so. Some of the graphics pipes are mapped to cached memory regions and
some are not. Because of this a ioctl is used to memory map registers. The
reason is more is going on besides just memory mapping. You can pass
things like what caching options to use on a graphics pipe.
> If the protocol uses
> pixels as the basic unit, how can you write a resolution independent
> (and coordinate system independent) graphics server ? (just to name
> an example). This is seen nicely in font handling. Of course, anti
> aliasing and all the advanced text rendering jazz like hinting, kerning,
> etc. is fine, but can't be implemented if all you have are pixmaps and
> device coordinates.
You are thinking PC here. The graphics pipelines on a SGI servers are not
pixel based. You can't even access any buffers. Its all based around a
geometeric pipeline. It also isn't just program a few registers and you
get a triangle. Its much more complex than that. So the rendering protocol
at the driver is none. It just manages hardware access and state in a SMP
environment.
> In short, I'd not say X is obsolete, as we all depend on it. But new effords such
> as Fresco/Berlin are nevertheless very much needed, and could profit very much from
> a standardized console/graphics system.
I agree with you. I hate to see linux tried down to one technology
standard.
