Subject:
|
Re: LDGLite colour bug
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 15 Jan 2002 18:19:16 GMT
|
Viewed:
|
575 times
|
| |
|
|
In lugnet.cad.dev, Don Heyse writes:
> In lugnet.cad.dev, Travis Cobbs writes:
> >
> > "Don Heyse" <dheyse@hotmail.spam.go.away.com> wrote in message
> > news:GpF5sJ.66C@lugnet.com...
> > > In lugnet.cad.dev, Jacob Sparre Andersen writes:
> > > > What do you mean by "using the Mesa driver"? In both cases
> > > > the example was rendered directly on the monitor of a third
> > > > (Intel based) machine over the network.
> > >
> > > The third machine with the monitor is immaterial. The opengl
> > > driver runs on the machine where the ldglite executable is
> > > running. Based on your use of a remote display, I'm going to
> > > assume you're probably running linux (and most likely a Mesa
> > > opengl driver) on the intel machine where you ran the ldglite
> > > executable. Does it have the same version of Mesa? On
> > > ldraw.org, ldglite prints this when I run it:
> > >
> > > GL_VERSION = 1.2 Mesa 3.4
> > >
> > > What does the intel machine say?
> >
> > Actually, with a remote OpenGL display setup, OpenGL drivers can be active
> > on both machines. If Mesa supports the GLX protocol, and the machine he is
> > displaying onto also supports GLX, then the ldglite machine will simply
> > create the OpenGL commands and then send them over the network for the other
> > machine to interpret and display.
>
> Really? Where can I get more information on this? I was under the
> impression that GLX could only accelerate locally when used with DRI.
> I had no idea it had its own remote rendering protocol. Is this
> something new in XFree 4.0? Is there any way to tell if it's being
> used, perhaps something with glXQueryServerString() or glXIsDirect()?
> (Actually I'd prefer a glut or gl function for this since I'm not
> currently calling any GLX functions directly.)
>
> > This is significantly faster than trying to render on the remote machine and
> > then send the bitmap graphics over the wire. However, it means that the
> > actual OpenGL rendering is done on his local workstation. The remote
> > machine simply creates the list of commands to call.
>
> That sounds great, but makes troubleshooting a bit tougher unless I
> can tell who is doing the rendering. Does glGetString(GL_VERSION) get
> passed via the GLX protocol to the remote machine?
>
> Don
I did a quick check and found a few things you should find useful. At
opengl.org I found a good definition of what GLX is (which includes the
remote display portion):
http://www.opengl.org/developers/documentation/glx.html
The above also contains a link to the GLX specification (which may or may not
be useful to you).
At xfree86.org I found some limited information about remote display as
implemented in XFree86 4.0.1:
http://www.xfree86.org/4.0.1/DRI6.html
(Read section 6.1). In addition, under a different section of the same
document (Limitations and Known Bugs) it states that one of the limitations
is lack of support for hardware-accelerated indirect rendering:
http://www.xfree86.org/4.0.1/DRI9.html
This is significant because the previous section stated or at least strongly
implied that remote rendering was equivalent to indirect rendering.
While I'm not sure, my guess after reading all this is that semi-recent
versions of Mesa will use the GLX wire protocol for remote display (with
possible fallback to standard X wire protocol). However, when the GLX
commands are received on your local machine, they are rendered using software
without hardware acceleration. I'm not sure about that, though.
From a historical standpoint, Mesa could not originally provide support for
the GLX wire protocol, because it has to be implemented in the X server. Up
until XFree86 4.0 was released, XFree86 had no support for GLX. So Mesa
used the standard X remote display mechanism.
SGIs, on the other hand, could only remotely display OpenGL apps using the
GLX wire protocol, so you could not remotely display an SGI OpenGL app to a
Linux machine, even if the Linux machine had Mesa (unless you convinced the
SGI to use a local Mesa for its OpenGL rendering instead of the system OpenGL
library).
Then XFree86 4.0 added support for GLX. I'm not entirely sure what happened
at that point. At a guess, you gained instant support to run an OpenGL app
on an SGI and display it on a Linux box. However, until and unless Mesa was
updated to use GLX for remote display, displaying from a Linux box to another
Linux box would still use the old X remote display mechanism. But since
XFree86 4.0 was released so long ago, I would think it would be reasonable
to expect Mesa to now support GLX for remote rendering.
Now none of this directly answered some of your questions, but hopefully I
have provided enough information for you to know where to start looking. I
don't know the direct answers to the other questions. The version part could
be checked relatively easily, though: install a different version on the local
and remote machines and see what version number you get back when you
ask for it. I believe that xdpyinfo will tell you if the X Server you are
displaying to supports GLX (as one of the X Server extensions). This won't
tell you if Mesa is using it, though. Hopefully the Mesa documentation will
mention it somewhere.
|
|
Message has 1 Reply:
 | | Re: LDGLite colour bug
|
| In lugnet.cad.dev, Travis Cobbs writes: ... (...) Yes, I think that would work. Perhaps Jacob could install Mesa 4.1 on one of his (apparently) many machines and try this? I would, but I don't have the hardware available, and after all, he did start (...) (22 years ago, 16-Jan-02, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: LDGLite colour bug
|
| (...) Really? Where can I get more information on this? I was under the impression that GLX could only accelerate locally when used with DRI. I had no idea it had its own remote rendering protocol. Is this something new in XFree 4.0? Is there any (...) (22 years ago, 15-Jan-02, to lugnet.cad.dev)
|
14 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
