Browse Prior Art Database

Rendering OpenGL in a Processor Subsystem

IP.com Disclosure Number: IPCOM000117511D
Original Publication Date: 1996-Mar-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 133K

Publishing Venue

IBM

Related People

Lawless, JJ: AUTHOR [+3]

Abstract

In a parallel processing environment for OpenGL, each node in the processor complex needs to be working constantly to achieve maximum system performance. Therefore, the graphics datastream needs to be partitioned into pieces for each node to render, from this point on to be called workgroups. To properly render the OpenGL, each node must know the current state of attributes such as matrices, linestyles, etc..., in order to properly render any particular workgroup. This state is only known at the end of processing all previous workgroups in the processor complex.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 43% of the total text.

Rendering OpenGL in a Processor Subsystem

      In a parallel processing environment for OpenGL, each node in
the processor complex needs to be working constantly to achieve
maximum system performance.  Therefore, the graphics datastream needs
to be partitioned into pieces for each node to render, from this
point on to be called workgroups.  To properly render the OpenGL,
each node must know the current state of attributes such as matrices,
linestyles, etc..., in order to properly render any particular
workgroup.  This state is only known at the end of processing all
previous workgroups in the processor complex.

      The first problem is that each node is only receiving a portion
of the graphics datastream in its workgroup, yet each node needs the
entire current attribute state.  The second problem is that all
workgroups must be handled in sequential order to establish correct
current state.  The third problem is to avoid having any processor
waiting for the previous processor to finish processing it's
workgroup assignment so that they may truly be working in parallel.
The forth problem is the number of function calls inherent in OpenGL
datastream.  Each function call takes a relatively high number of
processor cycles for the call to and return from the subroutine.
  Attribute                        Common
  Processor                        Access Memory
  Node 1                 Node 2                  Node N
  Processor              Processor               Processor
  Local                  Local                   Local
  State                  State                   State
  Memory                 Memory                  Memory

      The solution implemented is to have a separate attribute
processor scanning the OpenGL graphics datastream for attribute/state
information.  The attribute processor stores the attribute/state
information in memory accessible by each processor in the parallel
processor complex.

      For maximum performance, the attribute processor partitions
the OpenGL datastream into workgroups of appropriate size to keep all
processors working simultaneously.  Further, the attribute processor
must indicate all atttribute/state changes to the node responsible
for rendering the workgroup.  To accomplish this, the attribute
processor scans the OpenGL datastream, as it creates the workgroups,
setting bits in flag words indicating which attribute/state
information has changed within this workgroup.  Each node in the
parallel complex has a set of these flags indicating a accumulation
of attribute/state changes since the last time that node received a
workgroup for processing.  At the start of each workgroup, the
attribute processor copies the current attribute/state into memory
accessible...