Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Høgsberg wrote: > Ok, big disclaimer here: I haven't looked into glucose or even glitz > much, so what I'm suggesting here may not apply. But my take is that > we shouldn't be loading libGL in the X server to begin with. If we > want to use opengl in the X server we should call into the dispatch > table directly (as for example the __glXDRIbindTexImage implementation > in GL/glx/glxdri.c: > > CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? > GL_TEXTURE_BINDING_2D : > GL_TEXTURE_BINDING_RECTANGLE_NV, > &texname)); I think that's correct. Alternately (preferably?) we could generate a fake libGL or gl_calls.h or something so that we can do glGetIntegerv(...) and have it be expanded directly to the above for us. We shouldn't link libGL with the X server any more than we'd link Xlib with it. > and we may have to export some of the GLX code for use inside the X > server (creating glx drawables and contexts etc) and separate out the > protocol stuff. Basically if we have to hack around linking issues > and fudge symbol resolution issues we're doing something wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+v30X1gOwKyEAw8RAqSkAJ9weVM3XSBzC5bL84xVwJ9D5KtkXgCdEfgm BRH8+WHsAB1oRAwbW7JgTC0= =59EP -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11174] Regression (missing / black vertices) between 6.4.2 and 6.5.1 (with trackballs)
http://bugs.freedesktop.org/show_bug.cgi?id=11174 --- Comment #9 from [EMAIL PROTECTED] 2007-09-26 14:42 PST --- (In reply to comment #7) > I gave this a very quick try, and it indeed looks horrible (on r200). For me > though it always looks horrible, I don't have to press space. Also, it doesn't > just look black, it more looks like z-fighting issues so it flickers black. > Not sure if that's related, but unless this is a bug in mesa (with display > list > handling?), the game does some things it shouldn't do - there are tons of mesa > warnings about stack overflows (mostly in the menu) and stack underflows > (in-game) with the projection/modelview matrix stacks (and it tries to use an > illegal filter mode for the texture mag filter, but that should be harmless). > This app uses GL_LINE polygon mode, which causes a tcl fallback in the r200 > driver, which could lead to z-fighting - but even specifiying tcl_mode=0 > doesn't do anything. > With the software rasterizer, it looks almost ok though - there are a lot of > very small white triangles flying around randomly (maybe that represents some > snow or something and is meant to be there), and the tile boundaries look > crappy (they are somewhat disjoint, I think the game uses the GL_LINE poly > mode > to draw the tile borders (with polygonoffset) and then GL_FILL mode for the > tile, but it doesn't seem to quite match up with the neighboring tiles). > Thanks for looking into this, I already had a hunch that this might actually be a trackballs problem, as all other OpenGL apps seem to work fine. I've mailed upstream about this. Id there anything obvious I can check for in the trackballs source while we are waiting for upstream to respond? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On Wed, 2007-09-26 at 14:15 -0400, Kristian Høgsberg wrote: > On 9/20/07, José Fonseca <[EMAIL PROTECTED]> wrote: > > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > > However, when loaded, references to __glXFreeContext *inside* > > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > > > If you have multiple definitions for a symbol it is completely random > > > which a given reference will resolve to. > > > > > > Now, the two underscores are a good hint that these are internal symbols > > > and they should not be exported at all or if they have to, one of them > > > must be renamed. > > > > > > > libtool's -export-dynamic flag is not being used. Using libtool's > > > > -module > > > > flag doesn't change anything. > > > > > > Does this symbol have to be exported? If no, you should use libtool's > > > --export-symbol feature to explicitely declare which symbols should be > > > visible and which should not. In fact, it is always wise to use > > > --export-symbol when creating shared libraries to prevent ABI breakage > > > by accidentally exporting private symbols. > > > > > > If __glXFreeContext should be exported, then it should be decided which > > > library owns this symbol, and the other must be modified not to export > > > it. > > > > > > If it is the case that libGL.so exports __glXFreeContext but > > > libglxgext.so wants to locally override it, and for some reason you > > > absolutely cannot rename it, then you must use gcc's > > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > > in libglgxext.so, but that is not portable to non-ELF platforms and > > > other compilers and also has run-time performance costs IIRC. > > > > I agree in principle with your suggestions. But I'm not entitled to > > decide if __glX* symbols > > should or not be exported, nor to say what's the best way to accomplish it. > > > > I know that __glX* functions came originally from SGI code. From there > > derived copies appear on mesa (for libGL), and more than once in > > xserver code -- I suppose always for indirect rendering purposes (in > > places such as AIGLX, DMX, and Xgl). It is likely that other vendors > > also ship libGL exporting those symbols. > > > > But it would definitely make things simpler and less likely to break > > if the __glX* symbols were not exported... > > Ok, big disclaimer here: I haven't looked into glucose or even glitz > much, so what I'm suggesting here may not apply. But my take is that > we shouldn't be loading libGL in the X server to begin with. If we > want to use opengl in the X server we should call into the dispatch > table directly (as for example the __glXDRIbindTexImage implementation > in GL/glx/glxdri.c: > > CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? > GL_TEXTURE_BINDING_2D : > GL_TEXTURE_BINDING_RECTANGLE_NV, > &texname)); > > and we may have to export some of the GLX code for use inside the X > server (creating glx drawables and contexts etc) and separate out the > protocol stuff. Basically if we have to hack around linking issues > and fudge symbol resolution issues we're doing something wrong. glucose is already doing what you say above Kristian, it's definitely not loading libGL. Remember Xgl is an OpenGL client, and that's where the problems are caused. Nothing to do with glucose here. Alan. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On 9/26/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > On 9/20/07, José Fonseca <[EMAIL PROTECTED]> wrote: > > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > > However, when loaded, references to __glXFreeContext *inside* > > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > > > If you have multiple definitions for a symbol it is completely random > > > which a given reference will resolve to. > > > > > > Now, the two underscores are a good hint that these are internal symbols > > > and they should not be exported at all or if they have to, one of them > > > must be renamed. > > > > > > > libtool's -export-dynamic flag is not being used. Using libtool's > > > > -module > > > > flag doesn't change anything. > > > > > > Does this symbol have to be exported? If no, you should use libtool's > > > --export-symbol feature to explicitely declare which symbols should be > > > visible and which should not. In fact, it is always wise to use > > > --export-symbol when creating shared libraries to prevent ABI breakage > > > by accidentally exporting private symbols. > > > > > > If __glXFreeContext should be exported, then it should be decided which > > > library owns this symbol, and the other must be modified not to export > > > it. > > > > > > If it is the case that libGL.so exports __glXFreeContext but > > > libglxgext.so wants to locally override it, and for some reason you > > > absolutely cannot rename it, then you must use gcc's > > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > > in libglgxext.so, but that is not portable to non-ELF platforms and > > > other compilers and also has run-time performance costs IIRC. > > > > I agree in principle with your suggestions. But I'm not entitled to > > decide if __glX* symbols > > should or not be exported, nor to say what's the best way to accomplish it. > > > > I know that __glX* functions came originally from SGI code. From there > > derived copies appear on mesa (for libGL), and more than once in > > xserver code -- I suppose always for indirect rendering purposes (in > > places such as AIGLX, DMX, and Xgl). It is likely that other vendors > > also ship libGL exporting those symbols. > > > > But it would definitely make things simpler and less likely to break > > if the __glX* symbols were not exported... > > Ok, big disclaimer here: I haven't looked into glucose or even glitz > much, so what I'm suggesting here may not apply. But my take is that > we shouldn't be loading libGL in the X server to begin with. If we > want to use opengl in the X server we should call into the dispatch > table directly (as for example the __glXDRIbindTexImage implementation > in GL/glx/glxdri.c: > > CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? > GL_TEXTURE_BINDING_2D : > GL_TEXTURE_BINDING_RECTANGLE_NV, > &texname)); > > and we may have to export some of the GLX code for use inside the X > server (creating glx drawables and contexts etc) and separate out the > protocol stuff. Basically if we have to hack around linking issues > and fudge symbol resolution issues we're doing something wrong. The thread's subject is a bit misleading, but this problem actually only happens on Xgl (which is supposed to link to the system /usr/lib/libGL which may even have nothing to do with the DRI, but it get's duplicates when it does). glucose reuses some of the Xgl code, but it bypasses libGL, and uses AIGLX as you are suggesting. José Fonseca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On 9/20/07, José Fonseca <[EMAIL PROTECTED]> wrote: > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > However, when loaded, references to __glXFreeContext *inside* > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > If you have multiple definitions for a symbol it is completely random > > which a given reference will resolve to. > > > > Now, the two underscores are a good hint that these are internal symbols > > and they should not be exported at all or if they have to, one of them > > must be renamed. > > > > > libtool's -export-dynamic flag is not being used. Using libtool's -module > > > flag doesn't change anything. > > > > Does this symbol have to be exported? If no, you should use libtool's > > --export-symbol feature to explicitely declare which symbols should be > > visible and which should not. In fact, it is always wise to use > > --export-symbol when creating shared libraries to prevent ABI breakage > > by accidentally exporting private symbols. > > > > If __glXFreeContext should be exported, then it should be decided which > > library owns this symbol, and the other must be modified not to export > > it. > > > > If it is the case that libGL.so exports __glXFreeContext but > > libglxgext.so wants to locally override it, and for some reason you > > absolutely cannot rename it, then you must use gcc's > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > in libglgxext.so, but that is not portable to non-ELF platforms and > > other compilers and also has run-time performance costs IIRC. > > I agree in principle with your suggestions. But I'm not entitled to > decide if __glX* symbols > should or not be exported, nor to say what's the best way to accomplish it. > > I know that __glX* functions came originally from SGI code. From there > derived copies appear on mesa (for libGL), and more than once in > xserver code -- I suppose always for indirect rendering purposes (in > places such as AIGLX, DMX, and Xgl). It is likely that other vendors > also ship libGL exporting those symbols. > > But it would definitely make things simpler and less likely to break > if the __glX* symbols were not exported... Ok, big disclaimer here: I haven't looked into glucose or even glitz much, so what I'm suggesting here may not apply. But my take is that we shouldn't be loading libGL in the X server to begin with. If we want to use opengl in the X server we should call into the dispatch table directly (as for example the __glXDRIbindTexImage implementation in GL/glx/glxdri.c: CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? GL_TEXTURE_BINDING_2D : GL_TEXTURE_BINDING_RECTANGLE_NV, &texname)); and we may have to export some of the GLX code for use inside the X server (creating glx drawables and contexts etc) and separate out the protocol stuff. Basically if we have to hack around linking issues and fudge symbol resolution issues we're doing something wrong. cheers, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11174] Regression (missing / black vertices) between 6.4.2 and 6.5.1 (with trackballs)
http://bugs.freedesktop.org/show_bug.cgi?id=11174 --- Comment #8 from [EMAIL PROTECTED] 2007-09-26 07:52 PST --- (In reply to comment #6) > Erm, was mesa already using git in the 6.4.2 days? It was probably using CVS at the time, but the whole development history was preserved when moving to Git, so this isn't a problem. > Also installing 6.4.2 requires me to downgrade several key Operating system > parts like the xserver, libdrm, etc. It shouldn't. You don't even need to install anything, just set the environment variable LIBGL_DRIVERS_PATH=/path/to/directory_containing_r300_dri.so/ and possibly LD_LIBRARY_PATH=/path/to/libGL.so.1 . > I don't want to know what I have todo to my system to be able to build 6.4.2 > from source. Again, I'm not sure there should be any big trouble. You may want to use make DRI_DIRS=r300 to avoid any trouble with other drivers though. > As said I'm willing to spend some time on this, but telling me to go fetch a > needle in a haystack isn't really helpful. git-bisect does that for you. :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mesa 7.0.2 coming soon
Just FYI: There's been a fair number of bug fixes on the Mesa 7.0.x branch and a few people have asked me about the next release so I'm planning to release 7.0.2 in the next few days. I'm cherry-picking a few recent fixes from master and have a few patches to apply yet... -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11174] Regression (missing / black vertices) between 6.4.2 and 6.5.1 (with trackballs)
http://bugs.freedesktop.org/show_bug.cgi?id=11174 --- Comment #7 from [EMAIL PROTECTED] 2007-09-26 07:13 PST --- I gave this a very quick try, and it indeed looks horrible (on r200). For me though it always looks horrible, I don't have to press space. Also, it doesn't just look black, it more looks like z-fighting issues so it flickers black. Not sure if that's related, but unless this is a bug in mesa (with display list handling?), the game does some things it shouldn't do - there are tons of mesa warnings about stack overflows (mostly in the menu) and stack underflows (in-game) with the projection/modelview matrix stacks (and it tries to use an illegal filter mode for the texture mag filter, but that should be harmless). This app uses GL_LINE polygon mode, which causes a tcl fallback in the r200 driver, which could lead to z-fighting - but even specifiying tcl_mode=0 doesn't do anything. With the software rasterizer, it looks almost ok though - there are a lot of very small white triangles flying around randomly (maybe that represents some snow or something and is meant to be there), and the tile boundaries look crappy (they are somewhat disjoint, I think the game uses the GL_LINE poly mode to draw the tile borders (with polygonoffset) and then GL_FILL mode for the tile, but it doesn't seem to quite match up with the neighboring tiles). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa3D threadsafe?
John Stavrakakis wrote: > Hi all, > I have recently written some small test applications that use pthreads > to execute the commands between glBegin and glEnd in parallel. I have > crafted it so that each parallel item is a whole quad/triangle (no > STRIP). I know that the NVIDIA Linux driver has no support for this kind > of operation because it crashed :( But Mesa compiled with the -D > PTHREADS does! > > So I would like to know, are the operations that I am trying to perform > in fact thread safe and are producing the correct results, as they > appear correct by visual inspection, but for something larger I am > unable to know if/when glError occurs and may miss it of something is > going wrong. I also thought about using glFinish when I encounter glEnd, > but again I cant know if it in fact conforms to specification. > > glFinish - block until all GL execution is complete I suspect you're just getting lucky with Mesa. The GLX specification has some words about threading with OpenGL. Basically a rendering context can only be bound in one thread at any given time. If you're trying to use one rendering context in two or more threads at once, you're likely to get into trouble. -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11174] Regression (missing / black vertices) between 6.4.2 and 6.5.1 (with trackballs)
http://bugs.freedesktop.org/show_bug.cgi?id=11174 --- Comment #6 from [EMAIL PROTECTED] 2007-09-26 06:54 PST --- I'm not using git, I'm using the Fedora development bracnh packages which are mesa-7.0.1 + a patch updating r300 support to git master. Not that the r300 patch is very relevant as I can reproduce this on intel video machines as well. Erm, was mesa already using git in the 6.4.2 days? As that was the latest working version. Also installing 6.4.2 requires me to downgrade several key Operating system parts like the xserver, libdrm, etc. I don't want to know what I have todo to my system to be able to build 6.4.2 from source. As said I'm willing to spend some time on this, but telling me to go fetch a needle in a haystack isn't really helpful. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mesa3D threadsafe?
Hi all, I have recently written some small test applications that use pthreads to execute the commands between glBegin and glEnd in parallel. I have crafted it so that each parallel item is a whole quad/triangle (no STRIP). I know that the NVIDIA Linux driver has no support for this kind of operation because it crashed :( But Mesa compiled with the -D PTHREADS does! So I would like to know, are the operations that I am trying to perform in fact thread safe and are producing the correct results, as they appear correct by visual inspection, but for something larger I am unable to know if/when glError occurs and may miss it of something is going wrong. I also thought about using glFinish when I encounter glEnd, but again I cant know if it in fact conforms to specification. glFinish - block until all GL execution is complete thanks in advance -- * John Stavrakakis PhD Candidate Department of Information Technologies University of Sydney Email: [EMAIL PROTECTED] WWW: http://wiki.vislab.usyd.edu.au/moinwiki/JohnStavrakakis ** - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
