SGI systems with multiple graphics cards use the SGIX_hyperpipe, and SGIX_swap_barrier extensions to control rendering across multiple pipes. These extensions need server side dispatch to a function provided by the driver. I've put together a patch which adds two new entrypoints to the glx module to allow screens to register hyperpipe and swapbarrier functions to be called when the glx commands are received by the server. For systems which do not register these functions, there should be no impact.
Created attachment 2987 [details] [review] Use system method for byte/word accesses (take 3) patch for cvs head to provide sgi glx extensions.
I've reviewed the patch, and I have a couple comments. In general, until we have DRI drivers loaded in the X-server, this looks like the right approach. However, I would like to see some additional documentation, probably at __glXHyperpipeInit and __glXSwapBarrierInit, that describes how drivers hook into the functionality. I assume that the driver would just call these functions with the right datastructures, but from where and when is it right to make those calls? As a *really* minor nit, there are a couple whitespace issues. The indentation of the extension strings in glxscreens.c is wrong, and there's at least one stray blank line added (also in glxscreens.c). Also, is there going to be a similar patch for the client-side?
(In reply to comment #2) > I've reviewed the patch, and I have a couple comments. In general, until we > have DRI drivers loaded in the X-server, this looks like the right approach. > However, I would like to see some additional documentation, probably at > __glXHyperpipeInit and __glXSwapBarrierInit, that describes how drivers hook > into the functionality. I assume that the driver would just call these > functions with the right datastructures, but from where and when is it right to > make those calls? Any time in DDX init when the driver knows it has enough info to support hardware GLX. We do it at the bottom of the driver's ScreenInit, which seems like the right place. I'll document this in the patch. > As a *really* minor nit, there are a couple whitespace issues. The indentation > of the extension strings in glxscreens.c is wrong, and there's at least one > stray blank line added (also in glxscreens.c). And some trailing whitespace. And the GLX_BAD_HYPERPIPE_GLX token is defined wrong, according to the spec.
Created attachment 3103 [details] [review] glx-hyperpipe-and-swapbarriers-2.patch reattach (lousy disk crash), and fix the enum to 92.
any further comment on the acceptability of this?
I'd like to see some of the text from your 2005-07-02 09:37 comment documenting __glXHyperpipeInit and __glXSwapBarrierInit. Other than that, it looks fine to me.
applied, with additional commentary and whitespace cleanups. thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.