From 01df5d59e56a1b060568f8cad2e89f7eea22fc70 Mon Sep 17 00:00:00 2001 From: marha Date: Mon, 29 Aug 2011 08:51:20 +0200 Subject: xwininfo libX11 libXmu libxcb mesa xserver xkeyboard-config git update 29 aug 2011 --- mesalib/src/mesa/tnl/NOTES | 200 ++++++++++++++++++++++----------------------- 1 file changed, 99 insertions(+), 101 deletions(-) (limited to 'mesalib/src/mesa/tnl/NOTES') diff --git a/mesalib/src/mesa/tnl/NOTES b/mesalib/src/mesa/tnl/NOTES index 9a35e948b..43c469201 100644 --- a/mesalib/src/mesa/tnl/NOTES +++ b/mesalib/src/mesa/tnl/NOTES @@ -1,102 +1,100 @@ -INTRODUCTION - -A generic, configurable software implementation of GL transformation & -lighting. - -This module provides an implementation of the routines required by the -'vtxfmt' mechanism of core mesa for tnl functionality in all -combinations of compile and execute modes. - -Most current drivers use the tnl module exclusively to provide this -functionality, though there is an experimental alternate -implementation provided by the tnl_dd/t_dd_imm_* files which can -handle a small subset of GL states in execute mode only. - - -STATE - -To create and destroy the module: - - GLboolean _tnl_CreateContext( struct gl_context *ctx ); - void _tnl_DestroyContext( struct gl_context *ctx ); - -The module is not active by default, and must be installed by calling -_tnl_Wakeup(). This function installs internal tnl functions into all -the vtxfmt dispatch hooks, thus taking over the task of transformation -and lighting entirely: - - void _tnl_wakeup_exec( struct gl_context *ctx ); - void _tnl_wakeup_save_exec( struct gl_context *ctx ); - - -This module tracks state changes internally and maintains derived -values based on the current state. For this to work, the driver -ensure the following funciton is called whenever the state changes and -the swsetup module is 'awake': - - void _tnl_InvalidateState( struct gl_context *ctx, GLuint new_state ); - -There is no explicit call to put the tnl module to sleep. Simply -install other function pointers into all the vtxfmt dispatch slots, -and (optionally) cease calling _tnl_InvalidateState(). - -CUSTOMIZATION - -The module provides customizability through several mechanisms. The -most important is by allowing drivers to specify the pipeline through -which vertex data is passed, including its eventual transfer to -rasterization hardware (or software). - -The default pipeline is specified in t_pipeline.c, and is usually a -starting point for driver pipelines. Some drivers will remove a stage -where hardware provides support for the implemented operation (for -instance fog where per-pixel hardware fog is available, as in the dri -tdfx driver), or add stages to shortcircuit latter operations (for -example taking advantage of hardware support for strips and other -higher-level primitives (for example the radeon driver). - -In addition, the following functions provide further tweaks: - -extern void -_tnl_need_projected_coords( struct gl_context *ctx, GLboolean flag ); - - - Direct the default vertex transformation stage to - produce/not produce projected clip coordinates. - -extern void -_tnl_need_dlist_loopback( struct gl_context *ctx, GLboolean flag ); - - - Direct the display list component of the tnl module to - replay display lists as 'glVertex' type calls, rather than - passing the display list data directly into the tnl pipeline - mechanism. - - This allows display lists to be replayed by the tnl module - even when the module is not strictly active. - - -extern void -_tnl_need_dlist_norm_lengths( struct gl_context *ctx, GLboolean flag ); - - - Direct the display list component to enable/disable caching - 1/length values for display list normals. Doing so is - ususally helpful when lighting is performed in software, but - wasteful otherwise. - - -DRIVER INTERFACE - -The module itself offers a minimal driver interface: - - void (*RunPipeline)( struct gl_context *ctx ); - -Normally this is set to _tnl_RunPipeline(), however the driver can use -this hook to wrap checks or other code around this call. - -In addition, the driver interface for the default render pipeline -stage is housed in the tnl context struct (this could be cleaner). - - -RENDER DRIVER INTERFACE - +INTRODUCTION + +A generic, configurable software implementation of GL transformation & +lighting. + +This module provides an implementation of the routines required by the +'vtxfmt' mechanism of core mesa for tnl functionality in all +combinations of compile and execute modes. + +Most current drivers use the tnl module exclusively to provide this +functionality. + + +STATE + +To create and destroy the module: + + GLboolean _tnl_CreateContext( struct gl_context *ctx ); + void _tnl_DestroyContext( struct gl_context *ctx ); + +The module is not active by default, and must be installed by calling +_tnl_Wakeup(). This function installs internal tnl functions into all +the vtxfmt dispatch hooks, thus taking over the task of transformation +and lighting entirely: + + void _tnl_wakeup_exec( struct gl_context *ctx ); + void _tnl_wakeup_save_exec( struct gl_context *ctx ); + + +This module tracks state changes internally and maintains derived +values based on the current state. For this to work, the driver +ensure the following funciton is called whenever the state changes and +the swsetup module is 'awake': + + void _tnl_InvalidateState( struct gl_context *ctx, GLuint new_state ); + +There is no explicit call to put the tnl module to sleep. Simply +install other function pointers into all the vtxfmt dispatch slots, +and (optionally) cease calling _tnl_InvalidateState(). + +CUSTOMIZATION + +The module provides customizability through several mechanisms. The +most important is by allowing drivers to specify the pipeline through +which vertex data is passed, including its eventual transfer to +rasterization hardware (or software). + +The default pipeline is specified in t_pipeline.c, and is usually a +starting point for driver pipelines. Some drivers will remove a stage +where hardware provides support for the implemented operation (for +instance fog where per-pixel hardware fog is available), +or add stages to shortcircuit latter operations (for +example taking advantage of hardware support for strips and other +higher-level primitives (for example the radeon driver). + +In addition, the following functions provide further tweaks: + +extern void +_tnl_need_projected_coords( struct gl_context *ctx, GLboolean flag ); + + - Direct the default vertex transformation stage to + produce/not produce projected clip coordinates. + +extern void +_tnl_need_dlist_loopback( struct gl_context *ctx, GLboolean flag ); + + - Direct the display list component of the tnl module to + replay display lists as 'glVertex' type calls, rather than + passing the display list data directly into the tnl pipeline + mechanism. + + This allows display lists to be replayed by the tnl module + even when the module is not strictly active. + + +extern void +_tnl_need_dlist_norm_lengths( struct gl_context *ctx, GLboolean flag ); + + - Direct the display list component to enable/disable caching + 1/length values for display list normals. Doing so is + ususally helpful when lighting is performed in software, but + wasteful otherwise. + + +DRIVER INTERFACE + +The module itself offers a minimal driver interface: + + void (*RunPipeline)( struct gl_context *ctx ); + +Normally this is set to _tnl_RunPipeline(), however the driver can use +this hook to wrap checks or other code around this call. + +In addition, the driver interface for the default render pipeline +stage is housed in the tnl context struct (this could be cleaner). + + +RENDER DRIVER INTERFACE + See t_context.h for the definition and explanation of this. \ No newline at end of file -- cgit v1.2.3