Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Synchronization of Multiple Rendering Models in Multiple Processes

IP.com Disclosure Number: IPCOM000115845D
Original Publication Date: 1995-Jun-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 6 page(s) / 194K

Publishing Venue

IBM

Related People

Chen, AR: AUTHOR [+2]

Abstract

Customers are demanding a method to use different rendering API in the same window of a windowing system (i.e., mixing gl and X or X and graPHIGS). Within AIXwindows* some graphics models are rendering through the X Server and so me directly to the graphics adapters through direct access windows. A method is needed to synchronize calls to the various graphics APIs so that rendering occurs in a predictable manner.

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

Synchronization of Multiple Rendering Models in Multiple Processes

      Customers are demanding a method to use different rendering API
in the same window of a windowing system (i.e., mixing gl and X or X
and graPHIGS).  Within AIXwindows* some graphics models are rendering
through the X Server and so me directly to the graphics adapters
through direct access windows.  A method is needed to synchronize
calls to the various graphics APIs so that rendering occurs in a
predictable manner.

      In the X Window System** and the AIXwindows Graphics
Infrastructure, synchronization methods are inadequate.  Existing
current methods include:
  o  XSync subroutine (X Window System).  The X Sync subroutine
      flushes the X Client buffer and performs a GetInputFocus
protocol
      to insure that the client buffer has reached the X Server
before
      the X Client is allowed to send another request to the X
Server.
      The X Sync subroutine only insures that the preceding requests
      are part of the X Server's dispatch loop.  There is no
guarantee
      that the requests have been actually rendered.  They may be
      waiting in an adapter FIFO.  This is an inadequate solution for
      direct access clients first because of the possible latency
time
      while commands may be waiting in an adapter FIFO and second
      because XSync requires a round trip to the X Server to perform
      the GetInputFocus.
  o  The OpenGL*** interface provides two primitives called XWaitGL
      and GLWaitX.  These provide the ability to synchronize
protocols
      from core X and OpenGL.  When X and OpenGL are part of the same
      process, they write to the same adapter FIFO and these become a
      noop.  A possible method of implementing XWaitGL and GLWaitX
when
      GL and X are rendered through DWA is to use the XSync protocol.
      However, this is deficient for the reasons discussed in the
      previous bullet.

      The solution to the problem is the addition of the HardwareSync
minor protocol to the DirectAccess Extension.  The new minor protocol
insures that all requests in the X protocol stream occur after the
HardwareSync protocol has completed.

      Fig. 1 shows that when the HardwareSync Minor Protocol is
received, the X Server uses the IgnoreClient internal subroutine to
remove the client from X processing until the device driver notifies
the X Server that the sync processing is complete.

      Fig. 2 shows a possible scenario for use of the HardwareSync
minor protocol.  The application is rendering a series of X protocols
as represented by X11a, then a series of GL primitives as represented
by GLa and then a series of X protocols as represented by X11b.  X11a
must complete before GLa and GLa must complete before X11b.  The bold
line on the left represents the hardware sync protocol.

      The device-depen...