[cairo] Re: [Mesa3d-dev] Re: Points in Cairo Glitz paper

[Allen Akin]

On Thu, Apr 22, 2004 at 04:26:01PM -0700, Keith Packard wrote:
| 
| Around 13 o'clock on Apr 22, Allen Akin wrote:
| 
| > In OpenGL, PBuffers are surfaces for offscreen drawing.  Back buffers,
| > stereo buffers, and (to a lesser extent) auxiliary buffers are used for
| > multibuffering.  The need for different types of drawing surfaces
| > reflects differences in drawing semantics for onscreen vs. offscreen.
| 
| I understand the semantic distinction at the API level, and I can even 
| believe there was an historic distinction in the hardware, but I would 
| like to know if that hardware-level difference remains in more recent 
| hardware, or whether these differences now exist solely in the GL api and 
| Mesa implementation.

Here are some:

	Offscreen buffers can have color formats that aren't permitted
	for displayable buffers (e.g. deep floating-point RGB or deep
	integer luminance).

	Offscreen buffers need not have color buffers at all (e.g.
	shadow maps; in the near future, coordinate arrays as render
	targets).

	Offscreen buffers associated with textures for render-to-texture
	applications can have physical layouts that are incompatible
	with displayable buffers (e.g. they may be tiled rather than
	addressed linearly, or be losslessly compressed).

The first and last are due to current hardware limitations; the middle
one due to straightforward semantics (displayable buffers must have
color information, non-displayable buffers needn't).

It's hard to draw conclusions about whether such differences will be
long-lived, or whether new ones will arise; the tradeoffs tend to change
from generation to generation based on performance targets and
expectations from Microsoft.  Textures are pretty squirrelly, and the
hardware vendors always want to reserve the right to treat them
differently from displayable buffers, even when they can be used as
rendering targets.  Until recently, OpenGL maintained distinct object
types mainly so that the vendors would have that flexibility.

OpenGL is most likely headed toward "uber buffers," for which the app
declares the operations it's interested in performing and the driver
tells it whether it can allocate a (possibly hierarchical) memory object
that supports them.  Operations include things like use as a color
rendering target, use as a depth buffer, use as a plain texture source,
use as a mipmapped texture source, use as a cubemapped texture source,
use as a vertex array source, use as a displayable buffer, etc.  It's up
to the app to have a fallback strategy if its preferred combination of
operations isn't supportable.

Allen