Most of the changes that were in my previous "Final new code in texmem-0-0-1 branch" patch are in this patch as well. Some of the code, such as the Radeon code-gen updates, has already been committed.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg09490.html
In addition, a few fixes were made to the device-independent vertical-retrace code. Michal Daenzer pointed out a couple problems with the code, and I've made some work-arounds. The biggest problem was that the user-mode API has to use 64-bit counters for buffer-swaps and retraces, but the kernel ioctls only provide 32-bit counters. I put a small has in vblank.c that should work around most of the problems here.
The bulk of the changes were in the GLX support in libGL.so. As mentioned with my previous patch, the current reporting mechanism is wrong. The extensions returned by glXGetClientString(dpy,GLX_EXTENSIONS) is the set of extensions supported by libGL.so. It has *nothing* to do with the server or and direct rendering driver. The extensions returned by glXQueryExtensionsString is the intersection of the set of extensions supported by the client (libGL.so) and the server, plus any client-side extensions (such as GLX_ARB_get_proc_address). I have extended this to include any extensions that are direct rendering only that are supported by the direct rendering driver. This includes extensions like GLX_NV_vertex_array_range.
In glxextensions.c I track 5 bits for each extension. Each bit represents one of the following:
1. Is the extension supported by libGL.so?
2. Is the extension supported by the server?
3. Is the extension supported by the direct rendering driver?
4. Is the extension client-side only?
5. Is the extension for direct rendering only?By looking at the state of those five bits, the function __glXGetUsableExtensions can determine which extensions should be exposed by glXQueryExtensionString.
I deserve a good scolding for the other changes that I made. :) Last weekend I got a stray hair and decided to start implementing SGIX_fbconfig. The bad news is that this diversion delayed me sending this patch from Sunday to Thursday. The good news is that libGL.so now supports all of SGIX_fbconfig. I have not started on the server side, and I have not started on client-driver part either. As I get time (or stray hairs!) over the next few weeks I will probably finish the implementation. If someone would like to help out with this or with implemented GLX_SGI_make_current_read, I won't try to stop you. :)
As of this patch, our client-side library supports the following extensions:
GLX_ARB_get_proc_address
GLX_ARB_multisample
GLX_EXT_import_context
GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_MESA_swap_control
GLX_MESA_swap_frame_usage
GLX_OML_swap_method
GLX_OML_sync_control
GLX_SGI_swap_control
GLX_SGI_video_sync
GLX_SGIS_multisample
GLX_SGIX_fbconfig
GLX_SGIX_visual_select_groupExtension specs for MESA_swap_control and MESA_swap_frame_usage are included in the patch archive file and are attached to the e-mail.
There is still one problem with the extension tracking that should be noted. There are a few things that are tracked as globals (i.e., new functions added to the GLX function table) that should be tracked per-display. The problem is, what happens if a user has an R200 and some other card that both export GLX_NV_vertex_array_range. Right now each driver will try to insert their own glXAllocateMemoryNV function in the global function table. :( The same holds true for the direct_support and client_support bit-vectors in glxextensions.c. I'm not too worried about it right now because this is stuff that was already broken. We will need to fix this at some point.
My plan is to commit these changes on Monday (17-Mar-2003...my birthday!) and freeze the texmem-0-0-1 tree. After that, we just need to figure out how to do all the various merges that need to be done (XFree86 to DRI trunk, filp-0-0-1 to DRI trunk, and texmem-0-0-1 to DRI trunk). It should be fun stuff. :)
Name
MESA_swap_control
Name Strings
GLX_MESA_swap_control
Version
Date: 3/17/2003 Revision: 1.0
Number
???
Dependencies
None
Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
version 1.5.
Overview
This extension allows an application to specify a minimum periodicity
of color buffer swaps, measured in video frame periods.
New Procedures and Functions
int glXSwapIntervalMESA(int interval)
int glXGetSwapIntervalMESA(void)
New Tokens
None
Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
None
Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
None
Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
and the Framebuffer)
None
Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
None
Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
None
Additions to the GLX 1.3 Specification
[Add the following to Section 3.3.10 of the GLX Specification (Double
Buffering)]
glXSwapIntervalMESA specifies the minimum number of video frame periods
per buffer swap. (e.g. a value of two means that the color buffers
will be swapped at most every other video frame.) A return value
of zero indicates success; otherwise an error occurred. The interval
takes effect when glXSwapBuffers is first called subsequent to the
glXSwapIntervalMESA call.
A video frame period is the time required by the monitor to display a
full frame of video data. In the case of an interlaced monitor,
this is typically the time required to display both the even and odd
fields of a frame of video data.
If <interval> is set to a value of 0, buffer swaps are not synchron-
ized to a video frame. The <interval> value is silently clamped to
the maximum implementation-dependent value supported before being
stored.
The swap interval is not part of the render context state. It cannot
be pushed or popped. The current swap interval for the window
associated with the current context can be obtained by calling
glXGetSwapIntervalMESA. The default swap interval is 1.
On XFree86, setting the environment variable LIBGL_NO_VSYNC sets the
swap interval to 0.
Errors
glXSwapIntervalMESA returns GLX_BAD_VALUE if parameter <interval> is
less than zero.
glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
GLXContext.
GLX Protocol
None. This extension only extends to direct rendering contexts.
New State
Get Value Get Command Type Initial Value
--------- ----------- ---- -------------
[swap interval] GetSwapInterval Z+ 1
New Implementation Dependent State
None
Name
MESA_swap_frame_usage
Name Strings
GLX_MESA_swap_frame_usage
Version
Date: 3/17/2003 Revision: 1.0
Number
???
Dependencies
GLX_SGI_swap_control affects the definition of this extension.
GLX_MESA_swap_control affects the definition of this extension.
GLX_OML_sync_control affects the definition of this extension.
Based on WGL_I3D_swap_frame_usage version 1.3.
Overview
This extension allows an application to deterine what portion of the
swap period has elapsed since the last swap operation completed. The
"usage" value is a floating point value on the range [0,max] which is
calculated as follows:
td
percent = ----
tf
where td is the time measured from the last completed buffer swap (or
call to enable the statistic) to when the next buffer swap completes, tf
is the entire time for a frame which may be multiple screen refreshes
depending on the swap interval as set by the GLX_SGI_swap_control or
GLX_OML_sync_control extensions.
The value, percent, indicates the amount of time spent between the
completion of the two swaps. If the value is in the range [0,1], the
buffer swap occurred within the time period required to maintain a
constant frame rate. If the value is in the range (1,max], a constant
frame rate was not achieved. The value indicates the number of frames
required to draw.
This definition of "percent" differs slightly from
WGL_I3D_swap_frame_usage. In WGL_I3D_swap_frame_usage, the measurement
is taken from the completion of one swap to the issuance of the next.
This representation may not be as useful as measuring between
completions, as a significant amount of time may pass between the
issuance of a swap and the swap actually occuring.
There is also a mechanism to determine whether a frame swap was
missed.
New Procedures and Functions
int glXGetFrameUsageMESA(Display *dpy,
GLXDrawable drawable,
float *usage)
int glXBeginFrameTrackingMESA(Display *dpy,
GLXDrawable drawable)
int glXEndFrameTrackingMESA(Display *dpy,
GLXDrawable drawable)
int glXQueryFrameTrackingMESA(Display *dpy,
GLXDrawable drawable,
int64_t *swapCount,
int64_t *missedFrames,
float *lastMissedUsage)
New Tokens
None
Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
None
Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
None
Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
and the Framebuffer)
None
Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
None
Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
None
Additions to the GLX 1.3 Specification
The frame usage is measured as the percentage of the swap period elapsed
between two buffer-swap operations being commited. In unextened GLX the
swap period is the vertical refresh time. If SGI_swap_control or
MESA_swap_control are supported, the swap period is the vertical refresh
time multiplied by the swap interval (or one if the swap interval is set
to zero).
If OML_sync_control is supported, the swap period is the vertical
refresh time multiplied by the divisor parameter to
glXSwapBuffersMscOML. The frame usage in this case is less than 1.0 if
the swap is commited before target_msc, and is greater than or equal to
1.0 otherwise. The actual usage value is based on the divisor and is
never less than 0.0.
int glXBeginFrameTrackingMESA(Display *dpy,
GLXDrawable drawable,
float *usage)
glXGetFrameUsageMESA returns a floating-point value in <usage>
that represents the current swap usage, as defined above.
Missed frame swaps can be tracked by calling the following function:
int glXBeginFrameTrackingMESA(Display *dpy,
GLXDrawable drawable)
glXBeginFrameTrackingMESA resets a "missed frame" count and
synchronizes with the next frame vertical sync before it returns.
If a swap is missed based in the rate control specified by the
<interval> set by glXSwapIntervalSGI or the default swap of once
per frame, the missed frame count is incremented.
The current missed frame count and total number of swaps since
the last call to glXBeginFrameTrackingMESA can be obtained by
callling the following function:
int glXQueryFrameTrackingMESA(Display *dpy,
GLXDrawable drawable,
int64_t *swapCount,
int64_t *missedFrames,
float *lastMissedUsage)
The location pointed to by <swapCount> will be updated with the
number of swaps that have been commited. This value may not match the
number of swaps that have been requested since swaps may be
queued by the implementation. This function can be called at any
time and does not synchronize to vertical blank.
The location pointed to by <missedFrames> will contain the number
swaps that missed the specified frame. The frame usage for the
last missed frame is returned in the location pointed to by
<lastMissedUsage>.
Frame tracking is disabled by calling the function
int glXEndFrameTrackingMESA(Display *dpy,
GLXDrawable drawable)
This function will not return until all swaps have occurred. The
application can call glXQueryFrameTrackingMESA for a final swap and
missed frame count.
If these functions are succesful, zero is returned. If the context
associated with dpy and drawable is not a direct context,
GLX_BAD_CONTEXT is returned.
Errors
If the function succeeds, zero is returned. If the function
fails, one of the following error codes is returned:
GLX_BAD_CONTEXT The current rendering context is not a direct
context.
GLX Protocol
None. This extension only extends to direct rendering contexts.
New State
None
New Implementation Dependent State
None
texmem-0-0-1-20030313.tar.bz2
Description: Binary data
