Graphics Binary Interface Emulator

Abstract:

	This is an graphics binary interface emulation layer on existing high
end SGI platforms (VTX) to provide a headstart on development for the Project
Reality HW. The scope of the emulation will be focused on the graphics.

Schedule:

	This emulation platform is only the only development environment until
the arrival of prototype HW (3/95). The 1st delivery of the emulation platform
will be around 6/94

Graphics Binary Interface:

	This is basically a scene graph produced by the CPU and consumed by the
RCP processor. Since there is a single producer and consumer, all static
parts of the scene graph remains single buffered. All dynamic parts (eg. a
matrix for moving an object) need to be buffered so that CPU and the RCP can
execute in parallel.

Overall Emulator Architecture:

	The emulator executes a ROM image that represent the actual ROM image.
Once the scene graph has been constructed by the application, it is handed
off to a second process that emulates the RCP thru OpenGL. Since OpenGL is a
easy to use virtual layer on top of variety of hardware, it will impose a set
of virtual restrictions on the true hardware capabilities. Our goal is to map
our hardware on top of a more restrictive OpenGL interface. Therefore, a set of
hardware combinations will not be available when using the emulator.

	The complete list of exceptions are described in the errata sheet.

GBI graphics emulation:

Geometric:

	The geometric portion of the systems is fairly easily emulated. We will
use a single matrix stack (MODELVIEW or PROJECTION) to emulate the single matrix
stack of the GBI. We'll store the vertex list on the host and once the
connectivity information comes down, we can send the polygons to the OpenGL
graphics subsystem.

RDP Colors:

	Formats of the framebuffer and texture image are stored as state
information when the formatting commands are executed. The RDP color commands
are normalized to OpenGL formats these commands are executed.

Texture:

	All texture parameter commands are store as state until the load texture
command is executed. The load texture command then looks up the state info and
see if such an OpenGL texture object exist. If so, just calls it. If not, builds
an OpenGL texture object and calls it. These texture objects are tagged by
their texel image address.

	We need to build OpenGL texture objects so the ONYX 4MB texture ram can
actually cache the least recently used textures so that they would be fast. The
texture objects can not be explicitly freed (destroyed) in the RDP interface.
Therefore, the current emulator can not continuously add new textures. Maybe we
can use glDeleteLists in the future (just flip thru 2MB range at 64bit ptrs,
this may take awhile)

Completion:

RSP commands
--------------------------------------------------------------------------------

			Specification		Emulation Implementation
hierarchical DL
	load segment	done			done
	display list	done			done

Matrix (kluster)
	combine		cheaper frac/int order	done except TBD spec
	stack pop	done			done
 	srt		independent rot
	viewport	done (need doc)		done

Geometry
	vertex		done			done
	tri1		done			done
	triN		done			done
	strip		done			done

Texture (lk)
	st scale	done			done
	texture		done			done
	4/4 8/8 3/1
	CI

Lighting (kluster)
	light		TBD
	material coeff	TBD

Zbuffer
	zbuffer		done			done

culling (kluster)
	face reject	TBD
	sphere		TBD			not possible
	bound		done			not possible
	bound end	done			not possible

LOD
			TBD			not possible

Load Monitoring
			TBD			not possible

AA
			TBD


RDP commands
--------------------------------------------------------------------------------

Order of implementation
--------------------------------------------------------------------------------
Texture blocks		done
Texture parameters	done
Filters			done
Copy (blit)
FillRect		done
Zbuffer			done
Indexed Textures
Backface
Lighting
Blend
Scissor
Cleanup
	SetCombineMode cleanup

Misc:

Functionality/Errata Sheet:
	Geometry Portion
		LOD does not work
		Coarse Culling does not work
	Raster Portion
		Basic State
			Only 16 bit pixel mode for framebuffer

		Texture
			cannot modify the texels in the texture once it is
			defined in the memory. This is because distinct textures
			are identified with their addresses in the emulator.

			can't deal with loadtile widths != texture image width.
			in other words, can't load a subtile of a bigger tile.

			w & h must be powers of 2.
			no mirroring
			wrapping must be on textures boundaries. No subtexture
			 wrapping.

			No subtile of a bigger texture. Just load block type of
			commands. LoadTile does not work

			only a single texture can be in tmem at once

			Sequence of commands
				Texture
				SetTextureImage
				LoadBlock
				SetTile
				SetTileSize

			If using color-index textures, use this sequence
			of commands:
				Texture
				SetOtherMode (G_MD_EN_TLUT)
				SetOtherMode (G_MD_TLUT_TYPE) (optional)
				LoadTLUT
				SetTextureImage
				LoadBlock
				SetTile
				SetTileSize
			Since color-index textures are converted on the
			SetTile call, changing the LUT after the above
			sequence does not change the actual texture, although
			it will on the hardware.

			For alpha write enable, sequence of commands
				SetBlendColor
				SetOtherMode (G_MD_A_COMPARE_EN);
			Because of floating point error, use 0x80 instead
			of 0xff for the blend alpha if using 1-bit texture
			alphas.

			Following textures are supported
				5/5/5/1	RGBA texels
				8/8	IA
				4/4	IA
				3/1	IA
				8	CI
				4	CI

		Zbuffer

			SetMaskImage shall be done prior to clearing zbuffers
			using SetColorImage

			Setting Zbuffer buffer
				SetMaskImage

			Turning on/off
				Zbuffer
				SetOtherMode

			Clear Zbuffer
				SetColorImage (must follow SetMaskImage)
				SetFillColor
				FillRect
	Misc
		gBranchList() acts exactly like gDisplayList()