How would you cope with Applications that query a capability, but force indirect rendering? Wouldn't they be misguided into thinking GLX_NV_vertex_array_range was present in the server, when it's probably not available?
I believe the DRI is the first project where HW accellerated direct rendering was implemented, but indirect rendering fell back to a software renderer. If we had HW accellerated indirect rendering, I believe these Query functions would work the way they were intended...i.e. the GLX_NV_vertex_array_range would work on an indirect rendering context and should then be advertised by glXQueryExtensionsString.
All of the extensions that I have put in the category, such as GLX_NV_vertex_array_range, are ones that are *never* available in an indirect context. There are a few that fall into that category. They are:
GLX_MESA_agp_offset
GLX_MESA_swap_control
GLX_MESA_swap_frame_usage
GLX_NV_vertex_array_range
GLX_OML_sync_control
GLX_SGI_video_syncIn each of these cases there is no GLX protocol defined, so it is impossible to implement them for indirect rendering. The specs for these extensions makes this pretty clear.
In all those cases, if one of the functions is called with an indirect context GLX_BAD_CONTEXT is returned. If an app expects these extensions to work with an indirect context, the app is broken. :)
We should perhaps look at how the Nvidia drivers advertise some of these extensions. I suspect they probably do it "right." :)
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
