home *** CD-ROM | disk | FTP | other *** search
/ Amiga Magazin: Amiga-CD 2000 April & May / AMIGA_2000_04.iso / patches / mesa3.1 / mesa-3_1.lha / src / AOS / PLANS < prev    next >
Encoding:
Text File  |  1999-09-23  |  9.3 KB  |  256 lines
  1. /*****************************************************************************/
  2. /*****************************************************************************/
  3.  
  4.  caveats:
  5.  
  6.   - seperated clusters of functionality:
  7.     - display (graphics-driver)
  8.     - internals (GL-processor)
  9.     - communication (GL-parser)
  10.       - module-manager (configuration of clusters)
  11.  
  12.     application
  13.     ^
  14.     |
  15.     +---> communication <-----*------> display
  16.         ^                ^
  17.         |                .
  18.         *------> internals <......... (hybrid)
  19.  
  20.     (* possible through any kind of communication-way)
  21.  
  22.     (the communicator talks with the GL-processor that talks with the
  23.      displayer. every part of it can be replaced. some examples for
  24.      the existing ports: aMesaGL (display), AMRTL (display),
  25.      StormMesa (display) differs mainly only for the display-part,
  26.      CyberGL (display, internals) uses it's own GL-processor)
  27.     
  28.     (it is questionable if the GL-processor has to speak directly
  29.      to the displayer, for better design it has not, for faster access
  30.      yes (there is something tricky: someone can program a hybrid of
  31.      displayer and GL-processor reducing message-passing to a minimum
  32.      (dummy-messages only for syncronisation with the application))
  33.     
  34.     (if the table-approach is taken, there is an easy direct communication
  35.      between core and displayer possible, no need for hybrids)
  36.  
  37.   - runtime exchanging of clusters/modules
  38.   - a module-manager of all available services (hmm, sounds like
  39.     jini :^) so the user can specify how to drive his machine
  40.  
  41.  descriptions:
  42.  
  43.   - communicator:
  44.     - OS-dependent
  45.  
  46.     (can be a local-communicator that passes the function-parameters
  47.      directly to the other module or something really weird like a
  48.      Envoy-connector, the communicator depends heavily on the
  49.      module-manager)
  50.  
  51.   - internals:
  52.     - OS-independent
  53.     - Mesa or another processor
  54.  
  55.     (nothing to talk about in special)
  56.  
  57.   - display:
  58.     - OS-dependent
  59.     - all function for display-lists of the core (3D-support)
  60.  
  61.     (there is some work to do, we have to build a mechanism that doesn't
  62.      fiddles with references, but with locks (eg. a pointer to the
  63.      framebuffer of the vax at the university isn't usefull), and
  64.      manipulation of the thing that displays the display becomes harder
  65.      as any abstractions of the display are visible)
  66.  
  67.     (in case of 3D-support it's a bit confusing which functions to
  68.      put in the displayer, I think it's best to put every 2D-things
  69.      to the displayer and let someone with a 3D-driver program a
  70.      hybrid or not (PowerVR has fantastic capabilities and can
  71.      do much of the OpenGL-functionality and is a candidate for a hybrid,
  72.      Virge3D is more simple and doesn't need a hybrid)
  73.  
  74.  capabilities:
  75.  
  76.   - every module has to identify itself and it's capabilities to the
  77.     module-manager (extensions, basics)
  78.   - the module-manager has to choose a combination of the modules that
  79.     fits best for the user-purposes (like BestModeID)
  80.   - extensions-calls has to be passed directly from the application to
  81.     the communicator (extension-ID-calls)
  82.  
  83.  implementation:
  84.  
  85.   - functions:
  86.    - struct glAContext *glACreateContext(struct TagItem Tags, ...);
  87.      void glAChangeContext(struct glAContext *glAc, struct TagItem Tags, ...);
  88.      void glADestroyContext(struct glAContext *glAc);
  89.  
  90.      is mainly a module-manager-specific function
  91.  
  92.      request-tags:
  93.  
  94.       AGL_INT_CAPABILITY    0x????????
  95.       AGL_DISP_CAPABILITY    0x????????
  96.       ....
  97.      
  98.      capability-requests:
  99.      
  100.       INT_CAP_LIGHTS        0x????????
  101.       INT_CAP_3DHARDWARE    0x????????    (hardware-support for core)
  102.       INT_CAP_RADIOSITY        0x????????
  103.       DISP_CAP_3DHARDWARE    0x????????    (hardware-support for display)
  104.       DISP_CAP_OFFSCREEN    0x????????    (offscreen-framebuffer)
  105.       ...
  106.  
  107.    (all functions of the displayer and the core are written into a
  108.     vector-table, all function-calls are passed through the stack,
  109.     all display- and core-funtions are called inlined or stub-based
  110.     directly from the application)
  111.  
  112.    - struct glAVisual *glACreateVisual(struct TagItem Tags, ...);
  113.      void glAChangeVisual(struct glAVisual *glAv, struct TagItem Tags, ...);
  114.      void glADestroyVisual(struct glAVisual *glAv);
  115.  
  116.      is mainly a displayer-function ONLY called from the manager
  117.  
  118.   - function-calling (application):
  119.  
  120.    /**************************************************************************/
  121.  
  122.    #ifdef BUILD_STUBS
  123.    #undef inline
  124.    #else
  125.    #define extern static
  126.    #endif
  127.  
  128.    struct glAContext {
  129.      ... (*basicTable) (args...)[];
  130.      ... (*extTable) (args...)[];
  131.  
  132.      ...
  133.    };
  134.  
  135.    #define GL_SETCOLOR3F    0x???????
  136.    #define GLEXT_SETWINDOW    0x???????
  137.  
  138.    ... glSetColor3f(...);
  139.    ... glAextSetWindow(...);
  140.  
  141.    extern struct glAContext *globalContext;
  142.  
  143.    #define glcall(vec, args...)        globalContext->basicTable[vec](args)
  144.    #define glextcall(vec, args...)    globalContext->extTable[vec](args)
  145.  
  146.    extern inline ... glSetColor3f(args...) {
  147.      return glcall(GL_SETCOLOR3F, args...);
  148.    }
  149.  
  150.    extern inline ... glAextSetWindow(args...) {
  151.      return glextcall(GLEXT_SETWINDOW, args...);
  152.    }
  153.  
  154.    /**************************************************************************/
  155.  
  156.    (all os-specific function are extension (makes life easier))
  157.  
  158.   - module-manager:
  159.    - context/visual/... management
  160.    - table-management
  161.    - has a public port that let a new module join the list (manager-inter-
  162.      communication and syncronisation through TCP/LAN etc.)
  163.    - checks public HD-places for modules
  164.  
  165.    (on non-protected OSs the manager can pass the function-vectors directly
  166.     to the table, otherwise a small function is called that sends the args
  167.     and get back the returnval, the whole problem of memory-protection is
  168.     centralized in the manager (that is not difficult to write), NONE of the
  169.     modules (on no OS) has to take care of protection-state/level)
  170.  
  171.  
  172. /*****************************************************************************/
  173. /*****************************************************************************/
  174.  
  175.  implementation details:
  176.  
  177.    all functions of gl/glu/glut/... are replaced by functions that build the
  178.   manager
  179.  
  180.    the manager splits the functions in display-dependent (gl/glut/...) and
  181.   core-dependent (gl/glu/...)
  182.  
  183.    on program-startup the manager tries to detect any local display and core
  184.   and parses the command-line for specifications of special display- and core-
  185.   adresses on other machines through specified communication-ways
  186.  
  187.    the manager sets up the specified display (local/net/...) and initialize
  188.   the core with the parameters to call the display (local/net/...) directly
  189.   now the core and display can talk to another without using the manager
  190.   the manager has only to call display- or core-functions
  191.  
  192.  example of a local manager, local core and local display call:
  193.  
  194.   manager    detects core local
  195.   manager    detects display local
  196.   manager    gives the core the localDisplay display that calls
  197.         the calls in the local display
  198.   application    calls glFlush()
  199.   manager    function glFlush() is called
  200.   manager    knows core is local and calls glFlush() in the localCore
  201.   localCore    function glFlush() is called
  202.   localCore    do something internal and calls Flush() in localDisplay
  203.   localDisplay    function Flush() is called
  204.   localDisplay    puts the data onto the display and returns
  205.   localCore    get return-value and returns
  206.   manager    get return-value and returns
  207.   application    checks return-value
  208.  
  209.  example of a local manager, local core and net display call:
  210.  
  211.   manager    detects core local
  212.   manager    detects display on another machine
  213.   manager    gives the core the netDisplay display that calls
  214.         the calls in the net display
  215.   application    calls glFlush()
  216.   manager    function glFlush() is called
  217.   manager    knows core is local and calls glFlush() in the localCore
  218.   localCore    function glFlush() is called
  219.   localCore    do something internal and calls Flush() in netDisplay
  220.   netDisplay    function Flush() is called
  221.   netDisplay    transfers informations to targetDisplay
  222.   targetDisplay    recieves informations from netDisplay
  223.   targetDisplay    function Flush() is called
  224.   targetDisplay    puts the data onto the display and transfers return-value
  225.         to netDisplay
  226.   netDisplay    recieves return-value and returns
  227.   localCore    get return-value and returns
  228.   manager    get return-value and returns
  229.   application    checks return-value
  230.  
  231.  example of a local manager, net core and local display call:
  232.  
  233.   manager    detects core on another machine
  234.   manager    detects display local
  235.   manager    gives the core the netDisplay display that calls
  236.         the calls in the local display
  237.   application    calls glFlush()
  238.   manager    function glFlush() is called
  239.   manager    knows core is away and calls glFlush() in the netCore
  240.   netCore    function glFlush is called
  241.   netCore    transfers informations to targetCore
  242.   targetCore    recieves informations from netCore
  243.   targetCore    function glFlush() is called
  244.   targetCore    do something internal and calls Flush() in netDisplay
  245.   netDisplay    function Flush() is called
  246.   netDisplay    transfers informations to localDisplay
  247.   localDisplay    recieves informations from netDisplay
  248.   localDisplay    function Flush() is called
  249.   localDisplay    puts the data onto the display and transfers return-value
  250.         to netDisplay
  251.   netDisplay    recieves return-value and returns
  252.   targetCore    get return-value and transfers return-value
  253.   netCore    recieves return-value and returns
  254.   manager    get return-value and returns
  255.   application    checks return-value
  256.