Why run xserver on the OpenGL API?

[Marcelo E. Magallon]

Hi,

On Tue, Nov 25, 2003 at 02:59:40PM -0800, Kendall Bennett wrote:

 > glReadPixels() and glDrawPixels() are horrendously slow for doing any
 > kind of software rendering. Reading from framebuffer memory is a huge
 > performance hit, so to expect the X server to read the framebuffer
 > memory, do some software rendering and put it back again will cause a
 > massive performance hit.

 Don't blame the API, blame the drivers.  I used to bitch about
 glReadPixels/glDrawPixels.  Now I bitch about glTexImage* and
 glTexSubImage* :-)

 No, seriously, have you given it some thought as to _why_ these
 functions are slow?  Let's look at the API:

       void glReadPixels( GLint x,
                          GLint y,
                          GLsizei width,
                          GLsizei height,
                          GLenum format,
                          GLenum type,
                          GLvoid *pixels )

       void glDrawPixels( GLsizei width,
                          GLsizei height,
                          GLenum format,
                          GLenum type,
                          const GLvoid *pixels )

 you basically have to tell the driver how much data you have (width,
 height), in which format (type), and how do you want to use it
 (format).  If you have an RGBA visual, it's very likely that the
 hardware is storing packed bytes in _some_ order.  PC hardware likes
 BGRA for the internal representation.  That means that if you ask the
 functions to work with BGRA data it's going to fly.  If you pass it
 GL_FLOATs and ask it to store GL_BGRA data, it's going to perform
 width*height*4 conversions (scaling, biasing and clamping at least --
 probably well over 10 cycles per component) ... of course that's slow!

 What do I get form my crappy GeForce3 for texture uploads (RGBA from
 BGRA data, UNSIGNED_BYTE data)?  110 MB/s.  That's dissappointing for
 an AGP 4x card.  I get something a bit faster from DrawPixels.

 Marcelo