[Dri-devel] Final new code in texmem-0-0-1 branch (take 2)

[Ian R. <id...@us...>]

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/dri...@li.../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_group

Extension 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. :)