Bug 3652

Summary:

Add support for GLX_SGIX_hyperpipe and GLX_SGIX_swap_barrier

Product:

xorg

Reporter:

Eric Kunze <ekunze>

Component:

Server/General

Assignee:

Adam Jackson <ajax>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

high

CC:

alexdeucher, idr

Version:

unspecified

Hardware:

SGI

OS:

All

Whiteboard:

i915 platform:

i915 features:

Bug Depends on:

Bug Blocks:

1690

Attachments:

Description	Flags
glx-hyperpipe-and-swapbarriers-2.patch	none

Description Eric Kunze 2005-06-28 16:55:27 UTC

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.

Comment 1 Eric Kunze 2005-06-28 19:52:49 UTC

Created attachment 2987 [details] [review]
Use system method for byte/word accesses (take 3)

patch for cvs head to provide sgi glx extensions.

Comment 2 Ian Romanick 2005-06-30 09:24:21 UTC

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?

Comment 3 Adam Jackson 2005-07-02 09:37:30 UTC

(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.

Comment 4 Adam Jackson 2005-08-29 16:57:48 UTC

Created attachment 3103 [details] [review]
glx-hyperpipe-and-swapbarriers-2.patch

reattach (lousy disk crash), and fix the enum to 92.

Comment 5 Adam Jackson 2005-10-04 18:21:19 UTC

any further comment on the acceptability of this?

Comment 6 Ian Romanick 2005-10-05 10:31:31 UTC

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.

Comment 7 Adam Jackson 2005-10-05 15:40:05 UTC

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.