Re: [Dri-devel] Adding GLX extensions?
W liście z sob, 23-11-2002, godz. 00:04, Ian Romanick pisze: > Before I just launch into this, I will explain some of the motivation and > (brief) history that led to this document. > [snip] > > I've done some sizing on these changes, and I think that I can handle most > of the device independent parts. I've already written code to handle > enabling and disabling of extensions. After I merge in Brian's changes to > the texmem branch, I will commit these changes to the branch. I've also > made the changes to the R100 driver to support the GLX_SGI_swap_control (and > the "MESA" version, see below). On some of the remaining extensions I've > notes about whether or not I can reasonably make the changes. On some of > them I've even noted that a "newbie" could probably make the changes. Hi If a "newbie" can handle it I'd like to help. Just tell me what to do. BTW: I was just going to post a message in order to ask wheather there are some things to do which newbie can handle. Things that are quite simple but more advanced developers just don't have time to do or have more important tasks? I'm mainly interested in radeon as this is the only card I have. Jacek --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: Before I just launch into this, I will explain some of the motivation and (brief) history that led to this document. As near as I can tell, the GLX side of DRI has stagnated. I seems as though we are approaching a critical mass to make some real improvements in that area. Brian and I have had some discussions (both on and off the list) about adding an extension handling mechanism for GLX that mirrors the mechanism for regular GL. Some improvements in that area have already been committed to the mesa4.1 branch, and they will soon (this weekend?) be merged into the trunk. The first change is a new function to query the version of the internal (i.e., driver to libGL.so) GLX API. Drivers can use this function to determine if certain data fields and functions are present in GLX. Drivers can then expose enhanced functionality with new enough versions of libGL and fallback with old versions. The __glXGetInternalVersion function returns the version, which is currently a date, as an unsigned integer. Later, a function called driCompareGLXAPIVersion will be added to determine if the current API version is new enough. This will help drivers handle the case where libGL is so old that it does not support the __glXGetInternalVersion function. The other change was to add private GLX functions that reside in libGL.so to the table used by glXGetProcAddress. This allows drivers to avoid the burden of using dlsym (see the end of lib/GL/mesa/src/drv/r200/r200_screen.c in the trunk). They can simply call glXGetProcAddress to get pointers to functions that may only exist in new versions of libGL.so. __glXGetInternalVersion is a good example of such a function. As soon as these changes find their way into the trunk, I will merge them into the texmem-0-0-1 branch. I suspect that merging the mesa4.1 merged trunk into the texmem branch will be very "exciting" work. :) Good thing for me that next week is a holiday week... This sets the stage for drivers to enable or disable GLX extensions in a clean manner, compatible (forward and backward) manner. I believe that this is important for our open source driver work and DRI in general for three big reasons. This is why I am very interested in getting this stuff done. 1. We've fallen behind. There are other vendors of closed-source drivers on Linux that don't use DRI that have a significant GLX feature advantage. There is quite a bit of functionality, both the stuff I have listed below and more, that our open source drivers just flat don't support. 2. Device independence. Pretty much any GLX extension that requires new entry points could be implemented the same way that GLX_NV_VERTEX_ARRAY_RANGE is implemented in the R200 driver (see the bottom of lib/GL/mesa/src/drv/r200/r200_screen.c). The problem with that is that most of the code would be the same or nearly the same for every single driver. I've spent enough time refactoring duplicated code in the DRI code base to know better than to fall into that trap! Not only that, adding the extensions in this way would prevent libGL from being used to do indirect rendering on a remote system (app running on x86 Linux, rendering on MIPS SGI, for example) that did support the extensions. 3. Closed source drivers that use DRI. Quite a bit of this functionality is or could be supported by those few IHVs that actually use DRI for their close source drivers. The problem is that they have to supply their own libGL. That just causes problems for everyone. I realize that supporting closed source drivers is pretty low on most people's priority list, but doing something to help both open and closed source drivers just gives me that warm, fuzzy, win-win feeling. :) I've done some sizing on these changes, and I think that I can handle most of the device independent parts. I've already written code to handle enabling and disabling of extensions. After I merge in Brian's changes to the texmem branch, I will commit these changes to the branch. I've also made the changes to the R100 driver to support the GLX_SGI_swap_control (and the "MESA" version, see below). On some of the remaining extensions I've notes about whether or not I can reasonably make the changes. On some of them I've even noted that a "newbie" could probably make the changes. The rest of this document is basically broken into two sections. The first section lists the changes I propose be made to the internal GLX API. With three exceptions, all of the changes are to the __DRI*Rec structures. We'll have to be careful with those structures since they're accessed both by libGL and the DRI drivers. We should try our best to preserve forward/ backward compatibility In general your ideas sound good. I'll try to work with you on this once you get going. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
Re: [Dri-devel] Adding GLX extensions?
Before I just launch into this, I will explain some of the motivation and (brief) history that led to this document. As near as I can tell, the GLX side of DRI has stagnated. I seems as though we are approaching a critical mass to make some real improvements in that area. Brian and I have had some discussions (both on and off the list) about adding an extension handling mechanism for GLX that mirrors the mechanism for regular GL. Some improvements in that area have already been committed to the mesa4.1 branch, and they will soon (this weekend?) be merged into the trunk. The first change is a new function to query the version of the internal (i.e., driver to libGL.so) GLX API. Drivers can use this function to determine if certain data fields and functions are present in GLX. Drivers can then expose enhanced functionality with new enough versions of libGL and fallback with old versions. The __glXGetInternalVersion function returns the version, which is currently a date, as an unsigned integer. Later, a function called driCompareGLXAPIVersion will be added to determine if the current API version is new enough. This will help drivers handle the case where libGL is so old that it does not support the __glXGetInternalVersion function. The other change was to add private GLX functions that reside in libGL.so to the table used by glXGetProcAddress. This allows drivers to avoid the burden of using dlsym (see the end of lib/GL/mesa/src/drv/r200/r200_screen.c in the trunk). They can simply call glXGetProcAddress to get pointers to functions that may only exist in new versions of libGL.so. __glXGetInternalVersion is a good example of such a function. As soon as these changes find their way into the trunk, I will merge them into the texmem-0-0-1 branch. I suspect that merging the mesa4.1 merged trunk into the texmem branch will be very "exciting" work. :) Good thing for me that next week is a holiday week... This sets the stage for drivers to enable or disable GLX extensions in a clean manner, compatible (forward and backward) manner. I believe that this is important for our open source driver work and DRI in general for three big reasons. This is why I am very interested in getting this stuff done. 1. We've fallen behind. There are other vendors of closed-source drivers on Linux that don't use DRI that have a significant GLX feature advantage. There is quite a bit of functionality, both the stuff I have listed below and more, that our open source drivers just flat don't support. 2. Device independence. Pretty much any GLX extension that requires new entry points could be implemented the same way that GLX_NV_VERTEX_ARRAY_RANGE is implemented in the R200 driver (see the bottom of lib/GL/mesa/src/drv/r200/r200_screen.c). The problem with that is that most of the code would be the same or nearly the same for every single driver. I've spent enough time refactoring duplicated code in the DRI code base to know better than to fall into that trap! Not only that, adding the extensions in this way would prevent libGL from being used to do indirect rendering on a remote system (app running on x86 Linux, rendering on MIPS SGI, for example) that did support the extensions. 3. Closed source drivers that use DRI. Quite a bit of this functionality is or could be supported by those few IHVs that actually use DRI for their close source drivers. The problem is that they have to supply their own libGL. That just causes problems for everyone. I realize that supporting closed source drivers is pretty low on most people's priority list, but doing something to help both open and closed source drivers just gives me that warm, fuzzy, win-win feeling. :) I've done some sizing on these changes, and I think that I can handle most of the device independent parts. I've already written code to handle enabling and disabling of extensions. After I merge in Brian's changes to the texmem branch, I will commit these changes to the branch. I've also made the changes to the R100 driver to support the GLX_SGI_swap_control (and the "MESA" version, see below). On some of the remaining extensions I've notes about whether or not I can reasonably make the changes. On some of them I've even noted that a "newbie" could probably make the changes. The rest of this document is basically broken into two sections. The first section lists the changes I propose be made to the internal GLX API. With three exceptions, all of the changes are to the __DRI*Rec structures. The second section is a list of GLX extensions (or 1.3 features) that could be supported for direct rendering with these changes. For a lot of the extension functions there is a direct or almost direct mapping to added functions or data in the internal API. For a couple of the other functions, I've included some of my notes on how the function could be implemented. The last section is some commentary about some extensions that aren't covered by this document. Link
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: On Tue, Nov 19, 2002 at 10:55:12AM -0700, Brian Paul wrote: Ian Romanick wrote: On Tue, Nov 19, 2002 at 08:35:45AM -0700, Brian Paul wrote: Well, there isn't an official query like this, but there is the _glapi_get_version() function which returns the version of the dispatcher code. See the top of glapi.c for the version history. This seems a little hinkey to me. If I'm adding new data structures or dispatch functions to, for example, __DRIcontext or __DRIdrawable, I need to bump a version in a file that comes from extras/Mesa/src? That just seems weird and potentially problematic to me. :) Right. It's not the real solution to your problem. But it's the only thing remotely similar to what you need. Perhaps we should add a new internal function to libGL to help with this in the future. Would something like: const char * GLX_PREFIX(glXGetInternalAPIVersion)(void); in lib/GL/glx/glxcmd.c be acceptable? It would return a date string like _glapi_get_version. Then a driver would have to do the same dlsym trick that is done in __driRegisterExtensions in r200_screen.c to get the version. I could add a wrapper for that in common/utils.c (in the texmem branch). const char * __glXGetInternalAPIVersion(void); would be better. This should not be a public function. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Tue, Nov 19, 2002 at 10:55:12AM -0700, Brian Paul wrote: > Ian Romanick wrote: > > On Tue, Nov 19, 2002 at 08:35:45AM -0700, Brian Paul wrote: > >>Well, there isn't an official query like this, but there is the > >>_glapi_get_version() function which returns the version of the dispatcher > >>code. See the top of glapi.c for the version history. > > > > > > This seems a little hinkey to me. If I'm adding new data structures or > > dispatch functions to, for example, __DRIcontext or __DRIdrawable, I need to > > bump a version in a file that comes from extras/Mesa/src? That just seems > > weird and potentially problematic to me. :) > > Right. It's not the real solution to your problem. But it's the only > thing remotely similar to what you need. > > Perhaps we should add a new internal function to libGL to help with this > in the future. Would something like: const char * GLX_PREFIX(glXGetInternalAPIVersion)(void); in lib/GL/glx/glxcmd.c be acceptable? It would return a date string like _glapi_get_version. Then a driver would have to do the same dlsym trick that is done in __driRegisterExtensions in r200_screen.c to get the version. I could add a wrapper for that in common/utils.c (in the texmem branch). -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Tue, Nov 19, 2002 at 09:53:28AM +0100, Johannes Rath wrote: > Jens Owen wrote: > > > Oddly enough, ATI provides a libGL.so replacement in their package. I'm > > not sure why they do this. > > You don't neccessary need to replace libGL.so.1.2 If you do not, you just > loose some extended functionality like GLX 1.3 pbuffers. That make sense. Just so that I know that I'm putting my time in the "right" places, which GLX extensions / features to ATI and PowerVR care about? fbconfig and pbuffers are obvious, but which other ones? -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: On Tue, Nov 19, 2002 at 08:35:45AM -0700, Brian Paul wrote: Allen Akin wrote: On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote: | | How does one go about determining the (data structure / API) version of | libGL.so? As I understand it, there isn't a formal version number. Apps that follow the Linux ABI shouldn't need to be aware of the libGL version, so there isn't one. http://oss.sgi.com/projects/ogl-sample/ABI/ The closed-source OpenGL implementations apparently don't meet the ABI standard yet. (At least, NVIDIA's doesn't; can't speak firsthand for any others.) I think Ian might be looking for an internal version number so he can test how new libGL is from within a DRI driver. Is that right, Ian? Correct. Well, there isn't an official query like this, but there is the _glapi_get_version() function which returns the version of the dispatcher code. See the top of glapi.c for the version history. This seems a little hinkey to me. If I'm adding new data structures or dispatch functions to, for example, __DRIcontext or __DRIdrawable, I need to bump a version in a file that comes from extras/Mesa/src? That just seems weird and potentially problematic to me. :) Right. It's not the real solution to your problem. But it's the only thing remotely similar to what you need. Perhaps we should add a new internal function to libGL to help with this in the future. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Tue, Nov 19, 2002 at 08:35:45AM -0700, Brian Paul wrote: > Allen Akin wrote: > > On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote: > > | > > | How does one go about determining the (data structure / API) version of > > | libGL.so? > > > > As I understand it, there isn't a formal version number. Apps that > > follow the Linux ABI shouldn't need to be aware of the libGL version, > > so there isn't one. > > > > http://oss.sgi.com/projects/ogl-sample/ABI/ > > > > The closed-source OpenGL implementations apparently don't meet the ABI > > standard yet. (At least, NVIDIA's doesn't; can't speak firsthand for > > any others.) > > I think Ian might be looking for an internal version number so he can > test how new libGL is from within a DRI driver. Is that right, Ian? Correct. > Well, there isn't an official query like this, but there is the > _glapi_get_version() function which returns the version of the dispatcher > code. See the top of glapi.c for the version history. This seems a little hinkey to me. If I'm adding new data structures or dispatch functions to, for example, __DRIcontext or __DRIdrawable, I need to bump a version in a file that comes from extras/Mesa/src? That just seems weird and potentially problematic to me. :) -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian, I happened to be looking at glxcmds.c. The glXSwapIntervalSGI() function is already there (along with most known GLX extension functions). It's just a stub though. I had forgotten that I added stub functions for most/all GLX extensions a few years ago, hoping it would simplify things down the road. That should help you. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Allen Akin wrote: On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote: | | How does one go about determining the (data structure / API) version of | libGL.so? As I understand it, there isn't a formal version number. Apps that follow the Linux ABI shouldn't need to be aware of the libGL version, so there isn't one. http://oss.sgi.com/projects/ogl-sample/ABI/ The closed-source OpenGL implementations apparently don't meet the ABI standard yet. (At least, NVIDIA's doesn't; can't speak firsthand for any others.) I think Ian might be looking for an internal version number so he can test how new libGL is from within a DRI driver. Is that right, Ian? Well, there isn't an official query like this, but there is the _glapi_get_version() function which returns the version of the dispatcher code. See the top of glapi.c for the version history. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
AW: [Dri-devel] Adding GLX extensions?
Title: AW: [Dri-devel] Adding GLX extensions? Jens Owen wrote: > Oddly enough, ATI provides a libGL.so replacement in their package. I'm > not sure why they do this. You don't neccessary need to replace libGL.so.1.2 If you do not, you just loose some extended functionality like GLX 1.3 pbuffers. Johannes
Re: [Dri-devel] Adding GLX extensions?
On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote: | | How does one go about determining the (data structure / API) version of | libGL.so? As I understand it, there isn't a formal version number. Apps that follow the Linux ABI shouldn't need to be aware of the libGL version, so there isn't one. http://oss.sgi.com/projects/ogl-sample/ABI/ The closed-source OpenGL implementations apparently don't meet the ABI standard yet. (At least, NVIDIA's doesn't; can't speak firsthand for any others.) Allen --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Fri, Nov 15, 2002 at 12:02:28PM -0700, Brian Paul wrote: > This would involve implementing glXSwapInterval() as an ordinary > function in libGL. It would simply stuff the interval value into > the __GLXContextRec struct (assuming it's per-context). Then, it > would be up to the DRI driver(s) to check if libGL was new enough > before grabbing that value from the context rec. How does one go about determining the (data structure / API) version of libGL.so? -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Adding GLX extensions?
-Original Message- From: Ian Romanick [mailto:[EMAIL PROTECTED]] Sent: 15 November 2002 20:40 To: DRI developer's list Subject: Re: [Dri-devel] Adding GLX extensions? [...] > Hmmm...would adding it as a hard-coded extension make life easier for IHVs > that want to provide binary-only drivers but not necessarilly their own > libGL.so? I'm thinking ATI and PowerVR... yes, it would make our life easier :) [...] Vlad Stamate www.powervr.com --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: Hmmm...would adding it as a hard-coded extension make life easier for IHVs that want to provide binary-only drivers but not necessarilly their own libGL.so? I'm thinking ATI and PowerVR... Oddly enough, ATI provides a libGL.so replacement in their package. I'm not sure why they do this. The Linux user base would really benefit from driver packages that didn't interfere with each other. Replacing a critical library like libGL.so has a major impact on the other drivers loaded on the system. I'm not just picking on ATI, here...NVidia does this, too. PowerVR is a good example of a well thought out install package. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
If I do that, in glxinfo it only shows up in the 'client glx extensions', which makes sense given the way I'm doing it. In the Nvidia driver, it shows up in both 'client glx extnesions' and 'GLX extensions'. Evidently, NVIDIA supports the extension for indirect rendering too. NVIDIA's indirect renderer is the same as their client renderer - ie they're both hw accelerated and both (afaik) the same piece of code. Keith --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote:
On Fri, Nov 15, 2002 at 12:02:28PM -0700, Brian Paul wrote:
Ian Romanick wrote:
I'm going to implement SGI_swap_control (which adds glXSwapIntervalSGI)
first because implementing it in any of the drivers that supports the vblank
syncing would be trivial. That way 99% of the work in not device dependent.
:) In the R200 driver, the behavior of SGI_swap_control can be added by
changing r200WaitForVBlank to do something like:
if ( rmesa->swap_interval != 0 ) {
vbl.type = DRM_VBLANK_ABSOLUTE;
vbl.sequence = rmesa->vbl_seq + rmesa->swap_interval;
}
else if ( getenv("LIBGL_SYNC_REFRESH") ) {
...
The only catch is that I can find NO documentation of the GLX protocol for
it. Given that, I'm going to implement it for direct rendering contexts
only. I believe that this could be done by either adding a new entry point
to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec
and adding a DRIswapInterval function to dri_util.c.
I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look
either like glXSwapBuffers or glXUseXFont (for their gc->isDirect cases,
anyway).
You have two choices:
1. A dynamically registered extension
[snip]
2. As a hard-coded extension
[snip]
Hmmm...would adding it as a hard-coded extension make life easier for IHVs
that want to provide binary-only drivers but not necessarilly their own
libGL.so? I'm thinking ATI and PowerVR...
I don't think it matters much either way.
What needs to be done in programs/Xserver/GL/glx/?
Nothing for a client-side-only GLX extension.
Okay. That's because that's the code that does the wire-protocol decoding
and dispatch, right?
right.
> How do I get the
extension string exported? This also applies to the
GLX_ARB_get_proc_address string. :)
Add it to __glXGLXDefaultClientExtensions[] in glx/glxcmds.c
If I do that, in glxinfo it only shows up in the 'client glx extensions',
which makes sense given the way I'm doing it. In the Nvidia driver, it
shows up in both 'client glx extnesions' and 'GLX extensions'.
Evidently, NVIDIA supports the extension for indirect rendering too.
> From the perspective on an ISV, where SHOULD it appear?
[Note that GLX has 3 functions for querying extensions...]
From my understanding, it depends on the particular extension. If a GLX
extension really only is client-side-only, then it'll only appear in the
string returned by glXGetClientString(dpy, GLX_EXTENSIONS).
glXQueryServerString(dpy, scrn, GLX_EXTENSIONS) will return the names of
extensions that are implemented in the server. But you won't be able to
use them if the same extension isn't implemented on the client side by
libGL.
If a GLX extension is implemented by both client and server, then it should
appear in glXQueryExtensionsString(dpy, scrn) since it computes the inter-
section of the extension strings.
That said, I don't know why NVIDIA's driver returns GLX_ARB_get_proc_address
from glXQueryExtensionsString().
-Brian
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Fri, Nov 15, 2002 at 12:02:28PM -0700, Brian Paul wrote:
> Ian Romanick wrote:
> > I'm going to implement SGI_swap_control (which adds glXSwapIntervalSGI)
> > first because implementing it in any of the drivers that supports the vblank
> > syncing would be trivial. That way 99% of the work in not device dependent.
> > :) In the R200 driver, the behavior of SGI_swap_control can be added by
> > changing r200WaitForVBlank to do something like:
> >
> >if ( rmesa->swap_interval != 0 ) {
> > vbl.type = DRM_VBLANK_ABSOLUTE;
> > vbl.sequence = rmesa->vbl_seq + rmesa->swap_interval;
> >}
> >else if ( getenv("LIBGL_SYNC_REFRESH") ) {
> > ...
> >
> > The only catch is that I can find NO documentation of the GLX protocol for
> > it. Given that, I'm going to implement it for direct rendering contexts
> > only. I believe that this could be done by either adding a new entry point
> > to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec
> > and adding a DRIswapInterval function to dri_util.c.
> >
> > I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look
> > either like glXSwapBuffers or glXUseXFont (for their gc->isDirect cases,
> > anyway).
>
> You have two choices:
>
> 1. A dynamically registered extension
[snip]
> 2. As a hard-coded extension
[snip]
Hmmm...would adding it as a hard-coded extension make life easier for IHVs
that want to provide binary-only drivers but not necessarilly their own
libGL.so? I'm thinking ATI and PowerVR...
> > What needs to be done in programs/Xserver/GL/glx/?
>
> Nothing for a client-side-only GLX extension.
Okay. That's because that's the code that does the wire-protocol decoding
and dispatch, right?
> > How do I get the
> > extension string exported? This also applies to the
> > GLX_ARB_get_proc_address string. :)
>
> Add it to __glXGLXDefaultClientExtensions[] in glx/glxcmds.c
If I do that, in glxinfo it only shows up in the 'client glx extensions',
which makes sense given the way I'm doing it. In the Nvidia driver, it
shows up in both 'client glx extnesions' and 'GLX extensions'. From the
perspective on an ISV, where SHOULD it appear?
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote:
On Fri, Nov 15, 2002 at 07:45:21AM -0700, Brian Paul wrote:
Jens Owen wrote:
Ian Romanick wrote:
Can I get a quick run-down of the GLX code so that I can know where to
begin?
Most of the server side support for GLX proper is in:
xc/programs/Xserver/GL/glx
This provides the main extension for indirect rendering and interfaces
with the "../dri" and another glue piece "../mesa/src/X", I think, to
complete the server side support.
The client side support is in:
xc/lib/GL/glx
That's basically it. If you've got detailed questions I can try to
answer them. Adding new extensions which just add new enum values
is pretty simple. Adding new GL/GLX functions is more work since you
have to implement the GLX encode/decode functions and server-side
dispatch.
I'm going to implement SGI_swap_control (which adds glXSwapIntervalSGI)
first because implementing it in any of the drivers that supports the vblank
syncing would be trivial. That way 99% of the work in not device dependent.
:) In the R200 driver, the behavior of SGI_swap_control can be added by
changing r200WaitForVBlank to do something like:
if ( rmesa->swap_interval != 0 ) {
vbl.type = DRM_VBLANK_ABSOLUTE;
vbl.sequence = rmesa->vbl_seq + rmesa->swap_interval;
}
else if ( getenv("LIBGL_SYNC_REFRESH") ) {
...
The only catch is that I can find NO documentation of the GLX protocol for
it. Given that, I'm going to implement it for direct rendering contexts
only. I believe that this could be done by either adding a new entry point
to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec
and adding a DRIswapInterval function to dri_util.c.
I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look
either like glXSwapBuffers or glXUseXFont (for their gc->isDirect cases,
anyway).
You have two choices:
1. A dynamically registered extension
In October I implemented a new mechanism in libGL to allow runtime
addition of new GLX extensions (not just GL extensions as it did before).
This will allow new DRI drivers to better work with older libGL libraries.
Basically, the driver calls __glXRegisterGLXFunction() and
__glXRegisterGLXExtensionString() to tell libGL about a new GLX extension.
If the user calls glXGetProcAddressARB("glXFoobarEXT") they'll get a
pointer to the new extension. And calls to glXQueryExtensionStrings()
will return the string registered with __glXRegisterGLXExtensionString().
To pull this off, libGL has a list of function name/address structs:
static struct name_address_pair *Dynamic_GLX_functions = NULL;
which keeps track of the functions registered with __glXRegisterGLXFunction().
glXGetProcAddressARB() just searches that list.
So, in principle you could and a server-side-only GLX extension to
libGL without ever touching the libGL code. But you should really
put a glXSwapInterval() function in libGL so that one can directly
call it without needing glXGetProcAddressARB().
The new glXAllocateMemoryNV() function would be good to follow as an
example of this.
Your implementation of glXSwapInterval() should also search this list.
You can cache the result of the search if you want.
In the r200 driver you'd have an r200SwapInterval() function that
got called via the glXGetProcAddressFunction(). This function would
just store the interval value in the rmesa context struct (assuming
that this value is per-context state - the spec doesn't say!).
2. As a hard-coded extension
This would involve implementing glXSwapInterval() as an ordinary
function in libGL. It would simply stuff the interval value into
the __GLXContextRec struct (assuming it's per-context). Then, it
would be up to the DRI driver(s) to check if libGL was new enough
before grabbing that value from the context rec.
One problem with this approach is that the extension would appear
to be present for all drivers, when it really isn't. We'd need
a new mechanism for DRI drivers to enable/disable GLX extensions
in a manner similar to Mesa's _mesa_enable/disable_extension().
The other problem is it would require the user to have the updated
libGL.so in addition to the new r200_dri.so driver.
What needs to be done in programs/Xserver/GL/glx/?
Nothing for a client-side-only GLX extension.
> How do I get the
extension string exported? This also applies to the
GLX_ARB_get_proc_address string. :)
Add it to __glXGLXDefaultClientExtensions[] in glx/glxcmds.c
-Brian
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Fri, Nov 15, 2002 at 07:45:21AM -0700, Brian Paul wrote:
> Jens Owen wrote:
> > Ian Romanick wrote:
> >
> >> Can I get a quick run-down of the GLX code so that I can know where to
> >> begin?
> >
> >
> > Most of the server side support for GLX proper is in:
> >
> > xc/programs/Xserver/GL/glx
> >
> > This provides the main extension for indirect rendering and interfaces
> > with the "../dri" and another glue piece "../mesa/src/X", I think, to
> > complete the server side support.
> >
> > The client side support is in:
> >
> > xc/lib/GL/glx
>
> That's basically it. If you've got detailed questions I can try to
> answer them. Adding new extensions which just add new enum values
> is pretty simple. Adding new GL/GLX functions is more work since you
> have to implement the GLX encode/decode functions and server-side
> dispatch.
I'm going to implement SGI_swap_control (which adds glXSwapIntervalSGI)
first because implementing it in any of the drivers that supports the vblank
syncing would be trivial. That way 99% of the work in not device dependent.
:) In the R200 driver, the behavior of SGI_swap_control can be added by
changing r200WaitForVBlank to do something like:
if ( rmesa->swap_interval != 0 ) {
vbl.type = DRM_VBLANK_ABSOLUTE;
vbl.sequence = rmesa->vbl_seq + rmesa->swap_interval;
}
else if ( getenv("LIBGL_SYNC_REFRESH") ) {
...
The only catch is that I can find NO documentation of the GLX protocol for
it. Given that, I'm going to implement it for direct rendering contexts
only. I believe that this could be done by either adding a new entry point
to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec
and adding a DRIswapInterval function to dri_util.c.
I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look
either like glXSwapBuffers or glXUseXFont (for their gc->isDirect cases,
anyway).
What needs to be done in programs/Xserver/GL/glx/? How do I get the
extension string exported? This also applies to the
GLX_ARB_get_proc_address string. :)
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Jens Owen wrote: Ian Romanick wrote: Can I get a quick run-down of the GLX code so that I can know where to begin? Most of the server side support for GLX proper is in: xc/programs/Xserver/GL/glx This provides the main extension for indirect rendering and interfaces with the "../dri" and another glue piece "../mesa/src/X", I think, to complete the server side support. The client side support is in: xc/lib/GL/glx That's basically it. If you've got detailed questions I can try to answer them. Adding new extensions which just add new enum values is pretty simple. Adding new GL/GLX functions is more work since you have to implement the GLX encode/decode functions and server-side dispatch. AFAIK, Brian uses lot's of magic and a couple of Newt's tails along with this module to build libGL.so It's not quite that bad, but there are a few sublties. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: Can I get a quick run-down of the GLX code so that I can know where to begin? Most of the server side support for GLX proper is in: xc/programs/Xserver/GL/glx This provides the main extension for indirect rendering and interfaces with the "../dri" and another glue piece "../mesa/src/X", I think, to complete the server side support. The client side support is in: xc/lib/GL/glx AFAIK, Brian uses lot's of magic and a couple of Newt's tails along with this module to build libGL.so Once I get started, I should be able to figure out the details & submit some additions to the developer's FAQ. :) That would be great. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Adding GLX extensions?
Since one of the ultimate goals of the texmem branches was to enable implementing GLX_SGIX_pbuffer, I've been looking into adding extensions to GLX. What I'd like to do is start by adding 2 (or 3) simple extensions to get the hang of it, but I'm a bit stuck. There is GLX code in several different places in the tree, I'm not quite positive how it all inter-relates. I'd like to start by adding GLX_SGI_swap_control and a slightly modified version (GLX_MESA_swap_control?) that allows 0 to be specified as an interval. After that, I'd like to dig into GLX_SGIX_fbconfig since it's required by GLX_SGIX_pbuffer. Can I get a quick run-down of the GLX code so that I can know where to begin? Once I get started, I should be able to figure out the details & submit some additions to the developer's FAQ. :) Also, should the extension string for GLX_ARB_get_proc_address be exported? glxinfo doesn't show it. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
