Ian Romanick wrote:

Log message:
Incorporate all changes from the driinterface-0-0-2-branch.
Obtained from: driinterface-0-0-2-branch

In the past I have had a DRI / non-DRI time split of 90%/10%. As of last Monday that switched to 10%/90%. This has caused me to change some of the DRI related plans. Here are my intentions for the short-term future.


1. Commit some minor changes to the r200 driver to use the new interfaces. This will go in Mesa trunk, but will be guarded by #ifdef. This is needed because the code calls some functions in dri_util.c that only exist in the branch.

2. Finish adding at least rudimentary server-side fbconfig support to the 0-0-3 branch. Looking at my 0-0-2 tree, which I haven't touched since November, it looks like most of the work has actually been done. That should allow us to enable GLX_SGIX_fbconfig in any driver that uses the new interfaces (i.e., r200 initially).

3. After some testing and "cool down" period, merge the branch into the trunk. I expect this to happen fairly quickly.

4. Create a driinterface-0-0-4-branch. The purpose of this branch will be to implement GLX protocol and indirect rendering support for pbuffers. *LOTS* of work will need to be done to the driver to enable pbuffers, so that won't be part of this branch. Once this is done, the client library and server will be able to advertise GLX 1.3 (for indirect rendering anyway).

If someone can add protocol support for ARB_texture_compression, we can actually advertise support for GLX 1.4. Since there is already protocol support for the new functionality in GL 1.4, we may even be able to advertise GLX 1.5, but I'm not 100% sure about that. There's no "official" spec for either GLX 1.4 or GLX 1.5. :(

5. After some testing and "cool down" period, merge the branch into the trunk. I expect this to happen fairly quickly.

At that point, I probably won't be able to do very much "big". The "big" things that will need to be done at that point are:

1. Enable GLX_SGI_make_current_read support in all drivers. The MGA driver already supports this extension. I did a patch once, which I'll have to find, that enabled it for r200, but the patch only worked with pageflipping disabled. People can start working on this now, if they like. :)

2. Port all drivers to the new interfaces. My intention is for the new interfaces to be the *only* interfaces in XFree86 5.0.0 (whenever that happens). They should also be the only interfaces for stand-alone drivers. This can start as soon as I commit my changes to the r200 driver.

3. Pave the way for pbuffer support in the drivers. Work may need to be done to support odd back/front/depth buffer combinations that will happen with pbuffers. Ideally we should be able to support things like pbuffers with 32-bit color and 16-bit depth (or vice-versa), etc. Once the pbuffer protocol is in, real pbuffer support can be done. I think the easiest way to do this will be to reserver a portion of off screen memory for pbuffers. Apps will allocate memory from this and use it for their pbuffer.

4. Change the interface between libglx.a and libGLcore.a to be the same as the interface between libGL.so and *_dri.so. This is *BIG*, but important. I will start doing some of this with the server-side work that I'm doing, but it's way more project than I have time to tackle. The ultimate goal of this is, of course, to get server-side accelerated 3D. I don't really expect much of this to be done until after the dust settles from the other changes.




------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to